análisis de sistemasUnidad 6 3 - Analisis DiagramasOO

Vista previa del material en texto

ANÁLISIS DE 
SISTEMAS
UNIDAD VI:
Análisis Orientado a Objetos
Diagramas
Conceptos
�Vista: subconjunto de UML que modela 
construcciones que representan una 
parte del sistema
�Área: nivel superior de las vistas
–Estructural: describe los elementos del 
sistema y sus relaciones con otros 
elementos
–Dinámica: describe el comportamiento del 
sistema en el tiempo
Área Estructural
Vista Diagramas Conceptos principales
Estática Clases Clase, asociación, 
generación, dependencia, 
realización, interfaz
Casos de 
uso
Casos de uso Caso de uso, actor, 
asociación, extensión, 
inclusión, generalización 
de casos de uso
Área Dinámica
Vista Diagramas Conceptos principales
Máquina de 
estados
De Transición de 
Estados
Estado, evento, transición, 
acción
Actividad Actividad Estado, actividad, 
transición, determinación, 
división, unión
Interacción
Secuencia Interacción, objeto, 
mensaje
Colaboración Colaboración, interacción, 
mensaje
Diagrama de Clases
generalización
clase
multiplicidad
asociación
clase asociación
navegabilidad
Persona
- atributo: 
+ operacion() : void
Vendedor Cliente
Pedido Producto
Origen
nota
ItemPedido
0..*
proviene de
1..1
0..*
incluye
1..*
1..1
sol icita
0..*
1..1
atiende
0..*
• Atributos:
[visibilidad] [/] nombre [multiplicidad] [:tipo] [= 
valor inicial] [{propiedades}]
• Operaciones:
[visibilidad] nombre [(lista de parámetros)] [:tipo 
de respuesta] [{propiedades}]
• Visibilidad:
existe definición a nivel público (+), privado (-) y 
protegido (#)
Cliente
+ apell ido: char = "xxx"
- cantidad: int = {valor}
+ oper1(int)
Partes de una Clases
Diferentes niveles de abstracción
• Algunas clases pueden tener diferentes niveles de abstracción:
• Es imprescindible distinguirlos y determinar cuál es el correcto:
• Probablemente una o todas las clases deberían integrar el modelo
Asociación
• Asociación: abstracción de los 
vínculos existentes entre los objetos
Clase Asociación
• Clase asociación: es una asociación que se 
modela como clase o viceversa
• Importante: la clase asociación tiene 
multiplicidad 1..1 con la asociación
Factura Artículo
ItemFacturado
0..* 1..*
Generalización
• Generalización: relación jerárquica entre clases 
en la que una clase hereda todos los miembros de 
otra más general (relación “tipo-de”)
Persona
- apell ido: 
- nombre: 
+ crear()
+ consultar()
Prestador
Criterios para generalizar
puede seres
subclases intermedias en jerarquías “anchas”
Persona
Empleado Cliente Prestador
Administrativ o Maestranza
{raíz}
{hoja}
Generalización Múltiple
¡Cuidado con los miembros
superpuestos o contradictorios!
Vehículo
VehículoDeAgua VehículoDeTierra VehículoDeAire
Anfibio
Agregación
• Agregación: relación jerárquica entre objetos 
en la que uno es el todo y los otros son las 
partes
• Agregación simple: relación todo-parte, 
contenedor-contenido,
conjunto-elemento
• Agregación de composición: agregación 
en la que las partes nacen
y mueren con el todo
Motor
Automóv il Conductor
1
Automóv il
Motor 1
• Guía para la construcción de Diagramas de Clases: 
• elaborar una lista de clases candidatas a partir de los 
requisitos
• detectar clases con diferentes niveles de abstracción
• definir las clases y colocarles sus atributos y 
comportamientos
•elegir la clase más representativa y colocarla en el 
centro del modelo
• asociar una a una el resto de las clases
• determinar multiplicidad y condicionalidad
• incorporar clases asociativas
•incorporar agregación y generalización
• verificar y validar el modelo contra los requisitos
Diagrama de Casos de Uso
actor caso de uso
Alumno Bibliotecario
Obtener préstamo
Devolver préstamo
Incorporar 
material a la 
biblioteca
Definición de Casos de Uso
Un caso de uso es una porción de la funcionalidad 
de un sistema descripta en términos de las 
interacciones de un actor con el sistema, con la 
finalidad de obtener un resultado de valor
• La funcionalidad se expresa en función de los 
resultados de valor esperados desde la perspectiva del 
usuario que interactúa con el sistema
• Los casos de uso se distribuyen con un criterio 
adecuado en el diagrama de casos de uso
• El conjunto de diagramas constituye el modelo de 
casos de uso
Definición de Actor
Toda persona, dispositivo, sistema organización 
o cosa que interactúa con el sistema con el fin de 
obtener un resultado de valor
• Persona, dispositivo, sistema, organización o cosa: 
en definitiva, todo lo que interactúe con el sistema
• Interactúa con el sistema: por lo tanto, no es parte 
del sistema; está fuera de él y permite demarcar la 
frontera del sistema
• Para obtener un resultado de valor: la interacción no 
es para realizar un proceso cualquiera, sino uno que 
permita alcanzar un objetivo o resultado de valor
Definición de Rol
Un rol es el papel que juega un actor en el 
momento de interactuar con el sistema
• Una persona, dispositivo, sistema, organización o 
cosa: puede jugar diferentes roles, por lo tanto, ser 
representado con diferentes actores
• Los roles (actores) tienen la particularidad de que 
pueden representar tanto conjuntos de objetos 
como objetos únicos
Modelado de Asociaciones
•Entre actores y casos de uso: asociación 
común con semántica de inicialización
• Entre actores: generalización
• Entre casos de uso: dependencias (con 
semánticas de extensión e inclusión) y 
generalización
Inclusión y Extensión
Alumno
Bibliotecario
Obtener préstamo
Incorporar 
material a la 
biblioteca
Consultar 
bibliografía
Incorporar a lista 
de espera
«extend»
«include»
«include»
Inclusión y Extensión
• «incluye» (include) se utiliza para extraer las 
parte comunes de los casos de uso; son casos de 
uso abstractos
•«extiende» (extend) se emplea para describir 
una funcionalidad que se agrega al caso de uso 
base en forma excepcional y que sin su existencia 
el caso de uso base igualmente alcanza su 
resultado de valor
• Los casos de uso abstractos son ejecutados por 
actores abstractos obtenidos de una estructura de 
generalización entre actores
Inclusión
Caso de Uso base 1
1. Paso del curso normal
2. Paso del curso normal
3. Paso del curso normal
4. Paso común
5. Paso común
6. Paso del curso normal
7. Paso del curso normal
8. Paso del curso normal
9. Paso del curso normal
Caso de Uso base 2
1. Paso del curso normal
2. Paso del curso normal
3. Paso del curso normal
4. Paso del curso normal
5. Paso del curso normal
4. Paso común
5. Paso común
6. Paso del curso normal
Caso de Uso común
1. Paso común
2. Paso común
Extensión
Caso de Uso base
1. Paso del curso normal
2. Paso del curso normal
3. Paso del curso normal
SI [condición] funcionalidad 
excepcional
4. Paso del curso normal
5. Paso del curso normal
6. Paso del curso normal
7. Paso del curso normal
8. Paso del curso normal
9. Paso del curso normal
Caso de Uso excepcional
1. Paso del curso normal
2. Paso del curso normal
3. Paso del curso normal
4. Paso del curso normal
5. Paso del curso normal
6. Paso del curso normal
7. Paso del curso normal
8. Paso del curso normal
Vista de Interacción
�Describe el intercambio de mensajes 
entre objetos para implementar el 
comportamiento de un sistema.
�Se muestra a través de dos 
diagramas centrados en diferentes 
aspectos:
–Secuencia: en la secuencia temporal de 
los mensajes
–Colaboración: en las relaciones entre 
objetos
Diagrama de Secuencia
 : Encargado
:WInPréstamos :Socio :Video :Préstamo
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
Diagrama de Colaboración
 : Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo
5: entregar recibo
Vista de Máquina de Estados
�Describe el comportamiento 
dinámico de los objetos, en un cierto 
plazo. 
�Modela las posibles historias de vida 
de un objeto de una clase.
�Cadaobjeto detecta eventos y 
responde a ellos.
Diagrama de Transición de 
Estados
� Estado describe un período de tiempo durante la 
vida de un objeto de una clase. 
Puede ser caracterizado como: 
– un conjunto de valores de objeto cualitativamente 
similares en cierta forma,
– el período de tiempo durante el cual un objeto espera 
que ocurra algún evento, 
– el período de tiempo durante el cual un objeto realiza 
una cierta actividad.
� Eventos representan las clases de cambios que 
un objeto puede detectar.
� Transición es la respuesta de un objeto a un 
evento dejando un estado para pasar a otro.
Ejemplo de D.T.E.
�Objeto:
Socio
Vista de Actividades
�Un diagrama de actividades muestra 
el flujo de actividades software 
implicadas en la ejecución de un 
proceso. 
�Permite entender el comportamiento 
de la ejecución de un sistema.
Diagrama de Actividades
� Actividad es un conjunto de acciones en 
ejecución.
� Cuando una actividad termina procede a 
ejecutar la siguiente, mostrando así el 
flujo de trabajo. 
� Las acciones incluyen llamadas a otras 
operaciones, envío de señales, creación o 
destrucción de objetos o simples cálculos, 
como la evaluación de una expresión
Diagrama de Actividades
�Flujo de objetos: se puede mostrar 
este flujo, relacionando los estados 
de los objetos con la actividad donde 
se produce.
�Calles: para organizar el diagrama se 
puede utilizar calles que representan 
una unidad organizativa que realiza 
las tareas.
Diagrama de Actividades
� Elementos:
– Actividad 
– Transición 
– Bifurcación
– Barra de División
– Barra de Unión 
Proveedor Ventas Contaduría
Ejemplo
Buscar Bebida [ no hay café ]
Poner café 
en filtro
Añadir agua 
al depósito
Coger taza
Poner filtro 
en máquina
Encender 
máquina
Café en 
preparación
/ cafetera.On
Servir café Beber
Coger 
zumo
[ hay café ]
indicador de fin
[ hay zumo ]
[ no zumo ]
Ejemplo
Ejemplo
Diagrama de Paquetes
�Los paquetes son una forma natural 
de agrupamiento del UML. 
�Pueden contener clases y casos de 
uso y se pueden anidar. 
�Cada elemento pertenece a un único 
paquete. Su utilización por otro 
paquete se hace por medio de la 
relación de dependencia entre 
paquetes o por anidamiento.
Diagrama de Paquetes
C.U.: 
Dar alta bibliografía
Actualizar bibliografía
Consultar bibliografía
Clases:
Bibliografía
Libro
Revista
Bibliografía
C.U.: 
Dar alta socios
Pagar cuota
Consultar socios
Clases:
Socio Alumno
Docente Cuota
Socio
C.U.: 
Solicitar préstamo
Devolver préstamo
Clases:
Préstamo
Régimen préstamo
Préstamos
Patrones
� En Buschmann ’96 se definen 3 tipos de 
patrones para la construcción de software:
Patrones arquitectónicos: aspectos 
fundamentales de la estructura de un sistema 
software. Especifican un conjunto predefinido 
de subsistemas con responsabilidades y una 
serie de recomendaciones para organizar los 
distintos componentes
– Patrones de Diseño: sobre aspectos 
relacionados al diseño de software. Por lo 
tanto se centran en aspectos mas específicos
– Patrones de bajo nivel para un lenguaje 
específico
Patrón Arquitectónico: Modelo en 
capas
Patrón Arquitectónico: Modelo en 
capas
Se asocia con el estereotipo de clases del análisis conocido 
como INTERFAZ
Patrón Arquitectónico: Modelo en 
capas
Se asocia con el estereotipo de clases del análisis conocido 
como CONTROL
Patrón Arquitectónico: Modelo en 
capas
Se asocia con el estereotipo de clases del análisis conocido 
como ENTIDAD