IES MAR DE CÁDIZ

1º del Ciclo Superior de Desarrollo de Aplicaciones Web

Entornos de Desarrollo.

1
TEMA 4: DIAGRAMAS DE CLASES. DIAGRAMAS DE
ESTADO

1. Diagramas de Clases

Pasos a seguir para la realización de los diagramas de clases:

1.1 Identificación de clases y objetos

1.2 Paradigma modelo-vista-controlador (MVC)
1.3 Asociaciones
1.4 Generalización
1.5 Notación para los diagramas de clases

2. Diagramas de transición de estados

2.1 Identificación de clases y objetos
2.2 Asociaciones

1 Diagramas de clases

1 IDENTIFICACIÓN DE OBJETOS Y CLASES.

Para construir un buen modelo de clases debemos tener en cuenta que:

- Cada comportamiento que se requiera del sistema debe ser proporcionado por
los objetos de las clases que elijamos.
- Un buen modelo de clases está formado (dentro de lo posible) por clases que
representan clases permanentes de los objetos del dominio, las cuales no
dependen de la funcionalidad requerida en este momento.

Para realizar la identificación de clases se utilizan dos técnicas distintas:

- La de identificación de nombres (tipo DDD: Diseño dirigido a los datos) y
- Las tarjetas CRC (tipo DDR: Diseño Dirigido por las Responsabilidades)

1 IDENTIFICACIÓN DE NOMBRES:
Con esta técnica se procede en dos etapas:
1.- Identifique las clases candidatas seleccionando todos los nombres y
locuciones nominales de la especificación de requisitos del sistema
2.- Descarte las candidatas que son inapropiadas por cualquier razón,
renombrando las clases restantes si es necesario.

Las clases pueden ser:

 Cosas tangibles o “del mundo real”: libro, copia, curso.
 Roles: socio biblioteca, estudiante, jefe de estudios.
 Eventos: llegada, salida, petición.
 Interacciones: encuentro, intersección.
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

Razones por las que se podría decidir que una clase candidata es inapropiada:
 Redundante: a la misma clase se le ha dado más de un nombre
 Imprecisa:no se puede identificar de forma no ambigua lo que significa un
nombre
 Un evento u operación: el nombre hace referencia a algo que se hace para,
por o en el sistema.
 Metalenguaje: el nombre forma parte de la manera en que se definen las
cosas.
 Fuera del alcance del sistema: el nombre es relevante para describir cómo
funciona el sistema pero no hace referencia a algo interno al sistema.
 Un atributo: está claro que un nombre hace referencia a algo sencillo, sin un
comportamiento interesante, que es un atributo de otra clase.

2 LAS TARJETAS CRC (Clase, Responsabilidades y Colaboraciones)

No son parte de UML pero añaden ideas útiles en todo el desarrollo.

Para crearlas en una pequeña tarjeta se almacenan:
 El nombre de la clase, en la parte de arriba
 Las responsabilidades de la clase, en la parte izquierda.
 Los colaboradores de la clase, clases que ayudan a ejecutar cada
responsabilidad, en la parte derecha de la tarjeta.

Las responsabilidades de la clase describen el propósito de la existencia de la

clase: están relacionadas con las operaciones que proporciona la clase, pero son
más generales de lo que se podría suponer. Por ejemplo: “mantener los datos
del libro” .
Una clase normalmente no debería tener más de tres o cuatro responsabilidades
y muchas clases tendrán sólo una o dos. Si una clase resulta tener más
responsabilidades se debería dividir. Si una clase no tiene responsabilidades no
debería haberse inventado.
Demasiadas responsabilidades se corresponden con una débil cohesión en el
modelo; muchos colaboradores se corresponden con un fuerte acoplamiento.

2 PARADIGMA MODELO-VISTA-CONTROLADOR

En el proceso de desarrollo de aplicaciones actual, uno de los principios

mas aplicados, casi omnipresente en las aplicaciones interactivas, es el de la
división de la aplicación en tres familias de clases especializadas; Estas familias
serían la vista, el modelo y el controlador. Es decir, un programa no se vería
como un código monolítico sino que sería descompuesto en varias partes o
capas especializadas que interactuarían entre ellas.
La clases de la familia vista serían aquellas clases que representan un
formulario o ventana a través del cual se interactúa con el usuario, es decir las
que permiten mostrar o recabar datos a o desde la aplicación al usuario.
Lo que suceda en estos formularios, lo que se le permitirá hacer o no
hacer al usuario, es decir, la lógica de la aplicación – lógica de negocios en
algunos textos- estará implementada en las clases de la familia controlador.
Por último, para respetar otro de los paradigmas de la programación
actual, el de la independencia entre la gestión de los datos y la aplicación
propiamente dicha, se utiliza una serie de clases, clases modelo, las cuales
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

