INGENIERIA DE SOFTWARE II Clase Nº 7 Bibliografía: Pressman, Roger. Ingeniería de Software. Un enfoque práctico. Cuarta Edición. McGrawHill.México. 1997. http://www.clikear.com/manuales/uml/diagramascasouso.aspx http://www.osmosislatina.com/lenguajes/uml/casos.htm © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

UNIDAD II. ESPECIFICACIÓN DE REQUERIMIENTOS Objetivos de la Unidad Al finalizar esta unidad el participante será capaz de: Utilizar notaciones y herramientas especializadas para especificar y documentar requerimientos de software. Elaborar modelos funcionales, estructurales y dinámicos de una aplicación usando UML. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

ANALISIS ORIENTADO A OBJETOS (AOO) Propósito es definir todas las clases que son relevantes al problema que se estudia. Método de Booch Método de Coad/Yourdon Método de Jacobson Método de Rumbaugh Método de Wirfs-Brock © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

NO ES UNA METODOLOGIA UML (UNIFIED MODELING LANGUAGE) Es un lenguaje de modelado de sistemas que integra y unifica diferentes notaciones y lenguajes formales. Facilita la representación del conocimiento acerca de un sistema y la comunicación de dicho conocimiento. Es un estándar administrado por el consorcio OMG (Object Management Group – www.omg.org -) Ha evolucionado agregando más poder y capacidad semántica a cada nueva versión (UML 1.4, UML 1.5, UML 2.0 y UML 2.1) Lenguaje gráfico para visualizar, especificar, construir y documentar las partes de un sistema de software. Puede utilizarse a lo largo de todo el ciclo de vida. NO ES UNA METODOLOGIA © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

UML (UNIFIED MODELING LANGUAGE) Es utilizado para: Especificar Diseñar Visualizar Comunicar y Documentar sistemas. Se emplea directamente en las siguientes actividades del desarrollo de software: Modelado de Negocios Definición y especificación de requerimientos. Diseño arquitectónico Especificación y diseño de componentes de software Diseño detallado de programas Diseño de bases de datos Diseño de interfaces H/M Pruebas de sistemas Documentación de sistemas Características Unifica diferentes notaciones Intuitiva Homogénea Coherente Genérica Extensible Configurable Los datos estructurados están constituidos por datos de tipo simple. Una ESTRUCTURA DE DATOS es una colección o conjunto de datos que tienen el mismo nombre. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

UML (UNIFIED MODELING LANGUAGE) UML consta de un conjunto de notaciones gráficas y un lenguaje formal Las notaciones gráficas son usadas para: Modelar la estructura, funcionalidad, comportamiento e implementación de un sistema. Organizar los modelos producidos. El lenguaje formal es usado para: Expresar formalmente restricciones acerca de los elementos modelados de un sistema, permite representar: Invariantes Pre y post condiciones Referencias Otras restriciones Los datos estructurados están constituidos por datos de tipo simple. Una ESTRUCTURA DE DATOS es una colección o conjunto de datos que tienen el mismo nombre. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

UML (UNIFIED MODELING LANGUAGE) Diagramas Estructurales De Clases De Estructuras Compuestas De Componentes De Despliegues De Objetos De Paquetes Diagramas de Comportamiento De Actividades De Interacción De Secuencias De Comunicación De Vistas de Interacción Temporales De Casos de Uso De Máquinas de Estado Los datos estructurados están constituidos por datos de tipo simple. Una ESTRUCTURA DE DATOS es una colección o conjunto de datos que tienen el mismo nombre. Fuente: OMG, 2003a © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

REQUERIMIENTOS DIAGRAMAS DE CASOS DE USO (1) Técnicas de Recolección Cliente Creados por el Analista Identifica uso que se le dará al software Analista REQUERIMIENTOS Técnicas de Recolección Describen como el sistema será usado Escenarios © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (2) Los Diagramas de Casos de Uso son utilizados en la Ingeniería de Requerimientos para especificar los requisitos funcionales del sistema Los requisitos funcionales de una aplicación se especifican mediante uno o más casos de uso. Cada caso de uso es documentado mediante una Descripción Textual. Cajero Automático Validar Tarjeta Retirar Efectivo Transferir entre Cuentas Usuario ATM Caso de Uso: Validar Tarjeta Actor: Usuario Flujo de Eventos: El usuario introduce la tarjeta. El sistema valida la tarjeta El sistema presenta el menú de opciones Descripción Textual

DIAGRAMAS DE CASOS DE USO (3) Los Diagramas de Casos de Uso modelan: Los Actores del sistema Los Casos de Uso Las Relaciones entre Actores Las Relaciones entre Casos de Uso Las Relaciones de Comunicación entre Actores y Casos de Uso. Los Límites del Sistema El Refinamiento o descomposición de los Casos de Uso.

DIAGRAMAS DE CASOS DE USO (4) Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: Relaciones entre Actores y Casos de Uso Limites del Sistema Caso de Uso Include 1 <<include>> Relaciones entre Casos de Uso Casos de Uso Caso de Uso 1 Uso 2 Uso 3 Actor 1 Actor 2 Relaciones entre Actores

Representación icónica DIAGRAMAS DE CASOS DE USO (2) Actores Representan papeles ejecutados por personas (o dispositivos) cuando el sistema está en operación. Es cualquier cosa que se comunique con el sistema y que sea externo al mismo. Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema. Se representa mediante una figura humana. Esta representación sirve tanto para actores que son personas como para otro tipo de actores. Un actor en un clasificador y no una ocurrencia, es decir, no se refieren a un individuo en particular, sino a una clase de individuos que tienen un rol común (un grupo de personas). Representación icónica El símbolo es usado para representar el rol que objetos externos, de una misma clase, juegan cuando interactúan con el sistema © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (3) Actores ACTORES PRIMARIOS Interactúan para lograr el funcionamiento requerido del sistema a fin de alcanzar el objetivo propuesto. Trabajan directamente con el software ACTORES SECUNDARIOS Dan soporte al sistema de tal forma que los actores primarios puedan hacer su trabajo © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (3) Relaciones entre Actores Usuario Se pueden establecer relaciones de generalización entre los actores Un rol general puede ser heredado por uno o más roles específicos Piloto Pasajero Administrador Pasajero Frecuente

