DIAGRAMAS DE CLASE

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de consentimiento.
Un diagrama de clases está compuesto por los siguientes elementos:
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

ELEMENTOS QUE LO COMPONEN

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 se encuentra

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

Ejemplo

Una Cuenta Corriente que posee como característica: Balance

Puede realizar las operaciones de:
°Depositar
°Girar
°Balance
 SIMBOLOGÍA

CLASES PÚBLICAS, PRIVADAS Y PROTEGIDAS

Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el
grado de comunicación y visibilidad de ellos con el entorno, estos son:

Public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es
decir, es accsesible desde todos lados.

Private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo
sus métodos lo pueden accesar).

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).
Métodos:
Los métodos u operaciones de una clase son la forma en como ésta interactúa con su
entorno, éstos pueden tener las características:

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 accesar).

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

Relaciones entre Clases

Ahora ya definido el concepto de Clase, es necesario explicar cómo se pueden

interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada
extremo de la relación y éstas pueden ser:
-Uno o muchos: 1..* (1..n)
-0 o muchos: 0..* (0..n)
-Número fijo: m (m denota el número).
Herencia (Especialización/Generalización)

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase,
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), ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las
Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es
Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio,
VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo único "visible" es el método Caracteristicas
aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en
cambio atributos como Descapotable no son visibles por ser privados.
En donde se destaca que:
-Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).
-Cuando se destruye el Objeto Almacen 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.
La flecha en este tipo de relación indica la navegabilidad del objeto refereniado. Cuando
no existe este tipo de particularidad la flecha se elimina.
 ¿Qué es un diagrama de objetos en UML?
Un diagrama de objetos UML representa una instancia específica de un diagrama de clases
en un determinado momento en el tiempo. Cuando se lo representa gráficamente, verás
muchas similitudes con el diagrama de clases. Usamos el mismo ejemplo de clase de
coche de la página de diagramas de clases para ilustrar los diagramas de objetos. Nuestra
biblioteca de figuras UML puede ayudarte a diseñar cualquier diagrama de objetos
personalizado por medio de nuestra herramienta UML en línea.

Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y cómo esos

objetos se relacionan entre sí. Por ejemplo, en el siguiente diagrama de objetos, las tres
cuentas bancarias están ligadas al banco mismo. Los títulos de clase muestran el tipo de
cuentas (ahorros, corriente y tarjeta de crédito) que un cliente dado podría tener con este
banco en particular. Los atributos de clase son diferentes para cada tipo de cuenta. Esto se
ilustra por el hecho de que el objeto de tarjeta de crédito tiene un límite de crédito,
mientras que las cuentas de ahorros y corriente tienen tasas de interés. El diagrama de
objetos no está limitado a casos de uso bancario. Puedes crear un diagrama de objetos
para árboles genealógicos, departamentos corporativos, es decir, cualquier sistema con
partes interrelacionadas.

Diagrama de objetos vs. Diagrama de clases

Ejemplo de diagrama de objetos

Ejemplo de diagrama de clases

 DIAGRAMA DE CASOS DE USO
En un diagrama de casos de uso no se muestran los casos de uso en detalle; solamente se
resumen algunas de las relaciones entre los casos de uso, los actores y los sistemas. En
concreto, en el diagrama no se muestra el orden en que se llevan a cabo los pasos para
lograr los objetivos de cada caso de uso. Esos detalles pueden describirse en otros
diagramas y documentos, que pueden vincularse a cada caso de uso. Para obtener más
información, vea en este tema la sección Describir los casos de uso en detalle.

En las descripciones que se proporcionen de los casos de uso se usarán diversos términos
relacionados con el dominio en el que trabaja el sistema, como Ventas, Menú, Cliente, etc.
Es importante definir de manera clara estos términos y sus relaciones y, para ello, puede
resultar útil un diagrama de clases de UML. Para obtener más información, vea Diagramas
de clases de UML: Instrucciones.

Los casos de uso solamente se usan para los requisitos funcionales de un sistema. Otros
requisitos, como las reglas de negocio, los requisitos de calidad del servicio y las
restricciones de implementación, deben representarse por separado. La arquitectura y los
detalles internos también deben describirse por separado. Para obtener más información
sobre cómo definir los requisitos de usuario, vea Requisitos del usuario de modelos.
Los ejemplos que se usan en este tema están relacionados con un sitio web en el que los
clientes pueden hacer pedidos de comida de restaurantes locales.

EJEMPLO:

 Un actor (1) es una clase de

persona, organización, dispositivo o
componente de software externo que
interactúa con el sistema. Los actores
del ejemplo son cliente, restaurante,
sensor de temperatura y titular de
tarjeta de crédito.
 Un caso de uso (2) representa las
acciones que uno o varios de los
actores realizan a fin de conseguir un
objetivo determinado. Los casos de
uso del ejemplo son “Pedir menú”,
“Actualizar menú” y “Procesar pago”.
En un diagrama de casos de uso,
casos de uso están asociados (3) a los actores que los realizan.
 El sistema (4) es aquello que se está desarrollando. Puede ser un pequeño componente de
software cuyos actores simplemente son otros componentes de software; puede ser una
aplicación completa; o puede ser un gran conjunto de aplicaciones distribuidas que se
implementan en muchos equipos y dispositivos. Los subsistemas del ejemplo son “Sitio
web de pedidos de menú”, “Empresa de entrega de menús” y “Versión 2 del sitio web”.