Diagrama de Clases

Un diagrama de clases es un modelo del dominio problema que captura todos los
requerimientos del usuario respecto al sistema. La informacin de los requerimientos esta
contenida en los atributos y operaciones de las clases, y las asociaciones entre ellas.

Un diagrama de clases contiene detalles bsicos. Las clases representan tems de negocios
fsicos o conceptuales. Los atributos representan la informacin que se conoce de estos tems.
Las operaciones definen que se pueden hacer con stos tems. Las asociaciones describen
como interactan las clases entre s para llevar a cabo los requerimientos del sistema.

Las asociaciones capturan las reglas del negocio. Se aaden al Diagrama de Clases cuando se
revisa y refina.

Los mtodos tradicionales separan la funcionalidad de los datos que se requieren para la
ejecucin del sistema. Los diagramas de clases en cambio muestran ambos aspectos a la vez,
permitiendo un natural entendimiento de cmo se comportan los objetos del mundo real.

Cuando incluimos una clase en un diagrama de clases, el lector del mismo, debe pensar en los
objetos de esa clase para entenderlo mejor.

Una clase se representa por un rectngulo con tres secciones. El nombre del objeto se coloca
en la parte superior, los atributos en la parte media y las operaciones en la parte inferior.

Para comprimir el detalle de un diagrama de clases, se pueden suprimir las secciones de

atributos y operaciones. No debemos incluir excesivo detalle en un diagrama, ya que los
diagramas complejos son difciles de leer.

Definiendo Atributos
Un atributo indica que un objeto es responsable de retener una cierta pieza de informacin. Por
ejemplo una clase Automvil puede incluir NumeroAsientos y CapacidadMotor.

En el diagrama de clases opcionalmente podemos mostrar el tipo de dato de cada atributo. Por
ejemplo, el atributo NombreCompaia puede ser del tipo Text, entonces se escribira
NombreCompaia:Text

Podemos dejar sin definir el tipo de dato y el valor por defecto en el Diccionario de Datos
durante el anlisis. Sin embargo para la implementacin debemos especificarlos. Un valor por
defecto se asigna solamente donde sea aplicable segn las reglas del negocio. Esto sugiere
que un valor es suministrado en la creacin de los objetos llamando a una operacin del
mismo.
Definimos los tipos de datos utilizados en los atributos consistentemente en un proyecto u
organizacin. Estos pueden ser derivados de un lenguaje de programacin, base de datos o
una librera de tipos.

Definicin de Operaciones
Una operacin muestra que una clase es responsable de ejecutar una pieza de funcionalidad
del sistema. Los parmetros muestran la informacin que pasa el invocador de la operacin. El
tipo de retorno muestra la informacin entregada al invocador de la operacin.

Cada parmetro puede ser informacin pura o puede hacer referencia a un objeto. Un valor por
defecto implica que si el invocador no brinda un valor, el receptor utiliza el valor por defecto.

El tipo de retorno est usualmente restringido a un solo valor. Si se requiere ms de un valor,

se crea un tipo de objeto nuevo y se retorna un objeto de ese tipo. Esta clase, contendr como
atributos, los valores de retorno.
La definicin de parmetros, valores por defecto y tipos de retorno son opcionales en el
diagrama de clases al igual que los atributos. La ausencia de parntesis indica que los
parmetros son desconocidos en el momento del anlisis.
Una operacin se define por nombre. Esto se conoce como firma. Las operaciones pueden
tener una lista de parmetros y un tipo de retorno. Los parmetros son definidos por un
nombre, tipo de dato y valor por defecto. Los tipos de dato y valores por defecto son
dependientes del lenguaje de implementacin.

Objetos en Diagramas de Clases

Los objetos son una instancia de una clase y no suelen mostrarse en los Diagramas de Clases.
Los objetos se dibujan en los Diagramas de Secuencia y Colaboracin. En UML la forma de
diferenciar una clase y un objeto es el nombre subrayado. Los objetos se subrayan y las clases
no.

Cuando los objetos se muestran en un Diagrama de Clases, representan objetos especficos o

