Este documento presenta los contenidos de una unidad sobre diseño de sistemas. Incluye introducciones a temas como el proceso de diseño, principios de diseño, documentación de diseño, análisis y diseño orientados a objetos, modelos de dominio y casos de uso, y el lenguaje UML. También presenta un caso de estudio de ejemplo sobre un videoclub y los primeros artefactos de análisis requeridos como la presentación general del sistema, descripción de clientes, metas, funciones y atributos.

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. Cap. 15 Larman, 2ª. Ed. Cap. 14

3. UML: Primeros Artefactos del Análisis Unidad Nº I Craig Larman (Cap. 8) Ingeniería en Sistemas de Información DISEÑO DE SISTEMAS

7. DISEÑO DE SISTEMAS ANÁLISIS DE LOS REQUERIMIENTOS R equerimientos => Elementos que identifican, describen y documentan las necesidades o deseos de un producto. Son las pautas que deben realizarse clara e inequívocamente, para evitar futuros problemas y para facilitar la comunicación con el cliente y los desarrolladores. Durante el Análisis de Requerimientos se recomienda definir los siguientes artefactos :

12. DISEÑO DE SISTEMAS Primeros Artefactos del Análisis Las funciones se clasifican en CATEGORÍAS para establecer prioridades e identificar aquellas que pasarían inadvertidas . Las categorías son: Categoría Descripción Evidente Debe realizarse y el usuario debería saber que se ha realizado. Oculta Debe realizarse, aunque no es visible para los usuarios. Superflua Opcional, su inclusión no repercute significativamente en el costo ni en otras funciones.

13. DISEÑO DE SISTEMAS Caso I: Funciones Caso I Ref# Función Categoría R1.1. Registra el alquiler de un video. evidente R1.2. Calcula el total de lo alquilado. evidente R1.3 Captura la información sobre el video usando una captura manual del número de video. evidente R1.4 Marca el video alquilado como no disponible. oculta R1.5. Registra para cada video alquilado la fecha y hora del evento. oculta R1.6. Muestra el precio del video alquilado. evidente R1.7. Emite el ticket correspondiente. evidente R1.8 Captura la información sobre los socios usando una captura manual del número de socio. evidente R1.9 Informa si un video ha sido o no alquilado. evidente R1.10 Calcula la deuda total de un socio. evidente

15. DISEÑO DE SISTEMAS Primeros Artefactos del Análisis Caso I Atributo Detalles y restricciones de frontera tiempo de respuesta (restricción de frontera) la información sobre un video deberá aparecer en menos de 1 segundo. metáfora de interfaz (detalle) desarrollo del sistema en un lenguaje visual (detalle) permitir la utilización del mouse y el teclado plataforma del sistema operativo (detalle) Windows XP/ 7 facilidad de uso (detalle) guiar al operador durante la utilización del sistema

16. CASOS DE USO Craig Larman (Cap. 8) Ingeniería en Sistemas de Información DISEÑO DE SISTEMAS

19. DISEÑO DE SISTEMAS Casos de Uso UML no impone un formato rígido en su estructura, que puede modificarse para atender las necesidades y ajustarse al espíritu de la documentación. Se busca, ante todo, lograr una comunicación clara. Un caso expandido de uso muestra más detalles que uno de alto nivel; suelen ser útiles para alcanzar un conocimiento mas profundo de los procesos y de los requerimientos. CASO EXPANDIDO DE USO

20. Formato de un caso expandido de uso: Caso de Uso: Nombre del caso de uso. Actores: Lista de actores (agentes externos), en el cual se indica quien inicia el caso de uso. Propósito: Intención del caso de uso. Resumen: Repetición del caso de uso de alto nivel o alguna síntesis similar. Tipo: 1. Primario, secundario u opcional. 2. Esencial o real. Referencias Cruzadas: Casos de uso y/o Funciones relacionadas del sistema DISEÑO DE SISTEMAS Casos de Uso

21. DISEÑO DE SISTEMAS Casos de Uso Curso normal de los eventos Describe los detalles de la interacción entre los actores y el sistema. Explica la secuencia más común de los eventos: la historia normal de las actividades y la terminación exitosa de un proceso. No incluye situaciones alternas. Acción del actor Respuesta del sistema 1. Este caso de uso comienza cuando un Cliente ... 2. ... 3. ... Detalla las acciones atribuidas a los Actores Describe las respuestas dadas por el Sistema

25. Un error común en los casos de uso : Un error común en la identificación de los casos de uso consiste en representar los pasos, las operaciones o las transacciones como casos. Por ejemplo Caso de uso (incorrecto): imprimir recibo. Pues este sólo es un paso del caso de uso Comprar productos. DISEÑO DE SISTEMAS Casos de Uso Un Caso de Uso es una descripción de un proceso de principio a fin relativamente amplia, descripción que suele abarcar muchos pasos o transacciones, normalmente no es un paso ni una actividad individual del proceso.

