Your SlideShare is downloading. ×
0
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Primeros artefactos de análisis. casos de uso

17,131

Published on

UTN - FRT. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad I. Craig Larman. Primeros Artefactos de Análisis. Análisis de los Requerimientos. Casos de Uso

UTN - FRT. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad I. Craig Larman. Primeros Artefactos de Análisis. Análisis de los Requerimientos. Casos de Uso

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
17,131
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
219
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 4. DISEÑO DE SISTEMAS CASO DE ESTUDIO de Ejemplo: Video Club El dominio de nuestro problema es un sistema de información para un negocio dedicado al alquiler de videos (videoclub). El negocio presenta las siguientes características: <ul><ul><ul><li>Se trata de un negocio pequeño que no es parte de una organización mayor. </li></ul></ul></ul><ul><ul><ul><li>Solamente alquila videos. </li></ul></ul></ul><ul><ul><ul><li>Los videos se encuentran clasificados por género (comedia, acción, etc.). </li></ul></ul></ul><ul><ul><ul><li>El negocio no vende videos u otra cosa. </li></ul></ul></ul>
  • 5. DISEÑO DE SISTEMAS Caso de Estudio <ul><ul><li>La única transacción que se considera es el alquiler de los videos. </li></ul></ul><ul><ul><li>Un cliente puede alquilar más de un video. </li></ul></ul><ul><ul><li>Sólo se aceptan pagos en efectivo. </li></ul></ul><ul><ul><li>Al terminar de realizar un alquiler, el cliente recibe un ticket. </li></ul></ul><ul><ul><li>Cada cliente debe hacerse socio del videoclub para poder realizar un alquiler. </li></ul></ul><ul><ul><li>La devolución de los videos se realizará dentro de las 24 hs. Si el cliente excede el tiempo de devolución se le cobrará como otro alquiler por cada 24 hs. </li></ul></ul><ul><ul><li>En todo momento se podrá saber si un video está en estantería, prestado o si se cumplió en tiempo de entrega y no se lo devolvió. </li></ul></ul>
  • 6. DISEÑO DE SISTEMAS Primeros Artefactos de Análisis Se requieren realizar las siguientes tareas: <ul><li>Presentación General del Sistema </li></ul><ul><li>Descripción de Clientes </li></ul><ul><li>Metas </li></ul><ul><li>Funciones del Sistema </li></ul><ul><li>Atributos del Sistema </li></ul>
  • 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 :
  • 8. DISEÑO DE SISTEMAS Primeros Artefactos del Análisis       Caso I: El proyecto tiene por objeto crear un sistema para el alquiler de videos en un Video Club . <ul><li>Presentación General del Sistema : breve descripción del sistema que se pretende desarrollar. </li></ul>
  • 9. DISEÑO DE SISTEMAS Primeros Artefactos del Análisis <ul><li>Descripción de clientes: descripción de la parte interesada en el desarrollo del sistema. </li></ul>    Caso I: Video Club “SuperVideo” , comercio que se dedica al alquiler de películas en video.
  • 10. DISEÑO DE SISTEMAS Primeros Artefactos del Análisis     Caso I: La meta incluye: <ul><li>Metas : Consiste en especificar las ventajas y/o facilidades que brinda el nuevo sistema. </li></ul><ul><li>Facilitar la registración de los alquileres. </li></ul><ul><li>Control de devoluciones. </li></ul><ul><li>Cálculo automático de deudas. </li></ul><ul><li>Estadísticas sobre alquileres. </li></ul>
  • 11. DISEÑO DE SISTEMAS Primeros Artefactos del Análisis <ul><li>Funciones del sistema: Las funciones del sistema son las acciones que se prevén que el mismo deberá realizar. . </li></ul>Para que X sea en verdad una FUNCION DEL SISTEMA , se puede utilizar esta expresión: El sistema deberá hacer [X]
  • 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
  • 14. DISEÑO DE SISTEMAS Primeros Artefactos del Análisis <ul><li>Atributos del sistema : son cualidades no funcionales , es decir sus características o dimensiones . Los atributos pueden abarcar todas las funciones o ser específicos de una función o grupo de funciones. </li></ul>Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simbólicos; otros atributos pueden tener restricciones de frontera, que son condiciones obligatorias en un rango numérico de valores.
  • 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
  • 17. DISEÑO DE SISTEMAS Casos de Uso Para especificar los Casos de Uso de un Sistema, debemos antes conocer los requerimientos del mismo. (Primeros Artefactos) <ul><li>Documento Narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso </li></ul><ul><ul><ul><li>Son Historias o Casos de Utilización de un Sistema </li></ul></ul></ul><ul><ul><ul><li>No son exactamente los requerimientos ni las especificaciones funcionales de un Sistema. </li></ul></ul></ul><ul><ul><ul><li>Sí ejemplifican e incluyen tácitamente los requerimientos en las historias que narran. </li></ul></ul></ul>CASO DE USO
  • 18. DISEÑO DE SISTEMAS Casos de Uso <ul><ul><li>    Icono del Lenguaje UML para un caso de uso </li></ul></ul>Comprar productos Formato de un caso de uso de alto nivel:   Caso de Uso: Nombre Actores: Lista de actores. Tipo: Primario. Descripción:
  • 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
  • 22. <ul><li>Curso alterno de los eventos </li></ul><ul><li>Describe las opciones o excepciones que pueden presentarse con relación al curso normal. Si son complejas, podemos expandirlas y convertirlas en nuestros casos de uso. Se indica numero de línea, y la descripción de las excepciones. </li></ul>DISEÑO DE SISTEMAS Casos de Uso Cursos alternos. Línea 2: Introducción de identificador inválido. Indica error.
  • 23. <ul><ul><li>Entidad externa del sistema que participa en la historia del caso de uso. </li></ul></ul><ul><ul><li>Estimula al sistema con eventos de entrada o recibe algo de él. </li></ul></ul><ul><ul><li>Están representados por el Papel que desempeñan en el Caso : Cliente, Cajero, etc. </li></ul></ul><ul><ul><li>Se escribe su nombre con mayúscula en la narrativa del Caso para facilitar su identificación. </li></ul></ul><ul><ul><li>El Actor puede ser: iniciador (produce la estimulación inicial del Sistema), o bien ser simplemente: participante . </li></ul></ul>DISEÑO DE SISTEMAS Casos de Uso ACTORES
  • 24. DISEÑO DE SISTEMAS Casos de Uso <ul><ul><li>    Icono del Lenguaje UML que representa un actor de casos de uso </li></ul></ul>El ícono estándar es una figura humana estilizada, pero algunos utilizan un ícono con figura de computadora para designar los actores que son sistemas de cómputo y no seres humanos. <ul><li>Los actores pueden ser: </li></ul><ul><ul><ul><li>Seres humanos que desempeñan cierto papel. </li></ul></ul></ul><ul><ul><ul><li>Sistemas de cómputos. </li></ul></ul></ul><ul><ul><ul><li>Aparatos electrónicos o mecánicos. </li></ul></ul></ul>Cliente
  • 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
  • 28. Clasificación de los Caso de Uso Hay dos criterios: DISEÑO DE SISTEMAS Casos de Uso <ul><ul><li>Casos Primarios de Uso: representan los procesos comunes más importantes, como Alquilar Video. </li></ul></ul><ul><ul><li>Casos Secundarios de uso: representan procesos menores o raros: por ejemplo Solicitud de alta de un nuevo Video. </li></ul></ul><ul><ul><li>Casos Opcionales de Uso: representan procesos que pueden o no abordarse. </li></ul></ul>
  • 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
  • 31. DISEÑO DE SISTEMAS EJEMPLO PRÁCTICO Para el caso del videoclub se realizarán las siguientes tareas: <ul><li>Identificar los actores del sistema. </li></ul><ul><li>Identificar los casos de uso. </li></ul><ul><li>Realizar una descripción formal de los casos de uso. </li></ul><ul><li>Especificar el curso normal de eventos y los cursos alternos. </li></ul><ul><li>Realizar el diagrama de casos de uso. </li></ul>
  • 32. DISEÑO DE SISTEMAS Ejemplo Práctico <ul><li>1) Identificar los Actores del sistema: </li></ul><ul><ul><li>Empleado del Video Club. </li></ul></ul><ul><li>2) Identificar los Casos de Uso: </li></ul><ul><ul><ul><li>Alquiler de Video. </li></ul></ul></ul><ul><ul><ul><li>Devolución de Video. </li></ul></ul></ul><ul><ul><ul><li>Alta de Socio. </li></ul></ul></ul><ul><ul><ul><li>Baja de Socio. </li></ul></ul></ul><ul><ul><ul><li>Consultar socio. </li></ul></ul></ul><ul><ul><ul><li>Consultar Video. </li></ul></ul></ul>
  • 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.  
  • 37. DISEÑO DE SISTEMAS Ejemplo Práctico <ul><li>Curso alterno de los eventos: </li></ul><ul><ul><li>Línea 2: El cliente no es socio. Error. Ver Caso de Uso: Alta de Socio. </li></ul></ul><ul><ul><li>Línea 2: El Cliente tiene una multa no pagada. Ver Caso de Uso: Multas. </li></ul></ul><ul><ul><li>Línea 5: El Cliente no tiene el dinero necesario para pagar. Se cancela la operación. </li></ul></ul> 
  • 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 .

×