Panorámica UML

Panorámica de UML
Con agradecimientos a Antonio Luna,

Patricio Letelier, Édgar Oviedo y Laura
Valenzuela
Se reutilizan aquí materiales de Cenfotec, Rational Software y de la

Universidad Politécnica de Valencia
 Copyright Cenfotec S.A. 2004

Temas
• Modelos en la Ingeniería del software
• Vistas
• Paquetes
• Casos de uso
• Diagramas de interacción: secuencia y
colaboración
• Modelos estructurales: clases y objetos
• Diagramas de estados
• Diagramas de actividad
• Diagramas de componentes
• Diagramas de despliegue
Construcción de una casa para “fido”
Puede hacerlo una sola persona

Requiere:
Modelado mínimo
Proceso simple
Herramientas simples

Construcción de una casa
Construida eficientemente y en un tiempo

razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas
Construcción de un rascacielos
Construida por un equipo que involucra especialistas

Requiere:
Modelaje en distintos niveles y perspectivas
Proceso muy bien definido
Herramientas sofisticadas
Especialistas
Administración compleja

El desarrollo de modelos
• Cuando se pretende realizar un proyecto serio, de
cierta complejidad, se requiere la construcción de
modelos. El desarrollo de software no es la
excepción.
• Existen muchos elementos que contribuyen a crear
proyectos de software exitosos. Un elemento
común es el uso de modelos.
• Modelar es una técnica probada y plenamente
aceptada en cualquier rama de ingeniería.

¿Qué es un modelo?
• Es una simplificación de la realidad.
• Un buen modelo incluye los elementos esenciales
y omite aquellos que no resultan ser relevantes
para el nivel de abstracción que se desea
representar.

• Modelo inicial
• Descripción abstracta construida para comprender
el problema
• Modelos posteriores
• Describir qué hará el software y cómo lo hará,
asignando entre los objetos las responsabilidades
para llevar a cabo el comportamiento del sistema.

Variedades de modelos
El software
El mundo
Construido para entender. Construido para especificar.
Interpretado como una Interpretado como una
manifestación de hechos descripción de comportamiento
Modelo del mundo Correspondencia

sistemática
Modelo del software

modelo esencial
modelos de especificación e
implementación

Variedades de modelos
El software
El mundo
Construido para entender. Construido para especificar.
Interpretado como una Interpretado como una
manifestación de hechos descripción de comportamiento
Modelo del mundo Correspondencia

sistemática
Modelo del software

modelo esencial
modelos de especificación e
implementación
Descripción Prescripción
Mediante el uso de modelos podemos:
• Visualizar un sistema tal como es o como
queremos que sea.
• Especificar la estructura y comportamiento del
sistema
• Construir un sistema de software.
• Documentar las decisiones que hemos tomado en
el proceso de desarrollo del sistema.
• Mantener el software y controlar la evolución del
sistema.

• Se construyen modelos de sistemas complejos
debido a que es muy difícil comprender tales
sistemas completamente.
• Existen límites en la habilidad del intelecto humano
para entender la complejidad. Mediante el
modelaje simplificamos el problema enfocándonos
en un aspecto a la vez.

• Buscamos dividir el problema en pequeños
problemas y así amplificar el intelecto humano.
• Un modelo apropiadamente escogido permite al
modelador trabajar a un elevado nivel de
abstracción.
• Entre más complejo sea el sistema, es más
probable que falle o que se construya el sistema
equivocado si no se lleva a cabo una labor de
modelado.

• Todo sistema que resulta ser importante tiende
volverse complejo en el tiempo.
• Aunque se piense que no se necesite modelar;
cuando el sistema evolucione puede resultar muy
tarde.

El uso del modelado tiene una rica historia en las

disciplinas ingenieriles. Esa experiencia sugiere
cuatro principios básicos del modelaje:
1. La escogencia de cuáles modelos crear tiene una
profunda influencia en la forma cómo un problema
es enfrentado y cómo se diseña su solución.
2. Cada modelo puede ser expresado en diferentes
niveles de precisión.

