Del análisis al diseño. diagramas de secuencia y contratos

Ingeniería en Sistemas de Información

Diseño de Sistemas(3K1)

f) Ingeniería del Software Asistida por Computadora. Clasificación de CASE

Sommerville. Sección 4.5

C. Proceso de Diseño Pressman. Cap. 13.2 Introducción.

I. Fases del diseño. Pressman. Sección 13.1Sommerville. Sección 4.3.2

II. Diseño y calidad del software Pressman. 13.2.1

III. Principios y conceptos del diseño. Pressman. Sección 13.3 y 13.4

IV. Documentación del Diseño. Pressman, Sección 13.8

V. Análisis y Diseño Orientado a Objetos Sommerville, Cap.14Larman, 2ª. Ed., Cap. 1.4Pressman, Cap.21 y 22

VI. Modelos de dominio, Casos de Uso. (revisión)

Larman, 1ª. Ed.,Cap. 9/11Larman, 2a. Ed. Cap. 9/11

VII. Del Análisis al Diseño Larman, 1ª. Ed. Caps. 13/14 Larman, 2ª. Ed. Cap. 14

Contenidos de la Unidad 1Introducción al Diseño

DIAGRAMAS DE DIAGRAMAS DE SECUENCIASECUENCIA

Craig Larman (Cap. Craig Larman (Cap. 13)13)


DISEÑO DE SISTEMASDISEÑO DE SISTEMAS


El Diagrama de Secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores al sistema. Su creación forma parte de la investigación para conocer el sistema; se incluye dentro de la etapa del análisis.

En UML los Diagrama de Secuencia muestran gráficamente los eventos que pasan de los actores al sistema. Actividades y dependenciasActividades y dependencias

Los Diagramas de Secuencia de un sistema se preparan durante la fase del análisis. Para su creación, debemos formular antes los Casos de Uso.


Diagramas de Diagramas de SecuenciaSecuencia

Antes de iniciar el diseño lógico de cómo funcionará una aplicación de software, es necesario investigar y definir su comportamiento como una “caja negra”. El comportamiento del sistema es una descripción de lo que hace, sin explicar la manera en que lo hace. Una parte de la descripción es un Diagrama de la Secuencia del sistema.

COMPORTAMIENTO DEL COMPORTAMIENTO DEL SISTEMASISTEMA

DIAGRAMA DE SECUENCIA DEL DIAGRAMA DE SECUENCIA DEL SISTEMASISTEMA Los casos de uso indican cómo los actores interactúan con el Sistema de Software. Durante esa interacción un actor genera eventos dirigidos al sistema, solicitando alguna operación a cambio.



Conviene aislar y explicar gráficamente las operaciones que un actor solicita al sistema, porque ello contribuye a entender el comportamiento del sistema.

En UML los Diagramas de Secuencia dan una descripción gráfica de las interacciones del actor y de las operaciones que las mismas originan.

DIAGRAMA DE SECUENCIADIAGRAMA DE SECUENCIA => Representación que muestra, en un determinado Caso de Uso, los eventos generados por actores externos, su orden y los eventos internos del sistema.



A todos los sistemas se los trata como una caja negra; los diagramas se centran en los eventos que trascienden las fronteras del sistema y que fluyen desde los actores hacia los sistemas. El Diagrama de Secuencia debe prepararse para el curso normal de los eventos de un caso de uso y los cursos opcionales más interesantes.

Ejemplo de un Diagrama de la Secuencia de un Ejemplo de un Diagrama de la Secuencia de un sistemasistema El Diagrama de la Secuencia de un sistema describe, en el curso de los eventos de un caso de uso, los actores externos que interactúan directamente con el sistema (caja negra) y con los eventos del sistema generados por esos actores.



En el diagrama el tiempo avanza hacia abajo, y el orden de los eventos sigue el orden indicado en el caso de uso.

Los eventos del sistema pueden incluir parámetros

