44622246-as-a-2008

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


Unidad 2.1

UML y el Proceso de Desarrollo de Software



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


Comment

Rutinas de Coneccion

Comment


Comment


Comment


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



Cliente


<<include>>

<<include>>

tiene

OrdenCompra


Cliente


0..*

1

0..*

1

tiene

Autor

nombreapellido

Libro


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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


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



Cliente


<<include>>

<<include>>

tiene

OrdenCompra


Cliente


0..*

1

0..*

1

tiene

Autor

nombreapellido

Libro


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.


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


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”


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


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”


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

Primera iteración

ETAPA DE INICIO



Cliente


<<include>>

<<include>>

Comenzamos con los casos de uso.Inicialmente el nombre y una descripción


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

Primera iteración

ETAPA DE ELABORACIÓN



Cliente


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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

Primera iteració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"


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

Primera iteració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


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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

Primera iteració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 )


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

Primera iteració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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

Primera iteración


Codificamos y probamos.

Mostramos el ejecutable al usuario

public class AdaptadorFigura extends Figura{private int x;

public AdaptadorFigura(){ variables

x = 0; }}


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

Segunda iteración


Comenzamos una nueva iteración trabajando con nuevos casos de uso (o mejorando los anteriores)

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


• 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


Unidad 3.1 Casos de Uso




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


• ¿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


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


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


Iter

#n

------------Iter#2

prueba

Iter#n-1

------Iter#1

Implementación

Diseño

Análisis

Requisitos


disciplinas

un ejemplo...

Consultar libros en general

Consultar novedades Consultar ofertas

Cliente

Consultar libro

<<extend>><<extend>>

<<extend>>

un ejemplo...



comprar libro

Cliente

buscar libros

Consultar libro

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


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


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)


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)


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



Cliente

Gestor de Libros

Tarjeta de Credito

Consultar libro


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


• 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


Unidad 3.2 Diagrama de Clases




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


• ¿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{


private tipo b;


public void b1() {}

}

Bb

b1()

Aa

a1()

Interfaz

public interface A{


void operación();

}

public class B implements A{


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{


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{


private tipo b;

}

Asociación 1 a muchos

Aa

Bb

1..*1

-rol-b

1..*1

public class A{


private tipo a;

// * opción 1 *

// referencia al conjunto de objetos B

// mediante un vector

private Vector rol-b = new Vector();

}

public class B{


private tipo b;

}

public class A{


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{


private tipo b;

// referencia al conjunto de objetos C


private A a[]= new A[n];

}

public class A{


private tipo b;



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{


private tipo a;



private C c[] = new C[n];

}

public class B{


private tipo b;



private C c[]= new C[n];

}

public class C{


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


Unidad 3.3 - 3.4 Diagrama de Secuencia y Comunicación




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


• ¿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







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


Cliente


0..*

1

0..*

1

tiene

Autor

nombreapellido

Libro


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

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


Unidad 4.1 OCL




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


• ¿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/

http://vig-fp.prenhall.com/bigcovers/0321179366.jpg

http://www.omg.org/

¿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

*


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


Habitación


+huéspedes

*


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


Habitación


*

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


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


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


Compañia


+empleado

0..*0..*


+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


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


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


1..*1..* 1..*1..*

med1Obra1

obra2

af1

af2

af3Context Medico

... self.trabaja.afiliados


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


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


**+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 )



**+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)



**+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)



**+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’)


Cuenta/msaldo: Real

mCuentas

mTitulares 0..*

1..*

context Cuenta

inv: self.mTitulares->exists(c:Cliente| c.mEdad>=18)



**+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


Compañia


+empleado

0..*0..*


+empleador

0..* 0..*

expresiones <<definition>>

context Cuenta

def: msaldo : real = self.mMovs.mImporte->sum()

context Cuenta

inv: saldo > 0


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


Unidad 5.1 Patrones de Diseño




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


• ¿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


Piramide


3DAdaptador

dibujar()mover()

3DFigura


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



Cliente


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







Creamos el modelo del dominio: CLASES, ASOCIACIONES, ATRIBUTOS

tiene

OrdenCompra


Cliente


0..*

1

0..*

1

tiene

Autor

nombreapellido

Libro


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


Cliente


0..*

1

0..*

1

tiene

Autor

nombreapellido

Libro


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


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.


Ejemplo: En la aplicación ¿quién debería encargarse de crear una instancia de items?

CarritoCompra


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.


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


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


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


: 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


• 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


• 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


Unidad 6.1 Persistencia de Objetos




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


• ¿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


Cliente


0..*

1

0..*

1

tiene

Libro


1..*1..* 1..*1..*

esta escrito por

CarritoCompra


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


• Transformación de – Clases

– Asociaciones

– Composiciones

– Generalizaciones

Auto evaluación/2


• 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

44622246-as-a-2008

Documents