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

Documentos relacionados
Tema 4e: Proceso Unificado: Análisis

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

PROCESO UNIFICADO: DISEÑO

Tema 9: Método de Craig Larman

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

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

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

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

UNT INGENIERIA INDUSTRIAL INGENIERIA DE SOFTWARE

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

UML (Unified Modeling Language) Octubre de 2007

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

Interacción Persona - Ordenador

PROGRAMA ANALÍTICO DE ASIGNATURA

Diagramas UML JUAN CARLOS CONDE RAMÍREZ INTRODUCTION TO PROGRAMMING

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

Ingeniería de Software. UML.

TEMA 4. PROCESO UNIFICADO

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

El Proceso Unificado de Desarrollo

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

Análisis y Diseño de Sistemas Clase 5 Ingeniería de Requerimientos El modelo de Casos de Uso

El lenguaje Unificado de Modelado (UML)

Unidad 7. Ingeniería de Requisitos y Análisis OO. M.C. Martín Olguín

El Lenguaje Unificado de Modelado (UML)

Análisis y Diseño de Sistemas

Tema 4f: Proceso Unificado: Diseño

FUNDAMENTOS DE LA VISTA DE CASOS DE USO

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

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

Diseño Basado en Componentes. UML aplicado al diseño basado en componentes. Tabla de contenidos. Introducción a UML. Definición e historia

Universidad Salesiana de Bolivia Ingeniería de Sistemas

Tema 4g: Proceso Unificado: Implementación

Ingeniería de Software: Metodologías

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

Presentación de la Asignatura.

PROCESO UNIFICADO CAPTURA DE REQUISITOS

UML: Lenguaje Unificado de Modelado

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

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

Tema 13 Modelos de Representación de Diagramas

UML El Lenguaje Unificado de Modelado Grady Booch, Jim Rumbaugh e Ivar Jacobson

Documentación de Requisitos con Casos de Uso

Caracterización de los Procesos de Negocio

Obligatoria asignatura Programa elaborado por:

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

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

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

12/08/2017. Casos de uso. Casos de uso. Casos de uso. Casos de uso

CLASE 3: UML DIAGRAMAS CASOS DE USO. Universidad Simón Bolívar. Ingeniería de Software. Prof. Ivette Martínez

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

Tema 1. Introducción a UML C H R I STO PHER E X P Ó S I TO I Z Q U I ERDO A I R A M E X P Ó S I TO M Á R Q UEZ I S R A E L LÓ P EZ P L ATA M A R Í A

ORGANIZACIÓN DOCENTE del curso

Ejemplo: Caso de Uso: Registrar perfil de ADN Ejemplo: Caso de Uso: Pagar factura Ejemplo: Cajero Automático

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

INGENIERIA DE SOFTWARE ING. FRANCISCO RODRIGUEZ

Ingeniería de Software: Metodologías

UN EJEMPLO: EL PROCESO UNIFICADO DE DESARROLLO (1ª parte)

diagramas de comportamiento con UML.

Ingeniería del Software de Gestión

T3-Análisis y Diseño del Sistema Software

UML. (Unified Modeling Language) Lenguage Unificado de Modelado

Sistemas de Información II. Modelo del Negocio

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

Trabajo Práctico Nro. 7. Herramientas para el Modelado de Comportamiento Básico: Diagramas y Especificaciones de Casos de Uso

TEMA 6: INTRODUCCIÓN A UML

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

Tema: Herramientas UML, Análisis y diseño UML

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

MANUAL DE TALLERES INGENIERÍA DE SOFTWARE

Tema 7: Elicitación de Requisitos. Departamento de Lenguajes y Sistemas Informáticos II

Tema: Herramientas UML, Análisis y diseño UML

Lenguaje de Modelamiento Unificado.

CASOS DE USO Exploración de Requerimientos

INGENIERÍA WEB. Dr. Mario Rossainz López Fac. de Cs. de la Computación Benemérita Universidad Autónoma de Puebla Otoño de 2017

INGENIERIA DE SOFTWARE ING. FRANCISCO RODRIGUEZ

