• Author / Uploaded
• Will Farfan Urquizo

Citation preview

Diagramas de clases DIAGRAMAS DE CLASES

Historia: El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software). El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.

Objetivos Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnología de componentes, el cómputo distribuido, etc. Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el meta-modelo a un coste bajo. Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras podrían desarrollarse encima del UML. Permitir el intercambio del modelos entre una gran variedad de herramientas. Proporcionar semánticas suficientes para especificar las interfaces a bibliotecas para la comparición y el almacenamiento de componentes del modelo. Durante el desarrollo del UML sus autores tuvieron en cuenta: Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad de aspectos del modelado contemporáneo de una forma directa y económica.

Diferentes tipos de Diagramas INGENIERÍA DE SOFTWARE

Página 1

Diagramas de clases

Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que un diagrama es una proyección del mismo. UML proporciona un amplio conjunto de diagramas que normalmente se usan en pequeños subconjuntos para poder representar las cinco vistas principales de la arquitectura de un sistema. Diagramas de Clases Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos diagramas son los más comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseño estática o la vista de procesos estática (sí incluyen clases activas). Diagramas de Objetos Muestran un conjunto de objetos y sus relaciones, son como fotos instantáneas de los diagramas de clases y cubren la vista de diseño estática o la vista de procesos estática desde la perspectiva de casos reales o prototípicos. Diagramas de Casos de Usos Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista estática de los casos de uso y son especialmente importantes para el modelado y organización del comportamiento. Diagramas de Secuencia y de Colaboración Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de colaboración muestran la organización estructural de los objetos que envían y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboración sin INGENIERÍA DE SOFTWARE

Página 2

Diagramas de clases perdida de información, lo mismo ocurren en sentido opuesto. Diagramas de Estados Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinámica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración. Diagramas de Actividades Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.

Tipos de diagramas: INGENIERÍA DE SOFTWARE

Página 3

Diagramas de clases

• Diagramas de estructura: mostrar la estructura estática del sistema que se está modelando Incluye: diagramas de clase, componentes y/o objetos. • Diagramas de comportamiento: muestra el comportamiento dinámico entre los objetos y el sistema. Incluye: diagramas de actividades, casos de uso y de secuencia Atributos • Son descripciones de características, se usan para modelar información asociada con una entidad, sintaxis: Nombre atributo [multiplicidad]:Tipo = Valor inicial • La multiplicidad es opcional e indica el número de atributos por instancia de la clase. Clases Las clases son descripciones de un juego de objetos con características, comportamiento, relaciones y semánticas comunes. Se usan para modelar un juego de conceptos o entidades. • Se denotan con un rectángulo con compartimentos. • En ellos se ponen el nombre, los atributos, las operaciones y además se pueden usar para anotar otras propiedades del modelo como son (reglas del negocio, responsabilidades, excepciones, etc.) • Pueden tener interfaces para especificar conjuntos de operaciones proporcionadas a su ambiente. Todas las operaciones deben estar asociadas a métodos. • Pueden tener relaciones de generalización con otras clases.

INGENIERÍA DE SOFTWARE

Página 4

Diagramas de clases

¿Cuáles son sus usos más comunes? Modelar la vista de diseño estática de un sistema: Para modelar el vocabulario de un sistema. Implica decidir que abstracciones son parte del sistema y cuales no y así especificar esas abstracciones y sus responsabilidades. Para modelar colaboraciones simples. Se emplean para visualizar un conjunto de datos y sus colaboraciones. Para modelar un esquema lógico de base de datos. Se necesitará almacenar información persistente en una base de datos relacional o en una base de datos orientada a objetos. Una colaboración es un conjunto de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de todos los elementos INGENIERÍA DE SOFTWARE

Página 5

