Programación Avanzada. Análisis Especificación del Comportamiento del Sistema

Documentos relacionados
Análisis Especificación del Comportamiento del Sistema

Desarrollo Orientado a Objetos basado en UML

Programación Avanzada. Desarrollo Orientado a Objetos basado en UML

UML (Unified Modeling Language) Octubre de 2007

Programación Avanzada. Requerimientos de Software

Caso de Uso. Herramienta de relevamiento. domingo, 28 de octubre de 12

Requerimientos de Software

Unified modeling language

Ingeniería de requerimientos de software: Análisis. Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes

Modelado Estructural F E B R E R O,

Diagramas de interacción

Especificación de Requerimientos <Nombre del Proyecto> Nombre del Grupo de Desarrollo o Asignatura Nombre del Autor

UNIÓN INTERNACIONAL DE TELECOMUNICACIONES RED DIGITAL DE SERVICIOS INTEGRADOS (RDSI) ESTRUCTURA GENERALES

MODULO IV. Análisis y Diseño de Sistemas de Información INF-162 IV. UML. Casos de uso. Facilitador: Miguel Cotaña

Diseño. Diseño. Interacción. Aspectos comunes en interacción. Diagramas de Interacción. Curso de Arquitecturas de Software

1. Propósito. Establecer los puntos que debe cubrir como referencia documental mínima un documento de Diseño de sistemas automatizados.

Programación Orientada a Objetos

Cristian Blanco

Sistema de Administración de Farmacias Modelo de Diseño Versión 1.0. Historia de revisiones

CLASE 4: CASOS DE USO REQUERIMIENTOS. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Martínez

12/08/2017. Casos de uso. Casos de uso. Casos de uso. Casos de uso

diagramas de comportamiento con UML.

Unidad IV: Modelo de Diseño 4.1. Estrategias de diseño

INGENIERÍA DEL SOFTWARE

Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Modelado - Vocabulario del Sistema

Generación Parcial de Código

Programación 4 CASO DE ESTUDIO :: ANÁLISIS

Modelo de Casos de Uso

12/08/2017. Diagrama de secuencia. Diagrama de secuencia. Diagrama de secuencia. Diagrama de secuencia

Tema 2. Casos de Uso C H R I STO PHER E X P Ó S I TO I Z Q U I ERDO A I R A M E X P Ó S I TO M Á R Q UEZ I S R A E L LÓ P EZ P L ATA M A R Í A B E L

Instrucción 1. Criterios, Convenciones y recomendaciones para utilizar este instructivo

Diagramas De Casos De Uso

Programación Avanzada. Diseño Diagramas de Comunicación

Metodologías de Diseño. Diseño Diagramas de Colaboración

UML Unifield Modeling Languaje

Diagramas de secuencia

Uso de Metodología ICONIX

Unidad V. UML. Tema I. Conceptos Básicos Tema II. Definición de UML. Vocabulario Tema III. Elementos UML Tema IV. Diagramas.

! Qué es la POO?! Un paradigma de programación. ! No hay paradigmas mejores ni peores! Todos tienen sus ventajas e inconvenientes

Diagramas UML JUAN CARLOS CONDE RAMÍREZ INTRODUCTION TO PROGRAMMING

Programación 4. Diseño Criterios de Asignación de Responsabilidades GRASP

PRESENTACIÓN TRABAJO FIN DE GRADO

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7, SECCIÓN 1: REQUISITOS SOFTWARE

Programación 4. Diseño Diagramas de Comunicación

Lenguaje Unificado de Modelado

Comunicación entre objetos. A continuación mencionaremos los objetos Web y de qué manera interactúan entre ellos.

CLASE 9: DISEÑO CON PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez

Capítulo 16. Diagrama de Clases UML

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 1

INTRODUCCIÓN A LA NOTACIÓN UML Diagramas de clases

Unidad IV. Este tipo de codificación nos es permitido gracias a la sobrecarga, la cual se aplica a métodos y constructores.

