You are on page 1of 84

A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP

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. L 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
w w w . e d u o a c io n lT . o o m . a r I Tel. (54) (011) 4328-0457 Lavalie 648 - 4to Piso - Capital Federal
Copyright 2005-A ctualldad, educaclonIT. Todos los derechos están reservados

Página 1

A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP

4.4.2. Vínculo Direccional........................................................................................................................... 23 4.5. Aplicación................................................................................................................................................23 4.5.1. Fotografía del sistema....................................................................................................................... 23 4.6. Ejemplo .....................................................................................................................................................24 5. DIAGRAMA DE CASOS DE USO_______________________________________________________ 25 5.1. Definición................................................................................................................................................. 25 5.2. Objetivo ....................................................................................................................................................25 5.3. Elementos................................................................................................................................................26 5.3.1. Actor................................................................................................................................................... 26 5.3.2. Caso de Uso (Use Case).................................................................................................................... 26 5.4. Relaciones...............................................................................................................................................26 5.4.1. Asociación.......................................................................................................................................... 26 5.4.2. Generalización................................................................................................................................... 27 5.4.3. Especialización.................................................................................................................................. 27 5.4.4. Inclusión............................................................................................................................................. 28 5.4.5. Extensión............................................................................................................................................ 28 5.5. Aplicación................................................................................................................................................29 5.5.1. Captura de Requisitos Funcionales................................................................................................... 29 5.5.2. Modelo de Casos de Uso................................................................................................................... 29 5.5.3. Establecimiento de contratos............................................................................................................. 29 5.5.4. Construcción de Casos de Prueba (Test Cases)............................................................................... 29 5.6. Ejemplo ..................................................................................................................................................... 30 6. DIAGRAMA DE ESTADOS.............__ ___ ___ ___ ___ ___ ___ ___ _____________________ ............31 6.1. Definición.................................................................................................................................................31 6.2. Objetivo ....................................................................................................................................................31 6.3. Elementos................................................................................................................................................31 6.3.1. Estado (State)..................................................................................................................................... 31 6.3.2. Estado compuesto (Sub-machine State)............................................................................................ 31 6.3.3. Pseudo-Estado Inicial (Initial State)................................................................................................. 32 6.3.4. Pseudo-Estado Final (Final State).................................................................................................... 32 6.3.5. Punto de Entrada (Entry Point)......................................................................................................... 33 6.3.6. Punto de Salida (Exit Point).............................................................................................................. 33 6.3.7. Estado de Sincronización (Sync State).............................................................................................. 34 6.3.8. Estado Histórico (Shallow History State)......................................................................................... 34 6.3.9. Estado Histórico Profundo (Deep History State)............................................................................. 34 6.3.10. Fork.................................................................................................................................................. 35 6.3.11. Join................................................................................................................................................... 35 6.3.12. Unión (Junction).............................................................................................................................. 36 6.3.13. Decisión (Choice)............................................................................................................................ 36 6.4. Relaciones...............................................................................................................................................37 6.4.1. Transición.......................................................................................................................................... 37 6.5. Aplicación................................................................................................................................................37 6.5.1. Seguimiento de un objeto................................................................................................................... 37 6.6. Ejemplo ..................................................................................................................................................... 38 7. DIAGRAMA DE ACTIVIDADES________________________________________________________ 39 7.1. Definición................................................................................................................................................. 39 7.2. Objetivo....................................................................................................................................................39 7.3. Elementos................................................................................................................................................39 7.3.1. Actividad (Activity)............................................................................................................................ 39 7.3.2. Actividad Estructurada (Structured Activity)....................................................................................39 7.3.3. Acción (Action).................................................................................................................................. 39 7.3.4. Objeto (Object).................................................................................................................................. 40 7.3.5. Datastore Object................................................................................................................................ 40
w w w . e d u c a c io n lT . c o m . a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Copyright 2005-A ctualldad, educaclonlT. Todos los derechos están reservados

Página 2

A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP

7.3.6. CentralBujfer Node............................................................................................................................ 40 7.3.7. Pseudo-Estado Inicial (Initial State) ................................................................................................. 41 7.3.8. Pseudo-Estado Final (Final State).................................................................................................... 41 7.3.9. Señal de Envío (Send Signal)............................................................................................................. 41 7.3.10. Señal de Recepción (Receive Signal) .............................................................................................. 41 7.3.11. Manejador de Excepciones (Exception Handler)...........................................................................42 7.3.12. Fork.................................................................................................................................................. 42 7.3.13. Join................................................................................................................................................... 43 7.3.14. Decisión (Choice)............................................................................................................................ 43 7.3.15. Partición (Partition)........................................................................................................................ 44 7.4. Relaciones...............................................................................................................................................44 7.4.1. Flujo de control (Control Flow)........................................................................................................ 44 7.4.2. Flujo de objeto (Object Flow)........................................................................................................... 45 7.4.3. Flujo de objeto con Pines (Pinned Object Flow).............................................................................. 45 7.4.4. Flujo de Interrupción (Interrupt Flow)............................................................................................. 45 7.5. Aplicación................................................................................................................................................45 7.5.1. Desarrollo de aplicaciones procedurales......................................................................................... 45 7.5.2. Modelado de procesos de negocio - Workflow................................................................................. 46 7.6. Ejemplo ..................................................................................................................................................... 47 8. DIAGRAMA DE COMUNICACIÓN (COMMUNICATION DIAGRAM)______________________48 8.1. Definición.................................................................................................................................................48 8.2. Objetivo ....................................................................................................................................................48 8.3. Elementos................................................................................................................................................48 8.3.1. Actor................................................................................................................................................... 48 8.3.2. Objeto................................................................................................................................................. 48 8.3.3. Boundary............................................................................................................................................ 48 8.3.4. Control............................................................................................................................................... 49 8.3.5. Entity.................................................................................................................................................. 49 8.4. Relaciones...............................................................................................................................................49 8.4.1. Vinculo............................................................................................................................................... 49 8.4.2. Vinculo Direccional........................................................................................................................... 49 8.4.3. Mensaje.............................................................................................................................................. 49 8.5. Aplicación................................................................................................................................................50 8.5.1. Realización de Casos de Uso en el Modelo de Análisis...................................................................50 8.6. Ejemplo ..................................................................................................................................................... 51 9. DIAGRAMA DE SECUENCIA (SEQUENCE DIAGRAM)...__ ___ ___ ___ ___ ___ ___ ................... 52 9.1. Definición................................................................................................................................................. 52 9.2. Objetivo ....................................................................................................................................................52 9.3. Elementos................................................................................................................................................52 9.3.1. Actor................................................................................................................................................... 52 9.3.2. Línea de vida (LifeLine).....................................................................................................................52 9.3.3. Boundary............................................................................................................................................ 52 9.3.4. Control............................................................................................................................................... 53 9.3.5. Entity.................................................................................................................................................. 53 9.4. Relaciones...............................................................................................................................................53 9.4.1. Mensaje.............................................................................................................................................. 53 9.5. Aplicación................................................................................................................................................53 9.5.1. Realización de Casos de Uso en el Modelo de Diseño.................................................................... 55 9.6. Ejemplo..................................................................................................................................................... 54 10. DIAGRAMA DE COMPONENTES_____________________________________________________ 55 10.1. Definición...............................................................................................................................................55 10.2. Objetivo ..................................................................................................................................................55 10.3. Elementos..............................................................................................................................................55
w w w . e d u c a c io n lT . c o m . a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Copyright 2005-A ctualldad, educaclonlT. Todos los derechos están reservados

Página 3

A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP

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 Valúes) .................................................................................................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 P roceso 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
w w w . e d u c a c io n lT . c o m . a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Copyright 2005-A ctualldad, educaclonlT. Todos los derechos están reservados

Página 4

....................... Caso de Estudio................1............................................................................ a r I Tel............................3................................................................ 74 14....... LABORATORIO #03 ...2.......................................... 78 14.................... LABORATORIO #04 ......1.........81 14.................... educaclonlT..............2. Todos los derechos están reservados Página 5 ...........Diagrama Comunicación.. 81 14..2............. Construcción del Diagrama..... Caso de Estudio...........LABORATORIO #05 ... 74 14...... Construcción del Diagrama.................3....4...............3.....LABORATORIO #06 ........ 75 14.................75 14.............................1......................................... 77 14......................78 14......................................... Construcción del Diagrama..... Caso de Estudio........... Construcción del Diagrama..............Diagrama de Estados.............1...........77 14.............1. 82 de de de w w w .................4to Piso ........ (54) (011) 4328-0457 Lavalle 648 .............4........2.5.......... LABORATORIO #07 .................................6..................1...............2..................................................... Construcción del Diagrama........6................... Caso de Estudio.................. c o m .. Caso de Estudio........... 75 14.................... e d u c a c io n lT ..........Capital Federal Copyright 2005-A ctualldad...........................................5.......................7...... Construcción del Diagrama..................................................................2................................. 80 14...............2........Diagrama de Secuencia......... Caso de Estudio........................................Diagrama de Actividades......................................................A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 14.....4..............................6........... 77 14................. 79 14.........5........Diagrama Casos Uso.........79 14....7.........7...... 78 14.....................2.....

c o m . w w w . Introducción a UML 1. con el objetivo final de pasar del modelo a producto real. educaclonlT. a r I Tel. es una simplificación de la realidad. visualizar y documentar sistemas. cada diagrama tiene un objetivo bien definido. y esta basa en tres principios fundam entales: « Es un L e n g u a je : está form ado por elementos y reglas bien definidas. que poseen su propia sintaxis y semántica « Esta U n ific a d o : unifica los distintos criterios utilizados antes de su creación.1. e d u c a c io n lT .Capital Federal Copyright 2005-A ctualldad. Académicamente. UML no es una m e to d o lo g ía que presenta los pasos a seguir para realizar un desarrollo. Es posible decir que antes de construir un edificio se realizan maquetas a escala que representa modelos a seguir. UML esta estrechamente ligado con el paradigma de objetos. es decir que tom a las mejores propuestas de herram ientas previas para presentar una propuesta sumamente abarcativa e integradora « P e rm ite M o d e la r: está basado en la construcción de modelos que perm ite representar abstracciones de la realidad. así como también cuando se construye un auto se confeccionan distintos planos o modelos a escala para intentar simular o prever su com portam iento. Esta compuesto por distintos diagramas que permiten ir representando las distintas vistas de un sistema. 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.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 1. lo que permite construir sistemas de información de una form a mucho mas intuitiva.4to Piso . 1. (54) (011) 4328-0457 Lavalle 648 . Qué es UML UML es un lenguaje gráfico que perm ite modelar. UML significa U n ifie d M o d e lin g L a n g u a g e o Lenguaje Unificado de Modelado. Todos los derechos están reservados Página 6 . sino que es un lenguaje gráfico de modelado. integrada y sencilla con el proceso de desarrollo.2. es posible definirla como una abstracción de la realidad.

hasta algo mucho mas especifico que representa un gran compromiso con el producto a construir.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP Los modelos pueden ser expresados en distintos niveles de precisión. La prim er versión de UML. es utilizado desde la gestación hasta la instalación y el testing. En proyectos de software. sencilla y abarcativa.Capital Federal Copyright 2005-A ctualldad. Así es como las grandes empresas de tecnologías de información .3. c o m . 1. Booch es el fundador de Rational Software Corp. aunque puede utilizarse en proyectos que no son de tecnología de la información. e d u c a c io n lT . En el año 1998 UML se establece como Standard de tacto en la industria del Software.4to Piso . se utiliza tanto para sistemas monolíticos como para sistemas distribuidos. 1. como ser el modelado de un m otor o de una turbina. sale a la luz en el año 1997. Como nace UML La historia cuenta que UML da sus prim eros pasos con al unión de los “tres amigos” : Booch. Donde se utiliza UML se utiliza dentro del marco de IT. A partir de los años 90 comienzan a intercam biar ideas para intentar unificar criterios. En los años 80 cada uno utilizaba un lenguaje propietario aunque como denom inador común tenían como objetivo el desarrollo de sistemas. educaclonlT. w w w . En el campo de IT. con previa modelizacion. corrección e integración ente diagramas. la 1. donde representa el correcto enlace de los roles para lograr el éxito de la constricción del sistema.0.entre ellas Rational . Si bien para utilizar UML es posible realizar los distintos diagramas con papel y lápiz. Todos los derechos están reservados Página 7 . desde algo muy genérico presentando una visión. abarca desde proyectos pequeños hasta grandes proyectos. a r I Tel.4. y recluta en el año 1995 a Rumbaugh y Jacobson para comenzar a determ inar una especificación genérica. Permite realizar la integración del software. es conveniente contar con alguna herram ienta del tipo IDE que facilite su construcción.deciden forman un consorcio para la construcción de un Lenguaje Unificado de Modelado: UML. (54) (011) 4328-0457 Lavalle 648 . Rumbaugh y Jacobson. y a partir de 1998 un organización llamada OMG (Object Management Group) se encargo de generar nuevas revisiones.

