Analisis y Diseño de Sistemas II Orientado a objetos

Gloria Margot Gonzales Fernandez

Ingeniero en Informática

Instituto Superior Jesús María Fé y Alegría

Materia: Análisis y Diseño de Sistemas II

Curso: 3ero de Análisis de Sistemas

Introducción

Modelado estructural

Modelado del comportamiento

Modelado arquitectónico

2

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

3

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

4

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

5

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.

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

5. Diagrama de Estados

6. Diagrama de Implementación

6.1. Diagrama de Componentes

6.2 Diagrama de Despliegue

9

Ele

men

tos

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

Rel

acio

nes Dependencia

Asociación

Generalización

Realización

Dia

gra

mas

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

Reg

las

Mec

anis

mo

sNombres

Ámbito

Visibilidad

Integridad

Ejecución

Especificaciones

Adornos

Divisiones comunes

Extensiones

Entidad

Instancia

Estereotipo

Valor etiquetado

Restricción

Cliente

nombre

dirección

preferencial()

IUnknown

IOrtografía

Elena:Cliente

ColaEventos{vers = 3.2autor=eps}

añadir()

quitar()

vaciar()

«exception»

Overflow

{ordenado}

asistOrtog.dll

:Cliente

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

12

13

José:Cliente

José Pérez

:Cliente

Claudia

14

Clase

atributos

operaciones

Cada atributo es único en la clase

Sólo datos “simples” y NO otros objetos

Opcionalmente, tipo y valor por defecto

Funciones o procedimientos

Cada operación tiene un objeto destino implícito

Se puede aplicar la misma operación a clases distintas

Opcionalmente, lista de argumentos y tipo devuelto (no omitir)

15

Punto

x: float

y: float

trasladar(dx:float, dy:float)

distancia(pto: Punto) : float

:Punto

x=0

y=0

:Punto

x=3.5

y=2.25

:Punto

x=1

y=2

16

EEPROM

EEPStart

EEPStop

enviarDir(dir:Tparam)

EnviarByte(dato:Tvalor)

Control(accion:integer)

EEPAck

EEPNoAck

:EEPROM

17

Protocolo

EntradaCombo(m: TMensajeMovil)

LIGBM()

LL_ENT()

SILEN()

FIN_LIG()

INTBM()

FIN_LLENT()

CODSEG()

FININTB()

mensaje: TMensajeMovil

movil_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: TEstadoCombo


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

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

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

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

Cuáles de las siguientes declaraciones son válidas?

mostrar

+ mostrar

set(n: nombre, s: string) (0,0)

obtenerID() :Integer

reiniciar() :{concurrent}

OK

OK

NO

OK

NO

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

23

24

0 o 1

Muchos

n Exactamente n

m,n m o n

m-n Entre m y n

n+ Más de n

Exactamente 1

Direccionalidad

Multiplicidad

Clase

atributos

operaciones

Clase

atributos

operaciones

asociación

25

Punto

x: float

y: float



Línea



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

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

28

29

Clase

atributos

operaciones

Clase

atributos

operaciones

atributo

30

Fichero Usuario

permiso de acceso

acceso

Empresa Persona

sueldo

puesto

trabajo

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

31

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


Combo

...

estado: TEstadoCombo


CtrlCombo

ultimoCanal: Tcanal

estado: TEstadoCtrlCombo

inicioComunicación

finComunicación

enviarMensaje(m:TMensajeBase)

noPortadora

mensajes

35

Temporización

tEncendido:Duration

tApagado: Duration

tSilencio: Duration

LED

ident: LEDID


led_que_enciende

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

36

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

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

40

41

Clase

atributos

operaciones

Clase

atributos

operacionesasociación

Clase

atributos

operaciones

Clase

atributos


calificador

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

tApagado: Duration

tSilencio: Duration

led

tipoEvento

parpadeoLed

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

44

45

Empleado

salario

directivo

subordinado

{salario < directivo.salario}

Ventana

anchura

altura

{anchura<altura}

presidente

Persona {subconjunto} Comisión

miembro

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

46

47

Clase

atributos

operaciones

Clase

atributos


48

vértices

Polígono

dibujar()

Punto

dibujar()

dibujar

49

Puerto

leerNivel()

{ordered}

puertosTeclado

3Teclado

...

ultimaTecla

InterfazExterno

Display LED

6

Fija (lámpara)

Variable (empresa-departamento)

Recursiva (sentencia-bloque)

No es implementable eficientemente.

En algunos casos puede llegar a no permitirse.

50

Bloque

Sentencia

