Programación Orientada a Objetos

Programación Programación Orientada a ObjetosOrientada a Objetos

ANALISIS Y DISEÑOANALISIS Y DISEÑOUMLUML

22

UMLUML

• Un sistema orientado a objetos está conformado por objetos

• Pero eso es lo mismo que decir que una circuito electrónico está hecho con diodos, transistores, resistencias, capacitores, etc

• De la misma manera que para construir un circuito necesitamos especificar que componentes, sus valores y las interconexiones entre ellos (un esquemático), para construir un sistema OO necesitamos saber cuales son los objetos, sus atributos y métodos y cómo se interrelacionan entre sí

33

UMLUML

• Un esquemático esta formado por símbolos estándar que pueden ser comprendidos por cualquier ingeniero o técnico electrónico

• Así también un sistema OO necesita ser representado de una manera estándar para que este pueda ser entendido por diseñadores y programadores

44

UMLUML

• A la acción de construir estos diagramas se lo conoce como modelamiento

• Al producto se lo conoce como modelo• Modelo es una abstracción que se

construye para entender y resolver problemas

• Los modelos limitan nuestra vista a un subconjunto de la realidad

55

UMLUML

Hardware Real

Modelo - Hardware o Software

prototipo

Software Modelo en papel o Herramienta CASE

66

¿Para que A&D OO?¿Para que A&D OO?

El cambio a OO no es fácil, los lenguajes de modelamiento OO ayudan de alguna manera para que el cambio de paradigma sea un poco más sencillo.

Uno de los grandes retos en el desarrollo es construir el sistema correcto. Los lenguajes de modelamiento OO ayudan a lograr buena comunicación con los clientes y los expertos en el dominio.

77

UMLUML

¿Qué es Lenguaje de Modelamiento Unificado? Lenguaje de modelamiento estándar para:

Modelar sistemas (no solo software) usando OO

Establecer un modo de acoplamiento explícito entre los modelos conceptuales y ejecutables

Manejar las complejidades de sistemas de misión crítica

Proveer un lenguaje de modelamiento que pueda ser utilizado tanto por humanos como por las máquinas.

88

UMLUML

Los modelos se caracterizan por ser: Precisos Consistentes Fácil de comunicar Fácil de cambiar Entendibles

99

UMLUML

La Guerra de los modelos (80s-90s):– Booch - Grady Booch– OMT - James Rumbaugh– OOSE/Objectory - Ivar Jacobson– Fusion - David Coleman– OOA/OOD - Coad & Yourdon

1010

UMLUML

Método Boch

1111

UMLUML

Método OMT

1212

UMLUML

Método UML

1313

Lenguaje Unificado de ModelamientoLenguaje Unificado de Modelamiento

El lenguaje unificado de modelamiento (UML) unifica las notaciones de Booch, Rumbaugh (OMT) y Jacobson (OOSE)

Notación es la representación gráfica de diferentes modelos, es la sintaxis del lenguaje de modelamiento.

El UML es un estándar aprobado por la OMG y es ampliamente aceptado en la industria.

UML es un lenguaje de modelamiento, no un proceso de desarrollo de software; su intención es ayudar a las diferentes acercamientos para la producción de software OO.

1414

UMLUML

Se utiliza UML en diferentes tipos de sistemas: Sistemas de información Técnicos Tiempo real Distribuidos Software Sistemas de negocios

1515

UMLUML

Hay tres dimensiones para entender los modelos OO:

¿Por qué se construyen los modelos?

¿Qué hay en el modelo?

¿Cómo se relacionan los modelos?

1616

UMLUML

Fases en el desarrollo de sistemas: Análisis de requerimientos Análisis del sistema Diseño Implementación (programación) Pruebas de aceptación.

1717

UMLUML

Análisis OO Diseño OO Construcción OO

Entender y especificarel problema

Resolver elproblema

Construir lasolución

Los Modelos se utilizan para….

1818

UMLUML

Para cada una de estas fases existen modelos UML: Análisis

Foco: Especificar el dominio o el problema Perspectiva: Desde el punto de vista del cliente o usuario Actividades típicas: Entendimiento de los requerimientos, entendimiento

del dominio del problema, identificar límites del sistema, etc. Diseño

Foco: Resolver el problema Perspectiva: Del arquitecto, analista, diseñador, programador Actividades típicas: Definición de arquitectura del software, escoger

estructura de datos, desarrollar algoritmos, implementar relaciones, etc. Implementación y Pruebas

Foco: Construir la solución para soportar el modelo del diseño Perspectiva: Del arquitecto, analista, diseñador, programador Actividades típicas: Implementar clases, manejo de persistencias,

concurrencia, pruebas, funcionamiento

1919

UMLUML

Para cada una de estas fases existen modelos UML: Análisis de requerimientos

Casos de Uso Escenarios

Análisis del sistema Diagrama Análisis Interacción Modelo de Análisis de Objetos

Diseño Diagrama Diseño Interacción Modelo de Diseño de Objetos Diagrama de Estados

Implementación (programación) Diseño Descripción de Clases

Instalación Diagrama de Puesta en Producción

2020

UMLUML

• Diferentes modelos dan diferentes vistas de un problema, enfocados a responder preguntas particulares– Modelos estáticos

¿Cuáles son los objetos (entidades o cosas) en el problema? ¿Cuáles son sus características? ¿Qué tienen en común? ¿Cuáles son las relaciones estructurales entre ellos?

Modelos dinámicos ¿Qué pasa cuando el sistema esta corriendo? ¿Cuáles son las colaboraciones entre objetos ¿Cuál es la secuencia de eventos? ¿Cómo se comportan los objetos?

2121

UMLUML

Modelos estáticos

Es un

Es un

guauguau

ladra

mueve la cola

tiene cola

tiene 4 patas

tiene nariz húmeda perro

Modelos estáticos se concentran en la estructura y similitudes

2222

UMLUML

muchacho entregaperiódico

perro persigueal muchacho

perro muerdeal muchacho

perro entrega elperiódico

Modelo dinámico

Modelos dinámicos se concentran en el flujo de control y secuencia de eventos

2323

Diagramas UMLDiagramas UML

Diagramas de Caso de Uso Diagramas de Clase Diagramas de Interacción

Diagramas de secuencia Diagramas de colaboración

Diagrama de Estados Diagramas de Actividad Diagramas de Componentes Diagrama de Puesta en Producción

2424

UMLUML

• Modelos Estáticos:– Modelo de Análisis de Objetos– Modelo de Diseño de Objetos– Diseño de Descripción de Clases– Diagrama de Componentes– Diagrama de Puesta en Producción

• Modelos Dinámicos:– Casos de Uso– Escenarios– Diagrama de Análisis Interacción– Diagrama de Diseño Interacción– Diagramas de Estado

2525

Herramientas CASEHerramientas CASE

•Dibujar Diagramas•Actúan como repositorio•Ayudan a la navegación•Soporte Multiusuario•Genéran código•Ingeniería Reversa•Integración con otras herramientas

CASOS DE USO

2727

Casos de UsoCasos de Uso

• Requerimientos del Sistema Requerimientos son el conjunto de frases

que describen el comportamiento externo esperado de un sistema, cuando este sea puesto en operación.

2828


Los requerimientos pueden ser expresados como:

Requerimientos funcionales: comportamiento observable de lo que hará el sistema. Ej:

• cliente renta un vídeo. Requerimientos no funcionales: limitaciones en el

sistema y/o criterios aceptables como rendimiento, confiabilidad, utilidad, costo, disponibilidad, etc. Ej.: El sistema debería poder ser utilizado por alguien que

no sabe de computadoras, después de 2 horas de entrenamiento.

Un usuario del sistema debería poder procesar un reclamo en no más de 3 minutos.

2929


