05 modelo de diseño

Desarrollo de software orientado a objetos

Unidad 5:Modelo del Diseño

Agenda

Del análisis al diseño Diagramas de Interacción Responsabilidades y métodos

Del análisis al diseño

Del Análisis al Diseño

En el análisis se pone énfasis en el conocimiento de los requerimientos desde la perspectivas del “qué”: ¿qué procesos se requieren?, ¿qué conceptos son necesarios para el sistema?


En el diseño se da forma al sistema y se define su perfil (con la arquitectura incluida).

Se define “cómo” se satisfacen los requerimientos funcionales y no funcionales.


Propósitos: Lograr una clara comprensión de

requerimientos no funcionales relacionados con lenguajes de programación, reuso de componentes, sistemas operativos, tecnologías de distribución, concurrencia, bases de datos, etc.


……. Tener la capacidad de descomponer

el trabajo de implantación en piezas manejables que puedan ser desarrolladas por distintos grupos.

Capturar las interfaces más importantes entre los distintos subsistemas.

Del Análisis al DiseñoModelo de Análisis Modelo de Diseño

Es conceptual, unaabstracción del sistema sincaracterísticas de implem.

Es físico, es el anteproyectode la implementación

Es genérico respecto aldiseño (válido para muchos)

Es específico para laimplementación

Contempla tres estereotiposde clases: : “control”,“entity” y “boundary”

Diseña clases de muchosestereotipos dependiendodel lenguaje

Define pocas capas Define muchas capas

Realización de los Casos de Uso

Describe como se desarrolla un caso de uso en términos de sus clases y objetos.

Describe su diseño a partir de herramientas concretas de entrada y salida.

Se adjuntan a la especificación: La interfaz del usuario Los diagramas de interacción. Diagramas de clases orientados al diseño.

Realización de los Casos de Uso

Se puede completar una especificación esencial con el diseño de las pantallas y su interacción.

Se puede hacer especificaciones reales redefiniendo el flujo de los eventos utilizando los elementos de la interfaz (orientando la especificación a un manual de usuario).

Diagramas de interacción


Conceptos base Enfoque Cliente Servidor Diagrama de Secuencia del Sistema

Diagramas de interacción. ¿Qué son? Diagramas de secuencia Diagramas de colaboración

Enfoque Cliente-Servidor

Forma de solucionar un problema en la vida real.

Pregunta: ¿Qué hago si mi auto se

descompone?Solución

Voy al taller para que lo compongan


Pasos en la solución del problema: Buscar un servidor apropiado (taller) Hacerle la petición del servicio (pasarle el

mensaje “arreglar auto”) El servidor emplea el método apropiado

para resolver la petición (procedimiento de arreglo propio del taller)


Consideraciones: Al cliente no le interesa cómo el servidor

resuelve su petición. La solución está encapsulada u oculta en

el servidor. El pensamiento de un servidor es buscar

alguien más para que colabore con la solución.


Cliente Servidor Colaborador(es)

Comportamiento del sistema

Diagrama de secuencia del sistema

Muestra los eventos que fluyen de los actores al sistema

Evento: Acción de un actor que provoca que el sistema cambie de estado

Evento: Acción de un actor que provoca que el sistema cambie de estadoEvento

Sistema

Vender Productos: Versión 1

Repetir hasta que no haya mas productos

IntrProd(CUP, Cantidad)

Diagrama de Secuencia del Sistema

:SistemaCajero

TerminarVenta ()

EfectuarPago (Monto)

Cómo elaborar un diagrama de secuencia del sistema Colocar el símbolo del objeto sistema

y una línea vertical Para cada actor colocar su símbolo y

una línea vertical A partir de los eventos del caso de uso

identificar los eventos externos que son generados por los actores para los casos de uso

TerminarVenta Vs OprimirTeclaEnter

Cómo nombrar los eventos

Deben denominarse de tal manera que estén desprovistos del medio físico de entrada o de elementos de la interfaz.

Se debe utilizar verbos en infinitivo. Deben captar el propósito de la

operación y no definirse en función de la interfaz.

IntroducirImporteOfrecido(Monto)

¡Cada vez mejor!

IntroducirPago(Monto)

EfectuarPago(Monto)

Denominación de los Eventos

Importante:Describir el propósito

Importante:Describir el propósito

:SistemaCajero

IntrProd(CUP, Cantidad)

TerminarVenta ()

EfectuarPago (Monto)