S. Simple

*

Departamento

Empresa

*

Lámpara

PieBombillaTulipa

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

51

52

SuperClase

atributos

operaciones

SubClase

atributos

operaciones

SubClase

atributos

operaciones

SubClase

atributos

operaciones

...

discriminador

Herencia con

solapamiento

Herencia con

discriminador

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

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.

55

Computador Identificación

DNI PC Smart Card

Se puede

Prohibir situaciones conflictivas (C++, Eiffel)

Usar un heurístico para linealizar el árbol de herencia (CommonLoops)

Prohibir la herencia múltiple (Java)56

Vehículo

Vehículo Terrestre Vehículo Acuático

Bote Coche Vehículo Anfibio

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)

57

destino*origen

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.

58

ControlVentas

Responsabilidades

--determinar validez venta

--comunicar a Almacen y

Contabilidad

No controla saldo

del cliente

<<excepción>>

VentaRechazada

razón

Son elementos de modelado que pueden tener instancias Interfaz, Tipo de

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

Visibilidad

+ Public

# Protected

- Private

Alcanceinstancia

clasificador

59

Tarjeta

+ GetSaldo: long

+ Recarga(long cant)

+ Comprobar(long cant):boolean

- Saldo:long

- PIN:int

# Límite:long = 25.000

Formato atributos[visibilidad] nombre [multiplicidad] [:tipo]

[=valor inicial] [{propiedades}]

Propiedades predefinidas: changeable, addOnly, frozen

60

Tarjeta

+ GetSaldo: long


+ Comprobar(long cant):boolean

- Saldo:long

- PIN [1..*] : int {addOnly}


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

61

Tarjeta

+ GetSaldo: long {isQuery}


+ ComprobarPIN(int pinPrueba):boolean

- Saldo:long

- PIN [1..*] : int {addOnly}


Interfaz: colección de operaciones que se usa para

especificar un servicio de una clase o componente.

62

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.

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

63

+FormularioDePedido

+FormularioDeEstado

- Pedido

Cliente

Visibilidad.

64

+FormularioDePedido

+FormularioDeEstado

- Pedido

Cliente

<<import>>

Importación y Exportación.

+Ventana

+Formulario

#GestorEventos

GUI

exportación

Generalización.

WinGUI

LinuxGUI

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.

65

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

Introducción



Modelado Básico

Interacciones

Diagramas de interacción

Casos de uso y diagramas

Diagramas de actividades

Modelado Avanzado


67

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

68

69

Persona

Asignar(d:Departamento)

Empresa

empleado contratante

1..* *

P:Persona :Empresa

Asignar(desarrollo)

Enlace

Asociación

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

70

[Pre] 1:*(expr):mensaje(p,q):Valor

Precondición

ParámetrosExpresión

IteraciónIdentificador

Nº secuencia

Valor de

Retorno

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

71

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

72

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.

1: Acepta tarjeta

2: Lee Num. Tarjetas

3: Inicializa pantalla

4: Abre cuenta

5: Solicita PIN

6: Da PIN

7: Verfica PIN

8: Solicita Transacción

9: Selecciona Transacción

10: Solicita Cantidad

11: Captura Cantidad

12: Retira Dinero

13: Verifica Fondos

14: Descuenta Cantidad

15: Da dinero

16: Da recibo

17: Expulsa Tarjeta

Lector

Tarjet

as

Pantal

la

Captur

a

Cuenta

Joe

Ranura

de

dineroJoe: cliente

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

76

: InstructorConsola Instructor

BDinstructores

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

3: usuario correcto

4: iniciar sesion

5: usuario aceptado

Foco de

Control

Línea de

Vida

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

77

: Alumno

Cliente

Aplicación

Interfaz

Cliente

Sesion

1: login

2: crear sesion

3: create

4: logout

5: fin 6: destroy

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.

6: Da PIN

9: Selecciona Transacción

11: Captura Cantidad

5: Solicita PIN

8: Solicita Transacción

10: Solicita Cantidad 7: Verfica PIN

12: Retira Dinero

3: Inicializa pantalla

1: Acepta tarjeta 13: Verifica Fond

2: Lee Num. 14: Descuenta

Cantidad

Tarjetas

4: Abre cuenta

17: Expulsa Tarjeta

15: Da dinero

16: Da recibo

Pantal

la

Captur

a

Joe: cliente

Cuenta

Joe

Lector

Tarjet

as

Ranura

de

dinero

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

82

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,.....)

83

Utilizando el submenu Browse se puede generar un diagrama a

partir del otro

