[1]

Lenguaje Unificado de Modelado2.0

Arquitecturas de Sistemas TelemáticosDr. Ing. Álvaro Rendón Gallón

Cali, mayo de 2012

Especialización en Telemática

2Temario

• Modelado del Software• MDD: Desarrollo basado en modelos• Debilidades de UML 1.4• Mejoras de UML 2.0• Diagramas de estructura• Diagramas de comportamiento• Diagramas de interacción

[2]

3Frente a los riesgos de desarrollo …

4… construir modelos• Modelo:

– “Representación en pequeña escala”Diccionario Larousse

– “Abstracción de algo con el propósito de entenderloantes de construirlo”

Rumbaugh (OMT)

[3]

5Del modelo a la implementación

Pero existe una brecha entre el modelo y la implementación:• Diferencia en los materiales de construcción• Diferencia en los métodos de construcción• Efectos de escala

Una de las funciones del modelo es conducir la implementación

6

: Analista: IU_Inicio : Gestión : Tarjeta: IU_MenuPpal

1: Activa

3: ID_Clave

5: validarAcceso( ID, Clave) 6: buscarCódigo( ID)

7: leerContraseña( )

8: Activa

4: AceptarClick( )

2: Activa

El software tiene la rara propiedad de que permite transformarlos modelos en implementaciones completas sin cambiarlos medios, herramientas y métodos de ingeniería

Tipos de modelos:• Informal, formal, semi-formal

Inicio

FrmAcceso CtrlAcceso«submits»

Menu

«builds»

«query»Usuarios

Diagrama de Clases de Diseño

IdentificadorClave

Modelado de Software

Usuarios

AnalistaCtrlAccesoIU_Acceso

IU_Menu

Diagrama de Clases de Análisis

[4]

7Modelos informales

• Uso de figuras y lenguaje natural, con ayuda de tablas yotros elementos– SA/RT (Structured Analysis for Real-Time Systems)

– DARTS (Design Approach for Real-Time Systems)

– HRT-HOOD (Hard Real-Time Hierarchical Object OrientedDesign)

– ROOM (Real-time Object-Oriented Modeling)

– Octopus

• De uso extendido debido a que son muy intuitivos y norequieren una formación muy especializada

• No pueden ser interpretados por máquinas

8Especificación SA/RT

[5]

9Modelos formales

• Uso de notaciones con sintaxis y semántica definidas desde elpunto de vista matemático– Lógicas temporales: Expresión de propiedades.

Ej: CTL (Computational Tree Logic)– Álgebras de procesos: Representación de comportamiento.

Ej: SDL (Specification and Description Language)– Redes de Petri Temporizadas: Formalismo gráfico para

modelar comportamiento

• Su base matemática hace posible la verificación automáticade propiedades pero tienen problemas con sistemas de grantamaño

10

SPECIFICATION DataLink [ in, out ] ( credit : SeqNum ) : noexitBEHAVIOUR

( transmitter [ in, tx_info, tx_ack ] (0, 0, succ(succ(succ(succ(0)))))|||

receiver [ out, rx_info, tx_ack ] (0))|[ tx_info, tx_ack, rx_info, rx_ack ]|line [ tx_info, tx_ack, rx_info, rx_ack ]

WHEREPROCESS transmitter [ in, tx_info, tx_ack ]

( ns : SeqNum, nr : SeqNum, credit: SeqNum ) : noexit :=( [ ns lt (nr + credit) ] ->

in ?data:BitString; tx_info !info !ns !data; transmitter [ in, tx_info, tx_ack ] (succ(ns), nr, credit)

[] [ not (nr equal ns) ] ->tx_ack !ack !succ(nr) !empty (* ack arrives *)

; transmitter [ in, tx_info, tx_ack ] (ns, succ(nr), credit))

ENDPROC

Tx line Rxin

tx_ack rx_ack

rx_infoout

tx_info

Especificación LOTOS

[6]

11Modelos semi-formales• Combinan los tipos de notación anteriores o su definición

matemática no es muy rigurosa– Statemate statecharts– UML

• La representación gráfica con semántica formal se vefavorecida por el avance en la potencia de las máquinas

12Utilidad de los modelos de software

Para inspección• Ejecución mental• Poco confiable

Para análisis formal• Confiable• Aplicación limitada

Para ejecución• Más confiable que inspección• Experiencia directa

!

[7]

13Desarrollo basado en modelosMDD: Model Driven Development

Requisitos de los modelos:• Ejecutables• Que se puedan traducir a la implementación en forma

automática• … posiblemente para diferentes plataformas de

implementación (PIM: Platform Independent Models)

Requisitos del lenguaje de modelado• Su semántica de soporte debe ser precisa (no ambigua)• Debe permitir especializarlo al dominio de aplicación

“El modelo es la implementación”

14

.NET

Arquitectura basada en modelosMDA: Model Driven Architecture

Conjunto de estándares que dan soporte al desarrollo basado enmodelos (MDD).

Proceso de desarrollo MDA:

PIMPlatform Independent

Model

Transformación Transformación

Código

CCM

EJB

PSMPlatform Specific