Un caso de uso es la secuencia de transacciones en un sistema cuya tarea es producir un resultado con valor medible para un actor del sistema Sistema: Entidad encapsulada cuyos requerimientos han sido

descritos (programa, computador) Actor: Entidad fuera del sistema que interactúa con este

(usuario, otro sistema) Secuencia de transacciones: Serie de interacciones entre el

sistema y el actor que lo usa. Resultado con valor medible: objetivo logrado con valor no

trivial para el actor. El conjunto de casos de uso puede ser utilizado para

documentar los requerimientos funcionales del sistema

3030


Sistema

Caso de Uso

Serie de transacciones de valor para el actor

Entidad fuera del sistemaquien interactúa con este

3131


Sistema

Casos de uso del sistemaUsuario

del sistema

La Empresa

Cliente(usuario dela empresa)

Casos de uso de la empresa

3232


Hace depósito

Retira fondos Procesa préstamo

Añade cliente

Banco (empresa)

CajeraAgente

Cliente

Deposita cheque Adquiere préstamo

Sistema computacional

3333


¿Quiénes son los actores? Un actor es una entidad que interactúa con el sistema.

Ejm: Un usuario humano Otro sistema que requiere de servicios Otro sistema que provee de servicios El tiempo

El actor esta fuera de los límites del sistema - No es un objeto dentro del sistema

Un actor es una abstracción de un rol - No es un sola persona o el puesto de una persona

Un usuario puede jugar múltiples roles Dos personas diferentes podrían jugar el mismo rol.

3434


¿Qué son la secuencia de transacciones? Una secuencia es una serie de interacciones El foco esta en las interacciones que cruzan los

límites del sistema, no son acciones internas del sistema

La atención esta en las interacciones entre el actor y el sistema, no entre actores

La implementación precisa de las interacciones no deben describirse en el caso de uso

La serie de interacciones es iniciada por algún evento.

3535


Planifica reunión

Registra invitado a reunión

María (usuario del sistema)Juega el rol de registradora

María (usuario del sistema)Juega el rol de planificadora

Sistema Organizador de Reuniones

3636


Planifica reunión

Registra invitado a reuniónRegistrador

(actor primario)

Planificador(actor primario)

Sistema Verificador de tarjeta de crédito(actor secundario)

Sistema Organizador de Reuniones

3737


Actualiza ficha de paciente

Respaldo de información en tape

Sistema de registros médicos

Enfermero

3838


Una lista de casos de uso incluye: Lista de casos de uso utilizando el formato

de objetos. Descripción de cada caso de uso Descripción de cada actor (opcional) Diagrama o tabla de relaciones

entre casos de uso y actores.

3939


1. Caso de Uso A2. Caso de Uso B3. Caso de Uso C………….………….………….

Lista de Casos de Uso

Nombre: _________________Descripción: ______________________________________________________________Notas:___________________________________________

Descripción de Casos de Uso

Nombre: _________________Descripción: ______________________________________________________________Notas:___________________________________________

Descripción de Actores

Caso de Uso A

Diagrama de Casos de Uso

Caso de Uso B

Caso de Uso C

4040


Para identificar actores Buscar primero los actores primarios (los

actores secundarios pueden ser descubiertos a medida que se elabora el comportamiento de los casos de uso)

Buscar por roles, no usuarios individuales o títulos

El nombre debería enfocar en el rol de actor, con respecto a su interacción con el sistema.

4141


Rol Y Rol Z

Rol X

SistemaDiagrama de Casos de Uso

4242


Identificación de los roles de los actores Los casos de uso documentan lo que el sistema

debe hacer para satisfacer los objetivos de los actores que interactúan con el sistema

Los objetivos del actor deben reflejar un valor medible - no pasos individuales para alcanzar un objetivo de valor o interacciones triviales

Ordena pizza - es un objetivo de valor para el actor que juega el rol de cliente

Selecciona aceitunas - es solo un paso en ordenar pizza

Presionar ENTER es una interacción trivial

4343


Los objetivos pueden ser descritos desde la perspectiva de un actor quien utiliza el sistema - o desde la perspectiva del sistema

Ordena pizza es un objetivo desde la perspectiva del actor cliente Envía la orden de pizza a la cocina es un

objetivo desde la perspectiva del sistema

Cada objetivo de valor puede ser descrito con los casos de uso.

4444


Objetivo a

Objetivo b

Objetivo d Objetivo e

Objetivo c

Rol Y

Rol X

Rol Z

Sistema

Diagrama de Casos de Uso

4545


Objetivo a

Objetivo b

Objetivo d Objetivo e

Objetivo c

Rol Y

Rol X

Rol Z

Sistema

Descripción de Casos de Uso

Nombre: Caso de uso DDescripción: Describe funcionalidad

y aplicabilidad dentrodel contexto

Notas: Describe limitaciones y decisiones Describe reglas y políticas del

negocio

Nombre: Caso de uso EDescripción: Describe funcionalidad

y aplicabilidad dentrodel contexto

Notas: Describe limitaciones y decisiones Describe reglas y políticas del

negocio

4646

Ejemplo: CarreterasEjemplo: Carreteras

4747

Ejemplo: Carreteras (1)Ejemplo: Carreteras (1)

La compañía Pague&Maneje administra una red de carreteras. La red consiste en número de segmentos de vía. Cada segmento de vía esta delimitados por dos nodos que están descritos normalmente con su posición geográfica. La distancia entre los nodos delimitantes de un segmento de vía es conocido.

Algunos de los nodos están equipados con estaciones de control de acceso que pueden ser usadas para entrar y salir de la red de carreteras. Algunos de los nodos están equipados como puntos de servicio (estación de gasolina, baños, etc)

Una trayecto es una secuencia consecutiva de segmentos de vía. Comienza y termina en nodos con control de acceso.

4848

Ejemplo: Carreteras (2)Ejemplo: Carreteras (2)

Los clientes pueden registrarse con Pague&Maneje y obtener hasta 3 tarjetas. Los clientes pueden usar estas tarjetas para viajar en trayectorias en la red vial.

Las tarjetas regulares son válidas por un período y se envían facturas por cada uso de la tarjeta. El valor de la facturas se calculada a partir de la longitud de la trayectoria recorrida y el precio unitario esta asociado con cada tarjeta.

Además de las tarjetas regulares existe un número de tarjetas especiales. Las tarjetas MiniViaje son tarjetas prepagadas, válidas para una sola trayectoria. Están expiran cuando se recorre la trayectoria. Las tarjetas temporales son también prepagadas, son válidas por un tiempo dado y pueden dar acceso a toda la red vial.

4949

De captura de requerimientos a AnálisisDe captura de requerimientos a Análisis

Descubrir los potenciales casos de uso de un sistema, las interacciones típicas que el usuario tiene con el sistema para alcanzar sus objetivos.

Un caso de uso está escrito como un para de párrafos de texto, UML provee diagramas de caso de uso.

Desarrollar un modelo conceptual del domino, explorar el vocabulario del domino, dar una descripción del mundo en el cual deberá encajar.

Un diagrama de clases conceptual es útil aquí y algunos diagramas UML de actividad podrían ser útiles cuando el proceso de workflow es parte del mundo del usuario.

5050

Análisis y Diseño de MétodosAnálisis y Diseño de Métodos

El diagrama de clases conceptual resultante del análisis del domino junto con los casos de uso constituyen un modelo de análisis.

Un modelo de diseño comprende tanto la información de los conceptos del dominio como el comportamiento en los casos de uso, añade las clases que realmente hacen el trabajo y provee cierta arquitectura.

Un diagrama UML de especificación puede ser usado junto con diagramas UML de interacción y/o estado que muestran como las clases implementan los casos de uso.

5151

Modelo de Caso de Uso: ActoresModelo de Caso de Uso: Actores