Diagrama de Casos de Uso El Diagrama de Casos de Uso tiene como objetivo d e s c r ib ir las a c c io n e s d e l s is te m a d esd e el p u n t o de vis ta d e l u s u a rio . Esta compuesto por objetos y relaciones de enlace. que intentan representar / modelar distintas vistas de un sistema. casos de uso y distintos tipos de relaciones. modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto. (54) (011) 4328-0457 Lavalle 648 . relaciones entre clases y opcionalm ente los paquetes que agrupan a las clases. e d u c a c io n lT .1.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 2. Permite modelar la estructura del sistema desde un punto de vista estático. 2. 2. Esta compuesto por actores (agentes externos al sistemas. Representa las form as que tiene un usuario de utilizar un sistema.3. Permite representar al sistema en un mom ento determ inado del tiempo.Capital Federal Copyright 2005-A ctualldad. Diagrama de Objetos El Diagrama de Objetos tiene como objetivo d e s c r ib ir los o b je t o s d e l d o m in io y sus re la c io n e s . Todos los derechos están reservados Página 8 . Es posible construir diagramas con diferentes niveles de detalle. También es posible pensarlo como una instancia de un Diagrama de Clases. es proporcional a obtener una fotografía o snapshot del sistema en un mom ento determ inado. educaclonlT. y se puede utilizar como un “ contrato" entre cliente y proveedor de software para determ inar la funcionalidad del sistema.2. w w w . Introducción UML esta organizado en una serie de diagramas que tienen objetivos bien definidos.2.2. c o m . 2. con una sintaxis y semántica determ inada. a r I Tel.2.2. Esta compuesto por clases.1. es decir los requisitos funcionales. pueden ser usuarios u otros sistemas). Los Diagrama de UML 2.4to Piso . Diagrama de Clases El Diagrama de Clases tiene como objetivo d e s c r ib ir las clases d e l d o m in io y sus r e la c io n e s . Introducción a los diagramas de UML 2.

Capital Federal Copyright 2005-A ctualldad. ya que es muy parecido pero tiene como valor agregado los mensajes que se envían entre los objetos.2. Permite modelar tanto estas simples como compuestos y concurrentes. Es semánticamente equivalente al Diagrama de Comunicación. Diagrama de Actividades El Diagrama de Actividades tiene como objetivo d e s c r ib ir las a c cio ne s que o c u rre n d e n tro de un p ro c e s o . Esta compuesto por objetos y relaciones del tipo llamadas.4.2. con lo cual visualiza las acciones de manera ordenada. Diagrama de Estados El Diagrama de Estados tiene como objetivo d e s c r ib ir los e sta d o s p o r los c u ales p u e d e p a s a r un o b je t o d u r a n t e su ciclo de vida. Es semánticamente equivalente al Diagrama de Secuencia. representando que objeto se comunica con que otro. Es posible verlo como una extensión del Diagrama de Objetos. Diagrama de Secuencia El Diagrama de Secuencia tiene como objetivo d e s c r ib ir co m o c o la b o ra n los d is t in t o s o b je t o s e n tr e s í p a r a c o n s e g u ir un o b je t iv o a lo la rg o del tie m p o . 2.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 2. 2. representando que objeto se comunica con que otro. Esta compuesto por acciones simples y concurrentes. pero tiene la particularidad de estar obligatoriam ente ordenado en el tiem po. Diagrama de Comunicación El Diagrama de Comunicación tiene como objetivo d e s c r ib ir com o c o la b o ra n o se c o m u n ic a n los d is t in to s o b je t o s e n tr e s í p a r a c o n s e g u ir un o b je t iv o . a r I Tel.6. y transiciones entre las acciones.2. Se utiliza principalm ente para modelar flujo de trabajo o workflow. Todos los derechos están reservados Página 9 . Esta compuesto por estados. relaciones de enlace y relaciones del tipo llamadas. Se lo suele llamar tam bién Diagrama de Colaboración. Esta directam ente relacionado con el Diagrama de Comunicación ya que el objetivo es el mismo. w w w .4to Piso . 2. c o m . Esta compuesto por objetos. e d u c a c io n lT . (54) (011) 4328-0457 Lavalle 648 .7.5.2. pseudo-estados y transiciones entre estados. educaclonlT.

Todos los derechos están reservados Página 1 0 . educaclonlT. 2. e d u c a c io n lT .2. Diagrama de Componentes El Diagrama de Componentes tiene como objetivo d e s c r ib ir la re la c ió n q ue e x is te e n tr e los d is t in t o s c o m p o n e n te s d e l s is te m a . c o m . Diagrama de Despliegue El Diagrama de Despliegue tiene como objetivo d e s c r ib ir la a r q u i t e c t u r a de un s is te m a .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 2.Capital Federal Copyright 2005-A ctualldad. (54) (011) 4328-0457 Lavalle 648 . a r I Tel. Esta compuesto por nodos. interfaces y sus relaciones. perm itiendo modelar las relaciones e interfaces que existen entre los componentes. Es posible representar la arquitectura desde el punto de vista lógico. basándose en la organización del software. Está orientado a la implementación del sistema. representando directam ente cada unidad de hardware. o desde una punto de vista físico. Esta compuesto por componentes.2. Esta directam ente vinculado con el diseño del sistema.9.8. componentes y sus relaciones.4to Piso . w w w .

(54) (011) 4328-0457 Lavalle 648 . Existen dos posibles categorías. e d u c a c io n lT . Generalmente representan a estructuras o a posibles acciones pero sin una relación directa con el tiempo.2.1. Diagramas Estáticos Los D ia g ra m a s E s tá tic o s son aquellos que no tienen ninguna relación con el tiem po.4to Piso . los diagramas estáticos y los diagramas dinámicos. Todos los derechos están reservados Página 11 . y así sucesivamente. educaclonlT. Estos diagramas son: • • Diagrama de Actividades Diagramas de Interacción (es una subcategoría. c o m .3.3. es decir prim ero una acción.3. Diagramas Dinámicos Los D iag ra m as D in á m ic o s son aquellos que tienen relación con el tiem po.Capital Federal Copyright 2005-A ctualldad. Están directam ente vinculados con acciones que ocurren bajo cierta secuencia. 2. Clasificación Es posible clasificar a los diagramas según si tienen alguna relación con el tiempo o no. que incluye a los Diagramas de Secuencia y Comunicación) « Diagrama de Estado w w w . a r I Tel. luego otra. Estos diagramas son: • Diagrama de Clases « Diagrama de Objetos « Diagrama de Casos de Uso « Diagrama de Componentes • Diagrama de Despliegue 2.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 2.

educaclonlT.3.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 2. Estos diagramas son: « • « « Diagrama de Clases Diagrama de Objetos Diagrama de Componentes Diagrama de Despliegue 2. e d u c a c io n lT .3.Capital Federal Copyright 2005-A ctualldad. a r I Tel. Diagramas de Comportamiento Los D ia g ra m a s de C o m p o r ta m ie n to son aquellos que reflejan características de com portam iento del sistema o modelan procesos de negocios.4to Piso . Estos diagramas son: « « « • « Diagrama de Casos de Uso Diagrama de Comunicación Diagrama de Secuencia Diagrama de Actividades Diagrama de Estados w w w . Todos los derechos están reservados Página 12 . c o m .3. (54) (011) 4328-0457 Lavalle 648 . Diagramas Estructurales Los D ia g ra m a s E s tru c tu ra le s son aquellos que reflejan relaciones estáticas de una estructura.4.

" 3. relaciones y abstracciones. y por convención. Ejemplos de una clase puede ser la clase Auto. es una plantilla para arm ar un objeto. (54) (011) 4328-0457 Lavalle 648 . Clase Una clase representa a una agrupación de cosas. modelo. que es una clase representante de todos los autos posibles (autos de carrera. Objetivo Describir las clases del dominio y sus relaciones. atributos pueden ser color. y determ inan el estado que posteriorm ente tendrá un objeto En el caso de la clase Auto.4to Piso .3.como s u s ta n tiv o s en s in g u la r. cantidad de puertas y velocidad. representando a todos los animales posibles (mamíferos. modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto.) Las clases están form adas por atributos y métodos. Generalmente los métodos son verbos. Describe tipos de jerarquías. Las clases son detectadas en la mayoría de los casos . Re p res en tac ió n g r a f i c a de una clase w w w .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 3.3. Elementos 3. Por convención. la prim era letra debe estar en minúscula. etc. Que son los m é to d o s Los m é to d o s son las responsabilidades (o com portam iento) que realiza una clase. la prim era letra debe estar en minúscula. c o m . educaclonlT. la prim era letra debe estar en mayúscula. Todos los derechos están reservados Página 13 . etc. El Diagrama de Clases (Class Diagram) 3.Capital Federal Copyright 2005-A ctualldad. Definición El diagrama de clases es un diagram a que perm ite modelar la estructura del sistema desde un punto de vista estático.) Otro ejemplo puede ser la clase Animal. e d u c a c io n lT .. color. a r I Tel.1. 3. cualquier cantidad de patas. marca. Por convención. autos urbanos. cualquier marca.2. color.1. patente. Que son los a t r i b u t o s Los a t r i b u t o s son características que posee una clase. herbívoros u otros.

Se utiliza como base para otras clases en la relación de generalización. a r I Tel.4to Piso .Capital Federal Copyright 2005-A ctualldad. de carácter muy general. es decir un conjunto de métodos que no poseen implem entación.3. se puede crear un interfaz denominada Volador. pero no es posible determ inar que tipo de institución es. y la palabra en negrita e itálica. Por ejemplo. aterrizar y volar. pero no tiene sentido por sí sola. Por convención. o o m . (54) (011) 4328-0457 Lavalle 648 . e d u o a c io n lT . educaclonIT. la prim era letra debe estar en mayúscula. que tiene los atributos dirección y superficie. Interfaz A diferencia de la clase. Es una clase que no se puede instanciar. la interfaz define únicamente un com portam iento. Representa un "contrato” que una clase debe respetar en caso de im plem entar la interfaz. Las clases que no son abstractas se denominan c o n c re ta s . w w w .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP Auto cantidad Da Puertas: int velocidad: double + + + aceleraiQ : void arrancarQ : void fie na nQ void Las clases a b s t r a c t a s Las clases abstractas son clases que representan un concepto abstracto. es decir que no se puede crear un objeto a partir de ésta clase. Todos los derechos están reservados Página 14 . R e pr es e nt ac i ó n g r a fi c a de una clase a b s t r a c t a fi?sitine ron d ile c c ió n : S tiin g superficie: in t + pagaiImpu&stoaO : void 3. Por ejemplo una institución. que tiene los métodos despegar. Estos métodos deberán ser implem entados por las clases que decidan im plem entar la interfaz.2.

Todos los derechos están reservados Página 15 . a r I Tel.Capital Federal Copyright 2005-A ctualldad. w w w .4. o o m .4to Piso . y a la clase inferior se la denom ina subclase. Avión y Tren. Por ejemplo. (54) (011) 4328-0457 Lavalle 648 . Al construir varios relaciones de este tipo entre clases.a' de sp e g a r^ : void \faiar{) : v a d Por convención. y algunas de sus subclases pueden ser Auto.4. se genera la jerarquía de clases (o árbol de clases). Relaciones 3. 3. la clase MedioDeTransporte puede ser una superclase. Generalización La relación de generalización se produce entre dos clases. que representa a la relación de generalización.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP «¡rrtéflr'acs» V otad or + + + atenizarQ : vo. educaclonIT. e d u o a c io n lT . 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. La subclase deberá respetar la relación “es un" o “ is a” ..1. para definir el nombre de una interfaz se aplican las mismas reglas que para una clase. es posible entenderla como herencia. A la clase superior se la denomina su p e rc la s e . En térm inos de un lenguaje de programación.

Si Clasel está compuesta por Clase2 entonces Clasel determ ina la existencia de Clase2. es decir que el mismo Carburador no puede utilizarse al mismo tiempo en más de un Auto. w w w .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 3. con lo cual el Carburador no tiene sentido por si solo si no existe el Auto. donde Cuidador “ cuida” al Perro. Dicho Carburador puede utilizarse únicamente para ese Auto. donde una clase “ es s o c ia ” de otra o tienen algún tipo de relación. representando un fuerte sentido de pertenencia del “todo” hacia la “ parte” . un Auto e stá c o m p u e s ta por un Carburador. Es posible determ inar la multiplicidad de los extrem os de la relación. Es común describir con un nombre definido por el usuario la relación entre ambas.4. también serán eliminadas sus partes (Clase2). e d u c a c io n lT . y no para otros. ya que una clase determ ina la existencia de la otra. * Existen dos relaciones denominadas Composición y Agregación que son casos particulares de la relación de Asociación. Cui dador cuida Perro 1 1. también será eliminada Clase2. la clase Cuidador tiene una relación con la clase Perro. UML denomina a la relación como “ strong has-a relationship” . Clase2 no podrá existir por si sola si no existe C lasel. Por ejemplo. Asociación La relación de asociación representa una asociación entre dos clases. Si la Clasel es eliminada. Por ejemplo.3.2. (54) (011) 4328-0457 Lavalle 648 . Composición La relación de composición se puede describir como “ e stá c o m p u e s ta p o r” .4.Capital Federal Copyright 2005-Actualidad.4to Piso . 3. a r I Tel. c o m . es decir que si se elimina el “todo” (C la s e l). educacionIT. es decir que Clasel controla el tiem po de vida de Clase2. Todos los derechos están reservados Página 1 6 . en el caso anterior un cuidador cuida de uno a muchos perros.

Por ejemplo.4. es decir tiene sentido por si sola.. y la Columna es eliminada si la Tabla es eliminada. que incluye los métodos despegar. a r I Tel. pero si el Producto no form a parte de ninguna OrdenDeCompra.5. si Clasel tiene como partes a Clase2. aterrizar y volar. Clasel no controla el tiempo de vida de Clase2. sigue teniendo sentido por si mismo. Implementación o Realización La relación de implementación se produce entre una clase y una interfaz. 3. puede no ser eliminada Clase2. A diferencia de la composición. w w w . c o m . es decir que si se elim ina el “todo” (C la sel). representando un débil sentido de pertenencia del “todo” hacia la “ parte” .. La clase que im plem enta la interfaz tiene la obligación de Im plementar todos los métodos que forman parte de esa interfaz. no necesariamente serán eliminadas sus partes (Clase2). Agregación La relación de agregación se puede describir como “tie n e com o p a rte s a” . donde la Columna es construida si la Tabla es construida.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP Otro ejemplo muy ilustrativo puede ser la relación entre una Tabla y una Columna.4to Piso ." 0 . Si la OrdenDeCompra es eliminada. Por ejemplo. e d u c a c io n lT . Si la Clasel es eliminada. UML denomina a la relación como “weak has-a relationship” . Clase2 puede existir aún cuando Clasel no exista. educacionIT. una OrdenDeCompra tie n e com o p a rte s a uno o muchos Producto(s).Capital Federal Copyright 2005-Actualidad. un Avión para “ saber volar” deberá implem entar un interfaz denominada Volador.4. el Producto no será eliminado." 3.4. (54) (011) 4328-0457 Lavalle 648 . O rd e n De Co m pra P ro d u c to O -------------------------------------0 . Clasel no determ ina la existencia de Clase2. Todos los derechos están reservados Página 1 7 .

3. Clases Estereotipadas 3. Estas clases dentro de una arquitectura m ulticapa generalm ente pertenecen a la Capa de P re s e n ta c ió n (PL o P re s e n ta tio n L a y e r).5. o o m . estos son Boundary.Capital Federal Copyright 2005-A ctualldad. 3. El estereotipo Control El estereotipo C o n tr o l se utiliza para representar clases que se encargan de controlar los procesos de negocios.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP Esta relación también se denomina realización. El estereotipo Boundary El estereotipo B o u n d a r y se utiliza para representar clases que se encuentran en el lim ite (bound) del sistema. realizando la coordinación entre las clases del tipo Boundary y las clases del tipo actividades. Control y Entity. en el caso de las clases representa a una categoría o un tipo nuevo de clases. generalm ente implem entadas como ventanas.5.1. 3. Representa una funcionalidad determ inada. 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.5. e d u c a c io n lT . Se encargan de la organización y planificación de w w w .2. El Proceso Unificado de Desarrollo (presentado mas adelante) utiliza tres estereotipos de clases que se han estandarizado en el mercado.5. (54) (011) 4328-0457 Lavalle 648 . a r I Tel. En el patrón de diseño M-V-C representa a la vista. son clases que llevan a cabo las reglas de negocios. Entity.3. educaclonlT. Estas clases representan a la interfaz de usuario dentro de un sistema.4to Piso . Todos los derechos están reservados Página 18 . Se utilizan para capturar la interacción entre el usuario y el sistema a nivel de pantalla. identificada por su nombre.

Estas clases dentro de una arquitectura m ulticapa generalm ente pertenecen a la Capa de Acceso a D a to s (DAL o D ata Access L a y e r). El estereotipo Entity El estereotipo E n tity se utiliza para almacenar o persistir información propia del sistema. a r I Tel. En el patrón de diseño M-V-C representa al controlador.5. Representación grafica w w w . e d u c a c io n lT .4.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP Estas clases dentro de una arquitectura m ulticapa generalm ente pertenecen a la Capa de N eg o c io s (BL o B u sine ss L a y e r).5. 3.5.4to Piso . c o m . Todos los derechos están reservados Página 1 9 . En el patrón de diseño M-V-C representa al modelo. 3. educaclonIT. (54) (011) 4328-0457 Lavalle 648 .Capital Federal Copyright 2005-A ctualldad.

w w w . Adicionalmente. es posible utilizar una CRC Card (Class Responsability and Collaboration) para detallar el nombre de la clase.6.6. El modelo tiende a evolucionar en la fase de construcción a través de feed-backs que realizan los desarrolladores.6. De esta manera el program ador no tom a decisiones ni de Análisis ni de Diseño. 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.Capital Federal Copyright 2005-A ctualldad.4to Piso .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 3. El encargado de construirlo es el Diseñador. (54) (011) 4328-0457 Lavalle 648 . c o m . descripción. No se definen características propias de un lenguaje de programación.2. Toma como uno de ios documentos de entrada el correspondiente al Modelo de Análisis. y debe definir todo lo que sea necesario para que el desarrollador pueda codificar sin problemas. y se definen nuevas clases (en general las detectadas en Análisis se m antienen) que tiene un perfil netamente de diseño y resuelven cuestiones técnicas y ya no de negocios. sino que se intenta reflejar la realidad. 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. educaclonIT. e d u c a c io n lT . Aplicación 3.1. a r I Tel. 3. que son estereotipos de RUP (Racional Unified Process) presentados mas adelante. Todos los derechos están reservados Página 20 . es decir dentro de la de la etapa de Análisis. atributos y responsabilidades. 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. lo cual queda restringido a program ar en el código recibido. En algunos casos se categorizar las clases como e ntity / controller / boundary.

Todos los derechos están reservados Página 21 . determ inando el estereotipo < < ta b le > > para las tablas. el estereotipo < < co lu m n > > para los campos. y otros estereotipos posibles como <<P K > > para las claves prim arias y <<FK >> para las claves foráneas. 3. Ejemplo w w w . entre otros. e d u c a c io n lT .Capital Federal Copyright 2005-A ctualldad. (54) (011) 4328-0457 Lavalle 648 . c o m . a r I Tel. educaclonlT. En este caso las clases representan las tablas y los atributos representan los campos.3.7.4to Piso . 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.6. Para esto es necesario utilizar estereotipos (ver Sección Conceptos Generales).A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 3.

2. es una instancia de una clase. la prim era letra debe estar en minúscula y la palabra subrayada. y visualizar los objetos jun to con sus relaciones. c o m .3. Vínculo Se utiliza para establecer algún tipo de relación entre los objetos. (54) (011) 4328-0457 Lavalle 648 . a r I Tel. educacionIT." 4.4. Todos los derechos están reservados Página 22 . Definición El Diagrama de Objetos perm ite representar el sistema en un m omento determ inado del tiem po.3. e d u c a c io n lT . Es común agregar luego del nombre del objeto el nombre de la clase a la cual pertenece el objeto.4to Piso .Capital Federal Copyright 2005-Actualidad.1. y pueden estar estereotipados para una m ejor comprensión. es similar a obtener una fotografía o snapshot del sistema en un m omento determ inado.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 4. 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. Diagrama de Objetos (Object Diagram) 4.4. Elementos 4. Objeto El objeto representa una cosa en particular. no denota un tipo de relación en particular sino simplemente un vinculo que no tiene dirección..describir los objetos del dominio y sus relaciones.1. Por convención. Relaciones 4.1. Objetivo “. T o m a r Faneri : A lum no utn :Uni v e rs i dad 4. w w w . 4. Se suele utilizar como punto de partida para la construcción del Diagrama de Comunicación o Colaboración..

Su uso mas frecuente es la posibilidad de visualizar el sistema en un determinado momento. Aplicación 4.1.4to Piso .Capital Federal Copyright 2005-A ctualldad. w w w . estudiando que objetos están instanciados y la relación entre los mismos. 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. Vínculo Direccional Se utiliza de la misma form a que el vínculo. pero tiene como valor agregado que permite entender m ejor la relación.4. determ inar la navegabilidad de la misma. (54) (011) 4328-0457 Lavalle 648 . e d u c a c io n lT . c o m .5.5. 4. a r I Tel.A n á lis is y Diseño O rie n ta d o a O b je to s con UML y UP 4.2. Todos los derechos están reservadas Página 23 . educaclonIT.

Ejemplo w w w . educaclonlT.6. (54) (011) 4328-0457 Lavalle 648 .4to Piso .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 4. Todos los derechos están reservados Página 24 . c o m . e d u c a c io n lT . a r I Tel.Capital Federal Copyright 2005-A ctualldad.

y esta directam ente asociado con el “que debe hacer” un sistema. Definición El Diagrama de Casos de Uso representa las form as que tiene un usuario de utilizar un sistema.. es por esta razón que se utiliza para guiar el diseño y el desarrollo. etc. etc) son dirigidos por los casos de uso.M w w w . Diagrama de Casos de Uso 5. el sistema debe “adm inistrar clientes” . el rendim iento. Son requisitos no funcionales la velocidad de respuesta. donde especifique que el cliente no debe esperar mas de 1 segundo para realizar la transacción. (54) (011) 4328-0457 Lavalle 648 . son aquellos que especifican el “ que” debe hacer el sistema. Visualiza de form a directa los requisitos funcionales de un sistema. representa a las reglas de negocio. en el caso de estar operando con un cajero autom ático. Todos los derechos están reservados Página 25 . “ realizar cobros” . el hardware a utilizar..A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 5. 5. diseño. Por ejemplo.4to Piso . e d u c a c io n lT . exactitud. donde un cambio en un caso de uso impacta en gran parte del proceso de desarrollo. Todo el proceso de desarrollo de software (análisis. a r I Tel. educaclonlT. “ em itir facturas” . c o m . aunque pueden influir sobre la misma. Adicionalmente. es decir como ei sistema debería funcionar.Capital Federal Copyright 2005-A ctualldad. etc. Es im portante aclarar que no perm ite modelar workflow ni visualizar como se desarrollan las acciones detrás de los casos de uso. Requisi to No Funci onal Los requisitos no funcionales son aquellos que no determ inan la funcionalidad del sistema. Por ejemplo. es posible construir diagramas con diferentes niveles de detalle. el caso de uso "sacar dinero” puede tener asociado un requisito no funcional velocidad de repuesta. y no "como debe hacerlo” .describir las acciones del sistema desde el punto de vista del usuario.2. Requi si to Funci onal Los requisitos funcionales determ inan el funcionam iento del sistema. testing.1. Objetivo “.

a r I Tel.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 5. aunque también podría ser otro sistema. Asociación w w w . Elementos 5.4. Relaciones 5. Caso de Uso (Use Case) El caso de uso es la interacción que existe entre un actor y el sistema.1.4to Piso . pudiendo un caso de uso detallarse desde el punto de vista del usuario como un Diagrama de Casos de Uso. representa un form a de utilizar el sistema.Capital Federal Copyright 2005-Actualidad. Todos los derechos están reservados Página 26 . Generalmente son usuarios. El conjunto de todos los actores representará todas las form as de comunicación de una entidad externa con el sistema. (54) (011) 4328-0457 Lavalle 648 . e d u c a c io n lT . A cto r 5.4. Un caso de uso puede ser descrito en térm inos de casos de uso más simples. 5. Participa en un caso de uso (o más) con el propósito de cumplir su objetivo. educacionIT. c o m .2. Es posible entenderla como una unidad de funcionalidad expresada como una transacción entre un actor y el sistema.3.1. Actor El actor representa una entidad externa al sistema que utiliza el sistema.3.3. definiendo el rol que un usuario del sistema va a asumir cuando esté en funcionam iento.

(54) (011) 4328-0457 Lavalle 648 . y a otro elemento que tiene la base del elemento general. y aparte agrega otras cosas. Apl i caci ón e n t r e A ct or es Apl i caci ón e n t r e Casos de Uso 5.4to Piso . y el elemento2 es una esp e cia liza ció n del ele m e n tol. Se dice que el elem entol es una g e n e r a liz a c ió n del elemento2. Especialización w w w . a r I Tel.3. Todos los derechos están reservados Página 27 .4. 5. Por ejemplo. educacionIT.Capital Federal Copyright 2005-Actualidad. e d u c a c io n lT .2. el elemento2 tom a como base al e le m e n to l.4. Generalización La relación de Generalización representa a un elemento que es general. con lo cual el elemento2 tiene como mínimo lo que tiene el elemento 1.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 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. pero como valor agregado tiene algunas particularidades. Esta relación puede darse tanto entre actores como entre casos de uso. c o m .

Por ejemplo. “ abrir cuenta corriente” es una 5. í a b rir cuenta ) / ^ -«include» 5 -n \ re g is tra r da tos / i * i n el u d e » ------ *-v J j d e p o sita r fo n d o s 5. w w w .4. educacionIT. ya que al abrir un cuenta en un banco es necesario registrarse y depositar fondos en la cuenta. Se maneja bajo el mismo criterio que la generalización. el caso de uso “ entregar pasaporte” es una extensión del caso de uso “ abrir cuenta” .4.5. “ abrir cuenta” es una g e n e r a liz a c ió n de “ abrir cuenta corriente” . a r I Tel. el caso de uso “ abrir cuenta” incluye a los casos de uso “ registrar datos” y “ depositar fondos” . Por ejemplo. donde el caso de uso incluido es parte del caso de uso base. Todos los derechos están reservados Página 28 . (54) (011) 4328-0457 Lavalle 648 . Inclusión La relación de Inclusión representa que un caso de uso esta incluido en otro caso de uso base. Según el ejemplo anterior. c o m . cuando un caso de uso incluye al otro pero opcionalmente. Extensión La relación de Extensión se utiliza entre dos casos de uso.4to Piso . ya que solo será solicitado entregar el pasaporte a aquellas personas que sean extranjeros y quieran abrir una cuenta.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP La relación de Especialización es la relación inversa a la relación de Generalización.Capital Federal Copyright 2005-Actualidad. con lo cual también es aplicable a actores. e d u c a c io n lT . pero también e sp e cia liza ció n de “ abrir cuenta” .4.

