Tema 9: Método de Craig Larman

Documentos relacionados
Ingeniería de Software: Metodologías

Ingeniería de Software: Metodologías

QUÉ SON EL ANÁLISIS Y EL DISEÑO?

Análisis y Diseño Orientado a Objetos. 2 - Análisis

Interacción Persona - Ordenador

Ingeniería de Software: Metodologías

Proceso Unificado de Desarrollo de Software. 13 de sep de 2006

Tema 3: Diagramas de Casos de Uso. Arturo Mora Soto Octubre 2008

Fecha de elaboración: Julio de 2010 Fecha de última actualización:

Desarrollo Orientado a Objetos con UML C.E.C.yT. Juan de Dios Bátíz Paredes IPN Resumido y Reorganizado por Lic. Guillermo Cherencio

INGENIERIA DE SOFTWARE ING. FRANCISCO RODRIGUEZ

1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque:

Tema 4e: Proceso Unificado: Análisis

SILABO DEL CURSO DISEÑO DE SOFTWARE 1. DATOS GENERALES

MODULO III. Análisis y Diseño de Sistemas de Información INF-162 III. RUP. 3.1 Introducción. Facilitador: Miguel Cotaña 26 de Abril

UNIVERSIDAD RICARDO PALMA FACULTAD DE INGENIERIA EAP INGENIERIA INFORMATICA CICLO ACADEMICO 2003 II SILABO

Ingeniería de requerimientos de software: Análisis. Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes

Personas. Tecnología. Producto. Proceso

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS.

PROCESOS PARA LA INGENIERÍA DE SOFTWARE. Facultad de Estadística e Informática

UML (Unified Modeling Language) Octubre de 2007

Presentación de la Asignatura.

Obligatoria asignatura Programa elaborado por:

4/15/2010. Requerimientos de Software UARG.UNPA Requerimientos de Software. Requerimientos de Software

TEMA 4. PROCESO UNIFICADO

Oscar Alberto, Custodio Izquierdo Carlos Arturo, Hernández Torruco José Fecha de elaboración: 28 de Mayo de 2010 Fecha de última actualización:

El proceso de desarrollo. Angélica de Antonio,

ORGANIZACIÓN DOCENTE del curso

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA)

Programa Educativo: PROGRAMA DE ESTUDIO Área de Formación : Horas teóricas: Horas prácticas: Total de Horas: Total de créditos:

Unidad V. UML. Tema I. Conceptos Básicos Tema II. Definición de UML. Vocabulario Tema III. Elementos UML Tema IV. Diagramas.

Proceso Unificado de Desarrollo de Software. Fase de Inicio

Desarrollo Orientado a Objetos con UML

1. Preparar al estudiante para desarrollar aplicaciones de software utilizando un enfoque orientado a objetos.

Universidad Tecnológica Nacional Facultad Regional San Francisco. Ingeniería en Sistemas de Información. Análisis de Sistemas

El lenguaje Unificado de Modelado (UML)

El Lenguaje Unificado de Modelado (UML)

Universidad Salesiana de Bolivia Ingeniería de Sistemas

1. Preparar al estudiante para desarrollar aplicaciones de software utilizando un enfoque orientado a objetos.

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS Y SISTEMAS

INGENIERIA DE SOFTWARE ING. FRANCISCO RODRIGUEZ

Horas Contacto. Objetivos Se pretende que el estudiante asimile los conceptos fundamentales de análisis y diseño orientado a objetos

Procesos del software

PROGRAMA ANALÍTICO DE ASIGNATURA

Uso de Metodología ICONIX

UML y UP. Programa de Estudio.

INGENIERÍA DEL SOFTWARE

Proceso de Desarrollo de SW

UML y UP. Programa de Estudio.

Documentación de Requisitos con Casos de Uso

UML y UP. Programa de Estudio.