Los actores NO son parte del sistema, representan a cualquier persona o cosa que deba interactuar con el sistema. El afiliado a la biblioteca “presta una copia del libro” El bibliotecario “actualiza el catálogo”

Un actor puede: Solamente ingresar información al sistema Solamente recibir información del sistema Ingresar y recibir información del sistema

Los actores leen, crean, destruyen y modifican información Los actores son encontrados en la declaración del problema y en

conversaciones con los clientes y expertos del dominio Un solo actor puede realizar muchos casos de uso y un solo caso

de uso puede tener varios actores realizándolo

5252

Modelo de Casos de Uso: Casos de Uso (1)Modelo de Casos de Uso: Casos de Uso (1)

Un caso de uso modela un dialogo entre un actor y el sistema. Un editor de texto: “marca un texto en negrillas”, “crea un indice” Un sistema bibliotecario: “presta una copia del libro”, “actualiza el

catálogo” Un caso de uso representa la funcionalidad provista por el

sistema, ej. Las capacidades que el sistema proveerá al actor. La suma de todos los casos de uso es la figura externa del

sistema. Un caso de uso es una secuencia de transacciones realizadas

por un sistemas que conducen a un valores de resultado mesurables para un determinado actor.

5353


Un caso de uso puede ser pequeño o grande pero logra un objetivo discreto para algún usuario.

Un caso de uso tipicamente representa una parte importante de la funcionalidad que se completa de principio a fin. Un caso de uso debe proveer algo de valor para el actor.

Definición de un caso de uso: curso básico de eventos, número de cursos de acción excepcionales o alternativos

No existe estandar para ellos en UML

5454


Ejemplos de definición de un caso de uso: Nombre: nombre usado para referirse al caso de uso Resumen: una descripción corta Actores: todos los actores involucrados Precondiciones: condiciones del sistema al comienzo

de un caso de uso. Descripción: la descripción completa Excepciones: casos especiales Resultado: condición del sistema al final del caso de

uso

5555

Ejemplo: CarreterasCasos de Uso (1)Ejemplo: CarreterasCasos de Uso (1)

Una persona puede aplicar para registrarse como cliente Alguna información personal deber ser entregada y registrada

en el sistema, el cliente comienza con una cuenta en cero. Un cliente puede aplicar a una tarjeta

El sistema verifica la cuenta, cuando el límite de crédito es excedido, la tarjeta es negada, sino una nueva tarjeta es entregada y el sistema lo registra.

Un cliente puede aplicar por una tarjeta prepago El sistema verifica la cuenta, cuando el límite de crédito es

excedido la tarjeta es rechazada, sino una nueva tarjeta es entregada y el sistema lo registra.

El sistema imprime una factura para la nueva tarjeta y actualiza la cuenta del cliente.

5656


Un cliente puede (tratar de) viajar una trayectoria en una fecha dada con una tarjeta regular. El cliente entra a la red vial a través de algún tipo de control de

acceso. El sistema verifica la validez de las tarjetas y la cuenta del

cliente; Cuando se aprueba, el sistema registra el nodo de entrada y la fecha de entrada para la tarjeta y permite el acceso; Cuando no esta ok, el acceso es denegado.

El cliente deja la red vial en algún punto con otro nodo de control.

El sistema calcula el precio total, lo imprime como una factura, actualiza la cuenta de cliente y permite la salida.

5757


Un cliente puede (intentar) viajar una trayectoria en una fecha dada con un tarjeta de vacaciones. Es una variación del caso previo, a la salida no se imprime

factura la cuenta del cliente no es actualizada. Un cliente puede (intentar) viajar una trayectoria en un

día dado con una tarjeta minitrip. Es una extensión del caso de uso anterior, los nodos de

entrada y salida son verificados contra la trayectoria para la cual esta hecha la tarjeta.

Un ingeniero puede actualizar la red de carreteras Un fiscalizador o auditor puede registrar el pago de una

factura.

5858

ApplyFor Card

Apply ForPrepaid

Card TravelTrajectory

With Regular Card

Update Road

Networkengineer

customer

<<includes>>

TravelTrajectory

With Season Card

TravelTrajectory

With MinitripCard

<<extends>>

RegisterPayment Of

Invoicesbookkeeper

5959

Diagramas de Casos de UsoRelaciones de ActoresDiagramas de Casos de UsoRelaciones de Actores

La relación de “asociación” entre un actor y un caso de uso La participación de un actor en un caso de uso Es la única relación entre los actores y los casos de

uso La “generalización” de un actor A a un actor B

Indica que una instancia de A puede comunicarse con la misma clase de instancias de casos de uso que una instancia de B

6060

Diagramas de Casos de UsoRelaciones de Casos de UsoDiagramas de Casos de UsoRelaciones de Casos de Uso

La relación <<incluye>> permite factorizar una porción de comportamiento que es similar a través de dos o más casos de uso para evitar copiar descripciones de ese comportamiento

La relación <<extiende>> provee una forma más controlada de extensión del comportamiento de un caso de uso que la relación de generalización. El caso de uso base declara un número de puntos de extensión. El caso de uso extendido puede solamente alterar el comportamiento de esos puntos de extensión.

La relación de “generalización” indica que uno de los casos de uso es una variación del otro. Permite a un caso de uso especializado cambiar cualquier aspecto del caso de uso base.

6161

CaptureDeal

_________Extension points

After creation of the deal

AnalyzeRisk

PriceDeal

Valuation

LimitsExceeded

Trader

<<includes>>

RequestCatalog <<extends>>

SalesPerson

6262

Relaciones de Casos de UsoReglas empíricasRelaciones de Casos de UsoReglas empíricas

Usar incluir cuando se esta repitiendo dos o más casos de uso y se quiere evitar la repetición

Use generalización cuando esta describiendo una variación de un comportamiento normal y desea describirlo brevemente

Use extender cuando este describiendo la variación de un comportamiento normal y se desea hacerlo de una manera más controlado, declarando los puntos de extensión en el caso base.

6363

Objeto: Estado, Comportamient e Identidad (1)Objeto: Estado, Comportamient e Identidad (1)

Representación de una entidad Mundo real Conceptual

Algo concreto o un concepto

Concepto, abstracción o cosa con límites bien definidos y significado para una aplicación

6464

Objeto: Estado, Comportamient e Identidad (2)Objeto: Estado, Comportamient e Identidad (2)

Estado Una de las posibles condiciones en las cuales

puede existir Cambia con el tiempo Define un conjunto de propiedades, con los valores

de las propiedades más las relaciones que el objeto tiene.

Comportamiento Como un objeto responde a una petición Implementado por un conjunto de operaciones

Identidad Cada objeto es único

Diagrama de Clase

6666

Encontrar Objetos (Clases)Encontrar Objetos (Clases)

• El primer paso para construir un modelo de objetos es identificar las clases de objeto presentes en un problema

• La primera regla es que los objetos se deben tomar del ámbito del problema, no de la herramienta de solución

6767

ClaseClase

Descripción de un grupo de objeto con propiedades comunes (atributos), comportamiento común (operaciones), relaciones comunes con otros objetos y semántica común.

Una buena clase captura una y solamente una abstracción

Las clases deben ser nombradas usando el vocabulario del dominio.

6868


• Las clases se encuentran principalmente en los requerimientos del problema

• Son generalmente substantivos. • No hay que ser demasiado selectivos,

elija todas las clases que le vengan a la mente y en un paso posterior se las filtra

6969


Extraersubstantivos

Eliminar malasclases

Requerimientos

Dominio deProblema

Clases Candidatas Clases

7070


• No hay que preocuparse demasiado por herencia, encapsulación, mensajes o polimorfismo en esta etapa

• Luego procederemos a armar las interrelaciones entre los objetos