Universidad de Guadalajara Centro Universitario de los Lagos PROGRAMA DE ESTUDIO FORMATO BASE SI X M= módulo

PROGRAMACIÓN ORIENTADA A OBJETOS. Dr. Noé Alejandro Castro Sánchez

Unified Modeling Language 2.0

1.1 Conceptualización de UML

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMERICA)

Curso: Desarrollo y Administración de Requerimientos

Objetivos: Descripción del curso. Curso: Dirigido a: UML PARA DESARROLLADORES I - ANÁLISIS y DISEÑO UNIVERSIDAD NACIONAL DE INGENIERÍA

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMERICA)

Sistemas de Información II. Diseño de Sistemas Orientado a Objetos

Ingeniería a de Software CC51A

Para esta práctica usaremos los diagramas de casos de uso, diagramas de secuencia, y los diagramas de clase.

Unified modeling language

Modelo Dinámico del Diseño del Software y Representación en UML. UNIDAD 9 Análisis y Diseño de Sistemas de Información

Unified Modeling Language 2.0

DIAGRAMAS UML ANDRÉS ESTEBAN MARTÍNEZ HUTA CICLO DE VIDA DEL SOFTWARE GLORIA CECILIA RÍOS MUÑOZ

octubre de 2007 Arquitectura de Software

INGENIERÍA DEL SOFTWARE

Ingeniería de Software

Tema 4c: El Proceso Unificado de Desarrollo

Programación Orientada a Objetos. Tema 8: Análisis y Diseño Orientado a Objetos

Examen de Ingeniería del Software / 2º de Informática de Sistemas 21 de junio de 2007

Transcripción:

Análisis y Diseño Orientado a Objetos 2 - Análisis El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 The unified software development process, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999

2. El en el Proceso Unificado Actividades Fases Concepción Elaboración Construcción Transición Requisitos Análisis Diseño Implementación Pruebas Iteración preliminar Itera. #1 Itera. #2 Itera. #n Itera. #n+1 Itera. #n+2 Itera. #m Itera. #m+1 Iteraciones Ingeniería del software 2

Análisis 1. Visión general. 2. El en el Proceso Unificado de Desarrollo. 2.1 Artefactos. 2.1.1 Modelo de. 2.1.2 Clases de. 2.1.3 Realización en de los casos de uso. 2.1.4 Paquetes de. 2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases. 2.2.3. Análisis de los paquetes. Ingeniería del software 3

2 Análisis Visión general Especificado por Modelo de Soportado por Modelo de diseño Modelo de casos de uso Distribuido por Implementado por Modelo de despliegue Modelo de implementación Verificado por Modelo de pruebas Ingeniería del software 4

2 Análisis Visión general Requisitos Modelo de Casos de Uso dependencia de traza Análisis Modelo de Análisis Diseño Modelo de Diseño Modelo de Despliegue Implementación Modelo de Implementación Pruebas Modelo de Pruebas Ingeniería del software 5

2 Análisis Visión general Modelo de Caso de Uso Modelo de Análisis Modelo de Diseño Modelo de Despliegue Diagramas de Casos de Uso Diagramas de Clases Diagramas de Componentes Diagramas de Despliegue Diagramas de Secuencias Diagramas de Colaboraciones Incluidos paquetes Diagramas de Interacción Modelo de Implementación Diagramas de Estados Diagramas de Actividad Modelo de Pruebas Diagramas de Objetos Ingeniería del software 6

2 Análisis Visión general - Durante la captura de requisitos: lenguaje del cliente. - Es impreciso: deja problemas sin resolver (ambigüedades). Modelo de : - especificación detallada (precisa) de requisitos. - refina los casos de uso como colaboraciones entre clasificadores: clasificadores: clases de, paquetes. colaboraciones: realizaciones de los casos de uso. Gestionar asignaturas Realización en UI asignaturas Gestor de asignaturas Asignatura Ingeniería del software 7

2. El en el Proceso Unificado 2.1 Artefactos. 2.1.1 Modelo de. 2.1.2 Clases de. 2.1.3 Realización en de los casos de uso 2.1.4 Paquetes de. 2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases. 2.2.3. Análisis de los paquetes. Ingeniería del software 8

