Captulo 2

Clases
Contenido
Clases, atributos, operaciones y responsabilidades.
Modelado del vocabulario de un sistema.
Modelado de la distribucin de responsabilidades en un sistema.
Modelado de elementos que no son software.
Modelado de tipos primitivos.
Estructura de abstracciones de calidad.

Las clases son el bloque constructor ms importante de cualquier sistema
orientado a objetos; es una descripcin de un conjunto de objetos que
comparten los mismos atributos, operaciones, relaciones y semntica. Adems,
una clase implementa una o ms interfaces.

Las clases se usan para representar el vocabulario del sistema que se est
desarrollando, deben incluir abstracciones que forman parte del dominio del
problema; tambin se usan para representar elementos de software, de
hardware y hasta aquellos que son puramente conceptuales.

Las clases bien estructuradas son sencillas y forman parte de una distribucin
balanceada de responsabilidades dentro del sistema.

Introduccin

El modelado de un sistema involucra identificar los elementos que son
importantes desde tu punto de vista, los cuales integrarn el vocabulario del
sistema que ests modelando y cada uno de ellos ser distinto de los otros y
contar con un conjunto de propiedades.

En UML todos estos elementos son modelados como clases. Una clase es una
abstraccin de las cosas que forman parte del vocabulario. Una clase no es un
objeto individual, ms bien representa todo un conjunto de objetos.

En software, muchos lenguajes de programacin soportan directamente el
concepto de clase, lo cual es excelente, porque eso significa que las
abstracciones que creas pueden, en muchas ocasiones, ser mapeadas
directamente a uno de estos lenguajes, an si stas son de elementos que no
son software, por ejemplo un cliente, un negocio o una conversacin.

UML proporciona una representacin grfica de una clase, como se muestra en
la Figura 4-1. Esta notacin nos permite visualizar una abstraccin
independiente de cualquier lenguaje de programacin especfico y de una
manera que podemos enfatizar sus partes ms importantes: su nombre,
atributos y operaciones.


Figura
origen

mover()
cambiartamao()
desplegar()

Figura 4-1: Clases


Trminos y Conceptos

Una clase es una descripcin de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semntica. Grficamente, una
clase se representa como un rectngulo.

Nombres

Cada clase debe tener un nombre que la distinga de las otras clases. Un
nombre es una cadena textual, que cuando se encuentra solo, se le llama
nombre simple y cuando va precedido del nombre de un paquete en el cual
est contenida dicha clase se le llama nombre de ruta. Puede ser dibujado
mostrando solo el nombre, como se muestra en la Figura 4-2.


Cliente

Sensor de
Temperatura

Pared


Figura 4-2: Nombres Simples y de Ruta.

Nota: Un nombre de clase puede tener cualquier nmero de letras, nmeros y
ciertos smbolos de puntuacin (excepto el smbolo de dos puntos, :, ya que este
se usa para separar un nombre de clase de su nombre de paquete) y puede
abarcar varias lneas. En la prctica, los nombres de clase son cortos y
relacionados con el vocabulario del sistema que estamos modelando.
Generalmente la primera letra de cada palabra del nombre se pone en
mayscula como por ejemplo, Cliente o SensorTemperatura.

Reglas de Negocio::AgenteFraude
java::awt::Rectangle
Atributos

Un atributo es una propiedad asignada a una clase, describe un rango de
valores que pueden tener las instancias de esta propiedad. Una clase puede
tener cualquier nmero de atributos o ninguno. Un atributo representa alguna
propiedad del elemento que estamos modelando y es compartida por todos los
objetos de la clase, por lo tanto, es una abstraccin del tipo de datos o estado
que un objeto de la clase puede abarcar. En un momento dado, un objeto de
una clase tendr valores especficos para cada uno de los atributos de su
clase. Grficamente, los atributos son listados dentro en una subdivisin del
rectngulo, justo abajo del nombre de la clase, pueden ser representados
mostrando solamente sus nombres, como se muestra en la Figura 4-3.

Cliente
nombre
direccin
telfono
fechaNacimiento


Figura 4-3: Atributos

Nota: Al igual que la clase, un nombre de atributo es corto y
representa alguna propiedad de la clase que lo contiene.
Generalmente, la primera letra de cada palabra se pone en
mayscula excepto la primera letra, como por ejemplo, nombre o
fechaNacimiento.

