Desarrollo de Software Orientado a Objetos

Universidad Nacional del Santa
Facultad de Ingeniería
EAP Ingeniería de Sistemas e Informática
Desarrollo de Software Orientado a Objetos
Versión Mayo – 2009
Por:
Ing. Camilo Ernesto Suárez Rebaza
Docente UNS
Dpto. Acad. Ing. Civil y Sistemas
EAP Ingeniería de Sistemas e Informática
-2-
INDICE
I.
Fundamentos de la Tecnología Orientada a Objetos....................................... 4
1.1. Conceptos Básicos de la Orientación a Objetos .................................................. 4
1.2. Tecnologías Orientadas a Objetos ........................................................................... 5
II. Sistemas de Información .................................................................................... 7
2.1. Ciclo de Vida de los Sistemas de Información .................................................... 7
2.2. Tipos y Usos de los Sistemas de Información ...................................................... 7
2.3. Metodología para el desarrollo de Sistemas ......................................................... 9
III. Arquitectura Cliente/Servidor ......................................................................... 10
3.1. Terminología y Conceptos ....................................................................................... 11
3.2. Capas en una Arquitectura Cliente /Servidor ..................................................... 13
IV. Lenguaje Unificado de Modelado (UML) ....................................................... 18
4.1. Modelo Conceptual de UML................................................................................... 19
4.2. Modelado de la Arquitectura de un Sistema ....................................................... 24
V. Proceso Unificado de Rational (RUP) ............................................................. 26
5.1. Mejores Prácticas para el desarrollo de Software.............................................. 26
5.2. Estructura del Proceso: Dos dimensiones ............................................................ 30
5.3. Core Workflows (Flujos de Trabajo Central) ..................................................... 36
VI. Rational Rose ..................................................................................................... 39
VII. Bibliografía ........................................................................................................ 41
2
INTRODUCCION
En la actualidad los sistemas de información basados en computadoras, son el centro
de actividades de muchas organizaciones y objeto de gran consideración en la toma
de decisiones. Las tecnologías de información aplicadas eficientemente a los
sistemas automatizados hacen posible que las organizaciones tengan una estructura
funcional de alto desempeño para actuar como negocios integrados. Esto motiva a
que varias organizaciones traten de adoptar los nuevos avances tecnológicos de la
información con el propósito de integrar y mejorar el control de su carga procesal.
La implantación de sistemas informáticos en las organizaciones no está siendo
cabalmente explotada, ya que son pocos los colegios que utilizan adecuadamente sus
equipos computarizados, llegando a usar en sus áreas administrativas herramientas
ofimáticas para la presentación de documentos y mecanismos manuales para el
procesamiento de Datos. Esto conlleva a buscar una mejora en la actual forma de
trabajo administrativo de los colegios, automatizando sus principales procesos de
control con el fin de obtener información rápida, exacta y oportuna.
I. Fundamentos de la Tecnología Orientada a Objetos
1.1. Conceptos Básicos de la Orientación a Objetos
Algunas de las ideas fundamentales que subyacen en la tecnología
orientada a objetos son las siguientes:
Objeto: Los objetos son construcciones representacionales de las
entidades. Los objetos encapsulan las características estructurales
conocidas como atributos y las características de comportamiento
conocidas como operaciones. Los atributos son construcciones que
representan las características estructurales de las entidades y determinan
los posibles estados de un objeto. Las operaciones son construcciones
representacionales de las características de comportamiento de las
entidades y determinan los comportamientos posibles de un objeto
invocado, en respuesta a la recepción de un mensaje. Los objetos son
instanciamientos de clases.
Clases: Las clases son descripciones de objetos con una implementación
en común. Las clases están ligadas a la implementación uniforme de las
características estructurales y de comportamiento, es decir especifica una
estructura de datos y los métodos operativos permisibles que se aplican a
cada uno de sus objetos. Fundamentalmente, las clases son descripciones
de objetos con atributos, implementación de operaciones, semánticas,
asociaciones e interacciones comunes.
Métodos: Los métodos especifican la forma en que se controlan los datos
de un objeto. Los métodos en una clase sólo hacen referencia a las
estructuras de datos de ese tipo de objeto. No tienen acceso directo a las
estructuras de datos de otros objetos, debiéndoles enviar un mensaje para
utilizar su estructura.
Herencia: Es un mecanismo mediante el cual se puede crear una nueva
clase partiendo de una existente, se dice entonces que la nueva clase
hereda las características de la clase existente, aunque se le puede añadir
4
más capacidades o modificar las que tiene. Por lo tanto una subclase puede
heredar la estructura de datos y los métodos o algunos de los métodos de
su clase padre o superclase.
Polimorfismo: Hace referencia a la posibilidad de que dos métodos
implementen distintas acciones, aun teniendo el mismo nombre,
dependiendo del objeto que lo ejecuta o de los parámetros que recibe. Es
una operación que adopta varias formas de implantación, es decir se puede
hacer una solicitud de una operación sin conocer el método que debe ser
llamado. Estos detalles de la implantación quedan ocultos para el usuario.
Mensajes: Un mensaje es una solicitud para llevar a cabo una operación
indicada y producir un resultado. Una solicitud invoca una operación
específica, con uno o más objetos como parámetros.
1.2. Tecnologías Orientadas a Objetos
La Tecnología Orientada a Objetos es un nuevo enfoque sobre la manera
de organizar las diferentes piezas que componen un sistema de
información (software), el equipo físico (hardware) o una base de datos.
Estas piezas son denominadas "objetos", los cuales son pequeños
subsistemas independientes con datos propios caracterizados por clases y
tipos, y que están regidos por propiedades como herencia, comunicación
con lenguejes, poliformismos y otros que en conjunto permiten diferentes
ventajas prácticas.
Análisis Orientado a Objetos (AOO):
En el AOO se distinguen los objetos que van a ser parte de la aplicación.
En un primer momento, no se debe enfocar con rigurosidad los objetos que
pueden hacer falta en una aplicación. Lo que se hace, es un Brain Storming
(tormenta de ideas depuradas con posterioridad), para luego explicar con
mayor claridad los puntos funcionales definidos utilizando escenarios. Hay
que tener en claro la idea de que un buen análisis puede acortar
5
considerablemente la fase de desarrollo de programas, por ello, no se debe
escatimar horas en organizar y estructurar la aplicación en cuestión.
Diseño Orientado a Objetos (DOO):
El DOO de una aplicación es la implementación del AOO, teniendo en
cuenta el lenguaje con el que se va a programar. El enfoque particular del
análisis orientado a objetos (AOO), modela la forma en que las personas
comprenden y procesan la realidad a través de los conceptos que
adquieren. Estos conceptos se pueden implantar por diversos medios, entre
los que están las máquinas, computadoras y personas. Así uno de los
objetivos del diseño se restringe al software de aplicación, en donde los
diseños orientados a objetos (DOO) no necesitan de un lenguaje de
programación orientado a objetos para implantarse.
Programación Orientada a Objetos (POO):
Anteriormente la mayoría de las personas programaban de un modo TOPDown, en el que la programación era totalmente secuencial. En la POO los
mismos programas son vistos como objetos. El interés creciente en el
campo del análisis y el diseño orientado a objetos es debido a que la
programación orientada a objetos (POO) permite la producción de diseños
con esquemas flexibles, haciendo posible una fácil estructuración del
programa, similar a la forma de pensar humana.
Base de Datos Orientada a Objetos (BDOO) :
Una base de datos orientada a objetos (BDOO) es una base de datos
inteligente que está diseñada para ser físicamente eficiente en el
almacenamiento de datos complejos. Las bases de datos orientadas a
objetos toman la idea de las bases inteligentes de datos a su conclusión
lógica. No se tiene acceso a dato alguno si no es a través de los métodos
almacenados en la base de datos. Estos métodos están listos para entrar en
acción al momento en que reciben una solicitud. Los datos de todos los
objetos quedan entonces encapsulados.
6
II. Sistemas de Información
2.1. Ciclo de Vida de los Sistemas de Información
El concepto de ciclo de vida de un sistema de información es medular en
las investigaciones de sistemas. Durante su desarrollo, cada sistema se
mueve a través de varias fases de un ciclo de vida, después del cual sólo
funciona por varios años con un mínimo mantenimiento. El sistema se
deteriora gradualmente hasta el punto en que cesa de funcionar por
completo y se comienza un nuevo ciclo de vida con el desarrollo de un
nuevo sistema. Los autores sobre sistemas de información ilustran el ciclo
de vida con diferentes números de fases. Los ciclos de vida de sistemas
varían en gran manera en términos de longitud, pero por lo regular el ciclo
de vida de un sistema de información está en el rango de 3 a 8 años.
2.2. Tipos y Usos de los Sistemas de Información
Los Sistemas de Información cumplen tres objetivos básicos:
1) Automatizar los procesos operativos.
2) Proporcionar información que sirva como apoyo al proceso de toma de
decisiones organizacionales.
3) Lograr ventajas competitivas a través de su implantación y uso.
Los Sistemas de Información que logran la automatización de procesos
operativos dentro de una organización, son llamados frecuentemente
Sistemas Transaccionales, ya que su función primordial consiste en
procesar transacciones tales como pagos, cobros, entradas, salidas y sus
controles. Por otra parte, los Sistemas de Información que apoyan el
proceso de toma de decisiones son llamados Sistemas de Soporte a la
Toma de Decisiones. El tercer tipo de sistemas, de acuerdo con su uso y
objetivo, es el de los Sistemas Estratégicos, los cuales se desarrollan en las
organizaciones con el fin de lograr ventajas competitivas, a través del uso
de la tecnología de información. Por último se considera un cuarto tipo de
Sistemas de Información denominado Sistemas Personales de Información,
enfocado a incrementar la productividad de los usuarios.
7
Sistemas de Control de Información:
El Control es un sistema que permite asegurar que la puesta en marcha de
los objetivos institucionales se desarrolle de acuerdo a la planificación, o
bien, que se ajusten los procesos a aquellas variables que no pudieron ser
previstas durante el período de planificación. Para diseñar un proceso de
control de información, se reconocen cinco pasos esenciales, que son:
a) Definición de los resultados deseados por la Institución, para ello los
objetivos deben expresarse en términos precisos.
b) Establecer predictores de resultados, para controlar el conjunto de
actividades durante la marcha del proyecto.
c) Definir los estándares para los predictores y los resultados,
determinando normas para evaluar tanto los resultados intermedios
como los finales.
d) Diseñar una red de información y retroalimentación, recopilando
información en las diversas etapas del proyecto, y comparándola con
las normas definidas.
e) Evaluar la información y poner en marcha la acción correctiva.
Un Sistema de Control de Información es un Sistema de Informacción
transaccional y estratégico que abarca el control de:
La planeación y administración de recursos, para apoyar los objetvos
del sistema de información
Los recursos de cómputo, para ser utilizado en forma efectiva
proporcionando controles de entrada y salida adecuados, y guardando
los archivos de datos en un almacenamiento seguro.
El software del sistema, siguiendo procedimientos sistemáticos para
mantener y usar el software adquirido o desarrollado.
El acceso a los recursos de cómputo, para prever la seguridad física y
lógica de los recursos de cómputo evitando el uso no autorizado.
Integridad de Sistemas:
La integración es el método o procedimiento que sigue una Institución con
el fin de aprovechar todos los medios señalados por la mecánica
8
administrativa. La integridad es considerada como una de las fuerzas de
diseño que actúa sobre los componentes principales de un Sistema de
Información, permitiendo la comunicación entre dependencias dentro y
fuera de un área Institucional. Para desarrollar un Sistema Integral es
necesario seguir tres pasos bien marcados, que son:
a) Usar métodos adecuados para la selección de elementos y recursos
necesarios en cada dependencia institucional.
b) Articular rápida y eficazmente los nuevos elementos a la funcionalidad
de cada dependencia.
c) Estudiar las necesidades de progreso y desarrollo de las nuevas
funcionalidades de la institución.
La integración de los sistemas de información tienden a diseñarse con un
acoplamiento más estrecho entre sus diversas dependencias funcionales,
permitiendo que la conectividad y la comunicación mejore dentro de las
mismas. La tecnología informática está insertada y enlazada en las
organizaciones para una sincronización completa y una coordinación de
sus operaciones. Un sistema integral evita la separación funcional y
espacial del lugar de trabajo, dando como resultado una malla de
información organizacional.
2.3. Metodología para el desarrollo de Sistemas
La metodología del desarrollo de sistemas es el camino que siguen los
analistas de sistemas para realizar su trabajo. Se emplea el término
genérico de analista de sistemas para describir a la persona que tiene la
responsabilidad principal de conjuntar los componentes estructurales,
dándoles forma y sustancia en conformidad con las fuerzas del diseño para
construir sistemas de información exitosos.
En una organización pequeña, el analista quizás no solo diseñará el sistema
de información, sino que también hará la programación y operará la
computadora. En una organización grande el analista de sistemas solo
preparará las especificaciones del diseño que se darán a los técnicos.
9
III. Arquitectura Cliente/Servidor
La tecnología informática permite no sólo disminuir el papeleo y en general
agilizar las operaciones, sino también aumentar la competitividad de la empresa.
Los tiempos actuales han modificado substancialmente la forma de operar de las
organizaciones y ha inducido modificaciones en el quehacer de la tecnología
computacional dentro de ellas. Algunos de los aspectos que han cambiado son
los siguientes:
Las aplicaciones deben ser desarrolladas más rápidamente pues los
requerimientos del negocio cambian rápidamente.
La importancia de contar con una buena información destaca el fundamental
papel que juegan los sistemas de información.
Cada vez es más importante el poder hacer que la información esté
disponible en donde se necesita.
A medida que crece la competencia, las organizaciones tienen cada vez
menos recursos disponibles para los proyectos internos.
Con el fin de aumentar la productividad y de facilitar el uso de las
aplicaciones por parte de los usuarios, se requieren interfaces simples e
intuitivas, y que proporcionen un acceso transparente a la información.
Cada vez es mayor la tendencia hacia la integración de los sistemas evitando
las "islas de información" en las diferentes dependencias de una empresa.
Las aplicaciones deben adaptarse al ritmo vertiginoso de desarrollo de la
tecnología, para que puedan aprovechar sus potencialidades.
Las tecnologías computacionales modernas buscan responder a éstas
necesidades empresariales y para ello plantean nuevas formas de hacer las cosas.
Entre ellas una de las más importantes es el llamado modelo o Arquitectura
Cliente/Servidor. En el sentido más estricto, el término Cliente/Servidor describe
un sistema en el que una máquina cliente solicita a una segunda máquina
llamada servidor que ejecute una tarea específica. El cliente suele ser una
computadora personal común conectada a una LAN, y el servidor es, por lo
general, una máquina anfitriona, como un servidor de archivos PC. Algunas de
las principales LAN cliente/servidor con servidores especializados que pueden
realizar trabajos para clientes, incluyen a Windows NT, NetWare de Novell,
10
VINES de Banyan y LAN Server de IBM entre otros. Todos estos sistemas
operativos de red pueden operar y procesar solicitudes de aplicaciones que se
ejecutan en clientes, mediante el procesamiento de las solicitudes mismas.
3.1. Terminología y Conceptos
Cliente:
Una aplicación que inicia una comunicación con otra se la califica como
Cliente. Los usuarios finales invocan aplicaciones cliente cuando utilizan
un servicio de red.
Cada vez que se ejecuta una aplicación cliente, esta
contacta con el servidor, le envía una solicitud de servicio y espera la
respuesta o resultados del servicio. Los Clientes interactúan con el usuario,
usualmente en forma gráfica. Frecuentemente se comunican con procesos
auxiliares que se encargan de establecer conexión con el servidor, enviar el
pedido, recibir la respuesta, manejar las fallas y realizar actividades de
sincronización y de seguridad.
Por lo tanto, un proceso cliente es el encargado de llevar a cabo la
interacción con el usuario y de mostrar los resultados de las peticiones de
servicio. En la mayoría de las ocasiones los Clientes son mas fáciles de
diseñar que los servidores, y no suelen precisar privilegios especiales del
sistema para poder funcionar. En general el programa cliente cumple dos
funciones distintas: por un lado gestiona la comunicación con el servidor,
solicita un servicio y recibe los datos enviados por aquél. Por otro, maneja
la interface con el usuario: presenta los datos en el formato adecuado y
brinda las herramientas y comandos necesarios para que el usuario pueda
utilizar las prestaciones del servidor de forma sencilla.
Servidor:
Un Servidor es un programa que espera peticiones de servicio por parte de
un cliente. El Servidor recibe la petición del cliente, ejecuta el servicio
solicitado y retorna los resultados al cliente. No existe una interacción
directa entre el usuario y el servidor, de esto se encarga la aplicación
11
cliente. El programa servidor en cambio, sólo tiene que encargarse de
transmitir la información de manera eficiente. De esta forma un mismo
servidor puede atender a varios clientes al mismo tiempo.
Por consiguiente, los Servidores proporcionan un servicio al cliente y
devuelven los resultados. En algunos casos existen procesos auxiliares que
se encargan de recibir las solicitudes del cliente, verificar la protección,
activar un proceso servidor para satisfacer el pedido, recibir su respuesta y
enviarla al cliente. Además deben manejar los interbloqueos, la
recuperación ante fallas, y otros aspectos afines. Por las razones anteriores
la plataforma computacional asociada con los servidores es más poderosa
que la de los clientes.
Por esta razón se utilizan PCs poderosos, estaciones de trabajo,
minicomputadores o sistemas grandes. Por otro lado deben manejar
servicios como administración de la red, mensajes, control, administración
de la entrada al sistema (“login”), y recuperación. Usualmente en los
servidores existe además algún tipo de servicio de bases de datos.
Infraestructura de Comunicaciones:
Para que los clientes y los servidores puedan comunicarse se requiere una
infraestructura de comunicaciones, la cual proporciona los mecanismos
básicos de direccionamiento y transporte. La mayoría de los sistemas
Cliente/Servidor actuales se basan en redes locales y por lo tanto utilizan
protocolos no orientados a conexión, lo cual implica que las aplicaciones
deben hacer las verificaciones. La red debe tener características adecuadas
de desempeño, confiabilidad, transparencia y administración.
En una red de comunicaciones, el cliente es la máquina solicitante y el
servidor es la máquina proveedora mediante un software especializado en
ambos extremos. Por ejemplo, en un sistema de base de datos basado en
redes, la interface de usuario reside en el cliente, y las funciones de
almacenamiento y recuperación de datos, en el servidor.
12
Privilegios y Complejidad:
Debido a que los servidores a menudo tienen la necesidad de acceder a
datos, funciones, o puertos que el sistema operativo protege, el software
servidor suele precisar de privilegios del sistema especiales para poder
realizar la tarea para la cual ha sido creado. Como consecuencia de esto se
tiene mucho cuidado para evitar que los privilegios concedidos al servidor
sean aprovechados por los clientes para obtener permisos especiales. Por
ejemplo, un servidor de objetos que se ejecuta como un programa
privilegiado debe contener código para verificar si un cliente dado tiene
permiso para acceder a un objeto en concreto. El servidor no puede relegar
esta función sobre el sistema operativo, ya que su estado privilegiado le
sitúa, en ciertos aspectos concretos, por encima del sistema. Los
programas servidores deben contener código que maneje situaciones de:
Autenticación : Verificar la identidad del cliente.
Autorización : Determinar si un cliente dado posee permisos para
acceder al servicio que suministra.
Seguridad de datos : Garantizar que la información no es revelada, de
manera no intencionada, a clientes sin autorización.
Privacidad : Preservar la información de un usuario de accesos no
autorizados.
Protección : Garantizar que las aplicaciones de red no puedan abusar
de los recursos del sistema.
Los servidores que realizan un intensivo uso de la potencia del procesador
o que manejan grandes volúmenes de información operan más
eficientemente si manejan las solicitudes de servicio concurrentemente. La
combinación de privilegios especiales y ejecución concurrente, por norma
general, hace que los servidores sean más difíciles de diseñar e
implementar que los clientes.
3.2. Capas en una Arquitectura Cliente /Servidor
En un esquema Cliente/Servidor clásico (Figura 1) existen dos capas, el
cliente y el servidor: éste último está ubicado normalmente en otra
13
máquina, y suele ser un gestor de base de datos, como DB2, SQL Server,
Sybase Adaptive Server, Oracle, aunque también puede ser una base de
datos más pequeña, como Paradox, dBase, etc., a los cuales se acceden
directamente desde una aplicación cliente. Los mejores gestores de base de
datos relacionales proporcionan soporte para implementar en ellos diversas
reglas de negocio, mediante el uso de claves primarias, integridad
referencial, triggers, etc., mientras que sistemas como dBase y otros
apenas proporcionan soporte para reglas de negocio.
Figura 1 Arquitectura Cliente /Servidor en dos capas
Suponiendo que se tenga la información en un gestor de bases de datos
potente, entonces se podrá llevar a cabo la codificación de numerosas
validaciones: así, si en la base de datos se crea una regla de integridad
referencial que indique que todo pedido pertenece a un cliente, el gestor de
base de datos rechazará cualquier intento de almacenar un pedido en el que
no se indique al mismo. Cualquier aplicación que acceda a esta base de
datos se beneficiará de esta y otras validaciones automáticamente, sin tener
que añadir ni una línea de código. Si se utiliza una base de datos menos
potente, casi todas las reglas de negocio deberán implementarse dentro de
los programas que accedan a la base de datos. Si los programas que
acceden a la base de datos son varios, garantizar que en todos ellos se
respetan todas las reglas puede llegar a ser muy difícil y engorroso,
especialmente si se desarrollan con distintas herramientas.
Las bases de datos relacionales son cada vez más potentes, pero no todas
las reglas de negocio pueden reflejarse en ellas: por ejemplo, las reglas de
flujo son bastante difíciles de implementar dentro de la base de datos, y
14
suelen ser las aplicaciones cliente las que controlan que la información
siga una ruta válida a través del sistema. El problema se agrava cuando la
información del negocio se encuentra en distintas bases de datos, en donde
no hay manera de establecer una regla de integridad referencial entre
tablas almacenadas en dos bases de datos distintas y correspondientes a
distintos gestores de base de datos.
De nuevo, la solución al problema es implementar el chequeo en cada
aplicación cliente. Por lo tanto es conveniente encontrar la manera de
centralizar la gestión de estas reglas en un único lugar, de modo que todo
el código necesario no se tenga que duplicar en cada una de las
aplicaciones. La solución es crear una aplicación que se encargue de llevar
a cabo estas tareas, de modo que todos los clientes pidan o envíen
información a la misma, no al gestor de base de datos en el servidor: a éste
solo accederá la nueva aplicación, que conforma una nueva capa dentro de
un sistema Cliente/Servidor, la capa intermedia o middle-tier (Figura 2),
con lo que el sistema pasa de ser un sistema Cliente/Servidor convencional
a ser un sistema con tres capas (three-tiered), en la que puede haber varias
de estas aplicaciones, llamadas servidores de aplicación, lo que permite
distribuir la carga de trabajo.
Figura 2 Arquitectura Cliente /Servidor en tres capas (Three-Tiered)
Ubicación de las Reglas o la lógica del Negocio :
La decisión de dónde ubicar una determinada regla de negocio dentro de
una arquitectura Cliente/Servidor en tres capas puede simplificarse mucho
15
si se atiende al tipo de regla. Las reglas del modelo de datos especifican
los valores válidos para cada campo de cada tabla. Estas reglas deben ser
reforzadas en el servidor. Como complemento de esto, sin embargo, se
debe implementar estas validaciones también a nivel de cliente, por una
simple razón: evitar trabajo y esperas innecesarias a los usuarios.
Por lo que respecta a las reglas de relación, el lugar más adecuado para
implementarlas es el servidor. La mayor parte de los gestores de base de
datos proporcionan integridad referencial y los mecanismos necesarios
para implementar fácilmente estas reglas. Además, el hecho de que los
datos necesarios para verificar si se respetan las relaciones residan en la
misma base de datos hace que las verificaciones sean rápidas, mientras que
si el chequeo se hace en el cliente se incrementará el tráfico de red.
Las reglas de derivación pueden variar mucho en complejidad. Lo ideal es
implementar las reglas de derivación complejas en la capa intermedia para
su ejecución en el servidor, posiblemente mediante un procedimiento
almacenado, o mediante una sentencia SQL. Por otro lado, las reglas más
sencillas pueden también implementarse en la capa intermedia, de modo
que se tenga las reglas de cálculo centralizadas en una única aplicación.
Las reglas de restricción deben implementarse en el servidor, o en la capa
intermedia. Dado que estas reglas contemplan restricciones en los datos
que dependen casi siempre de información presente en varias tablas, llevar
a cabo el control en el cliente puede implicar cierto tráfico de red, por lo
que es más conveniente situar la implementación de la regla más cerca de
los datos.
Por último, quedan las reglas de flujo: estas reglas son excelentes
candidatas a ser implementadas en la capa intermedia, dado que su
complejidad suele ser bastante grande, lo que las hace inmanejables por un
gestor de bases de datos.
16
Figura 3 Ubicación de las reglas de negocio dentro del esquema de tres capas
Sistemas Cliente/Servidor en tres Capas:
Un Sistema Cliente/Servidor en tres capas representa un Sistema
Distribuido en el que se han separado los distintos servicios que componen
el sistema. La división que normalmente se sigue para estos sistemas es la
definición de tres capas lógicas (que posteriormente se convertirán en
diferentes capas físicas) de la siguiente manera: En la capa más inferior se
encuentra la capa de datos, en esta capa se ubican las diferentes bases de
datos de las que la aplicación obtendrá y añadirá datos, en ésta capa
también se encuentran los procedimientos almacenados que ayudan a
simplificar los accesos, modificaciones e inserciones sobre los datos.
La siguiente capa contiene las reglas o la lógica de negocios, en esta capa
se definen los componentes (entendiéndose por componente un conjunto
de clases que hacen algo) que contienen la definición de las operaciones
que son necesarias para que el sistema haga su trabajo, además en dichos
componentes residen las operaciones que manejan los datos de la capa
inferior. En éstos componentes están las reglas que dicen como utilizar los
datos y mantienen la integridad de los mismos. Por otro lado la capa de
negocios oculta una posible distribución física de los datos.
Por último está la capa de presentación, ésta capa se encarga únicamente
de presentar los datos a los usuarios y de establecer la interface para que
17
exista una comunicación entre los mismos usuarios y el sistema. Esta capa
carece de procesamiento y se limita únicamente a mostrar los datos a los
usuarios y comprobar que las peticiones de los mismos son, por lo menos,
semánticamente, correctas y de esta manera evitar que se hagan peticiones
a la capa de negocio que a priori son inviables debido a que incumplen
algún requisito previo.
En éste sentido, un sistema cliente/servidor en tres capas establece, al
menos, tres capas donde los usuarios no tienen constancia sobre como se
almacenan ni donde residen los datos, estos sólo se comunican con la capa
de presentación, ésta se ocupa de procesar las peticiones de los usuarios y
transmitirlas a los componentes de la capa de negocios, en esta capa se
procesará la petición modificando, pidiendo o consultando los datos
necesarios, que son provistos por la capa de datos que además de proveer
dichos datos a la capa superior se encarga de almacenarlos y mantenerlos
correctamente.
IV. Lenguaje Unificado de Modelado (UML)
El Lenguaje Unificado de Modelado es un lenguaje estándar para escribir planos
de software. UML puede utilizarse para visualizar, especificar, construir y
documentar los artefactos de un sistema que involucra una gran cantidad de
software. UML es apropiado para modelar desde sistemas de información en
empresas hasta aplicaciones distribuidas basadas en la web. Es un lenguaje de
modelado que proporciona un vocabulario y reglas para su uso en la
representación conceptual y física de un sistema. La decisión de usar
actualmente UML como notación para procesos software se debe a que se ha
convertido en un estándar de facto que tiene las siguientes características:
Permite modelar sistemas utilizando técnicas orientadas a objetos (OO).
Cubre la especificación de todas las decisiones de análisis, diseño e
implementación, permitiendo la construcción de modelos precisos.
Puede conectarse con lenguajes de programación usando Ingeniería directa e
inversa (Java, C++, Visual Basic).
18
Permite documentar todos los artefactos de un proceso de desarrollo
(requisitos, arquitectura, pruebas, versiones, etc.)
Cubre las cuestiones relacionadas con el tamaño propias de los sistemas
complejos y críticos.
Es un lenguaje muy expresivo que cubre todas las vistas necesarias para
desarrollar y luego desplegar los sistemas.
Existe un equilibrio entre expresividad y simplicidad, pues no es difícil de
aprender ni de utilizar.
UML es independiente del proceso, aunque para utilizarlo óptimamente debe
ser usado en un proceso dirigido por los casos de uso, centrado en la
arquitectura, iterativo e incremental.
4.1. Modelo Conceptual de UML
Para comprender UML, se necesita adquirir un modelo conceptual del
lenguaje, y esto requiere aprender tres elementos principales: los bloques
de construcción de UML, las reglas que dictan cómo se pueden combinar
estos bloques básicos y algunos mecanismos comunes que se aplican a
través de UML.
Bloques de Construcción UML:
El vocabulario de UML incluye tres clases de bloques de construcción:
Elementos, Relaciones y Diagramas. Los ELEMENTOS son abstracciones
de primera clase en un modelo. Hay cuatro tipos de elementos en UML:
Elementos estructurales, Elementos de Comportamiento, Elementos de
agrupación y Elementos de anotación.
Los elementos estructurales, son los nombres de los modelos UML. En su
mayoría son las partes estáticas de un modelo, y representan cosas que son
conceptuales o materiales. Hay siete tipos de elementos estructurales.
1) Clase: Es una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semántica. Una clase
implementa una o más interfaces. Gráficamente una clase se representa
19
como un rectángulo, que normalmente incluye su nombre, atributos y
operaciones.
2) Interfaz : Es una colección de operaciones que especifican un servicio
de una clase o componente. Una interfaz puede representar el
comportamiento completo de una clase o componente o sólo una parte
de ese comportamiento. Gráficamente una interfaz se representa con un
círculo junto con su nombre.
3) Colaboración: Define una interacción y es una sociedad de roles y
otros elementos que colaboran para proporcionar un comportamiento
cooperativo mayor que la suma de los comportamientos de sus
elementos. Gráficamente, una colaboración se representa como una
elipse de borde discontinuo, incluyendo normalmente sólo su nombre.
4) Caso de Uso: Es una descripción de un conjunto de secuencias de
acciones que un sistema ejecuta y que produce un resultado observable
de interés para un actor particular. Gráficamente, un caso de uso se
representa
como
una
elipse
de
borde
continuo,
incluyendo
normalmente sólo su nombre.
5) Componente: Es una parte física y reemplazable de un sistema que
conforma un conjunto de interfaces y proporciona la implementación
de dicho conjunto. Gráficamente, un componente se representa como
un rectángulo con pestañas, incluyendo normalmente sólo su nombre.
6) Nodo: Es un elemento físico que existe en tiempo de ejecución y
representa un recurso computacional, que por lo general dispone de
algo de memoria y, con frecuencia, capacidad de procesamiento.
Gráficamente un nodo se representa como un cubo.
Los elementos de comportamiento, son las partes dinámicas de los
modelos UML. Estos son los verbos de un modelo y representan
comportamiento en el tiempo y el espacio. Hay dos tipos principales de
elementos de comportamiento.
20
1) Interacción: Es un comportamiento que comprende un conjunto de
mensajes intercambiados entre un conjunto de objetos. Gráficamente,
un mensaje se muestra como una línea dirigida con el nombre de su
operación.
2) Máquina de estados: Es un comportamiento que especifica las
secuencias de estados por las que pasa un objeto o una interacción.
Gráficamente, un estado se representa como un rectángulo de esquinas
redondeadas, incluyendo su nombre y sus subestados.
Los elementos de agrupación, son las partes organizativas de los modelos
UML. Estos son las cajas en las que puede descomponerse un modelo.
Hay un elemento de agrupación principal, los paquetes.
1) Paquete : Es un mecanismo de propósito general para organizar
elementos en grupos. Gráficamente, un paquete se visualiza como una
carpeta, incluyendo sólo su nombre y, a veces, su contenido.
Los elementos de anotación, son las partes explicativas de los modelos
UML. Hay un tipo principal de elemento de anotación llamado nota.
1) Nota : Es simplemente un símbolo para mostrar restricciones y
comentarios. Gráficamente, una nota se representa como un rectángulo
con una esquina doblada, junto con un comentario textual o gráfico.
Las RELACIONES en UML son de cuatro tipos: Dependencia,
Asociación, Generalización y Realización.
Una dependencia, es una relación semántica entres dos elementos, en la
cual un cambio a un elemento puede afectar a la semántica del otro
elemento. Gráficamente una dependencia se representa como una línea
discontinua, posiblemente dirigida, que incluye a veces una etiqueta.
Una asociación, es una relación estructural que describe un conjunto de
enlaces. La agregación es un tipo especial de asociación, que representa
una relación estructural entre un todo y sus partes. Gráficamente, una
asociación se representa como una línea continua dirigida, que a veces
21
incluye una etiqueta, y a menudo incluye otros adornos, como la
multiplicidad y los nombres del rol.
Una generalización, es una relación de especialización/generalización en
la cual los objetos del elemento especializado (el hijo) pueden sustituir a
los objetos del elemento general (el padre). Gráficamente, una relación de
generalización se representa como una línea continua con una punta de
flecha vacía apuntando al padre.
Una realización, es una relación semántica entre clasificadores, en donde
un clasificador especifica un contrato que otro clasificador garantiza que
cumplirá. Gráficamente una relación de realización se representa como una
mezcla entre una generalización y una relación de dependencia.
Los DIAGRAMAS en UML son la representación gráfica de un conjunto
de elementos. En teoría, un diagrama UML puede contener cualquier
combinación de elementos y relaciones. En la práctica, sin embargo, sólo
surge un pequeño número de combinaciones, las cuales son consistentes
con las cinco vistas más útiles que comprenden la arquitectura de un
sistema. Por esta razón UML incluye nueve diagramas:
Un diagrama de clases, muestra un conjunto de clases, interfaces y
colaboraciones, así como sus relaciones. Los diagramas de clases cubren la
vista de diseño estática de un sistema.
Un diagrama de objetos, muestra un conjunto de objetos y sus relaciones.
Estos diagramas cubren las vista de diseño estática o la vista de procesos
estática de un sistema.
Un diagrama de casos de uso, muestra un conjunto de casos de uso y
actores relacionados. Los diagramas de casos de uso cubren la vista de
casos de uso estática de un sistema.
Los diagramas de interacción cubren la vista dinámica de un sistema. Un
diagrama de secuencia, es un diagrama de interacción que resalta la
ordenación temporal de los mensajes; un diagrama de colaboración, es un
diagrama de interacción que resalta la organización estructural de los
objetos que envían y reciben mensajes.
22
Un diagrama de estados, muestra una máquina de estados, que consta de
estados, transiciones, eventos y actividades. Los diagramas de estados
cubren la vista dinámica de un sistema.
Un diagrama de actividades, es un tipo especial de diagrama de estados
que muestra el flujo de actividades dentro de un sistema. Los diagramas de
actividades cubren la vista dinámica de un sistema.
Un diagrama de componentes, muestra la organización y las dependencias
entre un conjunto de componentes. Los diagramas de componentes cubren
la vista de implementación estática de un sistema.
Un diagrama de despliegue, muestra la configuración de nodos de
procesamiento en tiempo de ejecución y los componentes que residen en
ellos. Los diagramas de despliegue cubren la vista de despliegue estática.
Reglas de UML:
Los bloques de construcción de UML, no pueden simplemente combinarse
de cualquier manera. Como cualquier lenguaje, UML tiene un número de
reglas que especifican a qué debe parecerse un modelo bien formado.
UML tiene reglas semánticas para:
Nombres : Cómo llamar a los elementos, relaciones y diagramas.
Alcance : El contexto que da un significado específico a un nombre.
Visibilidad : Cómo se pueden ver y utilizar esos nombres por otros.
Mecanismos Comunes en UML:
La construcción de modelos UML se hace más simple y armonioso al
ajustarse a un patrón de características comunes. En UML existen cuatro
mecanismos comunes:
Especificaciones: Proporcionan una base semántica que incluye a
todos los elementos de todos los modelos de un sistema.
Adornos: Sirven para conferir a los modelos de más semántica,
proporcionando a un elemento o modelo más nivel de detalle.
Divisiones comunes: Permiten que los modelos se dividan al menos en
un par de formas diferentes para facilitar su comprensión.
23
Mecanismos de extensibilidad: Sirven para poder representar ciertos
matices, incluye a los estereotipos, los valores etiquetados, y las
restricciones.
Figura 4 Vista General del Modelo Conceptual de UML
4.2. Modelado de la Arquitectura de un Sistema
La visualización, especificación, construcción y documentación de un
sistema con gran cantidad de software requiere que el sistema sea visto
desde varias perspectivas. La arquitectura de un sistema es quizás el
artefacto más importante que puede emplearse para manejar estos
diferentes puntos de vista y controlar el desarrollo iterativo e incremental
de un sistema a lo largo de su ciclo de vida.
La arquitectura de un sistema con gran cantidad de software puede
describirse mejor a través de cinco vistas interrelacionadas. Cada vista es
una proyección de la organización y la estructura del sistema, centrada en
un aspecto particular de ese sistema.
24
La vista de casos de usos, comprende los casos de uso que describen el
comportamiento del sistema tal y como es percibido por los usuarios
finales, analistas y encargados de las pruebas.
La vista de diseño, comprende las clases, interfaces y colaboraciones
que forman el vocabulario del problema y su solución.
La vista de procesos, comprende los hilos y procesos que forman los
mecanismos de sincronización y concurrencia del sistema.
La vista de implementación, comprende los componentes y archivos
que se utilizan para ensamblar y hacer disponible el sistema físico.
La vista de despliegue, contiene los nodos que forman la topología
hardware sobre la que se ejecuta el sistema.
Figura 5 Modelado de la arquitectura de un sistema
25
V. Proceso Unificado de Rational (RUP)
El Proceso Unificado de Rational es un proceso de ingeniería de software que se
adapta especialmente a UML. Proporciona una disciplina metodológica para la
asignación de tareas y responsabilidades dentro del desarrollo organizacional.
Tiene por objetivo asegurar la producción de software de alta calidad de acuerdo
a las necesidades de los usuarios finales dentro de un cronograma y presupuesto
predecible. RUP es un producto proceso. Es desarrollado y mantenido por
Software Rational y viene integrado con un conjunto de herramientas
desarrolladoras de software. RUP es también un proceso armazón (framework)
que puede ser adaptado y extendido para satisfacer las necesidades de una
organización. Esta metodología captura muchas de las mejores prácticas para
desarrollar software modernos, de una forma que sea adecuada a un amplio
rango de proyectos y organizaciones.
5.1. Mejores Prácticas para el desarrollo de Software
Si las causas de los problemas para el desarrollo de software son tratadas
de raíz, no sólo se eliminarán los síntomas, sino también se tendrá una
mejor posición para desarrollar y mantener software de calidad de un
modo repetible y predecible. La mejor práctica software radica en probar
todas los posibles métodos en el desarrollo del mismo, de manera que el
equipo de trabajo pueda descubrir la causa que origina los problemas
durante el desarrollo de software. Estas son las “mejores prácticas” no
porque se pueda cuantificar las causas de los problemas en forma precisa,
sino porque su uso permitirá el éxito de una organización. Las mejores
prácticas para el desarrollo de software son las siguientes:
Desarrollar software iterativamente.
Manejar requerimientos.
Usar una arquitectura basada en componentes.
Modelar visualmente el software.
Verificar continuamente la calidad del software.
Controlar los cambios en el software.
26
Desarrollo de software iterativo
El desarrollo de software iterativo ofrece las siguientes soluciones a las
causas de los problemas encontrados en su desarrollo:
1) Hace evidente serios errores de manera fácil durante el ciclo de vida,
siendo posible reaccionar a ellos.
2) Esta metodología facilita y estimula el uso de la retroalimentación, de
manera que responda a los requerimientos reales del sistema.
3) El equipo de desarrollo es forzado para centrarse en los temas más
críticos del proyecto, evitando de esta manera los riesgos reales
durante su ciclo de vida.
4) Continuas iteraciones permiten probar un objetivo estimado del estado
del proyecto.
5) Las inconsistencias entre requerimientos, diseños, e implementaciones
son detectadas fácilmente.
6) La carga de trabajo del equipo, especialmente del equipo de pruebas,
es dividida más uniformemente a lo largo del ciclo de vida del
proyecto.
7) El equipo de trabajo puede usar enseñanzas aprendidas y por
consiguiente puede mejorar el proceso continuamente.
8) Pueden detectarse riesgos en el proyecto, proporcionando la evidencia
concreta del estado del proyecto a lo largo de su ciclo de vida.
Figura 6 Proceso Iterativo e Incremental de RUP
27
Manejo de requerimientos
El manejo de requerimientos en un proyecto ofrece las siguientes
soluciones a las causas de los problemas durante el desarrollo de software:
1) Una metodología disciplinada que se construye bajo la administración
de requerimientos.
2) Las comunicaciones son basadas en requerimientos definidos.
3) Los requerimientos pueden ser priorizados, filtrados, y trazados.
4) Posibilita un objetivo estimado de funcionalidad y rendimiento.
5) Las inconsistencias son detectadas más fácilmente.
6) Con apoyo de la herramienta adecuada, es posible proveer un
repositorio para los requerimientos del sistema, atributos, y trazos, con
enlaces automáticos a documentos externos.
Uso de Arquitectura basada en componentes
El uso de una arquitectura basada en componentes ofrece las siguientes
soluciones a las causas de los problemas durante el desarrollo de software:
1) Los componentes facilitan la arquitectura elástica.
2) La modularidad permite una clara separación de intereses entre los
elementos de un sistema que están sujetas al cambio.
3) El reuso es facilitado para apoyar la estandarización de armazones y
poder comercializar los componentes disponibles.
4) Los componentes proveen una base natural para el manejo de
configuraciones.
5) Las herramientas de modelamiento visual proveen la automatización
para el desarrollo de componentes.
Modelado visual del software
El modelado visual del software ofrece las siguientes soluciones a las
causas de los problemas encontrados en su desarrollo:
1) Los casos de uso especifican comportamientos no ambiguos.
2) Los modelos no ambiguos capturan el diseño del software.
3) La no modularidad y las arquitecturas inflexibles son expuestas.
28
4) Los detalles pueden ser ocultados cuando sea necesario.
5) Los diseños no ambiguos revelan sus inconsistencias más rápidamente.
6) Las herramientas de modelado visual proveen soporte a modelamientos
basados en UML.
7) La calidad de la aplicación empieza con un buen diseño.
Figura 7 Modelamiento de un Sistema desde diversas perspectivas
Verificación continua de la calidad del software
La verificación continua de la calidad del software ofrece las siguientes
soluciones a las causas de los problemas encontrados en su desarrollo:
1) La estimación del estado del proyecto se hace objetiva, y no
subjetivamente, porque prueba los resultados, y no los documentos.
2) Esta estimación del objetivo expone inconsistentes requerimientos,
diseños e implementaciones.
3) Las pruebas y las verificaciones se enfocan en las áreas de más alto
riesgo, aumentando la calidad y efectividad de estas áreas.
4) Los defectos son identificados tempranamente, reduciendo en forma
radical el costo de arreglos.
5) Las herramientas de pruebas automatizadas proveen funcionalidad,
fiabilidad, y rendimiento.
29
Control de los cambios en el software
El control de los cambios en el software ofrece las siguientes soluciones a
las causas de los problemas encontrados en su desarrollo:
1) El flujo de trabajo de los cambios en los requerimientos es definido y
repetible.
2) Las peticiones de cambio facilitan comunicaciones claras.
3) Las áreas de trabajo aisladas reducen la interferencia entre los
miembros del equipo que trabajan en paralelo.
4) Los cambios en las proporciones estadísticas proveen una buena
métrica para evaluar el estado del proyecto objetivamente.
5) Las áreas de trabajo contienen todos los artefactos, que facilitan la
consistencia de un cambio.
6) La propagación de un cambio es tasable y controlada.
7) Los cambios pueden mantener a un sistema robusto y personalizado.
5.2. Estructura del Proceso: Dos dimensiones
Figura 8 Arquitectura Global del RUP (Dos dimensiones)
La figura 8 muestra la arquitectura global del Rational Unified Process. El
proceso tiene dos estructuras, o dos dimensiones:
El eje horizontal representa el tiempo y muestra como son
desplegados los aspectos del ciclo de vida del proceso.
30
El eje vertical representa los flujos de trabajo del proceso central (core
process), que agrupa las actividades lógicas por naturaleza.
La primera dimensión representa el aspecto dinámico del proceso, tal
como es implementado, y es expresado en términos de ciclos, fases,
iteraciones e hitos. La segunda dimensión representa el aspecto estático
del proceso y sé describe en términos de componentes del proceso,
actividades, flujos de trabajo, artefactos y trabajadores.
Aspecto Dinámico del RUP
Es la dinámica de la organización del proceso a lo largo del tiempo. El
ciclo de vida del software está dividido en ciclos y en cada ciclo se trabaja
una nueva generación del producto. RUP divide un ciclo de desarrollo en
cuatro fases consecutivas:
Fase de Iniciación (Inception).
Fase de Elaboración (Elaboration).
Fase de Construcción (Construction).
Fase de Transición (Transition ).
Cada fase concluye con un hito o hecho bien definido, que es un punto en
el tiempo en donde ciertas decisiones críticas deben hacerse, y por
consiguiente en donde se deben haber logrado metas importantes.
Fase de Iniciación:
Durante la fase de iniciación, se establece los casos de negocio del sistema
y se delimita el alcance del proyecto. El resultado de esta fase es:
Un documento visión: que es una visión general de los requerimientos
centrales del proyecto, características importantes, y restricciones
principales.
Un modelo de casos de uso inicial (10%-20% completo).
Un glosario inicial del proyecto (opcionalmente puede expresar en
forma parcial un modelo del dominio).
31
Un caso de negocio inicial que incluye el contexto del negocio,
criterios de éxito (proyección de réditos, reconocimiento de mercados,
etc.) y la proyección financiera.
Un plan del proyecto, mostrando fases e iteraciones.
Un modelo de negocio, si es necesario.
Uno o varios prototipos.
Al final de la fase de iniciación está el primer hito principal del proyecto:
Objetivos del ciclo de vida. El proyecto puede ser cancelado o repensado
considerablemente si falla al pasar el hito. Entre los principales criterios de
evaluación para la fase de iniciación tenemos:
Requerimientos entendidos como evidencias fidedignas de los casos de
uso primarios.
Profundidad y amplitud de cualquier prototipo arquitectónico
desarrollado.
Fase de Elaboración:
El propósito de la fase de elaboración es analizar el dominio del problema,
estableciendo un convincente fundamento arquitectónico; además se
desarrolla el plan del proyecto. El resultado de la fase de la elaboración es:
Un modelo de casos de uso (por lo menos 80% completo), en donde se
han identificado todos los casos de uso y actores, y se han desarrollado
la mayoría de descripciones de casos de uso.
Requerimientos suplementarios que capturan los requerimientos no
funcionales y cualquier requerimiento que no está asociado con un
caso de uso específico.
Una descripción de la Arquitectura del Software.
Un prototipo arquitectónico ejecutable.
Una lista de casos de negocio revisados.
Un plan de desarrollo para el proyecto global, mostrando las
“iteraciones” y el criterio de evaluación para cada iteración.
Un caso de desarrollo actualizado especificando el proceso a ser usado.
32
Un manual de usuario preliminar (optativo).
Al final de la fase de elaboración está el segundo hito principal del
proyecto: Arquitectura del ciclo de vida.
Aquí se examinan los alcances y los objetivos detallados del sistema, de la
arquitectura escogida. El proyecto puede abortarse o ser repensado
considerablemente si no pasa este hito. Los principales criterios de
evaluación para la fase de la elaboración involucra las respuestas a las
siguientes preguntas:
¿Es la visión del producto equilibrada?.
¿Es la arquitectura equilibrada?.
¿Es el plan para la fase de construcción suficientemente detallado y
exacto?
Fase de Construcción:
Durante la fase de construcción, se desarrollan todos los componentes
restantes y las características de la aplicación, los cuales son integrados
dentro del producto para luego ser cuidadosamente probados. El resultado
de la fase de construcción es un producto listo para ser puesto en manos de
los usuarios finales. Como mínimo consiste de:
El producto software integrado sobre plataformas adecuadas.
Los manuales de usuario (optativo).
Una descripción de la actual puesta en marcha.
Al final de la fase de construcción está el tercer hito principal del proyecto:
Capacidad Operacional Inicial. Aquí se decide si el software, las
localizaciones, y los usuarios están listos para operar. Esta versión es
llamada mayormente “beta”. La transición puede tener que ser pospuesta si
el proyecto no alcanza este hito. Los principales criterios de evaluación
para la fase de construcción involucra la respuesta a la siguiente pregunta:
¿Es esta versión del producto lo suficientemente estable y madura para
ser desplegada en la comunidad usuaria?.
33
Fase de Transición:
La fase de transición está completa cuando el producto base es
suficientemente maduro para ser desplegado en el dominio del usuario
final. Esta fase incluye:
Una “Prueba beta” para validar el nuevo sistema contra las
expectativas del usuario.
Conversión de base de datos operacionales.
Capacitación de usuarios y manejadores.
Al final de la fase de transición está el cuarto hito principal del proyecto:
Puesta en marcha del Producto. Aquí se decide si los objetivos fueron
alcanzados, y si se debe empezar otro ciclo de desarrollo. En algunos
casos, este hito puede coincidir con el extremo de la fase de iniciación del
próximo ciclo. Los principales criterios de evaluación para la fase de
transición involucra la respuesta a las siguiente pregunta:
¿Está el usuario satisfecho?.
Iteraciones :
Cada fase del RUP puede adicionalmente ser dividida en iteraciones. Una
iteración es un bucle de desarrollo completo que produce la puesta en
marcha (interna o externa) de un producto ejecutable o un subconjunto del
producto final, mediante el desarrollo incremental de iteración a iteración
hasta covertirse en el sistema final. Comparado con el proceso lineal, el
proceso iterativo tiene las siguientes ventajas:
Los cambios son más manejables.
Un alto nivel de reuso.
Mejor calidad global.
Aspecto Estático del RUP
Worker (Trabajador):
Un worker define la conducta y las responsabilidades de un individuo, o
un conjunto de individuos que trabajan grupalmente. Un individuo puede
tener muchos workers diferentes. En el RUP un worker representa más que
34
un rol definiendo como un individuo lleva a cabo su trabajo. Las
responsabilidades asignadas a un worker incluyen tanto la realización de
ciertos conjuntos de actividades así como la responsabilidad sobre un
conjunto de artefactos.
Activy (Actividad):
Una actividad de un worker específico es una unidad de trabajo que un
individuo puede realizar en ese rol. La actividad tiene un propósito claro,
usualmente expresado en términos de crear o actualizar algunos artefactos,
tales como un modelo, una clase o un plan. Cada actividad es asignada a
un worker específico. La granularidad de una actividad es generalmente de
unas cuantas horas a cuantos días, normalmente involucra a un worker, y
afecta a uno o solo a un pequeño número de artefactos.
Una actividad debe ser usada como un elemento de planeación y
desarrollo; si es demasiada pequeña debe ser abandonada, y si es
demasiada grande, el desarrollo tiene que ser expresado en términos de
partes de la actividad.
Artifac (Artefacto):
Un artefacto es un fragmento de información que puede ser producido,
modificado, o usado por un proceso. Los artefactos son los productos
tangibles del proyecto, los objetos del proyecto se producen o se usan
mientras se trabaja hacia el final del proyecto. Los artefactos son usados
por los workers como entradas para realizar una actividad, y como salidas
de resultados o rendimientos de tal actividad. En términos de diseño
orientado a objetos, las actividades son las operaciones en un objeto activo
(el worker) y los artefactos son los parámetros de estas actividades que
pueden tomar los siguientes estados o formas:
Un modelo, como el modelo de casos de uso o el modelo de diseño.
Un modelo elemental, es decir un elemento dentro de un modelo, como
una clase, un caso de uso o un subsistema.
Un documento, como el documento de casos del negocio o de la
arquitectura del Software.
Código fuente y Ejecutables.
35
Workflows (Flujos de Trabajo):
La enumeración de todos los workers, actividades y artefactos no
constituyen un proceso realmente. Se necesita describir de manera
significativa la secuencia de las actividades para producir resultados
valiosos, y para mostrar las interacciones entre workers. Un workflow es
una secuencia de actividades que produce un resultado de valor
observable. En términos de UML, un workflow puede ser expresado como
un diagrama de secuencia, un diagrama de colaboración, o un diagrama de
actividades.
5.3. Core Workflows (Flujos de Trabajo Central)
Hay nueve procesos de flujos de trabajo central en el RUP, que
representan una visión de todos los workers y actividades dentro de una
distribución lógica. Los procesos de flujos de trabajo están divididos en
seis flujos de trabajo central de “Ingeniería”: Modelo del negocio,
Requerimientos,Análisis y Diseño, Implementación, Prueba, y Despliegue;
y en tres flujos de trabajo central de “soporte”: Administración del
proyecto, Configuración y Administración de cambios, y Entorno.
Business Model (Modelo del Negocio):
RUP proporciona un idioma común entre la ingeniería del negocio y la
ingeniería de software. Este modelo documenta los procesos del negocio
usando los llamados casos de uso del negocio. Los casos de uso del
negocio son analizados para comprender cómo el negocio debe soportar
sus procesos. Esto es documentado en un modelo de objetos del negocio.
Requeriments (Requirimientos):
El objetivo del flujo de trabajo de requerimientos es describir lo que hace
el sistema , permitiendo el mutuo acuerdo entre los desarrolladores y los
clientes. Se crea un documento visión, y se solicitan los grupos de trabajo
necesarios. Se identifican los Actores (Actors) representando los usuarios,
y cualquier otro sistema que puede interactuar con el sistema a desarrollar.
36
Además se identifican los Casos de uso (Uses case) representando la
conducta del sistema. Los casos de uso son desarrollados de acuerdo a las
necesidades del actor y describen lo que hace el sistema y como interactúa
paso a paso con el actor.
Analysis and Design (Análisis y Diseño):
El objetivo del análisis y diseño es mostrar cómo será realizado el sistema
en la fase de implementación. Este flujo de trabajo resulta en un modelo de
diseño y opcionalmente en un modelo de análisis. El modelo de diseño
sirve como una abstracción del código fuente y consiste de clases de
diseño estructurados dentro de paquetes y subsistemas con interfaces bien
definidas. Comprende:
El cumplimiento de todos los requerimientos.
La Ejecución de las tareas y funciones especificadas es la decripción
de los casos de uso.
Una estructuración robusta (deben cambiar fácilmente si cambian los
requerimientos funcionales)
Implementation (Implementación):
El sistema es realizado a través de la implementación de componentes.
RUP describe cómo se reusará los componentes existentes, o cómo se
implementará los nuevos componentes, haciendo el sistema más fácil de
mantener e incrementando las posibilidades de reuso. El propósito de la
implementación es:
Definir el código de la organización, en términos de implementación
de subsistemas organizados en capas.
Implementar clases y objetos en términos de componentes.
Probar los componentes desarrollados como unidades.
Integrar los resultados producidos por implementadores individuales
(o equipos), dentro de un sistema ejecutable.
37
Test (Prueba):
La prueba es llevada a cabo a lo largo de tres dimensiones de calidad:
funcionalidad, rendimiento de la aplicación, y rendimiento del sistema. El
propósito de la prueba es:
Verificar la interacción entre los objetos.
Verificar la correcta integración de todos los componentes del
software.
Verificar que todos los requerimientos han sido correctamente
implementados.
Identificar y asegurar que los defectos sean tratados antes del
despliegue del software.
Deployment (Despliegue):
El propósito del flujo de trabajo de despliegue es producir un producto
exitoso para su puesta en marcha, y entregar el software a los usuarios
finales. Cubre un amplio rango de actividades que incluye:
Producción del software para su puesta en marcha externa.
Empaquetamiento del software.
Distribución del software.
Instalación del software.
Proporción de ayuda y asistencia a los usuarios.
Administración del proyecto:
Este flujo de trabajo se enfoca principalmente sobre el aspecto específico
de un proceso de desarrollo iterativo. El objetivo de este flujo es
proporcionar: una estructura para manejar los proyectos de software
intensivos, las pautas prácticas para planear, proveer el personal, ejecutar,
y monitorear el proyecto, y una estructura para manejar los riesgos.
Configuración y Administración de cambios:
En este flujo de trabajo se describe cómo controlar los diferentes artefactos
producidos por las personas que trabajan en un proyecto común. Los
38
controles ayudan a evitar la confusión costosa, y aseguran que los
artefactos resultantes no entren en conflicto debido a: la actualización
simultánea, la notificación simultánea y las versiones múltiples.
Entorno:
El propósito del este flujo de trabajo es proporcionar la organización del
software de desarrollo con su entorno (procesos y herramientas) para
soportar el desarrollo en equipo.
VI. Rational Rose
Rational Rose es una de las mejores herramientas de modelado de software que
forma parte del Rational Suite, un conjunto de herramientas unificadas con
soporte a Rational Unified Process (RUP). Estas herramientas facilitan el trabajo
durante todo el ciclo de vida de un proyecto. Rational Rose permite el desarrollo
de aplicaciones software así como el modelamiento de sus componentes
visuales. Además está comprensivamente integrada a la resolución de diseños
apropiados para afrontar a los actuales desafíos en el desarrollo de software.
Rational Rose unifica el desarrollo en equipo, integrando el modelamiento y el
entorno de desarrollo usando Unified Modeling Languaje (UML), y permitiendo
a todos los miembros del equipo el desarrollo individual, la comunicación entre
ellos y la entrega de un mejor software. Esta herramienta crea una robusta
arquitectura del sistema con la habilidad para modelar elásticas arquitecturas
basadas en componentes, permitiendo que la evolución del proceso software sea
controlada, manejada e identificada. Rational Rose es una herramienta Case para
todas las necesidades tecnológicas, ya que ofrece una integración con todos los
principales Entornos de Desarrollo Integrado, maximizando la velocidad y
simplicidad del esfuerzo de desarrollo.
Rational Rose puede soportar el modelado de arquitecturas cliente/servidor en
tres capas. Con el modelamiento de la arquitectura en tres capas se hace factible
la creación de una familia de aplicaciones basadas en un conjunto común de
componentes para su fácil distribución, extensibilidad, y mantenimiento. Al
modelar un esquema basado en tres capas se brinda una forma más poderosa de
39
modelamiento
orientado
a
objetos
para
el
diseño,
programación
e
implementación del sistema, siendo posible modelar arquitecturas conducidas
por procesos de desarrollo iterativo.
Los métodos de desarrollo de software recomiendan el uso de vistas estáticas y
dinámicas para el modelado lógico y físico de los artefactos de un proceso
durante el análisis y diseño orientado a objetos. Usando ésta notación Rational
Rose permite crear y refinar éstas vistas dentro de un modelo global
representando el dominio del problema y el sistema software. Este modelo
global contiene clases, casos de uso, objetos, paquetes lógicos, operaciones,
paquetes de componentes, componentes, procesos, dispositivos y las relaciones
existentes entre ellos. Además cada uno de éstos elementos poseen propiedades
que identifican sus características.
Un modelo también contiene diagramas y especificaciones, que proporcionan un
medio de visualización y manipulación de los elementos. Puesto que los
diagramas son usados para ilustrar múltiples vistas de un modelo, los íconos que
representan un elemento pueden aparecer en ninguno, uno o varios diagramas.
Rational Rose permite controlar qué elementos, relaciones y propiedades
aparecen en cada diagrama a través de ventanas independientes.
Un add-in (programa de ayuda) permite a un lenguaje de programación
integrarse a Rational Rose a través del uso de una sola sesión de software. Se
puede tener add-ins con la instalación personalizada de Rational Rose o por
intermedio de links brindados por las empresas desarrolladoras de software,
permitiendo el soporte de diferentes necesidades de desarrollo.
40
VII. Bibliografía
1. Berson, Alex; “Client Server Architecture: Three Tier”; 3°Edición, 1999, Edit.
McGraw Hill ,USA.
2. Booch, G., Rumbaugh, I.; “The Unified Modeling Languaje”; 2ºEdición, 1999,
Edit. Addison-Wesley, USA.
3. Booch G., Rumbaugh, I.; “The Unified Software Development Process”;
2ºEdición, 1999, Edit. Addison-Wesley Longman, USA.
4. Grupo Eidos; “Diseño Orientado a Objetos con UML”; Versión 1.0.0, 2000.
5. Letelier Torres, Patricio; “Análisis y Diseño Orientado a Objetos usando la
Notación UML”; 2°Edición, 2001, Edit. U.P.V, Madrid – España.
6. McClanahan, David; “Power Builder 7.0: A Developer’s Guide”; 2000, Editorial
M&T Books, USA.
7. Mora Uriarte, Felipe; “Metodología de la Investigación Científica y Técnicas de
Estudio”; 7°Edición, 1998, Lima – Perú.
8. OnLine Books Help; “Técnicas para Construir Aplicaciones Distribuidas con
Power Builder V8.0”; 2001.
9. OnLine Help; Rational Rose 2001.
10. Universidad de Oviedo, Area de Sistemas; “Proceso Software Basado en UML
para Aplicaciones Distribuidas”; 2001, España.
11. Stoner, James; “Administración de Sistemas”; 3°Edición, 1998, Ed, Prinfice Holl
Hispanoamérica S.A, Mexico.
12. Rational Suite; “Rational Unified Process”; 2001.
41