3. Los mejores modelos se encuentran conectados a

la realidad.
4. Un único modelo no es suficiente. Cada sistema
no trivial se enfoca mejor mediante un conjunto de
modelos separados pero interrelacionados.

• Con el incremento en la complejidad del software
se manifiestan las debilidades de los métodos
tradicionales para el desarrollo de software.
• La falta de un modelo unificado que guíe e integre
las diferentes fases impide transiciones
armoniosas.
• Las transiciones usuales consumen tiempo y a
menudo reducen la calidad del producto final.

• Las técnicas de orientación a objetos se centran en
los objetos.
• Se pone énfasis en el aspecto estructural, lo que
establece las interacciones y relaciones que sirven
de vías de comunicación y colaboración entre los
objetos

• En el enfoque orientado a objetos los bloques
básicos de construcción son los objetos.
• Los objetos son cosas del dominio del problema y
del dominio de la solución.
• A lo largo del proceso de desarrollo hablamos en
términos de los mismos elementos.

La construcción de modelos
• El modelo resultante de cada fase consiste siempre
de objetos y sus interrelaciones.
• El análisis y el diseño tienen mucho en común: los
mismos conceptos orientados a objetos, técnicas y
notaciones del análisis se aplican igualmente en el
diseño.
• La transición de una fase a otra es tan natural, que
a veces es difícil especificar el punto final del
análisis y el inicial del diseño.

Modelos: desarrollo y transición
ObjetoAmodificadoenestosmodelos por
aspectosdediseño. Expandidoenotros
Datos de A
ObjetoAmapeadoen
el modelodeanálisis
ComponenteA
del problema
Problemadel
mundoreal
Diseñodetallado
Diseñoarquitectónico
Fasedeanálisis
Fasedediseño
M odelosimplificadoquecaptalasemántica
del dominiodel problemaentérminosdelos M odelosquerepresentanel dominiodela
objetosrelacionadosysurepresentaciónpor solución. Afectados por aspectosde
mediodediagramasquemuestransu especificacióneimplementación.
estructuraycomportamiento.  Copyright Cenfotec S.A. 2004
Vistas
• Es imposible captar los detalles de un sistema
complejo en una sola vista. Se debe comprender:
– La estructura de clases.
– Los mecanismos de herencia.
– Los comportamientos individuales de los objetos.
– Las interacciones entre los objetos.
– La dinámica del sistema en su conjunto.

Vistas
I I III
II II
(a)
(b)

Vistas de un sistema
• Las diferentes vistas deben mostrarnos tres
aspectos esenciales:
Estructura
Comportamiento
Arquitectura

Vistas
• Estructura
– Describe las partes estáticas del sistema
ignorando el procesamiento.
• Comportamiento
– Describe la evolución dinámica del sistema y la
forma cómo colaboran grupos de objetos.
• Arquitectura.
– Muestra la descomposición de un sistema en
subsistemas, permitiéndonos agrupaciones
basadas en los objetos.

Modelos y vistas
Diagramas de Transición
Casos de uso
Diagrama de objetos
Diagramas de Colaboración
Diagrama de clases
Diagramas de Secuencia
Vista estática.
Vista dinámica.
(estructura)
(comportamiento)
Relaciones entre objetos
ej. diagrama de clases.
Orden de acciones,
ej. diagrama de
secuencias.
El software
El mundo Modelos intermedios
Vista arquitectónica.
Dividir un sistema en
subsistemas
ej. Paquetes
Diagrama de interacción Diagrama de clases
Diagrama de transición de
estados

Abstracción - Modelaje visual
“El modelaje captura las

partes esenciales del sistema”
Orden
Item
envío
Proceso de Negocios
Sistema Computacional

