Uml Curso Teori Aistpcsr

Ing. Ernesto Calderón Yarlequé

VENS

VENS

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS con UML

Expositor:


[email protected]


VENS

VENS

Público y Objetivos

Público al que va dirigido Cualquiera con la necesidad de aprender las capacidades y los

métodos de la tecnología orientada a objetos, especialmente aquellos involucrados con el desarrollo de sistemas complejos

Objetivos del Curso Luego de terminar el curso los participantes serán capaces de:

Explicar el proceso iterativo e incremental de desarrollo Definir los requerimientos del sistema desde el punto de vista del

usuario Crear un modelo orientado a objetos del comportamiento y

aspectos estructurales de los requerimientos del sistema Crear una arquitectura de sistema lógica Diseñar el sistema aplicando los conceptos de Abstracción,

encapsulamiento, herencia, polimorfismo y patrones


VENS

VENS

Tabla de Contenidos


VENS

VENS

Tabla de Contenido

Introducción Profundización en el análisis y diseño orientado a objetos usando

UML Desarrollo iterativo e incremental

Una visión del ciclo de vida de desarrollo de sistemas usando un modelo iterativo e incremental

Comportamiento del sistema Análisis del comportamiento necesario en un modelo orientado

por casos de uso Desarrollo de escenarios para los casos de uso

Objetos y Clases Definición de objetos, clases, estereotipos y paquetes


VENS

VENS

Tabla de Contenidos

Interacción entre Objetos Representación gráfica de un escenario

Encontrando las Clases Las aplicaciones del análisis por casos de uso para descubrir

clases en el sistema Definición de paquetes Dibujo del diagrama de clases

Relaciones Definir las relaciones necesarias para la interacción entre objetos

Operaciones y Atributos Definir estructura y comportamiento de clases


VENS

VENS

Tabla de Contenidos

Herencia Aplicaciones del principio de generalización y especialización

para descubrir relaciones superclases / subclases Comportamiento de los Objetos

Desarrollo de diagramas de transición de estados para mostrar gráficamente el comportamiento de un objeto

Homogenización Descubrimiento de mezclas de clases en diferentes casos de

usos Arquitectura

Discusión de las “4+1” vistas de la arquitectura


VENS

VENS

Tabla de Contenidos

Mecanismos claves Discusión de la estrategias de los mecanismo claves

Diseño de Clases Diseño de la interfaz del usuario Incorporación de patrones

Diseño de Relaciones Soporte de relaciones en C++

Diseño de Atributos y Operaciones Soporte para atributos y operaciones en C++

Diseño para Herencia Soporte para herencia en C++


VENS

VENS

Tabla de Contenidos

Resumen Resumen del curso de análisis y diseño Lecturas Bibliografía

Problema de sueldos Requerimientos para un sistema de sueldos

Problema de sueldos Análisis y diseño de soluciones para el problema de sueldos


VENS

VENS

Introducción

SI


VENS

VENS

Objetivos: Introducción

Ud. será capaz de: Explicar la crisis del software Discutir las fortalezas de la tecnología de objetos Discutir dónde la tecnología OO puede ser usada Definir análisis y diseño Explicar el origen de UML


VENS

VENS

Ejemplos extremos, PERO hay muchos desastres similares en una menor escala

Software failures reported by W. Wayt Gibbs in the September, 1994 issue of Scientific American

La Crisis del Software

El departamento de vehículos motorizados de California gastó más de $43 millones de dólares en un proyecto destinado a fusionar los sistemas de conductores y registro de vehículos

El sistema fue abandonado sin ni siquiera haber sido usado Un fallido esfuerzo de $165 millones de dólares de American Airlines de

vincular su software de reserva de pasajes con el sistema de reservaciones de Marriott, Hilton y Budget

El aeropuerto de Denver computarizó su sistema de equipaje, lo que resultó en millones de dólares perdidos por la demora en la apertura del aeropuerto


VENS

VENS

La Crisis del Software

En marzo de 1989, Arthur Andersen reportó Más de $300 mil millones al año son gastados en actividades de

software comercial en los Estados Unidos Sólo el 8% resulta en software que es distribuido y funciona

¿Cuáles son las razones para la crisis del software? Base inestable Fallas en el manejo del riesgo La complejidad del software


VENS

VENS

Base Inestable

Los requerimientos del negocio son ciclos de desarrollo más cortos Los usuarios esperan más en términos de flexibilidad

Los requerimientos iniciales usualmente están mal definidos


VENS

VENS

Fallas en el Manejo de Riesgos

EL ciclo de vida de cascada retrasa la identificación de problemas No hay pruebas de que el sistema funcionará hasta que está cerca de

ser terminado El resultado es de máximo riesgo


VENS

VENS

Complejidad de Software

La demanda del software de negocios se está incrementando Nadie entiende el sistema completo Los sistemas antiguos deben ser mantenidos, pero los desarrolladores

originales ya no están


VENS

VENS

Fortalezas de la Tecnología de Objetos

Un solo paradigma Un solo lenguaje usado por los usuarios, analistas, diseñadores e

implementadores Facilidad para elaborar la arquitectura y lograr el reutilización de código Los modelos reflejan mejor el mundo real

Mayor precisión describiendo datos corporativos y procesos Descomposición basada en divisiones naturales Fácil de entender y mantener

Estabilidad Un pequeño cambio en los requerimientos no significa cambios

masivos en el sistema en desarrollo


VENS

VENS

Un Simple Ejemplo de Ordenes de Compra

Orden

Item

Despacho via


VENS

VENS

Vendedor Producto

Venta

Empresa

Cliente

Persona Camión

Vehículo

Tren

Diagrama de Clases para el Ejemplo de Ventas


VENS

VENS

Efecto del Cambio de Requerimientos

Vendedor Producto

Venta

Empresa

Cliente

Persona Camión

Vehículo

Tren


VENS

VENS

¿Cuándo es Usado OO?

Sistemas basados en GUI OO trata de facilitar el diseño e implementación de sistemas con

GUIs


VENS

VENS

¿Cuándo Usar OO?

Sistemas empotrados Los métodos OO permiten desarrollar sistemas empotrados y de

tiempo real de alta calidad y flexibilidad


VENS

VENS

Plataformas PC

Estación de Trabajo

Interfaz de objetoDB y aplicaciones existentes

¿Cuándo Usar OO?

Computación Cliente/Servidor Los enfoques OO pueden encapsular información en objetos del

computador central, permitiendo la distribución de aplicaciones de pequeño tamaño


VENS

VENS

Software Existente Software de Re-ingeniería

¿Cuándo es Usado OO?

Re-ingeniería Los métodos OO permiten que se aplique re-ingeniería a partes

del sistema, protegiendo las inversiones en software existente


VENS

VENS

Análisis y Diseño Orientado a Objetos

OODAgregar detalles y

decisiones de diseño

Perspectiva del Desarrollador

OOAModelo de desarrollo de requerimientos

Perspectiva del Usuario


VENS

VENS

¿Qué es el Lenguaje de Modelado Unificado (UML)?

UML es descrito en The Unified Modeling Language for Object-Oriented Development, de Grady Booch, Jim Rumbaugh, e Ivar Jacobson

Disponible en http:\\www.rational.com Basado en las experiencias personales de los autores Incorpora contribuciones de otros metodologistas Co-presentado a la OMG por Rational Software, Microsoft, Hewlett-

Packard, Oracle, Texas Instruments, MCI Systemhouse y otros


VENS

VENS

Entradas a UML

Fusion

Descripción de operaciones,Numeración de mensajes

UML

Meyer

Condiciones de antes y después

Harel

Gráficos de estado

Wirfs-Brock

Responsabilidades

Embley

Clases Singleton,Visión de alto nivel

Odell

Clasificación

Shlaer - Mellor

Ciclo de vida del Objeto

Gamma, et.al

Marcos, diseños,notas

Booch

JacobsonRumbaugh


VENS

VENS

Evolución de UML

Industrialización

Estandarización

Unificación

Fragmentación

Booch ´91

Booch ´93

Unified Method 0.8

UML 1.0

OMT - 2

OMT - 1 OOSE

UML 0.9 & 0.91

OOPSLA ´95

Junio ´96 & Oct ´96

Envio a la OMGpara adopción, Julio ´97

Otros métodos

Feedbackpúblico

Publicación delEstandar 1.0 Dic ´96

UML PartnersExpertise

UML 1.1


VENS

VENS

Beneficios del Lenguaje de Modelado Unificado

Define un mapa parecido para el análisis y el diseño de implementaciones

Define una notación expresiva y consistente Hace más fácil el comunicarse con otros Ayuda a detectar omisiones e inconsistencias Permite análisis y diseño a pequeña y gran escala


VENS

VENS

Resumen: Introducción Nuevas técnicas de desarrollo son necesarias para mitigar la crisis del

software Los requerimientos no son estables El software se ha vuelto muy complejo Los clientes demandan flexibilidad

La tecnología de Objetos tiene muchos puntos fuertes Un solo paradigma Los modelos reflejan el mundo real Facilitan la arquitectura y el reuso de código Provee gran flexibilidad

Un pequeño cambio en los requerimientos no significa cambios masivos en el sistema en desarrollo


VENS

VENS

Resumen: Introducción (cont.)

OO está siendo usado para diferentes tipos de sistemas Basados en GUI, empotrados, computación cliente/servidor, y re-

ingeniería El análisis orientado a objeto es un método de análisis en el cual los

requerimientos son expresados en términos de los objetos encontrados en el problema

Enfocado en el QUE En el diseño orientado a objetos el modelo de análisis es transformado

en un modelo de diseño por medio de la refinación de éste, agregando detalles y capturando las decisiones de diseño necesarias para implementar el modelo

Enfocado en el COMO


VENS

VENS

Resumen: Introducción (cont.)

El Lenguaje de Modelado Unificado (UML por sus siglas en inglés) fue desarrollado por Grady Booch, Jim Rumbaugh, e Ivar Jacobson en colaboración con un número de otros colaboradores, basados en sus experiencias colectivas.


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 cómo documentar casos de uso Usar un diagrama de caso de uso para mostrar los actores, los casos

de uso, y sus interacciones Definir los escenarios para los casos de uso


VENS

VENS

¿Qué es el comportamiento del sistema?

El comportamiento de un sistema es cómo un sistema actúa y reacciona

La actividad exterior visible y “testeable” de un sistema El comportamiento del sistema es capturado en los casos de uso

Ellos describen el sistema, su ambiente, y la relación entre el sistema y su ambiente


VENS

VENS

Actor

Use-Case

Conceptos importantes al modelar el caso de uso

Un actor representa cualquier cosa que interactúe con él sistema

Un caso de uso es una secuencia de acciones que un sistema realiza, que produce un resultado observable de valor para un agente


VENS

VENS

El propósito primario del modelo caso de uso es comunicar las funcionesy el comportamiento del sistema al cliente o al usuario final

El propósito primario del modelo caso de uso es comunicar las funcionesy el comportamiento del sistema al cliente o al usuario final

¿Qué es un modelo de Caso de Uso?

Un modelo de caso de uso es un modelo de las funciones previstas del sistema (casos de uso) y su entorno (actores)

El mismo modelo de caso de uso es usado en análisis de requisitos, diseño y prueba


VENS

VENS

Beneficios del modelo de Casos de Usos

El modelo de casos de usos Es usado para comunicarse con el usuario final y el experto del

dominio Proporciona credibilidad en una etapa inicial del desarrollo

del sistema Asegura una comprensión mutua de los requisitos

Es usado para identificar Quién interactuará con el sistema y qué deberá hacer el

sistema Qué interfaz deberá tener el sistema

Es usado para verificar que: Se capturan todos los requisitos Que los desarrolladores hayan entendido los requisitos


VENS

VENS

Actores

Los actores no son parte del sistema, ellos representan roles que un usuario del sistema puede desempeñar

Un actor puede intercambiar activamente la información con el sistema

Un actor puede ser un recipiente pasivo de la información

Un actor puede representar a un humano, una máquina u otro sistema

Actor


VENS

VENS

Encontrando Actores: Preguntas Útiles

¿Quién está interesado en cierto requisito? ¿Dónde en la organización se utilizará el sistema? ¿Quién proveerá, utilizará y eliminará esta información del sistema? ¿Quién utilizará esta función? ¿Quién le dará soporte y mantenimiento al sistema? ¿Usa el sistema un recurso externo? ¿Qué actores necesita el caso de uso? ¿Un actor desempeña varios roles? ¿Varios agentes desempeñan el mismo rol?


VENS

VENS

Instancias de Actores

1 2 34 5 67 8 9* 0 #

Insert card

Ivar actúacomo unactor

Tom actúacomo unactor

Modelo de Caso de uso

Actor Caso de uso


VENS

VENS

Un usuario puede actuar como varios actores

1 2 34 5 67 8 9* 0 #

Insert cardCharlie como

operador

Cliente

Operador

Charlie comocliente

Charlie


VENS

VENS

Límites de los actores y del sistema

MantenimientoATM

CajeroBancario

¿Límite del Sistema?

Sistema ATM

Sistema Bancario


VENS

VENS

Casos de Uso

Un caso de uso modela un diálogo entre los actores y el sistema

Un caso de uso puede ser iniciado por un actor para invocar una cierta funcionalidad en el sistema

Un caso de uso es un flujo de eventos completos y significativos

Tomados al mismo tiempo, todos los casos de uso constituyen todas las formas posibles de utilizar el sistema

Caso de Uso


VENS

VENS

Encontrando Casos de Uso: Preguntas Útiles

¿Cuáles son las tareas de este actor? ¿El actor, creará, guardará, cambiará, eliminará o leerá la información

en el sistema? ¿Cuál caso de uso creará, guardará, cambiará, eliminará o leerá esta

información? ¿Necesitará el actor informar al sistema sobre cambios externos e

imprevistos? ¿Es necesario que el actor esté informado sobre ciertas ocurrencias en

el sistema? ¿Le proporciona una correcta secuencia el sistema a las tareas? ¿Cuáles casos de uso le darán soporte y mantenimiento al sistema? ¿Pueden todos los requerimientos funcionales ser realizados por los

casos de uso?


VENS

VENS

Fuentes de Información para Casos de Uso

Especificaciones del sistema / Manifestación del problema Literatura relevante del dominio Entrevistas con expertos del dominio Conocimiento personal del dominio Sistema heredados


VENS

VENS

Cliente

Realizar Transacciones

ATM Mantenimiento

Mantener maquina ATM

Realiza reportes

Banco

El Diagrama de Caso de Uso Un diagrama de un caso de uso ilustra como los casos de uso y los

actores interactúan, enviándose estímulos entre ellos


VENS

VENS

Documentación de Caso de Uso

Los casos de uso están documentados en Una breve descripción

El propósito del caso de uso en unas pocas líneas Flujo de eventos detallados

Descripción del flujo de eventos primario y alternativos que ocurren cuando el caso de uso es iniciado

La documentación debe leerse como un diálogo entre el actor y el caso de uso

Ambos documentos están escritos en términos que el cliente entenderá


VENS

VENS

Flujo de Eventos Caso de Uso

Cada caso de uso Tiene una secuencia de transacciones normal y básica Puede tener varias secuencias de transacciones alternativas Generalmente tiene varias secuencias de transacciones

excepcionales, las cuales manejan situaciones de error También puede tener pre y post condiciones bien definidas


VENS

VENS

Flujo de Eventos Caso de Uso (cont.)

Describe solamente los eventos que pertenecen al caso de uso, y no los que suceden en otros casos de uso

Evita terminología vaga tal como “por ejemplo”, “etc.” e “información”. El flujo de eventos debe describir:

Cómo y cuándo comienza y termina el caso de uso Cuándo el caso de uso interactúa con los actores Qué información se intercambia entre un actor y el caso de uso

No describe los detalles de la interfaz del usuario El flujo de eventos básico Cualquier flujo de eventos alternativo


VENS

VENS

¿Quién Lee la Documentación de Casos de Uso?

Clientes -- aprueban lo que debe hacer el sistema

Usuarios -- obtienen comprensión del sistema

Desarrolladores del Sistema -- documentan el comportamiento del sistema

Revisores --examinan el flujo de eventos Analistas del Sistema (Diseñadores) --

proveen la base para un análisis y diseño “Probador” del Sistema -- usado como

base para casos de prueba Líder de Proyecto -- provee entradas para

el planeamiento de proyectos Escritor Técnico -- base para escribir la

guía del usuario


VENS

VENS

Ejemplo de Registro en Curso

Al comienzo de cada semestre, los estudiantes pueden requerir información de un catálogo de cursos, el cual contiene una lista de los cursos ofrecidos para el semestre, indicando para cada curso profesor, departamento y prerequisitos. Información que es incluida para ayudar a los estudiantes a tomar decisiones.

El nuevo sistema permitirá a los estudiantes seleccionar cuatro cursos para el siguiente semestre. Además, cada estudiante podrá indicar dos cursos alternativos en caso de no poder ser asignado en su primera selección. El curso tendrá un máximo de diez estudiantes y un mínimo de tres. Un curso con menos de tres estudiantes será cancelado. Una vez que el proceso de registro es completado , el sistema de registro envía la información al sistema de cobranzas, para que al estudiante le puedan cobrar por el semestre.


VENS

VENS

Ejemplo de Registro en Curso (cont.)

Los profesores deben ser capaces de acceder al sistema on-line para indicar qué cursos estarán enseñando. También necesitarán ver qué estudiantes se inscribieron para sus cursos.

Para cada semestre, existe un período de tiempo en el que los estudiantes pueden modificar sus horarios. Los estudiantes deben ser capaces de acceder el sistema durante este tiempo para agregar o retirarse de cursos.


VENS

VENS

Diagrama de un Caso de Uso

Estudiante

Sistema de Cobranzas Registrar

Cursos a tomar

Solicitar lista de Curso

Seleccionar Cursos a enseñar

Profesor

Mantener Info de estudiante

MantenerInfo del Profesor Mantener Información de

Curso

Generar Catálogo

Registrador


VENS

VENS

Breve Descripción -- Registrar Cursos a Tomar

1.1 Breve Descripción

Este caso de uso es iniciado por un estudiante. Le entrega al estudiante la capacidad de crear, borrar, modificar y/o revisar un programa de cursos para un semestre dado.


VENS

VENS

Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar2.1 Pre-condiciones

Ninguna2.2 Flujo principal

Este caso de uso comienza cuando el estudiante ingresa el número de alumno. El sistema verifica que éste sea válido (E-1) y le lleva al estudiante a seleccionar el semestre actual o un semestre a futuro (E-2). El estudiante ingresa el semestre deseado. El sistema le indica al estudiante que elija la actividad deseada: CREAR, REVISAR, MODIFICAR, IMPRIMIR, BORRAR, o ABANDONAR.Si la actividad seleccionada es

CREAR, el A-1: Se ejecuta un subflujo de Crear un Nuevo Programa .

REVISAR, el A-2: Se ejecuta un subflujo de Revisar un Programa .

MODIFICAR, el A-3: Se ejecuta un subflujo de Modificar un Programa .

IMPRIMIR, el A-4: Se ejecuta un subflujo de Imprimir un Programa.

BORRAR, el A-5: Se ejecuta un subflujo de Borrar un Programa .ABANDONAR, el caso de uso termina.


VENS

VENS

Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar(cont.)

2.3 Flujos alternativosA-1: Crear un nuevo Programa El sistema muestra en la pantalla un programa en blanco. El estudiante

ingresa el número de cuatro ofrecimientos de cursos primarios y dos números de cursos alternativos (E-3). El estudiante entonces presenta su petición de cursos. Por cada selección primaria de curso el sistema revisará que los pre-requisitos sean cumplidos (E-4) y agregará al estudiante al curso, si éste está abierto (E-5). El sistema imprimirá el programa (E-6) y enviará la información de la cuenta al sistema de cuenta para ser procesada (E-7). Luego el caso de uso comienza de nuevo.

A-2: Revisar un programa El sistema recupera la información de todos los cursos ofrecidos en los que

el estudiante se encontraba registrado (E-8) y muestra lo siguiente : nombre del curso, número del curso, números de los cursos ofrecidos, días de la semana, hora, ubicación y número de horas de créditos. Cuándo el usuario indica que él / ella ya ha terminado la revisión, el caso de uso comienza nuevamente.


VENS

VENS

Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar (cont.)

A-3: Modificar un programaEl sistema revisa que no haya sido excedida la fecha final para los cambios

(E-9). El sistema recupera la información anterior de todos los ofrecimientos de curso en los cuales el estudiante se encontraba registrado (E-8) y muestra en la pantalla: nombre del curso, número del curso, número de los cursos ofrecidos, días de la semana, hora, ubicación y número de horas de créditos. El sistema le indica al usuario que seleccione la actividad deseada: BORRAR UN CURSO OFRECIDO, AGREGAR UN CURSO OFRECIDO, o ABANDONAR.

Si la actividad seleccionada es BORRAR UN CURSO OFRECIDO, el A-6: Se ejecuta un subflujo

de borrar un curso ofrecido.AGREGAR UN CURSO OFRECIDO, el A-7: Se ejecuta el

subflujo de agregar un curso ofrecido.ABANDONAR, el sistema imprime el programa al estudiante (E-6)

