Generación de codigo c++ a partir de modelos uml

Generación De Codigo C++ a partir de modelos UML
Laboratorio de sistemas de Información
Facultad de Informática - Universidad Politécnica de Valencia

Este documento trata de la etapa de implementación del desarrollo del ciclo
de vida y en particular de la creación de código fuente para implementar un sistema.
Claramente el código fuente que se escribe para implementar un sistema
tiene que basarse en los modelos generados en las etapas previas del desarrollo de
software, especialmente del diseño de diagramas de clase, de secuencia y de
estados. La creación de código puede ser informada simplemente por estos
modelos o basada en su transformación (o la de alguno de ellos) en fragmentos de
código. Esta clase presenta una forma de transformar diagramas de diseño de
clases UML en código C++.









Perspectiva general del documento
la distancia (gap) entre diseño y código
código para clases
código para las relaciones de generalización
código para las relaciones de delegación
código para atributos
código para asociaciones
código para operaciones

La lección comienza discutiendo la distancia (gap) entre el diseño y los
editores de UML. Luego se centra en los fragmentos de código que pueden ser
generados por varias clases de elementos del modelo que pueden encontrarse en
un diagrama de clases UML incluyendo:

clases,

relaciones de generalización,

relaciones de delegación,

atributos,

asociaciones, y

operaciones.

1
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia

L a d istan cia sem án tica en tre lo s m o d elo s d e d iseñ o y el có d ig o
Im p lem en tació n
E tap a d e D iseñ o

D iag ram a d e clases +
p ro p ied ad es relacio n ad as co n el có d ig o

D iag ram as d e E stad o

D iag ram as d e C lase

C O D IG O

D iag ram as d e S ecu en cia
A p ro x im ació n G en eral:
U so d e las h erram ien tas d e g en eració n d e có d ig o d e u n a h erram ien ta C A S E
p ara su av izar la d istan cia sem án tica

Los modelos generados durante la etapa de diseño del desarrollo de
software especifican las relaciones y comportamiento de las clases individuales de
un sistema hasta cierto punto y cierta formalidad, pero no con un nivel de detalle ni
con una notación que pudiera ser usada directamente como su implementación.
Para crear un ejecutable todavía necesitamos escribir el código fuente del sistema.
Para este fin existen herramientas que pueden utilizarse de apoyo e incluso
automatizar partes de la actividad de generación de código (ej. Compiladores,
depuradores, generadores de código).
A continuación describiremos el uso de una de estas herramientas: el
generador de código de C++ de Rose. Rose actualmente viene con dos generadores
de código, uno que genera código C++ a partir del diseño del diagrama de clases y
otro que genera código Java. Nuestra discusión cubrirá solamente el generador de
código C++.
El generador de código C++ de Rose produce código fuente C++ a partir de la
información contenida en un modelo de Rose. El código generado para cada
componente del modelo se determina por la especificación del componente en el
modelo y las propiedades de la generación de código que pueden ser especificadas
para el componente individual o ser aplicadas al modelo como un todo (el último
puede denominarse propiedades del proyecto). Estas propiedades especifican una
información de lenguaje específico requerido para fijar un componente UML en un
fragmento de código C++ y permiten al programador controlar el código generado
para cada uno de los componentes.
A continuación vamos a presentar los patrones de código generados por los
diferentes tipos de componentes que pueden encontrarse en un diagrama de
clases.
2








Código para clases
cabecera de clase
modificadores de clase (abstract, leaf)
constructor
anotaciones extraídas de la especificación de clase
clases esteorotipadas como catálogos de interfaces
declaración de paquetes

Para cada clase UML, el generador de código C++ produce los siguientes
fragmentos de código:
 una clase C++ que implementa la clase UML tiene el mismo nombre que ella
 comentarios extraidos del formulario de especificación de la clase UML
 un constructor de clase
 un destructor de clase
Si la clase UML es una clase abstracta, es decir una clase que no tiene
instancias directas, la clase C++ que se crea para su implementación se declara como
una clase abstracta mediante un constructor virtual puro.
Si la clase UML es una clase “hoja” (una clase que no tiene subclases) no
podemos especificarlo en la clase C++. Se podría implementar un analizador
sintáctico que comprobara que la clase no tiene subclases. En UML una clase hoja se
representa poniendo la cadena “leaf” entre corchetes bajo el nombre de la clase.
Si la clase UML ha sido estereotipada como una clase interface entonces
heredaremos de una clase que defina la interfaz (con métodos virtuales puros).
Si la clase UML pertenece a una serie de paquetes anidados entonces dentro
de un fichero de cabecera se incluirá las sentencias #include que definan la jerarquía
de paquetes que contiene la clase creada.

