Uml Diseno
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Uml Diseno as PDF for free.
More details
- Words: 4,177
- Pages: 49
Introducción al Paradigma Orientado a Objetos
1
Objetos
• ¿Qué es un objeto? Un objeto es un componente de software que contiene variables y métodos y que es usado para modelar algún aspecto de la “vida real”. Es una abstracción de la realidad.
• ¿Qué es una clase? Una clase es un plano o prototipo que define las variables y los métodos comunes a todos los objetos de un cierto tipo. 2
Objetos Los objetos son representaciones (simples/complejas) (reales/imaginarias) de cosas: reloj, avión empleado, etc.
No todo puede ser considerado como un objeto, algunas cosas son simplemente características o atributos de los objetos: color, velocidad, etc.
3
Objetos
Abstracción funcional
Abstracción de datos
Hay cosas que sabemos que los coches hacen pero no como lo hacen: • avanzar • parar • girar a la dcha • girar a la izda
Un coche tiene además ciertos atributos: • color • velocidad • tamaño • etc...
4
Objetos Los objetos encapsulan variables permitiendo acceso a ellas únicamente a través de los métodos Variables: Contenedores de valores Métodos: Contenedores de funciones Nombre de la Clase ------------------------------• Atributo1 • Atributo2 ------------------------------• Metodo1 • Metodo2 • Metodo3
Se puede permitir o restringir su acceso desde “afuera” Pueden ser Públicos o Privados
Estado: representado por el contenido de sus variables Comportamiento: definido por sus métodos
Objeto = Identidad + Estado + Comportamiento 5
Identidad • Oid (Object Identifier) Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes características: • Constituye un identificador único y global para cada objeto dentro dentro del sistema. • Es determinado en el momento de la creación del objeto. • Es independiente de la localización física del objeto, es decir, provee completa independencia de localización. • Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura. • No cambia durante toda la vida del objeto. Además, un oid no se reutiliza aunque el objeto deje de existir. • No se tiene ningún control sobre los oids y su manipulación resulta resulta transparente.
• Sin embargo, es preciso contar con algún medio para hacer referencia a un objeto utilizando referencias del dominio (valores de atributos). 6
Estado • El estado evoluciona con el tiempo. • Algunos atributos pueden ser constantes. • El comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. • Las operaciones de un objeto son consecuencia de un estímulo externo representado como mensaje enviado desde otro objeto.
7
Comportamiento • Los mensajes navegan por los enlaces, a priori en ambas direcciones. • La unidad de comunicación entre objetos se llama mensaje. • Estado y comportamiento están relacionados. • Ejemplo: no es posible aterrizar un avión si no está volando. Está Está volando como consecuencia de haber despegado del suelo. • Un estímulo causará la invocación de una operación, la creación o destrucción de un objeto o la aparición de una señal. • Un mensaje es la especificación de un estímulo.
8
Objetos • En UML, un objeto se representa por un rectángulo con un nombre subrayado.
9
Objetos • Ejemplo de varios objetos relacionados:
10
Objetos vs. Clases Una clase es una entidad abstracta • Es un tipo de clasificación de cosas • Define el comportamiento y atributos de un grupo de estructura y comportamientos similar
Un objeto es una instancia o variable de una clase • Un objeto se distingue de otros miembros de la clase por sus atributos.
11
Herencia Permite definir a partir de una clase, clase, otras clases relacionadas que supongan una: • Especialización de la clase dada. (Ej. la clase Automóvil es una especialización de la clase Vehículo) • Generalización de la clase dada. (La clase vehículo es una generalización de la clase Automóvil)
Si definimos la clase automóvil a partir de la clase vehículo se dice: dice: • “automóvil" hereda las variables y métodos de "vehículo" • “automóvil" extiende de "vehículo" • “automóvil" es subclase de "vehículo" • "vehículo" es superclase de “automóvil" 12
Polimorfismo • En programación orientada a objetos, el polimorfismo se refiere a la capacidad del lenguaje de programación de procesar objetos de manera distinta dependiendo de su tipo. • El polimorfismo representa en nuestro caso la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensaje. • Cada subclase hereda las operaciones pero tiene la posibilidad de de modificar localmente el comportamiento de estas operaciones.
13
Polimorfismo • Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta.
14
¿Preguntas?
15
UML
16
Objetivos de UML • Suministrar un lenguaje visual de modelado expresivo con el cual se pudieran crear e intercambiar modelos inteligibles. • Proveer mecanismos de extensión y especialización para ampliar los conceptos básicos. • Ser independiente de cualquier lenguaje de programación y de cualquier proceso de desarrollo.
17
Objetivos de UML • Incluir los fundamentos formales para entender el lenguaje. • Impulsar el desarrollo del mercado de herramientas OO. • Soportar los conceptos de desarrollo de alto nivel, tales como colaboraciones, marcos (frameworks), patrones (patterns) y componentes.
18
Diagrama de Clases
19
Diagrama de Clases • El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos del sistema o de un modelo de programación. • La clase define el ámbito de definición de un conjunto de objetos. • Cada objeto pertenece a una clase. • Los objetos se crean por instanciación de las clases.
20
Diagrama de Clases • Cada clase se representa en un rectángulo con tres compartimientos: • Nombre de la clase • Atributos de la clase • Operaciones de la clase
21
Diagrama de Clases: Atributos • • • • • • •
Tipo: Tipo: puede llegar a depender del lenguaje de programación a utilizar. utilizar. Valor inicial: inicial: valor que poseerá el atributo al crear un objeto. Visibilidad: Visibilidad: está relacionado con el encapsulamiento. Multiplicidad: Multiplicidad: determinar si un atributo debe estar o no, y si posee un único valor o una lista de valores. Ordenamiento: Ordenamiento: especifica si el atributo determina alguna relación de orden dentro dentro de la clase. Capacidad de cambio: cambio: permite definir atributos con valores constantes. Modificadores: Modificadores: un atributo puede ser de clase, derivado, volátil, transitorio. transitorio. El atributo fecha de nacimiento es público.
El atributo edad es derivado (puede calcularse a partir de la fecha de nacimiento), y determina una relación de orden entre las instancias de las personas. El atributo DNI es un atributo protegido.
El atributo coloresPreferidos representa una colección o conjunto de valores del tipo Color 22
Diagrama de Clases: Atributos Visibilidad La encapsulamiento presenta tres ventajas básicas: • • •
Se protegen los datos de accesos indebidos El acoplamiento entre las clases se disminuye Favorece la modularidad y el mantenimiento
Los atributos de una clase no deberían ser manipulables directamente directamente por el resto de objetos.
Niveles de encapsulamiento: (-) Privado : es el más fuerte. Esta parte es totalmente invisible desde fuera de la clase (excepto para clases friends en terminología terminología C++). (~) Package : Sólo es visible dentro del mismo package. (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original. (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio principio de encapsulamiento). 23
Diagrama de Clases: Atributos Multiplicidad 1
El atributo debe tener un único valor.
0..1
El atributo puede o no tener un valor.
0..*
El atributo puede tener varios valores o ninguno.
1..*
El atributo puede tener varios valores, pero debe tener al menos uno
*
El atributo puede tener varios valores.
M..N
El atributo puede tener entre M y N valores.
Modificadores • De clase o estático: estático: el atributo se aparece subrayado. No es necesario contar con un objeto para ejecutarlo. • Derivado: Derivado: es calculable a partir de otros atributos. • Transitorio: Transitorio: tendrá valor sólo durante una porción de la ejecución. • Volátil: Volátil: no se persiste.
24
Diagrama de Clases: Operaciones Una operación es un servicio que una instancia de la clase puede realizar. • • • •
Tipo devuelto: devuelto: puede llegar a depender del lenguaje de programación a utilizar. utilizar. Parámetros: Parámetros: además del tipo, puede especificarse si son In, Out o InOut. Visibilidad: Visibilidad: está relacionado con el encapsulamiento. Modificadores: Modificadores: una operación puede ser de clase, abstracta, query o constructor. constructor.
La operación calcularEdad es privado y no devuelve nada.
El método público calcularHorasTrabajadas es abstracto, las subclases de la clase Persona deberá implementarlo para utilizarlo.
25
Diagrama de Clases Relaciones entre Clases • Una asociación es una conexión estructural simple entre clases. Las instancias de las clases implicadas en una asociación estarán probablemente comunicándose en el momento de ejecución. • Los enlaces entre de objetos pueden representarse entre las respectivas clases • Formas de relación entre clases: • Asociación y Agregación (vista como un caso particular de asociación) • Generalización/Especialización 26
Diagrama de Clases: Asociación • La asociación expresa una conexión bidireccional entre objetos. • Una asociación es una abstracción de la relación existente en los enlaces entre los objetos.
Enlace
27
Diagrama de Clases Relaciones entre Clases Multiplicidad 1
Un elemento relacionado.
0..1
Uno o ningún elemento relacionado.
0..*
Varios elementos relacionados o ninguno.
1..*
Varios elementos relacionados pero al menos uno.
*
Varios elementos relacionados.
M..N
Entre M y N elementos relacionados.
28
Diagrama de Clases: Asociación Rol • Identificado como un nombre a los finales de la asociació asociación, describe la semá semántica de la relació relación en el sentido indicado. • Cada asociació asociación tiene dos roles; cada rol es una direcció dirección en la asociació asociación.
29
Diagrama de Clases: Asociación • Se asume que una asociación es bidireccional, es decir que se puede navegar desde cualquiera de clases implicadas a la otra, pero es posible indicar que la navegación ocurrirá en una sola dirección.
30
Diagrama de Clases: Agregación • Es una asociación especial, una relación del tipo “todo/parte” dentro de la cual una o más clases son partes de un conjunto.
31
Diagrama de Clases: Composición • La composición es una forma ‘fuerte’ de agregación. Se diferencian en: • En la composición tanto el todo como las partes tienen el mismo ciclo de vida. • Un objeto puede pertenecer solamente a una composición.
32
Diagrama de Clases: Asociación Calificada • Un calificador es un atributo (o tupla de atributos) de la asociación cuyos valores sirven para particionar el conjunto de objetos enlazados a otro. • Un calificador se representa como un pequeño rectángulo conectado al final de una asociación y a la clase. • El rectángulo del calificador es parte de la asociación, y no parte de la clase.
fila: fila: int columna: columna: int
33
Diagrama de Clases: Asociación nn-arias • Son asociaciones que se establecen entre má más de dos clases • Una clase puede aparecer varias veces desempeñ desempeñando distintos roles. • Las asociaciones nn-arias se representan a travé través de rombo que se une con cada una de las clases. clases. La relaciones nn-arias pueden ser usadas para impedir inconsistencias en el modelo.
34
Diagrama de Clases: Generalización • Una generalización se refiere a una relación entre una clase general (superclase o padre) y una versión más específica de dicha clase (subclase o hija).
35
Diagrama de Clases: Generalización • Nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada. • Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre están disponibles en sus clases hijas. • La especialización es una técnica muy eficaz para la extensión y reutilización. Restricciones predefinidas en UML: • Overlapping • Disjoint • Complete • Incomplete 36
Diagrama de Clases: Generalización • Particionamiento del espacio de objetos Clasificación Estática • Particionamiento del espacio de estados de los objetos Clasificación Dinámica • En ambos casos se recomienda considerar generalizaciones/especializaciones disjuntas • Usando discriminadores se pueden tener varias especializaciones de una misma clase padre
Discriminador
37
Diagrama de Clases: Generalización • La herencia múltiple debe manejarse con precaución. Algunos problemas son el conflicto de nombre y el conflicto de precedencia. precedencia. • Se recomienda un uso restringido y disciplinado de la herencia. • Permite modelar jerarquías alternativas.
38
Diagrama de Clases: Clase de asociación • Es una asociación y una clase simultáneamente. • Hay que tener en cuenta dónde se colocan los atributos.
39
Diagrama de Clases: Dependencia • Una dependencia es una relación de “uso” en la que un cambio en uno de los términos -por ejemplo, una claseclasepuede afectar a otro (otra clase)
40
Diagrama de Clases: Dependencia Posibles dependencias entre clases • use: use: el funcionamiento del origen depende de la presencia del destino • instantiate: instantiate: el origen crea instancias del destino • derive: derive: el origen puede calcularse a partir del destino • refine: refine: el origen está está un grado de abstracció abstracción má más detallado. • bind(): bind(): derivació derivación gené genérica de una plantilla • friend: friend: visibilidad caracterí característica de C++
41
Diagrama de Clases: Estereotipos • Un estereotipo representa el principal mecanismo de extensión de UML. Ofrece una forma de extender una metaclase, creando un nuevo elemento de metamodelo.
42
Diagrama de Clases: Interfaces • Una interfaz es una colección de operaciones que representan servicios ofrecidos por una clase o componente. • Por definición, todas estas operaciones tendrán una visibilidad pública. • La interfaz especifica algo similar a un contrato que la clase se compromete a respetar. • La clase realiza (o suministra una realización de) una o varias interfaces. • UML define dos tipos de interfaces: interfaz suministrada e interfaz requerida. 43
Diagrama de Clases: Interfaces • La interfaz suministrada es aquella que una clase efectivamente implementa.
44
Diagrama de Clases: Interfaces • Las interfaces requeridas son aquellas que necesita una clase para realizar su cometido. El símbolo utilizado para representarla es un semicírculo.
45
Ejemplo ¿Cómo interpretaría lo siguiente?
46
Modelo de Dominio vs. Modelo de Diseño • El diagrama de clases puede utilizarse con distintos fines en distintas etapas del proceso de desarrollo. • Durante la etapa de análisis, el modelo de dominio es encargado de mostrar el conjunto de clases conceptuales del problema y las relaciones presentes entre sí. • Durante la etapa de diseño, el modelo de diseño determina las futuras componentes de software (clases) y sus relaciones entre sí. 47
Modelo de Dominio • Es una representación de las cosas, entidades, idea, clases conceptuales u objetos del “mundo real” o dominio de interés, no de componentes de software. • Muestra clases conceptuales significativas en un dominio del problema. • Se usa como base para el diseño de los objetos de software.
48
Modelo de Dominio • Es el artefacto más importante del análisis. • Podría se considerado como un diccionario visual de abstracciones de clases conceptuales, vocabulario e información del dominio. • No es absolutamente correcto o incorrecto, su intenció intención en ser útil sirviendo como una herramienta de comunicació comunicación.
49
Modelo de Dominio • Otros nombres: modelo conceptual, modelo de objetos del dominio y modelo de los objetos de aná análisis. • Segú Según el punto de vista, tiene puntos en comú común con el Diagrama de Entidad Relació Relación. • Usando UML, el MD se representa con un conjunto de diagramas de clases. Se puede mostrar: • objetos del dominio o clases conceptuales • asociaciones entre las clases conceptuales • atributos de las clases conceptuales • NO SE DEFINE NINGUNA OPERACIÓ OPERACIÓN. La asignació asignación de responsabilidades de los objetos no forma parte de este modelo. 50
Modelo de Dominio: Clases Conceptuales Es vá válido… lido… • Tener clases conceptuales sin atributos. • Tener clases conceptuales para las cuales no haya requerimientos de informació información a registrar. • Tener clases conceptuales con rol de comportamiento, comportamiento, en lugar de informació información.
Estrategias para identificar • Utilizar lista de categorí categorías de clases conceptuales. • Identificar frases nominales (sustantivos o frases).
51
Modelo de Dominio: Clases Conceptuales
52
Modelo de Dominio: Clases Conceptuales Identificar frases nominales (sustantivos o frases) Se intenta identificar sustantivos o frases nominales en el vocabulario y descripciones del dominio del problema. Esta té técnica prá práctica no puede ser aplicada mecá mecánicamente sino que hay que usar el “sentido comú común” y capturar las abstracciones adecuadas puesto que el lenguaje natural es ambiguo y los conceptos relevantes no siempre se encuentran de manera explí explícita.
53
Ejemplo Un posible modelo de dominio para el caso del local de venta de electrodomé electrodomésticos… sticos…
54
Modelo de Diseño • A diferencia del Modelo de Dominio, el modelo de diseño se encuentra más cerca de la solución buscada. • Refleja decisiones en cuanto a asignación de responsabilidades entre los objetos (operaciones). • Toma como base el Modelo de Dominio, donde algunas entidades se promoverán a Clases. 55
Modelo de Diseño • Muestra cómo se relacionan componentes de software para resolver el problema planteado. • Es el paso previo a la implementación. • Es posible aplicar patterns según el tipo de problema.
56
Principios de Diseño
• • • • • •
Descomposición Abstracción Cohesión Bajo Acoplamiento Modularidad Encapsulamiento
57
Descomposición • Concepto común a todos los ciclos de vida y técnicas de diseño. • El concepto básico es simple: • Seleccionar una parte del problema • Determinar sus componentes usando cualquier mecanismo: funcional vs. estructuras de datos vs. orientado a objetos • Mostrar cómo interactúan los componentes • Repetir hasta satisfacer algún criterio de terminación
58
Abstracción • Provee un mecanismo para manejar la complejidad priorizando las características esenciales y suprimiendo los detalles de implementación. • Permite posponer ciertas decisiones de detalle que ocurren a distintos niveles de análisis: • Representaciones / Algoritmos • Arquitectura / Estructura • Externo / Funcional 59
Cohesión • Principio de unión entre los distintos aspectos que incluye una parte. • El concepto se aplica según la descomposición y el nivel de abstracción: • • • •
Relación entre las funcionalidades Relación entre las responsabilidades Relación entre los servicios Relación entre los datos 60
Bajo Acoplamiento • Principio de separación entre los distintos aspectos de distintas partes • El concepto se aplica según la descomposición y el nivel de abstracción: • • • •
Relación entre las funcionalidades Relación entre las responsabilidades Relación entre los servicios Relación entre los datos 61
Modularidad • Un sistema modular es un sistema estructurado con abstracciones altamente independientes llamadas módulos. • Modularidad es importante tanto para la etapa de diseño como de implementación. • Módulos deben tener interfaces abstractas bien definidas. • Módulos deben tener alta cohesión y bajo acoplamiento. 62
Encapsulamiento • Motivación: detalles de diseño que pueden cambiar se ocultan detrás de interfaces abstractas (módulos). • Los módulos se deben comunicar a través de interfaces bien definidas. • La información que se oculta incluye: • • • •
Representaciones de datos Algoritmos Entradas y salidas Interfaces de bajo nivel 63
Patrones de Diseño ¿Qué es un patrón de diseño? • Ante un problema reiterado ofrece una solución contrastada que lo resuelve. • Describe el problema en forma sencilla. • Describe el contexto en que ocurre. • Describe los pasos a seguir. • Describe los puntos fuertes y débiles de la solución. • Describe otros patrones asociados.
64
Patrones de Diseño ¿Por qué usarlos? • Mejora en la comunicación y documentación • “Hay que hacer un Factory Method” Method” • Facilita la documentación interna del proyecto.
• Mejora la ingeniería de software. • Eleva el nivel del grupo de desarrollo.
• Previene “reinventar la rueda” en diseño • Son soluciones ya probadas.
• Mejora la calidad y estructura • “¿Cuá “¿Cuán grande debe ser una clase?” 65
Patrones de Diseño Tipos de Patrones • De Creación: Creación: abstraen el proceso de creación de instancias. • Estructurales: Estructurales: se ocupan de cómo clases y objetos son utilizados para componer estructuras de mayor tamaño. • De Comportamiento: Comportamiento: atañen a los algoritmos y a la asignación de responsabilidades entre objetos. 66
Patrones de Diseño
Algunos nombres: • De Creación: • Factory Method, Method, Prototype, Prototype, Singleton, Singleton, etc.
• Estructurales: • Facade, Facade, Proxy, Proxy, Adapter, Adapter, etc.
• De Comportamiento: • Observer, Observer, Command, Command, Strategy, Strategy, etc. 67
Patrones de Diseño Cómo llegar a ser un maestro de ajedrez… ajedrez… 1. Primero, aprender las reglas del juego. juego. 2. A continuación, aprender los principios. principios. 3. Finalmente, para llegar a ser un maestro, hay que estudiar las partidas de otros maestros. maestros. Estas partidas contienen docenas de patrones que deben ser entendidos, memorizados y aplicados. aplicados.
… y para ser un maestro de software … 68
¿Preguntas?
69
Paquetes
70
Paquetes • Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado • Se representan gráficamente como:
71
Paquetes • Cada
paquete corresponde a un submodelo (subsistema) del modelo (sistema).
• Un
paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a (está (está definido en) só sólo un paquete.
• Entre
paquetes puede aparecer una relació relación de dependencia.
• Un
paquete encapsula a la vez que agrupa. 72
Paquetes • Un paquete es un grupo de elementos del modelo que pueden a su vez anidarse. • Son elementos auxiliares de organización y pueden contener cualquier elemento de modelado. • Su utilidad final es ganar claridad a costa de perder detalles que luego se podrán obtener al abrir el paquete. • Pueden ser utilizados con los distintos diagramas.
73
Paquetes • Se puede hacer referencia a una clase de otro paquete. • Cada clase se puede definir con visibilidad pública o privada. • Hay dos formas de referenciar elementos de otro paquete: access e import. import.
74
Paquetes • Se debe buscar que los elementos que se encuentren dentro de un mismo paquete posean alta cohesión entre sí y que haya bajo acoplamiento entre paquetes.
75
Ejemplo • Posible estructuración
76
¿Preguntas?
77
Diagrama de Objetos
78
Diagrama de Objetos • Muestra la interacción directa entre los objetos. • Es una representación del diagrama de clases en tiempo de ejecución, por tanto es una instancia posible del diagrama de clases. • Son útiles para representar escenarios.
79
Diagrama de Objetos
80
¿Preguntas?
81
Diagrama de Secuencia
82
Diagrama de Secuencia • Una interacción es un comportamiento que se centra en los intercambios observables de información entre los objetos. • Una línea de vida representa la participación de un objeto dado en una determinada interacción. Objetos
Mensajes Líneas de vida
Activación
83
Diagrama de Secuencia • Los objetos comunican a través de mensajes entre líneas de vida. • La notación para el mensaje siempre es una flecha, pero el tipo de flecha y la punta varía en función del tipo de mensaje: objeto
otroObjeto
84
Diagrama de Secuencia • También puede incluirse información referente a la creación y destrucción de objetos. objeto
otroObjeto
85
Diagrama de Secuencia Recursión • La operación oper() se llama a sí misma. Habrá una condición en la operación que parará la recursión. • Se muestra explícitamente la respuesta. objeto
86
Diagrama de Secuencia Ciclos y alternativas objeto
otroObjeto
objeto
otroObjeto
Muchas veces distintas alternativas pueden implicar distintos escenarios, que se deberían especificar con diagramas diferentes. 87
Ejemplo “… Supongamos que en una librería, un encargado debe registrar el préstamo de un libro… “
88
Otro ejemplo Un posible diseñ diseño para el caso del local de venta de electrodomé electrodomésticos… sticos…
89
Ejemplo “… tras autorizar la orden de compra, se debe emitir la factura correspondiente, la cual debe asentarse en la cuenta corriente …”
90
Ejemplo Veamos cómo se calcula el importe de la factura…
91
¿Preguntas?
92
Diagrama de Colaboración
93
Diagrama de Colaboración
• Son útiles en la fase exploratoria para identificar objetos. • La distribución de los objetos en el diagrama permite observar adecuadamente la interacción de un objeto con respecto de los demás. • La estructura estática viene dada por los enlaces; la dinámica por el envío de mensajes por los enlaces. 94
Diagrama de Colaboración: Mensajes • Un mensaje desencadena una acción en el objeto destinatario.
• Un mensaje puede ser enviado de manera condicionada. condicionada.
• Un mensaje puede devolver un resultado.
95
Diagrama de Colaboración
• La cronología, está dada mediante la numeración de los mensajes.
96
Colaboración vs. Secuencia • Ambos diagramas poseen un poder expresivo similar. • El diagrama de secuencia, otorga una mejor visión desde el punto de vista temporal o cronológico. • El diagrama de colaboración, otorga una mejor visión desde el punto de vista espacial. • En la etapa de análisis pueden ser utilizados para especificar escenarios. • En la etapa de diseño, contribuyen con la definición de los métodos de las clases. • s de sus interfaces. • Cada componente “realiza” o soporta algunas interfaces y “usa” otras provistas por otros componentes 97
1
Objetos
• ¿Qué es un objeto? Un objeto es un componente de software que contiene variables y métodos y que es usado para modelar algún aspecto de la “vida real”. Es una abstracción de la realidad.
• ¿Qué es una clase? Una clase es un plano o prototipo que define las variables y los métodos comunes a todos los objetos de un cierto tipo. 2
Objetos Los objetos son representaciones (simples/complejas) (reales/imaginarias) de cosas: reloj, avión empleado, etc.
No todo puede ser considerado como un objeto, algunas cosas son simplemente características o atributos de los objetos: color, velocidad, etc.
3
Objetos
Abstracción funcional
Abstracción de datos
Hay cosas que sabemos que los coches hacen pero no como lo hacen: • avanzar • parar • girar a la dcha • girar a la izda
Un coche tiene además ciertos atributos: • color • velocidad • tamaño • etc...
4
Objetos Los objetos encapsulan variables permitiendo acceso a ellas únicamente a través de los métodos Variables: Contenedores de valores Métodos: Contenedores de funciones Nombre de la Clase ------------------------------• Atributo1 • Atributo2 ------------------------------• Metodo1 • Metodo2 • Metodo3
Se puede permitir o restringir su acceso desde “afuera” Pueden ser Públicos o Privados
Estado: representado por el contenido de sus variables Comportamiento: definido por sus métodos
Objeto = Identidad + Estado + Comportamiento 5
Identidad • Oid (Object Identifier) Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes características: • Constituye un identificador único y global para cada objeto dentro dentro del sistema. • Es determinado en el momento de la creación del objeto. • Es independiente de la localización física del objeto, es decir, provee completa independencia de localización. • Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura. • No cambia durante toda la vida del objeto. Además, un oid no se reutiliza aunque el objeto deje de existir. • No se tiene ningún control sobre los oids y su manipulación resulta resulta transparente.
• Sin embargo, es preciso contar con algún medio para hacer referencia a un objeto utilizando referencias del dominio (valores de atributos). 6
Estado • El estado evoluciona con el tiempo. • Algunos atributos pueden ser constantes. • El comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. • Las operaciones de un objeto son consecuencia de un estímulo externo representado como mensaje enviado desde otro objeto.
7
Comportamiento • Los mensajes navegan por los enlaces, a priori en ambas direcciones. • La unidad de comunicación entre objetos se llama mensaje. • Estado y comportamiento están relacionados. • Ejemplo: no es posible aterrizar un avión si no está volando. Está Está volando como consecuencia de haber despegado del suelo. • Un estímulo causará la invocación de una operación, la creación o destrucción de un objeto o la aparición de una señal. • Un mensaje es la especificación de un estímulo.
8
Objetos • En UML, un objeto se representa por un rectángulo con un nombre subrayado.
9
Objetos • Ejemplo de varios objetos relacionados:
10
Objetos vs. Clases Una clase es una entidad abstracta • Es un tipo de clasificación de cosas • Define el comportamiento y atributos de un grupo de estructura y comportamientos similar
Un objeto es una instancia o variable de una clase • Un objeto se distingue de otros miembros de la clase por sus atributos.
11
Herencia Permite definir a partir de una clase, clase, otras clases relacionadas que supongan una: • Especialización de la clase dada. (Ej. la clase Automóvil es una especialización de la clase Vehículo) • Generalización de la clase dada. (La clase vehículo es una generalización de la clase Automóvil)
Si definimos la clase automóvil a partir de la clase vehículo se dice: dice: • “automóvil" hereda las variables y métodos de "vehículo" • “automóvil" extiende de "vehículo" • “automóvil" es subclase de "vehículo" • "vehículo" es superclase de “automóvil" 12
Polimorfismo • En programación orientada a objetos, el polimorfismo se refiere a la capacidad del lenguaje de programación de procesar objetos de manera distinta dependiendo de su tipo. • El polimorfismo representa en nuestro caso la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensaje. • Cada subclase hereda las operaciones pero tiene la posibilidad de de modificar localmente el comportamiento de estas operaciones.
13
Polimorfismo • Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta.
14
¿Preguntas?
15
UML
16
Objetivos de UML • Suministrar un lenguaje visual de modelado expresivo con el cual se pudieran crear e intercambiar modelos inteligibles. • Proveer mecanismos de extensión y especialización para ampliar los conceptos básicos. • Ser independiente de cualquier lenguaje de programación y de cualquier proceso de desarrollo.
17
Objetivos de UML • Incluir los fundamentos formales para entender el lenguaje. • Impulsar el desarrollo del mercado de herramientas OO. • Soportar los conceptos de desarrollo de alto nivel, tales como colaboraciones, marcos (frameworks), patrones (patterns) y componentes.
18
Diagrama de Clases
19
Diagrama de Clases • El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos del sistema o de un modelo de programación. • La clase define el ámbito de definición de un conjunto de objetos. • Cada objeto pertenece a una clase. • Los objetos se crean por instanciación de las clases.
20
Diagrama de Clases • Cada clase se representa en un rectángulo con tres compartimientos: • Nombre de la clase • Atributos de la clase • Operaciones de la clase
21
Diagrama de Clases: Atributos • • • • • • •
Tipo: Tipo: puede llegar a depender del lenguaje de programación a utilizar. utilizar. Valor inicial: inicial: valor que poseerá el atributo al crear un objeto. Visibilidad: Visibilidad: está relacionado con el encapsulamiento. Multiplicidad: Multiplicidad: determinar si un atributo debe estar o no, y si posee un único valor o una lista de valores. Ordenamiento: Ordenamiento: especifica si el atributo determina alguna relación de orden dentro dentro de la clase. Capacidad de cambio: cambio: permite definir atributos con valores constantes. Modificadores: Modificadores: un atributo puede ser de clase, derivado, volátil, transitorio. transitorio. El atributo fecha de nacimiento es público.
El atributo edad es derivado (puede calcularse a partir de la fecha de nacimiento), y determina una relación de orden entre las instancias de las personas. El atributo DNI es un atributo protegido.
El atributo coloresPreferidos representa una colección o conjunto de valores del tipo Color 22
Diagrama de Clases: Atributos Visibilidad La encapsulamiento presenta tres ventajas básicas: • • •
Se protegen los datos de accesos indebidos El acoplamiento entre las clases se disminuye Favorece la modularidad y el mantenimiento
Los atributos de una clase no deberían ser manipulables directamente directamente por el resto de objetos.
Niveles de encapsulamiento: (-) Privado : es el más fuerte. Esta parte es totalmente invisible desde fuera de la clase (excepto para clases friends en terminología terminología C++). (~) Package : Sólo es visible dentro del mismo package. (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original. (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio principio de encapsulamiento). 23
Diagrama de Clases: Atributos Multiplicidad 1
El atributo debe tener un único valor.
0..1
El atributo puede o no tener un valor.
0..*
El atributo puede tener varios valores o ninguno.
1..*
El atributo puede tener varios valores, pero debe tener al menos uno
*
El atributo puede tener varios valores.
M..N
El atributo puede tener entre M y N valores.
Modificadores • De clase o estático: estático: el atributo se aparece subrayado. No es necesario contar con un objeto para ejecutarlo. • Derivado: Derivado: es calculable a partir de otros atributos. • Transitorio: Transitorio: tendrá valor sólo durante una porción de la ejecución. • Volátil: Volátil: no se persiste.
24
Diagrama de Clases: Operaciones Una operación es un servicio que una instancia de la clase puede realizar. • • • •
Tipo devuelto: devuelto: puede llegar a depender del lenguaje de programación a utilizar. utilizar. Parámetros: Parámetros: además del tipo, puede especificarse si son In, Out o InOut. Visibilidad: Visibilidad: está relacionado con el encapsulamiento. Modificadores: Modificadores: una operación puede ser de clase, abstracta, query o constructor. constructor.
La operación calcularEdad es privado y no devuelve nada.
El método público calcularHorasTrabajadas es abstracto, las subclases de la clase Persona deberá implementarlo para utilizarlo.
25
Diagrama de Clases Relaciones entre Clases • Una asociación es una conexión estructural simple entre clases. Las instancias de las clases implicadas en una asociación estarán probablemente comunicándose en el momento de ejecución. • Los enlaces entre de objetos pueden representarse entre las respectivas clases • Formas de relación entre clases: • Asociación y Agregación (vista como un caso particular de asociación) • Generalización/Especialización 26
Diagrama de Clases: Asociación • La asociación expresa una conexión bidireccional entre objetos. • Una asociación es una abstracción de la relación existente en los enlaces entre los objetos.
Enlace
27
Diagrama de Clases Relaciones entre Clases Multiplicidad 1
Un elemento relacionado.
0..1
Uno o ningún elemento relacionado.
0..*
Varios elementos relacionados o ninguno.
1..*
Varios elementos relacionados pero al menos uno.
*
Varios elementos relacionados.
M..N
Entre M y N elementos relacionados.
28
Diagrama de Clases: Asociación Rol • Identificado como un nombre a los finales de la asociació asociación, describe la semá semántica de la relació relación en el sentido indicado. • Cada asociació asociación tiene dos roles; cada rol es una direcció dirección en la asociació asociación.
29
Diagrama de Clases: Asociación • Se asume que una asociación es bidireccional, es decir que se puede navegar desde cualquiera de clases implicadas a la otra, pero es posible indicar que la navegación ocurrirá en una sola dirección.
30
Diagrama de Clases: Agregación • Es una asociación especial, una relación del tipo “todo/parte” dentro de la cual una o más clases son partes de un conjunto.
31
Diagrama de Clases: Composición • La composición es una forma ‘fuerte’ de agregación. Se diferencian en: • En la composición tanto el todo como las partes tienen el mismo ciclo de vida. • Un objeto puede pertenecer solamente a una composición.
32
Diagrama de Clases: Asociación Calificada • Un calificador es un atributo (o tupla de atributos) de la asociación cuyos valores sirven para particionar el conjunto de objetos enlazados a otro. • Un calificador se representa como un pequeño rectángulo conectado al final de una asociación y a la clase. • El rectángulo del calificador es parte de la asociación, y no parte de la clase.
fila: fila: int columna: columna: int
33
Diagrama de Clases: Asociación nn-arias • Son asociaciones que se establecen entre má más de dos clases • Una clase puede aparecer varias veces desempeñ desempeñando distintos roles. • Las asociaciones nn-arias se representan a travé través de rombo que se une con cada una de las clases. clases. La relaciones nn-arias pueden ser usadas para impedir inconsistencias en el modelo.
34
Diagrama de Clases: Generalización • Una generalización se refiere a una relación entre una clase general (superclase o padre) y una versión más específica de dicha clase (subclase o hija).
35
Diagrama de Clases: Generalización • Nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada. • Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre están disponibles en sus clases hijas. • La especialización es una técnica muy eficaz para la extensión y reutilización. Restricciones predefinidas en UML: • Overlapping • Disjoint • Complete • Incomplete 36
Diagrama de Clases: Generalización • Particionamiento del espacio de objetos Clasificación Estática • Particionamiento del espacio de estados de los objetos Clasificación Dinámica • En ambos casos se recomienda considerar generalizaciones/especializaciones disjuntas • Usando discriminadores se pueden tener varias especializaciones de una misma clase padre
Discriminador
37
Diagrama de Clases: Generalización • La herencia múltiple debe manejarse con precaución. Algunos problemas son el conflicto de nombre y el conflicto de precedencia. precedencia. • Se recomienda un uso restringido y disciplinado de la herencia. • Permite modelar jerarquías alternativas.
38
Diagrama de Clases: Clase de asociación • Es una asociación y una clase simultáneamente. • Hay que tener en cuenta dónde se colocan los atributos.
39
Diagrama de Clases: Dependencia • Una dependencia es una relación de “uso” en la que un cambio en uno de los términos -por ejemplo, una claseclasepuede afectar a otro (otra clase)
40
Diagrama de Clases: Dependencia Posibles dependencias entre clases • use: use: el funcionamiento del origen depende de la presencia del destino • instantiate: instantiate: el origen crea instancias del destino • derive: derive: el origen puede calcularse a partir del destino • refine: refine: el origen está está un grado de abstracció abstracción má más detallado. • bind(): bind(): derivació derivación gené genérica de una plantilla • friend: friend: visibilidad caracterí característica de C++
41
Diagrama de Clases: Estereotipos • Un estereotipo representa el principal mecanismo de extensión de UML. Ofrece una forma de extender una metaclase, creando un nuevo elemento de metamodelo.
42
Diagrama de Clases: Interfaces • Una interfaz es una colección de operaciones que representan servicios ofrecidos por una clase o componente. • Por definición, todas estas operaciones tendrán una visibilidad pública. • La interfaz especifica algo similar a un contrato que la clase se compromete a respetar. • La clase realiza (o suministra una realización de) una o varias interfaces. • UML define dos tipos de interfaces: interfaz suministrada e interfaz requerida. 43
Diagrama de Clases: Interfaces • La interfaz suministrada es aquella que una clase efectivamente implementa.
44
Diagrama de Clases: Interfaces • Las interfaces requeridas son aquellas que necesita una clase para realizar su cometido. El símbolo utilizado para representarla es un semicírculo.
45
Ejemplo ¿Cómo interpretaría lo siguiente?
46
Modelo de Dominio vs. Modelo de Diseño • El diagrama de clases puede utilizarse con distintos fines en distintas etapas del proceso de desarrollo. • Durante la etapa de análisis, el modelo de dominio es encargado de mostrar el conjunto de clases conceptuales del problema y las relaciones presentes entre sí. • Durante la etapa de diseño, el modelo de diseño determina las futuras componentes de software (clases) y sus relaciones entre sí. 47
Modelo de Dominio • Es una representación de las cosas, entidades, idea, clases conceptuales u objetos del “mundo real” o dominio de interés, no de componentes de software. • Muestra clases conceptuales significativas en un dominio del problema. • Se usa como base para el diseño de los objetos de software.
48
Modelo de Dominio • Es el artefacto más importante del análisis. • Podría se considerado como un diccionario visual de abstracciones de clases conceptuales, vocabulario e información del dominio. • No es absolutamente correcto o incorrecto, su intenció intención en ser útil sirviendo como una herramienta de comunicació comunicación.
49
Modelo de Dominio • Otros nombres: modelo conceptual, modelo de objetos del dominio y modelo de los objetos de aná análisis. • Segú Según el punto de vista, tiene puntos en comú común con el Diagrama de Entidad Relació Relación. • Usando UML, el MD se representa con un conjunto de diagramas de clases. Se puede mostrar: • objetos del dominio o clases conceptuales • asociaciones entre las clases conceptuales • atributos de las clases conceptuales • NO SE DEFINE NINGUNA OPERACIÓ OPERACIÓN. La asignació asignación de responsabilidades de los objetos no forma parte de este modelo. 50
Modelo de Dominio: Clases Conceptuales Es vá válido… lido… • Tener clases conceptuales sin atributos. • Tener clases conceptuales para las cuales no haya requerimientos de informació información a registrar. • Tener clases conceptuales con rol de comportamiento, comportamiento, en lugar de informació información.
Estrategias para identificar • Utilizar lista de categorí categorías de clases conceptuales. • Identificar frases nominales (sustantivos o frases).
51
Modelo de Dominio: Clases Conceptuales
52
Modelo de Dominio: Clases Conceptuales Identificar frases nominales (sustantivos o frases) Se intenta identificar sustantivos o frases nominales en el vocabulario y descripciones del dominio del problema. Esta té técnica prá práctica no puede ser aplicada mecá mecánicamente sino que hay que usar el “sentido comú común” y capturar las abstracciones adecuadas puesto que el lenguaje natural es ambiguo y los conceptos relevantes no siempre se encuentran de manera explí explícita.
53
Ejemplo Un posible modelo de dominio para el caso del local de venta de electrodomé electrodomésticos… sticos…
54
Modelo de Diseño • A diferencia del Modelo de Dominio, el modelo de diseño se encuentra más cerca de la solución buscada. • Refleja decisiones en cuanto a asignación de responsabilidades entre los objetos (operaciones). • Toma como base el Modelo de Dominio, donde algunas entidades se promoverán a Clases. 55
Modelo de Diseño • Muestra cómo se relacionan componentes de software para resolver el problema planteado. • Es el paso previo a la implementación. • Es posible aplicar patterns según el tipo de problema.
56
Principios de Diseño
• • • • • •
Descomposición Abstracción Cohesión Bajo Acoplamiento Modularidad Encapsulamiento
57
Descomposición • Concepto común a todos los ciclos de vida y técnicas de diseño. • El concepto básico es simple: • Seleccionar una parte del problema • Determinar sus componentes usando cualquier mecanismo: funcional vs. estructuras de datos vs. orientado a objetos • Mostrar cómo interactúan los componentes • Repetir hasta satisfacer algún criterio de terminación
58
Abstracción • Provee un mecanismo para manejar la complejidad priorizando las características esenciales y suprimiendo los detalles de implementación. • Permite posponer ciertas decisiones de detalle que ocurren a distintos niveles de análisis: • Representaciones / Algoritmos • Arquitectura / Estructura • Externo / Funcional 59
Cohesión • Principio de unión entre los distintos aspectos que incluye una parte. • El concepto se aplica según la descomposición y el nivel de abstracción: • • • •
Relación entre las funcionalidades Relación entre las responsabilidades Relación entre los servicios Relación entre los datos 60
Bajo Acoplamiento • Principio de separación entre los distintos aspectos de distintas partes • El concepto se aplica según la descomposición y el nivel de abstracción: • • • •
Relación entre las funcionalidades Relación entre las responsabilidades Relación entre los servicios Relación entre los datos 61
Modularidad • Un sistema modular es un sistema estructurado con abstracciones altamente independientes llamadas módulos. • Modularidad es importante tanto para la etapa de diseño como de implementación. • Módulos deben tener interfaces abstractas bien definidas. • Módulos deben tener alta cohesión y bajo acoplamiento. 62
Encapsulamiento • Motivación: detalles de diseño que pueden cambiar se ocultan detrás de interfaces abstractas (módulos). • Los módulos se deben comunicar a través de interfaces bien definidas. • La información que se oculta incluye: • • • •
Representaciones de datos Algoritmos Entradas y salidas Interfaces de bajo nivel 63
Patrones de Diseño ¿Qué es un patrón de diseño? • Ante un problema reiterado ofrece una solución contrastada que lo resuelve. • Describe el problema en forma sencilla. • Describe el contexto en que ocurre. • Describe los pasos a seguir. • Describe los puntos fuertes y débiles de la solución. • Describe otros patrones asociados.
64
Patrones de Diseño ¿Por qué usarlos? • Mejora en la comunicación y documentación • “Hay que hacer un Factory Method” Method” • Facilita la documentación interna del proyecto.
• Mejora la ingeniería de software. • Eleva el nivel del grupo de desarrollo.
• Previene “reinventar la rueda” en diseño • Son soluciones ya probadas.
• Mejora la calidad y estructura • “¿Cuá “¿Cuán grande debe ser una clase?” 65
Patrones de Diseño Tipos de Patrones • De Creación: Creación: abstraen el proceso de creación de instancias. • Estructurales: Estructurales: se ocupan de cómo clases y objetos son utilizados para componer estructuras de mayor tamaño. • De Comportamiento: Comportamiento: atañen a los algoritmos y a la asignación de responsabilidades entre objetos. 66
Patrones de Diseño
Algunos nombres: • De Creación: • Factory Method, Method, Prototype, Prototype, Singleton, Singleton, etc.
• Estructurales: • Facade, Facade, Proxy, Proxy, Adapter, Adapter, etc.
• De Comportamiento: • Observer, Observer, Command, Command, Strategy, Strategy, etc. 67
Patrones de Diseño Cómo llegar a ser un maestro de ajedrez… ajedrez… 1. Primero, aprender las reglas del juego. juego. 2. A continuación, aprender los principios. principios. 3. Finalmente, para llegar a ser un maestro, hay que estudiar las partidas de otros maestros. maestros. Estas partidas contienen docenas de patrones que deben ser entendidos, memorizados y aplicados. aplicados.
… y para ser un maestro de software … 68
¿Preguntas?
69
Paquetes
70
Paquetes • Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado • Se representan gráficamente como:
71
Paquetes • Cada
paquete corresponde a un submodelo (subsistema) del modelo (sistema).
• Un
paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a (está (está definido en) só sólo un paquete.
• Entre
paquetes puede aparecer una relació relación de dependencia.
• Un
paquete encapsula a la vez que agrupa. 72
Paquetes • Un paquete es un grupo de elementos del modelo que pueden a su vez anidarse. • Son elementos auxiliares de organización y pueden contener cualquier elemento de modelado. • Su utilidad final es ganar claridad a costa de perder detalles que luego se podrán obtener al abrir el paquete. • Pueden ser utilizados con los distintos diagramas.
73
Paquetes • Se puede hacer referencia a una clase de otro paquete. • Cada clase se puede definir con visibilidad pública o privada. • Hay dos formas de referenciar elementos de otro paquete: access e import. import.
74
Paquetes • Se debe buscar que los elementos que se encuentren dentro de un mismo paquete posean alta cohesión entre sí y que haya bajo acoplamiento entre paquetes.
75
Ejemplo • Posible estructuración
76
¿Preguntas?
77
Diagrama de Objetos
78
Diagrama de Objetos • Muestra la interacción directa entre los objetos. • Es una representación del diagrama de clases en tiempo de ejecución, por tanto es una instancia posible del diagrama de clases. • Son útiles para representar escenarios.
79
Diagrama de Objetos
80
¿Preguntas?
81
Diagrama de Secuencia
82
Diagrama de Secuencia • Una interacción es un comportamiento que se centra en los intercambios observables de información entre los objetos. • Una línea de vida representa la participación de un objeto dado en una determinada interacción. Objetos
Mensajes Líneas de vida
Activación
83
Diagrama de Secuencia • Los objetos comunican a través de mensajes entre líneas de vida. • La notación para el mensaje siempre es una flecha, pero el tipo de flecha y la punta varía en función del tipo de mensaje: objeto
otroObjeto
84
Diagrama de Secuencia • También puede incluirse información referente a la creación y destrucción de objetos. objeto
otroObjeto
85
Diagrama de Secuencia Recursión • La operación oper() se llama a sí misma. Habrá una condición en la operación que parará la recursión. • Se muestra explícitamente la respuesta. objeto
86
Diagrama de Secuencia Ciclos y alternativas objeto
otroObjeto
objeto
otroObjeto
Muchas veces distintas alternativas pueden implicar distintos escenarios, que se deberían especificar con diagramas diferentes. 87
Ejemplo “… Supongamos que en una librería, un encargado debe registrar el préstamo de un libro… “
88
Otro ejemplo Un posible diseñ diseño para el caso del local de venta de electrodomé electrodomésticos… sticos…
89
Ejemplo “… tras autorizar la orden de compra, se debe emitir la factura correspondiente, la cual debe asentarse en la cuenta corriente …”
90
Ejemplo Veamos cómo se calcula el importe de la factura…
91
¿Preguntas?
92
Diagrama de Colaboración
93
Diagrama de Colaboración
• Son útiles en la fase exploratoria para identificar objetos. • La distribución de los objetos en el diagrama permite observar adecuadamente la interacción de un objeto con respecto de los demás. • La estructura estática viene dada por los enlaces; la dinámica por el envío de mensajes por los enlaces. 94
Diagrama de Colaboración: Mensajes • Un mensaje desencadena una acción en el objeto destinatario.
• Un mensaje puede ser enviado de manera condicionada. condicionada.
• Un mensaje puede devolver un resultado.
95
Diagrama de Colaboración
• La cronología, está dada mediante la numeración de los mensajes.
96
Colaboración vs. Secuencia • Ambos diagramas poseen un poder expresivo similar. • El diagrama de secuencia, otorga una mejor visión desde el punto de vista temporal o cronológico. • El diagrama de colaboración, otorga una mejor visión desde el punto de vista espacial. • En la etapa de análisis pueden ser utilizados para especificar escenarios. • En la etapa de diseño, contribuyen con la definición de los métodos de las clases. • s de sus interfaces. • Cada componente “realiza” o soporta algunas interfaces y “usa” otras provistas por otros componentes 97