Para todos los productos el cajero registra el CUP y la cantidad….

...Al terminar la captura indica que la venta terminó.

...El cajero registra el importe recibido en efectivo

Diagrama de Secuencia del Sistema

Diagramas de interacción… ¿Qué son? Un diagrama de interacción es una

representación gráfica de las interacciones entre los objetos.

Existen dos versiones: Diagramas de secuencia Diagramas de colaboración

Diagramas de interacción… ¿Qué son? Cada uno de estos diagramas

proporciona una vista diferente de la misma interacción. Los diagramas de secuencia están

ordenados de acuerdo al tiempo. Los diagramas de colaboración ponen

énfasis en los mensajes entre los objetos y pueden incluir flujos de datos.

Diagramas de secuencia

Introducción. Elementos. Distribución del flujo de control en

diagramas de secuencia.

Introducción

Los diagramas de secuencia se usan para ilustrar la realización de los casos de uso.

Una organización típica tiene un diagrama de secuencia para el flujo normal de eventos de un caso de uso y otro para cada flujo alternativo independiente.

Introducción

Los diagramas de secuencia son importantes para los diseñadores porque aclaran los roles de los objetos dentro de un flujo y proporcionan un input básico en la determinación de las responsabilidades de clases e interfases.

A diferencia de un diagrama de colaboración un diagrama de secuencia incluye una secuencia cronológica, pero no relaciones entre objetos.

Elementos del diagrama de secuencia El diagramas muestran:

Los objetos y actores que participan en la interacción.

La secuencia de mensajes intercambiada entre dichos objetos.

Diagramas de secuencia

Contiene: Objetos con sus líneas de vida Mensajes intercambiados entre los

objetos ordenados secuencialmente Focos de Control (opcionales). Scripts adicionales que aclaran el

propósito de la interacción entre objetos

Diagrama de secuencia

Objetos

Los objetos se dibujan como rectángulos con nombres subrayados.

Las líneas de vida de los objetos son representadas por líneas punteadas. Representa la existencia o presencia de un objeto en un determinado tiempo.

Actores

Los actores se representan normalmente al inicio de un diagrama de secuencia como el que invoca a la interacción de los objetos.

Si hay mas de un actor es preferible que se coloquen todos al inicio (extremo izquierdo) o al final (extremo derecho).

Mensajes

Un mensaje es la comunicación entre objetos que conlleva información y la expectativa de obtener un resultado.

Están indicados por flechas horizontales que son direccionadas desde una línea vertical (que representa al objeto cliente) hasta la otra (que representa al objeto servidor)

Las flechas horizontales están etiquetadas con el nombre del mensaje.

Mensajes

El orden de los mensajes de acuerdo al tiempo está indicado por la posición vertical, con los primeros en la parte de arriba.

La numeración es opcional y está basada en la posición de las líneas verticales.

Focos de control

Los focos de control representan el tiempo relativo en el que un flujo de control está focalizado en un objeto. Representa la secuencia de tiempo en

que un objeto esta dirigiendo sus mensajes.

Deben ser mostrados en un diagrama de secuencia para establecer ciclos.

Ej. Diagrama de Secuencia con focos de control

Scripts

Para escenarios complejos, los diagramas de secuencia pueden enriquecerse con el uso de scripts.

Estos, se escriben a la izquierda del diagrama de secuencias con los pasos alineados con las interacciones entre objetos.

Los scripts pueden ser escritos en lenguaje natural o pseudo código.

Scripts para los Diagramas de Secuencia

Ejemplo

* Obtener Detalle(): PrecioXCantidad

Detalle CompobanteComprobante

El objeto comprobante obtiene de cada uno de

sus detalles el precioxcantidad para

calcular el total

Distribución del control en un diagrama de secuencia La distribución del control en un

diagrama de secuencia puede ser centralizado, descentralizado o comúnmente una combinación de ambos comportamientos.

Distribución del control en un diagrama de secuencia El control centralizado significa que unos pocos

objetos gobiernan el flujo enviando y recibiendo mensajes del resto de objetos.

Estos objetos de control deciden el orden en el que otros objetos serán activados.

La interacción entre los otros objetos es mínima o no existe.

: Usuario : IReserva : CReservas

CONTROL CENTRALIZADO

: Reserva : Cliente : Producto

Distribución del control en un diagrama de secuencia

La principal ventaja del control centralizado consiste en que cada objeto no necesita hacer seguimiento del comportamiento del siguiente.

