Mapeo de relaciones entre clases en un diagrama uml y Java



Descargar 427,04 Kb.
Página4/4
Fecha de conversión02.10.2017
Tamaño427,04 Kb.
1   2   3   4

this.owner = owner;

}

public Advertiser getOwner ( ) {



return owner;

}

Ejemplo de asociación unidireccional con multiplicidad mayor a uno:

Advertiser

Account

1

*


public class Advertiser {

private Set accounts;

private Account account;

public Advertiser ( ) {



accounts = new HashSet ( );

}

public void addAccount ( Account a ){



accounts.add (a);

a.setOwner (this);

}

public void removeAccount (Account a){



accounts.remove (a);

a.setOwner (null);

}}



public class Account {

private Advertiser owner;

public void setOwner (Advertiser

newOwner) {

if (owner != newOwner) {

Advertiser old = owner;

owner = newOwner;

if (newOwner != null)

newOwner.addAccount (this);

if (oldOwner != null )

oldOwner.removeAccount(this);

}}


Ejemplo de asociaciones múltiples entre dos clases:





En este ejemplo al haber dos asociaciones bidireccionales entre Persona y Compañía, existe una ambigüedad en la traducción UML-Java, ya que en lugar de hacer corresponder empleado-empleador y acción-accionista podría hacerlo erróneamente entre empleador-accionista y entre empleado-acción. Este mismo problema aparece cuando se tienen dos atributos definidos en una misma clase y en la otra aparece sólo uno: No se puede saber si existen dos asociaciones y sólo una es bidireccional o y si existen tres asociaciones unidireccionales y ninguna bidireccional. En caso que el nombre de los atributos en Java coincidan con los nombres de roles UML o de asociaciones, la ambigüedad deja de existir, por lo que el problema se resuelve si se tiene un modelo UML de referencia.
Dependencia
Es el concepto con definición más vaga e imprecisa de UML.

Es una forma de asociación que especifica algún tipo de dependencia entre dos clases, donde un cambio en la clase de la cual se depende puede afectar a la clase dependiente, pero no necesariamente a la inversa. En UML se representa como una asociación pero, en lugar de usar una línea sólida se utiliza una línea punteada. Puede agregarse una flecha para indicar dependencia asimétrica.

La forma más común de dependencia es la conexión entre una clase que usa referencias a objetos de otra clase como parámetros de un método de la misma. En la siguiente figura se observa un conjunto de clases extraídas de un sistema que maneja la asignación de estudiantes y profesores a cursos en una universidad. La figura muestra la dependencia de la clase CourseSchedule (planificación de cursos) con respecto a Course, debido a que Course se usa como argumento en los métodos add y remove de CourseSchedule.

Si en el diagrama de clases se suministra la signatura completa de un método, como en el caso de la figura, no es necesario indicar la relación de dependencia puesto que, el uso de una clase por otra está implícito en la signatura.



También es común encontrar una relación de dependencia entre dos clases Java, donde en una de ella se utilizan variables locales (o campos) que son referencias a objetos de la clase de la cual se depende, además de aquellos casos donde se referencia a un método static de otra clase o, en métodos que retornan referencias a objetos de otras clases.
Otro ejemplo:

Clases de asociación
Una clase de asociación se caracteriza por ser a la vez una asociación y una clase, lo que permite añadir atributos y operaciones a la asociación. En Java, al igual que las asociaciones, no es posible implementar una clase de asociación como tal.

Las asociaciones con multiplicidad mayor a uno indican que una clase “fuente” está conectada a muchas instancias de una clase “objetivo” pero el diagrama de clases UML no muestra qué clase de contenedores se usan para representar dicha asociación. En la figura, se muestra un ejemplo del uso de una clase de asociación. En el diagrama de clases UML aparece una clase normal conectada a una clase de asociación mediante una línea punteada. Un programador Java interpreta que la clase “fuente” en realidad contiene una referencia a la clase de asociación, que a su vez contiene referencias a objetos de la clase “objetivo”. (en este caso Addres tiene una referencia a un Vector de String donde cada una de los String del mismo, representa una línea con una de las posibles direcciones postales de una persona).





Otro ejemplo: Se usa clase de asociación para representar la compra (purchase) de un libro (Book) por un comprador (Customer).



public class Book extends Object {

// Data attributes

private String title;

// Association attributes

public purchase purchaseOfCust;

// Default constructor

public Book() {

// Start user code section

// End user code section

} // default constructor Book

// Methods


// Do not delete this line -- regeneration end marker

// Attribute accessors

public String getTitle() {

return title;

}

public void setTitle(String title_) {



title = title_;

}


// Association accessors

public purchase getPurchaseOfCust() {

return purchaseOfCust;

}

} // class Book


public class Customer extends Object {

// Data attributes

private String name;

// Association attributes

public Vector purchaseOfBookSet;

// Default constructor

public Customer() {

purchaseOfBookSet = new Vector();

// Start user code section

// End user code section

} // default constructor Customer

// Methods


// Do not delete this line -- regeneration end marker