85

: Instructor

Consola

Instructor

BD

instructores

1: login(usuario)

2: leer(usuario)

3: usuario correcto

4: iniciar sesion

5: usuario aceptado

: InstructorConsola

Instructor

BD

instructores

1: login(usuario)

2: leer(usuario)

3: usuario correcto

4: iniciar sesion

5: usuario aceptado

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)

86

87

: InstructorConsola

Instructor

BD

instructores

1: login(usuario)

2: leer(usuario)

3: usuario correcto

4: iniciar sesion

5: usuario aceptado

inicio

fin

{inicio-fin<10s}

{Iniciar sesion.executionTime<5s}

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.

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

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 actores

3. Definir lo que el actor quiere hacer con el sistema

4. Para cada uno de estos escenarios (caso de uso) decida cuál sería la forma natural de interacción

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

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

April 12 94

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

95

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 datos

3. El sistema altera su estado interno

4. El sistema devuelve el resultado al actor

96

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

97

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

April 12 99

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

100

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 repetidos101

102

sesión alumno

controlCI

cambiar estado

modificar parámetros

Instructor

login

logout

acciones instructor

sesion instructor <<include>>

<<include>>

<<include>>

control backtrack

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

103

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

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

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

107

Se utilizan para dar un formato uniforme a la

explicación textual de los casos de uso

108

Caso de uso: Nombre del caso de uso

Este es el objetivo del caso de uso descrito con una frase corta

Ámbito: La “caja negra” considerada

Nivel: Uno de los tres niveles anteriores

Contexto de uso: Una frase más larga con la descripción del objetivo y las condiciones normales de desarrollo

Actor 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ón

Se 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

111

Caso de uso: Ciclo de Vida de Cuenta

Ámbito: El sistema completo

Nivel: Resumen

Contexto de uso: Para interactuar con el sistema el cliente es representado por un cajero o por cajero automático

Actor Principal: Cliente

112


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 sistema

3. El sistema solicita al cajero la siguiente información:

Nombre

Dirección

DNI

Tipo de Cuenta

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

113


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

5. El cliente ingresa dinero – sub-caso de uso

6. El cliente obtienen un balance – sub-caso de uso

7. El cliente saca dinero – sub-caso de uso

8. El cliente transfiere dinero – sub-caso de uso

9. Este paso se repite indefinidamente una vez al mes desde la fecha de apertura hasta fecha de cierre

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

12. El sistema envia un balance con los últimos movimientos

114

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 cuenta

4a.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

........

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

115

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

116

Introducción



Modelado Básico

Interacciones

Diagramas de interacción

Casos de uso y diagramas

Diagramas de actividades

Modelado Avanzado


117

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.

April 12 118

119

Solicitar Producto

Recibir Pedido

Pagar Factura

Procesar Pedido

Facturar al Cliente

Cerrar Pedido

Extraer Artículos

Enviar Pedido

Diagramas de Actividades

120

Estado Inicial

Actividad

Acción

EstadoEstado

Condición

Actividad

Actividad

Transición

sin Disparador

División Unión

Estado Final

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)

121

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)

122

Asignar Tareas

Replanificar

Seleccionar

Trabajos

[Hay Materiales]

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

123

124

Solicitar Producto

Recibir Pedido

Pagar Factura

Procesar Pedido

Facturar al Cliente

Cerrar Pedido

Extraer Artículos

Enviar Pedido

Cliente Ventas Almacen

O:Pedido

[en progreso]

O:Pedido

[completado]

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

125

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

126

127

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

}

Introducción



Modelado Básico

Modelado Avanzado

Eventos y Señales

Máquinas de Estados

Procesos y Hebras


128

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

129

Declaración de un evento

130

<<Signal>>

Colgar Inactivo

Activo

Colgar / cortarConexion()

<<signal>>

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

131

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

132

La relación entre una operación y los eventos que

puede generar se modela con una relación de

dependencia estereotipada como send.

134

colisión

fuerza : Float

(from eventos)

Agente de movimiento

posición

velocidad

moverA()

(from eventos)

<<send>>

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

135

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

136

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

137

138

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 puntuales

discretos en el tiempo

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

139

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.

140

gestor de Teclado

estado

tipo

reset()

Señales

pulsarBoton(b:boton)

encendido

apagado

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

141

142

Señal de robot

fallo hardwarecolision

sensor : integer

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

Atasco Motor

Abstractas

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

143

144

Excepción

establecerManejador()

primerManejador()

ultimoManejador()

Conjunto

añadir()

eliminar()

Duplicado