• Lo importante ahora es no olvidar a ningún objeto que pueda ser importante

7171

Pulir ClasesPulir Clases

• Hay varias reglas a seguir para poder filtrar a los objetos candidatos. Debemos eliminar:– Clases Redundantes– Clases Irrelevantes– Clases ambiguas– Atributos– Operaciones– Roles– Detalles de Implementación

7272


• Clases Redundantes– Si dos clases expresan la misma

información, la más descriptiva debe quedarse.

– Por ejemplo: un cliente puede describir a la persona que compra un ticket de vuelo, pero pasajero es una clase más descriptiva

– Por lo tanto si tanto cliente como pasajero están presentes se deberá eliminar uno de los dos, dejando el más descriptivo para el problema

7373


• Clases Irrelevantes– Si una clase tiene muy poco o nada que ver con el

problema, debe ser eliminada– Esto involucra el juicio del experto, porque en otro

contexto la clase tal vez es importante.– Ejemplo: En un sistema de reservaciones de

entradas a un teatro, las esposas de los que asisten no son importantes para el sistema. Pero en caso de un sistema de rol de pagos, si son importantes las esposas de los empleados.

7474


• Clases Ambiguas– Una clase debe ser específica. Algunas

clases candidatas tienen límites mal definidos o demasiado grandes.

– Por ejemplo una clase Almacenamiento es vaga mientras que Base de Datos es mas específica

7575


• Atributos– No se debe elevar los atributos al nivel de

clases.

– Por ejemplo: edad, peso, dirección son generalmente atributos.

– Si se necesita el atributo hay que envolverlo con una clase

7676


• Operaciones– De la misma manera, un método no se debe

tomar por una clase

– Por ejemplo: llamada telefónica es una secuencia de acciones entre el Usuario y la red Telefónica, no un objeto

– Pero por ejemplo si estamos haciendo un sistema de facturación, llamada si sería un objeto

7777


• Detalles de Implementación– Cualquier construcción extraña al mundo real

debe ser eliminada del modelo de análisis.

– Se pueden utilizar luego, en el diseño, pero no ahora.

– Por ejemplo: CPU, subrutina, proceso, algoritmo, interrupción, etc son detalles de implementación

7878

Identificar AsociacionesIdentificar Asociaciones

• Esta es una etapa en la que se trata de encontrar relaciones entre los objetos.

• Las más comunes son las de herencia “es un”

• Otras relaciones– “tiene un”– “controla a”– “trabaja para”– etc

7979

Identificar AsociacionesIdentificar Asociaciones

• Estas relaciones nos van a ayudar generar el famoso diagrama estático de objetos del sistema.

8080

Clase A Clase BAsociación

Persona Compañíaempleada por

empleado empleador

Modelamiento de Asociaciones

Características de las AsociacionesCaracterísticas de las Asociaciones

8181

MultiplicidadMultiplicidad

• Un factor importante que se debe considerar es el número de asociaciones en las que un objeto puede participar en cualquier instante

8282


• También se debe de tomar en consideración las restricciones que se pueden dar, como por ejemplo que un rectángulo no puede pertenecer a más de un diagrama a la vez

8383


• En ese caso en el diagrama se deben de incluir estas restricciones como propiedades de la asociación

• Ej.: Las siguientes restricciones se aplican:– Una Herramienta Rectángulo debe esa asociada

con solo un diagrama a la vez– Un diagrama puede o no tener una Herramienta

Rectángulo asociada– Un diagrama puede contener o estar asociado a

cero o más rectángulos– Todo rectángulo debe pertenecer a un diagrama

únicamente.

8484


• En ese caso en el diagrama se deben de incluir estas restricciones como propiedades de la asociación

• Las siguientes restricciones se aplican al diagrama anteriormente mostrado:– Una Herramienta Rectángulo debe esa asociada

con solo un diagrama a la vez– Un diagrama puede o no tener una Herramienta

Rectángulo asociada– Un diagrama puede contener o estar asociado a

cero o más rectángulos– Todo rectángulo debe pertenecer a un diagrama

únicamente.

8585


8686


8787

Tipos de RelacionesTipos de Relaciones

• Además de la Asociación existen otros tipos de Relaciones entre los objetos– Agregación

– Composición

– Generalización

8888

AgregaciónAgregación

• La agregación se usa para mostrar que una clase es parte de otra.

• Podríamos decir que es una asociación “contiene a”, “es contenido por”

• Ej: La clase computador contiene a la clase CPU y a la clase memoria

• La multiplicidad también se especifica en las agregaciones

8989

AgregaciónAgregación

9090

ComposiciónComposición

• La composición es similar a la agregación

• Se basa en una relación de posesión A contiene a B

• La diferencia estriba en que B no tienen sentido si no pertenece a A

• Por ejemplo: La clase ventana posee a la clase marco de ventana. Pero si no existiera la clase ventana, no tendríamos ninguna utilidad para la case marco de ventana

9191


9292


9393

GeneralizaciónGeneralización

• La generalización es una relación “es un”• Es la representación de la herencia de

clases• Se representa con una línea y una flecha

9494


9595

Dia

gra

ma

de

Cla

ses

Dia

gra

ma

de

Cla

ses

9696

Diagrama de Clases (Preliminar)Diagrama de Clases (Preliminar)

• Taller: Constuir el diagrama de Clases del Ascensor

9797

Diagrama de Clases (Preliminar)Diagrama de Clases (Preliminar)

• Taller: Constuir el diagrama de Clases del Ascensor

9898

Clases y Diagramas de ClaseClases y Diagramas de Clase

Un diagrama de clases describe los tipos de objetos en un sistema y las varias clases de relaciones estáticas que existen entre ellos.

Asociación y subtipo (generalización / especialización) son los dos principales tipos de relaciones estáticas

Los diagramas de clase también muestran los atributos y métodos de una clase y las restricciones que se aplican a la manera en que los objetos se conectan.

Un diagrama de objetos es una fotografía de los objetos en un sistema en un momento en el tiempo. También se conoce como diagrama de instancias.

9999

1 .. 3Customer NameAddress Account CheckAccountUpdateAccount

CardValidFromValidThrue UnitPrice

Valid?

registered-to1

RoadSegment Distance

NodeDescription

Access Control Node

EnterLeave

1

1 .. *

1

1begin1

end

TrajectoryDateOfEntry

PrintInvoiceComputeTotal

{ordered}

entry

exit

*

*

*

*

*

card-used1

*

100100

a CardUnitPrice: 4ValidFrom:1/1/00ValidTo:30/6/01



a CustomerName: “Viviane”Address: “Paris”Account:-500

a CustomerName: “Michel”Address: “Lion”Account:0

registered-to

registered-to

registered-to

101101

a NodeDescription: “Orleans”

a NodeDescription: ”Mer”

a NodeDescription: “Meung”

a NodeDescription: “Olivet”

a RoadSegmentDistance: 90



end

begin

begin

end

begin

end

A TrajectoryDateOfEntry: 1/4/01

102102

AsociacionesAsociaciones

Las asociaciones representan las relaciones entre las instancias de las clases

Cada asociación tiene dos roles; siendo el rol una dirección en la asociación

Un rol pude ser nombrado explícitamente con una etiqueta, si no hay etiqueta el nombre de la clase es usado.

Un role tiene multiplicidad, una indicación de cuantos objetos pueden participar en una relación dada. En general la multiplicidad indica límites inferiores y superiores.

103103

Asociaciones y PrespectivasAsociaciones y Prespectivas

Desde una perspectiva conceptual las asociaciones representan relaciones conceptuales: un usuario trabaja para un solo departamento, el departamento tiene varios usuarios trabajando para él.

