SlideShare una empresa de Scribd logo
1 de 51
Descargar para leer sin conexión
Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
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
DIAGRAMAS DE SECUENCIA Craig Larman (Cap. 13) Ingeniería en Sistemas de Información DISEÑO DE SISTEMAS
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.
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.
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.
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.
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 .
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.
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.    
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”.
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?.
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()
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()
DISEÑO DE SISTEMAS Diagramas de Secuencia Como elaborar un diagrama de secuencia   Para elaborar diagramas de Secuencia de un sistema que describan el curso normal de los eventos en un caso de uso   Aplique los siguientes pasos :   ,[object Object],[object Object],[object Object],[object Object]
DISEÑO DE SISTEMAS Diagramas de Secuencia Ejemplo: Los diagramas de secuencia de un sistema surgen de los casos de uso   Cajero :Sistema Comprar productos introducirProducto (CUP, cant) terminarVenta() efectuarPago (monto) ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
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: 
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 .
DISEÑO DE SISTEMAS Diagramas de Secuencia Cajero :Sistema Comprar productos  introducirProducto (CUP, cant) terminarVenta() efectuarPago (monto) Frontera del Sistema
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.
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
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
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.
CONTRATOS Craig Larman (Cap. 14) Ingeniería en Sistemas de Información DISEÑO DE SISTEMAS
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 .
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
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 .
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.
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  
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).
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.
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.
DISEÑO DE SISTEMAS Contratos Como preparar un contrato   Para preparar un contrato en los casos de uso:   => Aplique los siguientes pasos:   ,[object Object],[object Object],[object Object]
DISEÑO DE SISTEMAS Contratos ,[object Object],[object Object],[object Object],[object Object],[object Object]
DISEÑO DE SISTEMAS Contratos Contratos y otros artefactos   ,[object Object],[object Object],[object Object]
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
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:
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 .
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
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.
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. 
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).
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?
DISEÑO DE SISTEMAS Contratos Las  Precondiciones  definen las suposiciones sobre el estado del  Sistema  al iniciarse la  Operación . PRECONDICIONES   Hay muchas  Precondiciones  que pueden declararse en una  Operación , pero la experiencia revela que vale la pena mencionar las siguientes:   ,[object Object],[object Object]
DISEÑO DE SISTEMAS EJEMPLO PRÁCTICO: Para el caso del Videoclub se realizarán estas tareas: ,[object Object],[object Object]
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.
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.  
DISEÑO DE SISTEMAS Curso alterno de los eventos:   ,[object Object],[object Object],[object Object],[object Object],11. Calcula el saldo, registra el pago y emite el ticket.   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.   
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...
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.
DISEÑO DE SISTEMAS Excepciones Si el  código  no es válido, indicar que se cometió un error. Salida   Precondiciones El sistema conoce el  código   de video. Postcondiciones:           ,[object Object],[object Object],[object Object],[object Object]

Más contenido relacionado

La actualidad más candente

Mapa mental uml
Mapa mental umlMapa mental uml
Mapa mental umlrigo berto
 
Tm03 modelo de casos de uso
Tm03 modelo de casos de usoTm03 modelo de casos de uso
Tm03 modelo de casos de usoJulio Pari
 
Analisis y diseño diagrama de caso de uso
Analisis y diseño diagrama de caso de usoAnalisis y diseño diagrama de caso de uso
Analisis y diseño diagrama de caso de usoYovana Connie Roca Avila
 
Indagación de los requerimientos
Indagación de los requerimientosIndagación de los requerimientos
Indagación de los requerimientosUCATEBA
 
Diagrama de despliegue
Diagrama de despliegueDiagrama de despliegue
Diagrama de despliegueElvisAR
 
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Oswaldo Hernández
 
Modelado de casos de uso
Modelado de casos de usoModelado de casos de uso
Modelado de casos de usobelleta55
 
casos de uso
casos de usocasos de uso
casos de usostill01
 
Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoSergio Sanchez
 
Caso de uso de biblioteca
Caso de uso de bibliotecaCaso de uso de biblioteca
Caso de uso de bibliotecapersye
 
Plan de Pruebas
Plan de PruebasPlan de Pruebas
Plan de Pruebaschoselin
 
Tipos de Requerimientos en Ingeniería de Software
Tipos de Requerimientos en Ingeniería de SoftwareTipos de Requerimientos en Ingeniería de Software
Tipos de Requerimientos en Ingeniería de SoftwareLeo Ruelas Rojas
 

La actualidad más candente (20)

UML: CASOS DE USO
UML: CASOS DE USOUML: CASOS DE USO
UML: CASOS DE USO
 
Modelo Cascada!!
Modelo Cascada!!Modelo Cascada!!
Modelo Cascada!!
 
Clase 11 uml_casos_de_uso
Clase 11 uml_casos_de_usoClase 11 uml_casos_de_uso
Clase 11 uml_casos_de_uso
 
Mapa mental uml
Mapa mental umlMapa mental uml
Mapa mental uml
 
Tm03 modelo de casos de uso
Tm03 modelo de casos de usoTm03 modelo de casos de uso
Tm03 modelo de casos de uso
 
