UML y UP

A n lis is y Diseo O r ie n ta d o a O b je to s con UML y UP
1. INTRODUCCIN 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. INTRODUCCIN A LOS DIAGRAMAS DE UML.............__ ........__ ........__ ___ ___ ___ ___ ___ ..8 2.1. Introduccin.............................................................................................................................................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 Comunicacin................................................................................................................9 2.2.7. Diagrama de Secuencia.......................................................................................................................9 2.2.8. Diagrama de Componentes............................................................................................................... 10 2.2.9. Diagrama de Despliegue................................................................................................................... 10 2.3. Clasificacin...........................................................................................................................................11 2.3.1. Diagramas Estticos.......................................................................................................................... 11 2.3.2. Diagramas Dinmicos....................................................................................................................... 11 2.3.3. Diagramas Estructurales................................................................................................................... 12 2.3.4. Diagramas de Comportamiento........................................................................................................ 12 3. EL DIAGRAMA DE CLASES (CLASS DIAGRAM)________________________________________ 13 3.1. Definicin.................................................................................................................................................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. Generalizacin................................................................................................................................... 15 3.4.2. Asociacin.......................................................................................................................................... 16 3.4.3. Composicin....................................................................................................................................... 16 3.4.4. Agregacin......................................................................................................................................... 17 3.4.5. Implementacin o Realizacin........................................................................................................... 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. Representacin grafica...................................................................................................................... 19 3.6. Aplicacin................................................................................................................................................20 3.6. L Modelo de Anlisis o Modelo Conceptual........................................................................................ 20 3.6.2. Modelo de Diseo.............................................................................................................................. 20 3.6.3. Diseo de Base de Datos................................................................................................................... 21 3.7. Ejemplo ..................................................................................................................................................... 21 4. DIAGRAMA DE OBJETOS (OBJECT DIAGRAM)_____________ ___ ___ ___ .................................22 4.1. Definicin................................................................................................................................................. 22 4.2. Objetivo ....................................................................................................................................................22 4.3. Elementos................................................................................................................................................22 4.3.1. Objeto................................................................................................................................................. 22 4.4. Relaciones...............................................................................................................................................22 4.4.1. Vnculo............................................................................................................................................... 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 estn reservados
Pgina 1
4.4.2. Vnculo Direccional........................................................................................................................... 23 4.5. Aplicacin................................................................................................................................................23 4.5.1. Fotografa del sistema....................................................................................................................... 23 4.6. Ejemplo .....................................................................................................................................................24 5. DIAGRAMA DE CASOS DE USO_______________________________________________________ 25 5.1. Definicin................................................................................................................................................. 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. Asociacin.......................................................................................................................................... 26 5.4.2. Generalizacin................................................................................................................................... 27 5.4.3. Especializacin.................................................................................................................................. 27 5.4.4. Inclusin............................................................................................................................................. 28 5.4.5. Extensin............................................................................................................................................ 28 5.5. Aplicacin................................................................................................................................................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. Construccin de Casos de Prueba (Test Cases)............................................................................... 29 5.6. Ejemplo ..................................................................................................................................................... 30 6. DIAGRAMA DE ESTADOS.............__ ___ ___ ___ ___ ___ ___ ___ _____________________ ............31 6.1. Definicin.................................................................................................................................................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 Sincronizacin (Sync State).............................................................................................. 34 6.3.8. Estado Histrico (Shallow History State)......................................................................................... 34 6.3.9. Estado Histrico Profundo (Deep History State)............................................................................. 34 6.3.10. Fork.................................................................................................................................................. 35 6.3.11. Join................................................................................................................................................... 35 6.3.12. Unin (Junction).............................................................................................................................. 36 6.3.13. Decisin (Choice)............................................................................................................................ 36 6.4. Relaciones...............................................................................................................................................37 6.4.1. Transicin.......................................................................................................................................... 37 6.5. Aplicacin................................................................................................................................................37 6.5.1. Seguimiento de un objeto................................................................................................................... 37 6.6. Ejemplo ..................................................................................................................................................... 38 7. DIAGRAMA DE ACTIVIDADES________________________________________________________ 39 7.1. Definicin................................................................................................................................................. 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. Accin (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 estn reservados
Pgina 2
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. Seal de Envo (Send Signal)............................................................................................................. 41 7.3.10. Seal de Recepcin (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. Decisin (Choice)............................................................................................................................ 43 7.3.15. Particin (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 Interrupcin (Interrupt Flow)............................................................................................. 45 7.5. Aplicacin................................................................................................................................................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 COMUNICACIN (COMMUNICATION DIAGRAM)______________________48 8.1. Definicin.................................................................................................................................................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. Aplicacin................................................................................................................................................50 8.5.1. Realizacin de Casos de Uso en el Modelo de Anlisis...................................................................50 8.6. Ejemplo ..................................................................................................................................................... 51 9. DIAGRAMA DE SECUENCIA (SEQUENCE DIAGRAM)...__ ___ ___ ___ ___ ___ ___ ................... 52 9.1. Definicin................................................................................................................................................. 52 9.2. Objetivo ....................................................................................................................................................52 9.3. Elementos................................................................................................................................................52 9.3.1. Actor................................................................................................................................................... 52 9.3.2. Lnea 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. Aplicacin................................................................................................................................................53 9.5.1. Realizacin de Casos de Uso en el Modelo de Diseo.................................................................... 55 9.6. Ejemplo..................................................................................................................................................... 54 10. DIAGRAMA DE COMPONENTES_____________________________________________________ 55 10.1. Definicin...............................................................................................................................................55 10.2. Objetivo ..................................................................................................................................................55 10.3. Elementos..............................................................................................................................................55
Pgina 3
10.3.1. Componente.....................................................................................................................................55 10.3.2. Interfaz.............................................................................................................................................55 10.4. Relaciones.............................................................................................................................................56 10.4.1. Utilizacin (Use).............................................................................................................................. 56 10.4.2. Implementacin (Implementation)................................................................................................... 56 10.5. Aplicacin..............................................................................................................................................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. Definicin...............................................................................................................................................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 Ejecucin (Execution Environment)...........................................................................60 11.3.5. Especificacin de Despliegue (Deployment Spec)..........................................................................61 11.4. Relaciones.............................................................................................................................................61 11.4.1. Asociacin........................................................................................................................................ 61 11.4.2. Utilizacin (Use).............................................................................................................................. 61 11.4.3. Comunicacin (Communication Path)............................................................................................62 11.5. Aplicacin..............................................................................................................................................62 11.5.1. Definicin de la arquitectura de un sistema................................................................................... 62 11.6. Ejemplo................................................................................................................................................... 63 12. CONCEPTOS GENERALES...__ ...............................__ ___ ___ ...............................__ ..................... 64 12.1. Estereotipos..........................................................................................................................................64 12.2. Valor etiquetado (Tagged Vales) .................................................................................................64 12.3. Ingeniera Directa................................................................................................................................64 12.4. Ingeniera Inversa................................................................................................................................64 12.5. El Lenguaje XMI...................................................................................................................................65 13. INTRODUCCIN AL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE.....__ ___ 66 13.1. Definicin...............................................................................................................................................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 metodologa....................................................................................................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 Elaboracin............................................................................................................................. 72 13.5.3. Fase de Construccin...................................................................................................................... 72 13.5.4. Fase de Transicin........................................................................................................................... 72 14. LABORATORIOS............__ ........__ ........__ ........__ ........__ ........__ ___ ___ ___ ...__ ...................73 14.1. LABORATORIO #1 - Diagrama de Clases .......................................................................................73 14.1.1. Caso de Estudio............................................................................................................................... 73 14.1.2. Construccin del Diagrama............................................................................................................ 73 14.2. LABORATORIO #02 - Diagrama de Objetos ...................................................................................74
Pgina 4
14.2.1. Caso de Estudio................................................................................. 74 14.2.2. Construccin del Diagrama..................................................................... 74 14.3. LABORATORIO #03 - Diagrama Casos Uso..........................................................................75 14.3.1. Caso de Estudio................................................................................. 75 14.3.2. Construccin del Diagrama..................................................................... 75 14.4. LABORATORIO #04 - Diagrama de Estados...................................................................................77 14.4.1. Caso de Estudio................................................................................. 77 14.4.2. Construccin del Diagrama..................................................................... 77 14.5.LABORATORIO #05 - Diagrama de Actividades............................................................................78 14.5.1. Caso de Estudio................................................................................. 78 14.5.2. Construccin del Diagrama..................................................................... 78 14.6.LABORATORIO #06 - Diagrama de Secuencia...............................................................................79 14.6.1. Caso de Estudio................................................................................. 79 14.6.2. Construccin del Diagrama..................................................................... 80 14.7. LABORATORIO #07 - Diagrama Comunicacin........................................................................81 14.7.1. Caso de Estudio................................................................................. 81 14.7.2. Construccin del Diagrama..................................................................... 82
de de de
Pgina 5
1. Introduccin a UML
1.1. Qu es UML
UML es un lenguaje grfico que perm ite modelar, visualizar y documentar sistemas. Esta compuesto por distintos diagramas que permiten ir representando las distintas vistas de un sistema, cada diagrama tiene un objetivo bien definido. UML significa U n ifie d M o d e lin g L a n g u a g e o Lenguaje Unificado de Modelado, 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 semntica Esta U n ific a d o : unifica los distintos criterios utilizados antes de su
creacin, 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 construccin de modelos que
perm ite representar abstracciones de la realidad. UML esta estrechamente ligado con el paradigma de objetos, lo que permite construir sistemas de informacin de una form a mucho mas intuitiva, integrada y sencilla con el proceso de desarrollo. UML no es una m e to d o lo g a que presenta los pasos a seguir para realizar un desarrollo, sino que es un lenguaje grfico de modelado.
1.2. Que es un Modelo

Un modelo es una posibilidad de visualizar a escala o de una manera simulada algo que ser construido en la realidad. Es posible decir que antes de construir un edificio se realizan maquetas a escala que representa modelos a seguir, as como tambin cuando se construye un auto se confeccionan distintos planos o modelos a escala para intentar simular o prever su com portam iento. Acadmicamente, es posible definirla como una abstraccin de la realidad, es una simplificacin de la realidad, con el objetivo final de pasar del modelo a producto real.
Pgina 6
Los modelos pueden ser expresados en distintos niveles de precisin, desde algo muy genrico presentando una visin, hasta algo mucho mas especifico que representa un gran compromiso con el producto a construir.
1.3. Como nace UML

La historia cuenta que UML da sus prim eros pasos con al unin de los tres amigos : Booch, Rumbaugh y Jacobson. En los aos 80 cada uno utilizaba un lenguaje propietario aunque como
denom inador comn tenan como objetivo el desarrollo de sistemas, con previa modelizacion. A partir de los aos 90 comienzan a intercam biar ideas para intentar unificar criterios. Booch es el fundador de Rational Software Corp, y recluta en el ao 1995 a Rumbaugh y Jacobson para comenzar a determ inar una especificacin genrica, sencilla y abarcativa. As es como las grandes empresas de tecnologas de informacin - entre ellas Rational - deciden forman un consorcio para la construccin de un Lenguaje Unificado de Modelado: UML. La prim er versin de UML, la 1.0, sale a la luz en el ao 1997, y a partir de 1998 un organizacin llamada OMG (Object Management Group) se encargo de generar nuevas revisiones. En el ao 1998 UML se establece como Standard de tacto en la industria del Software.
1.4. Donde se utiliza

UML se utiliza dentro del marco de IT, aunque puede utilizarse en proyectos que no son de tecnologa de la informacin, como ser el modelado de un m otor o de una turbina. En el campo de IT, se utiliza tanto para sistemas monolticos como para sistemas distribuidos, abarca desde proyectos pequeos hasta grandes proyectos. Permite realizar la integracin del software, donde representa el correcto enlace de los roles para lograr el xito de la constriccin del sistema. En proyectos de software, es utilizado desde la gestacin hasta la instalacin y el testing. Si bien para utilizar UML es posible realizar los distintos diagramas con papel y lpiz, es conveniente contar con alguna herram ienta del tipo IDE que facilite su construccin, correccin e integracin ente diagramas.
Pgina 7
2. Introduccin a los diagramas de UML

2.1. Introduccin
UML esta organizado en una serie de diagramas que tienen objetivos bien definidos, con una sintaxis y semntica determ inada, que intentan representar / modelar distintas vistas de un sistema.
2.2. Los Diagrama de UML 2.2.1. Diagrama de Clases

El Diagrama de Clases tiene como objetivo 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 . Permite modelar la estructura del sistema desde un punto de vista esttico, modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto. Esta compuesto por clases, relaciones entre clases y opcionalm ente los paquetes que agrupan a las clases.
2.2.2. 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 . Permite representar al sistema en un mom ento determ inado del tiempo, es proporcional a obtener una fotografa o snapshot del sistema en un mom ento determ inado. Esta compuesto por objetos y relaciones de enlace. Tambin es posible pensarlo como una instancia de un Diagrama de Clases.
2.2.3. Diagrama de Casos de Uso

El Diagrama de Casos de Uso tiene como objetivo 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 . Representa las form as que tiene un usuario de utilizar un sistema, y se puede utilizar como un contrato" entre cliente y proveedor de software para determ inar la funcionalidad del sistema, es decir los requisitos funcionales. Esta compuesto por actores (agentes externos al sistemas, pueden ser usuarios u otros sistemas), casos de uso y distintos tipos de relaciones. Es posible construir diagramas con diferentes niveles de detalle.
Pgina 8
2.2.4. 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. Permite modelar tanto estas simples como compuestos y concurrentes. Esta compuesto por estados, pseudo-estados y transiciones entre estados.
2.2.5. Diagrama de Actividades

El Diagrama de Actividades tiene como objetivo 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 . Se utiliza principalm ente para modelar flujo de trabajo o workflow, con lo cual visualiza las acciones de manera ordenada. Esta compuesto por acciones simples y concurrentes, y transiciones entre las acciones.
2.2.6. Diagrama de Comunicacin

El Diagrama de Comunicacin 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 . Se lo suele llamar tam bin Diagrama de Colaboracin. Es posible verlo como una extensin del Diagrama de Objetos, ya que es muy parecido pero tiene como valor agregado los mensajes que se envan entre los objetos. Esta compuesto por objetos, relaciones de enlace y relaciones del tipo llamadas, representando que objeto se comunica con que otro. Es semnticamente equivalente al Diagrama de Secuencia.
2.2.7. 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 . Esta directam ente relacionado con el Diagrama de Comunicacin ya que el objetivo es el mismo, pero tiene la particularidad de estar obligatoriam ente ordenado en el tiem po. Esta compuesto por objetos y relaciones del tipo llamadas, representando que objeto se comunica con que otro. Es semnticamente equivalente al Diagrama de Comunicacin.
Pgina 9
2.2.8. 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 . Esta directam ente vinculado con el diseo del sistema, perm itiendo modelar las relaciones e interfaces que existen entre los componentes. Est orientado a la implementacin del sistema. Esta compuesto por componentes, interfaces y sus relaciones.
2.2.9. 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 . Es posible representar la arquitectura desde el punto de vista lgico, basndose en la organizacin del software, o desde una punto de vista fsico, representando directam ente cada unidad de hardware. Esta compuesto por nodos, componentes y sus relaciones.
Pgina 1 0
2.3. Clasificacin
Es posible clasificar a los diagramas segn si tienen alguna relacin con el tiempo o no. Existen dos posibles categoras, los diagramas estticos y los diagramas dinmicos.
2.3.1. Diagramas Estticos

Los D ia g ra m a s E s t tic o s son aquellos que no tienen ninguna relacin con el tiem po. Generalmente representan a estructuras o a posibles acciones pero sin una relacin directa con el tiempo. Estos diagramas son: Diagrama de Clases
Diagrama de Objetos Diagrama de Casos de Uso Diagrama de Componentes Diagrama de Despliegue
2.3.2. Diagramas Dinmicos

Los D iag ra m as D in m ic o s son aquellos que tienen relacin con el tiem po. Estn directam ente vinculados con acciones que ocurren bajo cierta secuencia, es decir prim ero una accin, luego otra, y as sucesivamente. Estos diagramas son: Diagrama de Actividades Diagramas de Interaccin (es una subcategora, que incluye a los
Diagramas de Secuencia y Comunicacin) Diagrama de Estado
Pgina 11
2.3.3. Diagramas Estructurales

Los D ia g ra m a s E s tru c tu ra le s son aquellos que reflejan relaciones estticas de una estructura. Estos diagramas son: Diagrama de Clases Diagrama de Objetos Diagrama de Componentes Diagrama de Despliegue
2.3.4. Diagramas de Comportamiento

Los D ia g ra m a s de C o m p o r ta m ie n to son aquellos que reflejan caractersticas de com portam iento del sistema o modelan procesos de negocios. Estos diagramas son: Diagrama de Casos de Uso Diagrama de Comunicacin Diagrama de Secuencia Diagrama de Actividades Diagrama de Estados
Pgina 12
3. El Diagrama de Clases (Class Diagram)

3.1. Definicin
El diagrama de clases es un diagram a que perm ite modelar la estructura del sistema desde un punto de vista esttico, modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto. Describe tipos de jerarquas, relaciones y abstracciones.
3.2. Objetivo
Describir las clases del dominio y sus relaciones.."
3.3. Elementos 3.3.1. Clase

Una clase representa a una agrupacin de cosas, es una plantilla para arm ar un objeto. Las clases son detectadas en la mayora de los casos - como
s u s ta n tiv o s en s in g u la r. Ejemplos de una clase puede ser la clase Auto, que es una clase representante de todos los autos posibles (autos de carrera, autos urbanos, cualquier marca, patente, color, etc.) Otro ejemplo puede ser la clase Animal, representando a todos los animales posibles (mamferos, herbvoros u otros, cualquier cantidad de patas, color, etc.) Las clases estn form adas por atributos y mtodos, y por convencin, la prim era letra debe estar en mayscula.
Que son los a t r i b u t o s

Los a t r i b u t o s son caractersticas que posee una clase, y determ inan el estado que posteriorm ente tendr un objeto En el caso de la clase Auto, atributos pueden ser color, marca, modelo, cantidad de puertas y velocidad. Por convencin, la prim era letra debe estar en minscula.
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. Generalmente los mtodos son verbos. Por convencin, la prim era letra debe estar en minscula.
Re p res en tac i n g r a f i c a de una clase
Pgina 13
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, de carcter muy general. Por ejemplo una institucin, que tiene los atributos direccin y superficie, pero no es posible determ inar que tipo de institucin es. Es una clase que no se puede instanciar, es decir que no se puede crear un objeto a partir de sta clase. Se utiliza como base para otras clases en la relacin de generalizacin, pero no tiene sentido por s sola. Las clases que no son abstractas se denominan c o n c re ta s . Por convencin, la prim era letra debe estar en mayscula, y la palabra en negrita e itlica.
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.3.2. Interfaz
A diferencia de la clase, la interfaz define nicamente un com portam iento, es decir un conjunto de mtodos que no poseen implem entacin. Estos
mtodos debern ser implem entados por las clases que decidan im plem entar la interfaz. Representa un "contrato que una clase debe respetar en caso de im plem entar la interfaz. Por ejemplo, se puede crear un interfaz denominada Volador, que tiene los mtodos despegar, aterrizar y volar.
w w w . e d u o a c io n lT . o o m . a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Pgina 14
rrtflr'acs
V otad or
+ + +
atenizarQ : vo.;a' de sp e g a r^ : void \faiar{) : v a d
Por convencin, para definir el nombre de una interfaz se aplican las mismas reglas que para una clase.
3.4. Relaciones 3.4.1. Generalizacin

La relacin de generalizacin se produce entre dos clases. La clase superior es una generalizacin de la clase inferior, como as tambin la clase inferior es una particularizacin de la clase superior. A la clase superior se la denomina su p e rc la s e , y a la clase inferior se la denom ina subclase. La subclase deber respetar la relacin es un" o is a , que representa a la relacin de generalizacin. Al construir varios relaciones de este tipo entre clases, se genera la jerarqua de clases (o rbol de clases). En trm inos de un lenguaje de programacin, es posible entenderla como herencia. Por ejemplo, la clase MedioDeTransporte puede ser una superclase, y algunas de sus subclases pueden ser Auto, Avin y Tren.
Pgina 15
3.4.2. Asociacin
La relacin de asociacin representa una asociacin entre dos clases, donde una clase es s o c ia de otra o tienen algn tipo de relacin. Es comn describir con un nombre definido por el usuario la relacin entre ambas. Por ejemplo, la clase Cuidador tiene una relacin con la clase Perro, donde Cuidador cuida al Perro. Es posible determ inar la multiplicidad de los extrem os de la relacin, en el caso anterior un cuidador cuida de uno a muchos perros.
Cui dador cuida
Perro
1. *
Existen dos relaciones denominadas Composicin y Agregacin que son casos particulares de la relacin de Asociacin.
3.4.3. Composicin
La relacin de composicin se puede describir como e st c o m p u e s ta p o r , ya que una clase determ ina la existencia de la otra. Si Clasel est compuesta por Clase2 entonces Clasel determ ina la existencia de Clase2. Clase2 no podr existir por si sola si no existe C lasel, es decir que Clasel controla el tiem po de vida de Clase2. Si la Clasel es eliminada, tambin ser eliminada Clase2, es decir que si se elimina el todo (C la s e l), tambin sern eliminadas sus partes (Clase2). UML denomina a la relacin como strong has-a relationship , representando un fuerte sentido de pertenencia del todo hacia la parte . Por ejemplo, un Auto e st c o m p u e s ta por un Carburador, con lo cual el
Carburador no tiene sentido por si solo si no existe el Auto. Dicho Carburador puede utilizarse nicamente para ese Auto, y no para otros, es decir que el mismo Carburador no puede utilizarse al mismo tiempo en ms de un Auto.
Copyright 2005-Actualidad, educacionIT. Todos los derechos estn reservados
Pgina 1 6
Otro ejemplo muy ilustrativo puede ser la relacin entre una Tabla y una Columna, donde la Columna es construida si la Tabla es construida, y la Columna es eliminada si la Tabla es eliminada.
3.4.4. Agregacin
La relacin de agregacin se puede describir como tie n e com o p a rte s a . A diferencia de la composicin, si Clasel tiene como partes a Clase2, Clasel no determ ina la existencia de Clase2. Clase2 puede existir an cuando Clasel no exista, es decir tiene sentido por si sola. Clasel no controla el tiempo de vida de Clase2. Si la Clasel es eliminada, puede no ser eliminada Clase2, es decir que si se elim ina el todo (C la sel), no necesariamente sern eliminadas sus partes (Clase2). UML denomina a la relacin como weak has-a relationship , representando un dbil sentido de pertenencia del todo hacia la parte . Por ejemplo, una OrdenDeCompra tie n e com o p a rte s a uno o muchos
Producto(s), pero si el Producto no form a parte de ninguna OrdenDeCompra, sigue teniendo sentido por si mismo. Si la OrdenDeCompra es eliminada, el Producto no ser eliminado.
O rd e n De Co m pra
P ro d u c to
-------------------------------------0 .." 0 .."
3.4.5. Implementacin o Realizacin

La relacin de implementacin se produce entre una clase y una interfaz. La clase que im plem enta la interfaz tiene la obligacin de Im plementar todos los mtodos que forman parte de esa interfaz. Por ejemplo, un Avin para saber volar deber implem entar un interfaz
denominada Volador, que incluye los mtodos despegar, aterrizar y volar.
Pgina 1 7
Esta relacin tambin se denomina realizacin.
3.5. Clases Estereotipadas 3.5.1. Que es un estereotipo de clase

El estereotipo representa la construccin de un nuevo elemento de UML que extiende a partir de uno ya existente, en el caso de las clases representa a una categora o un tipo nuevo de clases. Representa una funcionalidad determ inada, identificada por su nombre. El Proceso Unificado de Desarrollo (presentado mas adelante) utiliza tres
estereotipos de clases que se han estandarizado en el mercado, estos son Boundary, Control y Entity.
3.5.2. El estereotipo Boundary

El estereotipo B o u n d a r y se utiliza para representar clases que se encuentran en el lim ite (bound) del sistema. Estas clases representan a la interfaz de usuario dentro de un sistema, generalm ente implem entadas como ventanas. Se utilizan para capturar la interaccin entre el usuario y el sistema a nivel de pantalla. 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). En el patrn de diseo M-V-C representa a la vista.
3.5.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, son clases que llevan a cabo las reglas de negocios, realizando la coordinacin entre las clases del tipo Boundary y las clases del tipo actividades. Entity. Se encargan de la organizacin y planificacin de
w w w . e d u c a c io n lT . o o m . a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Pgina 18
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). En el patrn de diseo M-V-C representa al controlador.
3.5.4. El estereotipo Entity

El estereotipo E n tity se utiliza para almacenar o persistir informacin propia del sistema. 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). En el patrn de diseo M-V-C representa al modelo.
3.5.5. Representacin grafica
Pgina 1 9
3.6. Aplicacin 3.6.1. Modelo de Anlisis o Modelo Conceptual

