Ingeniería del Software I 2er. Cuatrimestre 2002 Casos de Uso Gustavo Pifarre.

Slides:



Advertisements
Presentaciones similares
Metodologías para el desarrollo de aplicaciones Web.
Advertisements

U.M.L A/Gx. Diego Gutiérrez Application Analysis and Design.
TECNICATURA UNIVERSITARIA EN INFORMATICA
ANÁLISIS DE REQUERIMIENTOS
TEMA 8: DIAGRAMAS EN UML.
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
10º2 Sergio Posso. Jonatán Agualimpia. Julia Blandón. Docente:
MODELADO DE ANALISIS Y DISEÑO
Curso de Diseño y Construcción de Productos de Software CLASE 2
Prof. César Luza Montero
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno.
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
DIAGRAMAS DE CLASES Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando.
DESCRIPCION DEL PROBLEMA
Análisis y Diseño O.O. Click to add notes Preguntas del diseño :
Aspectos Avanzados de la Tecnología de Objetos
Modelo de Requisitos Centro ISYS Escuela de Computación
Diagramas de clases Modelan la vista estática del sistema
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Profesor: Miguel Angel Vidal
DSOO - María Eugenia Valencia
PLANEACION DE UNA ESTRUCTURA ORGANIZACIONAL
Ingeniería de Software Orientada a Objetos
DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
Ingeniería de Sistemas Requerimientos
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
Análisis y Diseño de Sistemas
* FRAUSTO JIMENEZ GABRIELA * * HERNANDEZ TORRES ANA LAURA * * MANDUJANO JUAN CARLOS * * NOVA MARIN YARELI PAULINA * * ZAVALA CORTE JOCELYN ARELI *
Ingeniería de Software Orientado a Objetos
UNIDAD 3: “Desarrollo Orientado a Objetos con UML”
DISEÑO DE SOFTWARE 1ª. Parte
Fundamentos de programación
Bases de Datos Modelamiento.
1 Diseño Orientado a Objetos Agustín J. González ELO-329: Diseño y Programación Orientados a Objetos 1er. Sem
Requerimientos Funcionales y Casos de uso
INGENIERIA DE SOFTWARE
CASOS DE USO Ing. Sonia Godoy H..
Capitulo III CASOS DE USO Los casos de uso son un fenómeno interesante, durante mucho tiempo, tanto en el desarrollo orientado a objeto como en el tradicional,
Ingeniería de software
¿Por qué Casos de Uso?.
1 Diseño Orientado al Objeto Agustín J. González ELO-326: Seminario de Computadores II 2do. Sem
Algunas Herramientas de Apoyo al Diseño de Software Agustín J. González ELO329: Diseño y programación orientados a objetos.
Importancia en la efectividad del:
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
Diagramas de Interacción.
LSI ES:E Departament de Llenguatges i Sistemes Informàtics Laboratori Enginyeria del Software : Especificació 1 LESE-7 Práctica ES:E – Parte II Metodología.
Christian Monrreal Gonzalez Daryl Silverman Aguilar Gone
Ingeniería de Software Laboratorio V
Ingeniería de Software
Diseño de Sistemas.
Taller de Sistemas de Programas Clase 5 Dpto. de Computación y T.I.
Ingeniería de Requisitos
Roles de Open UP.
MODELAMIENTO VISUAL Y UML
UML.
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Fundamentos del Análisis Orientado a Objetos
Modelan la vista estática del sistema Elementos básicos: Clases Relaciones Objeto: Representación de una entidad discreta (real o abstracta) - Estado:
PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO
Unified Modeling Language (Lenguaje de Modelamiento unificado)
UNIDAD 2: “Características del Modelado UML” CONTENDIDO Elaborado por: Ingeniero Harold Cabrera Meza Actualizado por: Ingeniero Nilson Albeiro Ferreira.
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
Análisis y Diseño de Aplicaciones 3º Educación Media Tecnológica
CONCEPTO DE CICLO DE VIDA 1 En los departamentos de Sistemas se debe definir un marco de referencia común que debe ser:  Pueda ser empleado por todos.
Fundamentos de Ingeniería de Software
Presentación De UML Lenguaje estándar para escribir planos de software Se usa para visualizar, especificar, construir y documentar los artefactos de un.
Entregables del Proyecto
Flujos de Trabajo Fundamentales Proceso Unificado de Desarrollo de Software.
Fase de Inicio Proceso Unificado de Desarrollo de Software.
Transcripción de la presentación:

Ingeniería del Software I 2er. Cuatrimestre 2002 Casos de Uso Gustavo Pifarre

Ingeniería del Software I - 1er C Agenda zIntrodución: Qué es un caso de uso? zLos casos de usos en el contexto de la captura de requerimeintos zArtefactos zPerfiles de trabajo zFlujo de trabajo