Model

[8]

15Debilidades de UML 1.4UML es el fundamento de MDAPero debe superar algunas debilidades:• No explota suficientemente el potencial de MDD• Capacidades inadecuadas de modelado• Demasiado complejo• Definición inadecuada de la semántica

– Definición informal

• No posee capacidades de intercambio de diagramas• No está completamente alineado con MOF*

(*MetaObject Facility: Lenguaje de modelado para definir lenguajes de modelado)

16Mejoras de UML 2.0

• Soporte al desarrollo basado en componentes medianteestructuras compuestas (Clases y Componentes)

• Descomposición jerárquica de la estructura y elcomportamiento

• Integración cruzada de estructura y comportamiento

• Integración de la semántica de acciones a lasconstrucciones de comportamiento

• Estructura por niveles para facilitar la implementaciónincremental y las pruebas de compatibilidad: Básico,Intermedio y Completo.

[9]

17Especificación de UML 2.0

• Se divide en cuatro partes:– UML Infrastructure: Define las construcciones

fundamentales del lenguaje

– UML Superstructure: Define las construcciones delnivel de usuario

– OCL (Object Constrain Language): Lenguaje formaldefinido para describir expresiones en UML

– Diagram Interchange: Permite el intercambio dedocumentos UML entre diferentes herramientas

18Diagramas de UML 2.0

• Diagramas de Estructura– Diagrama de Clases– Diagrama de Objetos– Diagrama de Componentes– Diagrama de Estructuras

Compuestas– Diagrama de Paquetes– Diagrama de Implantación

• Diagramas de Comportamiento– Diagrama de Casos de Uso– Diagrama de Actividad– Diagrama de Máquinas de Estado

• Diagramas de Interacción– Diagrama de Secuencias– Diagrama de Comunicación– Diagrama de Tiempos– Diagramas de Descripción de

Interacciones

[10]

19Diagrama de Clases

(Sparx Systems, 2008)

Clase de asociación: Especificacaracterísticas propias de unaasociación

Interfaz ofrecidaInterfaz requeridaPuerto: Agrupa interfaces para una

determinada interacción

20Diagrama de Objetos

(Sparx Systems, 2008)

[11]

21Diagrama de Componentes

(Sparx Systems, 2008)

22Diagrama de Estructuras Compuestas

(Kobryn and Samuelsson, 2003)

Presenta la estructura interna de Clases y Componentes

[12]

23Diagrama de Paquetes

(Sparx Systems, 2008)

24Diagrama de Implantación

(Sparx Systems, 2008)

[13]

25Diagrama de Casos de Uso

(Douglass, 1999)

26Diagrama de Actividad

(Sparx Systems, 2008)

Manejador de Excepción:Especifica la acción a realizarcuando ocurre una excepción

Evento de EntradaEvento de Salida

[14]

27Diagrama de Máquinas de Estado

(Sparx Systems, 2008)

Regiones concurrentes

Acciones en los estados:Acción de EntradaAcción de Salida

28Diagrama de Secuencias

(Sparx Systems, 2008)

Mensaje de retorno

Inicio y final de un hilo

Combinación de fragmentos: Bucle (enla figura), alternativos (if-then-else),opcionales, paralelo, etc.

[15]

29Diagrama de Comunicación

(Sparx Systems, 2008)

Nuevo nombre para el Diagrama de Colaboración

30Diagrama de Tiempos

(Sparx Systems, 2008)

Despliegan el cambio en el estado o el valor de uno o más elementos a lolargo del tiempo. También puede mostrar la interacción entre eventostemporizados y las restricciones de tiempo y duración que los gobiernan

[16]

31Diagrama de Descripción de Interacciones

(Schmuller, 2004)

Es una forma de Diagrama de Actividades, en el cual los nodosrepresentan diagramas de interacción (Secuencias, Comunicación)

ref

Find book

ref

Leave Library

ref

Borrow book

RequestItem

Item found

sd Sale

book not found

32Referencias• Hogg, J. (2003). “Brass Bubbles. An Overview of UML 2.0 (and MDA)”.

Tutorial. Fourth Workshop On UML for Enterprise Applications: Deliveringthe Promise of MDA. Burlingame, USA. June 23-26. Disponible en:http://www.omg.org/news/meetings/workshops/uml_2003.htm

• Kobryn, C. and E. Samuelsson (2003). Driving Architectures with UML 2.0.Telelogic White Paper. Disponible en: http://www.uml-forum.com/pubs.htm

• OMG (2007). "Introduction to OMG's Unified Modeling Language (UML)".Disponible en: http://www.omg.org/gettingstarted/what_is_uml.htm

• Sparx Systems (2008). “UML 2 Tutorial”. Disponible en:http://www.sparxsystems.com.au/resources/uml2_tutorial/index.html

• Schmuller, J. (2004). Sams Teach Yourself UML in 24 Hours, Third Edition.Sams Publishing. Disponible en: http://freebookshare.com/

• Douglass, B.P. (1999). "Doing Hard Time: Developing Real-Time SystemsWith UML, Objects, Frameworks, and Patterns". Addison-Wesley.