Si se requiere hacer cambios en el curso de eventos se hace los cambios en le objeto de control.

Distribución del Control en un Diagrama de Secuencia

El control centralizado es apropiado: Si el orden en el cual los sub-eventos se

desarrollarán son cambiantes. Si se espera adicionar sub-eventos o

nuevos escenarios. Si se quiere conservar partes de la

funcionalidad como piezas separadas reusables.


El control descentralizado se origina cuando los objetos participantes se comunican directamente unos con otros sin la intervención del un objeto controlador.

: Usuario : IReserva : CReservas

CONTROL DESCENTRALIZADO

: Reserva : Cliente : Producto


El control descentralizado es apropiado: Si las fases de sub-eventos están fuertemente

emparejados como en el caso de objetos: Participantes de una jerarquía: País-Departamento-

Provincia-Distrito. Que forman parte de una organización (información)

jerárquica: CEO-Gerencia de División-Gerente de Sección, etc.

Que representan una progresión cronológica fija (siempre se van a realizar en un orden determinado): Publicidad, Pedido, Facturación, Despacho y Pago.


El control descentralizado es apropiado: Si se desea encapsular (y en

consecuencia hacer abstracciones) la funcionalidad porque se usa frecuentemente como un todo.

Diagramas de colaboración

Introducción. Elementos. Multiobjetos.

Introducción

Al igual que los diagramas de secuencia, los de colaboración se usan para aclarar los roles de los objetos que participan en un flujo de eventos de un caso de uso.

Son la principal fuente de información para determinar las responsabilidades de las clases e interfaces.

Introducción

El diagrama muestra las interacciones entre objetos organizadas alrededor de los propios objetos y sus mutuas conexiones.

Son mejores para comprender todos los efectos de un objeto dado y para el diseño de procedimientos.

Elementos

Contiene: Objetos. Actores. Asociaciones entre objetos. Mensajes intercambiados entre los

objetos. Flujos de datos entre objetos (si existen).

Diagramas de colaboración

Ejemplo:

English101

Sólo Objeto

:Curso

Sólo Clase

English 101:Curso

Objeto y Clase

Objetos

Los objetos se dibujan como rectángulos con nombres subrayados

Actores

Se representan normalmente para invocar o iniciar una interacción.

Si hay mas de uno es mejor diagramarlos en la periferia.

Horario : Formulario Un curso : Curso

Vínculos

Un vínculo de interacción está representado por una línea que conecta a los íconos de los objetos.

Indica que hay un camino de comunicación entre dos objetos conectados.

Notaciones para los vínculos

Un vínculo de interacción puede estar documentado con: Una flecha que apunta desde el objeto cliente

hacia el objeto servidor. El nombre del mensaje con una lista opcional

de parámetros y/o valores de retorno. Un número secuencial opcional que muestra el

orden relativo en que los mensajes son enviados.

Horario : Formulario Un Curso : Curso

1: Obtiene prerrequisitos

2: Selecciona cursos

Lista de Cursos

Objeto Servidor

MensajePuntos del cliente

al servidor

Objeto cliente

Data de retorno

Vínculo

Notaciones para los Vínculos

Representación de parámetros

Los parámetros pueden anotarse dentro de un paréntesis a continuación del nombre del mensaje. Es opcional incluir el tipo.

obtieneHorarioDisp(IdCurso: char)

:Curso :Horario

Representación del mensaje que devuelve valor

Puede incluirse un valor de retorno anteponiendo una variable y un operador de asignación.

La sintaxis es:

1: Creditos := obtieneCreditos(IdCurso: char):Entero

retorno : mensaje(parametro : tipoParametro) : tipoRetorno

:ControladoraMatricula :Curso

Representación de la iteración

La iteración se indica poniendo un asterisco (*) al número de secuencia.

1* : CM := cursoMatriculado():detalleMatricula

:Matricula :DetalleMatricula

Representación de la iteración

La iteración con cláusula.

1* :[i:=1..10] CM i := ObtenerCurso():Curso

:ControladoraCursos :Curso

Representación de condicionales mutuamente excluyentes

La iteración con cláusula.

1a :[con beca] ExonerarPago(IdMatricula)

:ControladoraPagos :Matricula

:CuentaCorriente

1b :[sin beca] CrearCuenta(IdMatricula)

Representación de las colecciones

Un multiobjeto, colección o conjunto de instancias se representa como:

Suele implementarse como un grupo de instancias guardadas en un contenedor u objeto colección

