Introducción a UML
Introducción a UML
Fuente: Marcela Varas
Contenidos
1. UML: qué es
2. UML Parte Estática
3. Taller
1. UML: Qué es
Lo que implica que sea unificado
Componentes: Vistas y Diagramas
Ejemplos
Unified Modeling Language
� Lenguaje de Modelado Visual de Propósito
general
� Usos:
� Especificar, visualizar, construir y documentar
artefactos de un sistema software.
� Se diseñó de manera de independizarlo del
método de desarrollo, y se intenta que sea
aplicable a todas las etapas del ciclo de vida
del software
UML: “Unificado”
� Cruza los métodos y notaciones anteriores
� Cruza los ciclos de desarrollo
� Cruza los dominios de aplicación
� Cruza las plataformas y lenguajes de
implantación
� Cruza los procesos de desarrollo
� Cruza los conceptos internos
UML: Componentes
� Vista Estática
� Vista de Casos de Uso
� Vista de Interacción
� Diagrama de Secuencia
� Diagrama de Colaboración
� Vista de la Máquina de Estados
� Vista de Actividades
� Vista Física
� Vista de la Gestión del Modelo
� Constructores de Extensibilidad
UML EstáticoVista Diagramas Conceptos Principales
Vista Estática Diagrama de Clases
Clase, Asociación, GeneralizaciónDependencia, Realización, Interfase
Vista de Casos de Uso
Diagrama de Casos de Uso
Caso de uso, Actor, Asociación, Extensión, Inclusión, Generalización de caso de uso
Vista de Implementación
Vista del despliegue (deployment)
Diagrama de Componentes
Componente, Interfaz, Dependencia, Realización
Diagrama de Despliegue
Nodo, Componente, Dependencia, Locación
Diagrama de Clases
Diagrama de Casos de Uso
Diagrama de Componentes
Diagrama de Despliegue
UML DinámicoVista Diagramas Conceptos
Principales
Vista de Máquina
de Estados
Diagrama de
Estados
(statechart)
Estado, Evento,
Transición, Acción
Vista de
actividades
Diagrama de
Actividades
Estado, Actividad,
Transición de
compleción,
Juntura (join),
Bifurcación (fork)
Vista de
Interacción
Diagrama de
Secuencia
Interacción,
Objeto, Mensaje,
Activación
Diagrama de
Colaboración
Colaboración,
Interacción, Rol de
colaboración,
Mensaje
Diagrama de Estados
Diagrama de Actividades
Diagrama de Secuencia
Diagrama de Colaboración
UMLGestión del Modelo
Vista Diagramas Conceptos Principales
Vista de la gestión
del modelo
Diagrama de
Clases
Paquete,
Subsistema,
Modelo
Vista Diagramas Conceptos Principales
Todas Todos Restricción, Estereotipo,
Valores tagged
(etiquetados)
Extensibilidad
Vista de la Gestión del Modelo
Extensibilidad
2. UML Parte Estática
�Diagrama de Casos de Uso
�Diagrama de Clases
Diagrama de Casos de Uso
� Modela la funcionalidad de un sistema percibido desde el usuario externo (actor).
� Un caso de uso es una unidad de funcionalidad coherente expresado como una transacción entre actores y el sistema.
� Pueden describirse en varios niveles de detalle.
� Un caso de uso se implementa como una colaboración en la vista de interacción.
Diagrama de Casos de Uso: Elementos
Actor:
� rol que juega un usuario con respecto al sistema.
� un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.
Caso de Uso:
� Operación o tarea específica que se realiza tras una orden de algún agente externo, originada por una petición de un actor o bien desde la invocación desde otro caso de uso
Diagrama de Casos de Uso: Relaciones
Asociación:
� Es el tipo de relación
más básica que indica la invocación desde un
actor o caso de uso a otra operación (caso de uso).
Dependencia o Instanciación:
� Es una forma muy
particular de relación entre clases, en la cual
una clase depende de otra, es decir, se instancia (se crea).
Diagrama de casos de Uso: Relaciones de Generalización
� Este tipo de relación esta
orientado exclusivamente
para casos de uso (y no
para actores).
� Se diferencian por el
estereotipo <<uses>> (uso)
o (<<extends>>) (herencia).
� extends: Se recomienda utilizar cuando un caso de uso es similar a otro (en sus características).
� uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
Diagrama de Casos de Uso: EjemploMáquina Recicladora
El sistema debe :
1. Registrar el número de ítemes ingresados.
2. Imprimir un recibo cuando el usuario lo solicita, que incluye
(a) una descripción de lo depositado, (b) el valor de cada
item y (c) el total
3. El usuario/cliente presiona el botón de comienzo
4. Existe un operador que desea saber lo siguiente: (a)
Cuántos ítemes han sido retornados en el día y (b) al final
de cada día, un resumen de todo lo depositado.
5. El operador debe además poder cambiar información
asociada a ítemes y dar una alarma en el caso de que (a)
un item se atore o (b) no hay más papel.
Máquina Recicladora: Identificación de Actores
Máquina Recicladora: Diagrama Completo
Diagrama de Clases
� Modela los conceptos del dominio de la aplicación.
� Permite visualizar las relaciones entre las clases que involucran el sistema
� Un diagrama de clases está compuesto por los siguientes elementos: � Clases: atributos, operaciones y visibilidad.
� Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
� Responsabilidades
Diagrama de Clases: ElementosClase
� Es la unidad básica que encapsula toda la
información de un Tipo de Objeto (un objeto es una instancia de una
clase).
Diagrama de Clases: ElementosAtributo
� Los atributos describen a una clase. Pueden
ser Públicos, Privados o Protegidos.
� public (+, ): Indica que el atributo serávisible tanto dentro
como fuera de la clase, es decir, es accesible
desde todos lados.
� private (-, ): Indica que
el atributo sólo será
accesible desde dentro de
la clase (sólo sus métodos lo pueden acceder).
� protected (#, ): Indica
que el atributo no seráaccesible desde fuera de la
clase, pero si podrá ser
accesado por métodos de
la clase además de las
subclases que se deriven(herencia)
Diagrama de Clases: ElementosOperaciones (métodos)
� Las operaciones o métodos
de una clase describen la
forma en la cual ésta
interactúa con su entorno. Pueden ser Públicas,
Privadas o Protegidas.
� public (+, ): Indica que el método será visible tanto
dentro como fuera de la
clase, es decir, es accesible
desde todos lados.
� private (-, ): Indica que
el método sólo será
accesible desde dentro de
la clase (sólo otros métodos de la misma clase lo
pueden acceder).
� protected (#, ): Indica que el atributo no será
accesible desde fuera de la
clase, pero si podrá ser
accesado por métodos de
la clase además de las subclases que se deriven
(herencia)
Diagrama de Clases: ElementosRelaciones entre Clases
� Las clases interrelacionadas modelan un sistema en su dimensión estática.
� Existen tres tipos de relaciones básicas:
� Dependencia
� Generalización
� Asociación
� Un cambio en la clase independiente
(Aplicación) puede afectar a la clase
dependiente (Ventana)
� La interpretación más frecuente es la de uso:
una clase usa a otra como argumento de
una operación.
� El objeto creado no se
almacena en el objeto que lo crea.
Relaciones entre Clases:Dependencia (instanciación o uso)
Relaciones entre Clases:Generalización
� Relaciona una abstracción general
(superclase) con una más concreta del mismo tipo (subclase)
� Una clase puede tener cero, una (herencia
simple) o más superclases (herencia
múltiple)
� Una clase sin superclases es una
clase raíz
� Una clase sin
subclases es una clase hoja
Relaciones entre Clases:Generalización - Polimorfismo
� Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones.� Un objeto de una subclase puede sustituir a
un objeto de la superclase en cualquier contexto. Lo inverso no es cierto
� Una operación de la subclase con igual signatura que una operación de la superclase la anula y sustituye.
� El polimorfismo es muy útil en la programación.
Relaciones entre Clases:Generalización
Relaciones entre clases:Asociación
� Relación estructural entre las clases.
� En general es simétrica
� Tiene un nombre, que la describe (verbo, con dirección de lectura)
� Puede tener un rol que describe el papel específico que una clase juega en una asociación.
� Tiene multiplicidad, que especifica por cada clase el número de objetos de la clase opuesta que se relacionan con un solo objeto de dicha clase a través de la asociación:
1 : uno
0..1 : cero o uno
3 : tres
*: muchos
1..*: al menos uno
2,6,7: dos, seis o siete
2-4, 10-12 : de dos a cuatro y de diez a doce
Relaciones entre clases:Asociación
Relaciones entre ClasesAgregación y Composición
� Composición
� Relación estática, en donde el tiempo de vida del objeto incluido estácondicionado por el tiempo de vida del que lo incluye.
� El Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo“, como un parámetro pasado “por valor”.
� Agregación
� Relación dinámica, en donde el tiempo de vida
del objeto incluido es
independiente del que lo
incluye.
� El objeto base utiliza al
incluido para su
funcionamiento, como un
parámetro pasado “por
referencia”.
Permite modelar objetos complejos, en base a relaciones todo –parte.
Relaciones entre Clases:Agregación y Composición
Agregación(Por referencia)
Composición(Por valor)
Diagrama de Clases: ElementosResponsabilidades
La distribución de
responsabilidades en un
sistema, se realiza
identificando un conjunto
de clases que colaboran
entre sí para llevar a cabo
algún comportamiento.
Luego hay que identificar
el conjunto de
responsabilidades para
cada clase
Diagrama de Clases
3. Caso
Para el caso descrito, desarrolle:
�Diagrama de Casos de Uso
�Diagrama de Clases
Gestión de Proyectos de Informática
El sistema debe manejar lo siguiente:� Unidad organizacional que solicita el proyecto
� Nombre del proyecto
� Organización del proyecto
� Planificación del proyecto (actividades, responsables, plazos, recursos asignados)
� Control del proyecto (nivel de avance, productos entregados)
� Se debe, además, manejar información de los recursos humanos involucrados ( nombre, perfil, filiación ) .
El sistema debe entregar:� Plan del proyecto
� Avance del proyecto
Bibliografía y Referencias: Fundamental
� James Rumbaugh, Ivar Jacobson, Grady
Booch, “The Unified Modeling Language
Reference Manual”, Addison Wesley, 1999
� Craig Larman, “UML y Patrones”, Prentice
Hall, 1999
� OMG www.omg.org
Bibliografía y ReferenciasComplementaria
� Rational www.rational.com
� Robert Muller, “Database Design For Smarties:
Using UML for Data Modeling”, Morgan Kaufmann, 1999
� Luis Guerrero, “Taller de UML”, DCC, Universidad de Chile, 2002, www.dcc.uchile.cl/~luguerre/cc61j
� Patricio Salinas, “Tutorial de UML”, DCC, Universidad de Chile, 2000, www.dcc.uchile.cl/~psalinas/uml
Top Related