es decir asegurar que lo que tiene que hacer el sistema. 5. De esta manera se evitan "m alentendidos” acerca de las funcionalidades que están incluidas de las que no están incluidas. c o m .5. y así asegurar la calidad del producto desde el punto de vista funcional. 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. 5. los casos de uso sirven como una form a de ponerse de acuerdo entre el cliente (es el que quiere/necesita un sistema) y el proveedor (es el que construye el sistema). incluyendo al cliente mismo. a r I Tel. Establecimiento de contratos Dependiendo de la envergadura del sistema. ya que los casos de prueba son los casos de uso con algunos agregados adicionales como casos especiales a testear.5.5. 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.2. Modelo de Casos de Uso El modelo de casos de uso es el conjunto de todos los diagramas de casos de uso que form an parte del sistema. educaclonIT. w w w .5.Capital Federal Copyright 2005-A ctualldad. Se suelen establecer contratos en base a los casos de uso. sistemático e intuitiva.3. Captura de Requisitos Funcionales La form a estándar de captura de requisitos funciones son los Diagrama de Casos de Uso.1. En este artefacto quedan documentados todos los requisitos funcionales que deberá satisfacer el sistema. lo esta haciendo correctam ente.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 5. El sistema no podrá tener más ni menos funcionalidad que la especificada en este documento. e d u c a c io n lT . y se utiliza como la documentación que detalle la funcionalidad del sistema. 5.4to Piso . (54) (011) 4328-0457 Lavalle 648 . Aplicación 5.4.5. Esto se debe a que es una form a sencilla. fácil de leer por cualquier persona que form a parte de un proyecto. Los casos de uso se utilizan como punto de partida para los casos de prueba. Todos los derechos están reservados Página 29 .

