Elaboracin de diagramas de clase

5.1. Introduccin
En el **diseo orientado a objetos**, un sistema se entiende como un conjunto de
objetos que tienen propiedades y comportamientos.
Un **objeto** consta de una estructura de datos y de una coleccin de mtodos u oper
aciones que manipulan esos datos. Los datos definidos dentro de un objeto son su
s atributos. Las operaciones definen el comportamiento de los objetos y cambian
el valor de uno o ms atributos. Los objetos se comunican unos con otros a travs de
l paso de mensajes.
Una **clase** no es ms que una plantilla para la creacin de objetos. Cuando se cre
a un objeto (instanciacin) se ha de especificar de qu clase es el objeto instancia
do, para que el compilador comprenda las caractersticas del objeto.
Para el anlisis y diseo orientado a objetos se utiliza **UML** (*Unified Modeling
Language*). Es un lenguaje de modelado basado en diagramas que sirven para expre
sar modelos (un modelo es una representacin de la realidad donde se ignoran detal
les de menor importancia). Se ha convertido en el estndar de facto en la mayor pa
rte de la metologas de desarrollo orientado a objetos que existen hoy en da.
5.2. Conceptos orientados a objetos
El paradigma *OO** se bas en el concepto de *objeto*. Un objeto es aquello que t
iene estado (propiedades ms valores, comportamiento (acciones y reacciones a mens
ajes) e identidad (propiedad que las distingue de los dems objetos). La estructur
a y comportamiento de objetos similares estn definidos en su clase comn, los trmino
s instancia y objeto son intercambiables. Una clase es un conjunto de objetos qu
e comparten una estructura y comportamiento comn.
Clases y objetos pueden perecen conceptos similares, pero existe una clara difer
encia conceptual entre ellos. Las clases son un concepto esttico definido en el p
rograma fuente, son una abstraccin de la esencia de un objeto, mientras que los o
bjetos son entes dinmicos que existen en tiempo y espacio, y que ocupan memoria e
n la ejecucin de un programa.
En el enfoque *OO* las propiedades del objeto son claves. Los principios del mod
elo *OO* son:
- Abstraccin
- Encapsulacin
- Modulariadad
- Jearqua
- Polimorfismo
- Tipificacin
- Concurrencia
- Persistencia
Propiedades
- **Abstraccin**. Denota las caractersticas esenciales de un objeto, donde se capt
uran sus comportamientos. El objetivo es obtener una descripcin formal. La abstra
ccin es clave en el proceso de anlisis y diseo orientado a objetos, ya que mediante
ella, podemos llegar a componer un conjunto de clases que permitan modelar la r
ealidad y el problema que se quiere resolver.
- **Encapsulacin**. La encapsulacin es el proceso de ocultar todos los detalles d
e un objeto que no contribuyen a sus caractersticas esenciales, es decir, separar
el aspecto externo del objeto accesible por otros objetos, del aspecto interno
del mismo que ser inaccesible para los dems. O lo que es lo mismo, la encapsulacin
consiste en ocultar los atributos y mtodos del objeto a otros objetos, estos no d
eben estar expuestos a los objetos exteriores. Una vez encapsulados, pasan a den
ominarse atributos y mtodos privados del objeto.
- **Modularidad**. Es la propiedad de una aplicacin o de un sistema que ha sido d
escompuesto en un conjunto de mdulos o partes ms pequeas coherentes e independiente
s. Estos mdulos se pueden compilar por separado, pero tienen conexiones con los o
tros mdulos.
- **Jearqua o herencia**. La programacin orientada a objetos introduce la posibili
dad de extender clases , produciendo nuevas definiciones de clases que heredan t
odo el comportamiento y cdigo de la clase extendida. La clase original se denomin
a clase padre, base o superclase. La nueva clase que se define como una extensin
se denomina clase hijo, derivada o subclase. La extensin de una clase se denomina
herencia, porque la nueva clase hija hereda todos los mtodos y atributos de la c
lase padre que se extiende. Cad subclase estara formada por un grupo de objetos ms
especializados caractersticas comunes que compartiran datos y operaciones. Los ob
jetos heredan las propiedades y el comportamiento de todas las clases a las que
pertenecen.
- **Polimorfismo**. Consiste en reunir con el mismo nombre comportamientos difer
entes. Es la propiedad por la cul un mismo mensaje puede originar conductas compl
etamente diferentes al ser recibido por diferentes objetos. De un modo ms preciso
: dos instancias u objetos, pertenecientes a distintas clase, pueden responder a
la llamada a mtodos del mismo nombre, cada uno de ellos con distinto comportamie
nto encapsulado, pero que responden a una interfaz comn (marcada a travs del mecan
ismo de la herencia).
- **Tipificacin**. Es la definicin precisa de un objeto, de tal forma que objetos
de diferentes tipos no puedan ser intercambiados o, cuando mucho, pueden interca
mbiarse de manera muy restringida.
- **Concurrencia**. Es la propiedad que distingue un objeto que est activo de uno
que no lo est. El objeto activo est haciendo algo, se utilizan sobre todo en la p
rogramacin concurrente o multihilo.
- **Persistencia**. Es la propiedad de un objeto a travs de la cual su existencia
transciende el tiempo (es decir, el objeto continua existiendo despus de que su
creador ha dejado de existir) y/o el espacio. Se refiere a objetos de clases aso
ciadas a Bases de Datos Orientadas a Objetos (BDOO) o a Bases De Datos Objeto Re
lacionales (BDOR).
Actualmente las metodologas ms importantes de anlisis y diseo de sistemas han conflu
ido en lo que es el UML, bajo el respaldo del *Object Management Group*.
5.3. UML
El **Lenguaje de Modelado Unificado** (UML) es un lenguaje grfico para visualizar
, especificar y documentar cada una de las partes que comprende el desarrollo de
software. Este lenguaje se puede utilizar para modelar tanto sistemas de softwa
re, como de hardware, como organizaciones del mundo real. Para ello utiliza una
serie de diagramas en los que se representan los distintos puntos de vista de mo
delado. Podemos decir que UML es un lenguaje que se utiliza para documentar.
Existen dos grandes versiones de UML.
- **UML 1.X** (1.1 - 1.5). Desde finales de los 90 se empez a trabajar con el estn
dar UML. En los aos sucesivos fueron apareciendo nuevas versiones que introducan m
ejoras o ampliaban a las anteriores.
- **UML 2.X** (2.1 - 2.5). En torno a 2005 se difundi una nueva versin de UML a la
que podemos denominar *UML 2.X*. Comprenden varias revisiones.
**UML 2.0** define 13 tipos de diagramas, dividios en 3 categoras: 6 tipos de dia
gramas representan la estructura esttica de la aplicacin o del sistema, 3 represen
tan tipos de diagramas generales de comportamiento y 4 representan diferentes as
pectos de las interacciones:
- **Diagramas de estructura (parte esttica del modelo). Incluye el diagrama de cl
ases, diagrama de objetos, diagrama de componentes, diagrama de estructura,compu
esta, diagrama de paquetes y diagrama de implementacin o despliegue. Se centran e
n los elementos que deben existir en el sitema modelado.
- **Diagramas de comportamiento (parte dinmica del modelo). Incluyen el diagrama
de casos de uso (usado por algunas metodologas durante la recopilacin de requisito
s), diagramas de actividad y diagramas de estado. Se centran en lo que debe suce
der en el sistema.
- **Diagramas de interaccin**. Todos derivados del diagrama de comportamiento ms g
eneral. Incluyen el diagrama de secuencia, diagrama de comunicacin, diagrama de t
iempos y diagrama de vista de interaccin. Se centran en el flujo del control y de
datos entre los elementos del sistema modelado.
5.3.1. Tipos de diagrama
Cada diagrama UML representa alguna parte o punto de vista del sistema. Los diag
ramas ms utilizados son los siguientes:
- **Diagramas de clase**. Los diagramas de clases muestran las diferentes clases
que componen un sistema y cmo se relacionan unas con otras.
- **Diagramas de objeto**. Representan objetos y sus relaciones. Muestra una ser
ie de objetos (instancias de las clases) y sus relaciones en un momento particul
ar de la ejecucin del sistema. Es un diagrama de instancias de las clases mostrad
as en el diagrama de clases. Son tiles para la comprensin de los diagramas de clas
es.
- **Diagramas de casos de uso**. Se utiliza para entender el uso del sistema, mu
estran un conjunto de actores, las acciones (casos de uso) que se realizan en el
sistema y las relaciones entre ellos.
- **Diagramas de secuencia**. Son una representacin temporal de los objetos y sus
relaciones. Enfatiza la interaccin entre los objetos y los mensajes que intercam
bian entres s junto con el orden temporal de los mismos.
- **Diagramas de estado**. Se utiliza para analizar los cambios de estado de los
objetos. Muestra los estados, eventos, transiciones y actividades de los difere
ntes objetos.
- **Diagramas de actividad**. En UML, un diagrama de actividad se utiliza para m
ostrar la secuencia de actividades. Los diagramas de actividades muestran el flu
jo de trabajo desde un punto de inicio hasta el punto final detallando las decis
iones que surgen en la progresin de los eventos contenidos en la actividad.
- **Diagramas de despliegue**. Especifica el hardware fsico sobre el que el siste
ma de software se ejecutar y tambin especifica cmo el software se despliega en ese
hardware. Est compuesto de nodos. Un nodo es una unidad material capaz de recibir
y de ejecutar software. La mayora de nodos son ordenadores. Los vnculos fsicos ent
re nodos tambin pueden describirse en el diagrama de despliegue, corresponden a l
as ramas de la red. Los nodos contiene software en su forma fsica, conocida como
*artefact*. Los archvios ejecutables, las bibliotecas compartidas, y los scropts
son ejemplos de formas fsicas de software.
- **Diagrama de paquetes**. Los diagramas de paquetes se usan para reflejar la o
rganizacin de paquetes y sus elementos. Cuando se utiliza para representar elemen
tos de clase, los diagramas de paquetes proporcionana una visualizacin de los esp
acios de nombre. El uso ms comn de los diagramas de paquete es organizar diagramas
de casos de uso y diagramas de clases, aunque el uso de diagramas de paquetes n
o se limita a estos elementos UML.
5.4. Diagramas de clases
Un diagrama de clases es un tipo de diagrama de estructuras (esttico) que describ
e la estructura de un sistema mostrando sus clases y las asociaciones entre ella
s. Sirve para visualizar las relaciones entre las clase que componen el sistema.
Un diagram de clases est compuesto por lo siguientes elementos:
- **Clases**: atributos, mtodos y visibilidad.
- **Relaciones**: asociaciones, herencia, agregacin, composicin, realizacin y depen
dencia.
5.4.1. Clases
Las clases son la unidad bsica que encapsula toda la informacin de un objeto (un o
bjeto es una instancia de una clase). A travs de ella podemos modelar el entorno
en estudio (un empleado, un departamento, una cuenta corriente, un articulo, etc
.). En UML, una clase se representa por un rectngulo que posee tres divisiones:
- **Parte superior**. Contiene el nombre de la clase.
- **Intermedio**. Contiene los atributos (o variables de instancia) que caracter
izan a la clase (pueden ser *private*, *protected*, *package* o *public*).
- **Parte inferior**. Contiene los mtodos u operaciones, los cuales son la forma
como interacta el objeto con su entorno (dependiendo de la visibilidad: *private*
, *protected*, *package* o *public*).
En la representacin de una clase los atributos y mtodos pueden omitirse. Por defec
to la visibilidad de los atributos debe ser *private* y de los mtodos *public*.
Atributos
Un atributo representa alguna propiedad de la clase que se encuentra en todas l
as instancias de la clase. Los atributos pueden representarse solo mostrando su
nombre, o mostrando su nombre y su tipo, e incluso su valor por defecto. Ejemplo
de atributos son: Nombre, Salario, Cdigo, Telfono, etc. Al crear los atributos se
indicar el tipo de dato, los tipos bsicos UML son Integer, String, Boolean. Tambin
se pueden indicar los tipos de cualquier lenguaje de programacin.
Al crear el atributo se indicar su visibilidad con el entorno, la visibilidad est
estrechamente relacionada con el encapsulamiento. Se distinguen los siguientes t
ipos:
- **public**. El atributo ser pblico, visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados. Tambin se representan con un signo +.
- **private**. El atributo solo ser accesible desde dentro de la clase (solo sus
mtodos pueden acceder al atributo). Tambin se representan con un signo -.
- **protected**. El atributo no ser accesible desde fuera de la clase, pero si po
dr ser accedido por mtodos de la clase, adems de las subclases que se deriven. Tamb
in se representa con el carcter almohadilla .
- **package**. El atributo empaquetado es visible en las clases del mismo paquet
e. Se representa con el carcter tilde ~.
Mtodos
Un mtodo, tambin llamado operacin, es la implementacin de un servicio de la clase qu
e muestra un comportamiento comn a todos los objetos. Definen la forma de cmo la c
lase interacta con su entorno. Igual que los atributos los mtodos pueden ser:
- **p**. El mtodo es accesible desde todos lados (desde dentro y fuera de la clas
e). Se representan con un signo +.
- **p**. Slo los mtodos de la clase pueden acceder a l. Se representa con un signo
-.
- **p**. El mtodo puede ser accedido por mtodos de la clase adems de los mtodos de l
as subclases que se deriven. Se representa con la almohadilla .
- **p**. El mtodo empaquetado o paquete solo es visible en la clases del mismo pa
quete. Se representa con el carcter tilde ~.
5.4.2. Relaciones
En el mundo real muchos objetos estn vinculados o relacionados entre s, los vnculos
se corresponden con asociaciones entre los objetos, por ejemplo, el vnculo exist
ente entre un alumno y el curso en el que est matriculado, o el vnculo entre un pr
ofesor y El Centro en el que trabaja. En UML, estos vnculos se describen mediante
asociaciones, de igual modo que los objetos se describen mediante clases.
Las asociaciones tienen un nombre y como ocurre con las clases, este es un refle
jo de los elementos de la asociacin. Tambin posee una carnalidad llamada *multipli
cidad* que representa el nmero de instancias de una clase que se relacionan con l
as instancias de otra clase, esta multiplicidad es similar a la carnalidad utili
zad en el modelo *Entidad/Relacin*. La multiplicidad situada en un extremo de una
asociacin indica a cuntas instancias de la clase situada en ese mismo extremo est
vinculada una instancias de la clase situada en el extremo opuesto.
En uno de los extremos de la asociacin, es posible especificar la multiplicidad mn
ima y la mxima con el fin de indicar el intervalo de valores al que deber pertenec
er siempre la multiplicidad. Para expresar las multiplicidades mnimas y mximas se
utiliza la siguiente notacin:
- 0..1. Cero o una vez.
- 1. Una y solo una vez.
- *. De cero a varias veces.
- 1..*. De una a varias veces.
- M..N. Entre M y N veces.
- N. N veces.
Distinguimos los siguientes tipos de relaciones:
**Asociacin**.
Puede ser bidireccional o unidireccional, dependiendo de si ambas conocen la exi
stencia la una de la otra o no. Dentro de una relacin de asociacin, cada clase jue
ga un papel (rol), que se indica en la parte superior o inferior de la lnea que c
onecta a dichas clases. La asociacin cuenta con instancias que son los vnculos y q
ue se representan como una lnea que conecta dos objetos y se pone un nombre a la
relacin.
Si se convierten a Java dos clases unidas por una asociacin bidirectional, cada u
na de las clases tendr un objeto o set de objetos, dependiendo de la multiplicida
d entre ellas. En cambio en la asociacin unidireccional, la clase destino no sabr
de la existencia de la clase origen, y la clase origen contendr un objeto o set d
e objetos de la clase destino.
La **navegabilidad** entre clases nos muestra que es posible pasar de un objeto
de la clase origen a uno o ms objetos de la clase destino dependiendo de la multi
plicidad. En el caso de la asociacin *Unidireccional* la navegabilidad va en un s
olo sentido, del origen al destino, el origen es navegable al destino, sin embar
go no es navegable al origen.
**Ejemplo**. El codigo generado en *Eclipse UML* correspondiente a asociaciones
de ejemplo se muestra a continuacion, observa que se utiliza la clase *HashSet*
para guardar colecciones de objetos en el caso de las multiplicidades.
public class Cliente {
public HashSet<Facturas> facturas = new HashSet<Facturas>();
public Cliente() {
}
public HashSet<Facturas> getFacturas() {
return this.facturas;
}
public void setFacturas(HashSet<Facturas> newFacturas) {
this.facturas = newFacturas;
}
 }
public class Facturas {
public Cliente cliente = null;
public Facturas() {
}
public Cliente getCliente() {
return this.cliente;
}
public void setCliente (Cliente newCliente) {
this.cliente = newCliente;
}
}
Una clase puede asociarse consigo misma creando una asociacion reflexiva, simila
r a las relaciones del modelo Entidad/Relacion. Estas asociaciones unen entre si
instancias de una misma clase.
**Clase asociacion**.
Una asociacion entre dos clase puede llevar informacion necesaria para esa asoci
acion, a esto se le llama **clase asociacion**, es como una relacion M:N con atr
ibutos del modelo Entidad/Relacion. En este caso, esta clase asociacion recibe e
l estatus de clase y sus instancias son elementos de la asociacion, al igual qu
e el resto, estas clases pueden estar dotadas de atributos y operaciones y estar
vinculadas a otras clases a traves de asociaciones.
**Herencia (generalizacion y especializacion)**.
Las clase con atributos y operaciones comunes se pueden organizar de forma jerar
quica mediante la herencia. La herencia es una abstraccion importante
para compartir similitudes entre clases, donde todos los atributos y operaciones
comunes a varias clases se pueden compartir por medio de la superclase, una cla
se mas general. Las clases mas refindas se conocen como las subclases. La genera
lizacion indica que una clase (clase secundaria o subclase) hereda los atributos
y metodos de otra (clase principal o superclase). La superclase generaliza a su
s subclases y las subclases especializan a la superclase.
Para representar esta asociacion se utiliza una flecha, el extremo de la flecha
apunta a la superclase.
**Ejemplo**. El codigo Java generado para una superclase Persona y sus subclases
Alumno y Empleado es:
public class Persona {
private int dni;
private char nombre;
private char sexo;
private char fechanacimiento;
public Persona() {
}
}
public class Alumno extends Persona {
private int numatricula;
private int curso;
public Alumno() {
 }
}
public class Empleado extends Persona {
private char numerosegsocial;
private char puestotrabajo;
private int salario;
public Empleado() {
}
}
**Composicion**.
Un objeto puede estar compuesto por otros objetos, en estos casos nos encontramo
s ante una asociacion entre objetos llamada **Asociacion de composicion**. Esta
asocia un objeto complejo con los objetos que los constituyen, es decir, sus com
ponentes. Existen dos formas de composicion, fuerte o debil. La fuerte se la con
oce como **composicion** y la debil se conoce como **agregacion**.
En la composicion fuerte, los componentes constituyen una parte del objeto compu
esto, y estos no pueden ser compartidos por varios objetos compuestos.
Por tanto, la cardinalidad maxima, a nivel del objeto compuesto, es obligatoriam
ente uno. La supresion del objeto compuesto comporta la supresion
de los componentes.
Se representa por una linea con un rombo relleno.
**Ejemplo**. El codigo Java generado para una clase Ordenador, con los getters y
los setters seria la siguiente:
public class Ordenador {
public HashSet<Memoria> memorias = new HashSet<Memoria>();
public HashSet<Disco> discos = new HashSet<Disco>();
public Teclado teclados = null;
public Placa placas = null;
public Ordenador() {
}
public HashSet<Memoria> getMemoria() {
return this.memorias;
}
public void setMemorias(HashSet<Memoria> newMemorias) {
this.memorias = newMemorias;
}
public HashSet<Disco> getDisco() {
return this.discos;
}
public void setDiscos(HashSet<Disco> newDiscos) {
this.discos = newDiscos;
}
public Teclado getTeclados() {
return this.teclados;
}
public void setTeclados(Teclado newTeclados) {
this.teclados = newTeclados;
}
public Placa getPlacas() {
return this.placas;
}
public void setPlacas(Placa newPlacas) {
this.placas = newPlacas;
 }
}
**Agregacion**.
La agregacion es la composicion debil, en este caso, los componentes pueden ser
compartidos por varios compuestos y la destruccion del compuesto no implica la d
estruccion de los componentes. La agregacion se da con mayor frecuencia que la c
omposicion en las primeras fases de modelado, es posible utilizar solo la agrega
cion y determinar mas adelante que asociaciones de agregacion son asociaciones d
e composicion.
Se representa por una linea con un rombo vacio.
**Realizacion**
Una relacion de realizacion es la relacion de herencia existen entre un clase in
terfaz y la subclase que implementa esa interfaz. Tambien se puede encontrar rel
aciones de realizacion entre los casos de uso y las colaboraciones que los reali
zan.
Esta relacion de herencia se representa graficamente mediante una flecha con una
linea discontinua, en lugar de una linea completa.
**Ejemplo**. Interfaz Animal y subclase Perro.
public interface Animal {
public void comer();
public void comunicarse();
public void reproducirse();
}
public class Perro implements Animal {
public Perro();
public void reproducirse() {
}
public void comunicarse() {
}
pubic void comer() {
}
}
**Dependencia**.
Es una relacion que se establece entre dos clase cuando una clase usa a la otra,
es decir, que la necesita para su cometido, las instancias de la clase se crean
y se emplean cuando se necesitan.
Se representa conuna flecha sin relleno disocntinua que va desde la clase utiliz
adora a la clase utilizada (clase de la que depende). Con la dependencia mostram
os que un cambio en la clase utilizada puede afectar al funcionamiento de la cla
se utilizadora, pero no al contrario.
Ejemplo de relacin de dependencia lo podemos tener con una clase *Impresora, y un
a clase *Documento*, la impresora imprime documentos, entonces necesita al docum
ento para imprimirlo.
5.4.3. Estereotipos
Los estereotipos son el mecanismo de extensibilidad que ms se utiliza dentro del
modelado UML, este mecanismo va a permitir definir nuevos elementos de modelado
UML basndose en uno existente. Nosotros mismos podemos definir la semntica (signif
icado, interpretacin y sentido) del estereotipo. Puede ser aplicado a cualquier e
lemento de modelado como clases, paquetes, relaciones de herencia, o cualquier o
tro tipo de relacin.
Cada estereotipo puede definir un conjunto de valores etiquetados y restriccione
s que se aplican al elemento estereotipado. El nombre del estereotipo generalmen
te se indica escribindolo entre comillas francesas *<< >>*, por ejemeplo *<<inter
face>>*, aunque tambin se les puede asociar un icono. Existen muchas formas de re
presentar un estereotipo.
Aunque crear estereotipos no es objetivo de estudio, si conviene saber e identif
icar los estereotipos que proporcionan las herramientas de modelado, algunos de
ellos son los siguientes.
- **Estereotipos para los diagramas de clases**
- Enumeration
- Interface
- DataType
- Signal
- Exception
- **Estereotipos para los diagramas de comportamiento**
- Entity
- Control
- Boundary
Al hacer el anlisis de una aplicacin podemos utilizar el mtodo **RUP** (Rational Un
ified Process) es un proceso de desarrollo de software desarrollado por la empre
sa *Rational Software*, actualmente propiedad de IBM. Junto a UML, constituye la
metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin
e sistemas orientados a objetos.
La idea de esta tcnica es considerar tres tipos distintos de clases de anlisis dur
ante la etapa del anlisis del sistema, estos tres tipos distintos de clases se pu
eden distinguir por los estereotipos de la siguiente tabla:
- **<<boundary>>**. Representa una clase mediadora entre el sistema y su entorno
. Es decir, son las clases que hacen de interface entre el sistema y los usuario
s, entre el sistema con otros sistemas, y el sistema con otros dispositivos exte
rnos. Se usan para modelar la interaccin entre el sistema y los actores, esta int
eraccin involucra recibir y presentar informaciones y peticiones desde los usuari
os y sistemas externos.
A los objetos de estas clases se les llama *instancias de clases lmite* o *fronte
ra*. Estas clases representarn, por ejemplo, las ventanas, formularios, impresora
s, o dispositivos de nuestro sistema.
-**<<control>>**. Estas clases son controladores, sus instancias coordinan el co
mportamiento del sistema que corresponde a uno o ms casos de uso. Los objetos con
trol modelan la funcionalidad del sistema, representan la coordinacin, secuencia,
gestin de transacciones y control de otros objetos.
Se usa representar clculos y derivaciones complejas, como la lgica del negocio que
no se puede relacionar con ninguna entidad.
- **<<entity>>**. Estas clases guardan informacin sobre el estado interno del sis
tema, a corto y largo plazo, corresponde al dominio del problema. Expresan la es
tructura lgica de datos del sistema y estn ntimamente relacionadas con el modelo de
datos.
Estn manipuladas por la clase de control y aceptan informacin de clases lmite.
Normalmente son clases persistentes (por ejemplo asociadas a tablas de bases de
datos relacionales), ejemplo de ellas pueden ser la clase artculos o la clase cli
entes.
Herramientas para el diseo de diagramas
Hoy en da existen cientos de herramientas CASE que soportan el lenguaje UML. A la
hora de elegir una herramienta, hay que tener en claro que para qu se va a utili
zar, y cul es el objetivo que se propone, porque podemos pensar en utilizar una h
erramienta para que genere cdigo Java, o simplemente utilizar la herramienta para
dibujar modelos y aadirlos a nuestra aplicacin.
Hemos optado por elegir herramientas de software libre, en esta unidad estudiare
mos el uso de varias herramientas que nos permitirn tener una visin global del fun
cionamiento de este tipo de software.
5.5.1. ArgoUML
ArgoUML es la herramienta de modelado UML de cdigo abierto lder e incluye soporte
para todos los diagramas UML 1.4 estndar. Se ejecuta en cualquier plataforma Java
y est disponible en diez idiomas. Se descarga desde la pgina web del desarrollado
r, su instalacin es sencilla e intuitiva. Alguna de sus caractersticas son las sig
uientes:
- Est escrita en Java y disponible en cualquier plataforma soportada por Java.
- Permite crear los siguientes tipos de diagramas: casos de uso, clases, secuenc
ia, colaboracin, estado, actividades y despliegue.
- Es compatible con el estndar UML 1.4.
- Tiene soporte para la creacin de perfiles y la distribucin de los modelos que ha
cen referencia a los perfiles. Se entrega con perfiles para: Java, C++ y UML 1.4
.
- ArgoUML proporciona la generacin de cdigo para Java, C++, C, SQL, PHP4 y PHP5.
- Proporciona generacin de ficheros PNG, GIF, JPG, SVG, EPS desde los diagramas.
- Dispone de **crticas de diseo**, que analizan el diseo en el que se trabaja y sug
ieren posibles mejoras. Estas sugerencias van desde la indicacin de errores de si
ntaxis, a los recordatorios para cumplir directrices de estilo.
Una vez instalada la herramienta, al abrirla se muestra la ventana inicial, como
todas las aplicaciones Windows dispone de la barra de mens y de la barra de herr
amientas. Adems se distinguen cuatro paneles:
- El panel del explorador a la izquierda, donde tenemos una vista en forma de rbo
l de los diagramas del modelo y los elementos que lo forman.
- A la derecha el panel de diseo del diagrama, donde se colocarn los elementos que
los forman.
- En la parte inferior izquierda se encuentra el panel de crticas y consejos que
ayuda a los diseadores a resolver los problemas que vayan surgiendo durante el di
seo.
- Y finalmente en la parte inferior se encuentra el panel de detalles y propieda
des. Donde se configurarn las propiedades de los elementos, y dems se podr visualiz
ar el cdigo que se va generando.
5.5.2. UML con Eclipse
Para poder realizar diagramas UML utilizando Eclipse instalaremos el plugin *UML
2*. Para ello desde Eclipse:
- Se abre el men *Help*
- Se selecciona *Eclipse Marketplace*
- Tecleamos *UML2* en Find
- Pulsamos el botn *Go* para que busque el plugin.
Una vez localizados los plugins, se muestra una lista de ellos, hemos de elegir
el plugin que se corresponda con la versin de Eclipse con la que se trabaje, en n
uestro caso se elige *UML Designer*
- Pulsa en *Install*
- Acepta las condiciones y comienza la instalacin.
Una vez terminada la instalacin y reiniciado, Eclipse observa que se han creado n
uevas vistas, la que interesa ahora es la vista *Modeling*.
Para crear un proyecto:
- Abrimos el men File > New > UML Project
- Tecleamos el nombre
- Aceptamos las opciones por defecto y creamos el proyecto.
Para crear un diagrama UML nos posicionamos sobre el proyecto, botn derecho del r
atn y se elige *Create Representation*, y desde ah se selecciona el tipo de diagra
ma a crear.
Dentro de los tipos de diagramas nos fijamos en los siguientes:
- **Diagrama de comportamiento** (UML Behavioral Modeling) para crear los diagra
mas de actividad, de estado, de casos de uso, y de secuencia.
- **Diagramas de estructuras o estructurales** (UML Structural Modeling), entre
los que se encuentran el diagrama de clases, diagrama de componentes, diagrama d
e estructura de compuesta, diagrama de implementacin o despliegue, diagrama de ob
jetos o diagrama de paquetes.
Creacin de diagramas de clase
Para crear un diagrama de clases se pulsa el botn derecho del ratn sobre el proyec
to, se elige *Create Representation* y dentro de *UML Structural Modeling* se s
elecciona *Class Diagram*. Se pulsa siguiente, se selecciona en qu modelo se crea
r el diagrama, se teclea un nombre y se abre la vista de diseo, que nos mostrara l
os siguientes elementos:
- **Vista del proyecto**.
- **Vista de diseo**.
- **Paleta de elementos**.
- **Pestaa Propiedades**.
Desde la paleta se seleccionar el elemento a insertar al diagrama, clase, paquete
, atributo, operacin o tipo de relacin, basta con marcar y arrastrar. Tambin se pue
den seleccionar los elementos desde la barra flotante de botones.
**Ejemplo 1**. Se trata de realizar un diagrama de clases para representar las r
elaciones entre empresa, empleados y clientes. Utilizaremos asociaciones de comp
osicin y generalizacin en el diagrama. Los requisitos son los siguientes:
- La empresa se compone de clientes y de empleados. Utilizaremos para estas rela
ciones asociaciaciones de composicin.
- Datos de la empresa son: CIF, razn social, direccin y telfono.
- Datos de clientes son: cdigo de cliente, nombre, fecha de nacimiento, telfono, e
mpresa para la que trabaja y comisin.
- Datos de empleado son: cdigo de empleado, nombre, fecha de nacimiento, telfono,
fecha de alta en la empresa y salario.
- Como los atributos nombre, fecha de nacimiento y telfono son comunes para clien
tes y empleados se crear una clase persona para esos atributos, y las clases clie
nte y empleado heredarn la clase persona.
- Un empleado puede ser director de varios empleados. De este director se necesi
ta saber tambin la categora y la fecha de alta como director. El director heredar d
e empleado y adems tendr una asociacin [1..*] con empleado.
- Para todas las clases crearemos dos mtodos, uno para asignar datos a los atribu
tos (como si fuese el constructor), este mtodo tendr tantos parmetros como atributo
s, y otro que se llame obtener que dvvolver un objeto de la misma clase.
Al crear una clase, si se hace doble clic sobre la misma se muestra la ventana d
e creacin de la clase, desde ella podremos teclear el nombre, elegir la visibilid
ad (*public*, *private*, *protected* y *package*) y marcar el tipo de clase (*Is
Abstract* si va a ser una clase abstracta, *Is leaf* si se considera que no pue
de en un futuro ser una especializacin, *Is Active* para indicar si la clase es u
na clase activa). Tambin se puede asignar un caso de uso a la clase.
Si se desean aadir atributos y operaciones a la clase, podemos movernos por las p
estaas *Attributes* y *Operations* y utilizaremos los botones correspondientes pa
ra aadir nuevos elementos, borrarlos o cambiarlos de posicin.
A la hora de aadir atributos se indicar el nombre, la visibilidad, las propiedades
del atributo y el tipo.
- *Is Read Only*. Atributo de solo lectura.
- *Is Static*. Las instancias de este tipo comparten el mismo valor para este at
ributo.
- *Is Leaf*. No esta diseado para permitir que este atributo se redefine en los t
ipos derivados.
- *Is Derived*. Este atributo se calcula a partir de otros atributos, es un atri
buto calculado.
- *Is Ordered*. La coleccin forma una lista sequencial y ordenada.
- *Is Unique*. No hay valores duplicados en la coleccin.
Al asignar un tipo de dato para los atributos, se abre la ventana para elegir el
tipo de dato.
Al crear una operacin se teclea el nombre, la visibilidad y se marca el tipo (se
dejan las opciones por defecto a no ser que se indique otra cosa en el enunciado
), y a continuacin se aaden los parmetros si los tiene. Para ello se pulsa a la pes
taa *Parameters* y al botn *aadir*. En la nueva ventana que aparece se escribe el n
ombre del parmetro, se selecciona el tipo de dato y se marca el tipo de parmetro (
*in*, parmetro de entrada; *inout*, parmetro de entrada-salida; *out*, parmetro de
salida; *return*, si la operacin devuelve un valor de retorno).
Tambin se pueden cambiar las propiedades de la clase desde la pestaa de propiedade
s. Desde aqu se podrn ver, aadir y modificar los atributos, las operaciones, las re
laciones de la clase, la apariencia y la semntica. Cambiaremos las propiedades de
la semntica, sobre todo, para indicar la multiplicidad de la clase cuando tiene
asociaciones.
Para elaborar el primer ejemplo, se crean clase con los atributos y operaciones
siguiendo lo indicado en el apartado. Una vez creadas las clases se crean las re
laciones.
Entre *Empresa* y *Cliente* se crea una asociacin de composicin que va del compues
to (*Empresa*) al componente (*Cliente*), se selecciona la asociacin de la paleta
y se pincha de la clase *Empresa* a la clase *Cliente*, desde el nombre de clas
e origen al nombre de clase destino.
Al crear las asociacin se generan automticamente sus nombres, observa que llevan e
l nombre de la clase con la que se asociacin seguida de una *s*. Observa tambin la
s multiplicidades de la asociacin que aparecen entre *[corchetes]*
La multiplicidad que se ha creado del lado de la clase *Empresa* es [0..1], y de
l lado de la clase *Cliente*, [*]; esto quiere decir que 1 empresa tiene muchos
clientes. Esto se traduce en java a que la clase *Empresa* tendr un *HashSet* de
objetos *Cliente* llamado *clientes* y la clase *Cliente* tendr un objeto de la c
lase *Empresa* llamado *empresas.
Se hace lo mismo entre las clases *Empresa* y *Empleado*. Los nombres de las aso
ciaciones se pueden cambiar para hacer ms legibles el diagrama. Basta con hacer d
os veces clic sobre el nombre en el diagrama, o tambin hacer doble clic en la aso
ciacin para que aparezca la ventana de propiedades de la asociacin y abrir los ele
mentos que componen la asociaicn.
**Nota**. Si una clase va a tener varias asociaciones con otra clase es convenie
nte cambiar los nombres de las asociaciones, pues esos nombres se utilizan al ge
nerar el cdigo java a partir del modelo, y es necesario que no sean iguales para
evitar errores de compilacin.
Para crear las asociacicones de generalizacin entre *Persona-Cliente* y *Persona-
Empleado*, se selecciona la asociacin de generalizacin de la paleta de diseo y se m
arca desde la clase que la herdera a la clase heredada, es decir, de *Cliente* a
*Persona*, y de *Empleado* a *Persona*. En Java la generalizacin crea una herenc
ia, as la clase *Cliente* y *Empleado* ser **extends* de *Persona*.
Se hace lo mismo entre las clases *Director-Empleado*, la clase *Director* hered
a a la clase *Empleado*, con lo que se selecciona la relacin de generalizacin de l
a palta y se arrastra de la clase *Director* a *Empleado*.
Finalmente, se crea la asociacin entre *Director* y *Empleado*. Es una asociacin n
ormal con una multiplicidad de [1..*], es decir, un *Director dirige a muchos em
pleados, y un *Empleado* es dirigido por un director. Se selecciona el smbolo aso
ciacin de la paleta de diseo y se arrastra de *Director* a *Empleado*, en este cas
o, da igual el orden, por defecto, la asociacin que se crea es muchos-muchos, es
decir [*] en ambos sentidos. Es necesario cambiar la multiplicidad de la asociac
in para dejarla en [1..*].
Para cambiar la multiplicidad de una asociacin se selecciona la asociacin y se abr
e la pestaa *Propiedades*, si no est visible se abre el men *Window/Show View/Prope
rties*.
Al lado de la clase *Director* hay que poner la multiplicidad de [1], y al lado
de la clase *Empleado* la de [*]. Dentro de la pestaa de propiedades descatacamao
s los siguientes apartados:
- **General**. En este apartado se puede poner el nombre a la asociacin, y se pue
den ver las clases que asocia.
- **Semantic**, donde se indica la semntica de la asociacin, es decir, el signific
ado y sentido de la asociacin. En este apartado es dodne se cambia la multiplicid
ad. Est formado por la parte donde se indican las propiedades de la asociacin *Ass
ociation*. Y las partes donde se indican las propiedades *Property* del papel qu
e juegan las clases que forman la asociacin, en nuestro caso *Empleado* y *Direct
or*.
Para cambiar la multiplicidad se abrem las propiedades de la asociacin y en la pr
opiedad *Lower* se indica el valor mnimo de la participacin de la clase en la asoc
iacin, y en *Upper* el valor mximo. As, en el ejercicio de la clase *Empleado* en e
sta asociacin tiene de valor mnimo [0] (tambin se poda haber considerado 1) y el val
or mximo [*], ya que un director dirige a 0 o a muchos empleados. Y la clase *Dir
ector* tiene una multiplicidad de valor mnimo [1] y de valor mximo [1], ya que es
un director el que dirige.
Si el modelo se convierte a Java con Eclipse, la clase *Director* tendr un *HashS
et* de objetos *Empleado* llamado *empleados_dirige* y la clase *Empleado* tendr
un objeto de la clase *Director* llamado *directors*.
**Ejemplo 2**. Se desea realizar el anlisis de un sistema de gestin informtica de u
na pequea agencia de viajes que oferta viajes a sus clientes. El sistema debe pro
porcionar una ventana inicial con una serie de mens que abrirn paso al resto de ve
ntanas de la aplicacin que permitirn realizar las siguientes acciones:
- La gestin de las reservas de viajes para realizar reservar, modificar reservas,
consultar reservas, borrar reservas, y generar e imprimir facturas.
- El mantenimiento de datos de clientes, para mantener actualizados los datos se
realizarn operaciones de consulta, altas, bajas y modificaciones de datos de cli
entes, y adems debe permitir generar listado de clientes.
- Mantenimiento de datos de viajes, para mantener actualizados los datos se real
izarn operaciones de consulta, altas, bajas, modificaciones e informes de viajes.
Disponemos de una base de datos donde estn almacenados los datos de los clientes,
los viajes, las reservas, las fechas de viaje, los datos son los siguientes:
- Datos de clientes son: cdigo-cliente, nombre, tlf y direccin.
- Datos de viajes son: cdigo, nombre, plazas y precio.
- Datos de las reservas son: nmero de reserva y estado de la reserva.
- Un cliente puede realizar muchas reservas, y una reserva es de un cliente.
- Igualmente, de un viaje se pueden realizar muchas reservas, y una reserva pert
enecer a un viaje.
- Los viajes se ofertan en varias fechas de viaje, de estas fechas se necesita s
aber la fecha de comienzo y la fecha de fin. Estas fechas pueden ser compartidas
por varios viajes.
- Tambin se cuenta con la informacin de un catlogo de viajes, datos del catlogo son:
cdigo, destino, procedencia, temporada, precio. Los viajes se crean a partir del
catlogo.
**Identifiacin de clases de diseo**.
Para la solucin consideramos los tres tipos distintos de clases de anlisis: *Entit
y*, *Control* y *Boundary*, y as identificamos las siguientes clases.
- Clases de tipo **Entidad**. Sern las clases persistentes asociadas a la BD, con
sideramos:
- Viaje
- Cliente
- Reserva
- Catalogo
- Fechas_Viaje
- Clases de **Control**. Formarn la lgica de la aplicacin, para controlar las opera
ciones que se hacen con los datos de la BD (altas, bajas, modificaciones, consul
tas). Consideramos las siguientes clases:
- OpeViajes
- OpeCliente
- OpeCatalogo
- OpeReservas
- OpeFechas
- Clases **Interfaz**. Lo forman las ventanas de la aplicacin. Consideramos una v
entana inicial la *VentanaPrincipal* con un men que abrir el resto de ventanas de
la aplicacin. Estas ventansa sern para el mantenimeinto de viajes (*VViajes*), par
a la gestin de reservas (*VReservas*), y para la gestin de clientes (*VClientes*).
Estas clases tendrn operaciones como insertar registro, modificar, borrar, lista
r, consultar. Podran ser botonoes que ejecutan operaciones o que abren otras vent
anas.
**Identificaciones de paquetes**.
Finalmente en este ltimo paso agruparemos las clases en paquetes, se crear un paqu
ete para las clases *Entidad*, otro para las clases de *Control* y otro para las
clase *Interfaz*, con el objetivo de separar los datos, la lgica, y la interfaz.
Para elaborar este diagrama primero se crearn los paquetes y a continuacin los dia
gramas de clase de cada paquete.
1. Se crea un modelo nuevo desde el men *File/New/UML Project*.
2. Se crea un diagrama de clases, botn derecho del ratn sobre el proyecto, elige *
Create Representation/Structural Modeling/Class Diagram*. Selecciona el modelo y
fin.
3. En el diseo del diagram de clases se aade primero los paquetes y se ponen los n
ombres. Y a continuacin se aade las clases con sus atributos y operaciones dentro
de cada paquete. Seguidamente se aadene las relacioens y se procede como se hizo
en el ejemplo anterior.
4. Se crea el diagrama de paquetes, botn derecho del ratn sobre el proyecto, se el
ige *Create Representation/Structural Modeling/Package Hierarchy*. Selecciona el
modelo y fin.
5. Aade los paquete al modelo, hay que seleccionar *Add* del apartado *Existing E
lements* de la paleta, para que aparezca la ventana con los elementos que hay ya
creados en el modelo. Se seleccionan los tres paquetes.
6. Por ltimo se aade la relacin entre los paquetes, se selecciona *Import* de la pa
leta y se lleva de la clase que se importa a la importada, es decir, de *Interfa
z* a *Control* y de *Control* a *Entidad*.
5.6. Generacin de cdigo a partir de diagramas de clases
Una vez realizado el modelo, lo que queda es generar las clases en Java.
Para generar cdigo Java en Eclipse es necesario instalarse el plugin *UML to Java
Generator*, se busca desde *Eclipse Marketplace* y se instala. Se marcan los el
ementos, se aceptan las condiciones y se instala.
Una vez instalado el plugin nos posicionamos sobre un modelo ya realizado, pulsa
mos el botn derecho del ratn y en el men contextual se elige *Run As/Acceleo UML to
Java Generation*.
Se muestra la ventana de configuracin de la generacin del proyecto, en esta ventan
a conviene poner un nombre para saber qu proyecto se generar. Se selecciona el mod
elo, se indica cul ser el nombre del proyecto, el nombre de la carpeta para guarda
r los archivos Java y el nombre de la carpeta para guardar las clases. Si se pul
sa la pestaa *Class* se puede seleccionar si se desaea que se generen automticamen
tos los *getters* y *setters*, por defecto aparecen seleccionados. Tambin se pued
e indicar el nombre del autor, la versin para la documentacin. Se pulsa al botn *Ru
n* y se genera el proyecto, que aparecer en el explorador de modelos.
La configuracin para la generacin de cdigo se guarda y queda asociada a un modelo,
con lo cual cuando se va a generar un nuevo proyecto conviene crear una nueva co
nfiguracin pulsando al botn + y seleccionar el modelo, porque si no siempre se lan
zar el mismo proyecto.
El proyecto que se crea en Java es un proyecto con errores, observa las clases d
el proyecto creado aquellas clases que tiene un *HashSet* tienen errore en las ln
eas, es porque no incluye bien los import, para corregir el error se aade *import
java.util.HashSet* en las clases.
5.7. Ingeniera inversa
En el contexto del software, los autores Chikofsky y Cross, establecen que la in
geniera inversa es el proceso de analizar un sistema para crear una representacin
del mismo, pero a un nivel ms elevedao de abstraccin. Por otro lado, Hall establec
e que la ingeniera inversa es un proceso que recorre hacia atrs el ciclo de desarr
ollo de software. Bajo este enfoque, es posible iniciar el proceso de abstraccin
a partir del cdigo fuente y llegar hasta la fase de anlisis, lo cual representa un
flujo inverso al tradicional en el modelo de cascada.
En la prctica se han considerado dos tipos de ingeniera inversa: basada en el cdigo
fuente y basada en el programa ejecutable. En el primer tipo, el cdigo fuente es
t disponible; pero se desconocen aspectos de ms alto nivel, existe una documentacin
pobre o exite documentacin, pero no est actualizada. En el segundo tipo, no exist
e cdigo fuente disponible, as que los esfuerzos se concentra en descubrir el corre
spondiente cdigo fuente.
Ejemplo 1
En este apartado aprenderemos a crear un diagrama de clases a partir de proyecto
s Java ya realizados. Partimos de un proyecto Java creado desde Eclipse. Est form
ado por los paquetes *Interfaz* y *Lgica*. El paquete *interfaz* contiene las ven
tanas de la aplicacin, son clases para mostrar las ventanas y para operar con los
datos. La clase *Principal* es un *extends JFrame*, y para las otras son *exten
ds JDialog*. El paquete *lgica* contiene las clases persistentes *Departamento*
y *Empleado*, y una clase para el tratamiento de excepciones.
Nos fijamos en las clases *Departamento* y *Empleado*, en los atributos y sobre
todo en la relacin entre ellas, el departamento tiene un array de empleados (*pri
vate Empleado [] empleadosdep *), para guardar los empleados de su departamento,
y el empleado tiene un objeto departamento para referenciar el departamento al
que pertenece (*private Departamento dept;*). Estas relaciones entre las clases
se mostrarn luego en el diagram de clases . El cdigo de las clases es el siguiente
(no se incluyen los getters y los setters):
public class Departamento {
private int dept_no;
private String dnombre;
private String loc;
private Empleado [] empleadosdep;
public Departamento(int dept_no, String dnombre, String loc){
this.dept_no = dept_no;
this.dnombre = dnombre;
this.loc = loc;
}
}
public class Empleado {
private int emp_no;
private String nombre;
private String pobla;
private String oficio;
private Double salario;
private Departamento dept;
public Empleado(int emp_no, String nombre, String pobla, String
oficio, Double salario, Departamento dept) {
this.emp_no = emp_no;
this.nombre = nombre;
this.pobla = pobla;
this.oficio = oficio;
this.salario = salario;
this.dept = dept;
}
}
Ejemplo 2
Partimos de un proyecto Java de Eclipse. Est formado por los paquetes *Datos* y *
Proceso*. En el primero tenemos las clases *Alumno* y *Notas* y en el segundo la
clase *Principal* con el mtodo *main()*.
La clase *Alumno* tiene 4 atributos (*dni*, *nombre*, *direccin* y *curso*), un c
onstructor con parmetros y lso mtodos *get* y *set* para los atributos.
La clase *Notas* tiene 3 atributos (*dni*, *asignatura* y *nota*), un constructo
r con parmetros y los mtodos *get* y *set* para los atributos.
El cdigo de la clase *Principal* es el siguiente:
package Proceso;
import Datos.Alumno;
import Datos.Notas;
public class Principal {
public static void main(String[] args) {
Alumno alum = new Alumno("12345678A", "JUAN", "BERROCALE
JO", "1DAM");
Notas nota = new Notas(alum.getDni(), "ENTORNOS DE DESAR
ROLLO", 7);
System.out.println(nota.getDni() + "*" + nota.getAsignat
ura() + "*" + nota.getNota());
}
}
En Eclipse hay varios plugins que nos permiten generar diagramas de clases con s
us relaciones y diagramas de secuencia. Algunos de estos plugins son *ObjectAid
UML y *eUML2*.
1. Pulsar en la opcin de men *Help/Install New Software*.
2. Pulsar en el botn *Add*, en *Name* escribir un nombre, por ejemplo *OBJECT AID
* y en *Location* escribimos la URL *http://www.objectaid.net/update*, pulsamos
el botn Ok.
3. A continuacin seleccionar *ObjectAid UML Explorer* y pulsar el botn *Next*, se
muestran los detalles de la instalacin, pulsar de nuevo en el botn *Next*. A conti
nuacin aceptar los trminos de licencia y se pulsa el botn *Finish*.
4. Se muestra una ventana avisando de que estamos instalando software que contie
ne contenido sin firmar, pulsamos el botn OK para continuar. Finalmente el proces
o de instalacin solicita que reiniciemos.
Para hacer uso del plugin y crear el diagrama de clases de nuestro proyecto Ecli
pse seguimos estos pasos:
1. Pulsamos con el botn derecho del ratn sobre el proyecto (o sobre una carpeta o
paquete) y seleccionamos *New/Other/ObjectAid UML Diagram/Class Diagram y pulsam
os el botn *Next*.
2. Escribimos el nombre, marcamos las casillas para que se muesatren todas la re
lacionesa y pulsamos el botn *Finish*. En el proyecto (o donde hayamos creado el
diagrama se muesatra un fichero con la extensin ucls.
3. En el ejemplo se ha creado el fichero *Diagrama de clases.ucls*. A continuacin
hacemos doble clic sobre el fichero creado para que se muestre el rea de edicin y
arrastramos las clases del proyecto. En el diagrama se muestran de forma automti
ca las relacionesa entre las clases.
Para poder generar el diagrama de secuencia necesitamos obtener una licencia. De
sde la URL de ObjectAID (http://www.objectaid.com/install-license), se muestran
los pasos a seguir para obtener una gratuita y configurarla en el entorno Eclips
e. La licencia gratuita tiene una duracin de un mes.
Una vez que tenemos configurada la licencia en Eclipse, pulsamos en el botn derec
ho del ratn sobre el proyecto y seleccionamos *New/Other/ObjectAID UML Diagram/Se
quence Diagram* y pulsamos el botn *Next*. Escribimos el nombre y pulsamos el botn
*Finish*. Se habr creado un nuevo fichero con la extensin *useq*.
A continuacin arrastramos la clase *Principal* a la zona de edicin del diagrama de
secuencia. Despus arrastramos el mtodo *main()* a la lnea de vida de la clase *Pri
ncipal*.
Por ltimo, pulsamos con el botn derecho del ratn sobre el mtodo *main()* y seleccion
amos *Add Called Operations*, se generarn las llamadas a los mtodos.
Para instalar el plugin *eUML2* seguimos los siguientes pasos.
1. Desde la URL http://www.soyatec.com/euml2/installation/ descargamos una licen
cia de evaluacin para probar eUML2. Para Kepler descargamos el fichero *eUML2-Stu
dio-Edition-...+dependencies_for_eclipse.zip*, lo guardamos en la carpeta C:/Plu
gin.
2. Pulsar en la opcin de men *Help/Install New Software*. A continuacin se pulsa el
botn *Add*, seguidamente se pulsa en *Archive* para localizar el fichero que se
ha descargado. Se pulsa el botn OK.
3. Seleccionar todos los elementos y pulsar el botn *Next*, se muestran los detal
les de la instalacin, pulsar de nuevo el botn *Next*. Aceptar los trminos de la lic
encia y pulsar el botn *Finish*. Comienza el proceso de instalacin (se necesita co
nexin a Internet). Al finalizar nos pide reiniciar Eclipse para que los cambios t
engan efecto.
Para aplicar ingenieria inversa la proyecto Eclipse pulsamos sobre l con el botn d
erecho del ratn y seleccionamos la opcin *eUML2/Reverse engineering*; se abre una
nueva ventana desde la que eleigmos el proyecto al que vamos a aplicar ingenieri
a inversa. Dejamos las opciones por defecto y pulsamos el botn *Finish*. A contin
uacin se abre una ventanita que nos pide informacin, pulsamos OK.
Despus de este proceso se habrn insertado en los ficheros Java las anotaciones (de
ntro de los comentarios) necesarias para generar los diagramas. La opcin *Clena*
elimina todas las anotaciones.
Para crear el diagrama de clases seguimos los siguientes pasos:
1. Pulsar con el botn derecho del ratn sobre el paquete y seleccionar *eUML2/Class
diagram editor*, en la siguiente pantalla que aparece marcamos las tres opcione
s para que se muestren todas las relaciones y pulsamos *OK*.
2. A cotninuacin seleccionamos las clases del paquete y pulsamos el botn *OK*. Aut
omticamente se crea un fichero con el nombre del paquete con la extensin *.ucd*, l
o guardamos.
3. Se genera el diagrama con las clases seleccionadas. Si las clases no estn rela
cionadas no se muestra ninguna relacin en el diagrama. Arrastramos la clase *Prin
cipal* para formar el diagrama.
Para crear el diagrama de secuencia seguimos los siguientes pasos:
1. Pulsamos con el botn derecho del ratn sobre el mtodo cuyos mensajes queramos mos
trar en el diagrama, seleccionamos *eUML2/Generate sequence diagram editor*.
2. En la siguiente ventana seleccionamos los mensajes que queremos mostrar en l y
pulsamos *OK*.
3. Automticamente se generar el diagrama. Se crea un nuevo fichero, en este caso c
on la extensin *usd* que contiene el diagrama, lo guardamos.