Ing. Ernesto Calderón Yarlequé
VENS
VENS
ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS con UML
Expositor:
Ing. Ernesto Calderón Yarlequé
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Público y Objetivos
Público al que va dirigido Cualquiera con la necesidad de aprender las capacidades y los
métodos de la tecnología orientada a objetos, especialmente aquellos involucrados con el desarrollo de sistemas complejos
Objetivos del Curso Luego de terminar el curso los participantes serán capaces de:
Explicar el proceso iterativo e incremental de desarrollo Definir los requerimientos del sistema desde el punto de vista del
usuario Crear un modelo orientado a objetos del comportamiento y
aspectos estructurales de los requerimientos del sistema Crear una arquitectura de sistema lógica Diseñar el sistema aplicando los conceptos de Abstracción,
encapsulamiento, herencia, polimorfismo y patrones
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tabla de Contenido
Introducción Profundización en el análisis y diseño orientado a objetos usando
UML Desarrollo iterativo e incremental
Una visión del ciclo de vida de desarrollo de sistemas usando un modelo iterativo e incremental
Comportamiento del sistema Análisis del comportamiento necesario en un modelo orientado
por casos de uso Desarrollo de escenarios para los casos de uso
Objetos y Clases Definición de objetos, clases, estereotipos y paquetes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tabla de Contenidos
Interacción entre Objetos Representación gráfica de un escenario
Encontrando las Clases Las aplicaciones del análisis por casos de uso para descubrir
clases en el sistema Definición de paquetes Dibujo del diagrama de clases
Relaciones Definir las relaciones necesarias para la interacción entre objetos
Operaciones y Atributos Definir estructura y comportamiento de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tabla de Contenidos
Herencia Aplicaciones del principio de generalización y especialización
para descubrir relaciones superclases / subclases Comportamiento de los Objetos
Desarrollo de diagramas de transición de estados para mostrar gráficamente el comportamiento de un objeto
Homogenización Descubrimiento de mezclas de clases en diferentes casos de
usos Arquitectura
Discusión de las “4+1” vistas de la arquitectura
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tabla de Contenidos
Mecanismos claves Discusión de la estrategias de los mecanismo claves
Diseño de Clases Diseño de la interfaz del usuario Incorporación de patrones
Diseño de Relaciones Soporte de relaciones en C++
Diseño de Atributos y Operaciones Soporte para atributos y operaciones en C++
Diseño para Herencia Soporte para herencia en C++
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tabla de Contenidos
Resumen Resumen del curso de análisis y diseño Lecturas Bibliografía
Problema de sueldos Requerimientos para un sistema de sueldos
Problema de sueldos Análisis y diseño de soluciones para el problema de sueldos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Introducción
Ud. será capaz de: Explicar la crisis del software Discutir las fortalezas de la tecnología de objetos Discutir dónde la tecnología OO puede ser usada Definir análisis y diseño Explicar el origen de UML
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplos extremos, PERO hay muchos desastres similares en una menor escala
Software failures reported by W. Wayt Gibbs in the September, 1994 issue of Scientific American
La Crisis del Software
El departamento de vehículos motorizados de California gastó más de $43 millones de dólares en un proyecto destinado a fusionar los sistemas de conductores y registro de vehículos
El sistema fue abandonado sin ni siquiera haber sido usado Un fallido esfuerzo de $165 millones de dólares de American Airlines de
vincular su software de reserva de pasajes con el sistema de reservaciones de Marriott, Hilton y Budget
El aeropuerto de Denver computarizó su sistema de equipaje, lo que resultó en millones de dólares perdidos por la demora en la apertura del aeropuerto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
La Crisis del Software
En marzo de 1989, Arthur Andersen reportó Más de $300 mil millones al año son gastados en actividades de
software comercial en los Estados Unidos Sólo el 8% resulta en software que es distribuido y funciona
¿Cuáles son las razones para la crisis del software? Base inestable Fallas en el manejo del riesgo La complejidad del software
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Base Inestable
Los requerimientos del negocio son ciclos de desarrollo más cortos Los usuarios esperan más en términos de flexibilidad
Los requerimientos iniciales usualmente están mal definidos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Fallas en el Manejo de Riesgos
EL ciclo de vida de cascada retrasa la identificación de problemas No hay pruebas de que el sistema funcionará hasta que está cerca de
ser terminado El resultado es de máximo riesgo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Complejidad de Software
La demanda del software de negocios se está incrementando Nadie entiende el sistema completo Los sistemas antiguos deben ser mantenidos, pero los desarrolladores
originales ya no están
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Fortalezas de la Tecnología de Objetos
Un solo paradigma Un solo lenguaje usado por los usuarios, analistas, diseñadores e
implementadores Facilidad para elaborar la arquitectura y lograr el reutilización de código Los modelos reflejan mejor el mundo real
Mayor precisión describiendo datos corporativos y procesos Descomposición basada en divisiones naturales Fácil de entender y mantener
Estabilidad Un pequeño cambio en los requerimientos no significa cambios
masivos en el sistema en desarrollo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un Simple Ejemplo de Ordenes de Compra
Orden
Item
Despacho via
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Vendedor Producto
Venta
Empresa
Cliente
Persona Camión
Vehículo
Tren
Diagrama de Clases para el Ejemplo de Ventas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Efecto del Cambio de Requerimientos
Vendedor Producto
Venta
Empresa
Cliente
Persona Camión
Vehículo
Tren
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Cuándo es Usado OO?
Sistemas basados en GUI OO trata de facilitar el diseño e implementación de sistemas con
GUIs
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Cuándo Usar OO?
Sistemas empotrados Los métodos OO permiten desarrollar sistemas empotrados y de
tiempo real de alta calidad y flexibilidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Plataformas PC
Estación de Trabajo
Interfaz de objetoDB y aplicaciones existentes
¿Cuándo Usar OO?
Computación Cliente/Servidor Los enfoques OO pueden encapsular información en objetos del
computador central, permitiendo la distribución de aplicaciones de pequeño tamaño
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Software Existente Software de Re-ingeniería
¿Cuándo es Usado OO?
Re-ingeniería Los métodos OO permiten que se aplique re-ingeniería a partes
del sistema, protegiendo las inversiones en software existente
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Análisis y Diseño Orientado a Objetos
OODAgregar detalles y
decisiones de diseño
Perspectiva del Desarrollador
OOAModelo de desarrollo de requerimientos
Perspectiva del Usuario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es el Lenguaje de Modelado Unificado (UML)?
UML es descrito en The Unified Modeling Language for Object-Oriented Development, de Grady Booch, Jim Rumbaugh, e Ivar Jacobson
Disponible en http:\\www.rational.com Basado en las experiencias personales de los autores Incorpora contribuciones de otros metodologistas Co-presentado a la OMG por Rational Software, Microsoft, Hewlett-
Packard, Oracle, Texas Instruments, MCI Systemhouse y otros
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Entradas a UML
Fusion
Descripción de operaciones,Numeración de mensajes
UML
Meyer
Condiciones de antes y después
Harel
Gráficos de estado
Wirfs-Brock
Responsabilidades
Embley
Clases Singleton,Visión de alto nivel
Odell
Clasificación
Shlaer - Mellor
Ciclo de vida del Objeto
Gamma, et.al
Marcos, diseños,notas
Booch
JacobsonRumbaugh
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Evolución de UML
Industrialización
Estandarización
Unificación
Fragmentación
Booch ´91
Booch ´93
Unified Method 0.8
UML 1.0
OMT - 2
OMT - 1 OOSE
UML 0.9 & 0.91
OOPSLA ´95
Junio ´96 & Oct ´96
Envio a la OMGpara adopción, Julio ´97
Otros métodos
Feedbackpúblico
Publicación delEstandar 1.0 Dic ´96
UML PartnersExpertise
UML 1.1
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Beneficios del Lenguaje de Modelado Unificado
Define un mapa parecido para el análisis y el diseño de implementaciones
Define una notación expresiva y consistente Hace más fácil el comunicarse con otros Ayuda a detectar omisiones e inconsistencias Permite análisis y diseño a pequeña y gran escala
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Introducción Nuevas técnicas de desarrollo son necesarias para mitigar la crisis del
software Los requerimientos no son estables El software se ha vuelto muy complejo Los clientes demandan flexibilidad
La tecnología de Objetos tiene muchos puntos fuertes Un solo paradigma Los modelos reflejan el mundo real Facilitan la arquitectura y el reuso de código Provee gran flexibilidad
Un pequeño cambio en los requerimientos no significa cambios masivos en el sistema en desarrollo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Introducción (cont.)
OO está siendo usado para diferentes tipos de sistemas Basados en GUI, empotrados, computación cliente/servidor, y re-
ingeniería El análisis orientado a objeto es un método de análisis en el cual los
requerimientos son expresados en términos de los objetos encontrados en el problema
Enfocado en el QUE En el diseño orientado a objetos el modelo de análisis es transformado
en un modelo de diseño por medio de la refinación de éste, agregando detalles y capturando las decisiones de diseño necesarias para implementar el modelo
Enfocado en el COMO
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Introducción (cont.)
El Lenguaje de Modelado Unificado (UML por sus siglas en inglés) fue desarrollado por Grady Booch, Jim Rumbaugh, e Ivar Jacobson en colaboración con un número de otros colaboradores, basados en sus experiencias colectivas.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Comportamiento del sistema
Usted será capaz de: Definir el comportamiento del sistema Definir casos de uso y actores Entender cómo documentar casos de uso Usar un diagrama de caso de uso para mostrar los actores, los casos
de uso, y sus interacciones Definir los escenarios para los casos de uso
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es el comportamiento del sistema?
El comportamiento de un sistema es cómo un sistema actúa y reacciona
La actividad exterior visible y “testeable” de un sistema El comportamiento del sistema es capturado en los casos de uso
Ellos describen el sistema, su ambiente, y la relación entre el sistema y su ambiente
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Actor
Use-Case
Conceptos importantes al modelar el caso de uso
Un actor representa cualquier cosa que interactúe con él sistema
Un caso de uso es una secuencia de acciones que un sistema realiza, que produce un resultado observable de valor para un agente
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El propósito primario del modelo caso de uso es comunicar las funcionesy el comportamiento del sistema al cliente o al usuario final
El propósito primario del modelo caso de uso es comunicar las funcionesy el comportamiento del sistema al cliente o al usuario final
¿Qué es un modelo de Caso de Uso?
Un modelo de caso de uso es un modelo de las funciones previstas del sistema (casos de uso) y su entorno (actores)
El mismo modelo de caso de uso es usado en análisis de requisitos, diseño y prueba
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Beneficios del modelo de Casos de Usos
El modelo de casos de usos Es usado para comunicarse con el usuario final y el experto del
dominio Proporciona credibilidad en una etapa inicial del desarrollo
del sistema Asegura una comprensión mutua de los requisitos
Es usado para identificar Quién interactuará con el sistema y qué deberá hacer el
sistema Qué interfaz deberá tener el sistema
Es usado para verificar que: Se capturan todos los requisitos Que los desarrolladores hayan entendido los requisitos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Actores
Los actores no son parte del sistema, ellos representan roles que un usuario del sistema puede desempeñar
Un actor puede intercambiar activamente la información con el sistema
Un actor puede ser un recipiente pasivo de la información
Un actor puede representar a un humano, una máquina u otro sistema
Actor
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Encontrando Actores: Preguntas Útiles
¿Quién está interesado en cierto requisito? ¿Dónde en la organización se utilizará el sistema? ¿Quién proveerá, utilizará y eliminará esta información del sistema? ¿Quién utilizará esta función? ¿Quién le dará soporte y mantenimiento al sistema? ¿Usa el sistema un recurso externo? ¿Qué actores necesita el caso de uso? ¿Un actor desempeña varios roles? ¿Varios agentes desempeñan el mismo rol?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Instancias de Actores
1 2 34 5 67 8 9* 0 #
Insert card
Ivar actúacomo unactor
Tom actúacomo unactor
Modelo de Caso de uso
Actor Caso de uso
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un usuario puede actuar como varios actores
1 2 34 5 67 8 9* 0 #
Insert cardCharlie como
operador
Cliente
Operador
Charlie comocliente
Charlie
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Límites de los actores y del sistema
MantenimientoATM
CajeroBancario
¿Límite del Sistema?
Sistema ATM
Sistema Bancario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Casos de Uso
Un caso de uso modela un diálogo entre los actores y el sistema
Un caso de uso puede ser iniciado por un actor para invocar una cierta funcionalidad en el sistema
Un caso de uso es un flujo de eventos completos y significativos
Tomados al mismo tiempo, todos los casos de uso constituyen todas las formas posibles de utilizar el sistema
Caso de Uso
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Encontrando Casos de Uso: Preguntas Útiles
¿Cuáles son las tareas de este actor? ¿El actor, creará, guardará, cambiará, eliminará o leerá la información
en el sistema? ¿Cuál caso de uso creará, guardará, cambiará, eliminará o leerá esta
información? ¿Necesitará el actor informar al sistema sobre cambios externos e
imprevistos? ¿Es necesario que el actor esté informado sobre ciertas ocurrencias en
el sistema? ¿Le proporciona una correcta secuencia el sistema a las tareas? ¿Cuáles casos de uso le darán soporte y mantenimiento al sistema? ¿Pueden todos los requerimientos funcionales ser realizados por los
casos de uso?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Fuentes de Información para Casos de Uso
Especificaciones del sistema / Manifestación del problema Literatura relevante del dominio Entrevistas con expertos del dominio Conocimiento personal del dominio Sistema heredados
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Cliente
Realizar Transacciones
ATM Mantenimiento
Mantener maquina ATM
Realiza reportes
Banco
El Diagrama de Caso de Uso Un diagrama de un caso de uso ilustra como los casos de uso y los
actores interactúan, enviándose estímulos entre ellos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Documentación de Caso de Uso
Los casos de uso están documentados en Una breve descripción
El propósito del caso de uso en unas pocas líneas Flujo de eventos detallados
Descripción del flujo de eventos primario y alternativos que ocurren cuando el caso de uso es iniciado
La documentación debe leerse como un diálogo entre el actor y el caso de uso
Ambos documentos están escritos en términos que el cliente entenderá
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Flujo de Eventos Caso de Uso
Cada caso de uso Tiene una secuencia de transacciones normal y básica Puede tener varias secuencias de transacciones alternativas Generalmente tiene varias secuencias de transacciones
excepcionales, las cuales manejan situaciones de error También puede tener pre y post condiciones bien definidas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Flujo de Eventos Caso de Uso (cont.)
Describe solamente los eventos que pertenecen al caso de uso, y no los que suceden en otros casos de uso
Evita terminología vaga tal como “por ejemplo”, “etc.” e “información”. El flujo de eventos debe describir:
Cómo y cuándo comienza y termina el caso de uso Cuándo el caso de uso interactúa con los actores Qué información se intercambia entre un actor y el caso de uso
No describe los detalles de la interfaz del usuario El flujo de eventos básico Cualquier flujo de eventos alternativo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Quién Lee la Documentación de Casos de Uso?
Clientes -- aprueban lo que debe hacer el sistema
Usuarios -- obtienen comprensión del sistema
Desarrolladores del Sistema -- documentan el comportamiento del sistema
Revisores --examinan el flujo de eventos Analistas del Sistema (Diseñadores) --
proveen la base para un análisis y diseño “Probador” del Sistema -- usado como
base para casos de prueba Líder de Proyecto -- provee entradas para
el planeamiento de proyectos Escritor Técnico -- base para escribir la
guía del usuario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo de Registro en Curso
Al comienzo de cada semestre, los estudiantes pueden requerir información de un catálogo de cursos, el cual contiene una lista de los cursos ofrecidos para el semestre, indicando para cada curso profesor, departamento y prerequisitos. Información que es incluida para ayudar a los estudiantes a tomar decisiones.
El nuevo sistema permitirá a los estudiantes seleccionar cuatro cursos para el siguiente semestre. Además, cada estudiante podrá indicar dos cursos alternativos en caso de no poder ser asignado en su primera selección. El curso tendrá un máximo de diez estudiantes y un mínimo de tres. Un curso con menos de tres estudiantes será cancelado. Una vez que el proceso de registro es completado , el sistema de registro envía la información al sistema de cobranzas, para que al estudiante le puedan cobrar por el semestre.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo de Registro en Curso (cont.)
Los profesores deben ser capaces de acceder al sistema on-line para indicar qué cursos estarán enseñando. También necesitarán ver qué estudiantes se inscribieron para sus cursos.
Para cada semestre, existe un período de tiempo en el que los estudiantes pueden modificar sus horarios. Los estudiantes deben ser capaces de acceder el sistema durante este tiempo para agregar o retirarse de cursos.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de un Caso de Uso
Estudiante
Sistema de Cobranzas Registrar
Cursos a tomar
Solicitar lista de Curso
Seleccionar Cursos a enseñar
Profesor
Mantener Info de estudiante
MantenerInfo del Profesor Mantener Información de
Curso
Generar Catálogo
Registrador
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Breve Descripción -- Registrar Cursos a Tomar
1.1 Breve Descripción
Este caso de uso es iniciado por un estudiante. Le entrega al estudiante la capacidad de crear, borrar, modificar y/o revisar un programa de cursos para un semestre dado.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar2.1 Pre-condiciones
Ninguna2.2 Flujo principal
Este caso de uso comienza cuando el estudiante ingresa el número de alumno. El sistema verifica que éste sea válido (E-1) y le lleva al estudiante a seleccionar el semestre actual o un semestre a futuro (E-2). El estudiante ingresa el semestre deseado. El sistema le indica al estudiante que elija la actividad deseada: CREAR, REVISAR, MODIFICAR, IMPRIMIR, BORRAR, o ABANDONAR.Si la actividad seleccionada es
CREAR, el A-1: Se ejecuta un subflujo de Crear un Nuevo Programa .
REVISAR, el A-2: Se ejecuta un subflujo de Revisar un Programa .
MODIFICAR, el A-3: Se ejecuta un subflujo de Modificar un Programa .
IMPRIMIR, el A-4: Se ejecuta un subflujo de Imprimir un Programa.
BORRAR, el A-5: Se ejecuta un subflujo de Borrar un Programa .ABANDONAR, el caso de uso termina.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar(cont.)
2.3 Flujos alternativosA-1: Crear un nuevo Programa El sistema muestra en la pantalla un programa en blanco. El estudiante
ingresa el número de cuatro ofrecimientos de cursos primarios y dos números de cursos alternativos (E-3). El estudiante entonces presenta su petición de cursos. Por cada selección primaria de curso el sistema revisará que los pre-requisitos sean cumplidos (E-4) y agregará al estudiante al curso, si éste está abierto (E-5). El sistema imprimirá el programa (E-6) y enviará la información de la cuenta al sistema de cuenta para ser procesada (E-7). Luego el caso de uso comienza de nuevo.
A-2: Revisar un programa El sistema recupera la información de todos los cursos ofrecidos en los que
el estudiante se encontraba registrado (E-8) y muestra lo siguiente : nombre del curso, número del curso, números de los cursos ofrecidos, días de la semana, hora, ubicación y número de horas de créditos. Cuándo el usuario indica que él / ella ya ha terminado la revisión, el caso de uso comienza nuevamente.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar (cont.)
A-3: Modificar un programaEl sistema revisa que no haya sido excedida la fecha final para los cambios
(E-9). El sistema recupera la información anterior de todos los ofrecimientos de curso en los cuales el estudiante se encontraba registrado (E-8) y muestra en la pantalla: nombre del curso, número del curso, número de los cursos ofrecidos, días de la semana, hora, ubicación y número de horas de créditos. El sistema le indica al usuario que seleccione la actividad deseada: BORRAR UN CURSO OFRECIDO, AGREGAR UN CURSO OFRECIDO, o ABANDONAR.
Si la actividad seleccionada es BORRAR UN CURSO OFRECIDO, el A-6: Se ejecuta un subflujo
de borrar un curso ofrecido.AGREGAR UN CURSO OFRECIDO, el A-7: Se ejecuta el
subflujo de agregar un curso ofrecido.ABANDONAR, el sistema imprime el programa al estudiante (E-6)
y el caso de uso vuelve a comenzar.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar(cont.)
A-4: Imprimir un programaEl sistema imprime el programa (E-6). El caso de uso comienza de nuevo.
A-5: Borrar un programaEl sistema recupera información (E-8) y muestra el programa actual. El
sistema pide al usuario que confirme la opción de borrar programa. Si es aceptada, se elimina el programa del sistema. Si el borrar no se confirma, la operación es cancelada y el caso de uso comienza de nuevo.
A-6: Borrar un curso ofrecidoEl estudiante ingresa el número del ofrecimiento a borrar. El sistema pide al
usuario que confirme esta opción de borrar el curso ofrecido. Si es aceptada, el curso ofrecido es eliminado del programa del estudiante. Si el borrar no es confirmado, la operación es cancelada y el flujo alternativo del caso de uso comienza de nuevo.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Flujo de Eventos -- Caso de Uso Registro en Cursos (cont.)
A-7: Agregar un curso ofrecidoEl estudiante ingresa el curso a agregar. El sistema revisará que se
cumplan los pre-requisitos (E-4) y agregará el estudiante al curso ofrecido, si éste se encuentra abierto (E-5). El flujo alternativo de caso de uso comienza de nuevo.
E-1: Excepciones de flujosE-1: Se ingresa un número de alumno no válido. El usuario puede re-
ingresar un número de alumno o terminar el caso de uso.E-2: Se ingresa un semestre no válido. El usuario puede re-ingresar un
semestre o terminar el caso de uso.E-3: El número del ofrecimiento de curso no es válido (rango). El usuario
puede re-ingresar un número válido o terminar el caso de uso.E-4: El usuario no satisface todos los pre-requisitos requeridos. El usuario es informado de por qué este curso no podrá ser programado. Si es posible, se sustituye por un curso alternativo. El caso de uso continúa.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Flujo de Eventos -- Caso de Uso Registro en Cursos (cont.)
E-5: El usuario es informado que el ofrecimiento de curso seleccionado está cerrado. Si es posible, se sustituye por un curso alternativo. El caso de uso continúa.
E-6: El programa no puede ser impreso. La información está guardada y el usuario es informado de que debe volver a presentar una solicitud de imprimir programa. El caso de uso continúa. E-7: El sistema guardará toda la información de cuentas de pago y la volverá a presentar al sistema de cuentas en una próxima fecha. El caso de uso continúa.
E-8: El sistema no puede recuperar información de un programa. El caso de uso, entonces, comienza desde el principio.
E-9: El sistema le informa al usuario que su programa no puede ser modificado. Entonces el caso de uso comenzará desde el principio.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué son Escenarios?
Un escenario es una instancia de un caso de uso es un solo flujo a través de un caso de uso
Cada caso de uso tendrá una red de escenarios Escenarios primarios
Flujo normal - la forma en la que el sistema debiese funcionar
Escenarios secundarios Excepciones al escenario primario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un Escenario para el Caso de Uso “Registrar Cursos a Tomar”
John ingresa su número de alumno 369 52 3449 y el sistema valida el número. El sistema pregunta por cuál semestre. John indica el semestre actual y elige crear un nuevo programa.
De una lista de cursos disponibles, John selecciona los cursos primarios Inglés 101, Geología 110, Historia Mundial 200, y Álgebra 110. Luego selecciona los cursos alternativos de Teoría de la Música 110 e Introducción a Programación Java 180.
El sistema determina que John cumple con todos los pre-requisitos necesarios y lo agrega a la lista de cursos.
El sistema indica que la actividad está completa. El sistema imprime el programa al estudiante y envía la información de cuenta de pago de cuatro cursos al sistema de cuenta para ser procesada.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Escenarios Secundarios
¿Cuáles son algunos de los escenarios secundarios para el caso de uso “Registro de Cursos”?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Escenarios Secundarios (cont.)
Algunos escenarios secundarios a considerar son: El estudiante no selecciona cuatro cursos primarios El curso primario no está disponible Cursos primarios y secundarios no están disponibles No es posible agregar al estudiante a la lista de curso No se puede crear el programa del estudiante
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Cuántos Escenarios se necesitan?
Respuesta simple: tantos como sea necesario para entender el funcionamiento del sistema.
Regla del pulgar: Escenarios primarios
Elabore aproximadamente el 80% de estos escenarios Escenarios secundarios
Elabore unos pocos de los escenarios secundarios interesantes y de alto riesgo.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Comportamiento del Sistema
Utilizando el problema entregado por el instructor Dibuje un diagrama de caso de uso Escriba una definición para cada actor Para un caso de uso
Escriba una breve descripción (dos oraciones máximo) Escriba el flujo de eventos Enumere algunos posibles escenarios
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Comportamiento del Sistema
El comportamiento de un sistema es cómo éste actúa y reacciona El comportamiento de un sistema puede ser caracterizado por un
conjunto de casos de uso Un caso de uso es una cierta funcionalidad que se ejecuta por el
sistema en respuesta a un estímulo proveniente de un actor externo Ellos proveen un vehículo de captura para los requerimientos
sobre un sistema desde el punto de vista del usuario Un actor es alguien o algo que se debe acoplar con el sistema en
desarrollo Un diagrama de un caso de uso es una representación gráfica del
sistema el cual muestra los actores y casos de uso identificados para el sistema
La documentación de un caso de uso consiste en una breve descripción y en un flujo de eventos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Objetos y Clases
Usted será capaz de : Definir y dar ejemplos de objetos Definir y dar ejemplos de clases Describir la relación entre clases y objetos Definir estereotipos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Informalmente, un objeto representa una entidad, física, conceptual o programa
Entidad física
Entidad conceptual
Entidad programa
Camión
Proceso Químico
Lista Enlazada
¿Qué es un Objeto?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Una Definición Formal
Un objeto es un concepto, una abstracción o una cosa con límites bien definidas y significado para una aplicación
Un objeto es algo que tiene: Estado Comportamiento Identidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Nombre: Joyce ClarkNº Empleado: 567138Fecha de Contr.: 21 de marzo 1987Estado: Adjunto
Profesor Clark
a + b = 10
Un Objeto Tiene Estado
El estado de un objeto es una de las posibles condiciones en que el objeto puede existir
El estado normalmente cambia en el transcurso del tiempo El estado de un objeto es implementado por un conjunto de
propiedades (llamadas atributos), con los valores de las propiedades, además de las conexiones que deben tener con otros objetos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Curso Algebra 101
Asignar profesor (Clark)
(Retorna:confirmación) Registro del
Sistema
a + b = 10
Un Objeto Tiene Comportamiento
El comportamiento de un objeto determina cómo éste actúa y reacciona frente a las peticiones de otros objetos
El comportamiento de un objeto es modelado por un conjunto de mensajes a los que puede responder (las operaciones que el objeto puede realizar)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Profesor “J Clark”enseña Algebra
Profesor “J Clark”enseña Algebra
Profesor “J Clark”enseña Algebra
Un Objeto tiene Identidad
Cada objeto tiene una identidad única, incluso si su estado es idéntico al de otro objeto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué son las Clases?
Hay muchos objetos identificados para cada dominio Una clase es una descripción de un grupo de objetos con
propiedades en común (atributos), comportamiento similar (operaciones), la misma manera de relacionarse entre objetos (asociaciones y agregados) y una semántica en común
Un objeto es una instancia de una clase Una clase es una abstracción en que:
Se enfatizan las características relevantes Se suprimen otras características
La abstracción nos ayuda a trabajar con cosas complejas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo de una Clase
a + b = 10
ClaseCurso
EstructuraNombre
UbicaciónDías ofrecidos
CréditosHora de inicio
Hora de término
ComportamientoAgregar un alumnoBorrar un alumno
Entregar una lista del cursoDeterminar si está lleno
Ing. Ernesto Calderón Yarlequé
VENS
VENS
ObjetosProfesor
Profesor Smith
Profesor Jones
Profesor Mellon
La Relación Entre Clases y Objetos Una clase es una definición abstracta de un objeto
Define la estructura y el comportamiento compartidos por los objetos
Sirve como modelo para la creación de objetos Los objetos pueden ser agrupados en clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Algebra 101Historia ArteQuímicaEspañol 101
Encontrando Clases
Una clase debe capturar una y solo una abstracción clave Mala abstracción: La clase estudiante que conoce la información
del estudiante y el programa del semestre actual del estudiante Buena abstracción: Clases separadas. Una para el estudiante y
otra programas del estudiante
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Asignando Nombre a una Clase
El nombre de la clase debe ser el sustantivo singular que mejor caracterice la abstracción
La dificultad al nombrar la clase revela una pobre definición de la abstracción
Los nombres deben provenir directamente del vocabulario del dominio
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Guía de estilo en el nombramiento de clases
Una guía de estilo debe dictar convenciones para el nombramiento de clases
Ejemplo de guía de estilo Las clases son nombradas usando sustantivos
singulares Los nombres de las clases comienzan con letra
mayúscula No se usa el subrayado
Los nombres compuestos por múltiples palabras se ponen juntos y la primera letra de cada palabra se escribe con mayúscula
Ejemplo: Estudiante, Profesor, Sistema De Pago
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Fijarse en los “QUE” e ignorar los “COMO”Fijarse en los “QUE” e ignorar los “COMO”
Definiendo la Semántica de las Clases
Después de nombrar las clases, debe hacerse un informe descriptivo conciso
Concentrarse en el propósito de la clase, no en su implementación
El nombre y la descripción de la clase sirven como base para un modelo de diccionario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mientras más se descubre del problema, se refina la definición de la clase y se agregan nuevas clases al modelo de diccionario
Mientras más se descubre del problema, se refina la definición de la clase y se agregan nuevas clases al modelo de diccionario
Muestra de las Entradas de un Modelo de Diccionario
Nombre: InformaciónDelEstudiante Definición: Información de una persona registrada
para asistir a clases en la universidad Nombre: Curso
Definición: Una clase ofrecida por la universidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Profesor
Profesor Clark
a + b = 10
Representando Clases
Una clase es representada usando un compartimiento rectangular
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Profesor
nombreempID
crear( )grabar( )borrar( )cambiar( )
Profesor
nombreempID
Profesor
crear( )grabar( )borrar( )cambiar( )
Profesor
Profesor
Compartimientos en la representación grafica de una clase Una clase está compuesta de tres secciones
La primera sección contiene el nombre de la clase La segunda sección muestra la estructura (atributos) La tercera sección muestra el comportamiento
(operaciones) La segunda y la tercera sección pueden ser suprimidas si
se necesita que no se vean en el diagrama
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Estereotipos
Un estereotipo es un nuevo tipo de elemento de modelado que extiende la semántica del metamodelo
Deben estar basados en tipos o clases existentes en el metamodelo
Cada clase debe tener al menos un estereotipo Estereotipos comunes
Clase Frontera Clase Entidad Clase Control Clase Excepción Clase Utilidad
Los estereotipos son mostrados en el compartimiento del nombre de la clase encerrados entre << >>
Ing. Ernesto Calderón Yarlequé
VENS
VENS
FormularioPrograma<<Boundary>>
Clase Frontera
Una clase frontera modela la comunicación entre el entorno del sistema y su funcionamiento interno
Clases interfaz típicas Windows (interfase del usuario) Protocolo de comunicación (interfase del sistema) Interfase de la impresora Sensores
En el escenario del “Registrar Cursos a Tomar”, un Formulario programa es creado para aceptar la información del usuario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
<<Boundary>>Sistema Cobranza
Interfaces con Otros Sistemas Una clase frontera también es usada para modelar una interfaz a
otro sistema Las características importantes de este tipo de clases frontera
son: La información que debe ser entregada al otro sistema El protocolo de comunicación usado para “hablarle” al otro
sistema En el escenario del “Registro de Cursos” , la información debe
ser enviada al Sistema Cobranza externo Una clase llamada Sistema Cobranza es creada para
sostener la interfaz con el sistema externo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Una clase entidad modela información y asocia comportamientos que generalmente son de larga duración (persistentes)
Puede reflejar un fenómeno de la vida real También puede ser necesitada por la tarea interna del
sistema Los valores de estos atributos normalmente son entregados
por un actor El comportamiento es independiente del entorno
Las clases entidades en el caso de uso “Registro de Cursos”: Curso Programa Catálogo ListaCursos
Programa<<entity >>
ListaCursos<<entity>>
Catalogo<<entity >>
Curso<<entity >>
Clase Entidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
<<control>>AdministradorDeRegistro
Clase Control Una clase control modela el comportamiento especifico de uno o
más casos de usos La clase control
Crea, inicializa y borra objetos controlados Controla la secuencia o coordina la ejecución de los objetos
controlados Controla asuntos concurrentes para las clases controladas Es usualmente la implementación de un objeto intangible
En el escenario del “Registro de Cursos”, la clase AdministradorDeRegistro controla los procesos de registro
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Objetos y Clases
Un objeto es algo que tiene estado, comportamiento e identidad
El estado de un objeto es una de las condiciones posibles en las que el objeto puede existir
El comportamiento determina cómo un objeto actúa y reacciona a los requerimientos de otros objetos
Cada objeto tiene una entidad única -- incluso si su estado es idéntico al de otro objeto
Una clase es una definición abstracta de un conjunto de objetos que tienen una estructura y un comportamiento común
A las clases se les debe dar por nombre la palabra que mejor caracterice su abstracción
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Objetos y Clases (cont.)
Las clases se representan como un compartimiento rectangular El primer compartimiento contiene el nombre de la clase El segundo compartimiento muestra su estructura (atributos) El tercer compartimiento muestra su comportamiento
(operaciones) Un estereotipo representa la clasificación de la clase
Toda clase debe tener al menos un estereotipo Estereotipos comunes: interfaz, entidad, control, excepción,
metaclase y utilidad La clase interfaz modela la comunicación entre el entorno del sistema
y su trabajo interno La clase entidad modela la información y el comportamiento asociado
que debe ser almacenado La clase control modela el control del comportamiento específico de
uno o más casos de usos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Interacciones de Objetos
Usted será capaz de: Utilizar diagramas de secuencia y de colaboración para mostrar las
interacciones entre los objetos.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué son los Diagramas de Interacción?
Un diagrama de interacción es una representación gráfica de interacciones entre objetos
Existen dos tipos de diagramas de interacción Diagramas de secuencia Diagramas de colaboración
Cada uno entrega un punto de vista distinto de la misma interacción Los diagramas de secuencia son ordenados en el tiempo Los diagramas de colaboración pueden incluir flujo de datos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es un Diagrama de Secuencia?
Un diagrama de secuencia muestra las interacciones de objetos ordenadas en una secuencia de tiempo
El diagrama muestra Los objetos participando en la interacción La secuencia de mensajes intercambiados
Un diagrama de secuencia contiene: Objetos con sus “líneas de vida” Mensajes intercambiados entre objetos en una secuencia
ordenada Linea de Vida Activa (opcional)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un Diagrama de Secuencia
John : Estudiante
FormularioRegistro
Cursos Disponibles
Formulario Programa
1: ingresar id
2: validar id
3: ingresar semestre actual
4: crear un nuevo programa
5: mostrar
6: obtener cursos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
cursosdisponibles
cursosdisponibles: Catálogo
: Catálogo
Object only Class onlyObject and Class
Nombrando Objetos en Diagramas de Secuencia
Los objetos son dibujados como rectángulos con nombres subrayados
Las “líneas de vida” de los objetos están representadas por líneas rayadas en descenso
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Formularioprograma
Obtener cursos
Cursos disponible
Mostrando la Interacción entre Objetos
La interacción de objetos está indicada por flechas horizontales las cuales son dirigidas desde la línea vertical representada por el objeto cliente a la línea representada por el objeto proveedor
Las flechas horizontales están etiquetadas con mensajes El orden de los mensajes con respecto al tiempo, está indicado por la
posición vertical. Enumerar las flechas horizontales es opcional ya que el orden está
basado en la posición vertical
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es Activación?
Una activación es el tiempo relativo en el que el flujo de control está enfocado en un objeto
Representa el tiempo en el que un objeto espera una respuesta a un mensaje enviado
La activación puede ser mostrado en un diagrama de secuencia mediante una línea de vida activa
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Enfoque de Control
John : Estudiante
formulario Registro
formulario programa
cursosdisponibles
1: ingresar id2: validar id
3: ingresar semestre actual
4: crear nuevo programa5: mostrar
6: obtener cursos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Formulario programa
obtener cursos
cursos disponibles
Cursos disponibles Para el semestre
Notas
Las notas pueden agregar más información al diagrama
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Libretos para Diagramas de Secuencia
Para escenarios complejos, los diagramas de secuencia pueden ser mejorados por medio del uso de libretos
Un libreto está escrito hacia la izquierda de un diagrama de secuencia con los pasos del libreto alineados con las interacciones de los objetos
Los libretos pueden ser escritos en lenguaje natural o pseudo códigos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo de Libreto
Procesar los cursos primariosprimero, usando sólo los cursosalternativos si es necesario
Formulario Programa
Obtener pre-requisito
unCurso
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagramas de Colaboración
Un diagrama de colaboración es una manera alternativa de representar mensajes intercambiados por un conjunto de objetos
El diagrama muestra interacciones organizadas alrededor de los objetos y las conexiones entre ellos
Un diagrama de colaboración contiene: Objetos Conexiones entre objetos Mensajes intercambiados entre objetos Datos fluyendo entre objetos, si los hubiera
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo de Diagrama de Colaboración
John : Student
registration form
schedule formavailable classes
1: enter id
2: validate id
3: enter current semester
4: create new schedule5: display
6: get courses
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Inglés101
Inglés 101:Curso
:Curso
Object only Class onlyObject and Class
Representando Objetos en un Diagrama de Colaboración
Los objetos son dibujados como rectángulos con nombres subrayados
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Formulario programa : Form Un curso : Curso
Representando Conexiones en un Diagrama de Colaboración
Una conexión en un diagrama de colaboración se representa como una línea que une íconos de objetos
Una conexión indica que existe un camino para establecer una comunicación entre los objetos conectados
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mensajes entre objetos
Una de conexión en un diagrama de colaboración puede mostar los mensajes enviados entre los objetos.
Un mensaje se representa con una flecha apuntando desde el objeto cliente a el objeto proveedor
El nombre del mensaje con una lista opcional de parámetros y/o un valor de retorno
Un número de secuencia opcional que muestra el orden relativo en el cual los mensajes son enviados
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Notación de conexiones
Formulario programa : Form Un curso : Curso
Supplier object
Message
points from client to supplier
Client object
Data return
1: obtener pre-requisitos
2: obtener cursos
Lista de curso
Objeto
Mensaje
Mensaje
Objetoconexión
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Interacción entre Objetos
La interacción de objetos puede ser representada gráficamente en un diagrama de secuencia, el cual muestra la existencia de objetos y las interacciones entre los objetos identificados
Los objetos son representados por rectángulos con sus nombres subrayados
Una “línea de vida” de un objeto es representadas por una línea rayadas vertical descendiendo del objeto
Los mensajes están indicados por flechas horizontales las cuales están dirigidas desde el objeto cliente (emisor) al objeto proveedor (receptor)
Las flechas horizontales están etiquetadas con el nombre del mensaje
Un libreto opcional puede ser agregado para mostrar más detalles al diagrama
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Interacción entre Objetos (cont.)
Un diagrama de colaboración es una representación gráfica alternativa de interacciones de objetos
Los objetos se representan con rectángulos Una interacción de conexión (línea) se dibuja entre objetos que
se comunican La conexión se anota con una flecha que contiene el
nombre del mensaje que apunta desde el objeto cliente a el objeto proveedor
La conexión puede también ser anotada con una flecha de retorno de datos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Encontrando Clases
Será capaz de: Discutir el análisis de casos de uso Encontrar objetos y clases mediante el análisis de casos de uso Usar cartas CRC para descubrir clases Dibujar un escenario usando diagramas de interacción Crear paquetes Crear diagramas de clase
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es el Análisis de Casos de Uso?
El análisis de casos de uso es el proceso de examinar los casos de uso para descubrir objetos y clases, para el sistema que está siendo desarrollado
Los escenarios son detallados y mostrados gráficamente en diagramas de interacción
Se crean las entidades, las interfaces y las clases de control
Las clases son agrupadas en paquetes Se creados los diagramas de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Encontrando Objetos “Entidad”
Los objetos “entidad” son identificados examinando los nombres y las frases del escenario analizado
Los nombres encontrados pueden ser: Objetos Descripciones del estado de un objeto Entidades externas y/o actores Nada de lo anterior
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Filtrando Nombres
Cuando esté identificando nombres, tenga cuidado que: Varios términos pueden referirse al mismo objeto Un término puede referirse a más de un objeto El lenguaje natural es bastante ambiguo
Este acercamiento puede identificar varios objetos sin importancia La lista de nombres debe ser filtrada
Una palabra de atención Cada nombre puede ser tratado como verbo; cada verbo puede
ser tratado como nombre El resultado depende fuertemente de la habilidad para
escribir de los autores
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Linea de fondo: Cada nombre debe ser considerado en el contexto del problema – él no se basta a si mismo
Linea de fondo: Cada nombre debe ser considerado en el contexto del problema – él no se basta a si mismo
Revisando los Nombres
El siguiente requerimiento es escrito para un sistema bancario “Los requerimientos legales serán transformados en cuentas”
Si SÓLO los nombres son considerados, ¿qué pasará?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El Escenario “Registrar Cursos a Tomar”
John ingresa su número de estudiante 369 52 3449 y el sistema valida el número. El sistema pregunta cuál semestre- John indica el semestre actual y elige crear un nuevo horario.
Desde una lista de cursos disponibles, John elige de entre los cursos primarios Ingles 101, Geología 110, Historia del Mundo 200 y Álgebra 110. Luego elige de entre los cursos alternativos Teoría de la Música 110 e Introducción a la Programación en Java180.
El sistema determina que John cumple con todos los prerequisitos examinando sus registros y lo agrega a las listas de los cursos.
El sistema indica que la actividad está completa. El sistema imprime el horario del estudiante y envía la información de cobro por cuatro cursos al sistema de cobranzas para su proceso.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué nombres deben ser filtrados?¿Qué nombres deben ser filtrados?
Los Nombres del Escenario “Registrar Cursos a Tomar”
John Número de estudiante 369523449 Sistema Número Semestre Semestre actual Nuevo horario Lista de cursos disponibles Cursos primarios Ingles 101 Geología 110 Historia del Mundo 200 Álgebra 110 Cursos alternativos Teoría Musical 110 Introducción a la programación en Java 180 Prerequisitos necesarios Registro del estudiante Lista del curso Actividad Horario del estudiante Información de cobro Cuatro cursos Sistema de cobranza
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Decisiones de Filtrado
John -- filtrado (actor) Número de estudiante 369523449 -- filtrado (propiedad de un estudiante) Sistema -- filtrado (lo que está siendo construido) Número -- filtrado (propiedad de un estudiante) Semestre -- filtrado (estado – cuando la selección ocurre) Semestre actual -- filtrado (lo mismo que semestre) Nuevo horario – candidato a objeto Lista de cursos disponibles -- candidato a objeto Cursos primarios -- filtrado (estado del curso seleccionado) Ingles 101 -- candidato a objeto Geología 110 -- candidato a objeto Historia del Mundo 200 -- candidato a objeto Álgebra 110 -- candidato a objeto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Decisiones de Filtrado
Cursos alternativos -- filtrado (estado del curso seleccionado)
Teoría Musical 110 -- candidato a objeto
Introducción a la programación en Java 180 -- candidato a objeto
Prerequisitos necesarios -- filtrado (cursos como otros cursos identificados)
Registro del estudiante -- candidato a objeto
Lista del curso -- candidato a objeto
Actividad -- filtrado (Expresión española)
Horario del alumno -- filtrado (lo mismo que nuevo horario)
Información de cobro -- candidato a objeto
Cuatro cursos -- filtrado (Información necesitada por el sistema de cobranza)
Sistema de cobranza -- filtrado (actor)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Candidatos a Objeto en el Escenario
Nuevo horario – lista de los cursos de un alumno en un semestre Lista de cursos disponibles – lista de todos los cursos impartidos en un
semestre Ingles 101 – una oferta para el semestre Geología 110 -- una oferta para el semestre Historia del Mundo 200 -- una oferta para el semestre Álgebra 110 -- una oferta para el semestre Teoría Musical 110 -- una oferta para el semestre Introducción a la programación en Java 180 -- una oferta para el
semestre
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Candidatos a Objeto en el Escenario
Registro del estudiante – la lista de los cursos aprobados anteriormente por el alumno
Lista del curso – lista de los estudiantes para un curso especifico
Información de cobro – información requerida por el sistema de cobranza
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Creando Clases
Los objetos encontrados son agrupados en clases Basados en estructuras y/o comportamientos similares
Este es un intento inicial Las clases pueden cambiar mientras más escenarios son
examinados
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Programa<<Entidad>>
Curso<< Entidad >>
InformaciónCobro<< Entidad >>
ListaCurso<< Entidad >>
RegistroEstudiante<< Entidad >>
Catálogo<< Entidad >>
Candidatas a Clases – Escenario “Creando un Horario”
Programa – lista de los cursos de un alumno en un semestre Catálogo – lista de todos los cursos impartidos en un semestre Curso – una oferta para un semestre RegistroEstudiante – lista de los cursos tomados previamente ListaCurso – lista de estudiantes para un curso en particular InformaciónCobro – información necesaria para el sistema de
cobranza
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Encontrando Clases Frontera
Examine cada par actor/escenario y cree clases de frontera obvias Durante el diseño, la clase será definida basada en los
mecanismos de la interfaz de usuario elegida Ejemplo:
El estudiante se presenta con diferentes opciones en el caso “Registrar Cursos a Tomar”
Una clase de frontera llamada “FormularioRegistro” se crea para permitir al estudiante seleccionar la opción deseada
El estudiante debe ingresar la información del curso al sistema en el escenario “Registrar Cursos a Tomar”
Una clase de frontera llamada”FormularioPrograma” se crea para guardar la información ingresada por el estudiante
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Candidatas a Clases Frontera – Escenario “Registrar Cursos a Tomar”
FormularioPrograma<<Boundary>>
FormularioRegistro<<Boundary>>
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Esquema de Ventana Los prototipos y/o esquemas de ventanas pueden ser creados para
comunicar el aspecto y sensación de clase de interfaz al usuario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Encontrando Clases de Interfaz
Las clases de interfaz también son creadas para la comunicación sistema-a-sistema
Un sistema puede ser otro sistema de software o un hardware (impresoras, alarmas, etc.)
Las clases de interfaz son agregadas para describir el protocolo de comunicación escogido
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Printer<<Boundary>>
Candidatas a Clases de Interfaz – Escenario “Registrar Cursos a Tomar”
El horario del estudiante es impreso en el escenario “Creando un Horario”
Una clase de interfaz llamada “Printer” es creada La información de cobro es enviada al sistema de cobranza en el
escenario “Registrar Cursos a Tomar” Una clase de interfaz llamada SistemaCobranza es creada
SistemaCobranza<<Boundary>>
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Encontrando Clases de Control
Las clases de control típicamente contienen información de secuencia Atención: las clases de control NO deben asumir las
responsabilidades que típicamente corresponden a las clases de interfaz o de entidad
A este nivel de análisis, una clase de control es típicamente creada para cada caso de uso
Responsable por el flujo de los eventos en el caso de uso Esto es solo el primer corte
Mientras más casos y escenarios son desarrollados, las clases de control pueden ser eliminadas, divididas o combinadas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Control para el caso de uso “Registrar Cursos a Tomar”
Una clase de control llamada “AdministradorRegistro” es creada Recibe información de la clase frontera “FormularioPrograma” Para cada uno de los cursos seleccionados
Pregunta al curso sus prerrequisitos Revisa para estar seguro de que todos los prerrequisitos
han sido tomados preguntando a “RegistroEstudiante” si un prerrequisito ha sido completado satisfactoriamente
Sabe qué hacer si un prerrequisito no ha sido tomado Pregunta al “curso” para saber si esta abierto Pide al curso agregar un “Estudiante” (si el curso está
abierto) Sabe qué hacer si ninguno de los 4 cursos está disponible Crea los objetos “ProgramaEstudiante” e
“InformaciónCobro” Pide a “SistemaCobro” enviar la “InformaciónCobro”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Candidatas a Clases de Control – Caso de Uso “Registrar Cursos a Tomar”
AdministradorRegistro<<Control>>
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tarjetas CRC (Clase –Responsabilidades -Colaboradores)
Las clases pueden también ser descubiertas usando tarjetas Clase –Responsabilidad -Colaboradores (CRC por sus siglas en inglés)
Introducidas por Ward Cunningham y Kent Beck en OOPSLA en 1989
Una tarjeta CRC en una tarjeta indexada de 3 x 5 que muestra El nombre de la clase y su descripción Las responsabilidades de la clase
Conocimiento interno de la clase Servicios brindados por la clase
Los colaboradores para las responsabilidades Un colaborador es una clase cuyos servicios son
necesarios para realizar una responsabilidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tarjeta CRC para la Clase Curso
Nombre de la clase Curso
Responsabilidades Colaboradores
Agregar un estudiante
Saber donde es dado el curso
Saber cuando el curso es dado
Estudiante
Saber los prerequisitos
Servicios entregados
Conocimiento interno
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Una sección de tarjeta CRC
Un grupo de personas es escogida para personificar un escenario Se crea una tarjeta para cada objeto en el escenario A cada participante se le asigna un grupo de tarjetas
La persona se transforma en la “clase” El escenario definido es actuado por los participantes En las tarjetas se anotan las responsabilidades y colaboraciones Se crean nuevas tarjetas por cada nuevo objeto descubierto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Beneficios de las Tarjetas CRC
A medida que más y más escenarios son completados, emergen rastros de colaboración
Las tarjetas pueden ser físicamente arregladas para representar esas colaboraciones
Esto puede ayudar a identificar jerarquías de generalización / especialización, o jerarquías de agregación entre las clases
Las tarjetas CRC son más efectivas para grupos que se inician en las técnicas OO, porque ellas:
Previenen la focalización en los detalles de la POO Previenen la generalización prematura Remarcan el “pensamiento objeto”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué Estoy Haciendo?
Las cosas van bien si . . . Todas las clases tiene nombres con sentido y específicos al dominio Cada clase tiene un pequeño conjunto de colaboradores No hay clases “indispensables” (una clase que colabora con todo el
resto debe ser redefinida) La información de cada clase cabe cómodamente en una tarjeta Un cambio de requerimientos puede ser manejado por las clases
Las cosas van mal si . . . Un número de clases no tienen responsabilidades Una sola responsabilidad es asignada a varias clases Todas las clases colaboran con todas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Dibujando Escenarios
A medida que las clases y los objetos son descubiertos, son documentados en diagramas de interacción
Los diagramas pueden ser de secuencia o de colaboración Los diagramas de interacción contienen el flujo de eventos para un
escenario dado Los nombres de los objetos son frecuentemente generales
Ej. estudiante en vez de John Los nombres de los objetos pueden ser omitidos si no son
necesarios para la comunicación Se agregan notas y/o libretos si se necesitan
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Secuencia para el Escenario “Registrar Cursos a Tomar”
: Estudiante :Formulario
Registración : Formulario
Programa : Catálogo : Administrador
registro1: ingresar id
2: validar Id
3: ingresar semestre
4: crear 5: mostrar
6: obtener la oferta de cursos
7: mostrar la oferta de cursos
8: seleccionar cursos
9: enviar
10: crear horario (estudiante, semestre, oferta de cursos)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Secuencia para el Escenario “Registrar Cursos a Tomar” (cont.)
: AdministradorRegistro
: CursosOfrecidos
: RegistroEstudiante
: Programa : Printer : InformaciónCobro
: SistemaCobro
11: obtener los prerequisitos
13: ¿disponible?
14: agregar estudiante (estudiante)
12: prerequisito tomado (curso)
15: crear
16: imprimir (horario)
17: crear
18: enviar (información de cobro)
LOOP a travesde todos loscursos selec.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Colaboración para el Escenario “Registrar Cursos a Tomar”
: Student
: RegistrationForm
: ScheduleForm
: Catalogue
: RegistrationManager
: CourseOffering
: StudentRecord
: Schedule
: Printer
: BillingInformation
: BillingSystem
2: validate id
5: display
6: get course offerings
7: show course offerings
10: create schedule (student, semester,
offerings)
11: get pre-requisite courses
12: pre-requisite taken (course)
13: available ?14: add student (student)
15: create
16: print (schedule)
17: create
18: send (billing information)
1: enter id3: enter semester4: create schedule
8: select course offerings9: submit
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Nombre paquete
¿Qué es un paquete?
Un paquete es un mecanismo de propósito general utilizado para organizar elementos en grupos
El número de clases crece a medida que más casos de uso y escenarios son analizados
Las clases pueden ser agrupadas en paquetes Proveen la habilidad de organizar el modelo en desarrollo
Un paquete es representado como una carpeta
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Paquetes en el Sistema de Registros
Las clases del Sistema de Registros pueden ser agrupadas en tres paquetes
Artefactos de la Universidad, Reglas de negocios e Interfaces Artefactos de la Universidad
Programa, Catálogo, Cursos ofrecidos, RegistroEstudiante, ListaCursos y InformaciónCobro
Reglas de negocio AdministradorRegistro
Interfaces FormularioRegistro, FormularioPrograma, SistemaCobro y Printer
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué son los Diagramas de Clases? La vista lógica esta conformada de muchos paquetes y clases
Un diagrama de clases es la vista de unos pocos (o todos) los paquetes y clases de la vista lógica
Generalmente hay varios diagramas de clases
El diagrama de clases principal es típicamente una vista de los paquetes de alto nivel de la vista lógica
Típicamente cada paquete tiene su propio diagrama de clases principal
Se agregan diagramas de clases adicionales si son necesarios
La vista de las clases participantes de un escenario
La vista de las clases privadas de un paquete
La vista de una clase y sus atributos y operaciones
La vista de la jerarquía de herencia
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Clases Principal para el Sistema de Registros
ArtefactosUniversidad
Interfaces Reglas Negocio
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Clases Principal del Paquete ArtefactosUniversidad
InformaciónCobro Catálogo CursosOfrecidos
ListaCursos Programa RegistroEstudiante
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Clases Principal del Paquete Interfaces
SistemaCobro
Printer
FormularioRegistro FormularioPrograma
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Clases Principal del Paquete ReglasNegocio
AdministradorRegistro
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Encontrando Clases
Elija un caso de uso desarrollado en la lección anterior Diagrame al menos un escenario en un diagrama de interacción
Cree todas las clases de entidad, interfaz y/o control necesarias
Cree una definición para cada clase Cree paquetes para el modelo Acomode las clases descubiertas en paquetes Cree el diagrama de clases inicial
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Encontrando Clases
Las clases son descubiertas analizando los casos de uso y los escenarios desarrollados para el sistema
El par actor/caso de uso es examinado para agregar las clases frontera al modelo
Se agregan las clases entidad examinando los nombres y las frases de los casos de uso y escenarios
Se agregan las clases de control Típicamente una clase de control por cada caso de uso en
el análisis preliminar Pueden ser usadas las tarjetas CRC para descubrir clases Un paquete es un mecanismo de propósito general para organizar
elementos en grupos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Encontrando Clases (cont.)
Un diagrama de clases es una vista de algunos (o todos) los paquetes y clases en la vista lógica
Usualmente hay varios diagramas de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Relaciones
Ud. será capaz de: Nombrar los dos tipos importantes de relaciones entre clases:
asociación y agregación Definir una asociación y representarla en los diagramas de clases Utilizar nombres de asociación y de roles para clarificar asociaciones Definir y especificar la multiplicidad de una asociación Definir una agregación y representarla en el diagrama de clases Definir y representar una asociación u agregación reflexiva Utilizar clases de asociación Definir calificadores y representarlos en diagramas de clases Descubrir relaciones en diagramas de interacción
Ing. Ernesto Calderón Yarlequé
VENS
VENS
La Necesidad de las Relaciones
Todo sistema abarca muchas clases y objetos Los objetos contribuyen en el comportamiento de un sistema
colaborando entre ellos mismos La colaboración se logra a través de las relaciones
Existen dos tipos importantes de relaciones durante el análisis Asociación Agregación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
AdministradorRegistro<<control>>
Curso<<entidad>>
Asociaciones
Una asociación es una conexión semántica bidireccional entre clases Esto implica que existe una conexión entre objetos en las clases
asociadas Las asociaciones están representadas en los diagramas de clases con
una línea conectando las clases asociadas Los datos puede fluir en una o ambas direcciones a lo largo de la
asociación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
AdministradorRegistro<<control>>
Curso<<entity>>
Navegación
Una asociación es una relación bi-direccional Dada la instancia de “AdministradorRegistro” existe asociado un
objeto “Curso” Dada la instancia de “Curso” existe asociado un objeto
“AdministradorRegistro”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
AdministradorRegistro<<control>>
Curso<<entity>>administra
Nombrando Asociaciones
Para clarificar su significado, una asociación debe ser nombrada El nombre se representa como una etiqueta ubicada a lo largo de la
línea de asociación, a medio camino entre los iconos de clases Un nombre de asociación normalmente es un verbo o una frase verbal
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Persona MaestroCurso
Definiendo Roles
Un rol denota el propósito o la capacidad con la que se asocia una clase con otra
Los nombres de roles son típicamente sustantivos El nombre de un rol es puesto a lo largo de la línea de asociación
cercano a la clase que modifica Uno o ambos terminan en una asociación que puede tener
nombres de un rol
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Puede existir más de una asociación entre dos clases Si hay más de una asociación entre dos clases entonces se le DEBE
poner un nombre
Las asociaciones múltiples deben ser puestas a prueba
Persona Enseña Curso
Inscripto
Asociaciones Múltiples
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Asociaciones Múltiples(cont.)
¿Un modelo bueno o malo?¿Un modelo bueno o malo?
Agregar un alumno aSelección del curso Curso
Borrar un alumno de
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Multiplicidad para Asociaciones
Multiplicidad es el número de instancias de una clase que se relacionan con una instancia de otra clase
Para cada asociación, hay dos decisiones de multiplicidad por hacer: una para cada final de la asociación
Por ejemplo, en la conexión que existe entre las instancias que cumplen el rol de maestro y curso
Para cada instancia de persona, muchos (ej. cero o mas) cursos serán enseñados
Para cada instancia de curso, exactamente una persona es el maestro
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Exactamente uno
Cero o mas
Uno o mas
Cero o uno
Rango especificado
1
0..*
1..*
0..1
2..4
Muchos*
Indicadores de Multiplicidad
Cada término de asociación contiene un indicador de multiplicidad Indica el número de objetos que participa en la relación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
1..*
Persona MaestroCurso
1
Ejemplo: Multiplicidad
Las decisiones de multiplicidad exponen muchas suposiciones ocultas acerca del problema que esta siendo modelado
¿Puede ser posible que un maestro no dicte algún curso? ¿Puede un curso tener dos maestros?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué le dice este diagrama?¿Qué le dice este diagrama?
Curso Maestro
10..*
¿Qué significa Multiplicidad?
La multiplicidad responde a dos preguntas ¿La asociación es obligatoria u opcional? ¿Cuál es el número máximo o mínimo de instancias que pueden
ser ligadas a una instancia?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
FormularioPrograma<<Boundary>>
FormularioRegistro<<Boundary>>
1 11
Agregación
La agregación es una forma especial de asociación donde un todo se relaciona con sus partes
También se conoce como “una parte de” o una relación de contención.
Una agregación esta representada como una asociación con un diamante al lado de su clase denotando el agregado.
La multiplicidad se representa de la misma manera que en las otras asociaciones.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Pruebas para comprobar la agregación
¿Es la frase “una parte de” usada para describir la relación? Una puerta es “una parte de” un Automóvil.
¿Son algunas operaciones sobre el todo, automáticamente aplicables a todas sus partes?
Mover el Automóvil, Mover la Puerta ¿Son algunos de los atributos de los valores propagadas del todo
hacia todas sus partes o solo a algunas en particular? El Automóvil es azul, la Puerta es Azul
¿Existe una simetría intrínseca en la relación donde una clase es subordinada de otra?
Una puerta ES parte de un Automóvil, pero un Automóvil NO ES parte de una Puerta
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Curriculum and Course are tightly coupled -- the Curriculum is“made up of” 1 to may Courses
Independent objects
AlumnoCurso
3..10
Curriculum
1..* 0..*1
¿Asociación o Agregación?
Si dos objetos están unidos firmemente por una relación todo-parte La relación es una agregación
Si dos objetos son usualmente considerados como independientes, aun cuando comúnmente están unidos
La relación es una asociación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
A course may have many pre-requisitesA course may be a pre-requisite for many other courses
Curso
Pre-requisito
0..*
0..*
Asociación Reflexiva
En una asociación reflexiva, los objetos de una misma clase están relacionados
Indica que múltiples objetos en la misma clase colaboran en conjunto del mismo modo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un objeto Producto esta “compuesta de”cero o mas objetos Producto
Producto
0..*
1
Agregaciones Reflexivas
Las agregaciones también pueden ser reflexivas Esto indica una asociación recursiva
Parte
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Alumno 0..*
3-10
Curso
Clase Asociación
Deseamos llevar un historial de las calificaciones de todos los cursos que el alumno ha tomado
La relación entre “Alumno” y “Curso” es una relación de muchos a muchos
¿Donde situamos los atributos de las calificaciones?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Clase Asociación (cont.)
El atributo de calificaciones no puede ser situado en la clase “Curso” porque existen (potencialmente) muchas relaciones a muchos objetos de Alumno
Por lo tanto, el atributo pertenece realmente a la relación individual Alumno-Curso
Una clase asociación es usada para almacenar información sobre la relación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Alumno 1..*
3-10
Curso
Notación de la Clase Asociación
Una clase asociación se representa usando el icono de clase La clase asociación se conecta con la asociación usando la línea
entrecortada La clase de asociación puede incluir múltiples propiedades de dicha
asociación Solamente una clase de asociación está permitida por cada asociación
Calificación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Alumno 13-10
Curso
Calificación
Alumno
1
3-10Curso
Calificación
La Clase Asociación y la Multiplicidad
Las Clases de Asociación son regularmente usadas en asociaciones del tipo muchos a muchos
Si la multiplicidad en cualquier extremo de la asociación es “muchos a uno”
Los atributos pueden ser situados dentro de una clase Una clase de Asociación aún puede ser usada
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Dado un objeto de Departamento y un valor para un EmpleadoID existe exáctamente un objeto Profesor
Dado un objeto departamenteo y unvalor para Título, existe un conjuntode objetos Profesor
Departmento ProfesorTitleTitleTítulo
1..*1
Departamento ProfesorEmployeeIDEmployeeIDEmpleadoID
11
Calificadores
Un calificador es un atributo o conjunto de atributos, cuyos valores particionan un conjunto de objetos relacionados a través de la asociación de un objeto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
1..*
{Ordenado porEmpleadoID}Profesor Departmento
1..*
Es miembro de
Es encabezado por
{Subconj.}
1
1 1
Restricciones
Una restricción es una expresión de alguna condición que se debe preservar
Una restricción se denota con llaves
Ing. Ernesto Calderón Yarlequé
VENS
VENS
unaForma : Forma Registro
unaForma : Forma Programa
Admi : Administrador Registro
mostrar
crear
Encontrando Asociaciones y Agregaciones
Los escenarios pueden ser examinados para determinar si una relación debe existir entre dos clases
Dos objetos se pueden comunicar si y solo si se “conocen” entre si
Asociaciones y/o agregaciones proveen un vía de comunicación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Asociación o Agregación?
RegistrationForm and ScheduleForm are tightly coupled -- a ScheduleForm is “part of” the RegistrationForm
ScheduleForm and RegistrationManagerare independent
FormularioRegistro<<Boundary>>
11FormularioPrograma<<Boundary>>
1 1
AdministradorRegistro1
1
1
1
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Interfaces
Business Rules
University Artifacts
Relaciones entre Paquetes
Los paquetes se relacionan entre si usando una relación de dependencia
Si una clase en un paquete se “comunica” con otra clase contenida en otro paquete entonces su relación de dependencia es adicionada a nivel de paquetes
Los diagramas de escenario y diagramas de clase son evaluados para determinar las relaciones entre paquetes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Relaciones durante Análisis y Diseño
Durante el análisis se deben establecer las conexiones (asociaciones y agregaciones) entre las clases
Dichas conexiones existen por la misma naturaleza de las clases, no por una implementación específica
Hacer una estimación inicial de multiplicidad de manera de exponer suposiciones ocultas
Los diagramas de clase son actualizados para mostrar sus relaciones agregadas
Durante el diseño: Las estimaciones de multiplicidad son refinadas y actualizadas Asociaciones y agregaciones son evaluadas y refinadas Las relaciones de paquetes son evaluadas y refinadas Los diagramas de clases maduran
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Actualización del Diagrama de Clases Principal para el Sistema de Registro
ArtefactosUniversidad
Interfaces Reglas Negocio
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Interfaces - Diagrama de Clases Principal
FormaRegistro<<Boundary>>
11
1
AdministradorRegistro(desde ReglasNegocio)
<<control>>
SistemaCobranza<<Boundary>>
1
1
1
FormaPrograma<<Boundary>>
1 1
1
1
Catalogo(desde ArtefactoUniversidad)
1
1
1
1
<<entity>>
Ing. Ernesto Calderón Yarlequé
VENS
VENS
ArtefactosUniversidad - Diagrama de Clases Principal
Curso<<entity>>
Catálogo<<entity>>
Formularioregistración(de Interface)
1
1
1
1
1
RegistroCurso<<entity>>
ListaCurso<<entity>>
AdministradorRegistro(desde Reglas de Negocio)
1
0..41
1
1
1
1
1
RegistroEstudiante<<entity>>1
1
1
1
1
1
1
1
0..4
<<Boundary>>
<<control>>
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Actualización de Diagrama de clase Principal de Reglamento Económico
Curso(desde ArtefactosUniversidad)
<< entity >>0..4
1
SistemaCobranza(desde Interfaz
<< boundary >>
FormularioItinerario(from Interfaces)
<<boundary>> RegistroCurso(desde ArtefactosUniversidad)
<<entity>>
ListaCursos(desde ArtefactosUniversidad)
<< entity >>Registro de Estudiante
(desde ArtefactosUniversidad)
<< entity >>
AdministradorRegistro<<control>>
1
11
1
11
1
1
1
1
1
11
1
11
1
1
1
1
1
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Relaciones
Usando los escenarios y diagramas de secuencia generados en las lecciones anteriores
Actualice los diagramas de clase mostrando la relación entre las clases
Asegúrese que las decisiones de multiplicidad inicial sean correctas
Agrega los paquetes y sus relaciones para el sistema
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Relaciones Todos los sistemas involucran muchos objetos que colaboran entre
ellos para crear la funcionalidad requerida Dos tipos de relaciones importantes son las asociaciones y las
agregaciones Una asociación es una conexión entre dos clases que representan
comunicación Una asociación puede tener nombre Nombres nemotécnicos pueden ser utilizados La comunicación puede ser tanto uni como bi-direcional (por
defecto) La multiplicidad es el número de instancias que participan en una
asociación Está representado cerca del final de la línea de asociación Cada término de asociación debiera de tener un indicador de
multiplicidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Relaciones (cont.)
Una agregación es una forma especializada de asociación en la cuál un todo esta relacionado con sus partes
Los extremos de una línea de agregación debe tener un indicador de multiplicidad
Una clase puede tener una asociación reflexiva Dos objetos en la misma clase que están relacionados
Las relaciones de agregación también pueden ser reflexivas La información que pertenece al vinculo entre objetos es mostrado en
una clase asociación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Relaciones (cont.)
Un calificador es un atributo de una clase que puede ser usado para reducir la multiplicidad de la asociación
Las relaciones pueden ser determinadas al examinar los escenarios y descubrir las necesidades de la comunicación entre objetos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Operaciones y Atributos
Ing. ERNESTO CALDERON [email protected]
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Operaciones y Atributos - Objetivos
Usted será capaz de: Definir operaciones para clases Definir atributos para clases Definir encapsulamiento y establecer sus beneficios Representar atributos y operaciones en diagramas de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un operación debería desempeñar una función simple y cohesionadaUn operación debería desempeñar una función simple y cohesionada
¿Qué es una Operación? Una clase contiene un conjunto de responsabilidades que definen el
comportamiento de los objetos que pertenecen a la clase. Las responsabilidades de una clase son llevadas a cabo por sus
operaciones Esto no es necesariamente mapeado uno a uno
Responsabilidad de la clase “producto”: mantener el precio de proveedor
Operaciones para esta responsabilidad Buscar la información en la base de datos Calcular el precio
Una operación es un servicio que puede ser solicitado desde un objeto para solicitar un determinado comportamiento
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Perspectiva Bancaria
Recibe préstamosPosee cuentasRecibe líneas de credito
Perspectiva Médica
Es examinadaToma remediosVa al hospitalRecibe una cuenta
Las operaciones son dependientes del dominio
Listar todas las operaciones relevantes al dominio Las operaciones de la clase “persona” serán distintas
dependiendo de la perspectiva solicitada
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Nombrando las Operaciones
Las operaciones deberían ser nombradas indicando el nombre de su resultado o salida, no los pasos dentro de la operación. Ejemplos:
calcularBalance() Pobremente nombrada
Indica que el balance debe ser calculado - esto es una decisión implementación/optimización
obtenerBalance() Bien nombrada
Indica solamente la salida
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Nombrando Operaciones (cont.)
Las operaciones debería ser nombradas desde la perspectiva del proveedor, no del cliente
En una estación de gas, el gas es recibido desde la bomba: Una operación para la bomba que tiene esta responsabilidad -
como debería ser llamada? Nombres buenos: entregarGas(),dispensar() Nombre malo : recibirGas()
La bomba da el gas, no lo recibe
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es una Operación Primitiva?
Una operación primitiva es una operación que puede ser implementada solamente usando las cualidades internas de la clase
Todas las operaciones de una clase son típicamente primitivas Ejemplo:
Agregar un ítem al conjunto - operación primitiva Agregar cuatro ítems al conjunto - no primitiva
Puede ser implementada con múltiples llamadas a la operación anterior de agregar un ítem al conjunto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Firmas de las Operaciones
La firma de una operación consta de: Lista opcional de argumentos Tipo de retorno
Durante el análisis NO ES OBLIGATORIO llenar la firma de la operación
Esta información puede ser retrasada hasta el diseño
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Curso
obtenerPrerequisito() : ListaCurso
Visualizando Operaciones
Las operaciones son mostradas en el tercer compartimiento de la clase
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Administrador Registro
obtenerPrerequisito
unCurso Administrador Registro
obtenerPrerequisito():ListaCurso
unCurso
Descubriendo Operaciones desde los Diagramas de Interacción
Los mensajes visualizados en los diagramas de secuencia y/o colaboración son usualmente operaciones de las clases receptoras
Los mensajes son traducidos a operaciones y agregados al diagrama de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Descubriendo Clases Adicionales
Si una firma de una operación se especifica, pueden ser descubiertas clases adicionales en:
Argumentos de la operación Clases de retorno
Ejemplo: obtenerPrerequisito() : ListaCurso agregarEstudiantet(John : InformaciónEstudiante)
Las clases descubiertas se adicionan al modelo Estas son mostradas en los diagramas de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Descubriendo Relaciones Adicionales
Los argumentos de las operaciones y las clases de retorno denotan una relación entre la clase y los argumentos y/o la clase de retorno
Ejemplo La clase “ListaCursos” tiene una operación
agregarEstudiante(John: InformaciónEstudiante) Esto implica que existe una relación entre “ListaCursos” e
“InformaciónEstudiante” Las relaciones descubiertas son agregadas al modelo
Estas son mostradas en los diagramas de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es un Atributo?
Un atributo es una definición de datos mantenido por instancias de una clase
Los atributos no tienen comportamiento -- no son objetos Los nombres de los atributos son sustantivos simples o frases simples
Los nombres deben ser únicos dentro de una clase Cada atributo debe tener una definición clara y concisa Buenos atributos para la clase Estudiante
Nombre -- nombre y apellido Carrera -- área principal de estudio
Un atributo malo para la clase Estudiante -- cursosSeleccionados Esta es una relación, no un atributo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
AtributosNombre
NúmeroDeEmpleadoáreaEnseñanza
Sue Smith567892
Matemáticas
George Jones578391
Biología
Valores de Atributos
Un valor de atributo es el valor de un atributo para un objeto en particular
Cada objeto tiene un valor para cada atributo definido para su clase Por ejemplo, para un objeto de la clase “Profesor”:
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Perspectiva Bancaria
nombredirecciónfechaDeNacimientonúmeroDeCuenta
Perspectiva Médica
nombredirecciónfechaDeNacimientoalturapeso
Atributos Dependientes del Dominio
Lista de todos los atributos relevantes al dominio del problema Los atributos de la clase Persona serán distintos dependiendo de
“a quien le preguntemos”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Curso
nombredescripciónubicaciónhorarioCréditos
obtenerPrerequisito () : Curso
<<entidad>>
Visualizando Atributos
Los atributos son mostrados en el segundo compartimiento de la clase
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Rectánguloaltoancho/área
Atributos Derivados
Un atributo derivado es un atributo cuyo valor puede ser calculado en base a el valor de otros atributos
Utilizado cuando no existe suficiente tiempo para recalcular el valor cada vez que sea necesario
Compensa desempeño en tiempo de ejecución vs. memoria requerida
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tipos de Datos y Valor Inicial de Atributos
Cada atributo posee: Tipo de Dato Valor inicial opcional
Durante el análisis NO ES OBLIGATORIO completar la definición del atributo
Esta información puede ser retrasada hasta el diseño
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Sólo modele los atributos que sean relevantes para el dominio del problemaSólo modele los atributos que sean relevantes para el dominio del problema
¿Cómo son descubiertos los Atributos?
Muchos atributos se descubren en el flujo de eventos de los casos de uso
Observe los sustantivos que no fueron considerados buenos candidatos para ser clases
Otros son descubiertos cuando se crea la definición de la clase La experiencia en el dominio puede también proveer buenos atributos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Curso
descripción
Ejemplo: Atributos en el problema de Inscripción de Cursos
“Cada curso tendrá una descripción en el catálogo” Un atributo llamado “descripción” es agregado a la clase Curso
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Guía de Estilo para el nombramiento de atributos y operaciones
Una guía de estilo debería dictar convenciones de nombres para atributos y operaciones
Provee consistencia a través del proyecto Guía hacia modelos y código más mantenible
Ejemplos Atributos y operaciones empiezan con una letra minúscula El subrayado no es usado
Nombre compuestos de múltiple palabras son colocados juntos y la primera letra de cada palabra adicional esta en mayúscula
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mostrando Atributos y Operaciones
Atributos y/u operaciones pueden ser mostradas dentro de la clase Diagramas de clases adicionales pueden ser creados para mostrar
atributos y operaciones Las relaciones no son mostradas, típicamente,en esos diagramas
de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Encapsulamiento
Una forma para ver una clase es que consiste de dos partes: la interfaz y la implementación
La interfaz puede ser vista y usada por otros objetos La implementación es oculta para los clientes
Ocultar los detalles de implementación de un objeto se llama encapsulamiento u ocultamiento de la información
El encapsulamiento ofrece dos tipos de protección. Protege: El estado interno de un objeto, de ser corrompido por sus clientes El código del cliente, de cambios en la implementación del objeto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
númeroCuentanombreBanconombreTitular
balance
retirar
depositar
generarInstrucciones
obtenerBalance
cambiarNombreTitular Los valores de los atributos pueden ser cambiados sólo por las operaciones que provee el objeto
Las operaciones son provistas para mostrar los valores de los atributos necesarios para los clientes
El estado del objeto no puede ser modificado por los clientes directamente
Ejemplo: Encapsulamiento
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Beneficios del Encapsulamiento
El código cliente puede usar la interfaz a una operación El código cliente no puede tomar ventaja de la implementación de la
operación La implementación puede cambiar, por ejemplo, para:
Corregir errores (Bugs) Mejorar el Desempeño Reflejar cambios en las políticas
El código del cliente no debe ser afectado por cambios en la implementación, esto reduce el efecto “arrastre” en el cual una corrección para una operación fuerza la correspondiente corrección en una operación del cliente la cual causa el cambio en un cliente del cliente….
La manutención es fácil y menos cara.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Operaciones y Atributos
Actualizar el diagrama de secuencia creado en la lección anterior para refinar los mensajes nombrando las operaciones en forma más concisa donde sea necesario
Crear el diagrama de Clases mostrando sólo atributos y operaciones Agregar cualquier relación adicional basada en argumentos de
operaciones y/o clases de retorno
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Operaciones y Atributos (cont.)
Una clase encierra un conjunto de responsabilidades las cuales definen el comportamiento de los objetos de la clase
Las responsabilidades son cumplidas por las operaciones definidas para la clase
Cada operación debería desarrollar una función simple y cohesiva Una operación debería hacer una cosa y hacerla bien Las operaciones son cómo un objeto actúa y reacciona ante los
mensajes que recibe Un atributo es una característica de una clase Un valor de un atributo es el valor de un atributo para un objeto en
particular
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Operaciones y Atributos (cont.)
Los atributos se descubren en el texto del enunciado del problema, cuando se crea la definición de la clase, y a través de la experiencia en el dominio.
Solamente los atributos relevantes y operaciones (aplicable para la solución del problema) deben ser modelados
Encapsulamiento es ocultar los detalles de implementación al mundo exterior
Protege el estado interno de un objeto Protege el código del cliente de cambios en la implementación de
las clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Herencia: Objetivos
Usted será capaz de: Definir y discutir herencia, generalización y especialización Representar una jerarquía de herencia en un diagrama de clases Entender las técnicas para encontrar la herencia Definir herencia múltiple
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Herencia
La herencia define una relación entre clases donde una clase comparte la estructura y/o comportamiento con una o más clases
La herencia define una jerarquía de abstracciones en que una subclase herede desde una o más superclases
Con la herencia simple, la subclase hereda desde una única superclase
Con la herencia múltiple, la subclase hereda desde más de una superclase
La herencia es una relación “es un” o “tipo de”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Superclase
Subclase
Relación de Herencia
InformaciónEstudiante
InformaciónUsuario
Dibujando una Jerarquía de Herencia
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Consideraciones para la Herencia
Ya que una relación de herencia no relaciona objetos individuales La relación no tiene nombre La multiplicidad no tiene sentido
Teóricamente, no existe límite para el número de niveles de herencia En la práctica actual, los niveles necesitan ser bastante limitados
Típicamente la herencia en C++ llega de 3 a 5 niveles La herencia en Smalltak puede ser un poco más profunda
Ing. Ernesto Calderón Yarlequé
VENS
VENS
La herencia apalanca las similaridades entre las clasesLa herencia apalanca las similaridades entre las clases
¿Qué es herencia?
Una clase hereda de sus padres: Atributos Operaciones Relaciones
Una subclase puede: Agregar atributos, operaciones y relaciones adicionales Redefinir las operaciones heredadas (¡tenga cuidado!)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un camión tiene tres atributos:númeroLicenciapesotonelaje
Un camión tiene tres atributos:númeroLicenciapesotonelaje
Camión
tonelaje
VehículoTerrestre
PesonúmeroLicencia
Auto
Heredando Atributos Los atributos se definen en el nivel más alto en la jerarquía de herencia
en la que son aplicados Las subclases de una clase heredan todos los atributos Cada subclase puede añadir atributos adicionales
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un camión tiene tres atributos:númeroLicenciapesotonelaje
y dos operaciones:registrar()obtenerImpuestos()
Un camión tiene tres atributos:númeroLicenciapesotonelaje
y dos operaciones:registrar()obtenerImpuestos()
Camióntonelaje
VehículoTerrestrepesonúmeroLicencia
Auto
registrar( )
obtenerImpuestos( )
Heredando Operaciones Las operaciones son definidas en el más alto nivel en la jerarquía de
herencia en que son aplicables. Las subclases heredan todas las operaciones de una clase Cada subclase puede aumentar o redefinir las operaciones heredadas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un auto es relacionado con un propietarioUn camión esta relacionado con un propietarioUn camión también tiene un trailer
Un auto es relacionado con un propietarioUn camión esta relacionado con un propietarioUn camión también tiene un trailer
Camióntonelaje
VehículoTerrestrepesonúmeroLicencia
Auto
dueño
registrar( )
obtenerImpuestos( )
Persona
0..*
Trailer
1
Heredando Relaciones Las relaciones también son heredadas y deben ser definidas en el más alto
nivel de la jerarquía de herencia en la cual son aplicables Las subclases de una clase heredan todas las relaciones de la superclase Cada subclase puede participar en relaciones adicionales
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Generalización de Clases
La generalización provee la capacidad para crear superclases que encapsulan estructura y/o comportamiento común entre subclases
La generalización se aplica: Identificando similitudes de estructura/comportamiento entre
varias clases Creando una superclase para encapsular
estructura/comportamiento común Las clases originales son subclasificadas a la nueva superclase
Las superclases son más abstractas que sus subclases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo de Generalización
Incrementandoabstracción
Activo
BienesRaices
Ahorros
CuentaBancaria
Corriente Accion
Valor
Bono
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Especialización de Clases
La especialización provee la capacidad para crear subclases que representan refinamientos en los que la estructura y/o comportamiento de una superclase son agregados o modificados
La especialización se aplica: Notando que algunas instancias exhiben estructura o
comportamiento especializado Creando subclases para agrupar instancias de acuerdo a su
especialización Las subclases son menos abstractas que sus superclases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Decrementandoabstracción
Ejemplo de EspecializaciónActivo
BienesRaices
Ahorros
CuentaBancaria
Corriente Accion
Valor
Bono
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Jerarquía de Herencia
La generalización y especialización son usadas para desarrollar la jerarquía de herencia
Durante el análisis, las jerarquías de herencia entre abstracciones claves (por ejemplo, clases) son establecidas solo si es necesario
Durante el diseño, las jerarquías de herencia son redefinidas para: Incrementar el reuso Incorporar clases de implementación Incorporar librerías de clases disponibles
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Vehiculo
Ford
VehiculoTerrestre
Camion Aereoplano
VehiculoAereo
Helicoptero
Las clases en el mismo nivel de
herencia deberían tener el mismo nivel
de abstracción
Las clases en el mismo nivel de
herencia deberían tener el mismo nivel
de abstracción
Niveles de Abstracción
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Aeroplano Helicoptero Lobo Caballo
ObjetoVolador Animal
Aguila
multipleinheritance
Aguila hereda de ObjetoVolador y AnimalAguila hereda de ObjetoVolador y Animal
Herencia Múltiple
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Use herencia múltiple solamente cuando sea necesario, y
¡siempre con precaución!
Use herencia múltiple solamente cuando sea necesario, y
¡siempre con precaución!
Conceptos de Herencia Múltiple
Conceptualmente necesario para modelar con exactitud el mundo real En la práctica, puede llevar a dificultades en la implementación
No todos los lenguajes de programación orientados a objetos soportan directamente herencia múltiple
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Cada lenguaje o ambiente de programación elije maneras de resolver estas dificultades
Cada lenguaje o ambiente de programación elije maneras de resolver estas dificultades
Name clashes on attributes or operations Repeated inheritance
ObjetoVolador
color
getColor
Animal
color
getColor
Aguila
Objeto Volador Animal
Aguila
ObjetoAnimado
color
Problemas con la Herencia Múltiple
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Encontrando Herencia
Es importante evaluar todas las clases para definir una posible herencia
Observar los comportamientos (operaciones) y los estados (atributos) comunes en las clases
Técnica de adición Agregue nuevas operaciones/atributos a las subclases
Técnica de modificación Redefina las operaciones
Debe ser cuidadoso en no hacer cambios semánticos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Las palabras claves “es un” y “tiene un” ayudarán a determinarla relación correcta
Las palabras claves “es un” y “tiene un” ayudarán a determinarla relación correcta
Herencia vs. Agregación
Herencia y agregación son usualmente confundidas La herencia representa una relación “es un” o “tipo de” La agregación representa una relación “tiene un”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un WindowWithScrollbar “tiene un” WindowUn WindowWithScrollbar “tiene un” Scrollbar
¿Qué relación debería ser usada?
Un WindowWithScrollbar “tiene un” WindowUn WindowWithScrollbar “tiene un” Scrollbar
¿Qué relación debería ser usada?
Window Scrollbar
WindowWithScrollbar
Window y Scrollbar
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un WindowWithScrollbar “es un” WindowUn WindowWithScrollbar “tiene un” Scrollbar
Un WindowWithScrollbar “es un” WindowUn WindowWithScrollbar “tiene un” Scrollbar
Scrollbar
Window
WindowWithScrollbar
11
Window
WindowWithScrollbar
Scrollbar
Window y Scrollbar (cont.)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Herencia vs. Agregación
Herencia Agregación
Palabra clave “es un”
Un objeto
Representado por una flecha
Palabra clave “tiene un”
Relaciona objetos de distintas clases
Representado por un diamante
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Metamorfosis existe en el mundo real¿Cómo podría ser modelada?
Metamorfosis existe en el mundo real¿Cómo podría ser modelada?
¿Qué es Metamorfosis?
Metamorfosis
1. Un cambio en una forma, estructura o función; específicamente el cambio físico experimentado por algunos animales, como un renacuajo a una rana
2. Cualquier cambio marcado, como un carácter, apariencia o condición
Webster’s New World Dictionary
Simon & Schuster, Inc., 1979
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Part-timeStudentnameaddressnumberCourses
Full-timeStudentnameaddressstudentIDgradDate
Ejemplo de Metamorfosis En la universidad existen estudiantes a tiempo completo y estudiantes
a medio tiempo Los estudiantes a tiempo completo tienen un número id y un
fecha de graduación prevista, pero los estudiantes a medio tiempo no.
Los estudiantes a medio tiempo toman un máximo de tres cursos mientras que para los de tiempo completo no existe límite
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Student
nameaddress
FulltimeStudent
studentIDgradDate
ParttimeStudent
numberCourses
¿Qué pasa si los estudiantes part-time pasan a serestudiantes full-time?
¿Qué pasa si los estudiantes part-time pasan a serestudiantes full-time?
Un enfoque
Una relación de herencia puede ser creada
Ing. Ernesto Calderón Yarlequé
VENS
VENS
ParttimeClassification
numberCourses
FulltimeClassification
studentIDgradDate
Student
nameaddress
1
0..1
1
0..1
0..1
0..1
1
1
Metamorfosis
Es muy difícil cambiar la clase de un objeto Una mejor técnica de modelación
Colocar la estructura y comportamiento que “cambia” dentro de su propia clase
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Metamorfosis (cont.)
Mary Smithestudiante Full-time
Joe Jonesestudiante Part-time
MarySmith : Student
: Full-timeClassification
1
1
JoeJones : Student
: Part-timeClassification
1
1
Ing. Ernesto Calderón Yarlequé
VENS
VENS
: Student : FulltimeClassification
: StudentManager
: ParttimeClassification
delete
create
change to full time
Metamorfosis (cont.)
La Metamorfosis es completado por el objeto “hablando” con las partes cambiantes.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Student
nameaddress
1 1 Classification
Parttime
numberCourses
Fulltime
studentIDgradDate
Metamorfosis y Herencia
La herencia puede ser usada para modelar estructura, comportamiento y/o relaciones comunes a las partes “cambiantes”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Parttime
numberCourses
FulltimestudentIDgradDate
11
ResidentInformationdormroomroomKeyID
Studentnameaddress10..1 10..1
Classification1 1
Metamorfosis y Flexibilidad Esta técnica también agrega flexibilidad al modelo Ejemplo: un estudiante puede también vivir en el campus. En este
caso, existe un identificador para el dormitorio, un número de habitación y un número clave de la habitación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Herencia
Examinar las clases definidas en el problema y agregar herencia donde sea necesario
Asegúrese que cualquier metamorfosis esté considerada Actualice los diagramas de clase como sea necesario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Herencia: Resumen
La herencia define una relación entre clases donde una clase comparte la estructura y/o comportamiento de una o más clases
Define una jerarquía de abstracciones en la que una subclase hereda desde una superclase
Herencia simple -- una clase hereda desde una superclase Herencia múltiple -- una clase hereda desde más de una superclase Una subclase hereda atributos, operaciones y relaciones desde su
superclase(s) Un subclase puede
Agregar atributos, operaciones y relaciones Refinar las operaciones heredadas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Herencia : Resumen (cont.)
La generalización provee la capacidad para crear superclases que encapsulan estructura y/o comportamiento común a varias subclases
La especialización provee la capacidad para crear subclases que representan refinamientos en los cuales la estructura y/o comportamiento de las superclases son agregadas o modificadas
Herencia y agregación son usualmente confundidas Herencia representa una relación “es un” o “tipo de” Agregación representa una relación “tiene un”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Comportamiento de los Objetos
Ing. ERNESTO CALDERON [email protected]
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Comportamiento de los Objetos
Usted será capaz de: Explicar la necesidad de Diagramas de Transición de Estados (DTE) Entender como encontrar estados Desarrollar una muestra simple de un DTE
Estados y Transiciones Eventos Condiciones de guarda Acciones y Actividades
Entender el concepto de estados anidados Explicar las relaciones entre diagramas de transición de estados,
diagramas de interacción entre objetos y diagramas de clases
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es un Diagrama de transición de estados?
Un diagrama de transición de estados sirve para mostrar la historia de la vida de una determinada clase, los eventos que causan la transición desde un estado a otro, y las acciones que resultan debido a un cambio de estado.
El espacio de estados de una determinada clase es la enumeración de todos los posibles estados de un objeto.
El estado de un objeto es una de las posibles condiciones en que un objeto puede existir
Este reúne todas las propiedades del objeto Usualmente estático
Además de los valores de cada una de estas propiedades Usualmente dinámico
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Nombre del estado
Dibujo de los Estados
Un estado es representado como un rectángulo redondeado, en un diagrama de transición de estado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
numEstudiantes < 10
Abierto
El máximo número de estudiantes por curso es 10
numEstudiantes > = 10
Cerrado
numStudents = 7
Inglés101 : CursoCurso
numEstudiantes
Estados y Atributos
Los estados pueden ser distinguidos por los valores de ciertos atributos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Profesor Curso0..*1
Estados y Conexiones
Los estados pueden también ser distinguidos por la existencia de ciertas conexiones
Las instancias de la clase “Profesor” pueden tener dos estados: Enseñar, cuando existe una conexión con el curso En estado suspendido, cuando no existe conexión
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Estado Final Estado inicial
Estados Especiales
El estado inicial es el estado del objeto cuando es creado Un estado inicial es obligatorio Sólo un estado inicial es permitido El estado inicial es representado como un círculo relleno
El estado final indica el fin de la vida para el objeto Un estado final es opcional Puede existir más de un estado final El estado final es indicado por un ojo de toro
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Eventos
Un evento es algo que ocurre en un punto en el tiempo y permite la transición del objeto a un estado
El estado de un objeto determina la respuesta a diferentes eventos
Ejemplo: Añadir un alumno a un curso Crear un nuevo curso
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Abierto CanceladoCancelar el curso
Añadir estudiante
Transiciones
Una transición es un cambio desde un estado primitivo a un estado sucesor como resultado de ciertos estímulos
El estado sucesor puede resultar ser el mismo estado primitivo Una transición puede ocurrir como respuesta a un evento Las transiciones pueden ser relacionadas con los eventos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Abierto Registración Completa
Cerrar Registración [ numEstudiantes >= 3 ]
Condiciones de Guarda
Una condición de guarda es una expresión booleana que permiten una transición sólo si la condición es verdadera
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Creación AbiertoRegistro abierto Initialize
Añadir estudiante / Inc(numEstudiantes)
Acciones
Una acción es una operación que está asociada con una transición Para ser terminada requiere de una cantidad de tiempo
insignificante Se considera no-interrumpible
Los nombres de las acciones son mostrados en la flecha de transición
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Creación Abierto
Cerrado
Registraciónn abierta / Inicializar
numEstudiantes
Añadir estudiante
[ numEstudiantes = 10 ]/ ^CursoReporte.Crear
reporte
Enviando Eventos
Un evento puede desencadenar el envío de otro evento Mostrado como: ^Clase.evento
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Cerrado
do: Reportar curso esta lleno
Actividades
Una actividad es una operación que requiere tiempo para ser completada
Las actividades son asociadas con un estado Una actividad
Comienza cuando se ingresa al estado Puede ser ejecutada hasta ser completada o puede ser
interrumpida por una transición que este ocurriendo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Cancelado
do: ^ListaCursos.Eliminar estudiante(Estudiante)
Enviando Eventos Durante un Estado
Una actividad también puede enviar un evento a otro objeto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Cerrado
do: finalizar curso
Ofrecido
Transiciones Automáticas
Algunas veces, el único propósito de un estado es el de realizar una actividad
Una transición automática ocurre cuando la actividad es completada Si existen múltiples transiciones automáticas
Una condición de guarda es necesaria en cada transición Las condiciones deben ser mutuamente excluyentes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Sin-asignar
do: Asignar un profesor al curso
Añadir estudiante / numEstudiantes = 0
Abierto
entry: Registrar un estudiante
Añadir estudiante
Acciones de Entrada y Salida
Cuando una acción debe ocurrir sin importar cómo se ha ingresado o salido de un estado, la acción puede ser asociada con el estado
En realidad, la acción es asociada con cada transición entrando o saliendo del estado
La acción es mostrada dentro del icono de estado precedida por la palabra “entry” o “exit”
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Estados Anidados
Los diagramas de transición de estado pueden volverse inmanejablemente largos y complejos
Los estados anidados pueden ser usados para simplificar diagramas complejos
Un superestado es un estado que incluye estados anidados llamados subestados
Las transiciones comunes de los subestados son representadas en el nivel del superestado
Cualquier número de niveles de anidación son permitidos Los estados anidados pueden llevar a sustanciales reducciones de
complejidad gráfica, permitiendo modelar problemas más largos y complejos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de transición de estado para la Clase del Curso sin Utilizar Estados Anidados
Inicializar
do: Inicializar objecto curso
Sin-asignar
do: Asignar profesor al curso
Abierto
do: Registrar un estudiante
Cerrado
do: Reportar curso esta lleno
Cancelado
do: Enviar noticias de cancelación
añadirEstudiante/ numEstudiantes = 0
cancelarCurso
RegistraciónCompleta
dor: Generar clase roster
cancelarCurso
[ numEstudiantes = 10 ]
cancelarCurso
registración cerrada[ numEstudiantes > = 3 ]
añadirEstudiante
registración cerrada[
numEstudiantes < 3 ]
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de transición de estado para la Clase Curso Utilizando Estados Anidados
Inicializar Registrar
entry: Register a student
Sin-asignar
do: Asignar profesor al curso
Abrir
Cerrado Cancelado
RegistraciónCompleta
do: Generar clase roster
Añadir estudiante / numEstudiantes = 0
[ numEstudiantes = 10 ]
cancelarCurso
registración cerrada[ numEstudiantes > = 3 ]
registración cerrada[ numEstudiantes < 3 ]
añadirEstudiante
do: Reportar curso esta cerrado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Estados Anidados con Historia
El uso de características históricas indica que ante el retorno a un superestado, el subestado visitado más recientemente será ingresado
El uso de la H encerrada por un círculo para denotar que la característica histórica se aplica al superestado
Si la característica de historia no es usada, el subestado inicial será siempre ingresado cuando el superestado sea ingresado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo: Estado Anidado con Historia
En el curso sistema de registro, la selección de curso hace lo siguiente Acepta cursos primarios Acepta cursos alternativos
El usuario puede renunciar en cualquier momento El usuario puede suspender una sesión por un máximo de 30 minutos
mientras selecciona cursos El formulario es grabado después de que todos los cursos han sido
seleccionados el formulario es enviado a procesar después de que ha sido grabado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Estados Anidados con Historia (De Tipo Formulario de Registración)
H
Creaciónentry: Crear formulario
do: inicializar formulario
Grabar
do: Grabar formulario
Enviardo: Enviar formulario para procesarlo
Suspender
do: Esperar por 30 minutos
Selección curso
Selección de curso alternativo
exit: Incrementar contador curso
Selección de curso primariado: Aceptar número curso
exit: Incrementar contador curso
do: Aceptar número curso
[ Contador curso < 4 ]
[ Contador curso = 4 ] / Poner contador curso en 0
[ Contador curso < 2 ]
[Contador curso= 2 ]
Resumir
Suspender
Salir
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Dónde Empezar ...
Durante el análisis, inicialmente concentrarse en el comportamiento de las clases, con significativo comportamiento dinámico
Para una clase dada, se deben buscar posibles estados mediante: Evaluación de los valores de los atributos Evaluación de las operaciones Definir las reglas para cada estado y Identificar las transacciones válidas entre estados
Examinar la ruta de los mensajes o los diagramas de mensaje-objeto que conlleven a que la clase sea modelada
El intervalo entre dos operaciones puede ser un estado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Comportamiento del Objeto Crear un diagrama de transición de estado para modelar el comportamiento
dinámico de la clase empleados con los siguientes estados
Postulante, Contratado, Ausente, Desempleado, Retirado
Información del estado Postulante
Una entrevista es conducida durante este estado
Este estado es concluido por el evento emplear
Información del estado Contratado
El estado contratado posee tres subestados basados en la clasificación de su sueldo
Por hora, Salario fijo y con Comisiones
La clasificación por sueldo puede variar en cualquier momento
Las clasificaciones por sueldo son creadas/borradas mediante la entrada/salida al subestado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Comportamiento del Objeto (cont.) Información sobre el estado Ausente
Un empleado puede tomarse una ausencia de máximo 1 año mientras se encuentre en cualquier subestado de contratado
Si el empleado vuelve regresa al subestado anterior
Información del estado Desempleado
Un empleado puede ser despedido mientras se encuentre en cualquier subestado de empleado
Un empleado puede renunciar mientras se encuentre en cualquier subestado de empleado
El historial del empleado es catalogado como terminado en este estado
Información del estado Retirado
Un empleado debe retirarse al cumplir 65
La información sobre la pensión se calcula en este estado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Comportamiento del Objeto
Un diagrama de transición de estado representa el ciclo de vida del objeto en términos de:
Los posibles estados del objeto Las transiciones entre esos estados
Existen dos estados especiales El estado inicial es el estado ingresado cuando un objeto es
creado El estado final indica el fin de la vida para el objeto
Una transición es un cambio desde un estado original a un estado sucesor, el cual puede ser el mismo estado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Comportamiento del Objecto (cont.)
Una transición puede ocurrir como resultado de lo siguiente: Un evento Una condición ha sido satisfecha
Una acción es una operación que toma una cantidad insignificante de tiempo
Una actividad es una operación que es ejecutada mientras el objeto reside en un estado
Los estados anidados ayudan a enfrentar las complejidades asociadas con diagramas de estado planos
La historia permite la visita al subestado más reciente dentro de un estado
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Homogenización
Usted será capaz de: Discutir por qué la homogenización es necesaria Determinar cuando dos clases deberían ser combinadas, cuando una
clase debería ser dividida y cuando una clase debería ser eliminada Evaluar la consistencia de los diagramas de clases y los diagramas de
interacciones. Discutir la necesidad de la reestructuración de paquetes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué es la homogenización?
Homogenizar
“mezclar o suavizar una mixtura, para hacerla homogénea”
- Webster’s New Collegiate Dictionary -
Mientras más casos de uso y escenarios son desarrollados se torna necesario hacer el modelo homogéneo
Esto es especialmente cierto si diferentes grupos están trabajando en diferentes casos de uso
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué se busca?
Las clases son examinadas para determinar si Dos o más clases pueden ser combinadas Una clase debería ser dividida Una clase debería ser eliminada por completo
Los paquetes son reestructurados para solucionar problemas de: Acoplamiento Reuso Visibilidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Combinando Clases
Cuando múltiples equipos están haciendo el análisis de los casos de uso, una clase puede ser nombrada de distinta manera por los diferentes grupos
Esto es especialmente cierto debido a que en el análisis de casos de uso de trabaja con el lenguaje natural
El recorrido del modelo debe ser canalizado en Evaluar las definiciones de la clase Evaluar la estructura y comportamiento de las clases Buscar sinónimos Buscar el nombre que es más cercano al dominio
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Professor
nameaddresstenureStatus
1
0..*
Department
1
0..*Teacher
nameaddress
0..*
11
0..*
Department
Teacher
nameaddresstenureStatus
0..*
11
0..*
Ejemplo: Combinando Clases
Se elije Teacher ya que no todos los instructores en la Universidad han alcanzado el nivel de Professor
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo: Combinando Clases de Control
Desde que una clase de control es asignada para un caso de uso como un paso inicial, se hace necesario re-evaluar las clases de control
Las clases de control con comportamientos similares pueden ser combinadas
Ejemplo:
El “Administrador” interactúa con el caso de uso “MantenerInformaciónEstudiante” y con el caso de uso “MantenerInformaciónProfesor”
Dos clases de control fueron creadas La secuencia en cada una de estas dos clases de control es muy
similar (revisión, creación, borrar información acerca del autor) Las clases de control pueden ser combinadas en una sola clase
de control llamada AdministraciónDeUsuarios
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Student
nameaddressphoneNumbermajornumStudentsinMajor
changeMajor()
Student
nameaddressphoneNumber
changeMajor( )
Major
namenumberStudents
1
0..*
1
0..*
Dividiendo Clases
Clases con estructuras y/o comportamientos que no están cohesionados pueden ser divididos en diferentes clases
Ejemplo:
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Eliminando Clases Una clase puede ser eliminada del modelo si
No tiene ninguna estructura o comportamiento
No participa en ninguno de los casos de uso
En particular, examine las clases de control
La falta de responsabilidad en la secuencia podría llevar a la eliminación de la clase de control
Ejemplo:
Un caso de uso para el actor “Professor” es “Seleccionar Cursos a enseñar”
Esto significa que el actor “Professor” ingresa el nombre y número del curso y un vínculo a la clase “ProfessorInformation” es creado
Ya que no hay demasiado comportamiento secuencial, esta clase de control es eliminada
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Secuencia Actualizado
: Professor
: ProfessorCourseForm
: Course
1: open
3: set course
4: process
2: set prof id
5: addProfessor ( )
6: quit
: ProfessorCourseForm
: Professor
: Course : ProfCourseManager
1: open
3: set course
4: process
2: set prof id
7: quit
5: addProfessor ( )
6: addProfessor ( )
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Preguntas de Chequeo de Consistencia
Los diagramas de clases y los diagramas de interacciones deben ser revisados para verificar su consistencia
¿Es cada operación de una clase necesaria para al menos un escenario?
¿Existe una clase por cada objeto en el diagrama de interacciones?
Si un diagrama de objetos o interacciones muestra un mensaje viajando desde un objeto de clase A a un objeto de clase B, verifique que
Una operación en la clase A es la responsable del envío del evento
Una operación en la clase B espera el evento y lo maneja
Una asociación correspondiente ha sido definida entre la clase A y la clase B en el diagrama de clases
El diagrama de transición de estado para la clase B (si ha sido desarrollado) incluye este evento
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Reestructurando Paquetes
Mientras más casos se desarollan se hace necesario reestructurar los paquetes en el modelo
Fuerte acoplamiento entre paquetes puede significar que los paquetes deben ser combinados
Dos vías de dependencia entre paquetes puede significar que el paquete debe ser dividido
Evalúe las consideraciones de reuso Un paquete reusable debe tener pocas dependencias
Evalúe las partes públicas y privadas del paquete No toda clase en un paquete debe ser parte de la interfaz
pública del paquete Agregar clases de interfaz si es necesario para
encapsular el paquete
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Homogenización
Discuta las decisiones de homogenización necesarias en este punto del análisis
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Homogenización
Mientras más escenarios y casos de uso se desarrollan se hace necesario hacer al modelo homogéneo
Las clases son examinadas para determinar si Dos o más clases pueden ser combinadas Una clase debe ser dividida Una clase debe ser eliminada por completo
Los paquetes son reestructurados para resolver problemas de Acoplamiento Reuso Visibilidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Diseño Arquitectónico
Ser capaz de: Listar los atributos de una buena arquitectura Investigar la vista de arquitectura “4+1” Explicar el propósito de los diagramas de componentes Explicar el propósito de los diagramas de implantación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Visión Arquitectónica
Dos características comunes para que virtualmente todos los proyectos OO sean exitosos son:
La existencia de una fuerte visión arquitectónica La aplicación de un ciclo de vida incremental, iterativo y bien
administrado La arquitectura debe ser simple Una conducta común lograda a través de abstracciones y
mecanismos comunes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mary Shaw
“La arquitectura de software está relacionada con la organización de los sistemas de software, la selección de los componentes de los cuales ellas están compuestas, las interacciones entre esos componentes, la composición de componentes que interactúan hacia subsistemas mayores progresivamente, y los patrones generales que guian esas composiciones. Esto tiene que ver no solamente con la estructura de los sistemas, sino también con su funcionalidad, desempeño, diseño, selección entre alternativas y comprensibilidad.”
Una Definición de Arquitectura de Software
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Atributos de Buenas Arquitecturas
Las buenas arquitecturas se construyen en capas bien definidas de abstracción:
Cada capa representa una abstracción coherente Cada capa tiene una interfaz controlada y bien definida Cada capa se construye sobre facilidades bien definidas y
controladas a niveles más bajos de abstracción Hay una clara separación entre la interfaz y la implementación de cada
capa Los cambios en la implementación de una capa no violan las
suposiciones hechas por sus clientes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Desarrollando la Arquitectura del Sistema
El diseño arquitectónico aborda la administración de riesgos Las buenas arquitecturas son determinadas mejor a través del
desarrollo incremental e iterativo A un pequeño equipo de arquitectos experimentados, guiado por un
Arquitecto Jefe, se le debe asignar la responsabilidad para: Definir y mantener la integridad arquitectónica del sistema Aprobar todos los cambios para las interfaces del paquete Valorar los riesgos del proyecto Proponer el orden y el contenido de cada iteración
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Dimensiones de la Arquitectura de Software
Diferentes perspectivas para las diferentes partes Usuarios finales, clientes y el administrador de proyecto Ingeniero de sistema, desarrollador, arquitecto y probador
Perspectivas múltiples requieren vistas múltiples Los diagramas de clases no muestran como los sistemas
mapean con el hardware Los diagramas de bloque del hardware no representan qué
partes del sistema son software estándar comercial
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Una Arquitectura Requiere Múltiples Vistas
Para describir completamente una arquitectura, se requieren cuatro vistas:
La vista lógica para proveer una descripción estática de las clases primarias y sus relaciones
La vista de componentes para mostrar cómo el código se organiza en paquetes y bibliotecas y el uso de software estándar comercial
La vista de procesos para mostrar los procesos y las tareas La vista de implantación para mostrar los procesadores,
dispositivos y enlaces en el medio operacional Finalmente, una vista de escenarios (vista de casos de uso) explica
cómo las otras cuatro vistas trabajan en conjunto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El Modelo “Vista 4+1”
Vista de Componentes
Vista Proceso Vista Implantación
Vista Caso de Uso
Vista Lógica
Funcionalidad
Usuarios Finales
Administración de Software,Reuso, Portabilidad
Ingenieros de Software
Desempeño, Disponibilidad,
Tolerancia a fallos
Integradores de Sistema
Desempeño, Disponibilidad, Tolerancia a fallos, Escalabilidad,
Entrega e Instalación
Ingenieros de Sistema
ComprensibilidadUsabilidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Vista Lógica
La vista lógica de la arquitectura se concentra en los requerimientos funcionales del sistema
Qué le proveerá el sistema a sus usuarios en términos de servicios
Provee una descripción estática de las clases primarias y sus relaciones
La vista lógica es capturada en los diagramas de clases los cuales contienen los paquetes, las clases y las relaciones que representan las abstracciones claves del sistema bajo desarrollo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
ClasesBásicas
global
Paquetes Lógicos Globales
Ciertos paquetes son usados por todos los otros paquetes Clases básicas
Conjuntos, listas, colas, etc. Clases para la manipulación de errores
Estos paquetes son marcados como globales
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Paquete Cliente
Paquete Suministrador
Implicaciones de Dependencia
Algunas de las implicaciones de la dependencia entre paquetes son: Cada vez que se le hace un cambio al paquete suministrador, el
paquete cliente tiene, potencialmente, que ser recompilado y vuelto a probar
El paquete cliente no puede ser reusado de manera independiente debido a que este depende del paquete suministrador
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Evitando Dependencias Circulares
Es deseable que la jerarquía del paquete sea acíclica Esto significa que la siguiente situación deberá ser evitada (si es
posible) El paquete A usa el paquete B, el cual usa el paquete A
Tal dependencia circular significa que los paquetes A y B efectivamente tendrán que ser tratados como un paquete simple
Círculos mayores de dos paquetes también tendrán que ser evitados Ejemplo, el paquete A usa el paquete B el cual usa el paquete C
que a su vez usa al paquete A Las dependencias circulares pueden ser fraccionadas dividiendo uno
de los paquetes en dos paquetes menores
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Dependencia Circular en el Sistema de Registro
Interfaces Reglas de Negocio
Cambia a Interfacesde Entrada Reglas de
Negocio
Interfaces de Salida
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Interfaz Pública de un Paquete
Una interfaz de un paquete debe encapsular su implementación detrás de una interfaz pública tal como lo hace una clase
Cada clase en un paquete tiene un parámetro de control de exportación, el cual debe ser fijado a público o implementación (privado)
Solamente las clases públicas podrán ser usadas por clases de otros paquetes
Las clases de implementación (privadas) solamente pueden ser usadas dentro de su paquete
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Vista de Componentes
La vista de componentes de la arquitectura tiene que ver con la organización modular del software real dentro del medio de desarrollo
Los diagramas de componentes se crean para mostrar los paquetes y componentes que conforman el sistema bajo desarrollo
Muestra la asignación de clases a los componentes Muestra la asignación de componentes a los paquetes
Los paquetes se organizan en una jerarquía de capas, donde cada capa tiene una interfaz bien definida
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un componente es una unidad de código fuente que sirve como un bloque de construcción para la estructura física de un sistema
Estereotipos (con iconos alternativos) pueden ser usados para definir tipos específicos de componentes.
Ejemplos: exe, dll, programas principales, encabezados, módulos, formularios
Las clases que se agrupan en una componente son aquellas que o bien tienen funciones cooperativas o las que necesitan estar en una proximidad cercana por eficiencia de implementación
Notación de un componente: Nombre Componente
¿Qué es un Componente?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Nombre 1
Nombre 3
Nombre 2
Nombre 1
Nombre 2
Diagramas de Componente Un diagrama de componente muestra la localización de las clases y
los objetos en la implementación de componentes así como sus dependencias en compilación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagramas de Componente (cont.)
Se requiere Un nombre para cada componente, este nombre típicamente denota el nombre del archivo físico correspondiente en el área de trabajo de desarrollo
La única relación es una dependencia de compilación, representada por una línea discontinua direccionada que apunta al módulo para el cual existe
En C++, una dependencia de compilación se indica por las directivas #include
No pueden existir ciclos dentro de un conjunto de dependencias de compilación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Curriculum
Curso
Curriculum
Curso
Ejemplo: Diagrama de Componente
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Nombre del paquete
Paquetes en la Vista Componente
Un paquete en la vista componente es una colección de componentes, algunos de los cuales están visibles a otros paquetes y otros están ocultos
Un paquete agrupa componentes que están lógicamente relacionados Un paquete en la vista componente agrupa componentes de modo
similar a los paquetes que en la vista lógica agrupan clases Cada componente en un sistema tiene que vivir en un paquete simple
o al más alto nivel del sistema Notación:
Ing. Ernesto Calderón Yarlequé
VENS
VENS
MFC Interfaz deregistro deusuario
Sistema deRegistro
Diagramas de Componentes Principales
Un diagrama de componente principal es una familia de paquetes conectados a través de enlaces dirigidos que representan dependencias
Ejemplo:
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Correspondencia entre Paquetes en las Vistas Lógicas y de Componentes
En general, un paquete en la vista lógica puede corresponder directamente a un paquete en la vista de componentes
Las estructuras lógica y física pueden variar por las siguientes razones:
Los paquetes en la vista lógica son agrupados, es decir, se mantienen a los objetos unidos comunicándose estrechamente para la implementación
Los paquetes en la vista componente son añadidos para implementar la funcionalidad a bajo nivel no representada durante el análisis
La estructura de división del trabajo del equipo de desarrollo influencia la asignación de paquetes y componentes en la vista componentes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo: Correspondencia entre Paquetes en las Vistas Lógica y de Componente
Diagrama de Vista Lógicade Alto Nivel
Diagrama de Vista Componente de Alto Nivel
MFC Interfaz deRegistro deUsuario
Sistema deRegistro
DispositivoGUI Interfaz de Registro deUsuario
Sistema deRegistro
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Vista de Proceso
La vista del proceso de la arquitectura se enfoca en el proceso de descomposición
Esta vista muestra la localización de los componentes a procesar El diagrama componente es actualizado para mostrar la localización de
los componentes a procesar La vista proceso se concentra en la disponibilidad del sistema,
confiabilidad, desempeño, administración del sistema y sincronización
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Especificación del paquete (DLL) Especificación de la tarea (EXE)
Componentes de Proceso
Las bibliotecas ejecutables y vinculadas son representadas mediante componentes en UML
Especificación del paquete (DLL) Especificación de la tarea (EXE)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Nombre1Nombre2
Nombre1 Nombre2
MiProceso.exe
Diagrama de Componentes para un Proceso
Cada componente puede depender de otras componentes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Procesos para el Sistema de Matrícula de Curso
Curriculum.exe Matrícula.exe
Proceso para la creación y mantenimiento del curriculum
Proceso para la selección de cursospor estudiantes y profesores
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Vista Implantación
La vista de implantación de la arquitectura mapea componentes con nodos de procesamiento
Requerimientos tales como rendimiento, desempeño y tolerancia a fallos son tomados en cuenta
Los diagramas de implantación se crean para mostrar los diferentes nodos (procesadores y dispositivos) en el sistema
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El Diagrama de Implantación
Un diagrama de implantación muestra la asignación de componentes a nodos en la vista de implantación de un sistema
Los procesadores y dispositivos son estereotipos comunes de Nodo.
Los nodos se conectan en un diagrama que refleja los caminos de comunicación entre ellos
Los elementos esenciales en un diagrama de implantación son los nodos y sus conexiones
Ing. Ernesto Calderón Yarlequé
VENS
VENS
nodo conexión
nombre etiqueta
Notación para Diagramas de Implantación
Un nodo es un objeto físico en tiempo de ejecución que representa recursos computacionales
Una conexión indica comunicación, usualmente mediante el acoplamiento directo de hardware
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Sistema deRegistro
Base de datos
Dormitorios
Bloque Principal
Biblioteca<<dispositivo>>
<<dispositivo>>
<<dispositivo>>
Ejemplo: Diagrama Implantación del Sistema de Registro
Este diagrama muestra dos nodos y los dispositivos con los cuales el sistema de registro se comunica
Ing. Ernesto Calderón Yarlequé
VENS
VENS
proceso 1, proceso 2, ... proceso n
Nombre delProcesador
Procesos
Un proceso es la ejecución de un hilo de control de un programa (OO) o sistema
Un sistema extenso puede ser dividido en múltiples procesos o hilos de control
Los objetos son asignados a los procesos (sus asignaciones pueden ser dinámicas)
Los procesos son asignados a procesadores (el conjunto de procesos puede ser dinámico)
Notación:
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mapeando Paquetes de Desarrollo a Procesos Ejecutables
El mapeo de los paquetes de desarrollo a procesos ejecutables involucra el entendimiento de la topología y las prioridades del sistema, incluyendo:
Arquitectura, velocidad y capacidad del procesador Mantener las asociaciones de clases juntas para minimizar la
comunicación entre procesos (IPC) Estrategia IPC -- ¿cliente/suministrador u otros? Técnicas de Procesamiento Distribuido
Se tienen que resolver las cuestiones que involucren múltiples procesadores de hardware o de sistemas distribuidos, durante el diseño del sistema.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mapeando Procesos Ejecutables al Hardware
Los procesos tienen que ser asignados a un dispositivo de hardware para su ejecución
Entre las consideraciones se encuentran: Tiempo de respuesta y rendimiento del sistema Capacidad y ancho de banda de las comunicaciones Localización física del hardware requerido Requerimientos del procesamiento distribuido Sobrecarga o estabilización del procesador en un sistema
distribuido Tolerancia a fallos . . .
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Vista Caso de Uso
Los casos de uso son los manipuladores para el diseño arquitectónico Abstracciones de requerimientos complejos, extensos Identificación de interfaces críticas Forzar a los diseñadores a enfocarse en asuntos concretos
Ellos demuestran y validan las vistas de implantación, lógica, de proceso y de desarrollo de la arquitectura
Ing. Ernesto Calderón Yarlequé
VENS
VENS
La “Vista 4+1” de un Modelo UML
Vista Componente
Vista Proceso Vista Implantación
Vista Caso de Uso
Vista Lógica
Diagramas de clases,Diagramas de secuencia Diagramas de
Componentes
Diagramas de implantación Diagramas de implantación
Diagramas Casos de Uso,Diagramas de Secuencia
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Cómo está la Arquitectura Documentada?
La arquitectura está documentada en un documento de arquitectura Aproximadamente 100 páginas para un sistema extenso
El documento incluye: Una descripción textual de la filosofía arquitectónica (las vistas) y
los requerimientos claves de manejo Balances hechos y alternativas consideradas Una vista de alto nivel de la vista lógica (paquetes y clases
claves) Escenarios específicos a arquitecturas Vistas de desarrollo, de procesos a alto nivel y vistas de
implantación Los mecanismos claves
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Quién Desarrolla la Arquitectura de Software?
Lo hace el equipo de arquitectura: un grupo de los mejores y más experimentados desarrolladores
Se establece al principio en el proyecto (no después de la fase de elaboración)
La mayoría de los proyectos de una complejidad razonable requieren de un equipo de arquitectura, no de simplemente un único arquitecto
Dirigido por el arquitecto jefe quien estará 100% dedicado Incluye los guías para los diseñadores de las funciones
principales y de las funciones críticas del sistema
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Evolución del Equipo de Arquitectura
Fase de Elaboración
Fase de Construcción
Equipo de Arquitectura•Arquitecto•Diseñadores guias•Desarrolladores de infraestructura
Equipo de Arquitectura•Arquitecto•Grupo pequeño de apoyo
Equipo 1 de la Aplicación•Diseñador guia•Ingenieros de aplicación
Equipo 2 de la Aplicación•Diseñador guia•Ingenieros de aplicación
.
.
.
En la fase de elaboración, los miembros están 100% dedicados al equipo de arquitectura. Durante la construcción, los miembros se convierten en diseñadores guias de los equipos de aplicación y apoyan parcialmente al equipo de arquitectura
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Con una buena arquitectura, un equipo de desarrollo promedio puede tener éxito. Con una arquitectura débil,
inclusive los desarrolladores más expertos no tendrán éxito
Beneficios de un Equipo de Arquitectura
Entregables Documento de Arquitectura Partes de los documentos de diseño de bajo nivel Guías para el diseño y la programación Elementos de los planes de puesta en circulación Revisión del diseño del sistema entregado
La eficacia y habilidades del equipo de arquitectura son críticas para el éxito de un proyecto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Diseño arquitectónico
Discutir las consideraciones de la arquitectura para el problema Añadir modelos al paquete mientras sea requerido
Reubicar clases en los diferentes paquetes mientras sea requerido
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Diseño Arquitectónico
El propósito de esta fase es crear una arquitectura para la implementación y establecer las políticas tácticas comunes que tienen que ser usadas a lo largo del sistema
Los atributos de las buenas arquitecturas son: Las buenas arquitecturas son construidas en capas de
abstracción bien definidas Existe una separación clara entre la interfaz y la implementación
de cada capa La arquitectura es simple
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Diseño Arquitectónico (cont.)
La vista lógica de la arquitectura se concentra en los requerimientos funcionales del sistema
Los diagramas de clases los cuales representan las abstracciones claves del sistema
La vista proceso de la arquitectura se concentra en la disponibilidad, confiabilidad, escalabilidad, integridad, desempeño, administración y sincronización del sistema
El sistema se descompone en un conjunto de tareas independientes las cuales se agrupan en procesos
La vista componente de la arquitectura se concentra en la organización del software del sistema
Los diagramas de componentes se crean para mostrar los paquetes y componentes que conforman el sistema
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Diseño Arquitectónico (cont.)
La vista de implantación de la arquitectura mapea el software con los nodos de procesamiento
Los diagramas de implantación son creados para mostrar los diferentes procesadores y dispositivos en el sistema
Los casos de uso demuestran y validan las vistas lógica, de proceso, desarrollo y de implantación de la arquitectura
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Mecanismos Claves
Ser capaz de: Describir algunos mecanismos claves específicos a OO Explicar los aspectos asociados con la interfaz de base de datos Listar algunas consideraciones para la evaluación de los sistemas de
administración de bases de datos Describir el manejo de excepciones y sus tópicos asociados Explicar los aspectos asociados con la comunicación entre procesos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Qué son los Mecanismos Claves?
Un mecanismo clave es una decisión estratégica teniendo en cuenta estándares, políticas y prácticas comunes. Por ejemplo:
Una propuesta común para el manejo de errores, o Una forma común de comunicación entre procesos
La mayoría de los principios del diseño de software tradicional aún se aplican en el diseño OO
Los problemas a ser resueltos son similares, como por ejemplo, la contención de recursos, la atenuación de riesgos y otros
Se producen algunas diferencias debido a: Soluciones que siendo estructuradas usan métodos OO Las características de los lenguajes de programación OO
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mecanismos Claves Comunes
Administración de la contención de recursos Manipulación especial requerida para el arranque y término del sistema Integración con los sistemas de almacenamiento de datos persistentes Detección, manipulación y reporte de errores Comunicación entre procesos Pase de mensajes Aspecto y sensación de la interfaz de usuario Reuso del software
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Contención de los Recursos
Una clase administradora de recursos podrá ser usada para controlar el acceso a los recursos
La clase administradora utiliza métodos de software tradicionales, tales como semáforos para controlar el acceso a sus recursos
El administrador provee operaciones para permitir a los clientes de los recursos adquirirlos, liberarlos, ponerlos en cola para adquirirlos, obtener sus estado, etc
Una superclase que contiene la interfaz a los recursos administrados puede ser suministrada con el administrador de recursos para mejorar su reusabilidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Contención de los Recursos (cont.)
Fichero MemoriaCompartida
AdministradorRecurso
adquiere ()libera ()
RecursoAdministrado
1..*1 1..*1
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Arranque y Término del Sistema
Si ya no se ha cubierto durante el análisis, deberán ser definidos los casos de uso, tanto para el arranque como para el término del sistema
Los escenarios deberán ser desarrollados para cada caso de uso - tantos como sean requeridos para la manipulación de todas las principales situaciones, tanto normales como atípicas
Durante este proceso nuevos estados y conductas pueden ser descubiertos para las clases existentes y puede originarse la necesidad de nuevas clases para controlar el arranque y término del sistema
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetos Persistentes
Un objeto persistente es aquel que existe lógicamente más allá del alcance del programa que lo creó
Los lenguajes de programación OO tratan solamente con los objetos esencialmente transitorios, residentes en memoria
Un objeto persistente tiene la capacidad de guardar los valores de sus atributos en algún tipo de almacenamiento persistente
Un objeto persistente puede también ser creado en memoria e inicializado con sus valores de atributos desde un almacenamiento persistente
La estrategia completa para proveer persistencia a los objetos en el sistema, es un mecanismo clave
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Almacenamiento Persistente
El almacenamiento persistente puede hacerse usando un sistema de archivo simple o algún tipo de sistema de administración de base de datos
Existen varios modelos para DBMSs: Jerárquico En red Relacional (RDBMS) Orientado a objeto (ODBMS)
El Relacional y el ODBMSs son los más comunes
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Seleccionando una Propuesta para la Persistencia
La estrategia de diseño para retener objetos persistentes tiene que considerar
Tiempos de acceso Capacidad de almacenamiento Confiabilidad en los sistemas de almacenamiento Accesos a datos existentes
El modelo seleccionado influencia al sistema y al diseño de objetos en que los diseñadores tienen que considerar:
Métodos adicionales de objetos para almacenar y obtener los objetos persistentes
Adición de atributos para manipular detalles del sistema de almacenamiento
Clases adicionales para interactuar con el DBMS
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Criterio de Evaluación del DBMS
El criterio de evaluación para seleccionar un DBMS debe ser decidido desde el inicio
Las siguientes transparencias contienen criterios encontrados en “Consideraciones Para la Evaluación de Sistemas de Administración de Bases de Datos Objetos” por Robert Gancarz y Grant Colley, Object Magazine, Marzo/Abril 1992
Estos criterios también se aplican para la selección de un sistema de administración de bases de datos relacionales
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Fortalezas del proveedor Considerar la fortaleza financiera, la estructura de la
organización, los procedimientos de apoyo al cliente, el entrenamiento y apoyo a consultas y asociaciones con otras compañías
Desempeño de la Base de datos Ningún estándar de comparación de rendimiento puede probar
que la DBMS es la más rápida para todas las aplicaciones El desempeño depende de la aplicación
Son muy importantes los prototipos específicos de la aplicación
Potencial de las Bases de datos La administración de transacciones, el control de concurrencia,
resguardos y recuperaciones, la seguridad y los lenguajes de consulta respaldan las capacidades que deben ser evaluadas
Criterio de Evaluación de un DBMS (cont.)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Criterios de Evaluación del DBMS (cont.)
Arquitectura de la Base de datos Evaluar los esquemas de control de concurrencia, los
mecanismos de bloqueo y los administradores de almacenamiento
Herramientas de desarrollo Seleccionar las herramientas para el diseño de la base de datos,
la modificación del esquema de la base de datos y la navegación y depuración de la base de datos
Ayuda del lenguaje Asegurar que exista ayuda en el lenguaje seleccionado para el
sistema que está siendo desarrollado Facilidad de migración
Cuán fácil/difícil es migrar hacia el sistema de base de datos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
En el fondo: Invertir el tiempo y energía para seleccionarel sistema de administración de bases de datos adecuadopara el proyectoEs SIEMPRE más caro corregir un error que hacer las cosas correctas desde la primera vez !!!
En el fondo: Invertir el tiempo y energía para seleccionarel sistema de administración de bases de datos adecuadopara el proyectoEs SIEMPRE más caro corregir un error que hacer las cosas correctas desde la primera vez !!!
Criterio de Evaluación del DBMS (cont.)
Integración con Sistemas Existentes Cuán fácil/difícil es la integración con los sistemas de
administración de bases de datos existentes Soporte multiusuario
Evaluar el soporte para el desarrollo multiusuario, la administración de configuración, diferentes versiones y estrategias de bloqueo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Aspectos de las Bases de Datos Relacionales
Hay dos aspectos principales a contemplar cuando se diseña un sistema OO usando una base de datos relacional
Existe una diferencia semántica natural entre el modelo basado en clases, de un diseño orientado a objeto y el modelo basado en tablas de una base de datos relacional
Un mapeo o traducción entre ambos tiene que ser definido La conducta que interactúa con el RDBMS y la implementación de esta
traducción tienen que estar definidas ¿Deberá esta conducta estar insertada en objetos persistentes o
de algún modo ser mantenida separada?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mapeos más complicados son posiblesOne class maps to multiple tablesMultiple classes map to one table
Cliente
nombredireccióndescuento
Tabla del Cliente
clienteID nombre dirección descuento
Mapeo a Bases de Datos Relacionales
Típicamente, cada clase mapea con una tabla y cada instancia mapea con una fila.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tabla Orden
ordenID entrega urgencia clienteID
Tabla Cliente
Cliente
nombredireccióndescuento
Orden
tiempoEntregaurgencia
0..*
11
0..*
clienteID nombre dirección descuento
Mapeo a Bases de Datos Relacionales(cont.)
Las relaciones uno-a-muchos se implementan usando una llave externa en la tabla representando el lado “muchos” de la relación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tabla Ingrediente del Producto
productoID ingredienteID
Producto
Ingrediente
1..*
0..*
1..*
0..*
Mapeo a Bases de Datos Relacionales (cont.)
Las tablas se crean para resolver relaciones muchos-a-muchos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Tabla Orden
ordenID fechaEntrega urgencia
ordenID fechaFin fechaInicio
Tabla OrdenEspecial
Orden
fechaEntregaurgencia
OrdenEspecial
fechaIniciofechaFin
OrdenPendiente
frecuencia
Mapeo a Bases de Datos Relacionales (cont.)
Las superclases / subclases pueden también ser mapeadas a tablas Cada clase y subclase es una tabla Las vistas son provistas para la jerarquía
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Mapeo a Bases de Datos Relacionales (cont.)
Existen estrategias alternativas para las superclases y subclases Repetir todos los atributos en la tabla superclase
Problema: espacio desperdiciado Repetir todos los atributos en la tabla subclase
Problema: redundancia Desempeño versus balanceo del espacio de almacenamiento se usan
para decidir qué mapeo usar en situaciones de herencia
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Interactuando con RDBMS
El principal aspecto asociado con la interacción con un RDBMS es si separar la conducta específica de la aplicación de la conducta específica de la base de datos
Suponga que nuestro sistema tiene una clase Cliente la cual hemos decidido que debe ser persistente
¿Debe la clase cliente contener los detalles de mapeo OO-a-RDBMS?
¿Debe la clase Cliente contener el funcionamiento para interactuar con el agente RDBMS (es decir, código que genere SQL para leer/escribir desde/hacia la base de datos?
¿Debe la clase Cliente inclusive saber que ésta es persistente? Cualquier modo puede funcionar - cada uno tiene sus propias ventajas
y desventajas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Interactuando con RDBMS (cont.)
La conducta específica a la base de datos no separada de la conducta específica a la aplicación:
Cada clase persistente puede tener incorporada funcionalidades de crear, leer, actualizar y borrar (CRUD) (es decir, operaciones que ejecuten mapeos OO-a-RDBMS y generen SQL para implementar esto)
Ventajas Ningún reto técnico para implementarlo
Desventajas Los modelos OO y RDBMS no son separables La funcionalidad CRUD no siempre es puramente
heredable
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Conducta de la Base de Datos dentro de la Clase
: AdministradorCurriculum : Curso
1: guardar ( )
Curso
descripción
guardar ()El Curso tiene que tenerconocimiento de la base de datos
El Curso tiene que tenerconocimiento de la base de datos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Interactuando con RDBMS La conducta específica a la base de datos se separa de la conducta
específica de la aplicación El sistema puede ser modelado en dos partes: la Aplicación y la
Interfaz con la Base de datos Para cada clase persistente, se define una clase de interfaz
de base de datos asociada la cual entiende el mapeo OO-a-RDBMS y tiene la funcionalidad para interactuar con el RDBMS
Ventajas El modelo OO es separable del modelo RDBMS Las herramientas están disponibles para generar las clases
básicas de interfaz con la base de datos Desventajas
Un reto técnicamente mayor de implementación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
: AdministradorCurriculum : AdministradorTransacción
: CursoBD : Curso
1:guardarCurso (Curso)
2: guardar(Curso)3: obtenerDescripcion ( )
4: hacerPersistente ( )
El AdministradorTransacciónsepara lo lógico (Curso)de lo físico (CursoBD)
El AdministradorTransacciónsepara lo lógico (Curso)de lo físico (CursoBD) Curso
AdministradorTransacción
CursoBD
Separar la Conducta de la Base de Datos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
DBMSs Orientados a Objetos
ODBMSs permiten almacenamiento, recuperación y restablecimiento de los propios objetos (con datos complejos encapsulados dentro de cada objeto)
Un ODBMS típicamente contiene Objetos (es decir, valores de atributos) Información de clase sobre cada objeto
No hay diferencia semántica entre el modelo OO y el modelo ODBMS - ellos son idénticos
Ningún funcionamiento especial tiene que ser diseñado para interactuar con el ODBMS
Ing. Ernesto Calderón Yarlequé
VENS
VENS
DBMSs Orientados a Objetos (cont.) Ventajas:
Interfaz no fundida entre la aplicación y la base de datos Relativamente poco código requerido para crear objetos
persistentes Muy efectivo con sistemas que tienen que contemplar estructuras
de datos complicadas Desventajas:
Mayor riesgo de desarrollo mientras la tecnología ODBMS y sus productos no estén tan maduros como sus contrapartes RDBMS
Desempeño con estructuras de datos más simples no provee ventajas sobre RDBMS
Las inversiones existentes en tecnología relacional, tienen que ser consideradas cuando se vaya a evaluar tecnología de bases de datos orientada a objetos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Detección de Errores
Una propuesta consistente para la detección de errores debe ser establecida
Los objetos deben detectar los errores que violarían sus integridades - estos errores son:
Los producidos dentro de sus operaciones Los resultantes de parámetros recibidos de objetos clientes Los resultantes de valores retornados provistos por los objetos
suministradores Un plan puede ser establecido para monitorear la salud del sistema
Operación de prueba para cada clase que verifique la integridad de la estructura interna y del entorno
Monitoreo de objetos definido para, periódicamente, consultar cada función de prueba del objeto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Manejo de Errores
Inclusive en los sistemas OO, el manejo de errores tiene que ser cuidadosamente diseñado -- más del 30% del código final frecuentemente existe para manipular condiciones de errores
Los lenguajes modernos OO (tales como C++ ) proveen características para el manejo de excepciones que ayudan en este diseño
El manejo de excepciones permite que un error sea manipulado por un objeto fuera del objeto que detectó el error
Esto es frecuentemente apropiado, debido a que el amplio impacto de un error en el sistema no es siempre conocido por el objeto que lo detecta
Ing. Ernesto Calderón Yarlequé
VENS
VENS
class String {public: class RangeError { int badIndex; }; // error type char getChar(int index) const; // ...};char String::getChar(int index) const { if (index < 0 || index > lastValid) throw RangeError(index); // throw point return contents[index];};void foo() {
try { String s = “hello”; char c = s.getChar(0); } catch (const String::RangeError& why) { // catch point cout << “subscript out of range” << why.badIndex << endl; }}
Ejemplo del Manejo de Excepciones
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Lanzando y Capturando Excepciones
Cuando hay un problema que no puede ser manejado en el contexto actual, una excepción puede ser creada y “lanzada”
lanzar Problema(“las cosas están mal”); ¿Qué hace lanzar?
El objeto excepción es creado y “retornado” ¿A dónde va el objeto excepción?
Cuando una excepción se lanza, en la pila de llamadas se busca el primer manipulador que machee
Habrá un manipulador de excepción por cada tipo de excepción que pudiera ser capturada
catch (Problem&) {
// maneja excepciones del tipo Problem}
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Aspectos del Manejo de Excepciones
En el proceso de búsqueda en la pila de llamadas, destructores para objetos locales son llamados para
Variables Automáticas Parámetros por valor Valores temporales
Destructores no se llaman para Variables Dinámicas Variables Estáticas
El código después del punto de lanzamiento nunca es ejecutado Las excepciones se atribuyen administración de recursos (por ejemplo,
el cierre de ficheros abiertos)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Deben Siempre ser Usadas las Excepciones?
Las excepciones no deben ser usadas en las siguientes situaciones: Condiciones de errores comunes
Si hay suficiente información disponible para manejar el error, entonces esto NO es una excepción
Para controlar el flujo del programa Una excepción NO es un retorno alternativo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Cuándo Deben Ser Usadas Las Excepciones?
Las excepciones son lanzadas como resultado de un error grave No hay retorno al punto donde fue lanzada la excepción
Las excepciones no deben ser usadas si el error puede ser manejado (corregido) y el procesamiento puede continuar
Una operación puede ser llamada para “reparar” el problema y el procesamiento puede continuar
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Usos Típicos de las Excepciones
Reparar el problema y continuar el procesamiento sin volver a la función que lanzó la excepción
Calcular un resultado alternativo Lanzar el error a un contexto mayor Terminar el programa Agrupar funciones que usan esquemas de errores comunes Simplificar el código Hacer el código más fácil de mantener
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Reportando los Errores
Mantener registrado el error respectivo y reportar on-line son claves para la mayoría de los sistemas
Una conducta consistente en el reporte de errores puede ser implementada en la clase de error básica usada en el manejo de excepciones
Esta conducta puede incluir Añadir el error a un registro de errores de alcance a todo el
sistema Distribuir el error para el procesamiento, el cual facilita el
monitoreo de errores on-line Este tipo de propuesta asegura consistencia a la vez que separa la
responsabilidad detallada de las clases de la aplicación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
ClaseA ClaseB
functionB( )
: ClaseA : ClaseB
1: functionB ( )
Comunicación entre procesos
ClaseA llama a una operación de la ClaseB, functionB() ¿Qué sucede cuando ClaseA y ClaseB están en procesos diferentes? Esto se convierte en un aspecto crítico en los sistemas distribuidos Se requiere un mecanismo estándar para la comunicación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Comunicación entre Procesos(cont.)
Una solución común que soporta el paradigma OO ha sido desarrollada
Las clases Proxy se insertan en cada proceso el cual provee las interfaces de las clases originales y encapsula la comunicación a más bajo nivel
La distribución es transparente a las clases de la aplicación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Estándares Distribuidos OO
Seleccionar un estándar de distribución es un asunto de diseño si el sistema usa objetos distribuidos
Hay dos estándares emergiendo para la distribución OO Common Object Request Broker Architecture (CORBA) Component Object Model (COM/OLE) Java Beans
Object Request Brokers (ORB) provee acceso transparente a objetos en un medio distribuido
ORB permite conectividad cliente/servidor independiente de la ubicación
Las decisiones de distribución pueden ser tomadas en tiempo de ejecución
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Clases Proxy
ClaseA ClienteProxyB
Object Request Broker
ServidorProxyB ClaseB
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Planificando para el Reuso
Los componentes reusables tienen que ser considerados al inicio en el diseño para su incorporación al sistema
Evaluar bibliotecas de software internas, comerciales para módulos que apliquen en el sistema
Las bibliotecas de clases son grupos de clases colaborando que proveen algún servicio, interfaz o función
Las bibliotecas de clases están comúnmente disponibles para: Objetos contenedores Interfaces a bases de datos Ventanas de interfaz de usuario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Actualizando Diagramas
Los diagramas de clases se actualizan para mostrar los mecanismos claves seleccionados
Los diagramas de secuencias se actualizan para mostrar interacción entre las clases ya descubiertas y las clases que representan las estrategias de mecanismos claves
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Clase Actualizado
Equipos de Universidad
Interfacesde entrada
Reglas delnegocio
Interfaces de salida
Base de datos
VentanasGUI
Basamento
global
Manejo de errores
global
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Secuencia Actualizado
anOffering : (Course : Registrar
aForm : CurriculumMgr
theCourse : Course
dbMgr : TransactionMgr
dbCourse : DBCourse
dbOffering : DBOffering
theManager : CurriculumMgr
1: open
2: enter id
3: verify id
5: create a
4: enter
12: create(professor, time,
6: set number, name, description,
7: set number offerings, professor,
8: process
9: create course(number, name, description, credit hours, offerings,
10: create(number, name, description,
11: create offering(number, pofessor,
13: save 14: save(course)
15: get info
16: commit
17: save(offering)
18: get info
19: commit
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Mecanismos Claves
Discutir las estrategias de mecanismos claves para el problema Actualizar los diagramas de clases para mostrar la incorporación de los
mecanismos claves Actualizar los diagramas mientras sea necesario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Mecanismos Claves
La selección de los mecanismos claves se enfocara en las decisiones respecto a estándares, políticas y prácticas comunes, incluyendo:
Administración de la contención de los recursos Manipulación especial requerida para el arranque y la
terminación de los sistemas Integración con sistemas de almacenamiento de datos
persistentes Detección / manejo / reporte de errores Comunicación entre procesos Reuso del software
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Diseñando Clases
Ser capaz de: Discutir las decisiones de diseño de la interfaz de usuario Añadir clases para resolver los problemas de diseño Usar patrones para resolver problemas de diseño
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diseño de la Interfaz de Usuario
Las clases fronteras administran la interfaz de las comunicaciones entre el usuario y el sistema
Ellas proveen la capacidad de enviar y recibir información desde fuera del sistema
Durante el análisis, las clases fronteras de alto nivel son identificadas Durante el diseño, el diseño de la interfaz de usuario se completa
Diseño de la ventana Número de ventanas Manipulación de eventos de usuarios
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Descubriendo los Requerimientos de Interfaz
Cualquier prototipo de interfaz de usuario hecho anteriormente es un buen punto de partida para esta fase del diseño
Los diagramas de colaboración y/o secuencia también proveen una buena fuente para los requerimientos de interfaz
Algo en el sistema tiene que proveer la capacidad de recibir todos los “mensajes” que vengan de un actor
Algo en el sistema tiene que proveer la capacidad de enviar todos los “mensajes” que van hacia un actor
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Secuencia para la Creación de un Escenario de Curso
anOffering : (Course : Registrar
aForm : CurriculumForm
theCourse : Course
dbMgr : TransactionMgr
dbCourse : DBCourse
dbOffering : DBOffering
theManager : CurriculumMgr
1: open2: enter id
3: verify id
5: create a
4: enter
12: create(professor, time,)
6: set number, name, description,
7: set number offerings, professor,
8: process
9: create course(number, name, description, credit hours, offerings,)
10: create(number, name, description,)
11: create offering(number, professor,)
13: save 14: save(course)
15: get info
16: commit
17: save(offering)
18: get info
19: commit
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Requerimientos de la Interfaz de Usuario
Actor “Registrador” Entrar la información requerida para crear un curso y sus ofertas
Requerimientos desde otros escenarios El actor tiene la capacidad de crear cursos, crear ofertas, revisar
cursos, revisar ofertas de cursos, modificar cursos, modificar ofertas de cursos, borrar cursos, borrar ofertas
Decisiones de diseño Una ventana contiene todas las opciones disponibles a Registrar Una ventana contiene información del curso Una ventana contiene información de la oferta Botones disponibles en las ventanas de curso y oferta para
permitir que la información sea salvada, cancelada o borrada
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Matrícula de Cursos
John : estudiante
Formulario de matrícula
cursos disponibles
Formulario dehorarios
1: entrar id
2: validar id
3: entrar semestre actual
4: crear nuevo horario
5: mostrar
6: obtener cursos
7: seleccionar
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Interfaz del Sistema de Registro Requerimientos para este Escenario
Actor estudiante Tiene que ser provisto con un medio de selección de cursos para
el sistema actual La lista de los cursos disponibles es mostrada al actor
Decisión de diseño Una ventana GUI se crea para contener cuadros de listas (list
boxes) para las selecciones de los cursos Los cuadros de listas contienen los nombres de todos los
cursos ofrecidos
Ing. Ernesto Calderón Yarlequé
VENS
VENS
¿Que Sucede Cuando se Hace Click Sobre el Botón OK?
Todos los constructores GUI son diferentes Algunos crean objetos que contienen la información desde la
ventana Otros crean estructuras de datos con la información
Algunas técnicas comunes Las clases de control reciben los datos desde la ventana GUI y
los procesan Los datos de la ventana son pasados desde la ventana GUI
a la clase de control
ó El botón sabe qué hacer con el dato en la ventana
Ing. Ernesto Calderón Yarlequé
VENS
VENS
FuncionesMatemáticas<<utility>>
Clase Utility
El estereotipo utility se usa para una clase que contiene una colección de subprogramas libres
Los subprogramas libres son funciones no miembros, es decir, funciones que no pertenecen a una clase en particular
Las clases Utility son usualmente definidas para Proveer algunos servicios algorítmicos comunes, servicios que
pueden ser útiles en una variedad de contextos Agrupar bibliotecas no orientadas a objetos o aplicaciones
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Curso
1..*1
AdministradorMatrícula<<control>>
1..*1
Scheduling Algorithms<<utility>>
1
0..*
1
0..*
Ejemplo: Clase Utility
La clase utility “SchedulingAlgorithms” contiene funciones que resuelven conflictos de horarios
Ing. Ernesto Calderón Yarlequé
VENS
VENS
extern float inchToCentimeter(float inch);
extern float centimeterToInch (float centimeter);
Usando Funciones Libres Usando la Clase Utility C++ (recomendado)
#ifndef UNIT_UTILITIES#define UNIT_UTILITIES
class/*_utility*/ Unit_Utilities {public: static float inchToCentimeter(float inch); static float centimeterToInch(float centimeter);};
#endif // UNIT_UTILITIES
Ejemplo: Clase Utility (cont.)
Para evitar que múltiples utilidades (funciones libres C++) se conviertan en unidades separadas, una clase utility puede ser creada para empacar todas las funciones bajo una interfaz
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Clases de Ayuda
Durante el diseño, una clase puede ser añadida para “ayudar” a ejecutar alguna funcionalidad requerida
Ejemplo: El FormularioCurriculum tiene que verificar que el id entrado sea
válido Si la verificación tiene que ver solamente con el formato del
id, entonces la ventana puede ejecutar esta funcionalidad Si la verificación tiene que ver con la seguridad, entonces
información adicional es requerida Lista de números id válidos Esta clase es añadida al sistema
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El Surgimiento de Patrones
Un patrón de diseño es una solución para un problema de diseño común
Un patrón Describe un problema de diseño común Describe la solución del problema Discute los resultados y el balance de aplicar el patrón
Los patrones están siendo recopilados, catalogados, y usados para construir sistemas
Proveen la capacidad de reusar arquitecturas y diseños exitosos Conducen a sistemas más fáciles de mantener Incrementan la productividad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Adaptación de Patrones
Los sistemas de registros de cursos tienen tres tipos de usuarios: los estudiantes, profesores y el que registra
Una jerarquía UsuarioRegistro fue creada para los diferentes tipos de usuarios
El tipo de usuario a crear depende del dato entrado en una ventana GUI
Problema: ¿Quién crea el tipo específico de usuario? El patrón Factory Method puede ser usado para crear el tipo
adecuado de usuario basado en datos en tiempo de ejecución Al factory le son dados los datos y se le dice cómo crear el
tipo correcto de objeto
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El Patrón Factory
La operación crea(que) del UsuarioFactory crea el tipo adecuado de UsuarioRegistrar
La operación crea(que) del UsuarioFactory crea el tipo adecuado de UsuarioRegistrar
Estudiante Profesor Registrar
UsuarioFactory
crea (qué)
UsuarioRegistrar
11
crea
11
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Otros Ejemplos de Patrones
Prototipe -- crea un objeto mediante la copia de un objeto prototípico Unico (singleton) -- asegura que una clase tiene solamente una
instancia y brinda un punto global de acceso a esta Adaptador -- convierte la interfaz de una clase a otra interfaz Iterador -- provee una forma de acceder a los elementos de un objeto
agregación Memo -- captura y exterioriza un estado interno del objeto para que el
objeto pueda ser recuperado a este estado después (esto se hace sin interrumpir la encapsulación)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Principios a considerar: Una clase debe tener un simple pero bien enfocado propósito. Una clase debe hacer solo una cosa y hacerla bien!!!
Principios a considerar: Una clase debe tener un simple pero bien enfocado propósito. Una clase debe hacer solo una cosa y hacerla bien!!!
¿Cuántas Clases son Requeridas?
Muchas clases simples significa que cada clase Encapsula menos de la inteligencia total del sistema Es más reusable Es más fácil de implementar
Unas pocas clases complejas significa que cada clase Encapsula una gran parte de la inteligencia total del sistema Es menos probable que sea reusable Es más difícil de implementar
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio: Clases en el Diseño
Discuta clases adicionales que pudieran ser añadidas al modelo para facilitar decisiones de diseño
Actualice los diagramas si es necesario
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Clases en el Diseño
Durante el diseño, clases son añadidas para facilitar el diseño del sistema
Una clase utility es una colección de subprogramas libres Un patrón de diseño es una solución a un problema de diseño común Los patrones están siendo recopilados, catalogados y usados para
construir sistemas Brindan la capacidad de reusar arquitecturas y diseños exitosos Conducen a sistemas más fáciles de mantener Incrementan la productividad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diseñando Relaciones
Ing. ERNESTO CALDERON [email protected]
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetivos: Diseñando Relaciones
Ser capaz de: Determinar la navegación de la relación Refinar las asociaciones y relaciones de agregación Discutir opciones de la visibilidad de objetos Discutir decisiones de diseño múltiples Diseñar clases asociación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El Cliente puede “hablar” a la OrdenLa Orden no puede “hablar” al
Cliente
El Cliente puede “hablar” a la OrdenLa Orden no puede “hablar” al
Cliente
Cliente Orden
0..*0..*
Navegación En análisis, las asociaciones son bidireccionales En diseño, una asociación puede ser unidireccional
Se añade una flecha a la asociación para mostrar que la navegación va solamente en una dirección
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Decisiones de Navegación
Durante el diseño nosotros miramos si es realmente necesario navegar en ambas direcciones
La necesidad para la navegación es reflejada por los casos de usos y los escenarios
Dada una instancia de la clase A, ¿nosotros necesitamos encontrar todas las instancias asociadas de la clase B?
Dada una instancia de la clase B, ¿nosotros necesitamos encontrar todas las instancias asociadas de la clase A?
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Proveedor Producto
1..*1..* 1..*1..*
Interrogantes de la Navegación
El sistema tiene que responder preguntas tales como: ¿De qué “proveedor” puedo yo obtener este “producto”?
(producto a proveedor) ¿Qué “productos” son suministrados por un “proveedor” en
particular? (proveedor a producto)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
La Navegación en Ambos Sentidos vs. La Navegación en un Sentido
Las relaciones en los dos sentidos son más difíciles y costosas de implementar que las relaciones en un solo sentido
Inclusive si la navegación en ambos sentidos se requiere, una relación de un solo sentido pudiera bastar bajo ciertas circunstancias. Por ejemplo:
La navegación en una de las direcciones es muy poco frecuente y no tiene rigurosos requerimientos de desempeño, o
El número de instancias de una de las clases es muy pequeño
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Proveedor Producto
1..*1..*
Ejemplo: Simplificando una Relación Situación 1: Yo frecuentemente necesito saber qué proveedores
suministran un cierto producto pero, solamente necesito conocer la lista de todos los productos suministrados por un proveedor una vez al trimestre para procesar las facturas
Implementar la dirección producto-a-proveedor y buscar todas las instancias de productos cuando recopile una lista de productos para cada proveedor
Situación 2: Solamente existen dos proveedores Implementar solamente la dirección producto-a-proveedor y
buscar todos los productos registrados cuando yo requiera recorrer la relación en el sentido opuesto.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Orden
1..*
OrdenItem
Navegación para Agregaciones
Una agregación puede también ser unidireccional durante el diseño Un flecha se añade para la línea de agregación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Perfeccionamiento de las Agregaciones
Una relación de agregación significa que el objeto fuente tiene que contener conocimiento semántico del objeto blanco o destino
Las relaciones pueden ser de dos tipos: Por referencia Por valor
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Implicaciones por Valor y por Referencia
Por valor significa que los objetos se crean y se destruyen como una consecuencia de la creación y destrucción de otro objeto
En otras palabras, los tiempos de vida de los objetos relacionados son iguales
Por referencia significa que los tiempos de vida de los objetos relacionados pueden ser independientes
Por tanto, la selección de por valor o por referencia determina cómo la creación y la destrucción de los objetos será diseñada en C++
Ing. Ernesto Calderón Yarlequé
VENS
VENS
CursoCatálogo
1..*1..*
Relaciones por Referencia
Las relaciones por referencia denotan tiempos de vida independientes Mostradas como un diamante no relleno
Ing. Ernesto Calderón Yarlequé
VENS
VENS
BotónOKVentanaSelecciónCurso 1 111
Relaciones por Valor
Las relaciones por valor indican tiempos de vida dependientes Crear el objeto, entonces crear el objeto relacionado Eliminar el objeto, entonces eliminar el objeto relacionado
Por ejemplo, cuando se crea la VentanaSeleccionCurso, se crea el BotónOK
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Un objeto Cliente depende de un objeto ServidorUn objeto Cliente depende de un objeto Servidor
Cliente Servidor
Relaciones de Dependencia
Una relación de dependencia significa que una clase depende de otras clases para algunos servicios
Una relación de dependencia se dibuja como una flecha de líneas discontinuas
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Relaciones de Dependencia (cont.)
Una relación de dependencia indica o bien que: Las operaciones de la clase cliente crean objetos de la clase
servidor Las operaciones de la clase cliente tienen firmas cuyos
argumentos o retorno de la clase son instancias de (o referencias a) la clase servidor
Ing. Ernesto Calderón Yarlequé
VENS
VENS
#include “BillingSystem.h”void RegistrationManager::process(){ BillingSystem theInterface; …}
Las Operaciones Crean Objetos de la Clase Servidor
RegistrationManager
process ()
BillingSystem
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Objetos de la Clase Servidor como Argumentos de Operación
TransactionManager
saveCourse (Course&)
Course
class Course;class TransationManager { public: … void saveCourse(Course&); private: …};
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Yo puedo ver . . .
Visibilidad de los Objetos
Las relaciones proveen un camino para la comunicación entre objetos Para que los objetos puedan “hablar” ellos tienen que estar visibles
La visibilidad de un objeto determina el diseño de una relación
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Opciones de Visibilidad de los Objetos
Hay cuatro opciones de visibilidad Global
El objeto servidor es un objeto global Parámetro
El objeto servidor es un parámetro a una operación en el objeto cliente
Local El objeto servidor es declarado localmente
Campo El objeto servidor es un campo en el objeto cliente
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diagrama de Clase Diagrama de Colaboración
CurriculumController
createCourse ()
TransactionManager
saveCourse (Course)
1
1
: CurriculumController
: TransactionManager
1: saveCourse (Course)
Modelo de Análisis
La operación createCourse() de CurriculumController le pide al TransactionManager que salve un nuevo objeto Course
Ing. Ernesto Calderón Yarlequé
VENS
VENS
CurriculumController
createCourse ()
TransactionManager
saveCourse (Course&)
: CurriculumController : TransactionManagerG
1: saveCourse (Course)
G
Diseño del Modelo -- Visibilidad Global
El objeto TransactionManager es declarado globalmente
La visibilidad global conlleva a una relación de dependencia
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Visibilidad Global
static TransactionManager theManager;class CurriculumController { public: void createCourse(); …};class Course;void CurriculumController::createCourse() { Course *aNewCourse; … theManager.saveCourse(aNewCourse); …};
Ing. Ernesto Calderón Yarlequé
VENS
VENS
CurriculumController
createCourse (TransactionManager&)
TransactionManager
saveCourse (Course&)
: CurriculumController : TransactionManagerG
1: saveCourse (Course)
P
Diseño del Modelo -- Parámetro Visibilidad
El objeto TransactionManager es un parámetro para la operación createCourse() del CurriculumController
El objeto TransactionManager es solamente visible a la operación createCourse
El parámetro visibilidad conlleva a una relación de dependencia
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Parámetro Visibilidadclass TransactionManager;class Course;class CurriculumController { public: void createCourse(TransactionManager&); …};void CurriculumController:: createCourse(TransactionManager& theManager) {
Course *aNewCourse; … theManager.saveCourse(aNewCourse); …}
Ing. Ernesto Calderón Yarlequé
VENS
VENS
CurriculumController
createCourse ()
TransactionManager
saveCourse (Course&)
: CurriculumController : TransactionManagerG
1: saveCourse (Course)
L
Diseño del Modelo -- Visibilidad Local
El objeto TransactionManager es declarado dentro de la operación createCourse() de CurriculumController
El objeto TransactionManager es solamente visible a la operación createCourse
La visibilidad local conlleva a una relación de dependencia
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Visibilidad Local#include “TransactionManager.h”;class Course;class CurriculumController { public: void createCourse(); …};void CurriculumController::createCourse() { Course *aNewCourse; TransactionManager theManager; … theManager.saveCourse(aNewCourse); … }
Ing. Ernesto Calderón Yarlequé
VENS
VENS
CurriculumController
createCourse ()
TransactionManager
saveCourse (Course)
: CurriculumController : TransactionManagerG
1: saveCourse (Course)
F
Diseño del Modelo -- Visibilidad de Campo
El objeto TransactionManager es un miembro dato de la clase CurriculumController
El objeto TransactionManager es visible para todas las operaciones de la clase CurriculumController
La visibilidad de campo conlleva a una relación de asociación (o de agregación)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
#include “TransactionManager.h”;class Course;class CurriculumController { public: void createCourse(); … private: TransactionManager theManager;};void CurriculumController::createCourse() {
Course *aNewCourse;… theManager.saveCourse(aNewCourse); … }
Visibilidad de Campo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo: Diseño de Relaciones
El CurriculumController es responsable de la administración de la información de todos los cursos. El Course es creado y salvado en la base de datos Curriculum. Un TransactionManager es responsable de las interfaces con la base de datos. Hay una clase DBCourse que sabe cómo salvar la información del curso pertinente. Cada curso puede tener entre 3 y 10 estudiantes matriculados y solamente un profesor. Un estudiante puede matricular hasta un máximo de cuatro cursos. Cada profesor dicta tres cursos. Un reporte que lista los cursos, el profesor y los estudiantes matriculados, se ejecuta para las primeras tres semanas del semestre.
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El Modelo antes del Diseño de la Relación
StudentCourse
0..4 3..10
Professor
30..4
3
CurriculumController
createCourse ()
TransactionManager
saveCourse (Course)
DBCourse
save (Course)
1
1
11
1
11
1
1
1..*
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Decisiones de Diseño
El CurriculumController usa al TransactionManager para cada curso que este administra
La operación createCourse() no es la única operación para usar el TransactionManager
Se elige la visibilidad de campo El CurriculumController envía mensajes hacia el
TransactionManager pero el TransactionManager no envía ningún mensaje al CurriculumController
La relación es unidireccional (de CurriculumController a TransactionManager)
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Decisiones de Diseño (cont.)
El CurriculumController crea un nuevo curso dentro de la operación createCourse
Es seleccionada la visibilidad local La operación saveCourse del TransactionManager es pasada al objeto
Course Es seleccionada la visibilidad de parámetro
El TransactionManager usa un objeto DBCourse para salvar un objeto Course
Esta es la única operación que requiere del objeto Course Es seleccionada la visibilidad local
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Decisiones de Diseño (cont.)
La operación salvar de DBCourse se pasa al objeto Course Se selecciona la visibilidad de parámetro
Un Curso tiene que conocer sus estudiantes para generar el reporte Estos requerimientos no establecen que un Estudiante tenga que
conocer sus cursos La relación se produce unidireccionalmente
Un Curso tiene que conocer su Profesor para generar el reporte Estos requerimientos no establecen que un Profesor tenga que
conocer sus cursos La relación se produce unidireccionalmente
Ing. Ernesto Calderón Yarlequé
VENS
VENS
El Modelo después del Diseño de la Relación
BDCurso
save (Course)
CurriculumController
createCourse ()
TransactionManager
saveCourse (Course)
EstudianteCurso
3..10
Profesor
3..10
1
1
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Multiplicidad para las Relaciones
La multiplicidad es el número de instancias que participan en una asociación
Estimados iniciales de multiplicidad hechos durante el análisis tienen que ser actualizados y refinados durante el diseño
Todas las relaciones de asociación y agregación tienen que tener especificada la multiplicidad
Ing. Ernesto Calderón Yarlequé
VENS
VENS
class Professor;class Course { public: // public info private: Professor *teacher; …};
Course Professor
Teacher
10..*
Implementación de Asociaciones con Multiplicidad de 1 o 0 a 1
Si cada Curso tiene a lo sumo un Profesor, entonces cada objeto Curso puede incluir un apuntador simple al objeto Profesor correspondiente
Ing. Ernesto Calderón Yarlequé
VENS
VENS
CursoProfesor
dictando( ) 1 0..*
Opcionalmente
Si un vínculo es opcional, una operación para probar la existencia del vínculo debe ser incluida
Por ejemplo, si un Profesor puede estar en sabático, una operación apropiada deberá ser incluida en la clase Profesor para probar el vínculo
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Item
Lista
Opciones de Diseño para Multiplicidad de más de Uno
La multiplicidad de más de uno es usualmente diseñada usando clases “contenedoras”
Una clase contenedora es una clase cuyas instancias son colecciones de otros objetos
Las clases contenedoras comunes incluyen: Conjuntos, listas, diccionarios, pilas, colas, …
Las clases contenedoras son frecuentemente clases parametrizadas las cuales se muestran como:
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejemplo de Clase Parametrizada
Course
Item
List
1
StudentList
1
Student
#include “List.h”class Course { public: … private: List<Student> students; …}
Ing. Ernesto Calderón Yarlequé
VENS
VENS
CursoEstudiante
3..103..10
Lista
Notación para Clases Contenedoras Para reducir la confusión en diagramas de clases extensos, las clases
contenedoras no son mostradas típicamente en los diagramas de clases
Si el tipo de contenedor se requiere para la comunicación, una nota puede ser usada
Ing. Ernesto Calderón Yarlequé
VENS
VENS
nota
Curso Estudiante
3..104 3..104
Clase Asociación
Una clase asociación contiene información que pertenece a un vínculo entre objetos y no a ningún objeto envuelto en la relación
Calificacion
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diseñando Clases Asociación
Durante el diseño, las clases de asociación evolucionan por: La transformación de la clase asociación en una clase
interpuesta entre las otras dos clases El establecimiento de asociaciones con multiplicidad adecuada
entre la clase asociación y las otras dos clases La multiplicidad es siempre UNA clase de conexión a las
clases vinculadas Diseñando las nuevas asociaciones
La navegación puede ser bidireccional o unidireccional
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Diseñando Clases de Asociación (cont.)
EstudianteCalificacion
notaCurso
3..103..104 11
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Ejercicio
Usando los escenarios y los diagramas de clases desarrollados Discutir consideraciones del diseño de relaciones
Actualizar los diagramas de clases para mostrar las consideraciones de diseño de relaciones
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Diseñando Relaciones
Durante el análisis, las asociaciones y agregaciones son relaciones bidireccionales
Durante el diseño, ellas pueden convertirse en relaciones unidireccionales
Las asociaciones se diseñan en dos modos Por valor -- los objetos tienen tiempos de vida dependientes Por referencia -- los objetos tienen tiempos de vida
independientes Una relación de dependencia significa que una clase depende de otra
clase para un servicio en particular Examinar la visibilidad de los objetos ayuda a determinar el diseño de
las relaciones
Ing. Ernesto Calderón Yarlequé
VENS
VENS
Resumen: Diseñando Relaciones (cont.)
Las opciones de visibilidad incluyen: Visibilidad global -- el objeto está disponible globalmente Visibilidad de Parámetro -- el objeto es un parámetro a un
método Visibilidad local -- el objeto es declarado localmente Visibilidad de campo -- el objeto es parte de la estructura
Los punteros son típicamente usados para implementar la multiplicidad de 1 o de 0..1
La multiplicidad de más de uno es usualmente diseñada usando clases “contenedoras”, tales como una Lista o Cola
Una clase contenedora es una clase cuyas instancias son colecciones de otros objetos
Top Related