2.1.1. Artefactos. Modelo de Artefactos Modelo de Clases de Realización en Paquetes de Actividades Descripción arquitectónica Representa la estructura global del sistema (subsistemas y/o capas en el modelo de diseño). Modelo de * * Paquete de Diagramas de clases Diagramas de interacción Descripción textual Responsabilidades Atributos Relaciones * * * * Clase de Realización en Interfaz Control Entidad Ingeniería del software 9

2.1.2. Artefactos. Clases de Artefactos Modelo de Clases de Realización en Paquetes de Actividades Representa una abstracción de lo que serán una o varias clases en diseño. Se centra en los requisitos funcionales. Clase de Res posabilidades Atributos Relac iones Interfaz Control Entidad Ingeniería del software 10

Utilizamos el ejemplo. Aplicación para los Perfiles de ADN Actor: Biólogo Caso de Uso: Registrar Perfil.. Aplicación Perfiles ADN Registrar Perfil Registrar Perfil Biólogo Ingeniería del software 11

2.1.2. Artefactos. Clases de. Interfaz Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Paquetes de Actividades Notación UML de las clases de interfaz: IU ADN <<boundary>> IU ADN IU ADN Relaciones permitidas: Con Actores y con clases de Control. Ejemplo representación: Biólogo IU ADN Ingeniería del software 12

2.1.2. Artefactos. Clases de. Interfaz Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Paquetes de Actividades Características de las clases de Interfaz: Modelan la interacción entre el sistema y los actores. Representan la interfaz de la aplicación (ventanas, formularios,...), pero con poco detalle o del sistema (incluye también todos los dispositivos de la interfaz). Describen la información presentada al actor y las peticiones que hace el actor al sistema. Ingeniería del software 13

2.1.2. Artefactos. Clases de. Control Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Paquetes de Actividades Notación UML de las clases de control: Gestor ADN <<control>> Gestor ADN Gestor ADN Relaciones permitidas: Con clases de interfaz, con otras clases de control y con clases de entidad. Nunca con actor. Ejemplo de representación: Biólogo IU ADN Gestor ADN Ingeniería del software 14

2.1.2. Artefactos. Clases de. Control Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Paquetes de Actividades Características de las clases de Control: Representan la coordinación entre objetos. Lógica del negocio, cálculos. Se usan para representar el control de un caso de uso concreto No representan ni interacciones con el actor ni problemas de almacenamiento de información. Ingeniería del software 15

2.1.2. Artefactos. Clases de. Entidad Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Paquetes de Actividades Notación UML de las clases de entidad: Usuario <<entity>> Usuario Usuario Relaciones permitidas: Con clases de control. Nunca con actor. Ejemplo de representación: Biólogo IU ADN Gestor ADN Usuario Ingeniería del software 16

2.1.2. Artefactos. Clases de. Entidad Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Paquetes de Actividades Características de las clases de Entidad: Representan la información significativa para el sistema. Modelan la información de larga vida (persistencia). Pueden provenir de las entidades del dominio o de las del negocio, pero no tienen por qué corresponderse completamente. Encapsulan información y operaciones asociadas.. Ingeniería del software 17

2.1.3. Artefactos. Realización en de los casos de uso Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Paquetes de Actividades - Es una colaboración que describe cómo se realiza en un caso de uso en términos de clases de y sus interacciones. Modelo de casos de uso Use case Modelo de <<trace>> Realización en Ingeniería del software 18

2.1.3. Artefactos. Realización en de los casos de uso Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Paquetes de Actividades La realización en de un caso de uso, incluye: - diagramas de clases: clases participantes y sus relaciones. - diagramas de interacción: escenarios del CU. - descripción textual del flujo de eventos - requisitos no funcionales (si aparecen). Ingeniería del software 19

2.1.3. Artefactos. Realización en de los casos de uso. Diagramas de clase Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Diagrama de clases Diagramas de interacción Paquetes de Actividades Biólogo IU ADN Gestor ADN usuario Diagrama de clases parcial para la realización del caso de uso Registrar Perfil ADN - Una clase de puede participar en varios casos de uso. - Algunas responsabilidades, atributos y asociaciones pueden ser específicos de un sólo caso de uso. Ingeniería del software 20