y el caso de uso vuelve a comenzar.


VENS

VENS

Flujo de Eventos -- Caso de Uso Registrar Cursos a Tomar(cont.)

A-4: Imprimir un programaEl sistema imprime el programa (E-6). El caso de uso comienza de nuevo.

A-5: Borrar un programaEl sistema recupera información (E-8) y muestra el programa actual. El

sistema pide al usuario que confirme la opción de borrar programa. Si es aceptada, se elimina el programa del sistema. Si el borrar no se confirma, la operación es cancelada y el caso de uso comienza de nuevo.

A-6: Borrar un curso ofrecidoEl estudiante ingresa el número del ofrecimiento a borrar. El sistema pide al

usuario que confirme esta opción de borrar el curso ofrecido. Si es aceptada, el curso ofrecido es eliminado del programa del estudiante. Si el borrar no es confirmado, la operación es cancelada y el flujo alternativo del caso de uso comienza de nuevo.


VENS

VENS

Flujo de Eventos -- Caso de Uso Registro en Cursos (cont.)

A-7: Agregar un curso ofrecidoEl estudiante ingresa el curso a agregar. El sistema revisará que se

cumplan los pre-requisitos (E-4) y agregará el estudiante al curso ofrecido, si éste se encuentra abierto (E-5). El flujo alternativo de caso de uso comienza de nuevo.

E-1: Excepciones de flujosE-1: Se ingresa un número de alumno no válido. El usuario puede re-

ingresar un número de alumno o terminar el caso de uso.E-2: Se ingresa un semestre no válido. El usuario puede re-ingresar un

semestre o terminar el caso de uso.E-3: El número del ofrecimiento de curso no es válido (rango). El usuario

puede re-ingresar un número válido o terminar el caso de uso.E-4: El usuario no satisface todos los pre-requisitos requeridos. El usuario es informado de por qué este curso no podrá ser programado. Si es posible, se sustituye por un curso alternativo. El caso de uso continúa.


VENS

VENS

Flujo de Eventos -- Caso de Uso Registro en Cursos (cont.)

E-5: El usuario es informado que el ofrecimiento de curso seleccionado está cerrado. Si es posible, se sustituye por un curso alternativo. El caso de uso continúa.

E-6: El programa no puede ser impreso. La información está guardada y el usuario es informado de que debe volver a presentar una solicitud de imprimir programa. El caso de uso continúa. E-7: El sistema guardará toda la información de cuentas de pago y la volverá a presentar al sistema de cuentas en una próxima fecha. El caso de uso continúa.

E-8: El sistema no puede recuperar información de un programa. El caso de uso, entonces, comienza desde el principio.

E-9: El sistema le informa al usuario que su programa no puede ser modificado. Entonces el caso de uso comenzará desde el principio.


VENS

VENS

¿Qué son Escenarios?

Un escenario es una instancia de un caso de uso es un solo flujo a través de un caso de uso

Cada caso de uso tendrá una red de escenarios Escenarios primarios

Flujo normal - la forma en la que el sistema debiese funcionar

Escenarios secundarios Excepciones al escenario primario


VENS

VENS

Un Escenario para el Caso de Uso “Registrar Cursos a Tomar”

John ingresa su número de alumno 369 52 3449 y el sistema valida el número. El sistema pregunta por cuál semestre. John indica el semestre actual y elige crear un nuevo programa.

De una lista de cursos disponibles, John selecciona los cursos primarios Inglés 101, Geología 110, Historia Mundial 200, y Álgebra 110. Luego selecciona los cursos alternativos de Teoría de la Música 110 e Introducción a Programación Java 180.

El sistema determina que John cumple con todos los pre-requisitos necesarios y lo agrega a la lista de cursos.

El sistema indica que la actividad está completa. El sistema imprime el programa al estudiante y envía la información de cuenta de pago de cuatro cursos al sistema de cuenta para ser procesada.


VENS

VENS

Escenarios Secundarios

¿Cuáles 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 están disponibles No es posible agregar al estudiante a la lista de curso No se puede crear el programa del estudiante


VENS

VENS

¿Cuántos Escenarios se necesitan?

Respuesta simple: tantos como sea necesario para entender el funcionamiento del sistema.

Regla del pulgar: Escenarios primarios

Elabore aproximadamente el 80% de estos escenarios Escenarios secundarios

Elabore unos pocos de los escenarios secundarios interesantes y de alto riesgo.


VENS

VENS

Ejercicio: Comportamiento del Sistema

Utilizando el problema entregado por el instructor Dibuje un diagrama de caso de uso Escriba una definición para cada actor Para un caso de uso

Escriba una breve descripción (dos oraciones máximo) Escriba el flujo de eventos Enumere algunos posibles escenarios


VENS

VENS

Resumen: Comportamiento del Sistema

El comportamiento de un sistema es cómo éste actúa y reacciona El comportamiento de un sistema puede ser caracterizado por un

conjunto de casos de uso Un caso de uso es una cierta funcionalidad que se ejecuta por el

sistema en respuesta a un estímulo proveniente de un actor externo Ellos proveen un vehículo de captura para los requerimientos

sobre un sistema desde el punto de vista del usuario Un actor es alguien o algo que se debe acoplar con el sistema en

desarrollo Un diagrama de un caso de uso es una representación gráfica del

sistema el cual muestra los actores y casos de uso identificados para el sistema

La documentación de un caso de uso consiste en una breve descripción y en un flujo de eventos


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 relación entre clases y objetos Definir estereotipos


VENS

VENS

Informalmente, un objeto representa una entidad, física, conceptual o programa

Entidad física

Entidad conceptual

Entidad programa

Camión

Proceso Químico

Lista Enlazada

¿Qué es un Objeto?


VENS

VENS

Una Definición Formal

Un objeto es un concepto, una abstracción o una cosa con límites bien definidas y significado para una aplicación

Un objeto es algo que tiene: Estado Comportamiento Identidad


VENS

VENS

Nombre: Joyce ClarkNº Empleado: 567138Fecha de Contr.: 21 de marzo 1987Estado: Adjunto

Profesor Clark

a + b = 10

Un Objeto Tiene Estado

El estado de un objeto es una de las posibles condiciones en que el objeto puede existir

El estado normalmente cambia en el transcurso del tiempo El estado de un objeto es implementado por un conjunto de

propiedades (llamadas atributos), con los valores de las propiedades, además de las conexiones que deben tener con otros objetos


VENS

VENS

Curso Algebra 101

Asignar profesor (Clark)

(Retorna:confirmación) Registro del

Sistema

a + b = 10

Un Objeto Tiene Comportamiento

El comportamiento de un objeto determina cómo éste actúa y reacciona frente a las peticiones de otros objetos

El comportamiento de un objeto es modelado por un conjunto de mensajes a los que puede responder (las operaciones que el objeto puede realizar)


VENS

VENS

Profesor “J Clark”enseña Algebra



Un Objeto tiene Identidad

Cada objeto tiene una identidad única, incluso si su estado es idéntico al de otro objeto


VENS

VENS

¿Qué son las Clases?

Hay muchos objetos identificados para cada dominio Una clase es una descripción de un grupo de objetos con

propiedades en común (atributos), comportamiento similar (operaciones), la misma manera de relacionarse entre objetos (asociaciones y agregados) y una semántica en común

Un objeto es una instancia de una clase Una clase es una abstracción en que:

Se enfatizan las características relevantes Se suprimen otras características

La abstracción nos ayuda a trabajar con cosas complejas


VENS

VENS

Ejemplo de una Clase

a + b = 10

ClaseCurso

EstructuraNombre

UbicaciónDías ofrecidos

CréditosHora de inicio

Hora de término

ComportamientoAgregar un alumnoBorrar un alumno

Entregar una lista del cursoDeterminar si está lleno


VENS

VENS

Clases y Objetos

¿Cuántas clases ve?


VENS

VENS

ObjetosProfesor

Profesor Smith

Profesor Jones

Profesor Mellon

La Relación Entre Clases y Objetos Una clase es una definición abstracta de un objeto

Define la estructura y el comportamiento compartidos por los objetos

Sirve como modelo para la creación de objetos Los objetos pueden ser agrupados en clases


VENS

VENS

Algebra 101Historia ArteQuímicaEspañol 101

Encontrando Clases

Una clase debe capturar una y solo una abstracción clave Mala abstracción: La clase estudiante que conoce la información

del estudiante y el programa del semestre actual del estudiante Buena abstracción: Clases separadas. Una para el estudiante y

otra programas del estudiante


VENS

VENS

Asignando Nombre a una Clase

El nombre de la clase debe ser el sustantivo singular que mejor caracterice la abstracción

La dificultad al nombrar la clase revela una pobre definición de la abstracción

Los nombres deben provenir directamente del vocabulario del dominio


VENS

VENS

Guía de estilo en el nombramiento de clases

Una guía de estilo debe dictar convenciones para el nombramiento de clases

Ejemplo de guía de estilo Las clases son nombradas usando sustantivos

singulares Los nombres de las clases comienzan con letra

mayúscula No se usa el subrayado

Los nombres compuestos por múltiples palabras se ponen juntos y la primera letra de cada palabra se escribe con mayúscula

Ejemplo: Estudiante, Profesor, Sistema De Pago


VENS

VENS

Fijarse en los “QUE” e ignorar los “COMO”Fijarse en los “QUE” e ignorar los “COMO”

Definiendo la Semántica de las Clases

Después de nombrar las clases, debe hacerse un informe descriptivo conciso

Concentrarse en el propósito de la clase, no en su implementación

El nombre y la descripción de la clase sirven como base para un modelo de diccionario


VENS

VENS

Mientras más se descubre del problema, se refina la definición de la clase y se agregan nuevas clases al modelo de diccionario

Mientras más se descubre del problema, se refina la definición de la clase y se agregan nuevas clases al modelo de diccionario

Muestra de las Entradas de un Modelo de Diccionario

Nombre: InformaciónDelEstudiante Definición: Información de una persona registrada

para asistir a clases en la universidad Nombre: Curso

Definición: Una clase ofrecida por la universidad


VENS

VENS

Profesor

Profesor Clark

a + b = 10

Representando Clases

Una clase es representada usando un compartimiento rectangular


VENS

VENS

Profesor

nombreempID

crear( )grabar( )borrar( )cambiar( )

Profesor

nombreempID

Profesor

crear( )grabar( )borrar( )cambiar( )

Profesor

Profesor

Compartimientos en la representación grafica de una clase Una clase está compuesta de tres secciones

La primera sección contiene el nombre de la clase La segunda sección muestra la estructura (atributos) La tercera sección muestra el comportamiento

(operaciones) La segunda y la tercera sección pueden ser suprimidas si

se necesita que no se vean en el diagrama


VENS

VENS

Estereotipos

Un estereotipo es un nuevo tipo de elemento de modelado que extiende la semántica del metamodelo

Deben estar basados en tipos o clases existentes en el metamodelo

Cada clase debe tener al menos un estereotipo Estereotipos comunes

Clase Frontera Clase Entidad Clase Control Clase Excepción Clase Utilidad

Los estereotipos son mostrados en el compartimiento del nombre de la clase encerrados entre << >>


VENS

VENS

FormularioPrograma<<Boundary>>

Clase Frontera

Una clase frontera modela la comunicación entre el entorno del sistema y su funcionamiento interno

Clases interfaz típicas Windows (interfase del usuario) Protocolo de comunicación (interfase del sistema) Interfase de la impresora Sensores

En el escenario del “Registrar Cursos a Tomar”, un Formulario programa es creado para aceptar la información del usuario


VENS

VENS

<<Boundary>>Sistema Cobranza

Interfaces con Otros Sistemas Una clase frontera también es usada para modelar una interfaz a

otro sistema Las características importantes de este tipo de clases frontera

son: La información que debe ser entregada al otro sistema El protocolo de comunicación usado para “hablarle” al otro

sistema En el escenario del “Registro de Cursos” , la información debe

ser enviada al Sistema Cobranza externo Una clase llamada Sistema Cobranza es creada para

sostener la interfaz con el sistema externo


VENS

VENS

Una clase entidad modela información y asocia comportamientos que generalmente son de larga duración (persistentes)

Puede reflejar un fenómeno de la vida real También puede ser necesitada por la tarea interna del

sistema Los valores de estos atributos normalmente son entregados

por un actor El comportamiento es independiente del entorno

Las clases entidades en el caso de uso “Registro de Cursos”: Curso Programa Catálogo ListaCursos

Programa<<entity >>

ListaCursos<<entity>>

Catalogo<<entity >>

Curso<<entity >>

Clase Entidad


VENS

VENS

<<control>>AdministradorDeRegistro

Clase Control Una clase control modela el comportamiento especifico de uno o

más casos de usos La clase control

Crea, inicializa y borra objetos controlados Controla la secuencia o coordina la ejecución de los objetos

controlados Controla asuntos concurrentes para las clases controladas Es usualmente la implementación de un objeto intangible

En el escenario del “Registro de Cursos”, la clase AdministradorDeRegistro controla los procesos de registro


VENS

VENS

Resumen: Objetos y Clases

Un objeto es algo que tiene estado, comportamiento e identidad

El estado de un objeto es una de las condiciones posibles en las que el objeto puede existir

El comportamiento determina cómo un objeto actúa y reacciona a los requerimientos de otros objetos

Cada objeto tiene una entidad única -- incluso si su estado es idéntico al de otro objeto

Una clase es una definición abstracta de un conjunto de objetos que tienen una estructura y un comportamiento común

A las clases se les debe dar por nombre la palabra que mejor caracterice su abstracción


VENS

VENS

Resumen: Objetos y Clases (cont.)

Las clases se representan como un compartimiento rectangular El primer compartimiento contiene el nombre de la clase El segundo compartimiento muestra su estructura (atributos) El tercer compartimiento muestra su comportamiento

(operaciones) Un estereotipo representa la clasificación de la clase

Toda clase debe tener al menos un estereotipo Estereotipos comunes: interfaz, entidad, control, excepción,

metaclase y utilidad La clase interfaz modela la comunicación entre el entorno del sistema

y su trabajo interno La clase entidad modela la información y el comportamiento asociado

que debe ser almacenado La clase control modela el control del comportamiento específico de

uno o más casos de usos


VENS

VENS

Interacciones de Objetos


VENS

VENS

Objetivos: Interacciones de Objetos

Usted será capaz de: Utilizar diagramas de secuencia y de colaboración para mostrar las

interacciones entre los objetos.


VENS

VENS

¿Qué son los Diagramas de Interacción?

Un diagrama de interacción es una representación gráfica de interacciones entre objetos

Existen dos tipos de diagramas de interacción Diagramas de secuencia Diagramas de colaboración

Cada uno entrega un punto de vista distinto de la misma interacción Los diagramas de secuencia son ordenados en el tiempo Los diagramas de colaboración pueden incluir flujo de datos


VENS

VENS

¿Qué es un Diagrama de Secuencia?

Un diagrama de secuencia muestra las interacciones de objetos ordenadas en una secuencia de tiempo

El diagrama muestra Los objetos participando en la interacción La secuencia de mensajes intercambiados

Un diagrama de secuencia contiene: Objetos con sus “líneas de vida” Mensajes intercambiados entre objetos en una secuencia

ordenada Linea de Vida Activa (opcional)


VENS

VENS

Un Diagrama de Secuencia

John : Estudiante

FormularioRegistro

Cursos Disponibles

Formulario Programa

1: ingresar id

2: validar id

3: ingresar semestre actual

4: crear un nuevo programa

5: mostrar

6: obtener cursos


VENS

VENS

cursosdisponibles

cursosdisponibles: Catálogo

: Catálogo

Object only Class onlyObject and Class

Nombrando Objetos en Diagramas de Secuencia

Los objetos son dibujados como rectángulos con nombres subrayados

Las “líneas de vida” de los objetos están representadas por líneas rayadas en descenso


VENS

VENS

Formularioprograma

Obtener cursos

Cursos disponible

Mostrando la Interacción entre Objetos

La interacción de objetos está indicada por flechas horizontales las cuales son dirigidas desde la línea vertical representada por el objeto cliente a la línea representada por el objeto proveedor

Las flechas horizontales están etiquetadas con mensajes El orden de los mensajes con respecto al tiempo, está indicado por la

posición vertical. Enumerar las flechas horizontales es opcional ya que el orden está

basado en la posición vertical


VENS

VENS

¿Qué es Activación?

Una activación es el tiempo relativo en el que el flujo de control está enfocado en un objeto

Representa el tiempo en el que un objeto espera una respuesta a un mensaje enviado

La activación puede ser mostrado en un diagrama de secuencia mediante una línea de vida activa


VENS

VENS

Enfoque de Control

John : Estudiante

formulario Registro

formulario programa

cursosdisponibles

1: ingresar id2: validar id

3: ingresar semestre actual

4: crear nuevo programa5: mostrar

6: obtener cursos


VENS

VENS

Formulario programa

obtener cursos

cursos disponibles

Cursos disponibles Para el semestre

Notas

Las notas pueden agregar más información al diagrama


VENS

VENS

Libretos para Diagramas de Secuencia

Para escenarios complejos, los diagramas de secuencia pueden ser mejorados por medio del uso de libretos

Un libreto está escrito hacia la izquierda de un diagrama de secuencia con los pasos del libreto alineados con las interacciones de los objetos

Los libretos pueden ser escritos en lenguaje natural o pseudo códigos


VENS

VENS

Ejemplo de Libreto

Procesar los cursos primariosprimero, usando sólo los cursosalternativos si es necesario

Formulario Programa

Obtener pre-requisito

unCurso


VENS

VENS

Diagramas de Colaboración

Un diagrama de colaboración es una manera alternativa de representar mensajes intercambiados por un conjunto de objetos

El diagrama muestra interacciones organizadas alrededor de los objetos y las conexiones entre ellos

Un diagrama de colaboración contiene: Objetos Conexiones entre objetos Mensajes intercambiados entre objetos Datos fluyendo entre objetos, si los hubiera


VENS

VENS

Ejemplo de Diagrama de Colaboración

John : Student

registration form

schedule formavailable classes

1: enter id

2: validate id

3: enter current semester

4: create new schedule5: display

6: get courses


VENS

VENS

Inglés101

Inglés 101:Curso

:Curso

Object only Class onlyObject and Class

Representando Objetos en un Diagrama de Colaboración

Los objetos son dibujados como rectángulos con nombres subrayados


VENS

VENS

Formulario programa : Form Un curso : Curso

Representando Conexiones en un Diagrama de Colaboración

Una conexión en un diagrama de colaboración se representa como una línea que une íconos de objetos

Una conexión indica que existe un camino para establecer una comunicación entre los objetos conectados


VENS

VENS

Mensajes entre objetos

Una de conexión en un diagrama de colaboración puede mostar los mensajes enviados entre los objetos.

Un mensaje se representa con una flecha apuntando desde el objeto cliente a el objeto proveedor

El nombre del mensaje con una lista opcional de parámetros y/o un valor de retorno

Un número de secuencia opcional que muestra el orden relativo en el cual los mensajes son enviados


VENS

VENS

Notación de conexiones

Formulario programa : Form Un curso : Curso

Supplier object

Message

points from client to supplier

Client object

Data return

1: obtener pre-requisitos

2: obtener cursos

Lista de curso

Objeto

Mensaje

Mensaje

Objetoconexión


VENS

VENS

Resumen: Interacción entre Objetos

La interacción de objetos puede ser representada gráficamente en un diagrama de secuencia, el cual muestra la existencia de objetos y las interacciones entre los objetos identificados

Los objetos son representados por rectángulos con sus nombres subrayados

Una “línea de vida” de un objeto es representadas por una línea rayadas vertical descendiendo del objeto

Los mensajes están indicados por flechas horizontales las cuales están dirigidas desde el objeto cliente (emisor) al objeto proveedor (receptor)

Las flechas horizontales están etiquetadas con el nombre del mensaje

Un libreto opcional puede ser agregado para mostrar más detalles al diagrama


VENS

VENS

Resumen: Interacción entre Objetos (cont.)

Un diagrama de colaboración es una representación gráfica alternativa de interacciones de objetos

Los objetos se representan con rectángulos Una interacción de conexión (línea) se dibuja entre objetos que

se comunican La conexión se anota con una flecha que contiene el

nombre del mensaje que apunta desde el objeto cliente a el objeto proveedor

La conexión puede también ser anotada con una flecha de retorno de datos


VENS

VENS

Encontrando Clases


VENS

VENS

Objetivos: Encontrando Clases

Será capaz de: Discutir el análisis de casos de uso Encontrar objetos y clases mediante el análisis de casos de uso Usar cartas CRC para descubrir clases Dibujar un escenario usando diagramas de interacción Crear paquetes Crear diagramas de clase


VENS

VENS

¿Qué es el Análisis de Casos de Uso?

El análisis de casos de uso es el proceso de examinar los casos de uso para descubrir objetos y clases, para el sistema que está siendo desarrollado

Los escenarios son detallados y mostrados gráficamente en diagramas de interacción

Se crean las entidades, las interfaces y las clases de control

Las clases son agrupadas en paquetes Se creados los diagramas de clases


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 términos pueden referirse al mismo objeto Un término puede referirse a más de un objeto El lenguaje natural es bastante ambiguo

Este acercamiento puede identificar varios objetos sin importancia La lista de nombres debe ser filtrada

Una palabra de atención Cada nombre puede ser tratado como verbo; cada verbo puede

ser tratado como nombre El resultado depende fuertemente de la habilidad para

escribir de los autores


VENS

VENS

Linea de fondo: Cada nombre debe ser considerado en el contexto del problema – él no se basta a si mismo

Linea de fondo: Cada nombre debe ser considerado en el contexto del problema – él no se basta a si mismo

Revisando los Nombres

El siguiente requerimiento es escrito para un sistema bancario “Los requerimientos legales serán transformados en cuentas”

Si SÓLO los nombres son considerados, ¿qué pasará?


VENS

VENS

El Escenario “Registrar Cursos a Tomar”

John ingresa su número de estudiante 369 52 3449 y el sistema valida el número. El sistema pregunta cuál semestre- John indica el semestre actual y elige crear un nuevo horario.

Desde una lista de cursos disponibles, John elige de entre los cursos primarios Ingles 101, Geología 110, Historia del Mundo 200 y Álgebra 110. Luego elige de entre los cursos alternativos Teoría de la Música 110 e Introducción a la Programación en Java180.

El sistema determina que John cumple con todos los prerequisitos examinando sus registros y lo agrega a las listas de los cursos.

El sistema indica que la actividad está completa. El sistema imprime el horario del estudiante y envía la información de cobro por cuatro cursos al sistema de cobranzas para su proceso.


VENS

VENS

¿Qué nombres deben ser filtrados?¿Qué nombres deben ser filtrados?

Los Nombres del Escenario “Registrar Cursos a Tomar”

John Número de estudiante 369523449 Sistema Número Semestre Semestre actual Nuevo horario Lista de cursos disponibles Cursos primarios Ingles 101 Geología 110 Historia del Mundo 200 Álgebra 110 Cursos alternativos Teoría Musical 110 Introducción a la programación en Java 180 Prerequisitos necesarios Registro del estudiante Lista del curso Actividad Horario del estudiante Información de cobro Cuatro cursos Sistema de cobranza


VENS

VENS

Decisiones de Filtrado

John -- filtrado (actor) Número de estudiante 369523449 -- filtrado (propiedad de un estudiante) Sistema -- filtrado (lo que está siendo construido) Número -- filtrado (propiedad de un estudiante) Semestre -- filtrado (estado – cuando la selección ocurre) Semestre actual -- filtrado (lo mismo que semestre) Nuevo horario – candidato a objeto Lista de cursos disponibles -- candidato a objeto Cursos primarios -- filtrado (estado del curso seleccionado) Ingles 101 -- candidato a objeto Geología 110 -- candidato a objeto Historia del Mundo 200 -- candidato a objeto Álgebra 110 -- candidato a objeto


VENS

VENS

Decisiones de Filtrado

Cursos alternativos -- filtrado (estado del curso seleccionado)

Teoría Musical 110 -- candidato a objeto

Introducción a la programación en Java 180 -- candidato a objeto

Prerequisitos necesarios -- filtrado (cursos como otros cursos identificados)

Registro del estudiante -- candidato a objeto

Lista del curso -- candidato a objeto

Actividad -- filtrado (Expresión española)

Horario del alumno -- filtrado (lo mismo que nuevo horario)

Información de cobro -- candidato a objeto

Cuatro cursos -- filtrado (Información necesitada por el sistema de cobranza)

Sistema de cobranza -- filtrado (actor)


VENS

VENS

Candidatos a Objeto en el Escenario

Nuevo horario – lista de los cursos de un alumno en un semestre Lista de cursos disponibles – lista de todos los cursos impartidos en un

semestre Ingles 101 – una oferta para el semestre Geología 110 -- una oferta para el semestre Historia del Mundo 200 -- una oferta para el semestre Álgebra 110 -- una oferta para el semestre Teoría Musical 110 -- una oferta para el semestre Introducción a la programación en Java 180 -- una oferta para el

semestre


VENS

VENS

Candidatos a Objeto en el Escenario

Registro del estudiante – la lista de los cursos aprobados anteriormente por el alumno

Lista del curso – lista de los estudiantes para un curso especifico

Información de cobro – información requerida por el sistema de cobranza


VENS

VENS

Creando Clases

Los objetos encontrados son agrupados en clases Basados en estructuras y/o comportamientos similares

Este es un intento inicial Las clases pueden cambiar mientras más escenarios son

examinados


VENS

VENS

Programa<<Entidad>>

Curso<< Entidad >>

InformaciónCobro<< Entidad >>

ListaCurso<< Entidad >>

RegistroEstudiante<< Entidad >>

Catálogo<< Entidad >>

Candidatas a Clases – Escenario “Creando un Horario”

Programa – lista de los cursos de un alumno en un semestre Catálogo – lista de todos los cursos impartidos en un semestre Curso – una oferta para un semestre RegistroEstudiante – lista de los cursos tomados previamente ListaCurso – lista de estudiantes para un curso en particular InformaciónCobro – información necesaria para el sistema de

cobranza


VENS

VENS

Encontrando Clases Frontera

Examine cada par actor/escenario y cree clases de frontera obvias Durante el diseño, la clase será definida basada en los

mecanismos de la interfaz de usuario elegida Ejemplo:

El estudiante se presenta con diferentes opciones en el caso “Registrar Cursos a Tomar”

Una clase de frontera llamada “FormularioRegistro” se crea para permitir al estudiante seleccionar la opción deseada

El estudiante debe ingresar la información del curso al sistema en el escenario “Registrar Cursos a Tomar”

Una clase de frontera llamada”FormularioPrograma” se crea para guardar la información ingresada por el estudiante


VENS

VENS

Candidatas a Clases Frontera – Escenario “Registrar Cursos a Tomar”


FormularioRegistro<<Boundary>>


VENS

VENS

Esquema de Ventana Los prototipos y/o esquemas de ventanas pueden ser creados para

comunicar el aspecto y sensación de clase de interfaz al usuario


VENS

VENS

Encontrando Clases de Interfaz

Las clases de interfaz también son creadas para la comunicación sistema-a-sistema

Un sistema puede ser otro sistema de software o un hardware (impresoras, alarmas, etc.)

Las clases de interfaz son agregadas para describir el protocolo de comunicación escogido


VENS

VENS

Printer<<Boundary>>

Candidatas a Clases de Interfaz – Escenario “Registrar Cursos a Tomar”

El horario del estudiante es impreso en el escenario “Creando un Horario”

Una clase de interfaz llamada “Printer” es creada La información de cobro es enviada al sistema de cobranza en el

escenario “Registrar Cursos a Tomar” Una clase de interfaz llamada SistemaCobranza es creada

SistemaCobranza<<Boundary>>


VENS

VENS

Encontrando Clases de Control

Las clases de control típicamente contienen información de secuencia Atención: las clases de control NO deben asumir las

responsabilidades que típicamente corresponden a las clases de interfaz o de entidad

A este nivel de análisis, una clase de control es típicamente creada para cada caso de uso

Responsable por el flujo de los eventos en el caso de uso Esto es solo el primer corte

Mientras más casos y escenarios son desarrollados, las clases de control pueden ser eliminadas, divididas o combinadas


VENS

VENS

Control para el caso de uso “Registrar Cursos a Tomar”

Una clase de control llamada “AdministradorRegistro” es creada Recibe información de la clase frontera “FormularioPrograma” Para cada uno de los cursos seleccionados

Pregunta al curso sus prerrequisitos Revisa para estar seguro de que todos los prerrequisitos

han sido tomados preguntando a “RegistroEstudiante” si un prerrequisito ha sido completado satisfactoriamente

Sabe qué hacer si un prerrequisito no ha sido tomado Pregunta al “curso” para saber si esta abierto Pide al curso agregar un “Estudiante” (si el curso está

abierto) Sabe qué hacer si ninguno de los 4 cursos está disponible Crea los objetos “ProgramaEstudiante” e

“InformaciónCobro” Pide a “SistemaCobro” enviar la “InformaciónCobro”


VENS

VENS

Candidatas a Clases de Control – Caso de Uso “Registrar Cursos a Tomar”

AdministradorRegistro<<Control>>


VENS

VENS

Tarjetas CRC (Clase –Responsabilidades -Colaboradores)

Las clases pueden también ser descubiertas usando tarjetas Clase –Responsabilidad -Colaboradores (CRC por sus siglas en inglés)

Introducidas por Ward Cunningham y Kent Beck en OOPSLA en 1989

Una tarjeta CRC en una tarjeta indexada de 3 x 5 que muestra El nombre de la clase y su descripción Las responsabilidades de la clase

Conocimiento interno de la clase Servicios brindados por la clase

Los colaboradores para las responsabilidades Un colaborador es una clase cuyos servicios son

necesarios para realizar una responsabilidad


VENS

VENS

Tarjeta CRC para la Clase Curso

Nombre de la clase Curso

Responsabilidades Colaboradores

Agregar un estudiante

Saber donde es dado el curso

Saber cuando el curso es dado

Estudiante

Saber los prerequisitos

Servicios entregados

Conocimiento interno


VENS

VENS

Una sección de tarjeta CRC

Un grupo de personas es escogida para personificar un escenario Se crea una tarjeta para cada objeto en el escenario A cada participante se le asigna un grupo de tarjetas

La persona se transforma en la “clase” El escenario definido es actuado por los participantes En las tarjetas se anotan las responsabilidades y colaboraciones Se crean nuevas tarjetas por cada nuevo objeto descubierto


VENS

VENS

Beneficios de las Tarjetas CRC

A medida que más y más escenarios son completados, emergen rastros de colaboración

Las tarjetas pueden ser físicamente arregladas para representar esas colaboraciones

Esto puede ayudar a identificar jerarquías de generalización / especialización, o jerarquías de agregación entre las clases

Las tarjetas CRC son más efectivas para grupos que se inician en las técnicas OO, porque ellas:

Previenen la focalización en los detalles de la POO Previenen la generalización prematura Remarcan el “pensamiento objeto”


VENS

VENS

¿Qué Estoy Haciendo?

Las cosas van bien si . . . Todas las clases tiene nombres con sentido y específicos al dominio Cada clase tiene un pequeño conjunto de colaboradores No hay clases “indispensables” (una clase que colabora con todo el

resto debe ser redefinida) La información de cada clase cabe cómodamente en una tarjeta Un cambio de requerimientos puede ser manejado por las clases

Las cosas van mal si . . . Un número de clases no tienen responsabilidades Una sola responsabilidad es asignada a varias clases Todas las clases colaboran con todas


VENS

VENS

Dibujando Escenarios

A medida que las clases y los objetos son descubiertos, son documentados en diagramas de interacción

Los diagramas pueden ser de secuencia o de colaboración Los diagramas de interacción contienen el flujo de eventos para un

escenario dado Los nombres de los objetos son frecuentemente generales

Ej. estudiante en vez de John Los nombres de los objetos pueden ser omitidos si no son

necesarios para la comunicación Se agregan notas y/o libretos si se necesitan


VENS

VENS

Diagrama de Secuencia para el Escenario “Registrar Cursos a Tomar”

: Estudiante :Formulario

Registración : Formulario

Programa : Catálogo : Administrador

registro1: ingresar id

2: validar Id

3: ingresar semestre

4: crear 5: mostrar

6: obtener la oferta de cursos

7: mostrar la oferta de cursos

8: seleccionar cursos

9: enviar

10: crear horario (estudiante, semestre, oferta de cursos)


VENS

VENS

Diagrama de Secuencia para el Escenario “Registrar Cursos a Tomar” (cont.)

: AdministradorRegistro

: CursosOfrecidos

: RegistroEstudiante

: Programa : Printer : InformaciónCobro

: SistemaCobro

11: obtener los prerequisitos

13: ¿disponible?

14: agregar estudiante (estudiante)

12: prerequisito tomado (curso)

15: crear

16: imprimir (horario)

17: crear

18: enviar (información de cobro)

LOOP a travesde todos loscursos selec.


VENS

VENS

Diagrama de Colaboración para el Escenario “Registrar Cursos a Tomar”

: Student

: RegistrationForm

: ScheduleForm

: Catalogue

: RegistrationManager

: CourseOffering

: StudentRecord

: Schedule

: Printer

: BillingInformation

: BillingSystem

2: validate id

5: display

6: get course offerings

7: show course offerings

10: create schedule (student, semester,

offerings)

11: get pre-requisite courses

12: pre-requisite taken (course)

13: available ?14: add student (student)

15: create

16: print (schedule)

17: create

18: send (billing information)

1: enter id3: enter semester4: create schedule

8: select course offerings9: submit


VENS

VENS

Nombre paquete

¿Qué es un paquete?

Un paquete es un mecanismo de propósito general utilizado para organizar elementos en grupos

El número de clases crece a medida que más casos de uso y escenarios son analizados

Las clases pueden ser agrupadas en paquetes Proveen la habilidad de organizar el modelo en desarrollo

Un paquete es representado como una carpeta


VENS

VENS

Paquetes en el Sistema de Registros

Las clases del Sistema de Registros pueden ser agrupadas en tres paquetes

Artefactos de la Universidad, Reglas de negocios e Interfaces Artefactos de la Universidad

Programa, Catálogo, Cursos ofrecidos, RegistroEstudiante, ListaCursos y InformaciónCobro

Reglas de negocio AdministradorRegistro

Interfaces FormularioRegistro, FormularioPrograma, SistemaCobro y Printer


VENS

VENS

¿Qué son los Diagramas de Clases? La vista lógica esta conformada de muchos paquetes y clases

Un diagrama de clases es la vista de unos pocos (o todos) los paquetes y clases de la vista lógica

Generalmente hay varios diagramas de clases

El diagrama de clases principal es típicamente una vista de los paquetes de alto nivel de la vista lógica

Típicamente cada paquete tiene su propio diagrama de clases principal

Se agregan diagramas de clases adicionales si son necesarios

La vista de las clases participantes de un escenario

La vista de las clases privadas de un paquete

La vista de una clase y sus atributos y operaciones

La vista de la jerarquía de herencia


VENS

VENS

Diagrama de Clases Principal para el Sistema de Registros

ArtefactosUniversidad

Interfaces Reglas Negocio


VENS

VENS

Diagrama de Clases Principal del Paquete ArtefactosUniversidad

InformaciónCobro Catálogo 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 lección anterior Diagrame al menos un escenario en un diagrama de interacción

Cree todas las clases de entidad, interfaz y/o control necesarias

Cree una definición para cada clase Cree paquetes para el modelo Acomode las clases descubiertas en paquetes Cree el diagrama de clases inicial


VENS

VENS

Resumen: Encontrando Clases

Las clases son descubiertas analizando los casos de uso y los escenarios desarrollados para el sistema

El par actor/caso de uso es examinado para agregar las clases frontera al modelo

Se agregan las clases entidad examinando los nombres y las frases de los casos de uso y escenarios

Se agregan las clases de control Típicamente una clase de control por cada caso de uso en

el análisis preliminar Pueden ser usadas las tarjetas CRC para descubrir clases Un paquete es un mecanismo de propósito general para organizar

elementos en grupos


VENS

VENS

Resumen: Encontrando Clases (cont.)

Un diagrama de clases es una vista de algunos (o todos) los paquetes y clases en la vista lógica

Usualmente hay varios diagramas de clases


VENS

VENS

Relaciones


VENS

VENS

Objetivos: Relaciones

Ud. será capaz de: Nombrar los dos tipos importantes de relaciones entre clases:

asociación y agregación Definir una asociación y representarla en los diagramas de clases Utilizar nombres de asociación y de roles para clarificar asociaciones Definir y especificar la multiplicidad de una asociación Definir una agregación y representarla en el diagrama de clases Definir y representar una asociación u agregación reflexiva Utilizar clases de asociación Definir calificadores y representarlos en diagramas de clases Descubrir relaciones en diagramas de interacción


VENS

VENS

La Necesidad de las Relaciones

Todo sistema abarca muchas clases y objetos Los objetos contribuyen en el comportamiento de un sistema

colaborando entre ellos mismos La colaboración se logra a través de las relaciones

Existen dos tipos importantes de relaciones durante el análisis Asociación Agregación


VENS

VENS

AdministradorRegistro<<control>>

Curso<<entidad>>

Asociaciones

Una asociación es una conexión semántica bidireccional entre clases Esto implica que existe una conexión entre objetos en las clases

asociadas Las asociaciones están representadas en los diagramas de clases con

una línea conectando las clases asociadas Los datos puede fluir en una o ambas direcciones a lo largo de la

asociación


VENS

VENS


Curso<<entity>>

Navegación

Una asociación es una relación bi-direccional Dada la instancia de “AdministradorRegistro” existe asociado un

objeto “Curso” Dada la instancia de “Curso” existe asociado un objeto

“AdministradorRegistro”


VENS

VENS


Curso<<entity>>administra

Nombrando Asociaciones

Para clarificar su significado, una asociación debe ser nombrada El nombre se representa como una etiqueta ubicada a lo largo de la

línea de asociación, a medio camino entre los iconos de clases Un nombre de asociación normalmente es un verbo o una frase verbal


VENS

VENS

Persona MaestroCurso

Definiendo Roles

Un rol denota el propósito o la capacidad con la que se asocia una clase con otra

Los nombres de roles son típicamente sustantivos El nombre de un rol es puesto a lo largo de la línea de asociación

cercano a la clase que modifica Uno o ambos terminan en una asociación que puede tener

nombres de un rol


VENS

VENS

Puede existir más de una asociación entre dos clases Si hay más de una asociación entre dos clases entonces se le DEBE

poner un nombre

Las asociaciones múltiples deben ser puestas a prueba

Persona Enseña Curso

Inscripto

Asociaciones Múltiples


VENS

VENS

Asociaciones Múltiples(cont.)

¿Un modelo bueno o malo?¿Un modelo bueno o malo?

Agregar un alumno aSelección del curso Curso

Borrar un alumno de


VENS

VENS

Multiplicidad para Asociaciones

Multiplicidad es el número de instancias de una clase que se relacionan con una instancia de otra clase

Para cada asociación, hay dos decisiones de multiplicidad por hacer: una para cada final de la asociación

Por ejemplo, en la conexión que existe entre las instancias que cumplen el rol de maestro y curso

Para cada instancia de persona, muchos (ej. cero o mas) cursos serán enseñados

Para cada instancia de curso, exactamente una persona es el maestro


VENS

VENS

Exactamente uno

Cero o mas

Uno o mas

Cero o uno

Rango especificado

1

0..*

1..*

0..1

2..4

Muchos*

Indicadores de Multiplicidad

Cada término de asociación contiene un indicador de multiplicidad Indica el número de objetos que participa en la relación


VENS

VENS

1..*

Persona MaestroCurso

1

Ejemplo: Multiplicidad

Las decisiones de multiplicidad exponen muchas suposiciones ocultas acerca del problema que esta siendo modelado

¿Puede ser posible que un maestro no dicte algún curso? ¿Puede un curso tener dos maestros?


VENS

VENS

¿Qué le dice este diagrama?¿Qué le dice este diagrama?

Curso Maestro

10..*

¿Qué significa Multiplicidad?

La multiplicidad responde a dos preguntas ¿La asociación es obligatoria u opcional? ¿Cuál es el número máximo o mínimo de instancias que pueden

ser ligadas a una instancia?


VENS

VENS



1 11

Agregación

La agregación es una forma especial de asociación donde un todo se relaciona con sus partes

También se conoce como “una parte de” o una relación de contención.

Una agregación esta representada como una asociación con un diamante al lado de su clase denotando el agregado.

La multiplicidad se representa de la misma manera que en las otras asociaciones.


VENS

VENS

Pruebas para comprobar la agregación

¿Es la frase “una parte de” usada para describir la relación? Una puerta es “una parte de” un Automóvil.

¿Son algunas operaciones sobre el todo, automáticamente aplicables a todas sus partes?

Mover el Automóvil, Mover la Puerta ¿Son algunos de los atributos de los valores propagadas del todo

hacia todas sus partes o solo a algunas en particular? El Automóvil es azul, la Puerta es Azul

¿Existe una simetría intrínseca en la relación donde una clase es subordinada de otra?

Una puerta ES parte de un Automóvil, pero un Automóvil NO ES parte de una Puerta


VENS

VENS

Curriculum and Course are tightly coupled -- the Curriculum is“made up of” 1 to may Courses

Independent objects

AlumnoCurso

3..10

Curriculum

1..* 0..*1

¿Asociación o Agregación?

Si dos objetos están unidos firmemente por una relación todo-parte La relación es una agregación

Si dos objetos son usualmente considerados como independientes, aun cuando comúnmente están unidos

La relación es una asociación


VENS

VENS

A course may have many pre-requisitesA course may be a pre-requisite for many other courses

Curso

Pre-requisito

0..*

0..*

Asociación Reflexiva

En una asociación reflexiva, los objetos de una misma clase están relacionados

Indica que múltiples objetos en la misma clase colaboran en conjunto del mismo modo


VENS

VENS

Un objeto Producto esta “compuesta de”cero o mas objetos Producto

Producto

0..*

1

Agregaciones Reflexivas

Las agregaciones también pueden ser reflexivas Esto indica una asociación recursiva