Beneficios de una notación visual
Manejar la complejidad
Interfaz de Usuario
(Visual Basic,
Java, ..)
Lógica del Negocio
(C++, Java, ..)
Múltiples Sistemas
Servidor de BDs
(C++ & SQL, ..)
Modelar el sistema
independientemente
de la tecnología de Componentes
Reutilizados
implementación
Promover la reutilización
¿Qué es UML?
• UML = Unified Modeling Language
• Un lenguaje de propósito general para el modelaje
orientado a objetos
• Definido en documentos “OMG Unified Modeling
Language Specification”
• UML combina notaciones provenientes de:
– Modelado Orientado a Objetos
– Modelado de Datos
– Modelado de Componentes
– Modelado de Flujos de Trabajo (Workflows)
Situación de partida
• Diversos métodos y técnicas OO, con muchos
aspectos en común pero utilizando distintas
notaciones.
• Inconvenientes para el aprendizaje, aplicación,
construcción y uso de herramientas, etc.
• Pugna entre distintos enfoques (y correspondientes
gurúes)
Establecer una notación estándar

¿Qué (no) es UML?
• UML no es...
– ... una técnica
– ... una metodología
– ... un proceso de desarrollo
– ... una herramienta de modelaje
• UML es un lenguaje (notación) de modelaje
compuesto por varios tipos de diagramas que se
aplican a lo largo de todo el proceso de desarrollo
del software: desde la conceptualización del
problema, pasando por el diseño de la solución
hasta llegar incluso a la aplicación de pruebas.

Historia de UML
• Comenzó como el “Método Unificado”, con la
participación de Grady Booch y Jim Rumbaugh. Se
presentó en el OOPSLA’95.
• El mismo año se unió Ivar Jacobson. Los “Tres
Amigos” son socios en la compañía Rational
Software, desarrolladora de la herramienta CASE
Rational Rose.

Historia de UML
2001-2003 UML 2.0
2000 UML 1.4
1999 UML 1.3

Revisiones menores
1998
UML 1.2
Nov ‘97 UML aprobado por el OMG

Participantes en UML 1.0
 Rational Software
(Grady Booch, Jim Rumbaugh y Ivar
Jacobson)  MCI Systemhouse
 Digital Equipment  Microsoft
 Hewlett-Packard  ObjecTime
 i-Logix (David Harel)  Oracle Corp.
 IBM  Platinium Technology
 ICON Computing  Sterling Software
(Desmond D’Souza)
 Intellicorp and James Martin & Taskon
Co. (James Odell)  Texas Instruments
 Unisys

UML aglutina enfoques OO
Rumbaugh
Booch Jacobson
Odell
Meyer
Pre- and Post-conditions
Shlaer-Mellor UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
Aspectos novedosos
• Definición semi-formal del Metamodelo de UML
• Mecanismos de extensión en UML:
– Stereotypes
– Constraints
– Tagged Values
– Permiten adaptar los elementos de modelado,

asignándoles una semántica particular

Perspectivas de UML
• UML será el lenguaje de modelaje orientado a
objetos estándar predominante los próximos años
• Razones:
– Participación de metodólogos influyentes
– Participación de importantes empresas
– Aceptación por el OMG como notación estándar
• Evidencias:
– Herramientas que proveen la notación UML
– Edición de libros
– Congresos, cursos, camisetas, etc.
Breve tour por UML
Adaptado del trabajo de Patricio

Letelier
 www.dsic.upv.es/~uml

Modelos y diagramas
• Un modelo captura una vista de un sistema del mundo real.
Es una abstracción de dicho sistema, considerando un
cierto propósito. Así, el modelo describe completamente
aquellos aspectos del sistema que son relevantes al
propósito del modelo, y en un apropiado nivel de detalle.
• Diagrama: una representación gráfica de una colección de

elementos de modelado, a menudo dibujada como un grafo
con vértices conectados por arcos
OMG UML 1.4 Specification

Modelos y diagramas
• Un proceso de desarrollo de software debe ofrecer un
conjunto de modelos que permitan expresar el producto desde
cada una de las perspectivas de interés.
• El código fuente del sistema es el modelo más detallado del

sistema (y además es ejecutable). Sin embargo, se requieren
otros modelos ...
• Cada modelo es completo desde su punto de vista del