Uno de los posibles usos del diagrama de clases es la construccin del denominado Modelo Conceptual. El modelo conceptual es uno o varios diagramas de clase construidos por un Analista Funcional que esta basado en la deteccin de clases (junto con sus atributos y posibles mtodos) y sus relaciones pero desde un punto de vista funcional, es decir dentro de la de la etapa de Anlisis. No se definen caractersticas propias de un lenguaje de programacin, sino que se intenta reflejar la realidad. En algunos casos se categorizar las clases como e ntity / controller / boundary, que son estereotipos de RUP (Racional Unified Process) presentados mas adelante. Adicionalmente, es posible utilizar una CRC Card (Class Responsability and Collaboration) para detallar el nombre de la clase, descripcin, atributos y
responsabilidades.
3.6.2. Modelo de Diseo

El modelo de diseo es el conjunto de diagramas de clases (puede ser uno solo) que se utiliza como base para realizar la codificacin de la aplicacin. El encargado de construirlo es el Diseador, y debe definir todo lo que sea necesario para que el desarrollador pueda codificar sin problemas. Toma como uno de ios documentos de entrada el correspondiente al Modelo de Anlisis, y se definen nuevas clases (en general las detectadas en Anlisis se m antienen) que tiene un perfil netamente de diseo y resuelven cuestiones tcnicas y ya no de negocios. A partir del Modelo de Diseo se genera el cdigo fuente de manera automtica que ser tomado como base por los desarrolladores. De esta manera el
program ador no tom a decisiones ni de Anlisis ni de Diseo, lo cual queda restringido a program ar en el cdigo recibido. El modelo tiende a evolucionar en la fase de construccin a travs de feed-backs que realizan los desarrolladores.
Pgina 20
3.6.3. Diseo de Base de Datos