2.1.3. Artefactos. Realización en de los casos de uso. Diagramas de interacción - La secuencia de acciones en un caso de uso comienza cuando un actor envía un mensaje a una clase límite. - Se van a utilizar diagramas de colaboración. - Ejemplo: Caso de uso Registrar Perfil ADN del actor Biólogo 1: Login y pwd 2: Login y pwd del actor 3: Validar (usr y pwd) : Biólogo 5: Solicitar 6: visualizar 4: OK : IU ADN Información : Gestor ADN (Solicitud Perfil ADN información : Usuario Perfil ADN) Diagrama de colaboración parcial para la realización del caso de uso Registrar Perfil ADN Ingeniería del software 21

2.1.3. Artefactos. Realización en de los casos de uso. Flujo de eventos y Requisitos no funcionales Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Diagrama de clases Diagramas de interacción Flujo de eventos y requisitos no funcionales Paquetes de Actividades Flujo de eventos. - Para clarificar los diagramas de colaboración: descripción textual. - Si es muy complejo no será mejor dividir el caso de uso? Requisitos No funcionales. - Se recogen si aparecen y se asignan a casos de uso. Ingeniería del software 22

2.1.4. Artefactos. Paquetes de Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Diagrama de clases Diagramas de interacción Flujo de eventos y requisitos no funcionales Paquetes de Actividades Paquete de - Un paquete es un conjunto de clases (y otros elementos) relacionadas, generalmente relevante para un pequeño subconjunto de actores o suficientemente representativo por sí mismo, que puede implementarse o llevarse a cabo como una sola unidad. Ingeniería del software 23

2.1.4. Artefactos. Paquetes de Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Diagrama de clases Diagramas de interacción Flujo de eventos y requisitos no funcionales Paquetes de Actividades Cliente Transacciones Consultas Venta de entradas Cajero automático Mantenimiento Reposiciones Personal Mto Empleado Ingeniería del software 24

2.1.4. Artefactos. Paquetes de Artefactos Modelo de Clases de Interfaz Control Entidad Realización en Diagrama de clases Diagramas de interacción Flujo de eventos y requisitos no funcionales Paquetes de Actividades * Clase de * Paquete de Ingeniería del software 25 * Realización en - Para organizar los artefactos de : clases de, realización de casos de uso y otros paquetes. - Fuertemente cohesionados y débilmente acoplados. - No existen en tiempo de ejecución.

2. El en el Proceso Unificado 2.1 Artefactos. 2.1.1 Modelo de. 2.1.2 Clases de. 2.1.3 Realización en de los casos de uso 2.1.4 Paquetes de. 2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases. 2.2.3. Análisis de los paquetes. Ingeniería del software 26

2.2. Actividades Para ilustrar las actividades, utilizaremos el ejemplo del cajero automático. Sacar dinero <<include>> Cliente del banco Ingresar dinero Transferencia <<include>> <<include>> Validar usuario Ingeniería del software 27

2.2.1. Actividades. Análisis casos de uso Artefactos Actividades Análisis de los casos de uso Análisis de las clases Interfaz Control Entidad Análisis de los paquetes Identificar las clases de necesarias para la realización del caso de uso y representar el diagrama de clases. Distribuir el comportamiento del caso de uso entre las clases de. Capturar/asignar requisitos no funcionales a clases de. Ingeniería del software 28

2.2.1. Actividades. Análisis casos de uso. Identificación y representación de las clases de Artefactos Actividades Análisis de los casos de uso Identificación de clases de Representación del diagrama de clases Distribuir el comportamiento Análisis de las clases Análisis de los paquetes Clases entidad se derivan de la descripción del caso de uso (información persistente en el sistema). Una clase interfaz por cada actor (p.e.). Una clase de control que gobierne en flujo del caso de uso Representar las clases de en un diagrama de clases Ingeniería del software 29

Análisis del caso de uso. Identificación de las clases. Ejemplo Cajero: Validar usuario Artefactos Actividades Análisis de los casos de uso Identificación de clases de Representación del diagrama de clases Distribuir el comportamiento Análisis de las clases Análisis de los paquetes Validar usuario Interfaz de cajero Realización en UsuariosDelBanco (from Logical View) Autenticar (from Logical View) Ingeniería del software 30

