Lenguaje UML Unified Modeling Language · PDF file• Diagramas de Clases y Objetos •...

1

Universidad de OviedoLenguajes y Sistemas Informáticos

Departamento de Informática

Francisco Ortín [email protected]

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


¿¿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


¿¿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


(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


(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


(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


(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


¿¿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


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


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




4


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


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



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




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


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






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


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


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

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


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






: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


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








:Thread :Hola

etiqueta :JLabel

(from Logical Model)

botón :JButton

(from Logical Model)

Comienzodel Applet

init()

new

new

addActionListener(this)

Un Primer Ejemplo


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






«executable»HolaMundo.class

«html»hola.html

«image»uml.gif

«artifact»Hola.java

Un Primer Ejemplo

7


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

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





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


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)


8


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



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



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)



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





«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


9


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



Ejemplo de RelacionesEjemplo de Relaciones

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 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



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


10


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





MiApplet

+ run() : void

«interface»Runnable

+ run() : void

JApplet

Productor

+ run() : void

Consumidor

+ run() : void

Productos

Planficador

«realize»

1 1

«realize» «realize»

*







MiApplet

+ run() : void

Runnable

JApplet

Productor

+ run() : void

Consumidor

+ run() : void

Productos

Planficador

«realize»

1 1

«realize»«realize»

*



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…


egistered Trial Version EA 4.00 Unregistered

egistered Trial Version EA 4.00 Unregistered

Directorio Fichero

nombre:String1 0..1


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)


egistered Trial Version EA 4.00 Unregistered T




Persona Empresa

Trabajo

- salario: double

* *




11


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


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.













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


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



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


12


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)



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.


En caso contrario, sería el escenario 1.2

Si no, sería otro escenario del mismo CU

Gerente

Establecer Límites


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





13


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


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 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



A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version









:ConsultaO :Existe :ConsultaNo :Primera

:Usuario

evaluar("hola mundo")


false

boolean:= evaluar(frase)


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


14


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








: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



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






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


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









AWTJSP

Consultas

IU Consultas HTMLIU Consultas Applet

Diagramas de Paquetes





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


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


16


Ejemplo de Diagrama de EstadosEjemplo de Diagrama de Estados

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



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



Introducir Password

+ On Entry / buffer.clear()+ Do Action / suppressEcho()+ On Exit / buffer.compare(password)



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











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



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


17





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


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

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



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












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é]


18





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


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



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

«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”


19





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


EjemploEjemploEA 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 [email protected]

Lenguaje UMLLenguaje UML((Unified Modeling LanguageUnified Modeling Language))

Lenguaje UML Unified Modeling Language · PDF file• Diagramas de Clases y Objetos •...

Documents

Transcript of Lenguaje UML Unified Modeling Language · PDF file• Diagramas de Clases y Objetos •...