annimos. Los especficos reciben un nombre y los annimos se quedan con el nombre de la
clase.

Cuando un objeto se muestra aqu, usualmente es dibujado con los valores de los atributos.

Diagrama de Objetos. Estos diagramas son tiles para explicar un Diagrama de Clases o si
tenemos problemas en la clasificacin. Son beneficiosos cuando examinamos la multiplicidad y
para mostrar ejemplos de antes y despus.

Identificacin de Clases
Inicialmente identificamos clases para formar una coleccin a partir de la cual empiezan las
investigaciones. Esta recoleccin es un prototipo de trabajo. Conforme el proyecto avanza
podemos adicionar detalles o retirar clases.
La terminologa de los lenguajes de programacin no se utiliza en la fase de Anlisis. Sin
embargo debemos prestar atencin al vocabulario del negocio. Utilicemos los trminos tcnicos
apropiados al negocio para ayudar a la comunicacin.

Los Casos de Uso son un buen punto para iniciar el anlisis de un negocio. Estos capturan
todos los modos y usos del sistema y por ello proveen un punto de inicio natural.
Identifiquemos todos los nombres y frases; debemos seleccionar los mejores nombres entre
varios sinnimos, pero mantenerlos dentro de los lmites del vocabulario.

El proceso de identificacin de clases es una tarea de equipo. Esto permite un rpido

intercambio y refinamiento de ideas. Asegrense de no desviarse del tema o aadir demasiado
detalle en esta etapa. Es muy tentador empezar a identificar todos los atributos de una clase
tan pronto encontramos una.
Los Sustantivos deben registrarse en una lista. Usualmente se analizan un pequeo nmero de
Use Cases, que contienen talvez hasta 50 tems en una lista. Debemos mantener esta lista
para futuras referencias, posiblemente para aadir ms tems o retirar algunos.
En el sistema del supermercado, la transcripcin del Use Case resalta lo que sucede cuando
un cliente se acerca a caja. Subrayando todos los sustantivos, podemos obtener una lista inicial
de candidatos a clases en el sistema.

Algunos candidatos son duplicados o sinnimos. La siguiente etapa es revisar la lista y eliminar
cualquiera que no sea necesario.

Una vez hecha la lista maestra de los sustantivos se ha terminado, escribimos los mismos en
pedazos de papel o en una pizarra y se discuten abiertamente sobre su importancia y rol en el
sistema. As son fciles de mover, eliminar o aadir. Esto ayuda a decidir rpidamente sobre
estos candidatos a clases.

Organizacin del Diagrama de Clases

Una vez que la lista de candidatos se ha escrito en papel, organcenla de forma tal que
aquellos relacionados se encuentren juntos. No hay una respuesta formal correcta, pero
algunos alineamientos se vern mejor que otros.

Apunten a formar pequeas agrupaciones de tems relacionados, para estudiarlos en ms

detalles. Los de nombres idnticos se descartan. Se debe revisar aquellos tems similares para
determinar si se refieren al mismo concepto, y as juntarlos.

En el ejemplo, total, recibo y pago pueden ser colocados al final al estar relacionados con el
final del proceso. La transacciones se muestran en el recibo y se muestra la lista de bienes.
Una transaccin es por un precio, y un producto tiene un precio. Entonces, el precio puede ser
degradado a ser Atributo en lugar de Clase.

Sistema, caja, operador de caja y cliente, son todos tems fsicos. El cliente tiene una tarjeta
preferida. Una canasta contiene los bienes llevados a caja.

Es factible que algunos candidatos representen lo mismo. De ser as, podramos utilizar
diferentes palabras para describirlos. Donde indentifiquemos sinnimos eliminemos todos
excepto los sustantivos descriptivos para estar seguros de no usar el mismo concepto en ms
de una clase.

Convirtiendo los sustantivos irrelevantes en atributos clarifica a los sustantivos restantes. Esto
asegura que los sustantivos restantes no sean ignorados pero se mantengan en el modelo
dentro de otra clase. Una vez que se investigue con mayor profundidad en fases posteriores
estos atributos podran volver a ser clases.