Ejemplo w w w .6.Capital Federal Copyright 2005-A ctualldad. educaclonlT. a r I Tel. o o m .4to Piso . (54) (011) 4328-0457 Lavalle 648 . e d u o a c io n lT . Todos los derechos están reservados Página 30 .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 5.

1.3. a r I Tel. Estado compuesto (Sub-machine State) El estado compuesto es un estado que contiene sub-estados. Se lo conoce también como Maquina de Estados. Si se modela el estado compuesto como una “ caja negra” que esta desarrollada en un diagrama aparte.. Definición El Diagrama de Estados perm ite visualizar los cambios de com portam iento de un objeto a partir de sus transiciones. c o m . « t* d o 6. y representa el conjunto de valores que tiene ese objeto en un determ inado momento. educacionIT. (54) (011) 4328-0457 Lavalle 648 .3.2. Estado (State) El estado corresponde generalm ente a un objeto. Todos los derechos están reservados Página 31 . Describe un periodo de tiempo durante el ciclo de vida del objeto.4to Piso .Capital Federal Copyright 2005-Actualidad.describir los estados por los cuales puede pasar un objeto durante su ciclo de vida... e d u c a c io n lT . Elementos 6.2. su representación grafica es la siguiente: w w w . Diagrama de Estados 6.3.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 6." 6. Es posible modelar los sub-estados dentro del estado compuesto. o en un diagrama de estados aparte.. que visualiza las acciones que ocurren cuando un objeto entra en ese estado. 6.1. El com portam iento interior de un estado es posible modelarlo con un Diagrama de Actividad. Objetivo “.

Capital Federal Copyright 2005-A ctuaiidad. c o m . (54) (011) 4328-0457 Lavalle 648 . p seu d o -astad o in ic ia l 6. a r I Tel. Pseudo-Estado Final (Final State) w w w . su representación grafica es la siguiente: ■oslado1 6.4to Piso . Todos los derechos están reservados Página 32 .3. Pseudo-Estado Inicial (Initial State) El pseudo estado inicial representa el comienzo de las transiciones de los posibles estados.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP ís ia d * com puesto Si se modela el estado compuesto como un conjunto de sub-estados visibles. e d u c a c io n lT .4. educaclonIT.3.3.

3. c o m . w w w . / estado 1 \ V ii d i> ps-jijd > J esta do fin a l 6. y representa el punto de salida del sub estado o estado compuesto desde el interior. Punto de Salida (Exit Point) El punto de salida es utilizado en sub estados o estados compuestos. e d u c a c io n lT . y representa el punto de entrada al estado compuesto desde el exterior. 6.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP El pseudo estado final representa el final esperado de las transiciones de los posibles estados. Punto de Entrada (Entry Point) El punto de entrada es utilizado en estados compuestos.3. Todos los derechos están reservados Página 33 .6. a r I Tel. educaclonlT.4to Piso . (54) (011) 4328-0457 Lavalle 648 .5.Capital Federal Copyright 2005-A ctualldad.

educacionIT.Capital Federal Copyright 2005-Actualidad. Estado de Sincronización (Sync State) El estado de sincronización indica que los caminos concurrentes que pasen por este estado serán sincronizados. aunque no tiene la capacidad para representar el estado activo de un posible sub-estado (si existiera) del sub-estado del estado compuesto. 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. Todos los derechos están reservados Página 34 . c o m . « ítid o de sincr#nizjcl»n 6.3. Estado Histórico Profundo (Deep History State) w w w . 6. (54) (011) 4328-0457 Lavalle 648 .3.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 6. a r I Tel.9.8.7.3.4to Piso . e d u c a c io n lT .

Capital Federal Copyright 2005-A ctualldad.11.3. educaclonlT. Join El join es el proceso inverso al fork. 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. (54) (011) 4328-0457 Lavalle 648 . w w w .3. Todos los derechos están reservados Página 35 . c o m .4to Piso . es un pseudo estado que se utiliza para unir dos transiciones de entrada concurrentes en una única transición de salida. a r I Tel. y además tiene la capacidad para representar el estado activo de un posible sub-estado (si existiera) del subestado del estado compuesto. 6. e d u c a c io n lT . es decir que almacena el histórico de todos los estados activos en form a recursiva.10.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP El estado histórico profundo se utiliza para representar el estado activo (o subestado) mas reciente de un estado compuesto.

a r I Tel. y si es falsa tom a el camino alternativo. e d u c a c io n lT . educaclonlT. 6. (54) (011) 4328-0457 Lavalle 648 . o también para separar un camino en varios caminos alternativos.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 6. Todos los derechos están reservados Página 36 . si el resultado de la condición es negativo entonces no se produce esa transición. Se suelen agregar guardas a las transiciones para especificar una condición para la transición.4to Piso . Decisión (Choice) La decisión indica un condicional en el progreso: si la condición es verdadera tom a un camino. 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.13.3.3.Capital Federal Copyright 2005-A ctualldad. c o m .12. w w w .

Es im portante destacar que un Diagrama de Estados no es un diagrama m ayorm ente utilizado. es posible especificar un evento disparador (trigger) que inicia la transición de un estado a otro. En form a opcional. Todos los derechos están reservados Página 37 . Transición La transición es una ocurrencia en el tiempo.Capital Federal Copyright 2005-Actualidad. w w w . Adicionalmente.1. a r I Tel. educacionIT.4. cuando el foco del negocio requiere hacer énfasis en las transiciones de ese objeto.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 6. Representa la form a de vincular estado.5.5. Relaciones 6. Seguimiento de un objeto El Diagrama de Estados se utiliza generalm ente para hacer un seguimiento fino de un objeto en particular.4.1. y es el medio en que un estado pasa a otro estado. se utiliza únicamente para casos puntuales. c o m . (54) (011) 4328-0457 Lavalle 648 .4to Piso . sin una determ inada duración. Aplicación 6. • it a d o l evento =rt=do2 6. se utilizan para ayudar al desabollador a entender funcionalidades complejas o algún proceso de negocio especializado en una área determinada. e d u c a c io n lT .

a r I Tel. Todos los derechos están reservados Página 38 . El estado compuesto “ inscripto" desarrollado en otro diagrama queda de la siguiente manera: w w w .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 6. c o m . educaclonlT.6. e d u c a c io n lT . Ejemplo Se modelo a continuación los estados posibles de un alumno de una universidad.4to Piso . (54) (011) 4328-0457 Lavalle 648 .Capital Federal Copyright 2005-A ctualldad.

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. a c tiv id a d estru ctu ra d a 7. Diagrama de Actividades 7. educacionIT.3.." 7.. 7. y representa la transform ación que ocurre dentro del sistema. e d u c a c io n lT . Elementos 7. Generalmente representa a una unidad funcional dentro de una actividad mayor o de un proceso.1. y puede incluir la participación de sub-actividades y/o acciones. a r I Tel. w w w .3. c o m . visualizando las acciones de manera ordenada. Actividad (Activity) Una actividad refleja el control de flujo y de datos de un proceso. Objetivo “.describir la acciones que ocurren dentro de un proceso.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP 7. La diferencia principal con las actividades radica en que la acción no puede descomponerse.3.1. (54) (011) 4328-0457 Lavalle 648 ..3.2. Acción (Action) La acción es la unidad funcional básica dentro de un diagrama de actividades.2.. localizándose en la secuencia de acciones y condiciones necesarias para su ejecución.3.Capital Federal Copyright 2005-Actualidad. Todos los derechos están reservados Página 39 . Permite modelar procesos y comprender la ejecución general de un sistema.4to Piso . ^ a c tiv id a d 7. Definición El Diagrama de Actividad se utiliza principalm ente para modelar flujo de trabajo o w orkflow.