3

C ód igo p ara clases - E jem p lo 1
E ntityC lasses
< < E ntity C lass> >
L ibraryItem

C O D IG O C + +

E sta es una clase que representa
los objetos de una librería

//F ichero fuente ../E ntityC lass.h
/**
el objeto incluido en la librería
*/
public class L ibraryItem {
L ibraryItem () {}};

Como se muestra en la transparencia de arriba, el generador de código C++
produce una clase C++ llamada LibraryItem para implementar la clase UML
LibraryItem.
El contenido del campo de documentación del formulario de especificación
de la clase UML se transforma en un comentario que precede la definición de la
clase.
La clase C++ LibraryItem fue declarada con un constructor virtual puro ya que
la clase UML LibraryItem era una clase abstracta. En UML las clases abstractas se
denotan poniendo sus nombres en cursiva. Rose provee un modificador “abstract”
en el formulario de especificación de clases que puede ser usado para especificar
que una clase es abstracta.
Nótese también que el generador de código C++ generó una sentencia
#include indicando la estructura anidada de paquetes que contiene la clase
LibraryItem y un constructor y destructor para esta clase.
Un ejemplo de clase C++ generada para implementar una clase estereotipada
como una interface se muestra en la siguiente transparencia.

4

C ód igo p ara clases - E jem p lo 2

< < Interface > >
S ortedS et

C O D IG O C + +

//F ichero fuente ../S ortedS et.h
/*
*/
public class S ortedS et {
virtual S ortedS et() = 0};

La transparencia de arriba muestra el fichero interface.h creado para
implementar una clase UML que ha sido estereotipada como una clase de interface.
Nótese que no se ha creado un constructor para esta clase <<interface>>.
El código por defecto que se genera para una relación de generalización
entre dos clases en un diagrama de clases UML consiste en una declaración de
herencia en la cabecera de la clase C++ que implementa la subclase. Además, si la
superclase no pertenece al mismo paquete que la subclase se genera una sentencia
#include que importa el fichero que representa al paquete.
Nótese que, el código generado para las clases UML que tienen más de una
superclase se resuelve utilizando la herencia múltiple.
C ód igo p ara relacion es d e gen eralización - E jem p lo
tools
U IP P ackage
Código para relaciones de generalización


la subclase se declara que hereda de la superclase llamando al
< < U Interface> >
< < tools.h> >
<
constructor de enusuperclase < tools.h> >
la
L oanM
M enu

si la subclase ha sido estereotipada como una M enu
clase
{leaf}
<<interface>>, la superclase debe ser también abstracta

si la superclase no pertenece al mismo paquete que la subclase
también se genera una sentencia #include para importar el fichero

C O D IG O

//F ichero fuente ../E ntityC lass.h
/**
*/
C++
public class L ibraryItem {
L ibraryItem () {}};


5

La transparencia de arriba muestra el código C++ generado para la clase UML
LoanMenu. Este código incluye: una sentencia de herencia que apunta a la clase
Menu que implementa la relación de generalización entre LoanMenu y Menu en el
diagrama UML;y una sentencia “#include” que importa Menu desde el fichero
donde ha sido definido (tools.h).
Nótese también que la clase C++ LoanMenu debería revisarse para que no
tuviera subclases ya que la clase UML LoanMenu se declara como una clase hoja en
el diagrama UML. El diagrama de la transparencia utiliza la notación estándar UML
para denotar las clases hoja. De acuerdo con esta notación, una clase hoja se denota
poniendo la cadena “leaf” entre corchetes bajo su nombre. En Rose hay una
propiedad especial llamada “final” que puede usarse para determinar si la clase es
una hoja o no. Si el valor de esta propiedad se establece a “true” (“false”) la clase
se especifica como una clase hoja (no hoja).

Código para las relaciones de delegación

El código es generado solamente para las relaciones de delegación
entre una clase normal y una clase catalogada como de <<interfaces>>.

La función delegada es declarada como friends ( amiga)

Una clase puede tener un número indeterminado de delegaciones

Si la interface no pertenece al mismo paquete que la clase que lo
usa, se debe declarar la sentencia #include# para importarlo.

6

El código por defecto que es generado para una relación de delegación que conecta
con una clase declarada como <<interface>> en un diagrama de clases de UML
consiste en una implementación en la que se declara que la clase origen de la
relación es amiga (friend) de la clase declarada como <<interface>>. Pudiendo la
clase origen usar el servicio que ofrece el catálogo de interfaces. Además, en la
declaración del catálog se declaran las funciones que se van a exportar con el
identificador friend para declarar las funciones que podrán ser utilizadas rompiendo
la visibilidad de la clase. Recordar que este tipo de relaciones no tiene relación de
transitividad.