Dentro de la especificación las asociaciones en perspectiva representan responsabilidades: un usuario es responsable de saber en que departamento trabaja. Un departamento es responsable de saber quienes son sus empleados. Con buenas convenciones las interfaces pueden ser deducidas del diagrama.

En un modelo de implementación la asociaciones podrían mostrar punteros: un puntero de un usuario al departamento donde trabaja, una colección de punteros de un departamento hacia sus empleados.

104104

NavegaciónNavegación

Las flechas pueden ponerse en las asociaciones para indicar navegabilidad

La navegabilidad no sirve a ningún propósito en los diagramas conceptuales, aparecen en el cambio de la especificación a la implementación.

En un modelo de especificación las flechas indican responsabilidades asimétricas: una versión de la herramienta conoce su estatus, un estatus no conoce a que versión está asociada.

En un diagrama de implementación las flechas indican punteros de una clase a otras solamente: un puntero de la versión de la herramienta al estatus, no hay puntero de regreso.

105105

1 .. 3CardValidFromValidThrue UnitPrice

Valid?

registered-to1


NodeDescription

Access Control Node

EnterLeave

1

1 .. *

1

1begin1end



{ordered}

entry

exit

*

*

*

*

*

card-used1

*

Customer NameAddress Account CheckAccountUpdateAccount

106106

Navegación y ConvencionesNavegación y Convenciones

Cuando la navegabilidad es en una dirección solamente se conoce como asociación unidireccional.

Cuando la navegabilidad es en ambas direcciones se conoce como asociación bidireccional.

Las asociaciones sin flechas son, de acuerdo con UML, o bidireccionales o de navegabilidad no dicha.

Las asociaciones bidireccionales implican una restricción extra en la cual los dos roles son el inverso el uno del otro.

107107

Asociaciones y NombresAsociaciones y Nombres

Las Asociaciones pueden tener un nombre Los modeladores de datos tradicionales usan una frase

verbal para una asociación de tal manera que las relaciones pueden utilizar frases como: “es empleado por” “esta casado con”

Los modeladores de objetos prefieren sustantivos para uno u otro rol de la asociación, este corresponde mejor con las responsabilidades y operaciones: “empleado” “esposa”

Nombre una asociación cuando mejore su compresión, evite poner “tiene” o “esta relacionado”

108108

AtributosAtributos

Los atributos son similares a las asociaciones A nivel conceptual, un atributo es solamente otra notación

para una asociación de valor simple. Al nivel de especificación, los atributos implican

navegabilidad de los objetos a los atributos solamente. A nivel de implementación, usar un atributo implica que

los objetos contienen su propia copia del objeto atributo. Ej.: semántica de valor más que de referencia para tipos usados como atributos (cadenas, números, etc)

visibilidad nombre: tipo = valorpordefecto Existe notación para: visibilidad, ámbito

109109

OperacionesOperaciones

Las operaciones son procesos que una clase sabe como llevar a cabo.

A nivel de especificación las operaciones corresponden a los métodos públicos de un tipo; las operaciones que solamente manipulan atributos no son mostradas, estas pueden ser inferidas.

En el modelo de implementación las operaciones privadas y protegidas deben ser mostradas también; la notación de visibilidad es inspirada en C++: +(público), -(privado), #(protegido), el significado de estos indicadores es a menudo dependiente del lenguaje

Una pregunta es una operación que obtiene un valor sin cambiar el estado del sistema

110110

OperacionesOperaciones

La sintaxis completa de UML para las operaciones es:visibilidad nombre(lista-parametros) : expresión-tipo-retorno {cadena-propiedades} visibilidad es + (pública), # (protegida), o – (privada) nombre es una cadena lista-parametros contiene parámetros separados por comas,

sintaxis: dirección nombre: tipo = valor-defecto

direction: in, out, inout Expresión-tipo-retorno: lista separada por comas de los

tipos retornados Cadena-propiedades: valores de propiedades aplicadas a la

operación dada.

111111

Asociaciones Derivadas y AtributosAsociaciones Derivadas y Atributos

Las asociaciones derivadas y los atributos son aquellos que pueden ser calculados de otros atributos o asociaciones “la edad de una persona puede ser calculada a partir de su fecha de

nacimiento” En los diagramas conceptuales, los marcadores derivados

solamente recuerdan que la derivación (y por tanto la restricción) existe

En la especificación las características derivadas indican una restricción entre valores, no una sentencia acerca que es calculado o almacenado explícitamente

En la implementación las valores derivados son útiles para anotar los campos que son usados como caché por razones de desempeño.

112112

Objetos Referencia y Objetos de ValorObjetos Referencia y Objetos de Valor

Para los objetos referencia la identidad es importante. Existe usualmente un objeto de software para designa un objeto del mundo real. Para objetos de valor la identidad es menos importante, múltiples objetos de valor pueden ser referenciados por el mismo objeto del mundo real.

Los objetos referencia son los mismos cuando tienen la misma identidad, los objetos de valor son los mismos cuando representan el mismo valor.

Los objetos de valor son creados y destruidos frecuentemente pero deberían ser inmutables o la compartición debe evitarse.

Dentro de UML los atributos son usualmente usados para objetos de valor y las asociaciones son usadas para referenciar a los objetos de referencia.

113113

1 .. 3CustomerName: stringAddress: stringAccount: integer

CheckAccount():booleanUpdateAccount(n:integer)RegisterCard(): voidPrintAddress(): void

CardValidFrom: DateValidThrue: DateUnitPrice: integerCardId:number

Valid?(d:Date): booleanGetNewCardId(): number GetCard(n:number):Card

registered-to

1

Date is a utility class

DateDay:integerMonth: integerYear: integer

IsBefore(d:Date) : boolean IsAfter(d:Date): booleanEqual(d:Date): boolean

114114

Customer-Name: string-Address: string-Account: integer-Cards:Set(Card)

+RegisterCard():void+CheckCredit():boolean {query}+UpdateAccount(n:integer) +PrintAddress(): void

CardCardId:numberValidFrom: DateValidThrue: DateUnitPrice: integerRegistered-to: Customer

Valid?(d:Date): booleanSetValidFrom(d:Date) : voidSetValidThue(d:Date) : voidSetUnitPrice(d:Date): voidGetValidFrom(d:Date) : booleanGetValidThue(d:Date) : booleanGetUnitPrice(d:Date): integerGetNewCardId(): numberGetCard(n:number):Card

TrajectoryDateOfEntry: DateCard-Used: Card/Customer: CustomerEntry: NodeExit:Node

CheckTrajectory():booleanPrintInvoice (): void

115115


Conceptualmente una clase es una generalización de otra si cada instancia de la última es por definición una instancia de la primera.

Dentro de la especificación, la generalización significa que la herencia de un subtipo incluye todos los elementos de la interfase del supertipo.

En la implementación la generalización es asociada con la herencia en los lenguajes de programación y así con subclases y no con subtipos

116116

Clases AbstractasClases Abstractas

Una clase abstracta es una clase con declaración de métodos pero sin cuerpo de métodos. Sirve a un propósito esencial como lo es la especificación de interfaces. Las subclases deben proveer la implementación (cuerpo de los métodos) antes de la inicialización.

Para una clase o método abstracto, al convención de UML es italizar el ítem abstracto y usar la restricción {abstract}

117117

Card {abstract}

Valid?

Regular CardValidFromValidThrueUnitPrice

Valid?

Minitrip Card Used?TrajectoryValid?Invalidate

Season CardValidFromValidThrue

Valid?

Prepaid Card PricePaid

What to do if trajectory is exited : printinvoice,

invalidate, nothing?

A regular card is valid on a given date if the date is between the validfrom and the validthrue

A minitrip card is valid if the trajectory matches

118118

InterfacesInterfaces

OrderReader necesita DataInput

DataInputStream implementa las interfaces DataInput e InputStream y es subclase de la última.