El modelo de datos o diseo de una base de datos tambin es posible realizarlo a travs de un diagrama de clases. En este caso las clases representan las tablas y los atributos representan los campos. Para esto es necesario utilizar estereotipos (ver Seccin Conceptos Generales), 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 forneas, entre otros.
3.7. Ejemplo
Pgina 21
4. Diagrama de Objetos (Object Diagram)

4.1. Definicin
El Diagrama de Objetos perm ite representar el sistema en un m omento determ inado del tiem po, es similar a obtener una fotografa o snapshot del sistema en un m omento determ inado, y visualizar los objetos jun to con sus relaciones. Se suele utilizar como punto de partida para la construccin del Diagrama de Comunicacin o Colaboracin.
4.2. Objetivo
..describir los objetos del dominio y sus relaciones.."
4.3. Elementos 4.3.1. Objeto

El objeto representa una cosa en particular, es una instancia de una clase. Nace de utilizar una clase como plantilla y llenar sus atributos con valores. Los objetos dentro del diagrama dependen de algn tipo de clase, y pueden estar
estereotipados para una m ejor comprensin. Por convencin, la prim era letra debe estar en minscula y la palabra subrayada. Es comn agregar luego del nombre del objeto el nombre de la clase a la cual pertenece el objeto.
T o m a r Faneri : A lum no
utn :Uni v e rs i dad
4.4. Relaciones 4.4.1. Vnculo

Se utiliza para establecer algn tipo de relacin entre los objetos, no denota un tipo de relacin en particular sino simplemente un vinculo que no tiene direccin.
Pgina 22
A n lis is y Diseo O rie n ta d o a O b je to s con UML y UP
4.4.2. Vnculo Direccional

Se utiliza de la misma form a que el vnculo, pero tiene como valor agregado que permite entender m ejor la relacin, determ inar la navegabilidad de la misma.
4.5. Aplicacin 4.5.1. Fotografa del sistema

Este diagrama es el menos utilizado de todos los diagramas ya que no representa relevancia sobre ninguna vista posible del sistema. Su uso mas frecuente es la posibilidad de visualizar el sistema en un determinado momento, estudiando que objetos estn instanciados y la relacin entre los mismos.
Copyright 2005-A ctualldad, educaclonIT. Todos los derechos estn reservadas
Pgina 23
4.6. Ejemplo
Pgina 24
5. Diagrama de Casos de Uso

5.1. Definicin
El Diagrama de Casos de Uso representa las form as que tiene un usuario de utilizar un sistema, y esta directam ente asociado con el que debe hacer un sistema, y no "como debe hacerlo . Visualiza de form a directa los requisitos funcionales de un sistema, es decir como ei sistema debera funcionar, es por esta razn que se utiliza para guiar el diseo y el desarrollo. Todo el proceso de desarrollo de software (anlisis, diseo, testing, etc) son dirigidos por los casos de uso, donde un cambio en un caso de uso impacta en gran parte del proceso de desarrollo. Es im portante aclarar que no perm ite modelar workflow ni visualizar como se desarrollan las acciones detrs de los casos de uso. Adicionalmente, es posible construir diagramas con diferentes niveles de detalle.
Requi si to Funci onal

Los requisitos funcionales determ inan el funcionam iento del sistema, son aquellos que especifican el que debe hacer el sistema, representa a las reglas de negocio. Por ejemplo, el sistema debe adm inistrar clientes , realizar cobros , em itir facturas , etc.
Requisi to No Funci onal

Los requisitos no funcionales son aquellos que no determ inan la funcionalidad del sistema, aunque pueden influir sobre la misma. Son requisitos no funcionales la velocidad de respuesta, el rendim iento,
exactitud, el hardware a utilizar, etc. Por ejemplo, en el caso de estar operando con un cajero autom tico, el caso de uso "sacar dinero puede tener asociado un requisito no funcional
velocidad de repuesta, donde especifique que el cliente no debe esperar mas de 1 segundo para realizar la transaccin.
5.2. Objetivo
..describir las acciones del sistema desde el punto de vista del usuario..M
Pgina 25
5.3. Elementos 5.3.1. Actor

El actor representa una entidad externa al sistema que utiliza el sistema. Generalmente son usuarios, aunque tambin podra ser otro sistema. Participa en un caso de uso (o ms) con el propsito de cumplir su objetivo, definiendo el rol que un usuario del sistema va a asumir cuando est en funcionam iento. El conjunto de todos los actores representar todas las form as de comunicacin de una entidad externa con el sistema.
A cto r
5.3.2. Caso de Uso (Use Case)

