UML
Ingeniería de Software 1
Contenido
Desarrollo de soft OO usando UML
Introducción
Modelado del soft
UML (Conceptos básicos)
Paradigma OO
Fundamentos
Diagramas de CU
Diagramas de Interacciones
Diagramas de clase
Diagramas de estado/actividad
Diagrama de componentes
Diagrama de despliegue
Ingeniería de Software 2
Modelado del software
Ejemplos Modelado
Construcción de una Proceso bien
definido
cucha para un perro
Herramientas más
Puede hacerlo sofisticadas
una sola persona Construcción de un
Requiere: rascacielos
Modelado mínimo
Proceso simple Contexto de
Herramientas desarrollo
simples Determinar
Construcción de una configuración del
casa proceso
Recursos
Construida
necesarios
eficientemente y
Herramientas más
en un tiempo
sofisticadas aún.
razonable de un
equipo Ingeniería de Software 3
Claves en Desarrollo de SI
Notación
Herramientas Proceso
Ingeniería de Software 4
Abstracción - Modelado Visual (MV)
“El modelado captura las
partes esenciales del sistema”
Orden
Item
envío
Proceso de Negocios
Sistema Computacional
Ingeniería de Software 5
¿Qué es UML?
UML = Unified Modeling Language
Un lenguaje de propósito general para el
modelado orientado a objetos
Documento “OMG Unified Modeling
Language Specification”
UML combina notaciones provenientes
desde:
Modelado Orientado a Objetos
Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (Workflows)
Ingeniería de Software 6
Motivación
Diversos métodos y técnicas OO, con
muchos aspectos en común pero
utilizando distintas notaciones
Inconvenientes para el aprendizaje,
aplicación, construcción y uso de
herramientas, etc.
Pugna entre distintos enfoques (y
correspondientes gurús)
Establecer una notación estándar
Ingeniería de Software 7
Historia de UML
Comenzó como el “Método Unificado”, con
la participación de Grady Booch y Jim
Rumbaugh. Se presentó en el OOPSLA’95
Ingeniería de Software 8
Historia de UML
2001 UML 2.0
Ingeniería de Software 9
UML “aglutina” enfoques OO
Rumbaugh
Booch Jacobson
Odell
Meyer
Pre- and Post-conditions
Shlaer-Mellor UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
Ingeniería de Software 10
Aspectos Novedosos
Definición semi-formal del Metamodelo de
UML
Mecanismos de Extensión en UML:
Stereotypes
Constraints
Tagged Values
Ingeniería de Software 11
Inconvenientes en UML
Definición del proceso de desarrollo
usando UML. UML no es una metodología
Falta integración con respecto de otras
técnicas tales como patrones de diseño,
interfaces de usuario, documentación,
etc.
“Monopolio de conceptos, técnicas y
métodos en torno a UML”
Ingeniería de Software 12
Perspectivas de UML
UML será el lenguaje de modelado
orientado a objetos estándar
predominante los próximos años
Razones:
Participación de metodólogos influyentes
Participación de importantes empresas
Aceptación del OMG como notación estándar
Evidencias:
Herramientas que proveen la notación UML
“Edición” de libros
Congresos, cursos, etc.
Ingeniería de Software 13
Modelos y Diagramas
Un modelo captura una vista de un sistema del
mundo real. Es una abstracción de dicho sistema,
considerando un cierto propósito. Así, el modelo
describe completamente aquellos aspectos del
sistema que son relevantes al propósito del
modelo, y a un apropiado nivel de detalle.
Diagrama: una representación gráfica de una
colección de elementos de modelado, a menudo
dibujada como un grafo con vértices conectados
por arcos
OMG UML 1.4 Specification
Ingeniería de Software 14
... Modelos y Diagramas
Un proceso de desarrollo de software debe ofrecer un
conjunto de modelos que permitan expresar el
producto desde cada una de las perspectivas de interés
El código fuente del sistema es el modelo más
detallado del sistema (y además es ejecutable). Sin
embargo, se requieren otros modelos ...
Ingeniería de Software 15
Diagramas de UML
Ingeniería de Software 16
... Diagramas de UML
Los diagramas expresan gráficamente partes de un modelo
State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de
Diagrams Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboración Modelo Componentes
Scenario Component
Scenario Component
Diagramas
Diagrams de
Diagramas de
Diagrams Diagrams
Diagrams Distribución
Estados Diagramas de
Actividad
Ingeniería de Software 17
Organización de Modelos
Vista de
Vista Lógica Realización
Vista de los
Casos de Uso
Vista de Vista de
Procesos Distribución
Ingeniería de Software 19
Paquetes en UML
Los paquetes ofrecen un mecanismo
general para la organización de los
modelos/subsistemas agrupando
elementos de modelado
Se representan gráficamente como:
Nombre de
paquete
Ingeniería de Software 20
… Paquetes en UML
Cada paquete corresponde a un
submodelo (subsistema) del modelo
(sistema)
Un paquete puede contener otros
paquetes, sin límite de anidamiento pero
cada elemento pertenece a (está definido
en) sólo un paquete
Una clase de un paquete puede aparecer
en otro paquete por la importación a
través de una relación de dependencia
entre paquetes
Ingeniería de Software 21
… Paquetes en UML
Todas las clases no son
necesariamente visibles
desde el exterior del
paquete, es decir, un
paquete encapsula a la
vez que agrupa
El operador “::”
permite designar una
clase definida en un
contexto distinto del
actual
Ingeniería de Software 22
… Paquetes en UML
Ingeniería de Software 23
Diagrama de Casos de Uso
para captura de
requisitos Tipos de Venta
Ingeniería de Software 24
… Ejemplos
[Tarjeta Caducada]
<<extend>>
Venta en Rebajas
Vendedor
Ingeniería de Software 25
… Ejemplos
<<include>>
Reintegro Cuenta Corriente
<<include>>
Ingeniería de Software 26
Diagrama de Secuencia
prestar(video, socio)
verificar situación socio
registrar préstamo
entregar recibo
Ingeniería de Software 27
Diagrama de Colaboración
:Socio
:Video
5: entregar recibo
: Encargado 4: registrar préstamo
:Préstamo
Ingeniería de Software 28
Diagrama de Clases
Ingeniería de Software 29
Ejemplos
dirige director
Departamento Profesor
0..1 1
Ingeniería de Software 30
… Ejemplos (Clase Asociación)
empleador trabajadores
Empresa Empleado
* 1..*
Cargo
superior
nombre
sueldo 0..1
subordinado 1..*
Ingeniería de Software 31
… Ejemplos (Generalización)
Trabajador
{ disjunta, completa }
Ingeniería de Software 32
… Ejemplos
1..4 1..2 1
1 n
n
1 n 1 n
Avión Vuelo Reserva
n
{ disjunta, completa }
{ disjunta, completa }
Ingeniería de Software 33
Diagrama de Estados
alta baja
número_préstamos = 0
sin préstamos
Socio
número : int
nombre : char[50]
número_prestamos : int = 0
prestar devolver[ número_préstamos = 1 ]
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date)
número_préstamos > 0
con préstamos
prestar
Ingeniería de Software 34
Diagrama de Actividad
Encender máquina
/ cafetera.On
Café en preparación
indicador de fin
Servir café
Beber
Ingeniería de Software 35
… Otro Ejemplo (con swim lines)
Pasajero Vendedor Airline
Solicitar pasaje
Verificar
existencia vuelo
Informar alternativas
y precios
Seleccionar vuelo
Confirmar
Pagar pasaje plaza reservada
Emitir billete
Ingeniería de Software 36
Diagrama Componentes
Control y Análisis
Interfaz de T erminal
Comment
Comment
Ingeniería de Software 37
Diagrama de Despliegue
Comm ent
Rutinas de Conecci on
Comm ent
T erminal de Consul ta
Interfaz de T erminal
Rutinas de Conecci on
Comm ent Comm ent
Punto de Venta
Rutinas de Conecci on
Comm ent
Ingeniería de Software 38
Resumen
Ingeniería de Software 39
UML
Paradigma OO
Diagramas
Ingeniería de Software 40
¿Por qué la Orientación a Objetos?
Conceptos comunes
Proximidad de los conceptos de modelado durante
de modelado respecto de las el análisis, diseño e
entidades del mundo real implementación
Mejora captura y validación Facilita la transición
de requisitos
entre distintas fases
Acerca el “espacio del
problema” y el “espacio de la Favorece el desarrollo
solución” iterativo del sistema
Modelado integrado de Disipa la barrera
propiedades estáticas y entre el “qué” y el
dinámicas del ámbito del “cómo”
problema Sin embargo, existen
Facilita construcción, problemas ...
mantenimiento y reutilización
Ingeniería de Software 41
Problemas en OO
“...Los conceptos básicos de la OO se
conocen desde hace dos décadas, pero su
aceptación todavía no está tan extendida
como los beneficios que esta tecnología
puede sugerir”
“...La mayoría de los usuarios de la OO no
utilizan los conceptos de la OO de forma
purista, como inicialmente se pretendía.
Esta práctica ha sido promovida por
muchas herramientas y lenguajes que
intentan utilizar los conceptos en diversos
grados”
--Wolfgang Strigel
Ingeniería de Software 42
… Problemas en OO
Un objeto contiene datos y operaciones que
operan sobre los datos, pero ...
Podemos distinguir dos tipos de objetos
degenerados:
Un objeto sin datos (que sería lo mismo que una
biblioteca de funciones)
Un objeto sin “operaciones”, con sólo operaciones
del tipo crear, recuperar, actualizar y borrar (que se
correspondería con las estructuras de datos
tradicionales)
Un sistema construido con objetos degenerados
no es un sistema verdaderamente orientado a
objetos
“Las aplicaciones de gestión están constituidas
mayoritariamente por objetos degenerados”
Ingeniería de Software 43
Reflexiones respecto de Situación Actual de
Desarrollo de SI
DFDs DEs
Enfoque Entornos de
Estructurado E-R Programación
Modelo Visual
Diagramas de Casos de Uso Relacional
Diagramas de Actividad
Diagramas de Secuencia
Diagramas de Colaboración d Modelo
Relacional !! Bases de Datos
(Objeto-)
Enfoque OO Diagrama de Clases
Relacionales
Diagrama de Estados
Diagramas de Actividad
Ingeniería de Software 44
Diagramas de Casos de Uso
Ingeniería de Software 45
Casos de Uso
Los Casos de Uso (Ivar Comparación con respecto a los
Jacobson) describen bajo Diagramas de Flujo de Datos del
Enfoque Estructurado
la forma de acciones y Un caso de uso es una función
reacciones el atómica ofrecida por el sistema al
comportamiento de un entorno (actores)
sistema desde el p.d.v. del DFD puede ser detallada en un
usuario DFD Hijo
Caso Uso y Proceso igual
Permiten definir los límites modelado, pero caso de uso
del sistema y las expresa funcionalidad mediante
relaciones entre el sistema interacción de actores
y el entorno Caso de uno no modela detalle
funcional interno
Los Casos de Uso son Relaciones de extensión y
descripciones de la generalización de CU no tienen
funcionalidad del sistema igual en DFD
independientes de la
implementación
Ingeniería de Software 46
… Casos de Uso
Los Casos de Uso cubren
la carencia existente en
métodos previos (OMT,
Booch) en cuanto a la
determinación de
requisitos
Los Casos de Uso Actor A
Caso de Uso A
particionan el conjunto
de necesidades
atendiendo a la Caso de Uso B
categoría de usuarios Actor B
que participan en el
mismo
Están basado en el
lenguaje natural, es
decir, es accesible por
los usuarios
Ingeniería de Software 47
… Casos de Uso
Actores:
Principales: personas que usan el sistema
Secundarios: personas que mantienen o
administran el sistema
Material externo: dispositivos materiales
imprescindibles que forman parte del ámbito de la
aplicación y deben ser utilizados
Otros sistemas: sistemas con los que el sistema
interactúa
La misma persona física puede interpretar varios
papeles como actores distintos
El nombre del actor describe el papel
desempeñado
Ingeniería de Software 48
… Casos de Uso
Los Casos de Uso se determinan
observando y precisando, actor por actor,
las secuencias de interacción, los
escenarios, desde el punto de vista del
usuario
Un escenario es una instancia de un caso
de uso
Los casos de uso intervienen durante todo
el ciclo de vida. El proceso de desarrollo
estará dirigido por los casos de uso
Ingeniería de Software 49
Casos de Uso: Relaciones
UML define cuatro Inclusión : una
instancia del Caso de
tipos de relación Uso origen incluye
en los Diagramas también el
comportamiento
de Casos de Uso: descrito por el Caso
Comunicación de Uso destino
<<include>>
<<include>>
reemplazó al
Caso de Uso
Actor
denominado
<<uses>>
Ingeniería de Software 50
… Casos de Uso: Relaciones
Extensión : el Caso Herencia : el Caso
de Uso origen de Uso origen
extiende el hereda la
comportamiento especificación del
del Caso de Uso Caso de Uso
destino destino y
posiblemente la
modifica y/o amplía
<<extend>>
Ingeniería de Software 51
… Casos de Uso: Relaciones
Ejemplo:
Identificación
<<include>>
Transferencia
Cliente
<<extend>>
Transferencia en Internet
Ingeniería de Software 52
… Casos de Uso: Relaciones
Ejemplo:
Ingeniería de Software 53
Casos de Uso: Construcción
Un caso de uso debe ser simple, inteligible, claro
y conciso
Generalmente hay pocos actores asociados a cada
Caso de Uso
Preguntas clave:
¿cuáles son las tareas del actor?
¿qué información crea, guarda, modifica, destruye o
lee el actor?
¿debe el actor notificar al sistema los cambios
externos?
¿debe el sistema informar al actor de los cambios
internos?
Ingeniería de Software 54
… Casos de Uso: Construcción
La descripción del Caso de Uso comprende:
el inicio: cuándo y qué actor lo produce?
el fin: cuándo se produce y qué valor devuelve?
la interacción actor-caso de uso: qué mensajes
intercambian ambos?
objetivo del caso de uso: ¿qué lleva a cabo o
intenta?
cronología y origen de las interacciones
repeticiones de comportamiento: ¿qué operaciones
son iteradas?
situaciones opcionales: ¿qué ejecuciones
alternativas se presentan en el caso de uso?
Ingeniería de Software 55
RF- <id del requisito> <nombre del requisito funcional>
Versión <numero de versión y fecha>
Autores <autor>
Fuentes <fuente de la versión actual>
Objetivos asociados <nombre del objetivo>
Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de
activación> , abstracto durante la realización de los
casos de uso <lista de casos de uso>}
Precondición <precondición del caso de uso>
Secuencia Paso Acción
Normal 1 {El <actor> , El sistema} <acción realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n
Postcondición <postcondición del caso de uso>
Excepciones Paso Acción
1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de uso RF-x>, a continuación este caso
de uso {continua, aborta}
2
3
Rendimiento Paso Cota de tiempo
1 n segundos
2 n segundos
Frecuencia esperada <nº de veces> veces / <unidad de tiempo>
Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Comentarios <comentarios adicionales>
Ingeniería de Software 56
Modelo de Casos de Uso y
Modelo Conceptual (Análisis)
La especificación de cada caso de uso y
los correspondientes D. de Interacción
establecen el vínculo con el modelo
conceptual
En métodos OO que carecen de una
técnica de captura de requisitos se
comienza inmediatamente con la
construcción del modelo conceptual
(análisis)
Ingeniería de Software 57
Diagramas de Interacción
Ingeniería de Software 58
Interacción
Los objetos interactúan para realizar
colectivamente los servicios ofrecidos por
las aplicaciones. Los diagramas de
interacción muestran cómo se comunican
los objetos en una interacción
Existen dos tipos de diagramas de
interacción: el Diagrama de Colaboración
y el Diagrama de Secuencia
Mensajes:
Sintaxis para mensajes
Predecesor/fuarda secuencia:retorno := msg
(args)
Ingeniería de Software 59
Diagramas de interacción
El Diagrama de Secuencia es más
adecuados para observar la perspectiva
cronológica de las interacciones
El Diagrama de Colaboración ofrece una
mejor visión espacial mostrando los
enlaces de comunicación entre objetos
El D. de Colaboración puede obtenerse
automáticamente a partir del
correspondiente D. de Secuencia (o
viceversa)
Ingeniería de Software 60
Diagrama de Secuencia
Muestra la secuencia de mensajes
entre objetos durante un escenario
concreto
Cada objeto viene dado por una
barra vertical
El tiempo transcurre de arriba abajo
Cuando existe demora entre el
envío y la atención se puede indicar
usando una línea oblicua
Ingeniería de Software 61
… Diagrama de Secuencia
Ingeniería de Software 62
Diagrama de Secuencia
mostrando foco de control,
condiciones, recursión
creación y destrucción
de objetos
Ingeniería de Software 63
… Diagrama de Secuencia
Ingeniería de Software 64
Diagrama de Colaboración
Son útiles en la fase exploratoria para
identificar objetos
La distribución de los objetos en el
diagrama permite observar
adecuadamente la interacción de un
objeto con respecto de los demás
La estructura estática viene dada por los
enlaces; la dinámica por el envío de
mensajes por los enlaces
Ingeniería de Software 65
Mensajes
Un mensaje Un mensaje se
desencadena una
acción en el objeto envía de manera
destinatario condicionada:
Un mensaje se envía
si han sido enviados
los mensajes de una [x>y] 1: Mensaje
lista (sincronización): B
A
Ingeniería de Software 66
… Mensajes
Ingeniería de Software 67
Diagrama de Clases
Ingeniería de Software 68
Clasificación
El mundo real puede ser visto desde
abstracciones diferentes (subjetividad)
Mecanismos de abstracción:
Clasificación / Instanciación
Composición / Descomposición
Agrupación / Individualización
Especialización / Generalización
La clasificación es uno de los mecanismos
de abstracción más utilizados
Ingeniería de Software 69
Clases
La clase define el Cada clase se
ámbito de representa en un
rectángulo con tres
definición de un compartimientos:
conjunto de nombre de la clase
objetos atributos de la clase
Cada objeto operaciones de la
pertenece a una clase
clase motocicleta
Los objetos se
crean por color
cilindrada
instanciación de velocidad maxima
las clases arrancar
acelerar
Ingeniería de Software frenar 70
Clases: Notación Gráfica
Otros ejemplos:
lista
pila
primero
ultimo apilar
añadir desapilar
quitar cardinalidad
cardinalidad
Ingeniería de Software 71
Clases: Encapsulación
La encapsulación presenta dos ventajas
básicas:
Se protegen los datos de accesos indebidos
El acoplamiento entre las clases se disminuye
Favorece la modularidad y el mantenimiento
Los atributos de una clase no deberían ser
manipulables directamente por el resto de
objetos
Ingeniería de Software 72
… Clases: Encapsulación (Recordar)
Los niveles de encapsulación están
heredados de los niveles de C++:
(-) Privado : es el más fuerte. Esta parte es
totalmente invisible (excepto para clases
friends en terminología C++)
(#) Los atributos/operaciones protegidos están
visibles para las clases friends y para las clases
derivadas de la original
(+) Los atributos/operaciones públicos son
visibles a otras clases (cuando se trata de
atributos se está transgrediendo el principio de
encapsulación)
Ingeniería de Software 73
… Clases: Encapsulación
Ejemplo:
Reglas de visibilidad
+ "Operación pública"
# "Operación protegida"
- "Operación privada"
Ingeniería de Software 74
Relaciones entre Clases
Los enlaces entre de objetos pueden
representarse entre las respectivas clases
Formas de relación entre clases:
Asociación y Agregación (vista como un caso
particular de asociación)
Generalización/Especialización
Las relaciones de Agregación y
Generalización forman jerarquías de
clases
Ingeniería de Software 75
Asociación
La asociación expresa una conexión
bidireccional entre objetos
Una asociación es una abstracción de la
relación existente en los enlaces entre los
objetos
Universidad Estudiante
Una asociación
Ingeniería de Software 76
… Asociación
Ejemplo:
marido
casado-con 0.. 1
0.. 1 trabaja-para * Compañía
mujer Persona *
nombre emplea-a
jefe nombre
0.. 1 s. s. dirección
Administra * empleado
Ingeniería de Software 77
… Asociación
Especificación de multiplicidad
(mínima...máxima)
1 Uno y sólo uno
0..1 Cero o uno
M..N Desde M hasta N (enteros naturales)
* Cero o muchos
0..* Cero o muchos
1..* Uno o muchos (al menos uno)
La multiplicidad mínima >= 1 establece
una restricción de existencia
Ingeniería de Software 78
Asociación Cualificada
* 0..1
Aerolínea nro_billete Viajero
Tablero fila 1 1
columna
Cuadro
Ajedrez
Ingeniería de Software 79
Agregación
La agregación representa una relación
parte_de entre objetos
En UML se proporciona una escasa
caracterización de la agregación
Puede ser caracterizada con precisión
determinando las relaciones de
comportamiento y estructura que existen
entre el objeto agregado y cada uno de
sus objetos componentes
Ingeniería de Software 80
Agregación: Caracterización
Caracterizaciones relacionadas con la multiplicidad
Ingeniería de Software 82
Ejemplos
Ingeniería de Software 83
... Ejemplos
Ingeniería de Software 84
… Ejemplos
1 contiene
Agregación Polígono 3.. *
Punto
{ordenado}
* * Persona
Cuenta Asociación excluyente
or
*
Empresa
1
* está-autorizado-en *
Usuario Estación
Autorización
prioridad
Clase de asociación privilegios
camb_privil
Ingeniería de Software 85
Clases y Objetos
Diagrama de Clases y Diagramas de
Objetos pertenecen a dos vistas
complementarias del modelo
Un Diagrama de Clases muestra la
abstracción de una parte del dominio
Un Diagrama de Objetos representa una
situación concreta del dominio
Las clases abstractas no son instanciadas
Ingeniería de Software 86
Generalización
Permite gestionar la complejidad
mediante un ordenamiento taxonómico de
clases
Se obtiene usando los mecanismos de
abstracción de Generalización y/o
Especialización
La Generalización consiste en factorizar
las propiedades comunes de un conjunto
de clases en una clase más general
Ingeniería de Software 87
... Generalización
La Generalización y
Nombres usados: clase Especialización son
padre - clase hija. Otros equivalentes en
nombres: superclase - cuanto al resultado: la
subclase, clase base - jerarquía y herencia
clase derivada establecidas
Las subclases heredan Generalización y
propiedades de sus clases Especialización no son
padre, es decir, atributos operaciones reflexivas
y operaciones (y ni simétricas pero sí
asociaciones) de la clase transitivas
padre están disponibles
en sus clases hijas
Ingeniería de Software 88
... Generalización
Vehículo
Ingeniería de Software 89
... Generalización
La especialización es una técnica muy
eficaz para la extensión y reutilización
Coche
Restricciones predefinidas
Funcionando Estropeadoen UML:
disjunta - no disjunta
total (completa) - parcial (incompleta)
Ingeniería de Software 90
... Generalización
Particionamiento del
La noción de clase está espacio de objetos =>
próxima a la de conjunto Clasificación Estática
Dada una clase, podemos Particionamiento del
ver el conjunto relativo a espacio de estados de
las instancias que posee o los objetos =>
bien relativo a las Clasificación Dinámica
propiedades de la clase En ambos casos se
Generalización y recomienda considerar
especialización expresan generalizaciones/espe
relaciones de inclusión cializaciones disjuntas
entre conjuntos
Ingeniería de Software 91
... Generalización
Un ejemplo de Clasificación
Estática:
Vehículo Aéreo
{ estática }
Avión Helicóptero
Ingeniería de Software 92
... Generalización
Un ejemplo de Clasificación
Dinámica:
Coche
{ dinámica }
Funcionando Estropeado
Ingeniería de Software 93
... Generalización
Extensión: Posibles instancias de una
clase
Intensión: Propiedades definidas en una
clase
A
int(A) int(B)
ext(B) ext(A)
B
Ingeniería de Software 94
... Generalización
Clasificación Estática
C0
C1 Cn
Ingeniería de Software 95
... Generalización
Clasificación Dinámica
C0
ext(C0) = ext(Ci) completa
extt(Ci) extt(Cj) = disjunta en t
{ dinámica }
extt1(Ci) extt2(Cj) posiblemente
no disjunta en
C1 Cn diferentes
instantes
Ingeniería de Software 96
... Generalización
Ejemplo: varias especializaciones a partir de
la misma clase padre, usando
discriminadores:
Comercial Militar
uso
Vehículo Aéreo
estructura
Avión Helicóptero
Ingeniería de Software 97
Clasificación Múltiple (herencia múltiple)
Ingeniería de Software 98
… Herencia Múltiple
Uso disciplinado de la herencia múltiple:
clasificaciones disjuntas con clases padre en hojas de
jerarquías alternativas
Bípedo Cuadrúpedo
cubertura comida
Animal
Con Plumas cobertura
comida
cobertura Carnívoro
Con Escamas
Conejo
Ingeniería de Software 99
Principio de Sustitución
?
León Oso Tigre
Estados y Transiciones
A B
perder empleo
jubilarse
jubilarse
jubilado
estado A
entry: acción por entrar
exit: acción por salir
do: acción mientras en estado
on evento: acción
Ejemplo:
e1
A B
e2
e2
Quedaría como:
e1
Aa b
B
e2
C
Ingeniería de Software 115
… Generalización de Estados
e1
Aa Bb
e2
e0
e1
Aa b
B
e2 C
e0
La agregación de estados es la
composición de un estado a partir
de varios estados independientes
La composición es concurrente por
lo que el objeto estará en alguno de
los estados de cada uno de los
subestados concurrentes
Ejemplo:
e1
e1
Ejemplo:
Ejemplo:
A
d2
B
in
D x y
out
d1
C
H*
Ingeniería de Software 122
… Historia
Ejemplo:
Espera
La destrucción de un objeto es
efectiva cuando el flujo de control
del autómata alcanza un estado
final no anidado
La llegada a un estado final anidado
implica la “subida” al superestado
asociado, no el fin del objeto
Ejemplo:
crash
En vuelo
despegar aterrizar
Crear(matricula)
En tierra
Ejemplo: A
/ Abrir ranura
Depósito efectuado
B
Ingeniería de Software 127
Diagrama de Actividad
El Diagrama de Actividad es una
especialización del Diagrama de Estado,
organizado respecto de las acciones y
usado para especificar:
Un método
Un caso de uso
Un proceso de negocio (Workflow)
Las actividades se enlazan por
transiciones automáticas. Cuando una
actividad termina se desencadena el paso
a la siguiente actividad
Ejemplo:
Nodo
<<RDSI>>
<<RDSI>>
Podemos distinguir tipos Control
de nodos y connexiones
por estereotipado
Enfoque Ericsson
Ingeniería de Software 141
Dos dimensiones
tiempo
Workers Artefactos
Ingeniería de Software Actividades 145
... Elementos en RUP
Workers Testing professional
workers
Analyst workers • Test Designer
Business-Process • Tester
Analyst Manager workers
Business Designer • Change Control
Business-Model Manager
Reviewer • Configuration Manager
Requirements • Deployment Manager
Reviewer • Process Engineer
System Analyst • Project Manager
Use-Case Specifier • Project Reviewer
User-Interface Other workers
Designer
• Any Worker
Developer workers • Course Developer
Architect • Graphic Artist
Architecture • Stakeholder
Reviewer • System Administrator
Capsule Designer • Technical Writer
Code Reviewer • Tool Specialist
Database Designer
Design Reviewer
Designer
Implementer Ingeniería de Software 146
... Elementos en RUP
Workers, Actividades, Artefactos
Ejemplo: System Analyst Worker
Capturar, definir y
Requisitos
validar los casos de uso
Verificar que se
Pruebas satisfacen los casos
de uso
«trace» «trace»
«trace»
«trace»
Pruebas
Unitarias
Pruebas Funcionales X
Caso de Prueba
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
Ingeniería de Software 152
..Proceso dirigido por los casos de Uso
Análisis
Diseño
Codific.
n veces Pruebas e
Integración
Ingeniería de Software 155
... Proceso Iterativo e Incremental
Cada iteración comprende:
Planificar la iteración (estudio de riesgos)
Análisis de los Casos de Uso y escenarios
Diseño de opciones arquitectónicas
Codificación y pruebas. La integración del nuevo
código con el existente de iteraciones anteriores
se hace gradualmente durante la construcción
Evaluación de la entrega ejecutable (evaluación
del prototipo en función de las pruebas y de los
criterios definidos)
Preparación de la entrega (documentación e
instalación del prototipo)
Enfoque
Cascada
Enfoque
Iterativo e
Incremental
Architecture
Ingeniería de Software 159
Fases del Ciclo de Vida
El ciclo de vida consiste en una serie de ciclos,
cada uno de los cuales produce una nueva versión
del producto
Cada ciclo está compuesto por fases y cada una
de estas fases está compuesta por un número de
iteraciones
Las fases son:
Inicio o Estudio de oportunidad
Elaboración
Construcción
Transición
15%
Requisitos
Una iteración en la
fase de elaboración
Análisis
10%
Diseño 15%
Implementación
30%
Pruebas 15%
P re lim ina ry ite r. ite r. ite r. ite r. ite r. ite r. ite r.
Ite ra tion (s) #1 #2 #n # n+ 1 # n+2 #m #m +1
Requisitos
Una iteración en la
fase de elaboración
Análisis
Diseño
Implementación
Pruebas
Otro
Objeto
Banco de Valencia
Felipe
Cuenta Corriente 114
Azul
979 Kg
70 CV
...
Ejemplo de interacción:
Otro objeto
Un mensaje
Operacion 2
Un objeto
Operacion 1
… Comunicación
Categorías de objetos:
Activos - Pasivos
Cliente – Servidores, Agentes
Objeto Activo: posee un hilo de ejecución
(thread) propio y puede iniciar una
actividad
Objeto Pasivo: no puede iniciar una
actividad pero puede enviar estímulos una
vez que se le solicita un servicio
Cliente es el objeto que solicita un servicio.
Servidor es el objeto que provee el servicio
solicitado
Ingeniería de Software 179
… Comunicación
Servidor 2
Un cliente
Objeto 1
: Mensaje A
Objeto 2
: Mensaje C : Mensaje E
Objeto 3 Objeto 4
: Mensaje D
Ingeniería de Software 183
Mensaje y Estímulo
Un estímulo causará la invocación de una
operación, la creación o destrucción de un
objeto o la aparición de una señal
Un mensaje es la especificación de un estímulo
Tipos de flujo de control:
Llamada a procedimiento o flujo de control
anidado
Flujo de control plano
Retorno de una llamada a procedimiento
Otras variaciones
Esperado (balking)
Cronometrado (time-out)