Post on 06-Jun-2015
1
Universidad de OviedoLenguajes y Sistemas Informáticos
Departamento de Informática
Francisco Ortín Solerortin@lsi.uniovi.es
Lenguaje UMLLenguaje UML((Unified Modeling LanguageUnified Modeling Language))
2Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
3Francisco Ortín Soler
¿¿QuQuéé es UML?es UML?
• UML es un lenguaje estándar (OMG, www.omg.org) para representar “planos”(footprints) software
• Los planos software se representan mediante distintas vistas de un mismo modelo
• Una vista es una proyección de la organización y estructura de un sistema, centrada en un aspecto particular del mismo
• UML define una notación: material gráfico para representar cada una de las vistas del modelo; es la sintaxis del lenguaje UML
• UML es por lo tanto un lenguaje para modelar un sistema real (análisis) o software (diseño)
Introducción
4Francisco Ortín Soler
¿¿QuQuéé es un modelo?es un modelo?
• Un modelo es una simplificación de la realidad [Booch99].
• ¿Por qué es necesario modelar?1. Los modelos nos ayudan a visualizar cómo es o
queremos que sea un sistema (abstracción).2. Los modelos nos permiten especificar la
estructura y comportamiento de un sistema.3. Los modelos nos proporcionan plantillas que nos
guían en la construcciónde un sistema.
4. Los modelosdocumentan las decisiones que hemosadoptado.
Introducción
2
5Francisco Ortín Soler
(I) Lenguaje para Visualizar(I) Lenguaje para Visualizar
• El lenguaje gráfico de UML facilita la comunicación entre los distintos miembros de un proyecto
• Permite elevar el nivel de abstracción para obtener una visión más general de una parte de un proyecto
• UML es más que un montón de símbolos gráficos; detrás de cada símbolo hay una semántica bien definida. Por lo tanto, una herramienta puede interpretar un modelo sin ambigüedad
Introducción
6Francisco Ortín Soler
(II) Lenguaje para Especificar(II) Lenguaje para Especificar
• Especificar significa construir modelos:Precisos (correctos, coherentes)No ambiguos (formales)Completos (enlace entre distintas vistas)
• UML cubre la especificación de todas las decisiones de
Análisis (conceptual y especificación)DiseñoImplementación
que deben realizarse en un sistema con gran cantidad de software.
Introducción
7Francisco Ortín Soler
(III) Lenguaje para Construir(III) Lenguaje para Construir
• UML NO es un lenguaje de programación visual, pero sus modelos pueden traducirse a gran variedad de lenguajes de programación (Java, C++ o VB)
• Rational Rose y Sparx EA poseen facilidades para la ingeniería directa e inversa a determinados lenguajes y sistemas de componentes
• El mayor nivel de abstracción para modelar facilita la construcción de la arquitectura global del sistema, así como el diseño detallado de las partes de un proyecto y su futura implementación
Introducción
8Francisco Ortín Soler
(IV) Lenguaje para Documentar(IV) Lenguaje para Documentar
• Un producto software no es únicamenteel código ejecutable final
• El modelo de la aplicación documenta ésta para:
Mejorar la comprensión del códigoFuturas ampliacionesModificaciones y corrección de erroresRealización de pruebas de funcionamientoMigración a otras plataformas o selección de un nuevo lenguaje de programación
Introducción
3
9Francisco Ortín Soler
¿¿QuQuéé NO es UML?NO es UML?
• UML NO es un método: “proceso disciplinado para generar un conjunto de modelos que describen varios aspectos de un sistema software en desarrollo, utilizando una notación bien definida” [Booch99]
• UML NO es una metodología: “colección de métodos a lo largo del ciclo de vida del desarrollo de software unificados por alguna aproximación general” [Booch99].
• El LENGUAJE UML NO es un proceso de desarrollo software: “conjunto de actividadesnecesarias para transformar los requisitos de un usuario en un sistema software” [Jacobson99].
Introducción
10Francisco Ortín Soler
El Proceso Unificado (RUP)El Proceso Unificado (RUP)• Sobre el lenguaje UML se ha definido el proceso unificado
(RUP, Rational Unified Process)• Utilizando UML, el proceso unificado define las actividades
necesarias en un proyecto software, definiéndose como:
Dirigido por los casos de usoArtefacto básico para establecer el comportamiento deseado del sistema, validarlo, realizar pruebas y comunicar a las personas involucradas en el proyecto
Centralizado en la arquitecturaRequisitos, dominio y plataforma tecnológica
Iterativo e incremental (dirigida por el riesgo)Iterativo: Involucra creación iterativa de códigoIncremental: Continua integración en la arquitectura del sistemaRiesgo: Cada iteración ataca y reduce los riesgos más significativos para el éxito del proyecto
Introducción
11Francisco Ortín Soler
MetodologMetodologíías y UMLas y UML
• El lenguaje de modelado UML es empleado por multitud de metodologías:
Métrica 3El Proceso UnificadoOOHDM (Object-Oriented Hypermedia Design Model)CatalysisDSDM (Dynamic Systems Development Method)FusionAOSD (Aspect Oriented Software Development)
Introducción
12Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
4
13Francisco Ortín Soler
Vistas en UMLVistas en UML
• Una vista es un conjunto de construcciones en UML que representan un aspecto determinado del sistema
• Una vista en UML se representa mediante uno o varios diagramas bajo la notación UML
• Las distintas vistas se pueden clasificar en función de su semántica:
Vistas estructuralesVistas dinámicas (de comportamiento)Vista de gestión o colección de elementos
Presentación de UML
14Francisco Ortín Soler
Vistas y DiagramasVistas y Diagramas• Vistas estructurales:
Diagramas de clases (y objetos)Diagrama de casos de usoDiagramas de componentes Diagramas de despliegue
• Vistas de comportamiento:Diagrama de estadosDiagrama de actividadesDiagrama de colaboraciónDiagrama de secuencia
• Vistas de gestión o colección de elementos:Utilización de paquetes como representación de los subsistemas en los diagramas
Presentación de UML
15Francisco Ortín Soler
Arquitectura de un Sistema Arquitectura de un Sistema • La arquitectura de un sistema define los planos a un
elevado nivel de abstracción• En función de los requisitos previos del sistema,
establece las vistas más significativas de éste• Ejemplo: para desarrollar un sistema distribuido, la
arquitectura del sistema se obtendrá en función de:El tipo de cliente de la aplicación (X-net y SO)El tipo de conexión del cliente (ancho de banda)El número de clientes simultáneos estimadosLa seguridad de la conexión (SSL, TLS)El tipo de servidor(es) (SO, Ancho Banda, Administración)El tipo del SGBD a utilizar y sus característicasLas futuras ampliaciones al sistema
Presentación de UML
16Francisco Ortín Soler
Presentación de UML
Modelado de la ArquitecturaModelado de la Arquitectura
• La arquitectura de un sistema con gran cantidad de software puede describirse a través de cinco vistas relacionadas
• La obtención de éstas se lleva a cabo a través de (dirigida por) los casos de uso
Vista Estructural(lógica)
Vista de Procesos(dinámica)
Vista deImplementación
Vista de Despliegue
Vista de Casosde Uso
ModelosFísicos
ModelosLógicos
ClasesDatos Casos Uso
EscenariosRequisitos
Componentes
Interacción (Secuencia, Colaboración)ActividadesEstados Despliegue
5
17Francisco Ortín Soler
PerspectivasPerspectivas
• En función del ciclo que nos encontremos en el desarrollo de software, los diagramas describirán modelos desde distintas perspectivas [Fowler]
• Además de su significado, variarán en su nivel de detalle
Conceptual: Representa los conceptos del dominio que se está estudiando. Son independientes del lenguaje y no tienen por qué aparecer en el futuro sistemaEspecificación: Se especifica el software, observando las interfaces, no la implementaciónDiseño / Implementación: Tenemos distintas clases como implementación de los interfaces, componiendo el sistema software
Presentación de UML
18Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
19Francisco Ortín Soler
AppletApplet en Swingen Swing
• Mostraremos un primer ejemplo de vistas y diagramas en UML
• El siguiente ejemplo, es una pequeña aplicación en la plataforma Java
ejemplos/hola/hola.html
• El proyecto presentado está enejemplos/hola/hola.eap
Un Primer Ejemplo
20Francisco Ortín Soler
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers
JApplet
+ init() : void
Hola
+ init() : void+ actionPerformed(ActionListener) : void
«interface»ActionListener
+ actionPerformed(ActionListener) : void
JButton
+ getText() : String+ setText(String) : void+ addActionListener(ActionListener) : void
JLabel
+ setText(String) : void+ getText() : String
Container
+ setLayout()+ add()
«realize»
1-etiqueta 1-botón
Vista de Clases (Vista Estructural)Vista de Clases (Vista Estructural)
La perspectiva a emplear (por la sencillez del ejemplo) será de implementación
Un Primer Ejemplo
6
21Francisco Ortín Soler
id Subsistemas4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
4 00 Unregistered Trial Version EA 4 00 Unregistered Trial V
jav ax
+ JApplet+ JButton+ JLabel
java
+ Container+ ActionListener
JAppletLogical Model::Hola
+ init() : void+ actionPerformed(ActionListener) : void
Diagrama de GestiDiagrama de Gestióón o Agrupacin o Agrupacióónn
• Se usan los paquetes para agrupar elementos• En este caso, agrupamos elementos estructurales (clases)
Un Primer Ejemplo
22Francisco Ortín Soler
Diagrama de Objetos (Estructural)Diagrama de Objetos (Estructural)
• Representamos una instantánea en tiempo de ejecución de la estructura de una parte del modelo
Un Primer Ejemplo
cd Objetos00 Unregistered Trial Version EA 4.00 Unregistered Tr
00 Unregistered Trial Version EA 4.00 Unregistered Tr
00 Unregistered Trial Version EA 4.00 Unregistered Tr
00 Unregistered Trial Version EA 4.00 Unregistered Tr
00 Unregistered Trial Version EA 4.00 Unregistered Tr
00 Unregistered Trial Version EA 4.00 Unregistered Tr
00 Unregistered Trial Version EA 4.00 Unregistered Tr
:Hola
botón :JButton
text = "borrar"
etiqueta :JLabel
text = "Hola"
Instantánea de haber mostrado en la etiqueta el mensaje "Hola"
1-botón1-etiqueta
23Francisco Ortín Soler
Vista DinVista Dináámica (Diagrama Secuencia)mica (Diagrama Secuencia)
• Vista dinámica de la creación del applet
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial V
:Thread :Hola
etiqueta :JLabel
(from Logical Model)
botón :JButton
(from Logical Model)
Comienzodel Applet
init()
new
new
addActionListener(this)
Un Primer Ejemplo
24Francisco Ortín Soler
Vista de ImplementaciVista de Implementacióón (D. Componentes)n (D. Componentes)
• Diagrama en el que se muestran los elementos físicos de los que está compuesto
nregistered Trial Version EA 4.00 Un
nregistered Trial Version EA 4.00 Un
nregistered Trial Version EA 4.00 Un
nregistered Trial Version EA 4.00 Un
nregistered Trial Version EA 4.00 Un
nregistered Trial Version EA 4.00 Un
«executable»HolaMundo.class
«html»hola.html
«image»uml.gif
«artifact»Hola.java
Un Primer Ejemplo
7
25Francisco Ortín Soler
Vista y Diagrama de DespliegueVista y Diagrama de Despliegue
• Muestra cómo los componentes del sistema se distribuyen entre sus nodos computacionales
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Ve
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Ve
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Ve
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Ve
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Ve
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Ve
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Ve
4 00 Unregistered Trial Version EA 4 00 Unregistered Trial Ve
Serv idorWeb
«executable»Component
Model::HolaMundo.class
«html»Component Model::hola.html
«image»Component Model::uml.gif
Cliente
Nav egador Web*
«TCP IP»
Internet
Un Primer Ejemplo
26Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
27Francisco Ortín Soler
Diagramas de Clases (y objetos)Diagramas de Clases (y objetos)
• Modelan la vista estática estructural del sistema
• Pertenecen a la vista lógica del modelo• El diagrama de clases es la “columna vertebral”
de casi todos los métodos: la mayoría de los diagramas (excluyendo principalmente al de casos de uso) se centran en él [Fowler]
• Es el diagrama más utilizado en los modelos de sistemas orientados a objetos; son los “planos”principales [Booch]
Diagramas de Clases y Objetos
28Francisco Ortín Soler
ClasesClases
• Una clase es una implementación de un tipo(clase) de objetos
• Poseen propiedades (atributos) que definen la estructura del objeto
• Poseen operaciones (métodos) que definen el comportamiento de cada uno de los objetos
• Colaboran con otras clases para conseguir un objetivo común
• Una de las técnicas empleadas para “descubrir”clases es emplear fichas CRC (Clase-Responsabilidad-Colaboración) Wirfs-Brooks
• Enfatiza:Las relaciones entre las clasesSus responsabilidades (operaciones públicas, su interfaz)
Diagramas de Clases y Objetos
8
29Francisco Ortín Soler
Ejemplo Ficha CRCEjemplo Ficha CRC
PedidoRevisa si hay elementos en existencia Línea de Pedido
Determina precio Línea de Pedido
Revisa si el pago es válido Cliente
Despacha a la dirección de entrega
Responsabilidades Colaboraciones
Nombre de la Clase
Diagramas de Clases y Objetos
30Francisco Ortín Soler
ered Trial Version EA 4.
ered Trial Version EA 4.
ered Trial Version EA 4.
ered Trial Version EA 4
Ventana
- visible: boolean = true# tamaño: int# posición: Punto
- calcularCoordenadaZ() : int+ crear() : Ventana+ mover(int, int) : void+ dibujar(int, int) : void
Clases en UMLClases en UML
• Las operaciones y propiedades pueden tener visibilidad:
+ pública# protegida- privada
• Los tipos se separan del identificador con :
• Los atributos que producen asociaciones son se suelen explicitar (implementación)
• Los valores por defecto de los atributos se pueden especificar con =
Método de clase (static)
Método abstracto
Clase abstracta
Valor por omisión
Diagramas de Clases y Objetos
31Francisco Ortín Soler
Mecanismos de ExtensibilidadMecanismos de Extensibilidad
• UML no es un lenguaje cerrado, permitiendo extenderse de modo controlado mediante:
Estereotipos: Extiende el vocabulario de los elementos de un diagrama, permitiendo nuevos tipos de bloques de construcción. Sintaxis: <<estereotipo>>
Valores etiquetados: Extiende las propiedades de un bloque de construcción añadiendo nueva información. Sintaxis: {Etiqueta=valor}
Restricciones: Extiende la semántica de un bloque, añadiendo reglas o modificando las existentes. Sintaxis: Entre {} con lenguaje natural o con OCL (Object Constraint Language)
Diagramas de Clases y Objetos
32Francisco Ortín Soler
Mecanismos de ExtensibilidadMecanismos de Extensibilidad
- indice: int- elementos: int
+ mostrar(OutputStream) : void
{indice>elementos}
{Autor = Francisco Ortin,Versión = 1.0}
«exception»FueraRango
Trial Version EA 4.00
Trial Version EA 4.00
Trial Version EA 4.00
Trial Version EA 4.00
Trial Version EA 4.00
«exception»FueraRango
- indice: int- elementos: int
+ mostrar(OutputStream) : void
constraints{indice>elementos}
tagsAutor = Francisco OrtinVersión = 1.0
Representación en Enterprise Architect
Representación Estándar UML
Valores Etiquetados
Restricciones
Estereotipos
Diagramas de Clases y Objetos
9
33Francisco Ortín Soler
Relaciones entre ClasesRelaciones entre Clases
• Las clases se pueden relacionar con las siguientes relaciones:
AsociaciónAgregación (todo parte)Composición (agreg. exclusiva)
Generalización (herencia)Realización (implementación)
Dependencia (uso)• Cada asociación tiene dos papeles (roles) que
pueden ser etiquetados (y se puede especificar su visibilidad)
• Un papel puede tener una multiplicidadexpresada con constantes_enteras, *, ..
• Las asociaciones pueden denotar navegabilidad(sentido) mediante una flecha
Diagramas de Clases y Objetos
34Francisco Ortín Soler
Ejemplo de RelacionesEjemplo de Relaciones
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
Univ ersidad
Estudiante
Departamento
Asignatura
Titulación
Profesor
Contratado Funcionario
1..*1
1..*
impartir
1..*
1..*
1..*
1..*
docencia1..*
*
1..*
* estudiar 1..*
-carrera
1
-director
multiplicidades
navegabilidad
generalización
asociación
roles
composición
agregación
nombreasociación
Diagramas de Clases y Objetos
35Francisco Ortín Soler
Diagramas de ObjetosDiagramas de Objetos
• Modelan las instancias de los elementos contenidos en los diagramas de clases
• Muestra un conjunto de objetos y sus relaciones en un momento concreto del tiempo de ejecución
• Son la base para los diagramas de colaboración
• La sintaxis es:El nombre o tipo son opcionalesNo es necesario especificar los valores de los atributos
objeto:Clase
atributo1 = valor1atributo2 = valor2
Diagramas de Clases y Objetos
36Francisco Ortín Soler
Ejemplo de Diagrama de ObjetosEjemplo de Diagrama de Objetoslógica :Asignatura
:Universidad informática :Departamento
informática :Titulación
juan :Estudiante
manuel :Estudiante
maría :Estudiante
programación :Asignatura
JABrugos :Funcionario
AAJuan :Contratado
-director
docencia
estudiar
estudiar
estudiar
impartir
impartir
Diagramas de Clases y Objetos
10
37Francisco Ortín Soler
InterfacesInterfaces• Interfaz (interface) es:
Un tipo (conjunto de operaciones)Una capacidad de un conjunto de abstraccionesUna colección de mensajes u operaciones
• Hay lenguajes (Java), arquitecturas (CORBA), componentes (COM) y middlewares (RMI) que dan soporte a este concepto
• Una clase (o componente) implementa (realiza) varios interfaces• En UML tiene representación de icono y un estereotipo
<<interface>>00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
MiApplet
+ run() : void
«interface»Runnable
+ run() : void
JApplet
Productor
+ run() : void
Consumidor
+ run() : void
Productos
Planficador
«realize»
1 1
«realize» «realize»
*
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
00 Unregistered Trial Version EA 4.00 Unregist
MiApplet
+ run() : void
Runnable
JApplet
Productor
+ run() : void
Consumidor
+ run() : void
Productos
Planficador
«realize»
1 1
«realize»«realize»
*
Diagramas de Clases y Objetos
38Francisco Ortín Soler
Asociaciones CualificadasAsociaciones Cualificadas• ¿Cómo podría establecerse una relación entre Directorio y
Fichero?Un fichero tiene que estar en un directorioUn directorio tiene un conjunto de ficherosEl nombre del fichero ha de ser único
• Asociación Cualificada• En implementación: array asociativo, map, diccionario…
Diagramas de Clases y Objetos
egistered Trial Version EA 4.00 Unregistered
egistered Trial Version EA 4.00 Unregistered
Directorio Fichero
nombre:String1 0..1
39Francisco Ortín Soler
Clases de AsociaciClases de Asociacióónn
• Cuando necesitemos que una asociación tenga estado, ésta se puede modelar como una clase de asociación
Una persona puede tener muchos trabajos, pero sólo uno para una misma empresaEl salario NO es un atributo de la empresa ni de la persona, sino de la asociación (contrato)
Diagramas de Clases y Objetos
egistered Trial Version EA 4.00 Unregistered T
egistered Trial Version EA 4.00 Unregistered T
egistered Trial Version EA 4.00 Unregistered T
egistered Trial Version EA 4.00 Unregistered T
Persona Empresa
Trabajo
- salario: double
* *
40Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
11
41Francisco Ortín Soler
Casos de UsoCasos de Uso
• Un caso de uso es una interacción típica entre un usuario y un sistema computacional [Fowler]
• Un casos de uso especifican el comportamiento deseado del sistema (objetivos del usuario) [Jacobson]
• Describe qué hace un sistema, pero no especifica cómo lo hace [Booch]
• Un caso de uso da lugar a un conjunto de posibles escenarios
Diagramas de Casos de Uso
42Francisco Ortín Soler
Diagramas de Casos de UsoDiagramas de Casos de Uso• Un diagrama de casos de uso muestra un conjunto de casos de uso, actores y sus
relaciones. También es común mostrar los límites del sistema.
Diagramas de Casos de Uso
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E
A 4 00 U i t d T i l V i EA 4 00 U i t d T i l V i E
Sistema de Finanzas
Gerente
Comerciante
Agente de Ventas
Establecer Límites
Analizar Riesgo
Negociar Precio
Capturar Negociación
Límite Excedido
Evaluar
Actualizar Cuentas
Sistema de Contabilidad
«extend»
«include»
«include»
Actores
Casos de Uso
Límites del sistema
Relaciones
43Francisco Ortín Soler
ActoresActores• “Un actor representa un conjunto coherente de roles que
juegan los usuarios de los casos de uso al interaccionar con el sistema” [Jacobson]
• Un actor es un rol jugado por personas (no una persona) u otros sistemas
• Son externos al sistema. Pueden:Requerir al sistema el cumplimiento de un objetivo (primarios)Ser empleados para cumplir un objetivo (secundarios)
Gerente
Comerciante
Agente de Ventas
Sistema de Contabilidad
Secundario
Primarios
SistemaExterno
Roles
Pueden ser la misma persona
Diagramas de Casos de Uso
44Francisco Ortín Soler
IncludeInclude y y ExtendExtend• Además de los vínculos entre los actores y los casos de
uso, hay otros dos tipos de vínculos entre los casos de uso
• La relación include (anteriormente use) se da cuando dos CU tienen comportamiento compartido y se factoriza éste
• La relación extend indica que un caso de uso aumenta la funcionalidad de otro con un(os) caso(s) particular(es) que extienden su funcionamiento (variación de comportamiento “normal”)
Sólo se indica la interacción con los más generales
Analizar Riesgo
Negociar Precio
Capturar Negociación
Límite Excedido
Evaluar«extend»
«include»
«include»Caso particular
Funcionalidad común
Diagramas de Casos de Uso
12
45Francisco Ortín Soler
EscenariosEscenarios
• Un escenario es una sola ruta a través de un caso de uso. Una ruta que muestra una particular combinación de condiciones, dentro de un caso de uso
• Un escenario es una instancia de un caso de uso• Los escenarios suelen describirse mediante
diagramas de secuencia (colaboración)• La descripción de escenarios y CUs suele
realizarse con los siguientes datos:Nombre, Precondiciones, Postcondiciones(objetivo), Excepciones, Actores, Detalle de Operaciones (Pasos en CU)
Diagramas de Casos de Uso
46Francisco Ortín Soler
Escenario Escenario ““LLíímite Operacimite Operacióónn””
Nombre Escenario 1.1: Límite Operación.Precondiciones: No existe un límite previo a la
operación en curso.Postcondiciones: La operación ha sido validada con
límites superior y/o inferior.Excepciones: Cliente no encontrado, operación ya
restringida.Actor Principal: Gerente.Detalle Operaciones:
Obtener cliente y operación.Cliente existente en la BD.Comprobar solvencia del cliente.Operación no existente.Comprobar que los límites solicitados se
encuentran dentro de los rangos del cliente.Confirmación alta.
Diagramas de Casos de Uso
En caso contrario, sería el escenario 1.2
Si no, sería otro escenario del mismo CU
Gerente
Establecer Límites
47Francisco Ortín Soler
UtilizaciUtilizacióón de Diagramas CUn de Diagramas CU
• Jacobson define el RUP dirigido por los CU, porque éstos se pueden emplear para:
Capturar el comportamiento general deseado del sistemaComprender el sistema (desarrolladores, clientes)Validar y crear la arquitecturaObtener los requisitos del sistema (escenarios)Identificar inicialmente las clases (abstracciones) : análisisTras la implementación, validación de los casos de usos identificados (pruebas)Crear el GUI del sistema
Diagramas de Casos de Uso
48Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
13
49Francisco Ortín Soler
Diagramas de InteracciDiagramas de Interaccióónn
• Forman parte del modelo dinámico• Describen el modo en el que un grupo de objetos
interaccionan para lograr cierto comportamiento
• Muestra el modelo de un sistema, desde el punto de vista del paso de mensajes entre objetos
• Representan escenarios• Dos tipos:
Destacando la ordenación temporal de los mensajes: Diagramas de secuenciaDestacando la organización estructural de los objetos: Diagramas de colaboración
• Poseen equivalencia semántica (de uno se puede obtener el otro)
Diagramas de Interacción
50Francisco Ortín Soler
Empleo de Diagramas de InteracciEmpleo de Diagramas de Interaccióónn
• En análisis y especificación del modelo conceptual:
Se utilizan como representación (formalización) de escenariosAyudan a la comprensión del sistemaFacilitan el descubrimiento de objetos y clases
• En la fase de diseño:Facilitan la documentación del códigoFacilitan el descubrimiento de mensajes (y métodos) y atributos de una claseAyudan a comprender los roles de los objetos en cada comportamiento dinámico
Diagramas de Interacción
51Francisco Ortín Soler
Diagramas de SecuenciaDiagramas de Secuencia
• Enfatizan la temporalidad de los mensajes entre los objetos. Incluyen:
ObjetosLa línea de tiempoMensajes con argumentosCiclo de vida de los objetosInformación devuelta por un métodoEspecificación de procesos concurrentes
Diagramas de Interacción
52Francisco Ortín Soler
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
:ConsultaO :Existe :ConsultaNo :Primera
:Usuario
evaluar("hola mundo")
evaluar("hola mundo")
false
boolean:= evaluar(frase)
evaluar("hola mundo")
false
true
true
Ejemplo Diagrama SecuenciaEjemplo Diagrama Secuencia• Realización de la consulta
O( Existe(pepe) , No( Primera(adios) ) )en la frase “hola mundo”
Objetos
Mensajes Línea de vida
Devolución
Foco de control
Diagramas de Interacción
14
53Francisco Ortín Soler
Ejemplo Diagrama ColaboraciEjemplo Diagrama Colaboracióónn
• En los diagramas de colaboración, los focos de control se especifican con numeración 1, 2, 2.1, 2.2, 3…
00 Unregistered Trial Version EA 4.00 Unregistered Trial Ver
00 Unregistered Trial Version EA 4.00 Unregistered Trial Ver
00 Unregistered Trial Version EA 4.00 Unregistered Trial Ver
00 Unregistered Trial Version EA 4.00 Unregistered Trial Ver
00 Unregistered Trial Version EA 4.00 Unregistered Trial Ver
00 Unregistered Trial Version EA 4.00 Unregistered Trial Ver
00 Unregistered Trial Version EA 4.00 Unregistered Trial Ver
00 Unregistered Trial Version EA 4.00 Unregistered Trial Ver
:ConsultaO
:Existe
palabra = "pepe"
:Primera
palabra = "adios"
:ConsultaNo
::Usuario
1 evaluar("hola mundo")
1.1 evaluar("hola mundo")
1.2 false
1.3 evaluar("hola mundo")
1.3.1 evaluar("hola mundo") 1.3.2 false
1.4 true
2 true
Diagramas de Interacción
54Francisco Ortín Soler
SincronizaciSincronizacióónn
• En los diagramas de interacción (secuencia y colaboración) se pueden especificar distintos envíos de mensajes
Simple: Un solo hilo de control, el objeto activo le pasa el control al objeto pasivo (que pasa a ser activo)Síncrono: El cliente se bloquea hasta que el servidor acepta o rechaza el mensajeAsíncrono: No se interrumpe la ejecución del cliente; no se sabe cuándo se llevará a cabo la petición
Mensaje Representación UML Representación EASimpleSíncronoAsíncrono
Diagramas de Interacción
55Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
56Francisco Ortín Soler
Paquetes en UMLPaquetes en UMLDiagramas de Paquetes
• Un paquete es un mecanismo general para organizar modelos/subsistemas, agrupando elementos de modelado
• Cada paquete representa a un submodelo(subsistema) del modelo (sistema)
• Un paquete puede contener a otro paquete sin límite de anidamiento
• Un paquete no sólo se utiliza para agrupar clases, sino cualquier elemento estructural de UML
• El operador :: permite referenciar a una clase definida en un contexto distinto al actual
• La principal relación entre paquetes es de dependencia: se produce cuando los cambios en el destino generan cambios en el origen
15
57Francisco Ortín Soler
EjemploEjemplo
• Lo siguiente puede ser un diagrama de paquetes de la estructura estática de la implementación de la aplicación de Consultas, siguiendo una arquitectura MVC (Modelo / Vista / Controlador)
stered Trial Version EA 4.00 Unregistered Tri
stered Trial Version EA 4.00 Unregistered Tri
stered Trial Version EA 4.00 Unregistered Tri
stered Trial Version EA 4.00 Unregistered Tri
stered Trial Version EA 4.00 Unregistered Tri
stered Trial Version EA 4.00 Unregistered Tri
stered Trial Version EA 4.00 Unregistered Tri
stered Trial Version EA 4.00 Unregistered Tri
stered Trial Version EA 4.00 Unregistered Tri
AWTJSP
Consultas
IU Consultas HTMLIU Consultas Applet
Diagramas de Paquetes
58Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
59Francisco Ortín Soler
Diagrama de EstadosDiagrama de Estados
• Se utilizan principalmente para representar el comportamiento de las instancias de una clase
Son útiles en objetos con un comportamiento significativo basado en su estado (no para todos)
• Describen el comportamiento de un solo objeto durante todo su ciclo de vida
Se describe mediante los estados posibles en los que puede entrar un objeto particular y la manera en la que éste cambia
• Representan autómatas de estados finitos, constando de:Estados: Situación en la vida de un objeto, satisfaciendo una condición, realizando una actividad o esperando algún eventoTransiciones: Se cambia de un estado a otro, porque se produce un evento o se satisface una condición
• Los estados están caracterizados parcialmente por los valores de algunos atributos del objeto
Diagramas de Estados
60Francisco Ortín Soler
Estados y TransicionesEstados y Transiciones
• Las transiciones se representan con la sintaxis:Evento [Condición] / Acción
Evento: Acontecimiento significativo que ocupa un lugar en el tiempo (invocaciones, paso de tiempo o cambio de estado)Condición: Expresión lógica. Tienen que especificarse excluyentes ya que la máquina de estados ha de ser deterministaAcción: Computación atómica (invocación a un método, creación o destrucción de un objeto)
• Para especificar el ciclo de vida de un objeto, se utilizan
Estados iniciales Estados finales
Diagramas de Estados
16
61Francisco Ortín Soler
Ejemplo de Diagrama de EstadosEjemplo de Diagrama de Estados
Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4
Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4
Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4
Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4
Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4
Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4
Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4
Initial
Sin Préstamos
Con Préstamos
Logical View::Cliente
- DNI: int- nombre: String- númeroPrestamos: int
+ concederPréstamo()+ cancelarPréstamo()
Final
alta
solicitarPrestamo /concederPréstamo amortizar [númeroPréstamos==0] /cancelarPréstamo
baja
amortizar [númeroPrestamos>0] /cancelarPréstamosolicitarPréstamo /concederPréstamo
Diagramas de Estados
62Francisco Ortín Soler
Actividades y acciones de entrada y salidaActividades y acciones de entrada y salida
• A veces se necesita que un objeto realice una actividad al encontrarse en un estado
• Se puede definir ésta, para que se produzca ante un evento dentro del estado
• Una actividad suele ser la invocación de un método• Los eventos predefinidos son:
Entrada (entry): Al entrar en un estado, sin importar la transición ejecutadaSalida (exit): Al abandonar un estado, sin importar la transición provocadaHacer (do): Mientras se está en el estado, hasta que sea interrumpido por un evento
d Trial Version EA 4.00 Unr
d Trial Version EA 4.00 Unr
d Trial Version EA 4.00 Unr
Introducir Password
+ On Entry / buffer.clear()+ Do Action / suppressEcho()+ On Exit / buffer.compare(password)
Diagramas de Estados
63Francisco Ortín Soler
SubestadosSubestados SecuencialesSecuenciales
• Si deseamos que se entre en cualquier momento se puede cancelar la operación, podemos jerarquizar estados
• Se introducen diagramas de estados dentro de un estado y de éste se puede salir a partir de un evento
• El flujo en el diagrama mostrado es secuencial
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
A 4.00 Unregistered Trial Version EA 4.00 Unregister
Diagrama de estados de las instancias de una clase Cajero
Inactiv o
Mantenimiento
Activo
+ On Entry / leerTarjeta+ On Exit / expulsarTarjeta
Impresión
Procesamiento Opción
Selección Opción
Validación Tarjeta
reparación
finalReparación
[no continuar][continuar]
[tarjetaCorrecta]
[tarjetaIncorrecta]
tarjetaIntroducidacancelar
Diagramas de Estados
64Francisco Ortín Soler
egistered Trial Version EA 4.00 Unregistered Trial Ve
egistered Trial Version EA 4.00 Unregistered Trial Ve
egistered Trial Version EA 4.00 Unregistered Trial Ve
egistered Trial Version EA 4.00 Unregistered Trial Ve
egistered Trial Version EA 4.00 Unregistered Trial Ve
egistered Trial Version EA 4.00 Unregistered Trial Ve
egistered Trial Version EA 4.00 Unregistered Trial Ve
egistered Trial Version EA 4.00 Unregistered Trial Ve
i t d T i l V i EA 4 00 U i t d T i l V
Diagrama de estados del mantenimiento de un Cajero
Inactiv o
ManenimientoPruebas
Órdenes
Probar Periféricos
Probar Monitor
Espera Orden
reparación finalReparación
[noContinuar]
[continuar]
pulsarTecla
SubestadosSubestados ConcurrentesConcurrentes• Pueden jerarquizarse los estados para denotar, dentro de
un estado, concurrencia• En este caso, una vez dentro del superestado, existirán dos
subestados activos
Diagramas de Estados
17
65Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
66Francisco Ortín Soler
Diagramas de ActividadesDiagramas de Actividades
• Es un diagrama de comportamiento dinámico• El significado de actividad depende de la perspectiva del
diagrama:Conceptual: Una actividad es una tarea que debe ser llevada a cabo por una persona o computadoraEspecificación o Implementación: Una actividad es un método de una clase
• Los diagramas de actividades son útiles para:La especificación y compresión de un flujo de trabajoAnálisis de casos de uso y escenarios (es probable que sea muy difícil tener objetos)Aplicaciones multihilo
• No son útiles para especificar:Colaboración entre objetos (diagramas de interacción)Comportamiento de objetos (diagramas de estados)
Diagramas de Actividades
67Francisco Ortín Soler
EjemploEjemploEA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4 00 Unregistered Trial Version EA 4 00 Unregistered Trial Version EA 4 0
Diagrama de actividades del funcionamiento de una máquina de bebidas
Pedir Bebida
Poner Café
Poner Filtro Añadir Agua Obtener Taza
Hacer Café
Serv ir Café
SeleccionarBebida
Explusar Bebida
Av isarUsuario
[existe]
[refresco]
[agotada]
[café]
condición
bifurcación secuencialdivisión
concurrente
uniónconcurrente
actividades
inicial
final
Diagramas de Actividades
68Francisco Ortín Soler
CallesCalles• Los diagramas de
actividades dicen qué sucede, pero no quién lo realiza
Dominio: No indica quéentidad realiza la actividadImplementación: No se especifica la clase
• Las calles o carriles (swimlanes) subsanan esta deficiencia
Combinan la lógica de la secuencia con las responsabilidades de cada calle
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
Indicador Cafetera Expendedora Voz
Diagrama de actividades del funcionamiento de una máquina de bebidas
Pedir Bebida
Poner Café
Poner Filtro Añadir Agua Obtener Taza
Hacer Café
Serv ir Café
SeleccionarBebida
Explusar Bebida
Av isarUsuario
[existe]
[refresco]
[agotada]
[café]
Diagramas de Actividades
18
69Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
70Francisco Ortín Soler
Diagramas de ComponentesDiagramas de Componentes
• Componente: Parte física y reemplazable de un sistema
que conforma un conjunto de interfaces yProporciona una implementación (clases)
• Modela ejecutables, bibliotecas, tablas, ficheros, documentos, componentes…
• Modela parte de la vista física del sistema• Residirán en los nodos del sistema (diagrama de
despliegue)• Las relaciones de dependencia se emplean para
designar que un componente emplea los servicios de otro
Diagramas de Componentes
71Francisco Ortín Soler
ObjetivosObjetivos
• Básicamente su utilidad es a nivel de implementación y arquitectura
Implementación de componentes reales (COM+, EJB, CORBA).Futura sustitución binaria de versiones.Especificación de tablas (BD), archivos auxiliares o documentos utilizados.Modelado de un API en función de sus interfaces y módulos o componentes.Organización de la aplicación en archivos fuente
Diagramas de Componentes
72Francisco Ortín Soler
EjemploEjemplo
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio
A 4 00 Unregistered Trial Version EA 4 00 Unregistered Trial Versio
«COM»MS CryptoAPI
Comunicacion.dll
Comunicación
AutenticaciónTransaccionesITransacciones
Compras.exe
Datos
JDBC
LDAP
«artifact»Logo.gif
«send»
Componentes (código fuente o ejecutable)
Artefactos (elemento físico)
Interfaces Dependencias
Assembly: Relación “requiere”
Diagramas de Componentes
19
73Francisco Ortín Soler
ContenidosContenidos
• Introducción• Presentación de UML• Un Primer Ejemplo• Diagramas de Clases y Objetos• Diagramas de Casos de Uso• Diagramas de Interacción• Diagramas de Paquetes• Diagramas de Estados• Diagramas de Actividades• Diagramas de Componentes• Diagramas de Despliegue
74Francisco Ortín Soler
Diagrama de DespliegueDiagrama de Despliegue
• Modela la topología hardware del sistema• Pertenece a la vista física del sistema• Un nodo es un elementos físico que representa
un recurso con capacidad computacional• En los nodos se despliegan y ejecutan
componentes• Los arcos (interconexiones) representan
conexiones físicas entre nodos• Los estereotipos permiten precisar las
características de los equipos y conexiones
Diagramas de Despliegue
75Francisco Ortín Soler
EjemploEjemploEA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.0
Serv idor Web
Serv idor LDAP
«oracle»SGBD
Component Model::Datos
Component Model::LDAP
Component Model::
Transacciones
Cliente Web
iexplore.exe
Cliente Gráfico
Component Model::Compras.
exe
«COM»Component Model::MS CryptoAPI
Component Model::
Autenticación ATM
2SSL
1
TCP/IP
*
IP:8080
*Multiplicidad
Conexiones
Nodos
Componentes
Diagramas de DespliegueUniversidad de Oviedo
Lenguajes y Sistemas InformáticosDepartamento de Informática
Francisco Ortín Solerortin@lsi.uniovi.es
Lenguaje UMLLenguaje UML((Unified Modeling LanguageUnified Modeling Language))