No debemos desgastarnos en el proceso de decisin de que una clase sea un atributo y

viceversa. En esta fase no hay respuestas definitivas. Ms adelante podemos darnos cuenta
que si una clase no posee ningn comportamiento puede volverse un atributo.

No necesitamos restringirnos a los sustantivos encontrados en los Use Cases. Una lluvia de
ideas es til para capturar el conocimiento requerido. Hacemos entonces una lista con nuevos
candidatos a clase.

Capture cada clase sin juzgar, permitiendo cualquier cosa que venga a la mente, incluso ideas
inusuales. Debemos estar seguros de que todas estas palabras se encuentren dentro del
vocabulario del usuario. Examine la lista los mismos criterios que con los Use Cases, dentro del
alcance del sistema.

Una vez que hemos eliminado las clases duplicados, sinnimos, y clases superfluas, nos
quedamos con una lista revisada. Este es un solo ejemplo de muchas posibilidades.

Se remueven todas las clases redundantes. Es comn que se aadan nuevas clases mientras
nos adentramos ms en el funcionamiento interno del sistema. Las clases se refinan y adornan
ms an durante el diseo, donde se definen correctamente los atributos, operaciones y
relaciones.

Cmo encontrar Clases adems de los Use Cases

Dnde buscar?

Observar de primera mano: si se trata de un sistema de trafico aereo, observe como se

usa un simulador de vuelo, aprender terminologa y los pasos del proceso al que se
enfrenta, y las necesidades de tiempo real.
Escuchar activamente a los expertos del dominio problema: contactarse de ser posible
con expertos en la materia en cuestin, que no necesariamente pertenezcan a la
organizacin para la cual desarrollamos el modelo.
Revisar resultados de anlisis previos de sistemas similares o iguales, an cuando
estos no pertenezcan a la misma organizacin.
Leer, leer, leer: investigar sobre el tema a consideracin, de diversas fuentes, como
libros o la Internet. Esto ayuda a comprender ms sobre aquello en lo que estamos
involucrados.
Prototipo: si se trata de un sistema de Tiempo Real, basado fundamentalmente en la
interaccin humano-computador, nunca hay que dejar de lado la opcin del prototipo.

Qu buscar?

Estructuras: identificar estructuras buscando posibilidades de organizacin de las

clases encontradas (agregacin y herencia).
Otros sistemas: sistemas que interactan con el que esta en desarrollo.
Dispositivos: qu dispositivos requiere el sistema para interactuar? De acuerdo a las
necesidades del sistema se deben incluir aparatos de ser necesario, por ejemplo, un
cajero automtico, un PLC, etc.
Cosas o eventos a ser recordados: necesidades de registro de eventos especiales, o
histricos a preservarse, documentos, fechas, incidentes, etc.
Roles: los roles que cumplen las personas y que sean relevantes de descripcin en el
sistema.
Procedimientos operacionales: aquellos procesos que necesitan ser registrados a
pesar de no estar explcitamente solicitados en los requisitos. Por ejemplo,
procedimientos y el flujo de pasos para llevarlo a cabo; con atributos como nombre de
procedimiento, nivel de autorizacin requerido, descripcin de pasos del procedimiento.
Lugares: locaciones fsicas, oficinas, ciudades, etc. De los cuales se requiera conocer
algo.
Unidades organizacionales: las unidades organizacionales a las que pertenecen las
personas o roles, as como las oficinas o departamentos, si el sistema requiere
informacin respecto de esta informacin.

Qu considerar y qu confrontar?
Una vez que hemos encontrado clases potenciales de todo tipo, bajo las modalidades
aprendidas, debemos confrontar cada una y decidir si es necesario mantenerlas en el modelo o
no. Con tal motivo, nos haremos las siguientes preguntas clase por clase para tomar
decisiones, y producto de estas preguntas, procederemos a mantenerlas, promover atributos a
clases o degradar clases a atributos, segn sea conveniente.

Necesidad de registro: estamos seguros que se requiere la informacin de esta clase