sistema, sin embargo, pueden existir relaciones de
rastreabilidad entre los diferentes modelos.
Diagramas de UML
 Diagrama de Casos de Uso
 Diagrama de Clases
 Diagrama de Objetos
Diagramas de Comportamiento
 Diagrama de Estados
 Diagrama de Actividad
Diagramas de Interacción
 Diagrama de Secuencia
 Diagrama de Colaboración
Diagramas de implementación
 Diagrama de Componentes
 Diagrama de Despliegue  Copyright Cenfotec S.A. 2004
Diagramas de UML
Los diagramas expresan gráficamente partes de un modelo

State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de
Diagrams Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboración Modelo Componentes
Scenario Component
Scenario Component
Diagramas
Diagrams de
Diagramas de
Diagrams Diagrams
Diagrams Despliegue
Estados Diagramas de
Actividad
Organización de los modelos
4+1 vistas de Kruchten (1995)
Vista de
Vista Lógica Implementación
Vista de los
Casos de Uso
Vista de Vista de
Procesos Distribución

Organización de los modelos
• Propuesta de Rational Unified Process (RUP)
– M. de Casos de Uso del Negocio (Business Use-Case
Model)
– M. de Objetos del Negocio (Business Object Model)
– M. de Casos de Uso (Use-Case Model)
– M. de Análisis (Analysis Model)
– M. de Diseño (Design Model)
– M. de Despliegue (Deployment Model)
– M. de Datos (Data Model)
– M. de Implementación (Implementation Model)
– M. de Pruebas (Test Model)

Paquetes en UML
• Los paquetes ofrecen un mecanismo general para
la organización de los modelos y subsistemas,
mediante la agrupación de elementos de modelaje.
• Se representan gráficamente como:
Nombre de
paquete

Paquetes en UML
• Cada paquete corresponde a un submodelo
(subsistema) del modelo (sistema)
• Un paquete puede contener otros paquetes, sin
límite de anidamiento pero cada elemento
pertenece a sólo un paquete (está definido en
solamente un paquete)
• Una clase de un paquete puede aparecer en otro
paquete por importación, mediante una relación de
dependencia entre paquetes

Paquetes en UML
 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

Paquetes en Rational Rose
Customers
Otra Clase
Customers
CheckingAccount
<<access>> (f rom Banking)
Banking Banking
CheckingAccount

Paquetes en UML

Diagrama de Casos de Uso
• Los casos de uso son una técnica para captar
información de cómo un sistema o negocio trabaja,
o de cómo se desea que trabaje
• No pertenece estrictamente al enfoque orientado a
objetos, es una técnica para captar o expresar
requerimientos

Casos de uso
• Un caso de uso es...
– “... un documento narrativo que describe la
secuencia de eventos de un actor (un agente
externo) que usa un sistema para completar un
proceso” [JACOBSON92]
– “... una interacción típica entre un usuario y un
sistema de cómputo” [FOWLER99]
• Un caso de uso:
– capta alguna función visible para el usuario
– puede ser pequeño o grande
– logra un objetivo discreto para el usuario
Ejemplos de casos de uso
Verificar Situación del Cliente

Supervisor
Preparar Catálogo
Administrativo Sistema
Inventario
Tipos de Venta

En el paquete tipos de venta:
Venta Normal
Venta en Rebajas
Vendedor
Venta en Ofertas

Solicitar Préstamo
Cliente
[Tarjeta Caducada]
<<extend>>
Solicitar Nueva Tarjeta

<<include>>
Reintegro Cuenta Corriente
Cliente Verificar Operación
<<include>>
Reintegro Cuenta de Crédito

Interacción
• Los objetos interactúan para realizar
colectivamente los servicios ofrecidos por las
aplicaciones. Los diagramas de interacción
muestran cómo se comunican los objetos en una
interacción
• Existen dos tipos de diagramas de interacción en
UML:
– el Diagrama de Colaboración y
– el Diagrama de Secuencia

Diagrama de Secuencia
• Muestra la secuencia de mensajes entre objetos
durante un escenario concreto
• Cada objeto (que interactúa) viene dado por una
barra vertical
• El tiempo transcurre de arriba hacia abajo