serían el conjunto de clases encargada de manipular y mantener los datos

presentes en la BBDD de la empresa u organismo.

No todos los programas de una aplicación son abarcables por el

paradigma MVC -modelo/vista/controlador-. Por ejemplo, los programas por
lotes, es decir, aquellos que no necesitan de la interacción del usuario, no
requieren de una clase vista. Otro ejemplo, es el de la difusión de contenidos
multimedia a través de red, que se basa en un paradigma conocido como
productor/consumidor. No obstante, se debería de cumplir en lo posible el
paradigma propuesto, por ejemplo manteniendo la división entre modelos y
controladores.

Las ventajas que se buscan con el seguimiento de este paradigma son

varias:
La lógica de los programas puede mantenerse aislada de la lógica de la
interacción con el usuario, lo que permite algoritmos más duraderos y menos
difícil de mantener.
Sería posible crear vistas con distintas tecnologías que compartieran el
mismo controlador, es decir, una vista podría ser un programa en una aplicación
de escritorio, y otra vista asociada al mismo controlador podría ser una página
web cargada en un navegador.
Por otro lado, las clases modelo serían además de lo expuesto
anteriormente, altamente reutilizables en todos los programas de la aplicación,
e incluso en diferentes aplicaciones de distintos subsistemas del mismo
organismo o empresa.

1 Repercusión en los diagramas de clase

A la hora de elaborar el diagrama de clases de una aplicación, hay que
tener en cuenta que la técnica de identificación de nombres produce solo clases
de la familia de clases modelos. Por lo tanto, sería necesario utilizar los casos de
uso o las tarjetas CRC para determinar las clases controladoras con sus
correspondientes vistas.

2 Enfoque práctico:

Una propuesta inicial de trabajo sería la de crear una clase controlador

por cada caso de uso o requisito funcional demandado que hubiera que
programar. Para cada proceso interactivo previamente identificado en la
detección y descripción de los casos de uso de la aplicación se crearía la vista
pertinente que permitiría la presentación y toma de datos a o desde el
controlador. En el caso de toma de datos para lanzar aplicaciones por lotes, un
controlador diferenciado para la vista de toma de datos, de otro controlador
para recoger en él la lógica del proceso por lote.
Por último, una clase modelo por cada tabla o vista de la BBDD de la
aplicación que se vaya a usar.

Sobre estos criterios iniciales, se debería avanzar a modelos más

refinados según los casos de programa a resolver y los criterios nacidos de la
experiencia y la práctica.
En el caso concreto de las clases modelos se debería buscar ampliar el
número de ellas para crear además una clase diferente por cada consulta
-query- que se necesite lanzar sobre la BBDD.
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

3 Restricciones:

Es importante resaltar que todo lo que ocurra debe de estar sometido al

algoritmo que reside en las clases controladoras, por tanto no debe de haber
interacción directa de las clases vista con las clases modelos; tampoco entre las
clases vista, ni, por supuesto entre las modelo.
Además, cada clase modelo es soberana de los datos de la tabla cuya
gestión encapsula, por tanto este tipo de clases no deben proporcionar al
controlador más que los meros datos que necesite. Para ello tendrá que
contener una serie de métodos que permitan la lógica algorítmica que este
pueda necesitar, pero no deberá en absoluto facilitar el acceso a estructuras de
datos que permitan la interacción de otras clases con la BBDD, ni siquiera con la
tabla o query al que el modelo en concreto refiere.
Para completar las clases modelos, estas deben de contener algoritmos
suficientes para almacenar los datos según las necesidades del controlador; hay
que insistir en que sólo los meros datos deberían llegar a la clase controlador,
aunque en el caso de las consultas, se podría indicar inicialmente la sentencia
que correspondería a dicha consulta. En todo caso no se deben de recibir en el
controlador estructuras o clases auxiliares referidas a la gestión de la BBDD
implementadas para “cocinar” el servicio que el controlador espera de las
diferentes clases modelo. Es muy importante que tampoco se programe en las
clases modelo parte de la lógica que debería residir en el controlados, pues
dificulta la interpretación de este, dificultando su mantenibilidad, además
produciría modelos sobrecargados de código y pésimos para su reutilización en
otras aplicaciones de diferentes subsistemas del organismo o empresa que se
informatiza.