Diagramas de estado
Diagramas de estadoDiagramas de estado
Diagramas de estado
 
Modelado del negocio
Modelado del negocioModelado del negocio
Modelado del negocio
 
Analisis y diseño diagrama de caso de uso
Analisis y diseño diagrama de caso de usoAnalisis y diseño diagrama de caso de uso
Analisis y diseño diagrama de caso de uso
 
Indagación de los requerimientos
Indagación de los requerimientosIndagación de los requerimientos
Indagación de los requerimientos
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Diagrama de despliegue
Diagrama de despliegueDiagrama de despliegue
Diagrama de despliegue
 
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
 
Modelado de casos de uso
Modelado de casos de usoModelado de casos de uso
Modelado de casos de uso
 
casos de uso
casos de usocasos de uso
casos de uso
 
Ejemplo
EjemploEjemplo
Ejemplo
 
Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De Uso
 
Caso de uso de biblioteca
Caso de uso de bibliotecaCaso de uso de biblioteca
Caso de uso de biblioteca
 
Plan de Pruebas
Plan de PruebasPlan de Pruebas
Plan de Pruebas
 
Análisis estructurado
Análisis estructuradoAnálisis estructurado
Análisis estructurado
 
Tipos de Requerimientos en Ingeniería de Software
Tipos de Requerimientos en Ingeniería de SoftwareTipos de Requerimientos en Ingeniería de Software
Tipos de Requerimientos en Ingeniería de Software
 

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

Similar a Del análisis al diseño. diagramas de secuencia y contratos (20)

Diagrama De Secuencia www.giiaa.com
Diagrama De Secuencia www.giiaa.comDiagrama De Secuencia www.giiaa.com
Diagrama De Secuencia www.giiaa.com
 
MODELADO DE DATOS
MODELADO DE DATOSMODELADO DE DATOS
MODELADO DE DATOS
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Semana13-AOO.ppt
Semana13-AOO.pptSemana13-AOO.ppt
Semana13-AOO.ppt
 
Diagramas de flujo
Diagramas de flujoDiagramas de flujo
Diagramas de flujo
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
 
Diagramadeflujo 140115215731-phpapp02
Diagramadeflujo 140115215731-phpapp02Diagramadeflujo 140115215731-phpapp02
Diagramadeflujo 140115215731-phpapp02
 
Clase diagramas desecuencia
Clase diagramas desecuenciaClase diagramas desecuencia
Clase diagramas desecuencia
 
Caso De Uso
Caso De UsoCaso De Uso
Caso De Uso
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Unidad 1
Unidad  1Unidad  1
Unidad 1
 
Unidad 1
Unidad  1Unidad  1
Unidad 1
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Manual del Software Arena.
Manual del Software Arena.Manual del Software Arena.
Manual del Software Arena.
 
DiagramasDeSecuencia COMP Y ABAST5-SEM.ppt
DiagramasDeSecuencia COMP Y ABAST5-SEM.pptDiagramasDeSecuencia COMP Y ABAST5-SEM.ppt
DiagramasDeSecuencia COMP Y ABAST5-SEM.ppt
 

Más de Juan Pablo Bustos Thames

El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian SommervilleEl Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian SommervilleJuan Pablo Bustos Thames
 
El Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanEl Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanJuan Pablo Bustos Thames
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de controlJuan Pablo Bustos Thames
 
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Juan Pablo Bustos Thames
 
Soluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidadSoluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidadJuan Pablo Bustos Thames
 
Patrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspPatrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspJuan Pablo Bustos Thames
 
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Juan Pablo Bustos Thames
 

Más de Juan Pablo Bustos Thames (20)

Pruebas del Software
Pruebas del SoftwarePruebas del Software
Pruebas del Software
 
Verificación y Validación del Diseño
Verificación y Validación del DiseñoVerificación y Validación del Diseño
Verificación y Validación del Diseño
 
Diseño a Nivel de Componentes
Diseño a Nivel de ComponentesDiseño a Nivel de Componentes
Diseño a Nivel de Componentes
 
El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian SommervilleEl Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
 
El Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanEl Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger Pressman
 
Reglas de Oro
Reglas de OroReglas de Oro
Reglas de Oro
 
Diseño de interfaces
Diseño de interfacesDiseño de interfaces
Diseño de interfaces
 
Modelos de dominio específicos
Modelos de dominio específicosModelos de dominio específicos
Modelos de dominio específicos
 
Arquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidos
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de control
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
 
Diagramas de clases
Diagramas de clasesDiagramas de clases
Diagramas de clases
 
Soluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidadSoluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidad
 
Patrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspPatrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. grasp
 
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
 
Modelos de dominio
Modelos de dominioModelos de dominio
Modelos de dominio
 
Modelos de dominio
Modelos de dominioModelos de dominio
Modelos de dominio
 
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetosAnálisis y diseño orientado a objetos
Análisis y diseño orientado a objetos
 
Documentación del diseño
Documentación del diseñoDocumentación del diseño
Documentación del diseño
 

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

  • 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()
  • 15.
  • 16.
  • 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.
  • 33.
  • 34.
  • 35.
  • 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?
  • 44.
  • 45.
  • 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.  
  • 48.
  • 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.
  • 51.