26. Casos de uso y procesos del dominio Un Caso de Uso describe un proceso, que puede ser un proceso de negocios. Un proceso describe, de comienzo a fin, una secuencia de los eventos, acciones y transacciones que se requieren para producir u obtener algo de valor para una empresa o actor. Procesos: Ordenar un producto. Realizar una llamada telefónica. DISEÑO DE SISTEMAS Casos de Uso

27. Caso de Uso, funciones del sistema y rastreabilidad Las funciones del sistema identificadas durante la especificación previa de requerimientos deben asignarse a los casos de uso. Además, debe ser posible verificar, mediante la sección Referencias Cruzadas, que todas las funciones hayan sido asignadas. Con ello se logra un vinculo importante respecto a la rastreabilidad entre los artefactos. En definitiva, todas las funciones y casos de uso del sistema deberían poder rastrearse hasta la implementación y la aplicación de pruebas. DISEÑO DE SISTEMAS Casos de Uso

29. Casos Esenciales de Uso Son casos expandidos que se expresan en una forma teórica que contiene poca tecnología y pocos detalles de implementación : las decisiones de diseño se posponen y se abstraen de la realidad, especialmente las relacionadas a la interfaz con el usuario. Describen al proceso a partir de sus actividades y motivos esenciales . Los casos de alto nivel son siempre ESENCIALES, debido a su alto grado de brevedad y abstracción. DISEÑO DE SISTEMAS Casos de Uso Casos Reales de Uso Describen concretamente el proceso a partir de su diseño concreto actual, sujeto a tecnologías específicas de entrada y salida. Se orienta particularmente a definir las interfaces con el usuario, ofrece presentaciones de pantalla y explica la actuación de los artefactos.

30. DISEÑO DE SISTEMAS Casos de Uso DIAGRAMA DE CASOS DE USO Un Diagrama de Caso de Uso explica gráficamente un conjunto de Casos de Uso de un sistema, los actores y la relación entre éstos y los casos de uso. Las líneas de comunicaciones entre los casos y los actores indican el flujo de información o el estímulo. Actor 1 Actor 2 Sistema X Caso de Uso 1 Caso de Uso 2 Caso de Uso 3

33. DISEÑO DE SISTEMAS Ejemplo Práctico Formato de un caso de uso de alto nivel: Caso de Uso: Alquiler de Vídeo Actores: Empleado Tipo: Primario. Descripción: Un cliente llega a la caja registradora con los videos que quiere alquilar. El empleado registra los videos y cobra el importe. Al terminar la operación, el Cliente se marcha con los videos y el comprobante. 3) Descripción Formal de los Casos de Uso: Se realiza la descripción de los Casos de Uso con el formato de alto nivel. Considerando ésto, solo se describe la acción en general. A modo de ejemplo solo se describen dos casos de uso.

34. DISEÑO DE SISTEMAS Ejemplo Práctico Caso de Uso: Devolución de Video Actores: Empleado Tipo: Primario. Descripción: Un cliente llega al negocio con los videos que quiere devolver. El empleado registra los videos y verifica fecha de devolución. El empleado recibe los videos y el Cliente se retira.

35. DISEÑO DE SISTEMAS Ejemplo Práctico Formato de un caso expandido de uso: Caso de Uso: Alquiler de Video Actores: Empleado (Iniciador) Propósito: Dejar registrado que el Cliente alquilo X película. Resumen: Un cliente llega a la caja registradora con los videos que quiere alquilar. El empleado registra los videos y cobra el importe. Al terminar la operación, el Cliente se marcha con los videos y el comprobante. Tipo: Primario. Referencias Funciones : R1.1., R1.2., R1.3., R1.6., R1.7. Cruzadas: 4) Especificar el curso normal de eventos y los cursos alternos.

36. DISEÑO DE SISTEMAS Trabajo Práctico Nº 2 Curso normal de los eventos: Acción del actor Respuesta del sistema 1. Este caso de uso comienza cuando en Cliente llega a la caja con videos para aquilarlos. 2. El empleado verifica que el cliente sea socio, registra los videos, y el estado de este (si no tiene alguna multa pendiente) 3. El Cliente confirma que no quiere mas videos. 4. El empleado emite un ticket y cobra. 5. El cliente paga lo correspondiente al ticket. 6. El empleado cobra. Entrega el/los video/s al cliente. 7. Este recibe los videos, y se retira.

38. DISEÑO DE SISTEMAS Ejemplo Práctico Caso I: Funciones 5) Realizar el diagrama de casos de uso. Empleado Video Club Alquilar Videos Alta de nuevos Videos Alta de Socio .