Ingeniería del Software I - 1er C Casos de Uso zUn sistema de software tiene sentido para dar servicios a sus usuarios. Los casos de usos son una herramienta para especificar los requisitos de un sistema mediante la descripción de los servicios que presta zUn caso de uso es un fragmento de funcionalidad que proporciona al usuario un resultado importante

Ingeniería del Software I - 1er C Casos de Uso zEl caso de uso se plantea desde el punto de vista del usuario, desde sus necesidades, su interacción y su propia evaluación de importancia zLos casos de uso pueden dirigir el proceso de desarrollo. Guían el diseño, la implementación y la prueba del sistema

Ingeniería del Software I - 1er C Casos de Uso zUsuario hace referencia a alguien o algo que interactua con el sistema. zLos requisitos reales son aquellos que agregan valor a los usuarios del sistema

Ingeniería del Software I - 1er C Captura de requerimientos zEnumerar los requerimientos candidatos zComprender el contexto del sistema yModelado del dominio yModelado del negocio zCapturar requerimientos funcionales zCapturar requerimientos no funcionales

Ingeniería del Software I - 1er C Captura de requerimientos zEl objetivo es desarrollar un modelo del sistema que se va a construir zLos casos de uso son una forma adecuada de crear ese modelo zLos requerimientos funcionales se estructuran naturalmente como casos de uso zLos requerimientos no funcionales están asociados en general a un caso de uso

Ingeniería del Software I - 1er C Artefactos zModelo de Casos de Uso yCasos de Uso yLos actores yDescripción de Arquitectura yGlosario yPrototipo de interfaz de usuario

Ingeniería del Software I - 1er C Modelo de casos de uso zEs el acuerdo entre los desarrolladores y el cliente zEs un modelo que contiene yActores yCasos de uso ySus relaciones

Ingeniería del Software I - 1er C Actor zEl modelo describe lo que hace el sistema para cada tipo de usuario zCada tipo de usuario será representado con uno o mas actores zCada sistema o dispositivo externo será representado con uno o mas actores zLos actores representan terceros fuera del sistema que colaboran con el sistema

Ingeniería del Software I - 1er C Actor zEl entormo de un sistema es el conjunto de todos los actores zLos actores suelen corresponder con trabajadores zEl rol del trabajador define lo que hace el trabajador en un proceso de negocio concreto zDotamos a cada trabajador con un caso de uso del sistema para cada uno de sus roles

Ingeniería del Software I - 1er C Actor zEl actor juega un papel por cada caso de uso con el que colabora zUna instancia de un actor es un usuario concreto que interactua con el sistema zCualquier entidad que se ajuste a un actor puede actuar como una instancia del actor

Ingeniería del Software I - 1er C Casos de uso zUn caso de uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia zUn caso de uso es una especificación zEspecifica el comportamiento de cosas dinámicas, de instancias de los casos de uso

Ingeniería del Software I - 1er C Descripción de Casos de uso zUn caso de uso tiene operaciones y atributos zUna descripción puede incluir: yDiagrama de estado yDiagrama de actividad yColaboraciones yDiagramas de secuencia

Ingeniería del Software I - 1er C Descripción de Casos de uso zLos diagramas de estado especifican el ciclo de vida de las instancias de los casos de usos en terminos de estados y transiciones entre los estados zCada transicion es una secuencia de acciones zLos diagramas de actividad describen el ciclo de vida con mas detalle describiendo la secuencia temporal de acciones dentro de una transición

Ingeniería del Software I - 1er C Descripción de Casos de uso zLos diagramas de colaboración y los de secuencia se emplean para describir las interaciones entre una instancia típica de un actor y la instancia típica de un caso de uso zLa instancia de una caso es la realización ( o ejecución) de un caso de uso zLos atributos de un caso de uso representan los valores que una instancia de un caso de uso utiliza y manipula durante la ejecución de su caso de uso

Ingeniería del Software I - 1er C Propiedades del modelo zEl único tipo de interacione en el modelo de casos de uso tiene lugar entre instancias de actores e instancias de casos de uso zEsto asegura que el modelo sea simple e intuitivo z Consideramos atómicas las instancias de los casos de uso zEl comportamiento de cada caso de uso puede interpretarse independiente de los otros

Ingeniería del Software I - 1er C Descripción de Arquitectura zContiene una vista de la arquitectura del modelo de casos de uso, que representa los casos de uso más significativos

Ingeniería del Software I - 1er C Glosario zDefine términos comunes importantes que los analistas utilizan al describir el sistema

Ingeniería del Software I - 1er C Prototipo de Interfaz zAyudan a comprender y especificar las interacciones entre actores humanos y el sistema

Ingeniería del Software I - 1er C Perfiles de trabajo

Ingeniería del Software I - 1er C Perfiles de trabajo zEs un puesto al cual se puede asignar una persona real. Una abstración de un ser humano con ciertas capacidades zCada perfil tiene una descripción de sus responsabilidades yAnalista de Sistemas yEspecificado de casos de uso yDiseñador de interfaz de usuario yArquitecto