Ejemplo => curso normal de los eventos en el caso Comprar Productos. El cajero es el único actor en el sistema de CAJA y genera los eventos del sistema introducirProducto, terminarVenta y efectuarPago.



Sistema como caja negra

Cajero

Actor

:Sistema

CASO DE USO: Comprar productos

introducirProducto (CUP, cant)

terminarVenta()

efectuarPago (monto)

Repetir hasta que no haya más productos.

Texto que aclara el control, la lógica, la iteración, etcPuede tomarse del caso de uso. Evento del sistema. Inicia

una operación del sistema.

Evento de un Sistema => Hecho Externo de Entrada, que un actor produce en un sistema. Origina una Operación de Repuesta.



Operación de un Sistema => Acción que éste ejecuta en repuesta a un Evento del Sistema.

EVENTOS Y OPERACIONES DE UN EVENTOS Y OPERACIONES DE UN SISTEMASISTEMA

Por ejemplo, cuando el cajero genera el evento IntroducirProducto, causa la ejecución de la operación introducirProducto; el nombre del evento y de la operación son idénticos; la distinción reside en que el evento es el estímulo nombrado y la operación es la respuesta.



Cajero :Sistema

CASO DE USO: Comprar productos


Evento del sistema.“IntroducirProducto”.Inicia una operación del Sistema del mismo nombre “IntroducirProducto”.

Los eventos del sistema inician las operaciones del mismo



Registro de las operaciones de un sistemaRegistro de las operaciones de un sistema

Para determinar el conjunto de las operaciones requeridas del sistema, se identifican previamente sus eventos correlativos. Si utilizamos parámetros, las operaciones son las siguientes:

IntroducirProducto (Cod, cantidad)

TerminarVenta()

EfectuarPago(monto)

¿Cómo se registran estas operaciones en el lenguaje UML?.



TipoX

Operacion1()Operacion2()

Notaciones de las operaciones en UML

Las operaciones se agrupan como del tipo «Sistema».

Los parámetros son opcionales: pueden incluírse o no



Operaciones del sistema registradas en el tipo Sistema

Sistema

terminarVenta()introducirProducto()efectuarPago()

La representación del tipo Sistema es diferente a lo que se expresó en el Modelo Conceptual. Los elementos del Modelo Conceptual representan Conceptos del Mundo Real; en cambio, el tipo Sistema es un Concepto Artificial. El tipo Sistema => muestra las operaciones, cosa totalmente nueva. Pues => estamos describiendo el comportamiento del sistema.El tipo Sistema => es información dinámica (distinto al Modelo Conceptual, que representa información “estática”).


Diagramas de Diagramas de SecuenciaSecuenciaComo elaborar un diagrama de Como elaborar un diagrama de

secuenciasecuencia Para elaborar diagramas de Secuencia de un sistema que describan el curso normal de los eventos en un caso de uso Aplique los siguientes Aplique los siguientes pasospasos:

1. Trace una línea que represente el sistema como una caja negra.

2. Identifique los actores que operan directamente sobre el sistema. Trace una línea para cada uno de ellos.

3. A partir del curso normal de los eventos del caso de uso identifique los eventos (“externos”) del sistema (que son generados por los actores). Muéstrelos gráficamente en el diagrama.

4. A la izquierda del diagrama puede incluir o no el texto del caso de uso.



Ejemplo:Ejemplo:

Cajero

:Sistema

Comprar productos


terminarVenta()


CASO DE USO:COMPRAR PRODUCTOSCurso normal de los eventos:1. Este caso de uso comienza

cuando un cliente llega a una CAJA con productos que desea comprar.

2. El cajero registra el código universal del producto (CUP) de cada producto. Si hay mas de uno del mismo producto, también se puede capturar la cantidad.

3. El sistema determina el precio del producto y agrega la información sobre el producto a la transacción actual de ventas. Se muestran la descripción y el precio del producto actual.