en este caso adicionalmente representa que un objeto es construido.3. a r I Tel. w w w . Central Buffer Node El buffer tiene el mismo significado que el datastore. pero se utiliza para almacenar información tem poralm ente (información no persistente o transitoria).3.5. « da tastore » « d a ta d o re» a c c ió n fue nte d e stin o 1 l\ << selection >> Obtiene el ítem i << transform aron » A l man ce na el item 7. Objeto (Object) El objeto tiene el mismo significado que el presentado para los diagramas anteriores.6.A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP m ientras acciones. e d u c a c io n lT . educacionIT.3.4. modificado o consultado luego de una actividad. Todos los derechos están reservados Página 40 .Capital Federal Copyright 2005-Actualidad. (54) (011) 4328-0457 Lavalle 648 . Se puede utilizar tanto para almacenar información como para consultar información. que una actividad puede descomponerse en sub-actividades y/o 7.4to Piso . Datastore Object El datastore es un objeto que se utilice para modelar la persistencia de información permanente. o b je to 7. c o m .

En el siguiente ejemplo. la señal de envío se utiliza para notificar al proveedor acerca de la creación de un pedido. Existen dos tipos de señales de recepción. Señal de Envío (Send Signal) La señal de envío se utiliza para representar que se esta enviando un objeto en form a de señal hacia algún destino no necesariamente representado en el diagrama.3. w w w . donde es enviado el objeto “ pedido” al proveedor. educacionIT. 7.4to Piso .A n á lis is y Diseño O r ie n ta d o a O b je to s con UML y UP ^ a c c ió n fu e n te ^ a c c ió n j —----------r i ­ d e stin o 7. 7. c o m .7.8.9. Pseudo-Estado Inicial (Initial State) El pseudo estado inicial representa el comienzo de los flujos entre las acciones. (54) (011) 4328-0457 Lavalle 648 .3.3.Capital Federal Copyright 2005-Actualidad. 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.10. a r I Tel. Pseudo-Estado Final (Final State) El pseudo estado inicial representa el final de los flujos entre las acciones.3. e d u c a c io n lT . ^ c r e a r p e d id o i j~ ■ n o tific a r p io v & e d o r 7. Todos los derechos están reservados Página 41 .

com . Fork w w w . finalización del mes. (54) (011) 4328-0457 Lavalle 648 . Todos los derechos están reservados Página 42 . es una acción que espera la ocurrencia de un evento del tipo tiempo. etc. r f excepti on Handl er 7.Capital Federal C opyright 2005-Actualidad. educacionIT. comienzo de mes 7. por ejemplo comienzo de un mes. Si se utiliza en conjunto con la señal de envío.ar | Tel. Manejador de Excepciones (Exception Handler) El manejador de excepciones esta compuesto por una o mas acciones y se encarga de tom ar medias correctivas en caso de que se haya lanzado alguna excepción (o se haya producido algún error).11.A nálisis y Diseño O rientado a O bjetos con UML y UP Accept Event Action Esta señal se utiliza para determ inar la recepción de un evento por parte de terceros. comienzo del día.3.e d u cacionIT . Accept Time Event Act ion Esta señal se utiliza para representar el pasaje del tiem po. establece que el flujo continuara normalmente una vez que se produzca la señal de respuesta.4to Piso .12.3.

3. Join El join es el proceso inverso al fork. (54) (011) 4328-0457 Lavalle 648 . Todos los derechos están reservados Página 43 . w w w . educaclonIT.13.e d u c a c io n lT . Decisión (Choice) La decisión indica un condicional en el progreso: si la condición es verdadera tom a un camino.Capital Federal Copyright 2005-A ctualldad.14. 7. 7.c o m . y si es falsa tom a el camino alternativo.3.A nálisis y Diseño O rientado a O bjetos con UML y UP El fork es un pseudo estado que se utiliza para separar un flu jo de entrada en dos flujos concurrentes que tienen como destino diferentes actividades y/o acciones. es un pseudo estado que se utiliza para unir dos flu jo s de entrada concurrentes en un único flujo de salida.a r I Tel.4to Piso .

y permiten estructurar la vista o las partes de la actividad. Relaciones 7.A nálisis y Diseño O rientado a O bjetos con UML y UP 7. (54) (011) 4328-0457 Lavalle 648 . educaclonIT. Todos los derechos están reservados Página 44 .4to Piso . determ inado por una dirección. Flujo decontrol (Control Flow) El flu jo de control es un conector que une dos actividades o acciones. Determina que o quien realiza cada actividad. realizando una separación lógica.c o m .4.15.e d u c a c io n lT . el control pasa a la acción siguiente. una inicial y una final. También son denominadas swimlañes.4.Capital Federal Copyright 2005-A ctualldad. 7. Una vez que la acción inicial es completada.1. w w w .3.a r I Tel. Partición (Partition) La partición se utiliza para establecer responsabilidades en las acciones o actividades. Son de uso opcional.

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. 7. representando un flujo de información de la actividad al objeto. (54) (011) 4328-0457 Lavalle 648 .a r I Tel.Capital Federal Copyright 2005-Actualidad.3.pin salida > i __ —f I pin entrada accioné 1 J 7.c o m . Flujo de objeto con Pines (Pinned Object Flow) El flujo de objeto con distinción es semánticamente igual al flujo de objeto tradicional. 7.4.4. 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. donde se pueden representar las sentencias (acciones) junto con las estructuras w w w .5. educacionIT.2. al estilo diagramas de jackson.4.1.4. Flujo de objeto (Object Flow) El flujo de objeto conecta una actividad con un objeto. Todos los derechos están reservados Página 45 . la diferencia radica en la form a de graficarlo. ( a c c io n l V l ^----------------.e d u c a c io n lT . Aplicación 7.5.4to Piso .A nálisis y Diseño O rientado a O bjetos con UML y UP Es posible definir una guarda que representa una condición que debe cumplir la acción inicial para pasar a la próxim a acción. ya que de esta manera resulta mas compacto.

A nálisis y Diseño O rientado a O bjetos con UML y UP de control de flujo utilizando las decisiones.2. w w w .4to Piso . joins y actividades estructuradas para representar llamadas a “ cajas negras” o procedimientos. y visualizar la transform ación de información que va ocurriendo durante todo el proceso. Es posible modelar como arranca un proceso. forks.Workflow El uso mas común del Diagrama de Actividades es la representación de flujos de trabajo o procesos de negocio.Capital Federal Copyright 2005-A ctualldad. (54) (011) 4328-0457 Lavalle 648 . educaclonIT.c o m .5.e d u c a c io n lT .a r I Tel. o también fuera del sistema a través de señales de recepción (por ejemplo. En este contexto los eventos generalm ente se originan dentro del sistema al finalizar las diferentes acciones. Todos los derechos están reservados Página 46 . a partir de quien o en que área se produce. el proveedor entrego la mercadería) y a través de eventos correspondientes al tiem po (por ejemplo. paso un mes). 7. Modelado de procesos de negocio .

A nálisis y Diseño O rientado a O bjetos con UML y UP

7.6. Ejemplo

w w w .e d u c a c io n lT .c o m .a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Copyright 2005-A ctualldad, educaclonlT. Todos los derechos están reservados

Página 47

A nálisis y Diseño O rientado a O bjetos con UML y UP

8. Diagrama de Comunicación (Communication Diagram)
8.1. Definición
El Diagrama de Colaboración modela los objetos jun to 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 Diagrama de Secuencia Interacción, y semánticamente es equivalente al

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.

Actor

8.3.2. Objeto
Es el mismo elemento que se utiliza en el Diagrama de Objetos.

8.3.3. Boundary

w w w .e d u c a c io n lT .c o m .a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Copyright 2005-Actualidad, educacionIT. Todos los derechos están reservados

Página 48

A nálisis y Diseño O rientado a O bjetos con UML y UP

Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso representa a un objeto, instancia de una clase que esta estereotipada como Boundary.

8.3.4. Control
Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso representa a un objeto, instancia de una clase que esta estereotipada como Control.

8.3.5. Entity
Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso representa a un objeto, instancia de una clase que esta estereotipada como Entity.

8.4. Relaciones 8.4.1. Vinculo
Es la misma relación que se utiliza en el Diagrama de Objetos.

8.4.2. Vinculo Direccional
Es la misma relación que se utiliza en el Diagrama de Objetos.

8.4.3. Mensaje
El mensaje es una llamada que se realiza de un objeto origen a un objeto destino, para entablar una “conversación” . Existen dos tipo de mensajes a enviar: los mensajes sincrónicos y los mensajes asincrónicos.

Me nsaj e Si ncróni co
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.

w w w .e d u c a c io n lT .c o m .a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Copyright 2005-A ctualldad, educaclonlT. Todos los derechos están reservados

Página 49

A nálisis y Diseño O rientado a O bjetos con UML y UP

Me ns aj e A s in c r ó n i c o
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 deCasos 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 o b je to s 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.

w w w .e d u c a c io n lT .c o m .a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Copyright 2005-A ctualldad, educaclonIT. Todos los derechos están reservados

Página 50

a r I Tel. educaclonIT.A nálisis y Diseño O rientado a O bjetos con UML y UP 8.Capital Federal Copyright 2005-A ctualldad. (54) (011) 4328-0457 Lavalle 648 .c o m . Todos los derechos están reservados Página 51 .4to Piso .e d u c a c io n lT . Ejemplo ¡ I n t e r f jz S a lid a w w w .6.

.3. pone mayor énfasis en la interacción entre objetos a través del tiem po y no m uestra la relación entre objetos que no sea a través de mensajes. Esta basado en la utilización de un eje vertical im aginario que representa el paso del tiem po. Diagrama de Secuencia (Sequence Diagram) 9.A nálisis y Diseño O rientado a O bjetos con UML y UP 9.2. Este representada con una línea vertical punteada. ” 9.3. Definición El Diagrama de Secuencia se utiliza para representar la interacción de objetos a lo largo del tiem po.describir como colaboran los distintos objetos entre sí para conseguir un objetivo a lo largo del tiempo .Capital Federal Copyright 2005-A ctualldad. A diferencia del Diagrama de Comunicación.3. 9. Boundary w w w . Todos los derechos están reservados Página 52 . Actor Es el mismo elemento que se utiliza en el Diagrama de Comunicación 9. Elementos 9.3.1. (54) (011) 4328-0457 Lavalle 648 .2. . Objetivo “. por eso es semánticamente igual al diagrama de Comunicación.1.4to Piso .e d u c a c io n lT . educaclonlT.a r I Tel.. Línea de vida (LifeLine) La línea de vida representa desde el nacimiento del objeto hasta su destrucción.. aunque con algunas variantes desde el punto de vista sintáctico. cb je to l 9.3.c o m .

Por ejemplo.5.4.5. educaclonlT. 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.3. Generalmente se utilizan o b je to s de diseño. w w w . con un mayor nivel de detalle.1.e d u c a c io n lT . Control Es el mismo elemento que se utiliza en el Diagrama de Comunicación 9.4.5.4. Entity Es el mismo elemento que se utiliza en el Diagrama de Comunicación 9. Aplicación 9. Mensaje Es la misma relación que se utiliza en el Diagrama de Comunicación.4to Piso . También se utilizan los mensajes sincrónicos y los asincrónicos.3.c o m .Capital Federal Copyright 2005-A ctualldad.A nálisis y Diseño O rientado a O bjetos con UML y UP Es el mismo elemento que se utiliza en el Diagrama de Comunicación 9. Relaciones 9. que luego utilizará un desabollador para im plem entar el sistema. el caso de uso “ registrar usuario” representa una acción que realiza un usuario en un sistema.a r I Tel. y si es necesario documentar lo que ocurre detrás del “ registrar usuario” . (54) (011) 4328-0457 Lavalle 648 . Todos los derechos están reservados Página 53 . 9. se utiliza este diagrama para visualizar la interacción entre los objetos para alcanzar el objetivo de la registración. donde el objetivo es visualizar la interacción de objetos a nivel técnico.1.

Ejemplo $ A U suaria O Irv tírfa z R e s ¡si ra c ió n O&storReg retracten Adminislrad&rDeCori&xiones I re¡gistr¿nj w w w .a r I Tel. educaclorIT. Todos los derechos están reservados Página 54 .e d u c a c io n lT . (54) (011) 4328-0457 Lavalle 648 .A nálisis y Diseño O rientado a O bjetos con UML y UP 9.Capital Federal Copyright 2005-A ctualldad.c o m .6.4to Piso .

jar en Java. educacionIT. contiene un conjunto de métodos sin implem entar. Una interfaz. un componente puede tener en su interior Diagramas de Comunicación.A nálisis y Diseño O rientado a O bjetos con UML y UP 10. un protocolo de com portam iento. Puede estar representado como un archivo de código fuente." 10. (54) (011) 4328-0457 Lavalle 648 . en su aspecto mas básico.Capital Federal Copyright 2005-Actualidad. Objetivo “. 10.3.3. Todos los derechos están reservados Página 55 .e d u c a c io n lT . Interfaz La interfaz es una especificación de com portam iento..1. Actividades y Estados. Secuencia.2. un archivo . generalm ente contienen clases.a r I Tel.describir la relación que existe entre los distintos componentes del sistema. Un componente puede ser muy pequeño.dII en Windows o un archivo .. w w w .2.1.c o m .. Dentro del enfoque de UML. com ponente a 10. y pueden haber otros mas grandes que agrupen a los mas pequeños.3. Diagrama de Componentes 10. es una parte lógica de un sistema que envuelve una implem entación. Se puede entender como un contrato entre las partes. Elementos 10. Componente Un componente representa a una porción del software. En su interior. Esta directam ente vinculado con el diseño.4to Piso . Definición El Diagrama de Componentes perm ite modelar las relaciones e interfaces que existen entre distintos componentes que conformaran el sistema. que los implem entadores que la utilizan están comprometidos a respetar. y se utiliza como base para el desarrollo de la implementación del sistema..

4. c o n s u m id o r . una form a completa que expresa los métodos que agrupa junto con su nombre. También se denomina a esta relación como Realización.4.A nálisis y Diseño O rientado a O bjetos con UML y UP Existen dos form as de representar una interfaz.4. ya que un cambio en el proveedor podría afectar el normal funcionamiento del cliente.... (54) (011) 4328-0457 Lavalle 648 .> p ro ve e d o r a 10.Capital Federal Copyright 2005-Actualidad. Implementation (Implementation) La relación se puede visualizar de dos form as distintas.. La relación esta form ada por: • • un proveedor (suppüer) 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.. « i nte rfa t í » iníerfaz íflítfWZ 10. .e d u c a c io n lT .4to Piso .. Utilización (Use) La relación de utilización puede existir entre componentes.c o m .. Todos los derechos están reservados Página 56 . dependiendo de como se representa la interfaz. Relaciones 10.2. y una form a más sencilla que representa a través de un icono la interfaz solo con su nombre.1.a r I Tel.. educacionIT. esta fundam entada en un componente que utiliza a un segundo componente para llevar a cabo su funcionalidad.... w w w ..

.4to Piso .1. y definiendo una organización en térm inos generales de un sistema. ¡ntarF& z com ponente « re a liz e » O ¡nterfaz 10. stock.2.. especificando posibles componentes que conforman un modulo. etc.5. llamados módulos. adm inistración de productos. educaclonlT. 10.A nálisis y Diseño O rientado a O bjetos con UML y UP c o m p o n e n te a « r e a liz a » « ¡n te rr'a c e » . .5.a r I Tel.. w w w . i. Modelado de un Sistema El Diagrama de Componentes puede ser utilizado para modelar un sistema si se utilizan los grandes componentes del sistema. De esta manera se puede construir un diagrama que visualice la relación existente entre los módulos.e d u c a c io n lT .Capital Federal Copyright 2005-A ctualldad.c o m . Modelado de un Modulo El Diagrama de Componentes puede ser utilizado con un mayor nivel de detalle. Todos los derechos están reservados Página 57 . Aplicación 10. 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. estableciendo “ proveedores” y "clientes” bien definidos. (54) (011) 4328-0457 Lavalle 648 . por ejemplo la posible relación entre los módulos de compras.5. y sus posibles interfaces. ventas.

Capital Federal Copyright 2005-A ctualldad. educaclonIT.4to Piso .A nálisis y Diseño O rientado a O bjetos con UML y UP 10. (54) (011) 4328-0457 Lavalle 648 . Ejemplo J Ses/O ites D e U suaao V en rtas a (EíTcrípiarfor o : re a liza» A « le a liz e » ¡Ventas w w w .e d u o a c io n lT .a r I Tel.6. Todos los derechos están reservados Página 58 .o o m .

(54) (011) 4328-0457 Lavalle 648 ." 11. 11. Elementos 11.c o m . / nodo ■ ■ ■ 11.. Objetivo ".describir la arquitectura de un sistema.3.2.3. Los componentes residen dentro de un nodo. Un nodo puede ser un servidor. Diagrama de Despliegue 11. es decir que el nodo representa el “ medio am biente” de un componente.2..3. y alberga uno o más componentes y /o código ejecutable.a r I Tel. o desde una punto de vista físico. donde puede ser desplegado un sistema. representando directam ente cada unidad de hardware. Puede tener m em oria y capacidad de procesamiento. una impresora.e d u c a c io n lT .A nálisis y Diseño O rientado a O bjetos con UML y UP 11.Capital Federal Copyright 2005-A ctualldad..4to Piso . etc.1. educaclonIT. una estación de trabajo. Todos los derechos están reservados Página 59 . Nodo (Node) El nodo es una unidad que representa a un recurso computacional. Componente (Component) Conceptualmente igual al componente utilizado en el Diagrama de Componentes. Definición El Diagrama de Despliegue representa la arquitectura desde el punto de vista lógico. basándose en la organización del software. w w w .1..

Un ejemplo puede ser el software de un servidor Web.c o m . Ambiente de Ejecución (Execution Environment) El Ambiente de Ejecución es un nodo estereotipado como < < execution enviro n m e nt> > que representa una unidad de software que provee un Ambiente de Ejecución para componentes.e d u c a c io n lT . Dispositivo (Device) El Dispositivo es un nodo estereotipado como < < de vice > > que representa una unidad de hardware dentro de un sistema.4.3. un switch. etc.a r I Tel. Todos los derechos están reservados Página 60 . educaclonlT.Capital Federal Copyright 2005-A ctualldad.A nálisis y Diseño O rientado a O bjetos con UML y UP 11. Un ejemplo puede ser el hardware de una servidor Web.3.4to Piso . / «d evice» disp ositi v ü .3.■ / 11. / «ex* cmti on environment» am biente de e je c u c ió n w w w . una impresora. (54) (011) 4328-0457 Lavalle 648 .

3.A nálisis y Diseño O rientado a O bjetos con UML y UP 11. (54) (011) 4328-0457 Lavalle 648 .e d u c a c io n lT . / nodol / A nodo 2 y / 11.1. es decir asociación.4. agregación y composición. Las reglas utilizadas para las asociaciones son las mismas que las utilizadas para el Diagrama de Clases. y se m aneja bajo los mismos principios que la relación de utilización en el Diagrama de Componentes. Todos los derechos están reservados Página 61 . Especificación de Despliegue (Deployment Spec) La Especificación de Despliegue especifica los parám etros ju n to con los valores necesarios para llevar a cabo un despliegue de uno o mas componentes dentro de uno nodo. w w w .5.a r I Tel. Asociación La relación de asociación se realiza entre nodos.c o m . Utilización (Use) La relación de utilización se realiza entre nodos para establecer que un nodo. para llevar a cabo sus tareas. ■ > :d a pl oym e nt spe c» especificación de despliegue 11. y representa que los nodos asociados cooperan de alguna manera.Capital Federal Copyright 2005-A ctualldad.4. necesita utilizar otro nodo.2. Esta relación establece una dependencia entre los nodos. educaclonlT. Relaciones 11.4.4to Piso .

4. w w w .. Definición de la arquitectura de un sistema El Diagrama de Despliegue se puede utilizar para representar la arquitectura del sistema.. Todos los derechos están reservados Página 62 . Se deben especificar los servidores intervenientes en cada capa ju n to con los potenciales clientes. (54) (011) 4328-0457 Lavalle 648 .1.....a r I Tel....> «use» n o d tó 11. educaclonlT.e d u c a c io n lT .4to Piso .c o m ... Los cables de red o enlaces aéreos se utilizan para representar esta relación. Aplicación 11. /' nodol y ---------. si tiene valor para el negocio es posible visualizar también impresoras.... modelando las partes que intervienen.A nálisis y Diseño O rientado a O bjetos con UML y UP / 7 n odol ■.5..... routers o cualquier otra unidad de hardware que tenga incidencia sobre el sistema.3.:> / nodo2 S 11. representados en ambos casos por nodos que incluyen sus componentes de software más representativos. 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.5. Adicionalmente. switches..Capital Federal Copyright 2005-A ctualldad.

A nálisis y Diseño O rientado a O bjetos con UML y UP 11. Todos los derechos están reservados Página 63 .a r I Tel. (54) (011) 4328-0457 Lavalle 648 .c o m .4to Piso . educaclonlT. Ejemplo «exeeutton envii&nm ent» W eb S e rv e r PHP D atabase S e rve r Database M anage ment System SI w w w .Capital Federal Copyright 2005-A ctualldad.e d u c a c io n lT .6.

Ingeniería Directa La ingeniería directa es el proceso que perm ite generar código fuente en cualquier lenguaje a partir de los distintos diagramas de UML. El E n te rp ris e A rc h ite c t permite generar código en diversos lenguajes. entre ellos Java. C#. (54) (011) 4328-0457 Lavalle 648 . Perl.2. C+ + . Ingeniería Inversa La ingeniería inversa es el proceso que perm ite generar diagramas a partir de código fuente.c o m . Conceptos Generales 12. y entre las relaciones la mas conocida es << use> >.4to Piso . Está form ado por una etiqueta (tag) y un valor (valué).4. Por ejemplo. C+ + . como ser clases y/o relaciones.Net. El E n te rp ris e A rc h ite c t perm ite generar el diagrama de clases a partir del código fuente de diversos lenguajes tales como Java. Delphi y PHP w w w .A nálisis y Diseño O rientado a O bjetos con UML y UP 12. pero vacíos. Las clases estereotipadas mas comunes son las clases del tipo < < Boundary> >. VB. a partir del diagrama de clases es posible generar el "esqueleto del sistem a” . En caso de no establecer un icono para el estereotipo. quedando definido con una semántica extendida y un nuevo icono gráfico. se puede guardar el nombre de la persona que construyó una clase o la versión de la misma. es decir el código fuente form ado por clases y métodos.3. Perl. < < C o ntro l> > y << Entity> > .Net. Estereotipos Un estereotipo es un nuevo elemento de UML que extiende a partir de uno existente.e d u c a c io n lT . Delphi y PHP. VB. aunque este ultim o es opcional.Capital Federal Copyright 2005-A ctualldad.1. 12.a r I Tel. se visualiza de la form a < < nom breEstereotipo> >. educaclonlT. donde por ejemplo. 12. Se utiliza generalm ente para construir el diagrama de clases a partir de las clases de código fuente de cualquier lenguaje. Valor etiquetado (Tagged Valúes) El valor etiquetado se utiliza para guardar información adicional dentro un elemento de UML. Los estereotipos pueden utilizarse para cualquier elemento de UML. G#. 12. Todos los derechos están reservados Página 64 .

El objetivo de XMI es perm itir la portabilidad de un proyecto armado en UML desde cualquier tipo de aplicación. Todos los derechos están reservados Página 65 .5.Capital Federal Copyright 2005-A ctualldad. es posible utilizar el Enterprise Architect y guardar el proyecto en form ato .A nálisis y Diseño O rientado a O bjetos con UML y UP 12. y es una form a de almacenar los diagramas de UML en un form ato de texto basado en XML.xm l. El Lenguaje XMI XMI significa XML Metadata Interchange. Por ejemplo. para luego utilizar otra aplicación como Rational o PoseidonUML y poder abrir el proyecto sin inconvenientes.a r I Tel. w w w .e d u c a c io n lT . educaclonlT.4to Piso . (54) (011) 4328-0457 Lavalle 648 .c o m .

e d u c a c io n lT . y en su propuesta genérica se lo denom ina UP (Unified Process). tampoco define tiem pos ni coordinación entre los roles de los distintos trabajadores del sistema. fundada por Jacobson. educaclonIT.4to Piso . y no un fin. concentrando lo m ejor de cada uno. UML no es una metodología (como sí lo es UP) sino que es un lenguaje.a r I Tel. (54) (011) 4328-0457 Lavalle 648 . Jacobson trabajaba en la empresa Ericsson y tenia como principales tareas el análisis y diseño de sistemas de información. Se la conoce inicialm ente como RUP (Rational Unified Process). es una metodología orientada a la construcción de software. que luego compraría a Objectory para comenzar a marcar el camino para lo que luego se conocería como RUP. la experiencia obtenida en tareas sim ilares en su anterior w w w . Definición El Proceso Unificado de Desarrollo. El proyecto se desarrolla hasta el año 1996 de form a independiente. Todos los derechos están reservados Página 66 . Introducción al Proceso Unificado de Desarrollo de Software 13. que es la propuesta propietaria de la empresa Rational.A nálisis y Diseño O rientado a O bjetos con UML y UP 13. cuando decide independizarse y fundar Objectory para dedicarse a la investigación de una metodología que perm ita el desarrollo de sistemas. también conocido como UP.2. de manera organizada. y como alcanzar un objetivo. Es el proceso utilizado para guiar a los desarrolladores. Historia 13. El proceso Objectory La metodología RUP tiene una larga historia que nace en Objectory en el año 1987.2.1.1. Es posible definirlo como un proceso que define quien está haciendo que. cuando lo esta haciendo.c o m . 13. visualizar y modelar un sistema. utilizando toda empresa. Nace como la unión de distintas metodologías antes separadas por distintos autores. UML tiene como objetivo documentar. y no define quien realiza cada actividad. La diferencia radical con UML es que UML es un medio. presentando una gran evolución y captando la atención de la compañía Rational.Capital Federal Copyright 2005-A ctualldad.

y finalm ente construye la metodología denominada RUP. La necesidad de una metodología w w w . 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. testing. y comienza a comprar empresas que se encargaban de actividades puntuales y estaban bien desarrolladas en esos campos.4to Piso . que significa unificado ya que representa la unificación de todas las diferentes técnicas de desarrollo y de todas las metodologías utilizadas anteriorm ente • P de Process. gestión de configuración.1) Estos cambios fueron realizados entre los años 1996 y 1997. como ser gestión de requisitos. 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.3.2. etc.3. 13. correspondiente al proceso que indica paso a paso las tareas a realizar para cum plir un objetivo 13. correspondiente al nombre de la empresa U de U n ifie d . (54) (011) 4328-0457 Lavalle 648 .a r I Tel.2. versión 1. Entre los aspectos más im portantes.Capital Federal Copyright 2005-A ctualldad. educaclonlT.2.c o m . Establecieron las siglas RUP basándose en las siguientes ideas: « « ñ de R ational. El Proceso Unificado de Rational (RUP) En el año 1998 Rational decide expandirse en la búsqueda de una metodología genérica. Rational absorben toda la experiencia y conocimientos. 13.A nálisis y Diseño O rientado a O bjetos con UML y UP Objectory representaba el concepto de Object Factory (o fábrica de objetos). Todos los derechos están reservados Página 67 .e d u c a c io n lT .

a r I Tel. dirigiendo tareas para cada desabollador por separado y del equipo como un todo. Proporciona un marco genérico de trabajo. y los casos de uso definirán los objetivos y la dirección del trabajo en cada iteración. La arquitectura proporciona la estructura para las iteraciones que se realizaran durante el proceso de desarrollo para evolucionar y refinar el producto.e d u c a c io n lT . y utiliza como herram ienta visual al UML. 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érm inos de tiem po y su evolución correspondiente « maximice la productividad 13. Esta basado en tres aspectos claves: « « • está dirigido por casos de uso está centrado en una arquitectura es iterativo e increm ental Los tres conceptos tienen la misma im portancia. Todos los derechos están reservados Página 68 . Dirigido por Casos de Uso El Proceso Unificado de Desarrollo esta dirigido por el conjunto de casos de uso.4.A nálisis y Diseño O rientado a O bjetos con UML y UP En todo desarrollo de software es necesaria una metodología para coordinar a los trabajadores que forman parte del proyecto. Un caso de uso es una funcionalidad bien definida del sistema que proporciona al w w w . Resulta necesario un proceso que: « proporcione una guía para ordenar actividades de un equipo. para lograr que no se solapan tareas junto con el cum plim iento de objetivos en fechas panificadas • especifiquen los artefactos que deben desarrollarse.Capital Federal Copyright 2005-A ctualldad.4to Piso .c o m . 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 transform ar los requisitos de un usuario en un sistema de software. educaclonlT. (54) (011) 4328-0457 Lavalle 648 .1.

Todos los derechos están reservados Página 69 . 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 (m ulticapa. lo que debería hacer el sistema).c o m . el cual describe la funcionalidad integral del sistema. ya que estos deben "encajar" en la arquitectura. por una lado. Esto se debe a que una arquitectura tiene una relación directa con los casos de uso. y representan el punto de partida para la construcción de los casos de prueba (test cases).e d u c a c io n lT . 13. A medida que los casos de uso se especifican y se van retinando. el arquitecto de software debe comprender los casos de uso claves del sistema.) Para su definición. la arquitectura ira "m adurando".4to Piso . w w w . generalm ente se eligen entre el 5% al 10% del to ta l. Se utiliza la palabra "dirigido’ ya que los casos de uso sirven como h ilo c o n d u c to r del desarrollo del software. especificarlos y realizarlos en térm inos de subsistemas. orientados a servicios.2.Capital Federal Copyright 2005-A ctualldad. componentes y clases. siendo estos casos de uso los mas representativos del sistema o los que constituyen las funciones claves. y por el otro. esquem atizarla según los factores no dependientes de los casos de uso.A nálisis y Diseño O rientado a O bjetos con UML y UP usuario un resultado. Para definir una arquitectura es conveniente. Se utilizan para guiar el diseño y la implem entación.a r I Tel. educaclonlT. El conjunto de casos de usos constituyen el M odelo de Casos de Uso. (54) (011) 4328-0457 Lavalle 648 .4. trabajar con los casos de uso del sistema. Representa a los requisitos funcionales (es decir. Para evaluar la viabilidad técnica de los casos de uso sobre una arquitectura. 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 decir que la arquitectura debe perm itir el desarrollo normal de todos los casos de uso. etc. es donde el software sera ejecutado.