Comunicación entre objetos

Ingeniería de Software

DIAGRAMAS UML ANDRÉS ESTEBAN MARTÍNEZ HUTA CICLO DE VIDA DEL SOFTWARE GLORIA CECILIA RÍOS MUÑOZ

T3-Análisis y Diseño del Sistema Software

Diagramas de Secuencia

DIAGRAMAS DE CLASES. Clases, asociaciones y atributos. Interfaces con sus operaciones y constantes. Información acerca del tipo de los atributos.

Tecnología de Programación

Guía práctica de estudio 09: UML

Lenguajes de Programación

Elementos Diagramas de Clases Clase:

Empleado. Departamento

Requerimientos de Software

la cual es usada también por el terapeuta en cual asiste al paciente al utilizar ésta, dando así

Objetos de Flujo. Actividades

Modelado Estático Básico. Diseño de Software Avanzado Departamento de Informática

4/15/2010. Requerimientos de Software UARG.UNPA Requerimientos de Software. Requerimientos de Software

Ejercicio de Programación Orientada a Objetos Curso 2016/2017 Exámenes

Registrar información o datos de una persona REQUERIMIENTO QUE LO UTILIZA O ESPECIALIZA:

UNT INGENIERIA INDUSTRIAL INGENIERIA DE SOFTWARE

Applying UML and paterns (Capítulos 8, 9 y 10)

6.3 EDIFICACIÓN. [Proceso]

Pruebas de Software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Análisis y Diseño de Sistemas

Programación Avanzada CONCEPTOS BÁSICOS DE IMPLEMENTACIÓN EN C++