Diagramas de clases ¿Cuáles son las técnicas comunes de modelado? Las clases colaboran unas con otras para llegar a una semántica mayor que la asociada a cada clase individual, por lo que a parte de capturar el vocabulario del sistema hay que prestar atención a la visualización, especificación, construcción y documentación de la forma en que estos elementos del vocabulario colaboran entre sí. Para modelar una colaboración: Hay que identificar los mecanismos que se quieren modelar. Hay que identificar las clases, interfaces y otras colaboraciones que participan en esta colaboración, y las relaciones entre estos elementos. Hay que usar escenarios para recorrer la interacción entre estos elementos. Se descubrirán partes del model que faltaban y otras que eran semánticamente incorrectas. Rellenar estos elementos con su contenido. Para las clases se realiza un reparto equilibrado de responsabilidades. Después, hay que convertir estas en atributos y operaciones concretos. ¿Cómo se modela un esquema lógico de base de datos? Cuando se modela con diagramas de clases se permite el modelado del comportamiento de los datos a almacenar. Para modelar un esquema: Hay que identificar aquellas clases del modelo cuyo estado debe trascender el tiempo de vida de las aplicaciones. Hay que crear un diagrama de clases que contenga estas clases. Hay que expandir los detalles estructurales de estas clases. Es especificar los detalles de sus atributos. Buscar patrones comunes que complican el diseño físico de bases de datos (asociaciones cíclicas y uno a uno). Se deben crear abstraccione intermedias para simplificar la estructura lógica. Hay que considerar el comportamiento de las clases persistentes expandiendo las operaciones que sean importantes para el acceso a los datos y la integridad de estos. Hay que usar herramientas que ayuden a transformar un diseño lógico en un diseño físico.

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, orientados a objetos. •

Propiedad de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo

INGENIERÍA DE SOFTWARE

Página 6

Diagramas de clases de quién diseñe el sistema se pueden unir los datos con las operaciones. •

El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica.

•

Presenta las clases del sistema con sus relaciones estructurales y de herencia.

Las clases representan los bloques de construcción más importantes de cualquier sistema orientado a objetos. Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. La representación gráfica de clases en UML se muestra en la siguiente figura.

Esta notación es independiente de cualquier lenguaje de programación. El primer bloque de la figura representa el nombre de la clase, el segundo bloque contiene los atributos, y el tercer bloque contiene las operaciones. El nombre de la clase puede ser simple (ej: Figura) o puede indicar el camino completo (paquete) donde reside la clase (ej: Grafico::Figura). En la definición de los atributos se pueden incluir sus tipos (ej: altura:Real). Lo mismo para las operaciones (ej: mover(a:int, b:int):boolean). No es necesario mostrar todas las características. A veces las clases tienen tantas características, que no es conveniente mostrarlas todas. En estos casos también se pueden organizar las características usando estereotipos. Por ejemplo:

INGENIERÍA DE SOFTWARE

Página 7

Diagramas de clases

Responsabilidades Una responsabilidad es un contrato o una obligación de una clase. Al modelar clases, un buen comienzo consiste en especificar las responsabilidades de los elementos. Una clase bien estructurada tiene al menos una responsabilidad (debería tener pocas). Gráficamente, las responsabilidades se expresan en una sección al final de la clase. Por ejemplo:

Uso de clases Modelar el vocabulario de un sistema: Para modelar el vocabulario de un sistema, hay que identificar aquellas cosas que utilizan los usuarios para describir el problema o la solución. Para esto se pueden utilizar tarjetas CRC y análisis basado en casos de uso. Una vez identificadas las INGENIERÍA DE SOFTWARE

Página 8

Diagramas de clases abstracciones, hay que identificar sus responsabilidades. El siguiente es un ejemplo del modelado del vocabulario de un sistema.

Modelar la distribución de responsabilidades: Para modelar la distrubución de responsabilidades en un sistema, hay que identificar un conjunto de clases que colaboren entre ellas para llevar a cabo algún comportamiento. Luego hay que identificar el conjunto de responsabilidades para cada clase. Por ejemplo:

INGENIERÍA DE SOFTWARE

Página 9

Diagramas de clases

Observe cómo estas clases colaboran de forma que ninguna clase hace mucho ni muy poco. Relaciones Las clases casi nunca se encuentran aisladas. Por lo general la mayoría de ellas colaboran con otras de varias maneras. Por tanto, al modelar un sistema también hay que modelar la forma en que las clases se relacionan. En el modelado orientado a objetos hay tres tipos de relaciones: dependencias, generalizaciones y asociaciones.