Podemos especificar todava ms un atributo, estableciendo su tipo y
posiblemente un valor inicial por omisin como se muestra en la Figura 4-4.

Pared
altura:Float
ancho:Float
grosor:Float
tieneSoporte:Boolean=false


Figura 4-4: Atributos y sus Tipos

Operaciones

Una operacin es la implementacin de un servicio que puede ser solicitado
por cualquier objeto de la clase para comportarse de cierta manera y es
compartida por todos los objetos de esa clase, la cual puede tener cualquier
nmero de operaciones o ninguna. En muchas ocasiones, invocar una
operacin sobre un objeto, cambia los datos o estado del objeto. Grficamente,
las operaciones son listadas dentro de otra subdivisin del rectngulo justo
debajo de los atributos de la clase y pueden mostrar solamente sus nombres,
como se ve en la Figura 4-5.

Rectngulo

agregar()
crecer()
mover()

Figura 4-5: Operaciones

Nota: Un nombre de operacin es un verbo corto que representa algn
comportamiento de la clase. Generalmente, la primera letra de cada
palabra se pone con mayscula excepto la primera letra, como por
ejemplo, mover o estVaco.

Puedes especificar una operacin estableciendo su signatura, que incluye el
nombre, tipo y valor por omisin de todos los parmetros y (en el caso de
funciones) un tipo return, como se muestra en la Figura 4-6.

SensorTemperatura

reset( )
colocarAlarma(t:Temperatura)
valor( ):Temperatura

Figura 4-6: Operaciones y sus Signaturas

Organizacin de Atributos y Operaciones

Cuando dibujamos una clase, no tenemos que mostrar necesariamente todos
los atributos y operaciones; de hecho, en muchos casos, no podemos y
probablemente no debemos hacerlo porque puede haber bastantes en una
figura o porque solamente un subconjunto de estos atributos y operaciones van
a ser relevantes en una vista especfica. Por estas razones, podemos
simplificar una clase, lo que significa que podemos elegir solamente algunos o
ninguno de los atributos y operaciones de ella para mostrarlos. Una subdivisin
del rectngulo vaca, no necesariamente significa que no hay atributos u
operaciones, sino que no los seleccionamos para mostrarlos. Podemos
especificar de una manera explcita que hay ms atributos o propiedades pero
que no las mostramos, poniendo al final del rectngulo estos caracteres, ("...").

Para organizar mejor las largas listas de atributos y operaciones, podemos
separarlas en categoras descriptivas y agregando a cada grupo un estereotipo,
como se muestra en la Figura 4-7.

AgenFraud

<<constructor>>
nuevo()
nuevo(p:Polica)
<<proceso>>
proceso(o:Orden)
...
<<consulta>>
esSospechoso(o:Orden)
esFraudulento(o:Orden)
<<auxiliar>>
validarOrden(o:Orden)

Figura 4-7: Estereotipos para Elementos de una Clase

Responsabilidades

Una responsabilidad es un convenio o una obligacin de una clase. Cuando
creamos una clase, estamos especificando que todos los objetos de ella tienen
el mismo tipo de estado y de comportamiento. A un nivel ms abstracto, los
atributos y operaciones correspondientes son solo los medios por los cuales las
responsabilidades de la clase son llevados a cabo.

Cuando modelamos las clases, un buen punto de inicio es especificar las
responsabilidades de los elementos en nuestro vocabulario. Las tcnicas como
las tarjetas CRC y el anlisis basado en casos de uso son especialmente tiles
aqu. Una clase puede tener cualquier nmero de responsabilidades, aunque,
en la prctica, todas las clases bien estructuradas tienen al menos una
responsabilidad. Conforme refinamos nuestros modelos, traducimos estas
responsabilidades en un conjunto de atributos y operaciones, de manera que
sean cumplidas de la mejor manera.

Grficamente, las responsabilidades pueden ser representadas en la parte baja
del cono de clase, como se muestra en la Figura 4-8.

AgenFraud


Responsabilidades
--determinar el riesgo
de la orden de un
cliente
--manejar criterios
especficos del cliente
por fraude

Figura 4-8: Responsabilidades

Nota: Una responsabilidad se escribe como una frase, un
enunciado o un prrafo pequeo.

Otros Elementos

Los atributos, operaciones y responsabilidades son los elementos ms
comunes y bsicos que se necesitarn cuando se creen abstracciones ya que
en stos se encuentra la semntica de las clases. Algunas veces, sin embargo,
se necesitar visualizar o especificar otros elementos, tales como la visibilidad
de los atributos individuales y las operaciones; las caractersticas especficas
de un lenguaje para una operacin, tal como si es polimrfico o constante; o
hasta las excepciones que los objetos de la clase podran producir o manipular.
Estas y muchos otros elementos pueden ser expresados en UML, pero stos
ya son conceptos avanzados.

Cuando construimos modelos, descubrimos que casi todas las abstracciones
que creamos son de algn tipo de clase. Algunas veces, intentaremos separar
la implementacin de una clase, de su especificacin, y esto puede ser
expresado en UML utilizando interfaces.

Cuando empezamos a construir modelos ms complejos, a menudo nos
encontraremos una y otra vez, con clases que son del mismo tipo, como por
ejemplo, las clases que representan procesos concurrentes e hilos de control, o
clases que representan elementos fsicos, tales como applets, Java Beans,
objetos COM+, archivos, pginas Web y hardware. Esto es porque este tipo de
clases son muy comunes y representan abstracciones de arquitectura, UML
proporciona clases activas (que representan procesos e hilos de control),
componentes (que representan componentes de software fsico) y nodos (que
representan dispositivos de hardware).

Cuando construimos modelos, generalmente hacemos grupos de clases que
interactan entre s, en UML estas grupos forman colaboraciones y son
visualizadas en diagramas de clases en muchas ocasiones.


Tcnicas Comunes de Modelado

Modelado del Vocabulario de un Sistema

Usaremos clases ms comnmente para modelar abstracciones que surgen del
problema que se est tratando de resolver o de la tecnologa que estemos
usando para implementar una solucin a dicho problema. Cada una de estas
abstracciones es parte del vocabulario de nuestro sistema, lo que significa, por
lo tanto, que representan los elementos que son importantes para los usuarios
y los implementadores.

Para los usuarios muchas abstracciones no son tan difciles de identificar
porque, generalmente, son elementos que ellos mismos ya usaron para
describir su sistema; las tcnicas como las tarjetas CRC y el anlisis basado en
casos de uso son excelentes para ayudar a los usuarios en este proceso. Para
los implementadores, estas abstracciones son generalmente solo los
elementos de la tecnologa que dar la solucin.

Para modelar el vocabulario de un sistema:

Identifique aquellos elementos que los usuarios o implementadores usan
para describir el problema o solucin. Utilice tarjetas CRC y anlisis
basado en casos de uso para ayudar a identificar las abstracciones.
Para cada abstraccin, identifique un conjunto de responsabilidades.
Est seguro de que cada clase est definida de forma sencilla y que
haya un buen balance de responsabilidades entre ellas.
Proporcione los atributos y operaciones que sean necesarios para llevar
a cabo las responsabilidades de cada clase.

La Figura 4-9 muestra un conjunto de clases modeladas de un sistema de
ventas, esta figura incluye abstracciones que fueron dibujadas a partir del
vocabulario del problema, tales como Envo, Factura y Almacn.


Figura 4-9: Modelado del Vocabulario de un Sistema

Como nuestro modelo se vuelve ms grande, muchas de estas clases se van a
unir en grupos que estn relacionados conceptualmente y semnticamente. En
UML, podemos usar paquetes para modelar estos grupos de clases.

Muchos de nuestros modelos rara vez sern completamente estticos. Ms
bien, muchas abstracciones en el vocabulario del sistema interactuarn entre
ellas de manera dinmica. En UML, hay muchas maneras de modelar este
comportamiento dinmico.

Modelado de la Distribucin de Responsabilidades en un Sistema

Una vez que empezamos a modelar nuestras clases, vamos a querer estar
seguros de que nuestras abstracciones proporcionen un conjunto balanceado
de responsabilidades. Lo que significa que deseamos que no haya clases ni
muy grandes ni muy pequeas. Si abstraemos clases que son demasiado
grandes nuestros modelos sern difciles de cambiar y no sern muy reusables.
Por el contrario, si abstraemos otras que son muy pequeas, terminaremos con
muchas ms de las que pudieran razonablemente manejarse o entenderse.
Con UML podemos visualizar y especificar este balance de responsabilidades.