    // Attribute accessors

public String getName() {

return name;

}

public void setName(String name_) {



name = name_;

}


// Association accessors

public Vector getPurchaseOfBookSet() {

return purchaseOfBookSet;

}

} // class Customer


public class purchase extends Object {

// Data attributes

private String date;

// Association attributes

public Customer cust;

public Book book;

// Default constructor

public purchase(Customer cust_, Book book_) {

cust = cust_;

book = book_;

cust.purchaseOfBookSet.addElement(this);

book.purchaseOfCust = this;

// Start user code section

// End user code section

} // default constructor purchase

// Methods


// Do not delete this line -- regeneration end marker

    // Attribute accessors

public String getDate() {

return date;

}

public void setDate(String date_) {



date = date_;

}


// Association accessors

public Customer getCust() {

return cust;

}

public Book getBook() {



return book;

}

} // class purchase


Como puede observarse, no es posible diferenciar la implementación Java de una clase de asociación de la obtenida al implementar asociaciones normales. No puede asegurarse que es una clase de asociación y no dos asociaciones binarias entre dos clases.
Calificadores de una asociación
Son utilizados cuando la asociación es implementada a través de algún tipo de clave o índice, (por ejemplo, cuando se accede al objeto real que está al otro lado de la asociación, mediante un índice de un diccionario, tabla o base de datos) en lugar de hacerlo mediante una referencia Java normal.
Ejemplo:

Para un determinado estudiante y un dado nombre de examen, se puede acceder al puntaje alcanzado por el estudiante en dicho examen.




Para implementar la asociación podría utilizarse un diccionario (Por ejemplo usando HashTable, definida en Java):

class Student { HashTable scores;….}
Otro ejemplo:


public class Customer {

// atributos de los datos

private String name;

// atributos de la asociación

public Hashtable bookSet;

// Default constructor

public Customer() {

bookSet = new Hashtable();

//…


}

//...


// métodos de acceso a los atributos

public String getName() {

return name;

}

public void setName(String name_) {



name = name_;

}

// métodos de acceso para la asociación



public Vector getBookSet(String bookID_) {

Object object = bookSet.get(bookID_);

if (object != null)

return ((Vector) object);

return null;

}

public void addBook(String bookID_, Book book_) {



if (book_ == null)

return;


// si la asociación cualificada tiene multiplicidad mayor a

// 1 debe suministrar métodos hashCode y equals para

// bookID (cualificador) para el uso de java.util.Hashtable.

Vector vector = (Vector) bookSet.get(bookID_);

if (vector == null) {

vector = new Vector();

bookSet.put(bookID_, vector);

}

vector.addElement(book_);



}

public void removeBook(String bookID_, Book book_) {

if (book_ == null)

return;


Vector vector = (Vector) bookSet.get(bookID_);

if (vector != null)

vector.removeElement(book_);}} // class Customer
Agregación
Es una forma especial de asociación asimétrica que connota una relación “todo/parte”(o entre todo (también llamado “agregado”) y parte se da una relación de tipo “tiene un/una”); donde el “todo” está a un nivel conceptualmente superior a la “parte”, a diferencia de la asociación, en que ambas clases están al mismo nivel conceptual.
Ejemplo: Auto y conductor
class Car {

Driver driver;

public setDriver( Driver driver) {

this.driver = driver;

driver.drive( this ) ;

}}

class Driver {

Car car;

public drive(Car car) {

this.car = car;

}}

Puede notarse que la implementación es indistinguible de aquélla de la asociación. En el libro de Robert Martin no se recomienda su uso para el caso de implementar las clases en Java.


Composición
Es una forma asociación simétrica que connota una relación “todo/parte” en la cual la remoción del conjunto (también llamado “compuesto”) implica la eliminación (si es la decisión del “todo”) de las partes componentes y en la cual la “parte” puede pertenecer a un solo conjunto a la vez (aunque el “todo” puede transferir la propiedad de la “parte” a otro objeto, el cual pasará a ser responsable de su tiempo de vida).
Ejemplo: Auto y Motor
class Car {

private Engine engine = New Engine( this ) ;

}

class Engine {

Car car = null ;

public Engine(Car car) {

this.car = car;

}}
Nuevamente, al igual que para la relación de agregación, la implementación, es indistinguible de la asociación, aún cuando en UML representan conceptos diferentes, por tanto, cualquier tipo de representación sufrirá de una pérdida de información e introduce una discontinuidad entre diseño e implementación. En el proyecto de fin de carrera de Belén Criado Sánchez se afirma que la diferencia entre composición es a menudo un asunto de gusto más que una diferencia semántica y que la composición expresa que las partes están físicamente contenidas en el todo y que esto es imposible de implementar en Java puesto que los atributos de una clase son sólo referencias o punteros a objetos de otra clase, nunca es un valor contenido físicamente.


En Java la destrucción de objetos ocurre “entre bastidores” a cargo del recolector de basura (garbage collector), de forma tal que, muy rara vez se maneja el tiempo de vida de un objeto; esta es una de las razones por las cuales es infrecuente el uso de la relación de composición (y la de agregación) para describir programas en Java.
Otro ejemplo: Aquí la composición es usada para indicar la clonación (en su forma “deep copy”) de sus componentes, para impedir que los usuarios de una clase cambien los componentes de un objeto sin usar métodos del contenedor. En este ejemplo se tiene una clase que representa direcciones completas de personas (Address) que contiene muchos String, cada cadena contiene una línea de la dirección completa. Cuando se hace una copia de la dirección se desea que la copia cambie independientemente del original.

Generalización
La generalización es utilizada para construir jerarquías de clases. Aunque es un concepto más abstracto, también suele utilizarse la palabra herencia para referirse a la generalización. En la figura se ve una clase concreta RealPerson que hereda (extends) de una clase abstracta (representada en UML con un nombre escrito en itálica) Person.


En UML las flechas siempre apuntan en un sentido que está relacionado con la dependencia indicada en el código fuente: puesto que la clase RealPerson menciona a la clase Person en su declaración, en UML la flecha apunta desde dicha subclase a la clase base.


Realización
UML utiliza una notación parecida a la usada en el caso de relación de generalización/especialización para indicar otra relación de supertipos a subtipos: el de una interface con una clase que la implementa. En este caso se utiliza una línea

punteada, con la misma punta de flecha que la usada para indicar una relación de herencia.





En Java la realización se traslada directamente usando la palabra clave implements.


Otro ejemplo (herencia múltiple usando extensión e implementación de interfaces):


public interface Receiver {

...

// Métodos



public void receive();

} // interface Receiver


public interface Transmitter {

...


// Métodos

public void transmit();

} // interface Transmitter
public interface Radio extends Transmitter, Receiver {

...


// Métodos

public int tune();

} // interface Radio
public class Stereo extends ElectronicDevice implements Radio {

...


// Default constructor

public Stereo() {

// …

} // default constructor Stereo



...

// Métodos-Implementación

public void receive() {…

}


public void transmit() {…

}

public int tune() {…



}

...


} // class Stereo
Referencias:


  • UML for Java Programmers – Robert C. Martin (Prentice Hall)

  • http://www.auldenfire.com/aitpncc/resources/uml.shtml. Último acceso: 13/11/2008.

  • http://fag.grm.hia.no/ikt403/year2007/slides/UML-ppt/2007-06-ClassDiagrams.ppt#54. Último acceso: 13/11/2008.

  • http://www.ifi.uio.no/in219/verktoy/doc/html/doc/code_gens/java/. Último acceso: 13/11/2008.

  • “Mapping UML Associations into Java Code”, en Journal of Object Technology, vol. 2, no. 5, September-October 2003, pp. 135-162.

  • Roundtrip engineering for classes: Mapping between UML Diagram and Java structures based on Poseidon for UML and the Eclipse Platform. MSc. Thesis de Sunay Yaldiz, Technical University Hamburg-Harburg, Alemania

  • Belén Criado Sánchez. Verificación de la implementación de asociaciones UML en Java. Ingeniería Informática, julio 2001, Proyecto de fin de carrera

  • Entrelazamiento de los aspectos estático y dinámico en las asociaciones UML, Tesis doctoral Gonzalo Fuster Génova, Universidad Carlos III de Madrid, 2003
1   2   3   4


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal