Sunteți pe pagina 1din 11

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. Reglas de Negocio::AgenteFraude java::awt::Rectangle

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.

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.

S-ar putea să vă placă și