Overflow

Underflow<<send>>

<<send>>

<<send>>

Introducción



Modelado Básico

Modelado Avanzado

Eventos y Señales


Procesos y Hebras

Diagramas de estados


145

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

146

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

147

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

148

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

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

150

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

152

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

153

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.

154

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

155

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.

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


Abrir

Cerrar

Sobregiro

Noficar a cliente

Retiro [balance <0]

Depósito [balance <0]

Verifica Balance

[Balance <0 for >30 días]

Cliente

Solicita

Cancelación

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

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

162

163

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

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

164

165

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*

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

166

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

167

H

H*

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

168

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

169

Inactivo

Mantenimiento

Probar

Perifericos

Autodiagno

sis

Espera Orden

Probar

Perifericos

Autodiagno

sis

Espera Orden

mantener

continuar

tecla pulsada

Introducción



Modelado Básico

Modelado Avanzado

Eventos y Señales


Procesos y Hebras


170

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

171

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)

172

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

Representación Gráfica:

En realidad se trata de un estereotipo

En Rational Rose, no existe este

estereotipo, hay que crearlo

174

Control comunicacion

estado

Ultimo mensaje

reset()

Señales

mensaje recibido

error_enviar

error_recibir

<<active>>

Control comunicacion

estado

Ultimo mensaje

reset()

Señales

mensaje recibido

error_enviar

error_recibir

175

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

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

176

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

177

En Rational Rose los objetos activos se pueden especificar en la

definición de la clase, pero no como estereotipo:

178

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

179

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

180

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

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

182

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

183

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

184

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

185

Uno de los diagramas más utilizados en las vistas de procesos son

los diagramas de interacción con flujos múltiples

186

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:

Introducción



Modelado Arquitectónico

Componentes y diagramas de componentes

Diagramas de despliegue

Patrones y marcos de trabajo

187

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

188

Un componente es una parte física y

reemplazable de un sistema que implementa

un conjunto de interfaces

Gráficamente se representa por

189

Componente

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

190

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

191

La relación entre un componente y las clases que

representa puede especificarse explícitamente

192

Cliente

Simulación

(.exe)

Interfaz CORBA

Ejecutivo Laminas

Dataview

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:

193

visualizador

Interfaz

dependencia

realización

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

194

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

195

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

196

Rational Rose no utiliza los anteriores componentes

estándar, sino el siguiente conjunto propio de

estereotipos

197

Espec. Paquete

Cuerpo Subprog.

Prog. PrincipalEspec. Subprog.

Cuerpo Paquete Espec. Proceso Cuerpo Proceso

199

signal.h {ver=3.5} signal.h {ver=4.0} signal.h {ver=4.1}

interp.cpp signal.cpp

irq.h device.cpp

parent

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

Introducción







202

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

203

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

204

Procesador 1 Procesador 2

Dispositivo

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

205

Servidor

preemptive

dbadmintktmstr

terminal

preemptive

user.exe

Consola

10-T Ethernet

RS-232

UnidadRAID

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

Sistemas Empotrados

Sistemas Cliente-Servidor

Sistemas Completamente Distribuidos

Introducción







212

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

Adquiere

información del

cliente

Crea nueva cuenta

de crédito

:Cuenta

[inicializando]

Ajusta Limite de Crédito

Verifica historia crediticia

del cliente

Revisar

histori

a

crediti

ciaRechaza

Cuenta

:Cuenta

[Rechazada]

Acepta

Cuenta

:Cuenta

[Aprobada]

Acepta

Términos

:Cuenta

[Abierta]

Firma

Contrato

Servicio a usuario Adm. Depto. Crédito Cliente

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

216

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

217

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

218

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

219

220

IDistribuido

Cola

añadirMensaje()

quitarMensaje()

contar()

Mensaje

ID

cabecera

cuerpo

Agente de Transporte

emisor

recibido

enviarMensaje()

1

1..*

1

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

1

1..*

colaDeEntrada colaDeSalida

221

: 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

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

222

Paso de Mensajes

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

223

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

225

Observador

Sujeto

Observador

Cola Tareas

BarraDesplazamiento

Sujeto

Observador

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

226

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

227

228

Ejecutivo Cíclico<<framework>>

Gestor de Eventos

Cliente

Gestor

Eventos Comunes

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

229

Estudie el ejemplo de modelado del elevador

con UML accesibe de la página de apoyos del

curso

Analisis y Diseño de Sistemas II Orientado a objetos

Technology

Transcript of Analisis y Diseño de Sistemas II Orientado a objetos