tema2

TEMA 2. EL LENGUAJE DE MODELADO UNIFICADO

Gloria Margot Gonzales FernandezIngeniero en Informática

Instituto Superior Jesús María Fé y AlegríaMateria: Análisis y Diseño de Sistemas II

Curso: 3ero de Análisis de Sistemas

2

Contenido

Introducción Modelado estructural Modelado del comportamiento Modelado arquitectónico

3

UML es un lenguaje de modelado de software: Proporciona un vocabulario y reglas para crear modelos

softw. Suficientemente expresivo para cubrir distintas vistas de la

arquitectura del software a lo largo del ciclo de vida. Mayor nivel de abstracción que un lenguaje de

programación. UML es un lenguaje para visualizar los elementos

de un gran sistema software, facilitando: la comunicación entre los participantes (incluidas

herramientas) en el desarrollo, la comprensión de las soluciones (notación gráfica), el mantenimiento de las soluciones conceptuales a lo largo

del tiempo (documentación).

4

UML es un lenguaje para especificar software: Se pueden construir modelos precisos, no ambiguos y

completos. Cubre las decisiones de análisis, diseño e implementación.

UML es un lenguaje para construir software: No es un lenguaje de programación visual, pero sus

modelos se pueden conectar de forma directa a una gran variedad de ellos.

Correspondencias entre UML y lenguajes: Java, C++, etc. Ingeniería directa: generación de código. Ingeniería inversa: reconstrucción de modelos.

UML es un lenguaje para documentar: requisitos, arquitectura, diseño, código fuente, pruebas, ...

5

El modelo conceptual está compuesto por 3 bloques de construcción básicos: Elementos

Abstracciones básicas a partir de las que se construyen los modelos

Relaciones Entre los elementos

Diagramas Grupo consistente de elementos y sus relaciones

Qué es UML ?

El UML modela sistema mediante el uso de objetos que forman parte de él así como, las relaciones estáticas o dinámicas que existen entre ellos.

UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños.

Diagramas empleados por UML

1. Diagrama de Casos de Uso

2. Diagrama de Clases

3. Diagrama de Actividades

4. Diagrama de Iteración

4.1. Diagrama de Secuencia

4.2. Diagrama de Colaboración

Diagramas empleados por UML

5. Diagrama de Estados

6. Diagrama de Implementación

6.1. Diagrama de Componentes

6.2 Diagrama de Despliegue

9

UML: El LenguajeE

lem

ento

s

Estructurales

Comportamiento

Agrupación

Anotación

Clase

Interfaz

Colaboración

Caso de uso

Clases activs

Componente

Nodo

Interacción

Máquina de estados

Paquetes

Frameworks

Modelos

Subsistemas

Nota

Clase

atributos

métodos

IInterfaz

Colaboración

Caso de UsoClase Act

atributos

métodosComponente

Nodo

Interacción

Estado

Paquete

Nota

10

UML: El LenguajeR

elac

ione

s Dependencia

Asociación

Generalización

Realización

Dia

gram

as

Diagrama de clases

Diagrama de objetos

Diagrama de casos de uso

Diagrama de secuencia

Diagrama de colaboración

Diagrama de estados

Diagrama de actividades

Diagrama de componentes

Diagrama de despliegue

0..1 *

role1 role2

11

UML: El LenguajeR

egla

sM

ecan

ism

osNombres

Ámbito

Visibilidad

Integridad

Ejecución

EspecificacionesAdornos

Divisiones comunes

Extensiones

Entidad

Instancia

Estereotipo

Valor etiquetado

Restricción

Cliente

nombredirección

preferencial()

IUnknown

IOrtografía

Elena:Cliente

ColaEventos{vers = 3.2autor=eps}

añadir()quitar()vaciar()

«exception»Overflow

{ordenado}

asistOrtog.dll

:Cliente

12

Modelado Estructural: Modelo de Objetos

Describe estructura de los objetos de un sistema: identidad, relaciones con otros objetos, atributos y operaciones

Es el más característico del Diseño O.O.

Gráficamente: diagramas de clases diagramas de instancias

13

Clases e Instancias

Cliente

nombredirección

comprar

José:Cliente

José Pérez

:Cliente

Claudia

14

Atributos y Operaciones

Clase

atributos

operaciones

Cada atributo es único en la claseSólo datos “simples” y NO otros objetosOpcionalmente, tipo y valor por defecto

Funciones o procedimientosCada operación tiene un objeto destino implícitoSe puede aplicar la misma operación a clases distintasOpcionalmente, lista de argumentos y tipo devuelto (no omitir)

15

Punto

x: floaty: float

trasladar(dx:float, dy:float)distancia(pto: Punto) : float

:Punto

x=0y=0

:Punto

x=3.5y=2.25

:Punto

x=1y=2

16

EEPROM

EEPStartEEPStopenviarDir(dir:Tparam)EnviarByte(dato:Tvalor)Control(accion:integer)EEPAckEEPNoAck

:EEPROM

17

Protocolo

EntradaCombo(m: TMensajeMovil)LIGBM()LL_ENT()SILEN()FIN_LIG()INTBM()FIN_LLENT()CODSEG()FININTB()

mensaje: TMensajeMovilmovil_origen: TIdMovil

Combo

MandarRegRx(c: Tcanal)MandarRegTx(c: Tcanal)MandarReg0(c: Tcanal)MandarRegMode(c: Tcanal)MandarRegGain(c: Tcanal)MandarRegRefP(c: Tcanal)LeerPortadora()LeerCabecera()EscribirCabecera()EscribirDato(m: TMensajeBase)LeerDato(m: TMensajeMovil)SubirSquelch()BajarSquelch()RestituirSquelch()

estado: TEstadoCombomovil_origen: TIdMovil

Visibilidad de Clases