Si la interfaz de DataInput cambia, el OrderReader deberá cambiar también.

119119

Agregación y ComposiciónAgregación y Composición

Agregación es una relación part-de “un carro tiene un motor y llantas como sus partes”

La diferenciación entre agregación y asociación es un tópico muy debatido (usualmente dependiente del dominio) “una compania no es la agregación de sus clientes”

La composición es una variedad más fuerte de agregación, los objetos parte pertenecen a un solo objeto completo, viven y mueren con el todo; el borrado del todo borra a las partes.

Una multiplicidad 1..1 en una asociación o una agregación implica borrado en cascada

120120

Reglas de RestricciónReglas de Restricción

Las construcciones básicas de asociación, atributos y generalización especifican restricciones importantes, pero no pueden indicar todas las restricciones en el dominio del problema.

Las restricciones pueden ser escritas en el diagrama de clases entre { } ya sea usando lenguaje informal o una notación más formal.

121121

Barrier

Access ControlNode

TrafficLight

Access Control Station

1

1

1..12

CardReader

1

CustomerName: stringAddress: stringDateOfBirth: Date

/Age():number


NodeDescription

1begin1end

*

*{age() >= 18}

{begin <> end}

122122

Coleciones para Roles MultivalorColeciones para Roles Multivalor

Un rol multivalor es uno donde el límite superior de la multiplicidad es mayor que 1.

La convención es que los roles multivalor son mentalizados como conjuntos: no existe orden implícito y los objetos destino no aparecen en el más que una vez.

Este valor por defecto puede ser cambiado con las restricciones: {ordered}, {bag}, {ordered bag}, {hierarchy}

123123

Restricción congeladaRestricción congelada

{frozen} es una restricción que puede será aplicada a un atributo, un rol o una clase.

En un atributo o rol, este indica que el valor de ese atributo o rol no puede cambiar durante el tiempo de vida del objeto fuente, cuando se aplica a una clase, indica que todos los roles y atributos asociados con la clase son inmutables.

El valor es un conjunto al tiempo de la creación del objeto; espere un argumento en un constructor, no espere operaciones que actualicen el valor.

La gente comete errores, vigile esta restricción en el modelo de especificación

124124

EstereotiposEstereotipos

Un estereotipo indica un nivel superior de clasificación

Jacobson, por ejemplo, distingue los 3 tipos de clases: objetos interfaz, objetos de control y entidades de objetos con íconos especiales para cada una

UML usa estereotipos como un mecanismo de extensión en lenguaje natural <<algún tipo>>

Dentro de los diagramas de clase pueden existir estereotipos para clases, asociaciones y generalizaciones.

125125

Clasificación Múltiple y DinámicaClasificación Múltiple y Dinámica

La clasificación simple y estática de los objetos es muy restrictiva para el modelamiento conceptual.

En la clasificación múltiple un objeto puede ser descrito por muchos tipos que no están necesariamente conectados por herencia (≠ herencia múltiple)

Los subtipos con el mismo discriminador (nombre del rol) son disjuntos.

El discriminador puede marcarse como {complete} No todos las combinaciones de subtipos son legales La clasificación dinámica permite a un objeto cambiar

de tipo dentro de la estructura de subtipos, se anota como <<dynamic>>

126126

127127

Customer

FrequentCustomer

Female

Male

CorporateCustomer

sex

type

{complete}

TransportCustomer

<<dynamic>>

CustomerName: stringAddress: stringSex: {Male,Female}

PrintAddress():void

128128

Clases AsociaciónClases Asociación

Las clases asociación permiten añadir atributos, operaciones y características a una asociación.

Es útil modelar la información que pertenece a una asociación dentro de ella misma y no dentro de los cualquiera de los dos o más objetos participantes.

Añada restricciones extras en comparación con el caso más general de tener a clase entre dos clases participantes: existe solamente una instancia de la clase asociación entre dos objetos participantes

129129

130130

CompanyExistsSince: Date

RoadSegment Distance:integerOpenSince:Date

NodeDescription

1begin1end

*

* owner**

OwnershipSince: Date

owns

131131

Asociaciones CalificadasAsociaciones Calificadas

Una asociación calificada es el equivalente en UML de las construcciones como listasdeasociación, mapas y diccionarios.

Un calificador es llevado con la clase fuente, una multiplicidad puede ser mostrada en el rol destino.

En un modelo conceptual indica una restricción En el modelo de especificación indica que el

acceso al destino se hace a través de una búsqueda bajo llave.

En el modelo de implementación muestra el uso de una estructura de datos asociativos.

132132

133133

CompanyExistsSince: Date

NodeDescription

Access Control Node

EnterLeave

Service Node

Description

0..1manages

134134

Clases ParmetrizadasClases Parmetrizadas

• Esta inspirada en la noción de clases parametrizadas (plantillas) de C++

• Es un concepto útil cuando se trabaja con colecciones en lenguajes estáticos.

• En UML una clase parametrizada obtiene un parámetro template

• Ya sea una sintaxis similar a la de C++ en el nombre de la clase o un estereotipo <<bind>> en una relación refinada puede ser usada para mostrar un elemento unido.

• Usar un elemento unido es diferente de subtipo, se trata de restringir el tipo solamente, no las nuevas características que pueden ser añadidas

135135

Sequence<RoadSegment>

{ordered}

*

Sequence

Insert(T)Remove(T)

T Sequence

Insert(T)Remove(T)

T

RoadSequence Distance



<<bind>><RoadSegment>




1 .. *



{ordered}

*

1

*

136136

Relaciones Avanzadas: DependenciaRelaciones Avanzadas: Dependencia

Relación “usa” El cambio en la especificación de una

cosa afecta a otra que la usa. 17 estereotipos pueden ser aplicado a las

relaciones de dependencia.

137137

PaquetesPaquetes

¿Como se divide un sistema grande en sistemas más pequeños?

Agrupar elementos del modelo juntos, por ejemplo clases

Paquete es una colección de elementos del modelo, por ejemplo una colección de paquetes relacionados y/o clases

Cada paquete debe contener una interfaz, conformada por el conjunto de sus clases públicas.

El resto de clases en un paquete son implementación, ej. No se comunican con otras clases en otros paquetes

138138

Relaciones entre PaquetesRelaciones entre Paquetes

Importar: una manera de acceso que especifica que los contenidos públicos del paquete importado entren al espacio de nombre del paquete importador, como si hubieran sido declarados en este.

Acceso: especifica que al paquete fuente se le otorga el derecho de referenciar los elementos del paquete destino.

Generalización: familias de paquetes

139139

140140

Diagramas de InteracciónDiagramas de Interacción

Los diagramas de interacción son los modelos que describen como los grupos de objetos colaborar en algún comportamiento.

Típicamente, un diagrama de interacción captura el comportamiento de un solo caso de uso.

Existe dos clases de diagramas de interacción: diagramas de secuencia y diagramas de colaboración

Ambos tipos de diagramas muestran un número de objetos ejemplo y los mensajes que son pasados entre estos objetos.

141141

Diagramas de Secuencia (1) Diagramas de Secuencia (1)

Los objetos se muestran como cajas en la parte superior de las líneas de vida usando el esquema de nombre de UML unNombreClase o NombreObjeto:NombreClase

Los mensajes son representados por flechas entre las líneas de vida de dos objetos. Los mensajes son rotulados con el nombre del mensaje y opcionalmente con los argumentos.

El orden el cual los mensajes ocurren es mostrado de arriba a abajo.

Delegación-propia o llamada-propia: un mensaje que un objeto se envía a si mismo, es mostrado como una flecha que regresa a la línea de vida.

142142

Diagramas de Secuencia (2) Diagramas de Secuencia (2)

Información de control puede ser añadida: Condiciones, ej. [checkOk] : el mensaje solo es enviado si la