Análisis del caso de uso. Identificación de las clases. Ejemplo Cajero: Validar usuario Artefactos Actividades Análisis de los casos de uso Identificación de clases de Representación del diagrama de clases Distribuir el comportamiento Análisis de las clases Análisis de los paquetes Interfaz de cajero Autenticar (from Logical View) UsuariosDelBanco (from Logical View) Diagrama de clases para la realización del caso de uso Validar usuario Ingeniería del software 31

2.2.1. Actividades. Análisis casos de uso Artefactos Actividades Análisis de los casos de uso Identificación de clases de Representación del diagrama de clases Distribuir el comportamiento Análisis de las clases Análisis de los paquetes Utilizar diagramas de colaboración 1 diagrama de colaboración por cada camino del caso de uso Sobre los diagramas de colaboración: inicia un actor expresión de las interacciones: mensajes Ingeniería del software 32

Análisis del caso de uso: Validar usuario Camino Básico 3: código 1: introducir tarjeta 4: autentica (datos, código) 7: visualiza (opciones) : Cliente del banco 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo) 8: Visualiza (opciones) 6: OK : UsuariosDelBanco Ingeniería del software 33

Análisis del caso de uso: Validar usuario Camino Alternativo: Código incorrecto 3: código 1: introducir tarjeta 4: autentica (datos, código) : Cliente del banco 2: teclear código 8: teclear código 7: visualiza (error) : Interfaz de cajero : Autenticar 5: valida (datos, codigo) 6: Error Faltan escenarios: - anular transacción (después del 2) - si 3 veces error: cancelar y quedarse con la tarjeta. : UsuariosDelBanco Ingeniería del software 34

Análisis del caso de uso: Sacar dinero Sacar dinero Realización en Interfaz de cajero Transacción (from Logical View) Cuenta (from Logical View) Cliente del banco Interfaz de cajero Transacción Cuenta (from Use Case View) Ingeniería del software 35

Análisis del caso de uso: Sacar dinero Camino básico 11: dinero retirado 9: tarjeta retirada 3: importe 1: sacar dinero 4: retirardinero (importe) : Cliente del banco 2: teclee importe 7: expulsadinero (importe) : Interfaz de cajero : Transacción 8: retirar tarjeta 5: obtener (importe) 10: retirar dinero 6: OK 12:Visualizar Introduzca su tarjeta : Cuenta Ingeniería del software 36

Análisis del caso de uso: Sacar dinero Camino Alternativo: No hay saldo 10: tarjeta retirada 3: importe 1: sacar dinero 4: retirardinero (importe) : Cliente del banco 2: teclee importe 7: no hay fondos : Interfaz de cajero : Transacción 8: no hay saldo suficiente 5: obtener (importe) 9: retirar tarjeta 6: no hay saldo 11: Visualizar Introduzca su tarjeta Faltan escenarios: - en el cajero no hay dinero. - se ha superado el límite diario : Cuenta Ingeniería del software 37

Análisis del caso de uso: Ingresar dinero Ingresar dinero Realización en Interfaz de cajero Transacción (from Logical View) Cuenta (from Logical View) Cliente del banco Interfaz de cajero Transacción Cuenta (from Use Case View) Ingeniería del software 38

Análisis del caso de uso: Ingresar dinero Camino básico 5: dinero introducido 6: validar (importe) 3: importe 1: ingresar dinero 7: ingresardinero (importe) : Cliente del banco 2: teclee importe 10: OK : Interfaz de cajero : Transacción 4: introducir dinero 11: dinero ingresado 9: OK 8: ingreso (importe) 12: Visualizar Introduzca su tarjeta : Cuenta Ingeniería del software 39

Análisis del caso de uso: Ingresar dinero Camino alternativo: Cantidad incorrecta : Cliente del banco : Interfaz de cajero Ingeniería del software 40