Especificación que denota si una carácterística de una clase puede ser utilizada por otros clasificadores Public (+) .- Cualquier clasificador externo Protected (#) .- Cualquier descendiente Private (-) .- Solo el propio clasificador

Clases - Atributos

Representan el nivel más abstracto al que se modelan las características estructurales de las clases.

De forma general la sintaxis de un atributo contiene: [visibilidad] nombre [multiplicidad] [: tipo]

[=valor inicial] [{propiedades}]

Clases - Atributos

Cuáles de las siguientes declaraciones son válidas? Origen + origen & origen *Cabeza: Item Nombre [0..+] : String Id: Integer {frozen} Id: Integer = {0,0}

OK

OK

NO

NO

NO

OK

OK

Clases - Operaciones

Representan el nivel más abstracto al que se modelan las carácterísticas comportamentales de una clase

De forma general la sintaxis de un atributo contiene: [visibilidad] nombre [(lista de parámetros)] [: tipo de

retorno] [{propiedades}]

Clases - Operaciones

Cuáles de las siguientes declaraciones son válidas?mostrar+ mostrarset(n: nombre, s: string) (0,0)obtenerID() :Integerreiniciar() :{concurrent}

OK

OK

NO

OK

NO

23

Enlaces y Asociaciones

Enlace: conexión entre dos o más instancias

Asociación: abstracción de un grupo de enlaces

Todos los enlaces de una misma asociación: conectan objetos de las mismas clases tienen una semántica común

Asociaciones inherentemente bidireccionales

Pueden ser: binarias, ternarias o de orden superior

24

Asociaciones

0 o 1Muchos

n Exactamente nm,n m o nm-n Entre m y nn+ Más de n

Exactamente 1Direccionalidad

Multiplicidad

Clase

atributos

operaciones

Clase

atributos

operaciones

asociación

25

Punto

x: floaty: float

trasladar(dx:float, dy:float)distancia(pto: Punto) : float

Línea

trasladar(dx:float, dy:float)distancia(pto: Punto) : floatrotar(ang: float)

intersecta +2

punto_referencia

ángulo: float

P1:Punto

P2:Punto

P3:Punto

L4:Línea

L3:Línea

L2:Línea

L1:Línea P2P1

L1

P3

L2

L3L4

26

GestorLEDs

inicializar()llamadaEntrante()tomaDeLínea()colgar()pilaBaja()modoContestador()...

leds

6

LED

ident: LEDID

parpadea(te:Duration, ta:Duration)

27

Proyecto Lenguaje

Persona

C:Lenguaje

CentralNuclear:Proyecto

Luis:Persona

Ensamblador:LenguajeEole400:Proyecto

Fortran:Lenguaje

José María:Persona

28

Asociaciones con Atributos

Las asociaciones pueden tener atributos

Propiedad de la asociación. No puede incluirse en ninguna de las clases asociadas

Cuando hay multiplicidad 1/1 o 1/M, el atributo puede incluirse en la clase de multiplicidad 1

A veces, este tipo de asociación se puede modelar como una clase independiente

29

Clase

atributos

operaciones

Clase

atributos

operaciones

atributo

30

Fichero Usuario

permiso de acceso

acceso

Empresa Persona

sueldopuesto

trabajo

31

Roles

Un rol es un extremo de una asociación

Una asociación binaria tiene dos roles Se pueden nombrar explícitamente:

para recorrer asociaciones, y para especificar direccionalidad

Los nombres de los roles: deben ser únicos en asociaciones que parten de

una misma clase son necesarios para asociaciones entre objetos de

la misma clase

32

Clase

atributos

operaciones

Clase

atributos

operaciones

rol rol

asociación

33

propietario

usuario_autorizadosubdirectorios

Usuario Directoriopadre

34

recepción

emisión

Protocolo

EntradaCombo(m: TMensajeMovil)LIGBM()LL_ENT()SILEN()FIN_LIG()INTBM()FIN_LLENT()CODSEG()FININTB()

mensaje: TMensajeMovilmovil_origen: TIdMovil

Combo

...

estado: TEstadoCombomovil_origen: TIdMovil

CtrlCombo

ultimoCanal: Tcanalestado: TEstadoCtrlComboinicioComunicaciónfinComunicaciónenviarMensaje(m:TMensajeBase)noPortadora

mensajes

35

Temporización

tEncendido:DurationtApagado: DurationtSilencio: Duration

LED

ident: LEDID


led_que_enciende

36

Restricciones en Asociaciones

Con las propiedades vistas hasta ahora se pueden modelar la mayoría de las relaciones estructurales

Sin embargo, existen algunas que son más fácilmente expresables con las siguientes restriciones {ordered}/{sorted} indica que los objetos están

ordenados {implicit} indica que la relación no es manifiesta,

solo conceptual {changeable} se pueden modificar los enlaces {addonly} solo se pueden añadir {frozen} no se pueden modificar

37

Clase

atributos

operaciones

Clase

atributos

operaciones

{ordered}

asociación

38

Ventana{ordered}

visibilidadPantalla

Alumnos{sorted}

calificaciónCurso

39

Puerto

leerNivel()

Teclado

ultimaTecla

...

{ordered}

puertosTeclado

40

Asociaciones Calificadas

Relacionan dos clases y un calificador

El calificador es un atributo especial que: reduce la multiplicidad de la asociación, clasifica el conjunto de objetos del extremo

“muchos”, puede considerarse como una asociación

ternaria.

Partición disjunta de la asociación

41

Clase

atributos

operaciones

Clase

atributos

operacionesasociación

Clase

atributos

operaciones

Clase

atributos

operacionesasociacióncalificador

disminuye multiplicidad

42

Empresa Personaempleados

empleadosdepartamentoEmpresa Persona

Directorio Filecontenido

contenidonombreDirectorio File

43

GestorLEDs

inicializar()llamadaEntrante()tomaDeLínea()colagar()pilaBaja()modoContestador()...

ledsPuerto

3

LED

ident: LEDID


Temporización

tEncendido:DurationtApagado: DurationtSilencio: Duration

led

tipoEvento

parpadeoLed

44

Restricciones

A veces es necesario especificar restricciones sobre objetos asociados sobre atributos de un objeto sobre la vida de los objetos sobre enlaces

Se expresan en lenguaje natural o con fórmulas

45

Empleado

salario

directivo

subordinado

{salario < directivo.salario}

Ventana

anchuraaltura

{anchura<altura}

presidente

Persona {subconjunto} Comisión

miembro

46

Agregación

La agregación es un tipo especial de asociación

Modela la relación “ser parte de” Transitiva y antisimétrica Es usual la propagación de

operaciones entre un objeto y sus componentes

La existencia de un objeto componente suele depender de la existencia del objeto compuesto

47

Clase

atributos

operaciones

Clase

atributos

operacionesasociación

48

vértices

Polígono

dibujar()

Punto

dibujar()

dibujar

49

Puerto

leerNivel()

{ordered}

puertosTeclado

3Teclado

...

ultimaTecla

InterfazExterno

Display LED

6

50

Agregación Fija (lámpara)

Variable (empresa-departamento)

Recursiva (sentencia-bloque)

No es implementable eficientemente. En algunos casos puede llegar a no permitirse.

Bloque

Sentencia

S. Simple

*

Departamento

Empresa

*

Lámpara

PieBombillaTulipa

51

Herencia

Generalización o Especialización Encapsulamiento de

características comunes Reutilización y Extensión En la notación gráfica:

Posible uso de “discriminadores” Herencia disjunta y no disjunta Redefinición de métodos Clases abstractas Herencia múltiple

52

SuperClase

atributos

operaciones

SubClase

atributos

operaciones

SubClase

atributos

operaciones

SubClase

atributos

operaciones

...

discriminador

Herencia consolapamiento

Herencia condiscriminador

53

Punto Figura

área(): float {abstract}perímetro(): float {abstract}

Elipse

área(): float perímetro(): float

Polígono

perímetro(): float

Triángulo

área(): float

Cuadrado

área(): float

Círculo

perímetro(): float

54

LEDPuerto

encender()apagar()

LEDRegistro

GestorLEDs

inicializar()llamadaEntrante()tomaDeLínea()colagar()pilaBaja()modoContestador()...

LED

ident: LEDID


ledsRgto33

ledsPto

6

leds

55

Herencia Múltiple

La herencia múltiple permite a una clase tener más de una superclase, heredando las características de todos sus padres.¯ Complica las jerarquías de herencia, que dejan de ser árboles para

convertirse en grafos. Incrementa las posibilidades de reutilización.¯ Pérdida de simplicidad conceptual y de implementación.

Problemas: conflictos y herencia repetida.

Computador Identificación

DNI PC Smart Card

56

Herencia Repetida

Se puede Prohibir situaciones conflictivas (C++, Eiffel) Usar un heurístico para linealizar el árbol de herencia

(CommonLoops) Prohibir la herencia múltiple (Java)

Vehículo

Vehículo Terrestre Vehículo Acuático

Bote Coche Vehículo Anfibio

57

Relaciones de Dependencia

Dependencia=Relación de uso

Se da cuando el cambio en un elemento puede afectar a otro elemento que lo utiliza pero no necesariamente a la inversa

Etiquetas especiales: bind (el destino es una plantilla instanciada por el origen)

instantiate (el origen crea instancias del destino)

instanceOf (el origen es instancia del destino)

refine (el origen está a un grado de abstracción más detallado que el destino)

use (la semántica del origen depende de la del destino)

destino*origen

58

Ampliando los modelos Notas

Expresa comentarios o aclaraciones relativas a un elemento o grupo de ellos.

Responsabilidades Contrato u obligación de una clase Se expresan mediante texto libre

Estereotipos Crea nuevos tipos de bloques de

construcción específicos al problema que se modela. No confundir con superclase.

Se expresa mediante un nombre entre comillas tipográficas.

ControlVentas

Responsabilidades--determinar validez venta--comunicar a Almacen y Contabilidad

No controla saldo del cliente

<<excepción>>VentaRechazada

razón

59

Adornos para Clasificadores Son elementos de

modelado que pueden tener instancias Interfaz, Tipo de

datos, Señal, Componente, Nodo, Casos de uso, Subsistema.

Visibilidad+ Public# Protected- Private

Alcanceinstanciaclasificador

Tarjeta

+ GetSaldo: long+ Recarga(long cant)+ Comprobar(long cant):boolean

- Saldo:long- PIN:int# Límite:long = 25.000

60

Especificación de Atributos Formato atributos

[visibilidad] nombre [multiplicidad] [:tipo] [=valor inicial] [{propiedades}]

Propiedades predefinidas: changeable, addOnly, frozen

Tarjeta

+ GetSaldo: long+ Recarga(long cant)+ Comprobar(long cant):boolean

- Saldo:long- PIN [1..*] : int {addOnly}# Límite:long = 25.000

61

Especificación de Operaciones Formato operaciones

[visibilidad] nombre [(lista parámetros)] [:tipoDevuelto] [{propiedades}]

Propiedades predefinidas: isQuery, ...(para concurrencia)

Formato parámetros[dirección] nombre : tipo [=valor defecto]

direcciones: in,out, inout

Tarjeta

+ GetSaldo: long {isQuery}+ Recarga(long cant)+ ComprobarPIN(int pinPrueba):boolean

- Saldo:long- PIN [1..*] : int {addOnly}# Límite:long = 25.000

62

Interfaces Interfaz: colección de operaciones que se usa

para especificar un servicio de una clase o componente.

Tarjeta Multifunción

IIdentificación IPago

Si es necesario puede representarse como una clase estereotipada. No tendrá atributos ni métodos; sólo operaciones.

<<interface>>IPago

GetSaldo()Recarga()

Las operaciones pueden incluir adornos como estereotipos, valores etiquetados, restricciones y propiedades de visibilidad y concurrencia.

63

Paquetes Un paquete es un elemento de propósito general

para organizar elementos del modelo en grupos. Puede contener clases, interfaces, nodos,

colaboraciones, casos de uso, diagramas e incluso otros paquetes.

Un paquete forma un espacio de nombres. Estereotipos estándar: framework, subsystem, system stub, facade +FormularioDePedido

+FormularioDeEstado- Pedido

Cliente

64

Paquetes Visibilidad.

+FormularioDePedido+FormularioDeEstado- Pedido

Cliente

<<import>>

Importación y Exportación.

+Ventana+Formulario#GestorEventos

GUI

exportación

Generalización.

WinGUILinuxGUI

65

Consejos Prácticos No lanzarse a dibujar clases y asociaciones sin sentido. Intentar que el modelo sea simple, evitando

complicaciones innecesarias. Los nombres deben ser significativos. No incluir en los objetos punteros a otros objetos. Utilizar, si es posible, asociaciones binarias. Utilizar

preferentemente asociaciones calificadas en vez de ternarias o con atributos.

Dejar la definición de la multiplicidad para cuando se tenga un mejor conocimiento del problema.

No incluir los atributos de las asociaciones en las clases. Evitar las jerarquías de composición o generalización de

muchos niveles. Revisar el modelo hasta que sea satisfactorio. Documentar el modelo. Utilizar sólo los elementos necesarios.

Diagramas en UML y su uso

Diagramas deCasos de Uso

Diagramas deSecuencia

Diagramas deColaboración

DiagramasDe Clases

Diagramas deEstados

Diagramas deActividad

Diagramas deComponentes

Diagramas deDistribución

Diagramas deActividad

Captura de Requisitos

Análisis y Diseño Implementación

67

Contenido

Introducción Modelado estructural Modelado del comportamiento

Modelado Básico Interacciones Diagramas de interacción Casos de uso y diagramas Diagramas de actividades

Modelado Avanzado Modelado arquitectónico

68

Interacciones

DefiniciónUna interacción es un comportamiento que implica un intercambio de de mensajes entre varios objetos en un contexto determinado con un objetivo determinado

Se utilizan para expresar los aspectos dinámicos de las colaboraciones

Las interacciones se llevan a cabo entre objetos no entre clases

Un enlace es una conexión semántica entre objetos Para que se pueda enviar un mensaje entre dos objetos

debe existir un enlace Un enlace es una instancia de una asociación entre clases

69

Interacciones

Persona

Asignar(d:Departamento)

Empresa

empleado contratante

1..* *

P:Persona :Empresa

Asignar(desarrollo)

Enlace

Asociación

70

Interacciones

Normalmente basta con indicar que existe un enalce, pero se puede indicar el tipo de enlace utilizando los estereotipos: Association Self Global Local Parameter

Los mensajes también pueden ser más o menos detallados [Pre] 1:*(expr):mensaje(p,q):Valor

Precondición

ParámetrosExpresiónIteración

IdentificadorNº secuencia

Valor deRetorno

71

Diagramas de Interacción

Hay dos tipos: Diagramas de secuencia Diagramas de colaboración

Son dos de los cinco que se utilizan para modelar el comportamiento dinámico de los sistemas

Un diagrama de interacción consiste en: Un conjunto de objetos (no clases) y sus

relaciones Los mensajes que se pueden enviar entre

ellos

72


Un diagrama de secuencia es un diagrama en el que se destaca la ordenación temporal de los eventos

Un diagrama de colaboración destaca la organización estructural de los objetos que envían y reciben los mensajes

Son semánticamente equivalentes Se puede generar uno a partir del otro, sin perdida de

información Visualmente, sin embargo, esta información puede ser

más difícil de percibir

Diagramas de Secuencia

Hacen énfasis en la ordenación temporal de los mensajes.

Se coloca a la izquierda el objeto que inicia la interacción y a la derecha los objetos subordinados.

Muestran la “línea de vida” de la secuencia completa

Muestran el “foco de control” como un rectángulo delgado que representa el tiempo que se ejecuta una acción.

Diagrama de Secuencia

Diagramas de Secuencias

1: Acepta tarjeta2: Lee Num. Tarjetas

3: Inicializa pantalla 4: Abre cuenta

5: Solicita PIN6: Da PIN

7: Verfica PIN8: Solicita Transacción9: Selecciona Transacción10: Solicita Cantidad11: Captura Cantidad

12: Retira Dinero13: Verifica Fondos

14: Descuenta Cantidad

15: Da dinero16: Da recibo

17: Expulsa Tarjeta

Lector Tarjeta

s

Pantalla

Captura

CuentaJoe

Ranura de

dineroJoe: cliente

76

Diagramas de Secuencia Los diagramas de secuencia se suelen asociar a los casos

de uso, mostrando como estos se realizan a través de interacciones entre sociedades de objetos

: InstructorConsola Instructor

BDinstructores

1: login(usuario)2: leer(usuario)

3: usuario correcto

4: iniciar sesion

5: usuario aceptado

Foco deControl

Línea deVida

77

Diagramas de Secuencia Los mensajes se

corresponden generalmente a métodos de los objetos

Los objetos pueden ser creados durante la ejecución

En Rational Rose, la creación de objetos no se puede reflejar de la forma estándar

: Alumno

ClienteAplicación

InterfazCliente

Sesion

1: login

2: crear sesion

3: create

4: logout

5: fin 6: destroy

78

Diagramas de Secuencia

Diagramas de Colaboración

Muestran la organización de los objetos de una interacción de modo estructural.

Se dibujan los objetos a manera de nodos en un grafo.

Se representan los enlaces y los adornos. Muestran el camino entre los enlaces Incluyen un número para especificar el

orden en la secuencia de interacción. Son semanticamente equivalentes a los

diagramas de secuencia.

Diagrama de Colaboración

6: Da PIN9: Selecciona Transacción11: Captura Cantidad

5: Solicita PIN 8: Solicita Transacción 10: Solicita Cantidad 7: Verfica PIN

12: Retira Dinero 3: Inicializa pantalla1: Acepta tarjeta 13: Verifica Fond

2: Lee Num. 14: Descuenta Cantidad Tarjetas

4: Abre cuenta 17: Expulsa Tarjeta

15: Da dinero16: Da recibo


Pantalla

Captura

Joe: cliente

CuentaJoe

Lector Tarjeta

s

Ranura de

dinero

82


Destacan la organización de los objetos que participan en una interacción

Es un grafo en el que los nodos son los objetos y los arcos los enlaces

Los arcos se etiquetan con los mensajes que envían y reciben los objetos

Dan una visión del flujo de control en el contexto de la organización de los objetos que colaboran

83


Hay dos características que los distinguen de los diagramas de secuencia: El camino

Para indicar como se enlazan los objetos se utilizan estereotipos en los extremos de los enlaces (local, global y self)

El número de secuencia Para indicar la ordenación de los mensajes se

utiliza la numeración decimal de Deway (1, 1.1,.....)

84


85

Equivalencia entre Diagramas

Utilizando el submenu Browse se puede generar un diagrama a partir del otro

: Instructor

Consola Instructor

BDinstructores

1: login(usuario)

2: leer(usuario)

3: usuario correcto

4: iniciar sesion

5: usuario aceptado


BDinstructores


3: usuario correcto

4: iniciar sesion

5: usuario aceptado

86


No tienen por que utilizarse sólo para los casos de uso

Son útiles para modelar aspectos dinámicos de cualquier interacción entre cualquier instancia en cualquier vista del sistema (clases, interfaces, componentes,...)

Las interacciones se pueden “adornar” con restricciones temporales (marcas temporales)

87



BDinstructores


3: usuario correcto

4: iniciar sesion

5: usuario aceptado

inicio

fin

{inicio-fin<10s}

{Iniciar sesion.executionTime<5s}

Casos de Uso, Qué son?

Caso de Uso: Descripción de un conjunto de secuencias

de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor

Actor: Se refiere a los distintos roles que los

usuarios juegan al interactuar con los casos de uso.

Diagramas de Casos de Uso

Contienen: Casos de Uso, Actores y Relaciones de dependencia, generalización y

asociación Usos comunes:

Para modelar el contexto del sistema Para modelar los requisitos del sistema

Caso de Uso - Ejemplo

Caso de Uso – Modelado de un Contexto

Caso de Uso – Modelado de Requerimientos

Resumiendo Casos de Uso - Secuencia

1. Identificar QUIÉN(es) va(n) a utilizar el sistema directamente --- Ese (esos) será(n) nuestro(s) actor(es).

2. Tomar uno de esos actores3. Definir lo que el actor quiere hacer con el sistema4. Para cada uno de estos escenarios (caso de uso) decida

cuál sería la forma natural de interacción5. Hacer una descripción de alto nivel de la interacción

actor – sistema (cuando el actor hace “x”, el sistema hace “y”)

6. Considere ahora los casos extendidos de uso (aquellos menos naturales pero posibles)

7. Repita los pasos 2 al 7 para cada actor

April 15, 2023 94

Casos de Uso

Se utilizan para especificar el comportamiento deseado del un sistema o subsistema Describe el conjunto de secuencias de acciones que

lleva a cabo el sistema para producir un resultado para un actor.

Capturan el comportamiento deseado del sistema, sin especificar como se lleva a cabo dicho comportamiento

Principalmente son un medio de comunicación para que los desarrolladores y los usuarios lleguen a un consenso en la especificación

Ayudan a validar el sistema durante el desarrollo

95

Casos de Uso

Los casos de uso son principalmente descripciones textuales

La notación gráfica de UML (diagrama de casos de uso) solo muestra los nombres y sus relaciones

Al ser textuales, son informales y no son buenas para razonar acerca del sistema Es mejor utilizar los diagramas de interacción

resultantes de su formalización

96

Casos de Uso

Un caso de uso es una descripción de las posibles secuencias de interacción entre el sistema y actores externos en relación a el objetivo de un actor particular

Un caso de uso sigue normalmente cuatro fases:

1. El actor envía al sistema una petición y los datos necesarios para llevarla a cabo

2. El sistema valida la petición y los datos3. El sistema altera su estado interno4. El sistema devuelve el resultado al actor

97

Casos de Uso

Los casos de uso se pueden detallar a muy distintos niveles de granularidad

Se suelen distinguir los siguientes niveles: Nivel de resumen: muestran ciclo de vida de la

secuencia de objetivos directamente relacionadas. Se pueden considerar como una tabla de contenidos de

casos de uso de niveles más detallados Nivel de usuario: describen el objetivo del actor cuando

intenta llevar a cabo una acción sobre el sistema Nivel de subfunción: son casos de uso requeridos para

llevar a cabo los de usuario, con un mayor nivel de detalle Pueden ser considerados prácticamente como manuales de

operación

April 15, 2023 98

Casos de Uso

Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con ellos Normalmente representan a una persona, un

dispositivo hardware u otro sistema al interactuar con el nuestro

Se pueden definir categorías generales de actores y especializarlos a través de la relaciones de generalización

Los actores se conectan a los casos de uso mediante asociaciones.

April 15, 2023 99

Casos de Uso

100


Se pueden organizar en paquetes Se pueden especificar relaciones entre

ellos: generalización extensión inclusión

Estas relaciones se usan para: Factorizar el comportamiento común

extrayendo un comportamiento de los casos en que se incluye

Factorizar variantes poniendo ese comportamiento en otros casos de

uso que lo extienden

101


Generalización El caso de uso hijo hereda el comportamiento y

el significado del caso de uso padre El hijo puede añadir o redefinir el

comportamiento del padre El hijo se puede colocar en cualquier lugar en

que aparezca el padre Inclusión

El caso de uso base incorpora explícitamente el comportamiento del caso de uso incluido

El caso de uso incluido forma parte de otro más complejo

Se utiliza para evitar describir flujos repetidos

102


sesión alumno

controlCI

cambiar estado

modificar parámetros

Instructorlogin

logout

acciones instructor

sesion instructor <<include>>

<<include>>

<<include>>

control backtrack

103


Extensión Se utilizan para modelar la parte de un

caso de uso que puede ser vista como un comportamiento opcional

También se pueden utilizar para modelar un subflujo separado que solo se ejecuta bajo ciertas condiciones Un ejemplo es el modelado de varios flujos

que se puedan dar en un punto dado por la interacción explicita con un actor

104


Alumno

identificación

sesion alumno

<<include>>

Acción errónea

Acciones de Alumno

<<include>><<extend>>

Todos los valores

Petición de valores

Valores cambiados Selección

Activar vble dinámica

105


Nacional

Internacional

Llamado Recibir Llamada

Llamada no atendida

<<extends>>

Llamante

Numero no existe

Comunicando

No hay linea

Realizar Llamada<<extends>>

<<extends>>

<<extends>>

Marcar Número<<includes>>

Numero Incorrecto

<<extends>>

106


Cliente

Correo

Transferir DineroObtener un Balance

Sacar Dinero

Ciclo de Vida Cuenta

Ingresar Dinero

Cajero

Identificar Cliente

<<includes>>

Cajero Automático

Identificar Cliente y Cuenta en Cajero Automático

<<includes>> <<includes>>

<<includes>>

<<includes>>

<<includes>>

<<includes>>

107

Casos de Uso

Niveles: Resumen

Ciclo de vida Cuenta Usuario

Ingresar Dinero Transferir Dinero Obtener un Balance Sacar Dinero

Subfunción Identificar Cliente Identificar Ciente y Cuenta en Cajero Automático

108

Cuestionario de Casos de Uso

Se utilizan para dar un formato uniforme a la explicación textual de los casos de usoCaso de uso: Nombre del caso de usoEste es el objetivo del caso de uso descrito con una frase cortaÁmbito: La “caja negra” considerada Nivel: Uno de los tres niveles anterioresContexto de uso: Una frase más larga con la descripción del objetivo y las condiciones normales de desarrolloActor Principal: Un nombre de rol del actor principal o su descripción Escenario de Éxito Principal: ...Extensiones: ...

Caso de uso: Nombre del caso de usoEste es el objetivo del caso de uso descrito con una frase cortaÁmbito: La “caja negra” considerada Nivel: Uno de los tres niveles anterioresContexto de uso: Una frase más larga con la descripción del objetivo y las condiciones normales de desarrolloActor Principal: Un nombre de rol del actor principal o su descripción Escenario de Éxito Principal: ...Extensiones: ...

109


Escenario de Éxito Principal:

Número_de_Paso "." descripción_de_acciónSe numeran todos los pasos del escenario desde el

disparo al objetivo Se pueden anidar, utilizando numeración de Dewey

(3.1.2)No se deben incluir sentencias condicionales; las

condiciones y alternativas se muestran en la parte de extensión

Extensiones: ...

Escenario de Éxito Principal:

Número_de_Paso "." descripción_de_acciónSe numeran todos los pasos del escenario desde el

disparo al objetivo Se pueden anidar, utilizando numeración de Dewey

(3.1.2)No se deben incluir sentencias condicionales; las

condiciones y alternativas se muestran en la parte de extensión

Extensiones: ...

110


Extensiones: Condición especial ":" Descripción de acción

| sub-caso de uso

Siempre se refiere a un paso del escenario principal

Una extensión o sustituye al paso principal o es una alternativa. La notación utilizada es:

Sustitución: 2 || Alternativa: 2a

Una alternativa puede corresponder a un comportamiento regular, excepcional recuperable o erróneo no recuperable

Extensiones: Condición especial ":" Descripción de acción

| sub-caso de uso

Siempre se refiere a un paso del escenario principal

Una extensión o sustituye al paso principal o es una alternativa. La notación utilizada es:

Sustitución: 2 || Alternativa: 2a

Una alternativa puede corresponder a un comportamiento regular, excepcional recuperable o erróneo no recuperable

111

EjemploCaso de uso: Ciclo de Vida de Cuenta

Ámbito: El sistema completo Nivel: ResumenContexto de uso: Para interactuar con el sistema el cliente es representado por un cajero o por cajero automáticoActor Principal: Cliente

Caso de uso: Ciclo de Vida de Cuenta

Ámbito: El sistema completo Nivel: ResumenContexto de uso: Para interactuar con el sistema el cliente es representado por un cajero o por cajero automáticoActor Principal: Cliente

112

EjemploEscenario de Éxito Principal: 1. Un cliente informa al cajero de que quiere abrir una

cuenta 2. En representación del cliente el cajero inicia la

apertura de la cuenta en el sistema3. El sistema solicita al cajero la siguiente

información:NombreDirecciónDNITipo de Cuenta

4. El sistema valida la información y crea la cuenta del cliente

Escenario de Éxito Principal: 1. Un cliente informa al cajero de que quiere abrir una

cuenta 2. En representación del cliente el cajero inicia la

apertura de la cuenta en el sistema3. El sistema solicita al cajero la siguiente

información:NombreDirecciónDNITipo de Cuenta

4. El sistema valida la información y crea la cuenta del cliente

113

EjemploEscenario de Éxito Principal:

Los pasos del 5 al 8 son opcionales, individualmente repetibles y pueden ocurrir en cualquier orden

5. El cliente ingresa dinero – sub-caso de uso6. El cliente obtienen un balance – sub-caso de uso7. El cliente saca dinero – sub-caso de uso8. El cliente transfiere dinero – sub-caso de uso9. Este paso se repite indefinidamente una vez al mes

desde la fecha de apertura hasta fecha de cierreEl Sistema envía por correo ordinario la información de su cuenta al cliente

10. El cajero, en representación del cliente, inicia el cierre de la cuenta

11. El sistema elimina la cuenta12. El sistema envia un balance con los últimos

movimientos

Escenario de Éxito Principal: Los pasos del 5 al 8 son opcionales, individualmente repetibles y pueden ocurrir en cualquier orden

5. El cliente ingresa dinero – sub-caso de uso6. El cliente obtienen un balance – sub-caso de uso7. El cliente saca dinero – sub-caso de uso8. El cliente transfiere dinero – sub-caso de uso9. Este paso se repite indefinidamente una vez al mes

desde la fecha de apertura hasta fecha de cierreEl Sistema envía por correo ordinario la información de su cuenta al cliente

10. El cajero, en representación del cliente, inicia el cierre de la cuenta

11. El sistema elimina la cuenta12. El sistema envia un balance con los últimos

movimientos

114

Ejemplo

Extensiones: 4a. El sistema informa que el cliente ya tiene una cuenta

de este tipo abierta 4a.1. El sistema solicita al cajero que confirme la

creación de la cuenta4a.2a. El cajero confirma la creación y el caso de

uso continua por el paso 3 4a.2b. El cliente decide no crearla y el caso de

uso finaliza sin ningún efecto sobre el estado

........

Extensiones: 4a. El sistema informa que el cliente ya tiene una cuenta

de este tipo abierta 4a.1. El sistema solicita al cajero que confirme la

creación de la cuenta4a.2a. El cajero confirma la creación y el caso de

uso continua por el paso 3 4a.2b. El cliente decide no crearla y el caso de

uso finaliza sin ningún efecto sobre el estado

........

115

Casos de Uso. Resumen

Los diagramas de casos de uso pueden ser vistos como un mapa general de las funcionalidades más importantes des sistema

Deben ser lo suficientemente claros para que alguien externo al sistema los entienda

Los casos de uso se deben utilizar para: Modelar el contexto del sistema

Especificar las fronteras e identificar los actores Modelar los requisitos del mismo

Especificar que debe hacer el sistema desde el punto de vista externo

116

Casos de Uso. Resumen

Los casos de uso son la base para establecer las pruebas del sistema Para este cometido deben ir refinandose a lo

largo del desarrollo También pueden utilizarse en ingeniería

inversa. En este caso los pasos a seguir son: Identificar cada actor que interactúa con el

sistema Trazar el flujo de eventos del sistema ejecutable

en relación con cada actor Agrupar flujos relacionados en casos de uso Organizarlos utilizando las relaciones vistas

117

Contenido


Modelado Básico Interacciones Diagramas de interacción Casos de uso y diagramas Diagramas de actividades

Modelado Avanzado Modelado arquitectónico

April 15, 2023 118

Diagramas de Actividades

Se pueden considerar un caso especial de máquina de estados en la que: La mayoría de los estados son actividades La mayoría de las transiciones se disparan

implícitamente por la terminación de acciones Diferencias con un diagrama de estados.

Un diagrama de actividad se usa para modelar una secuencia de acciones en un proceso

Un diagrama de estados para modelar los estados discretos de un objeto a lo largo de su ejecución.

119

Solicitar Producto

Recibir Pedido

Pagar Factura

Procesar Pedido

Facturar al Cliente

Cerrar Pedido

Extraer Artículos

Enviar Pedido


120

Diagramas de ActividadElementos Básicos

Estado Inicial

ActividadAcción

EstadoEstado

Condición

Actividad

Actividad

Transiciónsin Disparador

División Unión

Estado Final

121

Diagramas de Actividad

Estados: Las acciones son un tipo especial de estado UML no impone un lenguaje para expresar las acciones,

pero se suele utilizar la sintaxis y semántica de un lenguaje de programación

Transiciones: Son transiciones sin disparadores o de terminación El flujo de control pasa inmediatamente al siguiente

estado después de finalizar la tarea del estado origen El flujo continua indefinidamente hasta que se

encuentra un estado de parada (puede haber flujos infinitos)

122

Diagramas de Actividad

Bifurcación: Tienen una entrada y dos o más salidas En cada transición de salida se incluye una guarda Se puede dejar una salida sin especificar (else) UML no impone el lenguaje de las guardas (también

se suele utilizar un lenguaje de programación especifico)

Asignar Tareas

Replanificar

SeleccionarTrabajos

[Hay Materiales]

123

Calles y Flujos de Objetos Calles

Representan una división de actividades en grupos, normalmente asignados a objetos o subsistemas

Cada calle tiene un nombre único en un diagrama Existe una relación entre calles y flujos concurrentes

Flujos de Objetos Se pueden asignar objetos concretos a actividades y reflejarlos en el diagrama También se puede indicar como cambian sus atributos, su estado y sus roles a

lo largo del flujo

124

Calles y Flujos de Objetos

Solicitar Producto

Recibir Pedido

Pagar Factura

Procesar Pedido

Facturar al Cliente

Cerrar Pedido

Extraer Artículos

Enviar Pedido

ClienteCliente VentasVentas AlmacenAlmacen

O:Pedido[en progreso]

O:Pedido[completado]

125

Diagramas de Actividad. Usos Comunes

Son diagramas de tipo general que pueden involucrar la actividad de cualquier tipo de abstracción en cualquier vista (clases, componentes, nodos,...)

Sin embargo, se suelen utilizar para: Modelar un flujo de trabajo

Se hace hincapié en actividades tal y como las ven los actores

Para modelar una operación Se utilizan como diagramas de flujo, para modelar los

detalles de una computación

126

Diagramas de Actividad. Modelado de una operación

Pueden hacer de UML un lenguaje de programación visual, pero éste no es el objetivo

Sólo se debe utilizar en el caso de que sea un comportamiento: Complejo y difícil de entender analizando el código Especialmente importante y que sirva de

documentación de algún aspecto fundamental del sistema

Se pueden utilizar tanto en ingeniería directa como en ingeniería inversa

127

Diagramas de ActividadModelado de una operación

return Punto(0,0)

do/ x=(l.delta-delta)/(pendiente-l.pendiente);

do/ y=(pendiente*x)+delta;

return Punto(0,0)

return Punto(x,y)

Punto Linea::intersec (L:Linea)

{

if (pendiente==l.pendiente) return Punto(0,0)

int x= (l.delta-delta)/(pendiente-l.pendiente);

int y=(pendiente*x)+delta;

return Punto(x,y);

}

Punto Linea::intersec (L:Linea)

{

if (pendiente==l.pendiente) return Punto(0,0)

int x= (l.delta-delta)/(pendiente-l.pendiente);

int y=(pendiente*x)+delta;

return Punto(x,y);

}

128

Contenido


Modelado Básico Modelado Avanzado

Eventos y Señales Máquinas de Estados Procesos y Hebras

Modelado arquitectónico

129

Eventos y Señales

En UML un evento es la especificación de un acontecimiento significativo que ocupa un lugar en el tiempo y en el espacio.

En el contexto de las máquinas de estados modelan los estímulos que producen un cambio de estado.

Los eventos pueden ser: Síncronos:invocación de operaciones. Asíncronos:señales, paso del tiempo

130

Eventos y Señales

Declaración de un evento

<<Signal>>

Colgar Inactivo

Activo

Colgar / cortarConexion()

<<signal>>

131

Eventos

Tipos: Externos: entre el sistema y sus actores

(interrupción, pulsación de una tecla,...) Internos: entre los objetos del sistema

Se pueden modelar 4 tipos de eventos: Señales Eventos de llamada Paso del tiempo Cambio de estado

132

Señales

Son objetos con nombre enviados (lanzados), asíncronamente por un objeto y capturados por otro.

El tipo más común de señales internas son las excepciones, tal y como son soportadas por los lenguajes de programación.

Son una clase en sentido general: Pueden existir instancias Pueden existir relaciones de generalización Pueden tener atributos y operaciones

Se generan como resultado de una transición en una máquina de estados de un objeto

134

Señales

La relación entre una operación y los eventos que puede generar se modela con una relación de dependencia estereotipada como send.

colisión

fuerza : Float

(from eventos)

Agente de movimiento

posición

velocidad

moverA()

(from eventos)

<<send>>

135

Eventos de Llamada

Representan la invocación de una operación de un objeto

Son eventos síncronos Cuando un objeto invoca una operación

sobre otro objeto que tiene una máquina de estados: el control pasa del emisor al receptor el evento dispara la transición la operación acaba el receptor pasa a un nuevo estado y el

control regresa al emisor

136

Eventos de Llamada

No existen señales visuales para distinguir un evento de señal de un evento de llamada, sólo el contexto del modelo

La operación aparecerá declarada en la lista de operaciones del objeto receptor

Una señal será manejada por la máquina de estados y un evento de llamada por un método

137

Eventos de Tiempo y Cambio

Un evento de tiempo representa el paso del tiempo

Se modela con la palabra after seguida de una expresión

El tiempo se mide desde el instante en el que se entra en el estado

Un evento de cambio representa un cambio en el estado o el cumplimiento de alguna condición

Se modela con la palabra when seguida de una expresión booleana

138

Eventos de Tiempo y Cambio

Inactivo

Activo

When (11:49pm) / autotest()

after(2 seg) / cortar conexión

Aunque un evento de cambio modela un test continuo, normalmente se transforma en condiciones puntualesdiscretos en el tiempo

Aunque un evento de cambio modela un test continuo, normalmente se transforma en condiciones puntualesdiscretos en el tiempo

139

Envio y Recepción de Eventos Los eventos de llamada y de señal implican al

menos dos objetos (el que lo provoca y el que lo trata)

En ocasiones es necesario modelar el envio de una señal a un conjunto de objetos (mulicasting) o a todos los objetos de sistema (broadcasting).

Multicasting Se representa un objeto que envía una señal a una

colección que contendrá un conjunto de receptores Broadcasting

Se mostrará un objeto que envía una señal a otro objeto que representa el resto del sistema

140

Señales y Clases Activas Los eventos de llamada que pueda recibir un

objeto se modelan como operaciones Las señales que puede recibir un objeto se

reflejan en un compartimento extra de la clase

No son las declaraciones de las señales, sino su uso.

gestor de Teclado

estado

tipo

reset()

SeñalespulsarBoton(b:boton)

encendidoapagado

141

Modelado de una familia de señales

En los sistema dirigidos por eventos, las señales forman una jerarquía

Se pueden generar eventos polimórficos y/o eventos abstractos (para ajustar la jerarquía)

Una familia de señales se modela principalmente para especificar los tipos de señales que puede recibir un objeto activo

142

Modelado de una familia de señales

Señal de robot

fallo hardwarecolision

sensor : integer

fallo batería fallo mecanico Fallo de visión fallo de rango

Atasco Motor

Abstractas

143

Modelado de Excepciones

Cuando se especifica un interfaz o una clase, además de atributos y operaciones, es conveniente especificar las excepciones

Las excepciones son un tipo de señales y se modelan como clases estereotipadas

Se asocian a la especificación de las operaciónes

Son lo contrario que las familias de señales: Se modelan para especificar las excepciones que puede

generar un objeto a través de sus operaciones

144

Modelado de Excepciones

Excepción

establecerManejador()

primerManejador()

ultimoManejador()

Conjunto

añadir()

eliminar()

Duplicado

Overflow

Underflow<<send>><<send>>

<<send>>

145

Contenido



Eventos y Señales Máquinas de Estados Procesos y Hebras Diagramas de estados


146

Máquinas de Estados

Una máquina de estados especifica la secuencia de estados por la que pasa un objeto durante su vida

La evolución se produce a causa de eventos, bien internos, bien enviados desde otro objeto

También se pueden utilizar para modelar el comportamiento dinámico de otros elementos de modelado (instancias de una clase, un caso de uso o un sistema completo).

147

Máquinas de estados

Relación con otros diagramas: Diagramas de interacción. Modelan el

comportamiento de una sociedad de objetos, mientras que la máquina de estados modela el comportamiento de un objeto individual

Diagramas de actividades. Se centran en el flujo de control entre actividades, no en el flujo de control entre estados. El evento para pasar de una actividad a otra es

la finalización de la anterior actividad

148

Máquinas de estados

Elementos: Estado: condición o situación de un objeto durante la cual:

se satisface alguna condición se realiza alguna actividad se espera algún evento

Evento: especificación de un acontecimiento significativo que ocupa un lugar en el tiempo y en el espacio en el contexto de las máquinas de estados, un estímulo que

puede disparar una transición entre estados Transición: relación entre dos estados que indica como los

objetos cambian de estado (eventos+condiciones) Actividad:ejecución no atómica en curso dentro de una

máquina de estados Acción: computación atómica ejecutable que produce un

cambio de estado en el modelo o devuelve un valor

149

Inactivo

Activo

Timeout

do/ mensaje timeout

Tono de marcado

do/ reproducir tono

Marcando

Invalido

do/ Mensaje invalido

Espera

Hablando

Comunicando

do/ tono comunicando

Sonando

do/ tono llamada

Conexión

Timeout

do/ mensaje timeout

Tono de marcado

do/ reproducir tono

Marcando

Invalido

do/ Mensaje invalido

Espera

Hablando

Comunicando

do/ tono comunicando

Sonando

do/ tono llamada

Conexión

after( 15 seg ) tecla( t )[ incompleto ]

tecla( t )[ completo ]

conectado

ocupado

tecla( t )[ invalido ]

after( 15 seg )

tecla( t )

responde / habilitar voz

usr. llamado cuelga

descuelga / tono de marcado

cuelga / desconectar

150

Estados

Elementos: Nombre (puede ser anónimo) Acciones de entrada/salida (al entrar y salir del

estado) Transiciones internas (se manejan sin cambiar

de estado) Subestados: estructura anidada que engloba

subestados: Secuenciales: subestados disjuntos, es decir

activos secuencialmente Concurrentes: activos concurrentemente

Eventos diferidos: lista de eventos que no se manejan en eses estado, pero que no se pierden

151

Estados

152

Estados

Acciones de entrada/salida: Se utilizan cuando al entrar o salir de un

estado se requiere realizar una acción Son independientes de la transición por la que

se llega o por la que se abandona el estado Se puede lograr el mismo efecto con una

máquina de estados plana, pero sería necesario especificar estas acciones en cada entrada y salida

No pueden tener parámetros, ni guardas Se representan con entry/acción, exit/acción

dentro del estado

153

Estados

Transiciones Internas: Son transiciones como respuesta a eventos

que deben ser manejados sin abandonar el estado

Son distintas de las autotransiciones: En las autotransiciones, se abandona el estado y

se vuelve a él Se ejecutan las acciones de entrada y de salida Pueden tener eventos con parámetros y guardas Son básicamente interrupciones

Se representan mediante transición/acción, dentro del estado

154

Estados

Actividades: Cuando un objeto esta en un estado, puede no

estar ocioso, sino ejecutando alguna tarea Estas tareas son las actividades y se ejecutan

de forma continuada hasta que se recibe un evento

Para representarlas se utiliza la transición do/actividad

Se pueden especificar secuencias do/a1;a2;a3 En este caso las acciones no se interrumpen,

pero la actividad se puede interrumpir entre acciones.

155

Estados

Eventos diferidos: En UML, sólo los eventos especificados son tratados Si un evento llega y no esta especificado el

comportamiento en ese estado, se pierde Si se quiere conservar un evento, pero no se quiere

tratar, hay que especificarlo como diferido Existe una cola interna donde se almacenan estos

eventos Son tratados tan pronto como el objeto entra en un

estado que no difiere estos eventos Se especifica nombre_evento/defered, dentro del

estado

156

Estados

Diagramas de Estados

Representan autómatas de estados finitos Especifica la secuencia de estados por los que

pasa un objeto a lo largo de su vida en respuesta a eventos.

Un estado es una condición en la vida de un objeto durante la cual satisface alguna condición, realiza alguna actividad o espera algún evento.

Un evento es un acontecimiento significativo que ocupa un espacio y un tiempo y que produce un estímulo que puede disparar una transición.

Una transición es una relación entre dos estados especificada por la aparición de un evento.

Diagramas de Estados

Generalización Sirve para reducir la complejidad de un

diagrama de estados Se definen así subestados y superestados Los subestados heredan las variables de

estado y las transiciones internas

155 www.dsic.upv.es/~uml

Generalización de Estados

Ejemplo:

A B

C

e1

e2

e2

III. El Paradigma OO: Diagrama de Estados


Quedaría como:

C

a bA Be1

e2

Generalización de Estados



Las transiciones de entrada deben ir hacia subestados específicos:

C

a bA B

e1

e2

e0

… Generalización de Estados



Es preferible tener estados iniciales de entrada a un nivel de manera que desde los niveles superiores no se sepa a qué subestado se entra:

C

a bA B

e1

e2

e1

e0

… Generalización de Estados


Diagramas de Estado

Abrir

Cerrar

SobregiroNoficar a cliente

Retiro [balance <0]

Depósito [balance <0]

Verifica Balance[Balance <0 for >30 días]

ClienteSolicita

Cancelación

Partes de Estados y Transiciones

Estados Nombre Acciones de I /

O Transiciones

internas Subestados Eventos

diferidos

Transiciones Estado origen Evento de

disparo Condición de

guarda Acción Estado destino

Estado Inicial Estado Final

162

Transiciones

Una transición tiene cinco partes Estado orígen Evento de disparo Condición de guarda Acción Estado destino

Una transición puede tener: Muchos Orígenes (join): unión de estados

concurrentes Muchos Destinos (fork): división en múltiples

estados concurentes

163

Transiciones

Initialization

Registration

Closed

Open

exit/ update database

do/ refresh screen

on select window( window )/ display new window

Closed

Open

exit/ update database

do/ refresh screen

on select window( window )/ display new window

Cancelled

Cancel course

Add student / Set

count = 0

Add student[ Count < 10 ]

[ Count = 10 ]

^CourseReport.Create

164

Subestados

Ayudan a simplificar las máquinas complejas

Pueden ser concurrentes y secuenciales Subestados secuenciales:

Sólo un estado dentro del subestado está activo al mismo tiempo

Se pueden especificar transiciones comunes a todos los subestados (cancelar en el ejemplo)

Pueden tener o no un estado inicial Cómo máximo pueden tener un estado inicial

y otro final

165

Subestados

idle

inicializar( Nombre Simulador )

freeze

Cargar IC

cargar nueva IC

En Ejecución

EsperarConfirmación

run

Enviar Información

Interpretar comando

EsperarConfirmación

run

Pasar a Run[ IC cargada ] ^Gestor MC.pasar_a_run

Enviar Información

freeze

run

Interpretar comando

after 0.5 seg

comando simulación

H*

166

Subestados

Estados de historia Cuando una transición entra en un subestado

compuesto, por defecto, la máquina anidada empieza de nuevo su ejecución, a menos que la transición sea a directa

A veces se requiere recordar el último subestado que estaba activo antes de abandonar el subestado compuesto

Ej. ¿Cómo se podría hacer con una máquina plana?

En UML un estado de historia permite que se recuerde el último subestado

167

Subestados El símbolo representa una historia superficial,

recuerda el estado de la submáquina inmediata Para recordar el estado más interno a cualquier

profundidad se utiliza

H

H*

168

Subestados

Subestados concurrentes: Permiten especificar dos o más submáquinas que se

ejecutan en paralelo en el contexto del objeto Para describir un subestado concurrente es necesario

especificar un estado por cada submáquina En lugar de dividir el estado de un objeto en

estados concurrentes se pueden definir dos objetos activos, con su propia máquina

Si el comportamiento de uno de los objetos depende del estado del otro es mejor usar subestados

169

Subestados Si los comportamientos dependen sólo de los

mensajes, es mejor utilizar objetos activos Si hay poca o ninguna comunicación es

indiferente usar uno u otro, aunque en general es más claro usar objetos activos

Inactivo

Mantenimiento

Probar Perifericos

Autodiagnosis

Espera Orden

Probar Perifericos

Autodiagnosis

Espera Orden

mantener

continuar

tecla pulsada

170

Contenido



Eventos y Señales Máquinas de Estados Procesos y Hebras


171

Procesos y Hebras

Cualquier sistema contiene elementos activos (al menos uno) Un elemento activo es aquel capaz de iniciar

una acción por si mismo Un elemento pasivo es aquel que sólo ejecuta

operaciones porque otros las invocan Los elementos activos son complejos:

Concurrencia, comunicación y sincronización UML modela los elementos activos como

objetos activos

172

Procesos y Hebras

Cada flujo de control independiente se modela como un objeto activo

Distinguimos dos tipos de objetos activos: Procesos: Flujo pesado, que se ejecuta

concurrentemente con otros procesos y que, normalmente, dispone de un espacio de direcciones independiente

Hebras: Flujo que se ejecuta dentro de un proceso. Un mismo proceso puede tener varios flujos de control que comparte el espacio de direcciones

Esta distinción coincide con la existente en la mayoría de los sistemas operativos actuales (POSIX, NT)

173

Procesos y Hebras

Los objetos activos son instancias de clases activas

La comunicación entre objetos activos es también mediante paso de mensajes, pero con una semántica distinta Los mensajes ayudan a sincronizar las

interacciones de flujos independientes La concurrencia a este nivel se especifica

de forma independiente del sistema y puede ser real o simulada (esto se indicará en el diagrama de despliegue)

174

Procesos y Hebras

Representación Gráfica:

En realidad se trata de un estereotipo En Rational Rose, no existe este

estereotipo, hay que crearlo

Control comunicacion

estado

Ultimo mensaje

reset()

Señalesmensaje recibido

error_enviarerror_recibir

<<active>>Control comunicacion

estado

Ultimo mensaje

reset()

Señalesmensaje recibido

error_enviarerror_recibir

175

Procesos y Hebras

Para crear un estereotipo que solo este disponible en un modelo basta con incluirlo en el campo de estereotipo de la definición de clase

176

Procesos y Hebras

Los estereotipos pueden tener iconos asignados o no

Además se puede mostrar el nombre o el icono o no distinguirlos de los elementos normales de UML

Para definir estereotipos permanentes es necesario modificar: DefaultStereotypes.ini Especificar un nuevo

icono

177

Procesos y Hebras

Todos los mecanismos de extensibilidad de UML pueden aplicarse a las clases activas

Aparte del estereotipo de clase activa se distinguen otros dos, equivalentes a los conceptos de proceso y hebra en los sistemas operativos: process thread

178

Procesos y Hebras

En Rational Rose los objetos activos se pueden especificar en la definición de la clase, pero no como estereotipo:

179

Comunicación entre Procesos

El paso de mensajes tiene una semántica distinta dependiendo de si los objetos son activos o pasivos: De pasivo a pasivo: se trata de la simple invocación de

una operación De activo a activo:

Rendezvous o cita: El emisor envía el mensaje y espera a que sea aceptado El receptor lo acepta e invoca la llamada (el emisor sigue

esperando) Se devuelve el resultado (si lo hay) y los dos siguen con su flujo

Invocación asíncrona: Semántica de buzón No se espera a que se reciba el mensaje

180


De activo a pasivo: hay que tener en cuenta que varios procesos prueden acceder al mismo tiempo un mismo objeto Exclusión mutua Sincronización

De pasivo a activo: Es consecuencia de una llamada previa de otro objeto

activo al pasivo Tiene la misma semántica

Se pueden incluir otras características a los mensajes Balking: mensaje síncrono que no espera si el receptor

no está listo Timeout: igual pero espera un tiempo máximo Periódicos o aperiódicos

181


A : proceso

active

D :

proceso

active

B : proceso

active

C :

proceso

F : otro

sequential

G :

proceso

active1: sincrona

2: asincrona

3: balking

4: normal

5: timeout

H :

proceso

active

6: periódico

182


Los tipos de mensajes se especifican en los diagramas de interacción

En cada mensaje se especifican los detalles

También se puede indicar el tipo de objeto (show concurrency), que coincidirá con el especificado en la clase

183

Sincronización

Aparte de en los mensajes, que ayudan a especificar la sincronización inherente a la aplicación, es necesario resolver el problema de los accesos múltiples

Aparece cuando existe más de un flujo de control en un objeto: Máquinas de estados concurrentes Invocaciones de un objeto pasivo por varios

activos La clave en este caso es tratar un objeto

como una sección crítica

184

Sincronización Existen tres enfoques:

Secuencial: Los emisores deben de coordinarse fuera del objeto

Con guardas: La integridad del objeto se garantiza tratando secuencialmente las llamadas a las operaciones con guardas

Concurrente: La integridad se garantiza porque la operación se ejecuta siempre de forma atómica

185

Vistas de procesos

Además de las vistas de casos de uso y lógicas, es conveniente tener también una vista de procesos del sistema

Esta vista se ocupa principalmente de la capacidad de adaptación, funcionamiento y rendimiento del sistema

Se utilizan los mismos diagramas, pero centrados en las clases activas que representan a las hebras y procesos

186

Flujos de Control Múltiple Uno de los diagramas más utilizados en las vistas de

procesos son los diagramas de interacción con flujos múltiples

leer_temperatura : proceso

active

leer_presion : proceso

active

controlador : proceso

visualizar : proceso

active

estadistica : proceso

active

datos compartidos : otro

guarded

calentador : proceso

valvula : proceso

p1: presion

t1: temp

t2: calentar

p2: abrir valvula

c1: actualizar

v1:

e1:

187

Contenido

Introducción Modelado estructural Modelado del comportamiento Modelado Arquitectónico

Componentes y diagramas de componentes Diagramas de despliegue Patrones y marcos de trabajo

188

Componentes

Se utilizan para modelar los elementos físicos que pueden hallarse en un nodo

Ejecutables Bibliotecas Tablas Archivos Documentos

Deben definir abstracciones precisas con interfaces bien definidos y que permitan la reemplazabilidad

189

Componentes

Un componente es una parte física y reemplazable de un sistema que implementa un conjunto de interfaces

Gráficamente se representa por

Componente

190

Componentes

En muchos sentidos los componentes son como las clases: Ambos tienen nombre Ambos pueden realizar un conjunto de

interfaces Ambos pueden participar en relaciones de

dependencia, generalización y asociación Ambos pueden anidarse Ambos pueden participar en interacciones

Sin embargo, hay diferencias significativas

191

Componentes

Diferencias entre componentes y clases: Las clases representan abstracciones lógicas y

los componentes elementos físicos (secuencias de bits)

Los componentes residen directamente en un nodo

Los componentes representan el empaquetamiento físico de elementos lógicos (de un distinto nivel de abstracción)

Las clases tienen atributos y operaciones directamente accesibles, los componentes sólo tienen operaciones alcanzables a través de sus interfaces

192

Componentes

La relación entre un componente y las clases que representa puede especificarse explícitamente

Cliente

Simulación(.exe)

Interfaz CORBA

Ejecutivo LaminasDataview

193

Componentes e Interfaces

Un interfaz es una colección de operaciones que se utiliza para especificar un servicio de una clase o componente

Este concepto a dado lugar a los sistemas basados en componentes (COM, CORBA, Java Beans)

Representación standard:

visualizador

Interfaz

dependencia

realización

194

Componentes e Interfaces

La existencia de los interfaces rompe la dependencia entre los componentes Un componente que utiliza una interfaz determinada

funcionará adecuadamente independientemente del componente que realice la interfaz

El componente que realiza la interfaz es siempre sustituible por un componente o conjunto de componentes que implementen dicha interfaz

Un componente puede utilizarse en un contexto determinado si y sólo si todas sus interfaces de importación son suministradas por otros componentes

195

Tipos de Componentes

Componentes de despliegue Los necesarios y suficientes para formar un

sistema ejecutable Bibliotecas dinámicas (DLLs) y ejecutables

Componentes producto del trabajo Productos finales del proceso de desarrollo

Archivos de código fuente y archivos de datos a partir de los cuales se crean los componentes de despliegue

Componentes de ejecución Se crean como consecuencia de un sistema en

ejecución Un proceso que se crea a partir de un ejecutable

196

Tipos de Componentes

Todos los mecanismos de extensibilidad se pueden aplicar a los componentes (incluidos los estereotipos)

UML define cinco estereotipos estándar executable: componente que se puede ejecutar en un

nodo library: biblioteca de objetos dinámica o estática table: componente que representa una tabla de una

base de datos file: documento con código fuente o datos document: componente que representa un documento

197

Componentes en Rational Rose Rational Rose no utiliza los anteriores

componentes estándar, sino el siguiente conjunto propio de estereotipos

Espec. Paquete

Cuerpo Subprog.

Prog. PrincipalEspec. Subprog.

Cuerpo Paquete Espec. Proceso Cuerpo Proceso

198

Especificación de Componentes

199

Modelado de código fuentesignal.h {ver=3.5} signal.h {ver=4.0} signal.h {ver=4.1}

interp.cpp signal.cpp

irq.h device.cpp

parent

Diagramas de Componentes

Su contenido particular incluye Componentes Interfaces Relaciones de dependencia, generalización,

asociación y realización Usos comunes

Modelar código fuente Modelar versiones ejecutables Modelar bases de datos físicas Modelar sistemas adaptables

Diagrama de Componentes

202

Contenido



203

Despliegue

Los nodos al igual que los componentes son un elemento fundamental en el modelado físico de un sistema

Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional Un nodo representa un procesador o un dispositivo

sobre el que se pueden desplegar los componentes UML proporciona una representación gráfica de

un nodo genérico que se puede particularizar para representar procesadores y dispositivos específicos

204

Diagramas de Despliegue Un diagrama de despliegue muestra:

los distintos dispositivos y su interconexión la asignación de componentes (procesos,

ficheros,...) a dispositivos Debe existir un solo diagrama de despliegue

por modelo

Procesador 1 Procesador 2

Dispositivo

205

Diagramas de Despliegue Son especialmente utiles para:

Describir sistemas empotrados, en los que hay gran cantidad de software interactuado con el hardware

Modelar sistemas distribuidos, en los que la asignación de componentes a procesadores puede ser importante

Servidor

preemptive

dbadmintktmstr

terminalpreemptive

user.exe

Consola

10-T Ethernet

RS-232

UnidadRAID

206

Especificación de Procesadores

207

Especificación de Procesos

208

Dispositivos y Conexiones

Diagramas de Despliegue Muestra la configuración de los nodos que

participan en la ejecución y los componentes que residen en ellos.

Sus contenidos particulares son: Nodos Relaciones de dependencia y asociación

Usos comunes: Modelar vistas de despliegue estáticas Por ejemplo: distribución, entrega e instalación

de las partes que configuran el sistema físico Modelar sistemas empotrados, cliente/servidor y

de componentes distribuidos

Diagrama de Despliegue

Técnicas Comunes de Modelado de Despliegue

Sistemas Empotrados Sistemas Cliente-Servidor Sistemas Completamente Distribuidos

212

Contenido




Muestran el flujo de las actividades del sistema. Son un caso particular de los diagramas de estados Las actividades producen acciones. Se usan para especificar

Métodos Casos de uso Flujo de trabajo (workflow)

Los diagramas de actividades contienen: Estados de actividad y de acción Transiciones Objetos

Diagrama de Actividades


Adquiere información del

clienteCrea nueva

cuenta de crédito

:Cuenta[inicializando]

Ajusta Limite de CréditoVerifica historia crediticia del

cliente

Revisar historia creditici

aRechaza Cuenta

:Cuenta[Rechazada]

Acepta Cuenta

:Cuenta[Aprobada]

Acepta Términos

:Cuenta[Abierta]

Firma Contrato

Servicio a usuario Adm. Depto. Crédito Cliente

216

Patrones y Marcos de Trabajo

Todos los sistemas bien estructurados están llenos de patrones. Un patrón proporciona una solución común a un

problema en un contexto dado

Un mecanismo es un patrón de diseño que se aplica a una sociedad de clases

Un marco de trabajo (framework) es un patrón arquitectónico que proporciona una plantilla extensible para aplicaciones dentro de un dominio

217

Patrones y Marcos de Trabajo

Tanto en un sistema nuevo, como en una modificación de un sistema existente no se debe empezar desde cero

Hay que intentar aplicar formas comunes de resolver problemas En sistemas que interactúan con el usuario, una forma

probada de organizar las abstracciones es utilizar el patrón modelo-vista-control

En sistemas de solución de problemas de forma colaborativa se suele utilizar una arquitectura de pizarra

En sistemas dirigidos por eventos se utiliza el patrón cadena de responsabilidad para organizar los manejadores de eventos

218

Colaboraciones

Son el elemento básico para describir patrones de diseño.

Una colaboración permite nombrar a un bloque conceptual que incluye tanto aspectos estáticos como dinámicos

Denota una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar algún comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos

219

Colaboraciones

Una colaboración tiene dos aspectos: Estructural: especifica las clases, interfaces o

componentes Se organizan utilizando las relaciones normales de UML

(asociaciones, generalizaciones y dependencias) Al contrario que los paquetes o subsistemas, no contienen

a sus elementos. Puede hacer referencia o utilizar elementos declarados en

distintos sitios Se trata de un bloque conceptual de la arquitectura del

sistema Comportamiento: dinámica de cómo interactúan estos

elementos Se representa mediante diagramas de interacción Debe ser consistente con la visión estructural

220

Colaboraciones

IDistribuido

Cola

añadirMensaje()quitarMensaje()contar()

Mensaje

IDcabeceracuerpo

Agente de Transporte

emisorrecibido

enviarMensaje()

1

1..*

1

+Buzón 1..* 1..*

1

1..*

colaDeEntrada colaDeSalida

221

Colaboraciones

: Actor : Mensaje : colaDeSalida : Agente de

Transporte

los agentes de transporte

periódicamente quitan

mensjaes de las colas

asignadas, según sus

politicas de planificación

1: crear

2: añadirMensaje

3: quitarMensaje

222

Colaboraciones

Ambos diagramas deben ser consistentes Los objetos deben ser instancias de clases Los mensajes deben ser operaciones visibles

Puede haber más de un diagrama de interacción por colaboración, mostrando distintos aspectos de una colaboración

Representación

Paso de Mensajes

223

Colaboraciones

Además de para mostrar patrones de diseño, las colaboraciones pueden utilizarse para mostrar la realización de los casos de uso

La implementación de un caso de uso vendrá dada por una o más colaboraciones de los objetos de implementación del sistema

Se pueden representar en diagramas de casos de uso, utilizando relaciones de realización y refinamiento

224

Colaboraciones

225

Mecanismos

Un mecanismo o patrón de diseño se modela como una colaboración parametrizada

Se representan en UML de forma parecida a como se representan las clases plantilla

Observador

SujetoObservador

Cola Tareas

BarraDesplazamiento

Sujeto

Observador

226

Marcos de Trabajo

Es un patrón arquitectónico que proporciona una plantilla extensible para aplicaciones dentro de un dominio

Por ejemplo, para desarrollar un sistema en tiempo real podemos utilizar: Un ejecutivo cíclico Una arquitectura orientada a eventos Un conjunto de tareas con un planificador concreto

Las tres alternativas pueden estar definidas como marcos de trabajo y “sólo” habrá que instanciarlas

227

Marcos de Trabajo

Un marco de trabajo es algo más grande que un mecanismo

Se puede concebir como una microarquitectura que incluye un conjunto de mecanismos que colaboran para resolver un problema en un dominio común

Un marco de trabajo se especifica como un paquete estereotipado. Dentro del paquete se pueden ver mecanismos

existentes en cualquiera de las vistas del sistema No sólo hay mecanismo, también pueden incluirse

casos de uso, colaboraciones simples,....

228

Marcos de Trabajo

Ejecutivo Cíclico<<framework>>

Gestor de Eventos

ClienteGestor

Eventos Comunes

229

Marcos de Trabajo

Los Marcos de Trabajo son diferentes de las bibliotecas de clases

Una biblioteca de clases contiene abstracciones que las abstracciones del desarrollador pueden instanciar o invocar

Un marco de trabajo contiene abstracciones que pueden instanciar o invocar a las abstracciones del desarrollador

Modelado de Sistema Empotrado

Modelado de un Sistema Cliente-Servidor

Modelado de un Sistema Completamente

Distribuido

Proceso Unificado

AUTOESTUDIO

Estudie el ejemplo de modelado del elevador con UML accesibe de la página de apoyos delcurso

Próxima Clase 1er Examen Parcial

tema2

Education