Uml Curso Teori Aistpcsr2077

VENS
ANLISIS Y DISEO ORIENTADO A OBJETOS con UML
Expositor: Ing. Ernesto Caldern Yarlequ Rernestocy@Hotmail.com
VENS
Ing. Ernesto Caldern Yarlequ
VENS
Pblico y Objetivos
Pblico al que va dirigido
Cualquiera con la necesidad de aprender las capacidades y los mtodos de la tecnologa orientada a objetos, especialmente aquellos involucrados con el desarrollo de sistemas complejos Luego de terminar el curso los participantes sern capaces de:

Objetivos del Curso
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 lgica

Disear el sistema aplicando los conceptos de Abstraccin, encapsulamiento, herencia, polimorfismo y patrones
VENS
VENS
Tabla de Contenidos
VENS
VENS
Tabla de Contenido
Introduccin
Profundizacin en el anlisis y diseo orientado a objetos usando UML Una visin del ciclo de vida de desarrollo de sistemas usando un modelo iterativo e incremental Anlisis del comportamiento necesario en un modelo orientado por casos de uso Desarrollo de escenarios para los casos de uso
Desarrollo iterativo e incremental
Comportamiento del sistema
Objetos y Clases
Definicin de objetos, clases, estereotipos y paquetes

VENS
VENS
Tabla de Contenidos
Interaccin entre Objetos
Representacin grfica de un escenario Las aplicaciones del anlisis por casos de uso para descubrir clases en el sistema Definicin de paquetes
Encontrando las Clases
Dibujo del diagrama de clases

Definir las relaciones necesarias para la interaccin entre objetos
Relaciones
Operaciones y Atributos
Definir estructura y comportamiento de clases
VENS
VENS
Tabla de Contenidos
Herencia
Aplicaciones del principio de generalizacin y especializacin para descubrir relaciones superclases / subclases Desarrollo de diagramas de transicin de estados para mostrar grficamente el comportamiento de un objeto Descubrimiento de mezclas de clases en diferentes casos de usos Discusin de las 4+1 vistas de la arquitectura
Comportamiento de los Objetos
Homogenizacin
Arquitectura
VENS
VENS
Tabla de Contenidos
Mecanismos claves
Discusin de la estrategias de los mecanismo claves Diseo de la interfaz del usuario Incorporacin de patrones
Diseo de Clases

Diseo de Relaciones
Soporte de relaciones en C++

Soporte para atributos y operaciones en C++
Diseo de Atributos y Operaciones
Diseo para Herencia
Soporte para herencia en C++

VENS
VENS
Tabla de Contenidos
Resumen
Resumen del curso de anlisis y diseo
Lecturas
Bibliografa Requerimientos para un sistema de sueldos Anlisis y diseo de soluciones para el problema de sueldos
Problema de sueldos
Problema de sueldos
VENS
VENS
Introduccin
SI
VENS
VENS
Objetivos: Introduccin
Ud. ser capaz de:
Explicar la crisis del software
Discutir las fortalezas de la tecnologa de objetos

Discutir dnde la tecnologa OO puede ser usada Definir anlisis y diseo Explicar el origen de UML
VENS
VENS
La Crisis del Software
El departamento de vehculos motorizados de California gast ms de $43 millones de dlares en un proyecto destinado a fusionar los sistemas de conductores y registro de vehculos
El sistema fue abandonado sin ni siquiera haber sido usado
Un fallido esfuerzo de $165 millones de dlares 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 dlares perdidos por la demora en la apertura del Software failures reported by W. Wayt Gibbs in the aeropuerto September, 1994 issue of Scientific American
Ejemplos extremos, PERO hay muchos desastres similares en una menor escala
VENS
VENS
La Crisis del Software
En marzo de 1989, Arthur Andersen report
Ms de $300 mil millones al ao son gastados en actividades de software comercial en los Estados Unidos Slo el 8% resulta en software que es distribuido y funciona Base inestable
Cules son las razones para la crisis del software?

Fallas en el manejo del riesgo

La complejidad del software
VENS
VENS
Base Inestable
Los requerimientos del negocio son ciclos de desarrollo ms cortos
Los usuarios esperan ms en trminos de flexibilidad
Los requerimientos iniciales usualmente estn mal definidos
VENS
VENS
Fallas en el Manejo de Riesgos

EL ciclo de vida de cascada retrasa la identificacin de problemas No hay pruebas de que el sistema funcionar hasta que est cerca de ser terminado El resultado es de mximo riesgo
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 estn
VENS
VENS
Fortalezas de la Tecnologa de Objetos
Un solo paradigma
Un solo lenguaje usado por los usuarios, analistas, diseadores e implementadores
Facilidad para elaborar la arquitectura y lograr el reutilizacin de cdigo Los modelos reflejan mejor el mundo real

Mayor precisin describiendo datos corporativos y procesos Descomposicin basada en divisiones naturales Fcil de entender y mantener Un pequeo cambio en los requerimientos no significa cambios masivos en el sistema en desarrollo
Estabilidad
VENS
VENS
Un Simple Ejemplo de Ordenes de Compra

Orden
Item
Despacho via
VENS
VENS
Diagrama de Clases para el Ejemplo de Ventas

Venta
Vendedor
Cliente
Producto
Vehculo
Empresa
Persona
Camin
Tren
VENS
VENS
Efecto del Cambio de Requerimientos

Venta
Vendedor
Cliente
Producto
Vehculo
Empresa
Persona
Camin
Tren
VENS
VENS
Cundo es Usado OO?
Sistemas basados en GUI
OO trata de facilitar el diseo e implementacin de sistemas con GUIs
VENS
VENS
Cundo Usar OO?
Sistemas empotrados
Los mtodos OO permiten desarrollar sistemas empotrados y de tiempo real de alta calidad y flexibilidad
VENS
VENS
Cundo Usar OO?
Computacin Cliente/Servidor
Los enfoques OO pueden encapsular informacin en objetos del computador central, permitiendo la distribucin de aplicaciones de pequeo tamao
Plataformas PC Estacin de Trabajo
Interfaz de objeto DB y aplicaciones existentes
VENS
VENS
Cundo es Usado OO?
Re-ingeniera
Los mtodos OO permiten que se aplique re-ingeniera a partes del sistema, protegiendo las inversiones en software existente
Software Existente
Software de Re-ingeniera
VENS
VENS
Anlisis y Diseo Orientado a Objetos
OOA
Modelo de desarrollo de requerimientos
OOD
Agregar detalles y decisiones de diseo
Perspectiva del Usuario
Perspectiva del Desarrollador
VENS
VENS
Qu es el Lenguaje de Modelado Unificado (UML)?
UML es descrito en The Unified Modeling Language for ObjectOriented 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, HewlettPackard, Oracle, Texas Instruments, MCI Systemhouse y otros
VENS
VENS
Entradas a UML
Booch
Rumbaugh Jacobson
Meyer
Condiciones de antes y despus
Fusion
Descripcin de operaciones, Numeracin de mensajes
Harel
Grficos de estado
UML
Shlaer - Mellor
Ciclo de vida del Objeto
Embley
Clases Singleton, Visin de alto nivel
Gamma, et.al
Marcos, diseos, notas
Wirfs-Brock Odell
Clasificacin
Responsabilidades
VENS
VENS
Evolucin de UML
Envio a la OMG para adopcin, Julio 97
UML 1.1
Industrializacin
Publicacin del Estandar 1.0 Dic 96
UML 1.0
Estandarizacin
Feedback pblico
Junio 96 & Oct 96
UML 0.9 & 0.91

UML Partners Expertise
Unificacin
OOPSLA 95 Unified Method 0.8
Booch 93
Otros mtodos Booch 91
OMT - 2
OMT - 1 OOSE
Fragmentacin
VENS
VENS
Beneficios del Lenguaje de Modelado Unificado
Define un mapa parecido para el anlisis y el diseo de implementaciones Define una notacin expresiva y consistente

Hace ms fcil el comunicarse con otros Ayuda a detectar omisiones e inconsistencias Permite anlisis y diseo a pequea y gran escala
VENS
VENS
Resumen: Introduccin
Nuevas tcnicas 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 Un solo paradigma Los modelos reflejan el mundo real Facilitan la arquitectura y el reuso de cdigo
La tecnologa de Objetos tiene muchos puntos fuertes

Provee gran flexibilidad
Un pequeo cambio en los requerimientos no significa cambios masivos en el sistema en desarrollo
VENS
VENS
Resumen: Introduccin (cont.)
OO est siendo usado para diferentes tipos de sistemas
Basados en GUI, empotrados, computacin cliente/servidor, y reingeniera
El anlisis orientado a objeto es un mtodo de anlisis en el cual los requerimientos son expresados en trminos de los objetos encontrados en el problema
Enfocado en el QUE
En el diseo orientado a objetos el modelo de anlisis es transformado en un modelo de diseo por medio de la refinacin de ste, agregando detalles y capturando las decisiones de diseo necesarias para implementar el modelo
Enfocado en el COMO
VENS
VENS
Resumen: Introduccin (cont.)
El Lenguaje de Modelado Unificado (UML por sus siglas en ingls) fue desarrollado por Grady Booch, Jim Rumbaugh, e Ivar Jacobson en colaboracin con un nmero de otros colaboradores, basados en sus experiencias colectivas.
VENS
VENS
Comportamiento del sistema
VENS
VENS
Objetivos: Comportamiento del sistema

Usted ser capaz de:
Definir el comportamiento del sistema
Definir casos de uso y actores

Entender cmo 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
VENS
VENS
Qu es el comportamiento del sistema?
El comportamiento de un sistema es cmo un sistema acta y reacciona
La actividad exterior visible y testeable de un sistema Ellos describen el sistema, su ambiente, y la relacin entre el sistema y su ambiente
El comportamiento del sistema es capturado en los casos de uso
VENS
VENS
Conceptos importantes al modelar el caso de uso
Un actor representa cualquier cosa que interacte con l sistema
Actor
Un caso de uso es una secuencia de acciones que un sistema realiza, que produce un resultado observable de valor para un agente
Use-Case
VENS
VENS
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 anlisis de requisitos, diseo y prueba
El propsito primario del modelo caso de uso es comunicar las funciones y el comportamiento del sistema al cliente o al usuario final
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 comprensin mutua de los requisitos Quin interactuar con el sistema y qu deber hacer el sistema Qu interfaz deber tener el sistema
Es usado para identificar
Es usado para verificar que:
Se capturan todos los requisitos

Que los desarrolladores hayan entendido los requisitos
VENS
VENS
Actores
Actor
Los actores no son parte del sistema, ellos representan roles que un usuario del sistema puede desempear Un actor puede intercambiar activamente la informacin con el sistema Un actor puede ser un recipiente pasivo de la informacin Un actor puede representar a un humano, una mquina u otro sistema
VENS
VENS
Encontrando Actores: Preguntas tiles

Quin est interesado en cierto requisito? Dnde en la organizacin se utilizar el sistema?
Quin proveer, utilizar y eliminar esta informacin del sistema?

Quin utilizar esta funcin? Quin le dar soporte y mantenimiento al sistema? Usa el sistema un recurso externo?
Qu actores necesita el caso de uso?

Un actor desempea varios roles? Varios agentes desempean el mismo rol?
VENS
VENS
Instancias de Actores
Insert card
Ivar acta como un actor
1 4 7 *
2 5 8 0
3 6 9 #
Tom acta como un actor
Modelo de Caso de uso
Actor
Caso de uso
VENS
VENS
Un usuario puede actuar como varios actores

Insert card 1 4 7 * 2 5 8 0 3 6 9 #
Charlie como operador
Charlie Charlie como cliente

Cliente
Operador
VENS
VENS
Lmites de los actores y del sistema
Mantenimiento ATM
Lmite del Sistema?

Sistema ATM
Cajero Bancario
Sistema Bancario
VENS
VENS
Casos de Uso
Un caso de uso modela un dilogo 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
Caso de Uso
Tomados al mismo tiempo, todos los casos de uso constituyen todas las formas posibles de utilizar el sistema
VENS
VENS
Encontrando Casos de Uso: Preguntas tiles

Cules son las tareas de este actor? El actor, crear, guardar, cambiar, eliminar o leer la informacin en el sistema? Cul caso de uso crear, guardar, cambiar, eliminar o leer esta informacin? 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? Cules casos de uso le darn soporte y mantenimiento al sistema?
Pueden todos los requerimientos funcionales ser realizados por los casos de uso?
VENS
VENS
Fuentes de Informacin para Casos de Uso

Especificaciones del sistema / Manifestacin del problema Literatura relevante del dominio
Entrevistas con expertos del dominio

Conocimiento personal del dominio Sistema heredados
VENS
VENS
El Diagrama de Caso de Uso
Un diagrama de un caso de uso ilustra como los casos de uso y los actores interactan, envindose estmulos entre ellos
Realizar Transacciones Cliente
Banco Realiza reportes
ATM Mantenimiento Mantener maquina ATM
VENS
VENS
Documentacin de Caso de Uso
Los casos de uso estn documentados en
Una breve descripcin
El propsito del caso de uso en unas pocas lneas

Descripcin del flujo de eventos primario y alternativos que ocurren cuando el caso de uso es iniciado
Flujo de eventos detallados
La documentacin debe leerse como un dilogo entre el actor y el caso de uso
Ambos documentos estn escritos en trminos que el cliente entender
VENS
VENS
Flujo de Eventos Caso de Uso
Cada caso de uso
Tiene una secuencia de transacciones normal y bsica
Puede tener varias secuencias de transacciones alternativas

Generalmente tiene varias secuencias de transacciones excepcionales, las cuales manejan situaciones de error Tambin puede tener pre y post condiciones bien definidas
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 terminologa vaga tal como por ejemplo, etc. e informacin. El flujo de eventos debe describir:

Cmo y cundo comienza y termina el caso de uso Cundo el caso de uso interacta con los actores
Qu informacin se intercambia entre un actor y el caso de uso
No describe los detalles de la interfaz del usuario
El flujo de eventos bsico Cualquier flujo de eventos alternativo
VENS
VENS
Quin Lee la Documentacin de Casos de Uso?
Clientes -- aprueban lo que debe hacer el sistema Usuarios -- obtienen comprensin del sistema Desarrolladores del Sistema -documentan el comportamiento del sistema Revisores --examinan el flujo de eventos Analistas del Sistema (Diseadores) -proveen la base para un anlisis y diseo Probador del Sistema -- usado como base para casos de prueba Lder de Proyecto -- provee entradas para el planeamiento de proyectos Escritor Tcnico -- base para escribir la gua del usuario
VENS
VENS
Ejemplo de Registro en Curso
Al comienzo de cada semestre, los estudiantes pueden requerir informacin de un catlogo de cursos, el cual contiene una lista de los cursos ofrecidos para el semestre, indicando para cada curso profesor, departamento y prerequisitos. Informacin 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. Adems, cada estudiante podr indicar dos cursos alternativos en caso de no poder ser asignado en su primera seleccin. El curso tendr un mximo de diez estudiantes y un mnimo de tres. Un curso con menos de tres estudiantes ser cancelado. Una vez que el proceso de registro es completado , el sistema de registro enva la informacin al sistema de cobranzas, para que al estudiante le puedan cobrar por el semestre.
VENS
VENS
Ejemplo de Registro en Curso (cont.)
Los profesores deben ser capaces de acceder al sistema on-line para indicar qu cursos estarn enseando. Tambin necesitarn ver qu estudiantes se inscribieron para sus cursos. Para cada semestre, existe un perodo 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.
VENS
VENS
Diagrama de un Caso de Uso

Sistema de Cobranzas
Solicitar lista de Curso

Registrar Cursos a tomar
Profesor Seleccionar Cursos a ensear
Estudiante
Mantener Info del Profesor Registrador
Mantener Informacin de Curso
Mantener Info de estudiante
Generar Catlogo
VENS
VENS
Breve Descripcin -- Registrar Cursos a Tomar

1.1 Breve Descripcin
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.
VENS
VENS
Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar

2.1 Pre-condiciones Ninguna 2.2 Flujo principal Este caso de uso comienza cuando el estudiante ingresa el nmero de alumno. El sistema verifica que ste sea vlido (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.
VENS
VENS
Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar(cont.)

2.3 Flujos alternativos A-1: Crear un nuevo Programa El sistema muestra en la pantalla un programa en blanco. El estudiante ingresa el nmero de cuatro ofrecimientos de cursos primarios y dos nmeros de cursos alternativos (E-3). El estudiante entonces presenta su peticin de cursos. Por cada seleccin 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 informacin 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 informacin de todos los cursos ofrecidos en los que el estudiante se encontraba registrado (E-8) y muestra lo siguiente : nombre del curso, nmero del curso, nmeros de los cursos ofrecidos, das de la semana, hora, ubicacin y nmero de horas de crditos. Cundo el usuario indica que l / ella ya ha terminado la revisin, el caso de uso comienza nuevamente.
VENS
VENS
Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar (cont.)

A-3: Modificar un programa El sistema revisa que no haya sido excedida la fecha final para los cambios (E-9). El sistema recupera la informacin 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, nmero del curso, nmero de los cursos ofrecidos, das de la semana, hora, ubicacin y nmero de horas de crditos. 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.
VENS
VENS
Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar(cont.)

A-4: Imprimir un programa El sistema imprime el programa (E-6). El caso de uso comienza de nuevo. A-5: Borrar un programa El sistema recupera informacin (E-8) y muestra el programa actual. El sistema pide al usuario que confirme la opcin de borrar programa. Si es aceptada, se elimina el programa del sistema. Si el borrar no se confirma, la operacin es cancelada y el caso de uso comienza de nuevo. A-6: Borrar un curso ofrecido El estudiante ingresa el nmero del ofrecimiento a borrar. El sistema pide al usuario que confirme esta opcin de borrar el curso ofrecido. Si es aceptada, el curso ofrecido es eliminado del programa del estudiante. Si el borrar no es confirmado, la operacin es cancelada y el flujo alternativo del caso de uso comienza de nuevo.
VENS
VENS
Flujo de Eventos -- Caso de Uso Registro en Cursos (cont.)

A-7: Agregar un curso ofrecido El 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 flujos E-1: Se ingresa un nmero de alumno no vlido. El usuario puede re-ingresar un nmero de alumno o terminar el caso de uso. E-2: Se ingresa un semestre no vlido. El usuario puede re-ingresar un semestre o terminar el caso de uso. E-3: El nmero del ofrecimiento de curso no es vlido (rango). El usuario puede re-ingresar un nmero vlido 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 contina.
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 contina. E-6: El programa no puede ser impreso. La informacin est guardada y el usuario es informado de que debe volver a presentar una solicitud de imprimir programa. El caso de uso contina. E-7: El sistema guardar toda la informacin de cuentas de pago y la volver a presentar al sistema de cuentas en una prxima fecha. El caso de uso contina. E-8: El sistema no puede recuperar informacin 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.
VENS
VENS
Qu son Escenarios?
Un escenario es una instancia de un caso de uso
es un solo flujo a travs de un caso de uso Escenarios primarios
Cada caso de uso tendr una red de escenarios
Flujo normal - la forma en la que el sistema debiese funcionar Excepciones al escenario primario
Escenarios secundarios
VENS
VENS
Un Escenario para el Caso de Uso Registrar Cursos a Tomar

John ingresa su nmero de alumno 369 52 3449 y el sistema valida el nmero. El sistema pregunta por cul semestre. John indica el semestre actual y elige crear un nuevo programa. De una lista de cursos disponibles, John selecciona los cursos primarios Ingls 101, Geologa 110, Historia Mundial 200, y lgebra 110. Luego selecciona los cursos alternativos de Teora de la Msica 110 e Introduccin a Programacin 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 enva la informacin de cuenta de pago de cuatro cursos al sistema de cuenta para ser procesada.
VENS
VENS
Escenarios Secundarios
Cules son algunos de los escenarios secundarios para el caso de uso Registro de Cursos?
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 estn disponibles No es posible agregar al estudiante a la lista de curso No se puede crear el programa del estudiante
VENS
VENS
Cuntos 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.
VENS
VENS
Ejercicio: Comportamiento del Sistema
Utilizando el problema entregado por el instructor
Dibuje un diagrama de caso de uso
Escriba una definicin para cada actor

Para un caso de uso

Escriba una breve descripcin (dos oraciones mximo) Escriba el flujo de eventos
Enumere algunos posibles escenarios
VENS
VENS
Resumen: Comportamiento del Sistema

El comportamiento de un sistema es cmo ste acta 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 estmulo proveniente de un actor externo
Ellos proveen un vehculo 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 representacin grfica del sistema el cual muestra los actores y casos de uso identificados para el sistema La documentacin de un caso de uso consiste en una breve descripcin y en un flujo de eventos
VENS
VENS
Objetos y Clases
VENS
VENS
Objetivos: Objetos y Clases

Usted ser capaz de : Definir y dar ejemplos de objetos Definir y dar ejemplos de clases Describir la relacin entre clases y objetos Definir estereotipos
VENS
VENS
Qu es un Objeto?
Informalmente, un objeto representa una entidad, fsica, conceptual o programa Entidad fsica
Camin
Entidad conceptual
Proceso Qumico
Entidad programa
Lista Enlazada
VENS
VENS
Una Definicin Formal
Un objeto es un concepto, una abstraccin o una cosa con lmites bien definidas y significado para una aplicacin Un objeto es algo que tiene: Estado Comportamiento Identidad
VENS
VENS
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, adems de las conexiones que deben tener con otros objetos
a + b = 10
Nombre: N Empleado: Fecha de Contr.: Estado:

Profesor Clark
Joyce Clark 567138 21 de marzo 1987 Adjunto
VENS
VENS
Un Objeto Tiene Comportamiento
El comportamiento de un objeto determina cmo ste acta 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)
a + b = 10
Asignar profesor (Clark)
(Retorna:confirmacin)
Registro del Sistema
Curso Algebra 101
VENS
VENS
Un Objeto tiene Identidad
Cada objeto tiene una identidad nica, incluso si su estado es idntico al de otro objeto
Profesor J Clark ensea Algebra
VENS
VENS
Qu son las Clases?

Hay muchos objetos identificados para cada dominio Una clase es una descripcin de un grupo de objetos con propiedades en comn (atributos), comportamiento similar (operaciones), la misma manera de relacionarse entre objetos (asociaciones y agregados) y una semntica en comn Un objeto es una instancia de una clase Una clase es una abstraccin en que: Se enfatizan las caractersticas relevantes Se suprimen otras caractersticas La abstraccin nos ayuda a trabajar con cosas complejas
VENS
VENS
Ejemplo de una Clase

Clase Curso
Estructura Nombre Ubicacin Das ofrecidos Crditos Hora de inicio Hora de trmino Comportamiento Agregar un alumno Borrar un alumno Entregar una lista del curso Determinar si est lleno
a + b = 10
VENS
VENS
Clases y Objetos
Cuntas clases ve?
VENS
VENS
La Relacin Entre Clases y Objetos
Una clase es una definicin abstracta de un objeto
Define la estructura y el comportamiento compartidos por los objetos

Sirve como modelo para la creacin de objetos
Los objetos pueden ser agrupados en clases
Objetos
Profesor
Profesor Mellon
Profesor Smith
Profesor Jones
VENS
VENS
Encontrando Clases

Una clase debe capturar una y solo una abstraccin clave Mala abstraccin: La clase estudiante que conoce la informacin del estudiante y el programa del semestre actual del estudiante Buena abstraccin: Clases separadas. Una para el estudiante y otra programas del estudiante
Algebra 101 Historia Arte Qumica Espaol 101
VENS
VENS
Asignando Nombre a una Clase

El nombre de la clase debe ser el sustantivo singular que mejor caracterice la abstraccin La dificultad al nombrar la clase revela una pobre definicin de la abstraccin Los nombres deben provenir directamente del vocabulario del dominio
VENS
VENS
Gua de estilo en el nombramiento de clases

Una gua de estilo debe dictar convenciones para el nombramiento de clases Ejemplo de gua de estilo Las clases son nombradas usando sustantivos singulares Los nombres de las clases comienzan con letra mayscula No se usa el subrayado Los nombres compuestos por mltiples palabras se ponen juntos y la primera letra de cada palabra se escribe con mayscula Ejemplo: Estudiante, Profesor, Sistema De Pago
VENS
VENS
Definiendo la Semntica de las Clases
Despus de nombrar las clases, debe hacerse un informe descriptivo conciso Concentrarse en el propsito de la clase, no en su implementacin El nombre y la descripcin de la clase sirven como base para un modelo de diccionario
Fijarse en los QUE e ignorar los COMO
VENS
VENS
Muestra de las Entradas de un Modelo de Diccionario
Nombre: InformacinDelEstudiante Definicin: Informacin de una persona registrada para asistir a clases en la universidad Nombre: Curso Definicin: Una clase ofrecida por la universidad
Mientras ms se descubre del problema, se refina la definicin de la clase y se agregan nuevas clases al modelo de diccionario
VENS
VENS
Representando Clases
Una clase es representada usando un compartimiento rectangular
a + b = 10
Profesor
Profesor Clark
VENS
VENS
Compartimientos en la representacin grafica de una clase
Una clase est compuesta de tres secciones La primera seccin contiene el nombre de la clase La segunda seccin muestra la estructura (atributos) La tercera seccin muestra el comportamiento (operaciones) La segunda y la tercera seccin pueden ser suprimidas si se necesita que no se vean en el diagrama
Profesor
Profesor
Profesor
Profesor
nombre empID crear( ) grabar( ) borrar( ) cambiar( )
nombre empID
crear( ) grabar( ) borrar( ) cambiar( )
Profesor
VENS
VENS
Estereotipos
Un estereotipo es un nuevo tipo de elemento de modelado que extiende la semntica 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 Excepcin Clase Utilidad
Los estereotipos son mostrados en el compartimiento del nombre de la clase encerrados entre << >>
VENS
VENS
Clase Frontera
Una clase frontera modela la comunicacin entre el entorno del sistema y su funcionamiento interno Clases interfaz tpicas

Windows (interfase del usuario) Protocolo de comunicacin (interfase del sistema) Interfase de la impresora
Sensores
En el escenario del Registrar Cursos a Tomar, un Formulario programa es creado para aceptar la informacin del usuario <<Boundary>> FormularioPrograma
VENS
VENS
Interfaces con Otros Sistemas
Una clase frontera tambin es usada para modelar una interfaz a otro sistema Las caractersticas importantes de este tipo de clases frontera son:

La informacin que debe ser entregada al otro sistema El protocolo de comunicacin usado para hablarle al otro sistema
En el escenario del Registro de Cursos , la informacin debe ser enviada al Sistema Cobranza externo
Una clase llamada Sistema Cobranza es creada para sostener la interfaz con el sistema externo
<<Boundary>> Sistema Cobranza
VENS
VENS
Clase Entidad
Una clase entidad modela informacin y asocia comportamientos que generalmente son de larga duracin (persistentes)

Puede reflejar un fenmeno de la vida real
Tambin 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 Curso Programa Catlogo ListaCursos
<<entity >> Programa <<entity >> Catalogo <<entity>> ListaCursos <<entity >> Curso
Las clases entidades en el caso de uso Registro de Cursos:

VENS
VENS
Clase Control
Una clase control modela el comportamiento especifico de uno o ms casos de usos La clase control

Crea, inicializa y borra objetos controlados Controla la secuencia o coordina la ejecucin de los objetos controlados Controla asuntos concurrentes para las clases controladas Es usualmente la implementacin de un objeto intangible
En el escenario del Registro de Cursos, la clase AdministradorDeRegistro controla los procesos de registro
<<control>> AdministradorDeRegistro
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 cmo un objeto acta y reacciona a los requerimientos de otros objetos Cada objeto tiene una entidad nica -- incluso si su estado es idntico al de otro objeto Una clase es una definicin abstracta de un conjunto de objetos que tienen una estructura y un comportamiento comn A las clases se les debe dar por nombre la palabra que mejor caracterice su abstraccin
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 clasificacin de la clase Toda clase debe tener al menos un estereotipo Estereotipos comunes: interfaz, entidad, control, excepcin, metaclase y utilidad La clase interfaz modela la comunicacin entre el entorno del sistema y su trabajo interno La clase entidad modela la informacin y el comportamiento asociado que debe ser almacenado La clase control modela el control del comportamiento especfico de uno o ms casos de usos
VENS
VENS
Interacciones de Objetos
VENS
VENS
Objetivos: Interacciones de Objetos

Usted ser capaz de:
Utilizar diagramas de secuencia y de colaboracin para mostrar las interacciones entre los objetos.
VENS
VENS
Qu son los Diagramas de Interaccin?
Un diagrama de interaccin es una representacin grfica de interacciones entre objetos Existen dos tipos de diagramas de interaccin

Diagramas de secuencia Diagramas de colaboracin
Cada uno entrega un punto de vista distinto de la misma interaccin

Los diagramas de secuencia son ordenados en el tiempo

Los diagramas de colaboracin pueden incluir flujo de datos
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 interaccin La secuencia de mensajes intercambiados
Un diagrama de secuencia contiene:

Objetos con sus lneas de vida

Mensajes intercambiados entre objetos en una secuencia ordenada Linea de Vida Activa (opcional)
VENS
VENS
Un Diagrama de Secuencia
John : Estudiante
Formulario Registro 1: ingresar id 2: validar id
Formulario Programa
Cursos Disponibles
3: ingresar semestre actual 4: crear un nuevo programa 5: mostrar 6: obtener cursos
VENS
VENS
Nombrando Objetos en Diagramas de Secuencia

Los objetos son dibujados como rectngulos con nombres subrayados Las lneas de vida de los objetos estn representadas por lneas rayadas en descenso
cursos disponibles cursos disponibles: Catlogo : Catlogo
Object only
Object and Class
Class only
VENS
VENS
Mostrando la Interaccin entre Objetos
La interaccin de objetos est indicada por flechas horizontales las cuales son dirigidas desde la lnea vertical representada por el objeto cliente a la lnea representada por el objeto proveedor Las flechas horizontales estn etiquetadas con mensajes El orden de los mensajes con respecto al tiempo, est indicado por la posicin vertical. Enumerar las flechas horizontales es opcional ya que el orden est basado en la posicin vertical
Formulario programa Cursos disponible
Obtener cursos
VENS
VENS
Qu es Activacin?
Una activacin 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 activacin puede ser mostrado en un diagrama de secuencia mediante una lnea de vida activa
VENS
VENS
Enfoque de Control
John : Estudiante 1: ingresar id formulario Registro formulario programa cursos disponibles
2: validar id
3: ingresar semestre actual 4: crear nuevo programa 5: mostrar 6: obtener cursos
VENS
VENS
Notas
Las notas pueden agregar ms informacin al diagrama
Cursos disponibles Para el semestre Formulario programa cursos disponibles
obtener cursos
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 cdigos
VENS
VENS
Ejemplo de Libreto
Formulario Programa unCurso
Procesar los cursos primarios primero, usando slo los cursos alternativos si es necesario
Obtener pre-requisito
VENS
VENS
Diagramas de Colaboracin
Un diagrama de colaboracin 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 colaboracin contiene:

Objetos Conexiones entre objetos Mensajes intercambiados entre objetos Datos fluyendo entre objetos, si los hubiera
VENS
VENS
Ejemplo de Diagrama de Colaboracin

2: validate id
1: enter id 3: enter current semester registration form 4: create new schedule John : Student 5: display
available classes 6: get courses
schedule form
VENS
VENS
Representando Objetos en un Diagrama de Colaboracin
Los objetos son dibujados como rectngulos con nombres subrayados
Ingls 101
Ingls 101: Curso
:Curso
Object only
Object and Class
Class only
VENS
VENS
Representando Conexiones en un Diagrama de Colaboracin
Una conexin en un diagrama de colaboracin se representa como una lnea que une conos de objetos Una conexin indica que existe un camino para establecer una comunicacin entre los objetos conectados
Formulario programa : Form
Un curso : Curso
VENS
VENS
Mensajes entre objetos
Una de conexin en un diagrama de colaboracin 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 parmetros y/o un valor de retorno Un nmero de secuencia opcional que muestra el orden relativo en el cual los mensajes son enviados
VENS
VENS
Notacin de conexiones
Mensaje
points from client to Mensaje supplier Message
2: obtener cursos
Objeto Client object 1: obtener pre-requisitos Formulario programa : Form Lista de curso Un curso : Curso
Data return
conexin
Objeto Supplier object
VENS
VENS
Resumen: Interaccin entre Objetos
La interaccin de objetos puede ser representada grficamente en un diagrama de secuencia, el cual muestra la existencia de objetos y las interacciones entre los objetos identificados
Los objetos son representados por rectngulos con sus nombres subrayados Una lnea de vida de un objeto es representadas por una lnea rayadas vertical descendiendo del objeto
Los mensajes estn indicados por flechas horizontales las cuales estn dirigidas desde el objeto cliente (emisor) al objeto proveedor (receptor)
Las flechas horizontales estn etiquetadas con el nombre del mensaje
Un libreto opcional puede ser agregado para mostrar ms detalles al diagrama

VENS
VENS
Resumen: Interaccin entre Objetos (cont.)
Un diagrama de colaboracin es una representacin grfica alternativa de interacciones de objetos

Los objetos se representan con rectngulos Una interaccin de conexin (lnea) se dibuja entre objetos que se comunican
La conexin se anota con una flecha que contiene el nombre del mensaje que apunta desde el objeto cliente a el objeto proveedor La conexin puede tambin ser anotada con una flecha de retorno de datos
VENS
VENS
Encontrando Clases
VENS
VENS
Objetivos: Encontrando Clases

Ser capaz de:
Discutir el anlisis de casos de uso
Encontrar objetos y clases mediante el anlisis de casos de uso

Usar cartas CRC para descubrir clases Dibujar un escenario usando diagramas de interaccin Crear paquetes
Crear diagramas de clase
VENS
VENS
Qu es el Anlisis de Casos de Uso?
El anlisis 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 grficamente en diagramas de interaccin
Se crean las entidades, las interfaces y las clases de control
Las clases son agrupadas en paquetes
Se creados los diagramas de clases
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
VENS
VENS
Filtrando Nombres
Cuando est identificando nombres, tenga cuidado que:
Varios trminos pueden referirse al mismo objeto
Un trmino puede referirse a ms de un objeto

El lenguaje natural es bastante ambiguo La lista de nombres debe ser filtrada Cada nombre puede ser tratado como verbo; cada verbo puede ser tratado como nombre
Este acercamiento puede identificar varios objetos sin importancia
Una palabra de atencin
El resultado depende fuertemente de la habilidad para escribir de los autores
VENS
VENS
Revisando los Nombres
El siguiente requerimiento es escrito para un sistema bancario
Los requerimientos legales sern transformados en cuentas
Si SLO los nombres son considerados, qu pasar?
Linea de fondo: Cada nombre debe ser considerado en el contexto del problema l no se basta a si mismo
VENS
VENS
El Escenario Registrar Cursos a Tomar

John ingresa su nmero de estudiante 369 52 3449 y el sistema valida el nmero. El sistema pregunta cul 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, Geologa 110, Historia del Mundo 200 y lgebra 110. Luego elige de entre los cursos alternativos Teora de la Msica 110 e Introduccin a la Programacin 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 enva la informacin de cobro por cuatro cursos al sistema de cobranzas para su proceso.
VENS
VENS
Los Nombres del Escenario Registrar Cursos a Tomar

John Sistema
Nmero de estudiante 369523449 Nmero
Semestre
Nuevo horario Cursos primarios Geologa 110 lgebra 110
Semestre actual
Lista de cursos disponibles Ingles 101 Historia del Mundo 200 Cursos alternativos
Teora Musical 110

Prerequisitos necesarios Lista del curso Horario del estudiante Cuatro cursos
Introduccin a la programacin en Java 180

Registro del estudiante Actividad Informacin de cobro
Sistema de cobranza
Qu nombres deben ser filtrados?
VENS
VENS
Decisiones de Filtrado

