modelo diseño

Modelo DiseñoJoan Sebastián Ramírez Pérez2015

Agenda

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

Agenda

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

UML 2.0

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.

Clase

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.

Diagrama de clases

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.

Asociación

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.

Generalización

Generalización

Realización

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

Realización

Agregación y composició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”

Agregación

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”

Composición

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.

Dependencia

Resumen

¿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 bibliotecaUna 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.

Identificación sustantivos: ejemplo bibliotecaUna 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.

Diagrama de clases

Agenda

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

¿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.

Ejemplo

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

Agenda

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

¿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.

Diagrama colaboración

Ejemplo

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

De diagrama de secuencia a diagrama de colaboración

Agenda

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

Bibliografía

Larman,C.:UmlyPatrones:Introducciónalanálisisydiseñoorientadoaobjetos,2ed.PrenticeHall.2005.627p.

Ambler,S.TheObjectPrimer.SecondEdition.CambridgeUniversityPress.2001. Buschmann,Franketal.:PatternOrientedSoftwareArchitecture,Volume1:ASystemofPatter

ns,Willey&Sons,1996. GammaE.,Helm,R.,Johnson,R.,VlissidesJ.:DesignPatterns:ElementsofReusableObjectOri

entedSoftware,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.

Gracias