4. Y así sucesivamente.Los diagramas de secuencia de un sistema surgen de los casos de uso



Para identificar los eventos de un sistema debemos tener una idea clara de su frontera.

EVENTOS Y FRONTERAS DE UN EVENTOS Y FRONTERAS DE UN SISTEMASISTEMA

La frontera de un sistema se selecciona en función del sistema de software (y también del hardware). Un evento del sistema es un hecho externo que estimula directamente el software.

En el caso de uso ComprarProductos identificamos los eventos del sistema:



Primero debemos determinar los actores que interactúan directamente con el sistema.

El Cliente interactúa con el Cajero, pero no directamente con el Sistema de CAJA; ésto sólo lo hace el Cajero. Por tanto, el Cliente no es un generador de eventos del sistema; sólo el Cajero lo es.



Cajero

:Sistema

Comprar productos


terminarVenta()


Frontera del Sistema



Asignación de nombre a los Asignación de nombre a los eventos y a las operaciones eventos y a las operaciones de un sistemade un sistema

Los eventos (y sus operaciones asociadas) deben expresarse como propósitos y no según el medio físico de entrada que se utilice.

Es mejor que el nombre de un evento comience con un verbo (agregar..., introducir ..., terminar ..., efectuar ...), porque recalca que los eventos están orientados a comandos.



Cajero :Sistema


introducirTeclaOprimida(CUP, cant)

Nombre más idóneo

Nombre menos idóneo

Escoja los nombres de los eventos y de las operaciones en un nivel abstracto



“terminarVentaerminarVenta” es preferible a “introducirTeclaOprimidaintroducirTeclaOprimida” porque capta mejor el propósito de la operación: mantiene un carácter abstracto y no se pronuncia sobre las decisiones de diseño sobre cuál interfaz sirve para capturar el evento del sistema.

En cuanto a expresar las operaciones en el nivel de propósito, procure alcanzar el nivel más alto o la meta final de asignar nombre a la operación.

Por ejemplo, respecto a la operación que captura el pago:

introducirImporteOfrecido deficiente

introducirPago(monto) mejor



Presentación del texto del Presentación del texto del caso de usocaso de uso A veces conviene mostrar fragmentos del texto del caso de uso dentro del diagrama de secuencia para describir gráficamente la estrecha relación entre ambos artefactos.

Cajero :Sistema


terminarVenta()


En todos los productos, el Cajero registra el código y la cantidad. Al terminar de capturar el producto, el Cajero indica a la CAJA que la venta concluyó.El Cajero le indica el total al Cliente, y éste le dá un pago.El Cajero registra el importe recibido.

CONTRATOSCONTRATOS

Craig Larman (Cap. Craig Larman (Cap. 14)14)




ContratosContratos

Actividades y dependenciasActividades y dependencias

Los Contratos contribuyen al definir el comportamiento de un Sistema: describen el efecto que sobre él tienen las operaciones.

El lenguaje UML ofrece un soporte para describir estos «Contratos».

Los Contratos de las Operaciones del Sistema se elaboran durante la fase de Análisis. Su preparación depende de contar antes con el Modelo Conceptual, de los Diagramas de Secuencia del Sistema y la identificación de sus Operaciones.


ContratosContratos

Antes de emprender el diseño lógico de cómo funcionará una aplicación de software, es necesario investigar y definir su comportamiento como una “caja negra”.

El comportamiento del sistema es una descripción de lo queque hace, sin explicar la manera que (cómo) lo hace.

Los contratos son documentos muy útiles, que describen el comportamiento de un sistema a partir de cómo cambia el estado de un sistema cuando se llama una operación suya.

COMPORTAMIENTO DEL COMPORTAMIENTO DEL SISTEMASISTEMA


ContratosContratos

CONTRATOSCONTRATOS

