Análisis y Diseño - Ecotec – Generando desarrollo, …€¦ · PPT file · Web...
182
Programación Programación Orientada a Orientada a Objetos Objetos ANALISIS Y DISEÑO ANALISIS Y DISEÑO UML UML
Transcript of Análisis y Diseño - Ecotec – Generando desarrollo, …€¦ · PPT file · Web...
Programación Programación Orientada a ObjetosOrientada a Objetos
ANALISIS Y DISEÑOANALISIS Y DISEÑOUMLUML
22
UML
• 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
UML
• 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
UML
• 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
UML
Hardware RealModelo - Hardware o Software
prototipo
Software Modelo en papel o Herramienta CASE
66
¿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
UML
¿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
UML
Los modelos se caracterizan por ser: Precisos Consistentes Fácil de comunicar Fácil de cambiar Entendibles
99
UML
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
UML
Método Boch
1111
UML
Método OMT
1212
UML
Método UML
1313
Lenguaje 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
UML
Se utiliza UML en diferentes tipos de sistemas: Sistemas de información Técnicos Tiempo real Distribuidos Software Sistemas de negocios
1515
UML
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
UML
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
UML
Análisis OO Diseño OO Construcción OO
Entender y especificarel problema
Resolver elproblema
Construir lasolución
Los Modelos se utilizan para….
1818
UML
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
UML
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
UML
• 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
UML
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
UML
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 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
UML
• 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 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 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
Casos de Uso
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
Casos de Uso
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
Casos de Uso
Sistema
Caso de Uso
Serie de transacciones de valor para el actorEntidad fuera del sistemaquien interactúa con este
3131
Casos de Uso
Sistema
Casos de uso del sistemaUsuariodel sistema
La Empresa
Cliente(usuario dela empresa)
Casos de uso de la empresa
3232
Casos de Uso
Hace depósito
Retira fondos Procesa préstamo
Añade cliente
Banco (empresa)
CajeraAgente
Cliente
Deposita cheque Adquiere préstamo
Sistema computacional
3333
Casos de Uso
¿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
Casos de Uso
¿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
Casos de Uso
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
Casos de Uso
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
Casos de Uso
Actualiza ficha de paciente
Respaldo de información en tape
Sistema de registros médicos
Enfermero
3838
Casos de Uso
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
Casos de Uso
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
Casos de Uso
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
Casos de Uso
Rol Y Rol Z
Rol X
SistemaDiagrama de Casos de Uso
4242
Casos de Uso
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
Casos de Uso
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
Casos de Uso
Objetivo a
Objetivo b
Objetivo d Objetivo e
Objetivo c
Rol Y
Rol X
Rol Z
Sistema
Diagrama de Casos de Uso
4545
Casos de Uso
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: Carreteras
4747
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)
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á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é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: 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)
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
Modelo de Casos de Uso: Casos de Uso (2)
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
Modelo de Casos de Uso: Casos de Uso (3)
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)
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
Ejemplo: CarreterasCasos de Uso (2)
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
Ejemplo: CarreterasCasos de Uso (3)
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 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 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í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)
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)
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)
• 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
Clase
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
Encontrar Objetos (Clases)
• 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
Encontrar Objetos (Clases)
Extraersubstantivos
Eliminar malasclases
Requerimientos
Dominio deProblema
Clases Candidatas Clases
7070
Encontrar Objetos (Clases)
• 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 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
Pulir Clases
• 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
Pulir Clases
• 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
Pulir Clases
• 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
Pulir Clases
• 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
Pulir Clases
• 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
Pulir Clases
• 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 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 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 Asociaciones
8181
Multiplicidad
• Un factor importante que se debe considerar es el número de asociaciones en las que un objeto puede participar en cualquier instante
8282
Multiplicidad
• 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
Multiplicidad
• 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
Multiplicidad
• 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
Multiplicidad
8686
Multiplicidad
8787
Tipos de Relaciones
• Además de la Asociación existen otros tipos de Relaciones entre los objetos– Agregación– Composición– Generalización
8888
Agregació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ón
9090
Composició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
Composición
9292
Composición
9393
Generalizació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
Generalización
9595
Dia
gram
a de
Cla
ses
9696
Diagrama de Clases (Preliminar)
• Taller: Constuir el diagrama de Clases del Ascensor
9797
Diagrama de Clases (Preliminar)
• Taller: Constuir el diagrama de Clases del Ascensor
9898
Clases 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
1begin1end
TrajectoryDateOfEntry
PrintInvoiceComputeTotal
{ordered}
entry
exit
*
*
*
*
*
card-used1
*
100100
a CardUnitPrice: 4ValidFrom:1/1/00ValidTo:30/6/01
a CardUnitPrice: 5ValidFrom:1/1/01ValidTo:30/6/01
a CardUnitPrice: 5ValidFrom:1/1/01ValidTo:31/12/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
a RoadSegmentDistance: 120
a RoadSegmentDistance: 20
end
begin
begin
end
begin
end
A TrajectoryDateOfEntry: 1/4/01
102102
Asociaciones
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 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ó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 .. 3 CardValidFromValidThrue UnitPrice
Valid?
registered-to1
RoadSegment Distance
NodeDescription
Access Control Node
EnterLeave
1
1 .. *
1
1begin1end
TrajectoryDateOfEntry
PrintInvoiceComputeTotal
{ordered}
entry
exit
*
*
*
*
*
card-used1
*
Customer NameAddress Account CheckAccountUpdateAccount
106106
Navegació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 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
Atributos
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
Operaciones
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
Operaciones 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 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 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
Generalización
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 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
Interfaces
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ó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ó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():numberRoadSegment Distance
NodeDescription
1begin1end
*
*{age() >= 18}
{begin <> end}
122122
Coleciones 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 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
Estereotipos
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á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ó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 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 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
TrajectoryDateOfEntry
PrintInvoiceComputeTotal
<<bind>><RoadSegment>
TrajectoryDateOfEntry
PrintInvoiceComputeTotal
RoadSegment Distance
1 .. *
TrajectoryDateOfEntry
PrintInvoiceComputeTotal
{ordered}
*1
*
136136
Relaciones 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
Paquetes
¿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 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ó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)
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)
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 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ó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: 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ó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 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 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
Estados
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
Estados
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 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
Transiciones
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
Transiciones
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
Transiciones
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
Eventos
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 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ó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 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/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 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
Actividades
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
Subestados
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: 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)
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?
[CardOk] / AccountOk?
refusing-access
[after 30 sec]checking-account[not CardOk]
[not AccountOk]
[AccountOk] / New, PutGreen, Open
Cancel
Cancel
Cancel
176176
idle
checking-card
Enter / CardOk?
[CardOk] / AccountOk?
refusing-access
[after 30 sec]checking-account[not CardOk]
[not AccountOk]
[AccountOk] / New, PutGreen, Open
Cancel
active
177177
closedopen
closingDo/Activate-motor-till-open
Entry/Ring-bellExit/Stop-bell
openingDo/activate-motor-till-closed
Entry/Ring-bellExit/Stop-bell
Open
Close
ringing silent
Stop-bell
Ring-bell
178178
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)
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)
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)
Es comprensible y por lo tanto debe nombrarse sus estado y transiciones con vocabulario del sistema
No está profundamente anidado. Usa pocos subestados concurrentes.