Para modelar la distribucin de responsabilidades en un sistema:

Identifique un conjunto de clases que trabajen juntas para llevar a cabo
algn comportamiento.
Identifique un conjunto de responsabilidades para cada una de estas
clases.
Observe que este conjunto de clases como un todo, separe clases que
tienen muchas responsabilidades en abstracciones ms pequeas, junte
las clases pequeas que tienen responsabilidades triviales en una ms
grande y reasigne responsabilidades.
Considere las formas en las que las clases colaboran con otras y
redistribuya sus responsabilidades de manera que ninguna clase quede
sobrando o sea la nica en una colaboracin.

Por ejemplo, en la Figura 4-10 muestra un conjunto de clases dibujadas de
Smalltalk, muestra la distribucin de responsabilidades entre las clases
Modelo, Vista y Controlador. Nota cmo todas ellas trabajan en conjunto
de manera que ninguna hace ni mucho ni poco.

Figura 4-10: Modelado de la Distribucin de las Responsabilidades en un
Sistema


Modelado de Elementos que no son Software

Algunas veces, los elementos que modelamos pueden nunca tener una
analoga en software, por ejemplo, la gente que enva facturas y los robots que
automticamente empacan rdenes para su envo desde el almacn, podra
ser un flujo de trabajo que modelamos en un sistema de ventas. La aplicacin
podra no tener ningn software que los represente.

Para modelar elementos que no son software:

Modele el elemento que est abstrayendo como una clase.
Si quiere distinguir estos elementos desde los bloques de construccin
de UML, cree un nuevo constructor utilizando estereotipos para
especificar esta nueva semntica y para dar un caracterstica visual
distintiva.
Si el elemento que est modelando es de algn tipo de hardware,
considere el modelado como un tipo de nodo, de tal manera que pueda
expandir ms su estructura.

Nota: UML est diseado para modelar sistemas de software
extensos, aunque, en conjunto con lenguajes de modelado de
hardware, como VHDL, puede ser completamente capaz de
modelar sistemas de hardware.

Como muestra la Figura 4-11, es perfectamente normal abstraer humanos
como clases, porque cada uno representa un conjunto de objetos con una
estructura y comportamiento comunes.

Robot

procesoOrden()
cambiarOrden()
estado()

Figura 4-11: Modelado de Elementos que no son Software.

Modelado de Tipos Primitivos

En el otro extremo, los elementos que modelamos pueden ser representados
directamente en el lenguaje de programacin que estemos utilizando para
implementar una solucin. Generalmente, estas abstracciones involucran tipos
primitivos, tales como enteros, caracteres, cadenas y hasta tipos de
enumeracin, que podramos crear nosotros mismos.

Para modelar tipos primitivos:
Modele el elemento que est abstrayendo como un tipo o una
enumeracin, se ponen usando notacin de clase con el estereotipo
apropiado.
Si necesita especificar el rango de valores asociado con este tipo, use
restricciones.
Como muestra la Figura 4-12, estos elementos pueden ser modelados en UML
como tipos o enumeraciones, los cuales se ponen como clases pero estn
explcitamente sealados con estereotipos. Los elementos como los enteros
son modelados como tipos y podemos indicar de forma explcita el rango de
valores que estos elementos pueden tomar usando restricciones. De forma
similar, los tipos de enumeracin como Booleano y Estado, pueden ser
modelados como enumeraciones, con sus valores individuales proporcionados
como atributos.

Figura 4-12: Modelado de Tipos Primitivos

Nota: Algunos lenguajes como C y C++, nos permiten poner un valor
entero equivalente a una enumeracin. Podemos modelar esto en
UML sealando los atributos que denotan una enumeracin con un
valor inicial constante por omisin.

Sugerencias y Tips

Cuando modeles clases en UML, recuerda que cada clase debe mapear una
abstraccin tangible y conceptual en el dominio del usuario final o del
implementador. Una clase bien estructurada:
Proporciona una abstraccin sencilla de un elemento del vocabulario del
dominio del problema o del dominio de la solucin.
Incluye un conjunto de responsabilidades pequeo, bien definido y las
lleva a cabo muy bien.
Proporciona un separacin clara entre la especificacin de la abstraccin
y su implementacin.
Es entendible, simple, extensible y adaptable.