:Detalle Matricula

Representación de los mensajes a un multiobjeto

:Venta vl:VentaDetalle

:VentaDetalle

1: mens1()2: mens2()

1.1: crear()

2.2: imprimir()

1.2: adicionarDetalle(vl)

2.1: vl := obtenerDetalle(IdVenta)

¿Cómo comenzar?

Procedimiento recomendado:1 Preparar un diagrama para cada operación

del sistema (encontradas en los diagramas de secuencia del sistema para cada caso de uso), que lo incluya como mensaje inicial.

2 Dividir el diagrama si se vuelve complejo.3 Diseñar un sistema de objetos interactuantes

para que realicen las tareas (tomar en cuenta las post-condiciones de contratos o casos de uso).

Diagramas de interacción y otros artefactos

:Sistema

Iniciar Reserva()

Casos de uso y diagramas de Secuencia del Sistema

Caso de uso: Realizar Reserva()

Post Condiciones: • Se creó un objeto Reserva.....

Especificaciones de casos de uso y post-

condiciones, diagramas de clases de análisis

: Usuario : IReserva : CReservasIniciar Reserva()


Ejemplo de elaboración de diagramas de interacción

Caso de Uso: Registrar Reserva (escenario de la reserva en agencia).

: Usuario SISTEMA

BuscarCliente()

IniciarReserva()

TerminarReserva()

BuscarProducto()


Counter

(from Actores)

ECliente

EProductoCCliente

CProductos

EReserva

EFormaPagoCReservaIListaReserva

IReserva


Operación: IniciarReserva () Descripción: Permite la creación de una

nueva reserva. Pre-Condiciones:

El sistema conoce la agencia registradora. Post-Condiciones:

Se creo una instancia de la clase Reserva. Se asoció una agencia a la instancia Reserva.


: Usuario : IReserva

R1 : RESERVA: SUCURSAL

: CReserva : IListaReservas

IniciarReserva()

IniciarReserva()

ObtenerSucursal(IdSucursal)

CrearReserva( )

AbrirIReserva(Ope, NombreAgencia)


4: CrearReserva( )

: Usuario

: IReserva

R1:RESERVA

: IListaReservas

: CReserva

:SUCURSAL

1: IniciarReserva()

2: IniciarReserva()

3: ObtenerSucursal(IdSucursal)

5: AbrirIReserva(Ope, NombreAgencia)

Responsabilidades y métodos

Responsabilidades y Métodos Las responsabilidades no son mas que los contratos

u obligaciones que tienen las clases. Las responsabilidades se implementan como

métodos. Se descubren a partir de los diagramas de

interacción. Asignarlas correctamente es uno de los problemas

de mayor importancia en el DOO. Podemos agruparlas en dos categorías:

Hacer Conocer

Responsabilidades y Métodos

Entre las responsabilidades relacionadas con hacer están: Hacer algo en uno mismo:

Imprimir Comprobante() Iniciar una acción en otros:

CalcularTotalesVenta() Controlar y coordinar actividades en otros

objetos: RegistrarVenta()

Responsabilidades y Métodos

Entre las responsabilidades relacionadas con conocer están: Estar enterado de los datos privados

encapsulados: MostrarNombreCliente() Estar enterado de la existencia de objetos

conexos: MostrarDetalleVenta() Estar enterado de las cosas que se pueden

derivar o calcular CalcularImpuesto()

Se pueden inferir del Modelo Conceptual

Responsabilidades y Métodos Otra forma de reconocer responsabilidades

es a partir de la naturaleza de las clases. Las interfaces son expertas en mostrar y recibir

información. La entidades son expertas en el manejo de

datos. Las controladoras son las administradoras de

los casos de uso y se encargan de resolver los pedidos complejos (que involucran a varias clases).

Los multiobjetos son expertos en manejar listas de objetos

Conclusiones

Asignar responsabilidades de manera adecuada es una de las tareas mas importantes del diseño y la que ocupa mas tiempo.

Los diagramas de interacción se usan en dos fases: En la primera, ayudan a descubrir los métodos de las

clases. En la segunda deben ser actualizados de tal manera que

todos los métodos de las clases estén en algún diagrama de interacción.

Los patrones de diseño son útiles para asignar responsabilidades correctamente.

Las tarjetas CRC permiten documentar las clases y sus colaboradoras mas cercanas.

05 modelo de diseño

Documents

Transcript of 05 modelo de diseño