Modelo diseño

Modelo Diseño
Joan Sebastián Ramírez Pérez
2015

Agenda
 Contexto
 Diagrama de clases
 Diagrama de paquetes
 Diagrama de colaboraciones
 Bibliografía

¿Qué describe un diagrama de clases?
 Los tipos de objetos en el sistema.
 Las relaciones estáticas que existen entre ellos.
 Los atributos y operaciones de las clases.
 Las restricciones a las clases y a sus asociaciones.

¿Qué es una clase?
 Descripción de conjunto de objetos que comparten los mismos atributos,
operaciones, métodos, relaciones y semántica.
 Las clases son gráficamente representadas por cajas con compartimentos para:
 Nombre de la clase, atributos y operaciones.
 Responsabilidades, Reglas, Historia de Modificaciones, etc.

Clase
Una clase debe:
 proporcionar una abstracción bien definida de algo del dominio del problema o de
la solución.
 Contiene un conjunto pequeño de responsabilidades.
 Muestra una clara distinción entre la implementación y la especificación de la
abstracción.
 Ser sencilla, entendible, extensible y adaptable.

Interface
 Es una colección de operaciones que especifican un servicio de una clase o
componente, es decir, un comportamiento externamente visible de ese elemento.
 Se especifican las operaciones externamente visibles sin especificación de la
estructura interna.
 Contrato que adquiere la clase que la implementa.
 Gráficamente se representa como un circulo.

Tipos de relación.
 Asociación
 Generalización.
 Realización.
 Agregación.
 Composición.
 Dependencia.

¿Cómo se nombran las asociaciones?
 La dirección de lectura por defecto para la
asociación es de izquierda a derecha y de
arriba a abajo.
 El nombre debe comenzar con mayúscula
porque la asociación representa un
clasificador de enlaces entre instancias.
(UML )
 Cada extremo de la asociación es llamado
ROL. (tiene multiplicidad)

Asociación
 Relación estructural.
 Relación bilateral.

Generalización
 Es la relación taxonómica entre un elemento y otro elemento mas general.
 Concepto de herencia Programación Orientada a Objetos.
 Relación padre hijo.
 Dado un conjunto de clases, se busca responsabilidades, atributos y operaciones
comunes.
 Si B hereda de A es porque todo objeto de B es un objeto de A.

Realización
 Significa que existe una relación entre el padre y el hijo en la forma de una
implementación.

Agregación
 una clase “contiene” a otros elementos. Sin embargo la clase no pierde sentido sin
la existencia de los mismos.
 “Puede vivir sin ellos y sigue siendo la misma... clase”

Composición
 A diferencia de la agregación, este tipo de interacción indica que la integridad de la
clase, depende de los elementos asociados.
 “La clase pierde su integridad sin las clases relacionadas”

Dependencia
 Relación semántica entre dos elementos.
 No necesariamente se requiere que existan tipos de objetos relacionados.
 Indica que el cambio en una entidad afectara de una u otra forma la otra.

¿Cómo saber cuales son clases?
 Los términos usados por usuarios y desarrolladores para describir el sistema son
clases candidatas.
 Para cada clase, ¿cuáles son sus responsabilidades? ¿están balanceadas entre las
clases?
 ¿Qué atributos y operaciones necesita cada clase para llevar a cabo sus
responsabilidades?
 Identificación de sustantivos dentro del negocio.

Identificación sustantivos: ejemplo
biblioteca
Una biblioteca contiene libros y revistas. Puede haber varias copias de un libro.
Algunos de los libros son reservados sólo para préstamos a corto plazo. Todos los
otros pueden ser prestados a cualquier miembro de la biblioteca por tres semanas. Los
miembros de la biblioteca pueden normalmente solicitar hasta seis items de una vez,
pero miembros del staff pueden solicitar hasta doce items a la vez. Solamente
miembros del staff pueden pedir prestamos de revistas.
El sistema debe conservar la pista de cuando los libros y revistas son prestados y
retornados forzando las reglas de la biblioteca.

Relaciones entre clases
 Libro es un Item.
 Revista es un Item.
 Copia es una copia de Libro.
 MiembroDeBiblioteca.
 Item.
 MiembroDeStaff es un MiembroDeBiblioteca.
 ¿Es el Item necesario?

Operaciones
 MiembroDeBiblioteca pide prestado Copia.
 MiembroDeBiblioteca devuelve Copia.
 MiembroDeStaff pide prestado Revista.
 MiembroDeStaff devuelve Revista.

¿Qué es un diagrama de paquetes?
 Representación de la división de un sistema en agrupaciones lógicas mostrando las
dependencias entre esas agrupaciones. Dado que normalmente un paquete está
pensado como un directorio, los diagramas de paquetes suministran una
descomposición de la jerarquía lógica de un sistema.
 Los paquetes están normalmente organizados para maximizar la coherencia interna
dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes.

Estereotipos
 Existen dos estereotipos de la relación de dependencia entre paquetes,
<<import>> y <<Access>>.
 Ambos especifican que el paquete origen tiene acceso a los elementos del paquete
destino.
 La diferencia es que <<import>> añade al espacio de nombres del origen el
contenido del destino, evitando la calificación de nombres.

Dependencia
 La relación de dependencia indica que los elementos de un paquete utilizan o
importan los elementos del paquete del que dependen.

Generalización
 La generalización entre paquetes es similar a la generalización entre clases, los
paquetes hijos heredan los elementos del paquete padre. La generalización entre
paquetes suele utilizarse para especificar familias de paquetes.

Atención!!
 Se deben evitar referencias circulares tanto entre clases como en paquetes. Sin
embargo en clases algunas veces se hace inevitable.

Tarea
Leer:
http://www.agilemodeling.com/artifacts/packageDiagram.htm

¿Qué es?
 Un diagrama de colaboración es una representación de la interacción entre los objetos.
 Un diagrama de interacción que muestra los objetos, la forma en que se relacionan
(interacción) y los mensajes (métodos) que se envían.
 Los diagramas de colaboración muestran las relaciones entre los roles de los objetos. La
secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse
explícitamente mediante números de secuencia.
 Se puede convertir cualquier diagrama de secuencias en diagrama de colaboraciones y
viceversa. Por medio de esto se puede representar la información de secuencia en un
diagrama de colaboraciones. Para ello se agrega una cifra a la etiqueta de un mensaje,
la cual corresponde a la secuencia propia del mensaje. La cifra y el mensaje se separan
mediante dos puntos (:).

¿Qué busca?
 Especificar un contrato entre objetos.
 Implementar las asociaciones del diagrama de clases mediante el paso de mensajes
de un objeto a otro.
 Dicha implementación es llamada “enlace”.
 Mostrar cómo las instancias específicas de las clases trabajan juntas para conseguir
un objetivo común.

¿Qué contiene un diagrama de
colaboración?
 Objetos o Roles: nodos del grafo.
 Enlaces o comunicaciones: arcos del grafo.
 Mensajes: llevan número de secuencia y flecha dirigida.
 Anidamiento: se utiliza la numeración decimal Ej: 1, 1.1, 1.1.1 ........
 Iteración: colocar un * antes del número de secuencia y una cláusula de condición,
si es necesario. ej. *[x>0].
 Bifurcación: los caminos alternativos tendrán el mismo número de secuencia,
seguido del número de subsecuencia, y se deben distinguir por una condición.

¿Qué interacciones modelamos?
 Llamada: invoca una operación sobre un objeto. Puede ser a sí mismo.
 Retorno: el receptor de una llamada devuelve un valor al emisor, si es necesario.
 Envío: envía una señal a un objeto.
 Creación: para crear un objeto.
 Destrucción: para destruir un objeto. Puede destruirse a sí mismo.
 Secuenciación: el flujo de mensajes forma una secuencia. La secuencia es indicada
por un número antes del mensaje y una flecha dirigida. Para modelar caminos
alternativos, se coloca el mismo número de secuencia seguido de un número de
subsecuencia.

De diagrama de secuencia a diagrama de
colaboración
 Un lector solicita un libro al bibliotecario, y le brinda su título. El bibliotecario
busca el libro en un índice y solicita al asistente que le alcance el libro

De diagrama de secuencia a diagrama de
colaboración

Bibliografía
 Larman,C.:UmlyPatrones:Introducciónalanálisisydiseñoorientadoaobjetos,2ed.PrenticeHa
ll.2005.627p.
 Ambler,S.TheObjectPrimer.SecondEdition.CambridgeUniversityPress.2001.
 Buschmann,Franketal.:PatternOrientedSoftwareArchitecture,Volume1:ASystemofPatterns
,Willey&Sons,1996.
 GammaE.,Helm,R.,Johnson,R.,VlissidesJ.:DesignPatterns:ElementsofReusableObjectOrient
edSoftware,AddisonWesley,1995.
 Martin,J.YOdell,J.Analisisydiseñoorientadoaobjetos.PrenticeHall.1992.
 Eckel,Bruce.ThinkinginJava.PrenticeHall.1998.
 OMG.UMLSpecificationv1.3.1999.
 Fowler,M.PatternsofEnterpriseApplicationArchitecture.Addison-Wesley.2003.
 Gamma,Helm,JohnsonyVlissides.DesignPatterns.Addison-Wesley.1995.

Modelo diseño

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Modelo diseño

Más de Joan Sebastián Ramírez Pérez

Modelo diseño