Diagrama UML

4
UML estructural
Tanto para AOO como para DOO se utilizan los conceptos y las notaciones, esencialmente grficas, de UML (Unified Modeling Language). En una primera clasificacin de la notacin UML se puede dividir en varias vistas. Una vista es un subconjunto de construcciones de UML que representan un aspecto del sistema: UML estructural logico: describe la estructura lgica de los elementos del sistema y sus relaciones. Sus conceptos principales son las clases, los paquetes y los casos de uso. Esta vista incluye los diagramas de clases y los diagramas de casos de uso. UML Dinmico: describe las interacciones entre los objetos con el tiempo. Las vistas de comportamiento dinmico incluyen los diagramas de interaccin, las mquinas de estado y los diagramas de actividades Implementacin: describe la estructura fisica del SW en cuanto a los componentes de que consta y su ubicacin. Est formada por los diagramas de componentes y de despliegue. Este captulo se centrar en el UML estructural lgico. Se llama as por que muestra todas las relaciones posibles a lo largo del tiempo y no las que son vlidas en un cierto momento. UML estructural lgico est constituido por:
Diagramas de clases
Dpto. Electrnica, Automtica e Informtica Industrial
83
Captulo 4: UML estructural
Apuntes de Informtica Industrial
Diagrama de casos de uso 4.1 OMG y UML

OMG (Object Managment Group), creada en 1989, es una organizacin no lucrativa en la que participan ms de 800 empresas de SW, HW, consultoras, ... Su objetivo es la elaboracin de estndares para la Programacin Orientada a Objetos. Slo se dedican a realizar documentos, no su implementacin. Por ejemplo, CORBA (objetos distribuidos en la Red) es un estndar (documentos) de la OMG. Posteriormente, existen empresas que realizan su implementacin. En el caso de CORBA, existen paquetes como MICO que son componentes que dan soporte a los servicios establecidos en la documentacin. UML ha sido propuesto por OMG a ISO para que sea un estndar. UML es una cierta unificacin de mtodos anteriores como: OMT de Rumbaugh OOSE de Jacobson El mtodo de Booch. En 1997 aparece UML V1.0 presentado por la OMG.
4.2 Clases en UML