condición es verdadera. Marcadores de Iteración. Ej. * DoSomething : muestra que un

mensaje ha sido enviado varias veces a múltiples objetos receptores. Las respuestas pueden ser mostradas a través de líneas

punteadas, estas pueden ser omitidas para evitar congestionar el diagrama

Para mostrar que un objeto esta activo, una caja de activación puede ser usada, esta hace el diagrama más difícil de leer, pero más fácil de entender.

La delegación de objetos puede mostrarse con una x grande

an Access Control Node a Card a Customer a Road Segment

a Trajectory

EnterisValid==Valid?

accountOK==checkAccount

[isValid And accountOK] New

LeaveComputeTotal

PrintInvoice

* GetDistanceGetUnitPrice

UpdateAccount

X

an Access Control Node a Card a Customer a Road Segment

a Trajectory

Enter isValid==Valid?

accountOK==checkAccount

[isValid And accountOK] New

LeaveComputeTotal

PrintInvoice

* GetDistanceGetUnitPrice

UpdateAccount

X

145145

Procesos Concurrentes en Diagramas de SecuenciaProcesos Concurrentes en Diagramas de Secuencia

Las cajas de activación aparecen explícitamente en la línea de vida para indicar ya sea ejecución o espera por la respuesta a un mensaje sincrónico.

Puntas de flecha indican mensajes asincrónicos: Crear un nuevo hilo (flecha arriba de activación) Crear un nuevo objeto (flecha a caja de objeto) Comunicación con un hilo que ya está corriendo

La consecuencias de delegación propia pueden ser mostradas más claramente a través de activaciones apiladas

Dos escenarios para un caso de uso pueden ser dibujados en dos diagramas o en un diagrama usando lógica condicional

an Access Control Node a Card a Customer

Enter

isValid==Valid?

accountOK==CheckAccount

[isValid And accountOK]

a Card Reader

Read

New

a Barrier a Traffic Light

Open

PutGreen

[after 30 sec]PutRed

a Trajectory

an Access Control Node a Card a Customer

Enter

CardValid?

AccountOk?

a Card Reader

Read

CardValid

AccountOk

ChecksComplete?

ChecksComplete?

a Trajectory

148148

Diagramas de ColaboraciónDiagramas de Colaboración

Objetos ejemplo son mostrados como íconos usando el esquema de UML unNombredeClase o NombreObjeto: NombreClase

Las flechas indican los mensajes enviados y la secuencia es indicada al numerar esos mensajes.

El esquema de numeración simple muestra la secuencia general solamente.

El esquema de numeración decimal hace más claro que operación llama a que otra operación.

La información de control aparece como en el diagrama de secuencia.

149149

Diagramas de Colaboración: EnlacesDiagramas de Colaboración: Enlaces

Los enlaces son instancias de una asociación El nombre del rol puede ser mostrado a cada fin de

enlace El nombre de la asociación puede ser mostrado cerca

del camino (subrayado) Estereotipos pueden ser agregados al fin de un enlace

para indicar varios tipos de implementación: Asociación Parámetro (parámetro de método) Local (variable local de un método) Global (variable global) Self (enlace a si mismo)

150150

an Access Control Node

a Card

a Customer

a Road Segment

a Trajectory

1. Enter

2. isValid==Valid?

3. accountOK==CheckAccount

4. [isValid And accountOK] New6. ComputeTotal

5. Leave9. PrintInvoice

7. * GetDistance

8. GetUnitPrice

10. UpdateAccount

151151

an Access Control Node

a Card

a Customer

a Road Segment

a Trajectory

1. Enter

1.1. isValid==Valid?

1.2. accountOK==CheckAccount

1.3. [isValid And accountOK] New2.1. ComputeTotal

2. Leave2.2. PrintInvoice

2.1.1. * GetDistance

2.1.2. GetUnitPrice

2.3. UpdateAccount

152152

Comparación D. de Secuencia y D. de ColaboraciónComparación D. de Secuencia y D. de Colaboración

Los diagramas de secuencia ponen mayor énfasis en la secuencia.

Los diagramas de colaboración permiten posicionar a los objetos de acuerdo a su relación estática.

Cualquier forma es ayudada por la simplicidad: cuando se representan muchos condicionales o lazos de comportamiento el método no sirve.

Cuando existe gran cantidad de comportamiento condicional es recomendable usar diagramas separados para cada escenario.

Los diagramas de interacción son buenos para buscar en el comportamiento de varios objetos dentro de un caso de uso simple; no son buenos para precisar la definición del comportamiento.

153153

Un diagrama de interacción bien estructuradoUn diagrama de interacción bien estructurado

Se enfoca en comunicar un aspecto de la dinámica del sistema.

Contiene solo aquellos elementos que son escenciales para comprender ese aspecto.

Provee detalles consistentes con el nivel de abstracción y deber exponer solo aquellos adornos que sean escenciales para comprenderlo.

No es tan minimalístico que desinforma al lector acerca de las semánticas que son importantes.

154154

Diagramas de estadoDiagramas de estado

Los diagramas de estados describen todos los posibles estados de en los que un objeto pude esta y como el objeto cambia de estado como resultados de eventos que llegan al objeto.

Los diagramas de estados son dibujados para una sola clase para mostrar el comportamiento a lo largo de la vida del objeto.

Usar diagramas de estado para aquellas clases que exhiben un comportamiento interesante solamente.

Interfaces de Usuario y objetos de control son candidatos populares.

155155

EstadosEstados

Los estdos son una condición o situación durante la vida de un objeto durante el cual: Satisface alguna condición, Realiza alguna actividad o Espera por algún evento

Los objetos permanecen en un estado por un período finito de tiempo.

156156

EstadosEstados

Diferentes partes de un estado: Nombre: cadena textual; un estado pude ser

anónimo Acciones de Entrada/Salida: acciones que son

ejecutadas al entrar o salir un estado. Transiciones internas: transiciones que son

manejadas sin causar un cambio de estado Subestados: estructura anidada de un estado,

involucrando subestados disjuntos (secuencialmente activos) o concurrentes (concurrentemente activos)

157157

Estados Inicial y FinalEstados Inicial y Final

El estado Inicial indica el punto por defecto en el cual comienza la máquina de estados o subestado (circulo lleno en negro)

El estado final indica que la ejecución de la máquina de estados ha sido completado (círculo lleno en negro rodeado de un círculo vacío)

Los estados inicial y final son seudo-estados. Ninguno tiene las partes de un estado normal, excepto por el nombre.

158158

TransicionesTransiciones

La transición es una relación entre dos estados que indica que: Un objeto en el primer estado realizará cierta

acción y Entrará al segundo estado cuando un evento

específico ocurra y condiciones específicas sean satisfechas.

Cuando se cambia de estado, se dice que se ha disparado la transición.

159159


Las transiciones tienen 5 partes: Estado fuente: este es el estado afectado

por la transición; si un objeto esta en el estado fuente, una transición de salida pude dispararse cuando el objeto recibe el evento disparador de la transición y si las condiciones de guarda son satisfechas.

Estado destino: el estado que esta activo luego de haber completado la transición

160160


Evento [Guarda] / Acción Evento disparador: el evento cuya recepción por

parte del objeto en el estado fuente hace que la transición se pueda disparar, dado que se cumpla con las condiciones de guarda.

Condiciones de Guarda: una expresión booleana que es evaluada cuando la transición es disparada por la recepción de un evento disparador; si la expresión evalúa verdadero, la transición se dispara, si la expresión evalúa falso, la transición no se dispara y si no hay otras transiciones disparadas por el mismo evento, el evento se pierde.

Acción : una cálculo ejecutable de manera atómica que puede actuar directamente en el objeto.

161161

EventosEventos

