08-uml (1)

49
Prof. Jannelly Bello ANÁLISIS Y DISEÑO O.O

Upload: montox-jesus-montoya-vilchez

Post on 14-Apr-2016

220 views

Category:

Documents


0 download

DESCRIPTION

uml

TRANSCRIPT

Page 1: 08-UML (1)

Prof. Jannelly Bello

ANÁLISIS Y DISEÑO O.O

Page 2: 08-UML (1)

A.O.O Y D.O.O

Page 3: 08-UML (1)

ANÁLISIS ORIENTADO A OBJETOS (AOO)

Desarrollar modelos que describan el software a desarrollar y de esta manera satisfacer los requerimientos del cliente. Permite obtener:

Definición de Clases y la Relación entre las mismas. Funcionamiento Interno de las clases (atributos y métodos). Mecanismo de comunicación entre clases.

Objetivo

Consiste en definir todas las clases que representan el problema a resolver, la forma en que se relacionan e interactúan unas con otras, el funcionamiento interno (atributos y operaciones) de los objetos y los mecanismos de comunicación (mensajes) que les permiten trabajar juntos.

¿Qué es?

Diagramas de caso de Uso: Describe las funcionalidades del sistema a partir de las interacciones del usuario.

Diagrama de Clases sin nivel de detalle.

Diagramas

Page 4: 08-UML (1)

PASOS PARA A.O.O Definición de CASOS DE USO.

Definición de escenarios de cómo interactúan los actores con el sistema a desarrollar.

Modelar las características estáticas de las clasesSe realiza utilizando un Lenguaje Unificado de Modelado.

Page 5: 08-UML (1)

DISEÑO ORIENTADO A OBJETOS (DOO)

Desarrollar modelos que describan el software a desarrollar y de esta manera satisfacer los requerimientos del cliente

Objetivo

Consiste en definir los detalles internos de cada clase, definición de atributos, operaciones y detalles de los mensajes.

¿Qué es?

Diagrama de clases: Describe el sistema identificando sus clases y relaciones entre ellas.

Diagrama de colaboración: Describe la interacción entre objetos organizadas alrededor de las asociaciones entre ellos.

Diagrama de secuencia: Describe la interacción entre los objetos ordenada en un periodo de tiempo.

Diagramas

Page 6: 08-UML (1)

Prof. Jannelly Bello

LENGUAJE UNIFICADO DE MODELADOUML

Page 7: 08-UML (1)

CONTENIDO PROGRAMÁTICO Definición Origen Principios del UML Diagramas

Diagrama de Casos de Uso Diagrama de Clases

Relaciones de Asociación Relaciones de Todo/Parte Relaciones de Generalización/Especialización

Diagrama de Colaboración Diagrama de Secuencia Diagrama de Paquetes

Page 8: 08-UML (1)

¿QUÉ ES UML? Lenguaje Unificado de Modelado Permite Visualizar, Especificar, Construir, y

Documentar software orientado a objetos. Divide el sistema en un conjunto de diagramas que

a su vez representan una vista del proyecto. Todos los diagramas muestran en conjunto la

arquitectura del proyecto.

Page 9: 08-UML (1)

ORIGEN La notación UML se deriva y unifica las tres

metodologías de análisis y diseño Orientado a objetos: Grady Booch, James Rumbaugh e Ivar Jacobson.

El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método ISOO (Ingeniería del Software Orientada a Objetos).

Las metodologías de Booch y Rumbaugh se enfocan hacia el modelado de los objetos que conforman el sistema, su relación y colaboración.

Page 10: 08-UML (1)

ORIGEN La metodología de Jacobson se enfoca en el usuario.

Todo en su método se deriva de los casos de uso. UML se ha ido fomentando y aceptando como

estándar desde la formación de OMG (Object Management Group - Grupo de Gestión de Objetos).

En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar para el análisis y el diseño orientado a objetos.

En la actualidad  ya se publicó la revisión 2.0.

