Análisis de Sistemas Administrativos
Unidad 1.1 Análisis y Diseño OO
Facultad de Tecnología Informática UAI
Mg. Carlos Gerardo Neil 2008
Análisis de Sistemas Administrativos
Unidad 2.1
UML y el Proceso de Desarrollo de Software
Facultad de Tecnología Informática UAI
Mg. Carlos Gerardo Neil 2008
Programa de la Asignatura1.1. Análisis y diseño OO 2.1. Proceso de desarrollo de software. 1º parte3.1. Casos de uso 3.2. Diagramas de clases. 3.3. Diagramas de comunicación. 3.4. Diagramas de secuencia. 4.1. Lenguaje de restricción de objetos. 5.1. Patrones de Diseño. 6.1. Transformación del Modelo de Clases al Modelo ER 7.1. Proceso de desarrollo de software 2º parte
Clase anterior – repaso general
• ¿Cuál la diferencia entre el análisis y diseño Estructurado y el OO?
• ¿Cuál es la diferencia entre análisis, diseño e implementación y que es lo que realizo en cada una de estas actividades?
• ¿Vinculo la etapa de análisis con la descripción del modelo de dominio de la aplicación?
• ¿Comprendo cual es el uso de las tarjetas CRC?
• ¿Cuál es el objetivo de la abstracción y el encapsulamiento?
• ¿Cuál es la diferencia entre mensajes, operaciones y método?
• ¿Qué diferencia existe entre asociación, agregación y composición?
• ¿Cuál es la diferencia entre generalización y herencia?
UML
• ¿Qué son los modelos?• ¿Para qué sirven los modelos?• Tipos de modelos y perspectivas
¿Cuáles son los modelos de UML?
¿Se usan todos...?
¿Qué son los modelos?
• Un modelo es una representación que capta los aspectos más importantes de lo que estamos modelando y simplifica u omiten el resto
• Es la representación de una abstracción
• Un modelo de un sistema software está construido en un lenguaje de modelado. Tiene semántica y notación. Incluye gráficos y texto
• El modelo es la columna vertebral de un lenguaje utilizado por todos los integrantes del equipo:
Desarrolladores Expertos del dominio Usuarios Analistas
¿Para qué sirven los modelos?
Ayudan a la comprensión de sistemas complejos
Indican QUÉ hará el sistema pero NO CÓMO lo hará
Ayuda a la corrección de errores
Ayuda a la evolución y reuso
Esencial para la comunicación entre miembros de un equipo
Tipos de modelos y perspectivas
Usando la misma notación (UML) se pueden considerar tres perspectivas:
• Esencial o conceptual: los diagramas describen cosas del mundo real o dominio de interés
• De especificación: los diagramas describen abstracciones software independientes de la implantación
• De implantación: los diagramas describen implementaciones software en un lenguaje particular
Orígenes de UMLA mediados de los noventa existían muchos métodos de Análisis y Diseño OO
Los mismos conceptos se representaban con distinta notación Existía mucha confusión No existía un lenguaje líder de modelado
En 1994 deciden unificar sus métodos:
Unified Modeling Language (UML)
El proceso de estandarización promovido por OMG comenzó en 1997
G. Booch (Método Booch) J. Rumbaugh (OMT) I. Jacobson (Proceso Objectory)
¿Qué es UML?
UML es un lenguaje estándar para:
visualizar
especificar
construir
documentar
los artefactos de un sistema.
¿Dónde Usamos UML?
Usamos UML en todas las etapas del proceso de desarrollo
¿Para qué sirve UML?
UML permite:
– Definir los límites del sistema y sus principales funciones, mediante Casos de Uso y actores.
– Ilustrar el funcionamiento de un caso de uso mediante Diagramas de Interacción
– Representar la estructura de un sistema mediante Diagramas de Clases.
– Modelar el comportamiento de los objetos mediante Diagramas de Máquinas de Estados.
¿Cómo extendemos UML?
UML incluye tres construcciones principales de extensión:
Restricciones: una declaración textual de una relación semántica expresada en un cierto lenguaje formal (OCL) ó en lenguaje natural.
Estereotipos: una nueva clase de elemento del modelo, ideada por el modelador, y basada en un tipo existente de elemento del modelo.
Valores etiquetados: una porción de información con nombre, unida a cualquier elemento del modelo.
Diagramas UML
Use CaseDiagramsUse Case
DiagramsDiagramas de Casos de Uso
ScenarioDiagramsScenario
DiagramsDiagramas deComunicacion
StateDiagramsState
DiagramsDiagramas deComponentes
ComponentDiagramsComponent
DiagramsDiagramas deDespliegue
StateDiagramsState
DiagramsDiagramas de Objetos
ScenarioDiagramsScenario
DiagramsDiagramas deEstados
Use CaseDiagramsUse Case
DiagramsDiagramas deSecuencia
StateDiagramsState
DiagramsDiagramas deClases
Diagramas deActividad
Modelo
Diagrama de Casos de Uso
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
Muestra las distintas operaciones que se esperan de un sistema y cómo se relacionan con su entorno
Diagrama de Clases
tiene
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Cliente
nombreapellidodireccionteprof esion
0..*
1
0..*
1
tiene
Autor
nombreapellido
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
1..*
1
1..*
1
tiene
Items
cantidad
1..*
1
1..*
1
1
0..*
1
0..* pertenecen
Muestra las distintas las clases atributos, métodos y relaciones entre ellas
Diagramas de Secuencia (objetos)
: Encargado:WInPréstamos :Socio :Video :Préstamo
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
Muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo
Diagrama de Comunicación (objetos)
: Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo5: entregar recibo
Muestra la forma de representar interacciones entre objetos,
Diagrama de Estados
con préstamos
sin préstamos
alta baja
prestar devolver[ número_préstamos = 1 ]
prestar
devolver[ número_préstamos > 1 ]
número_préstamos = 0
número_préstamos > 0
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro
inicio
fin
estado
transición
Diagrama de Actividad
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 ]
Muestran transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos.
Diagrama de Componentes
Interfaz de Terminal
Gestión de Cuentas Rutinas de conexión Acceso a BD
Control y Análisis
Muestra las dependencias lógicas entre componentes software
Módulos
Elementos físicos
por ejemplo Archivos, bibliotecas
dependencias
Servicios ofrecido por otros componentes
Diagrama de Despliegue
Punto de Venta
Servidor Central
Terminal de Consulta
Gestión de Cuentas
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Rutinas de Coneccion
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Acceso a BD
Comment
Control y Análisis
Comment
Muestran la organización de los componentes del sistema
nodo
comunicación
Proceso de Unificado de Desarrollo
Proceso Unificado de desarrollo
UML no es un proceso...
...UML es una notación
Por lo tanto precisa de un proceso de desarrollo (ciclo de vida) que especifique la secuencia de actividades que deben realizarse
Proceso Unificado de desarrollo/2
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Ciclo de vida en cascada
Ciclo de vida en espiral
Proceso Unificado
Proceso Unificado (PU)
Proceso de Desarrollo de Software
Conjunto de actividades para transformar los requisitos del usuario en un sistema software
Proceso Unificado (UP)
• Dirigido por Casos de Uso• Centrado en la Arquitectura• Iterativo e Incremental
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
tiene
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Cliente
nombreapellidodireccionteprof esion
0..*
1
0..*
1
tiene
Autor
nombreapellido
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
1..*
1
1..*
1
tiene
Items
cantidad
1..*
1
1..*
1
1
0..*
1
0..* pertenecen
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Dirigido por Casos de Uso
• Los casos de uso representan los requisitos funcionales y guían el diseño, la implementación y la prueba
• Basándose en los casos de uso los desarrollares crean modelos de diseño e implementación que llevan a cabo los casos de uso
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
tiene
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Cliente
nombreapellidodireccionteprof esion
0..*
1
0..*
1
tiene
Autor
nombreapellido
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
1..*
1
1..*
1
tiene
Items
cantidad
1..*
1
1..*
1
1
0..*
1
0..* pertenecen
Centrado en la Arquitectura
• La arquitectura es una vista de diseño con las características más importantes, dejando los detalles de lado. Describe diferentes vistas del sistema
• Constituyen la “forma del sistema”, incluye aspectos estáticos y dinámicos
• La arquitectura y los casos de uso evolucionan en paralelo
Autor
nombreapellido
ClienteOcacional ClienteEspecializado
profesion
DireccionCompra
callenumero
OpcionEntrega
tipo
Tarjeta
nombrenumero
OrdenCompra
numero
IngresarPref erencias()
1
1
1
1
1
1
1
1
1
1
1
1
Cliente
nombreapellidodireccionte
ingresarDatos()
0..*1 0..*1 tiene
CarritoCompra
agregarItem()v enta()
1
1
1
1
es de
1
1
1
1
usa
Items
cantidad
crear()subtotal()
1..*
1
1..*
1
tiene
EjemplarLibro
numero
darPrecio()1
0..*
1
0..* pertenecen
Categoria
tipo
Libro
isbntituloeditorial
ConsultarLibro()
1..* 1..*1..* 1..*escrito por
1..*
1
1..*
1
tiene
1
1..*
1
1..*
pertenece
Iterativo e Incremental/1
• Desarrollo iterativo:
El desarrollo se organiza en una serie de mini proyectos de duración fija, llamados iteraciones (2 a 6 semanas)
• El resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado.
• Cada iteración incluye sus propias actividades de: análisis de requisitos, diseño, implementación y prueba
Iterativo e Incremental/2
• El sistema crece incrementalmente a lo largo del tiempo, iteración tras iteración.
• El resultado de cada iteración es un sistema ejecutable, pero incompleto
• En general, cada iteración aborda nuevos requisitos y amplia el sistema incrementalmente
• La salida de una iteración NO es un prototipo desechable, es un subconjunto de calidad del sistema final
Disciplinas y fases
Disciplina: conjunto de actividades y artefactos vinculados en una área determinada: requisitos, diseño, implementación, etc.
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Fases: periodo de tiempo entre dos hitos principales de un proceso de desarrollo
Ciclo de desarrollo
punto en donde han de tomarse decisiones importantes
Sistema en ambiente de producción
Fases del Proceso Unificado
• Inicio: visión aproximada, incluye: análisis del negocio, alcance, estimaciones imprecisas
• Elaboración: visión refinada, implementación iterativa del núcleo central de la arquitectura, resolución de riesgos altos, identificación de más requisitos
• Construcción: implementación iterativa del resto de requisitos de menor riesgo
• Transición: pruebas beta
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Fase de inicio
Fase de inicio/1
Actividades a realizar (una o algunas)
• Visión y análisis del negocio (objetivos y restricciones de alto nivel)
• Modelo de casos de uso (requisitos funcionales y no funcionales relacionados)
• Especificaciones complementarias (otros requisitos)
• Listas de riesgos (del negocio, técnicos, etc.)
• Prototipos (para clarificar la visión)
• Plan de iteración (qué hacer en la primera iteración)
Fase de inicio/2
No se entendió la fase de inicio si...
• La duración es mayor a unas pocas semanas
• Se intenta definir la mayoría de los requisitos
• Se espera que los planes y la estimación sea fiable
• Se define la arquitectura
• No se identifican la mayoría de de los nombres de los casos de uso y los actores
• Se escribieron todos los casos de uso en detalle
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Fase de elaboración
Fase de elaboración/1
Actividades a realizar
• Se descubren y estabilizan la mayoría de los casos de uso
• Se reducen o eliminan los riesgos importantes
• Se implementan y prueban los elementos básicos de la arquitectura
• Duración: 2 a 4 iteraciones con una duración de 2 a 6 semanas (dependiendo de la duración del proyecto)
Fase de Elaboración/2
Artefactos de la fase de elaboración
• Modelo del dominio (entidades del dominio)• Modelo de diseño (diagramas de clases, de iteración.
etc)• Modelo de datos• Modelo de pruebas• Modelos de implementación
El producto resultante no es un prototipo desechableEl código y el diseño son de calidad y se integran al sistema
final
Fase de Elaboración/3
No se entendió la fase de elaboración si...
• Sólo comprende una iteración
• La mayoría de los requisitos se definieron antes de la elaboración
• NO hay programación de código ejecutable
• Se intenta llevar a cabo un diseño completo antes de la codificación
• Los usuarios no se involucran en la evaluación
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Fase de construcción
Fase de Construcción
• Objetivos
• Terminar de construir la aplicación
• Realizar pruebas alfa
• Preparar pruebas beta (para la transición)
• Preparación de guías de usuario
• Preparación de materiales de aprendizaje
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Fase de transición
Fase de Transición
Objetivo: poner el sistema en producción
Actividades
• Realización de pruebas beta
• Reaccionar a la retroalimentación a partir de las pruebas beta
• Conversión de datos
• Cursos de entrenamiento
Bibliografía Básica
Larman C. UML y patrones. Una introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado. 2ª ed. Madrid: Prentice-Hall; 2003.
Jacobson I. Booch G. Rumbaugh J. El Proceso de Desarrollo Unificado. Addison-Wesley. 2000
Sugerencias
• Recuerde que cada fase, si bien pasa por todas las disciplinas (análisis, diseño, etc.) pone énfasis en algunas de ellas más que en otras
• Valore la importancia de los casos de uso (unidad 3.1). A partir de ellos se crean todos los demás modelos del sistema
• Tenga en cuenta que después de cada iteración (que corresponde aproximadamente a un ciclo de vida en cascada) se va definiendo un sistema ejecutable, pero incompleto, que debe corroborar con el usuario
• Recuerde que inicio no es igual a requisitos, elaboración no es igual a análisis y construcción no es igual a diseño, etc
• Recuerde que cada iteración tiene un duración fija de 2 a 6 semanas aproximadamente dependiendo de la magnitud del proyecto
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 2.1 si puedo definir y dar ejemplos de:
• Disciplinas / Fases
• Fase de inicio
• Fase de elaboración
• Fase de construcción
• Fase de transición
• Desarrollo iterativo e incremental
• Interpreto en el gráfico que significan las “montañitas”
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Auto evaluación/2Comprendí los conceptos más importantes de la unidad 2.1, si
• Conozco por qué usamos modelos y no directamente codificamos
• Entiendo en qué etapas del proceso de desarrollo utilizo UML
• Entiendo la diferencia entre el ciclo de vida en cascada y el UP
• Comprendo la relación que existe entre disciplinas de UP y el ciclo de vida en cascada
• Entiendo qué tienen en común el ciclo de vida en espiral y el UP
• Comprendo en qué hacen énfasis cada una de las fases del UP
• Entiendo cuál es el producto final de cada iteración
2º parte
Proceso de desarrollo “simplificado”
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Primera iteración
ETAPA DE INICIO
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
Comenzamos con los casos de uso.Inicialmente el nombre y una descripción
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Primera iteración
ETAPA DE ELABORACIÓN
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
Describimos los casos de uso con mayor detalle.
Escenario principal
El cliente ingresa a la pagina Web de CVLIEl cliente ingresa a la opción “registración “El sistema solicita ingreso de los datos personalesEl sistema evalúa el país….…..
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Primera iteración
ETAPA DE ELABORACIÓN
Creamos los diagramasde secuencia de sistemas para cada caso de uso.
Escenario principal
El cliente ingresa a la pagina Web de CVLIEl cliente ingresa a la opción “registración “El sistema solicita ingreso de los datos personalesEl sistema evalúa el país.…..
: SISTEMA
: cliente ingresarSistema()
ingresarDatosPersonales()
ingresarTarjetaCredito()
ingresarPreferenciasEnvio()
ingresarClaveContraseña()
DSS "Registrarse al sistema"
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Primera iteración
ETAPA DE ELABORACIÓN
Creamos el modelo del dominio: CLASES, ASOCIACIONES, ATRIBUTOS
Autor
nombreapellido
ClienteOcacional ClienteEspecializado
profesion
DireccionCompra
callenumero
OpcionEntrega
tipo
Tarjeta
nombrenumero
OrdenCompra
numero
IngresarPref erencias()
1
1
1
1
1
1
1
1
1
1
1
1
Cliente
nombreapellidodireccionte
ingresarDatos()
0..*1 0..*1 tiene
CarritoCompra
agregarItem()v enta()
1
1
1
1
es de
1
1
1
1
usa
Items
cantidad
crear()subtotal()
1..*
1
1..*
1
tiene
EjemplarLibro
numero
darPrecio()1
0..*
1
0..* pertenecen
Categoria
tipo
Libro
isbntituloeditorial
ConsultarLibro()
1..* 1..*1..* 1..*escrito por
1..*
1
1..*
1
tiene
1
1..*
1
1..*
pertenece
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Primera iteración
ETAPA DE ELABORACIÓN
Asignamos responsabilidadesa las clases, asistidos por los patrones de ASIGNACION DERESPONSABILIDADES
CarritoCompra
venta()
1..*
11
tiene
1..*
Items
cantidad
subtotal()
0..* pertenecen
1
0..*
1
EjemplarLibro
numeroprecio
darPrecio()
: Items : CarritoCompra1: crear( parametros )
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Primera iteración
ETAPA DE ELABORACIÓN
Transformamos el modelo de clases a un modelo dedatos y luego al modelo relacional
CLIENTE
EJEMPLARLIBRO
cod_cli
num_ejemp
1
1
ORDENCOMPRA
1
1
1
cod_carro
cod_ord
AUTOR LIBRO
cod_librocod_autor
ITEMS
num_item
CARRITOCOMPRA
1
N
N
N 1
1
N
N N
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Primera iteración
ETAPA DE ELABORACIÓN
Codificamos y probamos.
Mostramos el ejecutable al usuario
public class AdaptadorFigura extends Figura{private int x;
public AdaptadorFigura(){ variables
x = 0; }}
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
Segunda iteración
ETAPA DE ELABORACIÓN
Comenzamos una nueva iteración trabajando con nuevos casos de uso (o mejorando los anteriores)
Fin
Programa de la Asignatura
1.1. Análisis y diseño OO 2.1. Proceso de desarrollo de software. 1º parte3.1. Casos de uso 3.2. Diagramas de clases. 3.3. Diagramas de comunicación . 3.4. Diagramas de secuencia. 4.1. Lenguaje de restricción de objetos. 5.1. Patrones de Diseño. 6.1. Transformación del Modelo de Clases al Modelo ER 7.1. Proceso de desarrollo de software. 2º parte
Introducción
Consideraciones Generales
EL paradigma OO se impuso por…
• Conceptos comunes de modelado a lo largo de todo el ciclo de vida
• Reducción de la brecha entre el mundo de los problemas y el mundo de los modelos
• Aumento de complejidad de los sistemas
• Aumento de la necesidad de reutilización
• Uso de patrones
Análisis, Diseño, Implantación
• El análisis OO pone énfasis en la investigación del problema y los requisitos, en vez de ponerlo en la solución
• El diseño pone énfasis en una solución conceptual, que satisface los requisitos, en vez de ponerlo en la implantación
• La implantación es la traducción de la solución a un lenguaje de programación determinado
Análisis OO vs. Diseño OO
• Durante el análisis OO se presta especial atención a encontrar y describir los objetos (conceptos) del dominio del problema
• Durante el diseño OO se presta atención a la definición de los objetos software y en como colaboran para satisfacer los requisitos
Clientenombreapellido
Cliente
concepto del dominio
visualizacion de los conceptos del dominio
representacion en un lenguaje de programación
public class Cliente
{ private String nombre
private String apellido
public void imprimirNombre()
…….. }
Análisis OO
• La finalidad del análisis OO es crear una descripción del dominio desde una perspectiva de clasificación de objetos: identificación de conceptos, atributos e interrelaciones significativas
• El modelo del dominio NO es una descripción de los objetos software, es una visualización de los conceptos del mundo real y sus vinculaciones (se representan mediante diagrama de clases, sin operaciones)
Abstracción y Encapsulamiento
La abstracción es la propiedad que permite representar las características esenciales de un objeto, sin preocuparse de las restantes características (no esenciales).
El Encapsulamiento es la propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior .
El encapsulamiento, al separar el comportamiento del objeto de su implantación, permite la modificación de éste sin que se tengan que modificar las aplicaciones que lo utilizan
Clases conceptuales
• Una clase conceptual se puede considerar en términos de:
• Símbolo: palabras o imágenes que representan la clase conceptual
• Intensión: la definición de la clase conceptual
• Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual
Una venta representa una transacción de compra
venta 1
venta 2
venta 3
Ventafechahora
Modelo del dominio
Análisis = descomposición de un dominio de interés en clases conceptuales
Modelo del dominio = representación visual de las clases conceptuales del mundo real
Se visualizan en el modelo de dominio:
• Clases conceptuales• Asociaciones entre clases
conceptuales• Atributos de las clases
conceptuales
ArticulonroSerie
Especificaciondescripcionprecio
describe
Responsabilidades
• Una responsabilidad es un contrato u obligación de una clase
• Una clase puede tener cualquier numero de responsabilidades, pero una clase bien estructurada debería tener al menos una y como mucho unas pocas (alta cohesión)
• Las responsabilidades se describen inicialmente con texto libre
• Al ir refinando los modelos, las responsabilidades se traducirán en el conjunto de atributos y operaciones que satisfagan esas responsabilidades
(ver guía 5.1 Patrones de Diseño para Asignación de Responsabilidades)
Tarjetas CRC (Colaboración-Responsabilidad-Clase)
Por cada clase describimos:
El nombre de la clase y su descripciónLa responsabilidad de la clase
– Conocimiento interno de la clase– Servicios brindados por la clase
Los colaboradores para las responsabilidades– Un colaborador es una clase cuyos servicios son necesarios para una
responsabilidad
Usaremos una adaptación de las tarjetas CRC como primera aproximación para luego refinar las clases en la etapa de diseño
Tarjetas CRC
El nombre de la clase: es importante que el nombre refleje la esencia de lo que hace la clase
Las responsabilidades de la clase: determinan qué debe hacer. Estas responsabilidades pertenecen, esencialmente, a dos categorías: hacer y conocer
HACERHacer algo uno mismo.Iniciar una acción en otros objetos.Controlar y coordinar actividades en otros objetos
CONOCERConocer los datos privados encapsulados.Conocer los objetos relacionados.Conocer las cosas que se pueden derivar o calcular.
Las colaboraciones de la clase especifican con qué otras clases interactúan
Tarjetas CRC (adaptación)
Ejemplo
RESPONSABILIDADES COLABORACIONES
Agregar un estudiante ESTUDIANTE
Conocer los prerrequisitos
Conocer cuándo el curso es dado
Conocer dónde es dado el curso
Nombre de la clase: CURSO Descripción: específica el curso….
HACER
CONOCER
Diseño OO
• La finalidad del diseño OO es definir los objetos software y sus colaboraciones (se utilizan en esta etapa diagramas de interacción: comunicación y secuencia)
• A diferencia del modelo del dominio, este modelo no muestra conceptos del mundo real, sino clases software, con atributos operaciones y asociaciones
Objetos
“Un objeto es cualquier cosa real o abstracta, acerca de la cual almacenamos datos y las operaciones que controlan dichos datos”
Se opone al análisis estructurado donde los datos y el comportamiento están débilmente relacionados
Tenemos que olvidarnos del modelo estructurado...
Propiedades de los Objetos
“El estado de un objeto abarca todas las propiedades (normalmente estáticas) del mismo, más los valores actuales (normalmente dinámicos) de cada una de esas propiedades”
“El comportamiento nos muestra como actúa y reacciona un objeto, en términos de sus cambios de estado y paso de
mensajes”
“La identidad es aquella propiedad de un objeto que lo distingue de todos los demás objetos”
Clases
Una clase especifica una estructura de datos y las operaciones permisibles que se aplican a cada uno de sus objetos.
Los objetos se vinculan mediante enlaces enviando mensajes a operaciones que activan los métodos
• Mensaje: es una solicitud para que se lleve a cabo la operación indicada y se produzca el resultado.
• Operaciones: es una función o transformación que se aplica a un objeto de una clase
• Métodos: es la implementación de una operación
“Un objeto es una instancia de una clase”
Relaciones de Asociación
“Se descompone (clases) para comprender, se une (asociación) para contruir”
• Los enlaces entre objetos son instancias de la asociación entre sus clases
• La asociación representa un acoplamiento débil, la Agregación y la Composición expresa un acoplamiento más fuerte en clases
Relaciones de Jerarquía
• La generalización consiste en factorizar los elementos comunes de un conjunto de clases en una clase más general llamada superclase
• La herencia es una técnica de los lenguajes de programación para construir una clase a partir de una o varias clases, compartiendo atributos y operaciones
Polimorfismo/1Permite la posibilidad de desencadenar operaciones diferentes en
respuesta a un mismo mensaje
el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operación de
diferentes formas, según sea el objeto que se referencia en ese momento.
Circulo
dibujar()mover()
Rectangulo
dibujar()mover()
Triangulo
dibujar()mover()
Figura
dibujar()mover()
Editor
Polimorfismo/2
Circulo
dibujar()mover()
Rectangulo
dibujar()mover()
Triangulo
dibujar()mover()
Figura
dibujar()mover()
Editor
La interacciones entre objetos se escriben según los términos de las especificaciones definidas en las superclases
El método dibujar() no es igual para cada figura
Redefino en las subclases el método dibujar()
Cada vez que se invoque el método dibujar() dependerá de la
clase a la pertenece el objeto
unCirculo.dibujar();
UnTriangulo.dibujar();
unRectangulo.dibujar();
Análisis Estructurado vs. Análisis Orientado a Objetos
El enfoque tradicional del análisis y diseño estructurados, se descompone el problema en funciones o procesos y estructuras de datos
En un enfoque OO se busca descomponer el problema, no en funciones, sino en unidades más
pequeñas denominadas objetos,
Beneficios del Enfoque OO
Disminución del bache semántico entre análisis y diseño proveyendo una representación consistente en todo el ciclo de
vida
Enfoque OOLa transición del análisis al diseño es un refinamiento
Enfoque EstructuradoEn la transición del análisis al diseño
pasamos del DFD al DE mediante un proceso heurístico no trivial
Sugerencias• Cuando realice el análisis ponga énfasis en la investigación del problema y los requisitos
• Cuando realice el diseño ponga énfasis en una solución conceptual del problema
• En la etapa de análisis se realiza el Modelo del dominio (representación visual de las clases conceptuales del mundo real)
• Realice una tarjeta CRC para comenzar a entender la clase propuesta (esta será refinada posteriormente en la etapa de diseño)
• Si bien son conceptos vinculados, tenga presente la diferencia entre mensaje, operación y método
• Recuerde que la composición y la agregación son tipos particulares de asociaciones
• Tenga en cuenta que la generalización es un concepto que permite organizar estructuralmente las abstracciones y la herencia es una técnica de los lenguajes de programación que permite implementarla
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 1.1 si puedo definir y dar ejemplos de:
• Análisis OO / Diseño OO• Modelo de dominio de la aplicación• Abstracción / Encapsulamiento• Estado / Comportamiento / Identidad • Tarjetas CRC• Mensaje / Operación / Método • Asociación / Agregación / Composición • Generalización / Herencia / Polimorfismo
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 1, si
• Comprendo la diferencia entre el análisis y diseño Estructurado y el OO
• Entiendo la diferencia entre análisis, diseño e implementación y que es lo que realizo en cada una de estas actividades
• Vinculo la etapa de análisis con la descripción del modelo de dominio de la aplicación
• Comprendo cual es el uso de las tarjetas CRC
• Entiendo cual es el objetivo de la abstracción y el encapsulamiento
• Entiendo la diferencia entre mensajes, operaciones y método
• Comprendo la diferencia entre asociación, agregación y composición
• Entiendo la diferencia entre generalización y herencia
Análisis de Sistemas Administrativos
Unidad 3.1 Casos de Uso
Facultad de Tecnología Informática UAI
Mg. Carlos Gerardo Neil 2008
Programa de la Asignatura
1.1. Análisis y diseño OO 2.1. Proceso de desarrollo de software. 1º parte3.1. Casos de uso 3.2. Diagramas de clases. 3.3. Diagramas de comunicación. 3.4. Diagramas de secuencia. 4.1. Lenguaje de restricción de objetos. 5.1. Patrones de Diseño. 6.1. Transformación del Modelo de Clases al Modelo ER 7.1. Proceso de desarrollo de software 2º parte
Clase anterior – repaso general
• ¿Por qué usamos modelos y no directamente codificamos?
• ¿En qué etapas del proceso de desarrollo utilizo UML?
• ¿Cuál es la diferencia entre el ciclo de vida en cascada y el UP?
• ¿Cuál es la relación que existe entre disciplinas de UP y el ciclo de vida en cascada?
• ¿Qué tienen en común el ciclo de vida en espiral y el UP?
• ¿En qué que hacen énfasis cada una de las fases del UP?
• ¿En qué termina cada iteración?
Casos de Uso
Ingeniería de Requisitos
• La Ingeniería de Requisitos direcciona el proceso de elicitación, definición, modelado, análisis, especificación y validación de los requisitos de un sistema y de su software, basado en un enfoque sistemático, separando el "qué" del "cómo" del diseño.
¿Qué es un Requisito?
• Flujo de trabajo fundamental cuyo proposito esencial es orientar el desarrollo hacia el sistema correcto
• Esto se lleva a cabo mediante la descripcion de los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entre el cliente (usuario) y los desarrolladores del sistema, acerca de lo que el sistema debe hacer y lo que no
• El conjunto de todos los requisistos forman la base para el desarrollo del sistema o el componente de sistema
Tipos de Requisitos
• Funcionales: especifica una acción que debe ser capaz de realizar el sistema, sin considerar restricciones físicas
• No funcionales: especifica restricciones físicas sobre un requisito funcional (rendimiento, plataforma, fiabilidad)
Requisitos y Casos de Uso
• Los casos de uso son una técnica para la especificación de requisitos funcionales propuesta inicialmente por Jacobson (1992)
• Los casos de uso presentan una ventaja sobre la descripción textual de los requisitos funcionales
• Los casos de uso son, ante todo, requisitos funcionales
• A pesar de ser una técnica ampliamente aceptada, existen múltiples propuestas para su realización
¿Qué es un caso de uso?
• Los casos de uso son una técnica que se utiliza para documentar los requerimientos funcionales de un sistema desde el punto de vista de los usuarios
• Los casos de uso responden a la pregunta: ¿Qué se supone que el sistema debe hacer para los usuarios?
• Un caso de uso es un texto muy simple con cierto formato que describe cómo se debería comportar un sistema ante la interacción con uno o más usuarios
Los casos de uso no son “orientados a objetos”
Ventajas de los casos de uso
• Los casos de uso sirven como una forma de comunicación entre personas de uno o varios equipos de trabajo, estimulando la discusión acerca del comportamiento del sistema en cuestión
• Los casos de uso sirven, por su simpleza, para validar los requerimientos directamente con los (futuros) usuarios del sistema
Diagrama de Casos de Uso
actor 2
actor 1
caso de uso 2
caso de uso 1
<<extend>>
caso de uso 3
caso de uso 4
<<include>>
El valor de los casos de uso está en su descripción detallada (no en el dibujo…)
Casos de Uso
Describe tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él
Están acotados al uso de una determinada funcionalidad, claramente diferenciada, del sistema
Un caso de uso realiza cierto trabajo cuyo efecto es tangible para un actor
Actorcaso de uso
Casos de Uso - actores
Un actor es alguien o algo que interactúa con el sistema (una persona, una organización, un programa o sistema de hardware o software)
Un actor estimula al sistema con algún evento o recibe información del sistema
Un actor es externo al sistema
Un actor cumple un rol definido (Ej.: Cliente, Banco, empleado)
Diagrama de Contexto
Permite determinar las fronteras del sistema
CVLI
Cliente
Administrador Sistema
<< actor>>
TARJETA DECREDITO
<< actor>>
GESTORDE ENVIO
<< actor>>
GESTORDE LIBROS
0..*
0..1
0..1
0..1
0..1
secundario
secundario
secundario
Tipo de Actores
Actores primarios: utilizan las funciones principales del sistema
Actores secundarios: efectúan tareas administrativas o de mantenimiento
CVLI
Cliente
Administrador Sistema
<< actor>>
TARJETA DECREDITO
<< actor>>
GESTORDE ENVIO
<< actor>>
GESTORDE LIBROS
0..*
0..1
0..1
0..1
0..1
secundario
secundario
secundario
¿Cómo encontrar actores?
• ¿Quién usa el sistema?• ¿Quién instala o mantiene al sistema?• ¿Qué otros sistemas utilizan al sistema?• ¿Quién recibe información del sistema?• ¿Quién le provee información al sistema?
Una buena técnica para encontrar posibles actores es responder las siguientes preguntas:
Caso de uso y Escenarios
Un caso de uso no trivial describe un conjunto de secuencias, no una única secuencia. Es conveniente separar el flujo principal
de los flujos alternativos
Por ejemplo: el caso de uso Contratar Empleado podría tener variantes: contratar externos (Escenario más frecuente) , traslado dentro de la misma empresa, contratar extranjeros. Cada una de estas variantes se puede expresar en una secuencia diferente
Cada secuencia específica del caso de uso se denomina Escenario
Un escenario es una secuencia específica de acciones entre los actores y el sistema (es una instancia de un caso de uso)
Caso de Uso y Colaboraciones Un caso de uso captura el comportamiento esperado del sistema sin tener que
especificar cómo se implementará
Es importante separar el análisis (que especifica un comportamiento) de la implementación (que especifica cómo se lleva a cabo ese comportamiento)
De todas maneras, un caso de uso deberá implantarse y esto lo hará mediante una sociedad de clases (incluyendo su estructura estática y dinámica) que se modela como una colaboración
Una realización especifica un contrato entre el caso de uso y su colaboración
Caso de uso
Colaboración
hacer pedido
gestion de Pedidos
Realización
Caso de Uso - asociación
Muestra la relación entre los actores y los casos de uso
Los actores sólo se pueden conectar a los casos de uso a través de asociaciones que indican que el actor y el caso de uso se comunican entre sí y que pueden enviar y recibir mensajes
• El actor inicia la comunicación
• El actor recibe la comunicación del caso de uso
Relación <<include>>
Una relación de inclusión entre casos de uso especifica que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso en el lugar establecido en el caso de uso base
Una relación de inclusión se representa como una dependencia
Una dependencia es una relación de uso que declara que un caso de uso utiliza información y servicios de otro
Caso de Uso A Caso de Uso B
<<include>>
El caso de uso A incluye en su funcionalidad el caso uso B
¿Cuándo se utiliza include?
Cuando un caso de uso incorpora explicitamente el comportamiento de otro caso de uso
Para evitar repeticiones de descripción de flujos de eventos
Cuando distintos casos de uso poseen un conjunto de eventos con la misma funcionalidad, estos eventos se pueden factorizar en un nuevo caso de uso, el cual se relacionará con los anteriores mediante la relación de inclusión
Cuando un caso de uso es muy extenso y difícil de leer
Se entiende que algunos de los pasos en una situación dentro de un Caso de Uso son los mismos que los de otro Caso de Uso, y en lugar de listar
los mismos pasos, tan sólo indicamos el Caso de Uso de donde provienen
Relación <<extend>>Una relación de extensión entre casos de uso especifica que un caso de
uso base incorpora implícitamente el comportamiento de otro caso de uso en el lugar especificado por el caso de uso base que extiende. Se representa mediante una dependencia
La funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en algunas oportunidades
La excepción consiste en interrumpir el caso de uso B y pasar a ejecutar otro caso de uso A
Caso de Uso ACaso de Uso B
<<extend>>
El caso de uso B (caso de uso base) incluye en su funcionalidad (opcionalmente) el caso uso A
Relación <<extend>>
En la relación de extensión, existe un caso de uso base el cual puede se extendido por otro caso de uso
La extensión se realiza a partir de los puntos de extensión y éste caso de uso es utilizado en esos puntos si se cumple una condición
El caso de uso base no necesita nombrar al o a los casos de uso que lo extienden
El caso de uso que extiende, nombra al caso de uso base, nombra al o a los puntos de extensión e incluye la condición que determina si se toma o no la extensión.
Se entiende que se agregan pasos a un Caso de Uso existente, y esto se hace creando un nuevo Caso de Uso, que enriquece al existente, pero no lo
modifica.
¿Cuándo se utiliza extend?
Se puede utilizar para:
Cuando se desea describir una variación del comportamiento normal de un caso de uso.
Para conjuntos de eventos que son ejecutados solamente en ciertos casos.
Cuando la sección de flujos alternativos de un caso de uso se torna muy grande y difícil de leer, es conveniente crear nuevos casos de usos a partir de estos flujos alternativos que extiendan al caso de uso original.
Ejemplo/1
Pago con Vale Regalo
Procesar Venta
<<extend>>
Caso de uso base
caso de uso que extiende
El caso de uso base no necesita nombrar a el o a los casos de uso que lo extienden
El caso de uso que extiende, nombra al caso de uso base, nombra a el o a los puntos de extensión e incluye la condición que determina si se toma o no la extensión.
Ejemplo/2
Caso de uso PROCESAR VENTAPunto de extensión: pago, paso 7Escenario principal
1. el cliente llega al puesto de venta con mercaderías para comprar….….7. El cliente paga y gestiona el pago
Caso de uso PAGO CON VALE REGALO
Condición: el cliente quiere pagar con vale regaloPuntos de extensión: pago en PROCESAR VENTAEscenario principal
1. el cliente le da el vale regalo al cajero2. …
Caso de uso base
Caso de Uso que extiende
condición
Puntos de extensión
Pre y Post Condiciones
Pre condiciones: establece lo que siempre debe cumplirse antes de comenzar un caso de uso. No se prueban en el caso de uso, se asumen que son verdaderas
Post condiciones: establece qué debe cumplirse cuando el caso de uso se completa con éxito
Plantilla básico para descripción de CdeU
• Nombre de caso de uso• Resumen• Actores• Fecha de creación: • Fecha de actualización:• Versión• Pre condición• [Punto de extensión] (si fuera necesario)• [Condición] (si fuera necesario)
• Escenario principal• Flujo alternativo• Post condición
Los Casos de uso y las fases en el UP
• En la fase de inicio se reconocen las mayoría de los casos de uso, pero no su descripción detallada
• En la fase de elaboración, se refinan en las sucesivas iteraciones
• En la fase de construcción, se escriben casos de uso menores
• En la fase de transición, no se describen casos de uso
El Proceso UnificadoIterativo e incremental
Iter
#n
------------Iter#2
prueba
Iter#n-1
------Iter#1
Implementación
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboracióninicioFases
disciplinas
un ejemplo...
Consultar libros en general
Consultar novedades Consultar ofertas
Cliente
Consultar libro
<<extend>><<extend>>
<<extend>>
un ejemplo...
Consultar libros en general
Consultar novedades Consultar ofertas
comprar libro
Cliente
buscar libros
Consultar libro
<<extend>>
<<extend>><<extend>>
<<include>><<include>>
Comenzamos con el caso práctico...
Compañía de Ventas de Libros por Internet (CVLI) (Descripción sintética del Sistema)
• El cliente accede a la información sobre los libros a través de la Web• El cliente elegirá un nombre de usuario y una clave como método de
autentificación para efectuar las transacciones• El cliente podrá realizar búsquedas por autor, título o ISBN• El cliente debe estar previamente registrado• El cliente puede establecer preferencias de envío• El cliente puede introducir opciones de empaquetado• La librería deberá recoger los datos de los pedidos• La librería deberá rearmar en uno único los pedidos aislados que estén
dentro del plazo de 90 minutos• La empresa puede realizar envíos parciales en función de la disponibilidad
de los ítems
Identificación de los actores
• Cliente (primario)
• Administrador del sistema (primario)
• Tarjeta de crédito (secundario)
• Gestor de libros (secundario)
• Gestor de envío (secundario)
Diagrama de Contexto
Permite determinar las fronteras del sistema
CVLI
Cliente
Administrador Sistema
<< actor>>
TARJETA DECREDITO
<< actor>>
GESTORDE ENVIO
<< actor>>
GESTORDE LIBROS
0..*
0..1
0..1
0..1
0..1
secundario
secundario
secundario
Identificación de los Casos de Uso
ClienteRegistrarse al sistemaConsultar libroComprar libroEstablecer preferencias de envío y empaquetado Administrador del sistemaArmar pedidosRearmar pedidos
Diagrama de Casos de Uso
Armar pedidos
Rearmar pedidos Administrador del Sistema
Establecer preferencias de envío y empaquetado
Consultar libro
Cliente
Gestor de Libros
Comprar libro
Registrarse al sistema
Tarjeta de Credito
Descripción de los Casos de Uso
Nombre de caso de uso: Registrarse al sistema
Resumen: el cliente, antes de realizar una primera transacción de compra o búsqueda de libros, debe introducir todos sus datos por única vez, los cuales serán guardados por el sistema y éste le ofrecerá la posibilidad de tener una clave y contraseña que utilizará para cada transacción que realice posteriormente, el cliente tendrá la posibilidad de hacer cambios en los datos introducidos, incluso en su clave y contraseña
Actores: cliente (primario), tarjeta de crédito (secundario)
Descripción de los Casos de Uso
Titulo: Consultar libro
Resumen: el cliente, una vez ingresado al sistema, podrá navegar por el mismo en búsqueda de libros, novedades, ofertas, etc.
Actores: cliente (primario), gestor de libros (secundario)
Descripción de los Casos de Uso
Titulo: Comprar libro
Resumen: el cliente, una vez ingresado al sistema, podrá realizar compras de libros, eligiéndolo de una lista ofrecida por la empresa, cada libro elegido, se sumará a una carrito de compra, etc. El cliente informará el número y tipo de tarjeta de crédito para realizar el pago. Deberá especificar dirección de envió y forma de pago
Actores: cliente (primario), gestor de libros (secundario), tarjeta de crédito (secundario)
Refinamiento: include y extend
Establecer preferencias de envío y empaquetado
Consultar libros en general
Consultar novedades Consultar ofertas
Cliente
Gestor de Libros
Tarjeta de Credito
Consultar libro
<<extend>><<extend>>
<<extend>>
Comprar libro
<<include>>
<<extend>>
Desarrollo de un Caso de UsoNombre de caso de uso: Registrarse al sistema
Resumen: el cliente, antes de realizar una primera transacción de compra o búsqueda de libros, debe introducir todos sus datos por única vez, los cuales serán guardados por el sistema y éste le ofrecerá la posibilidad de tener una clave y contraseña que utilizará para cada transacción que realice posteriormente, el cliente tendrá la posibilidad de hacer cambios en los datos introducidos, incluso en su clave y contraseña
Actores: cliente (primario), tarjeta de crédito (secundario)
Fecha de creación: Fecha de actualización:Versión:
Pre condición: el cliente ingresa al sistema por primera vez
Escenario principal
1. El cliente ingresa a la pagina Web de CVLI2. El cliente ingresa a la opción “registración “3. El sistema solicita ingreso de los datos personales: nombre y apellidos, dirección, localidad, código postal,
país4. El cliente ingresa los datos personales5. El sistema evalúa el país de origen y solicita ingreso de los datos de la tarjeta de crédito: tipo de tarjeta,
número, fecha límite de validez6. El cliente ingresa datos de la tarjeta de crédito7. El sistema chequea el número de la tarjeta de crédito8. El sistema (teniendo en cuenta el país de origen) solicita la opción de preferencia de envío por omisión,
esta opción puede modificarse en cada envío9. El cliente ingresa preferencia de envío10. El sistema solicita, para finalizar, el ingreso de la clave de acceso y la contraseña11. El cliente ingresa clave y contraseña12. El sistema solicita reingreso de contraseña13. El cliente reingresa contraseña14. El sistema informa que la transacción se realizo correctamente
Flujo alternativo A1 Ingreso incorrecto de los números de los datosLa secuencia comienza en el punto 4 del escenario principal
5. El sistema informa que los datos ingresados son incorrectos 6. El sistema pide ingreso de números nuevamente
El escenario vuelve al punto 5 A2 Ingreso incorrecto de los números de la tarjeta de créditoLa secuencia comienza en el punto 7 del escenario principal
7. El sistema informa que los números ingresados son incorrectos 8. El sistema evalúa si la cantidad de veces que ingreso el numero de tarjeta en forma incorrecta es menor a 39. El sistema pide ingreso de números nuevamente
El escenario vuelve al punto 8 Poscondición: el cliente está registrado en el sistema
Sugerencias• Utilice la plantilla modelo de casos de uso. Ayuda a entender las partes
componentes
• Recuerde que los casos de uso son texto, el gráfico sólo nos brinda una visión general
• Piense al caso de uso como una comunicación entre el actor y el sistema (no en cómo resolverá el sistema el problema planteado)
• Los flujos alternativos pueden ser errores o excepciones (no relaciones de extensión)
• Utilice las relaciones de extensión e inclusión en una etapa posterior de refinamiento. Al principio céntrese en comprender bien el caso de uso
• Describa el flujo de eventos lo suficientemente claro para que alguien externo al sistema lo pueda entender
• Amplíe la funcionalidad del caso de uso en cada iteración del proceso de desarrollo
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 3.1 si puedo definir y dar ejemplos de:
• Requisitos funcionales y no funcionales• Escenarios • Escenario principal• Flujo alternativo• Colaboraciones• Relación de inclusión• Relación de extensión • Pre y post condiciones
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 3.1, si:
• Entiendo que lo más importante de los casos de usos es la descripción detallada de la interacción actor-sistema. No el gráfico
• Comprendo qué es un escenario y lo vinculo con las relaciones de extensión e inclusión
• Entiendo qué es una colaboración y vinculo este concepto con la realización de un caso de uso
• Entiendo qué describe una pre y una post condición
• Comprendo cuándo usar una relación de inclusión y cuándo una extensión
• Comprendo que las relaciones de extensión e inclusión corresponden a una etapa de refinamiento
• FIN
Análisis de Sistemas Administrativos
Unidad 3.2 Diagrama de Clases
Facultad de Tecnología Informática UAI
Mg. Carlos Gerardo Neil 2008
Programa de la Asignatura
1.1. Análisis y diseño OO 2.1. Proceso de desarrollo de software. 1º parte3.1. Casos de uso 3.2. Diagramas de clases. 3.3. Diagramas de colaboración. 3.4. Diagramas de secuencia. 4.1. Lenguaje de restricción de objetos. 5.1. Patrones de Diseño. 6.1. Transformación del Modelo de Clases al Modelo ER 7.1. Proceso de desarrollo de software 2º parte
Clase anterior – repaso general
• ¿Qué es un escenario y cómo lo vinculo con las relaciones de extensión e inclusión?
• ¿Qué es una colaboración y cómo vinculo este concepto con la realización de un caso de uso?
• ¿Qué describe una pre y una post condición?
• ¿Cuándo debo usar una relación de inclusión y cuándo una extensión?
• ¿Comprendo que las relaciones de extensión e inclusión corresponden a una etapa de refinamiento?
Clases
Las clases representan los bloques de construcción más importantes de cualquier sistema orientado a objetos.
Una clase es una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semántica.
Los lenguajes de programación OO soportan directamente el concepto de clase
public class Cliente
{ private String nombre;
private String apellido;
public void imprimirNombre() { };
… }
Clientenombreapellido
imprimirNombre()
Atributos y Operaciones
Un atributo es una propiedad de una clase que es compartida por todos los elementos de esa clase
Una clase puede tener cualquier número de atributos o no tener ninguno
Una operación es una abstracción de algo que se puede hacer a un objeto y que es compartido por todos los objetos de la clase
Una clase puede tener cualquier numero de operaciones o ninguna
Nombre de Clase
atributo 1atributo 2atributo n
operacion 1()operacion 2()operacion n()
Compartimiento para atributos
Compartimiento para operaciones
Compartimiento para nombre de clase
Visibilidad de Atributos y Operaciones
• Visibilidad pública (Public +): cualquier clase externa puede utilizar la característica
• Visibilidad privada (Private -): solo la propia clase puede utilizar la característica
• Visibilidad protegida (Protected #): cualquier descendiente de la clase puede utilizar la característica
• Visibilidad de paquete (package ~) solo los que estén declarados dentro del paquete pueden utilizar la característica
Nombre de Clase
atributo 1atributo 2atributo n
operacion 1()operacion 2()operacion n()
(-) visibilidad privada(#) visibilidad protegida(+) visibilidad pública(~) visibilidad paquete
Descripción de atributos y operaciones
Atributo
Visibilidad [/] nombre : tipo = valor inicial
ejemplo - temperatura : integer = 0
Operación Visibilidad nombre (lista parámetros ) : tipo de
expresión retornada
ejemplo +BuscarValor (n: integer) : integer
Calentadortemperatura : Integer = 0
BuscarValor(n : integer) : Integer
Instancias de clases: objetos
Una instancia es la manifestación concreta de una abstracción a la que se le pueden aplicar un conjunto de operaciones y posee un estado que almacena el efecto de las operaciones
: Usuario : Usuario
Usuario
Clase Usuario
Objetos Usuario
¿Cómo se grafican los objetos?:
dos puntos, nombre de la clase, subrayado
:CLASE
Clases abstractas
Son clases que no pueden ser instanciadas, se utilizan en jerarquías de generalización. Las clases abstractas tienen, al menos, una operación abstracta.
Una operación abstracta tiene que ser implementada por algún método en un nivel más bajo de abstracción
Nombre en cursiva
Triangulo
Figura
calcularSuperficie()
Cuadrado
calcularSuperficie()
Interfaz/1
Una interfaz es una colección de operaciones que especifican un servicio de una clase o un componente
Específica el comportamiento visible externamente de la clase
Una interfaz define un conjunto de especificaciones de operaciones (su signatura) pero no su implementación
La interfaz es parecida a la clase abstracta, ninguna de las dos pueden tener instancias directas, no obstante una clase abstracta puede tener operaciones concretas.
Una interfaz es como una clase abstracta donde todas las operaciones también son abstractas
Interfaz/2
La realización es una relación entre clasificadores
La realización se emplea para especificar la relación que existe entre una interfaz y la clase que proporciona la operación
Permite “simular” herencia múltiple
Defino la operación imprimir para muchas clases
Cada clase la implementa como corresponde
MatrizCuadrada
imprimir()
Imprimible
imprimir()
<<Interface>>
Vector
imprimir()
Matriz
Realización
Relaciones/1
• Las clases no se encuentran aisladas, existen tres tipos principales de relaciones:
– Dependencias: relaciones de uso entre clases– Asociaciones: relaciones estructurales entre clases – Generalizaciones: conectan clases generales con sus
especializaciones
Ventana
abrir()cerrar()mover()dibujar()
VentanaDeConsola
Evento
VentanaDE Dialogo Control
dependencia
generalizaciónasociación
Relaciones/2
Asociación Agregación
Composición
Generalización
Dependencia
Realización
Dependencias
• Una dependencia es un relación de uso que declara que un elemento utiliza información de otro elemento
• En general se utilizan el contexto de las clases para indicar que una clase utiliza las operaciones de otra o utiliza variables o parámetros cuyo tipo viene dado por la otra clase
• En los diagramas de clase, se utilizan para describir la visibilidad entre clases que no es de tipo atributo
la operacion reproducirEn utiliza un parametro del tipo Canal
PeliculaDeVideonombre
reproducirEn(c : Canal)iniciar()parar()
Canal
Asociaciones
• Una asociación es una relación estructural que específica que los objetos de una clase están conectados con objetos de otra (que puede ser la misma)
• Son relaciones entre clases que indica alguna conexión significativa que deseamos preservar durante algún tiempo
EmpresaPersona
*1..* *
patron
1..*
empleado
trabaja Para >1..*
1
dirige A >
jefe
operario1..*
1
Asociación binaria
Asociación unaria
Nombre de rol
multiplicidad
Asociaciones – nombre de rolNombre de rol: cada objeto juega un rol específico en la asociación
por ejemplo, en la asociación binaria trabaja Para, un objeto Persona, juega el rol de empleado
En la asociación unaria dirige A, un objeto Persona puede jugar el rol de operario o de jefe
EmpresaPersona
*1..* *
patron
1..*
empleado
trabaja Para >1..*
1
1..* operario
1
jefe
dirige A >
Asociaciones – multiplicidad de rol/1
Multiplicidad: define cuántas instancias de una clase A pueden asociarse con una instancia de una clase B
Representa un rango de enteros que especifican el tamaño posible del conjunto de objetos relacionados (v gr.: 0..1; 1..1; 0..*; 1..*)
El valor de la multiplicidad indica cuántas instancias se pueden asociar con otras en un momento concreto
una tienda puede tener uno o muchos artículos
Un artículo se vende en una tienda
Tienda Articulo
1..*11 1..*
Asociaciones – multiplicidad de rol/2
A
A
A
A
A
A
B
B
B
B
B
B
1
0..1
0..*
1..*
3
0..1,3..5,7..9
A B3..6
Exactamente Uno:
Cero o Uno:
Cero o Muchos:
Uno o Más:
Número Exacto:
Lista:
Rango:
Asociaciones - Agregación
• Este tipo especial de asociación modela una relación TODO/PARTE
• Es un tipo de asociación más fuerte
• Es una relación no simétrica entre clases donde uno de los extremos cumple un rol dominante
Computadora
Impresora
0..1
0..*0..*
Todo
Parte
Asociaciones - Composición• La composición es una forma de agregación con una fuerte relación de pertenencia y
vidas coincidentes de la parte con el todo
• Dependencia existencial. El elemento dependiente desaparece al destruirse el que lo contiene
• Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene
• Los objetos contenidos no son compartidos
Computadora
CPU Monitor Teclado1 1
1
Clase Asociación
Una asociación puede representarse por medio de una clase que permite añadir, por ejemplo, atributos y operaciones
empresa empleado1..*
1..*
cargo
nombresueldo
empleador
empleado1..*
1..*
Por ejemplo, debido a la multiplicidad, el nombre del cargo y el sueldo no pueden pertenecer a la empresa o al empleado; son atributos de la asociación
Instancia de Asociación: enlace
empleado empresa
11..*trabaja para
empleadorempleado
1..* 1
emp1 : empleado
emp2 : empleado
em : empresa
emp3 : empleado
asociación
enlace
(emp3, em)
(emp1, em)
(emp2, em)
cada instancia de una asociación (enlace) es una tupla de referencias a objetos
Asociaciones – navegación
La navegación indica que en una asociación es posible navegar de los objetos de un tipo a los de otro. Esto es debido a que el objeto inicial almacena alguna referencia del objeto navegable
La navegación es el enunciado del conocimiento de una clase respecto a otra
Usuario Clave
*11 *
Dirección de navegación
Asociaciones – visibilidad de rol
Dada una asociación entre clases, los objetos de una clase pueden ver y navegar hasta los objetos de otra a menos que se restringa específicamente
La visibilidad privada indica que los objetos de ese extremo no son accesibles a ningún objeto externo a la asociación
por ejemplo, un objeto Clave es accesible a un objeto Usuario pero no a un objeto GrupoUsuarios
GrupoUsuarios Usuario** Clave*1
+usuario +propietario -clave
* * 1 *
Generalización
Rectangulo
dibujar()mover()
Circulo
dibujar()mover()
Triangulo
dibujar()mover()
Figura
color
dibujar()mover()
superclase
subclases
La generalización es una relación entre un elemento general (llamado superclase o padre ) y un tipo más específico de ese elemento (llamado subclase o hijo)
El hijo puede añadir nueva estructura y comportamiento o modificar el comportamiento del padre
La generalización consiste en factorizar los elementos comunes de un conjunto de clases en una clase más general llamada superclase
Paquetes/1• Un paquete es un mecanismo de propósito general para organizar el modelo de
manera jerárquica
• Ayudan a organizar los elementos de modelado con el fin de comprenderlos. Los paquetes pueden tener dentro otros paquetes
• Los paquetes tienen un nombre que los identifica, el nombre puede ser simple o calificado (cuando le precede el nombre del paquete donde se encuentra)
Cliente Departamento::Cliente
Paquetes/2
¿Cuáles son las ventajas de utilizar Paquetes?
– Evitar conflictos de nombres.
– Facilitar el reconocimiento y búsqueda de elementos de acuerdo a una funcionalidad específica.
– Controlar el acceso a sus contenidos.
– Todos los mecanismos de extensibilidad de UML se aplican a los paquetes.
ejemplo
Prestamo
fechaduracion
ObraNoInterpretada
Socio
nombreapellidodireccion
prestar()
Ubicacion
estanteriaestantetramo
Interprete
ObraInterpretada
1..*
1..*
1..*
1..*
Autor
nombreapellidofechaNacimiento
Ejemplar
numero
colocar()
1..*
1..*
1..*
1..*
1
1
1
1
Soporte
obra
titulo
1..*
1..*
1..*
1..*
1..*1 1..*1
1..*
1..*
1..*
1..*
Libro Video
estaEditadoEn
registradoEn
prestadoA
situadoEnescritaPor
interpretadaPor
Sugerencias
En la descripción de las clases del dominio del problema
– Identificar las clases y sus asociaciones más importantes– Incluir los atributos más importantes– No preocuparse inicialmente por las operaciones (corresponde a la etapa
de diseño)– No pensar en jerarquías (al principio...)
En una etapa de refinamiento (ver proceso de desarrollo) incluir
– Relaciones de jerarquía Clase/subclase– Agregaciones y composiciones– Patrones de diseño Larman– Patrones de diseño Gamma (opcional)– Restricciones OCL (opcional)
Auto evaluación/1Comprendí los conceptos más importantes de la unidad 3.2. si puedo
definir y dar ejemplos de:
• Clase
• Clase abstracta
• Interfaz
• Operación y atributos de clases
• Dependencias
• nombre de rol y multiplicidad
• Asociación / agregación / composición
• Generalización
• Paquetes
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 3.2, si
• Entiendo las diferencias entre clase, clase abstracta e interfaz
• Comprendo cuál es el objetivo de establecer una visibilidad determinada en atributos y operaciones y lo relaciono con el concepto de encapsulamiento
• Entiendo la diferencia conceptual entre agregación y composición y que ambas son tipos especiales de asociaciones
• Comprendo que el concepto de objeto y enlace son análogos
• Comprendo cómo y para qué utilizo las clases abstractas en las relaciones de generalización
• Entiendo cómo una clase hijo puede ampliar y/o modificar el comportamiento establecido en la clase padre
• Comprendo cómo usar los paquetes para organizar los elementos de modelado
Implementación básicas de las abstracciones
Clases, clases abstractas, generalización
public abstract class A{
// definición de atributos
private tipo A;
// definición de operaciones
public void b1() {}
}
public class B extends A{
// definición de atributos
private tipo b;
// definición de operaciones
public void b1() {}
}
Bb
b1()
Aa
a1()
Interfaz
public interface A{
// definición de operaciones
void operación();
}
public class B implements A{
// definición de atributos
private tipo b;
// definición e implementación
// de operaciones
public void operacion() {}
}
A
operacion()
<<Interface>>
Bb
operacion()
Asociación 1..1
public class A{
// definición de atributos
private tipo a;
// referencia a B mediante un atributo
// del tipo B
private B rol-b;
}
Aa
Bb
11
-rol-b
11
public class B{
// definición de atributos
private tipo b;
}
Asociación 1 a muchos
Aa
Bb
1..*1
-rol-b
1..*1
public class A{
// definición de atributos
private tipo a;
// * opción 1 *
// referencia al conjunto de objetos B
// mediante un vector
private Vector rol-b = new Vector();
}
public class B{
// definición de atributos
private tipo b;
}
public class A{
// definición de atributos
private tipo a;
// * opción 2 *
// referencia al conjunto de objetos B
// mediante un arreglo
private B rol-b[] = new B[n];
// “n” valor a definir
}
Asociación muchos a muchos(tienen problemas de integridad a resolver mediante código)
Aa
Bb
1..*1..*1..* 1..*
public class B{
// definición de atributos
private tipo b;
// referencia al conjunto de objetos C
// mediante un arreglo
private A a[]= new A[n];
}
public class A{
// definición de atributos
private tipo b;
// referencia al conjunto de objetos C
// mediante un arreglo
private B a[] = new B[n];
}
Clase asociación (una versión) (tienen problemas de integridad a resolver mediante código)
Aa
Bb
1..*1..* 1..*1..*
Cc
public class A{
// definición de atributos
private tipo a;
// referencia al conjunto de objetos C
// mediante un arreglo
private C c[] = new C[n];
}
public class B{
// definición de atributos
private tipo b;
// referencia al conjunto de objetos C
// mediante un arreglo
private C c[]= new C[n];
}
public class C{
// definición de atributos
private tipo c;
// referencia al objeto C
// mediante atributos
private B b;
private A a;
}
Aa
Bb
Cc
1..*1 1..* 11..* 1..*1 1
FIN
Análisis de Sistemas Administrativos
Unidad 3.3 - 3.4 Diagrama de Secuencia y Comunicación
Facultad de Tecnología Informática UAI
Mg. Carlos Gerardo Neil 2008
Programa de la Asignatura
1.1. Análisis y diseño OO 2.1. Proceso de desarrollo de software. 1º parte3.1. Casos de uso 3.2. Diagramas de clases. 3.3. Diagramas de comunicación. 3.4. Diagramas de secuencia. 4.1. Lenguaje de restricción de objetos. 5.1. Patrones de Diseño. 6.1. Transformación del Modelo de Clases al Modelo ER 7.1. Proceso de desarrollo de software 2º parte
Clase anterior – repaso general
• ¿Cuáles son las diferencias entre clase, clase abstracta e interfaz?
• ¿Cuál es el objetivo de establecer una visibilidad determinada en atributos y operaciones y lo relaciono con el concepto de encapsulamiento?
• ¿Cuál es la diferencia conceptual entre agregación y composición y que ambas son tipos especiales de asociaciones?
• ¿Porqué el concepto de objeto y enlace son análogos ?
• ¿Cómo y para qué utilizo las clases abstractas en las relaciones de generalización ?
• ¿Cómo una clase hijo puede ampliar y/o modificar el comportamiento establecido en la clase padre?
• ¿Cómo uso los paquetes para organizar los elementos de modelado?
Diagramas de interacción
Muestran el modo en que los objetos se comunican entre sí,
enviándose mensajes
• DIAGRAMA DE COMUNICACIÓN: enfatiza la organización estructural de los objetos
• DIAGRAMA DE SECUENCIA: hace énfasis en la ordenación temporal
inst1 : ClaseA inst2 : ClaseB
1: mensaje1
2: mensaje2
inst1 : ClaseA
inst2 : ClaseB
1: mensaje1
2: mensaje2
Relación entre diagrama de clases y de interacción
clase Aclase B
metodoA()
: clase A : clase B
1: metodoA( )
: clase B : clase A1: metodoA( )
Si un objeto envía un mensaje a otro objeto, quiere decir que sus clases respectivas están relacionadas en el diagrama de clases (asociación o dependencia) y debe haber visibilidad de una hacia la otra
Diagrama de clases
Diagrama de secuencia
Diagrama de Comunicación
Notación general
Empleado : Empleado
clase Instancia nombrada
instancia
Retorno:= mensaje(parametro:tipoParametro):tipoRetorno
valor:= pago(cantidad:integer):integer
Sintaxis de mensaje
Ejemplo
e1 : Empleado
Diagrama de Secuencia
Diagrama de Secuencia/1
Definición: Un diagrama de secuencia destaca la ordenación temporal de los
mensajes.
Sintaxis:
[Número de secuencia] [condición] * [expresión iteración] [valor de retorno :=] nombre del mensaje (parámetros)
Diagrama de Secuencia/2 • Muestran interacciones entre objetos según un punto de vista temporal.
• Representa una interacción entre objetos poniendo énfasis en la cronología de los envíos de mensajes
objeto
mensaje
emisor
destinatarioPeriodo de actividad
Envió sincrónico (Emisor bloqueado)
Mensaje al mismo objeto
Iteración
v: Vendedor :LíneaProducto *[1..8] verificarLínea()
Sintaxis:
* [expresión-iteración ] mensaje
Creación de objetos
: Registro : Venta
: Pago
1: realizarPago( )
2: create( )
Mensaje de creación de objetos
Ejemplo de diagrama de secuencia
• Los diagramas de secuencia de sistema se utilizan en la etapa de análisis para documentar casos de uso
• El actor genera eventos sobre el sistema, normalmente solicitando alguna operación como respuesta
• Deberíamos hacer un DSS por cada escenario…
Diagrama de Secuencia de Sistema (DSS)
Actor del Caso de uso
Sistema representado como un sólo objeto(caja negra)
Identifico mensajes hacia el sistema en el caso de uso
Diagrama de Secuencia del Sistema
• Muestra, para un escenario específico de un caso de uso, los eventos que generan los actores externos
• Los sistemas se tratan como cajas negras
• Muestran los mensajes que podrían ser traducidos a operaciones dentro del sistema
(y serán distribuidos, en la etapa de diseño, a los objetos del sistema)
Ejemplo de DSS
A los mensajes los extraemos del caso de uso
Los mensajes los nombramos independientemente de la implementación
Se puede mostrar, opcionalmente, la respuesta del sistema
Seguimos con el ejemplo
• El sistema (si estuviera compuesto por una sóla clase) podría tener, por ahora, las siguientes operaciones ...
SISTEMA
ingresarSistema()ingresarDatosPersonales()ingresarTarjetaCredito()ingresarPreferenciasEnvio()ingresarClaveContraseña()
Operaciones que serán asignados a las clases en la etapa de diseño
•Esto nos brinda una primera aproximación de las posibles operaciones, no implica necesariamente que serán ellas las operaciones del sistema (estamos en una epata inicial...)
Resumiendo…
SISTEMA
ingresarSistema()ingresarDatosPersonales()ingresarTarjetaCredito()ingresarPreferenciasEnvio()ingresarClaveContraseña()
: SISTEMA
: cliente ingresarSistema()
ingresarDatosPersonales()
ingresarTarjetaCredito()
ingresarPreferenciasEnvio()
ingresarClaveContraseña()
DSS "Registrarse al sistema"
Los operaciones de la “clase sistema”, deberán estar distribuidas entre todas las clases del sistema con los criterios que nos darán los patrones de asignación de responsabilidades
tiene
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Cliente
nombreapellidodireccionteprof esion
0..*
1
0..*
1
tiene
Autor
nombreapellido
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
1..*
1
1..*
1
tiene
Items
cantidad
1..*
1
1..*
1
1
0..*
1
0..* pertenecen
Diagramas de Comunicación
Diagramas de Comunicación/1
Definición:
Un Diagrama de Comunicación destaca la organización estructural de los objetos participantes y el envío de mensajes.
Sintaxis:Número de secuencia [condición] *[expresión iteración]: [valor de retorno :=]
nombre del mensaje ([parámetros])
Diagramas de Comunicación/2• Muestra las interacciones organizadas en torno a los objetos y los enlaces entre
ellos
• Lo utilizamos en la fase de diseño para asignar responsabilidades a las clases (definir dónde ubicar las operaciones)
Enlaces
• Un enlace es una conexión entre objetos, indica que es posible alguna forma de navegación o visibilidad entre los objetos
• Un enlace es una instancia de una asociación
inst1 : ClaseA
inst2 : ClaseB
1: mensaje1
2: mensaje2
enlace
Representación de los Mensajes
Representación de los Mensajes
Iteración sobre una colección
: Venta : LineaDeVenta1: *st:=getSubtotal
Envió de mensajes a cada objeto de
la colección
Iteración
Sintaxis:
* [expresión-iteración ] mensaje
Ejemplo:
v:Vendedor :LíneaProducto1 *[1..8]: verificarLínea()
Ejemplo de Diagrama de Comunicación
Sugerencias
• Recuerde que para que un objeto se pueda comunicar con otro deben tener algún tipo de relación (asociación o dependencia) entre ellos
• El diagrama de secuencia de sistema (DSS) lo utilizamos en la etapa de análisis, conjuntamente con los casos de uso, para la identificación de los mensajes
• Los diagramas de Comunicación lo utilizamos en la etapa de diseño, conjuntamente con los patrones para asignación de responsabilidades, para la distribución de operaciones en las clases
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 3.3 – 3.4 si puedo definir y dar ejemplos de:
• Diagrama de comunicación
• Diagrama de secuencia
• Enlace
• Menaje
• Itera ración
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 3.3, 3.4, si
• Entiendo que el diagrama de comunicación muestra lo mismo que el diagrama de secuencia
• Comprendo qué enfatiza el diagrama de secuencia y qué el de colaboración
• Comprendo el concepto de “caja negra” en los diagrama de secuencia de sistema
• Comprendo la diferencia entre un diagrama de secuencia (UML) y un diagrama de secuencia de sistema
• Entiendo la diferencia entre enlace y asociación y cómo se visualiza el enlace en los diagramas de iteración
• Comprendo cómo se visualiza la secuencia de mensajes en cada uno de los diagramas
• Entiendo que debo hacer un diagrama de secuencia de sistema por cada escenario del caso de uso
• FIN
Análisis de Sistemas Administrativos
Unidad 4.1 OCL
Facultad de Tecnología Informática UAI
Mg. Carlos Gerardo Neil 2008
Programa de la Asignatura
1.1. Análisis y diseño OO
2.1. Proceso de desarrollo de software. 1º parte
3.1. Casos de uso
3.2. Diagramas de clases.
3.3. Diagramas de comunicación.
3.4. Diagramas de secuencia.
4.1. Lenguaje de restricción de objetos.
5.1. Patrones de Diseño.
6.1. Transformación del Modelo de Clases al Modelo ER
7.1. Proceso de desarrollo de software 2º parte
Clase anterior – repaso general
• ¿Qué muestran el diagrama de comunicación y el diagrama de secuencia?
• ¿Qué enfatiza el diagrama de secuencia y qué el de colaboración ?
• ¿Cuál es el concepto que se quiere representar con la “caja negra” en los diagrama de secuencia de sistema?
• ¿Cuál es la diferencia entre un diagrama de secuencia (UML) y un diagrama de secuencia de sistema?
• ¿Cuál es la diferencia entre enlace y asociación y cómo se visualiza el enlace en los diagramas de iteración?
• ¿Cómo se visualiza la secuencia de mensajes en cada uno de los diagramas?
• ¿Debo hacer un diagrama de secuencia de sistema por cada escenario del caso de uso o solamente para el flujo principal?
Bibliografía usada para el curso
The Object Constraint Languaje Second EditionGetting Your Models Ready for MDA
Jos WarmerAnneke Kleppe
Object Constraint Language Versión 2.0
http://www.omg.org/
OCL
¿Por qué utilizar OCL?
• Un modelo es un conjunto consistente y coherente de elementos de la realidad que tienen características y restricciones
• Un modelo gráfico como UML no es suficiente para una especificación no ambigua
• Existe la necesidad de establecer restricciones adicionales sobre el modelo
• Muchas veces las restricciones se escriben en lenguaje natural
¿Qué problemas surgen con este tipo de especificaciones?
¿Por qué utilizar OCL?
• Una solución: LENGUAJES FORMALES
– Problemas: necesidad de usuarios con una fuerte formación matemática
• Una alternativa: OCL
– Lenguaje de características formales
– Fácil de leer
– Fácil de escribir
Características generales de OCL
• OCL es un lenguaje declarativo: establece qué debe ser hecho pero no cómo debe ser hecho
• El estado del sistema no cambiará como consecuencia de una expresión OCL
• Cuando una expresión OCL es evaluada, simplemente devuelve un valor
• OCL es un lenguaje tipado, por lo tanto cada expresión OCL tiene un tipo, por consiguiente todos los tipos deben concordar (no es posible comparar enteros con literales)
¿Qué no es OCL?
• NO es un lenguaje de programación
• NO es posible escribir lógica de programación
• NO es posible invocar operaciones que no sean una consulta
• NO considera aspectos de implementación
¿Para que sirve OCL?
Sirve para:
• Especificar reglas de negocio
• Definir la semántica de UML
• Especificar PIM para MDA
• Especificar modelos precisos y completos a partir de la construcción de modelos UML/OCL combinados
Un ejemploUn ejemplo
<<Invariant>>
self.pasajeros->size() <= self.avion.tipoavion.cant_de_asientos
Restricción: la cantidad de pasajeros de un vuelo debe ser menor o igual a la cantidad de asientos del tipo de avión que realiza el vuelo
Tipo_Avióntipo : Stringserie : Stringcant_de_asientos : Integercant_de_tripulantes : Integer
Avionid_avion : Integer
1
1..* +tipo
1
1..*
Pasajerosid_pasajero : Integerpasaporte : String
Vueloid_vuelo : Integerorigen : Stringdestino : String
1
1..*
+avion
1
1..*
1..*
*
+pasajeros
1..*
1..*
*
+tripulantes
1..*
*
*
Tipo contextual e instancia contextualTipo contextual e instancia contextual
El tipo contextual de una expresión OCL se corresponde con la entidad del modelo para la cual se define la expresión OCL.
Utilizaremos un término de UML estandard, denominado Clasificador (classifier) para indicar con él que nos referimos a una clase, una interfaz, un tipo de dato o un componente.
El tipo contextual de una expresión OCL, se escribe luego de la palabra reservada context.
Una expresión OCL se evalúa para un único objeto, el cual es siempre una instancia del tipo contextual (instancia contextual).
A veces es necesario referirnos explícitamente a la instancia contextual, por ello utilizamos la palabra self
Contexto de una expresiónContexto de una expresión
Las expresiones se pueden mostrar en un diagrama UML o no
El vínculo entre una entidad en un diagrama UML y una expresión OCL se denomina definición de contexto de una expresión OCL
<<Invariant>>
edad > 18PersonaPersona
nombre: Stringnombre: String
edad: Integeredad: Integer
........
context Persona
inv: edad > 18
Contexto y tipo de expresiónContexto y tipo de expresión
context Persona
inv: self.edad > 18
PersonaPersona
nombre: Stringnombre: String
edad: Integeredad: Integer
........
Instancia Instancia contextualcontextual
Tipo contextualTipo contextual
etiquetaetiqueta
Accediendo a propiedades de objetos
propiedades• Una propiedad es:
• Un atributo
• Un extremo de asociación
• Una operación/método libre de efectos laterales
Una operación o método se define como libre de efectos laterales si no modifica el estado del sistema
• Notación “Punto”: El valor de una propiedad en un objeto se especifica en una expresión OCL con un punto seguido del nombre de la propiedad
self.mEdad >= 17
self.obtenerprecio()
Propiedad: Atributo
Por ejemplo, la siguiente expresión OCL: “la edad de cliente es mayor o igual a 17 años”:
context Cliente
inv: self.mEdad >= 17
El valor de la subexpresión self.mEdad es el valor de mEdad en la instancia particular de Cliente identificada por self.
El tipo de la subexpresión self.mEdad es el tipo del atributo mEdad, que es un tipo Integer estándar.
ClientemNombre: StringmApellidos: StringmEdad: Integerlim_max_mov:Integer
Propiedad: Operaciones
Para referirnos a una operación, también se utiliza la notación punto
Por ejemplo:
context Producto
Inv: self.obtenerprecio() > 0
Producto
obtenerprecio()
Operaciones de coleccionesOCL define muchas operaciones en tipos de colección. Estas operaciones permiten contar con una manera flexible y poderosa de proyectar nuevas colecciones desde colecciones existentes.
Notación flecha “->”:
colección->operaciónDeColeccion()
NavegacionesNavegaciones
Las navegaciones nos permiten hacer referencia a objetos que están asociados con la instancia contextual
Hay dos tipos de navegaciones: simples y combinadas
Huésped
nombre : Stringedad : Integersexo : {hombre, mujer}
Habitación
número_piso : Integernúmero_habitación : Integernúmero_de_camas : Integertipo : {A, B}
+huéspedes
*
NavegacionesNavegaciones
Requerimiento: la cantidad de huéspedes de una habitación no debe superar la cantidad de camas de la habitación.
context Habitación
inv: self.huespedes->size() <= self.número_de_camas
Se utiliza el nombre de rol (del extremo opuesto de una relación) que vincula la clase donde se define la expresión con otra clase del diagrama.
Huésped
nombre : Stringedad : Integersexo : {hombre, mujer}
Habitación
número_piso : Integernúmero_habitación : Integernúmero_de_camas : Integertipo : {A, B}
+huéspedes
*
NavegacionesNavegaciones
Si se omite el nombre de rol, se usa como tal el nombre de la clase
context Habitación inv: self.Huesped->size() <= self.número_de_camas
Huésped
nombre : Stringedad : Integersexo : {hombre, mujer}
Habitación
número_piso : Integernúmero_habitación : Integernúmero_de_camas : Integertipo : {A, B}
*
Propiedad: extremos finales de asociacionesA partir de un objeto específico, es posible navegar una asociación en el diagrama de clase para referirnos a otros objetos y sus propiedades.
objeto.nombredelextremoFinal
El valor de la subexpresión es un objeto o conjuntos de objetos, dependiendo de la multiplicidad del extremo final de la asociación.
context Compañia
inv: self.gerente.esDesocupado = false
inv: self.empleados->notEmpty()
En self.empleados->notEmpty() estamos accediendo a la propiedad notEmpty en el conjunto self.empleados
Persona
nombre : Stringedad : IntegeresDesocupado : Boolean
Compañia
nombre : String* +empleados*
1+gerente
1
Extremo de Asociación y Navegación
Comenzando desde un objeto en particular, podemos navegar una asociación en un diagrama de clases para referirnos a otro objeto y a sus propiedades.
El valor de esta expresión es el conjunto de objetos que están del otro lado de la asociación nombreDeRol
Para hacerlo, navegamos la asociación usando su extremo opuesto:
context Persona inv: self.empleador
Persona
esCasado : BooleanesDesocupado : Booleanedad : IntegeresFeliz : Boolean
Compañia
nombre : StringcantidadDeEmpleados : Integer
0..*
1
compañiaGerenciada
gerente
0..*
0..*
0..*
1
empleador
0..*
0..*empleado
Si la multiplicidad del extremo es *, es una colección
Context Person inv:
self.employer ... (una colección)
Si la multiplicidad del extremo es 0 ó 1, es un objeto
Context Company inv: Self.manager... (Un objeto)
Combinando propiedadesLas propiedades se pueden combinar para escribir expresiones más complejas.
Una regla importante es que una expresión OCL siempre se evalúa a un objeto específico de un tipo especifico. Luego de obtener el resultado, es posible aplicar otra propiedad para obtener un nuevo resultado.
Cada expresión OCL puede ser leída y evaluada de izquierda a derecha
context Cliente
inv: self.lim_max_mov >= self.cuentas.mMovs->size()ClientemNombre: StringmApellidos: StringmEdad: Integerlim_max_mov:Integer
MovimientomImporte: RealmConcepto: StringmFecha: Date
Cuenta/msaldo: RealmTitulares
mMovs
0..*0..*
1..* cuentas
Tipos de expresiones OCLTipos de expresiones OCL
Invariantes
Pre/post-condiciones
Valores iniciales
Valores derivados
De consulta
otros
InvariantesInvariantes
Un invariante es una condición que debe ser verdadera para todas las instancias de un tipo específico en cualquier momento.
Su tipo contextual es un clasificadorcontext Habitación
inv: self.número_de_camas <= 10
context Habitación
inv: número_de_camas <= 10
context h: Habitación
inv: h.número_de_camas <= 10
Habitación
número_piso : Integernúmero_habitación : Integernúmero_de_camas : Integertipo : {A, B}
Pre y postcondicionesPre y postcondiciones
Una precondición /postcondición es una condición que debe ser verdadera antes /después de la ejecución de una operación.
La instancia contextual self es una instancia del tipo que es dueño de la operación.
La declaración incluye la palabra context, seguida del contexto y de la declaración de la operación y el tipo.
Las etiquetas pre y post declaran si se trata de una pre/postcondición.
context Empleado::aumentarsalario( cantidad: Real ): Real
pre: salario > 0
post: self.salario = self.salario@pre + cantidad and
result = self.salario
Pre y postcondicionesPre y postcondiciones
En una postcondición, nos podemos referir a los valores de cada propiedad de un objeto en dos momentos en el tiempo:
El valor de la propiedad al comienzo de la operación o método (utilizamos el postfijo @pre)
El valor de la propiedad una vez que la operación o método se ha ejecutado.
Nota: ‘@pre’ solo se permite en expresiones del tipo postcondicion !
context Empleado::aumentarsalario( cantidad: Real ): Real
pre: salario > 0
post: self.salario = self.salario@pre + cantidad and
result = self.salario
Expresiones para valores iniciales y Expresiones para valores iniciales y derivadosderivados
Una expresión OCL puede ser utilizada para indicar el valor inicial (o derivado) de un atributo o un extremo de asociación.
La expresión debe ser conforme al tipo resultante del atributo, ó
En el caso que el contexto es un extremo final de asociación la expresión debe ser conforme con el clasificador en tal extremo final
context Persona:: salario : Integer
init: 500
context Persona:: salario : Integer
derive: 500 + (50 * antigüedad)
Persona
salario : Integerantiguedad : Integer
Navegaciones CombinadasNavegaciones Combinadas
Las navegaciones no se limitan a una única asociación. Las expresiones OCL pueden estar encadenadas navegando un conjunto de asociaciones
context Vuelo
inv: self.avion.tipo.cant_de_asientos >= self.pasajeros->size()
Tipo_Avióntipo : Stringserie : Stringcant_de_asientos : Integercant_de_tripulantes : Integer
Avionid_avion : Integer
1
1..* +tipo
1
1..*
Pasajerosid_pasajero : Integerpasaporte : String
Vueloid_vuelo : Integerorigen : Stringdestino : String
1
1..*
+avion
1
1..*
1..*
*
+pasajeros
1..*
1..*
*
+tripulantes
1..*
*
*
Navegaciones a clases de Navegaciones a clases de asociaciónasociación
Para especificar la navegación a clases de asociación, OCL utiliza un punto y el nombre de la clase de asociación
context Persona
inv: self.job ....
Persona
nombre : Stringedad : IntegeresDesocupado : Boolean
Compañia
nombre : StringnumerodeEmpleados : Integer
+empleado
0..*0..*
Jobtitulo : StringdiaComienzo : Datesalario : Integer
+empleador
0..* 0..*
Navegaciones desde clases de Navegaciones desde clases de asociaciónasociación
Es posible navegar desde la clase de asociación a los objetos que participan en la asociación.
context Job
inv: self.empleado.edad > 21
Persona
nombre : Stringedad : IntegeresDesocupado : Boolean
Compañia
nombre : StringnumerodeEmpleados : Integer
+empleado
0..*0..*
Jobtitulo : StringdiaComienzo : Datesalario : Integer
+empleador
0..* 0..*
El metamodelo de OCL
En el metamodelo de OCL se define la jerarquía de colecciones de OCL y las operaciones de colección
collection
set sequencebagorderedset
Collection
size() : Integerincludes(object : T) : Booleanexcludes(object : T) : Booleancount(object : T) : IntegerincludesAll(c2 : Collection(T) : BooleanexcludesAll(c2 : Collection(T) : BooleanisEmpty() : Boolean
ColeccionesColecciones
• El tipo Collection es un tipo abstracto, con tipos de colección concretos como sus subtipos.
– Set (Conjunto)
– OrderedSet (Conjunto ordenado)
– Bag (Bolsa)
– Sequences (Secuencias)
Navegaciones y coleccionesNavegaciones y colecciones
Los tipos de colecciones juegan un importante rol en las expresiones OCL !
– Una única navegación resulta en un conjunto (Set),
– navegaciones combinadas en un Bag,
– navegaciones sobre asociaciones adornadas con {ordered} resultan en un OrderedSet.
Tipos Básicos
Tipos BásicosTipos Básicos
• En OCL, se definen un número de tipos básicos, los cuales están disponibles para el modelador en todo momento. Estos tipos son valores predefinidos y son independientes de cualquier modelo de objetos.
• Tipos Básicos:
– Boolean: true, false
– Integer :1, -5, 2, 34, 26524, ...
– Real: 1.5, 3.14, ...
– String: ‘esto es un string‘
– Colecciones (definidas anteriormente)
• Operaciones definidas en los tipos
– Integer: *, +, -, /, abs(), etc.
– Real: *, +, -, /, etc.
– Boolean: and, or, xor, not, implies, if-then-else-endif
– String: concat(), size(), substring()
Tipos BásicosTipos Básicos
Cada expresión OCL se escribe en el contexto de un modelo UML.
En UML un clasificador (classifier) es una clase, o una interfaz, un tipo de dato.
Todos los clasificadores de un modelo UML son tipos que pueden ser utilizados en las expresiones OCL que estén asociadas a dicho modelo.
Tipos EnumeradosTipos Enumerados
Las enumeraciones son tipos de datos en UML y tienen un nombre. Una enumeración define un número de literales, que son valores posibles de la enumeración.
En OCL podemos referirnos a los valores de una enumeración.
context Persona
inv: genero = Genero::masculino
Genero
masculinofemenino
Persona
nombre : Stringedad : Integergenero : Genero
<<enumeration>>
Navegaciones que resultan en un SetLas navegaciones simples resultan en un Set
El valor de una navegacion simple es un objeto o conjuntos de objetos, dependiendo de la multiplicidad del extremo final de la asociación.
context Compañia
inv: self.gerente.esDesocupado = false
inv: self.empleados->notEmpty()
.... self.gerente->size() = 1
Persona
nombre : Stringedad : IntegeresDesocupado : Boolean
Compañia
nombre : String* +empleados*
1+gerente
1
Navegaciones que resultan en Sets o Bags
W&K: When you navigate through more than one association with multiplicity greater than 1, you end up with a bag.
OCL specification: combined navigations results in a Bag
context Medico
... self.trabaja.afiliados
Medico ObraSocial
1..*1..*
Afiliado
1..*1..*
+trabaja+asociados+afiliados+obras_sociales
1..*1..* 1..*1..*
Navegaciones que resultan en Sets o Bags
Que sucede si queremos obtener el número de potenciales pacientes de un médico, pero quisiéramos contar tantas veces a un afiliado como obras sociales éste tenga.
Medico ObraSocial
1..*1..*
Afiliado
1..*1..*
+trabaja+asociados+afiliados+obras_sociales
1..*1..* 1..*1..*
med1Obra1
obra2
af1
af2
af3Context Medico
... self.trabaja.afiliados
Navegaciones que resultan en Sets o Bags
Que sucede si queremos obtener el número de potenciales pacientes de un médico, y pero NO quisiéramos contar tantas veces a un afiliado como obras sociales éste tenga.
Medico ObraSocial
1..*1..*
Afiliado
1..*1..*
+trabaja+asociados+afiliados+obras_sociales
1..*1..* 1..*1..*
med1Obra1
obra2
af1
af2
af3Context Medico
... self.trabaja.afiliados->asSet()
Colecciones y operaciones de colección
Operaciones de coleccióncollection
set sequencebagorderedset
union=intersection-includingexcludingsymmetricDifferencecountflattenasSetasOrderedSetasSequenceasBag
appendprepend
insertAtsubOrderedSetatindexOffirstlast
union=intersection-includingexcludingcountflattenasSetasOrderedSetasSequenceasBag
appendprepend
insertAtsubSequenceatindexOffirstlastincludingexcluding
asSetasOrderedSetasSequenceasBag
count=unionflatten
Operación Size()
La operación predefinida size() nos permite obtener la cantidad de elementos de una colección.
context Cliente
inv: self.mCuentas->size() < 10
ClientemNombre: StringmApellidos: StringmEdad: IntegerSexo: Genero
Cuenta/msaldo: Real
mCuentas
mTitulares 0..*
1..*
Operación SelectPermite obtener un subconjunto específico de una colección.
select es una operación sobre una colección y es especificada utilizando la sintaxis de flecha:
collection->select( expresión booleana)
El resultado es una colección que contiene todos los elementos de la colección origen para los cuales es verdadera la expresión booleana.
Para encontrar el resultado de esta operación, se evalúa la expresión para cada elemento de la colección. Si el resultado de la evaluación es verdadero para un elemento, este se incluye en la colección resultante.
Operación Select (cont.)
El contexto de la expresión en el argumento select es el del elemento de la colección en el cual el select es invocado.
context Proyecto
inv: self.participa -> select (edad > 50) ->notEmpty()
context Proyecto
inv: self.participa-> select (e: Empleado | e.edad > 50) ->notEmpty()
context Proyecto
inv: self.participa-> select (e | e.edad > 50) ->notEmpty()
Proyectonombre : Stringpresupuesto : Integer
Empleadonombre : Stringapellido : Stringedad : IntegeresCasado : BooleandiaNacimiento : Date
**+trabaja_en
*+participa*
Operador reject
El operador reject permite obtener un subconjunto de todos los elementos de una colección para el cual la expresión se evalúa a falso.
context Proyecto
inv: self.participa -> reject ( esCasado ) ->isEmpty()
... colección de las personas que no están casadas es vacía.Proyectonombre : Stringpresupuesto : Integer
Empleadonombre : Stringapellido : Stringedad : IntegeresCasado : BooleandiaNacimiento : Date
**+trabaja_en
*+participa*
Select y rejectLa operación reject está disponible en OCL por conveniencia, debido a que cada reject se puede escribir como un select con la expresión booleana negada.
collection->reject( v | expresión-booleana-utilizando-v )collection->select( v | not (expresión-booleana-utilizando-v ) )
Operador collectEl operador collect se utiliza cuando queremos derivar una nueva colección a partir de otra, pero que contiene objetos diferentes de la colección original.
Por ejemplo: deseamos obtener una colección de las fechas de cumpleaños de los empleados de la compañía:
self.empleados->collect( fechaNacimiento )
self.empleados->collect( emp : Empleado | emp.fechaNacimiento )
Proyectonombre : Stringpresupuesto : Integer
Empleadonombre : Stringapellido : Stringedad : IntegeresCasado : BooleandiaNacimiento : Date
**+trabaja_en
*+participa*
Operación ForAllEste operador permite especificar una expresión booleana que debe ser verdadera para todos los elementos de una colección.La exp. forAll tiene como resultado un valor booleano.
context Proyecto
inv: self.participa->forAll( p: Empleado | p.edad <= 65)
Proyectonombre : Stringpresupuesto : Integer
Empleadonombre : Stringapellido : Stringedad : IntegeresCasado : BooleandiaNacimiento : Date
**+trabaja_en
*+participa*
Operación ForAllEl operador forAll tiene una variante extendida en el cual se utiliza más de un iterador. Ambos iteradores iterarán sobre la colección completa. Efectivamente esto constituye el operador forAll en el producto cartesiano de la colección.
context Proyecto
inv: self.participa-> forAll (e1, e2: Empleado |
e1<> e2 implies e1.apellido <> e2.apellido)
Proyectonombre : Stringpresupuesto : Integer
Empleadonombre : Stringapellido : Stringedad : IntegeresCasado : BooleandiaNacimiento : Date
**+trabaja_en
*+participa*
Operación ExistsMuchas veces es importante saber si al menos para un elemento de una colección se verifica una condición:
context Proyecto
inv: self.participa->exists( p | p.nombre = ‘Jack’)
ClientemNombre: StringmApellidos: StringmEdad: IntegerSexo: Genero
Cuenta/msaldo: Real
mCuentas
mTitulares 0..*
1..*
context Cuenta
inv: self.mTitulares->exists(c:Cliente| c.mEdad>=18)
Proyectonombre : Stringpresupuesto : Integer
Empleadonombre : Stringapellido : Stringedad : IntegeresCasado : BooleandiaNacimiento : Date
**+trabaja_en
*+participa*
notEmpty()En el caso de una asociación con multiplicidad 0..1 es útil verificar si existe un objeto o no cuando navegamos la asociación
context Persona
inv: self.esposa->notEmpty() implies self.esposa.genero = Genero::femenino
0..1
0..10..1+marido
0..1
+esposa Genero
masculinofemenino
Persona
nombre : Stringedad : Integergenero : Genero
<<enumeration>>
Operación count()
self-> count(object)
El número de veces que la colección (self) incluye el objeto “object”
Bag{1, 2, 3, 2, 4, 2}->count(2) = 3
Diferencia entre count() y size()
Let y expresiones <<definition>>
Expresiones LetA veces una subexpresión es utilizada más de una vez en una restricción. La expresión let nos permite definir una variable la cual puede ser utilizada en una restricción.
context Persona
inv: let sueldo : Integer = self.job.salario->sum() in
if esDesocupado then
sueldo < 100
else
sueldo >= 100
endif
Persona
nombre : Stringedad : IntegeresDesocupado : Boolean
Compañia
nombre : StringnumerodeEmpleados : Integer
+empleado
0..*0..*
Jobtitulo : StringdiaComienzo : Datesalario : Integer
+empleador
0..* 0..*
expresiones <<definition>>
context Cuenta
def: msaldo : real = self.mMovs.mImporte->sum()
context Cuenta
inv: saldo > 0
ClientemNombre: StringmApellidos: StringmEdad: IntegerSexo: Genero
Cuenta/msaldo: Real
mCuentas
mTitulares 0..*
1..*
MovimientomImporte: RealmConcepto: StringmFecha: Fecha
mMovs
0..*
0..*
Operadores Lógicos/1
• Operador not
• Operador and
(bi and b2) = (b2 and b1)
b not b
false true
True false
b1 b2 B1 and b2
false false false
false true false
true false false
true true True
Operadores Lógicos/2
• Operador or
(bi or b2) = (b2 orb1)
• Operador xor
(bi xor b2) = (b2 xorb1)
b1 b2 b1 or b2
false false false
false true true
True false true
True true true
b1 b2 b1 xor b2
false false false
false true true
True false true
true true false
Operadores Lógicos/3• Operador implies
b1 implies b2
Si b1 es true, entonces b2 debe ser true (si b1 es false, nada puede decirse de b2)
context Person inv: self.wife->notEmpty implies self.wife.age>=18 and self.husband->notEmpty implies self.husband.age>=18
• Expresión if
if b then e1 else e2 endif
b es una expresión booleana y e1 y e2 son expresiones OCL
if (count <= 100) then x/2 else 0 endif
Un ejemplo práctico
Earning
Color
silvergold
Date
now : Date
isBefore(t : Date) : BooleanisAfter(t : Date) : BooleanfromYMD(t : Date) : Dateopname2()
Burning
ProgramPartners
numOfCustomers : Integername : String
LoyaltyProgramname : String
enroll(c : Customer)getServices() : Set(Services)
1..*
1..*
LoyaltyAccount
points : Integernumber : Integer
earn(i : Integer)burn(i : Integer)isEmpty() : Boolean
ServiceLevelname : String
1
1..*
Service
condition : BooleanpointsEarned : IntegerpointsBurned : Integerdescription : StringserviceNr : Integer
calcPoints() : Integer
1
0..*
0..1
1
Transaction
points : Integerdate : Dateamount : Real
program() : LoyaltyProgram
1
0..*
1
0..*
Customername : Stringtitle : StringisMale : BooleandateOfBirth : Date/ age : Integer
age() : Integer
0..*
0..*+programs
1..*
+partners 1..*
+program 1
+levels1..*
+participants
0..*+programs0..*
Membership0..*
1
0..*
+currentLevel
1
1
CustomerCardvalid : BooleanvalidFrom : DategoodThru : Datecolor : Color/ printedName : String
0..*
1
0..*+card
+owner 1
+cards
0..*
+partners
+delivered Services 0..*
1
+level 1
+available Services
0..1
+account1
+account
+transactions 0..*
1
+card
+transactions
0..*+generatedBy
+transactions
1
0..*
Sistema que administra programas de lealtad.
• Programas de Lealtad (LoyaltyProgram): Contiene los programas de lealtad.
• Socios del Programa (ProgramPartners): Representa a las compañías que ofrece a sus clientes ser miembros de un programa de lealtad.
• Los clientes que pertenecen a un programa de lealtad pueden aprovechar los servicios que ofrece cualquier compañía participante del programa al cual pertenece el cliente.
• Todo cliente de un socio de programa puede pertenecer a un programa de lealtad completando un formulario y obteniendo una tarjeta de membresía.
• La tarjeta de membresía, representada por la clase CustomerCard, se emite a una persona. La mayoría de los programas permite a sus clientes obtener puntos.
• Cada socio de programa decide de que forma se acumulan puntos y cuantos puntos deben ser acumulados por una compra (servicios de los socios del programa).
• Los puntos pueden ser utilizados para obtener servicios específicos de uno de los socios del programa. Para que un cliente acumule puntos, toda membresía puede estar asociada con una cuenta de lealtad.
• Existen transacciones para obtener puntos y para gastar puntos.• Existen distintos niveles de servicio en cada programa de lealtad.
Ejercicios / 1
• La cantidad de puntos (points) iniciales de la cuenta (LoyaltyAccount) debe ser 0
Context LoyaltyAccount::points
init :0
• La edad de los participantes debe ser mayor a 18
Context Customer inv ofAge:
Age >= 18
Ejercicios / 2
• el programa debe ofrecer, al menos, un servicio a los clientes
Context LoyaltyProgram inv minServices:
Partners.deliveredServices -> size() >= 1
Ejercicios / 3• La cantidad de tarjetas validas por cada usuario debe ser
igual al numero de programas en el que el usuario participa
Context Customer inv sizesAgree:
programs -> size() = cards -> select(valid = true) -> size()
Ahora a trabajar…
Earning
Color
silvergold
Date
now : Date
isBefore(t : Date) : BooleanisAfter(t : Date) : BooleanfromYMD(t : Date) : Dateopname2()
Burning
ProgramPartners
numOfCustomers : Integername : String
LoyaltyProgramname : String
enroll(c : Customer)getServices() : Set(Services)
1..*
1..*
LoyaltyAccount
points : Integernumber : Integer
earn(i : Integer)burn(i : Integer)isEmpty() : Boolean
ServiceLevelname : String
1
1..*
Service
condition : BooleanpointsEarned : IntegerpointsBurned : Integerdescription : StringserviceNr : Integer
calcPoints() : Integer
1
0..*
0..1
1
Transaction
points : Integerdate : Dateamount : Real
program() : LoyaltyProgram
1
0..*
1
0..*
Customername : Stringtitle : StringisMale : BooleandateOfBirth : Date/ age : Integer
age() : Integer
0..*
0..*+programs
1..*
+partners 1..*
+program 1
+levels1..*
+participants
0..*+programs0..*
Membership0..*
1
0..*
+currentLevel
1
1
CustomerCardvalid : BooleanvalidFrom : DategoodThru : Datecolor : Color/ printedName : String
0..*
1
0..*+card
+owner 1
+cards
0..*
+partners
+delivered Services 0..*
1
+level 1
+available Services
0..1
+account1
+account
+transactions 0..*
1
+card
+transactions
0..*+generatedBy
+transactions
1
0..*
Escribir el enunciado…
context LoyaltyPrograminv minServices: partners.deliveredServices -> size() >=1
context Customerinv sizesAgree: programs ->size() =
card -> select(valid = true)->size()
context LoyaltyPrograminv: participants -> forAll (age() <= 70)
context LoyaltyPrograminv: self.participants -> forAll (c1, c2 |
c1 <> c2 implies c1.name <> c2.name)
Escribir el enunciado…
context LoyaltyProgram
inv: points>0 implies transactions->exist(t | t.points > 0)
context LoyaltyAccount
inv: transactions -> collect (points)->exist(
p : Integer | p = 500)
context LoyaltyAccount
inv: transactions.points -> exist(
p : Integer | p = 500)
• Fin
Análisis de Sistemas Administrativos
Unidad 5.1 Patrones de Diseño
Facultad de Tecnología Informática UAI
Mg. Carlos Gerardo Neil 2008
Programa de la Asignatura
1.1. Análisis y diseño OO 2.1. Proceso de desarrollo de software. 1º parte3.1. Casos de uso 3.2. Diagramas de clases. 3.3. Diagramas de comunicación. 3.4. Diagramas de secuencia. 4.1. Lenguaje de restricción de objetos. 5.1. Patrones de Diseño Para Asignación de Responsabilidades. 6.1. Transformación del Modelo de Clases al Modelo ER 7.1. Proceso de desarrollo de software 2º parte
Clase anterior – repaso general
• ¿Cómo puedo complementar los modelos UML con sentencias OCL?
• ¿Cuál es la ventaja de usar OCL en lugar de un lenguaje informal?
• ¿Qué significa que OCL es un lenguaje declarativo?
• ¿Qué es un invariante en una clase?
• ¿Cómo se específica una propiedad (atributo, operación, nombre de rol) en un diagrama de clases?
• ¿Cómo navegar una asociación a partir de los nombres de rol?
• ¿Cómo sé si hago referencia a un conjunto o un objeto a partir de la multiplicidad del extremo opuesto de una asociación?
• ¿Cuál es la diferencia entre los distintos tipos de colecciones?
Patrones de Diseño: otra forma de reutilización...
Diseñar software orientado a objetos es difícil, más aún diseñar software orientado a objetos reutilizables.
• Se deben encontrar las clases y relaciones apropiados entre ellas
• Se deben definir jerarquías de herencia y de interfaces y establecer relaciones entre ellas.
• El diseño debe satisfacer las necesidades actuales del usuario, además de contemplar futuros problemas o requerimientos.
Patrones de Diseño
El término patrón se utilizó inicialmente en el campo de la arquitectura, por Christopher Alexander, a finales de los 70s.
Este conocimiento fue transportado al ámbito del desarrollo de software orientado a objetos y aplicado al diseño.
el libro que inicio el camino fue:
“Design Patterns: Elements of Reusable Object-Oriented Software” Gamma
Patrones de Diseño
Los patrones de diseño permiten la reutilización exitosa de diseños y arquitecturas más rápidamente
Ayuda a elegir alternativas de diseño que hace a los sistemas reutilizables.
Un patrón es un par problema/solución con nombre que se puede aplicar a nuevos contextos con consejos de cómo aplicarlo
Aprovechar las experiencia de los desarrolladores
Patrones de Diseñoelementos esenciales
El nombre del patrón: se usa para describir un problema de diseño, su solución y las consecuencias, en una o dos palabras.
El problema: describe cuándo aplicar el patrón, explica el problema y su contexto
La solución: describe los elementos que hacen al diseño, sus relaciones, responsabilidades y colaboraciones
Las consecuencias: establecen los costos y beneficios de aplicar el patrón
Ejemplo: Patrón Adaptador
Convierte la interfaz de una clase en la interfaz que el cliente espera.
“Un objeto Adaptador provee la funcionalidad prometida por una interfaz, sin tener que asumir qué clase es usada para
implementar la interfaz”.
Permite trabajar juntas a dos clases con interfaces incompatibles.
Interfaz: colección de operaciones que son utilizadas para especificar un servicio de una clase
Ejemplo: Patrón Adaptador
Clase que llama a un método de otra clase a través de una interfaz, sin asumir que el objeto que implementa el método al que llama, pertenezca a una clase específica.
Esta interfaz declara el método que una clase Client llama
Esta clase implementa el método que el cliente llama, haciendo un llamado a un método de la clase Adaptee, la cual no implementa la interfaz.
Esta clase no implementa el método de la interfaz, pero tiene algún método que la clase cliente quiere llamar
Ejemplo: editor de gráficos
Circulo
dibujar()mover()
Rectangulo
dibujar()mover()
Triangulo
dibujar()mover()
EditorFigura
dibujar()mover()
Esfera
3Ddibujar()3Dmover()
Paralelepipedo
3Ddibujar()3Dmover()
Piramide
3Ddibujar()3Dmover()
3DAdaptador
dibujar()mover()
3DFigura
3Ddibujar()3Dmover()
La interacciones entre objetos se escriben según los términos de las especificaciones definidas en las superclases
Asignación de Responsabilidades a las
Clases
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
Comenzamos con los casos de uso.Inicialmente el nombre y una descripción
Describimos los casos de uso con mayor detalle.
Escenario principal
El cliente ingresa a la pagina Web de CVLIEl cliente ingresa a la opción “registración “El sistema solicita ingreso de los datos personalesEl sistema evalúa el país….…..
Hasta ahora hemos llegado hasta acá …
Creamos los diagramasde secuencia de sistemas (DSS)Para cada escenario de cada caso de uso.
Escenario principal
El cliente ingresa a la pagina Web de CVLIEl cliente ingresa a la opción “registración “El sistema solicita ingreso de los datos personalesEl sistema evalúa el país.…..
: SISTEMA
: cliente ingresarSistema()
ingresarDatosPersonales()
ingresarTarjetaCredito()
ingresarPreferenciasEnvio()
ingresarClaveContraseña()
DSS "Registrarse al sistema"
Creamos el modelo del dominio: CLASES, ASOCIACIONES, ATRIBUTOS
tiene
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Cliente
nombreapellidodireccionteprof esion
0..*
1
0..*
1
tiene
Autor
nombreapellido
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
1..*
1
1..*
1
tiene
Items
cantidad
1..*
1
1..*
1
1
0..*
1
0..* pertenecen
Hasta ahora hemos llegado hasta acá …
¿Cómo sigo?
¿En qué clases ubico a las operaciones que resuelven la funcionalidad de cada caso de uso?
¿Qué criterios uso para tomar esas decisiones?
Asignación de responsabilidades a las clases
“Despues de la identificación de los requisitos de los usuarios y de la creación del modelo del dominio, añada operaciones en las clases de software y defina el paso de mensajes entre los
objetos para satisfacer los requisitos …”
Decisiones poco acertadas sobre la asignación de responsabilidades de cada clase, dan origen a sistemas y componentes frágiles y difíciles de mantener, entender,
reutilizar o extender
Responsabilidades
“Una responsabilidad es un contrato u obligación de una clase”
Las responsabilidades se relacionan con las obligaciones de un objeto respecto de su comportamiento.
La responsabilidad no es lo mismo que un método, pero los métodos se implementan para llevar a cabo las responsabilidades
Estas responsabilidades pertenecen, esencialmente, a dos categorías:
• hacer• conocer .
Responsabilidades
Entre las responsabilidades de un objeto relacionadas con el hacer se encuentran:
• Hacer algo uno mismo.
• Iniciar una acción en otros objetos.
• Controlar y coordinar actividades en otros objetos.
Responsabilidades
Entre las responsabilidades de un objeto relacionadas con el conocer se encuentran:
• Conocer los datos privados encapsulados.
• Conocer los objetos relacionados.
• Conocer las cosas que se pueden derivar o calcular.
“las responsabilidades relevantes de conocer a menudo se pueden inferir a partir del modelo del dominio”
Un ejemplo... (ver caso práctico)
tiene
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Cliente
nombreapellidodireccionteprof esion
0..*
1
0..*
1
tiene
Autor
nombreapellido
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
1..*
1
1..*
1
tiene
Items
cantidad
1..*
1
1..*
1
1
0..*
1
0..* pertenecen
El Patrón “Experto” [Larman]
Nombre: Experto.
Problema: ¿Cuál es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseño orientado a
objetos?
Solución: Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria
para cumplir la responsabilidad.
El Patrón “Experto”
Desde el punto de vista del patrón Experto, deberíamos buscar la clase de objetos que posee información sobre los Items vendidos
Nota: buscamos inicialmente en las clases del modelo de dominio
CarritoCompra
EjemplarLibro
numeroprecio
Items
cantidad
1..n
1
1..n
1
tiene
1
0..n
1
0..n pertenecen
El objeto que conoce esto es CarritoCompra
Ejemplo: ¿quién es el responsable de conocer el total de una venta?.
El Patrón “Experto”
¿Qué información hace falta saber para determinar la cantidad de Items vendidos y el precio para
saber la venta total? CarritoCompra
EjemplarLibro
numeroprecio
Items
cantidad
1..n
1
1..n
1
tiene
1
0..n
1
0..n pertenecen
cantidad de items vendidosItems.cantidad precio del libro
ejemplarLibro.precio
La cantidad de Items vendidos está en la clase Items y el precio, en EjemplarLibro, ambos tienen la información necesaria para realizar la responsabilidad
Seguimos con el ejemplo...
: CarritoCompra : Items
2 *: s := subtotal()1: venta()
: EjemplarLibro
3: p := darPrecio()
CarritoCompra
venta()
1..*
11
tiene
1..*
Items
cantidad
subtotal()
0..* pertenecen
1
0..*
1
EjemplarLibro
numeroprecio
darPrecio()
Envío el mensaje venta() a CarritoCompra
Envío el mensaje subtotal() a Items
Envío el mensaje darPrecio() a EjemplarLibro
*
El * indica que es iteración sobre una colección
El Patrón “Creador” [Larman]
El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos, tarea muy frecuente en los sistemas
orientados a objetos.
El objetivo de este patrón es encontrar un creador que debemos conectar
con el objeto producido en cualquier evento
: Items : CarritoCompra1: crear( parametros )
<<create>>
Estereotipo que indica que es un
mensaje de creación
Llamada a un constructor Variables de inicialización
El Patrón “Creador”
Problema: ¿Quién debería ser responsable de crear una nueva instancia de alguna clase?
La creación de objetos es una de las actividades más frecuentes en un sistema orientado a objetos. En consecuencia, conviene contar con un principio general para asignar las responsabilidades concernientes a
ella.
: Items
: CarritoCompra
1: crear( parametros )
Llamada a un constructor
Variables de inicialización
<<create>>
El Patrón “Creador”
Solución: Asignarle a la clase B la responsabilidad de crear una instancia de la clase A en uno de los siguientes casos:
· B agrega los objetos de A.· B contiene los objetos de A.· B registra las instancias de los objetos de A.· B tiene los datos de inicialización que serán enviados a A cuando este objeto sea creado (B es un experto respecto a la creación de A).
Beneficios: Se brinda apoyo a un bajo acoplamiento, lo cual supone menos dependencias respecto al mantenimiento y mejores oportunidades de reutilización.
El Patrón “Creador”
Ejemplo: En la aplicación ¿quién debería encargarse de crear una instancia de items?
CarritoCompra
agregarItem()v enta()
1..*
11
tiene
1..*
Items
cantidad
crear()subtotal()
CarritoCompra contiene uno o más Items
Cada vez que hago una compra, agrego un nuevo Item
Desde el punto de vista del patrón Creador, deberíamos buscar una clase que agregue, contenga, y realice otras operaciones sobre este tipo de instancias.
El Patrón “Creador”
Un CarritoCompra contiene (agrega) muchos objetos Items. Es por esto que el patrón Creador sugiere que CarritoCompra es la clase idónea
para asumir la responsabilidad de crear las instancias de Items.
: CarritoCompra : Items
2: crear()1: agregarItem()
CarritoCompra
agregarItem()v enta()
1..*
11
tiene
1..*
Items
cantidad
crear()subtotal()
Envío el mensaje agregarItem() a CarritoCompra
Envío el mensaje crear() a Items Normalmente se invoca al
constructor de la clase
<<create>>
El Patrón “Bajo acoplamiento”
El acoplamiento es la medida de la fuerza con que un elemento está conectado con otros.
Un alto acoplamiento implica que:
• Los cambios en las clases relacionadas fuerzan cambios en las clases locales
• Son difíciles de entender de manera aislada
• Son difíciles de reutilizar, debido a que su uso requiere la presencia adicional de las clases de las que depende
El Patrón “Bajo acoplamiento”
Problema: ¿cómo soportar bajas dependencias, bajo impacto en el cambio e incremento en la reutilización?
Solución: asignar las responsabilidades a las clases de manera de mantener el acoplamiento bajo
Beneficios: las clases son más independientes, lo que reduce el impacto al cambio
El Patrón “Alta cohesión”
La cohesión es una medida de la especificidad de una responsabilidad
Una clase con baja cohesión hace muchas cosas no relacionadas y adolece de los siguientes problemas:
Difíciles de entender, reutilizar y mantener
Regla empírica: una clase con alta cohesión tiene un número relativamente pequeño de métodos con funcionalidad altamente relacionada
El Patrón “Alta cohesión”
Problema: ¿como mantener la complejidad manejable?
Solución: asignar las responsabilidades de manera que las cohesión permanezca alta
Beneficios: se incrementa la claridad, se simplifica el mantenimiento y las mejoras, implica generalmente bajo acoplamiento
El Patrón “Controlador”
Problema: ¿Quién debe ser el responsable de gestionar un evento de entrada al sistema?
(Un evento del sistema de entrada es un evento generado por un actor externo)
Solución: asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que:
a) represente el sistema global
b) represente un escenario de caso de uso donde tiene lugar el evento
El Patrón “Controlador”
Durante el análisis, las operaciones del sistema pueden asignarse a la clase “Sistema”, eso no significa que una clase software “Sistema” las lleve a cabo
Sistema
introducirArticulo()realizarPago()
Durante el diseño, se le asignan las responsabilidades de las operaciones del sistema a una clase controlador (la clase controlador no es una clase del dominio de la aplicación)
ProcesarVenta
introducirArticulo()realizarPago()
El Patrón “Controlador”• Un objeto controlador no pertenece a la capa de interfaz
• Generalmente no hace trabajo, lo delega a otros objetos
• El controlador es una especie de fachada sobre la capa de dominio para la capa de interfaz
• Durante el diseño se asignan a una o más clases controlador las operaciones del sistema que se identifican durante el análisis
– Normalmente se utiliza una misma clase controlador para los eventos del sistema de un caso de uso
– Si no hay muchos eventos al sistema puedo usar una única clase controlador de fachada
El Patrón “Controlador” un ejemplo
Sistema
introducirArticulo()realizarPago()crearNuevaVenta()final izarVenta()crearNuevaDevolucion()introducirArticuloDevuelto()
ProcesarVenta
finalizarVenta()introducirArticulo()crearNuevaVenta()realizarPago()
GestionarDevoluciones
introducirArticuloDevuelto()crearNuevaDevolucion()
Operaciones del sistema descubiertas en la etapa de análisis
Asignación de operaciones en la etapa de diseño utilizando controladores
Análisis Diseño
El Patrón “Controlador”
: Controlador
: Ventana
: CarritoCompra
1: IntroducirArticulo(ID,cant)
2: crearLineaVenta(ID, cant)
Capa de Interfaz
Capa de Dominio
Mensaje de evento del sistema
Controlador, asume la responsabilidad de manejar las operaciones del sistema
Clase del dominio
La capa de interfaz no maneja eventos del sistema
Sugerencias
• Use los patrones de diseño para decidir en qué clases van qué operaciones
• Tómese el tiempo necesario para decidir la ubicación de las operaciones. Marcaran la calidad del diseño
• Antes de aplicar los patrones, estudie bien el uso que se hace de ellos en la
bibliografía
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 5.1 si puedo definir y dar ejemplos de:
• Patrón de diseño
• Responsabilidades
• Patrón de asignación de responsabilidades
• Patrón experto
• Patrón creador
• Patrón alta cohesión
• Patrón bajo acoplamiento
• Patrón controlador
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 5.1, si
• Entiendo cuál es el objetivo de usar un patrón para asignación de responsabilidades
• Entiendo en que disciplina del UP los utilizo
• Vinculo el concepto de realización de una colaboración en los casos de uso con el de diseño utilizando patrones
• Comprendo la vinculación de los diagramas de secuencia de sistema (DSS) con el uso de patrones de asignación de responsabilidades
• Entiendo por qué uso los patrones controladores
• Comprendo que normalmente utilizo más de un patrón para asignar responsabilidades a las clases
FIN
Análisis de Sistemas Administrativos
Unidad 6.1 Persistencia de Objetos
Facultad de Tecnología Informática UAI
Mg. Carlos Gerardo Neil 2008
Programa de la Asignatura
1.1. Análisis y diseño OO 2.1. Proceso de desarrollo de software. 1º parte3.1. Casos de uso 3.2. Diagramas de clases. 3.3. Diagramas de comunicación. 3.4. Diagramas de secuencia. 4.1. Lenguaje de restricción de objetos. 5.1. Patrones de Diseño Para Asignación de Responsabil. 6.1. Transformación del Modelo de Clases al Modelo ER 7.1. Proceso de desarrollo de software 2º parte
Clase anterior – repaso general
• ¿Cuál es el objetivo de usar un patrón para asignación de responsabilidades?
• ¿En qué disciplina del UP utilizo los patrones de diseño?
• ¿Cómo se vincula el concepto de realización de una colaboración en los casos de uso con el de diseño utilizando patrones para asignacion de responsabilidades?
• ¿Cómo se vinculan los diagramas de secuencia de sistema (DSS) con el uso de patrones de asignación de responsabilidades
• ¿Para qué uso los patrones controladores?
Modelo de Clases vs. Modelo de Datos
• En el modelo de clases tenemos:– Clases– Asociaciones– Clases Asociaciones– Generalizaciones– Atributos
• En el modelo de datos tenemos:– Entidades– Interrelaciones – Atributos– Identificadores
¿Cómo mantengo la persistencia de los objetos...?
...Mediante una base de datos
¿Cómo se puede hacer corresponder un modelo de objetos con un modelo de datos?
¿Cómo hago las transformaciones?
¿Todas las clases se transformarán en entidades?
¿Qué pasará con las asociaciones?
¿...y las clases asociaciones?
Alumno
Alumno Materia
Nota
Alumno Materia
?
?
?
¿Cómo hago las transformaciones?/2
¿... Qué pasará con las generalizaciones?
¿y con los atributos de las clases?
¿Y con las operaciones?
Materianombreaño
Materianombreaño
darNombre()darAño()
?
?
vehiculo
camion automovil
?
Transformación Básica - Clases
• Todas las clases se transforman en entidades
Alumnonombreapellidodireccion
ALUMNO
nombre
apellido
direccion
codAlu
Creo el Atributo identificador
el modelo de datos NO hay operaciones
Los atributos de la clase pasan a ser atributos de la entidad
Se crean nuevos atributos identificadores para cada entidad (los objetos no precisan Identificador único.)
Transformación Básica – Asociaciones
• Las asociaciones se transforman en interrelaciones
EMPRESA EMPLEADO(1, n)(1, 1)
EmpleadoEmpresa 1 1..*1 1..*
Se mantiene, en el modelo de datos, la misma multiplicidad de la asociación
Transformación Básica – Composición
FacturaNroFacturafecha
LineanroItemcantidad1..*1..*
• Las relaciones de composición
El “todo” se transforma en entidad fuerte y la “parte” y se transforman en entidad débil FACTURA LINEA
(1, n)(1, 1)
Transformación Básica – Clase Asociación
• La clase asociación se transforma en interrelación
– La multiplicidad es de M:N
– Los atributos de la clase asociación pasan a ser atributos de la interrelación
Empleado Empresa
1..*1..* 1..*1..*
PuestofechaIngresosueldo
EMPRESA
EMPLEADO
(1, n)
(1, n)
sueldo
FechaIngreso
PUESTO
Transformación Básica – Generalización
• Las relaciones de clasificación (tres opciones)
1. Se transforman en relaciones de clases y subclases en el modelo
entidad interrelación, o
vehiculotipoCombustiblepeso
automovilcantidadPasajeros
camioncapacidad
AUTOMOVIL
peso
cntidadPasajeros
tipoCombustible
codAut
Tengo que agregar el atributo identificador
2. Se pasan los atributos de la superclase a las subclases (desaparece la superclase)
3. Se pasan los atributos de las subclases a la superclase (y desaparecen aquellas)
VEHICULO
peso
cntidadPasajeros
tipoCombustible
codAut
capacidad
CAMION
peso tipoCombustible
codAut
capacidad
Un ejemplo
ALUMNO
CURSO MATERIA
cod_alum
cod_cur
cod_mat
N
1
PROFESOR
NOTA
M
NN
M
nota
fecha
cod_prof
supeclase
superclase
NOTA
notafecha
PROFESOR
CURSO
ALUMNO
1
*
MATERIA*
*
*
*
*
*
*
*
*
1
Transformación del modelo de clases al
modelo de datos
La transformación al modelo relacional es la
conocida...
Otro ejemplo...
Autor
nombreapellido
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Cliente
nombreapellidodireccionteprof esion
0..*
1
0..*
1
tiene
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
agregarItem()v enta()
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
darPrecio()
1..*
1
1..*
1
tiene
Items
cantidad
crear()subtotal()
1..*
1
1..*
1
tiene
1
0..*
1
0..* pertenecen
CLIENTE
EJEMPLARLIBRO
cod_cli
num_ejemp
1
1
ORDENCOMPRA
1
1
1
cod_carro
cod_ord
AUTOR LIBRO
cod_librocod_autor
ITEMS
num_item
CARRITOCOMPRA
1
N
N
N 1
1
N
N N
El modelo Relacional Asociado
Cliente(cod_cli, ...)
OrdenCompra(cod_ord, ..., cod_cli(Cliente))
CarritoCompra(cod_carro, ..., cod_cli(Cliente), cod_ord(OrdenCompra))
Items(num_item, ..., cod_carro(CarritoCompra), num_ejem(EjemplarLibro))
EjemplarLibro(num_ejem, ..., cod_libro(Libro))
Libro(cod_libro, ...)
Autor(cod_autor, ...)
LibroAutor(cod_libro(Libro), cod_autor(Autor))
Otro ejemplo
Story
-title-date-summary
Interview
Q&A
-question-answer
1..1
*
dateIDst title
1..n
1..1
body
part
Person
-name-address-email
1..1
Q&A
1..1
IDqa
Essay
-illustration
1..*
PersonStory
InteviewEssay
part
body name
emailsummary
answer
IDpr
question
1..n
1..1
1..n
1..n 1..1
illustration
address
1..*1..*
1..*
1..1
1..1
author
participant
ConceptualModel ERModel
participant
author
Sugerencias
• El modelo de datos es una consecuencia del modelo de clases, por lo tanto se diseña después de este
• La transformación es del modelo de clases al modelo conceptual (DER) y de éste al modelo lógico (relacional) – ver OED –
• Tenga en cuenta costos y beneficios de mantener en el modelo de datos conceptual, las relaciones de generalización
• Existen otros mapeos entre el diagrama de clases y el modelo de datos (ver bibliografía específica)
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 6.1 si puedo definir y dar ejemplos de:
• Transformación de – Clases
– Asociaciones
– Composiciones
– Generalizaciones
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 6.1, si
• Entiendo por qué utilizo una base de datos relacional y no, como parecería lógico, una base de datos OO
• Entiendo por qué derivo el modelo de datos del modelo de clases y no a la inversa
• Comprendo que la transformación propuesto no es la única posible
• Entiendo por qué solo transformo datos y no operaciones
• Comprendo por qué por a cada clase transformada, además de los atributos, debo añadirle, en el modelo de datos, un identificar único
FIN
Top Related