Análisis del caso de uso: Ingresar dinero Camino Alternativo: Cantidad incorrecta 5: dinero introducido 6: validar (importe) 3: importe 1: ingresar dinero : Cliente del banco 2: teclee importe : Interfaz de cajero 4: introducir dinero 7: importe incorrecto Ingeniería del software 41

Análisis del caso de uso: Transferencia La cuenta origen es la de la tarjeta y hay que teclear la destino. El importe y el nº de cuenta destino se solicitan al principio. Mirar primero si hay saldo y luego sacar. Transferencia Realización en Interfaz de cajero Transacción Cuenta (from Logical View) (from Logical View) Ingeniería del software 42

Análisis del caso de uso: Transferencia Camino básico 5: cuenta destino 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) : Cliente del banco 11: OK : Interfaz de cajero : Transacción 2: teclee cantidad 4: teclee cuenta destino 12: transferencia realizada 8: OK 7: obtener (cantidad) 9: ingreso (cantidad) 10: OK 13: Visualizar Introduzca su tarjeta cuentaorigen : Cuenta cuentadestino : Cuenta Ingeniería del software 43

Análisis del caso de uso: Transferencia C. Alternativo: No hay fondos en la cuenta origen 5: cuenta destino 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) : Cliente del banco : Interfaz de cajero : Transacción 2: teclee cantidad 7: obtener (cantidad) 4: teclee cuenta destino cuentaorigen : Cuenta cuentadestino : Cuenta Ingeniería del software 44

Análisis del caso de uso: Transferencia C. Alternativo: No hay fondos en la cuenta origen 5: cuenta destino 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) : Cliente del banco 9: no hay fondos : Interfaz de cajero : Transacción 2: teclee cantidad 7: obtener (cantidad) 4: teclee cuenta destino 8: no hay saldo 10: no hay fondos cuentaorigen : Cuenta Ingeniería del software 45

Análisis del caso de uso: Transferencia Camino Alternativo: Cuenta destino incorrecta 5: cuenta destino 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) : Cliente del banco : Interfaz de cajero : Transacción 2: teclee cantidad 4: teclee cuenta destino 8: OK 7: obtener (cantidad) 9: ingreso (cantidad) cuentaorigen : Cuenta cuentadestino : Cuenta Ingeniería del software 46

Análisis del caso de uso: Transferencia Cuenta destino incorrecta 5: cuenta destino 11: rollback 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) : Cliente del banco 12: error : Interfaz de cajero : Transacción 2: teclee cantidad 4: teclee cuenta destino 8: OK 7: obtener (cantidad) 9: ingreso (cantidad) 10: error 13: error 14:Visualizar Introduzca su tarjeta cuentaorigen : Cuenta cuentadestino : Cuenta Ingeniería del software 47

Diagrama de clases completo (ejemplo) Cuenta Cliente del banco Interfaz de cajero (from Use Case View) Transacción UsuariosDelBanco Por qué aparece solamente una clase de control? Dónde está Autenticar? Ingeniería del software 48

2.2.3. Actividades. Análisis de las clases Artefactos Actividades Análisis de los casos de uso Análisis de las clases Identificación de responsabilidades Identificación de atributos Distribuir el comportamiento Análisis de los paquetes Identificar las responsabilidades de las clases de Identificar atributos y relaciones de las clases de. Capturar requisitos especiales Ingeniería del software 49

2.2.3. Actividades. Análisis de las clases Artefactos Actividades Análisis de los casos de uso Análisis de las clases Identificación de responsabilidades Identificación de atributos Distribuir el comportamiento Análisis de los paquetes Identificar responsabilidades En cada caso de uso, ver qué papel juega (diagramas de colaboración). Combinar papeles y describirlos juntos. Ingeniería del software 50

Análisis de las clases. Identificar responsabilidades. Validar usuario. Secuencia correcta 3: código 1: introducir tarjeta 4: autentica (datos, código) : Cliente del banco 7: visualiza (opciones) 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo) 8: Visualiza (opciones) Interfaz de cajero visualizar teclear código leer código visualizar (opciones) Transacción autentica (datos, código) UsuariosDelBanco valida (datos, código) 6: OK : UsuariosDelBanco Ingeniería del software 51