SEMESTRE: CREDITOS: 3 Horas Presénciales: 3 Horas de Acompañamiento: 1 Total Horas Semanales 4 CODIGO: Sistemas de Información

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO

Diseño de la Arquitectura Lógica con Patrones. mayo de 2008

Implementacion y prueba de unidades. Figura 2.1. El ciclo de vida del software. 1

Rational Unified Process

PROCESOS PARA LA INGENIERÍA DE SOFTWARE. Facultad de Estadística e Informática

Capacitación adquirida por el alumno al finalizar este modulo

Tema 7: Diagramas de Colaboración

octubre de 2007 Arquitectura de Software

UNT INGENIERIA INDUSTRIAL INGENIERIA DE SOFTWARE

Principios de la Tecnología de Objetos

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA)

División Académica de Informática y Sistemas

Unified modeling language

Universidad Ricardo Palma

Programación Orientada a Objetos

BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA

Por qué están fallando los sistemas de información (SI)?

PROCESO UNIFICADO: DISEÑO

A continuación se describe con mayor detalle cada una de tales unidades:

De Desempeño De Conocimiento SABERES ESENCIALES CONTENIDOS RUTA FORMATIVA Saber Conocer Nociones, Proposiciones, Conceptos Categorías

Tema 4: Diagramas de Casos de Uso

El Proceso Unificado de Desarrollo

Diagrama de Clases I: asociaciones

Introducción a la orientación a objetos y a UML

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Diseño de casos de prueba. Pruebas de SI OO

Sistemas de Información II. Análisis de Sistemas Orientado a Objetos

Prof. Mariano Mancuso. Sistemas de información y control diagrama de clases

Qué es RUP? RUP es un proceso de desarrollo de software: Objetivos: Es también un producto:

Ingeniería de Software: Y eso qué es?

1.1 Conceptualización de UML

Caracterización de los Procesos de Negocio

Horas Contacto. Modelar gráficamente la solución de problemas con un enfoque Orientado a Objetos, usando un lenguaje de modelado, en este caso UML.

Análisis y Diseño de Sistemas

Proceso Unificado (Iterativo e incremental)

CICLOS DE VIDA Y METODOLOGIAS

6.3 EDIFICACIÓN. [Proceso]

Applying UML and paterns (Capítulos 8, 9 y 10)

Marcos López Sanz Ingeniería del Software de Gestión. Introducción El proceso unificado Principios básicos Las 4 p

Tema 4c: El Proceso Unificado de Desarrollo

Los modelos de proceso que se discuten en este capítulo son:

PLANIFICACIÓN DE INGENIERÍA DEL SOFTWARE

Tema 6: Diagramas de Secuencia

INGENIERÍA DE SOFTWARE. Sesión 8: Tipos de diagramas

División Académica de Informática y Sistemas

Procesos y desarrollo de SW Proceso Unificado

diagramas de comportamiento con UML.

Transcripción:

Tema 9: Método de Craig Larman Maria-Isabel, Sanchez Segura Arturo, Mora-Soto Diagramas de UML Los diagramas expresan gráficamente partes de un modelo Use Case Use Case Use Case Diagrams Diagramas de Use Diagramas Case Diagrams Diagrams Casos de Uso Diagrams de Secuencia State Diagramas State Diagrams Diagrams de State Clases State Diagrams Diagramas de Diagrams Objetos Scenario Scenario Diagrams Diagramas de Diagrams Colaboración Modelo State State Diagrams Diagramas de Diagrams Componentes Scenario Scenario Diagrams Diagramas de Diagrams Estados Diagramas de Actividad Component Diagrams Component Diagramas Diagrams de Distribución Mora-Soto 1

Objetivos de la Asignatura Principios Básicos de OO Formato Gráfico Lenguaje UML Técnicas OO Metodologías OO Aprender a Construir Sw OO De Calidad 3 Proceso de Desarrollo Definido por Craig Larman. Visión General n El método definido por Craig Larman, es una versión reducida de uno de los modelos de proceso descritos en el proceso unificado (Unified Process UP). 4 Mora-Soto 2

