Juti introducción a uml
-
Upload
alejandro-alba-hernandez -
Category
Documents
-
view
349 -
download
0
Transcript of Juti introducción a uml
Alejandro E. Alba Hernández 1
Introducción a UML
AUS. Gustavo Torossi
AUS. Gustavo Torossi 2
Mitos sobre UML
Aprender UML es aprender el paradigma de objetos.
UML es una metodología de desarrollo. UML es solo para modelos de objetos.
AUS. Gustavo Torossi 3
Entonces ¿qué es UML?
UML es un lenguaje “unificado” de modelado para: Visualizar Especificar Construir Documentar
los artefactos de un sistema de software.
Representar y Comunicar Ideas
Modelos precisos, no ambiguos, completos
Trasladar en forma directa a un leng. prog.
Los artefactos construidos durante un proyecto
AUS. Gustavo Torossi 4
¿Qué significa lenguaje “unificado”? Lenguaje = sintaxis + semántica Unificado a través de:
Métodos y notaciones históricas Etapas del ciclo de desarrollo (requerimientos a
implementación) Dominios de aplicación Lenguajes y plataformas de implementación Procesos de desarrollo
AUS. Gustavo Torossi 5
Evolución histórica
Nov ‘97 UML promulgado por la OMG
AUS. Gustavo Torossi 6
Influencias
AUS. Gustavo Torossi 7
Participantes en UML 1.0
Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)
Digital Equipment Hewlett-Packard i-Logix (David Harel)
IBM ICON Computing
(Desmond D’Souza) Intellicorp and James
Martin & co. (James Odell)
MCI Systemhouse Microsoft ObjecTime Oracle Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys
AUS. Gustavo Torossi 8
Modelos
E = M * C2
AUS. Gustavo Torossi 9
¿Qué es un modelo?
Una representación en algún medio que captura los aspectos importantes del sistema modelado desde un determinado punto de vista.
Un modelo de un sistema software es realizado en un lenguaje de modelado.
AUS. Gustavo Torossi 10
Propósito de los modelos
Capturar y precisar requerimientos de un dominio de conocimiento, que sea comprensible por todos los stakeholders del proyecto.
Pensar sobre un diseño de un sistema.
Capturar decisiones de diseño de un sistema.
Explorar posibles soluciones a un problema económicamente.
Generar productos de trabajo útiles.
Documentar.
AUS. Gustavo Torossi 11
UML - Conceptos
AUS. Gustavo Torossi 12
UML - Vistas
Una vista es un subconjunto de construcciones de modelado que se enfocan en un aspecto particular del sistema.
Las vistas pueden dividirse en tres áreas: Estructural Comportamiento dinámico Gestión del modelo
AUS. Gustavo Torossi 13
Vistas – Clasificación estructural
Describe los elementos del sistema (clasificadores) y sus relaciones.
Clasificadores más comunes: Clases Casos de Uso Componentes Nodos
Vistas: Vista Estática – Diagrama de clases Vista de Casos de uso – Diagrama de casos de uso Vista de Implementación – Diagrama de Componentes /
despliegue
AUS. Gustavo Torossi 14
Vistas – Comportamiento dinámico
Describe el comportamiento del sistema a través del tiempo. Vista de Interacción: modela como interactúan los objetos
para realizar una funcionalidad del sistema Diagrama de Colaboración Diagrama de Secuencia
Vista de Máquina de estados: modela el ciclo de vida de una instancia de una clase en estados y transiciones. Diagrama de Estados
Vista de Actividades: modela flujos de trabajo (workflows) Diagrama de Actividades
AUS. Gustavo Torossi 15
Vistas – Gestión del modelo
Describe la organización de los modelos en unidades jerárquicas.
Permite manejar la complejidad.
Permite organizar el sistema en paquetes, subsistemas, y modelos.
AUS. Gustavo Torossi 16
Relación Áreas - Vistas
AUS. Gustavo Torossi 17
Mecanismos de extensión de UML
Permiten adaptar los elementos de modelado asignándole una semántica particular. Estereotipos Valores etiquetados Restricciones (OCL)
Overflow
< < exception> >E ventQ ueue {vers ion= 3.2}
add()
rem ove()
{ordered}
AUS. Gustavo Torossi 18
La Vista Estática
AUS. Gustavo Torossi 19
La Vista Estática
Propósito: Captura la estructura de los objetos. Es la base sobre la que se construyen las otras
vistas. Es un modelo incremental.
Diagrama de Clases
AUS. Gustavo Torossi 20
Clasificación Clasificador: es un concepto discreto en el modelo que tiene identidad,
estado, comportamiento, y relaciones.
Tipos de Clasificadores Elementos del Sistema:
Clase Interfaz Tipos de datos
Conceptos de Comportamiento: Caso de Uso
Cosas del entorno: Actor
Estructuras de implementación: Componente Nodo Subsistema
AUS. Gustavo Torossi 21
Clases & Objetos Objeto = estructura + operaciones + estado interno +
identidad.
Un objeto es una instancia de una clase.
Clase: Conjunto de objetos con estructura, comportamiento, relaciones, y semántica común.
Ejemplos algo físico → Avión algo del negocio → Pedido un concepto lógico → Horario algo de la aplicación → Window, Botón, Menú algo del comportamiento → Tarea, Proceso
AUS. Gustavo Torossi 22
Clases: Notación Gráfica
Cada clase se representa en un rectángulo con tres compartimientos:
nombre de la claseatributos de la claseoperaciones de la clase
AUS. Gustavo Torossi 23
Clases: Niveles de visibilidad
Determina el nivel de encapsulamiento de los elementos de una clase.
(-) Privado : Los atributos/operaciones son visibles solo desde la propia clase.
(#) Los atributos/operaciones protegidos están visibles para la propia clase y para las clases derivadas de la original
(+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación)
AUS. Gustavo Torossi 24
Clases: Niveles de visibilidad
Ejemplo
Reglas de visibilidad
+ Atributo público : int# Atributo protegido : int- Atributo privado : int
+ "Operación pública"# "Operación protegida"- "Operación privada"
AUS. Gustavo Torossi 25
Clases: Estereotipos
Objetos Entidad
Objetos Interfaz
Objetos de Control
Empleado
UIEmplead
Control
AUS. Gustavo Torossi 26
Clases y Objetos
Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo.
Un Diagrama de Clases muestra la abstracción de una parte del dominio.
Un Diagrama de Objetos representa una situación concreta del dominio.
AUS. Gustavo Torossi 27
Diagrama de Objetos
B anco Cliente
*1
Cuenta
*11 * 1 *
unB anco : B anco
c liente01 : Cliente
c liente02 : Cliente
ct a0101 : Cuenta
cta02 01 : Cuen ta
cta02 02 : Cuen ta
Diagrama de Clase
Diagrama de Objetos
AUS. Gustavo Torossi 28
Interfaces Describen un protocolo de comportamiento sin
especificar su implementación. Contienen operaciones pero no atributos. Una interfaz puede ser implementada por varias clases.
Com parable
com pareTo()
< < Inte rface> >
S tring
comp areTo()
Date
com pareTo()
F i le
co mpareTo()
< < im plem ent> >< <im ple m ent > >
< < im plem ent> >
com pareTo { .. . } com pareTo { .. . } com pareTo { . .. }
S tring
c om pareTo()
Com parable
AUS. Gustavo Torossi 29
Relaciones
Las relaciones entre clasificadores son: Asociación (conocimiento) Agregación / Composición Generalización Dependencias
AUS. Gustavo Torossi 30
Asociación
Asociación: Conexión semántica entre instancias de clases. proporciona una “conexión” entre los objetos para el
envio de mensajes.
Enlace: Instancia de una asociación. Lista ordenada de referencias a objetos.
AUS. Gustavo Torossi 31
Asociación: representación gráfica
Persona Compañíatrabaja-para
nombres. s.
nombredirección
jefe
Administraempleado
* *
emplea-a
0.. 1
0.. 1
0.. 1
*
marido
casado-con
mujer
AUS. Gustavo Torossi 32
Asociación: multiplicidad
Especificación de multiplicidad (mínima...máxima)
1 Uno y sólo uno0..1 Cero o unoM..N Desde M hasta N (enteros naturales)* Cero o muchos0..* Cero o muchos1..* Uno o muchos (al menos uno)
La multiplicidad mínima >= 1 establece una restricción de existencia
AUS. Gustavo Torossi 33
Asociación: casos especiales
Asociación como clase
Asociación calificada
Asociación ordenada
Restricción
7HDWUR 2 EUD
) HFKD+RUD
3UHVHQWDFLRQ33
3UHVHQWDFLRQ ( QWUDGD1 XP B%XWDFD11
Presentacion Diapositiva
1{ordered}
1..*
Cuenta
Persona
1
*
orEmpresa
*
*
AUS. Gustavo Torossi 34
Agregación y composición
Representa una relación todo-partes entre objetos. Son una variación de la asociación con mayor fuerza semántica. Una composición es una forma de asociación más fuerte en la cual
el compuesto es responsable de gestionar sus partes, por ejemplo asignación y desasignación. La composición implica tres cosas Dependencia existencial. El elemento dependiente desaparece al
destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo.
Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene
Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto.
AUS. Gustavo Torossi 35
Representación gráfica
Agregación
Composición
&ROHFFLRQ 2 EUD22
&RP SXWDGRUD
$ / 8 5 $ 0 ' LVN''''''
AUS. Gustavo Torossi 36
Generalización
Relación taxonómica entre una descripción general y otra más específica que la extiende.
Relación “es un tipo de”.
Herencia: mecanismo a través del cual los atributos, operaciones, y restricciones definidas para una clase, denominada superclase, pueden ser heredados (reutilizados) por otras clase denominadas subclases.
AUS. Gustavo Torossi 37
Representación Gráfica
Cuenta
CajaDeA horro CuentaCte
Vehículo
Veihículo Terrestre Vehículo Aéreo
Coche Camión Avión Helicóptero
AUS. Gustavo Torossi 38
Herencia Múltiple
Animal
Bípedo Cuadrúpedo
Con Pelos
Con Plumas
Con Escamas
Herbívoro
Carnívoro
cubertura
cobertura
cobertura
comida
nro patas nro patas
comida
Conejo
AUS. Gustavo Torossi 39
Dependencias
Indica una relación semántica entre dos o más elementos del modelo en la cual un cambio al elemento proveedor puede requerir un cambio o indicar un cambio en el significado del elemento cliente en la dependencia.
AUS. Gustavo Torossi 40
Dependencias
De traza
De refinamiento
De uso
De importación
…
0 RGHORGHO$ QDOLVLV
0 RGHORGH' LVHxR
Cliente (analisis)
Cliente (diseño)
AUS. Gustavo Torossi 41
Diagrama de clases: ejemplo
AUS. Gustavo Torossi 42
La Vista de Casos de Uso
AUS. Gustavo Torossi 43
La Vista de Casos de Uso
Capturan los requerimientos funcionales del sistema Describen la forma de usar el sistema tal como se la ve
desde el exterior. Visión de “caja negra” del sistema. No es un modelo orientado a objetos. Particiona la funcionalidad del sistema en unidades
discretas: los casos de uso. Concepto introducido por I.Jacobson en OOSE. Diagramas de Casos de Uso: Actores + Caso de uso
AUS. Gustavo Torossi 44
Actor
Representa algo que interactúa con el sistema. Puede ser humano u otro sistema. Reside fuera del sistema. Describe el entorno. Describe un “rol” que asume un usuario. La misma persona física puede asumir distintos roles. Ejemplos:
Cliente del Banco Cajero Sistema Link
Cli ente del Banc o
AUS. Gustavo Torossi 45
Caso de Uso Secuencia de transacciones realizadas por el sistema que brinda un
resultado de valor a un actor. Describe una “forma” de utilizar el sistema. Funciones:
Capturan requerimientos funcionales del sistema. Estructuran los modelos de objetos en vistas manejables.
Un caso de uso puede tener varios caminos de acción o “escenarios”. Los casos de uso sirven como hilo conductor del proceso de
desarrollo.
AUS. Gustavo Torossi 46
Diagrama de Caso de Uso
Ad m in is tra ció nO per a d or
(f ro m A ctors )
Extra cció n
(f rom Ex trac cion)
Tra ns fe re nciaC lie n te
(f rom Actors )
D ep ó s ito
S is te m a C e n tra l
(f rom Actors )
Cajero Automático
AUS. Gustavo Torossi 47
Descripción textualCU Extracción – Camino Estandard
1 Un mensaje de bienvenida está en espera en la pantalla del CA.
2 El cliente inserta su tarjeta en el CA.
3 El CA lee el codigo de la banda magnética y verifica que sea aceptable.
4 Si la tarjeta es aceptable, el CA solicita al cliente su código PIN.
5 El cliente ingresa su código PIN.
6 Si el código PIN es correcto, el CA solicita al cliente el tipo de transacción a realizar.
7 El cliente selecciona <extracción> y el CA envía el código PIN al Sistema bancario solicitando los datos de la cuenta del cliente.
8 Los datos de la cuenta recibidos se despliegan en la pantalla.
9 El cliente selecciona una cuenta y el monto a extraer.
10 El CA envia al sistema bancario el requerimiento de extracción.
11 El CA preparan los billetes a ser dispensados.
12 El CA imprime el comprobante del movimiento.
13 Los billetes son dispensados al cliente.
AUS. Gustavo Torossi 48
Descripción textual
RF- <id del requisito> <nombre del requisito funcional> Versión <numero de versión y fecha> Autores <autor> Fuentes <fuente de la versión actual> Objetivos asociados <nombre del objetivo> Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>}
Precondición <precondición del caso de uso> Paso Acción
1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>
3 4 5 6
Secuencia Normal
n Postcondición <postcondición del caso de uso>
Paso Acción 1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta}
2
Excepciones
3 Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundos Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales>
AUS. Gustavo Torossi 49
Caso de Uso: Relaciones
Inclusión: Secuencias comunes a varios casos de uso.
3URFHVDU7DUMHWD
( [ WUDFFLyQ 7UDQVIHUHQFLD ' HSyVLWR
LQFOXGH! !
LQFOXGH! !
LQFOXGH! !
AUS. Gustavo Torossi 50
Caso de Uso: Relaciones
Extensión: Partes opcionales de un caso de uso.
( [ WUDFFLyQ
( VWDGtVWLFD( [ WUDFFLyQ
0 RQLWRUHR( [ WUDFFLyQ
H[ WHQG! ! H[ WHQG! !
AUS. Gustavo Torossi 51
Caso de Uso: Relaciones
Generalización: Distintas variantes de un caso de uso. (“es un tipo de”)
( [ WUDFFLyQ
( [ WUDFFLyQ3HVRV ( [ WUDFFLyQ' yODUHV
AUS. Gustavo Torossi 52
Caso de Uso: Relaciones
Ejemplo
«» «»
Hacer Pedido
<<extend>>
«» «»
SilicitarCatálogo
«» «»
Suministro dedatos declientes
<<include>>«» «»
Pedir Producto
<<include>>
«» «»
Pagar
<<include>>
«» «»
Pagar alcontado
«» «»
AcordarCrédito
AUS. Gustavo Torossi 53
La Vista de Interacción
AUS. Gustavo Torossi 54
La Vista de Interacción Representa como interactúan cooperativamente los objetos para
implementar el comportamiento definido por los casos de uso.
Colaboración: Interacción entre un conjunto de objetos para implementar un
comportamiento del sistema. Una colaboración <<realiza>> la funcionalidad definida en un casos de
uso.
Interacción: Una interacción es un conjunto de mensajes que se intercambian
dentro del contexto de una colaboración por instancias de clases (objetos) a través de enlaces (instancias de asociación).
AUS. Gustavo Torossi 55
Diagramas de Secuencia Énfasis en la secuencia cronológica de los mensajes.
: Encargado:WInPréstamos :Socio :Video :Préstamo
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
AUS. Gustavo Torossi 56
Diagrama de Colaboración Énfasis en la distribución física y relaciones de los objetos.
: Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo5: entregar recibo
AUS. Gustavo Torossi 57
La Vista de Máquina de Estados
AUS. Gustavo Torossi 58
La Vista de Máquina de Estados
Describe el comportamiento dinámico de los objetos, modelando su ciclo de vida.
Autómatas finitos con estados y transiciones. Cada objeto se trata en forma aislada, el que se
comunica con el resto del mundo detectando eventos y respondiendo a ellos.
Es útil modelar solo para objetos con comportamiento estado-dependiente.
Uso de Diagramas de Estado.
AUS. Gustavo Torossi 59
Diagramas de Estado Cada objeto está en un estado en cierto instante. El estado describe un período de tiempo caracterizado
por: Conjunto de valores de atributos y relaciones del objeto. Período de tiempo durante el que se espera que ocurra un evento Período de tiempo durante el cual el objeto realiza una actividad
El estado en el que se encuentra un objeto determina su comportamiento.
Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase.
La transición entre estados es instantánea y se debe a la ocurrencia de un evento.
AUS. Gustavo Torossi 60
Diagramas de Estado Estados y Transiciones
A B
Evento [condición] / Acción
El evento se considera instantáneo
AUS. Gustavo Torossi 61
Diagramas de Estado Ejemplo: Pila
3LOD9DFtD
3LODQRYDFtDQLOOHQD
3LODOOHQD
HYHQWRFRQGDFFLyQ
SXVK
ERUUDUSLOD
FUHDUSLODSRSHUURU
SRSVL] H!
SXVKVL] H! IXOO
ERUUDUSLOD
ERUUDUSLOD
SXVKVL] H IXOO
SXVKHUURU
SRS
SRSVL] H
AUS. Gustavo Torossi 62
Eventos Acontecimiento significativo que tiene localización en tiempo y espacio. No tiene duración. Instantáneo Tipo de eventos
Señal: comunicación asíncrona entre objetos. Llamada: invocación sincrónica de método del objeto que recibe el evento. Cambio: satisfacción de una condición lógica que depende de valores de un atributo. Tiempo: instante absoluto, o lapso transcurrido.
Pueden modelarse con clases y jerarquías
AUS. Gustavo Torossi 63
Acciones Una acción es un cómputo atómico y breve
una sentencia de asignación una operación aritmética el envío de una señal a otro objeto la invocación de una operación propia asignación de valores de retorno creación o destrucción de objetos una secuencia de acciones simples
Acciones específicas de entrada, salida, durante, un estado o por un evento
estado A
entry: acción por entrarexit: acción por salirdo: acción mientras en estadoon evento: acción
AUS. Gustavo Torossi 64
Estados compuestos
AUS. Gustavo Torossi 65
La Vista de Actividades
AUS. Gustavo Torossi 66
La Vista de Actividades
Variante de la máquina de estados para modelar flujos de trabajo.
Utilización de diagramas de actividad. Caso particular de los diagramas de estado.
Los estados representan estados de actividad no de un objeto.
AUS. Gustavo Torossi 67
Diagrama de Actividades
AUS. Gustavo Torossi 68
Calles y flujo de objetos
AUS. Gustavo Torossi 69
Vistas Físicas
AUS. Gustavo Torossi 70
Vista de Implementación Modela el empaquetado físico del sistema en unidades
reutilizables llamadas “componentes”. Un componente es una unidad física de implementación
con interfaces definidas pensada para ser utilizada como parte reemplazable del sistema.
Cada componente implementa una o más clases del diseño.
Incluyen código fuente, binario, o ejecutable. Los componentes se vinculan por relaciones de
dependencia.
AUS. Gustavo Torossi 71
Diagrama de Componentes
AUS. Gustavo Torossi 72
Vista de Despliegue Modela la disposición física de los recursos de ejecución
computacional (computadores, unidades de com., etc.) Nodo: es un objeto físico de ejecución que representa
un recurso computacional. Pueden tener estereotipos (UCP, memorias, disk, etc.)
Las asociaciones entre nodos representan líneas de comunicación.
Se representan por diagramas de despliegue.
AUS. Gustavo Torossi 73
Diagrama de Despliegue
AUS. Gustavo Torossi 74
Diagrama de Despliegue
&OLHQWH
$ 336HUYHU
' %6HUYHU''''
: HE%URZVHU
6HUYOHWV- 63- ' %&
AUS. Gustavo Torossi 75
La Vista de Gestión
AUS. Gustavo Torossi 76
La Vista de Gestión
La Vista de Gestión del modelo está compuesta por paquetes y relaciones de dependencia entre paquetes.
Paquete: es una unidad de organización del modelo. Los paquetes ofrecen un mecanismo general para la
organización de los modelos / subsistemas agrupando elementos de modelado.
Los paquetes contienen elementos del modelo como clases, diagramas de casos de uso, interacciones, etc.
Todos los elementos del modelo deben pertenecer a un paquete.
Los paquetes tambien pueden contener otros paquetes.
AUS. Gustavo Torossi 77
La Vista de Gestión
Los paquetes pueden organizarse según el criterio del diseñador: Por la vista (estática, casos de uso, etc.) Por subsistema Por etapa del ciclo de desarrollo.
Una buena organización refleja la arquitectura de alto nivel del sistema.
AUS. Gustavo Torossi 78
4 + 1 vistas de Kruchten
Vista Lógica
Vista de Procesos
Vista de Distribución
Vista de Realización
Vista de los Casos de Uso
AUS. Gustavo Torossi 79
Dependencias de acceso / importación
Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa
El operador “::” permite designar una clase definida en un contexto distinto del actual
AUS. Gustavo Torossi 80
Dependencias de acceso / importación
La dependencia de acceso no modifica el espacio de nombres del cliente. Solo concede permiso para establecer referencias.
La dependencia de importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como sinónimos de los caminos completos.
AUS. Gustavo Torossi 81
Modelo y Subsistema
Un modelo es un paquete que abarca una descripción completa de una vista particular de un sistema. Proporciona una descripción cerrada de un sistema a partir de un punto de vista.
Un subsistema es un paquete que tiene piezas separadas de especificación y de realización. Representa una partición del sistema.
AUS. Gustavo Torossi 82
Proceso de Desarrollo
AUS. Gustavo Torossi 83
Proceso de Desarrollo UML no prescribe ningún proceso de desarrollo.
Sin embargo se recomienda un proceso:
Dirigido por Casos de Uso
Centrado en la Arquitectura
Iterativo e Incremental
Ejemplo: Proceso Unificado (RUP)
AUS. Gustavo Torossi 84
Ciclo de Vida
AUS. Gustavo Torossi 85
Ciclo de Vida
AUS. Gustavo Torossi 86
Ciclo de Vida
AUS. Gustavo Torossi 87
Ciclo de Vida
AUS. Gustavo Torossi 88
Herramientas CASE
AUS. Gustavo Torossi 89
Herramientas CASE UML no es un leguaje de programación visual, pero sus
modelos pueden conectarse directamente con una variedad de lenguajes.
Forward & reverse engineering.
Ingeniería de ida y vuelta.
AUS. Gustavo Torossi 90
Herramientas CASE Rational Rose (www.rational.com)
Rational XDE (www.rational.com)
Borland Together (www.borland.com/together/)
Embarcadero Describe (www.embarcadero.com/)
AUS. Gustavo Torossi 91
Herramientas CASE - Libres Argo UML (argouml.tigris.org) Poseidon (www.gentleware.com) Dome (www.htc.honeywell.com/dome )
Comparativa: http://www.diatel.upm.es/malvarez/UML/Comparativa.html
AUS. Gustavo Torossi 92
Bibliografía
Título Autor ISBN
El Lenguaje Unificado de Modelado
Manual de Referencia
James Rumbaugh 8478290370
El Lenguaje Unificado de Modelado
Guía del Usuario
Grady Booch 8478290281
UML Gota a gota Martin Fowler 9684443641
UML y Patrones Craig Larman 8420534382
AUS. Gustavo Torossi 93
Recursos en la Web UML Resource Center (www.rational.com/uml/index.jsp)
The Rational Edge (www.therationaledge.com/)