Page 11: 08-UML (1)

PRINCIPIOS La forma como vemos el problema tiene una

profunda influencia en la forma como acometemos el problema y le damos solución al mismo.

Para modelar un sistema complejo no es suficiente un único modelo se requieren múltiples modelos donde cada uno representa una vista del sistema; estos modelos se complementan entre si.

Cualquier modelo puede ser representado con diferentes grados de precisión.

Los mejores Modelos están ligados a la realidad.

Page 12: 08-UML (1)

DIAGRAMAS

Page 13: 08-UML (1)

DIAGRAMA DE CASOS DE USO¿Qué es un Caso de Uso? Describe la funcionalidad del sistema desde el punto de vista del

usuario, es decir, se refiere al uso que se le dará al sistema.

Notación:Son representados por un óvalo y nombrados siempre con verbos en infinitivo. Ejemplo: Inscribir a Curso.

Inscribir a Curso

Page 14: 08-UML (1)

DIAGRAMA DE CASOS DE USO¿Qué es un Actor? Agente externo que interactúa con el sistema. Representa un

conjunto coherente de roles que juegan los usuarios de los casos de uso al interactuar con el sistema.

Notación:Representados por una figura de alambre de una persona.

Page 15: 08-UML (1)

DIAGRAMA DE CASOS DE USO¿Qué es un Diagrama de Caso de Uso? Describe las funcionalidades del sistema a partir de las

interacciones del usuario.

Relaciones entre Casos de Uso: Asociación: Comunicación entre un actor y un caso de uso

donde participa. Notación: Inclusión:   Relación de dependencia entre dos casos de uso

que denota la inclusión del comportamiento de un escenario en otro. Se utiliza cuando existen casos de uso cuyo comportamiento es común a varios casos de uso. Se representa incluyendo una etiqueta <<include>> sobre la flecha que conduce al caso de uso que se incluye.

Page 16: 08-UML (1)

DIAGRAMA DE CASOS DE USOExtensión: Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro, es decir, incluye comportamiento bajo determinadas condiciones.

Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero. Se denota con una relación que apunta del caso extendido al caso base incluyendo una etiqueta <<extend>> sobre la flecha.

Page 17: 08-UML (1)

DIAGRAMA DE CASOS DE USOCuando utilizar <<extends>> o <<include>>

Usar relaciones extendidas para comportamientos excepcionales, opcionales o que rara vez suceden.

Usar relaciones de inclusión para comportamientos que se comparten entre dos o más casos de uso

Page 18: 08-UML (1)

DIAGRAMA DE CASOS DE USO

Page 19: 08-UML (1)

IDENTIFICACIÓN DE CLASESUn objeto potencial debe satisfacer las siguientes características para ser considerado posible miembro del modelo:

• Retener Información: Se requiere guardar información para el funcionamiento del sistema

• Servicios necesarios: Conjunto de operaciones identificables que permitan cambiar el estado de sus atributos.

• Múltiples atributos.• Atributos comunes: El conjunto de atributos de la clase debe

aplicar a todas las ocurrencias del objeto• Operaciones comunes: El conjunto de operaciones debe aplicar a

todos los objetos de la clase.

Page 20: 08-UML (1)

IDENTIFICACIÓN DE CLASESClase Dispositivo: Entidades externas (sensores, motores, teclado).

Clase Propiedad: Representa alguna propiedad importante del entorno (Ejemplo: Establecimiento de créditos dentro del contexto de una aplicación de préstamos hipotecarios)

Clase interacción: Modelan interacciones entre objetos. (Ejemplo: Reservación de libros)

Page 21: 08-UML (1)

DIAGRAMA DE CLASES¿Qué es ?

Modela los conceptos del dominio de la aplicación: describe el sistema identificando sus clases y relaciones.

Componentes: Clases: Atributos, Métodos, Visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y uso.

Page 22: 08-UML (1)

DIAGRAMA DE CLASESClases

Representada por un rectángulo con tres divisiones:

Nombre Clase

Atributos

Operaciones

Page 23: 08-UML (1)

DIAGRAMA DE CLASESAtributos

Pueden ser de tres tipos (definen el grado de comunicación y la visibilidad de los atributos con el entorno).

Public (+): Indica que el atributo será visible tanto dentro como fuera de la clase.

Private (-): Indica que el atributo sólo será accesible desde la clase. Protected(#): Indica que el atributo no será accesible desde fuera

de la clase, pero si podrá ser accedido por métodos de la clase y subclases que se derivan (Herencia).

Page 24: 08-UML (1)

DIAGRAMA DE CLASESMétodos

Presentan tres características:

Public (+): Indica que el métodos será visible tanto dentro como fuera de la clase.

Private (-): Indica que el método sólo será accesible desde la clase. Protected(#): Indica que el método no será accesible desde fuera

de la clase, pero si podrá ser accedido por métodos de la clase y subclases que se derivan (Herencia).

Page 25: 08-UML (1)

DIAGRAMA DE CLASESRelaciones entre Clases Asociación: Representa la relación existente entre dos clases de

forma conceptual. Se documenta destacando el rol que juega cada clase en la asociación.

Simbología:

Page 26: 08-UML (1)

DIAGRAMA DE CLASESRestricciones en las asociaciones

Page 27: 08-UML (1)

DIAGRAMA DE CLASESRelaciones entre Clases

Cardinalidad (Multiplicidad): Indica el grado y nivel de

dependencia entre clases. Cantidad de objetos de

una clase que pueden relacionarse con un objeto de una clase asociada,

Puede ser: 1 (uno y sólo uno) 0…1 (cero o uno) N…M (desde N hasta M) * (cero o varios) 0…* (cero o varios) 1…* (uno o varios)

Page 28: 08-UML (1)

DIAGRAMA DE CLASESAsociaciones Reflexivas

Una clase es asociación consigo misma Una clase tiene objetos que pueden jugar diversos papeles o

roles.

Page 29: 08-UML (1)

DIAGRAMA DE CLASESRelaciones entre Clases Herencia (especialización/generalización):

Indica que una subclase hereda métodos y atributos de una super clase. La subclase además de poseer sus propios métodos y atributos, poseerá las características visibles de la superclase (Public y Protected).

Simbología

Page 30: 08-UML (1)

DIAGRAMA DE CLASESRelaciones entre Clases: Clases abstractas

Page 31: 08-UML (1)

DIAGRAMA DE CLASESRelaciones entre Clases Agregación:

Se da cuando una clase describe objetos que agregan otros objetos. (Todo Parte) Simbología

Page 32: 08-UML (1)

DIAGRAMA DE CLASESRelaciones entre Clases Restricciones en las agregaciones:

Sopa

Page 33: 08-UML (1)

DIAGRAMA DE CLASESRelaciones entre Clases

Composición (Agregación Exclusiva): Se da cuando un objeto contiene un numero de otros objetos y cuando el objeto contenedor se eliminan todas las instancias de los objetos que están contenidos desaparecen.Es una asociación fuerte, que implica tres cosas: Dependencia existencial: El elemento dependiente desaparece

al destruirse el que lo contiene. Hay una pertenencia fuerte: Se puede decir que el objeto

contenido es parte constitutiva y vital del que lo contiene Los objetos contenidos no son compartidos, esto es, no hacen parte

del estado de otro objeto.

Simbología

Page 34: 08-UML (1)

DIAGRAMA DE CLASES

Page 35: 08-UML (1)

DIAGRAMA DE SECUENCIA¿Qué es un diagrama de secuencia?

Modela la secuencia lógica, a través del tiempo, de los mensajes entre las instancias (objetos).

Notación: �Objetos: Se colocan en la parte superior del diagrama. Línea de tiempo: Representado por una línea discontinua.

------------- Avanza de arriba hacia abajo.

Línea de vida de los objetos: Representado con un rectángulo. Desciende de cada uno de los objetos. Indica la activación de un objeto (ejecución de una de las

operaciones del objeto).

Page 36: 08-UML (1)

DIAGRAMA DE SECUENCIANotación: � Mensajes :

Representados con flechas. Conectan una línea de vida con otra. Su ubicación en la dimensión vertical indica

el momento en el que sucede dentro de la secuencia. Los más cercanos a la parte superior del diagrama se ejecutan primero, los que ocurren después cerca de la parte inferior.

Recursividad: Representada con una flecha que regresa al objeto que inicio recursividad. Se da cuando el objeto ejecuta una de sus operaciones.

Page 37: 08-UML (1)

DIAGRAMA DE SECUENCIA

Page 38: 08-UML (1)

DIAGRAMA DE COLABORACIÓN¿Qué es un Diagrama de Colaboración? Un Diagrama de Colaboración describe las interacciones entre objetos

haciendo énfasis en la estructura de la colaboración Muestra la relación entre objetos y los mensajes que se envían entre sí.

Notación Asociación: Se representa con una línea continua. Mensaje: Se representa con una flecha cerca de la de la línea de

asociación. La flecha apunta al objeto receptor. Tipo de Mensaje: Se muestra en una etiqueta cerca de la flecha. Indica

al objeto receptor que ejecute una de sus operaciones. Finalizará con paréntesis, estos contienen los parámetros (en caso de que se requieran) con los que funcionara la operación. Ej: Agregar(Par1,Par2…)

Secuencia del Mensaje: Representada por una cifra que se agrega a la etiqueta del mensaje. La cifra y el mensaje se separan por medio de dos puntos (:). Ej: 1:Agregar(Par1, Par2).

Page 39: 08-UML (1)

DIAGRAMA DE COLABORACIÓN

Page 40: 08-UML (1)

DIAGRAMA DE COLABORACIÓN

Page 41: 08-UML (1)

EJEMPLO UML

MÁQUINA DISPENSADORA

DE GASEOSAS

Page 42: 08-UML (1)

CASOS DE USO

Page 43: 08-UML (1)

DIAGRAMA DE SECUENCIA

Page 44: 08-UML (1)

DIAGRAMA DE COLABORACION MEJOR DE LOS CASOS

Page 45: 08-UML (1)

DIAGRAMA DE SECUENCIA GENÉRICO

Page 46: 08-UML (1)

DIAGRAMA DE COLABORACION GENÉRICO

Page 47: 08-UML (1)

DIAGRAMA DE PAQUETES¿Qué es un Paquete?

Un paquete es un mecanismo que permite organizar modelos/subsistemas, agrupando elementos de modelado. Cada paquete representa a un submodelo (subsistema) del modelo (sistema).

Un paquete puede contener a otro paquete sin límite de anidamiento.

Un paquete no sólo se utiliza para agrupar clases, sino cualquier elemento estructural de UML.

La principal relación entre paquetes es de dependencia: se produce cuando los cambios en el destino generan cambios en el origen.

Page 48: 08-UML (1)

DIAGRAMA DE PAQUETESRepresentación de un Paquete

Se representan como carpetas y contienen los elementos que comparten un espacio de nombre.

Los elementos dentro de un paquete deben tener un identificador único. El paquete debe mostrar el nombre del paquete y puede opcionalmente

mostrar los elementos dentro del paquete en compartimientos extras. Cuando se incluyen clases a los paquetes, es útil asignar las clases con la

misma jerarquía de herencia, las clases que están relacionadas a través de la composición y las clases que colaboran.

Page 49: 08-UML (1)

DIAGRAMA DE PAQUETES¿Qué es un Diagrama de Paquetes?

Diagrama que representa cómo están organizados los elementos del modelo así como las dependencias entre esos paquetes.  

El uso más común de los diagramas de paquete es para organizar diagramas de casos de uso y diagramas de clases, aunque el uso de los diagramas de paquete no se limita a los elementos UML.