El caso de uso es la interaccin que existe entre un actor y el sistema, representa un form a de utilizar el sistema. Es posible entenderla como una unidad de funcionalidad expresada como una transaccin entre un actor y el sistema. Un caso de uso puede ser descrito en trm inos de casos de uso ms simples, pudiendo un caso de uso detallarse desde el punto de vista del usuario como un Diagrama de Casos de Uso.
5.4. Relaciones 5.4.1. Asociacin
Pgina 26
La relacin de Asociacin es una lnea de comunicacin entre un actor y el caso de uso de uso en el que participa.
5.4.2. Generalizacin
La relacin de Generalizacin representa a un elemento que es general, y a otro elemento que tiene la base del elemento general, pero como valor agregado tiene algunas particularidades. Por ejemplo, el elemento2 tom a como base al e le m e n to l, con lo cual el elemento2 tiene como mnimo lo que tiene el elemento 1, y aparte agrega otras cosas. Se dice que el elem entol es una g e n e r a liz a c i n del elemento2, y el elemento2 es una esp e cia liza ci n del ele m e n tol. Esta relacin puede darse tanto entre actores como entre casos de uso.
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.4.3. Especializacin
Pgina 27
La
relacin
de
Especializacin
es
la
relacin
inversa
la
relacin
de
Generalizacin. Segn el ejemplo anterior, abrir cuenta es una g e n e r a liz a c i n de abrir cuenta corriente , pero tambin e sp e cia liza ci n de abrir cuenta . Se maneja bajo el mismo criterio que la generalizacin, con lo cual tambin es aplicable a actores. abrir cuenta corriente es una
5.4.4. Inclusin
La relacin de Inclusin representa que un caso de uso esta incluido en otro caso de uso base, donde el caso de uso incluido es parte del caso de uso base. Por ejemplo, el caso de uso abrir cuenta incluye a los casos de uso registrar datos y depositar fondos , ya que al abrir un cuenta en un banco es necesario registrarse y depositar fondos en la cuenta.
a b rir cuenta
^ -include
5 -n
\
re g is tra r da tos
/
* i n el u d e
------
*-v J
j d e p o sita r fo n d o s
5.4.5. Extensin
La relacin de Extensin se utiliza entre dos casos de uso, cuando un caso de uso incluye al otro pero opcionalmente. Por ejemplo, el caso de uso entregar pasaporte es una extensin del caso de uso abrir cuenta , ya que solo ser solicitado entregar el pasaporte a aquellas personas que sean extranjeros y quieran abrir una cuenta.
Pgina 28
5.5. Aplicacin 5.5.1. Captura de Requisitos Funcionales

La form a estndar de captura de requisitos funciones son los Diagrama de Casos de Uso. Esto se debe a que es una form a sencilla, sistemtico e intuitiva, fcil de leer por cualquier persona que form a parte de un proyecto, incluyendo al cliente mismo.
5.5.2. Modelo de Casos de Uso

El modelo de casos de uso es el conjunto de todos los diagramas de casos de uso que form an parte del sistema. En este artefacto quedan documentados todos los requisitos funcionales que deber satisfacer el sistema, y se utiliza como la documentacin que detalle la funcionalidad del sistema. El sistema no podr tener ms ni menos funcionalidad que la especificada en este documento.
5.5.3. Establecimiento de contratos

Dependiendo de la envergadura del sistema, los casos de uso sirven como una 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). Se suelen establecer contratos en base a los casos de uso, donde cliente y proveedor se comprometen a que el sistema debe tener la funcionalidad
especificada en los casos de uso que forman parte del contrato. De esta manera se evitan "m alentendidos acerca de las funcionalidades que estn incluidas de las que no estn incluidas.
5.5.4. Construccin de Casos de Prueba (Test Cases)

Los casos de prueba son necesarios en todo sistema para poder realizar el testing de la aplicacin, y as asegurar la calidad del producto desde el punto de vista funcional, es decir asegurar que lo que tiene que hacer el sistema, lo esta haciendo correctam ente. Los casos de uso se utilizan como punto de partida para los casos de prueba, ya que los casos de prueba son los casos de uso con algunos agregados adicionales como casos especiales a testear.
Pgina 29
5.6. Ejemplo
Pgina 30
6. Diagrama de Estados
6.1. Definicin
El Diagrama de Estados perm ite visualizar los cambios de com portam iento de un objeto a partir de sus transiciones. Se lo conoce tambin como Maquina de Estados.
6.2. Objetivo
...describir los estados por los cuales puede pasar un objeto durante su ciclo de vida..."
6.3. Elementos 6.3.1. Estado (State)

El estado corresponde generalm ente a un objeto, y representa el conjunto de valores que tiene ese objeto en un determ inado momento. Describe un periodo de tiempo durante el ciclo de vida del objeto. El com portam iento interior de un estado es posible modelarlo con un Diagrama de Actividad, que visualiza las acciones que ocurren cuando un objeto entra en ese estado.
t* d o
6.3.2. Estado compuesto (Sub-machine State)

El estado compuesto es un estado que contiene sub-estados. Es posible modelar los sub-estados dentro del estado compuesto, o en un diagrama de estados aparte. Si se modela el estado compuesto como una caja negra que esta desarrollada en un diagrama aparte, su representacin grafica es la siguiente:
Pgina 31
s ia d * com puesto
Si se modela el estado compuesto como un conjunto de sub-estados visibles, su representacin grafica es la siguiente:
oslado1
6.3.3. Pseudo-Estado Inicial (Initial State)

El pseudo estado inicial representa el comienzo de las transiciones de los posibles estados.
p seu d o -astad o in ic ia l
6.3.4. Pseudo-Estado Final (Final State)
Copyright 2005-A ctuaiidad, educaclonIT. Todos los derechos estn reservados
Pgina 32
El pseudo estado final representa el final esperado de las transiciones de los posibles estados.
estado 1
V
ii d i>
ps-jijd
>
J
esta do fin a l
6.3.5. Punto de Entrada (Entry Point)

El punto de entrada es utilizado en estados compuestos, y representa el punto de entrada al estado compuesto desde el exterior.
6.3.6. Punto de Salida (Exit Point)

El punto de salida es utilizado en sub estados o estados compuestos, y representa el punto de salida del sub estado o estado compuesto desde el interior.
Pgina 33
6.3.7. Estado de Sincronizacin (Sync State)

El estado de sincronizacin indica que los caminos concurrentes que pasen por este estado sern sincronizados.
tid o de sincr#nizjcln
6.3.8. Estado Histrico (Shallow History State)

El estado histrico se utiliza para representar el estado activo (o sub-estado) mas reciente de un estado compuesto, aunque no tiene la capacidad para representar el estado activo de un posible sub-estado (si existiera) del sub-estado del estado compuesto.
6.3.9. Estado Histrico Profundo (Deep History State)

Pgina 34
El estado histrico profundo se utiliza para representar el estado activo (o subestado) mas reciente de un estado compuesto, y adems tiene la capacidad para representar el estado activo de un posible sub-estado (si existiera) del subestado del estado compuesto, es decir que almacena el histrico de todos los estados activos en form a recursiva.
6.3.10. Fork
El fork es un pseudo estado que se utiliza para separar una transicin de entrada en dos transiciones concurrentes que tienen como destino diferentes estados.
6.3.11. Join
El join es el proceso inverso al fork, es un pseudo estado que se utiliza para unir dos transiciones de entrada concurrentes en una nica transicin de salida.
Pgina 35
6.3.12. Unin (Junction)

La unin es un pseudo estado que se utiliza para unir m ltiples caminos en otros caminos que pueden ser compartidos, o tambin para separar un camino en varios caminos alternativos. Se suelen agregar guardas a las transiciones para especificar una condicin para la transicin, si el resultado de la condicin es negativo entonces no se produce esa transicin.
6.3.13. Decisin (Choice)

La decisin indica un condicional en el progreso: si la condicin es verdadera tom a un camino, y si es falsa tom a el camino alternativo.
Pgina 36
6.4. Relaciones 6.4.1. Transicin

La transicin es una ocurrencia en el tiempo, sin una determ inada duracin. Representa la form a de vincular estado, y es el medio en que un estado pasa a otro estado. En form a opcional, es posible especificar un evento disparador (trigger) que inicia la transicin de un estado a otro.
it a d o l evento
=rt=do2
6.5. Aplicacin 6.5.1. Seguimiento de un objeto

El Diagrama de Estados se utiliza generalm ente para hacer un seguimiento fino de un objeto en particular, cuando el foco del negocio requiere hacer nfasis en las transiciones de ese objeto. Adicionalmente, se utilizan para ayudar al
desabollador a entender funcionalidades complejas o algn proceso de negocio especializado en una rea determinada. Es im portante destacar que un Diagrama de Estados no es un diagrama
m ayorm ente utilizado, se utiliza nicamente para casos puntuales.
Pgina 37
6.6. Ejemplo
Se modelo a continuacin los estados posibles de un alumno de una universidad.
El estado compuesto inscripto" desarrollado en otro diagrama queda de la siguiente manera:
Pgina 38
7. Diagrama de Actividades
7.1. Definicin
El Diagrama de Actividad se utiliza principalm ente para modelar flujo de trabajo o w orkflow, visualizando las acciones de manera ordenada. Permite modelar
procesos y comprender la ejecucin general de un sistema, localizndose en la secuencia de acciones y condiciones necesarias para su ejecucin.
7.2. Objetivo
...describir la acciones que ocurren dentro de un proceso..."
7.3. Elementos 7.3.1. Actividad (Activity)

Una actividad refleja el control de flujo y de datos de un proceso, y puede incluir la participacin de sub-actividades y/o acciones. Generalmente representa a una unidad funcional dentro de una actividad mayor o de un proceso.
a c tiv id a d
7.3.2. Actividad Estructurada (Structured Activity)

La actividad estructurada es una actividad que visualiza de manera explcita que esta compuesto por un conjunto de actividades u acciones.
a c tiv id a d estru ctu ra d a
7.3.3. Accin (Action)

La accin es la unidad funcional bsica dentro de un diagrama de actividades, y representa la transform acin que ocurre dentro del sistema. La diferencia
principal con las actividades radica en que la accin no puede descomponerse,
Pgina 39
m ientras acciones.
que
una
actividad
puede
descomponerse
en
sub-actividades y/o
7.3.4. Objeto (Object)

El objeto tiene el mismo significado que el presentado para los diagramas anteriores, en este caso adicionalmente representa que un objeto es construido, modificado o consultado luego de una actividad.
o b je to
7.3.5. Datastore Object

El datastore es un objeto que se utilice para modelar la persistencia de informacin permanente. Se puede utilizar tanto para almacenar informacin como para consultar informacin.
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
<< transform aron A l man ce na el item
7.3.6. Central Buffer Node