3 ASOCIACIONES

Al igual que las clases se corresponden con nombres, las asociaciones se

corresponden con verbos.
Conceptualmente, se almacena una asociación si hay una asociación en el
mundo real descrita mediante una sentencia corta como “un socio de la
biblioteca toma prestado un libro” y la sentencia parece relevante para el
sistema en cuestión.
La clase A y la clase B están asociados si:
 Un objeto de la clase A envía un mensaje a un objeto de la clase B.
 Un objeto de la clase A crea un objeto de la clase B.
 Un objeto de la clase A tiene un atributo cuyos valores son objetos de la
clase B o colecciones de objetos de la clase B.
 Un objeto de la clase A recibe un mensaje con un objeto de la clase B pasado
como argumento.

El secreto de un buen diseño orientado a objetos está en terminar con un

modelo de clases que no distorsione la realidad conceptual del dominio (de
forma que alguien que comprenda el dominio no reciba sorpresas
desagradables) pero que también permita una implementación coherente de la
funcionalidad requerida.
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

- MULTIPLICIDADES
Se puede especificar:
 Un número exacto simplemente escribiéndolo.
 Un rango de números utilizando dos puntos entre un par de números.
 Un número arbitrario, no especificado utilizando *.

4 GENERALIZACIÓN

Otra relación importante que puede existir entre las clases es la generalización.

Un objeto de una clase especializada puede sustituirse por un objeto de na clase

más general en cualquier contexto que espere un miembro de la clase más
general pero no al revés.
No tiene que haber un abismo conceptual entre lo que hacen los objetos
de las dos clases al recibir el mismo mensaje.

1 Herencia.
Las jerarquías de generalización/especialización se conocen como herencia.
Herencia es el mecanismo que permite a una clase de objetos incorporar atributos y
métodos de otra clase, añadiéndolos a los que ya posee. Con la herencia se refleja una
relación “es_un” entre clases. La clase de la cual se hereda se denomina superclase, y
la que hereda subclase.
La generalización define una superclase a partir de otras. Por ejemplo, de las clases
profesor y estudiante se obtiene la superclase persona. La especialización o
especificación es la operación inversa, y en ella una clase se descompone en una o
varias subclases. Por ejemplo, de la clase empleado se pueden obtener las subclases
secretaria, técnico e ingeniero.

2 Agregación.
La agregación es un tipo de relación jerárquica entre un objeto que representa
la totalidad de ese objeto y las partes que lo componen. Permite el agrupamiento físico
de estructuras relacionadas lógicamente. Los objetos “son-parte-de” otro objeto
completo. Por ejemplo, motor, ruedas, carrocería son parte de automóvil.

3 Composición.
La composición es una forma de agregación donde la relación de propiedad es
más fuerte, e incluso coinciden los tiempos de vida del objeto completo y las partes
que lo componen. Por ejemplo, en un sistema de Máquina de café, las relaciones entre
la clase máquina y producto, o entre máquina y depósito de monedas, son de
composición.

4 Dependencia.
Una relación de dependencia se utiliza entre dos clases o entre una clase y una
interfaz, e indica que una clase requiere de otra para proporcionar alguno de sus
servicios.
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

Interfaces
Una interfaz es una especificación de la semántica de un conjunto de
operaciones de una clase o paquete que son visibles desde otras clases o
paquetes. Normalmente, se corresponde con una parte del comportamiento del
elemento que la proporciona.

Paquetes
Los paquetes se usan para dividir el modelo de clases del sistema de
información,
agrupando clases u otros paquetes según los criterios que sean oportunos. Las
dependencias entre ellos se definen a partir de las relaciones establecidas entre
los distintos elementos que se agrupan en estos paquetes (ver Diagrama de
paquetes).

5 NOTACIÓN:

Clases
Una clase se representa como una caja, separada en tres zonas por
líneas horizontales. En la zona superior se muestra el nombre de la clase que
aparece centrado y si la clase es abstracta se representa en cursiva. El
estereotipo, si se muestra, se sitúa sobre el nombre y entre el símbolo: << ....
>>.
La zona central contiene una lista de atributos, uno en cada línea. La
notación utilizada para representarlos incluye, dependiendo del detalle, el
nombre del atributo, su tipo y su valor por defecto, con el formato:

visibilidad nombre : tipo = valor-inicial { propiedades }

La visibilidad será en general publica (+), privada (-) o protegida (#),

aunque puede haber otros tipos de visibilidad dependiendo del lenguaje de
programación empleado.
En la zona inferior se incluye una lista con las operaciones que
proporciona la clase. Cada operación aparece en una línea con formato:

visibilidad nombre (lista-de-parámetros): tipo-devuelto { propiedad }

La visibilidad será en general publica (+), privada (-) o protegida (#),

aunque como con los atributos, puede haber otros tipos de visibilidad
dependiendo del lenguaje de programación. La lista de parámetros es una lista
con los parámetros recibidos en la operación separados por comas. El formato
de un parámetro es:
nombre : tipo = valor-por-defecto

La notación especificada se puede simplificar según el nivel de detalle

con el que se quiera trabajar en un momento dado.
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

Relaciones
Una relación de asociación se representa como una línea continua entre
las clases asociadas. En una relación de asociación, ambos extremos de la línea
pueden conectar con la misma clase, indicando que una instancia de una clase,
está asociada a otras instancias de la misma clase, lo que se conoce como
asociación reflexiva.
La relación puede tener un nombre y un estereotipo, que se colocan
junto a la línea. El nombre suele corresponderse con expresiones verbales
presentes en las especificaciones, y define la semántica de la asociación. Los
estereotipos permiten clasificar las relaciones en familias y se escribirán entre el
símbolo: << ... >>.
Las diferentes propiedades de la relación se pueden representar con la
siguiente notación:
Multiplicidad: La multiplicidad puede ser un número concreto, un rango o una
colección de números. La letra ‘n’ y el símbolo ‘*’ representan cualquier número.
Orden: Se puede especificar si las instancias guardan un orden con la palabra
clave ‘{ordered}’. Si el modelo es suficientemente detallado, se puede incluir
una restricción que indique el criterio de ordenación.
Navegabilidad: La navegación desde una clase a la otra se representa
poniendo una flecha sin relleno en el extremo de la línea, indicando el sentido
de la navegación.
Rol o nombre de la asociación: Este nombre se coloca junto al extremo de la
línea que esta unida a una clase, para expresar cómo esa clase hace uso de la
otra clase con la que mantiene la asociación.

Además, existen notaciones específicas para los otros tipos de relación,

como son:
Agregación: Se representa con un rombo hueco en la clase cuya instancia es
una agregación de las instancias de la otra.
Composición: Se representa con un rombo lleno en la clase cuya instancia
contiene las instancias de la otra clase.
Dependencia: Una línea discontinua con una flecha apuntando a la clase
cliente. La relación puede tener un estereotipo que se coloca junto a la línea, y
entre el símbolo: << ... >>.
Herencia: Esta relación se representa como una línea continua con una flecha
hueca en el extremo que apunta a la superclase.

Paquetes
Los paquetes se representan mediante un icono con forma de carpeta y
las dependencias con flechas discontinuas entre los paquetes dependientes (ver
Diagrama de paquetes).

Ejemplo
Estudio del sistema encargado de la gestión de préstamos y reservas de libros y
revistas de una biblioteca. Dependiendo del momento del desarrollo el diagrama estará
más o menos detallado. Así, el diagrama tendría la siguiente estructura en el proceso
de análisis:
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

2 Diagrama de transición de estados

1 DEFINICIÓN.

Un diagrama de transición de estados muestra el comportamiento

dependiente del tiempo de un sistema de información. Representa los estados
que puede tomar un componente o un sistema y muestra los eventos que
implican el cambio de un estado a otro.

Descripción
Los dos elementos principales en estos diagramas son los estados y las
posibles transiciones entre ellos.
– El estado de un componente o sistema representa algún comportamiento
que es observable externamente y que perdura durante un periodo de
tiempo finito. Viene dado por el valor de uno o varios atributos que lo
caracterizan en un momento dado.
– Una transición es un cambio de estado producido por un evento y refleja los
posibles caminos para llegar a un estado final desde un estado inicial.
Desde un estado pueden surgir varias transiciones en función del evento
que desencadena el cambio de estado, teniendo en cuenta que, las
transiciones que provienen del mismo estado no pueden tener el mismo
evento, salvo que exista alguna condición que se aplique al evento.

Un sistema sólo puede tener un estado inicial, que se representa mediante

una transición sin etiquetar al primer estado normal del diagrama. Pueden
existir varias transiciones desde el estado inicial, pero deben tener asociadas
condiciones, de manera que sólo una de ellas sea la responsable de iniciar el
flujo. En ningún caso puede haber una transición dirigida al estado inicial.
El estado final representa que un componente ha dejado de tener cualquier
interacción o actividad. No se permiten transiciones que partan del estado
final. Puede haber varios estados finales en un diagrama, ya que es posible
concluir el ciclo de vida de un componente desde distintos estados y mediante
diferentes eventos, pero dichos estados son mutuamente excluyentes, es decir,
sólo uno de ellos puede ocurrir durante una ejecución del sistema.
Los diagramas de transición de estados comprenden además otros dos
elementos que ayudan a clarificar el significado de los distintos estados por los
que pasa un componente o sistema. Estos elementos se conocen como
acciones y actividades. Una acción es una operación instantánea asociada a un
evento, cuya duración se considera no significativa y que se puede ejecutar:
dentro de un estado, al entrar en un estado o al salir del mismo. Una actividad
es una operación asociada a un estado que se ejecuta durante un intervalo de
tiempo hasta que se produce el cambio a otro estado.
Para aquellos estados que tengan un comportamiento complejo, se puede
utilizar un diagrama de transición de estados de más bajo nivel. Estos
diagramas se pueden mostrar por separado o bien incluirse en el diagrama de
más alto nivel, dentro del contorno del estado que representa. En cualquier
caso su contenido formará un contexto independiente del resto, con sus
propios estados inicial y final.
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

2 NOTACIÓN.

1 Estado
Un estado se representa como un rectángulo con las esquinas
redondeadas. El nombre del estado se coloca dentro del rectángulo y debe ser
único en el diagrama. Si se repite algún nombre, se asume que simboliza el
mismo estado.
Las acciones y actividades descritas como respuesta a eventos que no
producen un cambio de estado, se representan dentro del rectángulo con el
formato:
nombre-evento (parámetros) [condición] /acción
El estado inicial se representa con un pequeño círculo relleno, y el estado
final como un pequeño circulo relleno con una circunferencia que lo rodea.

2 Transición
Una transición se representa con una flecha continua que une dos estados y
que se dirige al estado al que cambia el componente. Junto a ella se coloca una
etiqueta que debe contener al menos el nombre del evento que provoca la
transición. Según el nivel de detalle, puede presentar otros elementos con el
formato siguiente:
nombre-evento (parámetros) [condición] /acción
Ejemplo.
IES MAR DE CÁDIZ
1º del Ciclo Superior de Desarrollo de Aplicaciones Web
Entornos de Desarrollo.

Glosario:

1 Cohesión
La cohesión tiene que ver con que cada módulo del sistema se refiera a
un único proceso o entidad. A mayor cohesión, mejor: el módulo en cuestión
será más sencillo de diseñar, programar, probar y mantener.

En el diseño estructurado, se logra alta cohesión cuando cada módulo

(función o procedimiento) realiza una única tarea trabajando sobre una sola
estructura de datos

Aplicado a la programación orientada a objetos, las clases tendrán alta

cohesión cuando se refieran a una única entidad. Una clase con alta cohesión
suele cumplir el principio de única responsabilidad; para los métodos se
aplicaría lo mismo que para las funciones o procedimientos.

2 Acoplamiento
El acoplamiento mide el grado de relación de un módulo con los demás.
A menor acoplamiento, mejor: el módulo en cuestión será más sencillo de
diseñar, programar, probar y mantener.

En el diseño estructurado, se logra bajo acoplamiento reduciendo las

interacciones entre procedimientos y funciones, reduciendo la cantidad y
complejidad de los parámetros y disminuyendo al mínimo los parámetros por
referencia

Una clase, en cambio, tendrá bajo acoplamiento cuando tenga la menor

dependencia posible de otras clases. Esta dependencia significa que – si bien
puede haber muchas clases que dependen de una – debería haber pocas
dependencias hacia otras clases desde una sola. Las dependencias que
importan son, de mayor a menor: generalización/herencia, composición,
asociación y dependencia débil.

Un paquete debe cumplir con estos mismos requisitos, en el sentido de

que debe tener vinculaciones mínimas con otros paquetes. Decimos que hay
dependencia entre paquetes cuando hay clases de un paquete que dependen
de clases de otro paquete, sea por herencia, asociación o simple dependencia
débil.