modelo diseño

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

Upload: joan-sebastian-ramirez-perez

Post on 16-Jan-2017

222 views

Category:

Software


0 download

TRANSCRIPT

Page 1: Modelo diseño

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

Page 2: Modelo diseño

Agenda

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

Page 3: Modelo diseño

Agenda

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

Page 4: Modelo diseño

UML 2.0

Page 5: Modelo diseño

Agenda

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

Page 6: Modelo diseño

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

Page 7: Modelo diseño

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

Page 8: Modelo diseño

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.

Page 9: Modelo diseño

Clase

Page 10: Modelo diseño

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.

Page 11: Modelo diseño

Diagrama de clases

Page 12: Modelo diseño

Tipos de relación.

Asociación Generalización. Realización. Agregación. Composición. Dependencia.

Page 13: Modelo diseño

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

Page 14: Modelo diseño

Asociación

Relación estructural. Relación bilateral.

Page 15: Modelo diseño

Asociación

Page 16: Modelo diseño

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.

Page 17: Modelo diseño

Generalización

Page 18: Modelo diseño

Generalización

Page 19: Modelo diseño

Realización

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

Page 20: Modelo diseño

Realización

Page 21: Modelo diseño

Agregación y composición

Page 22: Modelo diseño

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”

Page 23: Modelo diseño

Agregación

Page 24: Modelo diseño

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”

Page 25: Modelo diseño

Composición

Page 26: Modelo diseño

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.

Page 27: Modelo diseño

Dependencia

Page 28: Modelo diseño

Resumen

Page 29: Modelo diseño

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

Page 30: Modelo diseño

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.

Page 31: Modelo diseño

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.

Page 32: Modelo diseño

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?

Page 33: Modelo diseño

Operaciones

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

Page 34: Modelo diseño

Diagrama de clases

Page 35: Modelo diseño

Agenda

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

Page 36: Modelo diseño

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

Page 37: Modelo diseño
Page 38: Modelo diseño

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.

Page 39: Modelo diseño

Dependencia

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

Page 40: Modelo diseño

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.

Page 41: Modelo diseño

Ejemplo

Page 42: Modelo diseño

Atención!!

Se deben evitar referencias circulares tanto entre clases como en paquetes. Sin embargo en clases algunas veces se hace inevitable.

Page 43: Modelo diseño

Tarea

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

Page 44: Modelo diseño

Agenda

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

Page 45: Modelo diseño

¿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 (:).

Page 46: Modelo diseño

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

Page 47: Modelo diseño

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

Page 48: Modelo diseño

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

Page 49: Modelo diseño

Diagrama colaboración

Page 50: Modelo diseño

Ejemplo

Page 51: Modelo diseño

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

Page 52: Modelo diseño

De diagrama de secuencia a diagrama de colaboración

Page 53: Modelo diseño

De diagrama de secuencia a diagrama de colaboración

Page 54: Modelo diseño

Agenda

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

Page 55: Modelo diseño

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.

Page 56: Modelo diseño
Page 57: Modelo diseño

Gracias