Parte


VENS

VENS

Alumno 0..*

3-10

Curso

Clase Asociación

Deseamos llevar un historial de las calificaciones de todos los cursos que el alumno ha tomado

La relación entre “Alumno” y “Curso” es una relación de muchos a muchos

¿Donde situamos los atributos de las calificaciones?


VENS

VENS

Clase Asociación (cont.)

El atributo de calificaciones no puede ser situado en la clase “Curso” porque existen (potencialmente) muchas relaciones a muchos objetos de Alumno

Por lo tanto, el atributo pertenece realmente a la relación individual Alumno-Curso

Una clase asociación es usada para almacenar información sobre la relación


VENS

VENS

Alumno 1..*

3-10

Curso

Notación de la Clase Asociación

Una clase asociación se representa usando el icono de clase La clase asociación se conecta con la asociación usando la línea

entrecortada La clase de asociación puede incluir múltiples propiedades de dicha

asociación Solamente una clase de asociación está permitida por cada asociación

Calificación


VENS

VENS

Alumno 13-10

Curso

Calificación

Alumno

1

3-10Curso

Calificación

La Clase Asociación y la Multiplicidad

Las Clases de Asociación son regularmente usadas en asociaciones del tipo muchos a muchos

Si la multiplicidad en cualquier extremo de la asociación es “muchos a uno”

Los atributos pueden ser situados dentro de una clase Una clase de Asociación aún puede ser usada


VENS

VENS

Dado un objeto de Departamento y un valor para un EmpleadoID existe exáctamente un objeto Profesor

Dado un objeto departamenteo y unvalor para Título, existe un conjuntode objetos Profesor

Departmento ProfesorTitleTitleTítulo

1..*1

Departamento ProfesorEmployeeIDEmployeeIDEmpleadoID

11

Calificadores

Un calificador es un atributo o conjunto de atributos, cuyos valores particionan un conjunto de objetos relacionados a través de la asociación de un objeto


VENS

VENS

1..*

{Ordenado porEmpleadoID}Profesor Departmento

1..*

Es miembro de

Es encabezado por

{Subconj.}

1

1 1

Restricciones

Una restricción es una expresión de alguna condición que se debe preservar

Una restricción se denota con llaves


VENS

VENS

unaForma : Forma Registro

unaForma : Forma Programa

Admi : Administrador Registro

mostrar

crear

Encontrando Asociaciones y Agregaciones

Los escenarios pueden ser examinados para determinar si una relación debe existir entre dos clases

Dos objetos se pueden comunicar si y solo si se “conocen” entre si

Asociaciones y/o agregaciones proveen un vía de comunicación


VENS

VENS

¿Asociación o Agregación?

RegistrationForm and ScheduleForm are tightly coupled -- a ScheduleForm is “part of” the RegistrationForm

ScheduleForm and RegistrationManagerare independent


11FormularioPrograma<<Boundary>>

1 1

AdministradorRegistro1

1

1

1


VENS

VENS

Interfaces

Business Rules

University Artifacts

Relaciones entre Paquetes

Los paquetes se relacionan entre si usando una relación de dependencia

Si una clase en un paquete se “comunica” con otra clase contenida en otro paquete entonces su relación de dependencia es adicionada a nivel de paquetes

Los diagramas de escenario y diagramas de clase son evaluados para determinar las relaciones entre paquetes


VENS

VENS

Relaciones durante Análisis y Diseño

Durante el análisis se deben establecer las conexiones (asociaciones y agregaciones) entre las clases

Dichas conexiones existen por la misma naturaleza de las clases, no por una implementación específica

Hacer una estimación inicial de multiplicidad de manera de exponer suposiciones ocultas

Los diagramas de clase son actualizados para mostrar sus relaciones agregadas

Durante el diseño: Las estimaciones de multiplicidad son refinadas y actualizadas Asociaciones y agregaciones son evaluadas y refinadas Las relaciones de paquetes son evaluadas y refinadas Los diagramas de clases maduran


VENS

VENS

Actualización del Diagrama de Clases Principal para el Sistema de Registro

ArtefactosUniversidad

Interfaces Reglas Negocio


VENS

VENS

Interfaces - Diagrama de Clases Principal

FormaRegistro<<Boundary>>

11

1

AdministradorRegistro(desde ReglasNegocio)

<<control>>

SistemaCobranza<<Boundary>>

1

1

1

FormaPrograma<<Boundary>>

1 1

1

1

Catalogo(desde ArtefactoUniversidad)

1

1

1

1

<<entity>>


VENS

VENS

ArtefactosUniversidad - Diagrama de Clases Principal

Curso<<entity>>

Catálogo<<entity>>

Formularioregistración(de Interface)

1

1

1

1

1

RegistroCurso<<entity>>

ListaCurso<<entity>>

AdministradorRegistro(desde Reglas de Negocio)

1

0..41

1

1

1

1

1

RegistroEstudiante<<entity>>1

1

1

1

1

1

1

1

0..4

<<Boundary>>

<<control>>


VENS

VENS

Actualización de Diagrama de clase Principal de Reglamento Económico

Curso(desde ArtefactosUniversidad)

<< entity >>0..4

1

