UTN-FRT. Cátedra de Diseño de Sistemas. 3K1. 2011. Del Análisis al Diseño. Diagramas de Secuencia. Contratos. Craig Larman

1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)

2. Contenidos de la Unidad 1 Introducción al Diseño 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.1 Sommerville. 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.14 Larman, 2ª. Ed., Cap. 1.4 Pressman, Cap.21 y 22 VI. Modelos de dominio, Casos de Uso. (revisión) Larman, 1ª. Ed.,Cap. 9/11 Larman, 2a. Ed. Cap. 9/11 VII. Del Análisis al Diseño Larma n, 1ª. Ed. Caps. 13/14 Larman, 2ª. Ed. Cap. 14

3. DIAGRAMAS DE SECUENCIA Craig Larman (Cap. 13) Ingeniería en Sistemas de Información DISEÑO DE SISTEMAS

4. DISEÑ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 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.

5. DISEÑO DE SISTEMAS Diagramas de Secuencia 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 SISTEMA DIAGRAMA DE SECUENCIA DEL SISTEMA 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.

6. DISEÑO DE SISTEMAS Diagramas de Secuencia 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 SECUENCIA => Re presentación que muestra, en un determinado Caso de Uso , los eventos generados por actores externos , su orden y los eventos internos del sistema.

7. DISEÑO DE SISTEMAS Diagramas de Secuencia 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 sistema 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.

8. DISEÑO DE SISTEMAS Diagramas de Secuencia 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 .

9. DISEÑO DE SISTEMAS Diagramas de Secuencia 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 , e tc Puede tomarse del caso de uso. Evento del sistema. Inicia una operación del sistema.

10. Evento de un Sistema => Hecho Externo de Entrada , que un actor produce en un sistema. Origina una Operación de Repuesta . DISEÑO DE SISTEMAS Diagramas de Secuencia Operación de un Sistema => Acción que éste ejecuta en repuesta a un Evento del Sistema . EVENTOS Y OPERACIONES DE UN SISTEMA 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.

11. DISEÑO DE SISTEMAS Diagramas de Secuencia Los eventos del sistema inician las operaciones del mismo Cajero : Sistema CASO DE USO: Comprar productos introducirProducto (CUP, cant) Evento del sistema. “ IntroducirProducto”. Inicia una operación del Sistema del mismo nombre “ IntroducirProducto”.

12. DISEÑO DE SISTEMAS Diagramas de Secuencia Registro 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?.

13. DISEÑO DE SISTEMAS Diagramas de Secuencia Notaciones de las operaciones en UML Las operaciones se agrupan como del tipo « Sistema» . Los parámetros son opcionales: pueden incluírse o no TipoX Operacion1() Operacion2()

14. DISEÑO DE SISTEMAS Diagramas de Secuencia Operaciones del sistema registradas en el tipo Sistema 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” ). Sistema terminarVenta() introducirProducto() efectuarPago()

17. DISEÑO DE SISTEMAS Diagramas de Secuencia Para identificar los eventos de un sistema debemos tener una idea clara de su frontera . EVENTOS Y FRONTERAS DE UN SISTEMA 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:

18. DISEÑO DE SISTEMAS Diagramas de Secuencia 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 .

19. DISEÑO DE SISTEMAS Diagramas de Secuencia Cajero :Sistema Comprar productos introducirProducto (CUP, cant) terminarVenta() efectuarPago (monto) Frontera del Sistema

20. DISEÑO DE SISTEMAS Diagramas de Secuencia Asignación de nombre a los eventos y a las operaciones de 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.

21. DISEÑO DE SISTEMAS Diagramas de Secuencia Escoja los nombres de los eventos y de las operaciones en un nivel abstracto Cajero :Sistema introducirProducto (CUP, cant) introducirTeclaOprimida(CUP, cant) Nombre más idóneo Nombre menos idóneo

22. DISEÑO DE SISTEMAS Diagramas de Secuencia “ t erminarVenta ” es preferible a “ introducirTeclaOprimida ” 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

23. DISEÑO DE SISTEMAS Diagramas de Secuencia Presentación del texto del caso 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 introducirProducto (CUP, cant) terminarVenta() efectuarPago (monto) 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.

24. CONTRATOS Craig Larman (Cap. 14) Ingeniería en Sistemas de Información DISEÑO DE SISTEMAS

25. DISEÑO DE SISTEMAS Contratos Actividades 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 .

26. DISEÑO DE SISTEMAS Contratos 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 que 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 SISTEMA

27. DISEÑO DE SISTEMAS Contratos CONTRATOS 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 . Contrato => 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 .

28. DISEÑO DE SISTEMAS Contratos 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.

29. DISEÑO DE SISTEMAS Contratos Ejemplo de Contrato para la Operación: introducirProducto 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. Referencias Cruzadas Funciones del sistema. R1.1, R1.3,.... Casos de uso: Comprar productos. Notas Utilizar el acceso super rápido a la Base de Datos. Excepciones Si el CUP no es válido, indicar que se cometió un error. Salida

30. DISEÑO DE SISTEMAS 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).

31. DISEÑO DE SISTEMAS Contratos Secciones 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.

32. DISEÑO DE SISTEMAS Contratos Tipo: Nombre del tipo (concepto, clase de software, interfaz). Referencias Cruzadas 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. Salida Mensajes 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.

36. DISEÑO DE SISTEMAS introducirProducto(CUP,Cantida d) 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ón IntroducirProducto Postcondiciones: 1. Si se trata de una nueva venta, fue creada una nueva Venta .... Caso de Uso Diagrama de Secuencia Operaciones del Sistema Contratos

37. DISEÑO DE SISTEMAS Contratos 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. POSTCONDICIONES 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:

38. DISEÑO DE SISTEMAS Contratos 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 .

39. DISEÑO DE SISTEMAS Contratos 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 Conceptual

40. DISEÑO DE SISTEMAS Contratos 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 Postcondiciones El espíritu de las Postcondiciones: el Escenario y el Telón Las Postcondiciones deberían describir el estado de un Sistema, no las acciones a realizar.

41. DISEÑO DE SISTEMAS Contratos 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.

42. DISEÑO DE SISTEMAS Contratos 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. C ompare las fotografías de antes y después, y exprese como poscondiciones los cambios del estado del escenario (Se creó la instancia VentasLineadeProducto).

43. DISEÑO DE SISTEMAS Contratos 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 poscondiciones?

46. DISEÑO DE SISTEMAS 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.

47. DISEÑO DE SISTEMAS 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.

49. DISEÑO DE SISTEMAS 1) Diagrama de la secuencia para el caso de uso Alquiler de Video . Cajero :Sistema introducirSocio (codigo) terminarTransacción() efectuarPago (monto) 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...

50. DISEÑO DE SISTEMAS 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. Referencias Cruzadas 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.