El buffer tiene el mismo significado que el datastore, pero se utiliza para almacenar informacin tem poralm ente (informacin no persistente o transitoria).
Pgina 40
a c c i n
fu e n te
a c c i n
j ----------r i
d e stin o
7.3.7. Pseudo-Estado Inicial (Initial State)

El pseudo estado inicial representa el comienzo de los flujos entre las acciones.
7.3.8. Pseudo-Estado Final (Final State)

El pseudo estado inicial representa el final de los flujos entre las acciones.
7.3.9. Seal de Envo (Send Signal)

La seal de envo se utiliza para representar que se esta enviando un objeto en form a de seal hacia algn destino no necesariamente representado en el diagrama. En el siguiente ejemplo, la seal de envo se utiliza para notificar al proveedor acerca de la creacin de un pedido, donde es enviado el objeto pedido al proveedor.
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.3.10. Seal de Recepcin (Receive Signal)

La seal de recepcin se utiliza para representar la recepcin y/o aceptacin de un pedido. Existen dos tipos de seales de recepcin.
Pgina 41
A nlisis y Diseo O rientado a O bjetos con UML y UP
Accept Event Action

Esta seal se utiliza para determ inar la recepcin de un evento por parte de terceros. Si se utiliza en conjunto con la seal de envo, establece que el flujo continuara normalmente una vez que se produzca la seal de
respuesta.
Accept Time Event Act ion

Esta seal se utiliza para representar el pasaje del tiem po, es una accin que espera la ocurrencia de un evento del tipo tiempo, por ejemplo comienzo de un mes, finalizacin del mes, comienzo del da, etc.
comienzo
de mes
7.3.11. 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 excepcin (o se haya producido algn error).
r f
excepti on Handl er
7.3.12. Fork
w w w .e d u cacionIT .com .ar | Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
C opyright 2005-Actualidad, educacionIT. Todos los derechos estn reservados
Pgina 42
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.
7.3.13. Join
El join es el proceso inverso al fork, es un pseudo estado que se utiliza para unir dos flu jo s de entrada concurrentes en un nico flujo de salida.
7.3.14. Decisin (Choice)

La decisin indica un condicional en el progreso: si la condicin es verdadera tom a un camino, y si es falsa tom a el camino alternativo.
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
Pgina 43
7.3.15. Particin (Partition)

La particin se utiliza para establecer responsabilidades en las acciones o actividades. Determina que o quien realiza cada actividad. Son de uso opcional, y permiten estructurar la vista o las partes de la actividad, realizando una separacin lgica. Tambin son denominadas swimlaes.
7.4. Relaciones 7.4.1. Flujo decontrol (Control Flow)

El flu jo de control es un conector que une dos actividades o acciones, una inicial y una final, determ inado por una direccin. Una vez que la accin inicial es completada, el control pasa a la accin siguiente.
Pgina 44
Es posible definir una guarda que representa una condicin que debe cumplir la accin inicial para pasar a la prxim a accin.
7.4.2. Flujo de objeto (Object Flow)

El flujo de objeto conecta una actividad con un objeto, representando un flujo de informacin de la actividad al objeto.
7.4.3. Flujo de objeto con Pines (Pinned Object Flow)

El flujo de objeto con distincin es semnticamente igual al flujo de objeto tradicional, la diferencia radica en la form a de graficarlo, ya que de esta manera resulta mas compacto.
a c c io n l
^----------------- pin salida
> i __ f I pin entrada
accion 1
J
7.4.4. Flujo de Interrupcin (Interrupt Flow)

El flujo de interrupcin representa una interrupcin debido a una ocurrencia inesperada en alguna accin o actividad.
7.5. Aplicacin 7.5.1. Desarrollo de aplicaciones procedurales

Uno de los posibles usos que tiene el Diagrama de Actividades es la posibilidad de realizar el flujo de aplicaciones de tipo procedural, al estilo diagramas de jackson, donde se pueden representar las sentencias (acciones) junto con las estructuras
Pgina 45
de
control
de
flujo
utilizando
las
decisiones,
forks,
joins
actividades
estructuradas para representar llamadas a cajas negras o procedimientos.
7.5.2. Modelado de procesos de negocio - Workflow

El uso mas comn del Diagrama de Actividades es la representacin de flujos de trabajo o procesos de negocio. Es posible modelar como arranca un proceso, a partir de quien o en que rea se produce, y visualizar la transform acin de informacin que va ocurriendo durante todo el proceso. En este contexto los eventos generalm ente se originan dentro del sistema al finalizar las diferentes acciones, o tambin fuera del sistema a travs de seales de recepcin (por ejemplo, el proveedor entrego la mercadera) y a travs de eventos correspondientes al tiem po (por ejemplo, paso un mes).
Pgina 46
7.6. Ejemplo
Pgina 47
8. Diagrama de Comunicacin (Communication Diagram)

8.1. Definicin
El Diagrama de Colaboracin modela los objetos jun to con sus interacciones para visualizar como se lleva a cabo una tarea, modelando nicamente la interaccin entre los objetos que realizan esa tarea en particular. Se lo suele llamar tambin Diagrama de Comunicacin. Es posible verlo como una extensin del Diagrama de Objetos, ya que es muy parecido pero tiene como valor agregado los mensajes que se envan entre los objetos. Es uno del Diagrama de Diagrama de Secuencia Interaccin, y semnticamente es equivalente al
8.2. Objetivo
..Describir como colaboran o se comunican los distintos objetos entre s para conseguir un objetivo..."

El actor es una entidad externa al sistema que dispara el comienzo de la interaccin entre los objetos. La aparicin 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
Pgina 48
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 relacin que se utiliza en el Diagrama de Objetos.
8.4.2. Vinculo Direccional

Es la misma relacin 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 conversacin . Existen dos tipo de mensajes a enviar: los mensajes sincrnicos y los mensajes asincrnicos.
Me nsaj e Si ncrni co
El objeto origen enva un mensaje al objeto destino y espera a recibir una respuesta. Una vez recibida la respuesta, sigue con su tarea. El mensaje sincrnico se modela con una fecha de punta rellena.
Pgina 49
Me ns aj e A s in c r n i c o
El objeto origen enva un mensaje al objeto destino y no espera recibir respuesta, sigue con su tarea. El mensaje sincrnico se modela con una fecha de punta no rellena.
8.5. Aplicacin 8.5.1. Realizacin deCasos de Uso en el Modelo de Anlisis

Es muy comn utilizar los Diagramas de Comunicacin para visualizar la realizacin de un caso de uso. Por ejemplo, el caso de uso registrar usuario representa una accin que realiza un usuario en un sistema, y si es necesario documentar lo que ocurre detrs del registrar usuario , se utiliza este diagrama para visualizar la interaccin entre los objetos para alcanzar el objetivo de la registracin. Generalmente se utilizan o b je to s de anlisis, donde el objetivo es visualizar la interaccin de objetos a nivel negocio, no a nivel tcnico o a nivel diseo.
Pgina 50
8.6. Ejemplo
I n t e r f jz S a lid a
Pgina 51
9. Diagrama de Secuencia (Sequence Diagram)

9.1. Definicin
El Diagrama de Secuencia se utiliza para representar la interaccin de objetos a lo largo del tiem po, por eso es semnticamente igual al diagrama de
Comunicacin, aunque con algunas variantes desde el punto de vista sintctico. Esta basado en la utilizacin de un eje vertical im aginario que representa el paso del tiem po. A diferencia del Diagrama de Comunicacin, pone mayor nfasis en la interaccin entre objetos a travs del tiem po y no m uestra la relacin entre objetos que no sea a travs de mensajes.
9.2. Objetivo
...describir como colaboran los distintos objetos entre s para conseguir un objetivo a lo largo del tiempo .. .

Es el mismo elemento que se utiliza en el Diagrama de Comunicacin
9.3.2. Lnea de vida (LifeLine)

La lnea de vida representa desde el nacimiento del objeto hasta su destruccin. Este representada con una lnea vertical punteada.
cb je to l
9.3.3. Boundary
Pgina 52
9.3.4. Control
9.3.5. Entity
9.4. Relaciones 9.4.1. Mensaje

Es la misma relacin que se utiliza en el Diagrama de Comunicacin. Tambin se utilizan los mensajes sincrnicos y los asincrnicos.
9.5. Aplicacin 9.5.1. Realizacin de Casos de Uso en el Modelo de Diseo

Es muy comn utilizar los Diagramas de Secuencia para visualizar la realizacin de un caso de uso. Por ejemplo, el caso de uso registrar usuario representa una accin que realiza un usuario en un sistema, y si es necesario documentar lo que ocurre detrs del registrar usuario , se utiliza este diagrama para visualizar la interaccin entre los objetos para alcanzar el objetivo de la registracin. Generalmente se utilizan o b je to s de diseo, donde el objetivo es visualizar la interaccin de objetos a nivel tcnico, con un mayor nivel de detalle, que luego utilizar un desabollador para im plem entar el sistema.
Pgina 53
9.6. Ejemplo
$ A
U suaria
O
Irv trfa z R e s si ra c i n
O&storReg retracten
Adminislrad&rDeCori&xiones
I
registrnj
Copyright 2005-A ctualldad, educaclorIT. Todos los derechos estn reservados
Pgina 54
10. Diagrama de Componentes

10.1. Definicin
El Diagrama de Componentes perm ite modelar las relaciones e interfaces que existen entre distintos componentes que conformaran el sistema. Esta
directam ente vinculado con el diseo, y se utiliza como base para el desarrollo de la implementacin del sistema.
10.2. Objetivo
...describir la relacin que existe entre los distintos componentes del sistema..."
10.3. Elementos 10.3.1. Componente

Un componente representa a una porcin del software, es una parte lgica de un sistema que envuelve una implem entacin. Un componente puede ser muy pequeo, y pueden haber otros mas grandes que agrupen a los mas pequeos. En su interior, generalm ente contienen clases. Puede estar representado como un archivo de cdigo fuente, un archivo .dII en Windows o un archivo .jar en Java. Dentro del enfoque de UML, un componente puede tener en su interior Diagramas de Comunicacin, Secuencia, Actividades y Estados.
com ponente
10.3.2. Interfaz
La interfaz es una especificacin de com portam iento, un protocolo de com portam iento, que los implem entadores que la utilizan estn comprometidos a respetar. Se puede entender como un contrato entre las partes. Una interfaz, en su aspecto mas bsico, contiene un conjunto de mtodos sin implem entar.
Pgina 55
Existen dos form as de representar una interfaz, una form a completa que expresa los mtodos que agrupa junto con su nombre, y una form a ms sencilla que representa a travs de un icono la interfaz solo con su nombre.
i nte rfa t
inerfaz
fltfWZ
10.4. Relaciones 10.4.1. Utilizacin (Use)