DIAGRAMAS DE CASOS DE USO (3) Casos de Uso Expresa una unidad coherente de funcionalidad requerida por el sistema. Aportan una descripción acerca de cómo el sistema será usado. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. Se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (3) Comunicación Los actores se relacionan con los casos de uso mediante asociaciones. Una asociación modela la comunicación bidireccional entre un actor y un caso de uso. Envío de señales Envío de datos e información La comunicación es representada simplemente por una línea recta que se extiende de la figura del actor hacia el ovalo del caso de uso. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (3) Límites del Sistema Empleado para delimitar los limites del sistema, y representado por un rectángulo con color de fondo distintivo. La identificación del sistema se coloca en la parte superior izquierda. Nombre del Sistema © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (3) Relaciones entre Casos de Uso GENERALIZACIÓN Una generalización indica que un caso de uso (ovalo) es un caso especial de otro caso, en otros términos, representa una relación padre-hijo, donde el hijo puede ser suplido directamente por el padre en cualquier momento. Esta relación es representado por una línea con flecha que se extiende del caso de uso hijo hacia el caso de uso padre (general). Modela las relaciones en las cuales el comportamiento de un caso de uso general (padre) es heredado por uno o más casos de uso especializados (hijos) © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (3) Relaciones entre Casos de Uso Ejemplo de Generalización Reservación de Vuelos Actualizar Reservación Línea Aérea Realizar Reservación Modificar Reservación Eliminar Reservación © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (3) Relaciones entre Casos de Uso INCLUSIÓN Una inclusión es utilizada para indicar que un caso de uso (ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Es representada por una línea punteada con flecha y comentario <<include>> que se extiende del caso de uso base hacia el caso de uso de inclusión. Modelan relaciones en las cuales uno o más casos de uso incluyen (usan) el comportamiento de un caso de uso común. Son usados para compartir comportamiento común entre varios casos de uso. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

<<include>> DIAGRAMAS DE CASOS DE USO (3) Relaciones entre Casos de Uso Ejemplo de Inclusión Reservación de Vuelos Usar Reservación Registrar el Vuelo <<include>> Pasajero © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (3) Relaciones entre Casos de Uso EXTENSIÓN Una extensión representa una variación de un caso de usos a otro, aunque similar a una generalización, una extensión representa una dependencia especifica, mientras una generalización no implica que los casos de uso dependen uno del otro. Esta relación es representado por una línea punteada con flecha y comentario <<extend>> que se origina del caso de uso de extensión hacia el caso de uso base. Modelan relaciones en las cuales un caso de uso base incluye el comportamiento de una caso de uso extendido en uno o más puntos de su flujo de eventos. Estos puntos se denominan puntos de extensión. Tienen asociado una condición que determina cuando el caso de uso extendido es invocado por el caso de uso base. Son usadas para modelar separadamente el comportamiento excepcional del caso de uso base. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

<<extend>> DIAGRAMAS DE CASOS DE USO (3) Relaciones entre Casos de Uso Ejemplo de Extensión Reservación de Vuelos Realizar Reservación Reservar Multiples Destinos <<extend>> Pasajero Condición: Modo=Múltiples Destinos. Punto de Extensión: Verificar Modo © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO Muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Los casos de uso están en el interior de la caja del sistema. Los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

PASOS PARA ELABORAR DIAGRAMAS DE CASOS DE USO Identificar los límites del sistema. Identificar los actores. Para cada ACTOR, identificar sus objetivos. Definir casos de uso que satisfagan sus objetivos. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

REGLAS DE ESTILO PARA ELABORAR CASOS DE USO Cada actor y caso de uso debe tener un nombre único. Todos los actores se representan por una figura humana y deben tener nombres representativos. Los nombres deben indicar roles. El nombre de un caso de uso debe indicar acción y debe ser claro y conciso. Forma general = Verbo + Predicado Ejemplo: Actualizar Itinerarios Los casos de uso de un diagrama deben estar todos a un mismo nivel de abstracción. Evite el cruce de líneas. Evite tener demasiados casos de uso en un mismo diagrama. Use la regla 7 ± 2. Evite el uso complejo de relaciones de extensión e inclusión. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

DESCRIPCION TEXTUAL DE CASOS DE USO La simplicidad de los diagramas de casos de uso tienen un costo asociado Baja expresividad: El conjunto de acciones que ocurren entre un actor y el caso de uso no se pueden capturar con los símbolos de los diagramas. Cada caso de uso tiene asociado un flujo de eventos que indica el orden en que sus acciones se ejecutan. Este Flujo establece los detalles de la comunicación entre el caso de usos y los actores. Los flujos de eventos se describen separadamente usando DESCRIPCIONES TEXTUALES de casos de uso. Flujo de eventos principal (flujo feliz) Flujo de eventos alternativos. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

PLANTILLA PARA DESCRIPCION TEXTUAL DE CASOS DE USO © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

<<include>> EJEMPLO DE CASO DE USO (1) Punto de venta Procesar Venta Autenticarse <<include>> Cajero © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

EJEMPLO DE CASO DE USO (2) © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

EJEMPLO DE CASO DE USO (3)

EJEMPLO DE CASO DE USO (4)