Nombre-evento ‘(‘ lista-parametros ‘)’ Nombre-parametro ‘:’ tipo-expresion Eventos por lapso de tiempo

after(5 segundos)after(10 segundos desde la salida de estado A)

Las condiciones que se vuelven verdaderas a través de la palabra reservada when seguida de una expresión booleana. (prueba continua de la condición hasta que sea verdadera)

Transiciones sin un evento dentro de su rótulo ocurren tan pronto la actividad asociada con el estado se termina

162162

Condiciones de GuardaCondiciones de Guarda

Expresiones booleanas encerradas entre corchetes y puestas después de un evento disparador.

Evaluadas solamente después de que el evento dispara la transición

Es posible tener múltiples transiciones desde el mismo estado fuente y con el mismo evento disparador, siempre y cuando las condiciones no sean las mismas.

Dentro de la expresión booleana, es posible incluir condiciones acerca del estado de un objeto.

163163

AcciónAcción

Una acción es un cálculo ejecutable atómicamente.

Las acciones pueden incluir: Llamadas a operaciones del objeto que posee el

diagrama de estado u otros objetos visibles. Creación y destrucción de otro objeto

Las acciones son atómicas, Ej.: no pueden ser ininterrumpidas por un evento y deben ejecutarse hasta su finalización. Una actividad pude ser interrumpida por otros eventos!

164164

idleDo/display welcome mess

checkingDo/Checks

Do/display wait mess

Enter

[Ok] / New, PutGreen, Open

refusing-accessDo/display refusal mess

[not Ok][after 30 sec]

165165

166166

idle

checking-card

Enter / CardOk?

[CardOk] / AccountOk?

refusing-access

[after 30 sec]checking-account

[not CardOk]

[not AccountOk]

[AccountOk] / New, PutGreen, Open

167167

Estados Avanzados y TransicionesEstados Avanzados y Transiciones

Los diagramas de estado UML tiene características avanzadas que ayudan a: Manejar modelos de comportamiento

complejos Reducir el número de estados y transiciones Codificar un número de “frases” comunes y

algo complejas

Acciones Entrada/Salida, transiciones interna, actividades.

168168

Acciones Entrada/SalidaAcciones Entrada/Salida

Enviar la misma acción cada vez que entra a un estado: En el símbolo poara el estado, incluir una acción de

entrada marcada con la palabrar reservada entry

Enviar la misma acción cada vez que se sale del estado. En el símbolo para el estado, incluir una acción de

salida marcándola con la palabra reservada exit

Las acciones de entrada y saldia pueen no tener argumentos o condiciones de guarda.

169169

Transiciones InternasTransiciones Internas

Los eventos ocurren dentro del estado pero son manejados sin salir del estado.

Diferente que auto-transiciones Auto-transiciones: un evento dispara la transición, el estado es

abandonado, una acción (si existe) es despachada, el mismo estado es reingresado. Una auto-transición despacha la acción de salida del estado y despacha la acción de entrada al estado.

Transición interna: si el evento es disparado, la acción correspondiente es despachada SIN abandonar y reentrar al estado.

Las transiciones internas pueden tener eventos con parámetros y condiciones de guarda, las transiciones internas son esencialmente interrupciones.

170170

ActividadesActividades

Las actividades son las que se ejecutan mientras el objeto está en un estado, esperando que un evento ocurra.

La transición Do especifica el trabajo que necesita ser realizado dentro de un estado luego que la acción de entrada es despachada.

La actividad de una transición do podría ser Nombrar otra máquina de estados, Especificar una secuencia de acciones.

Las acciones no son interrumpibles pero las secuencias de acciones sí.

171171

closedopen

closingDo/Activate-motor-till-open

SensorWarning/Blockmotor Entry/Ring-bellExit/Stop-bell

openingDo/activate-motor-till-closed

Entry/Ring-bellExit/Stop-bell

Open

Close

ringing silent

Stop-bell

Ring-bell

Sensorwarning / Blockmotor

172172

SubestadosSubestados

Superestados pueden ser introducidos para agrupar un número de estados. Todos los subestados heredan cualquier transición de los superestados. El uso de superestados hace los diagramas más leíbles.

Los diagramas de estados concurrentes combinan diferentes comportamientos diferentes de un objeto dado. Un objeto pude estar en diferentes estados, cada uno forma una sección concurrente en el diagrama

173173

Subestados Secuenciales (1)Subestados Secuenciales (1)

Subestados Secuenciales: los estados compuestos pueden ser introducidos para agrupar a varios estados. Si el objeto es un estado compuesto, es solamente uno

de sus subestados a un tiempo dado. (subestados son disjuntos)

Transiciones que llevan fuera de un estado compuesto pueden tener como fuente el estado compuesto o un subestado. En el primer caso, el control primero deja el estado animado, luego deja el estado compuesto.

De una fuente fuera del estado compuesto, una transición pude ser destino de un estado compuesto o subestado.

174174

Subestados Secuenciales (2)Subestados Secuenciales (2)

Si el destino es un estdo compuesto, este debe incluir toda el estado inicial al cual pasar el control leugo de entrar al estado compuesto y luego despachar su acción de entrada (si existe)

Si en el destino hay un subestado, el control pasa al subestdo luego de despachar la acción de netrada (si existe) del estado compuesto y luego la acción de entrada (si exsite) del subestado.

175175

idle

checking-card

Enter / CardOk?


refusing-access

[after 30 sec]checking-account[not CardOk]

[not AccountOk]


Cancel

Cancel

Cancel

176176

idle

checking-card

Enter / CardOk?


refusing-access

[after 30 sec]checking-account[not CardOk]

[not AccountOk]


Cancel

active

177177

closedopen

closingDo/Activate-motor-till-open


openingDo/activate-motor-till-closed


Open

Close

ringing silent

Stop-bell

Ring-bell

178178

Estados Concurrentes (1)Estados Concurrentes (1)

Estos subestados permiten especificar dos o más máquinas de estados que se ejecutan en paralelo en el contexto de un objeto englobante. Si un subestado concurrente alcanza el

estado final antes que el otro, el control en ese subestado espera a su estado fina. Cuando ambas máquinas de estado anidnadas alcanza su estado final, el control de los subestados concurrentes se une de nuevo en un solo flujo.

179179

idle

checking-card

Enter

AccountOk?checking-account

[CardOk]

[AccountOk]

/ New, PutGreen, Open

Cancel

CardOk?

checking

180180

Estados Concurrentes (2)Estados Concurrentes (2)

Las transiciones a un estado compuesto se descompone en subestados concurrentes. El control se divide entre tantos flujos concurrentes como subestado concurrentes existen.

La transición de un subestado compuesto descompuesto en subestados concurrentes, el control se une de nuevo en un solo flujo.

Si todos los subestados concurrentes llegan a su fin, o si existe una transición específica fuera del estado compuesto englobante, el control se une de nuevo en un solo flujo.

181181

Máquina de estados bien estructurada (1)Máquina de estados bien estructurada (1)

Una máquina de estados representa el aspecto dinámico de un objeto individual, representa por ejemplo una instancia de una clase, un caso de uso o todo un sistema.

Es simple y por lo tanto no debería contener estados o transiciones superfluas.

Tiene un contexto limpio y por lo tanto puede tener acceso a todos los objetos visibles a su objeto englobante.

Es eficiente y por lo tanto puede llevar a cabo su comportamiento con un balance óptimo entre tiempo y recursos requeridos por las acciones que despacha.

182182

Máquina de estados bien estructurada (2)Máquina de estados bien estructurada (2)

Es comprensible y por lo tanto debe nombrarse sus estado y transiciones con vocabulario del sistema

No está profundamente anidado. Usa pocos subestados concurrentes.

Programación Orientada a Objetos

Documents

Transcript of Programación Orientada a Objetos