La relacin de utilizacin puede existir entre componentes, esta fundam entada en un componente que utiliza a un segundo componente para llevar a cabo su funcionalidad. La relacin esta form ada por: un proveedor (supper) que proveer servicios y/o informacin un cliente (client) que utilizar dichos servicios y/o informacin
Es necesario tener especial cuidado sobre los proveedores, ya que un cambio en el proveedor podra afectar el normal funcionamiento del cliente.
c o n s u m id o r
............. - >
p ro ve e d o r
10.4.2. Implementation (Implementation)

La relacin se puede visualizar de dos form as distintas, dependiendo de como se representa la interfaz. Tambin se denomina a esta relacin como Realizacin.
Pgina 56
c o m p o n e n te
a
r e a liz a
n te rr'a c e . . i- - . ntarF& z
com ponente
re a liz e
nterfaz
10.5. Aplicacin 10.5.1. Modelado de un Sistema

El Diagrama de Componentes puede ser utilizado para modelar un sistema si se utilizan los grandes componentes del sistema, llamados mdulos. De esta manera se puede construir un diagrama que visualice la relacin existente entre los mdulos, por ejemplo la posible relacin entre los mdulos de compras, ventas, adm inistracin de productos, stock, etc., y sus posibles interfaces, estableciendo proveedores y "clientes bien definidos, y definiendo una organizacin en trm inos generales de un sistema.
10.5.2. Modelado de un Modulo

