2. introducciÓn a los diagramas de umlhernanolivieri.com/material/uml/manualalumno.pdf · 13.2.3....

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



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.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.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



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.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.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



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



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



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.



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.



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.



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.



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.



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.


• Diagrama de Actividades

• Diagramas de Interacción (es una subcategoría, que incluye a los

Diagramas de Secuencia y Comunicación)

• Diagrama de Estado



2.3.3. Diagramas Estructurales Los Diagramas Estructurales son aquellos que reflejan relaciones estáticas de

una estructura.


• 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.


• Diagrama de Casos de Uso

• Diagrama de Comunicación

• Diagrama de Secuencia

• Diagrama de Actividades

• Diagrama de Estados



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



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.



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.



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.



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.



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.




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.


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



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.



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



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.



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.



4.6. Ejemplo



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..”



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



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



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.



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.



5.6. Ejemplo



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:



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)



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.



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)



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.



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.



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.



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:



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,



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).



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.



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



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.



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.



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



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).



7.6. Ejemplo



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



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


Control.

8.3.5. Entity Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso


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.



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.



8.6. Ejemplo



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



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.



9.6. Ejemplo



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.



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.



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.



10.6. Ejemplo



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.



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.



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.



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.



11.6. Ejemplo



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



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.



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.



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



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



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".



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.



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



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.



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



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



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



• 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



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.


• 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



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.


• Detectar actividades

• Detectar datastores

• Armar el diagrama correspondiente



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



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.


• 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



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



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.


• Armar el diagrama de colaboración basándose en el diagrama se

secuencia previamente realizado

Reutilizar los objetos ya construidos en el diagrama anterior



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.



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.

2. introducciÓn a los diagramas de umlhernanolivieri.com/material/uml/manualalumno.pdf · 13.2.3....

Documents