RUP Áreas de trabajo (Workflow) Concepción Elaboración Construcción Transición Requerimientos Análisis & Diseño Construcción Pruebas Esfuerzo Necesario por Actividad R A & D C P R A & D C P R A & D C P R A & D C P Distribución D D D D Iteración Preliminar Iteración 1 Iteración 2........ Iteración n Iteración n+1 Tiempo Características del Proceso n Evolutivo n Incremental: Menos tiempo hasta tener algo funcionando Contrastable con el cliente / usuario n Dirigido por Casos de Uso: Desarrollar el software desde dentro hacia fuera. Mora-Soto 3

Proceso dirigido por los Casos de Uso Requisitos Análisis & Diseño Implementación Pruebas Casos de Uso integran el trabajo Capturar, definir y validar los casos de uso Realizar los casos de uso Verificar que se satisfacen los casos de uso Proceso dirigido por los Casos de Uso «trace» «trace» Caso de Uso Realización de Análisis Realización de Diseño «trace» Pruebas Funcionales X «trace» Pruebas Unitarias Caso de Prueba [The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999] Mora-Soto 4

Proceso de Desarrollo Definido por Craig Larman. Visión General n 3 macro-etapas: Planificación y Especificación de Requisitos: Planificación, definición de requisitos, construcción de prototipos, etc. Construcción: La construcción del sistema propiamente dicha Instalación: Puesta en marcha del sistema en el entorno previsto de uso 9 Proceso de Desarrollo: Guía Planificación y Especificación de Requisitos Construcción Instalación Ciclo de Desarrollo 1 Ciclo de Desarrollo 2... Refinamiento del Plan Sincronización de Modelos Análisis Diseño Implementación Pruebas 10 Mora-Soto 5

FASE: Planificación y Especificación de Requisitos n Actividades: Definir el Plan-Borrador Crear el Informe de Investigación Preliminar Definir los Requisitos Registrar Términos en el Glosario Implementar Prototipo Definir Casos de Uso Definir el Modelo Conceptual - Borrador Definir la Arquitectura del Sistema - Borrador Refinar el Plan 11 Definición de Requisitos n Requisito: descripción de necesidades o aspiraciones respecto a un producto. n Objetivo de esta actividad: Identificar qué es lo que realmente se necesita n Formato del documento de requisitos no definido por UML 12 Mora-Soto 6

Definición de Requisitos n Contenido recomendable del documento de requisitos: Propósito Ámbito y Usuarios Funciones del sistema: n ReqF1:... Atributos del Sistema n Calidad: ReqC1:... n Seguridad: ReqS1:... n Rendimiento: ReqR1:... 13 Planificación y Especificación de Requisitos n Actividades: Definir el Plan-Borrador Crear el Informe de Investigación Preliminar Definir los Requisitos Registrar Términos en el Glosario Implementar Prototipo Definir Casos de Uso Definir el Modelo Conceptual - Borrador Definir la Arquitectura del Sistema - Borrador Refinar el Plan 14 Mora-Soto 7

FASE: Planificación y Especificación de Requisitos n Actividades: Definir el Plan-Borrador Crear el Informe de Investigación Preliminar Definir los Requisitos Registrar Términos en el Glosario Implementar Prototipo Definir Casos de Uso Definir el Modelo Conceptual - Borrador Definir la Arquitectura del Sistema - Borrador Refinar el Plan 15 Planificación de Ciclos de Desarrollo Ciclo de Desarrollo Ciclo de Desarrollo Ciclo de Desarrollo Caso de Uso A Versión Simplificada Caso de Uso A Versión Completa Caso de Uso B Caso de Uso C 16 Mora-Soto 8

