2. INTRODUCCIÓN A LOS DIAGRAMAS DE UML · 2012. 5. 9. · Análisis y Diseño Orientado a Objetos...
Transcript of 2. INTRODUCCIÓN A LOS DIAGRAMAS DE UML · 2012. 5. 9. · Análisis y Diseño Orientado a Objetos...
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 1 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
1. INTRODUCCIÓN A UML...............................................................................................................................6 1.1. QUÉ ES UML ................................................................................................................................................6 1.2. QUE ES UN MODELO .....................................................................................................................................6 1.3. COMO NACE UML ........................................................................................................................................7 1.4. DONDE SE UTILIZA........................................................................................................................................7
2. INTRODUCCIÓN A LOS DIAGRAMAS DE UML ....................................................................................8 2.1. INTRODUCCIÓN .............................................................................................................................................8 2.2. LOS DIAGRAMA DE UML .............................................................................................................................8
2.2.1. Diagrama de Clases.............................................................................................................................8 2.2.2. Diagrama de Objetos...........................................................................................................................8 2.2.3. Diagrama de Casos de Uso .................................................................................................................8 2.2.4. Diagrama de Estados...........................................................................................................................9 2.2.5. Diagrama de Actividades ....................................................................................................................9 2.2.6. Diagrama de Comunicación................................................................................................................9 2.2.7. Diagrama de Secuencia .......................................................................................................................9 2.2.8. Diagrama de Componentes ...............................................................................................................10 2.2.9. Diagrama de Despliegue ...................................................................................................................10
2.3. CLASIFICACIÓN...........................................................................................................................................11 2.3.1. Diagramas Estáticos..........................................................................................................................11 2.3.2. Diagramas Dinámicos .......................................................................................................................11 2.3.3. Diagramas Estructurales...................................................................................................................12 2.3.4. Diagramas de Comportamiento ........................................................................................................12
3. EL DIAGRAMA DE CLASES (CLASS DIAGRAM).................................................................................13 3.1. DEFINICIÓN.................................................................................................................................................13 3.2. OBJETIVO ....................................................................................................................................................13 3.3. ELEMENTOS ................................................................................................................................................13
3.3.1. Clase...................................................................................................................................................13 3.3.2. Interfaz ...............................................................................................................................................14
3.4. RELACIONES ...............................................................................................................................................15 3.4.1. Generalización...................................................................................................................................15 3.4.2. Asociación..........................................................................................................................................16 3.4.3. Composición.......................................................................................................................................16 3.4.4. Agregación .........................................................................................................................................17 3.4.5. Implementación o Realización...........................................................................................................17
3.5. CLASES ESTEREOTIPADAS ..........................................................................................................................18 3.5.1. Que es un estereotipo de clase ..........................................................................................................18 3.5.2. El estereotipo Boundary ....................................................................................................................18 3.5.3. El estereotipo Control........................................................................................................................18 3.5.4. El estereotipo Entity...........................................................................................................................19 3.5.5. Representación grafica ......................................................................................................................19
3.6. APLICACIÓN................................................................................................................................................20 3.6.1. Modelo de Análisis o Modelo Conceptual ........................................................................................20 3.6.2. Modelo de Diseño ..............................................................................................................................20 3.6.3. Diseño de Base de Datos ...................................................................................................................21
3.7. EJEMPLO .....................................................................................................................................................21 4. DIAGRAMA DE OBJETOS (OBJECT DIAGRAM).................................................................................22
4.1. DEFINICIÓN.................................................................................................................................................22 4.2. OBJETIVO ....................................................................................................................................................22 4.3. ELEMENTOS ................................................................................................................................................22
4.3.1. Objeto .................................................................................................................................................22 4.4. RELACIONES ...............................................................................................................................................22
4.4.1. Vínculo ...............................................................................................................................................22
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 2 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
4.4.2. Vínculo Direccional ...........................................................................................................................23 4.5. APLICACIÓN................................................................................................................................................23
4.5.1. Fotografía del sistema .......................................................................................................................23 4.6. EJEMPLO .....................................................................................................................................................24
5. DIAGRAMA DE CASOS DE USO ...............................................................................................................25 5.1. DEFINICIÓN.................................................................................................................................................25 5.2. OBJETIVO ....................................................................................................................................................25 5.3. ELEMENTOS ................................................................................................................................................26
5.3.1. Actor ...................................................................................................................................................26 5.3.2. Caso de Uso (Use Case) ....................................................................................................................26
5.4. RELACIONES ...............................................................................................................................................26 5.4.1. Asociación..........................................................................................................................................26 5.4.2. Generalización...................................................................................................................................27 5.4.3. Especialización ..................................................................................................................................27 5.4.4. Inclusión.............................................................................................................................................28 5.4.5. Extensión ............................................................................................................................................28
5.5. APLICACIÓN................................................................................................................................................29 5.5.1. Captura de Requisitos Funcionales...................................................................................................29 5.5.2. Modelo de Casos de Uso ...................................................................................................................29 5.5.3. Establecimiento de contratos.............................................................................................................29 5.5.4. Construcción de Casos de Prueba (Test Cases) ...............................................................................29
5.6. EJEMPLO .....................................................................................................................................................30 6. DIAGRAMA DE ESTADOS..........................................................................................................................31
6.1. DEFINICIÓN.................................................................................................................................................31 6.2. OBJETIVO ....................................................................................................................................................31 6.3. ELEMENTOS ................................................................................................................................................31
6.3.1. Estado (State).....................................................................................................................................31 6.3.2. Estado compuesto (Sub-machine State) ............................................................................................31 6.3.3. Pseudo-Estado Inicial (Initial State) .................................................................................................32 6.3.4. Pseudo-Estado Final (Final State)....................................................................................................32 6.3.5. Punto de Entrada (Entry Point).........................................................................................................33 6.3.6. Punto de Salida (Exit Point) ..............................................................................................................33 6.3.7. Estado de Sincronización (Sync State) ..............................................................................................34 6.3.8. Estado Histórico (Shallow History State) .........................................................................................34 6.3.9. Estado Histórico Profundo (Deep History State) .............................................................................34 6.3.10. Fork ..................................................................................................................................................35 6.3.11. Join ...................................................................................................................................................35 6.3.12. Unión (Junction) ..............................................................................................................................36 6.3.13. Decisión (Choice) ............................................................................................................................36
6.4. RELACIONES ...............................................................................................................................................37 6.4.1. Transición ..........................................................................................................................................37
6.5. APLICACIÓN................................................................................................................................................37 6.5.1. Seguimiento de un objeto...................................................................................................................37
6.6. EJEMPLO .....................................................................................................................................................38 7. DIAGRAMA DE ACTIVIDADES ................................................................................................................39
7.1. DEFINICIÓN.................................................................................................................................................39 7.2. OBJETIVO ....................................................................................................................................................39 7.3. ELEMENTOS ................................................................................................................................................39
7.3.1. Actividad (Activity) ............................................................................................................................39 7.3.2. Actividad Estructurada (Structured Activity)....................................................................................39 7.3.3. Acción (Action) ..................................................................................................................................39 7.3.4. Objeto (Object) ..................................................................................................................................40 7.3.5. Datastore Object ................................................................................................................................40
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 3 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
7.3.6. CentralBuffer Node............................................................................................................................40 7.3.7. Pseudo-Estado Inicial (Initial State) .................................................................................................41 7.3.8. Pseudo-Estado Final (Final State)....................................................................................................41 7.3.9. Señal de Envío (Send Signal).............................................................................................................41 7.3.10. Señal de Recepción (Receive Signal) ..............................................................................................41 7.3.11. Manejador de Excepciones (Exception Handler) ...........................................................................42 7.3.12. Fork ..................................................................................................................................................42 7.3.13. Join ...................................................................................................................................................43 7.3.14. Decisión (Choice) ............................................................................................................................43 7.3.15. Partición (Partition) ........................................................................................................................44
7.4. RELACIONES ...............................................................................................................................................44 7.4.1. Flujo de control (Control Flow)........................................................................................................44 7.4.2. Flujo de objeto (Object Flow) ...........................................................................................................45 7.4.3. Flujo de objeto con Pines (Pinned Object Flow)..............................................................................45 7.4.4. Flujo de Interrupción (Interrupt Flow) .............................................................................................45
7.5. APLICACIÓN................................................................................................................................................45 7.5.1. Desarrollo de aplicaciones procedurales .........................................................................................45 7.5.2. Modelado de procesos de negocio - Workflow .................................................................................46
7.6. EJEMPLO .....................................................................................................................................................47 8. DIAGRAMA DE COMUNICACIÓN (COMMUNICATION DIAGRAM) ............................................48
8.1. DEFINICIÓN.................................................................................................................................................48 8.2. OBJETIVO ....................................................................................................................................................48 8.3. ELEMENTOS ................................................................................................................................................48
8.3.1. Actor ...................................................................................................................................................48 8.3.2. Objeto .................................................................................................................................................48 8.3.3. Boundary ............................................................................................................................................48 8.3.4. Control ...............................................................................................................................................49 8.3.5. Entity ..................................................................................................................................................49
8.4. RELACIONES ...............................................................................................................................................49 8.4.1. Vinculo ...............................................................................................................................................49 8.4.2. Vinculo Direccional ...........................................................................................................................49 8.4.3. Mensaje ..............................................................................................................................................49
8.5. APLICACIÓN................................................................................................................................................50 8.5.1. Realización de Casos de Uso en el Modelo de Análisis ...................................................................50
8.6. EJEMPLO .....................................................................................................................................................51 9. DIAGRAMA DE SECUENCIA (SEQUENCE DIAGRAM)......................................................................52
9.1. DEFINICIÓN.................................................................................................................................................52 9.2. OBJETIVO ....................................................................................................................................................52 9.3. ELEMENTOS ................................................................................................................................................52
9.3.1. Actor ...................................................................................................................................................52 9.3.2. Línea de vida (LifeLine).....................................................................................................................52 9.3.3. Boundary ............................................................................................................................................52 9.3.4. Control ...............................................................................................................................................53 9.3.5. Entity ..................................................................................................................................................53
9.4. RELACIONES ...............................................................................................................................................53 9.4.1. Mensaje ..............................................................................................................................................53
9.5. APLICACIÓN................................................................................................................................................53 9.5.1. Realización de Casos de Uso en el Modelo de Diseño .....................................................................53
9.6. EJEMPLO .....................................................................................................................................................54 10. DIAGRAMA DE COMPONENTES...........................................................................................................55
10.1. DEFINICIÓN...............................................................................................................................................55 10.2. OBJETIVO ..................................................................................................................................................55 10.3. ELEMENTOS ..............................................................................................................................................55
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 4 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
10.3.1. Componente .....................................................................................................................................55 10.3.2. Interfaz .............................................................................................................................................55
10.4. RELACIONES .............................................................................................................................................56 10.4.1. Utilización (Use)..............................................................................................................................56 10.4.2. Implementación (Implementation)...................................................................................................56
10.5. APLICACIÓN..............................................................................................................................................57 10.5.1. Modelado de un Sistema..................................................................................................................57 10.5.2. Modelado de un Modulo..................................................................................................................57
10.6. EJEMPLO ...................................................................................................................................................58 11. DIAGRAMA DE DESPLIEGUE.................................................................................................................59
11.1. DEFINICIÓN...............................................................................................................................................59 11.2. OBJETIVO ..................................................................................................................................................59 11.3. ELEMENTOS ..............................................................................................................................................59
11.3.1. Nodo (Node).....................................................................................................................................59 11.3.2. Componente (Component) ...............................................................................................................59 11.3.3. Dispositivo (Device) ........................................................................................................................60 11.3.4. Ambiente de Ejecución (Execution Environment)...........................................................................60 11.3.5. Especificación de Despliegue (Deployment Spec)..........................................................................61
11.4. RELACIONES .............................................................................................................................................61 11.4.1. Asociación........................................................................................................................................61 11.4.2. Utilización (Use)..............................................................................................................................61 11.4.3. Comunicación (Communication Path)............................................................................................62
11.5. APLICACIÓN..............................................................................................................................................62 11.5.1. Definición de la arquitectura de un sistema ...................................................................................62
11.6. EJEMPLO ...................................................................................................................................................63 12. CONCEPTOS GENERALES ......................................................................................................................64
12.1. ESTEREOTIPOS ..........................................................................................................................................64 12.2. VALOR ETIQUETADO (TAGGED VALUES) .................................................................................................64 12.3. INGENIERÍA DIRECTA................................................................................................................................64 12.4. INGENIERÍA INVERSA................................................................................................................................64 12.5. EL LENGUAJE XMI ...................................................................................................................................65
13. INTRODUCCIÓN AL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE ..................66 13.1. DEFINICIÓN...............................................................................................................................................66 13.2. HISTORIA ..................................................................................................................................................66
13.2.1. El proceso Objectory .......................................................................................................................66 13.2.2. El proceso Objectory de Rational ...................................................................................................67 13.2.3. El Proceso Unificado de Rational (RUP) .......................................................................................67
13.3. LA NECESIDAD DE UNA METODOLOGÍA ....................................................................................................67 13.4. FUNDAMENTOS DEL PROCESO UNIFICADO DE DESARROLLO...................................................................68
13.4.1. Dirigido por Casos de Uso..............................................................................................................68 13.4.2. Centrado en una arquitectura .........................................................................................................69 13.4.3. Iterativo e incremental.....................................................................................................................70
13.5. CICLO DE VIDA DEL PROCESO UNIFICADO ...............................................................................................71 13.5.1. Fase de Inicio...................................................................................................................................71 13.5.2. Fase Elaboración.............................................................................................................................72 13.5.3. Fase de Construcción ......................................................................................................................72 13.5.4. Fase de Transición...........................................................................................................................72
14. LABORATORIOS.........................................................................................................................................73 14.1. LABORATORIO #1 – DIAGRAMA DE CLASES .......................................................................................73
14.1.1. Caso de Estudio ...............................................................................................................................73 14.1.2. Construcción del Diagrama ............................................................................................................73
14.2. LABORATORIO #02 – DIAGRAMA DE OBJETOS ...................................................................................74
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 5 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14.2.1. Caso de Estudio ...............................................................................................................................74 14.2.2. Construcción del Diagrama ............................................................................................................74
14.3. LABORATORIO #03 – DIAGRAMA DE CASOS DE USO..........................................................................75 14.3.1. Caso de Estudio ...............................................................................................................................75 14.3.2. Construcción del Diagrama ............................................................................................................75
14.4. LABORATORIO #04 – DIAGRAMA DE ESTADOS...................................................................................77 14.4.1. Caso de Estudio ...............................................................................................................................77 14.4.2. Construcción del Diagrama ............................................................................................................77
14.5. LABORATORIO #05 – DIAGRAMA DE ACTIVIDADES............................................................................78 14.5.1. Caso de Estudio ...............................................................................................................................78 14.5.2. Construcción del Diagrama ............................................................................................................78
14.6. LABORATORIO #06 – DIAGRAMA DE SECUENCIA ...............................................................................79 14.6.1. Caso de Estudio ...............................................................................................................................79 14.6.2. Construcción del Diagrama ............................................................................................................80
14.7. LABORATORIO #07 – DIAGRAMA DE COMUNICACIÓN........................................................................81 14.7.1. Caso de Estudio ...............................................................................................................................81 14.7.2. Construcción del Diagrama ............................................................................................................82
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 6 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
1. Introducción a UML 1.1. Qué es UML
UML es un lenguaje grafico que permite modelar, visualizar y documentar
sistemas. Esta compuesto por distintos diagramas que permiten ir representando
las distintas vistas de un sistema, cada diagrama tiene un objetivo bien definido.
UML significa Unified Modeling Language o Lenguaje Unificado de Modelado, y
esta basa en tres principios fundamentales:
• Es un Lenguaje: está formado por elementos y reglas bien definidas,
que poseen su propia sintaxis y semántica
• Esta Unificado: unifica los distintos criterios utilizados antes de su
creación, es decir que toma las mejores propuestas de herramientas previas
para presentar una propuesta sumamente abarcativa e integradora
• Permite Modelar: está basado en la construcción de modelos que
permite representar abstracciones de la realidad.
UML esta estrechamente ligado con el paradigma de objetos, lo que permite
construir sistemas de información de una forma mucho mas intuitiva, integrada y
sencilla con el proceso de desarrollo.
UML no es una metodología que presenta los pasos a seguir para realizar un
desarrollo, sino que es un lenguaje grafico de modelado.
1.2. Que es un Modelo Un modelo es una posibilidad de visualizar a escala o de una manera simulada
algo que será construido en la realidad. Es posible decir que antes de construir un
edificio se realizan maquetas a escala que representa modelos a seguir, así como
también cuando se construye un auto se confeccionan distintos planos o modelos
a escala para intentar simular o prever su comportamiento.
Académicamente, es posible definirla como una abstracción de la realidad, es una
simplificación de la realidad, con el objetivo final de pasar del modelo a producto
real.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 7 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Los modelos pueden ser expresados en distintos niveles de precisión, desde algo
muy genérico presentando una visión, hasta algo mucho mas especifico que
representa un gran compromiso con el producto a construir.
1.3. Como nace UML La historia cuenta que UML da sus primeros pasos con al unión de los “tres
amigos”: Booch, Rumbaugh y Jacobson.
En los años 80 cada uno utilizaba un lenguaje propietario aunque como
denominador común tenían como objetivo el desarrollo de sistemas, con previa
modelizacion. A partir de los años 90 comienzan a intercambiar ideas para
intentar unificar criterios.
Booch es el fundador de Rational Software Corp, y recluta en el año 1995 a
Rumbaugh y Jacobson para comenzar a determinar una especificación genérica,
sencilla y abarcativa.
Así es como las grandes empresas de tecnologías de información – entre ellas
Rational - deciden forman un consorcio para la construcción de un Lenguaje
Unificado de Modelado: UML. La primer versión de UML, la 1.0, sale a la luz en el
año 1997, y a partir de 1998 un organización llamada OMG (Object Management
Group) se encargo de generar nuevas revisiones. En el año 1998 UML se
establece como Standard de facto en la industria del Software.
1.4. Donde se utiliza UML se utiliza dentro del marco de IT, aunque puede utilizarse en proyectos que
no son de tecnología de la información, como ser el modelado de un motor o de
una turbina.
En el campo de IT, se utiliza tanto para sistemas monolíticos como para sistemas
distribuidos, abarca desde proyectos pequeños hasta grandes proyectos. Permite
realizar la integración del software, donde representa el correcto enlace de los
roles para lograr el éxito de la constricción del sistema. En proyectos de software,
es utilizado desde la gestación hasta la instalación y el testing.
Si bien para utilizar UML es posible realizar los distintos diagramas con papel y
lápiz, es conveniente contar con alguna herramienta del tipo IDE que facilite su
construcción, corrección e integración ente diagramas.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 8 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
2. Introducción a los diagramas de UML 2.1. Introducción
UML esta organizado en una serie de diagramas que tienen objetivos bien
definidos, con una sintaxis y semántica determinada, que intentan representar /
modelar distintas vistas de un sistema.
2.2. Los Diagrama de UML
2.2.1. Diagrama de Clases El Diagrama de Clases tiene como objetivo describir las clases del dominio y
sus relaciones. Permite modelar la estructura del sistema desde un punto de
vista estático, modelando las clases desde distintos enfoques de acuerdo a la
etapa del proyecto.
Esta compuesto por clases, relaciones entre clases y opcionalmente los paquetes
que agrupan a las clases.
2.2.2. Diagrama de Objetos El Diagrama de Objetos tiene como objetivo describir los objetos del dominio
y sus relaciones. Permite representar al sistema en un momento determinado
del tiempo, es proporcional a obtener una fotografía o snapshot del sistema en un
momento determinado.
Esta compuesto por objetos y relaciones de enlace. También es posible pensarlo
como una instancia de un Diagrama de Clases.
2.2.3. Diagrama de Casos de Uso El Diagrama de Casos de Uso tiene como objetivo describir las acciones del
sistema desde el punto de vista del usuario. Representa las formas que tiene
un usuario de utilizar un sistema, y se puede utilizar como un “contrato” entre
cliente y proveedor de software para determinar la funcionalidad del sistema, es
decir los requisitos funcionales.
Esta compuesto por actores (agentes externos al sistemas, pueden ser usuarios u
otros sistemas), casos de uso y distintos tipos de relaciones. Es posible construir
diagramas con diferentes niveles de detalle.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 9 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
2.2.4. Diagrama de Estados El Diagrama de Estados tiene como objetivo describir los estados por los
cuales puede pasar un objeto durante su ciclo de vida. Permite modelar
tanto estas simples como compuestos y concurrentes.
Esta compuesto por estados, pseudo-estados y transiciones entre estados.
2.2.5. Diagrama de Actividades El Diagrama de Actividades tiene como objetivo describir las acciones que
ocurren dentro de un proceso. Se utiliza principalmente para modelar flujo de
trabajo o workflow, con lo cual visualiza las acciones de manera ordenada.
Esta compuesto por acciones simples y concurrentes, y transiciones entre las
acciones.
2.2.6. Diagrama de Comunicación El Diagrama de Comunicación tiene como objetivo describir como colaboran o
se comunican los distintos objetos entre sí para conseguir un objetivo. Se
lo suele llamar también Diagrama de Colaboración. Es posible verlo como una
extensión del Diagrama de Objetos, ya que es muy parecido pero tiene como
valor agregado los mensajes que se envían entre los objetos.
Esta compuesto por objetos, relaciones de enlace y relaciones del tipo llamadas,
representando que objeto se comunica con que otro.
Es semánticamente equivalente al Diagrama de Secuencia.
2.2.7. Diagrama de Secuencia El Diagrama de Secuencia tiene como objetivo describir como colaboran los
distintos objetos entre sí para conseguir un objetivo a lo largo del
tiempo. Esta directamente relacionado con el Diagrama de Comunicación ya que
el objetivo es el mismo, pero tiene la particularidad de estar obligatoriamente
ordenado en el tiempo.
Esta compuesto por objetos y relaciones del tipo llamadas, representando que
objeto se comunica con que otro.
Es semánticamente equivalente al Diagrama de Comunicación.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 10 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
2.2.8. Diagrama de Componentes El Diagrama de Componentes tiene como objetivo describir la relación que
existe entre los distintos componentes del sistema. Esta directamente
vinculado con el diseño del sistema, permitiendo modelar las relaciones e
interfaces que existen entre los componentes. Está orientado a la implementación
del sistema.
Esta compuesto por componentes, interfaces y sus relaciones.
2.2.9. Diagrama de Despliegue El Diagrama de Despliegue tiene como objetivo describir la arquitectura de un
sistema. Es posible representar la arquitectura desde el punto de vista lógico,
basándose en la organización del software, o desde una punto de vista físico,
representando directamente cada unidad de hardware.
Esta compuesto por nodos, componentes y sus relaciones.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 11 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
2.3. Clasificación Es posible clasificar a los diagramas según si tienen alguna relación con el tiempo
o no. Existen dos posibles categorías, los diagramas estáticos y los diagramas
dinámicos.
2.3.1. Diagramas Estáticos Los Diagramas Estáticos son aquellos que no tienen ninguna relación con el
tiempo. Generalmente representan a estructuras o a posibles acciones pero sin
una relación directa con el tiempo.
Estos diagramas son:
• Diagrama de Clases
• Diagrama de Objetos
• Diagrama de Casos de Uso
• Diagrama de Componentes
• Diagrama de Despliegue
2.3.2. Diagramas Dinámicos Los Diagramas Dinámicos son aquellos que tienen relación con el tiempo. Están
directamente vinculados con acciones que ocurren bajo cierta secuencia, es decir
primero una acción, luego otra, y así sucesivamente.
Estos diagramas son:
• Diagrama de Actividades
• Diagramas de Interacción (es una subcategoría, que incluye a los
Diagramas de Secuencia y Comunicación)
• Diagrama de Estado
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 12 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
2.3.3. Diagramas Estructurales Los Diagramas Estructurales son aquellos que reflejan relaciones estáticas de
una estructura.
Estos diagramas son:
• Diagrama de Clases
• Diagrama de Objetos
• Diagrama de Componentes
• Diagrama de Despliegue
2.3.4. Diagramas de Comportamiento Los Diagramas de Comportamiento son aquellos que reflejan características
de comportamiento del sistema o modelan procesos de negocios.
Estos diagramas son:
• Diagrama de Casos de Uso
• Diagrama de Comunicación
• Diagrama de Secuencia
• Diagrama de Actividades
• Diagrama de Estados
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 13 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
3. El Diagrama de Clases (Class Diagram) 3.1. Definición
El diagrama de clases es un diagrama que permite modelar la estructura del
sistema desde un punto de vista estático, modelando las clases desde distintos
enfoques de acuerdo a la etapa del proyecto. Describe tipos de jerarquías,
relaciones y abstracciones.
3.2. Objetivo “..Describir las clases del dominio y sus relaciones..”
3.3. Elementos
3.3.1. Clase Una clase representa a una agrupación de cosas, es una plantilla para armar un
objeto. Las clases son detectadas – en la mayoría de los casos - como
sustantivos en singular.
Ejemplos de una clase puede ser la clase Auto, que es una clase representante de
todos los autos posibles (autos de carrera, autos urbanos, cualquier marca,
patente, color, etc.) Otro ejemplo puede ser la clase Animal, representando a
todos los animales posibles (mamíferos, herbívoros u otros, cualquier cantidad de
patas, color, etc.)
Las clases están formadas por atributos y métodos, y por convención, la primera
letra debe estar en mayúscula.
Que son los atributos
Los atributos son características que posee una clase, y determinan el
estado que posteriormente tendrá un objeto En el caso de la clase Auto,
atributos pueden ser color, marca, modelo, cantidad de puertas y velocidad.
Por convención, la primera letra debe estar en minúscula.
Que son los métodos
Los métodos son las responsabilidades (o comportamiento) que realiza una
clase. Generalmente los métodos son verbos. Por convención, la primera
letra debe estar en minúscula.
Representación grafica de una clase
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 14 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Las clases abstractas
Las clases abstractas son clases que representan un concepto abstracto, de
carácter muy general. Por ejemplo una institución, que tiene los atributos
dirección y superficie, pero no es posible determinar que tipo de institución
es.
Es una clase que no se puede instanciar, es decir que no se puede crear un
objeto a partir de ésta clase. Se utiliza como base para otras clases en la
relación de generalización, pero no tiene sentido por sí sola.
Las clases que no son abstractas se denominan concretas. Por convención,
la primera letra debe estar en mayúscula, y la palabra en negrita e itálica.
Representación grafica de una clase abstracta
3.3.2. Interfaz A diferencia de la clase, la interfaz define únicamente un comportamiento, es
decir un conjunto de métodos que no poseen implementación. Estos
métodos deberán ser implementados por las clases que decidan implementar
la interfaz. Representa un “contrato” que una clase debe respetar en caso de
implementar la interfaz.
Por ejemplo, se puede crear un interfaz denominada Volador, que tiene los
métodos despegar, aterrizar y volar.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 15 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Por convención, para definir el nombre de una interfaz se aplican las mismas
reglas que para una clase.
3.4. Relaciones
3.4.1. Generalización La relación de generalización se produce entre dos clases. La clase superior es
una generalización de la clase inferior, como así también la clase inferior es una
particularización de la clase superior.
A la clase superior se la denomina superclase, y a la clase inferior se la
denomina subclase. La subclase deberá respetar la relación “es un” o “is a”,
que representa a la relación de generalización.
Al construir varios relaciones de este tipo entre clases, se genera la jerarquía de
clases (o árbol de clases). En términos de un lenguaje de programación, es
posible entenderla como herencia.
Por ejemplo, la clase MedioDeTransporte puede ser una superclase, y algunas de
sus subclases pueden ser Auto, Avión y Tren.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 16 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
3.4.2. Asociación La relación de asociación representa una asociación entre dos clases, donde una
clase “es socia” de otra o tienen algún tipo de relación. Es común describir con
un nombre definido por el usuario la relación entre ambas.
Por ejemplo, la clase Cuidador tiene una relación con la clase Perro, donde
Cuidador “cuida” al Perro. Es posible determinar la multiplicidad de los extremos
de la relación, en el caso anterior un cuidador cuida de uno a muchos perros.
Existen dos relaciones denominadas Composición y Agregación que son casos
particulares de la relación de Asociación.
3.4.3. Composición La relación de composición se puede describir como “está compuesta por”, ya
que una clase determina la existencia de la otra. Si Clase1 está compuesta por
Clase2 entonces Clase1 determina la existencia de Clase2. Clase2 no podrá existir
por si sola si no existe Clase1, es decir que Clase1 controla el tiempo de vida de
Clase2. Si la Clase1 es eliminada, también será eliminada Clase2, es decir que si
se elimina el “todo” (Clase1), también serán eliminadas sus partes (Clase2).
UML denomina a la relación como “strong has-a relationship”, representando un
fuerte sentido de pertenencia del “todo” hacia la “parte”.
Por ejemplo, un Auto está compuesta por un Carburador, con lo cual el
Carburador no tiene sentido por si solo si no existe el Auto. Dicho Carburador
puede utilizarse únicamente para ese Auto, y no para otros, es decir que el
mismo Carburador no puede utilizarse al mismo tiempo en más de un Auto.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 17 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Otro ejemplo muy ilustrativo puede ser la relación entre una Tabla y una
Columna, donde la Columna es construida si la Tabla es construida, y la Columna
es eliminada si la Tabla es eliminada.
3.4.4. Agregación La relación de agregación se puede describir como “tiene como partes a”. A
diferencia de la composición, si Clase1 tiene como partes a Clase2, Clase1 no
determina la existencia de Clase2. Clase2 puede existir aún cuando Clase1 no
exista, es decir tiene sentido por si sola. Clase1 no controla el tiempo de vida de
Clase2. Si la Clase1 es eliminada, puede no ser eliminada Clase2, es decir que si
se elimina el “todo” (Clase1), no necesariamente serán eliminadas sus partes
(Clase2).
UML denomina a la relación como “weak has-a relationship”, representando un
débil sentido de pertenencia del “todo” hacia la “parte”.
Por ejemplo, una OrdenDeCompra tiene como partes a uno o muchos
Producto(s), pero si el Producto no forma parte de ninguna OrdenDeCompra,
sigue teniendo sentido por si mismo. Si la OrdenDeCompra es eliminada, el
Producto no será eliminado.
3.4.5. Implementación o Realización La relación de implementación se produce entre una clase y una interfaz. La clase
que implementa la interfaz tiene la obligación de implementar todos los métodos
que forman parte de esa interfaz.
Por ejemplo, un Avión para “saber volar” deberá implementar un interfaz
denominada Volador, que incluye los métodos despegar, aterrizar y volar.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 18 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Esta relación también se denomina realización.
3.5. Clases Estereotipadas
3.5.1. Que es un estereotipo de clase El estereotipo representa la construcción de un nuevo elemento de UML que
extiende a partir de uno ya existente, en el caso de las clases representa a una
categoría o un tipo nuevo de clases. Representa una funcionalidad determinada,
identificada por su nombre.
El Proceso Unificado de Desarrollo (presentado mas adelante) utiliza tres
estereotipos de clases que se han estandarizado en el mercado, estos son
Boundary, Control y Entity.
3.5.2. El estereotipo Boundary El estereotipo Boundary se utiliza para representar clases que se encuentran en
el limite (bound) del sistema. Estas clases representan a la interfaz de usuario
dentro de un sistema, generalmente implementadas como ventanas. Se utilizan
para capturar la interacción entre el usuario y el sistema a nivel de pantalla.
Estas clases dentro de una arquitectura multicapa generalmente pertenecen a la
Capa de Presentación (PL o Presentation Layer).
En el patrón de diseño M-V-C representa a la vista.
3.5.3. El estereotipo Control El estereotipo Control se utiliza para representar clases que se encargan de
controlar los procesos de negocios, son clases que llevan a cabo las reglas de
negocios, realizando la coordinación entre las clases del tipo Boundary y las
clases del tipo Entity. Se encargan de la organización y planificación de
actividades.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 19 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Estas clases dentro de una arquitectura multicapa generalmente pertenecen a la
Capa de Negocios (BL o Business Layer).
En el patrón de diseño M-V-C representa al controlador.
3.5.4. El estereotipo Entity El estereotipo Entity se utiliza para almacenar o persistir información propia del
sistema.
Estas clases dentro de una arquitectura multicapa generalmente pertenecen a la
Capa de Acceso a Datos (DAL o Data Access Layer).
En el patrón de diseño M-V-C representa al modelo.
3.5.5. Representación grafica
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 20 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
3.6. Aplicación
3.6.1. Modelo de Análisis o Modelo Conceptual Uno de los posibles usos del diagrama de clases es la construcción del
denominado Modelo Conceptual. El modelo conceptual es uno o varios diagramas
de clase construidos por un Analista Funcional que esta basado en la detección de
clases (junto con sus atributos y posibles métodos) y sus relaciones pero desde
un punto de vista funcional, es decir dentro de la de la etapa de Análisis.
No se definen características propias de un lenguaje de programación, sino que
se intenta reflejar la realidad. En algunos casos se categorizar las clases como
entity / controller / boundary, que son estereotipos de RUP (Racional Unified
Process) presentados mas adelante.
Adicionalmente, es posible utilizar una CRC Card (Class Responsability and
Collaboration) para detallar el nombre de la clase, descripción, atributos y
responsabilidades.
3.6.2. Modelo de Diseño El modelo de diseño es el conjunto de diagramas de clases (puede ser uno solo)
que se utiliza como base para realizar la codificación de la aplicación. El
encargado de construirlo es el Diseñador, y debe definir todo lo que sea necesario
para que el desarrollador pueda codificar sin problemas. Toma como uno de los
documentos de entrada el correspondiente al Modelo de Análisis, y se definen
nuevas clases (en general las detectadas en Análisis se mantienen) que tiene un
perfil netamente de diseño y resuelven cuestiones técnicas y ya no de negocios.
A partir del Modelo de Diseño se genera el código fuente de manera automática
que será tomado como base por los desarrolladores. De esta manera el
programador no toma decisiones ni de Análisis ni de Diseño, lo cual queda
restringido a programar en el código recibido.
El modelo tiende a evolucionar en la fase de construcción a través de feed-backs
que realizan los desarrolladores.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 21 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
3.6.3. Diseño de Base de Datos El modelo de datos o diseño de una base de datos también es posible realizarlo a
través de un diagrama de clases. En este caso las clases representan las tablas y
los atributos representan los campos.
Para esto es necesario utilizar estereotipos (ver Sección Conceptos Generales),
determinando el estereotipo <<table>> para las tablas, el estereotipo
<<column>> para los campos, y otros estereotipos posibles como <<PK>> para
las claves primarias y <<FK>> para las claves foráneas, entre otros.
3.7. Ejemplo
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 22 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
4. Diagrama de Objetos (Object Diagram) 4.1. Definición
El Diagrama de Objetos permite representar el sistema en un momento
determinado del tiempo, es similar a obtener una fotografía o snapshot del
sistema en un momento determinado, y visualizar los objetos junto con sus
relaciones.
Se suele utilizar como punto de partida para la construcción del Diagrama de
Comunicación o Colaboración.
4.2. Objetivo “..describir los objetos del dominio y sus relaciones..”
4.3. Elementos
4.3.1. Objeto El objeto representa una cosa en particular, es una instancia de una clase. Nace
de utilizar una clase como plantilla y llenar sus atributos con valores. Los objetos
dentro del diagrama dependen de algún tipo de clase, y pueden estar
estereotipados para una mejor comprensión.
Por convención, la primera letra debe estar en minúscula y la palabra subrayada.
Es común agregar luego del nombre del objeto el nombre de la clase a la cual
pertenece el objeto.
4.4. Relaciones
4.4.1. Vínculo Se utiliza para establecer algún tipo de relación entre los objetos, no denota un
tipo de relación en particular sino simplemente un vinculo que no tiene dirección.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 23 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
4.4.2. Vínculo Direccional Se utiliza de la misma forma que el vínculo, pero tiene como valor agregado que
permite entender mejor la relación, determinar la navegabilidad de la misma.
4.5. Aplicación
4.5.1. Fotografía del sistema Este diagrama es el menos utilizado de todos los diagramas ya que no representa
relevancia sobre ninguna vista posible del sistema. Su uso mas frecuente es la
posibilidad de visualizar el sistema en un determinado momento, estudiando que
objetos están instanciados y la relación entre los mismos.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 24 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
4.6. Ejemplo
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 25 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
5. Diagrama de Casos de Uso 5.1. Definición
El Diagrama de Casos de Uso representa las formas que tiene un usuario de
utilizar un sistema, y esta directamente asociado con el “que debe hacer” un
sistema, y no “como debe hacerlo”. Visualiza de forma directa los requisitos
funcionales de un sistema, es decir como el sistema debería funcionar, es por
esta razón que se utiliza para guiar el diseño y el desarrollo.
Todo el proceso de desarrollo de software (análisis, diseño, testing, etc) son
dirigidos por los casos de uso, donde un cambio en un caso de uso impacta en
gran parte del proceso de desarrollo.
Es importante aclarar que no permite modelar workflow ni visualizar como se
desarrollan las acciones detrás de los casos de uso.
Adicionalmente, es posible construir diagramas con diferentes niveles de detalle.
Requisito Funcional
Los requisitos funcionales determinan el funcionamiento del sistema, son
aquellos que especifican el “que” debe hacer el sistema, representa a las
reglas de negocio.
Por ejemplo, el sistema debe “administrar clientes”, “realizar cobros”, “emitir
facturas”, etc.
Requisito No Funcional
Los requisitos no funcionales son aquellos que no determinan la
funcionalidad del sistema, aunque pueden influir sobre la misma. Son
requisitos no funcionales la velocidad de respuesta, el rendimiento,
exactitud, el hardware a utilizar, etc.
Por ejemplo, en el caso de estar operando con un cajero automático, el caso
de uso “sacar dinero” puede tener asociado un requisito no funcional
velocidad de repuesta, donde especifique que el cliente no debe esperar mas
de 1 segundo para realizar la transacción.
5.2. Objetivo “..describir las acciones del sistema desde el punto de vista del usuario..”
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 26 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
5.3. Elementos
5.3.1. Actor El actor representa una entidad externa al sistema que utiliza el sistema.
Generalmente son usuarios, aunque también podría ser otro sistema.
Participa en un caso de uso (o más) con el propósito de cumplir su objetivo,
definiendo el rol que un usuario del sistema va a asumir cuando esté en
funcionamiento.
El conjunto de todos los actores representará todas las formas de comunicación
de una entidad externa con el sistema.
5.3.2. Caso de Uso (Use Case) El caso de uso es la interacción que existe entre un actor y el sistema, representa
un forma de utilizar el sistema. Es posible entenderla como una unidad de
funcionalidad expresada como una transacción entre un actor y el sistema.
Un caso de uso puede ser descrito en términos de casos de uso más simples,
pudiendo un caso de uso detallarse desde el punto de vista del usuario como un
Diagrama de Casos de Uso.
5.4. Relaciones
5.4.1. Asociación
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 27 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
La relación de Asociación es una línea de comunicación entre un actor y el caso
de uso de uso en el que participa.
5.4.2. Generalización La relación de Generalización representa a un elemento que es general, y a otro
elemento que tiene la base del elemento general, pero como valor agregado tiene
algunas particularidades.
Por ejemplo, el elemento2 toma como base al elemento1, con lo cual el
elemento2 tiene como mínimo lo que tiene el elemento 1, y aparte agrega otras
cosas. Se dice que el elemento1 es una generalización del elemento2, y el
elemento2 es una especialización del elemento1.
Esta relación puede darse tanto entre actores como entre casos de uso.
Aplicación entre Actores
Aplicación entre Casos de Uso
5.4.3. Especialización
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 28 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
La relación de Especialización es la relación inversa a la relación de
Generalización. Según el ejemplo anterior, “abrir cuenta” es una generalización
de “abrir cuenta corriente”, pero también “abrir cuenta corriente” es una
especialización de “abrir cuenta”.
Se maneja bajo el mismo criterio que la generalización, con lo cual también es
aplicable a actores.
5.4.4. Inclusión La relación de Inclusión representa que un caso de uso esta incluido en otro caso
de uso base, donde el caso de uso incluido es parte del caso de uso base.
Por ejemplo, el caso de uso “abrir cuenta” incluye a los casos de uso “registrar
datos” y “depositar fondos”, ya que al abrir un cuenta en un banco es necesario
registrarse y depositar fondos en la cuenta.
5.4.5. Extensión La relación de Extensión se utiliza entre dos casos de uso, cuando un caso de uso
incluye al otro pero opcionalmente.
Por ejemplo, el caso de uso “entregar pasaporte” es una extensión del caso de
uso “abrir cuenta”, ya que solo será solicitado entregar el pasaporte a aquellas
personas que sean extranjeros y quieran abrir una cuenta.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 29 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
5.5. Aplicación
5.5.1. Captura de Requisitos Funcionales La forma estándar de captura de requisitos funciones son los Diagrama de Casos
de Uso. Esto se debe a que es una forma sencilla, sistemático e intuitiva, fácil de
leer por cualquier persona que forma parte de un proyecto, incluyendo al cliente
mismo.
5.5.2. Modelo de Casos de Uso El modelo de casos de uso es el conjunto de todos los diagramas de casos de uso
que forman parte del sistema. En este artefacto quedan documentados todos los
requisitos funcionales que deberá satisfacer el sistema, y se utiliza como la
documentación que detalle la funcionalidad del sistema. El sistema no podrá
tener más ni menos funcionalidad que la especificada en este documento.
5.5.3. Establecimiento de contratos Dependiendo de la envergadura del sistema, los casos de uso sirven como una
forma de ponerse de acuerdo entre el cliente (es el que quiere/necesita un
sistema) y el proveedor (es el que construye el sistema).
Se suelen establecer contratos en base a los casos de uso, donde cliente y
proveedor se comprometen a que el sistema debe tener la funcionalidad
especificada en los casos de uso que forman parte del contrato. De esta manera
se evitan “malentendidos” acerca de las funcionalidades que están incluidas de
las que no están incluidas.
5.5.4. Construcción de Casos de Prueba (Test Cases) Los casos de prueba son necesarios en todo sistema para poder realizar el testing
de la aplicación, y así asegurar la calidad del producto desde el punto de vista
funcional, es decir asegurar que lo que tiene que hacer el sistema, lo esta
haciendo correctamente.
Los casos de uso se utilizan como punto de partida para los casos de prueba, ya
que los casos de prueba son los casos de uso con algunos agregados adicionales
como casos especiales a testear.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 30 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
5.6. Ejemplo
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 31 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
6. Diagrama de Estados 6.1. Definición
El Diagrama de Estados permite visualizar los cambios de comportamiento de un
objeto a partir de sus transiciones.
Se lo conoce también como Maquina de Estados.
6.2. Objetivo “...describir los estados por los cuales puede pasar un objeto durante su ciclo de
vida...”
6.3. Elementos
6.3.1. Estado (State) El estado corresponde generalmente a un objeto, y representa el conjunto de
valores que tiene ese objeto en un determinado momento. Describe un periodo
de tiempo durante el ciclo de vida del objeto.
El comportamiento interior de un estado es posible modelarlo con un Diagrama
de Actividad, que visualiza las acciones que ocurren cuando un objeto entra en
ese estado.
6.3.2. Estado compuesto (Sub-machine State) El estado compuesto es un estado que contiene sub-estados. Es posible modelar
los sub-estados dentro del estado compuesto, o en un diagrama de estados
aparte.
Si se modela el estado compuesto como una “caja negra” que esta desarrollada
en un diagrama aparte, su representación grafica es la siguiente:
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 32 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Si se modela el estado compuesto como un conjunto de sub-estados visibles, su
representación grafica es la siguiente:
6.3.3. Pseudo-Estado Inicial (Initial State) El pseudo estado inicial representa el comienzo de las transiciones de los posibles
estados.
6.3.4. Pseudo-Estado Final (Final State)
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 33 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
El pseudo estado final representa el final esperado de las transiciones de los
posibles estados.
6.3.5. Punto de Entrada (Entry Point) El punto de entrada es utilizado en estados compuestos, y representa el punto de
entrada al estado compuesto desde el exterior.
6.3.6. Punto de Salida (Exit Point) El punto de salida es utilizado en sub estados o estados compuestos, y
representa el punto de salida del sub estado o estado compuesto desde el
interior.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 34 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
6.3.7. Estado de Sincronización (Sync State) El estado de sincronización indica que los caminos concurrentes que pasen por
este estado serán sincronizados.
6.3.8. Estado Histórico (Shallow History State) El estado histórico se utiliza para representar el estado activo (o sub-estado) mas
reciente de un estado compuesto, aunque no tiene la capacidad para representar
el estado activo de un posible sub-estado (si existiera) del sub-estado del estado
compuesto.
6.3.9. Estado Histórico Profundo (Deep History State)
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 35 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
El estado histórico profundo se utiliza para representar el estado activo (o sub-
estado) mas reciente de un estado compuesto, y además tiene la capacidad para
representar el estado activo de un posible sub-estado (si existiera) del sub-
estado del estado compuesto, es decir que almacena el histórico de todos los
estados activos en forma recursiva.
6.3.10. Fork El fork es un pseudo estado que se utiliza para separar una transición de entrada
en dos transiciones concurrentes que tienen como destino diferentes estados.
6.3.11. Join El join es el proceso inverso al fork, es un pseudo estado que se utiliza para unir
dos transiciones de entrada concurrentes en una única transición de salida.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 36 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
6.3.12. Unión (Junction) La unión es un pseudo estado que se utiliza para unir múltiples caminos en otros
caminos que pueden ser compartidos, o también para separar un camino en
varios caminos alternativos. Se suelen agregar guardas a las transiciones para
especificar una condición para la transición, si el resultado de la condición es
negativo entonces no se produce esa transición.
6.3.13. Decisión (Choice) La decisión indica un condicional en el progreso: si la condición es verdadera
toma un camino, y si es falsa toma el camino alternativo.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 37 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
6.4. Relaciones
6.4.1. Transición La transición es una ocurrencia en el tiempo, sin una determinada duración.
Representa la forma de vincular estado, y es el medio en que un estado pasa a
otro estado.
En forma opcional, es posible especificar un evento disparador (trigger) que inicia
la transición de un estado a otro.
6.5. Aplicación
6.5.1. Seguimiento de un objeto El Diagrama de Estados se utiliza generalmente para hacer un seguimiento fino
de un objeto en particular, cuando el foco del negocio requiere hacer énfasis en
las transiciones de ese objeto. Adicionalmente, se utilizan para ayudar al
desarrollador a entender funcionalidades complejas o algún proceso de negocio
especializado en una área determinada.
Es importante destacar que un Diagrama de Estados no es un diagrama
mayormente utilizado, se utiliza únicamente para casos puntuales.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 38 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
6.6. Ejemplo Se modelo a continuación los estados posibles de un alumno de una universidad.
El estado compuesto “inscripto” desarrollado en otro diagrama queda de la
siguiente manera:
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 39 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
7. Diagrama de Actividades 7.1. Definición
El Diagrama de Actividad se utiliza principalmente para modelar flujo de trabajo o
workflow, visualizando las acciones de manera ordenada. Permite modelar
procesos y comprender la ejecución general de un sistema, localizándose en la
secuencia de acciones y condiciones necesarias para su ejecución.
7.2. Objetivo “...describir la acciones que ocurren dentro de un proceso...”
7.3. Elementos
7.3.1. Actividad (Activity) Una actividad refleja el control de flujo y de datos de un proceso, y puede incluir
la participación de sub-actividades y/o acciones. Generalmente representa a una
unidad funcional dentro de una actividad mayor o de un proceso.
7.3.2. Actividad Estructurada (Structured Activity) La actividad estructurada es una actividad que visualiza de manera explícita que
esta compuesto por un conjunto de actividades u acciones.
7.3.3. Acción (Action) La acción es la unidad funcional básica dentro de un diagrama de actividades, y
representa la transformación que ocurre dentro del sistema. La diferencia
principal con las actividades radica en que la acción no puede descomponerse,
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 40 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
mientras que una actividad puede descomponerse en sub-actividades y/o
acciones.
7.3.4. Objeto (Object) El objeto tiene el mismo significado que el presentado para los diagramas
anteriores, en este caso adicionalmente representa que un objeto es construido,
modificado o consultado luego de una actividad.
7.3.5. Datastore Object El datastore es un objeto que se utilice para modelar la persistencia de
información permanente. Se puede utilizar tanto para almacenar información
como para consultar información.
7.3.6. CentralBuffer Node El buffer tiene el mismo significado que el datastore, pero se utiliza para
almacenar información temporalmente (información no persistente o transitoria).
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 41 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
7.3.7. Pseudo-Estado Inicial (Initial State) El pseudo estado inicial representa el comienzo de los flujos entre las acciones.
7.3.8. Pseudo-Estado Final (Final State) El pseudo estado inicial representa el final de los flujos entre las acciones.
7.3.9. Señal de Envío (Send Signal) La señal de envío se utiliza para representar que se esta enviando un objeto en
forma de señal hacia algún destino no necesariamente representado en el
diagrama. En el siguiente ejemplo, la señal de envío se utiliza para notificar al
proveedor acerca de la creación de un pedido, donde es enviado el objeto
“pedido” al proveedor.
7.3.10. Señal de Recepción (Receive Signal) La señal de recepción se utiliza para representar la recepción y/o aceptación de
un pedido. Existen dos tipos de señales de recepción.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 42 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Accept Event Action
Esta señal se utiliza para determinar la recepción de un evento por parte de
terceros. Si se utiliza en conjunto con la señal de envío, establece que el
flujo continuara normalmente una vez que se produzca la señal de
respuesta.
Accept Time Event Action
Esta señal se utiliza para representar el pasaje del tiempo, es una acción que
espera la ocurrencia de un evento del tipo tiempo, por ejemplo comienzo de
un mes, finalización del mes, comienzo del día, etc.
7.3.11. Manejador de Excepciones (Exception Handler) El manejador de excepciones esta compuesto por una o mas acciones y se
encarga de tomar medias correctivas en caso de que se haya lanzado alguna
excepción (o se haya producido algún error).
7.3.12. Fork
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 43 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
El fork es un pseudo estado que se utiliza para separar un flujo de entrada en dos
flujos concurrentes que tienen como destino diferentes actividades y/o acciones.
7.3.13. Join El join es el proceso inverso al fork, es un pseudo estado que se utiliza para unir
dos flujos de entrada concurrentes en un único flujo de salida.
7.3.14. Decisión (Choice) La decisión indica un condicional en el progreso: si la condición es verdadera
toma un camino, y si es falsa toma el camino alternativo.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 44 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
7.3.15. Partición (Partition) La partición se utiliza para establecer responsabilidades en las acciones o
actividades. Determina que o quien realiza cada actividad. Son de uso opcional, y
permiten estructurar la vista o las partes de la actividad, realizando una
separación lógica. También son denominadas swimlanes.
7.4. Relaciones
7.4.1. Flujo de control (Control Flow) El flujo de control es un conector que une dos actividades o acciones, una inicial y
una final, determinado por una dirección. Una vez que la acción inicial es
completada, el control pasa a la acción siguiente.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 45 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Es posible definir una guarda que representa una condición que debe cumplir la
acción inicial para pasar a la próxima acción.
7.4.2. Flujo de objeto (Object Flow) El flujo de objeto conecta una actividad con un objeto, representando un flujo de
información de la actividad al objeto.
7.4.3. Flujo de objeto con Pines (Pinned Object Flow) El flujo de objeto con distinción es semánticamente igual al flujo de objeto
tradicional, la diferencia radica en la forma de graficarlo, ya que de esta manera
resulta mas compacto.
7.4.4. Flujo de Interrupción (Interrupt Flow) El flujo de interrupción representa una interrupción debido a una ocurrencia
inesperada en alguna acción o actividad.
7.5. Aplicación
7.5.1. Desarrollo de aplicaciones procedurales Uno de los posibles usos que tiene el Diagrama de Actividades es la posibilidad de
realizar el flujo de aplicaciones de tipo procedural, al estilo diagramas de jackson,
donde se pueden representar las sentencias (acciones) junto con las estructuras
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 46 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
de control de flujo utilizando las decisiones, forks, joins y actividades
estructuradas para representar llamadas a “cajas negras” o procedimientos.
7.5.2. Modelado de procesos de negocio - Workflow El uso mas común del Diagrama de Actividades es la representación de flujos de
trabajo o procesos de negocio. Es posible modelar como arranca un proceso, a
partir de quien o en que área se produce, y visualizar la transformación de
información que va ocurriendo durante todo el proceso.
En este contexto los eventos generalmente se originan dentro del sistema al
finalizar las diferentes acciones, o también fuera del sistema a través de señales
de recepción (por ejemplo, el proveedor entrego la mercadería) y a través de
eventos correspondientes al tiempo (por ejemplo, paso un mes).
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 47 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
7.6. Ejemplo
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 48 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
8. Diagrama de Comunicación (Communication Diagram) 8.1. Definición
El Diagrama de Colaboración modela los objetos junto con sus interacciones para
visualizar como se lleva a cabo una tarea, modelando únicamente la interacción
entre los objetos que realizan esa tarea en particular.
Se lo suele llamar también Diagrama de Comunicación. Es posible verlo como una
extensión del Diagrama de Objetos, ya que es muy parecido pero tiene como
valor agregado los mensajes que se envían entre los objetos.
Es uno del Diagrama de Interacción, y semánticamente es equivalente al
Diagrama de Secuencia
8.2. Objetivo “..Describir como colaboran o se comunican los distintos objetos entre sí para
conseguir un objetivo...”
8.3. Elementos
8.3.1. Actor El actor es una entidad externa al sistema que dispara el comienzo de la
interacción entre los objetos. La aparición de un actor dentro del diagrama es
opcional.
8.3.2. Objeto Es el mismo elemento que se utiliza en el Diagrama de Objetos.
8.3.3. Boundary
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 49 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso
representa a un objeto, instancia de una clase que esta estereotipada como
Boundary.
8.3.4. Control Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso
representa a un objeto, instancia de una clase que esta estereotipada como
Control.
8.3.5. Entity Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso
representa a un objeto, instancia de una clase que esta estereotipada como
Entity.
8.4. Relaciones
8.4.1. Vinculo Es la misma relación que se utiliza en el Diagrama de Objetos.
8.4.2. Vinculo Direccional Es la misma relación que se utiliza en el Diagrama de Objetos.
8.4.3. Mensaje El mensaje es una llamada que se realiza de un objeto origen a un objeto
destino, para entablar una “conversación”. Existen dos tipo de mensajes a enviar:
los mensajes sincrónicos y los mensajes asincrónicos.
Mensaje Sincrónico
El objeto origen envía un mensaje al objeto destino y espera a recibir una
respuesta. Una vez recibida la respuesta, sigue con su tarea.
El mensaje sincrónico se modela con una fecha de punta rellena.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 50 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Mensaje Asincrónico
El objeto origen envía un mensaje al objeto destino y no espera recibir
respuesta, sigue con su tarea.
El mensaje sincrónico se modela con una fecha de punta no rellena.
8.5. Aplicación
8.5.1. Realización de Casos de Uso en el Modelo de Análisis Es muy común utilizar los Diagramas de Comunicación para visualizar la
realización de un caso de uso.
Por ejemplo, el caso de uso “registrar usuario” representa una acción que realiza
un usuario en un sistema, y si es necesario documentar lo que ocurre detrás del
“registrar usuario”, se utiliza este diagrama para visualizar la interacción entre los
objetos para alcanzar el objetivo de la registración.
Generalmente se utilizan objetos de análisis, donde el objetivo es visualizar la
interacción de objetos a nivel negocio, no a nivel técnico o a nivel diseño.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 51 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
8.6. Ejemplo
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 52 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
9. Diagrama de Secuencia (Sequence Diagram) 9.1. Definición
El Diagrama de Secuencia se utiliza para representar la interacción de objetos a
lo largo del tiempo, por eso es semánticamente igual al diagrama de
Comunicación, aunque con algunas variantes desde el punto de vista sintáctico.
Esta basado en la utilización de un eje vertical imaginario que representa el paso
del tiempo.
A diferencia del Diagrama de Comunicación, pone mayor énfasis en la interacción
entre objetos a través del tiempo y no muestra la relación entre objetos que no
sea a través de mensajes.
9.2. Objetivo “...describir como colaboran los distintos objetos entre sí para conseguir un
objetivo a lo largo del tiempo...”
9.3. Elementos
9.3.1. Actor Es el mismo elemento que se utiliza en el Diagrama de Comunicación
9.3.2. Línea de vida (LifeLine) La línea de vida representa desde el nacimiento del objeto hasta su destrucción.
Este representada con una línea vertical punteada.
9.3.3. Boundary
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 53 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Es el mismo elemento que se utiliza en el Diagrama de Comunicación
9.3.4. Control Es el mismo elemento que se utiliza en el Diagrama de Comunicación
9.3.5. Entity Es el mismo elemento que se utiliza en el Diagrama de Comunicación
9.4. Relaciones
9.4.1. Mensaje Es la misma relación que se utiliza en el Diagrama de Comunicación. También se
utilizan los mensajes sincrónicos y los asincrónicos.
9.5. Aplicación
9.5.1. Realización de Casos de Uso en el Modelo de Diseño Es muy común utilizar los Diagramas de Secuencia para visualizar la realización
de un caso de uso.
Por ejemplo, el caso de uso “registrar usuario” representa una acción que realiza
un usuario en un sistema, y si es necesario documentar lo que ocurre detrás del
“registrar usuario”, se utiliza este diagrama para visualizar la interacción entre los
objetos para alcanzar el objetivo de la registración.
Generalmente se utilizan objetos de diseño, donde el objetivo es visualizar la
interacción de objetos a nivel técnico, con un mayor nivel de detalle, que luego
utilizará un desarrollador para implementar el sistema.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 54 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
9.6. Ejemplo
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 55 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
10. Diagrama de Componentes 10.1. Definición
El Diagrama de Componentes permite modelar las relaciones e interfaces que
existen entre distintos componentes que conformaran el sistema. Esta
directamente vinculado con el diseño, y se utiliza como base para el desarrollo de
la implementación del sistema.
10.2. Objetivo “...describir la relación que existe entre los distintos componentes del sistema...”
10.3. Elementos
10.3.1. Componente Un componente representa a una porción del software, es una parte lógica de un
sistema que envuelve una implementación. Un componente puede ser muy
pequeño, y pueden haber otros mas grandes que agrupen a los mas pequeños.
En su interior, generalmente contienen clases.
Puede estar representado como un archivo de código fuente, un archivo .dll en
Windows o un archivo .jar en Java.
Dentro del enfoque de UML, un componente puede tener en su interior Diagramas
de Comunicación, Secuencia, Actividades y Estados.
10.3.2. Interfaz La interfaz es una especificación de comportamiento, un protocolo de
comportamiento, que los implementadores que la utilizan están comprometidos a
respetar. Se puede entender como un contrato entre las partes.
Una interfaz, en su aspecto mas básico, contiene un conjunto de métodos sin
implementar.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 56 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Existen dos formas de representar una interfaz, una forma completa que expresa
los métodos que agrupa junto con su nombre, y una forma más sencilla que
representa a través de un icono la interfaz solo con su nombre.
10.4. Relaciones
10.4.1. Utilización (Use) La relación de utilización puede existir entre componentes, esta fundamentada en
un componente que utiliza a un segundo componente para llevar a cabo su
funcionalidad. La relación esta formada por:
• un proveedor (supplier) que proveerá servicios y/o información
• un cliente (client) que utilizará dichos servicios y/o información
Es necesario tener especial cuidado sobre los proveedores, ya que un cambio en
el proveedor podría afectar el normal funcionamiento del cliente.
10.4.2. Implementación (Implementation) La relación se puede visualizar de dos formas distintas, dependiendo de como se
representa la interfaz.
También se denomina a esta relación como Realización.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 57 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
10.5. Aplicación
10.5.1. Modelado de un Sistema El Diagrama de Componentes puede ser utilizado para modelar un sistema si se
utilizan los grandes componentes del sistema, llamados módulos. De esta manera
se puede construir un diagrama que visualice la relación existente entre los
módulos, por ejemplo la posible relación entre los módulos de compras, ventas,
administración de productos, stock, etc., y sus posibles interfaces, estableciendo
“proveedores” y “clientes” bien definidos, y definiendo una organización en
términos generales de un sistema.
10.5.2. Modelado de un Modulo El Diagrama de Componentes puede ser utilizado con un mayor nivel de detalle,
especificando posibles componentes que conforman un modulo. De esta manera
es posible modelar las porciones de software a utilizar dentro de una caja negra
(o modulo) y establecer desde el punto de vista diseño como conviene hacerlos
cooperar para lograr los objetivos del modulo.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 58 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
10.6. Ejemplo
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 59 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
11. Diagrama de Despliegue 11.1. Definición
El Diagrama de Despliegue representa la arquitectura desde el punto de vista
lógico, basándose en la organización del software, o desde una punto de vista
físico, representando directamente cada unidad de hardware.
11.2. Objetivo “...describir la arquitectura de un sistema...”
11.3. Elementos
11.3.1. Nodo (Node) El nodo es una unidad que representa a un recurso computacional, donde puede
ser desplegado un sistema. Puede tener memoria y capacidad de procesamiento,
y alberga uno o más componentes y/o código ejecutable.
Un nodo puede ser un servidor, una estación de trabajo, una impresora, etc.
11.3.2. Componente (Component) Conceptualmente igual al componente utilizado en el Diagrama de Componentes.
Los componentes residen dentro de un nodo, es decir que el nodo representa el
“medio ambiente” de un componente.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 60 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
11.3.3. Dispositivo (Device) El Dispositivo es un nodo estereotipado como <<device>> que representa una
unidad de hardware dentro de un sistema.
Un ejemplo puede ser el hardware de una servidor Web, una impresora, un
switch, etc.
11.3.4. Ambiente de Ejecución (Execution Environment) El Ambiente de Ejecución es un nodo estereotipado como <<execution
environment>> que representa una unidad de software que provee un Ambiente
de Ejecución para componentes.
Un ejemplo puede ser el software de un servidor Web.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 61 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
11.3.5. Especificación de Despliegue (Deployment Spec) La Especificación de Despliegue especifica los parámetros junto con los valores
necesarios para llevar a cabo un despliegue de uno o mas componentes dentro de
uno nodo.
11.4. Relaciones
11.4.1. Asociación La relación de asociación se realiza entre nodos, y representa que los nodos
asociados cooperan de alguna manera.
Las reglas utilizadas para las asociaciones son las mismas que las utilizadas para
el Diagrama de Clases, es decir asociación, agregación y composición.
11.4.2. Utilización (Use) La relación de utilización se realiza entre nodos para establecer que un nodo,
para llevar a cabo sus tareas, necesita utilizar otro nodo. Esta relación establece
una dependencia entre los nodos, y se maneja bajo los mismos principios que la
relación de utilización en el Diagrama de Componentes.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 62 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
11.4.3. Comunicación (Communication Path) La relación de comunicación se utiliza para establecer un camino real de
transmisión de datos entre dos nodos. Los cables de red o enlaces aéreos se
utilizan para representar esta relación.
11.5. Aplicación
11.5.1. Definición de la arquitectura de un sistema El Diagrama de Despliegue se puede utilizar para representar la arquitectura del
sistema, modelando las partes que intervienen. Se deben especificar los
servidores intervenientes en cada capa junto con los potenciales clientes,
representados en ambos casos por nodos que incluyen sus componentes de
software más representativos.
Adicionalmente, si tiene valor para el negocio es posible visualizar también
impresoras, switches, routers o cualquier otra unidad de hardware que tenga
incidencia sobre el sistema.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 63 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
11.6. Ejemplo
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 64 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
12. Conceptos Generales 12.1. Estereotipos
Un estereotipo es un nuevo elemento de UML que extiende a partir de uno
existente, quedando definido con una semántica extendida y un nuevo icono
grafico, aunque este ultimo es opcional.
En caso de no establecer un icono para el estereotipo, se visualiza de la forma
<<nombreEstereotipo>>.
Los estereotipos pueden utilizarse para cualquier elemento de UML, como ser
clases y/o relaciones. Las clases estereotipadas mas comunes son las clases del
tipo <<Boundary>>, <<Control>> y <<Entity>>, y entre las relaciones la mas
conocida es <<use>>.
12.2. Valor etiquetado (Tagged Values) El valor etiquetado se utiliza para guardar información adicional dentro un
elemento de UML. Está formado por una etiqueta (tag) y un valor (value), donde
por ejemplo, se puede guardar el nombre de la persona que construyó una clase
o la versión de la misma.
12.3. Ingeniería Directa La ingeniería directa es el proceso que permite generar código fuente en
cualquier lenguaje a partir de los distintos diagramas de UML. Por ejemplo, a
partir del diagrama de clases es posible generar el “esqueleto del sistema”, es
decir el código fuente formado por clases y métodos, pero vacíos.
El Enterprise Architect permite generar código en diversos lenguajes, entre
ellos Java, VB.Net, C#, C++, Perl, Delphi y PHP.
12.4. Ingeniería Inversa La ingeniería inversa es el proceso que permite generar diagramas a partir de
código fuente. Se utiliza generalmente para construir el diagrama de clases a
partir de las clases de código fuente de cualquier lenguaje.
El Enterprise Architect permite generar el diagrama de clases a partir del
código fuente de diversos lenguajes tales como Java, VB.Net, C#, C++, Perl,
Delphi y PHP
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 65 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
12.5. El Lenguaje XMI XMI significa XML Metadata Interchange, y es una forma de almacenar los
diagramas de UML en un formato de texto basado en XML. El objetivo de XMI es
permitir la portabilidad de un proyecto armado en UML desde cualquier tipo de
aplicación.
Por ejemplo, es posible utilizar el Enterprise Architect y guardar el proyecto en
formato .xml, para luego utilizar otra aplicación como Rational o PoseidonUML y
poder abrir el proyecto sin inconvenientes.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 66 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
13. Introducción al Proceso Unificado de Desarrollo de Software 13.1. Definición
El Proceso Unificado de Desarrollo, también conocido como UP, es una
metodología orientada a la construcción de software. Nace como la unión de
distintas metodologías antes separadas por distintos autores, concentrando lo
mejor de cada uno.
Es posible definirlo como un proceso que define quien está haciendo que, cuando
lo esta haciendo, y como alcanzar un objetivo. Es el proceso utilizado para guiar a
los desarrolladores.
Se la conoce inicialmente como RUP (Rational Unified Process), que es la
propuesta propietaria de la empresa Rational, y en su propuesta genérica se lo
denomina UP (Unified Process).
La diferencia radical con UML es que UML es un medio, y no un fin. UML tiene
como objetivo documentar, visualizar y modelar un sistema, y no define quien
realiza cada actividad, tampoco define tiempos ni coordinación entre los roles de
los distintos trabajadores del sistema. UML no es una metodología (como sí lo es
UP) sino que es un lenguaje.
13.2. Historia
13.2.1. El proceso Objectory La metodología RUP tiene una larga historia que nace en Objectory en el año
1987, fundada por Jacobson. Jacobson trabajaba en la empresa Ericsson y tenia
como principales tareas el análisis y diseño de sistemas de información, cuando
decide independizarse y fundar Objectory para dedicarse a la investigación de
una metodología que permita el desarrollo de sistemas, de manera organizada,
utilizando toda la experiencia obtenida en tareas similares en su anterior
empresa.
El proyecto se desarrolla hasta el año 1996 de forma independiente, presentando
una gran evolución y captando la atención de la compañía Rational, que luego
compraría a Objectory para comenzar a marcar el camino para lo que luego se
conocería como RUP.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 67 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Objectory representaba el concepto de Object Factory (o fábrica de objetos).
13.2.2. El proceso Objectory de Rational En el año 1996 Rational compra Objectory y comienza a unificar los principios
básicos de Objectory con los propios. Entre los aspectos más importantes, se
destacan los siguientes:
• Utilización de fases dentro de un proyecto
• Utilización de iteraciones controladas dentro de las fases
• Establecimiento de la arquitectura como la parte mas significativa de la
organización del sistema
• Incorporación de UML como lenguaje de modelado (estaba en fase de
desarrollo, versión 1.1)
Estos cambios fueron realizados entre los años 1996 y 1997.
13.2.3. El Proceso Unificado de Rational (RUP) En el año 1998 Rational decide expandirse en la búsqueda de una metodología
genérica, y comienza a comprar empresas que se encargaban de actividades
puntuales y estaban bien desarrolladas en esos campos, como ser gestión de
requisitos, gestión de configuración, testing, etc.
Rational absorben toda la experiencia y conocimientos, y finalmente construye la
metodología denominada RUP. Establecieron las siglas RUP basándose en las
siguientes ideas:
• R de Rational, correspondiente al nombre de la empresa
• U de Unified, que significa unificado ya que representa la unificación de
todas las diferentes técnicas de desarrollo y de todas las metodologías
utilizadas anteriormente
• P de Process, correspondiente al proceso que indica paso a paso las
tareas a realizar para cumplir un objetivo
13.3. La necesidad de una metodología
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 68 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
En todo desarrollo de software es necesaria una metodología para coordinar a los
trabajadores que forman parte del proyecto. Resulta necesario un proceso que:
• proporcione una guía para ordenar actividades de un equipo, dirigiendo
tareas para cada desarrollador por separado y del equipo como un todo, para
lograr que no se solapan tareas junto con el cumplimiento de objetivos en
fechas panificadas
• especifiquen los artefactos que deben desarrollarse, es decir los
documentos necesarios en cada fase a lo largo del desarrollo del software
• ofrezca criterios para el control de calidad
• ofrezca criterios en cuanto a la medición de productos y actividades del
proyecto en términos de tiempo y su evolución correspondiente
• maximice la productividad
13.4. Fundamentos del Proceso Unificado de Desarrollo El Proceso Unificado de Desarrollo es un proceso de desarrollo de software que
especifica las actividades necesarias para transformar los requisitos de un usuario
en un sistema de software. Proporciona un marco genérico de trabajo, y utiliza
como herramienta visual al UML.
Esta basado en tres aspectos claves:
• está dirigido por casos de uso
• está centrado en una arquitectura
• es iterativo e incremental
Los tres conceptos tienen la misma importancia. La arquitectura proporciona la
estructura para las iteraciones que se realizaran durante el proceso de desarrollo
para evolucionar y refinar el producto, y los casos de uso definirán los objetivos y
la dirección del trabajo en cada iteración.
13.4.1. Dirigido por Casos de Uso El Proceso Unificado de Desarrollo esta dirigido por el conjunto de casos de uso.
Un caso de uso es una funcionalidad bien definida del sistema que proporciona al
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 69 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
usuario un resultado. Representa a los requisitos funcionales (es decir, lo que
debería hacer el sistema).
El conjunto de casos de usos constituyen el Modelo de Casos de Uso, el cual
describe la funcionalidad integral del sistema. Se utilizan para guiar el diseño y la
implementación, y representan el punto de partida para la construcción de los
casos de prueba (test cases).
Se utiliza la palabra "dirigido" ya que los casos de uso sirven como hilo
conductor del desarrollo del software.
13.4.2. Centrado en una arquitectura El Proceso Unificado de Desarrollo esta centrado en una arquitectura ya que ésta
representa los cimientos del software a desarrollar, es donde el software sera
ejecutado. Una arquitectura comprende la definición de los siguientes conceptos:
• Arquitectura de hardware
• Sistema Operativo
• DataBase Management System (DBMS)
• Protocolos de comunicación de red
• Estrategia de diseño a seguir (multicapa, orientados a servicios, etc.)
Para su definición, el arquitecto de software debe comprender los casos de uso
claves del sistema. Esto se debe a que una arquitectura tiene una relación directa
con los casos de uso, ya que estos deben "encajar" en la arquitectura, es decir
que la arquitectura debe permitir el desarrollo normal de todos los casos de uso.
Para evaluar la viabilidad técnica de los casos de uso sobre una arquitectura,
generalmente se eligen entre el 5% al 10% del total, siendo estos casos de uso
los mas representativos del sistema o los que constituyen las funciones claves.
Para definir una arquitectura es conveniente, por una lado, esquematizarla según
los factores no dependientes de los casos de uso, y por el otro, trabajar con los
casos de uso del sistema, especificarlos y realizarlos en términos de subsistemas,
componentes y clases. A medida que los casos de uso se especifican y se van
refinando, la arquitectura ira "madurando".
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 70 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Una arquitectura debe satisfacer también a los requisitos no funcionales, como
ser rendimiento, performance y velocidad de respuesta.
El objetivo es encontrar una arquitectura estable y escalable, construyéndola de
tal manera que permita que el sistema de software evolucione.
13.4.3. Iterativo e incremental El Proceso Unificado de Desarrollo es iterativo e incremental ya que divide a un
proyecto en "mini-proyectos", también denominados iteraciones. El proyecto se
estructura en cuatro grandes fases (presentadas a continuación) donde en cada
fase se realizan una gran cantidad de iteraciones.
Cada iteración deberá planificarse y ejecutarse en forma controlada, basada en
casos de uso bien especificados para mitigar el riesgo y logrando así en cada
iteración un incremento real del sistema. Se intenta planificar todas las
iteraciones de la fase (o la mayor cantidad posible) y su correspondiente orden
lógico.
Una iteración comienza con la detección de los casos de uso (Requisitos), luego
Análisis, Diseño, Implementación y Pruebas, es decir que cada iteración convierte
un conjunto de casos de uso en código fuente.
Por cada iteración:
• se identifican y especifican los casos de uso mas relevantes
• se crea un diseño respetando la arquitectura
• se implementa el diseño con componentes
• se verifica que el resultado satisface los casos de uso
Teniendo en cuenta que las necesidades del usuario (los requisitos) no pueden
definirse completamente desde el comienzo, las distintas iteraciones sirven como
un refinamiento de requisitos.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 71 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
13.5. Ciclo de vida del Proceso Unificado El Proceso Unificado de Desarrollo establece la construcción de un sistema en
cuatro fases bien definidas:
• Inicio
• Elaboración
• Construcción
• Transición
Cada fase termina con un hito, donde se decide si se avanza a la fase siguiente.
En este punto se revén presupuestos, planificaciones y requisitos. Se suele reunir
el personal técnico con el de gestión para hacer una evaluación de la situación.
Los hitos se utilizan para estimar tiempos y recursos necesarios para la próxima
fase. Sirven también para controlar el progreso con las planificaciones
previamente realizadas. Si se encuentra alguna deficiencia, debe ser corregida
antes de pasar a la siguiente fase.
Cada fase esta formada por iteraciones, y cada iteración está compuesta por
flujos fundamentales de trabajo. Una iteración representa el conjunto de
actividades que tienen como objetivo realizar un avance real y “tangible” del
sistema. Para completar una iteración es necesario llevar a cabo todos los flujos
fundamentales de trabajo, presentados a continuación:
• Requerimientos
• Análisis y Diseño
• Implementación
• Testing
• Configuración
13.5.1. Fase de Inicio En la Fase de Inicio se genera una descripción del producto y se presenta el
análisis del negocio. Se definen las funciones principales del sistema para los
usuarios más representativos, el plan de proyecto y el costo del producto,
identificando los riesgos mas importantes. Se debe realizar en forma
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 72 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
aproximada una estimación del proyecto en cuanto a tiempos, costos y
recursos.
Se comienza a pensar en una posible arquitectura y se planifica en detalle la
Fase de Elaboración.
13.5.2. Fase Elaboración En la Fase de Elaboración se realiza una especificación detallada de la mayoría de
los casos de uso y se construye la arquitectura alineada con los casos de uso más
críticos.
Con la especificación de los casos de uso realizada se planifican las actividades y
se estiman los recursos necesarios hasta la terminación del proyecto.
13.5.3. Fase de Construcción En la fase de Construcción se utilizan la mayoría de los recursos. A esta altura la
arquitectura ya es estable, aunque puede incorporarse pequeñas mejoras. En
esta fase se construye el producto hasta convertirse en un sistema funcional.
Al finalizar esta fase, el sistema responderá por todos los casos de uso que han
pactado entre la empresa y el cliente. El sistema final podría contener defectos
(bugs) que se solucionarán en la próxima fase: la fase de Transición.
13.5.4. Fase de Transición En la fase de Transición el producto se convierte en versión beta, donde los
usuarios experimentados prueban el producto en busca de defectos. A medida
que se van detectando errores, los desarrolladores corrigen dichos defectos.
Esta fase incluye también la capacitación a usuarios y se redactan formalmente
los manuales.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 73 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14. LABORATORIOS 14.1. LABORATORIO #1 – Diagrama de Clases
14.1.1. Caso de Estudio La línea aérea AirBus, una de las empresas más grandes del mundo en materia
de transporte de pasajeros, se concentra principalmente en el manejo de aviones
comerciales. Estos aviones poseen una denominación y una capacidad que
determina la cantidad de pasajeros que puedan abordar el avión.
Los aviones comerciales son explotados a través de diferentes vuelos, que tienen
como principales características un destino, una duración y una fecha de salida.
Los vuelos están organizados en salidas periódicas e incluyen en su tripulación a
varias azafatas, un piloto, un co piloto y por supuesto, a los pasajeros que han
comprado su pasaje.
Sus aviones estacionan periódicamente en hangares de los diferentes
aeropuertos, aunque comparten el hangar con aviones privados que no forman
parte de la compañía.
14.1.2. Construcción del Diagrama Construir el Diagrama de Clases utilizando el Enterprise Architect para modelar la
estructura de la información presentada anteriomente. Para esto se solicita:
• Analizar, detectar e identificar las clases. Debatir con el docente acerca
de las clases a utilizar para seguir con los próximos pasos
• Identificar atributos y ubicarlos en las clases que corresponden
• Identificar clases abstractas
• Relacionar las clases que considere necesario con generalización
• Relacionar las clases que considere necesario utilizando asociación,
agregando navegabilidad y multiplicidad en sus extremos
• Relacionar las clases que considere necesario utilizando composición y
agregación
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 74 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14.2. LABORATORIO #02 – Diagrama de Objetos
14.2.1. Caso de Estudio La línea aérea AirBus ha comenzado con sus actividades el día 01/01/1990. Entre
su flota de aviones, se destaca el avión comercial denominado Airbus800, con
capacidad para 150 pasajeros. Este avión tiene asignados sus próximos vuelos,
que son los siguientes:
• Vuelo con destino a Buenos Aires, tiene fecha de salida el 20 de octubre
y una duración de 180 minutos
• Vuelo con destino a San Pablo, tiene fecha de salida el 21 de noviembre
y una duración de 220 minutos
• Vuelo con destino a Iguazu, tiene fecha de salida el 22 de diciembre y
una duración de 250 minutos
14.2.2. Construcción del Diagrama Construir el Diagrama de Objetos utilizando el Enterprise Architect para modelar
la estructura de la información presentada anteriormente. Para esto se solicita:
• Analizar, detectar e identificar los objetos. Debatir con el docente acerca
de los objetos a utilizar para seguir con los próximos pasos
• Relacionar los objetos con vínculos
• Establecer los valores de los atributos en los objetos
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 75 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14.3. LABORATORIO #03 – Diagrama de Casos de Uso
14.3.1. Caso de Estudio El aeropuerto de Ezeiza recibe gran cantidad de pasajeros por día, de los cuales
hay pasajeros nacionales como pasajeros extranjeros.
Una reducida cantidad de pasajeros decide adquirir su pasaje en el momento que
arriba al aeropuerto. Para esto se acerca al puesto de venta de la línea aérea y
selecciona su pasaje, estableciendo previamente el destino, la fecha de salida, el
horario de salida, la clase en que quiere viajar (Turista, Standard o Ejecutiva) y la
ubicación dentro del avión.
La persona encargada de la venta chequea disponibilidad y si existe disponibilidad
le solicita al pasajero presentar documentación personal como DNI y pasaporte.
En caso de ser extranjero le solicita también presentar la información de ingreso
al país.
Una vez presentada la documentación, el pasajero presenta los descuentos que
posee, que generalmente son descuento por millaje o descuento empresarial.
Para finalizar, el pasajero debe pagar el pasaje, que lo puede realizar en efectivo,
con tarjeta de crédito o tarjeta de debito. En caso de estas dos ultimas, deberá
firmar el comprobante de pago. Finalmente, el pasajero recibe su pasaje.
14.3.2. Construcción del Diagrama Construir el Diagrama de Casos de Uso utilizando el Enterprise Architect para
modelar las interacciones que tiene el pasajero con el puesto de venta, de la
información presentada anteriormente.
Para esto se solicita:
• Identificar actores
• De ser posible, identificar relaciones de generalización entre actores
• Identificar casos de uso
• Relacionar los casos de uso con los actores correspondientes mediante
asociación
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 76 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
• Relacionar los casos de uso entre ellos con las relaciones de inclusión y
generalización
• De ser posible, identificar relaciones de extensión entre casos de uso
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 77 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14.4. LABORATORIO #04 – Diagrama de Estados
14.4.1. Caso de Estudio La línea aérea lleva un control interno muy estricto de los pasajes de cada vuelo.
Para esto los categoriza en validos e inválidos.
Dentro de la categoría validos, reúne los pasajes que son validos para ser
utilizados. En primera instancia son presentados dentro del sistema de
administración de pasajes como disponibles, que representan a los pasajes que
están puestos a la venta. Los pasajes disponibles pueden ser reservados en
forma telefónica o por internet, y en el 95% de los casos luego son vendidos. El
5% es cancelado previo a la fecha de partida, motivo por el cual son puestos
nuevamente a la venta.
Ocurre en ciertas ocasiones que un pasaje que ha sido vendido es devuelto por el
pasajero que lo compro, en este caso se le devuelve al pasajero un 85% de su
valor y se pone en venta nuevamente.
Dentro de la categoría inválidos, se contemplan los pasajes que fueron
vendidos y que la fecha de partida del vuelo ya paso, ya que se intenta
monitorear cuantos pasajeros que compraron el pasaje no tomaron el vuelo. Para
esto define el pasaje como utilizado (el pasajero tomo el vuelo) y como caducado
(en pasajero no tomo el vuelo).
14.4.2. Construcción del Diagrama Construir el Diagrama de Estados utilizando el Enterprise Architect para modelar
los estados por los cuales puede pasar un pasaje de un vuelo, según la
información presentada anteriormente.
Para esto se solicita:
• Identificar estados
• Armar una diagrama de primer nivel con los estados mas generales
• Vincular los estados mas generales con diagramas de estados que
contendrán los sub estados
• Armar los diagramas de estados dependientes de los estados principales
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 78 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14.5. LABORATORIO #05 – Diagrama de Actividades
14.5.1. Caso de Estudio La línea aérea posee un sistema de venta de pasajes que utiliza en sus puestos
de venta.
Para poder comenzar con el proceso de venta, es necesario seleccionar el vuelo y
chequear su disponibilidad. En caso de no haber lugar se informa que el vuelo
esta completo y se ofrecen al pasajero vuelos alternativos para que éste pueda
volver a seleccionar un vuelo.
Si hay disponibilidad en el vuelo se le solicita al pasajero el DNI y el pasaporte, y
se chequea si es extranjero. En caso de serlo, se le pide adicionalmente la
información declarada al ingresar al país.
Luego se solicitan los descuentos que, en caso de tenerlos, se realiza el cálculo
del precio final del pasaje incluyendo los descuentos.
Una vez terminados todos estos pasos se realiza la venta del pasaje - la cual
deberá actualizar la disponibilidad en el vuelo y registrar la facturación – y se
entrega el pasaje al pasajero.
14.5.2. Construcción del Diagrama Construir el Diagrama de Actividades utilizando el Enterprise Architect para
modelar las actividades del proceso de venta de un pasaje, según la información
presentada anteriormente.
Para esto se solicita:
• Detectar actividades
• Detectar datastores
• Armar el diagrama correspondiente
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 79 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14.6. LABORATORIO #06 – Diagrama de Secuencia
14.6.1. Caso de Estudio La línea aérea posee un sistema de venta de pasajes que utiliza en sus puestos
de venta.
Dicho sistema, entre las diferentes ventanas que posee, se encuentra la
correspondiente a la de venta de pasajes, la cual esta confeccionada de la
siguiente manera:
Es necesario identificar como se realiza la venta del pasaje desde un punto de
vista interno al sistema, teniendo en cuenta ciertas reglas de negocio:
Si el millaje es > 0, el pasajero obtendrá un descuento
Si la clase es ejecutiva, el pasajero obtendrá un descuento
Si la cantidad de pasajes a vender es mayor a 2, el pasajero obtendrá un
descuento
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 80 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
Hay que tener en cuenta que al vender los pasajes se deberá chequear la
disponibilidad de pasajes en el vuelo, y si se realiza posteriormente la venta
habrá que actualizar la disponibilidad.
Es necesario también registrar las ventas como parte de la facturación.
14.6.2. Construcción del Diagrama Construir el Diagrama de Secuencia utilizando el Enterprise Architect para
modelar la interacción entre objetos para llevar a cabo la venta de un pasaje,
según la información presentada anteriormente.
Para esto se solicita:
• Analizar, detectar e identificar los objetos. Debatir con el docente acerca
de los objetos a utilizar para seguir con los próximos pasos
• Armar en un diagrama de clases las clases necesarias las cuales se
utilizaran para crear los objetos identificados
• Agregar los métodos necesarios a las clases para utilizarlos en el
diagrama de secuencia
• Construir el diagrama de secuencia que visualice la interacción que
realizan los objetos para llevar a cabo una venta de un pasaje
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 81 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14.7. LABORATORIO #07 – Diagrama de Comunicación
14.7.1. Caso de Estudio El caso de estudio es el mismo que el realizado para el diagrama de Secuencia.
La ventana utilizada es la siguiente:
La diferencia radica en que se desarrollara un escenario que tiene las siguientes
características:
El millaje es 0 (es decir que no tiene millaje)
La clase es ejecutiva, con lo cual el pasajero obtendrá un descuento
La cantidad de pasajes a vender es dos
Se asume que al consultar si hay pasajes disponibles (a través del
método consultarDisponibilidad() ) la respuesta será verdadera
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 82 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
14.7.2. Construcción del Diagrama Construir el Diagrama de Comunicación utilizando el Enterprise Architect para
modelar la interacción entre objetos para llevar a cabo la venta de un pasaje,
según la información presentada anteriormente.
Para esto se solicita:
• Armar el diagrama de colaboración basándose en el diagrama se
secuencia previamente realizado
Reutilizar los objetos ya construidos en el diagrama anterior
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 83 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
MAPA DE LA CARRERA
La carrera es un conjunto de cursos. Cada uno de estos cursos tiene diferentes alternativas de fechas para cursar, las mismas estan publicadas en el calendario del instituto. El siguiente mapa expresa las correlatividades entre los distintos cursos. Importante: Estos cursos pueden ser asistidos en forma individual sin necesidad de realizar toda la carrera completa.
Análisis y Diseño Orientado a Objetos con UML y UP
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Página 84 Lavalle 648 – 4to Piso – Capital Federal Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados
CURSOS RELACIONADOS
Java Standard Programming para Principiantes J2SE :: Curso de programación básico que provee las primeras herramientas de programación en la tecnología mas utilizada actualmente.