:WInPréstamos :Socio :Video :Préstamo

: Encargado
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo

Retirar Dinero del Cajero Automático

Curso Típico de Eventos
1. Este caso de uso empieza cuando Sistema

un cliente introduce su tarjeta en el : Cliente
cajero
2. El sistema pide la clave de 1: introducirNumeroTarjeta(numTarjeta)
identificación
3. El cliente introduce la clave
4. El sistema presenta las opciones
2: introducirClave(clave)
disponibles
5. El cliente selecciona la operación de
Retiro
6. El sistema pide la cantidad a retirar
7. El cliente introduce la cantidad 3: seleccionarOpcion(numOpcion)
requerida
8. El sistema procesa la petición y,
eventualmente, da el dinero solicitado
9. El sistema devuelve la tarjeta y 4: introducirCantidad(monto)
genera un recibo
10. El cliente recoge el dinero, el recibo
y la tarjeta y se va

Diagrama de Colaboración
• La distribución de los objetos en el diagrama
permite observar adecuadamente la interacción de
un objeto con respecto de los demás
• La estructura estática viene dada por los enlaces;
la dinámica por el envío de mensajes por los
enlaces

Diagrama de Colaboración
:Socio
:Video
2: verificar situación socio
1: prestar(video, socio) 3: verificar situación video

:WInPréstamos
5: entregar recibo
: Encargado 4: registrar préstamo
:Préstamo

Diagrama de Clases
• El Diagrama de Clases es el diagrama principal
para el análisis y el diseño
• Un diagrama de clases presenta las clases del
sistema con sus relaciones estructurales y de
herencia
• La definición de clase incluye definiciones para
atributos y operaciones
• El modelo de casos de uso aporta información para
establecer clases, objetos, atributos y operaciones

Clase y visibilidad
Alumno
DNI : char[10]
número_exp : int
nombre : char[50]
alta()
poner_nota(asignatura : char *, año : int, nota : float)
matricular(cursos : asignatura, año : int)
listar_expediente()

Asociación
dirige director
Departamento Profesor
0..1 1

Clase-asociación
empleador trabajadores
Empresa Empleado
* 1..*
Cargo
superior
nombre
sueldo 0..1
subordinado 1..*

Generalización
Trabajador
{ disjunta, completa }
Directivo Administrativo Obrero

Composición, generalización, asociaciones…
Motor Piloto Vendedor de billetes
1..4 1..2 1
1 n
n
1 n 1 n
Avión Vuelo Reserva
n
Avión militar Avión comercial Línea aérea
Avión de carga Avión de pasajeros

Diagrama de Estados
• Los Diagramas de Estados representan autómatas
(máquinas) de estados finitos, mostrando los
estados y las transiciones
• Son útiles sólo para los objetos con un
comportamiento significativo

Diagrama de Estados
alta baja
número_préstamos = 0
sin préstamos
Socio
número : int
nombre : char[50]
número_prestamos : int = 0
prestar devolver[ número_préstamos = 1 ]
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date) número_préstamos > 0
con préstamos
prestar
devolver[ número_préstamos > 1 ]

Diagrama de Actividad
• El Diagrama de Actividad es una especialización
del Diagrama de Estado, organizado respecto de
las acciones y usado para especificar:
– Un método
– Un caso de uso
– Un proceso de negocio (Workflow)
• Las actividades se enlazan por transiciones
automáticas. Cuando una actividad termina se
desencadena el paso a la siguiente actividad

Diagrama de Actividad
Buscar Bebida [ no hay café ] [ no zumo ]
[ hay café ]
[ hay zumo ]
Poner café Añadir agua Coger taza

en filtro al depósito Coger
zumo
Poner filtro
en máquina
Encender
máquina
/ cafetera.On
Café en
preparación
indicador de fin
Servir café Beber