FASE: Construcción n Refinamiento del Plan n Sincronización de Modelos n Análisis n Diseño n Implementación n Pruebas 17 FASE: Construcción n Las actividades se encadenan en una minicascada con un alcance limitado por los objetivos de la iteración Análisis Diseño n veces Codific. Pruebas e Integración Mora-Soto 9

Proceso Iterativo e Incremental Enfoque Cascada Enfoque Iterativo e Incremental FASE: Construcción n Refinamiento del Plan n Sincronización de Modelos Ø Análisis n Diseño n Implementación n Pruebas 20 Mora-Soto 10

Análisis (I) n Se investiga sobre el dominio del problema, circunscrito únicamente a los casos de uso tratados en el presente ciclo n Se intenta llegar a una buena comprensión del problema n Está centrado en el qué más que en el cómo 21 Análisis (II) n Actividades: Definir Casos de Uso en Formato Expandido Refinar los Diagramas de Casos de Uso Refinar el Modelo Conceptual Refinar el Glosario Definir los Diagramas de Secuencia del Sistema Definir Contratos de Operación Definir Diagramas de Estado 22 Mora-Soto 11

Casos de Uso en Formato Expandido - Caso de Uso: Realizar Reintegro - Actores: Cliente (iniciador) - Propósito: Realizar una operación de reintegro de una cuenta del banco. - Visión General: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero y la tarjeta y se va. - Tipo: primario y esencial - Referencias: Funciones: R1.3, R1.7 - Curso Típico de Eventos: Acción del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero. 2. Pide la clave de identificación. 3. Introduce la clave. 4. Presenta las opciones de operaciones disponibles. 5. Selecciona la operación de Reintegro. 6. Pide la cantidad a retirar. 7. Introduce la cantidad requerida. 8. Procesa la petición y, eventualmente, da el dinero solicitado. Devuelve la tarjeta y genera un recibo. 9. Recoge la tarjeta. 10. Recoge el recibo. 11. Recoge el dinero y se va. - Cursos Alternativos: Línea 4: La clave es incorrecta. Se indica el error y se cancela la operación. Línea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operación. 23 Análisis n Actividades: Definir Casos de Uso en Formato Expandido Refinar los Diagramas de Casos de Uso Refinar el Modelo Conceptual Refinar el Glosario Definir los Diagramas de Secuencia del Sistema Definir Contratos de Operación Definir Diagramas de Estado 24 Mora-Soto 12

Análisis n Actividades: Definir Casos de Uso en Formato Expandido Refinar los Diagramas de Casos de Uso Refinar el Modelo Conceptual Refinar el Glosario Definir los Diagramas de Secuencia del Sistema Definir Contratos de Operación Definir Diagramas de Estado 25 Análisis Clase con detalles a nivel de análisis Termostato temperatura_deseada temperatura_muestreada establecer_temp () Clase con detalles de implementación Termostato +temperatura_deseada: Temperatura = 20 #temperatura_muestreada: Temperatura Clase con detalles suprimidos Termostato +establecer_temp (valor: Temperatura) 26 Mora-Soto 13

Análisis n Actividades: Definir Casos de Uso en Formato Expandido Refinar los Diagramas de Casos de Uso Refinar el Modelo Conceptual Refinar el Glosario Definir los Diagramas de Secuencia del Sistema Definir Contratos de Operación Definir Diagramas de Estado 27 Análisis CASO DE USO: Realizar Reintegro Curso Típico de Eventos 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero. 2. Pide la clave de identificación. 3. Introduce la clave. 4. Presenta las opciones de operaciones disponibles. 5. Selecciona la operación de Reintegro. 6. Pide la cantidad a retirar. 7. Introduce la cantidad requerida. 8. Procesa la petición y, eventualmente, da el dinero solicitado. Devuelve la tarjeta y genera un recibo. 9. Recoge la tarjeta. 10. Recoge el recibo. 11. Recoge el dinero y se va. Cliente insertartarjeta(númer o) entraridentificación(cla ve) solicitaroperación(operaci ón) realizarreintegro(cantidad ) dineroretirado() reciboretirado() tarjetaretirada() :cajero_automático 28 Mora-Soto 14