El Diagrama de Secuencia de un sistema muestra los eventos generados por un actor externo, pero no profundiza en los detalles del funcionamiento de las operaciones invocadas. No contiene los detalles necesarios para entender la respuesta del sistema, o sea su comportamiento. ContratoContrato => Documento que describe lo que una operación propone lograr. Se redacta en estilo declarativo, enfatizando lo que sucederá y no cómo se conseguirá. Los contratos suelen expresarse a partir de los cambios de estado de las poscondiciones.


ContratosContratos

El Contrato describe los cambios del estado del sistema total cuando se invoca a una de sus operaciones.

Las operaciones del sistema requieren las descripciones del contrato

Sistema

introducirProducto()terminarVenta()efectuarPago ()

Se redactan contratos para cada operación del sistema, con el fin de describir su comportamiento.


ContratosContratos

Nombre:

introducirProducto (cup: número cant: entero)

Responsabilidades:

Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar la descripción y el precio del producto.

Tipo: Sistema.

ReferenciasCruzadas

Funciones del sistema.R1.1, R1.3,....Casos de uso: Comprar productos.

Notas Utilizar el acceso super rápido a la Base de Datos.

ExcepcionesSi el CUP no es válido, indicar que se cometió un error.

Salida

Ejemplo de Contrato para la Operación: introducirProductoEjemplo de Contrato para la Operación: introducirProducto


Precondiciones El sistema conoce el CUP.

Postcondiciones:

· Si se trata de una nueva venta, se creó una Venta (creación de instancia).· Si se trata de una nueva venta, la nueva Venta fue asociada a TPDV (asociación formada).· Se creó una instancia VentasLineasdeProductos (creación de una instancia).· Se asoció una instancia VentasLineasdeProductos a la Venta (asociación formada).· Se asignó cantidad a VentasLineadeProducto.cantidad (modificación de atributo).· Se asoció una instancia VentasLineadeProducto a la instancia EspecificacióndeProducto, basado esto en la correspondencia del CUP (asociación formada).


ContratosContratos

Secciones del ContratoSecciones del Contrato

No todas las secciones son necesarias; se recomiendan las de Responsabilidades y

Poscondiciones.

Nombre: Nombre de la Operación y Parámetros.

Responsabilidades:

Descripción informal de las responsabilidades (objetivos o propósitos) que debe cumplir la operación.


ContratosContratos

Tipo:Nombre del tipo (concepto, clase de software, interfaz).

ReferenciasCruzadas

Número de referencia de las funciones del sistema, casos de uso, etc.

Notas Notas de diseño, algoritmos e información afín.

Excepciones Casos excepcionales.

SalidaMensajes o registros que se envían afuera del sistema.

Precondiciones:

Suposiciones acerca del estado del sistema antes de ejecutar la operación.

Postcondiciones: El estado del sistema después de la operación.


ContratosContratos

Como preparar un Como preparar un contratocontrato Para preparar un contrato en los casos de uso: => Aplique los siguientes pasos:

1. Identifique las operaciones del sistema a partir de los diagramas de sus secuencia.

2. Elabore un contrato en cada operación del sistema.

3. Comience redactando la sección de Responsabilidades; después describa informalmente el propósito de la operación.


ContratosContratos

4. Complete luego la sección de Poscondiciones, describiendo en forma declarativa los cambios de estado de los objetos en el modelo conceptual.

5. Para describir las poscondiciones utilice las siguientes categorías:

Creación y eliminación de las instancias.

Modificación de los atributos.

Asociaciones formadas y canceladas.


ContratosContratos

Contratos y otros artefactosContratos y otros artefactos

• Los casos de uso sugieren los diagramas de eventos y de secuencia del sistema.

• Después se identifican las operaciones del sistema.

• El efecto de las operaciones del sistema se describe en los contratos.


introducirProducto(CUP,Cantidad)

CASO DE USO: COMPRAR

PRODUCTOS

Curso normal de los eventos

1. Este caso de uso comienza ...

Cajero Sistema

terminarVenta()

efectuarPago(monto)

Sistema

