Embed Size (px)
Citation preview
Programación Programación Orientada a ObjetosOrientada a Objetos
ANALISIS Y DISEÑOANALISIS Y DISEÑOUMLUML
22
¿Qué es UML?¿Qué es UML?
Filosofía
Metodología
Procesos
Notaciones
ModelosHerramientas de
Soporte
Guías
33
Análisis y Diseño Orientado a ObjetosAnálisis y Diseño Orientado a Objetos
Hubo una ola de métodos de Análisis y Diseño Orientado a Objetos (A&D OO) a finales de los 80s, principios de los 90
La mayoría de estos métodos consistían en un lenguaje de modelamiento gráfico y un proceso a manera de consejo en que pasos se debían llevar a cabo para realizar el desarrollo de sistemas. Ej. Análisis, diseño e implementación.
En la práctica cuando la gente decía que seguía un método, se refería a que usaban una notación.
Diferentes procesos son buenos para diferentes clientes y diferentes sistemas. La “guerra de métodos” no es necesaria.
Es molestoso cuando conceptos similares tienen notaciones diferentes y viceversa. La estandarización de la notación es algo útil
44
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.
55
¿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.
66
Esquema del proceso de DesarrolloEsquema del proceso de Desarrollo
Incepción: describe la lógica del negocio y el ámbito del proyecto.
Elaboración: recolecta requerimientos más detallados, hace un análisis y diseño a alto nivel para establecer una arquitectura básica y se proyecta el plan de acción
Construcción: iterativo e incremental, cada iteración desarrolla un software con calidad de producción que satisface a un subconjunto de los requerimientos.
Transición: pruebas, entrenamiento a usuarios, afinación de rendimiento.
Incepción TransiciónElaboración Construcción1 2 3 4 ...
77
Desarrollo de Software Orientado a ObjetosDesarrollo de Software Orientado a Objetos
Captura de Requerimientos: ¿que va a ser desarrollado? Análisis: construir un modelo conceptual del dominio y
escribir los casos de uso Diseño: decisiones sobre la arquitectura, especificación
completa de la estructura estática de los objetos y su comportamiento.
Implementación: la traducción del diseño a un lenguaje de programación específico.
CapturaRequerimientos
Análisis Diseño Implementación
88
Diagramas UMLDiagramas UML
Diagramas de Caso de Uso Diagramas de Clase y Objetos Diagramas de Interacción
Diagramas de secuencia Diagramas de colaboración
Diagrama de Estados Diagramas de Actividad Diagrama de Paquetes Diagramas de Componentes y Puesta en
Producción
99
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
1010
Ejemplo: CarreterasEjemplo: Carreteras
1111
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.
1212
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.
1313
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.
1414
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.
1515
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
1616
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.
1717
Modelo de Casos de Uso: Casos de Uso (2)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
1818
Modelo de Casos de Uso: Casos de Uso (3)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
1919
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.
2020
Ejemplo: CarreterasCasos de Uso (2)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.
2121
Ejemplo: CarreterasCasos de Uso (3)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.
2222
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
2323
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
2424
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.
2525
CaptureDeal
_________Extension points
After creation of the deal
AnalyzeRisk
PriceDeal
Valuation
LimitsExceeded
Trader
<<includes>>
RequestCatalog <<extends>>
SalesPerson
2626
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.
2727
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
2828
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
2929
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.
3030
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
3131
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
3232
3333
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.
3434
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
*
3535
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
3636
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
3737
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.
3838
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.
3939
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.
4040
1 .. 3CardValidFromValidThrue 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
4141
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.
4242
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”
4343
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
4444
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
4545
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.
4646
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.
4747
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.
4848
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
4949
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
5050
GeneralizaciónGeneralizació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
5151
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}
5252
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
5353
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.
5454
Agregación y ComposiciónAgregación y Composición
Agregación es una relación part-de “un caro 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
5555
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.
5656
Barrier
Access ControlNode
TrafficLight
Access Control Station
1
1
1..12
CardReader
1
CustomerName: stringAddress: stringDateOfBirth: Date
/Age():number
RoadSegment Distance
NodeDescription
1begin1end
*
*{age() >= 18}
{begin <> end}
5757
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}
5858
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
5959
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.
6060
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>>
6161
6262
Customer
FrequentCustomer
Female
Male
CorporateCustomer
sex
type
{complete}
TransportCustomer
<<dynamic>>
CustomerName: stringAddress: stringSex: {Male,Female}
PrintAddress():void
6363
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
6464
6565
CompanyExistsSince: Date
RoadSegment Distance:integerOpenSince:Date
NodeDescription
1begin1end
*
* owner**
OwnershipSince: Date
owns
6666
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.
6767
6868
CompanyExistsSince: Date
NodeDescription
Access Control Node
EnterLeave
Service Node
Description
0..1manages
6969
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
7070
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
*
7171
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.
7272
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.
7373
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.
7474
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
7777
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
8080
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.
8181
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)
8282
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
8383
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
8484
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.
8585
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.
8686
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.
8787
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.
8888
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)
8989
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.
9090
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.
9191
TransicionesTransiciones
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
9292
TransicionesTransiciones
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.
9393
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
9494
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.
9595
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!
9696
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]
9797
9898
idle
checking-card
Enter / CardOk?
[CardOk] / AccountOk?
refusing-access
[after 30 sec]checking-account
[not CardOk]
[not AccountOk]
[AccountOk] / New, PutGreen, Open
9999
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.
100100
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.
101101
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.
102102
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í.
103103
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
104104
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
105105
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.
106106
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.
107107
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
108108
idle
checking-card
Enter / CardOk?
[CardOk] / AccountOk?
refusing-access
[after 30 sec]checking-account[not CardOk]
[not AccountOk]
[AccountOk] / New, PutGreen, Open
Cancel
active
109109
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
110110
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.
111111
idle
checking-card
Enter
AccountOk?checking-account
[CardOk]
[AccountOk]
/ New, PutGreen, Open
Cancel
CardOk?
checking
112112
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.
113113
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.
114114
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.