Ingeniería del Software I - 1er C Analista de Sistemas zEs el responsible del conjunto de requisitos que están modelados en los casos de uso zEl analista es el responsable de delimitar el sistema, encontrando los actores y los casos de uso, asegurando que el modelo es completo y consistente zDirige el modelado y coordina la captura de requerimientos

Ingeniería del Software I - 1er C Especificador de casos de uso zEs el responsable de las descripciones detalladas de uno o más casos de uso

Ingeniería del Software I - 1er C Diseñador de interfaz de usuario zDan forma visual a las interfaces de usuario zEsto puede implicar el el desarrollo de prototipos de interfaces de usuario para algunos casos de usos, uno por cada actor

Ingeniería del Software I - 1er C Arquitecto zEs el responsable de la vista de arquitectura del modelo de casos de uso

Ingeniería del Software I - 1er C Flujo de Trabajo

Ingeniería del Software I - 1er C Flujo de Trabajo zEncontrar actores y casos de uso zPriorizar los casos de uso zDetallar un caso de uso zPrototipar la interfaz de usuario zEstructurar el modelo de casos de uso

Ingeniería del Software I - 1er C Encontrar actores y casos de uso zIdentificamos los actores y los casos de uso para: yDelimitar el sistema de su entorno yEsbozar quién y qué (actores) interactuan con el sistema, y que funcionalidad (casos de uso) se espera del sistema yCapturar y definir un glosario de términos comunes para la creación de descripciones detalladas de las funcionalidades del sistema ( es decir de los casos de uso)

Ingeniería del Software I - 1er C Encontrar actores y casos de uso zEsta actividad consta de cuatro pasos: yEncontrar los actores yEncontrar los casos de uso yDescribir brevemente cada caso de uso yDescribir el modelo de caso de uso completo

Ingeniería del Software I - 1er C Encontrar los actores zDepende del punto de partida zDos criterios para la elección ydebe existir al menos un usuario que represente al actor candidato ydebe existir coincidencia mínima entre los roles zEl analista de sistemas da nombre a los actores y los describe brevemente zDebemos identificar los actores que representan sistemas externos y los actores para el manteniminto y operación del sistema

Ingeniería del Software I - 1er C Encontrar los casos de uso zEl analista va repasando los actores y va proponiendo los casos de usos para cada actor zElegimos un nombre para cada caso de uso de forma que nos haga pensar en la secuencia de acciones concreta que añade valor a un actor. El nombre empieza generalmente con un verbo, y debe reflejar cuál es el objeto de la iteracción entre el actor y el sistema zRecordar que un caso de uso entrega un resultado que se puede observar y que añade valor a un actor en concreto

Ingeniería del Software I - 1er C Encontrar actores y casos de uso zEsta actividad consta de cuatro pasos: yEncontrar los actores yEncontrar los casos de uso yDescribir brevemente cada caso de uso yDescribir el modelo de caso de uso completo

Ingeniería del Software I - 1er C Priorizar casos de uso zEl propósito de esta actividad es determinar el grado de importancia de cada caso de usos, es decir cuales son: ynecesarios para el desarrollo en las primeras iteraciones ymás importantes para la definición de la arquitectura ymás exigentes en requerimiento no funcionales zLos resultados se recogen en la vista de arquitectura del modelo de casos de uso

Ingeniería del Software I - 1er C Detallar un caso de uso zDescribe su flujo de sucesos en detalle, incluyendo cómo comienza, termina e interactua con los actores zEl resultado de esta actividad es la descripción detallada de un caso de uso en particular en forma de texto y diagramas

Ingeniería del Software I - 1er C Estructura de la descripción zEl caso de uso define los estados que las instancias de los casos de uso pueden tener y la posible transición entre estos estados zElegir un camino básico completo y describir este camino en una seción de la descripción zEn secciones separadas caminos alternativos o desviaciones del camino básico (significativo)

Ingeniería del Software I - 1er C Qué incluir en la descripción? zEstado inicial (precondición) zComo y cuando comineza el caso de uso zEl prden requerido en el que las acciones se deben ejecutar zComo y cuando terminan zEstado finales (postcondición) zLos caminos no permitidos zDescripción de caminos alternativos

Ingeniería del Software I - 1er C Qué incluir en la descripción? zLa interación del sistema con los usuarios y que cambios producen zLa utilización de objetos, valores y recursos zDescribir explicitamente que hace el sistema (y separar la responsabilidad de los actores)

Ingeniería del Software I - 1er C Estructurar el modelo de casos de uso zEl modelo de casos de uso se estructura para: yExtraer descripciones de funcionalidad generales y compartidas que pueden ser utilizadas por descripciones más especificas (generalización) yExtraer descripciones de funcionalidad adicionales u opcionales que pueden extender descripciones más especificas (extensión) zEl resultado de esta actividad es un modelo más facil de entender y de trabajar con él