John -- filtrado (actor) Nmero de estudiante 369523449 -- filtrado (propiedad de un estudiante)
Sistema -- filtrado (lo que est siendo construido)

Nmero -- filtrado (propiedad de un estudiante) Semestre -- filtrado (estado cuando la seleccin 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 Geologa 110 -- candidato a objeto Historia del Mundo 200 -- candidato a objeto
lgebra 110 -- candidato a objeto
VENS
VENS
Decisiones de Filtrado
Cursos alternativos -- filtrado (estado del curso seleccionado)

Teora Musical 110 -- candidato a objeto Introduccin a la programacin 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 (Expresin espaola) Horario del alumno -- filtrado (lo mismo que nuevo horario)
Informacin de cobro -- candidato a objeto

Cuatro cursos -- filtrado (Informacin necesitada por el sistema de cobranza) Sistema de cobranza -- filtrado (actor)
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 Geologa 110 -- una oferta para el semestre Historia del Mundo 200 -- una oferta para el semestre
lgebra 110 -- una oferta para el semestre

Teora Musical 110 -- una oferta para el semestre Introduccin a la programacin en Java 180 -- una oferta para el semestre
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 Informacin de cobro informacin requerida por el sistema de cobranza
VENS
VENS
Creando Clases
Los objetos encontrados son agrupados en clases
Basados en estructuras y/o comportamientos similares Las clases pueden cambiar mientras ms escenarios son examinados
Este es un intento inicial
VENS
VENS
Candidatas a Clases Escenario Creando un Horario

Programa lista de los cursos de un alumno en un semestre Catlogo 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 InformacinCobro informacin necesaria para el sistema de cobranza
<< Entidad >> Curso <<Entidad>> Programa << Entidad >> Catlogo << Entidad >> ListaCurso << Entidad >> RegistroEstudiante << Entidad >> InformacinCobro
VENS
VENS
Encontrando Clases Frontera
Examine cada par actor/escenario y cree clases de frontera obvias
Durante el diseo, la clase ser definida basada en los mecanismos de la interfaz de usuario elegida El estudiante se presenta con diferentes opciones en el caso Registrar Cursos a Tomar
Ejemplo:
Una clase de frontera llamada FormularioRegistro se crea para permitir al estudiante seleccionar la opcin deseada
El estudiante debe ingresar la informacin del curso al sistema en el escenario Registrar Cursos a Tomar
Una clase de frontera llamadaFormularioPrograma se crea para guardar la informacin ingresada por el estudiante
VENS
VENS
Candidatas a Clases Frontera Escenario Registrar Cursos a Tomar
<<Boundary>> FormularioRegistro
<<Boundary>> FormularioPrograma
VENS
VENS
Esquema de Ventana
Los prototipos y/o esquemas de ventanas pueden ser creados para comunicar el aspecto y sensacin de clase de interfaz al usuario
VENS
VENS
Encontrando Clases de Interfaz
Las clases de interfaz tambin son creadas para la comunicacin 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 comunicacin escogido
VENS
VENS
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 informacin de cobro es enviada al sistema de cobranza en el escenario Registrar Cursos a Tomar
Una clase de interfaz llamada SistemaCobranza es creada <<Boundary>> Printer <<Boundary>> SistemaCobranza
VENS
VENS
Encontrando Clases de Control
Las clases de control tpicamente contienen informacin de secuencia
Atencin: las clases de control NO deben asumir las responsabilidades que tpicamente corresponden a las clases de interfaz o de entidad
A este nivel de anlisis, una clase de control es tpicamente creada para cada caso de uso
Responsable por el flujo de los eventos en el caso de uso Mientras ms casos y escenarios son desarrollados, las clases de control pueden ser eliminadas, divididas o combinadas
Esto es solo el primer corte
VENS
VENS
Control para el caso de uso Registrar Cursos a Tomar
Una clase de control llamada AdministradorRegistro es creada Recibe informacin 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 InformacinCobro Pide a SistemaCobro enviar la InformacinCobro
VENS
VENS
Candidatas a Clases de Control Caso de Uso Registrar Cursos a Tomar
<<Control>> AdministradorRegistro
VENS
VENS
Tarjetas CRC (Clase Responsabilidades Colaboradores)
Las clases pueden tambin ser descubiertas usando tarjetas Clase Responsabilidad -Colaboradores (CRC por sus siglas en ingls)
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 descripcin

Las responsabilidades de la clase

Conocimiento interno de la clase Servicios brindados por la clase Un colaborador es una clase cuyos servicios son necesarios para realizar una responsabilidad
Los colaboradores para las responsabilidades
VENS
VENS
Tarjeta CRC para la Clase Curso
Nombre de la clase
Curso
Responsabilidades
Colaboradores
Estudiante
Servicios entregados
Agregar un estudiante Saber los prerequisitos
Conocimiento interno
Saber cuando el curso es dado Saber donde es dado el curso
VENS
VENS
Una seccin 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
VENS
VENS
Beneficios de las Tarjetas CRC
A medida que ms y ms escenarios son completados, emergen rastros de colaboracin Las tarjetas pueden ser fsicamente arregladas para representar esas colaboraciones Esto puede ayudar a identificar jerarquas de generalizacin / especializacin, o jerarquas de agregacin entre las clases Las tarjetas CRC son ms efectivas para grupos que se inician en las tcnicas OO, porque ellas:

Previenen la focalizacin en los detalles de la POO Previenen la generalizacin prematura Remarcan el pensamiento objeto
VENS
VENS
Qu Estoy Haciendo?
Las cosas van bien si . . .

Todas las clases tiene nombres con sentido y especficos al dominio Cada clase tiene un pequeo conjunto de colaboradores No hay clases indispensables (una clase que colabora con todo el resto debe ser redefinida) La informacin de cada clase cabe cmodamente en una tarjeta Un cambio de requerimientos puede ser manejado por las clases
Las cosas van mal si . . .

Un nmero de clases no tienen responsabilidades

Una sola responsabilidad es asignada a varias clases Todas las clases colaboran con todas
VENS
VENS
Dibujando Escenarios
A medida que las clases y los objetos son descubiertos, son documentados en diagramas de interaccin
Los diagramas pueden ser de secuencia o de colaboracin
Los diagramas de interaccin 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 comunicacin Se agregan notas y/o libretos si se necesitan
VENS
VENS
Diagrama de Secuencia para el Escenario Registrar Cursos a Tomar

:Formulario Registracin : Estudiante 1: 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 : Formulario Programa : Catlogo
: Administrador registro
10: crear horario (estudiante, semestre, oferta de cursos)
VENS
VENS
Diagrama de Secuencia para el Escenario Registrar Cursos a Tomar (cont.)

: Administrador Registro : Cursos Ofrecidos : Registro Estudiante : Programa : Printer
: Informacin Cobro
: Sistema Cobro
LOOP a traves de todos los cursos selec.
11: obtener los prerequisitos 12: prerequisito tomado (curso) 13: disponible? 14: agregar estudiante (estudiante) 15: crear 16: imprimir (horario) 17: crear 18: enviar (informacin de cobro)
VENS
VENS
Diagrama de Colaboracin para el Escenario Registrar Cursos a Tomar

7: show course offerings 8: select course offerings 9: submit 6: get course offerings : Catalogue : StudentRecord : Student 2: validate id 1: enter id 3: enter semester 4: create schedule : RegistrationForm : RegistrationManager 18: send (billing information) 5: display 10: create schedule (student, semester, offerings) 15: create 12: pre-requisite taken (course) : ScheduleForm
: Schedule
17: create : CourseOffering 14: add student (student) 13: available ? 11: get pre-requisite courses
: BillingSystem
16: print (schedule) : BillingInformation
: Printer
VENS
VENS
Qu es un paquete?
Un paquete es un mecanismo de propsito general utilizado para organizar elementos en grupos

El nmero de clases crece a medida que ms 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
Nombre paquete
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 Programa, Catlogo, Cursos ofrecidos, RegistroEstudiante, ListaCursos y InformacinCobro AdministradorRegistro FormularioRegistro, FormularioPrograma, SistemaCobro y Printer
Artefactos de la Universidad
Reglas de negocio
Interfaces
VENS
VENS
Qu son los Diagramas de Clases?
La vista lgica 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 lgica
Generalmente hay varios diagramas de clases
El diagrama de clases principal es tpicamente una vista de los paquetes de alto nivel de la vista lgica Tpicamente 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 jerarqua de herencia
VENS
VENS
Diagrama de Clases Principal para el Sistema de Registros
Interfaces
Reglas Negocio
Artefactos Universidad
VENS
VENS
Diagrama de Clases Principal del Paquete ArtefactosUniversidad

InformacinCobro Catlogo CursosOfrecidos
ListaCursos
Programa
RegistroEstudiante
VENS
VENS
Diagrama de Clases Principal del Paquete Interfaces

SistemaCobro
Printer
FormularioRegistro
FormularioPrograma
VENS
VENS
Diagrama de Clases Principal del Paquete ReglasNegocio
AdministradorRegistro
VENS
VENS
Ejercicio: Encontrando Clases
Elija un caso de uso desarrollado en la leccin anterior
Diagrame al menos un escenario en un diagrama de interaccin
Cree todas las clases de entidad, interfaz y/o control necesarias

Cree una definicin para cada clase
Cree paquetes para el modelo
Acomode las clases descubiertas en paquetes

Cree el diagrama de clases inicial
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
Tpicamente una clase de control por cada caso de uso en el anlisis preliminar
Pueden ser usadas las tarjetas CRC para descubrir clases Un paquete es un mecanismo de propsito general para organizar elementos en grupos
VENS
VENS
Resumen: Encontrando Clases (cont.)
Un diagrama de clases es una vista de algunos (o todos) los paquetes y clases en la vista lgica
Usualmente hay varios diagramas de clases
VENS
VENS
Relaciones
VENS
VENS
Relaciones
VENS
VENS
Objetivos: Relaciones
Ud. ser capaz de:
Nombrar los dos tipos importantes de relaciones entre clases: asociacin y agregacin Definir una asociacin y representarla en los diagramas de clases Utilizar nombres de asociacin y de roles para clarificar asociaciones Definir y especificar la multiplicidad de una asociacin
Definir una agregacin y representarla en el diagrama de clases

Definir y representar una asociacin u agregacin reflexiva Utilizar clases de asociacin Definir calificadores y representarlos en diagramas de clases
Descubrir relaciones en diagramas de interaccin
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 colaboracin se logra a travs de las relaciones Asociacin
Existen dos tipos importantes de relaciones durante el anlisis

Agregacin
VENS
VENS
Asociaciones
Una asociacin es una conexin semntica bidireccional entre clases
Esto implica que existe una conexin entre objetos en las clases asociadas
Las asociaciones estn representadas en los diagramas de clases con una lnea conectando las clases asociadas Los datos puede fluir en una o ambas direcciones a lo largo de la asociacin
<<control>> AdministradorRegistro
<<entidad>> Curso
VENS
VENS
Navegacin
Una asociacin es una relacin bi-direccional
Dada la instancia de AdministradorRegistro existe asociado un objeto Curso Dada la instancia de Curso existe asociado un objeto AdministradorRegistro
<<entity>> Curso
VENS
VENS
Nombrando Asociaciones

Para clarificar su significado, una asociacin debe ser nombrada El nombre se representa como una etiqueta ubicada a lo largo de la lnea de asociacin, a medio camino entre los iconos de clases Un nombre de asociacin normalmente es un verbo o una frase verbal
administra
<<entity>> Curso
VENS
VENS
Definiendo Roles
Un rol denota el propsito o la capacidad con la que se asocia una clase con otra Los nombres de roles son tpicamente sustantivos El nombre de un rol es puesto a lo largo de la lnea de asociacin cercano a la clase que modifica
Uno o ambos terminan en una asociacin que puede tener nombres de un rol Maestro Curso
Persona
VENS
VENS
Asociaciones Mltiples

Puede existir ms de una asociacin entre dos clases Si hay ms de una asociacin entre dos clases entonces se le DEBE poner un nombre Persona Ensea Inscripto Curso
Las asociaciones mltiples deben ser puestas a prueba
VENS
VENS
Asociaciones Mltiples(cont.)
Seleccin del curso
Agregar un alumno a Borrar un alumno de
Curso
Un modelo bueno o malo?
VENS
VENS
Multiplicidad para Asociaciones
Multiplicidad es el nmero de instancias de una clase que se relacionan con una instancia de otra clase Para cada asociacin, hay dos decisiones de multiplicidad por hacer: una para cada final de la asociacin Por ejemplo, en la conexin que existe entre las instancias que cumplen el rol de maestro y curso
Para cada instancia de persona, muchos (ej. cero o mas) cursos sern enseados Para cada instancia de curso, exactamente una persona es el maestro
VENS
VENS
Indicadores de Multiplicidad
Cada trmino de asociacin contiene un indicador de multiplicidad
Indica el nmero de objetos que participa en la relacin Muchos Exactamente uno Cero o mas Uno o mas Cero o uno Rango especificado
* 1 0..* 1..* 0..1 2..4
VENS
VENS
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 algn curso? Puede un curso tener dos maestros?
Persona
Maestro Curso
1 1..*
VENS
VENS
Qu significa Multiplicidad?
La multiplicidad responde a dos preguntas
La asociacin es obligatoria u opcional?
Cul es el nmero mximo o mnimo de instancias que pueden ser ligadas a una instancia?
Maestro
0..* 1
Curso
Qu le dice este diagrama?
VENS
VENS
Agregacin
La agregacin es una forma especial de asociacin donde un todo se relaciona con sus partes
Tambin se conoce como una parte de o una relacin de contencin.
Una agregacin esta representada como una asociacin con un diamante al lado de su clase denotando el agregado. La multiplicidad se representa de la misma manera que en las otras asociaciones.
<<Boundary>> FormularioRegistro 1 1
<<Boundary>> FormularioPrograma
VENS
VENS
Pruebas para comprobar la agregacin
Es la frase una parte de usada para describir la relacin?
Una puerta es una parte de un Automvil.
Son algunas operaciones sobre el todo, automticamente aplicables a todas sus partes?
Mover el Automvil, 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 Automvil es azul, la Puerta es Azul
Existe una simetra intrnseca en la relacin donde una clase es subordinada de otra?
Una puerta ES parte de un Automvil, pero un Automvil NO ES parte de una Puerta
VENS
VENS
Asociacin o Agregacin?
Si dos objetos estn unidos firmemente por una relacin todo-parte
La relacin es una agregacin
Si dos objetos son usualmente considerados como independientes, aun cuando comnmente estn unidos
La relacin es una asociacin
Curriculum
1 1..*
Curso
0..* 3..10
Alumno
Curriculum and Course are tightly coupled -- the Curriculum is made up of 1 to may Courses
Independent objects
VENS
VENS
Asociacin Reflexiva
En una asociacin reflexiva, los objetos de una misma clase estn relacionados Indica que mltiples objetos en la misma clase colaboran en conjunto del mismo modo
Curso
0.. * 0.. *
Pre-requisito
A course may have many pre-requisites A course may be a pre-requisite for many other courses
VENS
VENS
Agregaciones Reflexivas

Las agregaciones tambin pueden ser reflexivas Esto indica una asociacin recursiva
Producto
0..*
Parte
Un objeto Producto esta compuesta de cero o mas objetos Producto
VENS
VENS
Clase Asociacin
Deseamos llevar un historial de las calificaciones de todos los cursos que el alumno ha tomado La relacin entre Alumno y Curso es una relacin de muchos a muchos Donde situamos los atributos de las calificaciones?
Alumno 3-10
0..*
Curso
VENS
VENS
Clase Asociacin (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 relacin individual Alumno-Curso Una clase asociacin es usada para almacenar informacin sobre la relacin
VENS
VENS
Notacin de la Clase Asociacin

Una clase asociacin se representa usando el icono de clase La clase asociacin se conecta con la asociacin usando la lnea entrecortada La clase de asociacin puede incluir mltiples propiedades de dicha asociacin Solamente una clase de asociacin est permitida por cada asociacin Alumno 3-10
Calificacin
1..*
Curso
VENS
VENS
La Clase Asociacin y la Multiplicidad
Las Clases de Asociacin son regularmente usadas en asociaciones del tipo muchos a muchos Si la multiplicidad en cualquier extremo de la asociacin es muchos a uno

Los atributos pueden ser situados dentro de una clase Una clase de Asociacin an puede ser usada
1
Alumno 3-10 Calificacin
Curso
Alumno
3-10 Calificacin
Curso
VENS
VENS
Calificadores
Un calificador es un atributo o conjunto de atributos, cuyos valores particionan un conjunto de objetos relacionados a travs de la asociacin de un objeto
EmpleadoID EmployeeID
Departamento
Profesor
1 1
Dado un objeto de Departamento y un valor para un EmpleadoID existe exctamente un objeto Profesor
Departmento
Ttulo Title
Profesor
1 1..*
Dado un objeto departamenteo y un valor para Ttulo, existe un conjunto de objetos Profesor
VENS
VENS
Restricciones
Una restriccin es una expresin de alguna condicin que se debe preservar
Una restriccin se denota con llaves

Profesor
{Ordenado por EmpleadoID}

1..*
Es miembro de 1
Departmento
1 {Subconj.}
Es encabezado por
VENS
VENS
Encontrando Asociaciones y Agregaciones
Los escenarios pueden ser examinados para determinar si una relacin debe existir entre dos clases
Dos objetos se pueden comunicar si y solo si se conocen entre si
Asociaciones y/o agregaciones proveen un va de comunicacin

unaForma : Forma Programa Admi : Administrador Registro
unaForma : Forma Registro mostrar
crear
VENS
VENS
Asociacin o Agregacin?
RegistrationForm and ScheduleForm are tightly coupled -- a ScheduleForm is part of the RegistrationForm
<<Boundary>> FormularioRegistro 1
<<Boundary>> FormularioPrograma 1 1
ScheduleForm and RegistrationManager are independent
1 AdministradorRegistro
VENS
VENS
Relaciones entre Paquetes
Los paquetes se relacionan entre si usando una relacin de dependencia Si una clase en un paquete se comunica con otra clase contenida en otro paquete entonces su relacin de dependencia es adicionada a nivel de paquetes Los diagramas de escenario y diagramas de clase son evaluados para determinar las relaciones entre paquetes
Interfaces Business Rules
University Artifacts
VENS
VENS
Relaciones durante Anlisis y Diseo
Durante el anlisis se deben establecer las conexiones (asociaciones y agregaciones) entre las clases
Dichas conexiones existen por la misma naturaleza de las clases, no por una implementacin especfica Hacer una estimacin inicial de multiplicidad de manera de exponer suposiciones ocultas
Los diagramas de clase son actualizados para mostrar sus relaciones agregadas Durante el diseo:
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
VENS
VENS
Actualizacin del Diagrama de Clases Principal para el Sistema de Registro
Interfaces
Reglas Negocio
Artefactos Universidad
VENS
VENS
Interfaces - Diagrama de Clases Principal

<<Boundary>> FormaRegistro
1 1 1 1 <<control>> AdministradorRegistro
(desde ReglasNegocio)
<<Boundary>> FormaPrograma
1
1 <<entity>> Catalogo
(desde ArtefactoUniversidad)
1 <<Boundary>> SistemaCobranza
VENS
VENS
ArtefactosUniversidad - Diagrama de Clases Principal

<<Boundary>> Formularioregistracin (de Interface) 1 1 <<entity>> Curso 0..4 1 1 <<control>> AdministradorRegistro (desde Reglas de Negocio) 1 1 1 1 1 <<entity>> ListaCurso <<entity>> RegistroEstudiante
1 <<entity>> Catlogo
<<entity>> RegistroCurso
VENS
VENS
Actualizacin de Diagrama de clase Principal de Reglamento Econmico

<<boundary>> FormularioItinerario
(from Interfaces)
<<entity>> RegistroCurso
(desde ArtefactosUniversidad)
1 1 << boundary >> 1 SistemaCobranza

(desde Interfaz
1 <<control>> AdministradorRegistro 1 1 1 0..4
<< entity >> Curso

1 << entity >> Registro de Estudiante

1 << entity >> ListaCursos

VENS
VENS
Ejercicio: Relaciones
Usando los escenarios y diagramas de secuencia generados en las lecciones anteriores
Actualice los diagramas de clase mostrando la relacin entre las clases
Asegrese que las decisiones de multiplicidad inicial sean correctas
Agrega los paquetes y sus relaciones para el sistema
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 asociacin es una conexin entre dos clases que representan comunicacin
Una asociacin puede tener nombre

Nombres nemotcnicos pueden ser utilizados La comunicacin puede ser tanto uni como bi-direcional (por defecto)
La multiplicidad es el nmero de instancias que participan en una asociacin

Est representado cerca del final de la lnea de asociacin Cada trmino de asociacin debiera de tener un indicador de multiplicidad
VENS
VENS
Resumen: Relaciones (cont.)
Una agregacin es una forma especializada de asociacin en la cul un todo esta relacionado con sus partes
Los extremos de una lnea de agregacin debe tener un indicador de multiplicidad Dos objetos en la misma clase que estn relacionados
Una clase puede tener una asociacin reflexiva
Las relaciones de agregacin tambin pueden ser reflexivas La informacin que pertenece al vinculo entre objetos es mostrado en una clase asociacin
VENS
VENS
Resumen: Relaciones (cont.)
Un calificador es un atributo de una clase que puede ser usado para reducir la multiplicidad de la asociacin Las relaciones pueden ser determinadas al examinar los escenarios y descubrir las necesidades de la comunicacin entre objetos
VENS
VENS
Operaciones y Atributos
Ing. ERNESTO CALDERON YARLEQUE Ernestocy@Latinmail.com
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
VENS
VENS
Qu es una Operacin?
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 informacin en la base de datos Calcular el precio
Una operacin es un servicio que puede ser solicitado desde un objeto para solicitar un determinado comportamiento
Un operacin debera desempear una funcin simple y cohesionada
VENS
VENS
Las operaciones son dependientes del dominio
Listar todas las operaciones relevantes al dominio
Las operaciones de la clase persona sern distintas dependiendo de la perspectiva solicitada
Perspectiva Bancaria
Recibe prstamos Posee cuentas Recibe lneas de credito
Perspectiva Mdica
Es examinada Toma remedios Va al hospital Recibe una cuenta
VENS
VENS
Nombrando las Operaciones
Las operaciones deberan ser nombradas indicando el nombre de su resultado o salida, no los pasos dentro de la operacin. Ejemplos:
calcularBalance()
Pobremente nombrada Indica que el balance debe ser calculado - esto es una decisin implementacin/optimizacin Bien nombrada Indica solamente la salida
obtenerBalance()
VENS
VENS
Nombrando Operaciones (cont.)
Las operaciones debera ser nombradas desde la perspectiva del proveedor, no del cliente En una estacin de gas, el gas es recibido desde la bomba:
Una operacin para la bomba que tiene esta responsabilidad como debera ser llamada?

Nombres buenos: entregarGas(),dispensar() Nombre malo : recibirGas() La bomba da el gas, no lo recibe
VENS
VENS
Qu es una Operacin Primitiva?
Una operacin primitiva es una operacin que puede ser implementada solamente usando las cualidades internas de la clase
Todas las operaciones de una clase son tpicamente primitivas Agregar un tem al conjunto - operacin primitiva Agregar cuatro tems al conjunto - no primitiva
Ejemplo:

Puede ser implementada con mltiples llamadas a la operacin anterior de agregar un tem al conjunto
VENS
VENS
Firmas de las Operaciones
La firma de una operacin consta de:
Lista opcional de argumentos
Tipo de retorno
Durante el anlisis NO ES OBLIGATORIO llenar la firma de la operacin
Esta informacin puede ser retrasada hasta el diseo
VENS
VENS
Visualizando Operaciones
Las operaciones son mostradas en el tercer compartimiento de la clase Curso

obtenerPrerequisito() : ListaCurso
VENS
VENS
Descubriendo Operaciones desde los Diagramas de Interaccin
Los mensajes visualizados en los diagramas de secuencia y/o colaboracin son usualmente operaciones de las clases receptoras
Los mensajes son traducidos a operaciones y agregados al diagrama de clases

unCurso Administrador Registro unCurso
Administrador Registro
obtenerPrerequisito
obtenerPrerequisito():ListaCurso
VENS
VENS
Descubriendo Clases Adicionales
Si una firma de una operacin se especifica, pueden ser descubiertas clases adicionales en:

Argumentos de la operacin Clases de retorno obtenerPrerequisito() : ListaCurso
Ejemplo:

agregarEstudiantet(John : InformacinEstudiante)
Estas son mostradas en los diagramas de clases
Las clases descubiertas se adicionan al modelo
VENS
VENS
Descubriendo Relaciones Adicionales
Los argumentos de las operaciones y las clases de retorno denotan una relacin entre la clase y los argumentos y/o la clase de retorno Ejemplo
La clase ListaCursos tiene una operacin agregarEstudiante(John: InformacinEstudiante) Esto implica que existe una relacin entre ListaCursos e InformacinEstudiante Estas son mostradas en los diagramas de clases
Las relaciones descubiertas son agregadas al modelo
VENS
VENS
Qu es un Atributo?
Un atributo es una definicin 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 definicin 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 relacin, no un atributo
VENS
VENS
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: Sue Smith 567892 Matemticas George Jones 578391 Biologa
Atributos Nombre NmeroDeEmpleado reaEnseanza
VENS
VENS
Atributos Dependientes del Dominio
Lista de todos los atributos relevantes al dominio del problema
Los atributos de la clase Persona sern distintos dependiendo de a quien le preguntemos
Perspectiva Bancaria
nombre direccin fechaDeNacimiento nmeroDeCuenta
Perspectiva Mdica
nombre direccin fechaDeNacimiento altura peso
VENS
VENS
Visualizando Atributos
Los atributos son mostrados en el segundo compartimiento de la clase

<<entidad>> Curso nombre descripcin ubicacin horario Crditos obtenerPrerequisito () : Curso
VENS
VENS
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 desempeo en tiempo de ejecucin vs. memoria requerida Rectngulo alto ancho /rea
VENS
VENS
Tipos de Datos y Valor Inicial de Atributos
Cada atributo posee:
Tipo de Dato
Valor inicial opcional
Durante el anlisis NO ES OBLIGATORIO completar la definicin del atributo
Esta informacin puede ser retrasada hasta el diseo
VENS
VENS
Cmo 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 definicin de la clase La experiencia en el dominio puede tambin proveer buenos atributos
Slo modele los atributos que sean relevantes para el dominio del problema
VENS
VENS
Ejemplo: Atributos en el problema de Inscripcin de Cursos
Cada curso tendr una descripcin en el catlogo
Un atributo llamado descripcin es agregado a la clase Curso
Curso
descripcin
VENS
VENS
Gua de Estilo para el nombramiento de atributos y operaciones
Una gua de estilo debera dictar convenciones de nombres para atributos y operaciones

Provee consistencia a travs del proyecto Gua hacia modelos y cdigo ms mantenible Atributos y operaciones empiezan con una letra minscula
Ejemplos

El subrayado no es usado
Nombre compuestos de mltiple palabras son colocados juntos y la primera letra de cada palabra adicional esta en mayscula
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, tpicamente,en esos diagramas de clases
VENS
VENS
Encapsulamiento
Una forma para ver una clase es que consiste de dos partes: la interfaz y la implementacin

La interfaz puede ser vista y usada por otros objetos La implementacin es oculta para los clientes
Ocultar los detalles de implementacin de un objeto se llama encapsulamiento u ocultamiento de la informacin El encapsulamiento ofrece dos tipos de proteccin. Protege:
El estado interno de un objeto, de ser corrompido por sus clientes El cdigo del cliente, de cambios en la implementacin del objeto
VENS
VENS
Ejemplo: Encapsulamiento
cambiarNombreTitular
Los valores de los atributos pueden ser cambiados slo por las operaciones que provee el objeto
retirar
depositar
nmeroCuenta nombreBanco nombreTitular balance obtenerBalance
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
generarInstrucciones
VENS
VENS
Beneficios del Encapsulamiento

El cdigo cliente puede usar la interfaz a una operacin El cdigo cliente no puede tomar ventaja de la implementacin de la operacin La implementacin puede cambiar, por ejemplo, para:
Corregir errores (Bugs)
Mejorar el Desempeo
Reflejar cambios en las polticas
El cdigo del cliente no debe ser afectado por cambios en la implementacin, esto reduce el efecto arrastre en el cual una correccin para una operacin fuerza la correspondiente correccin en una operacin del cliente la cual causa el cambio en un cliente del cliente. La manutencin es fcil y menos cara.
VENS
VENS
Ejercicio: Operaciones y Atributos
Actualizar el diagrama de secuencia creado en la leccin anterior para refinar los mensajes nombrando las operaciones en forma ms concisa donde sea necesario Crear el diagrama de Clases mostrando slo atributos y operaciones Agregar cualquier relacin adicional basada en argumentos de operaciones y/o clases de retorno
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 operacin debera desarrollar una funcin simple y cohesiva Una operacin debera hacer una cosa y hacerla bien Las operaciones son cmo un objeto acta y reacciona ante los mensajes que recibe Un atributo es una caracterstica de una clase Un valor de un atributo es el valor de un atributo para un objeto en particular
VENS
VENS
Resumen: Operaciones y Atributos (cont.)
Los atributos se descubren en el texto del enunciado del problema, cuando se crea la definicin de la clase, y a travs de la experiencia en el dominio. Solamente los atributos relevantes y operaciones (aplicable para la solucin del problema) deben ser modelados Encapsulamiento es ocultar los detalles de implementacin al mundo exterior

Protege el estado interno de un objeto

Protege el cdigo del cliente de cambios en la implementacin de las clases
VENS
VENS
Herencia
Ing. ERNESTO CALDERON YARLEQUE Rernestocy@Hotmail.com
VENS
VENS
Herencia: Objetivos
Usted ser capaz de:
Definir y discutir herencia, generalizacin y especializacin
Representar una jerarqua de herencia en un diagrama de clases

Entender las tcnicas para encontrar la herencia Definir herencia mltiple
VENS
VENS
Herencia
La herencia define una relacin entre clases donde una clase comparte la estructura y/o comportamiento con una o ms clases La herencia define una jerarqua de abstracciones en que una subclase herede desde una o ms superclases
Con la herencia simple, la subclase hereda desde una nica superclase Con la herencia mltiple, la subclase hereda desde ms de una superclase
La herencia es una relacin es un o tipo de
VENS
VENS
Dibujando una Jerarqua de Herencia

InformacinUsuario Superclase
Relacin de Herencia
InformacinEstudiante
Subclase
VENS
VENS
Consideraciones para la Herencia
Ya que una relacin de herencia no relaciona objetos individuales
La relacin no tiene nombre
La multiplicidad no tiene sentido

En la prctica actual, los niveles necesitan ser bastante limitados
Tericamente, no existe lmite para el nmero de niveles de herencia
Tpicamente la herencia en C++ llega de 3 a 5 niveles
La herencia en Smalltak puede ser un poco ms profunda
VENS
VENS
Qu es herencia?
Una clase hereda de sus padres:
Atributos
Operaciones
Relaciones Agregar atributos, operaciones y relaciones adicionales
Una subclase puede:
Redefinir las operaciones heredadas (tenga cuidado!)
La herencia apalanca las similaridades entre las clases
VENS
VENS
Heredando Atributos
Los atributos se definen en el nivel ms alto en la jerarqua de herencia en la que son aplicados Las subclases de una clase heredan todos los atributos Cada subclase puede aadir atributos adicionales
VehculoTerrestre Peso nmeroLicencia
Un camin tiene tres atributos: nmeroLicencia peso tonelaje

Auto
Camin tonelaje
VENS
VENS
Heredando Operaciones
Las operaciones son definidas en el ms alto nivel en la jerarqua de herencia en que son aplicables. Las subclases heredan todas las operaciones de una clase Cada subclase puede aumentar o redefinir las operaciones heredadas
VehculoTerrestre peso nmeroLicencia registrar( )
Auto
Camin tonelaje obtenerImpuestos( )
Un camin tiene tres atributos: nmeroLicencia peso tonelaje y dos operaciones: registrar() obtenerImpuestos()
VENS
VENS
Heredando Relaciones
Las relaciones tambin son heredadas y deben ser definidas en el ms alto nivel de la jerarqua 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
VehculoTerrestre peso nmeroLicencia 0..* registrar( ) dueo 1 Persona
Auto
Trailer Camin tonelaje obtenerImpuestos( )
Un auto es relacionado con un propietario Un camin esta relacionado con un propietario Un camin tambin tiene un trailer
VENS
VENS
Generalizacin de Clases
La generalizacin provee la capacidad para crear superclases que encapsulan estructura y/o comportamiento comn entre subclases La generalizacin se aplica:
Identificando similitudes de estructura/comportamiento entre varias clases Creando una superclase para encapsular estructura/comportamiento comn
Las clases originales son subclasificadas a la nueva superclase
Las superclases son ms abstractas que sus subclases
VENS
VENS
Ejemplo de Generalizacin
Activo
CuentaBancaria
Valor
BienesRaices
Ahorros
Corriente
Accion
Bono
Incrementando abstraccin
VENS
VENS
Especializacin de Clases
La especializacin 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 especializacin se aplica:
Notando que algunas instancias exhiben estructura o comportamiento especializado Creando subclases para agrupar instancias de acuerdo a su especializacin
Las subclases son menos abstractas que sus superclases
VENS
VENS
Ejemplo de Especializacin
Activo
CuentaBancaria
Valor
BienesRaices
Ahorros
Corriente
Accion
Bono
Decrementando abstraccin
VENS
VENS
Jerarqua de Herencia
La generalizacin y especializacin son usadas para desarrollar la jerarqua de herencia Durante el anlisis, las jerarquas de herencia entre abstracciones claves (por ejemplo, clases) son establecidas solo si es necesario Durante el diseo, las jerarquas de herencia son redefinidas para:

Incrementar el reuso Incorporar clases de implementacin Incorporar libreras de clases disponibles
VENS
VENS
Niveles de Abstraccin
Vehiculo
VehiculoTerrestre
VehiculoAereo
Las clases en el mismo nivel de herencia deberan tener el mismo nivel de abstraccin
Ford
Camion
Aereoplano Helicoptero
VENS
VENS
Herencia Mltiple
ObjetoVolador
multiple inheritance
Animal
Aeroplano
Helicoptero
Aguila
Lobo
Caballo
Aguila hereda de ObjetoVolador y Animal
VENS
VENS
Conceptos de Herencia Mltiple

Conceptualmente necesario para modelar con exactitud el mundo real En la prctica, puede llevar a dificultades en la implementacin
No todos los lenguajes de programacin orientados a objetos soportan directamente herencia mltiple
Use herencia mltiple solamente cuando sea necesario, y siempre con precaucin!
VENS
VENS
Problemas con la Herencia Mltiple Name clashes on

attributes or operations
ObjetoVolador color getColor Animal color getColor
Repeated inheritance
ObjetoAnimado color
Objeto Volador
Aguila
Animal
Cada lenguaje o ambiente de programacin elije maneras de resolver estas dificultades
Aguila
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 Agregue nuevas operaciones/atributos a las subclases Redefina las operaciones
Tcnica de adicin
Tcnica de modificacin
Debe ser cuidadoso en no hacer cambios semnticos
VENS
VENS
Herencia vs. Agregacin
Herencia y agregacin son usualmente confundidas
La herencia representa una relacin es un o tipo de
La agregacin representa una relacin tiene un
Las palabras claves es un y tiene un ayudarn a determinar la relacin correcta
VENS
VENS
Window y Scrollbar
Window Scrollbar
WindowWithScrollbar
Un WindowWithScrollbar tiene un Window Un WindowWithScrollbar tiene un Scrollbar Qu relacin debera ser usada?
VENS
VENS
Window y Scrollbar (cont.)

Window
Window
Scrollbar
WindowWithScrollbar
1 1
Scroll bar
WindowWithScrollbar
Un WindowWithScrollbar es un Window Un WindowWithScrollbar tiene un Scrollbar
VENS
VENS
Herencia vs. Agregacin

Herencia
Palabra clave es un
Agregacin
Palabra clave tiene un
Un objeto
Relaciona objetos de distintas clases
Representado por una flecha
Representado por un diamante
VENS
VENS
Qu es Metamorfosis?
Metamorfosis 1. Un cambio en una forma, estructura o funcin; especficamente el cambio fsico experimentado por algunos animales, como un renacuajo a una rana 2. Cualquier cambio marcado, como un carcter, apariencia o condicin
Websters New World Dictionary
Simon & Schuster, Inc., 1979
Metamorfosis existe en el mundo real Cmo podra ser modelada?
VENS
VENS
Ejemplo de Metamorfosis
En la universidad existen estudiantes a tiempo completo y estudiantes a medio tiempo
Los estudiantes a tiempo completo tienen un nmero id y un fecha de graduacin prevista, pero los estudiantes a medio tiempo no. Los estudiantes a medio tiempo toman un mximo de tres cursos mientras que para los de tiempo completo no existe lmite
Full-timeStudent
name address studentID gradDate
Part-timeStudent
name address numberCourses
VENS
VENS
Un enfoque
Una relacin de herencia puede ser creada

Student name address
Qu pasa si los estudiantes part-time pasan a ser estudiantes full-time?
FulltimeStudent studentID gradDate
ParttimeStudent
numberCourses
VENS
VENS
Metamorfosis

Es muy difcil cambiar la clase de un objeto Una mejor tcnica de modelacin
Colocar la estructura y comportamiento que cambia dentro de su propia clase

ParttimeClassification 0..1 Student name address 1 numberCourses
FulltimeClassification 0..1 studentID gradDate
VENS
VENS
Metamorfosis (cont.)
Mary Smith estudiante Full-time Joe Jones estudiante Part-time
MarySmith : Student
1
JoeJones : Student
1
: Full-timeClassification
: Part-timeClassification
VENS
VENS
Metamorfosis (cont.)
La Metamorfosis es completado por el objeto hablando con las partes cambiantes.

: Student : Parttime Classification : Fulltime Classification
: Student Manager change to full time
delete create
VENS
VENS
Metamorfosis y Herencia
La herencia puede ser usada para modelar estructura, comportamiento y/o relaciones comunes a las partes cambiantes
Student name address 1 1 Classification
Fulltime studentID gradDate
Parttime numberCourses
VENS
VENS
Metamorfosis y Flexibilidad

Esta tcnica tambin agrega flexibilidad al modelo Ejemplo: un estudiante puede tambin vivir en el campus. En este caso, existe un identificador para el dormitorio, un nmero de habitacin y un nmero clave de la habitacin
Student name address 1 1 Classification
ResidentInformation dorm room roomKeyID
0..1
Fulltime studentID gradDate
Parttime numberCourses
VENS
VENS
Ejercicio: Herencia
Examinar las clases definidas en el problema y agregar herencia donde sea necesario
Asegrese que cualquier metamorfosis est considerada
Actualice los diagramas de clase como sea necesario
VENS
VENS
Herencia: Resumen
La herencia define una relacin entre clases donde una clase comparte la estructura y/o comportamiento de una o ms clases
Define una jerarqua de abstracciones en la que una subclase hereda desde una superclase
Herencia simple -- una clase hereda desde una superclase Herencia mltiple -- una clase hereda desde ms 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
VENS
VENS
Herencia : Resumen (cont.)
La generalizacin provee la capacidad para crear superclases que encapsulan estructura y/o comportamiento comn a varias subclases La especializacin 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 agregacin son usualmente confundidas
Herencia representa una relacin es un o tipo de
Agregacin representa una relacin tiene un
VENS
VENS
Comportamiento de los Objetos
Ing. ERNESTO CALDERON YARLEQUE Rernestocy@Hotmail.com
VENS
VENS
Objetivos: Comportamiento de los Objetos

Usted ser capaz de:

Explicar la necesidad de Diagramas de Transicin 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 transicin de estados, diagramas de interaccin entre objetos y diagramas de clases
VENS
VENS
Qu es un Diagrama de transicin de estados?
Un diagrama de transicin de estados sirve para mostrar la historia de la vida de una determinada clase, los eventos que causan la transicin 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 enumeracin 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 rene todas las propiedades del objeto
Usualmente esttico Usualmente dinmico
Adems de los valores de cada una de estas propiedades
VENS
VENS
Dibujo de los Estados
Un estado es representado como un rectngulo redondeado, en un diagrama de transicin de estado
Nombre del estado
VENS
VENS
Estados y Atributos
Los estados pueden ser distinguidos por los valores de ciertos atributos Curso
numEstudiantes
Ingls101 : Curso
numStudents = 7
El mximo nmero de estudiantes por curso es 10

numEstudiantes < 10
Abierto
numEstudiantes > = 10
Cerrado
VENS
VENS
Estados y Conexiones
Los estados pueden tambin ser distinguidos por la existencia de ciertas conexiones Las instancias de la clase Profesor pueden tener dos estados:

Ensear, cuando existe una conexin con el curso En estado suspendido, cuando no existe conexin
Profesor
0..*
Curso
VENS
VENS
Estados Especiales
El estado inicial es el estado del objeto cuando es creado
Un estado inicial es obligatorio
Slo un estado inicial es permitido

El estado inicial es representado como un crculo relleno Un estado final es opcional
El estado final indica el fin de la vida para el objeto
Puede existir ms de un estado final

El estado final es indicado por un ojo de toro Estado Final
Estado inicial
VENS
VENS
Eventos
Un evento es algo que ocurre en un punto en el tiempo y permite la transicin del objeto a un estado
El estado de un objeto determina la respuesta a diferentes eventos Aadir un alumno a un curso Crear un nuevo curso
Ejemplo:

VENS
VENS
Transiciones
Una transicin es un cambio desde un estado primitivo a un estado sucesor como resultado de ciertos estmulos
El estado sucesor puede resultar ser el mismo estado primitivo
Una transicin puede ocurrir como respuesta a un evento Las transiciones pueden ser relacionadas con los eventos
Cancelar el curso
Abierto
Cancelado
Aadir estudiante
VENS
VENS
Condiciones de Guarda
Una condicin de guarda es una expresin booleana que permiten una transicin slo si la condicin es verdadera
Cerrar Registracin [ numEstudiantes >= 3 ]
Abierto
Registracin Completa
VENS
VENS
Acciones
Una accin es una operacin que est asociada con una transicin
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 transicin

Creacin Registro abierto Initialize Abierto
Aadir estudiante / Inc(numEstudiantes)
VENS
VENS
Enviando Eventos
Un evento puede desencadenar el envo de otro evento
Mostrado como: ^Clase.evento

Aadir estudiante Registracinn abierta / Inicializar
numEstudiantes
Creacin Abierto [ numEstudiantes = 10 ]/ ^CursoReporte.Crear reporte Cerrado
VENS
VENS
Actividades
Una actividad es una operacin 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 transicin que este ocurriendo
Cerrado
do: Reportar curso esta lleno
VENS
VENS
Enviando Eventos Durante un Estado
Una actividad tambin puede enviar un evento a otro objeto
Cancelado do: ^ListaCursos.Eliminar estudiante(Estudiante)
VENS
VENS
Transiciones Automticas
Algunas veces, el nico propsito de un estado es el de realizar una actividad Una transicin automtica ocurre cuando la actividad es completada Si existen mltiples transiciones automticas

Una condicin de guarda es necesaria en cada transicin Las condiciones deben ser mutuamente excluyentes
Cerrado
do: finalizar curso
Ofrecido
VENS
VENS
Acciones de Entrada y Salida
Cuando una accin debe ocurrir sin importar cmo se ha ingresado o salido de un estado, la accin puede ser asociada con el estado
En realidad, la accin es asociada con cada transicin entrando o saliendo del estado
La accin es mostrada dentro del icono de estado precedida por la palabra entry o exit
Aadir estudiante Aadir estudiante / numEstudiantes = 0
Sin-asignar
do: Asignar un profesor al curso
Abierto entry: Registrar un estudiante
VENS
VENS
Estados Anidados
Los diagramas de transicin 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 nmero de niveles de anidacin son permitidos Los estados anidados pueden llevar a sustanciales reducciones de complejidad grfica, permitiendo modelar problemas ms largos y complejos
VENS
VENS
Diagrama de transicin de estado para la Clase del Curso sin Utilizar Estados Anidados
aadirEstudiante aadirEstudiante/ numEstudiantes = 0 Abierto do: Registrar un estudiante
Inicializar do: Inicializar objecto curso
Sin-asignar do: Asignar profesor al curso cancelarCurso
cancelarCurso
registracin cerrada[ Cancelado do: Enviar noticias de cancelacin numEstudiantes < 3 ] registracin cerrada[ numEstudiantes > = 3 ]
cancelarCurso
[ numEstudiantes = 10 ] Cerrado do: Reportar curso esta lleno RegistracinCompleta dor: Generar clase roster
VENS
VENS
Diagrama de transicin de estado para la Clase Curso Utilizando Estados Anidados

Inicializar
Registrar
RegistracinCompleta do: Generar clase roster
registracin cerrada[ numEstudiantes > = 3 ]
Sin-asignar do: Asignar profesor al curso Aadir estudiante / numEstudiantes = 0 Abrir
registracin cerrada[ numEstudiantes < 3 ]
entry: Register a student
aadirEstudiante
[ numEstudiantes = 10 ]
Cancelado cancelarCurso
Cerrado
do: Reportar curso esta cerrado
VENS
VENS
Estados Anidados con Historia
El uso de caractersticas histricas indica que ante el retorno a un superestado, el subestado visitado ms recientemente ser ingresado El uso de la H encerrada por un crculo para denotar que la caracterstica histrica se aplica al superestado Si la caracterstica de historia no es usada, el subestado inicial ser siempre ingresado cuando el superestado sea ingresado
VENS
VENS
Ejemplo: Estado Anidado con Historia
En el curso sistema de registro, la seleccin de curso hace lo siguiente
Acepta cursos primarios
Acepta cursos alternativos
El usuario puede renunciar en cualquier momento El usuario puede suspender una sesin por un mximo de 30 minutos mientras selecciona cursos
El formulario es grabado despus de que todos los cursos han sido seleccionados
el formulario es enviado a procesar despus de que ha sido grabado
VENS
VENS
Estados Anidados con Historia (De Tipo Formulario de Registracin)

Seleccin curso Creacin
entry: Crear formulario do: inicializar formulario
Suspender Resumir
Suspender
do: Esperar por 30 minutos
[ Contador curso < 4 ]
Seleccin de curso primaria

do: Aceptar nmero curso exit: Incrementar contador curso
[ Contador curso = 4 ] / Poner contador curso en 0
Seleccin de curso alternativo

do: Aceptar nmero curso exit: Incrementar contador curso
[Contador curso= 2 ]
Grabar
do: Grabar formulario
Salir
H
Enviar
do: Enviar formulario para procesarlo
[ Contador curso < 2 ]
VENS
VENS
Dnde Empezar ...
Durante el anlisis, inicialmente concentrarse en el comportamiento de las clases, con significativo comportamiento dinmico Para una clase dada, se deben buscar posibles estados mediante:

Evaluacin de los valores de los atributos Evaluacin de las operaciones Definir las reglas para cada estado y
Identificar las transacciones vlidas 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
VENS
VENS
Ejercicio: Comportamiento del Objeto
Crear un diagrama de transicin de estado para modelar el comportamiento dinmico de la clase empleados con los siguientes estados
Postulante, Contratado, Ausente, Desempleado, Retirado
Informacin del estado Postulante

Una entrevista es conducida durante este estado Este estado es concluido por el evento emplear
Informacin del estado Contratado
El estado contratado posee tres subestados basados en la clasificacin de su sueldo
Por hora, Salario fijo y con Comisiones
La clasificacin por sueldo puede variar en cualquier momento Las clasificaciones por sueldo son creadas/borradas mediante la entrada/salida al subestado
VENS
VENS
Ejercicio: Comportamiento del Objeto (cont.)
Informacin sobre el estado Ausente
Un empleado puede tomarse una ausencia de mximo 1 ao mientras se encuentre en cualquier subestado de contratado
Si el empleado vuelve regresa al subestado anterior
Informacin 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
Informacin del estado Retirado

Un empleado debe retirarse al cumplir 65 La informacin sobre la pensin se calcula en este estado
VENS
VENS
Resumen: Comportamiento del Objeto
Un diagrama de transicin de estado representa el ciclo de vida del objeto en trminos de:

Los posibles estados del objeto Las transiciones entre esos estados El estado inicial es el estado ingresado cuando un objeto es creado El estado final indica el fin de la vida para el objeto
Existen dos estados especiales
Una transicin es un cambio desde un estado original a un estado sucesor, el cual puede ser el mismo estado
VENS
VENS
Resumen: Comportamiento del Objecto (cont.)
Una transicin puede ocurrir como resultado de lo siguiente:
Un evento
Una condicin ha sido satisfecha
Una accin es una operacin que toma una cantidad insignificante de tiempo Una actividad es una operacin 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 ms reciente dentro de un estado
VENS
VENS
Homogenizacin
VENS
VENS
Objetivos: Homogenizacin
Usted ser capaz de:
Discutir por qu la homogenizacin es necesaria
Determinar cuando dos clases deberan ser combinadas, cuando una clase debera ser dividida y cuando una clase debera ser eliminada
Evaluar la consistencia de los diagramas de clases y los diagramas de interacciones. Discutir la necesidad de la reestructuracin de paquetes
VENS
VENS
Qu es la homogenizacin?
Homogenizar mezclar o suavizar una mixtura, para hacerla homognea
- Websters New Collegiate Dictionary
Mientras ms casos de uso y escenarios son desarrollados se torna necesario hacer el modelo homogneo
Esto es especialmente cierto si diferentes grupos estn trabajando en diferentes casos de uso
VENS
VENS
Qu se busca?
Las clases son examinadas para determinar si
Dos o ms clases pueden ser combinadas
Una clase debera ser dividida

Una clase debera ser eliminada por completo Acoplamiento
Los paquetes son reestructurados para solucionar problemas de:
Reuso
Visibilidad
VENS
VENS
Combinando Clases
Cuando mltiples equipos estn haciendo el anlisis 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 anlisis de casos de uso de trabaja con el lenguaje natural Evaluar las definiciones de la clase
El recorrido del modelo debe ser canalizado en
Evaluar la estructura y comportamiento de las clases

Buscar sinnimos Buscar el nombre que es ms cercano al dominio
VENS
VENS
Ejemplo: Combinando Clases
Se elije Teacher ya que no todos los instructores en la Universidad han alcanzado el nivel de Professor
Department 1 1
Department
1
0..*
Professor name address tenureStatus
0..*
Teacher name address
0..* Teacher name address tenureStatus
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 interacta con el caso de uso MantenerInformacinEstudiante y con el caso de uso MantenerInformacinProfesor

Dos clases de control fueron creadas La secuencia en cada una de estas dos clases de control es muy similar (revisin, creacin, borrar informacin acerca del autor) Las clases de control pueden ser combinadas en una sola clase de control llamada AdministracinDeUsuarios
VENS
VENS
Dividiendo Clases
Clases con estructuras y/o comportamientos que no estn cohesionados pueden ser divididos en diferentes clases Ejemplo:
Student
Student name address phoneNumber changeMajor( ) 0..*
name address phoneNumber major numStudentsinMajor changeMajor()
Major name numberStudents
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 podra llevar a la eliminacin de la clase de control
Ejemplo:
Un caso de uso para el actor Professor es Seleccionar Cursos a ensear
Esto significa que el actor Professor ingresa el nombre y nmero del curso y un vnculo a la clase ProfessorInformation es creado Ya que no hay demasiado comportamiento secuencial, esta clase de control es eliminada Ing. Ernesto Caldern Yarlequ
VENS
VENS
Diagrama de Secuencia Actualizado

: Professor CourseForm : Professor 1: open : ProfCourse Manager : Course
2: set prof id
3: set course
: Professor CourseForm
5: addProfessor ( ) 6: addProfessor ( )
: Course
4: process
: Professor
1: open
2: set prof id
7: qui t
3: set course
4: process 5: addProfessor ( ) 6: quit
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 operacin 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 operacin en la clase A es la responsable del envo del evento Una operacin en la clase B espera el evento y lo maneja Una asociacin correspondiente ha sido definida entre la clase A y la clase B en el diagrama de clases El diagrama de transicin de estado para la clase B (si ha sido desarrollado) incluye este evento
VENS
VENS
Reestructurando Paquetes
Mientras ms 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 vas de dependencia entre paquetes puede significar que el paquete debe ser dividido Evale las consideraciones de reuso
Un paquete reusable debe tener pocas dependencias No toda clase en un paquete debe ser parte de la interfaz pblica del paquete Agregar clases de interfaz si es necesario para encapsular el paquete
Evale las partes pblicas y privadas del paquete
VENS
VENS
Ejercicio: Homogenizacin
Discuta las decisiones de homogenizacin necesarias en este punto del anlisis
VENS
VENS
Resumen: Homogenizacin
Mientras ms escenarios y casos de uso se desarrollan se hace necesario hacer al modelo homogneo Las clases son examinadas para determinar si

Dos o ms clases pueden ser combinadas Una clase debe ser dividida Una clase debe ser eliminada por completo Acoplamiento Reuso Visibilidad
Los paquetes son reestructurados para resolver problemas de

VENS
VENS
Diseo Arquitectnico
VENS
VENS
Objetivos: Diseo Arquitectnico

Ser capaz de:
Listar los atributos de una buena arquitectura
Investigar la vista de arquitectura 4+1

Explicar el propsito de los diagramas de componentes Explicar el propsito de los diagramas de implantacin
VENS
VENS
Visin Arquitectnica
Dos caractersticas comunes para que virtualmente todos los proyectos OO sean exitosos son:

La existencia de una fuerte visin arquitectnica La aplicacin de un ciclo de vida incremental, iterativo y bien administrado La arquitectura debe ser simple Una conducta comn lograda a travs de abstracciones y mecanismos comunes
VENS
VENS
Una Definicin de Arquitectura de Software

La arquitectura de software est relacionada con la organizacin de los sistemas de software, la seleccin de los componentes de los cuales ellas estn compuestas, las interacciones entre esos componentes, la composicin de componentes que interactan 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 tambin con su funcionalidad, desempeo, diseo, seleccin entre alternativas y comprensibilidad.
Mary Shaw
VENS
VENS
Atributos de Buenas Arquitecturas
Las buenas arquitecturas se construyen en capas bien definidas de abstraccin:

Cada capa representa una abstraccin coherente Cada capa tiene una interfaz controlada y bien definida Cada capa se construye sobre facilidades bien definidas y controladas a niveles ms bajos de abstraccin
Hay una clara separacin entre la interfaz y la implementacin de cada capa
Los cambios en la implementacin de una capa no violan las suposiciones hechas por sus clientes
VENS
VENS
Desarrollando la Arquitectura del Sistema

El diseo arquitectnico aborda la administracin de riesgos Las buenas arquitecturas son determinadas mejor a travs del desarrollo incremental e iterativo A un pequeo equipo de arquitectos experimentados, guiado por un Arquitecto Jefe, se le debe asignar la responsabilidad para:

Definir y mantener la integridad arquitectnica del sistema Aprobar todos los cambios para las interfaces del paquete Valorar los riesgos del proyecto Proponer el orden y el contenido de cada iteracin
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

Los diagramas de clases no muestran como los sistemas mapean con el hardware
Perspectivas mltiples requieren vistas mltiples
Los diagramas de bloque del hardware no representan qu partes del sistema son software estndar comercial
VENS
VENS
Una Arquitectura Requiere Mltiples Vistas
Para describir completamente una arquitectura, se requieren cuatro vistas:
La vista lgica para proveer una descripcin esttica de las clases primarias y sus relaciones La vista de componentes para mostrar cmo el cdigo se organiza en paquetes y bibliotecas y el uso de software estndar comercial
La vista de procesos para mostrar los procesos y las tareas

La vista de implantacin para mostrar los procesadores, dispositivos y enlaces en el medio operacional
Finalmente, una vista de escenarios (vista de casos de uso) explica cmo las otras cuatro vistas trabajan en conjunto
VENS
VENS
El Modelo Vista 4+1

Vista Lgica
Funcionalidad
Vista de Componentes
Administracin de Software, Reuso, Portabilidad
Usuarios Finales
Vista Caso de Uso

Comprensibilidad Usabilidad
Ingenieros de Software
Vista Proceso
Desempeo, Disponibilidad, Tolerancia a fallos
Vista Implantacin
Desempeo, Disponibilidad, Tolerancia a fallos, Escalabilidad, Entrega e Instalacin
Integradores de Sistema
Ingenieros de Sistema
VENS
VENS
Vista Lgica
La vista lgica de la arquitectura se concentra en los requerimientos funcionales del sistema
Qu le proveer el sistema a sus usuarios en trminos de servicios
Provee una descripcin esttica de las clases primarias y sus relaciones La vista lgica 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
VENS
VENS
Paquetes Lgicos Globales
Ciertos paquetes son usados por todos los otros paquetes
Clases bsicas
Conjuntos, listas, colas, etc.
Clases para la manipulacin de errores
Estos paquetes son marcados como globales
Clases Bsicas
global
VENS
VENS
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
Paquete Cliente Paquete Suministrador
VENS
VENS
Evitando Dependencias Circulares

Es deseable que la jerarqua del paquete sea acclica Esto significa que la siguiente situacin 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 tendrn que ser tratados como un paquete simple Crculos mayores de dos paquetes tambin tendrn 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
VENS
VENS
Dependencia Circular en el Sistema de Registro

Interfaces Reglas de Negocio
Cambia a
Interfaces de Entrada
Reglas de Negocio
Interfaces de Salida
VENS
VENS
Interfaz Pblica de un Paquete
Una interfaz de un paquete debe encapsular su implementacin detrs de una interfaz pblica tal como lo hace una clase Cada clase en un paquete tiene un parmetro de control de exportacin, el cual debe ser fijado a pblico o implementacin (privado)
Solamente las clases pblicas podrn ser usadas por clases de otros paquetes
Las clases de implementacin (privadas) solamente pueden ser usadas dentro de su paquete
VENS
VENS
Vista de Componentes
La vista de componentes de la arquitectura tiene que ver con la organizacin 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 asignacin de clases a los componentes Muestra la asignacin de componentes a los paquetes
Los paquetes se organizan en una jerarqua de capas, donde cada capa tiene una interfaz bien definida
VENS
VENS
Qu es un Componente?
Un componente es una unidad de cdigo fuente que sirve como un bloque de construccin para la estructura fsica de un sistema Estereotipos (con iconos alternativos) pueden ser usados para definir tipos especficos de componentes.
Ejemplos: exe, dll, programas principales, encabezados, mdulos, 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 implementacin Notacin de un componente:
Nombre Componente
VENS
VENS
Diagramas de Componente
Un diagrama de componente muestra la localizacin de las clases y los objetos en la implementacin de componentes as como sus dependencias en compilacin
Nombre 1 Nombre 2
Nombre 1 Nombre 2
Nombre 3
VENS
VENS
Diagramas de Componente (cont.)
Se requiere Un nombre para cada componente, este nombre tpicamente denota el nombre del archivo fsico correspondiente en el rea de trabajo de desarrollo La nica relacin es una dependencia de compilacin, representada por una lnea discontinua direccionada que apunta al mdulo para el cual existe En C++, una dependencia de compilacin se indica por las directivas #include No pueden existir ciclos dentro de un conjunto de dependencias de compilacin
VENS
VENS
Ejemplo: Diagrama de Componente

Curriculum Curriculum
Curso
Curso
VENS
VENS
Paquetes en la Vista Componente
Un paquete en la vista componente es una coleccin de componentes, algunos de los cuales estn visibles a otros paquetes y otros estn ocultos Un paquete agrupa componentes que estn lgicamente relacionados Un paquete en la vista componente agrupa componentes de modo similar a los paquetes que en la vista lgica agrupan clases Cada componente en un sistema tiene que vivir en un paquete simple o al ms alto nivel del sistema Notacin: Nombre del paquete
VENS
VENS
Diagramas de Componentes Principales
Un diagrama de componente principal es una familia de paquetes conectados a travs de enlaces dirigidos que representan dependencias
Ejemplo:
MFC Interfaz de registro de usuario
Sistema de Registro
VENS
VENS
Correspondencia entre Paquetes en las Vistas Lgicas y de Componentes
En general, un paquete en la vista lgica puede corresponder directamente a un paquete en la vista de componentes Las estructuras lgica y fsica pueden variar por las siguientes razones:
Los paquetes en la vista lgica son agrupados, es decir, se mantienen a los objetos unidos comunicndose estrechamente para la implementacin
Los paquetes en la vista componente son aadidos para implementar la funcionalidad a bajo nivel no representada durante el anlisis
La estructura de divisin del trabajo del equipo de desarrollo influencia la asignacin de paquetes y componentes en la vista componentes
VENS
VENS
Ejemplo: Correspondencia entre Paquetes en las Vistas Lgica y de Componente

DispositivoGUI Interfaz de Registro de Usuario MFC Interfaz de Registro de Usuario
Sistema de Registro
Sistema de Registro
Diagrama de Vista Lgica de Alto Nivel
Diagrama de Vista Componente de Alto Nivel
VENS
VENS
Vista de Proceso
La vista del proceso de la arquitectura se enfoca en el proceso de descomposicin
Esta vista muestra la localizacin de los componentes a procesar
El diagrama componente es actualizado para mostrar la localizacin de los componentes a procesar La vista proceso se concentra en la disponibilidad del sistema, confiabilidad, desempeo, administracin del sistema y sincronizacin
VENS
VENS
Componentes de Proceso
Las bibliotecas ejecutables y vinculadas son representadas mediante componentes en UML

Especificacin del paquete (DLL) Especificacin de la tarea (EXE)

Especificacin de la tarea (EXE)
Especificacin del paquete (DLL)
VENS
VENS
Diagrama de Componentes para un Proceso
Cada componente puede depender de otras componentes

Nombre1 Nombre2
MiProceso.exe
Nombre1
Nombre2
VENS
VENS
Procesos para el Sistema de Matrcula de Curso

Curriculum.exe Matrcula.exe
Proceso para la creacin y mantenimiento del curriculum
Proceso para la seleccin de cursos por estudiantes y profesores
VENS
VENS
Vista Implantacin
La vista de implantacin de la arquitectura mapea componentes con nodos de procesamiento Requerimientos tales como rendimiento, desempeo y tolerancia a fallos son tomados en cuenta Los diagramas de implantacin se crean para mostrar los diferentes nodos (procesadores y dispositivos) en el sistema
VENS
VENS
El Diagrama de Implantacin
Un diagrama de implantacin muestra la asignacin de componentes a nodos en la vista de implantacin de un sistema
Los procesadores y dispositivos son estereotipos comunes de Nodo.
Los nodos se conectan en un diagrama que refleja los caminos de comunicacin entre ellos Los elementos esenciales en un diagrama de implantacin son los nodos y sus conexiones
VENS
VENS
Notacin para Diagramas de Implantacin
Un nodo es un objeto fsico en tiempo de ejecucin que representa recursos computacionales Una conexin indica comunicacin, usualmente mediante el acoplamiento directo de hardware
nombre
etiqueta
nodo
conexin
VENS
VENS
Ejemplo: Diagrama Implantacin del Sistema de Registro
Este diagrama muestra dos nodos y los dispositivos con los cuales el sistema de registro se comunica
Sistema de Registro Base de datos
Dormitorios <<dispositivo>> Bloque Principal <<dispositivo>>
Biblioteca <<dispositivo>>
VENS
VENS
Procesos
Un proceso es la ejecucin de un hilo de control de un programa (OO) o sistema
Un sistema extenso puede ser dividido en mltiples procesos o hilos de control
Los objetos son asignados a los procesos (sus asignaciones pueden ser dinmicas) Los procesos son asignados a procesadores (el conjunto de procesos puede ser dinmico) Notacin:
Nombre del Procesador
proceso 1, proceso 2, ... proceso n
VENS
VENS
Mapeando Paquetes de Desarrollo a Procesos Ejecutables
El mapeo de los paquetes de desarrollo a procesos ejecutables involucra el entendimiento de la topologa y las prioridades del sistema, incluyendo:

Arquitectura, velocidad y capacidad del procesador Mantener las asociaciones de clases juntas para minimizar la comunicacin entre procesos (IPC) Estrategia IPC -- cliente/suministrador u otros?
Tcnicas de Procesamiento Distribuido
Se tienen que resolver las cuestiones que involucren mltiples procesadores de hardware o de sistemas distribuidos, durante el diseo del sistema.
VENS
VENS
Mapeando Procesos Ejecutables al Hardware
Los procesos tienen que ser asignados a un dispositivo de hardware para su ejecucin Entre las consideraciones se encuentran:

Tiempo de respuesta y rendimiento del sistema Capacidad y ancho de banda de las comunicaciones Localizacin fsica del hardware requerido
Requerimientos del procesamiento distribuido

Sobrecarga o estabilizacin del procesador en un sistema distribuido Tolerancia a fallos ...
VENS
VENS
Vista Caso de Uso
Los casos de uso son los manipuladores para el diseo arquitectnico
Abstracciones de requerimientos complejos, extensos
Identificacin de interfaces crticas

Forzar a los diseadores a enfocarse en asuntos concretos
Ellos demuestran y validan las vistas de implantacin, lgica, de proceso y de desarrollo de la arquitectura
VENS
VENS
La Vista 4+1 de un Modelo UML

Vista Lgica
Diagramas de clases, Diagramas de secuencia
Vista Componente
Diagramas de Componentes
Vista Caso de Uso

Diagramas Casos de Uso, Diagramas de Secuencia
Vista Proceso
Diagramas de implantacin
Vista Implantacin
Diagramas de implantacin
VENS
VENS
Cmo est la Arquitectura Documentada?
La arquitectura est documentada en un documento de arquitectura
Aproximadamente 100 pginas para un sistema extenso Una descripcin textual de la filosofa arquitectnica (las vistas) y los requerimientos claves de manejo Balances hechos y alternativas consideradas
El documento incluye:
Una vista de alto nivel de la vista lgica (paquetes y clases claves)

Escenarios especficos a arquitecturas Vistas de desarrollo, de procesos a alto nivel y vistas de implantacin Los mecanismos claves
VENS
VENS
Quin Desarrolla la Arquitectura de Software?
Lo hace el equipo de arquitectura: un grupo de los mejores y ms experimentados desarrolladores Se establece al principio en el proyecto (no despus de la fase de elaboracin) La mayora 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 guas para los diseadores de las funciones principales y de las funciones crticas del sistema
VENS
VENS
Evolucin del Equipo de Arquitectura

Fase de Construccin Fase de Elaboracin
Equipo de Arquitectura Arquitecto Diseadores guias Desarrolladores de infraestructura Equipo de Arquitectura Arquitecto Grupo pequeo de apoyo Equipo 1 de la Aplicacin Diseador guia Ingenieros de aplicacin Equipo 2 de la Aplicacin Diseador guia Ingenieros de aplicacin
En la fase de elaboracin, los miembros estn 100% dedicados al equipo de arquitectura. Durante la construccin, los miembros se convierten en diseadores guias de los equipos de aplicacin y apoyan parcialmente al equipo de arquitectura
. . .
VENS
VENS
Beneficios de un Equipo de Arquitectura
Entregables
Documento de Arquitectura
Partes de los documentos de diseo de bajo nivel

Guas para el diseo y la programacin Elementos de los planes de puesta en circulacin Revisin del diseo del sistema entregado
La eficacia y habilidades del equipo de arquitectura son crticas para el xito de un proyecto
Con una buena arquitectura, un equipo de desarrollo promedio puede tener xito. Con una arquitectura dbil, inclusive los desarrolladores ms expertos no tendrn xito
VENS
VENS
Ejercicio: Diseo arquitectnico

Discutir las consideraciones de la arquitectura para el problema Aadir modelos al paquete mientras sea requerido
Reubicar clases en los diferentes paquetes mientras sea requerido
VENS
VENS
Resumen: Diseo Arquitectnico
El propsito de esta fase es crear una arquitectura para la implementacin y establecer las polticas tcticas 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 abstraccin bien definidas Existe una separacin clara entre la interfaz y la implementacin de cada capa La arquitectura es simple
VENS
VENS
Resumen: Diseo Arquitectnico (cont.)
La vista lgica 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, desempeo, administracin y sincronizacin 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 organizacin del software del sistema
Los diagramas de componentes se crean para mostrar los paquetes y componentes que conforman el sistema
VENS
VENS
Resumen: Diseo Arquitectnico (cont.)
La vista de implantacin de la arquitectura mapea el software con los nodos de procesamiento
Los diagramas de implantacin son creados para mostrar los diferentes procesadores y dispositivos en el sistema
Los casos de uso demuestran y validan las vistas lgica, de proceso, desarrollo y de implantacin de la arquitectura
VENS
VENS
Mecanismos Claves
VENS
VENS
Objetivos: Mecanismos Claves

Ser capaz de:
Describir algunos mecanismos claves especficos a OO
Explicar los aspectos asociados con la interfaz de base de datos

Listar algunas consideraciones para la evaluacin de los sistemas de administracin de bases de datos Describir el manejo de excepciones y sus tpicos asociados
Explicar los aspectos asociados con la comunicacin entre procesos
VENS
VENS
Qu son los Mecanismos Claves?
Un mecanismo clave es una decisin estratgica teniendo en cuenta estndares, polticas y prcticas comunes. Por ejemplo:

Una propuesta comn para el manejo de errores, o Una forma comn de comunicacin entre procesos
La mayora de los principios del diseo de software tradicional an se aplican en el diseo OO
Los problemas a ser resueltos son similares, como por ejemplo, la contencin de recursos, la atenuacin de riesgos y otros Soluciones que siendo estructuradas usan mtodos OO Las caractersticas de los lenguajes de programacin OO
Se producen algunas diferencias debido a:

VENS
VENS
Mecanismos Claves Comunes

Administracin de la contencin de recursos Manipulacin especial requerida para el arranque y trmino del sistema Integracin con los sistemas de almacenamiento de datos persistentes Deteccin, manipulacin y reporte de errores Comunicacin entre procesos
Pase de mensajes
Aspecto y sensacin de la interfaz de usuario Reuso del software
VENS
VENS
Contencin de los Recursos
Una clase administradora de recursos podr ser usada para controlar el acceso a los recursos La clase administradora utiliza mtodos de software tradicionales, tales como semforos 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
VENS
VENS
Contencin de los Recursos (cont.)

AdministradorRecurso RecursoAdministrado adquiere () libera () 1 1..*
Fichero
MemoriaCompartida
VENS
VENS
Arranque y Trmino del Sistema
Si ya no se ha cubierto durante el anlisis, debern ser definidos los casos de uso, tanto para el arranque como para el trmino del sistema Los escenarios debern ser desarrollados para cada caso de uso tantos como sean requeridos para la manipulacin de todas las principales situaciones, tanto normales como atpicas 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 trmino del sistema
VENS
VENS
Objetos Persistentes
Un objeto persistente es aquel que existe lgicamente ms all del alcance del programa que lo cre Los lenguajes de programacin 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 algn tipo de almacenamiento persistente Un objeto persistente puede tambin 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
VENS
VENS
Almacenamiento Persistente
El almacenamiento persistente puede hacerse usando un sistema de archivo simple o algn tipo de sistema de administracin de base de datos Existen varios modelos para DBMSs:

Jerrquico En red Relacional (RDBMS) Orientado a objeto (ODBMS)
El Relacional y el ODBMSs son los ms comunes
VENS
VENS
Seleccionando una Propuesta para la Persistencia
La estrategia de diseo 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 diseo de objetos en que los diseadores tienen que considerar:
Mtodos adicionales de objetos para almacenar y obtener los objetos persistentes Adicin de atributos para manipular detalles del sistema de almacenamiento Clases adicionales para interactuar con el DBMS
VENS
VENS
Criterio de Evaluacin del DBMS
El criterio de evaluacin para seleccionar un DBMS debe ser decidido desde el inicio Las siguientes transparencias contienen criterios encontrados en Consideraciones Para la Evaluacin de Sistemas de Administracin de Bases de Datos Objetos por Robert Gancarz y Grant Colley, Object Magazine, Marzo/Abril 1992
Estos criterios tambin se aplican para la seleccin de un sistema de administracin de bases de datos relacionales
VENS
VENS
Criterio de Evaluacin de un DBMS (cont.)
Fortalezas del proveedor
Considerar la fortaleza financiera, la estructura de la organizacin, los procedimientos de apoyo al cliente, el entrenamiento y apoyo a consultas y asociaciones con otras compaas Ningn estndar de comparacin de rendimiento puede probar que la DBMS es la ms rpida para todas las aplicaciones
El desempeo depende de la aplicacin
Desempeo de la Base de datos
Son muy importantes los prototipos especficos de la aplicacin
Potencial de las Bases de datos
La administracin de transacciones, el control de concurrencia, resguardos y recuperaciones, la seguridad y los lenguajes de consulta respaldan las capacidades que deben ser evaluadas
VENS
VENS
Criterios de Evaluacin 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 Seleccionar las herramientas para el diseo de la base de datos, la modificacin del esquema de la base de datos y la navegacin y depuracin de la base de datos Asegurar que exista ayuda en el lenguaje seleccionado para el sistema que est siendo desarrollado
Herramientas de desarrollo
Ayuda del lenguaje
Facilidad de migracin
Cun fcil/difcil es migrar hacia el sistema de base de datos
VENS
VENS
Criterio de Evaluacin del DBMS (cont.)
Integracin con Sistemas Existentes
Cun fcil/difcil es la integracin con los sistemas de administracin de bases de datos existentes Evaluar el soporte para el desarrollo multiusuario, la administracin de configuracin, diferentes versiones y estrategias de bloqueo En el fondo: Invertir el tiempo y energa para seleccionar el sistema de administracin de bases de datos adecuado para el proyecto Es SIEMPRE ms caro corregir un error que hacer las cosas correctas desde la primera vez !!!
Soporte multiusuario
VENS
VENS
Aspectos de las Bases de Datos Relacionales
Hay dos aspectos principales a contemplar cuando se disea un sistema OO usando una base de datos relacional Existe una diferencia semntica natural entre el modelo basado en clases, de un diseo orientado a objeto y el modelo basado en tablas de una base de datos relacional
Un mapeo o traduccin entre ambos tiene que ser definido
La conducta que interacta con el RDBMS y la implementacin de esta traduccin tienen que estar definidas
Deber esta conducta estar insertada en objetos persistentes o de algn modo ser mantenida separada?
VENS
VENS
Mapeo a Bases de Datos Relacionales
Tpicamente, cada clase mapea con una tabla y cada instancia mapea con una fila.
Cliente
nombre direccin descuento
Tabla del Cliente

clienteID nombre direccin descuento
Mapeos ms complicados son posiblesOne class maps to multiple tablesMultiple classes map to one table
VENS
VENS
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 relacin
Cliente nombre direccin descuento
Tabla Cliente
clienteID nombre direccin descuento
0..* Orden tiempoEntrega urgencia
Tabla Orden
ordenID entrega urgencia clienteID
VENS
VENS
Mapeo a Bases de Datos Relacionales (cont.)
Las tablas se crean para resolver relaciones muchos-a-muchos
Producto
Tabla Ingrediente del Producto
0..*
productoID ingredienteID
1..* Ingrediente
VENS
VENS
Las superclases / subclases pueden tambin ser mapeadas a tablas
Cada clase y subclase es una tabla

Las vistas son provistas para la jerarqua
Orden fechaEntrega urgencia
Tabla Orden
ordenID fechaEntrega urgencia
Tabla OrdenEspecial
OrdenEspecial fechaInicio fechaFin
OrdenPendiente frecuencia
ordenID
fechaFin
fechaInicio
VENS
VENS
Existen estrategias alternativas para las superclases y subclases
Repetir todos los atributos en la tabla superclase
Problema: espacio desperdiciado

Problema: redundancia
Repetir todos los atributos en la tabla subclase
Desempeo versus balanceo del espacio de almacenamiento se usan para decidir qu mapeo usar en situaciones de herencia
VENS
VENS
Interactuando con RDBMS
El principal aspecto asociado con la interaccin con un RDBMS es si separar la conducta especfica de la aplicacin de la conducta especfica 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-aRDBMS?
Debe la clase Cliente contener el funcionamiento para interactuar con el agente RDBMS (es decir, cdigo 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
VENS
VENS
Interactuando con RDBMS (cont.)
La conducta especfica a la base de datos no separada de la conducta especfica a la aplicacin:
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
Ningn reto tcnico para implementarlo

Los modelos OO y RDBMS no son separables La funcionalidad CRUD no siempre es puramente heredable
Desventajas

VENS
VENS
Conducta de la Base de Datos dentro de la Clase

: AdministradorCurriculum 1: guardar ( ) : Curso
Curso descripcin El Curso tiene que tener conocimiento de la base de datos guardar ()
VENS
VENS
Interactuando con RDBMS
La conducta especfica a la base de datos se separa de la conducta especfica de la aplicacin
El sistema puede ser modelado en dos partes: la Aplicacin 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 OOa-RDBMS y tiene la funcionalidad para interactuar con el RDBMS El modelo OO es separable del modelo RDBMS Las herramientas estn disponibles para generar las clases bsicas de interfaz con la base de datos Un reto tcnicamente mayor de implementacin
Ventajas

Desventajas
VENS
VENS
Separar la Conducta de la Base de Datos

: AdministradorCurriculum : Administrador Transaccin 1:guardarCurso (Curso) 2: guardar(Curso) 3: obtenerDescripcion ( ) 4: hacerPersistente ( ) : CursoBD : Curso
AdministradorTransaccin
El AdministradorTransaccin separa lo lgico (Curso) de lo fsico (CursoBD)
Curso
CursoBD
VENS
VENS
DBMSs Orientados a Objetos
ODBMSs permiten almacenamiento, recuperacin y restablecimiento de los propios objetos (con datos complejos encapsulados dentro de cada objeto) Un ODBMS tpicamente contiene

Objetos (es decir, valores de atributos) Informacin de clase sobre cada objeto
No hay diferencia semntica entre el modelo OO y el modelo ODBMS - ellos son idnticos Ningn funcionamiento especial tiene que ser diseado para interactuar con el ODBMS
VENS
VENS
DBMSs Orientados a Objetos (cont.)
Ventajas:

Interfaz no fundida entre la aplicacin y la base de datos

Relativamente poco cdigo requerido para crear objetos persistentes Muy efectivo con sistemas que tienen que contemplar estructuras de datos complicadas Mayor riesgo de desarrollo mientras la tecnologa ODBMS y sus productos no estn tan maduros como sus contrapartes RDBMS Desempeo con estructuras de datos ms simples no provee ventajas sobre RDBMS
Desventajas:
Las inversiones existentes en tecnologa relacional, tienen que ser consideradas cuando se vaya a evaluar tecnologa de bases de datos orientada a objetos
VENS
VENS
Deteccin de Errores
Una propuesta consistente para la deteccin de errores debe ser establecida
Los objetos deben detectar los errores que violaran sus integridades estos errores son:

Los producidos dentro de sus operaciones Los resultantes de parmetros recibidos de objetos clientes Los resultantes de valores retornados provistos por los objetos suministradores Operacin de prueba para cada clase que verifique la integridad de la estructura interna y del entorno
Un plan puede ser establecido para monitorear la salud del sistema
Monitoreo de objetos definido para, peridicamente, consultar cada funcin de prueba del objeto
VENS
VENS
Manejo de Errores
Inclusive en los sistemas OO, el manejo de errores tiene que ser cuidadosamente diseado -- ms del 30% del cdigo final frecuentemente existe para manipular condiciones de errores Los lenguajes modernos OO (tales como C++ ) proveen caractersticas para el manejo de excepciones que ayudan en este diseo 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
VENS
VENS
Ejemplo del Manejo de Excepciones

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; } }
VENS
VENS
Lanzando y Capturando Excepciones
Cuando hay un problema que no puede ser manejado en el contexto actual, una excepcin puede ser creada y lanzada lanzar Problema(las cosas estn mal); Qu hace lanzar?
El objeto excepcin es creado y retornado
A dnde va el objeto excepcin?
Cuando una excepcin se lanza, en la pila de llamadas se busca el primer manipulador que machee
Habr un manipulador de excepcin por cada tipo de excepcin que pudiera ser capturada
catch (Problem&) {
// maneja excepciones del tipo Problem} VENS

VENS
Aspectos del Manejo de Excepciones
En el proceso de bsqueda en la pila de llamadas, destructores para objetos locales son llamados para

Variables Automticas Parmetros por valor Valores temporales
Destructores no se llaman para

Variables Dinmicas
Variables Estticas
El cdigo despus del punto de lanzamiento nunca es ejecutado Las excepciones se atribuyen administracin de recursos (por ejemplo, el cierre de ficheros abiertos)
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 informacin disponible para manejar el error, entonces esto NO es una excepcin
Una excepcin NO es un retorno alternativo
Para controlar el flujo del programa
VENS
VENS
Cundo Deben Ser Usadas Las Excepciones?
Las excepciones son lanzadas como resultado de un error grave
No hay retorno al punto donde fue lanzada la excepcin
Las excepciones no deben ser usadas si el error puede ser manejado (corregido) y el procesamiento puede continuar
Una operacin puede ser llamada para reparar el problema y el procesamiento puede continuar
VENS
VENS
Usos Tpicos de las Excepciones
Reparar el problema y continuar el procesamiento sin volver a la funcin que lanz la excepcin Calcular un resultado alternativo Lanzar el error a un contexto mayor Terminar el programa Agrupar funciones que usan esquemas de errores comunes
Simplificar el cdigo
Hacer el cdigo ms fcil de mantener
VENS
VENS
Reportando los Errores
Mantener registrado el error respectivo y reportar on-line son claves para la mayora de los sistemas Una conducta consistente en el reporte de errores puede ser implementada en la clase de error bsica usada en el manejo de excepciones Esta conducta puede incluir
Aadir 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 aplicacin
VENS
VENS
Comunicacin entre procesos

ClaseA llama a una operacin de la ClaseB, functionB() Qu sucede cuando ClaseA y ClaseB estn en procesos diferentes?
Esto se convierte en un aspecto crtico en los sistemas distribuidos

Se requiere un mecanismo estndar para la comunicacin
: ClaseA
ClaseA ClaseB
: ClaseB 1: functionB ( )
functionB( )
VENS
VENS
Comunicacin entre Procesos(cont.)
Una solucin comn 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 comunicacin a ms bajo nivel
La distribucin es transparente a las clases de la aplicacin
VENS
VENS
Estndares Distribuidos OO
Seleccionar un estndar de distribucin es un asunto de diseo si el sistema usa objetos distribuidos Hay dos estndares emergiendo para la distribucin 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 ubicacin Las decisiones de distribucin pueden ser tomadas en tiempo de ejecucin
VENS
VENS
Clases Proxy
ClaseA
ClienteProxyB
ServidorProxyB
ClaseB
Object Request Broker
VENS
VENS
Planificando para el Reuso
Los componentes reusables tienen que ser considerados al inicio en el diseo para su incorporacin al sistema Evaluar bibliotecas de software internas, comerciales para mdulos que apliquen en el sistema Las bibliotecas de clases son grupos de clases colaborando que proveen algn servicio, interfaz o funcin Las bibliotecas de clases estn comnmente disponibles para:
Objetos contenedores
Interfaces a bases de datos Ventanas de interfaz de usuario
VENS
VENS
Actualizando Diagramas
Los diagramas de clases se actualizan para mostrar los mecanismos claves seleccionados Los diagramas de secuencias se actualizan para mostrar interaccin entre las clases ya descubiertas y las clases que representan las estrategias de mecanismos claves
VENS
VENS
Diagrama de Clase Actualizado

Interfaces de salida VentanasGUI Interfaces de entrada
Reglas del negocio
Equipos de Universidad
Basamento
global
Manejo de errores
global
Base de datos
VENS
VENS
Diagrama de Secuencia Actualizado

: Registrar aForm : CurriculumMgr 1: open
theManager : CurriculumMgr
theCourse : Course
anOffering : (Course
dbMgr : TransactionMgr
dbCourse : DBCourse
dbOf f ering : DBOf f ering
2: enter id 3: verify id 4: enter 5: create a 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, 12: create(professor, time, 13: save 14: save(course) 15: get info 16: commit 17: save(offering) 18: get info 19: commit
VENS
VENS
Ejercicio: Mecanismos Claves

Discutir las estrategias de mecanismos claves para el problema Actualizar los diagramas de clases para mostrar la incorporacin de los mecanismos claves Actualizar los diagramas mientras sea necesario
VENS
VENS
Resumen: Mecanismos Claves
La seleccin de los mecanismos claves se enfocara en las decisiones respecto a estndares, polticas y prcticas comunes, incluyendo:

Administracin de la contencin de los recursos Manipulacin especial requerida para el arranque y la terminacin de los sistemas Integracin con sistemas de almacenamiento de datos persistentes
Deteccin / manejo / reporte de errores

Comunicacin entre procesos Reuso del software
VENS
VENS
Diseando Clases
VENS
VENS
Objetivos: Diseando Clases

Ser capaz de:
Discutir las decisiones de diseo de la interfaz de usuario
Aadir clases para resolver los problemas de diseo

Usar patrones para resolver problemas de diseo
VENS
VENS
Diseo 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 informacin desde fuera del sistema
Durante el anlisis, las clases fronteras de alto nivel son identificadas Durante el diseo, el diseo de la interfaz de usuario se completa

Diseo de la ventana Nmero de ventanas Manipulacin de eventos de usuarios
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 diseo Los diagramas de colaboracin y/o secuencia tambin 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
VENS
VENS
Diagrama de Secuencia para la Creacin de un Escenario de Curso

: Registrar aForm : CurriculumForm 1: open 2: enter id 3: verify id 4: enter 5: create a 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,) theManager : CurriculumMgr theCourse : Course anOffering : (Course dbMgr : TransactionMgr dbCourse : DBCourse dbOffering : DBOffering
11: create offering(number, professor,) 12: create(professor, time,)

13: save 14: save(course) 15: get info 16: commit 17: save(offering) 18: get info 19: commit
VENS
VENS
Requerimientos de la Interfaz de Usuario
Actor Registrador
Entrar la informacin requerida para crear un curso y sus ofertas 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
Requerimientos desde otros escenarios
Decisiones de diseo

Una ventana contiene todas las opciones disponibles a Registrar

Una ventana contiene informacin del curso Una ventana contiene informacin de la oferta Botones disponibles en las ventanas de curso y oferta para permitir que la informacin sea salvada, cancelada o borrada
VENS
VENS
Ventana Principal de Opciones Registrar
VENS
VENS
Ventana Curso
VENS
VENS
Ventana Oferta de Curso
VENS
VENS
Matrcula de Cursos
Formulario de matrcula John : estudiante 1: entrar id 2: validar id 3: entrar semestre actual 4: crear nuevo horario 5: mostrar 6: obtener cursos 7: seleccionar Formulario de horarios cursos disponibles
VENS
VENS
Interfaz del Sistema de Registro Requerimientos para este Escenario
Actor estudiante
Tiene que ser provisto con un medio de seleccin de cursos para el sistema actual La lista de los cursos disponibles es mostrada al actor Una ventana GUI se crea para contener cuadros de listas (list boxes) para las selecciones de los cursos
Decisin de diseo
Los cuadros de listas contienen los nombres de todos los cursos ofrecidos
VENS
VENS
Ventana de Registro de Curso
VENS
VENS
Que Sucede Cuando se Hace Click Sobre el Botn OK?
Todos los constructores GUI son diferentes
Algunos crean objetos que contienen la informacin desde la ventana Otros crean estructuras de datos con la informacin Las clases de control reciben los datos desde la ventana GUI y los procesan
Algunas tcnicas comunes
Los datos de la ventana son pasados desde la ventana GUI a la clase de control
El botn sabe qu hacer con el dato en la ventana
VENS
VENS
Clase Utility
El estereotipo utility se usa para una clase que contiene una coleccin de subprogramas libres
Los subprogramas libres son funciones no miembros, es decir, funciones que no pertenecen a una clase en particular Proveer algunos servicios algortmicos comunes, servicios que pueden ser tiles en una variedad de contextos
Las clases Utility son usualmente definidas para
Agrupar bibliotecas no orientadas a objetos o aplicaciones

<<utility>> FuncionesMatemticas
VENS
VENS
Ejemplo: Clase Utility
La clase utility SchedulingAlgorithms contiene funciones que resuelven conflictos de horarios

<<utility>> Scheduling Algorithms
0..* <<control>> AdministradorMatrcula 1 1..* Curso
VENS
VENS
Ejemplo: Clase Utility (cont.)
Para evitar que mltiples utilidades (funciones libres C++) se conviertan en unidades separadas, una clase utility puede ser creada para empacar todas las funciones bajo una interfaz
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
Usando Funciones Libres

extern float inchToCentimeter(float inch);
extern float centimeterToInch (float centimeter);
VENS
VENS
Clases de Ayuda
Durante el diseo, una clase puede ser aadida para ayudar a ejecutar alguna funcionalidad requerida Ejemplo:
El FormularioCurriculum tiene que verificar que el id entrado sea vlido
Si la verificacin tiene que ver solamente con el formato del id, entonces la ventana puede ejecutar esta funcionalidad
Si la verificacin tiene que ver con la seguridad, entonces informacin adicional es requerida Lista de nmeros id vlidos Esta clase es aadida al sistema
VENS
VENS
El Surgimiento de Patrones
Un patrn de diseo es una solucin para un problema de diseo comn Un patrn

Describe un problema de diseo comn Describe la solucin del problema Discute los resultados y el balance de aplicar el patrn
Los patrones estn siendo recopilados, catalogados, y usados para construir sistemas

Proveen la capacidad de reusar arquitecturas y diseos exitosos Conducen a sistemas ms fciles de mantener Incrementan la productividad
VENS
VENS
Adaptacin de Patrones
Los sistemas de registros de cursos tienen tres tipos de usuarios: los estudiantes, profesores y el que registra Una jerarqua UsuarioRegistro fue creada para los diferentes tipos de usuarios El tipo de usuario a crear depende del dato entrado en una ventana GUI Problema: Quin crea el tipo especfico de usuario?
El patrn Factory Method puede ser usado para crear el tipo adecuado de usuario basado en datos en tiempo de ejecucin
Al factory le son dados los datos y se le dice cmo crear el tipo correcto de objeto
VENS
VENS
El Patrn Factory
UsuarioFactory crea (qu) 1 crea 1 UsuarioRegistrar
Estudiante
Profesor
Registrar
La operacin crea(que) del UsuarioFactory crea el tipo adecuado de UsuarioRegistrar
VENS
VENS
Otros Ejemplos de Patrones

Prototipe -- crea un objeto mediante la copia de un objeto prototpico 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 agregacin Memo -- captura y exterioriza un estado interno del objeto para que el objeto pueda ser recuperado a este estado despus (esto se hace sin interrumpir la encapsulacin)
VENS
VENS
Cuntas Clases son Requeridas?
Muchas clases simples significa que cada clase
Encapsula menos de la inteligencia total del sistema
Es ms reusable
Es ms fcil de implementar Encapsula una gran parte de la inteligencia total del sistema
Unas pocas clases complejas significa que cada clase
Es menos probable que sea reusable

Es ms difcil de implementar
Principios a considerar: Una clase debe tener un simple pero bien enfocado propsito. Una clase debe hacer solo una cosa y hacerla bien!!!
VENS
VENS
Ejercicio: Clases en el Diseo
Discuta clases adicionales que pudieran ser aadidas al modelo para facilitar decisiones de diseo Actualice los diagramas si es necesario
VENS
VENS
Resumen: Clases en el Diseo
Durante el diseo, clases son aadidas para facilitar el diseo del sistema Una clase utility es una coleccin de subprogramas libres Un patrn de diseo es una solucin a un problema de diseo comn Los patrones estn siendo recopilados, catalogados y usados para construir sistemas

Brindan la capacidad de reusar arquitecturas y diseos exitosos Conducen a sistemas ms fciles de mantener Incrementan la productividad
VENS
VENS
Diseando Relaciones
Ing. ERNESTO CALDERON YARLEQUE Rernestocy@Hotmail.com VENS

VENS
Objetivos: Diseando Relaciones

Ser capaz de:
Determinar la navegacin de la relacin
Refinar las asociaciones y relaciones de agregacin

Discutir opciones de la visibilidad de objetos Discutir decisiones de diseo mltiples Disear clases asociacin
VENS
VENS
Navegacin
En anlisis, las asociaciones son bidireccionales
En diseo, una asociacin puede ser unidireccional
Se aade una flecha a la asociacin para mostrar que la navegacin va solamente en una direccin El Cliente puede hablar a la Orden La Orden no puede hablar al Cliente
Cliente
0..*
Orden
VENS
VENS
Decisiones de Navegacin
Durante el diseo nosotros miramos si es realmente necesario navegar en ambas direcciones La necesidad para la navegacin 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?
VENS
VENS
Interrogantes de la Navegacin
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)
Proveedor 1..* 1..*
Producto
VENS
VENS
La Navegacin en Ambos Sentidos vs. La Navegacin en un Sentido
Las relaciones en los dos sentidos son ms difciles y costosas de implementar que las relaciones en un solo sentido Inclusive si la navegacin en ambos sentidos se requiere, una relacin de un solo sentido pudiera bastar bajo ciertas circunstancias. Por ejemplo:
La navegacin en una de las direcciones es muy poco frecuente y no tiene rigurosos requerimientos de desempeo, o
El nmero de instancias de una de las clases es muy pequeo
VENS
VENS
Ejemplo: Simplificando una Relacin
Situacin 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 direccin producto-a-proveedor y buscar todas las instancias de productos cuando recopile una lista de productos para cada proveedor Implementar solamente la direccin producto-a-proveedor y buscar todos los productos registrados cuando yo requiera recorrer la relacin en el sentido opuesto.
Proveedor 1..* Producto
Situacin 2: Solamente existen dos proveedores
VENS
VENS
Navegacin para Agregaciones

Una agregacin puede tambin ser unidireccional durante el diseo Un flecha se aade para la lnea de agregacin
Orden
1..*
OrdenItem
VENS
VENS
Perfeccionamiento de las Agregaciones
Una relacin de agregacin significa que el objeto fuente tiene que contener conocimiento semntico del objeto blanco o destino Las relaciones pueden ser de dos tipos:

Por referencia Por valor
VENS
VENS
Implicaciones por Valor y por Referencia
Por valor significa que los objetos se crean y se destruyen como una consecuencia de la creacin y destruccin 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 seleccin de por valor o por referencia determina cmo la creacin y la destruccin de los objetos ser diseada en C++
VENS
VENS
Relaciones por Referencia
Las relaciones por referencia denotan tiempos de vida independientes
Mostradas como un diamante no relleno
Catlogo 1..*
Curso
VENS
VENS
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 BotnOK
VentanaSeleccinCurso
BotnOK
VENS
VENS
Relaciones de Dependencia
Una relacin de dependencia significa que una clase depende de otras clases para algunos servicios Una relacin de dependencia se dibuja como una flecha de lneas discontinuas
Cliente
Servidor
Un objeto Cliente depende de un objeto Servidor
VENS
VENS
Relaciones de Dependencia (cont.)
Una relacin 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
VENS
VENS
Las Operaciones Crean Objetos de la Clase Servidor
RegistrationManager
process ()
#include BillingSystem.h void RegistrationManager::process(){ BillingSystem theInterface; }
BillingSystem
VENS
VENS
Objetos de la Clase Servidor como Argumentos de Operacin
TransactionManager
saveCourse (Course&)
Course
class Course; class TransationManager { public: void saveCourse(Course&); private: };
VENS
VENS
Visibilidad de los Objetos

Las relaciones proveen un camino para la comunicacin entre objetos Para que los objetos puedan hablar ellos tienen que estar visibles
La visibilidad de un objeto determina el diseo de una relacin
Yo puedo ver . . .
VENS
VENS
Opciones de Visibilidad de los Objetos
Hay cuatro opciones de visibilidad
Global
El objeto servidor es un objeto global

El objeto servidor es un parmetro a una operacin en el objeto cliente El objeto servidor es declarado localmente El objeto servidor es un campo en el objeto cliente
Parmetro
Local
Campo
VENS
VENS
Modelo de Anlisis
La operacin createCourse() de CurriculumController le pide al TransactionManager que salve un nuevo objeto Course Diagrama de Clase CurriculumController
createCourse ()
1
Diagrama de Colaboracin
: CurriculumController
1: saveCourse (Course)
1
TransactionManager
saveCourse (Course)
: TransactionManager
VENS
VENS
Diseo del Modelo -- Visibilidad Global
El objeto TransactionManager es declarado globalmente

1: saveCourse (Course) : CurriculumController
G
G
La visibilidad global conlleva a una relacin de dependencia TransactionManager CurriculumController

createCourse () saveCourse (Course&)
VENS
VENS
Visibilidad Global
static TransactionManager theManager; class CurriculumController { public: void createCourse(); }; class Course; void CurriculumController::createCourse() { Course *aNewCourse; theManager.saveCourse(aNewCourse); };
VENS
VENS
Diseo del Modelo -- Parmetro Visibilidad
El objeto TransactionManager es un parmetro para la operacin createCourse() del CurriculumController
El objeto TransactionManager es solamente visible a la operacin createCourse
P
G
El parmetro visibilidad conlleva a una relacin de dependencia CurriculumController TransactionManager

saveCourse (Course&)
createCourse (TransactionManager&)
VENS
VENS
Parmetro Visibilidad
class TransactionManager; class Course; class CurriculumController { public: void createCourse(TransactionManager&); }; void CurriculumController:: createCourse(TransactionManager& theManager) { Course *aNewCourse; theManager.saveCourse(aNewCourse); }
VENS
VENS
Diseo del Modelo -- Visibilidad Local
El objeto TransactionManager es declarado dentro de la operacin createCourse() de CurriculumController
El objeto TransactionManager es solamente visible a la operacin createCourse
L
G
La visibilidad local conlleva a una relacin de dependencia TransactionManager CurriculumController

createCourse () saveCourse (Course&)
VENS
VENS
Visibilidad Local
#include TransactionManager.h; class Course; class CurriculumController { public: void createCourse(); }; void CurriculumController::createCourse() { Course *aNewCourse; TransactionManager theManager; theManager.saveCourse(aNewCourse); }
VENS
VENS
Diseo 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
F
G
La visibilidad de campo conlleva a una relacin de asociacin (o de agregacin) TransactionManager CurriculumController

createCourse () saveCourse (Course)
VENS
VENS
Visibilidad de Campo
#include TransactionManager.h; class Course; class CurriculumController { public: void createCourse(); private: TransactionManager theManager; }; void CurriculumController::createCourse() { Course *aNewCourse;
theManager.saveCourse(aNewCourse); }
VENS
VENS
Ejemplo: Diseo de Relaciones

El CurriculumController es responsable de la administracin de la informacin 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 cmo salvar la informacin del curso pertinente. Cada curso puede tener entre 3 y 10 estudiantes matriculados y solamente un profesor. Un estudiante puede matricular hasta un mximo 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.
VENS
VENS
El Modelo antes del Diseo de la Relacin

CurriculumController 1
createCourse () 1 1
Course
1..* 1 3 0..4 3..10
Student
TransactionManager
1 saveCourse (Course) 1
DBCourse
save (Course)
Professor
VENS
VENS
Decisiones de Diseo
El CurriculumController usa al TransactionManager para cada curso que este administra
La operacin createCourse() no es la nica operacin para usar el TransactionManager
Se elige la visibilidad de campo
El CurriculumController enva mensajes hacia el TransactionManager pero el TransactionManager no enva ningn mensaje al CurriculumController
La relacin es unidireccional (de CurriculumController a TransactionManager)
VENS
VENS
Decisiones de Diseo (cont.)
El CurriculumController crea un nuevo curso dentro de la operacin createCourse
Es seleccionada la visibilidad local
La operacin saveCourse del TransactionManager es pasada al objeto Course
Es seleccionada la visibilidad de parmetro
El TransactionManager usa un objeto DBCourse para salvar un objeto Course
Esta es la nica operacin que requiere del objeto Course
Es seleccionada la visibilidad local
VENS
VENS
Decisiones de Diseo (cont.)
La operacin salvar de DBCourse se pasa al objeto Course
Se selecciona la visibilidad de parmetro Estos requerimientos no establecen que un Estudiante tenga que conocer sus cursos
Un Curso tiene que conocer sus estudiantes para generar el reporte
La relacin 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 relacin se produce unidireccionalmente
VENS
VENS
El Modelo despus del Diseo de la Relacin

CurriculumController
createCourse ()
Curso
Estudiante
3..10
TransactionManager
saveCourse (Course)
BDCurso
save (Course)
Profesor
1
VENS
VENS
Multiplicidad para las Relaciones
La multiplicidad es el nmero de instancias que participan en una asociacin Estimados iniciales de multiplicidad hechos durante el anlisis tienen que ser actualizados y refinados durante el diseo Todas las relaciones de asociacin y agregacin tienen que tener especificada la multiplicidad
VENS
VENS
Implementacin 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 class Professor; class Course { public: // public info private: Professor *teacher; };
Course
0..*
Professor
Teacher
VENS
VENS
Opcionalmente
Si un vnculo es opcional, una operacin para probar la existencia del vnculo debe ser incluida Por ejemplo, si un Profesor puede estar en sabtico, una operacin apropiada deber ser incluida en la clase Profesor para probar el vnculo Profesor dictando( ) 1 0..* Curso
VENS
VENS
Opciones de Diseo para Multiplicidad de ms de Uno
La multiplicidad de ms de uno es usualmente diseada usando clases contenedoras
Una clase contenedora es una clase cuyas instancias son colecciones de otros objetos Conjuntos, listas, diccionarios, pilas, colas,
Las clases contenedoras comunes incluyen:
Las clases contenedoras son frecuentemente clases parametrizadas las cuales se muestran como:
Item
Lista
VENS
VENS
Ejemplo de Clase Parametrizada

Item List
Course 1
StudentList
Student
#include List.h class Course { public: private: List<Student> students; }
VENS
VENS
Notacin para Clases Contenedoras
Para reducir la confusin en diagramas de clases extensos, las clases contenedoras no son mostradas tpicamente en los diagramas de clases Si el tipo de contenedor se requiere para la comunicacin, una nota puede ser usada Lista Curso
3..10
Estudiante
VENS
VENS
Clase Asociacin
Una clase asociacin contiene informacin que pertenece a un vnculo entre objetos y no a ningn objeto envuelto en la relacin
Curso 4 Calificacion nota 3..10
Estudiante
VENS
VENS
Diseando Clases Asociacin
Durante el diseo, las clases de asociacin evolucionan por:
La transformacin de la clase asociacin en una clase interpuesta entre las otras dos clases El establecimiento de asociaciones con multiplicidad adecuada entre la clase asociacin y las otras dos clases
La multiplicidad es siempre UNA clase de conexin a las clases vinculadas La navegacin puede ser bidireccional o unidireccional
Diseando las nuevas asociaciones
VENS
VENS
Diseando Clases de Asociacin (cont.)
Curso
1 3..10
Calificacion
nota 4 1
Estudiante
VENS
VENS
Ejercicio
Usando los escenarios y los diagramas de clases desarrollados
Discutir consideraciones del diseo de relaciones
Actualizar los diagramas de clases para mostrar las consideraciones de diseo de relaciones
VENS
VENS
Resumen: Diseando Relaciones
Durante el anlisis, las asociaciones y agregaciones son relaciones bidireccionales
Durante el diseo, ellas pueden convertirse en relaciones unidireccionales Por valor -- los objetos tienen tiempos de vida dependientes Por referencia -- los objetos tienen tiempos de vida independientes
Las asociaciones se disean en dos modos

Una relacin 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 diseo de las relaciones
VENS
VENS
Resumen: Diseando Relaciones (cont.)
Las opciones de visibilidad incluyen:
Visibilidad global -- el objeto est disponible globalmente
Visibilidad de Parmetro -- el objeto es un parmetro a un mtodo

Visibilidad local -- el objeto es declarado localmente Visibilidad de campo -- el objeto es parte de la estructura
Los punteros son tpicamente usados para implementar la multiplicidad de 1 o de 0..1

La multiplicidad de ms de uno es usualmente diseada usando clases contenedoras, tales como una Lista o Cola
Una clase contenedora es una clase cuyas instancias son colecciones de otros objetos
VENS

Uml Curso Teori Aistpcsr2077

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml Curso Teori Aistpcsr2077

Transféré par

Droits d'auteur :

Formats disponibles

VENS

ANLISIS Y DISEO ORIENTADO A OBJETOS con UML

Expositor: Ing. Ernesto Caldern Yarlequ Rernestocy@Hotmail.com

Ing. Ernesto Caldern Yarlequ

Objetivos del Curso

Crear una arquitectura de sistema lgica

Ing. Ernesto Caldern Yarlequ

Ing. Ernesto Caldern Yarlequ

Desarrollo iterativo e incremental

Comportamiento del sistema

Definicin de objetos, clases, estereotipos y paquetes

Interaccin entre Objetos

Encontrando las Clases

Dibujo del diagrama de clases

Definir estructura y comportamiento de clases

Ing. Ernesto Caldern Yarlequ

Comportamiento de los Objetos

Ing. Ernesto Caldern Yarlequ

Soporte de relaciones en C++

Diseo de Atributos y Operaciones

Diseo para Herencia

Soporte para herencia en C++

Resumen del curso de anlisis y diseo

Ing. Ernesto Caldern Yarlequ

Explicar la crisis del software

Discutir las fortalezas de la tecnologa de objetos

Ing. Ernesto Caldern Yarlequ

La Crisis del Software

El sistema fue abandonado sin ni siquiera haber sido usado

Ing. Ernesto Caldern Yarlequ

La Crisis del Software

En marzo de 1989, Arthur Andersen report

Cules son las razones para la crisis del software?

Fallas en el manejo del riesgo

Ing. Ernesto Caldern Yarlequ

Los requerimientos del negocio son ciclos de desarrollo ms cortos

Los usuarios esperan ms en trminos de flexibilidad

Los requerimientos iniciales usualmente estn mal definidos

Ing. Ernesto Caldern Yarlequ

Fallas en el Manejo de Riesgos

Ing. Ernesto Caldern Yarlequ

Ing. Ernesto Caldern Yarlequ

Fortalezas de la Tecnologa de Objetos

Un solo lenguaje usado por los usuarios, analistas, diseadores e implementadores

Un Simple Ejemplo de Ordenes de Compra

Ing. Ernesto Caldern Yarlequ

Diagrama de Clases para el Ejemplo de Ventas

Ing. Ernesto Caldern Yarlequ

Efecto del Cambio de Requerimientos

Ing. Ernesto Caldern Yarlequ

Cundo es Usado OO?

Sistemas basados en GUI

OO trata de facilitar el diseo e implementacin de sistemas con GUIs

Ing. Ernesto Caldern Yarlequ

Cundo Usar OO?

Ing. Ernesto Caldern Yarlequ

Cundo Usar OO?

Interfaz de objeto DB y aplicaciones existentes

Ing. Ernesto Caldern Yarlequ

Cundo es Usado OO?

Ing. Ernesto Caldern Yarlequ

Anlisis y Diseo Orientado a Objetos

Perspectiva del Usuario

Perspectiva del Desarrollador