Published on Marco de Desarrollo de la Junta de Andalucía (

Análisis y Diseño del Software. El Lenguaje Unificado de Modelado UML 2.0

Ingeniería de Requisitos

CC Taller de UML Apuntes de Clase. Prof. Andrés Muñoz Ordenes 9 de mayo de 2012

UNIDAD 2: INTRODUCCION AL PARADIGMA ORIENTADO A OBJETOS. MODELADO DE OBJETOS USANDO DIAGRAMA DE CLASES

CLASE 7: ARQUITECTURA: DEL ANÁLISIS AL DISEÑO DIAGRAMAS DE SECUENCIA Y CONTRATOS

Especificación de requisitos de software. Proyecto: [Nombre del proyecto] Revisión [99.99] [Mes de año]

UML - Diagramas de interacción de Objetos

Proceso Unificado de Desarrollo de Software. 13 de sep de 2006

Contenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo

obtenidos a partir de los objetos que manipula. un nuevo paradigma de programación, La POO es Clases su forma de módulo.

Análisis y Diseño de Sistemas

MODELO DE REQUISITOS

Bases de datos 1. Teórico: Diseño Conceptual

BASES DE DATOS 1. Teórico: Diseño Conceptual

CLASE 9: DISEÑO CON PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez

DIAGRAMAS DE CASOS DE USO. Prof. Hooberth Chávez Bedoya

Diagramas de clases del diseño

Capítulos 2 y 5: Modelación con UML y Modelo Objeto

CLASE 3: UML DIAGRAMAS CASOS DE USO. Universidad Simón Bolívar. Ingeniería de Software. Prof. Ivette Martínez

2.5 DISEÑO ARQUITECTONICO

Bloque 1. Conceptos y técnicas básicas en programación

Capítulo 5. Diseño del Sistema

Transcripción:

Programación Avanzada Análisis Especificación del Comportamiento del Sistema

Contenido Introducción Modelo de Casos de Uso La Clase Sistema Interacciones con el Sistema Contratos de Software Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 2

Introducción Durante esta actividad de análisis se busca describir en forma precisa cuál debe ser el comportamiento esperado del sistema Se trabaja sobre el Modelo de Casos de Uso Viendo al sistema como una unidad Se definen protocolos que caractericen el uso del sistema por parte de los actores en cada escenario de los casos de uso El comportamiento completo del sistema es especificado al especificar cada mensaje de los protocolos Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 3

Introducción (2) Cada escenario de los casos de uso a analizar es entendido en términos de una interacción entre los actores involucrados y el sistema Al describir el significado de cada uno de los mensajes identificados en cada interacción se está especificando el comportamiento del sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 4

Introducción (3) Nos enfocamos en qué es lo que debe hacer el sistema ante cada mensaje La forma en cómo el sistema resuelve internamente un mensaje será definida durante la etapa de diseño Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 5

Modelo de Casos de Uso Contenido: Introducción Breve descripción textual que sirve como introducción al modelo Relevamiento de funcionalidades Descripción textual de información no reflejada en el resto del modelo, por ejemplo: Secuencias típicas en que los casos de uso son utilizados por los usuarios Otras funcionalidades no capturadas en los casos de uso Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 6

Modelo de Casos de Uso (2) Contenido (cont.) Actores Todos los actores detectados para el sistema Casos de uso Todos los casos de uso definidos Relaciones Todas las asociaciones entre actores y CU Comportamiento Especificación del comportamiento de cada caso de uso en el modelo, el cual está definido por: Eventos del Sistema y Contratos de Software Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 7

La Clase Sistema Durante esta actividad el sistema será considerado como un objeto: Que es instancia de una clase Sistema Que tiene operaciones (puede recibir mensajes) Que tiene un estado En todo Modelo de Casos de Uso se asume que existe una clase Sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 8

La Clase Sistema (2) Existe una única instancia de esta clase la cual representa al sistema entero Sistema : Sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 9

La Clase Sistema (3) Las operaciones de esta clase permiten que el sistema reciba mensajes de los actores: Se identifican al definir los protocolos que representan los escenarios de los diferentes casos de uso Durante el análisis no se busca diseñarlas Su semántica es definida en términos del efecto que deben tener sobre el estado del sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 10

La Clase Sistema (4) Un actor puede enviar mensajes al sistema invocando sus operaciones Sistema iniciarventa() agregarproducto() terminarventa() realizarpago() iniciarventa : Sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 11

La Clase Sistema (5) En esta actividad el estado del sistema se asume como una configuración de objetos válida respecto al Modelo de Dominio : Sistema : Producto : EspProd : Venta : Producto : Producto : EspProd : Venta Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 12

La Clase Sistema (6) Dado que no todos los actores participan en todos los casos de uso la visibilidad sobre las operaciones del sistema debe ser limitada Por tanto la clase sistema podría realizar diferentes interfaces Cada interfaz contendría las operaciones utilizadas en un (conjunto de) caso(s) de uso Las operaciones se encontrarían organizadas y los actores verían al sistema a través de la(s) interface(s) que le corresponde(n) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 13

La Clase Sistema (7) El actor Cajero usará al sistema solamente a través de esta interfaz «interface» RealizarVenta iniciarventa() agragarproducto() finalizarventa() realizarpago() Sistema El actor Supervisor usará al sistema solamente a través de esta interfaz «interface» CierreDeCaja cerrarcaja() calculartotales() Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 14

Interacciones con el Sistema Los casos de uso describen la forma en que actores utilizan al sistema para cumplir con sus objetivos Es necesario expresar estas ideas desde un punto de vista técnico Para ello se definen protocolos que determinan la interacción entre los actores y el sistema, ya sea para uno o varios escenarios de un caso de uso Cada protocolo es expresado mediante un Diagrama de Secuencia del Sistema (DSS) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 15

Interacciones con el Sistema (2) Caso de Uso 1 Esc. Típico Esc. Alternativo 1. Esc. Alternativo n : Cajero iniciarventa() : Sistema : Cajero : Sistema iniciarventa() agregarproducto(id,cant) descripcion, subtotal * [mas productos] terminarventa() total con impuestos realizarpago(monto) cambio, recibo Los DSSs se incluyen en la secc. Comportamiento del modelo agregarproducto(id,cant) descripcion, subtotal * [mas productos] terminarventa() total con impuestos realizarpago(monto) cambio, recibo Modelo de Casos de Uso Esc. Típico : Cajero iniciarventa() agregarproducto(id,cant) : Sistema Caso de Uso 2. Esc. Alternativo 1. Esc. Alternativo m descripcion, subtotal * [mas productos] terminarventa() total con impuestos realizarpago(monto) cambio, recibo : Sistema : Cajero iniciarventa() agregarproducto(id,cant) descripcion, subtotal * [mas productos] terminarventa() total con impuestos realizarpago(monto) cambio, recibo Un DSS que define la interacción entre los actores y el sistema en el escenario dado Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 16

Interacciones con el Sistema Eventos del Sistema Un evento del sistema Es un estímulo externo, Es generado por un actor, y Ante el cual el sistema debe reaccionar Las acciones de los actores (sobre el sistema) descritas en los casos de uso sugieren los eventos del sistema Es necesario considerar la definición de evento del sistema para identificarlos Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 17

Interacciones con el Sistema Eventos del Sistema (2) Ejemplo: El Cliente llega a la caja con artículos para comprar Es un evento externo pero no afecta al sistema No es un evento del sistema El Cajero ingresa el identificador del producto Es un estímulo externo generado por un actor ante el cual el sistema debe reaccionar Es un evento del sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 18

Interacciones con el Sistema Operaciones del Sistema Los eventos del sistema disparan una operación del sistema Estas operaciones son ejecutadas por la instancia sistema en resupuesta a la ocurrencia de un evento del sistema Las operaciones del sistema relativas a uno o varios escenarios de un caso de uso permiten definir la interacción entre los actores y el sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 19

Interacciones con el Sistema Operaciones del Sistema (2) Las operaciones del sistema pueden tener asociados parámetros Ejemplo: El Cajero ingresa el identificador del producto representa un evento que dispara la operación void agregarproducto(ident:string) El Cajero hasta terminar los productos representa un evento que dispara la operación void terminarventa() Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 20

Interacciones con el Sistema Diag. de Secuencia del Sistema Es un artefacto incluido en el Modelo de Casos de Uso que define e ilustra la interacción entre los actores y el sistema en uno o varios escenarios de un CU Incluye: Una instancia representando a cada participante (sistema y actores) Los mensajes enviados entre ellos en el/los escenario/s correspondiente/s (con sus respuestas) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 21

Interacciones con el Sistema Diag. de Secuencia del Sistema (2) Un Diagrama de Secuencia del Sistema puede ser construido para: Un escenario de un Caso de Uso Varios escenarios de un Caso de Uso Un criterio para decidir entre estas alternativas será la complejidad de estos escenarios y la simplicidad (o no) del DSS resultante Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 22

Interacciones con el Sistema Diag. de Secuencia del Sistema (3) Los diagramas de secuencia del sistema definen la conversación entre los actores y el sistema, enfocándose en los mensajes que el sistema recibe Sería posible incluir además mensajes enviados desde el sistema hacia los actores: Sin embargo esto no forma parte del conjunto de servicios que el sistema brinda (y cuya especificación es el objetivo de la presente actividad) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 23

Interacciones con el Sistema Diag. de Secuencia del Sistema (4) Notación: Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 24

Nombre del Diagrama Sistema Actor Iteración Criterio de parada Alternativo Operación del sistema TIEMPO Respuesta del sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 25

Interacciones con el Sistema Sugerencias Definición de un DSS: 1. Incluir una instancia que represente al sistema como una unidad 2. Identificar cada actor que participe en el/los escenario/s considerado/s e incluir una instancia para cada uno 3. De la descripción del caso de uso identificar aquellos eventos que los actores generen y sean de interés para el sistema e incluir cada uno de ellos como un mensaje Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 26

Interacciones con el Sistema Sugerencias (2) Límite del sistema: Para identificar eventos del sistema es útil pensar en el límite del sistema El límite suele determinarse para que coincida con el sistema de software (y el de hardware también) Buscar aquello que ocurra fuera de ese límite y que además lo atraviese Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 27

Interacciones con el Sistema Sugerencias (3) Límite del sistema (cont.): Es responsabilidad del sistema reaccionar ante el evento X? Es X externo? Límite del Sistema Se está comprando un producto promocional (ver que hacer con eso): es interno al sistema El Cliente elige un producto: no es de interés para el sistema SISTEMA El Cajero ingresa código del producto (elegido por el Cliente): eso sí es de interés Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 28

Interacciones con el Sistema Sugerencias (4) Memoria del Sistema: El sistema puede (o no) tener memoria: Sin memoria, los mensajes son independientes Con memoria, cada mensaje puede recordar la información utilizada en un estado previo del sistema Debe indicarse claramente si el sistema tiene o no memoria, y en caso de tenerla, qué información recuerda Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 29

Interacciones con el Sistema Sugerencias (5) Memoria del Sistema (cont.): Para indicar la memoria de un sistema, generalmente basta con indicarlo en el nombre del diagrama y mediante la utilización de notas en el diagrama Alternativamente, puede utilizarse un diagrama de estructura estática en aquellos casos en que interese indicar una estructura compleja de dicha memoria Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 30

Interacciones con el Sistema Sugerencias (6) Ejemplo: DSS sin memoria Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 31

Interacciones con el Sistema Sugerencias (7) Ejemplo: DSS con memoria el sistema recuerda la CI Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 32

Interacciones con el Sistema Errores Comunes Envío de mensajes hacia el usuario Desconocer la memoria del sistema No especificar data types utilizados Sobrecargar de información un diagrama de secuencia pudiendo realizar varios de ellos No indicar tipo de parámetros ni valor de retorno de los mensajes Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 33

Qué Sigue? Una vez identificadas las operaciones del sistema es posible especificar su comportamiento Esta especificación expresa el efecto que una operación tendrá sobre el sistema Para ello se realizará un Contrato de Software para cada operación del sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 34

Qué Sigue? (2) Los contratos se incluyen en la secc. Comportamiento del modelo Contrato: iniciarventa() Contrato: agregarproducto() Modelo de Casos de Uso Contrato: cancelarventa() Contrato: confirmarventa() Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 35

Contratos de Software Un contrato de software especifica el comportamiento o efecto de una operación La especificación es declarativa y no imperativa Esta técnica está basada en las ternas de Hoare en las que: Se describen propiedades del resultado, en lugar de dar un conjunto de pasos o instrucciones que indiquen cómo calcularlo Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 36

Contratos de Software Enfoque de Contratos El contrato de una operación es un contrato entre partes Consumidor de la operación: quién la invoca Proveedor de la operación: quién la implementa Determina derechos y obligaciones para cada una de las partes Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 37

Contratos de Software Enfoque de Contratos (2) Consumidor Proveedor Obligaciones Satisfacer precondición Satisfacer postcondición Derechos Obtener la postcondición satisfecha Procesamiento más simple al poder asumir como satisfecha la precondición Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 38

Contratos de Software Enfoque de Contratos (3) El Consumidor se compromete a satisfacer la precondición al invocar la operación: Si la satisface: tiene derecho a exigir que la postcondición se satisfaga Si no la satisface: no se le garantiza la correctitud del resultado de la invocación Por esta razón es responsabilidad del Consumidor saber cuándo invocar a la operación (y manejar en forma adecuada el resultado) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 39

Contratos de Software Enfoque de Contratos (4) El Proveedor se compromete a satisfacer la postcondición al finalizar la operación solamente cuando la precondición fue satisfecha al momento de la invocación El compromiso no comprende el caso en que la precondición no fue satisfecha: En ese caso el Proveedor puede devolver un valor arbitrario y el Consumidor tiene que aceptarlo y saber qué hacer con él Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 40

Contratos de Software Enfoque de Contratos (5) Ejemplo Autorización de Documento : Precondición: el documento está en la oficina antes de la hora 10 Postcondición: el documento está firmado por el Gerente a la hora 18 Consumidor: Yo te traigo el documento a las 10, pero a las 18 lo quiero firmado Proveedor: Yo te hago firmar el documento para las 18, pero lo necesito antes de las 10 Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 41

Contratos de Software Enfoque de Contratos (6) Ejemplo (cont.) Caso 1 (ambos cumplen) El documento llegó a las 9:45 A las 18 estaba firmado Caso 2 (el consumidor no cumple) El documento llegó a las 11:20 A las 18 no estaba firmado Caso 3 (el consumidor cumple pero el proveedor no) El documento llegó a las 9:10 A las 18 no estaba firmado El proveedor no tiene que cumplir Esto denota un bug en la implementación del proveedor Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 42

Contratos de Software Enfoque de Contratos (7) Consumidor: Prefiere precondiciones débiles: implica menos trabajo Prefiere postcondiciones fuertes: implica más resultados Proveedor: Prefiere precondiciones fuertes: implica menos preocupaciones Prefiere postcondiciones débiles: implica menos trabajo Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 43

Contratos de Software Enfoque de Contratos (8) Precondición: Es a lo que debe acceder el Consumidor para obtener el resultado deseado Es lo que debe exigir el Proveedor para llegar al resultado Postcondición: Es a lo que accederá el Consumidor Es a lo que se compromete el Proveedor Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 44

Contratos de Software Enfoque de Contratos (9) Tanto las Pre- como las Post- las determina el Proveedor El Consumidor: Viendo la Post- sabe qué va a obtener (sin saber cómo) Viendo la Pre- sabe a cambio de qué obtiene el resultado Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 45

Contratos de Software Contratos de Operaciones Los contratos se pueden realizar para operaciones de cualquier tipo de clase En esta actividad las realizaremos para operaciones del sistema Para una operación X tendremos {P}S{Q} P es la precondición de X (especificada) S es el programa que implementa X (a ser diseñado más adelante en la etapa de Diseño) Q es la postcondición de X (especificada) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 46

Contratos de Software Contratos de Operaciones (2) Quién utiliza el contrato (partes P y Q) de una operación? Un diseñador de nuestro equipo que deba diseñar S Para saber qué es lo que tiene que lograr su diseño de la operación En función de lo anterior para decidir cómo será el diseño de la operación (parte S) Un desarrollador de otro equipo que deba invocar la operación (el diseño o implementación de S no es su responsabilidad) Para saber qué es lo que la operación hace sin tener que ver el diseño o la implementación de S Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 47

Contratos de Software Condiciones En qué términos se expresan las pre- y postcondiciones? Y para el caso particular de operaciones del sistema? En términos generales estas condiciones refieren al estado del sistema antes y después de la invocación a la operación Las precondiciones refieren además a los argumentos de la operación Las postcondiciones refieren además al valor retornado por la operación (si existe) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 48

Contratos de Software Condiciones (2) Las Precondiciones refieren al momento previo a la invocación y expresan condiciones sobre Los valores de los parámetros de la operación El estado del sistema: La creación de objetos La destrucción de objetos La conexión de objetos La desconexión de objetos La modificación del valor de atributos de objetos Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 49

Contratos de Software Condiciones (3) Las Postcondiciones refieren al momento posterior a la invocación expresan condiciones sobre El valor de retorno (si corresponde) El estado del sistema: La creación de objetos La destrucción de objetos La conexión de objetos La desconexión de objetos La modificación del valor de atributos de objetos Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 50

Contratos de Software Condiciones (4) Creación de objetos: Pre: Declarar que el objeto no existe Post: Declarar que el objeto existe Destrucción de objetos: Pre: Declarar que el objeto existe Post: Declarar que el objeto no existe y que todos los objetos que estaban conectados a él ya no lo están Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 51

Contratos de Software Condiciones (5) Conexión de objetos: Pre: Declarar que los objetos no están conectados Post: Declarar que los objetos están conectados Desconexión de objetos: Pre: Declarar que los objetos están conectados Post: Declarar que los objetos no están conectados Modificación del valor de atributos de objetos: Pre: Declarar que el objeto exista Post: Declarar que el atributo del objeto tiene el valor dado Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 52

Contratos de Software Condiciones (6) Ejemplo para operación contratar() Precondición: No existe un objeto de tipo Empleado con el valor 6150 en el atributo codigo, existe un objeto de tipo Empresa con valor BROU en el atributo nombre Postcondición: Existe un nuevo objeto de tipo Empleado con el valor 6150 en el atributo codigo que está conectado a uno de tipo Empresa que tiene el valor BROU en el atributo nombre De esto se puede derivar que la operación crea al objeto de tipo Empleado y lo conecta con el de tipo Empresa Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 53

Contratos de Software Condiciones (7) 1 : Empresa nombre = BROU 2 : Empleado codigo = 6150 : Empresa nombre = BROU Se pasa del estado 1 al estado 2 mediante la ejecución de contratar( BROU, 6150); Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 54

Contratos de Software Condiciones (8) Notar que el contrato NO dice cómo debe implementarse la operación del sistema contratar() Expresa condiciones sobre el estado inicial y sobre el estado final que indican qué es lo que la operación hace, pero no cómo lo hace Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 55

Contratos de Software Estructura de Contratos Un contrato es un artefacto textual que se incluye en la sección Comportamiento del Modelo de Casos de Uso Está estructurado de la siguiente forma: Firma: Cabezal sintáctico de la operación Parámetros: Descripción de los parámetros de la operación Responsabilidades: Descripción de las responsabilidades, una idea de lo que debe realizar la operación Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 56

Contratos de Software Estructura de Contratos (2) Estructura (cont.) Referencias cruzadas: Caso(s) de Uso a los que pertenece la operación Salida: Resultado de la operación (sólo si es una función) Precondición: Descripción del estado de la instancia del sistema a la que se le aplicará la operación, y otras condiciones que sea necesario asumir previo a la aplicación (por ejemplo, con respecto a los parámetros) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 57

Contratos de Software Estructura de Contratos (3) Estructura (cont.) Postcondición: Descripción del estado de la instancia del sistema a la que se le aplicó la operación Snapshots: (Opcional) Pares de snapshots que ejemplifiquen el estado de la instancia a la que se le aplicó la invocación, previo y posterior a la invocación La invocación concreta que produce el cambio ejemplificado (mostrando los parámetros efectivos) Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 58

Contratos de Software Contratos en OCL OCL contiene construcciones que permiten expresar (parte de) contratos Nombre y Tipo al que la operación pertenece Precondición y Postcondición En el caso de operaciones del sistema el Tipo es la clase Sistema context Sistema::operacionDelSistema()... Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 59

Contratos de Software Contratos en OCL (2) La precondición y la postcondición se puede expresar directamente en OCL context Sistema::operacionDelSistema() pre: -- una condicion pre: -- otra condicion post: -- una condicion post: -- otra condicion Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 60

Contratos de Software Errores Comunes Incluir invariantes como postcondiciones Omitir el resultado de una operación como postcondición Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 61

Qué Sigue? Hasta el momento se tienen identificadas y especificadas las operaciones del sistema para todos los casos de uso definidos Es posible ahora realizar un diseño en el que Se identifiquen los objetos que realmente participarán en la solución Se definan interacciones entre dichos objetos tal que cada una cumpla un contrato correspondiente a una operación del sistema Programación Avanzada Análisis: Especificación del Comportamiento del Sistema 62