Análisis n Actividades: Definir Casos de Uso en Formato Expandido Refinar los Diagramas de Casos de Uso Refinar el Modelo Conceptual Refinar el Glosario Definir los Diagramas de Secuencia del Sistema Definir Contratos de Operación Definir Diagramas de Estado 29 Análisis: contratos de operación n Nombre: Nombre de la operación y parámetros. n Responsabilidades: Una descripción informal de las responsabilidades que la operación debe desempeñar. n Referencias Cruzadas: Números de referencia en los requisitos de funciones del sistema, casos de uso, etc. n Notas: Comentarios de diseño, algoritmos, etc. 30 Mora-Soto 15

Análisis: contratos de operación n Excepciones:Casos excepcionales. Situaciones que debemos tener en cuenta que pueden pasar. Se indica también qué se hace cuando ocurre la excepción. n Salida:Salidas que no corresponden a la interfaz de usuario, como mensajes o registros que se envían fuera del sistema. (En la mayor parte de las operaciones del sistema este apartado queda vacío) 31 Análisis: contratos de operación n Pre-condiciones:Asunciones acerca del estado del sistema antes de ejecutar la operación. Algo que no tenemos en cuenta que pueda ocurrir cuando se llama a esta operación del sistema. n Post-condiciones:El estado del sistema después de completar la operación. 32 Mora-Soto 16

Ejemplo de contrato de operación n n n n n n n n Nombre: insertartarjeta (número_tarjeta: número) Responsabilidades:Comenzar una sesión con el sistema para realizar una operación. Presentar las opciones disponibles. Referencias Cruzadas: Funciones del Sistema: R1.2, R1.6, R1.7 Casos de Uso: Reintegro Notas: Excepciones: Si la tarjeta es ilegible, indicar que ha habido un error. Salida: Pre-condiciones:No hay una sesión activa. Post-condiciones:Una nueva Sesión se ha creado. (creación de instancia).la Sesión se ha asociado con Cajero. (asociación formada). 33 Análisis n Actividades: Definir Casos de Uso en Formato Expandido Refinar los Diagramas de Casos de Uso Refinar el Modelo Conceptual Refinar el Glosario Definir los Diagramas de Secuencia del Sistema Definir Contratos de Operación Definir Diagramas de Estado 34 Mora-Soto 17

Construcción n Refinamiento del Plan n Sincronización de Modelos n Análisis Ø Diseño n Implementación n Pruebas 35 Diseño (I) n Solución a nivel lógico para satisfacer los requisitos n Se diseña cómo se va a comportar el sistema para realizar las funciones que se le solicitan n Se trabaja en un nivel muy cercano al software 36 Mora-Soto 18

Diseño n Actividades: Definir los Casos de Uso Reales Definir Informes e Interfaz de Usuario Refinar la Arquitectura del Sistema Definir los Diagramas de Interacción Definir el Diagrama de Clases de Diseño (en paralelo con los Diagramas de Interacción) Definir el Esquema de Base de Datos 37 Construcción n Refinamiento del Plan n Sincronización de Modelos n Análisis n Diseño Ø Implementación n Pruebas 38 Mora-Soto 19

Implementación n Lo especificado en la fase de Diseño se lleva a un lenguaje de programación. n Los elementos que forman la implementación se muestran con los diagramas: Diagrama de Componentes. Diagrama de Despliegue (o de Implantación). 39 Construcción n Refinamiento del Plan n Sincronización de Modelos n Análisis n Diseño n Implementación Ø Pruebas 40 Mora-Soto 20

Pruebas n Resultado de las pruebas según los niveles fijados: Se procede a ampliar el sistema con nuevos casos de uso. n Resultado por debajo de los niveles requeridos: Se refina lo abordado en el presente ciclo para mejorarlo. 41 Mora-Soto 21