Análisis de las clases. Identificar responsabilidades Validar usuario. Secuencia correcta 3: código 1: introducir tarjeta 4: autentica (datos, código) : Cliente del banco 7: visualiza (opciones) 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo) 8: Visualiza (opciones) Interfaz de cajero Visualizar (mensaje) leer código Transacción autentica (datos, código) UsuariosDelBanco valida (datos, código) 6: OK : UsuariosDelBanco Ingeniería del software 52

Análisis de las clases. Identificar responsabilidades Validar usuario. Código incorrecto 3: código 1: introducir tarjeta 4: autentica (datos, código) : Cliente del banco 2: teclear código 8: teclear código 7: visualiza (error) : Interfaz de cajero : Autenticar 5: valida (datos, codigo) Interfaz de cajero Visualizar (mensaje) leer código Transacción autentica (datos, código) UsuariosDelBanco valida (datos, código) 6: Error : UsuariosDelBanco Ingeniería del software 53

Análisis de las clases. Identificar responsabilidades Sacar dinero. Secuencia correcta Transacción 11: dinero retirado UsuariosDelBanco valida (datos, código) autentica (datos, código) 9: tarjeta retirada Cuenta retirardinero (importe) (4) retirar (importe) (5) 3: importe 1: sacar dinero 4: retirardinero (importe) : Cliente del banco 2: teclee importe 7: expulsadinero (importe) : Interfaz de cajero : Transacción Interfaz de cajero Visualizar (mensaje) leer código 8: retirar tarjeta 10: retirar dinero 12:Visualizar Introduzca su tarjeta 5: retirar (importe) 6: OK leer importe (3) expulsadinero (importe) (7) : Cuenta Ingeniería del software 54

2.2.3. Actividades. Análisis de las clases Identificar atributos Suelen ser nombres. Los tipos son conceptuales Clases entidad: derivados del dominio. Clases interfaz con actores humanos: formularios (campos de texto, etiquetas, ), informes (campos, etiquetas, ). Clases interfaz con subsistemas externos: propiedades de la interfaz de comunicación Clases control: estado de la sesión actual, variables. Ingeniería del software 55

Análisis de las clases. Identificar atributos Validar usuario. Secuencia correcta 3: código 1: introducir tarjeta 4: autentica (datos, código) : Cliente del banco 7: visualiza (opciones) 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo) 8: Visualiza (opciones) Interfaz de cajero 6: OK Transacción NumeroCuenta : UsuariosDelBanco UsuariosDelBanco colección (datoscuenta, codigo, numerocuenta) Ingeniería del software 56

Análisis de las clases. Identificar atributos Transferencia. Secuencia correcta 5: cuenta destino 3: cantidad Transacción NumeroCuenta cantidad 1: transferencia 6: transferencia (cuenta, cantidad) : Cliente del banco 11: OK : Interfaz de cajero : Transacción Interfaz de cajero Cuenta saldo UsuariosDelBanco 2: teclee cantidad 4: teclee cuenta destino 12: transferencia realizada 13: Visualizar Introduzca su tarjeta colección (datoscuenta, codigo, numerocuenta) 7: retirar (cantidad) 9: ingreso (cantidad) 8: OK 10: OK cuentaorigen : Cuenta cuentadestino : Cuenta Ingeniería del software 57

Análisis de las clases Clase Atributos Responsabilidades Interfaz de cajero Definir IU visualizar (mensaje) leer (código) leer (importe) expulsardinero (importe) validar (importe) leer (tarjeta) UsuariosDeBanco colección (datos, codigo, numerocuenta) valida (datos, código) Cuenta Saldo límite diario Retirar (importe) ingreso (importe) Transacción numerocuenta cantidad autenticar (datos, código) retirardinero (importe) ingresardinero (importe) transferencia (cuenta, cantidad) Ingeniería del software 58

2.2.4. Actividades. Análisis de los paquetes Paquetes débilmente acoplados Si se identifican las clases que tienen dependencia con clases de otros paquetes : estimar el efecto de cambios futuros reubicar clases contenidas en paquetes que son demasiado dependientes de otros paquetes. Elementos cohesionados Ingeniería del software 59