C ód igo p ara relacion es d e d elegación - E jem p lo
D B P ackage
< < Interface > >
S et

O bjectS et

A rray L ist

//F ichero fuente ../O bjectS et.h
public class O bjectS et {
friend A rrayL ist::S et()};

C O D IG O C + +

En la transparencia de arriba, la clase UML ObjectSet se declara como una
subclase de la clase UML ArrayList y desarrolla la clase <<interface>> Set. De este
modo, la clase C++ generada para implementar ObjectSet hereda de la clase
ArrayList e implementa la clase interface Set.

Código para atributos

se crea un campo para cada atributo

la visibilidad de un atributo en una clase UML (ej. Public, protected,
private) determina el modificador de visibilidad del campo generado

un campo estático es creado para un atributo de alcance de clase (ej.
Un atributo con la marca static en Rose)

7

Para cada atributo de una clase UML, el generador de código C++ crea un
campo con el mismo nombre que el atributo y cuyo tipo es el tipo especificado para
el atributo en el diagrama de clases.
La visibilidad del campo en la clase C++ se determina por la visibilidad del
atributo en el diagrama de clases. La visibilidad tiene que ver con la capacidad que
tienen otras clases diferentes a la clase que posee el atributo de acceder a él
directamente. En UML, la visibilidad de un atributo puede ser:
public – un atributo público puede ser accedido por cualquier clase
protected – un atributo protegido puede ser accedido solamente por las
sublcase de la clase a la que pertenece
private – un atributo privado no puede ser accedido por ninguna otra clase que
no sea la clase a la que pertenece
Estos tipos de visibilidad en UML corresponden directamente a los modificadores
de visibilidad que C++ soporta para campos de clase (y métodos) y de esta forma
pueden ser implementados por estos modificadores.
Si el alcance de un atributo UML es la clase a la que pertenece (en oposición a las
instancias de su clase), el campo generado es modificado por el modificador static.
Este modificador indica que el campo guarda un valor que se refiere a la clase como
un todo o es común a todas las instancias de la clase. En ambos casos, el campo sólo
puede ser accedido al nivel de la clase.
En la siguiente transparencia damos un ejemplo de código generado para
implementar atributos UML.

C ód igo p ara atrib u tos - E jem p lo
B ookC opy

-code:L ibraryC ode
+ selfm ark :S tring
+ lib _site:S tring
#noO fItem s:Integer

C O D IG O C + +

V ariable de C lase