Una dependencia es una relación de uso, que declara que un cambio en la especificación de un elemento (por ejemplo la clase Evento) puede afectar a otro elemento que la utiliza (por ejemplo la clase Ventana), pero no necesariamente a la inversa (la flecha va dirigida hacia el elemento del cual se depende). Una dependencia quiere decir que un elemento utiliza a otro. Una generalización conecta una clase general (llamada superclase o padre) con otra clase más especializada (llamada subclase o hijo). Es una relación "es-un" o "es-una". Por ejemplo, el CuadroDialogo es una Ventana. Las asociaciones son relaciones estructurales entre instancias, que especifican que los objetos de un elemento están conectados con los objetos de otro. Es legal que los objetos de unas clases estén conectados con objetos de la misma clase. Hay cuatro tipos de "adornos" que se le INGENIERÍA DE SOFTWARE

Página 10

Diagramas de clases pueden poner a estas relaciones: nombre, rol, multiplicidad y agregación. Ejemplo:

Nombre: Una asociación puede tener un nombre, que se utiliza para describir la naturaleza de la relación. Para evitar ambigüedades, se puede indicar una dirección al nombre, es decir, la dirección en que se debe leer el nombre. Rol: Un rol es la cara que la clase de un extremo de la asociación presenta a la clase del otro extremo. Es el rol que juega la clase en la asociación. Multiplicidad: Representa el número de objetos que pueden conectarse a través de una relación de asociación. Se puede indicar una multiplicidad de exactamente uno (1), cero o uno (0..1), muchos (0..*), o uno o más (1..*). También se puede indicar un valor exacto (por ejemplo, 3). Agregación: A veces se desea modelar una relación de tipo "todo/parte", en la cual una clase representa algo grande (el todo), que consta de elementos más pequeños (las partes). Este tipo de relación se denomina agregación, y es una relación "tiene-un" o "tiene-una". Ejemplo:

Composición: La composición es un tipo especial de asociación, que también modela relaciones "todo/parte". La diferencia es que tiene una fuerte relación de pertenencia y vidas coincidentes de la parte con el todo. Las "partes" pueden crearse después del "todo", pero una vez creadas, viven y mueren con el "todo" (se pueden eliminar explícitamente antes). Quiere decir que una "parte", solamente puede estar relacionada con un "todo". Ejemplo: INGENIERÍA DE SOFTWARE

Página 11

Diagramas de clases

En el siguiente ejemplo se muestran algunas de la relaciones antes descritas. Observen el poder de expresión de esta notación.

Algunos conceptos Para diferenciar a las clases abstractas, el nombre de éstas se pone en cursiva. Las clases abstractas no pueden tener instancias directas. La visibilidad de una característica especifica si puede ser utilizada por otros objetos. Hay tres niveles de visibilidad en UML: public (cualquiera la puede usar, la característica es precedida por el símbolo +), protected (cualquier descendiente la puede utilizar, se especifica con el símbolo #), y private (solamente la propia clase la usa, se especifica con el símbolo -). El alcance de una característica define si la característica aparece en cada instancia de la clase, o si sólo hay una característica para todas las instancias. Para definir alcance de clase, las características se subrayan. INGENIERÍA DE SOFTWARE

Página 12

Diagramas de clases Por defecto, las características tienen alcance de instancia. Ejemplo:

Hay otras propiedades poco utilizadas. Por ejemplo, leaf, que indica que una clase es una hoja, y por tanto no permite que otras clases herenden características de ella. La propiedad root indica que una clase no puede tener padres. Por ejemplo:

La multiplicidad define el número de instancias que puede tener una clase. Esta es 0, 1 o n. Por defecto, las clases tienen multiplicidad n. Si se quiere INGENIERÍA DE SOFTWARE

Página 13

Diagramas de clases definir una multiplicidad diferente de n, hay que especificarla. Por ejemplo:

Esto quiere decir que la clase Controlador Red solamente puede tener una instancia. A su vez, para esta clase pueden haber dos o más puerto Consola.

EJEMPLOS DE DIAGRAMAS DE CLASES:

INGENIERÍA DE SOFTWARE

Página 14

Diagramas de clases

INGENIERÍA DE SOFTWARE

Página 15

Diagramas de clases

INGENIERÍA DE SOFTWARE

Página 16