Global Azure Lima 2024 - Integración de Datos con Microsoft Fabric
Analisis y Diseño de Sistemas II Orientado a objetos
1. 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
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).
3
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, ...
4
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
5
6. 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.
7. 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
8. 5. Diagrama de Estados
6. Diagrama de Implementación
6.1. Diagrama de Componentes
6.2 Diagrama de Despliegue
9. Clase Clase Colaboración
Interfaz atributos IInterfaz
Colaboración métodos Clase Act
Estructurales Caso de uso Caso de Uso
atributos
Clases activs métodos
Nodo Componente
Elementos
Componente Nodo
Interacción Interacción
Comportamiento
Máquina de estados Estado
Paquetes
Frameworks
Agrupación Paquete
Modelos
Subsistemas
Anotación Nota Nota
9
10. Relaciones Dependencia
0..1 *
Asociación
role1 role2
Generalización
Realización
Diagrama de clases
Diagrama de objetos
Diagramas
Diagrama de casos de uso
Diagrama de secuencia
Diagrama de colaboración
Diagrama de estados
Diagrama de actividades
Diagrama de componentes
Diagrama de despliegue
10
12. 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
14. Cada atributo es único en la clase
Sólo datos “simples” y NO otros objetos Clase
Opcionalmente, tipo y valor por defecto
atributos
operaciones
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)
14
18. 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
19. 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}]
20. Cuáles de las siguientes declaraciones son válidas?
Origen OK
+ origen
& origen OK
*Cabeza: Item NO
Nombre [0..+] : String
NO
Id: Integer {frozen}
Id: Integer = {0,0} NO
OK
OK
21. 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}]
22. Cuáles de las siguientes declaraciones son válidas?
mostrar OK
+ mostrar OK
set(n: nombre, s: string) (0,0) NO
obtenerID() :Integer OK
reiniciar() :{concurrent} NO
23. 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. Clase Clase
atributos asociación atributos
operaciones operaciones
Multiplicidad 0o1
Muchos
n Exactamente n
m,n mon
m-n Entre m y n
n+ Más de n
Exactamente 1
Direccionalidad
24
27. Proyecto Lenguaje
Persona
C:Lenguaje Eole400:Proyecto Ensamblador:Lenguaje
Luis:Persona José María:Persona
CentralNuclear:Proyecto Fortran:Lenguaje
27
28. 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
30. acceso
Fichero Usuario
permiso de acceso
trabajo
Empresa Persona
sueldo
puesto
30
31. 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 Clase
atributos rol rol atributos
operaciones asociación operaciones
32
33. propietario padre
Usuario Directorio
usuario_autorizado
subdirectorios
33
36. 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
39. Puerto Teclado
{ordered} ultimaTecla
leerNivel() puertosTeclado ...
39
40. 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
44. 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 directivo Ventana
salario anchura
altura
subordinado {anchura<altura}
{salario < directivo.salario}
miembro
Persona {subconjunto} Comisión
presidente
45
46. 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
48. Polígono dibujar Punto
dibujar() vértices dibujar()
48
49. Puerto Teclado
3 {ordered}
ultimaTecla
puertosTeclado
leerNivel() ...
Display LED
6
InterfazExterno
49
50. Fija (lámpara) Lámpara
Tulipa Bombilla Pie
Variable (empresa-departamento)
Empresa
*
Departamento
Recursiva (sentencia-bloque)
Sentencia *
S. Simple Bloque
No es implementable eficientemente.
En algunos casos puede llegar a no permitirse.
50
51. 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
55. Computador Identificación
PC Smart Card DNI
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
56. Vehículo
Vehículo Terrestre Vehículo Acuático
Coche Vehículo Anfibio Bote
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
57. Dependencia=Relación de uso
origen * destino
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
58. Notas
No controla saldo
Expresa comentarios o aclaraciones
del cliente
relativas a un elemento o grupo de ellos.
Responsabilidades
ControlVentas
Contrato u obligación de una clase
Se expresan mediante texto libre
Estereotipos Responsabilidades
--determinar validez venta
Crea nuevos tipos de bloques de
--comunicar a Almacen y
construcción específicos al problema que Contabilidad
se modela. No confundir con superclase.
Se expresa mediante un nombre entre
comillas tipográficas. <<excepción>>
VentaRechazada
razón
58
59. Son elementos de
modelado que pueden
tener instancias
Interfaz, Tipo de
datos, Señal, Componen Tarjeta
te, Nodo, Casos de
uso, Subsistema. - Saldo:long
- PIN:int
Visibilidad # Límite:long = 25.000
+ Public + GetSaldo: long
# Protected + Recarga(long cant)
+ Comprobar(long cant):boolean
- Private
Alcance
instancia
clasificador
59
62. Interfaz: colección de operaciones que se usa para
especificar un servicio de una clase o componente.
Si es necesario puede
representarse como una
Tarjeta Multifunción
clase estereotipada. No
tendrá atributos ni métodos;
sólo operaciones.
Las operaciones pueden
incluir adornos como IIdentificación IPago
estereotipos, valores <<interface>>
etiquetados, restricciones y IPago
propiedades de visibilidad y GetSaldo()
concurrencia. Recarga()
62
63. 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: Cliente
framework, subsystem, system
stub, facade +FormularioDePedido
+FormularioDeEstado
- Pedido
63
65. 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
66. Diagramas en UML y su uso
Captura de Requisitos Análisis y Diseño Implementación
Diagramas de
Estados
Diagramas de
Secuencia Diagramas de
Distribución
Diagramas de Diagramas
Casos de Uso De Clases
Diagramas de Diagramas de
Colaboración Componentes
Diagramas de Diagramas de
Actividad Actividad
67. 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
67
68. Definición
Una 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 Empresa
1..* *
Asignar(d:Departamento) empleado contratante
Asociación
Asignar(desarrollo)
P:Persona :Empresa
Enlace
69
70. 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 Valor de
Retorno
Nº secuencia Parámetros
Expresión Identificador
Iteración
70
71. 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
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
72
73. 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.
74.
75. Lector Pantal Cuenta Ranura
Tarjet la Joe de
Joe: cliente
as Captur dinero
1: Acepta tarjeta a
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
76. 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
Consola BD
: Instructor Instructor instructores
Foco de
1: login(usuario)
2: leer(usuario) Control
Línea de
3: usuario correcto
Vida
4: iniciar sesion
5: usuario aceptado
76
77. Los mensajes se
corresponden Cliente Interfaz
generalmente a : Alumno
Aplicación Cliente
métodos de los 1: login
objetos 2: crear sesion
Los objetos pueden 3: create
Sesion
ser creados durante
la ejecución
4: logout
En Rational Rose, la
5: fin 6: destroy
creación de objetos
no se puede reflejar
de la forma estándar
77
79. 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.
80.
81. 6: Da PIN
Joe: cliente Selecciona Transacción
9: Pantal
11: Captura Cantidad la
Captur
5: Solicita PIN
8: Solicita Transacción a
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
Lector
Tarjet Cuenta
4: Abre cuenta
as Joe
17: Expulsa Tarjeta
Ranura
de 15: Da dinero
16: Da recibo
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
82
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,.....)
83
85. Utilizando el submenu Browse se puede generar un diagrama a
partir del otro
4: iniciar sesion
Consola BD
1: login(usuario) : Instructor Instructor instructores
Consola
Instructor
5: usuario aceptado 1: login(usuario)
2: leer(usuario)
: Instructor
3: usuario correcto
3: usuario correcto
2: leer(usuario)
4: iniciar sesion
BD 5: usuario aceptado
instructores
85
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)
86
88. 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.
89. 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
90.
91.
92.
93. 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
94. 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
95. 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
96. 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
97. 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
98. 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
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
100
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
101
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
103
104. identificación
<<include>>
Alumno sesion alumno <<include>>
<<extend>>
Acción errónea
Acciones de Alumno
Petición de valores Activar vble dinámica
Todos los valores
Valores cambiados Selección
104
105. Nacional
<<includes>>
Marcar Número
<<extends>> Internacional
Realizar Llamada
Llamante
<<extends>>
<<extends>>
Numero no existe
<<extends>>
Numero Incorrecto
Comunicando
Recibir Llamada
Llamado
<<extends>> No hay linea
Llamada no atendida
105
106. Identificar Cliente Identificar Cliente y Cuenta en
Cajero Automático
<<includes>>
<<includes>> <<includes>>
<<includes>>
Obtener un Balance
Ingresar Dinero Transferir Dinero Sacar Dinero
<<includes>>
<<includes>>
<<includes>>
Correo
Ciclo de Vida Cuenta
Cajero Cliente Cajero Automático
106
107. 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
108. Se utilizan para dar un formato uniforme a la
explicación textual de los casos de uso
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: ...
108
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: ...
109
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
110
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
111
112. 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 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
112
113. 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 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 113
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
........
114
115. 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
116. 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
117. 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
117
118. 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
120. Estado Inicial Estado Final
Actividad
Acción Actividad
Estado
Transición
Estado sin Disparador
Actividad
Condición
División Unión
120
121. 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
122. 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)
Seleccionar
Trabajos
Replanificar
[Hay Materiales]
Asignar Tareas
122
123. 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
125. 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
126. 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. Punto Linea::intersec (L:Linea)
{
if (pendiente==l.pendiente) return Punto(0,0)
return
Punto(0,0)
int x= (l.delta-delta)/(pendiente-l.pendiente);
int y=(pendiente*x)+delta;
do/ x=(l.delta-delta)/(pendiente-l.pendiente);
return Punto(x,y);
}
do/ y=(pendiente*x)+delta;
return
Punto(x,y)
127
128. Introducción
Modelado estructural
Modelado del comportamiento
Modelado Básico
Modelado Avanzado
Eventos y Señales
Máquinas de Estados
Procesos y Hebras
Modelado arquitectónico
128
129. 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
130. Declaración de un evento
<<Signal>>
Colgar Inactivo
<<signal>>
Colgar / cortarConexion()
Activo
130
131. 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
132. 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
134. La relación entre una operación y los eventos que
puede generar se modela con una relación de
dependencia estereotipada como send.
Agente de movimiento
(from eventos)
posición
velocidad
colisión <<send>> moverA()
(from eventos)
fuerza : Float
134
135. 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
136. 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
137. 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. When (11:49pm) / autotest()
Inactivo
after(2 seg) / cortar conexión
Activo
Aunque un evento de cambio modela un test continuo,
normalmente se transforma en condiciones puntuales
discretos en el tiempo
138
139. 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
140. 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ñales
pulsarBoton(b:boton)
encendido
apagado
140
141. 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
Abstractas
fallo hardware
colision
sensor : integer
fallo batería fallo mecanico Fallo de visión fallo de rango
Atasco Motor
142
143. 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
145. Introducción
Modelado estructural
Modelado del comportamiento
Modelado Básico
Modelado Avanzado
Eventos y Señales
Máquinas de Estados
Procesos y Hebras
Diagramas de estados
Modelado arquitectónico
145
146. 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
147. 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
148. 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. Activo
Timeout
do/ mensaje timeout
after( 15 seg ) tecla( t )[ incompleto ]
after( 15 seg )
Tono de marcado tecla( t ) Marcando
do/ reproducir tono
tecla( t )[ completo ]
tecla( t )[ invalido ]
descuelga / tono de marcado
Invalido
Inactivo
do/ Mensaje invalido Conexión
cuelga / desconectar
Espera ocupado
Comunicando
conectado
do/ tono comunicando
usr. llamado cuelga
Hablando Sonando
responde / habilitar voz do/ tono llamada
149
150. 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
152. 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
153. 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
154. 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
155. 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
157. 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.
158. 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
159. III. El Paradigma OO: Diagrama de Estados III. El Paradigma OO: Diagrama de Estados
Generalización de Estados Generalización de Estados
Ejemplo: Quedaría como:
e1
A e1
B Aa b
B
e2
e2
e2
C
C
155 156
www.dsic.upv.es/~uml www.dsic.upv.es/~uml
III. El Paradigma OO: Diagrama de Estados
III. El Paradigma OO: Diagrama de Estados
… Generalización de Estados … Generalización de Estados
Las transiciones de entrada deben ir hacia Es preferible tener estados iniciales de
subestados específicos: entrada a un nivel de manera que desde los
niveles superiores no se sepa a qué
e1 subestado se entra:
a
A b
B
e1
e2
Aa b
B
e0 e2 C
e0
C
157 158
www.dsic.upv.es/~uml www.dsic.upv.es/~uml
161. Estados Transiciones
Nombre Estado origen
Acciones de I / O Evento de
Transiciones disparo
internas Condición de
Subestados guarda
Eventos diferidos Acción
Estado destino
Estado Inicial Estado Final
162. 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
164. 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. inicializar( Nombre Simulador )
idle Cargar IC
cargar nueva IC
freeze
Pasar a Run[ IC cargada ] ^Gestor MC.pasar_a_run
freeze
run
En Ejecución
comando simulación
run Interpretar
comando
after 0.5 seg
H* Esperar
Enviar Confirmación
Información
165
166. 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
167. El símbolo H 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*
167
168. 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
169. 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
mantener
Mantenimiento
Probar Autodiagno
Perifericos sis
continuar
Espera Orden
tecla pulsada
169
170. Introducción
Modelado estructural
Modelado del comportamiento
Modelado Básico
Modelado Avanzado
Eventos y Señales
Máquinas de Estados
Procesos y Hebras
Modelado arquitectónico
170
171. 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
172. 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
173. 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
174. Representación Gráfica:
<<active>>
Control comunicacion
Control comunicacion
estado estado
Ultimo mensaje Ultimo mensaje
reset() reset()
Señales Señales
mensaje recibido mensaje recibido
error_enviar error_enviar
error_recibir error_recibir
En realidad se trata de un estereotipo
En Rational Rose, no existe este
estereotipo, hay que crearlo
174
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
175
176. 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
177. 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
178. En Rational Rose los objetos activos se pueden especificar en la
definición de la clase, pero no como estereotipo:
178
179. 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
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
180