Diagrama de clases

21
Diagramas de Clases Materia: ANÁLISIS Y DISEÑO DE SISTEMAS II Integrantes: Paralelo: 6 / A-1 Gestión: 1 / 2014

Transcript of Diagrama de clases

Page 1: Diagrama de clases

Diagramas de ClasesMateria: ANÁLISIS Y DISEÑO DE SISTEMAS IIIntegrantes:Paralelo: 6 / A-1Gestión: 1 / 2014

Page 2: Diagrama de clases

Diagramas de Clases Los diagramas de clases son diagramas de estructura estática que

muestran las clases del sistema y sus interrelaciones Los diagramas de clase son el pilar básico del modelado con UML, siendo

utilizados tanto para mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo puede ser construido (diseño).

El diagrama de clases de más alto nivel, será lógicamente un dibujo de los paquetes que componen el sistema. Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos. Las relaciones entre clases se documentan con una descripción de su propósito, sus objetos que intervienen en la relación y su opcionalidad (cuando un objeto es opcional el que intervenga en una relación).

Page 3: Diagrama de clases

Definición de diagrama de claseEl Diagrama de Clases es el diagrama principal para el análisis y diseño. Un

diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones. El mundo real puede ser visto desde abstracciones diferentes (subjetividad).

Page 4: Diagrama de clases

Los diagramas de clase representan la estructura del sistema. Se utilizan:

Durante el análisis de requerimientos para modelar los conceptos del dominio del problema

Durante el diseño del sistema para modelar los subsistemas e interfaces

Durante el diseño de objetos para modelar clases

Page 5: Diagrama de clases

Elementos de los diagramas de clases Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un

rectángulo que posee tres divisiones:

En donde: Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que

caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma

como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Page 6: Diagrama de clases

Elementos de los diagramas de clases Atributos: son valores que corresponden a un objeto, como color, material,

cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Ejemplo: el objeto es una puerta, sus propiedades o atributos serían: la marca, tamaño, color y peso.

Tipos de atributos: public (+, ): Indica que el atributo será visible tanto dentro como

fuera de la clase, es decir, es accesible desde todos lados. private (-, ): Indica que el atributo sólo será accesible desde dentro

de la clase (sólo sus métodos lo pueden utilizar). protected (#, ): Indica que el atributo no será accesible desde fuera

de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

Page 7: Diagrama de clases

Elementos de los diagramas de clases Operaciones/Métodos: son aquellas actividades o verbos que se pueden

realizar con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, confirmar, cargar. El nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

Tipos de métodos: public (+, ): Indica que el método será visible tanto dentro como

fuera de la clase, es decir, es accesible desde todos lados. private (-, ): Indica que el método sólo será accesible desde dentro

de la clase (sólo otros métodos de la clase lo pueden utilizar). protected (#, ): Indica que el método no será accesible desde fuera

de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

Page 8: Diagrama de clases

Cardinalidad Cardinalidad de relaciones: indica el grado y nivel de dependencia de las

clases, se anotan en cada extremo de la relación y éstas pueden ser: * = Cero, uno ó n. 0,1 = Cero o uno. 1..* = Uno o más. 1 = Exactamente uno (también podría ser otro número). 1..5 = Entre uno y cinco.

Elementos de los diagramas de clases

Page 9: Diagrama de clases

Relaciones Las clases casi nunca se encuentran aisladas. Por lo general la mayoría de

ellas colaboran con otras de varias maneras.Se examinan los diagramas de interacción para determinar qué tipo de

relación entre objetos tiene que existir para que pueda darse el comportamiento deseado, entonces Si 2 objetos necesitan comunicarse, debe haber una relación entre ellos.

Elementos de los diagramas de clases

Page 10: Diagrama de clases

Herencia o generalizaciónIndica que una subclase hereda los métodos y atributos especificados por una Super Clase (también llamada clase padre), por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected).

Relaciones

Page 11: Diagrama de clases

Asociación Asociación: 

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

Relaciones

Page 12: Diagrama de clases

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo")

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Relaciones

Agregación

Page 13: Diagrama de clases

Relaciones

Agregación

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente.

Page 14: Diagrama de clases

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicación):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).

Relaciones

Dependencia o Instanciación

Page 15: Diagrama de clases

Dependencia con otros artefactos La definición de este tipo de diagramas se lleva a cabo en la fase de diseño

del ciclo de desarrollo.Su preparación exige crear antes:Diagrama de Interacción: a partir de ello el diseñador identifica las clases

de software que intervienen en la solución, así como los métodos de las clases.

Modelo Conceptual: a partir de este el diseñador agrega detalles a la definición de las clases.

Page 16: Diagrama de clases

Construcción del diagrama de clases

Identificar todas las clases que participan en la solución del software. Para ello analicé los diagramas de iteración.

Dibujar en un diagrama de clases.Duplicar los atributos provenientes de los conceptos asociados del

modelo conceptual.Agregar los nombres de los métodos analizando los diagramas de

iteración.Incorporar la información sobre los tipos a los atributos y a los

métodos.Agregar las asociaciones necesarias para indicar la dirección de los

atributos.Agregar flechas de navegabilidad a en las asociaciones para indicar la

dirección de los atributos

Page 17: Diagrama de clases

Ejemplo (Modelo Conceptual)

Page 18: Diagrama de clases

Ejemplo (Diagrama de Clases)

Page 19: Diagrama de clases

Ventajas Es el más utilizado y más conocido de los diagramas orientados a objetos. Genera un código automáticamente. Propone soluciones a algunos errores. Representa las relaciones entre las clases de sistema. Se diseña los componentes de los sistemas. Se protegen los datos. Se posibilita una reducción de acoplamiento. Es la fuente de generación de código. El diagrama de clase representa clases, sus partes y la forma en la que las

clases de los objetos están relacionados con otro.

Page 20: Diagrama de clases

ConclusionesEn este artículo se ha presentado una de las técnicas de

modelado más difundidas en los métodos de análisis y diseño orientado a objetos

En resumen, citar la facilidad de comprensión de estos diagramas en el modelado de sistemas software, así como su apoyo y presencia desde los modelos conceptuales iníciales a la implementación, como dos de sus principales características.

Page 21: Diagrama de clases

Gracias por su atención.