El Diagrama de Componentes puede ser utilizado con un mayor nivel de detalle, especificando posibles componentes que conforman un modulo. De esta manera es posible modelar las porciones de software a utilizar dentro de una caja negra (o modulo) y establecer desde el punto de vista diseo como conviene hacerlos cooperar para lograr los objetivos del modulo.
Pgina 57
10.6. Ejemplo
J Ses/O ites D e U suaao
V en rtas
a
(ETcrpiarfor o : re a liza
A
le a liz e
Ventas
w w w .e d u o a c io n lT .o o m .a r I Tel. (54) (011) 4328-0457 Lavalle 648 - 4to Piso - Capital Federal
Pgina 58
11. Diagrama de Despliegue

11.1. Definicin
El Diagrama de Despliegue representa la arquitectura desde el punto de vista lgico, basndose en la organizacin del software, o desde una punto de vista fsico, representando directam ente cada unidad de hardware.
11.2. Objetivo
"...describir la arquitectura de un sistema..."
11.3. Elementos 11.3.1. Nodo (Node)

El nodo es una unidad que representa a un recurso computacional, donde puede ser desplegado un sistema. Puede tener m em oria y capacidad de procesamiento, y alberga uno o ms componentes y /o cdigo ejecutable. Un nodo puede ser un servidor, una estacin de trabajo, una impresora, etc.
/ nodo
11.3.2. Componente (Component)

Conceptualmente igual al componente utilizado en el Diagrama de Componentes. Los componentes residen dentro de un nodo, es decir que el nodo representa el medio am biente de un componente.
Pgina 59
11.3.3. Dispositivo (Device)

El Dispositivo es un nodo estereotipado como < < de vice > > que representa una unidad de hardware dentro de un sistema. Un ejemplo puede ser el hardware de una servidor Web, una impresora, un switch, etc.
/
d evice disp ositi v
11.3.4. Ambiente de Ejecucin (Execution Environment)

El Ambiente de Ejecucin es un nodo estereotipado como < < execution enviro n m e nt> > que representa una unidad de software que provee un Ambiente de Ejecucin para componentes. Un ejemplo puede ser el software de un servidor Web.
ex* cmti on environment

am biente de e je c u c i n
Pgina 60
11.3.5. Especificacin de Despliegue (Deployment Spec)

La Especificacin de Despliegue especifica los parm etros ju n to con los valores necesarios para llevar a cabo un despliegue de uno o mas componentes dentro de uno nodo.
> :d a pl oym e nt spe c especificacin de despliegue
11.4. Relaciones 11.4.1. Asociacin

La relacin de asociacin se realiza entre nodos, y representa que los nodos asociados cooperan de alguna manera. Las reglas utilizadas para las asociaciones son las mismas que las utilizadas para el Diagrama de Clases, es decir asociacin, agregacin y composicin.
/ nodol
A nodo 2
11.4.2. Utilizacin (Use)

La relacin de utilizacin se realiza entre nodos para establecer que un nodo, para llevar a cabo sus tareas, necesita utilizar otro nodo. Esta relacin establece una dependencia entre los nodos, y se m aneja bajo los mismos principios que la relacin de utilizacin en el Diagrama de Componentes.
Pgina 61
7 n odol ...................- > use n o d t
11.4.3. Comunicacin (Communication Path)

La relacin de comunicacin se utiliza para establecer un camino real de transmisin de datos entre dos nodos. Los cables de red o enlaces areos se utilizan para representar esta relacin.
/' nodol
y ---------- :>
/
nodo2
11.5. Aplicacin 11.5.1. Definicin de la arquitectura de un sistema

El Diagrama de Despliegue se puede utilizar para representar la arquitectura del sistema, modelando las partes que intervienen. Se deben especificar los
servidores intervenientes en cada capa ju n to con
los potenciales clientes,
representados en ambos casos por nodos que incluyen sus componentes de software ms representativos. Adicionalmente, si tiene valor para el negocio es posible visualizar tambin impresoras, switches, routers o cualquier otra unidad de hardware que tenga incidencia sobre el sistema.
Pgina 62
11.6. 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
Pgina 63
12. Conceptos Generales

12.1. Estereotipos
Un estereotipo es un nuevo elemento de UML que extiende a partir de uno existente, quedando definido con una semntica extendida y un nuevo icono grfico, aunque este ultim o es opcional. En caso de no establecer un icono para el estereotipo, se visualiza de la form a < < nom breEstereotipo> >. Los estereotipos pueden utilizarse para cualquier elemento de UML, como ser clases y/o relaciones. Las clases estereotipadas mas comunes son las clases del tipo < < Boundary> >, < < C o ntro l> > y << Entity> > , y entre las relaciones la mas conocida es << use> >.
12.2. Valor etiquetado (Tagged Vales)

El valor etiquetado se utiliza para guardar informacin adicional dentro un elemento de UML. Est form ado por una etiqueta (tag) y un valor (valu), donde por ejemplo, se puede guardar el nombre de la persona que construy una clase o la versin de la misma.
12.3. Ingeniera Directa

La ingeniera directa es el proceso que perm ite generar cdigo fuente en cualquier lenguaje a partir de los distintos diagramas de UML. Por ejemplo, a partir del diagrama de clases es posible generar el "esqueleto del sistem a , es
decir el cdigo fuente form ado por clases y mtodos, pero vacos. El E n te rp ris e A rc h ite c t permite generar cdigo en diversos lenguajes, entre ellos Java, VB.Net, G#, C+ + , Perl, Delphi y PHP.
12.4. Ingeniera Inversa

La ingeniera inversa es el proceso que perm ite generar diagramas a partir de cdigo fuente. Se utiliza generalm ente para construir el diagrama de clases a partir de las clases de cdigo fuente de cualquier lenguaje. El E n te rp ris e A rc h ite c t perm ite generar el diagrama de clases a partir del cdigo fuente de diversos lenguajes tales como Java, VB.Net, C#, C+ + , Perl, Delphi y PHP
Pgina 64
12.5. El Lenguaje XMI

XMI significa XML Metadata Interchange, y es una form a de almacenar los diagramas de UML en un form ato de texto basado en XML. El objetivo de XMI es perm itir la portabilidad de un proyecto armado en UML desde cualquier tipo de aplicacin. Por ejemplo, es posible utilizar el Enterprise Architect y guardar el proyecto en form ato .xm l, para luego utilizar otra aplicacin como Rational o PoseidonUML y poder abrir el proyecto sin inconvenientes.
Pgina 65
13. Introduccin al Proceso Unificado de Desarrollo de Software

13.1. Definicin
El Proceso Unificado de Desarrollo, tambin conocido como UP, es una metodologa orientada a la construccin de software. Nace como la unin de distintas metodologas antes separadas por distintos autores, concentrando lo m ejor de cada uno. Es posible definirlo como un proceso que define quien est haciendo que, cuando lo esta haciendo, y como alcanzar un objetivo. Es el proceso utilizado para guiar a los desarrolladores. Se la conoce inicialm ente como RUP (Rational Unified Process), que es la propuesta propietaria de la empresa Rational, y en su propuesta genrica se lo denom ina UP (Unified Process). La diferencia radical con UML es que UML es un medio, y no un fin. UML tiene como objetivo documentar, visualizar y modelar un sistema, y no define quien realiza cada actividad, tampoco define tiem pos ni coordinacin entre los roles de los distintos trabajadores del sistema. UML no es una metodologa (como s lo es UP) sino que es un lenguaje.
13.2. Historia 13.2.1. El proceso Objectory

La metodologa RUP tiene una larga historia que nace en Objectory en el ao 1987, fundada por Jacobson. Jacobson trabajaba en la empresa Ericsson y tenia como principales tareas el anlisis y diseo de sistemas de informacin, cuando decide independizarse y fundar Objectory para dedicarse a la investigacin de una metodologa que perm ita el desarrollo de sistemas, de manera organizada, utilizando toda empresa. El proyecto se desarrolla hasta el ao 1996 de form a independiente, presentando una gran evolucin y captando la atencin de la compaa Rational, que luego comprara a Objectory para comenzar a marcar el camino para lo que luego se conocera como RUP. la experiencia obtenida en tareas sim ilares en su anterior
Pgina 66
Objectory representaba el concepto de Object Factory (o fbrica de objetos).
13.2.2. El proceso Objectory de Rational

En el ao 1996 Rational compra Objectory y comienza a unificar los principios bsicos de Objectory con los propios. Entre los aspectos ms im portantes, se destacan los siguientes: Utilizacin de fases dentro de un proyecto Utilizacin de iteraciones controladas dentro de las fases Establecimiento de la arquitectura como la parte mas significativa de la
organizacin del sistema Incorporacin de UML como lenguaje de modelado (estaba en fase de
desarrollo, versin 1.1) Estos cambios fueron realizados entre los aos 1996 y 1997.
13.2.3. El Proceso Unificado de Rational (RUP)

En el ao 1998 Rational decide expandirse en la bsqueda de una metodologa genrica, y comienza a comprar empresas que se encargaban de actividades puntuales y estaban bien desarrolladas en esos campos, como ser gestin de requisitos, gestin de configuracin, testing, etc. Rational absorben toda la experiencia y conocimientos, y finalm ente construye la metodologa denominada RUP. Establecieron las siglas RUP basndose en las siguientes ideas:
de R ational, correspondiente al nombre de la empresa U de U n ifie d , que significa unificado ya que representa la unificacin de
todas las diferentes tcnicas de desarrollo y de todas las metodologas utilizadas anteriorm ente
P de Process, correspondiente al proceso que indica paso a paso las
tareas a realizar para cum plir un objetivo
13.3. La necesidad de una metodologa
Pgina 67
En todo desarrollo de software es necesaria una metodologa para coordinar a los trabajadores que forman parte del proyecto. Resulta necesario un proceso que: proporcione una gua para ordenar actividades de un equipo, dirigiendo
tareas para cada desabollador por separado y del equipo como un todo, para lograr que no se solapan tareas junto con el cum plim iento de objetivos en fechas panificadas especifiquen los artefactos que deben desarrollarse, es decir los
documentos necesarios en cada fase a lo largo del desarrollo del software ofrezca criterios para el control de calidad ofrezca criterios en cuanto a la medicin de productos y actividades del
proyecto en trm inos de tiem po y su evolucin correspondiente maximice la productividad
13.4. Fundamentos del Proceso Unificado de Desarrollo

El Proceso Unificado de Desarrollo es un proceso de desarrollo de software que especifica las actividades necesarias para transform ar los requisitos de un usuario en un sistema de software. Proporciona un marco genrico de trabajo, y utiliza como herram ienta visual al UML. 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. La arquitectura proporciona la estructura para las iteraciones que se realizaran durante el proceso de desarrollo para evolucionar y refinar el producto, y los casos de uso definirn los objetivos y la direccin del trabajo en cada iteracin.
13.4.1. Dirigido por Casos de Uso

El Proceso Unificado de Desarrollo esta dirigido por el conjunto de casos de uso. Un caso de uso es una funcionalidad bien definida del sistema que proporciona al
Pgina 68
usuario un resultado. Representa a los requisitos funcionales (es decir, lo que debera hacer el sistema). El conjunto de casos de usos constituyen el M odelo de Casos de Uso, el cual describe la funcionalidad integral del sistema. Se utilizan para guiar el diseo y la implem entacin, y representan el punto de partida para la construccin de los casos de prueba (test cases). 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.
13.4.2. Centrado en una arquitectura

El Proceso Unificado de Desarrollo esta centrado en una arquitectura ya que sta representa los cimientos del software a desarrollar, es donde el software sera ejecutado. Una arquitectura comprende la definicin de los siguientes conceptos: Arquitectura de hardware Sistema Operativo DataBase Management System (DBMS) Protocolos de comunicacin de red
Estrategia de diseo a seguir (m ulticapa, orientados a servicios, etc.) Para su definicin, el arquitecto de software debe comprender los casos de uso claves del sistema. Esto se debe a que una arquitectura tiene una relacin directa con los casos de uso, ya que estos deben "encajar" en la arquitectura, es decir que la arquitectura debe perm itir el desarrollo normal de todos los casos de uso. Para evaluar la viabilidad tcnica de los casos de uso sobre una arquitectura, generalm ente se eligen entre el 5% al 10% del to ta l, siendo estos casos de uso los mas representativos del sistema o los que constituyen las funciones claves. Para definir una arquitectura es conveniente, por una lado, esquem atizarla segn los factores no dependientes de los casos de uso, y por el otro, trabajar con los casos de uso del sistema, especificarlos y realizarlos en trm inos de subsistemas, componentes y clases. A medida que los casos de uso se especifican y se van retinando, la arquitectura ira "m adurando".
Pgina 69
Una arquitectura debe satisfacer tambin a los requisitos no funcionales, como ser rendim iento, performance y velocidad de respuesta. El objetivo es encontrar una arquitectura estable y escalable, construyndola de tal manera que perm ita que el sistema de software evolucione.
13.4.3. Iterativo e incremental

El Proceso Unificado de Desarrollo es iterativo e increm ental ya que divide a un proyecto en "m ini-proyectos", tambin denominados iteraciones. El proyecto se estructura en cuatro grandes fases (presentadas a continuacin) donde en cada fase se realizan una gran cantidad de iteraciones. Cada iteracin deber planificarse y ejecutarse en form a controlada, basada en casos de uso bien especificados para m itigar el riesgo y logrando as en cada iteracin un increm ento real del sistema. Se intenta planificar todas las
iteraciones de la fase (o la mayor cantidad posible) y su correspondiente orden lgico. Una iteracin comienza con la deteccin de los casos de uso (Requisitos), luego Anlisis, Diseo, Im plementacin y Pruebas, es decir que cada iteracin convierte un conjunto de casos de uso en cdigo fuente. Por cada iteracin: se identifican y especifican los casos de uso mas relevantes se crea un diseo respetando la arquitectura se im plem enta el diseo 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, las distintas iteraciones sirven como un refinamiento de requisitos.
Pgina 70
13.5. Ciclo de vida del Proceso Unificado

El Proceso Unificado de Desarrollo establece la construccin de un sistema en cuatro fases bien definidas: Inicio Elaboracin Construccin
Transicin Cada fase term ina con un h ito , donde se decide si se avanza a la fase siguiente. En este punto se revn presupuestos, planificaciones y requisitos. Se suele reunir el personal tcnico con el de gestin para hacer una evaluacin de la situacin. Los hitos se utilizan para estimar tiem pos y recursos necesarios para la prxim a fase. Sirven tambin para controlar el progreso con las planificaciones
previam ente realizadas. Si se encuentra alguna deficiencia, debe ser corregida antes de pasar a la siguiente fase. Cada fase esta form ada por ite ra c io n e s , y cada iteracin est compuesta por flu jo s fu n d a m e n ta le s de tr a b a jo . Una iteracin representa el conjunto de actividades que tienen como objetivo realizar un avance real y tangible" del sistema. Para completar una iteracin es necesario llevar a cabo todos los flujos fundam entales de trabajo, presentados a continuacin: Requerimientos Anlisis y Diseo I m plem en t acin Testing Configuracin
13.5.1. Fase de Inicio

En la Fase de Inicio se genera una descripcin del producto y se presenta el anlisis del negocio. Se definen las funciones principales del sistema para los usuarios ms representativos, el plan de proyecto y el costo del producto, identificando los riesgos mas im portantes. Se debe realizar en form a
Pgina 71
aproxim ada una estimacin del proyecto en cuanto a tiempos, costos y recursos. Se comienza a pensar en una posible arquitectura y se planifica en detalle la Fase de Elaboracin.
13.5.2. Fase Elaboracin

En la Fase de Elaboracin se realiza una especificacin detallada de la mayora de los casos de uso y se construye la arquitectura alineada con los casos de uso ms crticos. Con la especificacin de los casos de uso realizada se planifican las actividades y se estiman los recursos necesarios hasta la term inacin del proyecto.
13.5.3. Fase de Construccin

En la fase de Construccin se utilizan la mayora de los recursos. A esta altura la arquitectura ya es estable, aunque puede incorporarse pequeas mejoras. En esta fase se construye el producto hasta convertirse en un sistema funcional. Al finalizar esta fase, el sistema responder por todos los casos de uso que han pactado entre la empresa y el cliente. El sistema final podra contener defectos (bugs) que se solucionarn en la prxim a fase: la fase de Transicin.
13.5.4. Fase de Transicin

En la fase de Transicin el producto se convierte en versin beta, donde los usuarios experim entados prueban el producto en busca de defectos. A medida que se van detectando errores, los desarrolladores corrigen dichos defectos. Esta fase incluye tambin la capacitacin a usuarios y se redactan form alm ente los manuales.
Pgina 72
14. LABORATORIOS
14.1. LABORATORIO #1 - Diagrama de Clases 14.1.1. Caso de Estudio
La lnea area AirBus, una de las empresas ms grandes del mundo en m ateria de transporte de pasajeros, se concentra principalm ente en el manejo de aviones comerciales. Estos aviones poseen una denominacin y una capacidad que determ ina la cantidad de pasajeros que puedan abordar el avin. Los aviones comerciales son explotados a travs de diferentes vuelos, que tienen como principales caractersticas un destino, una duracin y una fecha de salida. Los vuelos estn organizados en salidas peridicas e incluyen en su tripulacin a varias azafatas, un piloto, un co piloto y por supuesto, a los pasajeros que han comprado su pasaje. Sus aviones estacionan peridicamente en hangares de los diferentes
aeropuertos, aunque comparten el hangar con aviones privados que no forman parte de la compaa.
14.1.2. Construccin del Diagrama

Construir el Diagrama de Clases utilizando el Enterprise Architect para modelar la estructura de la informacin presentada anteriom ente. Para esto se solicita: Analizar, detectar e identificar las clases. Debatir con el docente acerca de las clases a utilizar para seguir con los prxim os pasos Identificar atributos y ubicarlos en las clases que corresponden Identificar clases abstractas Relacionar las clases que considere necesario con generalizacin Relacionar las clases que considere necesario utilizando asociacin, agregando navegabilidad y m ultiplicidad en sus extrem os Relacionar las clases que considere necesario utilizando composicin y agregacin
Pgina 73
14.2. LABORATORIO #02 - Diagrama de Objetos 14.2.1. Caso de Estudio

La lnea area AirBus ha comenzado con sus actividades el da 0 1/01/1990. Entre su flota de aviones, se destaca el avin comercial denominado AirbusSOO, con capacidad para 150 pasajeros. Este avin tiene asignados sus prxim os vuelos, que son los siguientes: Vuelo con destino a Buenos Aires, tiene fecha de salida el 20 de octubre y una duracin de 180 m inutos Vuelo con destino a San Pablo, tiene fecha de salida el 21 de noviembre y una duracin de 220 m inutos Vuelo con destino a Iguazu, tiene fecha de salida el 22 de diciembre y una duracin de 250 m inutos

Construir el Diagrama de Objetos utilizando el Enterprise Architect para modelar la estructura de la informacin presentada anteriorm ente. Para esto se solicita: Analizar, detectar e identificar los objetos. Debatir con el docente acerca de los objetos a utilizar para seguir con los prximos pasos Relacionar los objetos con vnculos Establecer los valores de los atributos en los objetos
Pgina 74
14.3. LABORATORIO #03 - Diagrama de Casos de Uso 14.3.1. Caso de Estudio

El aeropuerto de Ezeiza recibe gran cantidad de pasajeros por da, de los cuales hay pasajeros nacionales como pasajeros extranjeros. Una reducida cantidad de pasajeros decide adquirir su pasaje en el mom ento que arriba al aeropuerto. Para esto se acerca al puesto de venta de la lnea area y selecciona su pasaje, estableciendo previam ente el destino, la fecha de salida, el horario de salida, la clase en que quiere viajar (Turista, Standard o Ejecutiva) y la ubicacin dentro del avin. La persona encargada de la venta chequea disponibilidad y si existe disponibilidad le solicita al pasajero presentar documentacin personal como DNI y pasaporte. En caso de ser extranjero le solicita tambin presentar la informacin de ingreso al pas. Una vez presentada la documentacin, el pasajero presenta los descuentos que posee, que generalm ente son descuento por m illaje o descuento empresarial. Para finalizar, el pasajero debe pagar el pasaje, que lo puede realizar en efectivo, con ta rje ta de crdito o ta rje ta de debito. En caso de estas dos ultim as, deber firm a r el com probante de pago. Finalmente, el pasajero recibe su pasaje.

Construir el Diagrama de Casos de Uso utilizando el Enterprise Architect para modelar las interacciones que tiene el pasajero con el puesto de venta, de la informacin presentada anteriorm ente. Para esto se solicita: Identificar actores De ser posible, identificar relaciones de generalizacin entre actores Identificar casos de uso Relacionar los casos de uso con los actores correspondientes mediante asociacin
Pgina 75
Relacionar los casos de uso entre ellos con las relaciones de inclusin y generalizacin
De ser posible, identificar relaciones de extensin entre casos de uso
Pgina 76
14.4. LABORATORIO #04 - Diagrama de Estados 14.41. Caso de Estudio

La lnea area lleva un control interno muy estricto de los pasajes de cada vuelo. Para esto los categoriza en validos e invlidos. Dentro de la categora validos, rene los pasajes que son validos para ser utilizados. En prim era instancia son presentados dentro del sistema de
adm inistracin de pasajes como disponibles, que representan a los pasajes que estn puestos a la venta. Los pasajes disponibles pueden ser reservados en form a telefnica o por internet, y en el 95% de los casos luego son vendidos. El 5% es cancelado previo a la fecha de partida, 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, en este caso se le devuelve al pasajero un 85% de su valor y se pone en venta nuevamente. Dentro de la categora in v lid o s , se contemplan los pasajes que fueron vendidos y que la fecha de partida del vuelo ya paso, ya que se intenta m onitorear cuantos pasajeros que compraron el pasaje no tomaron el vuelo. Para esto define el pasaje como utilizado (el pasajero tom o el vuelo) y como caducado (en pasajero no tom o el vuelo).

Construir el Diagrama de Estados utilizando el Enterprise Architect para modelar los estados por los cuales puede pasar un pasaje de un vuelo, segn la informacin presentada anteriorm ente. 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 contendrn los sub estados Arm ar los diagramas de estados dependientes de los estados principales
Pgina 77
14.5. LABORATORIO #05 - Diagrama de Actividades 14.5.1. Caso de Estudio

La lnea area posee un sistema de venta de pasajes que utiliza en sus puestos de venta. Para poder comenzar con el proceso de venta, es necesario seleccionar el vuelo y chequear su disponibilidad. En caso de no haber lugar se inform a que el vuelo esta completo y se ofrecen al pasajero vuelos alternativos para que ste pueda volver a seleccionar un vuelo. Si hay disponibilidad en el vuelo se le solicita al pasajero el DNI y el pasaporte, y se chequea si es extranjero. En caso de serlo, se le pide adicionalmente la informacin declarada al ingresar al pas. Luego se solicitan los descuentos que, en caso de tenerlos, se realiza el clculo del precio final del pasaje incluyendo los descuentos. Una vez term inados todos estos pasos se realiza la venta del pasaje - la cual deber actualizar la disponibilidad en el vuelo y registrar la facturacin - y se entrega el pasaje al pasajero.

Construir el Diagrama de Actividades utilizando el Enterprise Architect para modelar las actividades del proceso de venta de un pasaje, segn la informacin presentada anteriorm ente. Para esto se solicita: Detectar actividades Detectar datastores Arm ar el diagram a correspondiente
Pgina 78
14.6. LABORATORIO #06 - Diagrama de Secuencia 14.6.1. Caso de Estudio

La lnea area posee un sistema de venta de pasajes que utiliza en sus puestos de venta. Dicho sistema, entre las diferentes ventanas que posee, se encuentra la
correspondiente a la de venta de pasajes, la cual esta confeccionada de la siguiente manera:
Venia de Pasajes
DNI Pasajero
22.56g.45S
Vuelo
Bs As Madrid :: 21/05/2007 :: 17.00
Mil aje
752|
(en millas)
Clase
Ejecutiva
Cantidad de Pasajes
Vender Pasajes
Es necesario identificar como se realiza la venta del pasaje desde un punto de vista interno al sistema, teniendo en cuenta ciertas reglas de negocio:
s Si el m illaje es > 0, el pasajero obtendr un descuento s Si la clase es ejecutiva, el pasajero obtendr un descuento s Si la cantidad de pasajes a vender es mayor a 2, el pasajero obtendr un
descuento
Pgina 79
Hay que tener en cuenta que al vender los pasajes se deber chequear la disponibilidad de pasajes en el vuelo, y si se realiza posteriorm ente la venta habr que actualizar la disponibilidad. Es necesario tambin registrar las ventas como parte de la facturacin.

Construir el Diagrama de Secuencia utilizando el Enterprise Architect para modelar la interaccin entre objetos para llevar a cabo la venta de un pasaje, segn la informacin presentada anteriorm ente. Para esto se solicita: Analizar, detectar e identificar los objetos. Debatir con el docente acerca de los objetos a utilizar para seguir con los prximos pasos Arm ar en un diagrama de clases las clases necesarias las cuales se utilizaran para crear los objetos identificados Agregar los mtodos necesarios a las clases para utilizarlos en el diagram a de secuencia Construir el diagrama de secuencia que visualice la interaccin que realizan los objetos para llevar a cabo una venta de un pasaje
Pgina 80
14.7. LABORATORIO # 0 7 - Diagrama de Comunicacin 14.7.1. Caso de Estudio

El caso de estudio es el mismo que el realizado para el diagrama de Secuencia. La ventana utilizada es la siguiente:
Venia de Pasajes
DNI Pasajern
2 2 .5 6 8 .4 5 8
Vuelo
Bs As -Madrid ::2 1/05/2007:: 17.00
Millaje
752|
(en millas)
Clase
Ejecutiva
"V
Cantidad de Pasajes
Vender Pasajes
La diferencia radica en que se desarrollara un escenario que tiene las siguientes caractersticas:
El m illaje es 0 (es decir que no tiene m illaje)
s La clase es ejecutiva, 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 travs del
mtodo consultarDisponibilidad() ) la respuesta ser verdadera
Pgina 81