Diagrama de actividad con carriles
Pasaj ero Vendedor Airline
Solicitar
pasaje
Verificar
existencia vuelo
Dar detalles
vuelo
Informar alternativas y
precios
Seleccionar
vuelo
Solicitar Reservar
pago plazas
Confirmar plaza
Pagar reservada
pasaje
Emitir
billete

Diagrama de Componentes
• Los diagramas de componentes describen los
elementos físicos del sistema y sus relaciones
• Muestran las opciones de implementación
incluyendo código fuente, binario y ejecutable

Diagrama de Componentes
• Los componentes representan todos los tipos de
elementos software que entran en la fabricación de
aplicaciones informáticas. Pueden ser simples
archivos, paquetes de Ada, bibliotecas cargadas
dinámicamente, etc.
• Las relaciones de dependencia se utilizan en los
diagramas de componentes para indicar que un
componente utiliza los servicios ofrecidos por otro
componente

Diagrama Componentes
Interfaz de Terminal
Control y Análisis
Gestión de Cuentas Rutinas de conexión Acceso a BD

Diagrama de Despliegue
• Los Diagramas de Despliegue muestran la
disposición física de los distintos nodos que
componen un sistema y el reparto de los
componentes sobre dichos nodos
Nodo

• Los estereotipos permiten precisar la naturaleza
del equipo:
– Dispositivos
– Procesadores
– Memoria
• Los nodos se interconectan mediante soportes
bidireccionales que pueden a su vez estereotiparse

Servidor Central Control y Análisis
Acceso a BD Comment
Comment
Rutinas de Coneccion
Comment
Terminal de Consulta
Interfaz de Terminal
Comment Comment
Punto de Venta
Comment
Gestión de Cuentas Interfaz de Terminal
Comment Comment

Diagrama de Despliegue en Rational
Control y Análisis
Acceso a BD
Servidor Central
Component Diagram:
Components / Servidor Rutinas de conexión
Central
Servidor Central
Rutinas de conexión
Punto de Venta
Punto de Venta Terminal de
Consulta Gestión de Cuentas Interfaz de Terminal
Terminal de Consulta
Rutinas de conexión Interfaz de Terminal
Component Diagram: Component Diagram:
Components / Punto de Components / Terminal
Venta de Consulta

Resumen
• UML define una notación que se expresa como
diagramas que sirven para representar
modelos/subsistemas o partes de ellos
• El 80 por ciento de la mayoría de los problemas
pueden modelarse usando alrededor del 20 por
ciento de UML-- Grady Booch

Cenfotec

Panorámica UML

Cargado por

Copyright:

Formatos disponibles

Panorámica UML

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Panorámica UML

Cargado por

Copyright:

Formatos disponibles

Panorámica de UML

Con agradecimientos a Antonio Luna,

Se reutilizan aquí materiales de Cenfotec, Rational Software y de la

 Copyright Cenfotec S.A. 2004

Puede hacerlo una sola persona

 Copyright Cenfotec S.A. 2004

Construida eficientemente y en un tiempo

Construida por un equipo que involucra especialistas

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

Modelo del mundo Correspondencia

Modelo del software

 Copyright Cenfotec S.A. 2004

Modelo del mundo Correspondencia

Modelo del software

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

El uso del modelado tiene una rica historia en las

 Copyright Cenfotec S.A. 2004

3. Los mejores modelos se encuentran conectados a

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

“El modelaje captura las

 Copyright Cenfotec S.A. 2004

Establecer una notación estándar

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

2001-2003 UML 2.0

2000 UML 1.4

1999 UML 1.3

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

– Permiten adaptar los elementos de modelado,

 Copyright Cenfotec S.A. 2004

Adaptado del trabajo de Patricio

 Copyright Cenfotec S.A. 2004

• Diagrama: una representación gráfica de una colección de

OMG UML 1.4 Specification

 Copyright Cenfotec S.A. 2004

• El código fuente del sistema es el modelo más detallado del

• Cada modelo es completo desde su punto de vista del

Los diagramas expresan gráficamente partes de un modelo

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004

• Se representan gráficamente como:

 Copyright Cenfotec S.A. 2004

 Copyright Cenfotec S.A. 2004