//F ichero fuente ../B ookC opy .h
class B ookC opy {
private:
S tring code ;
public:
S tring selfm ark ;
S tring lin _site;
protected :
static Integer noO fItem s ;

8

El ejemplo de la transparencia superior muestra el código generado en C++ por la
clase BookCopy, la cuál posee cuatro atributos. La plantilla usada para la generación
de código sigue los siguientes patrones:
 El campo privado code se codifica como un atributo private.
 Los campos públicos shelfmark y lib_site son implementados como
atributos de tipo public.
 El campo protegido estático noOfItems corresponde a un atributo static
protected.

Nota: El nombre y el tipo del atribtuo noOfItems has sido subrayado para
representar el hecho de que es un atributo de clase y no de instancia como requiere
UML. No obstante, Rose no trata esta notación de UML. Un atributo de clase es
especificado usando la palabra reservada static en el cuadro de especificaciones. Un
atributo declarado como estático corresponde a una variable de clase.
C ó d ig o p a r a a s o cia cio n e s - E jem p lo

Código para las asociaciones

Un campo por cada asociación accesible desde la clasebfuente de la
Book
P u lis h er
1 ..*
p u b l ica t io n
1 ..1
asociación.o k
+ bo
- p u b l is h er

La visibilidad de un campo es determinada por la visibilidad
indicada en la asociación.(p. ej. Private, public, protected)

Un campo estático es creadobpor er .h asociación a una variable de
//F ich er o fu ent e ../P u lis h cada
clase.
cla s s P u b lis h er {
p u b lic :

La multiplicidad de la asociación es n si el tipo del campo es un
T lis t B o o k ;
vector de elementosPcuyo h er () es la clase apuntada por la asociación.
tipo { } } ;
u b lis

C O D IG O C + +

//F ich er o fu ent e ../ B o o k .h
cla s s B o o k
{
p r iva te:
P u b lis h er p u b lis h er ;
p u b lic : P u b lis h er () { } } ;

Decir que una asociación en UML es una relación entre dos clases. Cada una de ellas
juega un papel en la asociación.
El código por defecto generado en una asociación en UML consiste en un
campo por cada asociación accesible. Este campo es generado en la clase
generada por C++ para implementar la conexión con la case asociada. El tipo
del campo depende de la multiplicidad del papel de la asociación. Si la cota
superior de la multiplicidad es uno entonces la clase en C++ es implementada
con el tipo de la clase de la asociación apuntada. Si la cota superior indica que
la multiplicidad es n entonces la implementación se realiza como una lista. La
visibilidad del campo es determinada por la visibilidad asociada al papel como
en el caso de los atributos.
Un ejemplo de código generado por defecto en una asociación es mostrado en
la transparencia superior.
9

El generador de código C++ codifica el campo público book y el campo
privado publisher para representar los papeles de book y publisher de la asociación
publication. El primer campo ha sido implementado con la clase definida en C++
publisher. El campo posterior se ha definido en C++ con la clase book. Observar que
el tipo del campo book es una lista de identificadores de tipo book más que un
identificador único. Esto ha sido necesario debido a que la multiplicidad del papel
book es de 1..*.
Código para la asociación entre clases

Los campos que posee la asociación son declarados con su propio
tipo en la clase.

Una clase en C++ resuelve la asociación entre clases apuntando a las
clases de la asociación.

La multiplicidad de los roles determina el tipo exacto de los campos
pero

El generador de Rose no trata la asociación de clases.

Para implementar la asociación entre clases el generador de código C++ debería
crear:
 Una clase en C++ para implementar la asociación.
 Los campos de la asociación como campos de la clase que apuntan.
 Campos por cada clase apuntada.
No obstante, esto no lo hace. Rose solamente genera una plantilla para la
asociación entre clases. La clase en C++ que implementa la asociación no tiene
campos apuntando a las clases asociadas. Los campos son creados en la

E jem p lo d e cód igo p ara asociacion es
con clases asociación
B orrow erC lass

0..1

loan

0..n

+ borrow er

B ookC opy

+ book

L oan
+ out: D ate
+ due: D ate

//F ichero fuente ../B orrow erC lass.h
class B orrow erC lass {
public:
T list L oan;
B orrow erC lass() };

//F ichero fuente ../B ook .h
class L oan {
public:
B orrow erC lass borrow er;
B ookC opy book ;
L oan() };

10

asociación de clases para implementar la asociación como si no estuvieran
enlazados a una asociación entre clases.
El ejemplo de la transparencia superior muestra el código que debería haber
sido generado para una asociación entre clases. El generador de código debería
crear una clase en C++ para implementar la asociación de la clase Loan y los campos
en esta clase apuntando a las clases de la asociación Loan( ver campos borrower y
book en la clase Loan). También debería haber creado los campos en las clases de la
asociación apuntando a la implementación de la clase. ( ver campo Loan de la clase
BorrowerClass).
Advertir que el generador de C++ de Rose no crea este código. En el caso de
que lo hiciera sólo generaría la plantilla de la clase en C++ de Loan ( sin lo campos
para la asociación de Loan)., un campo llamado book en la clase borrower, y un
campo llamado borrower en la clase BookCopy.
Código para las operaciones

La cabecera de un método se basa en la declaración de la operación.

La visibilidad del método depende de la visibilidad de la operación.(
por defecto: pública (+), protegida (#) y privada (-)).

El cuerpo del esqueleto del método. (es necesario que sea
completado por el usuario, suministrando el código necesario).

Comentarios extraídos de la documentación de la operación.

Para cada operación de una clase en UML el generador de C++ produce:
 La cabecera del método en la clase C++ que implementa la operación. La
declaración del método se basa en la declaración de la operación.
 El esqueleto del cuerpo del método. El fragmento de código que
implementa el método lo codifica el programador.
 Los comentarios se extraen de la documentación asociada a la operación.
La visibilidad del método generado depende de la visibilidad de la operación, la cual
puede ser pública, protegida y privada. La visibilidad de estas operaciones funciona
de igual modo a la visibilidad de los atributos ya comentadas anteriormente.
Notar que el programador tiene que definir las operaciones para acceder a los
valores de los campos privados y protegidos de la clase.

11

C ó d ig o p ara o pera cio nes - E jem p lo 1
< < en tity class > >
L ib rary Ite m

E sta o p era ció n se in v o ca e n u n ele m en to d e bibliote ca
qu e pu ed e ser pr e sta do cu a nd o el siste m a re cib
u na p etició n pa ra a na liza r e ste ele m e nto.

+checkO ut (cardN um:S tring, outD ate:D ate)

//F ic hero fue nte ../L ibraryIte m .h
c la ss L ibraryIte m {
L ibraryIte m ()
/*
E sta o p era ció n se in v o ca e n u n ele m en to d e bibliote ca
qu e pu ed e ser pr e sta do cu a nd o el siste m a re cib e
u na p etició n pa ra a na liza r e ste ele m e nto.

C O D IG O C + +

*/
vo id c heckO ut(S tring cardN u m , D ate o utD ate)
}

Como muestra la transparencia superior, el código generado por el generador de
C++ para el método checkOut(String cardNum, Date outDate) para implementar la
operación en UML checkOut(cardNum:String, outDate:Date). La visibilidad de los
métodos fue declarada como pública para implementar la visibilidad de la operación
definida en el diagrama de clases. También, la anotación asociada con la operación
en el diagrama de clases fue transformada en un comentario en C++ dentro del
código.

12

C ód igo p ara op eracion es - E jem p lo 2

< < entity class> >
B orrow ableItem

B ookC opy
P roceedings
+ estim ateP enalty (){final}

+ estim ateP enalty ()
+ estim ateP enalty (){final}
A bstract

class B ookC opy : public B orrow ableItem {
…
R eal estim ateP enalty () }

C O D IG O C + +

class P roceedings: public B orrow ableItem {
…
R eal estim ateP enalty () }
class B orrow ableItem {
virtual R eal estim ateP enalty ()= 0 }

La operación estimatePenalty declarada por la clase abstracta BorrowableItem tiene
declarada una operación abstracta(en UML una operación abstracta se denota
poniendo la letra en cursiva) El significado de esta operación es el cálculo de la
penalización que el solicitante del préstamo de un libro tiene que pagar si no
devuelve el préstamo cuando es debido. La penalización depende de la tasa de
penalización diaria del tipo de objeto del préstamo ( por ejemplo, libros y autos
judiciales), llevando cada uno un tipo de penalización distinta. La implementación de
la operación estimatePenalty se realiza en las subclases de la clase BorrowableItem.
Consecuentemente, el método estimatePenalty generado para la implementación
de esta operación en la clase BorrowableItem es declarada como un método
abstracto y no posee el esqueleto del cuerpo para introducir el código de la
implementación.
Las dos subclases de BorrowableItem ( en este caso BookCopy y Proceedings) en la
transparencia superior redefinen la operación estimatePenalty para indicar que ellas
proveen la implementación y se declaran con la marca final. ( o equivalente a no
polimórfica) Para implementar esas operaciones, el generador de código de C++
produce unas nuevas cabeceras y cuerpos para ellas en las subclases BokkCopy y
Proceedings. Notar que ambos métodos son marcados con la notación final y su
implementación no puede ser sobrecargada por ninguna subclase de las clases
BokkCopy y Proceedings.
13

C ód igo p ara op eracion es - E jem p lo 3
< < entity class> >
B orrow ableItem

+ reserve(until:D ate){ concurrent}
+ noO fItem s():Integer

S tatic

S ynchronized

class B orrow ableItem {

C O D IG O C + +

void reserve(D ate until)
static Integer noO fItem s()
}

En la transparencia superior, la clase BorrowableItem tiene dos operaciones: La
operación reserve(until:Date) y la operación noOfItems():Integer.
La operación reserve(until:Date) puede ser invocada por un objeto prestable para
reservarlo durante un cierto período de tiempo. Una reserva puede ser hecha
solamente si el objeto actualmente no está prestado y no tiene una reserva previa
que se solape con el período de reserva solicitado. Si más de un flujo de control
puede invocar esta operación al mismo objeto simultáneamente entonces es en
estos casos cuando las reservas pueden solaparse. Para evitar esto, la operación es
declarada como concurrente. Se debe observar que en UML, la restricción
concurrente ha sido anotada junto a la declaración para marcarla como
concurrente. En C++ la concurrencia no es implementada.
La operación noOfItems():Integer puede ser invocada para contar los objetos cuyas
instancias de la clase BorrowableItem han sido creadas. Esta operación es declarada
como una variable de clase ( en UML una operación con una operación de clase se
marca subrayándola). De este modo el método generado en C++ es declarado como
un método estático.

14

Generación de codigo c++ a partir de modelos uml

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Generación de codigo c++ a partir de modelos uml (20)

Generación de codigo c++ a partir de modelos uml