Diseño. Iterativo e incremental El Proceso Unificado de Desarrollo es iterativo e increm ental ya que divide a un proyecto en "m ini-proyectos". las distintas iteraciones sirven como un refinamiento de requisitos. (54) (011) 4328-0457 Lavalle 648 .c o m .a r I Tel.Capital Federal Copyright 2005-A ctualldad. también denominados iteraciones.3. construyéndola de tal manera que perm ita que el sistema de software evolucione. Se intenta planificar todas las iteraciones de la fase (o la mayor cantidad posible) y su correspondiente orden lógico.4to Piso . Todos los derechos están reservados Página 70 .4. El proyecto se estructura en cuatro grandes fases (presentadas a continuación) donde en cada fase se realizan una gran cantidad de iteraciones. como ser rendim iento. performance y velocidad de respuesta. es decir que cada iteración convierte un conjunto de casos de uso en código fuente. educaclonlT. Por cada iteración: « se identifican y especifican los casos de uso mas relevantes « se crea un diseño respetando la arquitectura « se im plem enta 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 com pletam ente desde el comienzo. luego Análisis. 13. w w w . Cada iteración deberá planificarse y ejecutarse en form a controlada. El objetivo es encontrar una arquitectura estable y escalable. Im plementación y Pruebas.e d u c a c io n lT .A nálisis y Diseño O rientado a O bjetos con UML y UP Una arquitectura debe satisfacer también a los requisitos no funcionales. basada en casos de uso bien especificados para m itigar el riesgo y logrando así en cada iteración un increm ento real del sistema. Una iteración comienza con la detección de los casos de uso (Requisitos).

Se debe realizar en form a w w w . Los hitos se utilizan para estimar tiem pos y recursos necesarios para la próxim a fase. Para completar una iteración es necesario llevar a cabo todos los flujos fundam entales de trabajo. (54) (011) 4328-0457 Lavalle 648 . presentados a continuación: « Requerimientos « Análisis y Diseño « I m plem en t ación « Testing « Configuración 13. identificando los riesgos mas im portantes.4to Piso .a r I Tel.e d u c a c io n lT . Se definen las funciones principales del sistema para los usuarios más representativos. y cada iteración está compuesta por flu jo s fu n d a m e n ta le s de tr a b a jo . En este punto se revén presupuestos.5. Todos los derechos están reservados Página 71 . debe ser corregida antes de pasar a la siguiente fase. Si se encuentra alguna deficiencia. Una iteración representa el conjunto de actividades que tienen como objetivo realizar un avance real y “ tangible" del sistema. donde se decide si se avanza a la fase siguiente.1. educaclonlT. el plan de proyecto y el costo del producto.Capital Federal Copyright 2005-A ctualldad. Fase de Inicio En la Fase de Inicio se genera una descripción del producto y se presenta el análisis del negocio. planificaciones y requisitos. Se suele reunir el personal técnico con el de gestión para hacer una evaluación de la situación.A nálisis y Diseño O rientado a O bjetos con UML y UP 13. Cada fase esta form ada por ite ra c io n e s .c o m . 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 term ina con un h ito . Sirven también para controlar el progreso con las planificaciones previam ente realizadas.5.

costos y recursos.5. 13.5. 13. A medida que se van detectando errores. w w w . Se comienza a pensar en una posible arquitectura y se planifica en detalle la Fase de Elaboración.A nálisis y Diseño O rientado a O bjetos con UML y UP aproxim ada una estimación del proyecto en cuanto a tiempos. educaclonlT.Capital Federal Copyright 2005-A ctualldad.c o m . Todos los derechos están reservados Página 72 .4to Piso . A esta altura la arquitectura ya es estable. (54) (011) 4328-0457 Lavalle 648 . El sistema final podría contener defectos (bugs) que se solucionarán en la próxim a fase: la fase de Transición.4.2. el sistema responderá por todos los casos de uso que han pactado entre la empresa y el cliente. Esta fase incluye también la capacitación a usuarios y se redactan form alm ente los manuales. los desarrolladores corrigen dichos defectos. Fase de Transición En la fase de Transición el producto se convierte en versión beta. Con la especificación de los casos de uso realizada se planifican las actividades y se estiman los recursos necesarios hasta la term inación del proyecto. 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.3. aunque puede incorporarse pequeñas mejoras.a r I Tel. En esta fase se construye el producto hasta convertirse en un sistema funcional. 13.e d u c a c io n lT .5. Al finalizar esta fase. Fase de Construcción En la fase de Construcción se utilizan la mayoría de los recursos. donde los usuarios experim entados prueban el producto en busca de defectos.

una duración y una fecha de salida. Construcción del Diagrama Construir el Diagrama de Clases utilizando el Enterprise Architect para modelar la estructura de la información presentada anteriom ente.e d u c a c io n lT . Caso de Estudio La línea aérea AirBus. a los pasajeros que han comprado su pasaje. 14.2. Debatir con el docente acerca de las clases a utilizar para seguir con los próxim os 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. Para esto se solicita: « Analizar. LABORATORIOS 14. educaclonlT.Diagrama de Clases 14. que tienen como principales características un destino. Todos los derechos están reservados Página 73 . Los aviones comerciales son explotados a través de diferentes vuelos. LABORATORIO #1 .c o m . aunque comparten el hangar con aviones privados que no forman parte de la compañía.1. un piloto.Capital Federal Copyright 2005-A ctualldad. una de las empresas más grandes del mundo en m ateria de transporte de pasajeros. Sus aviones estacionan periódicamente en hangares de los diferentes aeropuertos. se concentra principalm ente en el manejo de aviones comerciales.1. Estos aviones poseen una denominación y una capacidad que determ ina la cantidad de pasajeros que puedan abordar el avión. detectar e identificar las clases. un co piloto y por supuesto.1.a r I Tel. Los vuelos están organizados en salidas periódicas e incluyen en su tripulación a varias azafatas.4to Piso . (54) (011) 4328-0457 Lavalle 648 .A nálisis y Diseño O rientado a O bjetos con UML y UP 14. agregando navegabilidad y m ultiplicidad en sus extrem os « Relacionar las clases que considere necesario utilizando composición y agregación w w w .1.

Entre su flota de aviones. que son los siguientes: « Vuelo con destino a Buenos Aires.1. Caso de Estudio La línea aérea AirBus ha comenzado con sus actividades el día 0 1/01/1990. tiene fecha de salida el 20 de octubre y una duración de 180 m inutos « Vuelo con destino a San Pablo. Construcción del Diagrama Construir el Diagrama de Objetos utilizando el Enterprise Architect para modelar la estructura de la información presentada anteriorm ente. Este avión tiene asignados sus próxim os vuelos. tiene fecha de salida el 21 de noviembre y una duración de 220 m inutos « Vuelo con destino a Iguazu. se destaca el avión comercial denominado AirbusSOO. LABORATORIO #02 .2. Para esto se solicita: « Analizar.Diagrama de Objetos 14. Todos los derechos están reservados Página 74 .A nálisis y Diseño O rientado a O bjetos con UML y UP 14.e d u c a c io n lT . tiene fecha de salida el 22 de diciembre y una duración de 250 m inutos 14.4to Piso .2.c o m .2. educaclonlT.2. con capacidad para 150 pasajeros. 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 w w w .Capital Federal Copyright 2005-A ctualldad.a r I Tel. (54) (011) 4328-0457 Lavalle 648 .

En caso de estas dos ultim as. el horario de salida.4to Piso .3. (54) (011) 4328-0457 Lavalle 648 . En caso de ser extranjero le solicita también presentar la información de ingreso al país. de los cuales hay pasajeros nacionales como pasajeros extranjeros. Todos los derechos están reservados Página 75 .1. LABORATORIO #03 . Para esto se acerca al puesto de venta de la línea aérea y selecciona su pasaje. Finalmente. 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.a r I Tel. de la información presentada anteriorm ente. el pasajero recibe su pasaje. la clase en que quiere viajar (Turista. educaclonlT. la fecha de salida. Para finalizar. Para esto se solicita: • • « « Identificar actores De ser posible.3.Capital Federal Copyright 2005-A ctualldad. Una vez presentada la documentación.A nálisis y Diseño O rientado a O bjetos con UML y UP 14. con ta rje ta de crédito o ta rje ta de debito. Caso de Estudio El aeropuerto de Ezeiza recibe gran cantidad de pasajeros por día. deberá firm a r el com probante de pago. el pasajero presenta los descuentos que posee. Standard o Ejecutiva) y la ubicación dentro del avión.e d u c a c io n lT . que lo puede realizar en efectivo. La persona encargada de la venta chequea disponibilidad y si existe disponibilidad le solicita al pasajero presentar documentación personal como DNI y pasaporte.2. Una reducida cantidad de pasajeros decide adquirir su pasaje en el mom ento que arriba al aeropuerto. el pasajero debe pagar el pasaje. estableciendo previam ente el destino. 14.Diagrama de Casos de Uso 14. identificar relaciones de generalización entre actores Identificar casos de uso Relacionar los casos de uso con los actores correspondientes mediante asociación w w w . que generalm ente son descuento por m illaje o descuento empresarial.3.c o m .

Capital Federal Copyright 2005-A ctualldad.c o m .e d u c a c io n lT .a r I Tel. identificar relaciones de extensión entre casos de uso w w w .4to Piso .A nálisis y Diseño O rientado a O bjetos con UML y UP • Relacionar los casos de uso entre ellos con las relaciones de inclusión y generalización • De ser posible. Todos los derechos están reservados Página 76 . (54) (011) 4328-0457 Lavalle 648 . educaclonlT.

El 5% es cancelado previo a la fecha de partida.2. Todos los derechos están reservados Página 77 .Diagrama de Estados 14. 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. m otivo 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. 14.A nálisis y Diseño O rientado a O bjetos con UML y UP 14.c o m . Para esto los categoriza en validos e inválidos.4. ya que se intenta m onitorear cuantos pasajeros que compraron el pasaje no tomaron el vuelo. Caso de Estudio La línea aérea lleva un control interno muy estricto de los pasajes de cada vuelo.Capital Federal Copyright 2005-A ctualldad. y en el 95% de los casos luego son vendidos.a r I Tel. Dentro de la categoría validos. en este caso se le devuelve al pasajero un 85% de su valor y se pone en venta nuevamente. se contemplan los pasajes que fueron vendidos y que la fecha de partida del vuelo ya paso.e d u c a c io n lT .4to Piso . En prim era instancia son presentados dentro del sistema de adm inistración de pasajes como disponibles. (54) (011) 4328-0457 Lavalle 648 . educaclonlT.4. LABORATORIO #04 . reúne los pasajes que son validos para ser utilizados. Dentro de la categoría in v á lid o s . Los pasajes disponibles pueden ser reservados en form a telefónica o por internet. Para esto define el pasaje como utilizado (el pasajero tom o el vuelo) y como caducado (en pasajero no tom o el vuelo).41. que representan a los pasajes que están puestos a la venta. Para esto se solicita: • « • Identificar estados Arm ar una diagrama de prim er nivel con los estados mas generales Vincular los estados mas generales con diagramas de estados que contendrán los sub estados « Arm ar los diagramas de estados dependientes de los estados principales w w w . según la información presentada anteriorm ente.

e d u c a c io n lT .la cual deberá actualizar la disponibilidad en el vuelo y registrar la facturación . Una vez term inados todos estos pasos se realiza la venta del pasaje . según la información presentada anteriorm ente.5.y se entrega el pasaje al pasajero.Capital Federal Copyright 2005-A ctualldad. y se chequea si es extranjero.1. Construcción del Diagrama Construir el Diagrama de Actividades utilizando el Enterprise Architect para modelar las actividades del proceso de venta de un pasaje. se le pide adicionalmente la información declarada al ingresar al país.A nálisis y Diseño O rientado a O bjetos con UML y UP 14.5. en caso de tenerlos.a r I Tel. 14. Si hay disponibilidad en el vuelo se le solicita al pasajero el DNI y el pasaporte. Para esto se solicita: « « • Detectar actividades Detectar datastores Arm ar el diagram a correspondiente w w w . En caso de serlo. (54) (011) 4328-0457 Lavalle 648 . Caso de Estudio La línea aérea posee un sistema de venta de pasajes que utiliza en sus puestos de venta. se realiza el cálculo del precio final del pasaje incluyendo los descuentos. educaclonlT.5. Todos los derechos están reservados Página 78 .c o m .Diagrama de Actividades 14. Luego se solicitan los descuentos que. Para poder comenzar con el proceso de venta. LABORATORIO #05 .4to Piso . En caso de no haber lugar se inform a que el vuelo esta completo y se ofrecen al pasajero vuelos alternativos para que éste pueda volver a seleccionar un vuelo.2. es necesario seleccionar el vuelo y chequear su disponibilidad.

(54) (011) 4328-0457 Lavalle 648 . el pasajero obtendrá un descuento s Si la cantidad de pasajes a vender es mayor a 2. entre las diferentes ventanas que posee.Capital Federal Copyright 2005-A ctualldad.Diagrama de Secuencia 14.a r I Tel.4to Piso . LABORATORIO #06 .A nálisis y Diseño O rientado a O bjetos con UML y UP 14. Caso de Estudio La línea aérea posee un sistema de venta de pasajes que utiliza en sus puestos de venta.00 Mil ¡aje 752| (en millas) Clase Ejecutiva Cantidad de Pasajes 2 Vender Pasajes Es necesario identificar como se realiza la venta del pasaje desde un punto de vista interno al sistema. Dicho sistema. el pasajero obtendrá un descuento w w w .c o m .6. se encuentra la correspondiente a la de venta de pasajes.e d u c a c io n lT . la cual esta confeccionada de la siguiente manera: i Venia de Pasajes DNI Pasajero 22. teniendo en cuenta ciertas reglas de negocio: s Si el m illaje es > 0. el pasajero obtendrá un descuento s Si la clase es ejecutiva. educaclonlT.45S Vuelo Bs As Madrid :: 21/05/2007 :: 17.6. Todos los derechos están reservados Página 79 .56g.1.

educaclonlT.2.Capital Federal Copyright 2005-A ctualldad. según la información presentada anteriorm ente. Es necesario también registrar las ventas como parte de la facturación. y si se realiza posteriorm ente la venta habrá que actualizar la disponibilidad. 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. Todos los derechos están reservados Página 80 .A nálisis y Diseño O rientado a O bjetos con UML y UP Hay que tener en cuenta que al vender los pasajes se deberá chequear la disponibilidad de pasajes en el vuelo. detectar e identificar los objetos.a r I Tel. 14.e d u c a c io n lT .4to Piso . (54) (011) 4328-0457 Lavalle 648 .c o m . Debatir con el docente acerca de los objetos a utilizar para seguir con los próximos pasos « Arm ar 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 diagram a 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 w w w . Para esto se solicita: « Analizar.6.

Capital Federal Copyright 2005-A ctualldad.e d u c a c io n lT .Diagrama de Comunicación 14.7.4 5 8 Vuelo Bs As -Madrid ::2 1/05/2007:: 17.a r I Tel. Caso de Estudio El caso de estudio es el mismo que el realizado para el diagrama de Secuencia. La ventana utilizada es la siguiente: é Venia de Pasajes DNI Pasajern 2 2 . LABORATORIO # 0 7 .1.4to Piso .A nálisis y Diseño O rientado a O bjetos con UML y UP 14. (54) (011) 4328-0457 Lavalle 648 . Todos los derechos están reservados Página 81 .00 ▼ Millaje 752| (en millas) Clase Ejecutiva "V Cantidad de Pasajes 2 Vender Pasajes La diferencia radica en que se desarrollara un escenario que tiene las siguientes características: s El m illaje es 0 (es decir que no tiene m illaje) s La clase es ejecutiva.7. educaclonlT.c o m . con lo cual el pasajero obtendrá un descuento s La cantidad de pasajes a vender es dos s Se asume que al consultar si hay pasajes disponibles (a través del método consultarDisponibilidad() ) la respuesta será verdadera w w w .5 6 8 .

Todos los derechos están reservados Página 82 .4to Piso . según la información presentada anteriorm ente. 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.c o m . Para esto se solicita: • Arm ar el diagram a de colaboración secuencia previam ente realizado Reutilizar los objetos ya construidos en el diagram a anterior basándose en el diagrama se w w w . educaclonlT.2.e d u c a c io n lT .a r I Tel.A nálisis y Diseño O rientado a O bjetos con UML y UP 14.Capital Federal Copyright 2005-A ctualldad.7. (54) (011) 4328-0457 Lavalle 648 .

Cada uno de estos cursos tiene diferentes alternativas de fechas para cursar.XML »z LU o tí> O > t f> C /> < Patrones de diseñe Análisis y diseño orientado a objetos (UML y IIP) Z < w w w .Ja va scrip t K.e d u c a c io n lT . Im portante: ístos cursospueden ser asistidos en forma individual sin necesidad de realizar toda la carrera completa. las mismas están publicadas en el calendario del instituto. educaclonIT. Todos los derechos están reservados Página 83 .4to Piso . S O rie n ta d o r personas C O N 2 J A V A p a ra N O p ro g ra m a d o re s experiencia en programación en -algún lengu aie (WBasic. C ob o L etc) Orientado a Personas SIN e ip e rie n c ia en p ro g ra m a c ió n z O O o 3 Q O N G £ Z LU I íN' Hibernate Java Vtfeb Programming (J2EEr Servlets JSP. S truts] LU LU C N A JA X . El siguiente mapa expresa las correlatividades entre los distintos cursos. (54) (011) 4328-0457 Lavalle 648 .c o m .a r I Tel. C ." JSTL. Pascal.A nálisis y Diseño O rientado a O bjetos con UML y UP > MAPA DE LA CARRERA La carrera es un conjunto de cursos.Capital Federal Copyright 2005-A ctuaiidad.

Capital Federal Copyright 2005-Actualidad.A nálisis y Diseño O rientado a O bjetos con UML y UP > CURSOS RELACIONADOS JAVA SfANDARD ■PRINCIPIANTES 9" ■.c o m . O o o o = 3 "O w w w .a r I Tel. (54) (011) 4328-0457 Lavalle 648 . educacionIT. Todos los derechos están reservados Página 84 .4to Piso .e d u c a c io n lT .