Construir el Diagrama de Comunicacin utilizando el Enterprise Architect para modelar la interaccin entre objetos para llevar a cabo la venta de un pasaje, segn la informacin presentada anteriorm ente. Para esto se solicita: Arm ar el diagram a de colaboracin secuencia previam ente realizado Reutilizar los objetos ya construidos en el diagram a anterior basndose en el diagrama se
Pgina 82
> MAPA DE LA CARRERA

La carrera es un conjunto de cursos. Cada uno de estos cursos tiene diferentes alternativas de fechas para cursar, las mismas estn publicadas en el calendario del instituto. El siguiente mapa expresa las correlatividades entre los distintos cursos.
Im portante: stos cursospueden ser asistidos en forma individual sin necesidad de realizar toda la carrera completa.
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 programacin en -algn lengu aie

(WBasic, Pascal. C , 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," JSTL, S truts]
LU LU C N
A JA X - Ja va scrip t K.XML
z LU
t>
O > t f> C /> <
Patrones de disee
Anlisis y diseo orientado a objetos (UML y IIP)
Z
<
Copyright 2005-A ctuaiidad, educaclonIT. Todos los derechos estn reservados
Pgina 83
> CURSOS RELACIONADOS

JAVA SfANDARD PRINCIPIANTES
9" .
o o o
= 3
"O
Pgina 84

UML y UP

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

UML y UP

Enviado por

Direitos autorais:

Formatos disponíveis

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

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

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

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

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

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

1.2. Que es un Modelo

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

1.3. Como nace UML

1.4. Donde se utiliza

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

2. Introduccin a los diagramas de UML

2.2. Los Diagrama de UML 2.2.1. Diagrama de Clases

2.2.2. Diagrama de Objetos

2.2.3. Diagrama de Casos de Uso

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

2.2.4. Diagrama de Estados

2.2.5. Diagrama de Actividades

2.2.6. Diagrama de Comunicacin

2.2.7. Diagrama de Secuencia

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

2.2.8. Diagrama de Componentes

2.2.9. Diagrama de Despliegue

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

2.3.1. Diagramas Estticos

Diagrama de Objetos Diagrama de Casos de Uso Diagrama de Componentes Diagrama de Despliegue

2.3.2. Diagramas Dinmicos

Diagramas de Secuencia y Comunicacin) Diagrama de Estado

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

2.3.3. Diagramas Estructurales

2.3.4. Diagramas de Comportamiento

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

3. El Diagrama de Clases (Class Diagram)

3.3. Elementos 3.3.1. Clase

Que son los a t r i b u t o s

Que son los m to d o s

Re p res en tac i n g r a f i c a de una clase

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

superficie: in t + pagaiImpu&stoaO : void

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

atenizarQ : vo.;a' de sp e g a r^ : void \faiar{) : v a d

3.4. Relaciones 3.4.1. Generalizacin

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

Cui dador cuida

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

-------------------------------------0 .." 0 .."

3.4.5. Implementacin o Realizacin

denominada Volador, que incluye los mtodos despegar, aterrizar y volar.

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

Esta relacin tambin se denomina realizacin.

3.5. Clases Estereotipadas 3.5.1. Que es un estereotipo de clase

3.5.2. El estereotipo Boundary

3.5.3. El estereotipo Control

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

3.5.4. El estereotipo Entity

3.5.5. Representacin grafica

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

3.6. Aplicacin 3.6.1. Modelo de Anlisis o Modelo Conceptual

3.6.2. Modelo de Diseo

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

3.6.3. Diseo de Base de Datos

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

4. Diagrama de Objetos (Object Diagram)

4.3. Elementos 4.3.1. Objeto