SistemaCobranza(desde Interfaz

<< boundary >>

FormularioItinerario(from Interfaces)

<<boundary>> RegistroCurso(desde ArtefactosUniversidad)

<<entity>>

ListaCursos(desde ArtefactosUniversidad)

<< entity >>Registro de Estudiante

(desde ArtefactosUniversidad)

<< entity >>


1

11

1

11

1

1

1

1

1

11

1

11

1

1

1

1

1


VENS

VENS

Ejercicio: Relaciones

Usando los escenarios y diagramas de secuencia generados en las lecciones anteriores

Actualice los diagramas de clase mostrando la relación entre las clases

Asegúrese que las decisiones de multiplicidad inicial sean correctas

Agrega los paquetes y sus relaciones para el sistema


VENS

VENS

Resumen: Relaciones Todos los sistemas involucran muchos objetos que colaboran entre

ellos para crear la funcionalidad requerida Dos tipos de relaciones importantes son las asociaciones y las

agregaciones Una asociación es una conexión entre dos clases que representan

comunicación Una asociación puede tener nombre Nombres nemotécnicos pueden ser utilizados La comunicación puede ser tanto uni como bi-direcional (por

defecto) La multiplicidad es el número de instancias que participan en una

asociación Está representado cerca del final de la línea de asociación Cada término de asociación debiera de tener un indicador de

multiplicidad


VENS

VENS

Resumen: Relaciones (cont.)

Una agregación es una forma especializada de asociación en la cuál un todo esta relacionado con sus partes

Los extremos de una línea de agregación debe tener un indicador de multiplicidad

Una clase puede tener una asociación reflexiva Dos objetos en la misma clase que están relacionados

Las relaciones de agregación también pueden ser reflexivas La información que pertenece al vinculo entre objetos es mostrado en

una clase asociación


VENS

VENS

Resumen: Relaciones (cont.)

Un calificador es un atributo de una clase que puede ser usado para reducir la multiplicidad de la asociación

Las relaciones pueden ser determinadas al examinar los escenarios y descubrir las necesidades de la comunicación entre objetos


VENS

VENS

Operaciones y Atributos

Ing. ERNESTO CALDERON [email protected]


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

Un operación debería desempeñar una función simple y cohesionadaUn operación debería desempeñar una función simple y cohesionada

¿Qué es una Operación? Una clase contiene un conjunto de responsabilidades que definen el

comportamiento de los objetos que pertenecen a la clase. Las responsabilidades de una clase son llevadas a cabo por sus

operaciones Esto no es necesariamente mapeado uno a uno

Responsabilidad de la clase “producto”: mantener el precio de proveedor

Operaciones para esta responsabilidad Buscar la información en la base de datos Calcular el precio

Una operación es un servicio que puede ser solicitado desde un objeto para solicitar un determinado comportamiento


VENS

VENS

Perspectiva Bancaria

Recibe préstamosPosee cuentasRecibe líneas de credito

Perspectiva Médica

Es examinadaToma remediosVa al hospitalRecibe una cuenta

Las operaciones son dependientes del dominio

Listar todas las operaciones relevantes al dominio Las operaciones de la clase “persona” serán distintas

dependiendo de la perspectiva solicitada


VENS

VENS

Nombrando las Operaciones

Las operaciones deberían ser nombradas indicando el nombre de su resultado o salida, no los pasos dentro de la operación. Ejemplos:

calcularBalance() Pobremente nombrada

Indica que el balance debe ser calculado - esto es una decisión implementación/optimización

obtenerBalance() Bien nombrada

Indica solamente la salida


VENS

VENS

Nombrando Operaciones (cont.)

Las operaciones debería ser nombradas desde la perspectiva del proveedor, no del cliente

En una estación de gas, el gas es recibido desde la bomba: Una operación para la bomba que tiene esta responsabilidad -

como debería ser llamada? Nombres buenos: entregarGas(),dispensar() Nombre malo : recibirGas()

La bomba da el gas, no lo recibe


VENS

VENS

¿Qué es una Operación Primitiva?

Una operación primitiva es una operación que puede ser implementada solamente usando las cualidades internas de la clase

Todas las operaciones de una clase son típicamente primitivas Ejemplo:

Agregar un ítem al conjunto - operación primitiva Agregar cuatro ítems al conjunto - no primitiva

Puede ser implementada con múltiples llamadas a la operación anterior de agregar un ítem al conjunto


VENS

VENS

Firmas de las Operaciones

La firma de una operación consta de: Lista opcional de argumentos Tipo de retorno

Durante el análisis NO ES OBLIGATORIO llenar la firma de la operación

Esta información puede ser retrasada hasta el diseño


VENS

VENS

Curso

obtenerPrerequisito() : ListaCurso

Visualizando Operaciones

Las operaciones son mostradas en el tercer compartimiento de la clase


VENS

VENS

Administrador Registro

obtenerPrerequisito

unCurso Administrador Registro

obtenerPrerequisito():ListaCurso

unCurso

Descubriendo Operaciones desde los Diagramas de Interacción

Los mensajes visualizados en los diagramas de secuencia y/o colaboración son usualmente operaciones de las clases receptoras

Los mensajes son traducidos a operaciones y agregados al diagrama de clases


VENS

VENS

Descubriendo Clases Adicionales

Si una firma de una operación se especifica, pueden ser descubiertas clases adicionales en:

Argumentos de la operación Clases de retorno

Ejemplo: obtenerPrerequisito() : ListaCurso agregarEstudiantet(John : InformaciónEstudiante)

Las clases descubiertas se adicionan al modelo Estas son mostradas en los diagramas de clases


VENS

VENS

Descubriendo Relaciones Adicionales

Los argumentos de las operaciones y las clases de retorno denotan una relación entre la clase y los argumentos y/o la clase de retorno

Ejemplo La clase “ListaCursos” tiene una operación

agregarEstudiante(John: InformaciónEstudiante) Esto implica que existe una relación entre “ListaCursos” e

“InformaciónEstudiante” Las relaciones descubiertas son agregadas al modelo

Estas son mostradas en los diagramas de clases


VENS

VENS

¿Qué es un Atributo?

Un atributo es una definición de datos mantenido por instancias de una clase

Los atributos no tienen comportamiento -- no son objetos Los nombres de los atributos son sustantivos simples o frases simples

Los nombres deben ser únicos dentro de una clase Cada atributo debe tener una definición clara y concisa Buenos atributos para la clase Estudiante

Nombre -- nombre y apellido Carrera -- área principal de estudio

Un atributo malo para la clase Estudiante -- cursosSeleccionados Esta es una relación, no un atributo


VENS

VENS

AtributosNombre

NúmeroDeEmpleadoáreaEnseñanza

Sue Smith567892

Matemáticas

George Jones578391

Biología

Valores de Atributos

Un valor de atributo es el valor de un atributo para un objeto en particular

Cada objeto tiene un valor para cada atributo definido para su clase Por ejemplo, para un objeto de la clase “Profesor”:


VENS

VENS

Perspectiva Bancaria

nombredirecciónfechaDeNacimientonúmeroDeCuenta

Perspectiva Médica

nombredirecciónfechaDeNacimientoalturapeso

Atributos Dependientes del Dominio

Lista de todos los atributos relevantes al dominio del problema Los atributos de la clase Persona serán distintos dependiendo de

“a quien le preguntemos”


VENS

VENS

Curso

nombredescripciónubicaciónhorarioCréditos

obtenerPrerequisito () : Curso

<<entidad>>

Visualizando Atributos

Los atributos son mostrados en el segundo compartimiento de la clase


VENS

VENS

Rectánguloaltoancho/área

Atributos Derivados

Un atributo derivado es un atributo cuyo valor puede ser calculado en base a el valor de otros atributos

Utilizado cuando no existe suficiente tiempo para recalcular el valor cada vez que sea necesario

Compensa desempeño en tiempo de ejecución vs. memoria requerida


VENS

VENS

Tipos de Datos y Valor Inicial de Atributos

Cada atributo posee: Tipo de Dato Valor inicial opcional

Durante el análisis NO ES OBLIGATORIO completar la definición del atributo

Esta información puede ser retrasada hasta el diseño


VENS

VENS

Sólo modele los atributos que sean relevantes para el dominio del problemaSólo modele los atributos que sean relevantes para el dominio del problema

¿Cómo son descubiertos los Atributos?

Muchos atributos se descubren en el flujo de eventos de los casos de uso

Observe los sustantivos que no fueron considerados buenos candidatos para ser clases

Otros son descubiertos cuando se crea la definición de la clase La experiencia en el dominio puede también proveer buenos atributos


VENS

VENS

Curso

descripción

Ejemplo: Atributos en el problema de Inscripción de Cursos

“Cada curso tendrá una descripción en el catálogo” Un atributo llamado “descripción” es agregado a la clase Curso


VENS

VENS

Guía de Estilo para el nombramiento de atributos y operaciones

Una guía de estilo debería dictar convenciones de nombres para atributos y operaciones

Provee consistencia a través del proyecto Guía hacia modelos y código más mantenible

Ejemplos Atributos y operaciones empiezan con una letra minúscula El subrayado no es usado

Nombre compuestos de múltiple palabras son colocados juntos y la primera letra de cada palabra adicional esta en mayúscula


VENS

VENS

Mostrando Atributos y Operaciones

Atributos y/u operaciones pueden ser mostradas dentro de la clase Diagramas de clases adicionales pueden ser creados para mostrar

atributos y operaciones Las relaciones no son mostradas, típicamente,en esos diagramas

de clases


VENS

VENS

Encapsulamiento

Una forma para ver una clase es que consiste de dos partes: la interfaz y la implementación

La interfaz puede ser vista y usada por otros objetos La implementación es oculta para los clientes

Ocultar los detalles de implementación de un objeto se llama encapsulamiento u ocultamiento de la información

El encapsulamiento ofrece dos tipos de protección. Protege: El estado interno de un objeto, de ser corrompido por sus clientes El código del cliente, de cambios en la implementación del objeto


VENS

VENS

númeroCuentanombreBanconombreTitular

balance

retirar

depositar

generarInstrucciones

obtenerBalance

cambiarNombreTitular Los valores de los atributos pueden ser cambiados sólo por las operaciones que provee el objeto

Las operaciones son provistas para mostrar los valores de los atributos necesarios para los clientes

El estado del objeto no puede ser modificado por los clientes directamente

Ejemplo: Encapsulamiento


VENS

VENS

Beneficios del Encapsulamiento

El código cliente puede usar la interfaz a una operación El código cliente no puede tomar ventaja de la implementación de la

operación La implementación puede cambiar, por ejemplo, para:

Corregir errores (Bugs) Mejorar el Desempeño Reflejar cambios en las políticas

El código del cliente no debe ser afectado por cambios en la implementación, esto reduce el efecto “arrastre” en el cual una corrección para una operación fuerza la correspondiente corrección en una operación del cliente la cual causa el cambio en un cliente del cliente….

La manutención es fácil y menos cara.


VENS

VENS

Ejercicio: Operaciones y Atributos

Actualizar el diagrama de secuencia creado en la lección anterior para refinar los mensajes nombrando las operaciones en forma más concisa donde sea necesario

Crear el diagrama de Clases mostrando sólo atributos y operaciones Agregar cualquier relación adicional basada en argumentos de

operaciones y/o clases de retorno


VENS

VENS

Resumen: Operaciones y Atributos (cont.)

Una clase encierra un conjunto de responsabilidades las cuales definen el comportamiento de los objetos de la clase

Las responsabilidades son cumplidas por las operaciones definidas para la clase

Cada operación debería desarrollar una función simple y cohesiva Una operación debería hacer una cosa y hacerla bien Las operaciones son cómo un objeto actúa y reacciona ante los

mensajes que recibe Un atributo es una característica de una clase Un valor de un atributo es el valor de un atributo para un objeto en

particular


VENS

VENS

Resumen: Operaciones y Atributos (cont.)

Los atributos se descubren en el texto del enunciado del problema, cuando se crea la definición de la clase, y a través de la experiencia en el dominio.

Solamente los atributos relevantes y operaciones (aplicable para la solución del problema) deben ser modelados

Encapsulamiento es ocultar los detalles de implementación al mundo exterior

Protege el estado interno de un objeto Protege el código del cliente de cambios en la implementación de

las clases


VENS

VENS

Herencia



VENS

VENS

Herencia: Objetivos

Usted será capaz de: Definir y discutir herencia, generalización y especialización Representar una jerarquía de herencia en un diagrama de clases Entender las técnicas para encontrar la herencia Definir herencia múltiple


VENS

VENS

Herencia

La herencia define una relación entre clases donde una clase comparte la estructura y/o comportamiento con una o más clases

La herencia define una jerarquía de abstracciones en que una subclase herede desde una o más superclases

Con la herencia simple, la subclase hereda desde una única superclase

Con la herencia múltiple, la subclase hereda desde más de una superclase

La herencia es una relación “es un” o “tipo de”


VENS

VENS

Superclase

Subclase

Relación de Herencia

InformaciónEstudiante

InformaciónUsuario

Dibujando una Jerarquía de Herencia


VENS

VENS

Consideraciones para la Herencia

Ya que una relación de herencia no relaciona objetos individuales La relación no tiene nombre La multiplicidad no tiene sentido

Teóricamente, no existe límite para el número de niveles de herencia En la práctica actual, los niveles necesitan ser bastante limitados

Típicamente la herencia en C++ llega de 3 a 5 niveles La herencia en Smalltak puede ser un poco más profunda


VENS

VENS

La herencia apalanca las similaridades entre las clasesLa herencia apalanca las similaridades entre las clases

¿Qué es herencia?

Una clase hereda de sus padres: Atributos Operaciones Relaciones

Una subclase puede: Agregar atributos, operaciones y relaciones adicionales Redefinir las operaciones heredadas (¡tenga cuidado!)


VENS

VENS

Un camión tiene tres atributos:númeroLicenciapesotonelaje


Camión

tonelaje

VehículoTerrestre

PesonúmeroLicencia

Auto

Heredando Atributos Los atributos se definen en el nivel más alto en la jerarquía de herencia

en la que son aplicados Las subclases de una clase heredan todos los atributos Cada subclase puede añadir atributos adicionales


VENS

VENS


y dos operaciones:registrar()obtenerImpuestos()


y dos operaciones:registrar()obtenerImpuestos()

Camióntonelaje

VehículoTerrestrepesonúmeroLicencia

Auto

registrar( )

obtenerImpuestos( )

Heredando Operaciones Las operaciones son definidas en el más alto nivel en la jerarquía de

herencia en que son aplicables. Las subclases heredan todas las operaciones de una clase Cada subclase puede aumentar o redefinir las operaciones heredadas


VENS

VENS

Un auto es relacionado con un propietarioUn camión esta relacionado con un propietarioUn camión también tiene un trailer

Un auto es relacionado con un propietarioUn camión esta relacionado con un propietarioUn camión también tiene un trailer

Camióntonelaje

VehículoTerrestrepesonúmeroLicencia

Auto

dueño

registrar( )

obtenerImpuestos( )

Persona

0..*

Trailer

1

Heredando Relaciones Las relaciones también son heredadas y deben ser definidas en el más alto

nivel de la jerarquía de herencia en la cual son aplicables Las subclases de una clase heredan todas las relaciones de la superclase Cada subclase puede participar en relaciones adicionales


VENS

VENS

Generalización de Clases

La generalización provee la capacidad para crear superclases que encapsulan estructura y/o comportamiento común entre subclases

La generalización se aplica: Identificando similitudes de estructura/comportamiento entre

varias clases Creando una superclase para encapsular

estructura/comportamiento común Las clases originales son subclasificadas a la nueva superclase

Las superclases son más abstractas que sus subclases


VENS

VENS

Ejemplo de Generalización

Incrementandoabstracción

Activo

BienesRaices

Ahorros

CuentaBancaria

Corriente Accion

Valor

Bono


VENS

VENS

Especialización de Clases

La especialización provee la capacidad para crear subclases que representan refinamientos en los que la estructura y/o comportamiento de una superclase son agregados o modificados

La especialización se aplica: Notando que algunas instancias exhiben estructura o

comportamiento especializado Creando subclases para agrupar instancias de acuerdo a su

especialización Las subclases son menos abstractas que sus superclases


VENS

VENS

Decrementandoabstracción

Ejemplo de EspecializaciónActivo

BienesRaices

Ahorros

CuentaBancaria

Corriente Accion

Valor

Bono


VENS

VENS

Jerarquía de Herencia

La generalización y especialización son usadas para desarrollar la jerarquía de herencia

Durante el análisis, las jerarquías de herencia entre abstracciones claves (por ejemplo, clases) son establecidas solo si es necesario

Durante el diseño, las jerarquías de herencia son redefinidas para: Incrementar el reuso Incorporar clases de implementación Incorporar librerías de clases disponibles


VENS

VENS

Vehiculo

Ford

VehiculoTerrestre

Camion Aereoplano

VehiculoAereo

Helicoptero

Las clases en el mismo nivel de

herencia deberían tener el mismo nivel

de abstracción

Las clases en el mismo nivel de

herencia deberían tener el mismo nivel

de abstracción

Niveles de Abstracción


VENS

VENS

Aeroplano Helicoptero Lobo Caballo

ObjetoVolador Animal

Aguila

multipleinheritance

Aguila hereda de ObjetoVolador y AnimalAguila hereda de ObjetoVolador y Animal

Herencia Múltiple


VENS

VENS

Use herencia múltiple solamente cuando sea necesario, y

¡siempre con precaución!

Use herencia múltiple solamente cuando sea necesario, y

¡siempre con precaución!

Conceptos de Herencia Múltiple

Conceptualmente necesario para modelar con exactitud el mundo real En la práctica, puede llevar a dificultades en la implementación

No todos los lenguajes de programación orientados a objetos soportan directamente herencia múltiple


VENS

VENS

Cada lenguaje o ambiente de programación elije maneras de resolver estas dificultades

Cada lenguaje o ambiente de programación elije maneras de resolver estas dificultades

Name clashes on attributes or operations Repeated inheritance

ObjetoVolador

color

getColor

Animal

color

getColor

Aguila

Objeto Volador Animal

Aguila

ObjetoAnimado

color

Problemas con la Herencia Múltiple


VENS

VENS

Encontrando Herencia

Es importante evaluar todas las clases para definir una posible herencia

Observar los comportamientos (operaciones) y los estados (atributos) comunes en las clases

Técnica de adición Agregue nuevas operaciones/atributos a las subclases

Técnica de modificación Redefina las operaciones

Debe ser cuidadoso en no hacer cambios semánticos


VENS

VENS

Las palabras claves “es un” y “tiene un” ayudarán a determinarla relación correcta

Las palabras claves “es un” y “tiene un” ayudarán a determinarla relación correcta

Herencia vs. Agregación

Herencia y agregación son usualmente confundidas La herencia representa una relación “es un” o “tipo de” La agregación representa una relación “tiene un”


VENS

VENS

Un WindowWithScrollbar “tiene un” WindowUn WindowWithScrollbar “tiene un” Scrollbar

¿Qué relación debería ser usada?

Un WindowWithScrollbar “tiene un” WindowUn WindowWithScrollbar “tiene un” Scrollbar

¿Qué relación debería ser usada?

Window Scrollbar

WindowWithScrollbar

Window y Scrollbar


VENS

VENS

Un WindowWithScrollbar “es un” WindowUn WindowWithScrollbar “tiene un” Scrollbar

Un WindowWithScrollbar “es un” WindowUn WindowWithScrollbar “tiene un” Scrollbar

Scrollbar

Window

WindowWithScrollbar

11

Window

WindowWithScrollbar

Scrollbar

Window y Scrollbar (cont.)


VENS

VENS

Herencia vs. Agregación

Herencia Agregación

Palabra clave “es un”

Un objeto

Representado por una flecha

Palabra clave “tiene un”

Relaciona objetos de distintas clases

Representado por un diamante


VENS

VENS

Metamorfosis existe en el mundo real¿Cómo podría ser modelada?

Metamorfosis existe en el mundo real¿Cómo podría ser modelada?

¿Qué es Metamorfosis?

Metamorfosis

1. Un cambio en una forma, estructura o función; específicamente el cambio físico experimentado por algunos animales, como un renacuajo a una rana

2. Cualquier cambio marcado, como un carácter, apariencia o condición

Webster’s New World Dictionary

Simon & Schuster, Inc., 1979


VENS

VENS

Part-timeStudentnameaddressnumberCourses

Full-timeStudentnameaddressstudentIDgradDate

Ejemplo de Metamorfosis En la universidad existen estudiantes a tiempo completo y estudiantes

a medio tiempo Los estudiantes a tiempo completo tienen un número id y un

fecha de graduación prevista, pero los estudiantes a medio tiempo no.

Los estudiantes a medio tiempo toman un máximo de tres cursos mientras que para los de tiempo completo no existe límite


VENS

VENS

Student

nameaddress

FulltimeStudent

studentIDgradDate

ParttimeStudent

numberCourses

¿Qué pasa si los estudiantes part-time pasan a serestudiantes full-time?

¿Qué pasa si los estudiantes part-time pasan a serestudiantes full-time?

Un enfoque

Una relación de herencia puede ser creada


VENS

VENS

ParttimeClassification

numberCourses

FulltimeClassification

studentIDgradDate

Student

nameaddress

1

0..1

1

0..1

0..1

0..1

1

1

Metamorfosis

Es muy difícil cambiar la clase de un objeto Una mejor técnica de modelación

Colocar la estructura y comportamiento que “cambia” dentro de su propia clase


VENS

VENS

Metamorfosis (cont.)

Mary Smithestudiante Full-time

Joe Jonesestudiante Part-time

MarySmith : Student

: Full-timeClassification

1

1

JoeJones : Student

: Part-timeClassification

1

1


VENS

VENS

: Student : FulltimeClassification

: StudentManager

: ParttimeClassification

delete

create

change to full time

Metamorfosis (cont.)

La Metamorfosis es completado por el objeto “hablando” con las partes cambiantes.


VENS

VENS

Student

nameaddress

1 1 Classification

Parttime

numberCourses

Fulltime

studentIDgradDate

Metamorfosis y Herencia

La herencia puede ser usada para modelar estructura, comportamiento y/o relaciones comunes a las partes “cambiantes”


VENS

VENS

Parttime

numberCourses

FulltimestudentIDgradDate

11

ResidentInformationdormroomroomKeyID

Studentnameaddress10..1 10..1

Classification1 1

Metamorfosis y Flexibilidad Esta técnica también agrega flexibilidad al modelo Ejemplo: un estudiante puede también vivir en el campus. En este

caso, existe un identificador para el dormitorio, un número de habitación y un número clave de la habitación


VENS

VENS

Ejercicio: Herencia

Examinar las clases definidas en el problema y agregar herencia donde sea necesario

Asegúrese que cualquier metamorfosis esté considerada Actualice los diagramas de clase como sea necesario


VENS

VENS

Herencia: Resumen

La herencia define una relación entre clases donde una clase comparte la estructura y/o comportamiento de una o más clases

Define una jerarquía de abstracciones en la que una subclase hereda desde una superclase

Herencia simple -- una clase hereda desde una superclase Herencia múltiple -- una clase hereda desde más de una superclase Una subclase hereda atributos, operaciones y relaciones desde su

superclase(s) Un subclase puede

Agregar atributos, operaciones y relaciones Refinar las operaciones heredadas


VENS

VENS

Herencia : Resumen (cont.)

La generalización provee la capacidad para crear superclases que encapsulan estructura y/o comportamiento común a varias subclases

La especialización provee la capacidad para crear subclases que representan refinamientos en los cuales la estructura y/o comportamiento de las superclases son agregadas o modificadas

Herencia y agregación son usualmente confundidas Herencia representa una relación “es un” o “tipo de” Agregación representa una relación “tiene un”


VENS

VENS

Comportamiento de los Objetos



VENS

VENS

Objetivos: Comportamiento de los Objetos

Usted será capaz de: Explicar la necesidad de Diagramas de Transición de Estados (DTE) Entender como encontrar estados Desarrollar una muestra simple de un DTE

Estados y Transiciones Eventos Condiciones de guarda Acciones y Actividades

Entender el concepto de estados anidados Explicar las relaciones entre diagramas de transición de estados,

diagramas de interacción entre objetos y diagramas de clases


VENS

VENS

¿Qué es un Diagrama de transición de estados?

Un diagrama de transición de estados sirve para mostrar la historia de la vida de una determinada clase, los eventos que causan la transición desde un estado a otro, y las acciones que resultan debido a un cambio de estado.

El espacio de estados de una determinada clase es la enumeración de todos los posibles estados de un objeto.

El estado de un objeto es una de las posibles condiciones en que un objeto puede existir

Este reúne todas las propiedades del objeto Usualmente estático

Además de los valores de cada una de estas propiedades Usualmente dinámico


VENS

VENS

Nombre del estado

Dibujo de los Estados

Un estado es representado como un rectángulo redondeado, en un diagrama de transición de estado


VENS

VENS

numEstudiantes < 10

Abierto

El máximo número de estudiantes por curso es 10

numEstudiantes > = 10

Cerrado

numStudents = 7

Inglés101 : CursoCurso

numEstudiantes

Estados y Atributos

Los estados pueden ser distinguidos por los valores de ciertos atributos


VENS

VENS

Profesor Curso0..*1

Estados y Conexiones

Los estados pueden también ser distinguidos por la existencia de ciertas conexiones

Las instancias de la clase “Profesor” pueden tener dos estados: Enseñar, cuando existe una conexión con el curso En estado suspendido, cuando no existe conexión


VENS

VENS

Estado Final Estado inicial

Estados Especiales

El estado inicial es el estado del objeto cuando es creado Un estado inicial es obligatorio Sólo un estado inicial es permitido El estado inicial es representado como un círculo relleno

El estado final indica el fin de la vida para el objeto Un estado final es opcional Puede existir más de un estado final El estado final es indicado por un ojo de toro


VENS

VENS

Eventos

Un evento es algo que ocurre en un punto en el tiempo y permite la transición del objeto a un estado

El estado de un objeto determina la respuesta a diferentes eventos

Ejemplo: Añadir un alumno a un curso Crear un nuevo curso


VENS

VENS

Abierto CanceladoCancelar el curso

Añadir estudiante

Transiciones

Una transición es un cambio desde un estado primitivo a un estado sucesor como resultado de ciertos estímulos

El estado sucesor puede resultar ser el mismo estado primitivo Una transición puede ocurrir como respuesta a un evento Las transiciones pueden ser relacionadas con los eventos


VENS

VENS

Abierto Registración Completa

Cerrar Registración [ numEstudiantes >= 3 ]

Condiciones de Guarda

Una condición de guarda es una expresión booleana que permiten una transición sólo si la condición es verdadera


VENS

VENS

Creación AbiertoRegistro abierto Initialize

Añadir estudiante / Inc(numEstudiantes)

Acciones

Una acción es una operación que está asociada con una transición Para ser terminada requiere de una cantidad de tiempo

insignificante Se considera no-interrumpible

Los nombres de las acciones son mostrados en la flecha de transición


VENS

VENS

Creación Abierto

Cerrado

Registraciónn abierta / Inicializar

numEstudiantes

Añadir estudiante

[ numEstudiantes = 10 ]/ ^CursoReporte.Crear

reporte

Enviando Eventos

Un evento puede desencadenar el envío de otro evento Mostrado como: ^Clase.evento


VENS

VENS

Cerrado

do: Reportar curso esta lleno

Actividades

Una actividad es una operación que requiere tiempo para ser completada

Las actividades son asociadas con un estado Una actividad

Comienza cuando se ingresa al estado Puede ser ejecutada hasta ser completada o puede ser

interrumpida por una transición que este ocurriendo


VENS

VENS

Cancelado

do: ^ListaCursos.Eliminar estudiante(Estudiante)

Enviando Eventos Durante un Estado

Una actividad también puede enviar un evento a otro objeto


VENS

VENS

Cerrado

do: finalizar curso

Ofrecido

Transiciones Automáticas

Algunas veces, el único propósito de un estado es el de realizar una actividad

Una transición automática ocurre cuando la actividad es completada Si existen múltiples transiciones automáticas

Una condición de guarda es necesaria en cada transición Las condiciones deben ser mutuamente excluyentes


VENS

VENS

Sin-asignar

do: Asignar un profesor al curso

Añadir estudiante / numEstudiantes = 0

Abierto

entry: Registrar un estudiante

Añadir estudiante

Acciones de Entrada y Salida

Cuando una acción debe ocurrir sin importar cómo se ha ingresado o salido de un estado, la acción puede ser asociada con el estado

En realidad, la acción es asociada con cada transición entrando o saliendo del estado

La acción es mostrada dentro del icono de estado precedida por la palabra “entry” o “exit”


VENS

VENS

Estados Anidados

Los diagramas de transición de estado pueden volverse inmanejablemente largos y complejos

Los estados anidados pueden ser usados para simplificar diagramas complejos

Un superestado es un estado que incluye estados anidados llamados subestados

Las transiciones comunes de los subestados son representadas en el nivel del superestado

Cualquier número de niveles de anidación son permitidos Los estados anidados pueden llevar a sustanciales reducciones de

complejidad gráfica, permitiendo modelar problemas más largos y complejos


VENS

VENS

Diagrama de transición de estado para la Clase del Curso sin Utilizar Estados Anidados

Inicializar

do: Inicializar objecto curso

Sin-asignar

do: Asignar profesor al curso

Abierto

do: Registrar un estudiante

Cerrado

do: Reportar curso esta lleno

Cancelado

do: Enviar noticias de cancelación

añadirEstudiante/ numEstudiantes = 0

cancelarCurso

RegistraciónCompleta

dor: Generar clase roster

cancelarCurso

[ numEstudiantes = 10 ]

cancelarCurso

registración cerrada[ numEstudiantes > = 3 ]

añadirEstudiante

registración cerrada[

numEstudiantes < 3 ]


VENS

VENS

Diagrama de transición de estado para la Clase Curso Utilizando Estados Anidados

Inicializar Registrar

entry: Register a student

Sin-asignar

do: Asignar profesor al curso

Abrir

Cerrado Cancelado

RegistraciónCompleta

do: Generar clase roster

Añadir estudiante / numEstudiantes = 0

[ numEstudiantes = 10 ]

cancelarCurso

registración cerrada[ numEstudiantes > = 3 ]

registración cerrada[ numEstudiantes < 3 ]

añadirEstudiante

do: Reportar curso esta cerrado


VENS

VENS

Estados Anidados con Historia

El uso de características históricas indica que ante el retorno a un superestado, el subestado visitado más recientemente será ingresado

El uso de la H encerrada por un círculo para denotar que la característica histórica se aplica al superestado

Si la característica de historia no es usada, el subestado inicial será siempre ingresado cuando el superestado sea ingresado


VENS

VENS

Ejemplo: Estado Anidado con Historia

En el curso sistema de registro, la selección de curso hace lo siguiente Acepta cursos primarios Acepta cursos alternativos

El usuario puede renunciar en cualquier momento El usuario puede suspender una sesión por un máximo de 30 minutos

mientras selecciona cursos El formulario es grabado después de que todos los cursos han sido

seleccionados el formulario es enviado a procesar después de que ha sido grabado


VENS

VENS

Estados Anidados con Historia (De Tipo Formulario de Registración)

H

Creaciónentry: Crear formulario

do: inicializar formulario

Grabar

do: Grabar formulario

Enviardo: Enviar formulario para procesarlo

Suspender

do: Esperar por 30 minutos

Selección curso

Selección de curso alternativo

exit: Incrementar contador curso

Selección de curso primariado: Aceptar número curso

exit: Incrementar contador curso

do: Aceptar número curso

[ Contador curso < 4 ]

[ Contador curso = 4 ] / Poner contador curso en 0

[ Contador curso < 2 ]

[Contador curso= 2 ]

Resumir

Suspender

Salir


VENS

VENS

Dónde Empezar ...

Durante el análisis, inicialmente concentrarse en el comportamiento de las clases, con significativo comportamiento dinámico

Para una clase dada, se deben buscar posibles estados mediante: Evaluación de los valores de los atributos Evaluación de las operaciones Definir las reglas para cada estado y Identificar las transacciones válidas entre estados

Examinar la ruta de los mensajes o los diagramas de mensaje-objeto que conlleven a que la clase sea modelada

El intervalo entre dos operaciones puede ser un estado


VENS

VENS

Ejercicio: Comportamiento del Objeto Crear un diagrama de transición de estado para modelar el comportamiento

dinámico de la clase empleados con los siguientes estados

Postulante, Contratado, Ausente, Desempleado, Retirado

Información del estado Postulante

Una entrevista es conducida durante este estado

Este estado es concluido por el evento emplear

Información del estado Contratado

El estado contratado posee tres subestados basados en la clasificación de su sueldo

Por hora, Salario fijo y con Comisiones

La clasificación por sueldo puede variar en cualquier momento

Las clasificaciones por sueldo son creadas/borradas mediante la entrada/salida al subestado


VENS

VENS

Ejercicio: Comportamiento del Objeto (cont.) Información sobre el estado Ausente

Un empleado puede tomarse una ausencia de máximo 1 año mientras se encuentre en cualquier subestado de contratado

Si el empleado vuelve regresa al subestado anterior

Información del estado Desempleado

Un empleado puede ser despedido mientras se encuentre en cualquier subestado de empleado

Un empleado puede renunciar mientras se encuentre en cualquier subestado de empleado

El historial del empleado es catalogado como terminado en este estado

Información del estado Retirado

Un empleado debe retirarse al cumplir 65

La información sobre la pensión se calcula en este estado


VENS

VENS

Resumen: Comportamiento del Objeto

Un diagrama de transición de estado representa el ciclo de vida del objeto en términos de:

Los posibles estados del objeto Las transiciones entre esos estados

Existen dos estados especiales El estado inicial es el estado ingresado cuando un objeto es

creado El estado final indica el fin de la vida para el objeto

Una transición es un cambio desde un estado original a un estado sucesor, el cual puede ser el mismo estado


VENS

VENS

Resumen: Comportamiento del Objecto (cont.)

Una transición puede ocurrir como resultado de lo siguiente: Un evento Una condición ha sido satisfecha

Una acción es una operación que toma una cantidad insignificante de tiempo

Una actividad es una operación que es ejecutada mientras el objeto reside en un estado

Los estados anidados ayudan a enfrentar las complejidades asociadas con diagramas de estado planos

La historia permite la visita al subestado más reciente dentro de un estado


VENS

VENS

Homogenización


VENS

VENS

Objetivos: Homogenización

Usted será capaz de: Discutir por qué la homogenización es necesaria Determinar cuando dos clases deberían ser combinadas, cuando una

clase debería ser dividida y cuando una clase debería ser eliminada Evaluar la consistencia de los diagramas de clases y los diagramas de

interacciones. Discutir la necesidad de la reestructuración de paquetes


VENS

VENS

¿Qué es la homogenización?

Homogenizar

“mezclar o suavizar una mixtura, para hacerla homogénea”

- Webster’s New Collegiate Dictionary -

Mientras más casos de uso y escenarios son desarrollados se torna necesario hacer el modelo homogéneo

Esto es especialmente cierto si diferentes grupos están trabajando en diferentes casos de uso


VENS

VENS

¿Qué se busca?

Las clases son examinadas para determinar si Dos o más clases pueden ser combinadas Una clase debería ser dividida Una clase debería ser eliminada por completo

Los paquetes son reestructurados para solucionar problemas de: Acoplamiento Reuso Visibilidad


VENS

VENS

Combinando Clases

Cuando múltiples equipos están haciendo el análisis de los casos de uso, una clase puede ser nombrada de distinta manera por los diferentes grupos

Esto es especialmente cierto debido a que en el análisis de casos de uso de trabaja con el lenguaje natural

El recorrido del modelo debe ser canalizado en Evaluar las definiciones de la clase Evaluar la estructura y comportamiento de las clases Buscar sinónimos Buscar el nombre que es más cercano al dominio


VENS

VENS

Professor

nameaddresstenureStatus

1

0..*

Department

1

0..*Teacher

nameaddress

0..*

11

0..*

Department

Teacher

nameaddresstenureStatus

0..*

11

0..*

Ejemplo: Combinando Clases

Se elije Teacher ya que no todos los instructores en la Universidad han alcanzado el nivel de Professor


VENS

VENS

Ejemplo: Combinando Clases de Control

Desde que una clase de control es asignada para un caso de uso como un paso inicial, se hace necesario re-evaluar las clases de control

Las clases de control con comportamientos similares pueden ser combinadas

Ejemplo:

El “Administrador” interactúa con el caso de uso “MantenerInformaciónEstudiante” y con el caso de uso “MantenerInformaciónProfesor”

Dos clases de control fueron creadas La secuencia en cada una de estas dos clases de control es muy

similar (revisión, creación, borrar información acerca del autor) Las clases de control pueden ser combinadas en una sola clase

de control llamada AdministraciónDeUsuarios


VENS

VENS

Student

nameaddressphoneNumbermajornumStudentsinMajor

changeMajor()

Student

nameaddressphoneNumber

changeMajor( )

Major

namenumberStudents

1

0..*

1

0..*

Dividiendo Clases

Clases con estructuras y/o comportamientos que no están cohesionados pueden ser divididos en diferentes clases

Ejemplo:


VENS

VENS

Eliminando Clases Una clase puede ser eliminada del modelo si

No tiene ninguna estructura o comportamiento

No participa en ninguno de los casos de uso

En particular, examine las clases de control

La falta de responsabilidad en la secuencia podría llevar a la eliminación de la clase de control

Ejemplo:

Un caso de uso para el actor “Professor” es “Seleccionar Cursos a enseñar”

Esto significa que el actor “Professor” ingresa el nombre y número del curso y un vínculo a la clase “ProfessorInformation” es creado

Ya que no hay demasiado comportamiento secuencial, esta clase de control es eliminada


VENS

VENS

Diagrama de Secuencia Actualizado

: Professor

: ProfessorCourseForm

: Course

1: open

3: set course

4: process

2: set prof id

5: addProfessor ( )

6: quit

: ProfessorCourseForm

: Professor

: Course : ProfCourseManager

1: open

3: set course

4: process

2: set prof id

7: quit

5: addProfessor ( )

6: addProfessor ( )


VENS

VENS

Preguntas de Chequeo de Consistencia

Los diagramas de clases y los diagramas de interacciones deben ser revisados para verificar su consistencia

¿Es cada operación de una clase necesaria para al menos un escenario?

¿Existe una clase por cada objeto en el diagrama de interacciones?

Si un diagrama de objetos o interacciones muestra un mensaje viajando desde un objeto de clase A a un objeto de clase B, verifique que

Una operación en la clase A es la responsable del envío del evento

Una operación en la clase B espera el evento y lo maneja

Una asociación correspondiente ha sido definida entre la clase A y la clase B en el diagrama de clases

El diagrama de transición de estado para la clase B (si ha sido desarrollado) incluye este evento


VENS

VENS

Reestructurando Paquetes

Mientras más casos se desarollan se hace necesario reestructurar los paquetes en el modelo

Fuerte acoplamiento entre paquetes puede significar que los paquetes deben ser combinados

Dos vías de dependencia entre paquetes puede significar que el paquete debe ser dividido

Evalúe las consideraciones de reuso Un paquete reusable debe tener pocas dependencias

Evalúe las partes públicas y privadas del paquete No toda clase en un paquete debe ser parte de la interfaz

pública del paquete Agregar clases de interfaz si es necesario para

encapsular el paquete


VENS

VENS

Ejercicio: Homogenización

Discuta las decisiones de homogenización necesarias en este punto del análisis


VENS

VENS

Resumen: Homogenización

Mientras más escenarios y casos de uso se desarrollan se hace necesario hacer al modelo homogéneo

Las clases son examinadas para determinar si Dos o más clases pueden ser combinadas Una clase debe ser dividida Una clase debe ser eliminada por completo

Los paquetes son reestructurados para resolver problemas de Acoplamiento Reuso Visibilidad


VENS

VENS

Diseño Arquitectónico


VENS

VENS

Objetivos: Diseño Arquitectónico

Ser capaz de: Listar los atributos de una buena arquitectura Investigar la vista de arquitectura “4+1” Explicar el propósito de los diagramas de componentes Explicar el propósito de los diagramas de implantación


VENS

VENS

Visión Arquitectónica

Dos características comunes para que virtualmente todos los proyectos OO sean exitosos son:

La existencia de una fuerte visión arquitectónica La aplicación de un ciclo de vida incremental, iterativo y bien

administrado La arquitectura debe ser simple Una conducta común lograda a través de abstracciones y

mecanismos comunes


VENS

VENS

Mary Shaw

“La arquitectura de software está relacionada con la organización de los sistemas de software, la selección de los componentes de los cuales ellas están compuestas, las interacciones entre esos componentes, la composición de componentes que interactúan hacia subsistemas mayores progresivamente, y los patrones generales que guian esas composiciones. Esto tiene que ver no solamente con la estructura de los sistemas, sino también con su funcionalidad, desempeño, diseño, selección entre alternativas y comprensibilidad.”

Una Definición de Arquitectura de Software


VENS

VENS

Atributos de Buenas Arquitecturas

Las buenas arquitecturas se construyen en capas bien definidas de abstracción:

Cada capa representa una abstracción coherente Cada capa tiene una interfaz controlada y bien definida Cada capa se construye sobre facilidades bien definidas y

controladas a niveles más bajos de abstracción Hay una clara separación entre la interfaz y la implementación de cada

capa Los cambios en la implementación de una capa no violan las

suposiciones hechas por sus clientes


VENS

VENS

Desarrollando la Arquitectura del Sistema

El diseño arquitectónico aborda la administración de riesgos Las buenas arquitecturas son determinadas mejor a través del

desarrollo incremental e iterativo A un pequeño equipo de arquitectos experimentados, guiado por un

Arquitecto Jefe, se le debe asignar la responsabilidad para: Definir y mantener la integridad arquitectónica del sistema Aprobar todos los cambios para las interfaces del paquete Valorar los riesgos del proyecto Proponer el orden y el contenido de cada iteración


VENS

VENS

Dimensiones de la Arquitectura de Software

Diferentes perspectivas para las diferentes partes Usuarios finales, clientes y el administrador de proyecto Ingeniero de sistema, desarrollador, arquitecto y probador

Perspectivas múltiples requieren vistas múltiples Los diagramas de clases no muestran como los sistemas

mapean con el hardware Los diagramas de bloque del hardware no representan qué

partes del sistema son software estándar comercial


VENS

VENS

Una Arquitectura Requiere Múltiples Vistas

Para describir completamente una arquitectura, se requieren cuatro vistas:

La vista lógica para proveer una descripción estática de las clases primarias y sus relaciones

La vista de componentes para mostrar cómo el código se organiza en paquetes y bibliotecas y el uso de software estándar comercial

La vista de procesos para mostrar los procesos y las tareas La vista de implantación para mostrar los procesadores,

dispositivos y enlaces en el medio operacional Finalmente, una vista de escenarios (vista de casos de uso) explica

cómo las otras cuatro vistas trabajan en conjunto


VENS

VENS

El Modelo “Vista 4+1”

Vista de Componentes

Vista Proceso Vista Implantación

Vista Caso de Uso

Vista Lógica

Funcionalidad

Usuarios Finales

Administración de Software,Reuso, Portabilidad

Ingenieros de Software

Desempeño, Disponibilidad,

Tolerancia a fallos

Integradores de Sistema

Desempeño, Disponibilidad, Tolerancia a fallos, Escalabilidad,

Entrega e Instalación

Ingenieros de Sistema

ComprensibilidadUsabilidad


VENS

VENS

Vista Lógica

La vista lógica de la arquitectura se concentra en los requerimientos funcionales del sistema

Qué le proveerá el sistema a sus usuarios en términos de servicios

Provee una descripción estática de las clases primarias y sus relaciones

La vista lógica es capturada en los diagramas de clases los cuales contienen los paquetes, las clases y las relaciones que representan las abstracciones claves del sistema bajo desarrollo


VENS

VENS

ClasesBásicas

global

Paquetes Lógicos Globales

Ciertos paquetes son usados por todos los otros paquetes Clases básicas

Conjuntos, listas, colas, etc. Clases para la manipulación de errores

Estos paquetes son marcados como globales


VENS

VENS

Paquete Cliente

Paquete Suministrador

Implicaciones de Dependencia

Algunas de las implicaciones de la dependencia entre paquetes son: Cada vez que se le hace un cambio al paquete suministrador, el

paquete cliente tiene, potencialmente, que ser recompilado y vuelto a probar

El paquete cliente no puede ser reusado de manera independiente debido a que este depende del paquete suministrador


VENS

VENS

Evitando Dependencias Circulares

Es deseable que la jerarquía del paquete sea acíclica Esto significa que la siguiente situación deberá ser evitada (si es

posible) El paquete A usa el paquete B, el cual usa el paquete A

Tal dependencia circular significa que los paquetes A y B efectivamente tendrán que ser tratados como un paquete simple

Círculos mayores de dos paquetes también tendrán que ser evitados Ejemplo, el paquete A usa el paquete B el cual usa el paquete C

que a su vez usa al paquete A Las dependencias circulares pueden ser fraccionadas dividiendo uno

de los paquetes en dos paquetes menores


VENS

VENS

Dependencia Circular en el Sistema de Registro

Interfaces Reglas de Negocio

Cambia a Interfacesde Entrada Reglas de

Negocio

Interfaces de Salida


VENS

VENS

Interfaz Pública de un Paquete

Una interfaz de un paquete debe encapsular su implementación detrás de una interfaz pública tal como lo hace una clase

Cada clase en un paquete tiene un parámetro de control de exportación, el cual debe ser fijado a público o implementación (privado)

Solamente las clases públicas podrán ser usadas por clases de otros paquetes

Las clases de implementación (privadas) solamente pueden ser usadas dentro de su paquete


VENS

VENS

Vista de Componentes

La vista de componentes de la arquitectura tiene que ver con la organización modular del software real dentro del medio de desarrollo

Los diagramas de componentes se crean para mostrar los paquetes y componentes que conforman el sistema bajo desarrollo

Muestra la asignación de clases a los componentes Muestra la asignación de componentes a los paquetes

Los paquetes se organizan en una jerarquía de capas, donde cada capa tiene una interfaz bien definida


VENS

VENS

Un componente es una unidad de código fuente que sirve como un bloque de construcción para la estructura física de un sistema

Estereotipos (con iconos alternativos) pueden ser usados para definir tipos específicos de componentes.

Ejemplos: exe, dll, programas principales, encabezados, módulos, formularios

Las clases que se agrupan en una componente son aquellas que o bien tienen funciones cooperativas o las que necesitan estar en una proximidad cercana por eficiencia de implementación

Notación de un componente: Nombre Componente

¿Qué es un Componente?


VENS

VENS

Nombre 1

Nombre 3

Nombre 2

Nombre 1

Nombre 2

Diagramas de Componente Un diagrama de componente muestra la localización de las clases y

los objetos en la implementación de componentes así como sus dependencias en compilación


VENS

VENS

Diagramas de Componente (cont.)

Se requiere Un nombre para cada componente, este nombre típicamente denota el nombre del archivo físico correspondiente en el área de trabajo de desarrollo

La única relación es una dependencia de compilación, representada por una línea discontinua direccionada que apunta al módulo para el cual existe

En C++, una dependencia de compilación se indica por las directivas #include

No pueden existir ciclos dentro de un conjunto de dependencias de compilación


VENS

VENS

Curriculum

Curso

Curriculum

Curso

Ejemplo: Diagrama de Componente


VENS

VENS

Nombre del paquete

Paquetes en la Vista Componente

Un paquete en la vista componente es una colección de componentes, algunos de los cuales están visibles a otros paquetes y otros están ocultos

Un paquete agrupa componentes que están lógicamente relacionados Un paquete en la vista componente agrupa componentes de modo

similar a los paquetes que en la vista lógica agrupan clases Cada componente en un sistema tiene que vivir en un paquete simple

o al más alto nivel del sistema Notación:


VENS

VENS

MFC Interfaz deregistro deusuario

Sistema deRegistro

Diagramas de Componentes Principales

Un diagrama de componente principal es una familia de paquetes conectados a través de enlaces dirigidos que representan dependencias

Ejemplo:


VENS

VENS

Correspondencia entre Paquetes en las Vistas Lógicas y de Componentes

En general, un paquete en la vista lógica puede corresponder directamente a un paquete en la vista de componentes

Las estructuras lógica y física pueden variar por las siguientes razones:

Los paquetes en la vista lógica son agrupados, es decir, se mantienen a los objetos unidos comunicándose estrechamente para la implementación

Los paquetes en la vista componente son añadidos para implementar la funcionalidad a bajo nivel no representada durante el análisis

La estructura de división del trabajo del equipo de desarrollo influencia la asignación de paquetes y componentes en la vista componentes


VENS

VENS

Ejemplo: Correspondencia entre Paquetes en las Vistas Lógica y de Componente

Diagrama de Vista Lógicade Alto Nivel

Diagrama de Vista Componente de Alto Nivel

MFC Interfaz deRegistro deUsuario

Sistema deRegistro

DispositivoGUI Interfaz de Registro deUsuario

Sistema deRegistro


VENS

VENS

Vista de Proceso

La vista del proceso de la arquitectura se enfoca en el proceso de descomposición

Esta vista muestra la localización de los componentes a procesar El diagrama componente es actualizado para mostrar la localización de

los componentes a procesar La vista proceso se concentra en la disponibilidad del sistema,

confiabilidad, desempeño, administración del sistema y sincronización


VENS

VENS

Especificación del paquete (DLL) Especificación de la tarea (EXE)

Componentes de Proceso

Las bibliotecas ejecutables y vinculadas son representadas mediante componentes en UML

Especificación del paquete (DLL) Especificación de la tarea (EXE)


VENS

VENS

Nombre1Nombre2

Nombre1 Nombre2

MiProceso.exe

Diagrama de Componentes para un Proceso

Cada componente puede depender de otras componentes


VENS

VENS

Procesos para el Sistema de Matrícula de Curso

Curriculum.exe Matrícula.exe

Proceso para la creación y mantenimiento del curriculum

Proceso para la selección de cursospor estudiantes y profesores


VENS

VENS

Vista Implantación

La vista de implantación de la arquitectura mapea componentes con nodos de procesamiento

Requerimientos tales como rendimiento, desempeño y tolerancia a fallos son tomados en cuenta

Los diagramas de implantación se crean para mostrar los diferentes nodos (procesadores y dispositivos) en el sistema


VENS

VENS

El Diagrama de Implantación

Un diagrama de implantación muestra la asignación de componentes a nodos en la vista de implantación de un sistema

Los procesadores y dispositivos son estereotipos comunes de Nodo.

Los nodos se conectan en un diagrama que refleja los caminos de comunicación entre ellos

Los elementos esenciales en un diagrama de implantación son los nodos y sus conexiones


VENS

VENS

nodo conexión

nombre etiqueta

Notación para Diagramas de Implantación

Un nodo es un objeto físico en tiempo de ejecución que representa recursos computacionales

Una conexión indica comunicación, usualmente mediante el acoplamiento directo de hardware


VENS

VENS

Sistema deRegistro

Base de datos

Dormitorios

Bloque Principal

Biblioteca<<dispositivo>>

<<dispositivo>>

<<dispositivo>>

Ejemplo: Diagrama Implantación del Sistema de Registro

Este diagrama muestra dos nodos y los dispositivos con los cuales el sistema de registro se comunica


VENS

VENS

proceso 1, proceso 2, ... proceso n

Nombre delProcesador

Procesos

Un proceso es la ejecución de un hilo de control de un programa (OO) o sistema

Un sistema extenso puede ser dividido en múltiples procesos o hilos de control

Los objetos son asignados a los procesos (sus asignaciones pueden ser dinámicas)

Los procesos son asignados a procesadores (el conjunto de procesos puede ser dinámico)

Notación:


VENS

VENS

Mapeando Paquetes de Desarrollo a Procesos Ejecutables

El mapeo de los paquetes de desarrollo a procesos ejecutables involucra el entendimiento de la topología y las prioridades del sistema, incluyendo:

Arquitectura, velocidad y capacidad del procesador Mantener las asociaciones de clases juntas para minimizar la

comunicación entre procesos (IPC) Estrategia IPC -- ¿cliente/suministrador u otros? Técnicas de Procesamiento Distribuido

Se tienen que resolver las cuestiones que involucren múltiples procesadores de hardware o de sistemas distribuidos, durante el diseño del sistema.


VENS

VENS

Mapeando Procesos Ejecutables al Hardware

Los procesos tienen que ser asignados a un dispositivo de hardware para su ejecución

Entre las consideraciones se encuentran: Tiempo de respuesta y rendimiento del sistema Capacidad y ancho de banda de las comunicaciones Localización física del hardware requerido Requerimientos del procesamiento distribuido Sobrecarga o estabilización del procesador en un sistema

distribuido Tolerancia a fallos . . .


VENS

VENS

Vista Caso de Uso

Los casos de uso son los manipuladores para el diseño arquitectónico Abstracciones de requerimientos complejos, extensos Identificación de interfaces críticas Forzar a los diseñadores a enfocarse en asuntos concretos

Ellos demuestran y validan las vistas de implantación, lógica, de proceso y de desarrollo de la arquitectura


VENS

VENS

La “Vista 4+1” de un Modelo UML

Vista Componente

Vista Proceso Vista Implantación

Vista Caso de Uso

Vista Lógica

Diagramas de clases,Diagramas de secuencia Diagramas de

Componentes

Diagramas de implantación Diagramas de implantación

Diagramas Casos de Uso,Diagramas de Secuencia


VENS

VENS

¿Cómo está la Arquitectura Documentada?

La arquitectura está documentada en un documento de arquitectura Aproximadamente 100 páginas para un sistema extenso

El documento incluye: Una descripción textual de la filosofía arquitectónica (las vistas) y

los requerimientos claves de manejo Balances hechos y alternativas consideradas Una vista de alto nivel de la vista lógica (paquetes y clases

claves) Escenarios específicos a arquitecturas Vistas de desarrollo, de procesos a alto nivel y vistas de

implantación Los mecanismos claves


VENS

VENS

¿Quién Desarrolla la Arquitectura de Software?

Lo hace el equipo de arquitectura: un grupo de los mejores y más experimentados desarrolladores

Se establece al principio en el proyecto (no después de la fase de elaboración)

La mayoría de los proyectos de una complejidad razonable requieren de un equipo de arquitectura, no de simplemente un único arquitecto

Dirigido por el arquitecto jefe quien estará 100% dedicado Incluye los guías para los diseñadores de las funciones

principales y de las funciones críticas del sistema


VENS

VENS

Evolución del Equipo de Arquitectura

Fase de Elaboración

Fase de Construcción

Equipo de Arquitectura•Arquitecto•Diseñadores guias•Desarrolladores de infraestructura

Equipo de Arquitectura•Arquitecto•Grupo pequeño de apoyo

Equipo 1 de la Aplicación•Diseñador guia•Ingenieros de aplicación

Equipo 2 de la Aplicación•Diseñador guia•Ingenieros de aplicación

.

.

.

En la fase de elaboración, los miembros están 100% dedicados al equipo de arquitectura. Durante la construcción, los miembros se convierten en diseñadores guias de los equipos de aplicación y apoyan parcialmente al equipo de arquitectura


VENS

VENS

Con una buena arquitectura, un equipo de desarrollo promedio puede tener éxito. Con una arquitectura débil,

inclusive los desarrolladores más expertos no tendrán éxito

Beneficios de un Equipo de Arquitectura

Entregables Documento de Arquitectura Partes de los documentos de diseño de bajo nivel Guías para el diseño y la programación Elementos de los planes de puesta en circulación Revisión del diseño del sistema entregado

La eficacia y habilidades del equipo de arquitectura son críticas para el éxito de un proyecto


VENS

VENS

Ejercicio: Diseño arquitectónico

Discutir las consideraciones de la arquitectura para el problema Añadir modelos al paquete mientras sea requerido

Reubicar clases en los diferentes paquetes mientras sea requerido


VENS

VENS

Resumen: Diseño Arquitectónico

El propósito de esta fase es crear una arquitectura para la implementación y establecer las políticas tácticas comunes que tienen que ser usadas a lo largo del sistema

Los atributos de las buenas arquitecturas son: Las buenas arquitecturas son construidas en capas de

abstracción bien definidas Existe una separación clara entre la interfaz y la implementación

de cada capa La arquitectura es simple


VENS

VENS

Resumen: Diseño Arquitectónico (cont.)

La vista lógica de la arquitectura se concentra en los requerimientos funcionales del sistema

Los diagramas de clases los cuales representan las abstracciones claves del sistema

La vista proceso de la arquitectura se concentra en la disponibilidad, confiabilidad, escalabilidad, integridad, desempeño, administración y sincronización del sistema

El sistema se descompone en un conjunto de tareas independientes las cuales se agrupan en procesos

La vista componente de la arquitectura se concentra en la organización del software del sistema

Los diagramas de componentes se crean para mostrar los paquetes y componentes que conforman el sistema


VENS

VENS

Resumen: Diseño Arquitectónico (cont.)

La vista de implantación de la arquitectura mapea el software con los nodos de procesamiento

Los diagramas de implantación son creados para mostrar los diferentes procesadores y dispositivos en el sistema

Los casos de uso demuestran y validan las vistas lógica, de proceso, desarrollo y de implantación de la arquitectura


VENS

VENS

Mecanismos Claves


VENS

VENS

Objetivos: Mecanismos Claves

Ser capaz de: Describir algunos mecanismos claves específicos a OO Explicar los aspectos asociados con la interfaz de base de datos Listar algunas consideraciones para la evaluación de los sistemas de

administración de bases de datos Describir el manejo de excepciones y sus tópicos asociados Explicar los aspectos asociados con la comunicación entre procesos


VENS

VENS

¿Qué son los Mecanismos Claves?

Un mecanismo clave es una decisión estratégica teniendo en cuenta estándares, políticas y prácticas comunes. Por ejemplo:

Una propuesta común para el manejo de errores, o Una forma común de comunicación entre procesos

La mayoría de los principios del diseño de software tradicional aún se aplican en el diseño OO

Los problemas a ser resueltos son similares, como por ejemplo, la contención de recursos, la atenuación de riesgos y otros

Se producen algunas diferencias debido a: Soluciones que siendo estructuradas usan métodos OO Las características de los lenguajes de programación OO


VENS

VENS

Mecanismos Claves Comunes

Administración de la contención de recursos Manipulación especial requerida para el arranque y término del sistema Integración con los sistemas de almacenamiento de datos persistentes Detección, manipulación y reporte de errores Comunicación entre procesos Pase de mensajes Aspecto y sensación de la interfaz de usuario Reuso del software


VENS

VENS

Contención de los Recursos

Una clase administradora de recursos podrá ser usada para controlar el acceso a los recursos

La clase administradora utiliza métodos de software tradicionales, tales como semáforos para controlar el acceso a sus recursos

El administrador provee operaciones para permitir a los clientes de los recursos adquirirlos, liberarlos, ponerlos en cola para adquirirlos, obtener sus estado, etc

Una superclase que contiene la interfaz a los recursos administrados puede ser suministrada con el administrador de recursos para mejorar su reusabilidad


VENS

VENS

Contención de los Recursos (cont.)

Fichero MemoriaCompartida

AdministradorRecurso

adquiere ()libera ()

RecursoAdministrado

1..*1 1..*1


VENS

VENS

Arranque y Término del Sistema

Si ya no se ha cubierto durante el análisis, deberán ser definidos los casos de uso, tanto para el arranque como para el término del sistema

Los escenarios deberán ser desarrollados para cada caso de uso - tantos como sean requeridos para la manipulación de todas las principales situaciones, tanto normales como atípicas

Durante este proceso nuevos estados y conductas pueden ser descubiertos para las clases existentes y puede originarse la necesidad de nuevas clases para controlar el arranque y término del sistema


VENS

VENS

Objetos Persistentes

Un objeto persistente es aquel que existe lógicamente más allá del alcance del programa que lo creó

Los lenguajes de programación OO tratan solamente con los objetos esencialmente transitorios, residentes en memoria

Un objeto persistente tiene la capacidad de guardar los valores de sus atributos en algún tipo de almacenamiento persistente

Un objeto persistente puede también ser creado en memoria e inicializado con sus valores de atributos desde un almacenamiento persistente

La estrategia completa para proveer persistencia a los objetos en el sistema, es un mecanismo clave


VENS

VENS

Almacenamiento Persistente

El almacenamiento persistente puede hacerse usando un sistema de archivo simple o algún tipo de sistema de administración de base de datos

Existen varios modelos para DBMSs: Jerárquico En red Relacional (RDBMS) Orientado a objeto (ODBMS)

El Relacional y el ODBMSs son los más comunes


VENS

VENS

Seleccionando una Propuesta para la Persistencia

La estrategia de diseño para retener objetos persistentes tiene que considerar

Tiempos de acceso Capacidad de almacenamiento Confiabilidad en los sistemas de almacenamiento Accesos a datos existentes

El modelo seleccionado influencia al sistema y al diseño de objetos en que los diseñadores tienen que considerar:

Métodos adicionales de objetos para almacenar y obtener los objetos persistentes

Adición de atributos para manipular detalles del sistema de almacenamiento

Clases adicionales para interactuar con el DBMS


VENS

VENS

Criterio de Evaluación del DBMS

El criterio de evaluación para seleccionar un DBMS debe ser decidido desde el inicio

Las siguientes transparencias contienen criterios encontrados en “Consideraciones Para la Evaluación de Sistemas de Administración de Bases de Datos Objetos” por Robert Gancarz y Grant Colley, Object Magazine, Marzo/Abril 1992

Estos criterios también se aplican para la selección de un sistema de administración de bases de datos relacionales


VENS

VENS

Fortalezas del proveedor Considerar la fortaleza financiera, la estructura de la

organización, los procedimientos de apoyo al cliente, el entrenamiento y apoyo a consultas y asociaciones con otras compañías

Desempeño de la Base de datos Ningún estándar de comparación de rendimiento puede probar

que la DBMS es la más rápida para todas las aplicaciones El desempeño depende de la aplicación

Son muy importantes los prototipos específicos de la aplicación

Potencial de las Bases de datos La administración de transacciones, el control de concurrencia,

resguardos y recuperaciones, la seguridad y los lenguajes de consulta respaldan las capacidades que deben ser evaluadas

Criterio de Evaluación de un DBMS (cont.)


VENS

VENS

Criterios de Evaluación del DBMS (cont.)

Arquitectura de la Base de datos Evaluar los esquemas de control de concurrencia, los

mecanismos de bloqueo y los administradores de almacenamiento

Herramientas de desarrollo Seleccionar las herramientas para el diseño de la base de datos,

la modificación del esquema de la base de datos y la navegación y depuración de la base de datos

Ayuda del lenguaje Asegurar que exista ayuda en el lenguaje seleccionado para el

sistema que está siendo desarrollado Facilidad de migración

Cuán fácil/difícil es migrar hacia el sistema de base de datos


VENS

VENS

En el fondo: Invertir el tiempo y energía para seleccionarel sistema de administración de bases de datos adecuadopara el proyectoEs SIEMPRE más caro corregir un error que hacer las cosas correctas desde la primera vez !!!

En el fondo: Invertir el tiempo y energía para seleccionarel sistema de administración de bases de datos adecuadopara el proyectoEs SIEMPRE más caro corregir un error que hacer las cosas correctas desde la primera vez !!!

Criterio de Evaluación del DBMS (cont.)

Integración con Sistemas Existentes Cuán fácil/difícil es la integración con los sistemas de

administración de bases de datos existentes Soporte multiusuario

Evaluar el soporte para el desarrollo multiusuario, la administración de configuración, diferentes versiones y estrategias de bloqueo


VENS

VENS

Aspectos de las Bases de Datos Relacionales

Hay dos aspectos principales a contemplar cuando se diseña un sistema OO usando una base de datos relacional

Existe una diferencia semántica natural entre el modelo basado en clases, de un diseño orientado a objeto y el modelo basado en tablas de una base de datos relacional

Un mapeo o traducción entre ambos tiene que ser definido La conducta que interactúa con el RDBMS y la implementación de esta

traducción tienen que estar definidas ¿Deberá esta conducta estar insertada en objetos persistentes o

de algún modo ser mantenida separada?


VENS

VENS

Mapeos más complicados son posiblesOne class maps to multiple tablesMultiple classes map to one table

Cliente

nombredireccióndescuento

Tabla del Cliente

clienteID nombre dirección descuento

Mapeo a Bases de Datos Relacionales

Típicamente, cada clase mapea con una tabla y cada instancia mapea con una fila.


VENS

VENS

Tabla Orden

ordenID entrega urgencia clienteID

Tabla Cliente

Cliente

nombredireccióndescuento

Orden

tiempoEntregaurgencia

0..*

11

0..*

clienteID nombre dirección descuento

Mapeo a Bases de Datos Relacionales(cont.)

Las relaciones uno-a-muchos se implementan usando una llave externa en la tabla representando el lado “muchos” de la relación


VENS

VENS

Tabla Ingrediente del Producto

productoID ingredienteID

Producto

Ingrediente

1..*

0..*

1..*

0..*

Mapeo a Bases de Datos Relacionales (cont.)

Las tablas se crean para resolver relaciones muchos-a-muchos


VENS

VENS

Tabla Orden

ordenID fechaEntrega urgencia

ordenID fechaFin fechaInicio

Tabla OrdenEspecial

Orden

fechaEntregaurgencia

OrdenEspecial

fechaIniciofechaFin

OrdenPendiente

frecuencia


Las superclases / subclases pueden también ser mapeadas a tablas Cada clase y subclase es una tabla Las vistas son provistas para la jerarquía


VENS

VENS


Existen estrategias alternativas para las superclases y subclases Repetir todos los atributos en la tabla superclase

Problema: espacio desperdiciado Repetir todos los atributos en la tabla subclase

Problema: redundancia Desempeño versus balanceo del espacio de almacenamiento se usan

para decidir qué mapeo usar en situaciones de herencia


VENS

VENS

Interactuando con RDBMS

El principal aspecto asociado con la interacción con un RDBMS es si separar la conducta específica de la aplicación de la conducta específica de la base de datos

Suponga que nuestro sistema tiene una clase Cliente la cual hemos decidido que debe ser persistente

¿Debe la clase cliente contener los detalles de mapeo OO-a-RDBMS?

¿Debe la clase Cliente contener el funcionamiento para interactuar con el agente RDBMS (es decir, código que genere SQL para leer/escribir desde/hacia la base de datos?

¿Debe la clase Cliente inclusive saber que ésta es persistente? Cualquier modo puede funcionar - cada uno tiene sus propias ventajas

y desventajas


VENS

VENS

Interactuando con RDBMS (cont.)

La conducta específica a la base de datos no separada de la conducta específica a la aplicación:

Cada clase persistente puede tener incorporada funcionalidades de crear, leer, actualizar y borrar (CRUD) (es decir, operaciones que ejecuten mapeos OO-a-RDBMS y generen SQL para implementar esto)

Ventajas Ningún reto técnico para implementarlo

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

heredable


VENS

VENS

Conducta de la Base de Datos dentro de la Clase

: AdministradorCurriculum : Curso

1: guardar ( )

Curso

descripción

guardar ()El Curso tiene que tenerconocimiento de la base de datos

El Curso tiene que tenerconocimiento de la base de datos


VENS

VENS

Interactuando con RDBMS La conducta específica a la base de datos se separa de la conducta

específica de la aplicación El sistema puede ser modelado en dos partes: la Aplicación y la

Interfaz con la Base de datos Para cada clase persistente, se define una clase de interfaz

de base de datos asociada la cual entiende el mapeo OO-a-RDBMS y tiene la funcionalidad para interactuar con el RDBMS

Ventajas El modelo OO es separable del modelo RDBMS Las herramientas están disponibles para generar las clases

básicas de interfaz con la base de datos Desventajas

Un reto técnicamente mayor de implementación


VENS

VENS

: AdministradorCurriculum : AdministradorTransacción

: CursoBD : Curso

1:guardarCurso (Curso)

2: guardar(Curso)3: obtenerDescripcion ( )

4: hacerPersistente ( )

El AdministradorTransacciónsepara lo lógico (Curso)de lo físico (CursoBD)

El AdministradorTransacciónsepara lo lógico (Curso)de lo físico (CursoBD) Curso

AdministradorTransacción

CursoBD

Separar la Conducta de la Base de Datos


VENS

VENS

DBMSs Orientados a Objetos

ODBMSs permiten almacenamiento, recuperación y restablecimiento de los propios objetos (con datos complejos encapsulados dentro de cada objeto)

Un ODBMS típicamente contiene Objetos (es decir, valores de atributos) Información de clase sobre cada objeto

No hay diferencia semántica entre el modelo OO y el modelo ODBMS - ellos son idénticos

Ningún funcionamiento especial tiene que ser diseñado para interactuar con el ODBMS


VENS

VENS

DBMSs Orientados a Objetos (cont.) Ventajas:

Interfaz no fundida entre la aplicación y la base de datos Relativamente poco código requerido para crear objetos

persistentes Muy efectivo con sistemas que tienen que contemplar estructuras

de datos complicadas Desventajas:

Mayor riesgo de desarrollo mientras la tecnología ODBMS y sus productos no estén tan maduros como sus contrapartes RDBMS

Desempeño con estructuras de datos más simples no provee ventajas sobre RDBMS

Las inversiones existentes en tecnología relacional, tienen que ser consideradas cuando se vaya a evaluar tecnología de bases de datos orientada a objetos


VENS

VENS

Detección de Errores

Una propuesta consistente para la detección de errores debe ser establecida

Los objetos deben detectar los errores que violarían sus integridades - estos errores son:

Los producidos dentro de sus operaciones Los resultantes de parámetros recibidos de objetos clientes Los resultantes de valores retornados provistos por los objetos

suministradores Un plan puede ser establecido para monitorear la salud del sistema

Operación de prueba para cada clase que verifique la integridad de la estructura interna y del entorno

Monitoreo de objetos definido para, periódicamente, consultar cada función de prueba del objeto


VENS

VENS

Manejo de Errores

Inclusive en los sistemas OO, el manejo de errores tiene que ser cuidadosamente diseñado -- más del 30% del código final frecuentemente existe para manipular condiciones de errores

Los lenguajes modernos OO (tales como C++ ) proveen características para el manejo de excepciones que ayudan en este diseño

El manejo de excepciones permite que un error sea manipulado por un objeto fuera del objeto que detectó el error

Esto es frecuentemente apropiado, debido a que el amplio impacto de un error en el sistema no es siempre conocido por el objeto que lo detecta


VENS

VENS

class String {public: class RangeError { int badIndex; }; // error type char getChar(int index) const; // ...};char String::getChar(int index) const { if (index < 0 || index > lastValid) throw RangeError(index); // throw point return contents[index];};void foo() {

try { String s = “hello”; char c = s.getChar(0); } catch (const String::RangeError& why) { // catch point cout << “subscript out of range” << why.badIndex << endl; }}

Ejemplo del Manejo de Excepciones


VENS

VENS

Lanzando y Capturando Excepciones

Cuando hay un problema que no puede ser manejado en el contexto actual, una excepción puede ser creada y “lanzada”

lanzar Problema(“las cosas están mal”); ¿Qué hace lanzar?

El objeto excepción es creado y “retornado” ¿A dónde va el objeto excepción?

Cuando una excepción se lanza, en la pila de llamadas se busca el primer manipulador que machee

Habrá un manipulador de excepción por cada tipo de excepción que pudiera ser capturada

catch (Problem&) {

// maneja excepciones del tipo Problem}


VENS

VENS

Aspectos del Manejo de Excepciones

En el proceso de búsqueda en la pila de llamadas, destructores para objetos locales son llamados para

Variables Automáticas Parámetros por valor Valores temporales

Destructores no se llaman para Variables Dinámicas Variables Estáticas

El código después del punto de lanzamiento nunca es ejecutado Las excepciones se atribuyen administración de recursos (por ejemplo,

el cierre de ficheros abiertos)


VENS

VENS

¿Deben Siempre ser Usadas las Excepciones?

Las excepciones no deben ser usadas en las siguientes situaciones: Condiciones de errores comunes

Si hay suficiente información disponible para manejar el error, entonces esto NO es una excepción

Para controlar el flujo del programa Una excepción NO es un retorno alternativo


VENS

VENS

¿Cuándo Deben Ser Usadas Las Excepciones?

Las excepciones son lanzadas como resultado de un error grave No hay retorno al punto donde fue lanzada la excepción

Las excepciones no deben ser usadas si el error puede ser manejado (corregido) y el procesamiento puede continuar

Una operación puede ser llamada para “reparar” el problema y el procesamiento puede continuar


VENS

VENS

Usos Típicos de las Excepciones

Reparar el problema y continuar el procesamiento sin volver a la función que lanzó la excepción

Calcular un resultado alternativo Lanzar el error a un contexto mayor Terminar el programa Agrupar funciones que usan esquemas de errores comunes Simplificar el código Hacer el código más fácil de mantener


VENS

VENS

Reportando los Errores

Mantener registrado el error respectivo y reportar on-line son claves para la mayoría de los sistemas

Una conducta consistente en el reporte de errores puede ser implementada en la clase de error básica usada en el manejo de excepciones

Esta conducta puede incluir Añadir el error a un registro de errores de alcance a todo el

sistema Distribuir el error para el procesamiento, el cual facilita el

monitoreo de errores on-line Este tipo de propuesta asegura consistencia a la vez que separa la

responsabilidad detallada de las clases de la aplicación


VENS

VENS

ClaseA ClaseB

functionB( )

: ClaseA : ClaseB

1: functionB ( )

Comunicación entre procesos

ClaseA llama a una operación de la ClaseB, functionB() ¿Qué sucede cuando ClaseA y ClaseB están en procesos diferentes? Esto se convierte en un aspecto crítico en los sistemas distribuidos Se requiere un mecanismo estándar para la comunicación


VENS

VENS

Comunicación entre Procesos(cont.)

Una solución común que soporta el paradigma OO ha sido desarrollada

Las clases Proxy se insertan en cada proceso el cual provee las interfaces de las clases originales y encapsula la comunicación a más bajo nivel

La distribución es transparente a las clases de la aplicación


VENS

VENS

Estándares Distribuidos OO

Seleccionar un estándar de distribución es un asunto de diseño si el sistema usa objetos distribuidos

Hay dos estándares emergiendo para la distribución OO Common Object Request Broker Architecture (CORBA) Component Object Model (COM/OLE) Java Beans

Object Request Brokers (ORB) provee acceso transparente a objetos en un medio distribuido

ORB permite conectividad cliente/servidor independiente de la ubicación

Las decisiones de distribución pueden ser tomadas en tiempo de ejecución


VENS

VENS

Clases Proxy

ClaseA ClienteProxyB

Object Request Broker

ServidorProxyB ClaseB


VENS

VENS

Planificando para el Reuso

Los componentes reusables tienen que ser considerados al inicio en el diseño para su incorporación al sistema

Evaluar bibliotecas de software internas, comerciales para módulos que apliquen en el sistema

Las bibliotecas de clases son grupos de clases colaborando que proveen algún servicio, interfaz o función

Las bibliotecas de clases están comúnmente disponibles para: Objetos contenedores Interfaces a bases de datos Ventanas de interfaz de usuario


VENS

VENS

Actualizando Diagramas

Los diagramas de clases se actualizan para mostrar los mecanismos claves seleccionados

Los diagramas de secuencias se actualizan para mostrar interacción entre las clases ya descubiertas y las clases que representan las estrategias de mecanismos claves


VENS

VENS

Diagrama de Clase Actualizado

Equipos de Universidad

Interfacesde entrada

Reglas delnegocio

Interfaces de salida

Base de datos

VentanasGUI

Basamento

global

Manejo de errores

global


VENS

VENS

Diagrama de Secuencia Actualizado

anOffering : (Course : Registrar

aForm : CurriculumMgr

theCourse : Course

dbMgr : TransactionMgr

dbCourse : DBCourse

dbOffering : DBOffering

theManager : CurriculumMgr

1: open

2: enter id

3: verify id

5: create a

4: enter

12: create(professor, time,

6: set number, name, description,

7: set number offerings, professor,

8: process

9: create course(number, name, description, credit hours, offerings,

10: create(number, name, description,

11: create offering(number, pofessor,

13: save 14: save(course)

15: get info

16: commit

17: save(offering)

18: get info

19: commit


VENS

VENS

Ejercicio: Mecanismos Claves

Discutir las estrategias de mecanismos claves para el problema Actualizar los diagramas de clases para mostrar la incorporación de los

mecanismos claves Actualizar los diagramas mientras sea necesario


VENS

VENS

Resumen: Mecanismos Claves

La selección de los mecanismos claves se enfocara en las decisiones respecto a estándares, políticas y prácticas comunes, incluyendo:

Administración de la contención de los recursos Manipulación especial requerida para el arranque y la

terminación de los sistemas Integración con sistemas de almacenamiento de datos

persistentes Detección / manejo / reporte de errores Comunicación entre procesos Reuso del software


VENS

VENS

Diseñando Clases


VENS

VENS

Objetivos: Diseñando Clases

Ser capaz de: Discutir las decisiones de diseño de la interfaz de usuario Añadir clases para resolver los problemas de diseño Usar patrones para resolver problemas de diseño


VENS

VENS

Diseño de la Interfaz de Usuario

Las clases fronteras administran la interfaz de las comunicaciones entre el usuario y el sistema

Ellas proveen la capacidad de enviar y recibir información desde fuera del sistema

Durante el análisis, las clases fronteras de alto nivel son identificadas Durante el diseño, el diseño de la interfaz de usuario se completa

Diseño de la ventana Número de ventanas Manipulación de eventos de usuarios


VENS

VENS

Descubriendo los Requerimientos de Interfaz

Cualquier prototipo de interfaz de usuario hecho anteriormente es un buen punto de partida para esta fase del diseño

Los diagramas de colaboración y/o secuencia también proveen una buena fuente para los requerimientos de interfaz

Algo en el sistema tiene que proveer la capacidad de recibir todos los “mensajes” que vengan de un actor

Algo en el sistema tiene que proveer la capacidad de enviar todos los “mensajes” que van hacia un actor


VENS

VENS

Diagrama de Secuencia para la Creación de un Escenario de Curso

anOffering : (Course : Registrar

aForm : CurriculumForm

theCourse : Course

dbMgr : TransactionMgr

dbCourse : DBCourse

dbOffering : DBOffering

theManager : CurriculumMgr

1: open2: enter id

3: verify id

5: create a

4: enter

12: create(professor, time,)

6: set number, name, description,

7: set number offerings, professor,

8: process

9: create course(number, name, description, credit hours, offerings,)

10: create(number, name, description,)

11: create offering(number, professor,)

13: save 14: save(course)

15: get info

16: commit

17: save(offering)

18: get info

19: commit


VENS

VENS

Requerimientos de la Interfaz de Usuario

Actor “Registrador” Entrar la información requerida para crear un curso y sus ofertas

Requerimientos desde otros escenarios El actor tiene la capacidad de crear cursos, crear ofertas, revisar

cursos, revisar ofertas de cursos, modificar cursos, modificar ofertas de cursos, borrar cursos, borrar ofertas

Decisiones de diseño Una ventana contiene todas las opciones disponibles a Registrar Una ventana contiene información del curso Una ventana contiene información de la oferta Botones disponibles en las ventanas de curso y oferta para

permitir que la información sea salvada, cancelada o borrada


VENS

VENS

Ventana Principal de Opciones Registrar


VENS

VENS

Ventana Curso


VENS

VENS

Ventana Oferta de Curso


VENS

VENS

Matrícula de Cursos

John : estudiante

Formulario de matrícula

cursos disponibles

Formulario dehorarios

1: entrar id

2: validar id

3: entrar semestre actual

4: crear nuevo horario

5: mostrar

6: obtener cursos

7: seleccionar


VENS

VENS

Interfaz del Sistema de Registro Requerimientos para este Escenario

Actor estudiante Tiene que ser provisto con un medio de selección de cursos para

el sistema actual La lista de los cursos disponibles es mostrada al actor

Decisión de diseño Una ventana GUI se crea para contener cuadros de listas (list

boxes) para las selecciones de los cursos Los cuadros de listas contienen los nombres de todos los

cursos ofrecidos


VENS

VENS

Ventana de Registro de Curso


VENS

VENS

¿Que Sucede Cuando se Hace Click Sobre el Botón OK?

Todos los constructores GUI son diferentes Algunos crean objetos que contienen la información desde la

ventana Otros crean estructuras de datos con la información

Algunas técnicas comunes Las clases de control reciben los datos desde la ventana GUI y

los procesan Los datos de la ventana son pasados desde la ventana GUI

a la clase de control

ó El botón sabe qué hacer con el dato en la ventana


VENS

VENS

FuncionesMatemáticas<<utility>>

Clase Utility

El estereotipo utility se usa para una clase que contiene una colección de subprogramas libres

Los subprogramas libres son funciones no miembros, es decir, funciones que no pertenecen a una clase en particular

Las clases Utility son usualmente definidas para Proveer algunos servicios algorítmicos comunes, servicios que

pueden ser útiles en una variedad de contextos Agrupar bibliotecas no orientadas a objetos o aplicaciones


VENS

VENS

Curso

1..*1

AdministradorMatrícula<<control>>

1..*1

Scheduling Algorithms<<utility>>

1

0..*

1

0..*

Ejemplo: Clase Utility

La clase utility “SchedulingAlgorithms” contiene funciones que resuelven conflictos de horarios


VENS

VENS

extern float inchToCentimeter(float inch);

extern float centimeterToInch (float centimeter);

Usando Funciones Libres Usando la Clase Utility C++ (recomendado)

#ifndef UNIT_UTILITIES#define UNIT_UTILITIES

class/*_utility*/ Unit_Utilities {public: static float inchToCentimeter(float inch); static float centimeterToInch(float centimeter);};

#endif // UNIT_UTILITIES

Ejemplo: Clase Utility (cont.)

Para evitar que múltiples utilidades (funciones libres C++) se conviertan en unidades separadas, una clase utility puede ser creada para empacar todas las funciones bajo una interfaz


VENS

VENS

Clases de Ayuda

Durante el diseño, una clase puede ser añadida para “ayudar” a ejecutar alguna funcionalidad requerida

Ejemplo: El FormularioCurriculum tiene que verificar que el id entrado sea

válido Si la verificación tiene que ver solamente con el formato del

id, entonces la ventana puede ejecutar esta funcionalidad Si la verificación tiene que ver con la seguridad, entonces

información adicional es requerida Lista de números id válidos Esta clase es añadida al sistema


VENS

VENS

El Surgimiento de Patrones

Un patrón de diseño es una solución para un problema de diseño común

Un patrón Describe un problema de diseño común Describe la solución del problema Discute los resultados y el balance de aplicar el patrón

Los patrones están siendo recopilados, catalogados, y usados para construir sistemas

Proveen la capacidad de reusar arquitecturas y diseños exitosos Conducen a sistemas más fáciles de mantener Incrementan la productividad


VENS

VENS

Adaptación de Patrones

Los sistemas de registros de cursos tienen tres tipos de usuarios: los estudiantes, profesores y el que registra

Una jerarquía UsuarioRegistro fue creada para los diferentes tipos de usuarios

El tipo de usuario a crear depende del dato entrado en una ventana GUI

Problema: ¿Quién crea el tipo específico de usuario? El patrón Factory Method puede ser usado para crear el tipo

adecuado de usuario basado en datos en tiempo de ejecución Al factory le son dados los datos y se le dice cómo crear el

tipo correcto de objeto


VENS

VENS

El Patrón Factory

La operación crea(que) del UsuarioFactory crea el tipo adecuado de UsuarioRegistrar

La operación crea(que) del UsuarioFactory crea el tipo adecuado de UsuarioRegistrar

Estudiante Profesor Registrar

UsuarioFactory

crea (qué)

UsuarioRegistrar

11

crea

11


VENS

VENS

Otros Ejemplos de Patrones

Prototipe -- crea un objeto mediante la copia de un objeto prototípico Unico (singleton) -- asegura que una clase tiene solamente una

instancia y brinda un punto global de acceso a esta Adaptador -- convierte la interfaz de una clase a otra interfaz Iterador -- provee una forma de acceder a los elementos de un objeto

agregación Memo -- captura y exterioriza un estado interno del objeto para que el

objeto pueda ser recuperado a este estado después (esto se hace sin interrumpir la encapsulación)


VENS

VENS

Principios a considerar: Una clase debe tener un simple pero bien enfocado propósito. Una clase debe hacer solo una cosa y hacerla bien!!!

Principios a considerar: Una clase debe tener un simple pero bien enfocado propósito. Una clase debe hacer solo una cosa y hacerla bien!!!

¿Cuántas Clases son Requeridas?

Muchas clases simples significa que cada clase Encapsula menos de la inteligencia total del sistema Es más reusable Es más fácil de implementar

Unas pocas clases complejas significa que cada clase Encapsula una gran parte de la inteligencia total del sistema Es menos probable que sea reusable Es más difícil de implementar


VENS

VENS

Ejercicio: Clases en el Diseño

Discuta clases adicionales que pudieran ser añadidas al modelo para facilitar decisiones de diseño

Actualice los diagramas si es necesario


VENS

VENS

Resumen: Clases en el Diseño

Durante el diseño, clases son añadidas para facilitar el diseño del sistema

Una clase utility es una colección de subprogramas libres Un patrón de diseño es una solución a un problema de diseño común Los patrones están siendo recopilados, catalogados y usados para

construir sistemas Brindan la capacidad de reusar arquitecturas y diseños exitosos Conducen a sistemas más fáciles de mantener Incrementan la productividad


VENS

VENS

Diseñando Relaciones



VENS

VENS

Objetivos: Diseñando Relaciones

Ser capaz de: Determinar la navegación de la relación Refinar las asociaciones y relaciones de agregación Discutir opciones de la visibilidad de objetos Discutir decisiones de diseño múltiples Diseñar clases asociación


VENS

VENS

El Cliente puede “hablar” a la OrdenLa Orden no puede “hablar” al

Cliente

El Cliente puede “hablar” a la OrdenLa Orden no puede “hablar” al

Cliente

Cliente Orden

0..*0..*

Navegación En análisis, las asociaciones son bidireccionales En diseño, una asociación puede ser unidireccional

Se añade una flecha a la asociación para mostrar que la navegación va solamente en una dirección


VENS

VENS

Decisiones de Navegación

Durante el diseño nosotros miramos si es realmente necesario navegar en ambas direcciones

La necesidad para la navegación es reflejada por los casos de usos y los escenarios

Dada una instancia de la clase A, ¿nosotros necesitamos encontrar todas las instancias asociadas de la clase B?

Dada una instancia de la clase B, ¿nosotros necesitamos encontrar todas las instancias asociadas de la clase A?


VENS

VENS

Proveedor Producto

1..*1..* 1..*1..*

Interrogantes de la Navegación

El sistema tiene que responder preguntas tales como: ¿De qué “proveedor” puedo yo obtener este “producto”?

(producto a proveedor) ¿Qué “productos” son suministrados por un “proveedor” en

particular? (proveedor a producto)


VENS

VENS

La Navegación en Ambos Sentidos vs. La Navegación en un Sentido

Las relaciones en los dos sentidos son más difíciles y costosas de implementar que las relaciones en un solo sentido

Inclusive si la navegación en ambos sentidos se requiere, una relación de un solo sentido pudiera bastar bajo ciertas circunstancias. Por ejemplo:

La navegación en una de las direcciones es muy poco frecuente y no tiene rigurosos requerimientos de desempeño, o

El número de instancias de una de las clases es muy pequeño


VENS

VENS

Proveedor Producto

1..*1..*

Ejemplo: Simplificando una Relación Situación 1: Yo frecuentemente necesito saber qué proveedores

suministran un cierto producto pero, solamente necesito conocer la lista de todos los productos suministrados por un proveedor una vez al trimestre para procesar las facturas

Implementar la dirección producto-a-proveedor y buscar todas las instancias de productos cuando recopile una lista de productos para cada proveedor

Situación 2: Solamente existen dos proveedores Implementar solamente la dirección producto-a-proveedor y

buscar todos los productos registrados cuando yo requiera recorrer la relación en el sentido opuesto.


VENS

VENS

Orden

1..*

OrdenItem

Navegación para Agregaciones

Una agregación puede también ser unidireccional durante el diseño Un flecha se añade para la línea de agregación


VENS

VENS

Perfeccionamiento de las Agregaciones

Una relación de agregación significa que el objeto fuente tiene que contener conocimiento semántico del objeto blanco o destino

Las relaciones pueden ser de dos tipos: Por referencia Por valor


VENS

VENS

Implicaciones por Valor y por Referencia

Por valor significa que los objetos se crean y se destruyen como una consecuencia de la creación y destrucción de otro objeto

En otras palabras, los tiempos de vida de los objetos relacionados son iguales

Por referencia significa que los tiempos de vida de los objetos relacionados pueden ser independientes

Por tanto, la selección de por valor o por referencia determina cómo la creación y la destrucción de los objetos será diseñada en C++


VENS

VENS

CursoCatálogo

1..*1..*

Relaciones por Referencia

Las relaciones por referencia denotan tiempos de vida independientes Mostradas como un diamante no relleno


VENS

VENS

BotónOKVentanaSelecciónCurso 1 111

Relaciones por Valor

Las relaciones por valor indican tiempos de vida dependientes Crear el objeto, entonces crear el objeto relacionado Eliminar el objeto, entonces eliminar el objeto relacionado

Por ejemplo, cuando se crea la VentanaSeleccionCurso, se crea el BotónOK


VENS

VENS

Un objeto Cliente depende de un objeto ServidorUn objeto Cliente depende de un objeto Servidor

Cliente Servidor

Relaciones de Dependencia

Una relación de dependencia significa que una clase depende de otras clases para algunos servicios

Una relación de dependencia se dibuja como una flecha de líneas discontinuas


VENS

VENS

Relaciones de Dependencia (cont.)

Una relación de dependencia indica o bien que: Las operaciones de la clase cliente crean objetos de la clase

servidor Las operaciones de la clase cliente tienen firmas cuyos

argumentos o retorno de la clase son instancias de (o referencias a) la clase servidor


VENS

VENS

#include “BillingSystem.h”void RegistrationManager::process(){ BillingSystem theInterface; …}

Las Operaciones Crean Objetos de la Clase Servidor

RegistrationManager

process ()

BillingSystem


VENS

VENS

Objetos de la Clase Servidor como Argumentos de Operación

TransactionManager

saveCourse (Course&)

Course

class Course;class TransationManager { public: … void saveCourse(Course&); private: …};


VENS

VENS

Yo puedo ver . . .

Visibilidad de los Objetos

Las relaciones proveen un camino para la comunicación entre objetos Para que los objetos puedan “hablar” ellos tienen que estar visibles

La visibilidad de un objeto determina el diseño de una relación


VENS

VENS

Opciones de Visibilidad de los Objetos

Hay cuatro opciones de visibilidad Global

El objeto servidor es un objeto global Parámetro

El objeto servidor es un parámetro a una operación en el objeto cliente

Local El objeto servidor es declarado localmente

Campo El objeto servidor es un campo en el objeto cliente


VENS

VENS

Diagrama de Clase Diagrama de Colaboración

CurriculumController

createCourse ()

TransactionManager

saveCourse (Course)

1

1

: CurriculumController

: TransactionManager

1: saveCourse (Course)

Modelo de Análisis

La operación createCourse() de CurriculumController le pide al TransactionManager que salve un nuevo objeto Course


VENS

VENS


createCourse ()

TransactionManager


: CurriculumController : TransactionManagerG


G

Diseño del Modelo -- Visibilidad Global

El objeto TransactionManager es declarado globalmente

La visibilidad global conlleva a una relación de dependencia


VENS

VENS

Visibilidad Global

static TransactionManager theManager;class CurriculumController { public: void createCourse(); …};class Course;void CurriculumController::createCourse() { Course *aNewCourse; … theManager.saveCourse(aNewCourse); …};


VENS

VENS


createCourse (TransactionManager&)

TransactionManager




P

Diseño del Modelo -- Parámetro Visibilidad

El objeto TransactionManager es un parámetro para la operación createCourse() del CurriculumController

El objeto TransactionManager es solamente visible a la operación createCourse

El parámetro visibilidad conlleva a una relación de dependencia


VENS

VENS

Parámetro Visibilidadclass TransactionManager;class Course;class CurriculumController { public: void createCourse(TransactionManager&); …};void CurriculumController:: createCourse(TransactionManager& theManager) {

Course *aNewCourse; … theManager.saveCourse(aNewCourse); …}


VENS

VENS


createCourse ()

TransactionManager




L

Diseño del Modelo -- Visibilidad Local

El objeto TransactionManager es declarado dentro de la operación createCourse() de CurriculumController

El objeto TransactionManager es solamente visible a la operación createCourse

La visibilidad local conlleva a una relación de dependencia


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


createCourse ()

TransactionManager

saveCourse (Course)



F

Diseño del Modelo -- Visibilidad de Campo

El objeto TransactionManager es un miembro dato de la clase CurriculumController

El objeto TransactionManager es visible para todas las operaciones de la clase CurriculumController

La visibilidad de campo conlleva a una relación de asociación (o de agregación)


VENS

VENS

#include “TransactionManager.h”;class Course;class CurriculumController { public: void createCourse(); … private: TransactionManager theManager;};void CurriculumController::createCourse() {

Course *aNewCourse;… theManager.saveCourse(aNewCourse); … }

Visibilidad de Campo


VENS

VENS

Ejemplo: Diseño de Relaciones

El CurriculumController es responsable de la administración de la información de todos los cursos. El Course es creado y salvado en la base de datos Curriculum. Un TransactionManager es responsable de las interfaces con la base de datos. Hay una clase DBCourse que sabe cómo salvar la información del curso pertinente. Cada curso puede tener entre 3 y 10 estudiantes matriculados y solamente un profesor. Un estudiante puede matricular hasta un máximo de cuatro cursos. Cada profesor dicta tres cursos. Un reporte que lista los cursos, el profesor y los estudiantes matriculados, se ejecuta para las primeras tres semanas del semestre.


VENS

VENS

El Modelo antes del Diseño de la Relación

StudentCourse

0..4 3..10

Professor

30..4

3


createCourse ()

TransactionManager

saveCourse (Course)

DBCourse

save (Course)

1

1

11

1

11

1

1

1..*


VENS

VENS

Decisiones de Diseño

El CurriculumController usa al TransactionManager para cada curso que este administra

La operación createCourse() no es la única operación para usar el TransactionManager

Se elige la visibilidad de campo El CurriculumController envía mensajes hacia el

TransactionManager pero el TransactionManager no envía ningún mensaje al CurriculumController

La relación es unidireccional (de CurriculumController a TransactionManager)


VENS

VENS

Decisiones de Diseño (cont.)

El CurriculumController crea un nuevo curso dentro de la operación createCourse

Es seleccionada la visibilidad local La operación saveCourse del TransactionManager es pasada al objeto

Course Es seleccionada la visibilidad de parámetro

El TransactionManager usa un objeto DBCourse para salvar un objeto Course

Esta es la única operación que requiere del objeto Course Es seleccionada la visibilidad local


VENS

VENS

Decisiones de Diseño (cont.)

La operación salvar de DBCourse se pasa al objeto Course Se selecciona la visibilidad de parámetro

Un Curso tiene que conocer sus estudiantes para generar el reporte Estos requerimientos no establecen que un Estudiante tenga que

conocer sus cursos La relación se produce unidireccionalmente

Un Curso tiene que conocer su Profesor para generar el reporte Estos requerimientos no establecen que un Profesor tenga que

conocer sus cursos La relación se produce unidireccionalmente


VENS

VENS

El Modelo después del Diseño de la Relación

BDCurso

save (Course)


createCourse ()

TransactionManager

saveCourse (Course)

EstudianteCurso

3..10

Profesor

3..10

1

1


VENS

VENS

Multiplicidad para las Relaciones

La multiplicidad es el número de instancias que participan en una asociación

Estimados iniciales de multiplicidad hechos durante el análisis tienen que ser actualizados y refinados durante el diseño

Todas las relaciones de asociación y agregación tienen que tener especificada la multiplicidad


VENS

VENS

class Professor;class Course { public: // public info private: Professor *teacher; …};

Course Professor

Teacher

10..*

Implementación de Asociaciones con Multiplicidad de 1 o 0 a 1

Si cada Curso tiene a lo sumo un Profesor, entonces cada objeto Curso puede incluir un apuntador simple al objeto Profesor correspondiente


VENS

VENS

CursoProfesor

dictando( ) 1 0..*

Opcionalmente

Si un vínculo es opcional, una operación para probar la existencia del vínculo debe ser incluida

Por ejemplo, si un Profesor puede estar en sabático, una operación apropiada deberá ser incluida en la clase Profesor para probar el vínculo


VENS

VENS

Item

Lista

Opciones de Diseño para Multiplicidad de más de Uno

La multiplicidad de más de uno es usualmente diseñada usando clases “contenedoras”

Una clase contenedora es una clase cuyas instancias son colecciones de otros objetos

Las clases contenedoras comunes incluyen: Conjuntos, listas, diccionarios, pilas, colas, …

Las clases contenedoras son frecuentemente clases parametrizadas las cuales se muestran como:


VENS

VENS

Ejemplo de Clase Parametrizada

Course

Item

List

1

StudentList

1

Student

#include “List.h”class Course { public: … private: List<Student> students; …}


VENS

VENS

CursoEstudiante

3..103..10

Lista

Notación para Clases Contenedoras Para reducir la confusión en diagramas de clases extensos, las clases

contenedoras no son mostradas típicamente en los diagramas de clases

Si el tipo de contenedor se requiere para la comunicación, una nota puede ser usada


VENS

VENS

nota

Curso Estudiante

3..104 3..104

Clase Asociación

Una clase asociación contiene información que pertenece a un vínculo entre objetos y no a ningún objeto envuelto en la relación

Calificacion


VENS

VENS

Diseñando Clases Asociación

Durante el diseño, las clases de asociación evolucionan por: La transformación de la clase asociación en una clase

interpuesta entre las otras dos clases El establecimiento de asociaciones con multiplicidad adecuada

entre la clase asociación y las otras dos clases La multiplicidad es siempre UNA clase de conexión a las

clases vinculadas Diseñando las nuevas asociaciones

La navegación puede ser bidireccional o unidireccional


VENS

VENS

Diseñando Clases de Asociación (cont.)

EstudianteCalificacion

notaCurso

3..103..104 11


VENS

VENS

Ejercicio

Usando los escenarios y los diagramas de clases desarrollados Discutir consideraciones del diseño de relaciones

Actualizar los diagramas de clases para mostrar las consideraciones de diseño de relaciones


VENS

VENS

Resumen: Diseñando Relaciones

Durante el análisis, las asociaciones y agregaciones son relaciones bidireccionales

Durante el diseño, ellas pueden convertirse en relaciones unidireccionales

Las asociaciones se diseñan en dos modos Por valor -- los objetos tienen tiempos de vida dependientes Por referencia -- los objetos tienen tiempos de vida

independientes Una relación de dependencia significa que una clase depende de otra

clase para un servicio en particular Examinar la visibilidad de los objetos ayuda a determinar el diseño de

las relaciones


VENS

VENS

Resumen: Diseñando Relaciones (cont.)

Las opciones de visibilidad incluyen: Visibilidad global -- el objeto está disponible globalmente Visibilidad de Parámetro -- el objeto es un parámetro a un

método Visibilidad local -- el objeto es declarado localmente Visibilidad de campo -- el objeto es parte de la estructura

Los punteros son típicamente usados para implementar la multiplicidad de 1 o de 0..1

La multiplicidad de más de uno es usualmente diseñada usando clases “contenedoras”, tales como una Lista o Cola

Una clase contenedora es una clase cuyas instancias son colecciones de otros objetos

Uml Curso Teori Aistpcsr

Documents

Transcript of Uml Curso Teori Aistpcsr