Las clases se representan por un rectngulo dividido en tres compartimentos: nombre de la clase, atributos y servicios. En el apartado del nombre, en la parte superior, se puede indicar un estereotipo, tales como <<anlisis>>, <<diseo>>, ... El nombre de la clase ser un sustantivo y empezar por <<analisis>> Im agenEsperm atozoides mayscula. Debajo del nombre se puede encontrar comentarios optativos entre llaves, { }. Cada atribuyo tiene un nombre o identificador y un tipo. Un atributo se define de la siguiente forma:
Visibilidad nombre_atributo : tipo_atributo = valor inicial {`otras propiedades }
84
La visibilidad hace referencia a si el atributo es pblico, protegido o privado. UML emplea los smbolos +, # y para indicar si es RespuestaFrecuencia pblico, protegido o privado respectivamente1. El nombre frecuenci aInicio : float frecuenci aFi n : fl oat del atributo es un sustantivo y empieza en minsculas. interval oFrec : float Seguidamente aparecer el tipo de atributo ( float, char, int, modulo : vector<double> ...). Opcionalmente puede aparecer el valor inicial del argumento : vector<double> atributo y otras propiedades colocadas entre los signos de parntesis. Las especificacin de las operaciones en UML tienen la siguiente sintaxis:
Visibilidad nombre_servicio (lista de parmetros):tipo de retorno {`otras propiedades}`
El nombre del servicio emplear un verbo con un sustantivo. La primera letra se escribir en minscula. Entre parntesis, (), aparecern los parmetros del servicio, siguiendo para cada uno de ellos, la regla sobre los atributos. Despus aparecer el tipo de retorno y opcionalmente otras propiedades entre llaves. El usuario puede crear otros compartimentos para dar informacin adicional como excepciones, requisitos, etc. Ejemplo 4.1 Realizar la implementacin en C++ de la siguiente descripcin UML referente a la clase Esfera.
Esfera radio_esfera : float = 2.0 getRadio() : float setRadio(radio : float) : void
}; #endif
CdgEspermatozoide
cdg_x : float cdg_y : float getCdg_y( : voi d) : float getCdg_x( : voi d) : float setCdg_y(cdg : fl oat) : void setCdg_x(cdg : fl oat) : void
#ifndef _INC_ESFERA_ #define _INC_ESFERA_ class Esfera { private: float radio_esfera; public: Esfera() {this->radio_esfera = 2.0f;} float getRadio() {return (this->radio_esfera);} void setRadio(float radio) {this->radio_esfera=radio;}
4.2.1 Variantes en el concepto de clases UML soporta diferentes tipos de clases que pueden ser implementadas o no por el lenguaje de programacin.
Rational Rose emplea los siguientes iconos para sealar la visibilidad del atributo o del . El candado significa privado, la llave es protegido y la goma que es pblico.
servicio:
85
4.2.1.1 Clases parametrizadas o contenedores Las clases parametrizadas son unas clases que son empleadas para crear una familia de otra clase. Estas clases son un tipo de contenedor, son conocidas tambin como templete. No todos los lenguajes soportan los templetes. Por ejemplo, en ANSI C++ existe el paquete STL (Standar Templete Library), mientras que JAVA no soporta este tipo de clases. La biblioteca contenedora STL permite a los programadores desarrollar aplicaciones con contenedores estndar, tales como pilas, listas, colas de espera, as como manipular el contenido de dichos contenedores de diversas maneras. De esta forma, los desarrolladores hacen uso de servicios de alta calidad sobre componentes muy utilizados en casi todas las aplicaciones. Por ejemplo, la necesidad de mantener una lista dinmica de objetos es algo muy habitual. Al emplear los templetes, los desarrolladores no deben de implementar dichos servicios, slo deben de saber utilizarlos. Por tanto, una clase parametrizada permite reutilizar el cdigo. Las clases parametrizadas son slo plantillas de contenedores (vector, lista, rboles, ...). A las clases que definen un contenedor de un tipo especfico, se las llama clases instanciadas, esto es, las clases instanciadas son instancias de clases parametrizadas. UML utiliza los signos de desigualdad, <>, para definir el tipo especfico acompaado con el nombre del contenedor. Ejemplo 4.2 Se desea realizar una aplicacin para un pocket sobre los pasajeros de un vuelo. Plantese bajo los frameworks de ANSI C++ o sobre MFC. En jerarqua a dos niveles se plantea las siguientes caractersticas: 1. Mantener una lista de pasajeros asociados a un vuelo a. El sistema debe de tener de cada pasajero, el nombre, el DNI y el asiento. b. El sistema debe dar el nmero total de pasajeros, de asientos ocupados y asientos libres.
c. El sistema debe de listar los datos de todos los pasajeros. d. El sistema debe de aadir datos sobre los pasajeros. Los trminos para el glosario seran: Pasajero, Vuelo, Asiento, DNI, Nombre, .... La lista de evento-actor-objetivo estara constituida por:
Evento Introducir datos pasajero Visualizar datos pasajero Ocupacin del vuelo Actor Azafat@ Azafat@ Azafat@ Objetivo Formar la base de datos del pasaje Verificar los datos de un pasajero Obtener datos de ocupacin del vuelo
86
El caso de uso sera la Lista PasajeroVuelo. Se podra considerar que los datos pudieran venir de una base de datos, en versiones futuras, y ser cargadas a travs de algun tipo de conexin al pocket. Establecindose el siguiente diagrama de caso de uso y arquitectura de la aplicacin.
GUI
ListaPasajerosVuelo Azafat@ <<include>>
ListaPasajeroVuelo Dominio
BaseDatos
AccesoBaseDatosPasajero
La primera tarea del AOO sera la construccin del modelo del dominio, ste podra ser:
<<Analisis>> Pasajero contiene 1 n
(from Vuelo)
<<Analisis>> Vuelo numTotalAsiento IDVuelo
tiene una 1 1
<<Analisis>> ListaPasajeros
(from Vuelo)
numDNI nombre asiento
Se ha aadido el estereotipo <<Analisis>> con el objeto de indicar de forma explcita el carcter de clases conceptuales. Se deja al lector que haga el DSS y algn contrato de operacin. En un primer diseo se puede emplear ANSI C++ o las MFC para las clases instanciadas. Si se utiliza el paqueta estndar, se emplearn las std::string para los atributos de tiras de caracteres y las STL std::vector para el contenedor requerido. Para una mejor compresin de las clases parametrizadas slo se muestra la solucin lgica de una parte de la lista de Pasajeros. Un primer esbozo queda reflejado en el siguiente diagrama de clase de diseo, DCD:
87
ListaPasajeros getDatoPasajero(numPasajero : unsigned) : Pasajero iniciarLista( : void) : void <<const>> darNumeroPasajeros( : void) : int setDatosPasajero( : const Pasajero) : void
Clase instanciada de STL vector
vector<Pasajero>
Pasajero numDNI : unsigned long nombre : std::string <<const>> getDNI( : void) : unsigned long setDNI(DNI : unsigned long) : void getNombre( : void) : std::string& setNombre(nom : const char*) : void
Cuya implementacin en C++ ser:

#ifndef _PASAJERO_INC_ #define _PASAJERO_INC_ #include <string> class Pasajero { public: void setNombre(const char *nom) {nombre = nom;} std::string & getNombre( void ) {return nombre;} void setDNI(unsigned long DNI) {numDNI=DNI;} unsigned long getDNI( void ) const {return (numDNI);} private: std::string nombre; unsigned long numDNI; }; #ifndef _INC_LISTA_PASAJEROS #define _INC_LISTA_PASAJEROS #include <vector> #include "Pasajero.h";
class ListaPasajeros { public: void setDatosPasajero (const Pasajero p1) {laListaPasajeros.push_back(p1);} int darNumeroPasajeros ( void ) const { return laListaPasajeros.size(); } void iniciarLista ( void ) { iteradorPasaje = laListaPasajeros.begin();} Pasajero getDatoPasajero( unsigned numPasajero ) { return (*(iteradorPasaje + numPasajero)); } private: std::vector<Pasajero> laListaPasajeros; std::vector<Pasajero>::iterator iteradorPasaje; }; #endif
#endif
Ntese los tres tipos de clase mostrados: conceptuales, de diseo y de implementacin. En el caso de emplear el framework MFC, se emplearn las CString para las frases y se utilizar para realizar la lista, la clase parametrizada CList:
88

#ifndef _INC_PASAJEROMFC_ #define _INC_PASAJEROMFC_ #include <afx.h> class PasajeroMFC { public: void setNombre(const char *nom) {nombre = nom;} CString & getNombre( void ) {return nombre;} void setDNI(unsigned long DNI) {numDNI=DNI;} unsigned long getDNI( void ) const {return (numDNI);} private: CString nombre; unsigned long numDNI; }; #endif

#ifndef _INC_LISTA_PASAJEROS #define _INC_LISTA_PASAJEROS #include <afxtempl.h> #include "PasajeroMFC.h"; class ListaPasajerosMFC { public: void setDatosPasajero (const PasajeroMFC p1) {laListaPasajeros.AddTail(p1);} int darNumeroPasajeros ( void ) const { return laListaPasajeros.GetCount(); } void iniciarLista ( void ) { pos = laListaPasajeros.GetHeadPosition();} PasajeroMFC getDatoPasajero( void ) { return laListaPasajeros.GetNext(pos); } private: CList<PasajeroMFC, PasajeroMFC> laListaPasajeros; POSITION pos; }; #endif
Clase parametrizada CList de las MFCs ListaPasajerosMFC

getDatoPasajero() iniciarLista() <<const>> darNumeroPasajeros() setDatosPasajero() CList<PasajeroMFC,PasajeroMFC>
PasajeroMFC
numDNI : unsigned long nombre : CString <<const>> getDNI() setDNI() getNombre() setNombre()
En la pgina web de la asignatura encontrar los fuentes de este ejemplo. 4.2.1.2 Interfaces Una interfaz especifica ciertas operaciones de algunos elementos del paquete que son visibles fuera del mismo. No necesita especificar todas las operaciones que soporta el paquete, por lo que el paquete podra incluir varias interfaces diferentes. Una interfaz se define en un diagrama de clases utilizando un rectngulo, como el de icono de clase, pero con el estereotipo de <<interface>> en la divisin del nombre
89
de la clase. No tiene atributos, por tanto, el icono slo tiene dos divisiones. En Rational Rose tambin se representa por un crculo. El sentido de las interfases se trata en la relacin entre cliente servidor. Si un paquete est especializado en algunas tareas o servicios, se le dota de un interfaz para que los clientes pidan ese trabajo. Las modificaciones internas dentro del paquete no sern transmitidas a los clientes de estos servicios. Estos aspectos se vern con mayor detenimiento en el captulo de diseo con patrones. En C++ se emplean las clases abstractas para implementar los interfaces. En Java y en C# existe la palabra clave interface. Ejemplo 4.3 Definir un interfaz para la visualizacin de los diagramas de Bode en la aplicacin de respuesta en frecuencia de los circuitos electrnicos. Un buen diseo debera de independizar la aplicacin de la visualizacin del diagrama de Bode. En el mercado existen distintos componentes para realizar un ploteado de una grfica X-Y. Se ha localizado un componente gratuito llamado NTGRAPH2. Sin embargo, en el futuro se podra optar por otro tipo de componente. Para evitar las fluctuaciones e inestabilidades de este servicio, se define un interfaz estable a este servicio. El diagrama de paquetes quedara:
ActiveX-Bode
<<interface>> IDiagramaBode pintaPlotXY()
VistaFrecuencia ELAI
NTGraph
El DCD resultante de aplicar diversos patrones GoF muestra la solucin lgica del problema:
www.codeproject.com
90
CRespFrMFCDlg
<<interface>> IAdaptadorVisualizar <<abstract>> InicializarPlotXY() <<abstract>> PintarPlotXY() <<static>> factoriaVisualizadores()
Interfaz estable
Cliente del paquete Visualizador
Solucin tecnolgica AdaptadorVisualCNTGraph AdaptadorVisualCNTGraph() <<virtual>> InicializarPlotXY() <<virtual>> PintarPlotXY() CNTGraph
Constructor privado Mtodo de Fabricacion (GoF)
Ejemplo 4.4 Realizar un paquete que sea capaz de ocultar el uso de framework para el manejo de tiras de caracteres. Emplese las MFC y ANSI C++.
<<interface>> INombre
(f rom Interf eseFrases)
AplicacionCliente
<<abstract>> setNombre() <<abstract>> getNombre() <<static>> factoriaObjetos()
Nombre
<<interface>> INombre <<abstract>> setNombre() <<abstract>> getNombre()
STDNombre <<virtual>> setNombre() <<virtual>> getNombre() STDNombre()
CNombre elNombre[80] : char <<virtual>> setNombre() <<virtual>> getNombre() CNombre()
MFCNombre
(from M etodoFabriaci on)
<<virtual>> setNombre() <<virtual>> getNombre() MFCNombre()
91
#ifndef _INOMBRE_INC_ #define _INOMBRE_INC_ enum Plataforma{ESTANDAR_STL, ESTILO_C, CADENA_MFC}; class INombre { public: virtual void setNombre (const char *) = 0; virtual const char * getNombre () = 0; //Factoria de objetos static INombre *factoriaObjetos (enum Plataforma); }; #endif
#ifndef _INC_CNOMBRE_ #define _INC_CNOMBRE_ #include <string> #include "INombre.h" class CNombre : public INombre { public: virtual void setNombre(const char *cadena) { strcpy (elNombre, cadena); } virtual const char * getNombre (void) { return (elNombre);} private: char elNombre[80]; }; #endif
#ifndef _INC_MFCNOMBRE_ #define _INC_MFCNOMBRE_ #include <afx.h> #include "INombre.h" class MFCNombre : public INombre { public: virtual void setNombre(const char *cadena) { elNombre=cadena; } virtual const char * getNombre (void) { return (elNombre);} private: CString elNombre; }; #endif
#ifndef _INC_STDNOMBRE_
#define _INC_STDNOMBRE_ #include <string> #include "INombre.h" class STDNombre : public INombre { public: virtual void setNombre(const char *cadena) { elNombre = cadena; } virtual const char * getNombre (void) { return (elNombre.c_str());} private: std::string elNombre; }; #endif
#include #include #include #include
<iostream> "../includes/STDNombre.h" "../includes/CNombre.h" "../includes/MFCNombre.h"
//Mtodo nico para producir los objetos nombres INombre* INombre::factoriaObjetos(enum Plataforma tipo) { if(tipo == ESTANDAR_STL) return new STDNombre; else if(tipo == ESTILO_C) return new CNombre; else if(tipo == CADENA_MFC) return new MFCNombre; else return NULL; } using namespace std; int main ( void ) { INombre *pNombre1 = INombre::factoriaObjetos(ESTANDAR_STL); INombre *pNombre2 = INombre::factoriaObjetos(ESTILO_C); INombre *pNombre3 = INombre::factoriaObjetos(CADENA_MFC); pNombre1->setNombre("Manolo Gonzalez"); pNombre2->setNombre("Pedro Lopez"); pNombre3->setNombre("Ana Rodriguez"); cout << pNombre1->getNombre() << endl; cout << pNombre2->getNombre() << endl; cout << pNombre3->getNombre() << endl;
delete pNombre1, pNombre2, pNombre3; return 0; }
Se recuerda que las clases abstractas en C++ carecen de instancias.
92
4.3 Representacin de los objetos

Se representa parecido a una clase, indicando los valores instanciados de los atributos. El nombre del objeto, el cual es opcional, va seguido de : y el nombre de la clase, todo ello subrayado. En general, se suele omitir el tipo de los atributos, as como el comportamiento de los servicios, porque ambos se conocen gracias a la especificacin de la clase.
Fernandez : Al umno
Los objetos estn reflejados en los diagramas de interaccin. stos aparecen en artefactos que describan la dinmica de la aplicacin. Por tanto, se vern en el UML dinmico y se analizarn con mayor detalle en el siguiente captulo.
4.4 Tipos de relaciones

Hay varios tipos de relaciones en UML entre clase, de las que se destacan: asociacin, generalizacin y varios tipos de dependencia. 4.4.1 Asociaciones Las asociaciones son conexiones semnticas entre clases. Cuando una asociacin conecta a dos clases, cada clase puede mandar un mensaje a la otra. Una asociacin permite a una clase conocer los atributos y las operaciones pblicas de la otra clase. La asociacin se representa por una lnea continua. Esta opcin indica que las clases unidas por la asociacin tienen dependencia cclica. Esta presentacin es vlida en el AOO y en su artefacto de Modelo del Dominio. Sin embargo, en el diseo se ver que esta actitud es impropia con una buena organizacin de las responsabilidades entre las clases. Por este motivo, en las asociaciones de diseo suelen aparecer reflejadas unas flechas que indican el sentido de la navegabilidad. Este concepto indica que la asociacin entre las clases son de carcter unidireccional. La fecha refleja que la clase a la que apunta puede ser empleada por la clase que emana la asociacin, pero no en sentido contrario. Si se pone un ejemplo entre la asociacin entre la clase A y B de forma que sea bidireccional o unidireccional, vase el resultado de su implementacin en C++:
93
+elA
+elB
+elB
class B; class A { public: B elB; }; class A; class B { public: A elA;
class B; class A { public: B elB; }; class B { };
Cada conexin de una asociacin a una clase puede tener nombre (el rol que desempea en la asociacin), visibilidad (si se pueden ver los atributos y servicios) y la propiedad ms importante que es la multiplicidad: cuantas instancias de una clase se puede relacionar con una instancia de otra clase. Si la asociacin, adems del nombre, tiene atributos se dice que es una clase de asociacin, la cual ser tratada ms adelante. La clase A est asociada con la clase B cuando: Un objeto de la clase A usa un servicio de 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.
estudia las 1..n 3 +la materia Asignatura notaTeoria
};
Alumno
1 +el que estudia
En resumen, si un objeto de la clase A tiene que saber algo de un objeto de la clase B aparece la asociacin, esto es, se establece la relacin necesito-conocer.
94
4.4.1.1 Agregacin y composicin Una agregacin es una forma de asociacin. Es un tipo de asociacin del todo con las partes. Se represente con una lnea continua, con un diamante en la clase que representa el todo y una flecha en la parte.
Ruedas 4 Puertas 3..5 1 Motor Coche
Un caso particular de la agregacin es la composicin o agregacin de composicin. En una composicin, los objetos componentes no tienen vida propia, esto es, que cuando se destruye el objeto compuesto tambin se destruyen las partes. Esta particularidad no se cumple necesariamente en la agregacin. Adems, un objeto componente slo puede formar parte de un objeto compuesto y no puede pasar de un objeto compuesto a otro. En UML, una agregacin por valor o composicin las partes son atributos del todo quedndose representado con el diamante relleno.
JuegoDados 2 Dado
Considere la agregacin cuando: Existe un ensamblaje obvio del todo con las parte. Alguna propiedad del compuesto se propaga a las partes. Las operaciones que se aplican sobre el compuesto se propagan a las partes, como la destruccin, movimiento o grabacin. El tiempo de vida de la parte est ligado al tiempo de vida del compuesto (existe una dependencia de creacin-eliminacin de la parte en todo).
Las prestaciones de la agregacin se dan en el paso del anlisis al diseo, por lo que no es muy significativo su inclusin en el Modelo del Dominio. Los beneficios son:
Ayuda en la identificacin de un creador (el compuesto) utilizando el patrn

GRASP creador.
Dpto. Electrnica, Automtica e Informtica Industrial 95
Las operaciones como la copia y la eliminacin que se aplican al todo a

menudo se propagan a las partes.
Como recomendacin, en caso de duda hay que descartarla. Los noveles del
AOO/D utilizan la agregacin y la composicin demasiado a menudo. Recuerde que ambos tipos son una asociacin. En caso de duda utilice una simple asociacin. 4.4.2 Generalizacin La generalizacin y la especializacin son conceptos fundamentales en el modelado del dominio que favorece una economa en las palabras; ms an, las jerarquas de clases conceptuales a menudo constituyen la fuente de inspiracin para las jerarquas de clases SW que se aprovechan de la herencia y reducen la duplicacin del cdigo. En el ejemplo:
Pago
cantidad : Di nero
PagoEnEfectivo
PagoACrdito
PagoConTarjeta
Pago representa la generalizacin y es la superclase, mientras las otras son de especializacin y son subclases. En UML, la generalizacin se representa por una lnea continua con una flecha hueca que apunta a la superclase. Es una forma de construir clasificaciones taxonmicas entre los conceptos que son representados en una jerarqua de clases. Para la realizacin de estas generalizaciones deben de cumplir dos reglas: A) Regla del 100%: La definicin de la superclase se debe poder aplicar a la subclase. La subclase debe ajustarse al 100% de los atributos y asociaciones de la superclase. B) Regla Es-Un: En el lenguaje natural debe comprobarse que la subclase Es Un tipo de la superclase (p.ej: PagoACrdito es un tipo de Pago). Una subclase potencial debera de estar de acuerdo con la regla del 100% y de la regla Es-un. Se crear una subclase de unas superclase cuando:
96
La subclase tiene atributos adicionales. La subclase tiene asociaciones adicionales. La subclase funciona de manera diferente e interesante a la superclase o a otras subclases. Se crear una superclase conceptual en una relacin de generalizacin de subclases cuando: 1. Cuando las subclases potenciales representen variaciones de un concepto similar. 2. Las subclases se ajustarn a las reglas del 100% y Es-un. 3. Todas las subclases tienen el mismo atributo que se puede factorizar y expresarlo en la superclase. 4. Todas las subclases tienen la misma asociacin que se puede factorizar y relacionar con la superclase. 4.4.2.1 Clases abstractas Son aquellas que carecen de instancia y que son instanciadas desde una clase derivada (subclase). Recurdese el ejemplo utilizado en las interfases.
<<interface>> INombre <<abstract>> setNombre() <<abstract>> getNombre()
STDNombre <<virtual>> setNombre() <<virtual>> getNombre() STDNombre()
CNombre elNombre[80] : char <<virtual>> setNombre() <<virtual>> getNombre() CNombre()
MFCNombre
(from M etodoFabriaci on)
<<virtual>> setNombre() <<virtual>> getNombre() MFCNombre()
En UML las clases abstractas se ponen su nombre en cursiva o se le aade el estereotipo de <<interface>>.
97
4.4.2.2 Herencia Es una manera de implementar la generalizacin. La herencia no es la gran solucin. Tiene el problema de la dependencia de la subclase con la superclase. De manera que si se modifica la superclase puede afectar a la subclase. Por este motivo slo se emplear la herencia de clases cuando proceda de una relacin de generalizacin conceptual. La composicin es ms robusta que la herencia. Ejemplo 4.5 Realizar una agenda telefnica Las caractersticas de la aplicacin, en jerarqua a dos niveles, son: 1. La agenda telefnica debe contener y gestionar la lista de telfonos de los contactos: 1.a. Debe permitir aadir, eliminar, listar un contacto El glosario estara formado por: listin telefnico, contacto, nombre, telfono, agenda telefnica, El caso de uso sera ObtenerInformacinAgendaTelefnica. La arquitectura bsica estara formada por un paquete del dominio y otro de visualizacin.
GUI
AgendaTelefnica
Usuario
(f rom Actors)
ObtenerInfoAgendaTelefonica
(from <Use Case Name>)
DominioAgenda
El modelo del dominio tiene las siguientes clases conceptuales:

est formado por AgendaTelefonica 1 1 1 contiene n Contacto nombre 1 n puede tener varios Telefono numero tipoTelefono
ContenedorContactos
98
La solucin lgica podra ser de forma jerrquica o de composicin. Sol. 1: Hacer Agenda sucbclase y que sea la ListaUsuarios de superclase. Esta solucin no es buena, ya que la jerarqua es no conceptual. Sol. 2: Agenda tiene una composicin con la clase instanciada de ListaUsuarios. Es mejor est solucin; cualquier variacin en la ListaUsuarios queda acotada por la asociacin de agregacin por valor. En el caso de que hubiese sido una subclase, las variaciones seran ms inestables.
ContenedorContactos
(f rom Logical View)
ContenedorContactos
1 Peor es un tipo de esta formada por 1 AgendaTelefonica

Mejor
AgendaTelefonica
Ejemplo 4.6 Realizar el anlisis para un programa de las fichas de libros y revista para una biblioteca. La lista de caractersticas del sistema a dos niveles sera: 1. Gestionar las fichas de una biblioteca 1.a. Insertar, eliminar y listar las fichas. 1.b. Las fichas pueden ser de libros o de revistas. Los libros pueden estar constituidos por uno o ms volmenes. 1.c. Las fichas de libros contendrn los campos de referencia, ttulo, autor, editorial y volumen; mientras para las revistas debern estar formados por el ao y el nmero de la revista, junto con la referencia y el ttulo. El glosario estara constituido por las definiciones de: Ficha, Biblioteca, Libros, Revista, Referencia, Ttulo, ... El modelo del dominio podra ser del tipo:
99
<<Anlisis>> CBiblioteca
(from bi bl ioteca)
esta formado por 1 1
<<Anlisis>> ListaFichas 1
es un contenedor de n
<<Analisis>> CFicha
(from bi blioteca)
<<Anlisis>> CFichaLibro
(from bi blioteca)
<<Anlisis>> CFichaRevista
(from bi bl ioteca)
<<Anlisis>> CFichaVolumen
(from bi bl ioteca)
Este ejemplo se ha utilizado como prcticas de la asignatura. Sobre el cdigo entregado se ha realizado ingeniera inversa con el siguiente diagrama de clases:
CFicha CFicha() <<virtual>> ~CFicha() AsignarReferencia() ObtenerReferencia() AsignarTitulo() ObtenerTitulo() Imprimir() PedirFicha() <<friend>> TomarLinea() CBiblioteca CBiblioteca() ~CBiblioteca() operator[]() AnyadirFicha() longitud() VisualizarFichas() eliminar() buscar() VisualizarFicha()
vector<CFicha*>
CFichaRevista NroDeRevista : int Anyo : int CFichaRevista() AsignarNroDeRevista() ObtenerNroDeRevista() AsignarAnyo() ObtenerAnyo() PedirRevista() Imprimir()
CFichaLibro CFichaLibro() AsignarAutor() ObtenerAutor() AsignarEditorial() ObtenerEditorial() PedirLibro() Imprimir()
CFichaVolumen CFichaVolumen() AsignarNroDeVolumen() ObtenerNroDeVolumen() PedirVolumen() Imprimir()
En Java no existe multiherencia.
100
4.4.3 Dependencia Una dependencia indica una relacin semntica entre dos o ms elementos del modelo. Relaciona los elementos del modelo entre ellos y no requiere un conjunto de instancias para su significado. Indica una situacin, en la cual un cambio en el elemento servidor puede requerir un cambio en el elemento cliente. Una relacin de dependencia muestra, por ejemplo, que una clase hace referencia a otra clase. Cuando hay dependencia entre dos clases, no se aaden atributos de instancia a la otra clase; lo cual es una diferencia respecto a la asociacin. Cuando no hay una relacin de asociacin o de generalizacin se utiliza normalmente la dependencia para el resto de relaciones. Las dependencias se suelen emplear con los paquetes. En UML se representan mediante una lnea a trazos acabada en flecha abierta. 4.4.4 Realizacin La relacin de realizacin conecta un elemento del modelo, tal como una clase, con otro elemento, como un interfaz, especificando su comportamiento pero no su estructura o implementacin. La realizacin es un tipo de dependencia. Presenta un tipo de relacin tpica entre cliente con el servidor. El cliente debe tener por herencia o por declaracin directa alguna de las operaciones pblicas que tenga el proveedor. La realizacin se indica con una flecha de lnea discontinua con una punta de flecha hueca cerrada. Es similar al smbolo de generalizacin con una lnea discontinua, para indicar que es similar a un tipo de herencia con relacin de dependencia.
Impl em entacin del servicio
Cli enteImpresora envi arT area()
<<Interface>> IImpresora
env iarTarea()
4.4.5 Otras asociaciones De vez en cuando es til dar ms detalles de los que se tiene sobre una asociacin. En estos casos se puede emplear un calificador. Un calificador es un valor que selecciona un objeto nico del conjunto de objetos relacionados a travs de la asociacin. Los calificadores son importantes para modelar nombres y cdigos de identificacin.
101
Vase el modelado del tablero del juego de tres en rayas.

Tablero 1 constituido por 9 Cuadrado
Tablero
fila : float[3] columna : float[3]
constituido por 1 1
Cuadrado
Se puede combinar la notacin de asociacin codificada con otros adornos de las asociaciones. 4.4.5.1 Asociaciones derivadas Una asociacin derivada es una asociacin redundante que se puede obtener como combinacin de otras relaciones del modelo.
estudia las 1..n 3 1..n /ensea Impartida por 1 Profesor 1..n 1
Alumno
Asignatura
Un elemento derivado puede ser determinado a partir de otros. Los atributos y las asociaciones son los elementos comunes para ser derivados. En UML un elemento derivado se representa anteponiendo una / al nombre del elemento. 4.4.5.2 Clases asociativas En principio, una asociacin no es una clase; no tiene por qu tener atributos ni operaciones. No obstante, si una asociacin debe tener atributos y operaciones propias o bien uno de los dos, entonces es preciso que se defina como clase. En este caso se habla de clase asociativa. Una clase asociativa se representa como una clase colgada del smbolo de la asociacin por medio de una lnea discontinua.
102
Empresa
+empleador 1
trab aja en
+empleado 1..n
Persona
Trabajo Sueldo : Dinero
Los indicios de que se podra incluir clases de asociaciones en el diagrama de clases son: Un atributo est relacionado con una asociacin. El tiempo de vida de las instancias de la clase asociacin depende de la asociacin. Existe una asociacin muchos a muchos entre dos conceptos e informacin asociada con la propia asociacin.
4.5 Comentarios
Un comentario es una anotacin asociada a un elemento, carece de significado directo, pero muestra una informacin significativa para el que ha realizado el modelado. En UML, el comentario se pone dentro de un rectngulo con un vrtice doblado, enlazado con una lnea discontinua al cual se refiere.
Alumno
nombre creditos
Matrcul a mni ma de 15 crdi tos
4.6 Paquetes
Un paquete (package) es slo una caja o contenedor que contiene elementos como clases, objetos, diagramas u otros paquetes. Si en el paralelismo con los sistemas biolgicos, las clases son la analoga a los tipos de clula; los paquetes que agrupan las clases altamente cohesivas en la organizacin con un objetivo particular tienen su correspondencia en la Naturaleza con los rganos biolgicos. En un paquete pueden aparecer tanto elementos del modelo como diagramas. El propsito general es la organizacin en grupos. Un paquete es usado para agrupar cosas que tengan algo en comn. Los paquetes se pueden anidar dentro de otros paquetes. Grficamente, un paquete es representado por UML como una carpeta. Los elementos de un paquete tienen visibilidad, por tanto, algunos elementos de ste pueden ser reconocidos desde otros paquetes. Los paquetes se configuran como un espacio de nombres de propsito general. En principio, cada elemento del paquete es
103
visible y reconocido dentro del paquete donde se ha declarado y su nombre no puede estar repetido dentro del paquete. El nombre del elemento tiene que estar codificado junto con el identificador del paquete; siendo la regla el nombre del paquete ms dos puntos, :, y el nombre del elemento. Paquete : Elemento Vase como este concepto se aplica en C++ con el espacio de nombres, utilizando el operador mbito, ::.
#include <iostream> int main() { //Uso del paquete estndar //y sintaxis de C++ entre //el paquete y el elemento std::cout<< "Hola Mundo\n"; } #include <iostream> //Definicin del espacio de nombres using namespace std; int main() { cout<< "Hola Mundo\n"; }
4.6.1.1 Cmo particionar el dominio en paquetes Ponga los elementos juntos dentro de un paquete s:
Se encuentran en la misma rea de inters estrechamente

relacionados por conceptos u objetivos-.
Estn juntos en una jerarqua de clases Participan en los mismos casos de uso. Estn fuertemente asociados.
Resulta til que todos los elementos relacionados con el modelo del dominio tenga como raz un paquete denominado Dominio y todos los conceptos bsicos, comunes, compartidos, se definan en un paquete que se pueda llamar Elementos Bsicos o Conceptos Comunes. Una forma de incrementar la estabilidad de los paquetes es reducir la dependencia de clases concretas de otros paquetes. El diseo empujar a realizar paquetes lo ms autnomos posibles. Los paquetes estarn formados por clases funcionalmente cohesivas (estos aspectos sern tratados con mayor detalle en el captulo del diseo orientado a objetos).
104
Hay que evitar la aparicin de dependencias circulares, esto es, un paquete depende de otro y a su vez, ste depende del anterior. En el caso de necesidad de dependencia cclica, se romper el ciclo mediante la interseccin de una interfaz estable. Si los paquetes ms responsables (de los que ms se depende) son inestables, existe un mayor riesgo de extender el impacto de los cambios a quienes depende de l. Hay que poner mucha atencin al paquete que ms se emplea. Sus constantes revisiones pueden afectar al resto. Hay que saber aislar para producir un diseo robusto. En C++ se es ms sensible a las dependencias que en Java. Un cambio en una clase C++ tiene un fuerte impacto en las clases que dependan de sta. El acoplamiento interno del paquete, o cohesin relacional, puede identificarse en:
CR = Nmero de relaciones int ernas Nmero de tipos
Donde el nmero de relaciones internas incluye las relaciones de atributos y parmetros, herencia e implementaciones de interfaces. Un CR muy bajo indica falta de cohesin. En resumen, las formas de incrementar la estabilidad en un paquete son:
Contiene slo o en su mayor parte interfaces y clases abstractas. No depende de otro paquete o de otros muy estables. Contiene cdigo relativamente estable y se refin antes de lanzar la
versin.
Es obligatorio una planificacin lenta de los cambios.

Los paquetes son normalmente la unidad bsica del trabajo de desarrollo y de versiones.
4.6.2 Vista de gestin del modelo

La gestin del modelo describe la organizacin de los propios modelos en unidades jerrquicas. El paquete es la unidad genrica de organizacin para los modelos. Esta vista cruza las otras vistas de UML y las organiza para el trabajo de desarrollo y el control de configuraciones. Los paquetes son unidades para manipular el contenido de un modelo. Cada elemento del modelo pertenece a un paquete. El modelo es una descripcin completa del
105
sistema desde un punto de vista, con una determinada precisin. Puede haber varios modelos de un sistema desde distintos puntos de vista; por ejemplo, un modelo de anlisis y un modelo de diseo. La informacin de gestin del modelo se representa en diagramas de clase, donde aparecen los paquetes y sus dependencias.
Ejemplo 4.10 Vista de gestin del modelo o diseo arquitectnico de la aplicacin de respuesta en frecuencia.
Se propone realizar una divisin en paquetes de la aplicacin segn muestra el diagrama de paquetes siguiente:
ActiveX-Bode
VistaFrecuenci a ELAI
MFC (.NET)
DominioFrecunc iaEla
STL-ANSI C++
4.7 Diagramas de casos de uso

Los diagramas de casos de uso sirven para mostrar las funciones de un sistema SW desde el punto de vista de sus interacciones con el exterior y sin entrar ni en la descripcin detallada ni en la implementacin de estas funciones. Reparte la funcionalidad del sistema en mensajes significativos entre los actores y el sistema. Un caso de uso es una descripcin lgica de una parte de funcionalidad del sistema. El propsito de un caso de uso es definir una pieza de comportamiento coherente, sin revelar la estructura interna. Se utilizan tanto en la fase de requisitos como de anlisis. No obstante, las especificaciones de los requisitos se hacen escribiendo los documentos, no dibujando los casos de uso que es un paso opcional. El diagrama es slo para ayudar a comprenderlos o reducir duplicaciones.
106
4.7.1 Relaciones entre casos de uso

Cuando se implementa un caso de uso, su funcionamiento se basa en la colaboracin entre clases. Una clase puede participar en mltiples colaboraciones y por tanto, en mltiples casos de uso, dando paso a relaciones entre los casos de uso. Aunque cada instancia de un caso de uso es independiente, la descripcin de un caso de uso se puede descomponer en otros casos de uso ms simple, apareciendo la relacin de inclusin. Se utilizar el estereotipo include cuando una actividad se est repitiendo en dos o ms casos de uso separados y se quiere evitar las repeticiones, haciendo una factorizacin. Por tanto, la inclusin de casos de usos es esencialmente una forma de reutilizacin. Habr que factorizar algunas subfunciones de forma separada y por tanto utilizar la relacin include cuando: Estn duplicados en otros casos de uso Un caso de uso es muy complejo y largo y separarlo en subfunciones facilita la compresin. Un caso de uso se puede tambin definir como una extensin incremental de un caso de uso base. A esta relacin se le llama de extensin y se utiliza el estereotipo de extend. Se dice que el caso de uso A extiende al B si dentro de B se ejecuta A cuando se cumple una condicin determinada. A tiene que ser un caso de uso que tambin se pueda ejecutar de forma separada de B. Un caso de uso tambin se puede especializar en uno o ms casos de uso. Esta relacin es la de generalizacin/especializacin de casos de uso. Un caso de uso A es una especializacin de un caso de uso de B, cuando el A es un proceso ms especfico que el de B. En UML, la relacin entre los actores y los casos de uso se representarn como una asociacin, indicando la comunicacin bidireccional entre usuarios y sistema. Las relaciones de inclusin y extensin se dibujan como flechas de lneas discontinuas con la palabra clave <<include>> y <<extend>>, respectivamente. La relacin de inclusin apunta al caso de uso a ser incluido; la relacin de extensin seala al caso de uso que se extender. Las generalizaciones de casos de uso sern dibujadas mediante la flecha de relaciones de herencia, la punta sealar al caso de uso de generalizacin. En la figura de abajo se muestra un diagrama de casos de uso con todas posibles relaciones que se pueden establecer.
107
Solicitar catlogo sabe donde hacer pedido, pero hacer pedido no sabe de donde viene...
<<extend>>
<<include>> Hacer Pedido Vendedor <<include>> <<include>>
Solicitar catlogo
Pago compras
Obtener datos cliente Pedir producto
Pago crdito
Pago al contado
Se recuerda que lo importante son los documentos de los casos de uso. No hay que perder mucho tiempo en el diagrama de casos de uso. Es tpico de los desarrolladores noveles dedicarse a dibujar casos de uso ms o menos sofisticados, buscando relaciones y nuevas inclusiones, cuando lo importante es la captura de los requisitos funcionales (ver captulo dedicado a la recogida de documentacin y requisitos).
4.8 Problemas
1. Notacin de UML sobre las clases. 2. Uso de las clases parametrizadas/instanciadas. Hgase un ejemplo sobre las pinturas de una galera de arte. 3. Defina un paquete sobre objetos geomtricos, tales como cuadrado, rectngulo, tringulo, ... Defina un interfase. 4. Defina una jerarqua de clases para los objetos geomtricos de la anterior pregunta. Presente las superclases y las subclases. 5. Cuando emplear una relacin de asociacin, agregacin, composicin, generalizacin y dependencia. 6. Cmo particionar una aplicacin en paquetes. 7. Qu es la vista de gestin del modelo.
108 Dpto. Electrnica, Automtica e Informtica Industrial
8. Relaciones en los diagramas de caso de uso.
Problema 4.1
Dinero
Implementar en C++ la siguiente clase Dinero definida en UML segn figura Problema 4.2 Realizar una descripcin textual del siguiente diagrama de clases.
cantidad : float elTipoMoneda : TipoDinero Dinero() Dinero(valor : float, elTipo : TipoDinero) Dinero(elValor : Dinero&) operator=(elValor : Dinero&) : Dinero& setCantidad(laCantidad : float) : void getCantidad( : void) : float setTipoDinero(elTipo : TipoDinero) : void getTipoDinero( : void) : TipoDinero
Motor 1..4
Piloto 1..2
Vendedor de billetes 1
1 Avin 1 *
* Vuelo * 1 *
* Reserva
1 Avin militar Avin comercial Lnea area
Avin de carga
Avin de pasajeros
109
Problema 4.3 Realizar una aplicacin grfica en cuyo MUNDO est definida una CAJA que contiene un nmero indeterminado de ESFERAS. Se debe similar el rebote entre las propias ESFERAS y stas con los SEGMENTOS de la CAJA.
La lista de caractersticas del sistema a dos niveles sera: 1. Simulacin de esferas que rebotan dentro de una caja 1.a. Las esferas rebotan contra las paredes y barreras de la caja y con ellas mismas. 1.b. La caja es cerrada y no se pueden escapar las esferas. 1.c. La caja est formada por cuatro paredes y un nmero indeterminado de barreras. Modelo del dominio:
Barrera 0..n Caja est constituido por Mundo
(f rom robote) (f rom robote)
Segmento
(f rom robote)
1 1 Pared 4
est formador por ContenedorESferas 1 contiene 0..n Esfera

(f rom robote)
La vista de gestin:
Dominio Rebote
Comunes <<OpenGL>> GLUT32
Diagrama de clase de diseo:
110
Caja Caja() Pintar() getSegmento() <<virtual>> ~CCaja() 1 4 4
Pared 1
Segmento longitud : double Segmento() Pintar() setColor() distancia() 1 3 vector2D() modulo() unitario() operator-() operator*() operator*()
Mundo Mundo() <<virtual>> ~CMundo() InitGL() OnKeyboardDown() OnTimer() OnDraw() 1 1 1
Barrera
vector2D
Interacciona <<static>> chocaEsferaCaja() 2 1 vector<Esfera> Esfera() Pintar() iteracion() setPos() setRadio() setVelocidad() setColor() getRadio() getCentro() getVelocidad() acelerar() 1 Esfera radio : double
Derecho de Autor 2009 Carlos Platero Dueas. Permiso para copiar, distribuir y/o modificar este documento bajo los trminos de la Licencia de Documentacin Libre GNU, Versin 1.1 o cualquier otra versin posterior publicada por la Free Software Foundation; sin secciones invariantes, sin texto de la Cubierta Frontal, as como el texto de la Cubierta Posterior. Una copia de la licencia es incluida en la seccin titulada "Licencia de Documentacin Libre GNU".
111
La Licencia de documentacin libre GNU (GNU Free Documentation License) es una licencia con copyleft para contenidos abiertos. Todos los contenidos de estos apuntes estn cubiertos por esta licencia. La version 1.1 se encuentra en http://www.gnu.org/copyleft/fdl.html. La traduccin (no oficial) al castellano de la versin 1.1 se encuentra en http://www.es.gnu.org/Licencias/fdles.html
ESTA PGIINA HA SIIDO DEJADA EN BLANCO IINTENCIIONADAMENTE ESTA PG NA HA S DO DEJADA EN BLANCO NTENC ONADAMENTE
112

Diagrama UML

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diagrama UML

Uploaded by

Copyright:

Available Formats

4

Dpto. Electrnica, Automtica e Informtica Industrial

Captulo 4: UML estructural

Apuntes de Informtica Industrial

Diagrama de casos de uso 4.1 OMG y UML

4.2 Clases en UML

Dpto. Electrnica, Automtica e Informtica Industrial

Apuntes de Informtica Industrial

Captulo 4: UML estructural

Dpto. Electrnica, Automtica e Informtica Industrial

Captulo 4: UML estructural

Apuntes de Informtica Industrial

Dpto. Electrnica, Automtica e Informtica Industrial

Apuntes de Informtica Industrial

Captulo 4: UML estructural

ListaPasajerosVuelo Azafat@ <<include>>

<<Analisis>> Vuelo numTotalAsiento IDVuelo

numDNI nombre asiento

Dpto. Electrnica, Automtica e Informtica Industrial

Captulo 4: UML estructural

Apuntes de Informtica Industrial

Clase instanciada de STL vector

Cuya implementacin en C++ ser:

Dpto. Electrnica, Automtica e Informtica Industrial

Apuntes de Informtica Industrial

Captulo 4: UML estructural

Clase parametrizada CList de las MFCs ListaPasajerosMFC

Dpto. Electrnica, Automtica e Informtica Industrial

Captulo 4: UML estructural

Apuntes de Informtica Industrial

<<interface>> IDiagramaBode pintaPlotXY()

Dpto. Electrnica, Automtica e Informtica Industrial

Apuntes de Informtica Industrial

Captulo 4: UML estructural

<<interface>> IAdaptadorVisualizar <<abstract>> InicializarPlotXY() <<abstract>> PintarPlotXY() <<static>> factoriaVisualizadores()

Cliente del paquete Visualizador

Solucin tecnolgica AdaptadorVisualCNTGraph AdaptadorVisualCNTGraph() <<virtual>> InicializarPlotXY() <<virtual>> PintarPlotXY() CNTGraph

Constructor privado Mtodo de Fabricacion (GoF)

<<abstract>> setNombre() <<abstract>> getNombre() <<static>> factoriaObjetos()

<<interface>> INombre <<abstract>> setNombre() <<abstract>> getNombre()

STDNombre <<virtual>> setNombre() <<virtual>> getNombre() STDNombre()

CNombre elNombre[80] : char <<virtual>> setNombre() <<virtual>> getNombre() CNombre()

<<virtual>> setNombre() <<virtual>> getNombre() MFCNombre()

Dpto. Electrnica, Automtica e Informtica Industrial

Captulo 4: UML estructural

Apuntes de Informtica Industrial

#include #include #include #include

<iostream> "../includes/STDNombre.h" "../includes/CNombre.h" "../includes/MFCNombre.h"

delete pNombre1, pNombre2, pNombre3; return 0; }

Se recuerda que las clases abstractas en C++ carecen de instancias.

Dpto. Electrnica, Automtica e Informtica Industrial

Apuntes de Informtica Industrial

Captulo 4: UML estructural

4.3 Representacin de los objetos

4.4 Tipos de relaciones

Dpto. Electrnica, Automtica e Informtica Industrial

Captulo 4: UML estructural

Apuntes de Informtica Industrial

class B; class A { public: B elB; }; class A; class B { public: A elA;

class B; class A { public: B elB; }; class B { };

1 +el que estudia

Dpto. Electrnica, Automtica e Informtica Industrial

Apuntes de Informtica Industrial

Captulo 4: UML estructural