introducirProducto() terminarVenta()

efectuarPago()

OperaciónIntroducirProducto

Postcondiciones:1. Si se trata de una nueva venta, fue creada una nueva Venta ....

Caso de Uso Diagrama de Secuencia

Operaciones del Sistema

Contratos


ContratosContratos

Después de la sección de Responsabilidades, la parte mas importante del contrato son las Postcondiciones, que estipula como cambió el sistema tras esta operación.

POSTCONDICIONESPOSTCONDICIONES

No son acciones que deben efectuarse durante la operación; sino declaraciones sobre el estado del sistema que se aplican una vez concluida la operación, es decir, una vez que el humo se ha disipado. Se aconseja expresar las Postcondiciones de esta manera en UML:


ContratosContratos

Categorías útiles que deben contemplarse en las Postcondiciones del Contrato:

Creación y eliminación de las instancias.

Modificación de los atributos.

Asociación formadas y canceladas.

Lo importante es adoptar una actitud declarativa, orientada al cambio de estado y no a la acción.

Las Postcondiciones deberían ser declaraciones sobre los estados o resultados, no una descripción de acciones a realizar.


ContratosContratos

Las Postcondiciones se expresan dentro del contexto del Modelo Conceptual.

* ¿Qué instancias es posible crear?

La Respuesta es: las provenientes del Modelo Conceptual.

* ¿Qué asociaciones es posible formar?

La Respuesta es: las que están en el Modelo Conceptual.

Las Postcondiciones se relacionan con el Modelo Las Postcondiciones se relacionan con el Modelo ConceptualConceptual


ContratosContratos

El Contrato constituye una excelente herramienta de investigación: permite describir los cambios necesarios para que el sistema funcione sin necesidad de describir cómo se logran.

En otras palabras, podemos postponer el diseño y la solución del software y concentrarnos analíticamente en lo que debe suceder, no en la manera de conseguirlo.

Ventaja de las Ventaja de las PostcondicionesPostcondiciones

El espíritu de las El espíritu de las Postcondiciones: Postcondiciones: el el Escenario y el TelónEscenario y el Telón Las Postcondiciones deberían describir el estado de un Sistema, no las acciones a realizar.


ContratosContratos

Expréselas en tiempo pasado para enfatizar que se trata de declaraciones sobre un cambio pretérito de estado. Por ejemplo:

Se creó una instancia VentasLineadeProducto (mejor)

en lugar de

Crear una instancia VentasLineadeProducto (peor) Reflexione sobre las Postcondiciones sirviéndose de la siguiente imagen:

El sistema y sus objetos se presentan en el escenario de un teatro.


ContratosContratos

1. Tome una fotografía del escenario antes de la operación.

2. Corra el telón del escenario y aplique la operación del sistema (ruido de fondo con sonidos metálicos, gritos, chillidos).

3. Corra el telón y tome una segunda fotografía.

4. Compare las fotografías de antes y después, y exprese como poscondiciones los cambios del estado del escenario (Se creó la instancia VentasLineadeProducto).


ContratosContratos

En la fase de Análisis no es probable (ni necesario) generar un grupo de Postcondiciones completas y exactas de la Operación del sistema.

Su elaboración es la conjetura inicial más acertada, y conviene intentarlo, durante el Análisis, aún sabiendo que los Contratos estarán incompletos.

Esta creación temprana (e incompleta) es sin duda, preferible a posponer la investigación hasta el Diseño; cuando los creadores se concentrarán en el diseño de una solución, más que en averiguar lo que debe hacerse.

¿Cuán completas deben ser las ¿Cuán completas deben ser las poscondiciones?poscondiciones?


ContratosContratos

Las Precondiciones definen las suposiciones sobre el estado del Sistema al iniciarse la Operación.

PRECONDICIONESPRECONDICIONES

Hay muchas Precondiciones que pueden declararse en una Operación, pero la experiencia revela que vale la pena mencionar las siguientes: • Cosas que son importantes probar en el software en algún momento de la ejecución de la operación.

• Cosas que no serán sometidas a prueba, pero de las cuales depende el éxito de la operación.


EJEMPLO PRÁCTICO:EJEMPLO PRÁCTICO:

Para el caso del Videoclub se realizarán estas tareas:

1. Por cada Curso Normal de Eventos, se realizará el correspondiente Diagrama de Secuencia.

2. A partir de los Diagramas de Secuencia, se identificarán a las Operaciones del Sistema y se confeccionará un Contrato.


Caso de Uso: Alquiler de Video

Actores: Empleado (Iniciador)

Propósito: Dejar registrado que un socio alquiló X película.

Resumen: : Un socio llega a la CAJA con los videos que quiere alquilar. El Empleado ingresa los videos y cobra el importe. Al terminar la operación, el socio se marcha con los videos y el comprobante.

Tipo: Primario y Esencial.

Referencias Cruzadas: Funciones: R1.1., R1.2., R1.3.,

R1.6., R1.7.


Curso normal de los eventos:

Acción del actor Respuesta del sistema

1. Este caso de uso comienza cuando un Socio llega a la caja con videos para alquilar.

2. El Empleado introduce el código del Socio.

3. Completa el nombre y domicilio del socio. Informa de multas pendientes.

4. El Empleado captura el código de video de cada video.

5. Confirma el precio del video y agrega el título de éste a la transacción.

6. El Socio confirma que no quiere mas videos.


7. El Empleado le indica al sistema que no se cargarán más videos.

8. Calcula el total y registra el alquiler.

9. El Socio ofrece un pago quizás mayor que el total.

10. El empleado ingresa el monto ofrecido.

12. El Socio recibe los videos, el ticket y se retira.

Curso alterno de los eventos: •Línea 2: El Cliente no es socio. Error. Ver Caso de Uso: Alta de Socio.

•Línea 3: El Socio tiene una multa no pagada. Ver Caso de Uso: Multas.

•Línea 4: Código de video inexistente. Indicar Error. •Línea 8: El Cliente no tiene el dinero necesario para pagar.

Se cancela la operación.

11. Calcula el saldo, registra el pago y emite el ticket.


1) Diagrama de la secuencia para el caso de uso Alquiler de Video.

Cajero

:Sistema

introducirSocio (codigo)

terminarTransacción()


introducirVideo (codigo)

Caso de Uso: Alquiler de Video

Curso Normal de los eventos

1. Este caso de uso comienza cuando un Socio llega a la caja con videos para alquilar.

2. El Empleado ingresa el código del Socio.

3. Completa el nombre y domicilio del socio. Informa de multas pendientes.

4. El Empleado ingresa el código cada video.

5. Confirma el precio del video y agrega el título de éste a la transacción.

6. Y así sucesivamente...


2) Contrato para introducirVideo

Nombre: introducirVideo (codigo: número)

Resposabilidades:

Capturar (registrar) el alquiler de un video y agregarlo al alquiler. Desplegar el título y el precio del video.

Tipo: Sistema.

ReferenciasCruzadas

Funciones del sistema: R1.1, R1.3,....Casos de uso: Alquiler de Videos.

Notas Utilizar el acceso super rápido a la Base de Datos.


ExcepcionesSi el código no es válido, indicar que se cometió un error.

Salida Precondicion

es El sistema conoce el código de video.

Postcondiciones:

• Se creó una instancia AlquilerLineadeVideo (creación de una instancia).

• Se asoció una instancia AlquilerLineasdeVideo al Alquiler (asociación formada).

• Se asoció una instancia AlquilerLineadeVideo a la instancia EspecificacióndeVideo, basado ésto en la correspondencia del código (asociación formada).

• Se modificó el atributo Video.Estado = alquilado (modificación de atributo)

Documents

Del análisis al diseño. diagramas de secuencia y contratos