para los objetivos del sistema? Son todos sus atributos relevantes para el modelo?
Necesidad de comportamiento: requiere esta clase proveer algn tipo de
comportamiento al sistema?
Mltiples atributos: sospechar de cualquier clase que posea un solo atributo, o un
conjunto de atributos que pueda ser tratado como objeto, ya que podran ser tratados
como atributos en lugar de clases. La clave es el nivel de detalle (abstraccin) que
requiere el sistema.
Ms de un objeto en la clase: las clases que en el sistema en ejecucin vayan a tener
un solo objeto son potencialmente descartables, como este auto o este avin, sin
embargo si el modelo lo requiere puede existir una clase de este tipo, en el caso del
control de trfico areo, podra requerirse informacin de un radar y este puede ser el
nico existente, sin embargo debe existir en el modelo.
Atributos siempre aplicables: si los objetos que se generarn a partir de una clase, no
siempre contienen valores en todos sus atributos, considerar desplegar la clase en una
estructura de herencia.
Servicios siempre aplicables: similarmente, si no todos los objetos de la clase se
comportarn de la misma forma o requerirn todos los servicios descritos, considerar
una estructura de herencia.
Requerimientos del dominio: a pesar de que ciertas consideraciones observadas en el
proceso de abstraccin deben ser dejadas a la etapa del diseo, es buena prctica
mantener un archivo con dichas ideas y conceptos descubiertos, para ser tomados en
cuenta en el diseo an cuando finalmente nunca sean usados, sin embargo, hay
ocasiones en que por requisitos explcitos del sistema debemos colocar restricciones
en el sistema desde el anlisis y que corresponden al diseo, como por ejemplo un
algoritmo en especial, por definicin legal, etc.
Resultados no meramente derivados: finalmente evitemos resultados meramente
derivados, como campos calculados (totales de facturas, edad de las personas, tiempo

transcurrido entre eventos, etc.) ya que bastar con mantener la informacin base de
dichos clculos para que alguna operacin de las clases correspondientes brinden el
resultado requerido por el sistema. Recordemos que esto puede cambiar en la etapa
de diseo por cuestiones de performance, mas no es el momento adecuado hacerlo en
la fase de anlisis.

Alcance del Sistema

El alcance del sistema aclara nuestro entendimiento de los lmites del sistema, lo que est
dentro y lo que est fuera de l.

Los actores son usualmente removidos del diagrama de clases. Los sistemas no suelen
reconocer qu persona est utilizando el sistema excepto en aspectos relacionados con
accesibilidad (seguridad del sistema).
En el ejemplo del supermercado, el alcance del sistema no incluye la identidad del cliente.
Cuando un cliente utiliza una tarjeta, el sistema no necesita saber que miembro de la familia
usa la tarjeta. La tarjeta es el objeto en el sistema, y no el cliente.

Al eliminar actores, debemos limitarnos a cuestionarnos sobre el Use Case actual y tratando de
no afectar otros Use Cases.
Cualquier trmino que indique al sistema completo debe ser eliminado, ya que estamos
interesados en el sistema interno y no en el sistema global. En el ejemplo, debemos entonces
eliminar cualquier frase como sistema, supermercado, o sistema de supermercado.
El sistema bajo investigacin puede ser ms amplio de lo que se estudia al principio. Por
ejemplo, puede ser parte de una cadena. El sistema de supermercado es entonces solo un
sub-sistema del espacio completo del sistema, entonces podra convertirse en una clase
razonable.

Diccionario de Datos
El diccionario de datos es el repositorio de toda la informacin. Contiene descripciones de
clases, atributos, operaciones, relaciones y multiplicidad.
El diccionario de datos tambin contiene otros modelos como Diagramas de Secuencia y
Diagramas de Estado. El diccionario puede ser mantenido en cualquier formato, desde archivos
de texto simple hasta en formato de metamodelo de UML de alguna herramienta CASE.

Palabras y frases solo vistas en un diagrama. El diccionario de datos describe las clases en
texto fcilmente legible.

Para minimizar la posibilidad de malinterpretacin, se produce una descripcin detallada y se

almacena en el Diccionario de Datos. Toda la informacin se guarda aqu.