ENTERPRISE

ARCHITECT

Manual prctico
 Enterprise Architect
Manual prctico

El objetivo del presente manual es acercar al usuario a las capacidades de la

herramienta Enterprise Architect, desde una perspectiva formativa y a travs de
diversos ejemplos didcticos.

Para ampliar cualquier concepto aqu recogido, se recomienda consultar el Manual

completo de la herramienta, la propia Ayuda de la aplicacin o la documentacin
disponible en la web de Sparx Systems.

www.sparxsystems.com

Este manual est basado en la versin 7.0 de la herramienta.

Agosto, 2007.

Pg 2 de 213
 Enterprise Architect
Manual prctico

NDICE
1. Introduccin .................................................................................................................. 7

o Objetivo y alcance del manual........................................................................ 7

o Interfaz de trabajo ............................................................................................ 8

2. Gestin de Modelos..................................................................................................... 9

o Introduccin...................................................................................................... 9
o Creacin de un nuevo Proyecto ..................................................................... 9
o Crear modelos UML ...................................................................................... 10
o Estructura del modelo ................................................................................... 10

3. Diagramas y Elementos UML .................................................................................. 12

o Introduccin.................................................................................................... 12
o Elementos UML bsicos ................................................................................ 12
o Diagrama de Paquetes................................................................................... 13
o Diagrama de Requisitos ................................................................................ 14

Formateo automtico y manual de diagramas ............................. 18
o Diagrama de Casos de Uso ........................................................................... 19
o Diagrama de Actividad ................................................................................. 28

Tecnologa QuickLink ........................................................................ 30
o Diagrama de Clases ....................................................................................... 31
o Diagrama de Secuencia (o de interaccin).................................................. 34

Cmo crear un Diagrama de Secuencia ......................................... 35

Cmo trabajar adecuadamente con los Diagramas
de Secuencia....................................................................................... 39
o Diagrama de Comunicacin (o de colaboracin) ...................................... 56
o Diagrama de Interfaz de Usuario................................................................. 59

Modelizacin de la navegacin entre pantallas............................ 62
o Otros diagramas ............................................................................................. 63

Diagrama de Despliegue.................................................................. 63

Diagrama de Mquina de estados .................................................. 65

Diagrama de Mantenimiento........................................................... 66

Diagrama de Mapas Mentales......................................................... 66

Otros diagramas ................................................................................ 68
o Extensiones UML. Estereotipos y Valores Etiquetados ............................ 69
o Personalizacin y otras operaciones con diagramas y
elementos UML .............................................................................................. 72

Mantenimiento de propiedades definibles por el usuario
(requerimientos, restricciones, estados, escenarios)................. 72

Pg 3 de 213
 Enterprise Architect
Manual prctico

Representacin del estado de los elementos mediante colores .. 75

Asignar un diagrama por defecto................................................... 76

Localizacin automtica de elementos en el rbol del
repositorio y en los diagramas ........................................................ 80

Validacin de los modelos ............................................................... 81

4. Modelizacin de datos .............................................................................................. 82

o Introduccin.................................................................................................... 82
o Creacin de tablas .......................................................................................... 82
o Propiedades de las tablas .............................................................................. 83
o Creacin de columnas.................................................................................... 83
o Claves Ajenas (Foreign Keys) ......................................................................... 84
o ndices y Triggers ........................................................................................... 87
o Tipos de datos para los distintos SGBDs .................................................... 88
o Ingeniera inversa de datos mediante ODBC............................................. 90
o Generacin DDL............................................................................................. 91

5. Transformaciones MDA e Ingeniera de cdigo fuente ..................................... 93

o Introduccin.................................................................................................... 93
o Tipos de datos para los diferentes lenguajes.............................................. 96
o Generacin de cdigo fuente a partir de un Modelo ................................ 96
o Parametrizacin de la Ingeniera de Cdigo .............................................. 99
o Ingeniera inversa partir de cdigo fuente o binarios ............................. 100
o Creacin automtica de Diagramas de Secuencia a partir
de cdigo fuente ........................................................................................... 102

6. Gestin de Proyectos ............................................................................................... 108

o Introduccin.................................................................................................. 108
o A nivel global................................................................................................ 108
o A nivel de Elemento o Paquete .................................................................. 110
o Soporte a las pruebas ................................................................................... 113

7. Exportacin e importacin...................................................................................... 114

o Introduccin.................................................................................................. 114
o XMI................................................................................................................. 114
o Tablas de informacin de referencia.......................................................... 115
o Exportacin e Importacin de paquetes ................................................... 117

8. Gestin de la configuracin en Enterprise Architect ........................................ 119

o Introduccin.................................................................................................. 119

Pg 4 de 213
 Enterprise Architect
Manual prctico

o Control de Versiones en Enterprise Architect.......................................... 119

Creacin de lneas de base ............................................................. 119

Comparacin entre versiones ........................................................ 120
o Conexin de Enterprise Architect con herramientas de gestin de la
configuracin: Ejemplo AccuRev............................................................... 122

Configuracin AccuRev ................................................................. 122

Configuracin Enterprise Architect.............................................. 123

Configuracin del Paquete Controlado ....................................... 124

9. Seguridad del proyecto ........................................................................................... 127

o Introduccin.................................................................................................. 127
o Activacin de la seguridad del proyecto .................................................. 127
o Gestin de roles y permisos........................................................................ 128
o Bloqueo de elementos.................................................................................. 131

10. Repositorios en Base de Datos .............................................................................. 134

o Introduccin.................................................................................................. 134
o Creacin del Repositorio ............................................................................. 134
o Transferencia de datos al Repositorio ....................................................... 136
o Conexin de los puestos con el Repositorio ............................................. 137

11. Documentacin HTML............................................................................................ 140

o Introduccin.................................................................................................. 140
o Plantillas ........................................................................................................ 140
o Generacin de documentacin HTML...................................................... 143

12. Documentacin RTF ................................................................................................ 146

o Introduccin.................................................................................................. 146
o Plantillas ........................................................................................................ 146
o Opciones de generacin de la documentacin......................................... 151
o Parametrizacin del lenguaje ..................................................................... 154
o Generacin de documentacin RTF........................................................... 155
o Documentos virtuales.................................................................................. 156
o Linked Documents .......................................................................................... 158
o Conexin con Microsoft Word. Macrodocumentos ................................ 160
o Otros informes .............................................................................................. 162

13. Trazabilidad y consistencia.................................................................................... 163

o Introduccin.................................................................................................. 163
o Matrices de trazabilidad.............................................................................. 163

Pg 5 de 213
 Enterprise Architect
Manual prctico

o Representacin grfica de la trazabilidad de elementos. Anlisis de

impacto de los cambios ............................................................................... 167

14. Auditora.................................................................................................................... 170

o Introduccin.................................................................................................. 170
o Descripcin de la ventana Audit Settings .................................................. 171
o Descripcin del men principal de Auditora ......................................... 173

15. Patrones UML ........................................................................................................... 176

o Introduccin.................................................................................................. 176
o Inclusin de un Patrn en el Modelo......................................................... 176
o Creacin de un Patrn ................................................................................. 178

16. Perfiles UML ............................................................................................................. 180

o Introduccin.................................................................................................. 180
o Creacin de un Perfil UML ......................................................................... 180

17. Integracin MDG ..................................................................................................... 185

o Introduccin.................................................................................................. 185
o Integracin MDG con Eclipse..................................................................... 186

Instalacin de MDG Integration for Eclipse ................................... 186

Conexin de Proyectos ................................................................... 188
o Integracin MDG con Visual Studio 2005................................................. 193

Instalacin de MDG Integration for Visual Studio 2005................ 193

Conexin de Proyectos ................................................................... 194

18. Caractersticas adicionales...................................................................................... 202

o Vista Element List .......................................................................................... 202

o Foro de discusin ......................................................................................... 204
o Estadsticas del proyecto ............................................................................. 206
o Estimacin por Puntos de Casos de Uso................................................... 207

19. ANEXO I: Enunciado del ejercicio prctico Gestin de Proyectos ............. 209

Pg 6 de 213
 Enterprise Architect
Manual prctico

1. Introduccin

Objetivo y alcance del manual

Enterprise Architect es una potente herramienta case orientada a la ingeniera de

software.

Se enmarca en los departamentos de TI de las organizaciones que desempeen labores

de desarrollo de software, y su utilizacin puede variar entre la simple creacin de
diagramas UML hasta la gestin completa del proceso de desarrollo de la organizacin.

Por ello, en una primera aproximacin, conviene definir el alcance que daremos a la
herramienta en nuestro entorno, que inicialmente puede limitarse a la modelizacin de
ciertos subsistemas o a la documentacin de algunos productos, y que podremos ir
ampliando progresivamente hasta hacer que prcticamente la totalidad de nuestra
metodologa o proceso de desarrollo del software se vea soportado en mayor o menor
medida por esta herramienta.

Este manual contempla, de un modo ms didctico que exhaustivo, aquellas

caractersticas que hacen de Enterprise Architect una herramienta muy interesante de
cara al desempeo de las tareas mencionadas, dando una visin general de manera que
sea el lector quien realmente decida en qu aspectos desea profundizar, una vez
conocido el entorno de trabajo y las posibilidades reales de la aplicacin.

En resumen; a lo largo del presente manual vamos a trabajar con tres elementos a la
vez. De un lado, trataremos el contenido fundamental, que es Enterprise Architect. De
otro, nos apoyaremos en dos patas fundamentales y sin las cuales es imposible
entender completamente la naturaleza de una herramienta de este tipo: UML como
lenguaje de modelizacin y el Proceso o Metodologa de desarrollo, como sistema de
organizacin de etapas y modelos del proyecto.

Aunque el detalle de estas dos ltimas no es el objetivo principal de este manual, s

precisaremos hacer uso de ellas para dotar a nuestros modelos de una semntica
coherente (UML) y a nuestro repositorio de una consistencia y capacidad acorde a los
actuales procesos y metodologa de desarrollo de software.

Pg 7 de 213
 Enterprise Architect
Manual prctico

Interfaz de trabajo

El aspecto de la herramienta, una vez la iniciamos, es el siguiente:

1 2

En este entorno de trabajo hay que destacar tres secciones principales: la barra de
herramientas o Toolbox (1), la seccin de diagramas (2) y el rbol del proyecto o Project
Browser (3).

La barra de herramientas contiene aquellos los elementos UML que emplearemos a la

hora de modelar el sistema.

La seccin de diagramas contendr todos aquellos diagramas y figuras que se vayan

creando mediante el lenguaje UML y que describirn la estructura y funcionamiento
del sistema.

El rbol del proyecto es una parte vital, ya que es la que nos proporcionar la
estructura de trabajo y de organizacin de los elementos del sistema. Esta seccin es la
que adaptaremos a nuestro proceso de desarrollo o, en su defecto, al conjunto de
productos que deseamos obtener tal y como se ver en el siguiente captulo.

Pg 8 de 213
 Enterprise Architect
Manual prctico

2. Gestin de Modelos

Introduccin

La creacin de la estructura de productos de un proyecto en Enterprise Architect es

una de las actividades fundamentales para poder obtener todo el partido del entorno.
Aunque en una aplicacin real de Enterprise Architect la estructura de productos
vendr determinada por la plantilla (repositorio) adecuada (o al menos as debiera ser),
en esta seccin veremos los mecanismos esenciales para construir dicha estructura.

Este esfuerzo debe interpretarse como el necesario para poder, ms adelante, abordar
un conjunto de actividades dentro de la organizacin que permita crear una o ms
plantillas que permitan reflejar la realidad del proceso de desarrollo en dicha
organizacin.

Creacin de un nuevo Proyecto

En Enterprise Architect existen diversos caminos para crear un proyecto. Las

combinaciones dependen del objetivo que nos marquemos. En la actualidad esta
funcionalidad se puede ejecutar a travs de dos opciones:

Create a new Project

Copy a Base Model

Desde el comienzo, Enterprise Architect ha basado la creacin de proyectos en la

utilizacin de una plantilla o template, que no era ms que un proyecto que se usa como
referencia para crear una estructura de trabajo.

Adems, a partir de la versin 6.0, existe la posibilidad de crear un proyecto vaco que
permite la incorporacin de estructuras parciales que pueden ser seleccionadas a
conveniencia a partir de un catlogo preexistente.

Para nuestro ejemplo, vamos a comenzar a trabajar sobre un proyecto vaco, por lo que
seleccionaremos la opcin Create a new Project y, en el asistente que nos aparecer a
continuacin, no seleccionaremos ningn modelo que incorporar a nuestro proyecto:
seremos nosotros quienes, a lo largo del desarrollo del manual, vayamos incorporando
productos y modelos de manera que al final tengamos una estructura que bien sirva de
plantilla para futuros proyectos.

Pg 9 de 213
 Enterprise Architect
Manual prctico

Crear modelos UML

En el caso de que no tengamos muy clara nuestra estructura del repositorio de

productos que deseamos crear, podemos hacer uso del asistente que la herramienta
inicia cuando creamos un proyecto nuevo (opcin Create a new Project). Se muestra la
siguiente ventana:

En ella podemos indicar qu vistas y modelos deseamos aadir a nuestro Project

Browser. De cada una de estas vistas colgarn posteriormente los productos y modelos
que vayamos creando.

Si por el contrario queremos trabajar sobre un proyecto en blanco y crear nosotros

mismos nuestra estructura de vistas y modelos, podemos prescindir del asistente y
elaborar un repositorio como el que iremos construyendo en los siguientes apartados.

Estructura del Modelo

En primer lugar, vamos a dar un nombre al Nodo Raz (por defecto Model), que ser el
nombre del proyecto: Proyecto Ejemplo.

Para ello, con el botn derecho sobre el Modelo, seleccionaremos Rename Model

Pg 10 de 213
 Enterprise Architect
Manual prctico

A continuacin, y mediante el botn

New Package iremos aadiendo
aquellas vistas o fases del proceso que nos
interesen.

La eleccin del Icon Style no tiene mayor trascendencia para el resultado final, por lo
que lo dejamos a eleccin del lector.

Crearemos, de momento, los siguientes modelos con sus correspondientes

subpaquetes:

CATLOGO DE REQUISITOS
1. Requisitos Funcionales
2. Requisitos No Funcionales
ANLISIS
1. Modelo de Negocio
2. Modelo de Dominio

NOTA: Podemos cambiar el orden de los paquetes

creados mediante los botones:

Una vez hecho esto, ya disponemos de una estructura bsica de trabajo sobre la cual
comenzar a modelar el sistema mediante diagramas que contendrn elementos UML.

Pg 11 de 213
 Enterprise Architect
Manual prctico

3. Diagramas y Elementos UML

Introduccin

Elementos UML o Artefactos son el conjunto de smbolos que el estndar UML pone a
nuestra disposicin para realizar la descripcin de un sistema. Al tratarse UML de un
lenguaje de modelizacin, los elementos y las relaciones entre ellos tienen una
SINTAXIS y una SEMNTICA.

Los Diagramas UML son la representacin grfica de los Elementos y las relaciones
existentes entre ellos.

Existe multitud de elementos diferentes, si bien dado el carcter didctico del manual,
nos centraremos a durante el desarrollo de los captulos en mostrar solo aquellos cuya
relevancia y utilidad sean principales.

Elementos UML bsicos

Algunos de ellos son:

En Enterprise Architect existen dos maneras de crear elementos UML. Una de ellas es
dibujarlos en un diagrama utilizando para ello el Toolbox. Otra, es crearlos
directamente en el Project Browser sin que tengan representacin en ningn diagrama.

Para ilustrar estas opciones, vamos a trabajar sobre la creacin del Catlogo de
Requisitos mediante un diagrama que represente grficamente el conjunto de
requisitos de una aplicacin de ejemplo.

Pg 12 de 213
 Enterprise Architect
Manual prctico

Diagrama de Paquetes

Desde el Project Browser, disponemos de un botn New Diagram que nos muestra un
cuadro de dilogo como el mostrado aqu.

En primer lugar, y a efectos puramente estticos y organizativos, vamos a crear un

diagrama de Paquetes (UML Structural  Package) que cuelgue de la vista Catlogo de
Requisitos de nuestro proyecto de prueba. Por defecto, los diagramas que creemos
tendrn el mismo nombre que el paquete que los contiene.

Seguidamente, arrastraremos los paquetes contenidos en la Vista al Diagrama recin

creado:

Una de las propiedades que tienen los diagramas de Paquetes es que los paquetes que
aparecen en ellos permiten navegar mediante doble clic al primer diagrama que se
encuentre dentro del paquete, en caso de haber alguno. Como de momento no
tenemos ningn diagrama dentro de los paquetes 1. Requisitos Funcionales y 2.
Requisitos No Funcionales, nuestro siguiente paso ser crear los diagramas que nos
permitan mostrar los requisitos de la aplicacin.

Pg 13 de 213
 Enterprise Architect
Manual prctico

Diagrama de Requisitos

De nuevo pulsaremos el botn New Diagram, y seleccionaremos Extended 

Requirements

Ya tenemos disponible un diagrama vaco donde ir mostrando los requisitos de la

aplicacin, que iremos creando sobre la marcha.

En Enterprise Architect existen dos maneras de crear elementos. Una de ellas, es desde
el Project Browser, mediante el botn New Element (CTRL+M). La otra, es dibujndolos
directamente en un diagrama haciendo uso del Toolbox. En este caso, utilizaremos el
toolbox para dibujar un requisito en nuestro nuevo diagrama, como se ve en la siguiente
figura:

Pg 14 de 213
 Enterprise Architect
Manual prctico

Acto seguido, se nos muestra su ventana de propiedades lista para que editemos
aquellas que consideremos necesario. Un repaso a la ventana, hace que nos fijemos
principalmente en:

Pestaa Properties:

Short Descripcin: El nombre el

requisito, o su codificacin en caso de
existir.
Status: El estado (aprobado, propuesto,
obligatorio)
Type: El tipo (Funcional, No
funcional)
Details: La descripcin detallada del
requisito.
Otros: Dificultad, prioridad, fase,
versin, autor

Pestaa Files:

File Path: La ruta a un archivo externo

(como un hipervnculo a un archivo
con informacin adicional, por
ejemplo).

Type: Para indicar si se trata de un

archivo local o una direccin URL.

Notes: Notas acerca de este archivo

externo.

Se pueden incluir tantos archivos

externos como se desee, mediante los
botones New y Save. El botn
Launch abrir el archivo
seleccionado utilizando la aplicacin
asociada por defecto en Windows
para el tipo de archivo de que se trate.

Pg 15 de 213
 Enterprise Architect
Manual prctico

Todo lo que acabamos de ver en relacin a la ventana de propiedades del elemento

Requirement es aplicable a la prctica totalidad de elementos UML con que vamos a
trabajar.

Antes de cerrar la ventana de propiedades, nicamente cambiaremos el nombre del

requisito a RF001.Requisito Funcional 1. Despus, y siguiendo el mismo mtodo,
crearemos otro requisito llamado RF002.Requisito Funcional 2.

Con los requisitos recin creados, vamos a establecer una relacin UML entre ellos,
utilizando el Toolbox y concretamente la relacin Aggregation. Para ello, basta con
seleccionar la herramienta y trazar una lnea del origen al destino, teniendo en cuenta
que en el destino se dibujar la punta de flecha.

NOTA: En UML la notacin de las relaciones vara en comparacin con las notaciones
estructuradas. En UML se habla de relaciones Cliente-Servidor. Para el caso que nos
atae, la relacin se leera como El requisito 2 es parte del requisito 1.

Destino de la relacin
(Servidor)
Punta de flecha

Origen de la relacin
(Cliente)

Otros tipos de relacin muy comunes en UML son las siguientes:

Composicin: Herencia: Realizacin: Asociacin: Sin Dependencia:

Es un tipo Muestra la Origen es cardinalidad ni Indica que un
especial de herencia entre realizado por direccin, elemento
agregacin. Se elementos. Se lee Destino o nicamente depende de otro.
lee Origen Origen hereda Destino realiza seala la Se lee Origen
compone a de Destino. a Origen. relacin o depende de
destino o Representa una asociacin entre Destino.
Destino est implementacin elementos.
compuesto por de un elemento.
Origen.

Pg 16 de 213
 Enterprise Architect
Manual prctico

Crearemos un nuevo diagrama junto con otros dos requisitos, esta vez dentro del
paquete 2. Requisitos No Funcionales con los nombres RNF001.Requisito No
Funcional 1 y RNF002.Requisito No Funcional 2. Esta vez, en lugar de utilizar el
toolbox, podemos hacerlo desde el botn del Project Browser New Element (CTRL+M) e
indicando en la ventana emergente:

NOTA: Las opciones que muestra esta ventana son tiles a la hora de generar muchos
elementos a la vez, de modo que:

Open Properties Dialog on Creation: Abre la ventana de propiedades del

elemento recin creado una vez pulsemos OK. Dejarla activada o no depender
de si vamos a querer ir modificando alguna propiedad en el momento de la
creacin, o si queremos elementos con las propiedades por defecto.
Close dialog on OK: Cierra esta ventana. En caso de querer crear mltiples
elementos, es mejor dejarla desactivada.
Add to Current Diagram: Muestra el elemento creado en el diagrama actual.
Normalmente se desactiva, ya que de querer mostrarlos en el diagrama
hubiramos utilizado el Toolbox directamente.

Una vez creados los elementos en el Project Browser, los arrastraremos al diagrama para
que se muestren en l. Al soltarlos, veremos la siguiente ventana:

Pg 17 de 213
 Enterprise Architect
Manual prctico

Siempre que NO estemos trabajando con objetos, es decir, con instancias de elementos,
utilizaremos la opcin as Simple Link. Solo en el caso de tratarse de un objeto aquello
que deseamos mostrar, seleccionaremos as instance of Element (Object) (por ejemplo,
en caso de representar un objeto perteneciente a una clase en un diagrama de
secuencia).

Con todo lo visto, estaramos en condiciones de poder realizar un Catlogo de

Requisitos que contenga los diagramas, elementos y relaciones necesarios para
describir los requisitos del enunciado del Anexo I de este manual.

Formateo Automtico de diagramas:

Enterprise Architect dispone de una utilidad de formateo automtico de

diagramas (auto layout), que intenta dejar con el mejor aspecto el diagrama con
que estemos trabajando. Es decir, elimina cruces entre lneas, jerarquiza de
arriba abajo en funcin de las relaciones, etc Se puede hacer uso de esta
funcin mediante el men Diagram  Layout Diagram.

Formateo Manual de diagramas:

Tambin es posible que en muchos casos queramos colocar los elementos de tal
modo que puede sucedernos que algunas lneas se crucen con otras y pasen por
encima de otros elementos. Esto se puede solucionar haciendo que las lneas, en
vez de una ruta directa, adopten formas dobladas. Existen varias opciones
para gestionar esto:

Pg 18 de 213
 Enterprise Architect
Manual prctico

Una de ellas es seleccionando la lnea y con el botn derecho seleccionar, dentro

de Line Style, alguna de las opciones que existen:

Direct: dibuja la lnea recta entre los dos elementos.

Auto Routing: Crea una lnea con esquinas automticamente
Custom Line: Permite al usuario definir los puntos donde se dobla la lnea, las
distancias de los segmentos, etc En caso de utilizar esta opcin, hay que
complementarla con otros dos comandos que se obtienen igualmente con el
botn derecho sobre una lnea definida como Custom Line
Blend line at cursor: Dobla la lnea donde est situado el cursor.
o sobre un punto de doblado:
Straighten line at cursor: Elimina el doblez y crea un nico segmento.

NOTA: Solo para ciertos tipos de relacin, existe adems el estilo Bezier que consiste en
una lnea curva entre los elementos.

Una vez demos por acabado el diagrama, estaremos dispuestos a, en el siguiente

apartado, desarrollar un Modelo de Negocio a partir de los requisitos detectados.

Diagrama de Casos de Uso

Para describir el Modelo de Negocio vamos a utilizar el diagrama de casos de uso, que
nos permitir mostrar la aplicacin y su entorno en principio desde dos puntos de
vista: contexto y negocio.

No obstante, este diagrama le utilizaremos principalmente cuando vayamos a describir

los Casos de Uso de cada uno de los subsistemas.

Diagrama de Contexto: En el diagrama de contexto mostraremos un nico caso

de uso que representar la aplicacin o sistema a desarrollar, y a su alrededor todos
aquellos actores externos al sistema (personas u otros sistemas) que interactan con l.

Pg 19 de 213
 Enterprise Architect
Manual prctico

Modelo de Negocio Detallado: En este diagrama, haremos una primera

aproximacin a lo que sern los subsistemas de anlisis, creando un caso de uso para
cada subsistema detectado y relacionando los subsistemas entre s y con los actores de
negocio que vayan a intervenir.

En primer lugar, crearemos en el Project Browser un nuevo paquete, dentro de la Vista

ANLISIS, denominado Modelo de Negocio, del que colgarn otros dos
subpaquetes denominados 1. Diagrama de Contexto y 2. Modelo de Negocio
Detallado.

Por ltimo, crearemos dentro del subpaquete 1. Diagrama de Contexto un diagrama

obtenido de UML Behavioral  Use Case, todo ello como se muestra en la siguiente
figura:

A continuacin, seleccionaremos del Toolbox el elemento Use Case y lo mostraremos

en el diagrama, crendose adems automticamente en el Project Browser.

Pg 20 de 213
 Enterprise Architect
Manual prctico

Veremos que, como siempre que creamos un nuevo elemento desde el Toolbox, se nos
muestra su ventana de propiedades. En este caso en particular, debemos cambiar el
Stereotype, escribiendo <<business use case>> para de este modo estereotipar al Caso de
Uso como <<Caso de Uso de Negocio>>.

Haciendo esto, el aspecto grfico del caso de uso vara un poco,

aadindose una lnea diagonal en la parte inferior.

Otro de los aspectos a analizar de la ventana de propiedades del Caso de Uso, es que
existen ms fichas que en la ventana de propiedades del Requisito con la que
trabajamos antes. Veamos por tanto qu otras propiedades podemos configurar para
estos elementos.

En la ficha General, destacamos:

Name: Nombre del Caso de Uso.

Stereotype: Estereotipo aplicado al elemento.
Status, Complexity: Estado y complejidad.
Notes: Descripcin de la funcionalidad del caso de uso.

Pg 21 de 213
 Enterprise Architect
Manual prctico

En la ficha Require:

Requirement: Nombre del requisito interno para este caso de uso.

Type: Tipo de requisito interno.
Status, Difficulty, Priority: Estado, dificultad y prioridad del requisito interno.

Con los botones New y Save podemos ir aadiendo requisitos internos.

En la ficha Constraints:

Pg 22 de 213
 Enterprise Architect
Manual prctico

Constraint: Nombre de la restriccin del elemento.

Type, Status: Tipo y estado de la restriccin. En tipo, indicando Pre-Condition y
Post-Condition podemos definir las pre y postcondiciones del Caso de Uso.

Con los botones New y Save podemos ir aadiendo restricciones.

En la ficha Link:

Aqu aparece automticamente una lista de todas las relaciones, de cualquier tipo, que
este elemento tiene con otros.

En la ficha Scenario:

Scenario: Nombre del escenario del caso de uso.

Type: Tipo del escenario del caso de uso (principal, alternativo, error).

Con los botones New y Save podemos ir aadiendo escenarios.

Por ltimo, en la ficha Files, al igual que se vimos en los Requisitos, aparecen
aquellos ficheros externos que deseemos enlazar al elemento.

Pg 23 de 213
 Enterprise Architect
Manual prctico

Como nica propiedad que modificaremos en el Caso de Uso de Negocio recin creado
ser el Nombre, por CUN01.Gestin de Peticiones y Proyectos.

Ahora llega el momento de disear el entorno en el que existe el sistema, es decir,

aadir Actores de Negocio que de un modo u otro interaccionen con el sistema.

Desde el Toolbox, del mismo modo que hemos utilizado para otros elementos,
crearemos en el diagrama los siguientes Actores de Negocio (con es estereotipo
<<business actor>>): AN01.Departamento, AN02.Organizacin, AN03.Informtica.

Hecho esto, nicamente falta indicar las relaciones que existen entre los actores y el
sistema, mediante una relacin Use.

Tanto el Diagrama de Contexto como el Modelo de Negocio Detallado son

representaciones de muy alto nivel de abstraccin. Vamos ahora a ver cmo sera el
Modelo de Negocio Detallado de nuestra aplicacin, fruto de explotar el Caso de Uso
de Negocio Gestin de Peticiones y Proyectos en aquellos subsistemas que lo
componen.

Del modo habitual, crearemos un nuevo Paquete que cuelgue del ANLISIS
denominado Modelo de Negocio Detallado, y dentro de l crearemos un nuevo
diagrama del tipo Use Case con el mismo nombre que el paquete que lo contiene.

Pg 24 de 213
 Enterprise Architect
Manual prctico

Con el nuevo diagrama a la vista, incluiremos desde el Toolbox tres Casos de Uso de
Negocio denominados: CUN02.Gestin de Peticiones, CUN03.Gestin de Proyectos y
CUN04.Gestin de Partes de Trabajo.

Hecho esto, localizaremos a cada uno de los Actores anteriormente creados, que se
encuentran en el Paquete donde se crearon: Diagrama de Contexto. Desde ah, los
arrastraremos al nuevo diagrama en el modo as Simple Link y trazaremos las
relaciones Use que cada actor tenga con cada subsistema. El resultado sera:

Ntese que bajo los Actores representados aparece el texto (from ) al ser elementos
obtenidos de otro paquete distinto al del diagrama, es decir, elementos extranjeros.
Existe una opcin en la herramienta que deshabilita o habilita la inclusin de ese texto,
que a veces puede no resultarnos de ninguna utilidad (doble clic en cualquier parte del
diagrama, y desactivar la opcin Show Name Space en la ficha Diagram).

Bien, con esto ya tenemos nuestro Modelo de Negocio casi finalizado. Ni que decir
tiene que habra que documentar los campos Notes y dems propiedades de cada
elemento, para describir su funcionalidad, alcance, etc si bien en este manual
nicamente nos hemos centrado en la creacin y representacin grfica de los
elementos que intervienen.

Pg 25 de 213
 Enterprise Architect
Manual prctico

Como siguiente paso, podramos comenzar a crear paquetes individuales para cada
subsistema de anlisis, dentro de los cuales describiremos ms a fondo la
funcionalidad del sistema a travs de Casos de Uso con sus respectivos Escenarios. El
nivel de descomposicin de cada Caso de Uso de Negocio en Casos de Uso simples
vendr determinada por la granularidad que se defina para cada proyecto.

Por lo tanto, siguiendo con el ejemplo, tendramos:

Veamos la descripcin, mediante casos de uso, del subsistema Gestin de Peticiones

Pg 26 de 213
 Enterprise Architect
Manual prctico

Es posible que para una descripcin de alto nivel como es el Modelo de Negocio, no
sea necesario, pero, ya a este nivel, s hay que hacer hincapi en describir los Escenarios
de los Casos de Uso del Sistema. Esta tarea la haremos desde la ventana de
propiedades del Caso de Uso, en la ficha Scenario.

Como viene siendo habitual en este tipo de ventanas, mediante los botones New y Save
vamos creando los diferentes escenarios que haya que describir, pudiendo ordenarlos
con los botones que representan las manos.

Describiremos, al menos, como regla general, el escenario principal de cada Caso de

Uso, pudiendo describir escenarios alternativos cuando sea preciso en funcin del
estudio de la funcionalidad del caso de uso.

El tipo de escenario (bsico, alternativo, etc) se selecciona desde la lista desplegable

Type. Veremos ms adelante como podemos personalizar estos valores a otros que se
adapten mejor a nuestro Proceso de desarrollo.

Se obvian en este Manual las descripciones de todos los Escenarios y Subsistemas,

estando disponibles en el archivo con el ejemplo completo.

Pg 27 de 213
 Enterprise Architect
Manual prctico

Existe tambin la posibilidad de documentar mucho ms a fondo la funcionalidad y

comportamiento de los Casos de Uso. Para ello, podremos valernos, entre otros, del
diagrama que veremos a continuacin y que podremos asociar a cada caso de uso en
particular para describir su funcionalidad concreta.

Diagrama de Actividad

El diagrama de Actividad es conocido tambin como el clsico Flujograma en el que

muestran procesos y condiciones que marcan la lgica del sistema y dirigen el flujo de
ejecucin del programa.

Supongamos por tanto que queremos describir con ms detalle, mediante este tipo de
representacin, la funcionalidad de uno de esos casos de uso con los que hemos
trabajado.

En primer lugar, lo que haremos ser asociar el diagrama de Actividad al Caso de Uso
concreto que describe. Para ello, seleccionando el Caso de Uso CU03.Abrir Proyecto,
pulsaremos el botn derecho del ratn y seleccionaremos la opcin Add  Activity
Diagram

Veremos que nos aparece colgado debajo del Caso de Uso de Negocio Seleccionado, un
nuevo diagrama listo para representar su funcionalidad:

Pues ya sin ms, elaboraramos como viene siendo costumbre, el diagrama haciendo
uso del Toolbox para insertar elementos y relaciones.

Pg 28 de 213
 Enterprise Architect
Manual prctico

Comenzando por una elemento Initial:

Despus un elemento Activity

Y utilizando Control flow para dirigir el flujo de

control de las actividades.

Para las decisiones, utilizaremos Decision en

cuyos flujos pondremos un nombre Si y No
para indicar los distintos caminos de la lgica del
programa.

Y por ltimo el elemento Final para marcar la

ltima actividad.

Pg 29 de 213
 Enterprise Architect
Manual prctico

Tecnologa QuickLink

Enterprise Architect dispone de una utilidad que simplifica la gestin de

relaciones entre elementos, llamada QuickLink.

Cuando seleccionamos un elemento, en la esquina superior derecha de este

aparece una flecha flotante desde la que podemos arrastrar hasta otro
elemento. Una vez soltemos el botn del ratn sobre el elemento de destino,
aparece un dilogo flotante que nos permite seleccionar el tipo de relacin que
queremos crear.

En caso de que soltemos el botn del ratn sobre cualquier zona vaca del
diagrama, lo que nos propondr la herramienta es la creacin de un nuevo
Elemento como destino de la relacin, y a continuacin un tipo de relacin
entre ambos.

Pg 30 de 213
 Enterprise Architect
Manual prctico

Diagrama de Clases

El diagrama de Clases es uno de los principales diagramas de UML. En l se pueden

representar Modelos de Clases y Modelos de Conceptuales, Lgicos y Fsicos de Datos.

Salvo excepciones, en un Diagrama de Clases nicamente aparecen Clases, Interfaces y

relaciones entre ellas.

El Modelo de Clases de un sistema est en continuo mantenimiento mientras el sistema

est siendo analizado y diseado. Podemos considerar por lo tanto que, durante el
proceso de desarrollo, el catlogo de Clases de un sistema est en constante ampliacin
y modificacin. De hecho, muchas Clases (o atributos u operaciones de ellas) nos
surgirn por induccin como necesarias para que el sistema cumpla con una
funcionalidad concreta.

Con todo esto queremos decir que la construccin de un Modelo de Clases de Anlisis
o de Diseo no es un proceso lineal y aislado, sino una parte del sistema que se ir
enriqueciendo a lo largo de todo el proceso de desarrollo. Por ello, las Clases que
vamos a crear en este apartado quedarn parcialmente incompletas, a la espera de que
otros procesos las vayan complementando a lo largo del anlisis del sistema.

Siguiendo con el ejemplo que estamos desarrollando, vamos a utilizar el paquete en la

vista ANLISIS del Project Browser denominado Modelo de Dominio del que
colgaremos un diagrama de Clases del mismo nombre.

Y en el diagrama, crearemos nuestra primera Clase CLD01.Peticin.

Una vez creada, nos iremos a su ventana de Propiedades para observar en ella las
diferencias con respecto a otros Elementos UML.

Pg 31 de 213
 Enterprise Architect
Manual prctico

En la ficha General:

Language: A pesar de que aparece en otras ventanas de propiedades, carece de sentido

excepto cuando hablamos de Clases. En caso de que vayamos a hacer uso de las
funcionalidades de la herramienta asociadas al cdigo fuente, esta propiedad nos
indica para qu lenguaje est pensada la implementacin de la Clase. Dependiendo del
lenguaje que seleccionemos, entre otras muchas cosas dispondremos de un abanico u
otro de tipos de datos para definir los Atributos de la Clase.

En la ficha Detail:

Pg 32 de 213
 Enterprise Architect
Manual prctico

En esta ventana nicamente llamaremos la atencin sobre los dos botones que nos
conducen a la definicin de Atributos y Operaciones de la Clase:

Attributes: Funcin tambin accesible con la Clase seleccionada en el diagrama,

pulsando F9. Nos muestra la ventana de definicin de Atributos de la Clase:

Dentro de esta ventana, iremos creando todos los atributos de la Clase. Para ello,
comnmente habr que indicar un Name, Type, Scope y Notes para cada atributo, e ir
salvndolos consecutivamente mediante los botones New y Save.

Si la clase va a ser transformada a cdigo en el futuro, conviene mantener una sintaxis

correcta en los Name de los Atributos. Los tipos de datos (int, byte, char) disponibles
estn en funcin del lenguaje de programacin seleccionado para la clase.

Operations: Funcin tambin accesible con la Clase seleccionada en el diagrama,

pulsando F10. Nos muestra la ventana de definicin de Operaciones (Mtodos) de la
Clase. Es importante resear que las Clases participantes en el Modelo de Dominio no
han de tener Operaciones, aunque veremos la ventana a modo didctico, ya que al fin y
al cabo estamos estudiando el diagrama de clases, que utilizaremos tanto para el
Modelo de Dominio como para el Modelo de Clases de Anlisis, donde las clases s
tendrn Operaciones.

Pg 33 de 213
 Enterprise Architect
Manual prctico

Dentro de esta ventana, iremos creando todas las operaciones de la Clase. Para ello,
comnmente habr que indicar, de cada operacin, el Name, Scope y Notes, y, caso de
haberlos unos Parameters (que definiremos utilizando el botn Edit), Return Type,
Abstract, Pure, etc para cada atributo, e ir salvndolos consecutivamente mediante los
botones New y Save.

Podemos describir adems el comportamiento de cada uno de los mtodos (mediante

pseudocdigo, por ejemplo) a travs de la ficha Behavior, as como las Pre y
Postcondiciones.

Diagrama de Secuencia (o de Interaccin)

Llegamos a una parte crtica del proyecto, que es la descripcin del comportamiento de
los objetos en tiempo de ejecucin. Esta descripcin se realiza para todos los Escenarios
de los Casos de Uso detectados, si bien este nivel de detalle puede ir en contra del
sentido comn o de las especificaciones de estilo de la compaa, debido al alto
volumen de trabajo que genera en entornos con muchos casos de uso. En cualquier
caso, es una tarea importantsima, en la que vamos fijarnos con detalle.

Pg 34 de 213
 Enterprise Architect
Manual prctico

Este apartado trata, por tanto, de abordar varios aspectos. Por un lado, los mecanismos
esenciales para construir diagramas de secuencia; por otro, encajar este tipo de
diagramas en un mtodo de trabajo, en el que el objetivo fundamental de dichos
diagramas es representar grficamente los Escenarios de los Casos de Uso.

Si se puede elegir, por qu decidimos usar el diagrama de secuencia?

En realidad tanto el diagrama de secuencia como el de comunicacin sirven a un

mismo objetivo: reflejar la interaccin de objetos necesaria para interpretar una
secuencia de acciones, con independencia del nivel de abstraccin que se elija para
dichos diagramas (no olvidemos que podemos afrontar esta tarea desde una
perspectiva de anlisis, ms abstracta, y desde una perspectiva de diseo, en la que se
orienta por completo al sistema final).

No obstante la manera de reflejar dicha secuencia es diferente; en el diagrama de

secuencia se muestra con mayor claridad el orden cronolgico; este es un factor muy
importante para decantarnos por dicho diagrama. Por otro lado, en Enterprise
Architect el tratamiento grfico, formal y tcnico que ofrece del diagrama de secuencia
es sensiblemente superior al ofrecido con el diagrama de comunicacin.

Por consiguiente, supongamos que, salvo justificadas excepciones, representaremos los

escenarios siempre mediante diagramas de secuencia.

Como crear un diagrama de secuencia

El proceso es el mismo que para cualquier otro diagrama. No obstante, hay que realizar
una serie de aclaraciones.

Opcin 1: Creacin de un diagrama de secuencia dentro de un Caso de Uso

En teora, dentro de un proceso formal orientado a casos de uso, el diagrama de

interaccin no tiene existencia propia, sino que depende de los escenarios de los casos
de uso: deberan existir tantos diagramas de interaccin como escenarios haya en los
casos de uso (aunque, como ya se ha mencionado, dicha exhaustividad puede ponerse
en entredicho en funcin a criterios y restricciones existentes en el proyecto o la
organizacin).

En Enterprise Architect, existe la posibilidad de vincular de manera directa uno o ms

diagramas a un elemento del Project Browser. De hecho, dependiendo del elemento (su
tipo) que seleccionemos en el rbol podramos asociarle un subconjunto determinado
de diagramas UML, de igual modo que hicimos en el apartado anterior con el
Diagrama de Actividad.

Pg 35 de 213
 Enterprise Architect
Manual prctico

Para el caso que nos ocupa, partimos de un caso de uso creado en el Project Browser.
Veamos cmo tenemos de nuevo la opcin de crear dentro del caso de uso los
diagramas vistos anteriormente. Seleccionamos el Caso de Uso y, con el botn derecho
del ratn, obtenemos el men contextual:

De nuevo podemos elegir cualquiera de los cinco, pero en general siempre

vincularemos a la realizacin de un caso de uso un diagrama de secuencia o de
comunicacin. Como ya hemos determinado en este apartado, asumimos que solo
emplearemos diagramas de secuencia salvo casos excepcionales; por tanto, si en la
pantalla anterior seleccionamos Sequence Diagram, obtenemos:

Pg 36 de 213
 Enterprise Architect
Manual prctico

Y aceptando:

Como puede verse, se ha creado un diagrama en blanco dentro del caso de uso
(vinculado a l) y tenemos el diagrama en pantalla dispuesto para comenzar.

Nota 1: El diagrama de secuencia, NO MUESTRA como en otros diagramas, su tipo y

su nombre en la lnea de estado superior. Esto es debido a que esa seccin, ser ocupada
por los nombres de los objetos que participarn en el diagrama.
Nota 2: En el diagrama de Casos de Uso en el que el Caso de Uso que vamos a describir
aparece dibujado, no se modifica la apariencia del Caso de Uso para indicar de algn
modo al usuario que ste contiene un diagrama por debajo. Para lograr esa
visualizacin, y la navegabilidad mediante doble clic desde el Caso de Uso al diagrama
que contiene, tendremos que seleccionarlo, y con el botn derecho seleccionar
Advanced Composite Element. Aparecer un smbolo en el caso de uso.

Opcin 2: Creacin de un diagrama de secuencia organizando la informacin en

paquetes

Aunque es el mtodo ms complicado, es probablemente el ms formal de cara a

abordar la creacin de los diagramas de secuencia asociados a los escenarios de los
casos de uso, sobre todo si dichos casos de uso se han elaborado creando varios
escenarios escritos asociados a cada uno de ellos.

En estos casos, o cuando se pretende organizar la informacin de manera coherente,

puede resultar ms adecuado organizar esta informacin mediante la creacin de
paquetes en el Project Browser y estableciendo algn tipo de trazabilidad de carcter
manual (a travs de los nombres) entre los casos de uso y los diagramas de secuencia
(de anlisis o de diseo) que representan grficamente los escenarios.

Pg 37 de 213
 Enterprise Architect
Manual prctico

Hay que recordar que el caso de uso en Enterprise Architect, contiene una estructura
de informacin sobre la que podemos definir por escrito cuantos escenarios deseemos
para ese caso de uso, pero dichos escenarios no tienen existencia propia en el Project
Browser. Esto dificulta enormemente establecer cualquier tipo de trazabilidad directa
entre el escenario escrito y el diagrama de secuencia que lo describe por lo que en el
mejor de los casos tendremos que establecer dicha relacin mediante una nomenclatura
adecuada.

Por todo ello, nuestro objetivo ser organizar lo mejor posible todo el repertorio de
diagramas de secuencia que existan en el proyecto. Si utilizamos un enfoque similar a
Mtrica o al Proceso Unificado, este bloque de informacin puede representarse bajo el
nombre genrico de Realizacin de un Caso de uso (conjunto total de diagramas de
secuencia, uno por escenario, que representan grficamente el comportamiento del
caso de uso).

Por tanto, una solucin puede ser crear un paquete en el Project Browser denominado
de forma similar (debera ser igual por motivos de trazabilidad) al caso de uso. Para
este caso, vamos a emplear las nomenclaturas propuestas por Mtrica 3: Anlisis de la
Realizacin de los Casos de Uso o Diseo de la Realizacin de los casos de Uso,
dependiendo del proceso o fase en el que se realizan los diagramas de secuencia y las
clases que se toman como referencia para instanciar a los objetos participantes.

Sea un proyecto en Enterprise Architect orientado a Mtrica 3; tendremos la siguiente

estructura:

Compuesta de: un paquete para cada Subsistema, un subpaquete para cada Caso de
Uso, y un Diagrama para cada Escenario de cada Caso de Uso.

Pg 38 de 213
 Enterprise Architect
Manual prctico

Por lo tanto, y a modo de resumen, existe una estructura que se ha creado para
organizar un sistema de informacin (paquete Modelo de Casos de Uso) que contiene
tres subsistemas debidamente identificados. Cada uno contiene los casos de usos
correspondientes a la funcionalidad que queremos describir en cada subsistema. La
organizacin en subsistemas de los casos de uso marca la organizacin del resto de los
productos.

Vamos a representar el diagrama de secuencia correspondiente al escenario o

escenarios del caso de uso CU02.Analizar Peticin (luego consultaremos como se ha
descrito ese escenario). Por tanto, hemos creado un paquete que represente el conjunto
de los diagramas de secuencia de todos los escenarios del sistema. En este caso,
adems, se trata de los diagramas de secuencia a nivel de anlisis, por lo que,
siguiendo la nomenclatura de Mtrica, vamos a crear el producto denominado:
Anlisis de la Realizacin de los Casos de Uso.

Hemos creado un paquete con el nombre del producto, precedido de la actividad en la

que se genera (recordemos que en este manual se indica el nmero de actividad por
motivos de claridad, pero no es necesario indicarlo en los proyectos reales). Como ya
hemos indicado, replicamos la estructura de Subsistemas que se ha definido
previamente para organizar el sistema, teniendo cuidado de que los nombres de los
paquetes sean exactamente iguales y se pueda realizar el seguimiento o trazabilidad
manual adecuado.

Puesto que vamos a reflejar la realizacin del caso de uso CU02.Analizar Peticin,
creamos dentro del subsistema al que pertenece el Caso de Uso un diagrama de
secuencia:

Se crea el diagrama vaco y se crea en el rbol la entrada correspondiente al diagrama

de secuencia con el mismo nombre que el caso de uso (como se ha dicho la
nomenclatura es simplemente una sugerencia; podran darse sistemas de numeracin
distintos en funcin de la complejidad del sistema, nmero de escenarios descritos por
caso de uso, etctera).

Como trabajar adecuadamente con los diagramas de secuencia

No existe un nico modo para la ejecucin de los diagramas de secuencia en Enterprise

Architect. Si embargo, es preciso conocer a fondo el mecanismo y las caractersticas del
proceso para asegurar la integridad de la informacin. Si se est trabajando segn una
metodologa como Mtrica o una adaptacin suya hay que considerar que se deben
establecer ciertas verificaciones con la informacin que se vaya reflejando en el
proyecto. Una de estas verificaciones, no por lgica deja de ser importante: todos los
objetos reflejados en un diagrama de secuencia deben tener una clase (o tipo) en el
proyecto. Es importante tener en mente esta regla para comprender el mecanismo de
trabajo descrito.

Pg 39 de 213
 Enterprise Architect
Manual prctico

Por tanto, y a pesar de que se puede abordar de diferentes formas la realizacin de

estos diagramas, hay algunos caminos ms adecuados que otros. Vamos a intentar
aclarar estos mecanismos y, si es posible, comparar sus ventajas e inconvenientes.

El modo de trabajo ms adecuado para preservar la consistencia mencionada

anteriormente es simultaneando la identificacin y localizacin de clases con la
creacin y construccin de diagramas de secuencia. Por qu? Es muy sencillo: de esta
manera, identificando primero la clase, podemos generar un objeto a partir de ella,
trasladarlo al diagrama de secuencia donde participa y por tanto asegurar que el objeto
se corresponde con la clase.

Luego veremos otras alternativas para esta actividad, pero de momento, desarrollemos
visualmente lo que acabamos de explicar:

Partimos, de las ltimas pantallas mostradas, donde habamos creado el diagrama de

secuencia completamente vaco. Puesto que hemos dicho que deberamos identificar o
localizar las clases al mismo tiempo, tendremos que crear la estructura necesaria para
ello.

Por coherencia con el ejemplo, la estructura en el proyecto que nos permita ir creando
las clases, conforme nos demos cuenta de la necesidad de objetos suyos para cubrir la
descripcin del escenario que estamos representando. En Mtrica 3, ese producto es el
Modelo de Clases de Anlisis, y lo podemos enfocar, como los diagramas de secuencia,
a los subsistemas de anlisis (o diseo) que se hayan identificado:

Pg 40 de 213
 Enterprise Architect
Manual prctico

En esta pantalla se pueden observar varios hechos relevantes a la vez:

1.- Vamos a realizar el diagrama de secuencia del escenario principal (de momento el
nico que hay descrito) asociado al caso de uso CU02.Analizar Peticin.

2.- Estamos respetando en todos los productos, la arquitectura de subsistemas de

anlisis que se identific en la creacin, desarrollo y organizacin de los casos de uso.
Recordemos que en Enterprise Architect debemos replicar esta estructura en todos los
productos significativos donde dicha arquitectura de subsistemas pueda tener un
impacto organizativo: en este caso tanto el producto Subsistemas de Anlisis, El
Anlisis de la Realizacin de los Casos de Usos, y el modelo de clases tienen
internamente una estructura similar que facilite la trazabilidad manual de los
elementos.

Con el objetivo de mantener dicha trazabilidad manual, hemos creado un diagrama de

secuencia con el mismo nombre que el caso de uso cuyo escenario queremos
representar. Asimismo, el diagrama de clases del subsistema 1. Gestin de Peticiones
(que contiene el caso de uso CU02.Analizar peticin) tiene como nombre un
identificador que contiene a su vez el identificador del subsistema que est
representando.

Una posible organizacin es la que se muestra en el rbol:

Un diagrama de secuencia por escenario. Todos los diagramas de secuencia

correspondientes a los casos de uso de un mismo subsistema, estn conviviendo juntos,
justo debajo del paquete que representa dicho subsistema.

Un diagrama de clases por subsistema. Todas las clases que participan (a travs de sus
objetos) en los diferentes diagramas de secuencia, uno por escenario de caso de uso,
considerando todos los casos de uso de un subsistema, participarn en el mismo
diagrama.

Un catlogo de clases, estructurado por tipos (boundary, control, entity) que contenga
fsicamente las clases, conforme se vayan identificando. Esto permitir a los diversos
usuarios del proyecto no tener que buscar a ciegas en mltiples subsistemas. Cuando
entren a un subsistema, vern las clases de ese subsistema dibujadas en un diagrama, y
podrn luego localizarla (Locate in Project Browser) con facilidad dentro del catlogo de
clases.

Por tanto, a partir de ahora, trabajaremos en paralelo con los tres productos:

Veremos el escenario, pensaremos qu objetos participan en el escenario, crearemos (si

no existen) clases que den soporte a esos objetos; esas clases las crearemos en el
diagrama del subsistema al que pertenece el caso de uso; desde el rbol ubicaremos la
clase de anlisis en la categora correspondiente del catlogo (pero en el diagrama se

Pg 41 de 213
 Enterprise Architect
Manual prctico

seguir viendo la clase); cogeremos la clase del rbol (Project Browser) y la

arrastraremos en el diagrama de secuencia en el que participa como objeto, realizando
dicho arrastre en el modo As instance of element. As, hasta ir concluyendo el
diagrama de secuencia. No es preciso insistir que este mecanismo no tiene porqu ser
el nico viable para realizar este trabajo, pero nos permite garantizar una serie de
verificaciones imprescindibles aunque quizs el mecanismo mental para la realizacin
de estos modelos y productos no sea realmente el descrito (al menos en ese orden).
Intentaremos reflejar visualmente mediante pantallas toda la secuencia de acciones que
acabamos de describir:

Partimos de la base de un escenario de un caso de uso, que servir de referencia para

empezar a construir la realizacin de dicho caso de uso. En el ejemplo, nos centraremos
en el Anlisis de la realizacin del caso de uso, aunque el mecanismo y los objetivos
sern los mismos para el caso de abordar esta actividad en diseo (DSI 3. Diseo de los
casos de uso reales y DSI 4. Diseo de clases):

Se muestra a continuacin el texto del escenario principal de un caso de uso:

A partir de este escenario elaboramos su diagrama de secuencia de anlisis (Anlisis de

la Realizacin), tomando como elementos de partida clases de Interfaz (Boundary), de
control (Control) y de entidad (Entity). La secuencia, por tanto, estar formada por
objetos instanciados de clases de estas categoras.

Pg 42 de 213
 Enterprise Architect
Manual prctico

Entendemos que el usuario se deber poner en contacto con el escenario a travs de un

interfaz grfico. Por tanto, por lo menos necesitaremos una clase de tipo Interfaz
(estereotipo <<Boundary>> en UML y Enterprise Architect). Adems, como mnimo
necesitaremos una clase que controle la lgica u operativa del escenario (podran hacer
falta ms en funcin de la complejidad del escenario). Finalmente, en este escenario, se
necesitarn por lo menos un objeto peticin (y quizs, aunque se ver ms tarde, otro
objeto proyecto) que har el papel de intermediario con el almacenamiento de
informacin para poder consultar y actualizar la informacin de peticiones; esto
significa que esta categora de clases deber ser de Entidad (o <<Entity>>).

Grficamente hablando, e intentando trasladar todo este mecanismo a Enterprise

Architect, necesitaremos primero crear las clases, a partir de las cuales podremos
generar los objetos que participarn en la secuencia. Estas clases pueden crearse
directamente en el rbol de Proyecto o crearse en un diagrama de clases que ir
acumulando las clases al nivel de organizacin que se elija (caso de uso, subsistema o
proyecto).

Se pueden observar varias caractersticas de la organizacin: todos los productos estn

organizados en base a los subsistemas identificados en las actividades iniciales. Esta
organizacin ha de ser replicada en cada uno de los productos, por lo que se tendr
especial cuidado en no cometer errores. Adems, el producto modelo de clases de
anlisis se ha organizado de la siguiente manera: por un lado, un paquete que contiene
un catlogo de clases de anlisis en donde estas clases se organizan por categoras
(control, entidad e interfaz); a continuacin un paquete por subsistema (donde podran
existir ms de un nivel de organizacin) y dentro de cada subsistema al menos un
diagrama de clases que reflejar todas las clases de cada subsistema.

El motivo de organizar las clases en un catlogo separado del subsistema es la facilidad

de localizacin de las clases por parte de los posibles tcnicos participantes en el
proyecto. Si las clases estuviesen repartidas por subsistemas, podra ser complicada su
localizacin en caso de necesidad de reutilizacin (para generar objetos, para colocar la
clase en otros diagramas, etctera). No obstante, una organizacin alternativa es tener
un catlogo de clases por subsistema, entendiendo que cada subsistema tendr un
conjunto de clases disjunto de cualquier otro conjunto perteneciente a otro subsistema.
En estos ejemplos se optar por tener un nico catlogo para todo el proyecto (tanto en
anlisis como en diseo).

Como ya se ha indicado, las clases cuyos objetos participarn en los diagramas de

secuencia se pueden crear directamente en el catlogo de clases, cada una dentro de la
categora que le corresponde o crearlas en algn diagrama de clases correspondiente al
subsistema al que pertenecen. En el primer caso, habr que arrastrar estas clases luego
a algn diagrama de clases para tener una visin grfica de las clases y sus
asociaciones. En el segundo caso, el problema ser de ubicacin puesto que las clases se
crearn en el paquete al que pertenece el diagrama. Entonces, una vez dibujadas,
habremos de mover, en el Project Browser, cada clase a la categora del catlogo
correspondiente.

Pg 43 de 213
 Enterprise Architect
Manual prctico

En ambos casos, al final, la situacin ser la misma.

Se ve como al final, hay un diagrama con las clases dibujadas, en este caso el diagrama
corresponder al subsistema Gestin de Peticiones, pero las clases fsicamente
estarn ubicadas dentro de los paquetes del catlogo, en su categora correspondiente.

Ahora ya podemos alternar este diagrama y sus clases con el diagrama de secuencia,
arrastrando desde el rbol las clases participantes en el escenario como objetos. Para
ello, se emplear el modo As instance of element de Enterprise Architect que aparece
como una de las posibilidades cuando se arrastra un elemento del rbol a un diagrama;
recordemos que como en los diagramas de secuencia deberan aparecer tambin los
actores que participan en los escenarios, comenzaremos por el actor. Buscamos el actor
Organizacin que se encuentra dentro del paquete actores (si lo hemos organizado as);
arrastramos el actor desde el rbol al diagrama de secuencia; se muestra la ventana
Paste Element; se elige la opcin As instance of element; se pulsa OK:

Pg 44 de 213
 Enterprise Architect
Manual prctico

Quedando el diagrama de secuencia con el actor, al principio (izquierda) del mismo

como objeto:

Recordemos que cuando arrastramos un elemento clasificador desde el rbol a un

diagrama como objeto (As instance of Element), se crea un objeto con tipo (el del
clasificador que se ha arrastrado), pero sin nombre; esta estructura se muestra
claramente por los dos puntos y nombre del clasificador, es decir:

[nombre del objeto] : nombre del clasificador

Se pone nombre de objeto entre corchetes puesto que es opcional. Como ose ha visto, al
arrastrar el actor al diagrama se ha creado una instancia (objeto) de dicho actor sin
nombre pero con el tipo del actor.

La misma operacin se tendra que ir realizando con las clases cuyos objetos creemos
que deben participar en el escenario (las clases que se han mostrado en una pantalla
anterior). Estas clases, recordemos que son de anlisis, se suelen ir poniendo en el
diagrama en un orden marcado por su tipo: primero las de tipo interfaz o boundary,
despus las de tipo control y finalmente las entidades o Entity. Esto no es obligado,
pero evidentemente ayuda a aclarar la secuencia descrita:

Pg 45 de 213
 Enterprise Architect
Manual prctico

Se comprueba que aparecen los objetos como instancias de las clases empleadas, todos
sin nombre (se ve porque su etiqueta empieza con los dos puntos), y todos con el tipo
del clasificador que se arrastr. Se comprueba tambin como todos los nombres de las
instancias aparecen subrayadas (en UML, el nombre de un objeto aparece siempre
subrayado; en el caso del actor se trata de un pequeo error de visualizacin de
Enterprise Architect; debera aparecer tambin subrayado).

A partir de este momento ya podemos empezar a representar el escenario de la manera

ms fidedigna posible, aunque el nivel de detalle depender de diversos factores:
criterios de la organizacin, nivel de detalle del escenario escrito, tipo de diagrama de
secuencia (anlisis o diseo), etctera

Para representar el escenario tenemos que emplear la relacin denominada message

(mensaje) que refleja el popular mecanismo que en orientacin a objetos nos permite
representar la interaccin entre dos objetos. Cuando un objeto invoca a otro (al mtodo
u operacin de otro), le enva un mensaje con la operacin del objeto receptor que
desea ejecutar. El mensaje es el elemento fundamental empleado por Enterprise
Architect para sincronizar los diagramas de secuencia con los diagramas de clases, ya
que todo mensaje recibido por un objeto en un diagrama de secuencia debe traducirse
en una operacin dentro de la clases a la que pertenece el objeto que recibe el mensaje.

Estos mensajes tambin servirn para reflejar la interaccin entre los actores y el
sistema. El actor en general interactuar con el sistema (con el escenario) a travs de los
interfaces de usuario, que en los diagramas de secuencia de anlisis estn
representados por clases de tipo <<Boundary>> o interfaz.

Veamos el mecanismo; en general se trata de dibujar una relacin como en cualquier

otro caso; la nica peculiaridad es que el mensaje se dibujar desde la lnea de vida
(lnea discontinua vertical) del objeto emisor hasta la lnea de vida del objeto receptor:

Pg 46 de 213
 Enterprise Architect
Manual prctico

Cuando se suelta el ratn, es decir cuando se arrastra la relacin (el mensaje) hasta el
objeto receptor del mensaje, aparece una ventana como la que se muestra justo arriba.
Veamos la pantalla correspondiente al mensaje con mayor detalle:

Pg 47 de 213
 Enterprise Architect
Manual prctico

La explicacin de esta ventana es muy importante para entender los mecanismos

internos de Enterprise Architect. El objetivo es que de alguna forma eficaz y slida, la
informacin de los diagramas de secuencia repercuta en los modelos de clases, de tal
modo que podra decirse que el sistema se diseara por induccin, a travs de los
ejemplos (diagramas) representados por todos los escenarios. Por tanto el
funcionamiento de esta ventana se convierte en un mecanismo esencial y en
consecuencia se ha de tener especial cuidado y saber qu se desea hacer en cada
momento:

En este caso podemos observar la primera seccin preparada para incluir el nombre del
mensaje. Y aqu se puede producir el primer error, y de gravedad. Debido a que la caja
de texto Message es editable, cabe la posibilidad de pensar que podramos solventar el
problema introduciendo directamente en esa caja el nombre del mensaje. Hacerlo, por
el contrario, ser un tremendo error y condicionar el resultado de nuestro esfuerzo.

Si tecleamos directamente el mensaje en el campo, Enterprise Architect simplemente

etiquetar la relacin que representa el mensaje pero no har nada que no sea
estrictamente poner un comentario. Por tanto, no repercutir nada en el resto del
proyecto (y por tanto, la clase a la que pertenece el objeto que recibe el mensaje no se
actualizar).

Aunque ms adelante podremos analizar algunos casos en los que introducir una
etiqueta directamente en este campo puede ser til, cuando queremos crear un mensaje
que debe corresponderse con una operacin en alguna clase (en este caso, en la clase a
la que pertenece el objeto que recibe el mensaje) el mtodo de trabajo ser muy
diferente.

En realidad el mecanismo es bastante rgido, pero lgico. En teora el objeto que recibe
el mensaje puede tener ya un interfaz de servicios (entendemos aqu la palabra interfaz
como el conjunto de operaciones a las que puede responder el objeto) y por tanto
pudiera ser que el mensaje que queremos enviar, o lo que es lo mismo, la operacin
cuyo mtodo queremos ejecutar ya existiese en el objeto (porque exista en la clase que
se us para crear el objeto o porque en otro diagrama de secuencia, haya surgido ese
mismo mensaje); por este motivo, antes de escribir, lo que tenemos que hacer es
desplegar la lista asociada a la caja de texto; dentro de esa lista estarn todos los
mensajes (operaciones) que hasta ese momento existen en la clase a la que pertenece el
objeto y por tanto, las operaciones que el objeto es capaz de ejecutar. Si en esa lista est
el mensaje, simplemente se selecciona y no hara falta nada ms; pero si no se
encuentra, en vez de escribir directamente en la caja, hay que informar al sistema de
esa nueva operacin, en especial, hay que informar a la clase del objeto, puesto que esa
operacin tendr que existir en la clase.

Pg 48 de 213
 Enterprise Architect
Manual prctico

Por tanto, en este ltimo caso, si el mensaje no existe, debemos de activar el botn
Operations. Este botn realmente, nos conducir a la ventana de operaciones de la clase
del objeto, daremos de alta en esa ventana la operacin, para registrarla dentro de la
clase, y al aceptar, esa operacin aparecer como mensaje en la caja de texto; en esta
situacin, s que podremos aceptar con tranquilidad la ventana del mensaje para que
aparezca dentro del diagrama de secuencia (con independencia de otros aspectos que
podamos incorporar relacionados con dicho mensaje):

En el caso que nos ocupa, no se puede ver con claridad en el ejemplo puesto que no se
exterioriza ninguna reaccin de forma visible, pero si hacemos clic en la lista
desplegable, no ocurre nada, no aparece nada; eso significa que la clase a la que
pertenece el objeto no tiene ninguna operacin y por tanto, su objeto an no tiene nada
en su interfaz. Por tanto procederemos a pulsar en el botn Operations:

Acercndonos a la ventana de operaciones, podemos comprobar como en realidad se

corresponde con la clase CLAN01.BPeticiones; en esta ventana intentaremos
documentar la operacin lo mejor posible (por supuesto, asumiendo posibles
actualizaciones en posteriores momentos):

Pg 49 de 213
 Enterprise Architect
Manual prctico

Esta parte no tiene otra

dificultad que conocer hasta
donde llegar en la
identificacin de elementos y
caractersticas de la operacin
en funcin de si se trata de
una operacin de una clase
de anlisis o una clase de
diseo:

De momento, le damos un
nombre a la operacin y la
guardamos. A continuacin,
la seleccionaremos de nuevo
para incorporar informacin
ms detallada.

Ya est seleccionada; ahora podemos, si lo consideramos oportuno, incorporar

parmetros al mensaje (operacin); para ello, pulsamos el botn Edit que aparece al
final de la seccin Parameters. Aqu podremos incorporar cuntos parmetros creamos
que debe tener la operacin; podemos darle un nombre, un tipo, caractersticas
adicionales y, por supuesto, comentarios.

Se pueden incorporar
muchos detalles a un
parmetro; en el caso del
ejemplo lo dejaremos slo
con nombre, tipo y en todo
caso algn comentario.

Una vez incorporados los

parmetros, hacemos clic en
el botn Close y volvemos a
la ventana de Operaciones de
la clase.

Pg 50 de 213
 Enterprise Architect
Manual prctico

Adems de lo que hemos visto, tambin se puede suministrar a la operacin, el tipo de

dato que devuelve (void por defecto) y otra informacin relevante (como mnimo, un
comentario detallado); se pueden ver mltiples opciones pero muchas de ellas estn
relacionadas con caractersticas fsicas de la operacin y estn orientadas a las
posibilidades de generacin de cdigo de Enterprise Architect.

Para el valor de retorno, se puede comprobar

como la lista desplegable se puede complicar
de manera extraordinaria puesto que muestra
los tipos de datos fundamentales del lenguaje
que est seleccionado por defecto para la
clase, pero tambin muestra todas las clases
que hasta ese momento existan en el proyecto
puesto que se tratan en realidad de tipos de
datos definidos por el usuario. Aparecern
clases de anlisis, de diseo, de dominio,
etctera; Enterprise Architect no distingue la
abstraccin, para la herramienta todos son
clases; por tanto la correcta identificacin de
las clases se convierte en un aspecto
importante para poder seleccionar las clases
adecuadas. Veremos a continuacin en el
diagrama de secuencia como se representa el
tipo de dato devuelto por el mensaje;

Pg 51 de 213
 Enterprise Architect
Manual prctico

Aceptando la operacin para guardarla en la clase, volvemos a la ventana del mensaje:

Pg 52 de 213
 Enterprise Architect
Manual prctico

Se puede observar como adems del campo Message que se ha actualizado con la
operacin en el formato correcto; se ha actualizado tambin Parameters y Return; sera
otro error escribir en estos dos campos de forma manual puesto que lo que
escribisemos no repercutira en la clase y quedara simplemente como texto
documental en el diagrama de secuencia. No obstante, pueden haber ocasiones en que
nos interese escribir directamente, pero porque el diagrama de secuencia es un simple
dibujo y no queremos que haya ningn tipo de interaccin con el resto del proyecto. En
ese caso, puede interesar escribir directamente sobre los campos.

Aceptando esta ventana, veremos finalmente como aparece el mensaje dentro del
diagrama de secuencia:

Se observa cmo el valor devuelto por la operacin se expresa mediante una

asignacin y la invocacin del mensaje se expresa mediante lo que se denomina un
control bar. Tambin puede adivinarse el problema que puede acabar surgiendo por el
uso de mensajes demasiado detallados, puesto que la longitud de la cadena aumenta y
el diagrama se ha de acomodar para separar la distancia entre objetos. Hay que tener
cuidado con estos problemas y saber manejarlos con soltura porque sern inevitables
en cuanto los proyectos e compliquen lo ms mnimo (debe plantearse la posibilidad
de modificar las propiedades del diagrama de secuencia para mostrar solo lo ms
importante y dejar los detalles ocultos, como por ejemplo los parmetros de las
operaciones).

Para que podamos observar la otra posibilidad, si ahora intentamos continuar la

secuencia (el escenario), dibujaremos un mensaje desde el objeto boundary al objeto de
tipo control:

Pg 53 de 213
 Enterprise Architect
Manual prctico

En este caso, si desplegamos la lista, podremos ver como ya existen operaciones, y en

concreto una que representa lo que queremos hacer y es que el objeto control ejecute la
operacin de consulta de peticin:

Como se ve, en esta situacin no hace falta pasar por el botn Operations puesto que la
operacin ya existe dentro del interfaz del objeto; simplemente lo seleccionamos y
aceptamos para que aparezca en el diagrama de secuencia:

Pg 54 de 213
 Enterprise Architect
Manual prctico

Lo que no podemos permitir es que los mensajes aparezcan como simples etiquetas,
que es lo que habra ocurrido si hubisemos escrito directamente sobre el campo sin
saber que el mecanismo real de trabajo es el que acabamos de describir.

Una vez representado todo el escenario en el diagrama de secuencia, ste quedar

registrado y las clases correspondientes actualizadas con los nuevos mensajes, o
utilizadas mediante la seleccin de las operaciones que se deben ajustar a lo requerido
en dicho escenario.

Nota importante sobre los nombres de los objetos

Tericamente, desde un punto de vista estrictamente basado en UML, no es necesario

que los objetos de un diagrama de secuencia tengan nombre. Recordemos que cuando
arrastramos una clase a un diagrama de secuencia en modo As instance of element se crea
un objeto cuyo tipo es el de la clase, pero sin nombre.

No obstante, debido a las connotaciones de Enterprise Architect y a la manera en la que

se elabora la documentacin formal, puede ser necesario tener que nombrar de forma
obligatoria los objetos para que tanto el ndice del documento como su contenido sean
manejables. Esto introduce un factor de complejidad extra en la gestin de los
diagramas de secuencia (sobre todo su tamao en anchura), puesto que los nombres de
los objetos pueden reducir la claridad del diagrama. Se intentar mostrar claramente en
la seccin dedicada a la obtencin de la informacin.

Un objeto puede tener nombre y no tener tipo en Enterprise Architect?

Si. Dentro de la nomenclatura estndar de UML, un objeto tiene la siguiente sintaxis:

[nombre del objeto] : clase a la que pertenece

Como se puede comprobar, el nombre es opcional; pero en Enterprise Architect existe la

posibilidad tambin de tener objetos sin tipo (podra ser un diagrama informal que a
modo de dibujo simple queramos hacer para aclarar una situacin); Enterprise Architect
crea uno objeto con nombre pero sin tipo siempre que el objeto se crea directamente
desde el toolbox correspondiente en lugar de arrastrar directamente desde una clase:

Pg 55 de 213
 Enterprise Architect
Manual prctico

Como se puede comprobar, al crear el objeto a partir del toolbox, Enterprise Architect
nos muestra la ventana de propiedades del elemento (en este caso del objeto) para que,
como en cualquier otro caso, podamos nombrar a dicho elemento, y al aceptar la
ventana vemos como el objeto queda con el nombre que hemos introducido, pero no
aparecen los dos puntos la seccin siguiente, puesto que an no se ha indicado a que
clase pertenece.

Esta situacin hay que evitarla en la medida de lo posible o solucionarla cuanto antes
para evitar ulteriores problemas o comportamientos de Enterprise Architect que
podramos considerar errneos cuando en realidad su funcionamiento es
completamente correcto: si intentamos enviar un mensaje a un objeto sin tipo, no puede
crearse ninguna operacin puesto que no hay clase a la que incorporarla y por tanto, lo
nico que podremos hacer es teclear el nombre del mensaje, con el consiguiente error ya
descrito.

Diagrama de Comunicacin (o de Colaboracin)

Como posible opcin a los Diagramas de Secuencia, se pueden utilizar los Diagramas
de Comunicacin. De hecho, estos dos tipos de diagramas son isomorfos: se puede
obtener uno a partir del otro. Los diagramas de Comunicacin, a pesar de tener un
tratamiento por parte de la herramienta algo ms deficiente, pueden ser tiles, por
ejemplo, a la hora de modelar la navegacin entre pantallas en entornos grficos.

Veamos, por tanto, un ejemplo de cmo se realizara uno de estos diagramas para
mismo ejemplo tratado en el Diagrama de Secuencia.

En primer lugar, crearemos en nuestro Project Browser un paquete que contenga esta
variacin, cuyo nombre sea, por ejemplo, Comunicacin.

Pg 56 de 213
 Enterprise Architect
Manual prctico

Dentro de este paquete, crearemos el Diagrama de Comunicacin y arrastraremos a l

todos los objetos intervinientes As instance of element, teniendo en cuenta que ya
tenemos las Clases creadas en el Modelo de Clases de Anlisis.

La metodologa para crear los mensajes entre objetos es la siguiente:

En primer lugar, creamos una asociacin (Associate) entre los objetos que se comunican
mediante el mensaje.

Pg 57 de 213
 Enterprise Architect
Manual prctico

A continuacin, con el botn derecho del ratn sobre la asociacin recin creada,
seleccionaremos Add message from como se muestra en la figura:

Por ltimo, en la ventana emergente, procederemos de igual modo que en el Diagrama

de Secuencia, es decir:
Seleccionando la operacin de la clase de la lista desplegable, en caso de que ya
exista o
Creando una nueva operacin en la clase mediante el botn Operations.

Pg 58 de 213
 Enterprise Architect
Manual prctico

Ntese que, al ir dibujando en el diagrama los distintos mensajes que se lanzan los
objetos entre s, stos van siendo numerados 1, 1.1, 1.2 y as sucesivamente.
Este es el modo que tienen los Diagramas de Comunicacin de representar la secuencia
temporal de los objetos.

En el caso de querer comenzar un nuevo grupo, es decir, que la numeracin pase a 2,

en el momento de establecer el mensaje, en su ventana, activaremos la casilla de
verificacin Start new group.

Repitiendo las acciones descritas, seguiremos creando mensajes sucesivamente hasta

completar la descripcin del Escenario.

Una vez descritos, mediante unos u otros diagramas, todos los escenarios de los Casos
de Uso del sistema, habremos obtenido el producto que Mtrica 3 denomina Anlisis
de la Realizacin de los Casos de Uso. Pero es posible que en nuestro proyecto
tengamos la necesidad de especificar algn detalle ms. Por ejemplo, los prototipos de
pantallas intervinientes en la realizacin de cada Caso de Uso.

Diagrama de Interfaz de Usuario

Los Diagramas de Interfaz de Usuario (User Interface) nos permiten crear prototipos
bsicos de las pantallas que el sistema mostrar al usuario durante la ejecucin de los
distintos Casos de Uso.

Para ver su funcionalidad, crearemos esta vez en nuestro Project Browser un nuevo
paquete que contendr nuestro producto Especificacin de la Interfaz de Usuario.
Una vez creado, y siguiendo con la metodologa de descomposicin en subsistemas
que venimos utilizando para la organizacin de otros productos, podramos crear
dentro de l una serie de paquetes que contuvieran las pantallas de cada uno de los
Subsistemas de Anlisis. Por lo tanto, procederemos as: crearemos un paqueta para
cada uno de los subsistemas y dentro de cada uno de ellos, los diagramas necesarios
para dibujar las pantallas de cada subsistema.

Pg 59 de 213
 Enterprise Architect
Manual prctico

La manera de crear el diagrama de Interfaz de Usuario es pulsando el botn New

Diagram y seleccionando Extended  User Interface como se muestra a continuacin:

Obteniendo as un nuevo diagrama vaco en el que insertar nuevos elementos. Los

elementos intervinientes en este tipo de diagrama son, principalmente, dos: Las Screen
y los GUI Elements.

En la figura anterior se muestra cmo desde el toolbox se ha seleccionado el elemento

Screen y se ha dibujado en el diagrama, obteniendo con ello la ventana de propiedades
del elemento que nos permite configurar sus propiedades del modo habitual en otros
artefactos UML.

Pg 60 de 213
 Enterprise Architect
Manual prctico

Los GUI Elements son los controles que aparecen en las pantallas (botones, cajas de
texto, listas desplegables, botones de opcin, casillas de verificacin, etc).

La manera de insertar estos controles dentro de un elemento Screen es muy intuitiva:

basta con seleccionar el GUI Element en el toolbox y dibujar el control dentro de la
pantalla. Una vez se nos muestre su ventana de propiedades, en el campo Stereotype
seleccionaremos el tipo de control de que se trata:

De este modo, crearemos el prototipo de cada una de las pantallas que deseemos
describir para cada subsistema.

Pg 61 de 213
 Enterprise Architect
Manual prctico

Modelizacin de la Navegacin entre pantallas

Es posible que queramos completar nuestro producto Especificacin de la Interfaz de

Usuario con un modelo que describa el comportamiento de la navegacin entre
pantallas: la secuencia de aparicin de stas.

Podemos utilizar, por ejemplo, un diagrama de Comunicacin para representar este

modelo, de alguna de las siguientes formas:

1. Insertando en el diagrama de Comunicacin los elementos

Screen de modo As instance of element (Object) (mediante el
arrastre de la Pantalla desde el Project Browser al diagrama):

Es la manera ms formal desde el punto de vista UML, ya que en

un diagrama de Comunicacin han de participar objetos, no
clasificadores. Por el contrario, esta opcin puede ser
excesivamente engorrosa debido a la generacin de objetos que
conlleva, especialmente en proyectos grandes o con gran nmero
de pantallas.

2. Insertando en el diagrama de Comunicacin los elementos

Screen de modo As simple link (mediante el arrastre de la
Pantalla desde el Project Browser al diagrama):

3. Insertando en el diagrama de
Comunicacin los diagramas de
Interfaz de Usuario As diagram frame
(mediante el arrastre del diagrama de
Interfaz de Usuario desde el Project
Browser al diagrama de Comunicacin):

Pg 62 de 213
 Enterprise Architect
Manual prctico

Otros diagramas

De un modo menos exhaustivo revisaremos algunos otros diagramas UML que

podemos construir con Enterprise Architect. Los procedimientos de creacin de estos
diagramas y sus elementos, al ser idnticos a los dems diagramas, sern omitidos en
lo sucesivo.

Diagrama de Despliegue (Deployment)

El diagrama de despliegue nos brinda una vista fsica del sistema, describiendo la
forma en que el sistema es implementado en la realidad, en relacin con la tecnologa.

En estos diagramas intervienen como elementos principales los Nodos y los

Componentes. Las relaciones entre ellos suelen ser Association o Deployment en
aquellos casos en que queremos describir que cierto componente se despliega en
determinado nodo, por ejemplo.

Un diagrama de Despliegue estndar podra tener el siguiente aspecto:

Para obtener esas divisiones horizontales, hemos hecho uso de un recurso de

Enterprise Architect denominado Swimlines que se obtiene a travs de la ventana que
aparece al seleccionar el men Diagram  Configure Swimlines and Matrix:

Pg 63 de 213
 Enterprise Architect
Manual prctico

En este caso se han utilizado 3 particiones horizontales, y en cada una de ellas se ha

definido un color de fondo en el momento de su creacin.

Tambin es posible crear y configurar perfiles de matrices complejas, desde la pestaa

Matrix y activando el checkbox Active.

Pg 64 de 213
 Enterprise Architect
Manual prctico

Diagrama de Mquina de Estados (State Machine)

Un diagrama de mquina de estados es un diagrama de comportamiento dinmico que

permite mostrar los distintos estados en que puede encontrarse el sistema en tiempo de
ejecucin; en concreto, los objetos que participan en la ejecucin.

Los elementos UML ms comunes para la realizacin de este tipo de diagramas son
State para indicar un posible estado del objeto y Transition como enlace entre
distintos estados. En las transiciones podremos indicar condiciones de guarda que han
de cumplirse para que se lleve a cabo, las acciones que se llevan a efecto, as como la
informacin que se incorpora al objeto debido al cambio de estado mediante atributos
del estado (se accede mediante F9, como a los atributos de una clase).

Tambin se utilizan, lgicamente, los elementos Inicial, Final y Synch para indicar el
inicio y fin del flujo de estados y las sincronizaciones del flujo.

Un ejemplo de diagrama de estados podra ser, para la clase CLAN05.EProyecto:

Pg 65 de 213
 Enterprise Architect
Manual prctico

Diagrama de Mantenimiento (Maintenance)

El diagrama de mantenimiento es una herramienta que puede servirnos para

representar grficamente distintos aspectos del desarrollo del proyecto, su gestin de
incidencias, defectos, pruebas a travs algunos nuevos elementos: casos de prueba
(testcases), incidencias (issues) y cambios (changes).

Normalmente se establece una relacin de dependencia entre los elementos

mantenidos y sus mantenimientos, como se muestra en el ejemplo siguiente:

Un Caso de Prueba es un conjunto de pruebas que se ejecutan ms de una vez. Por ello,
en vez de registrarlas elemento a elemento, se opta por recogerlas todas dentro de un
Caso de Uso con el estereotipo testcase, de manera que se puedan reutilizar para
tantos elementos como se desee, mediante un enlace de dependencia.

Diagrama de Mapas Mentales (Mind Mapping)

Los mapas mentales constituyen un tipo de diagrama utilizado para la representacin

de conceptos, ideas, tareas u otros elementos abstractos todos ellos relacionados con un
elemento o idea central. A partir de la versin 7.0 de Enterprise Architect es posible
hacer uso de este tipo de diagramas.

Estn relacionados con tareas como la creacin de agendas y reuniones dinmicas,

elaboracin de presentaciones, comentarios y revisiones tcnicas, brainstorming y
pueden ayudar en la captura de requisitos formales y en la especificacin de la
interactividad aplicacin usuarios en un proyecto software.

Pg 66 de 213
 Enterprise Architect
Manual prctico

La creacin de un mapa mental es igual que para cualquier otro tipo de diagrama, es
decir:

Seleccionar o crear el paquete o vista donde vaya a albergarse el diagrama.

Pulsar el botn New diagram, y seleccionar el tipo de diagrama MindMapping

de la categora MindMapping Diagrams. Al no tratarse de un diagrama UML,
su localizacin dentro del asistente de creacin de diagramas se encuentra en
una categora aparte:

Pulsar el botn OK

Pg 67 de 213
 Enterprise Architect
Manual prctico

Una vez creado el diagrama, podemos hacer uso de los elementos que pueden
componerlo:

Central topic: idea central sobre la que se quiere hacer un estudio.

Main topic: puntos principales y generales del estudio.
Topic: puntos concretos de estudio.
Subtopic: lneas de desarrollo de conceptos.
Relationship: relacin entre elementos.

He aqu un ejemplo diagrama con sus componentes:

Otros diagramas

Existen algunos otros diagramas que Enterprise Architect puede manejar, como el
diagrama de Componentes, de Tiempos, de Objetos, de Anlisis que no trataremos
en este manual.

En caso de precisar informacin o ejemplos sobre alguno de estos diagramas, se puede

consultar el manual completo de la aplicacin o bien la ayuda de la misma.

Pg 68 de 213
 Enterprise Architect
Manual prctico

Extensiones UML. Estereotipos y Valores Etiquetados

UML ofrece los estereotipos como ampliacin de la semntica de sus elementos. Ya

hemos tenido ocasin, a lo largo del ejemplo realizado, de utilizar algunos de ellos
como <<business use case>>, <<business actor>>, <<button>>, <<textbox>> o <<TestCase>>.

Los Valores Etiquetados (Tagged Values) son utilizados para definir nuevas propiedades
a los elementos UML.

Existe en la herramienta la posibilidad de redefinir o crear nuevos estereotipos y

valores etiquetados para los elementos. Para ello, se utilizan las siguientes ventanas:

Estereotipos:

Desde el men Settings  UML:

Pg 69 de 213
 Enterprise Architect
Manual prctico

Accedemos a la ventana de mantenimiento de estereotipos:

Podemos crear, eliminar y modificar los estereotipos que ofrece la herramienta, as

como asignar figuras y grficos a los estereotipos. Para ello se puede optar por utilizar
un metafile o bien dibujar manualmente la figura mediante un lenguaje script que
tiene la herramienta a tal efecto.

Valores Etiquetados:

Desde el men View  Tagged Values activaremos la visualizacin de la ventana de

edicin de valores etiquetados de los elementos, que aparecer por defecto como una
ficha ms bajo el Project Browser:

Pg 70 de 213
 Enterprise Architect
Manual prctico

Veamos las opciones que nos ofrece su barra de botones:

Botones para definir el Botones para crear un Botn para definir los tipos disponibles
tipo de ordenacin (por nuevo valor etiquetado, de valores etiquetados, a travs de la
categoras o alfabtico) editar sus notas y siguiente pantalla, tambin accesible
eliminar el valor. desde Settings  UML:

Esta ventana nos permite definir

los tipos de Tagged Values del
sistema. Por defecto, aparecen
Datafield, Role y
Software.

Pg 71 de 213
 Enterprise Architect
Manual prctico

Personalizacin y otras operaciones con diagramas y

elementos UML

Es muy importante destacar las posibilidades de personalizacin de ciertos tipos de

informacin que podemos llevar a cabo. Aunque a lo largo de todo el manual se
podrn ver algunos ejemplos de esto, aqu vamos a describir la manera de definir a
nuestro gusto aquellos tipos ms generales.

Mantenimiento de propiedades definibles por el usuario

Desde el men Settings  General Types podemos definir los tipos ms generales,
como son:

Los Tipos de Estado de los Elementos (por ejemplo, propuesto, aprobado,

validado, descartado as como su color a la hora de ser representado en un
diagrama)

Pg 72 de 213
 Enterprise Architect
Manual prctico

Los Tipos de Restriccin:

Los Tipos de Estado de las Restricciones:

Pg 73 de 213
 Enterprise Architect
Manual prctico

El Tipo de los Requisitos (por ejemplo, podemos crear Funcional, No Funcional,

De Rendimiento, De Seguridad)

Los Tipos Escenarios (principal, alternativo, de error):

Pg 74 de 213
 Enterprise Architect
Manual prctico

Representacin del estado de los elementos mediante colores

Ampliando lo visto en el punto anterior, cuando se hablaba de los Tipos de Estado de

los elementos, en donde podamos adems asignar un color a cada estado, vamos a ver
la manera de representar estos estados en los diagramas, ya que por defecto es una
opcin que est desactivada.

Recordamos la ventana de definicin de Tipos de Estado de los elementos:

En esta ventana podemos asignar el color a cada estado, as como decir para qu tipo
de elementos UML es vlida esa asignacin, mediante el botn Applies to.

Pues bien, por ltimo, para que los elementos representados en los diagramas
realmente aparezcan en los diagramas del color definido en esta ventana, tendremos
que activar la opcin Show status color on diagrams disponible en el men Tools 
Options y, dentro, en el apartado Objects:

Pg 75 de 213
 Enterprise Architect
Manual prctico

De este modo, el aspecto de un diagrama cuyos elementos tienen definido un color

para representar su estado, sera:

Asignar un diagrama por defecto

Es posible que el usuario desee, cada vez que abra el proyecto, que se muestre algn
diagrama por defecto. Esto puede ser til, por ejemplo, para mostrar un diagrama de
paquetes general de los modelos, o bien un mapa de productos o del Proceso de
desarrollo.

Vamos a crear, por tanto, un diagrama de bienvenida que se mostrar cada vez que
abramos nuestro proyecto, y que contendr los modelos principales de nuestro
proyecto.

Pg 76 de 213
 Enterprise Architect
Manual prctico

En primer lugar, crearemos una nueva Vista (paquete de primer nivel) llamado
INICIO. Dentro de esta vista, crearemos un diagrama de paquetes del mismo nombre.

Para organizar los paquetes utilizaremos un nuevo elemento denominado Boundary,

que nada tiene que ver con el estereotipo utilizado para las clases de interfaz, sino que
representa un contenedor de objetos, un marco, para los diagramas.

Dibujaremos tres boundaries en el diagrama, llamando a cada una de ellas como las
Vistas que tenemos creadas: Catlogo de Requisitos, Anlisis y Diseo.

Una vez hecho esto, arrastraremos aquellos paquetes que deseemos en su

correspondiente boundary. El resultado puede ser el que se muestra a continuacin:

Pg 77 de 213
 Enterprise Architect
Manual prctico

Bien, ahora vamos a mejorar un poco el aspecto del diagrama. Para ello, aadiremos
diferentes colores a las tres boundaries, y eliminaremos de la presentacin de los
paquetes los elementos que contienen. Tambin quitaremos cualquier referencia a
elementos extranjeros, para que no se muestren la etiquetas from junto a los
paquetes. En primer lugar, haremos doble clic en cualquier parte vaca del diagrama,
para ver su ventana de propiedades. En ella, iremos a la ficha Diagram:

Desmarcaremos la
opcin Show Name
Space. Esta ventana
tambin nos permite
configurar otras
opciones, como
Exclude image from
RTF Documents que
hace que el
diagrama no
aparezca en los
documentos RTF
que generemos.

De la ficha
Elements,
desmarcaremos la
opcin Package
Contents. Aqu
tambin podemos
configurar la
visibilidad de otros
elementos.

Pulsamos Aceptar.

Ahora tenemos un diagrama bastante ms limpio. Para dar color de fondo a las
boundaries, utilizaremos la opcin Configure Default Appearance que aparece dentro de
la opcin Appearance al pulsar el botn derecho del ratn sobre una boundary
seleccionada:

Pg 78 de 213
 Enterprise Architect
Manual prctico

En la ventana que nos aparece tenemos la posibilidad de, desmarcando la opcin Use
Default Color, seleccionar colores para el fondo, el borde y la fuente de cualquier
elemento, as como el grosor del borde.

Seleccionaremos un color para cada una de las boundaries, y obtendremos un diagrama

similar a ste:

Pg 79 de 213
 Enterprise Architect
Manual prctico

Hemos creado una especie de ndice visual de modelos del proyecto, desde el cual
poder acceder al diagrama de primer nivel de cada mediante un simple doble clic.

Solo nos falta decir a la herramienta que ste es el diagrama que queremos mostrar por
defecto, y para ello es necesario utilizar la opcin de men Diagram  Set as model
default.

Podemos comprobar esta funcionalidad cerrando y abriendo de nuevo el proyecto. Si

todo ha ido bien, se mostrar este diagrama al inicio.

Localizacin automtica de elementos en el rbol del repositorio y

en los diagramas

A medida que el proyecto se va haciendo ms y ms complejo, a veces puede

resultarnos especialmente difcil localizar rpidamente los elementos tanto en el Project
Browser como en los diagramas en que estn representados.

Existen en Enterprise Architect varias formas de hacer esto rpida y fcilmente:

Localizar en el Project Browser un determinado elemento de un diagrama:

A partir de la representacin de un elemento en un diagrama, podemos llegar a

localizarlo en el Project Browser mediante la opcin del men Element  Locate in
Project Browser

Localizar en el / los diagramas un determinado elemento seleccinado en el Project

Browser:

Para realizar esta tarea, existen dos mtodos. Haciendo clic con el botn derecho sobre
el elemento de Project Browser, las opciones son:

Pg 80 de 213
 Enterprise Architect
Manual prctico

Find in diagrams: Busca la aparicin del elemento en todos los diagramas del
proyecto. En caso de aparecer en ms de uno, se mostrar una ventana con la
lista de diagramas en que aparece su representacin.

Locate in current diagram: En caso de que el diagrama sea muy complejo y nos
cueste localizar en l determinado elemento, podemos seleccionarlo
automticamente con esta opcin.

Validacin de los modelos

Enterprise Architect dispone de una herramienta de validacin de los modelos,

accesible mediante la opcin Project  Model Validation  Validate selected. Esta
validacin de puede aplicar a cada diagrama en particular en cualquier momento. Las
reglas de validacin que la herramienta utiliza son configurables mediante Project 
Model Validation  Configure:

Se recomienda consultar la Ayuda de la herramienta en caso de tener especial inters

en profundizar en esta funcionalidad.

Pg 81 de 213
 Enterprise Architect
Manual prctico

4. Modelizacin de Datos

Introduccin

Enterprise Architect permite realizar Modelos Conceptuales, Lgicos y Fsicos de

Datos, si bien es este captulo nos vamos a centrar en el Modelo Fsico de Datos, por ser
los dems de tratamiento tcnico similar a los diagramas de clases anteriormente
tratados, con pequeas excepciones, como por ejemplo, es estereotipo <<entidad de
datos>> que se asigna a las clases persistentes.

Creacin de Tablas

Vamos a partir de una nueva Vista denominada DISEO de la que colgaremos un

paquete con el nombre Modelo Fsico de Datos y un diagrama de Clases del mismo
nombre:

En UML, una tabla es una Clase con el estereotipo <<table>>. Por lo tanto, para
comenzar a crear tablas fsicas en nuestro diagrama, emplearemos el elemento Table
del Toolbox para ahorrarnos el tener que introducir manualmente el estereotipo clase
por clase. Creamos, una a una, las tablas de nuestro sistema:

Pg 82 de 213
 Enterprise Architect
Manual prctico

Propiedades de las Tablas

Al tratarse de una Clase estereotipada como <<table>>, la ventana de propiedades

cambia sensiblemente con respecto a la de una Clase normal; en la ficha que
anteriormente apareca Detail ahora aparece Table Detail, con algunas diferencias:

Creacin de Columnas

Vamos ahora a definir las Columnas o Campos de la Tabla. Para ello, pulsaremos el
botn Columns/Attributes.

Observaremos tambin que la Columna es, al fin y al cabo, un Atributo con estereotipo
<<column>>.

El procedimiento es similar al de la creacin de Atributos para la clase, teniendo en

cuenta algunas diferencias como, por ejemplo, que habr que indicar la Primary Key
en caso de haberla, as como los tipos de datos de todos los campos en el desplegable
Data Type, que contendr valores acordes al tipo de base de datos seleccionado para
esa tabla (Oracle, SQL Server, MS Access).

Pg 83 de 213
 Enterprise Architect
Manual prctico

El aspecto definitivo de la Tabla PETICIN con todas sus columnas sera:

Podemos comprobar como, automticamente, Enterprise Architect nos ha creado una

Operacin para la Primary Key (PK) de la Tabla.

Continuaremos con este procedimiento hasta describir la totalidad de las Tablas

participantes en nuestro sistema sin especificar, por el momento, ninguna relacin
entre ellas:

Claves Ajenas (Foreing Keys)

En el Modelo Fsico de Datos, ya es necesario describir las Claves Ajenas de las Tablas,
as como su relacin y cardinalidad. La manera de gestionar a travs de la herramienta
esta descripcin es la siguiente:

Pg 84 de 213
 Enterprise Architect
Manual prctico

En primer lugar, crearemos los campos de Clave Ajena en las tablas que lo precisen:

En segundo lugar, trazaremos una asociacin (Associate) entre las tablas, teniendo en
cuenta que el destino de la relacin ser la tabla servidora, es decir, aquella que tiene el
campo a relacionar como campo Clave. El origen ser la tabla que tiene el campo a
relacionar como Clave Ajena.

Pg 85 de 213
 Enterprise Architect
Manual prctico

Por ltimo, con el botn derecho del ratn sobre la relacin recin creada,
seleccionaremos Foreign keys y en la pantalla emergente, definiremos la relacin
seleccionando de SOURCE y TARGET el campo a relacionar, y pulsando en Save como
se ve a continuacin:

Una vez definida la relacin, habra que modificar, si fuese preciso, su cardinalidad,
como ya hicimos en el Modelo de Dominio, es decir, dentro de las propiedades de la
relacin, en el campo Multiplicity de las fichas Source Role y Target Role. El
aspecto final sera:

Pg 86 de 213
 Enterprise Architect
Manual prctico

Es posible que, por motivos estticos o de espacio, queramos ocultar las largas
etiquetas que se muestran por defecto en la relacin. Podemos para ello utilizar la
opcin Set Visibility  Set Label Visibility que se muestra con el botn derecho sobre
la relacin, y dejar nicamente:

ndices y Triggers

Para definir ndices y triggers en nuestras tablas, tendremos que hacerlo como si de
operaciones estereotipadas de la clase se tratasen, por lo que desde la ventana de
Operaciones de la Tabla (F10), mediante los estereotipos <<index>> o <<trigger>>,
podremos definir por ejemplo:

Pg 87 de 213
 Enterprise Architect
Manual prctico

Tipos de datos para los distintos SGBDs

Dependiendo del tipo de Base de Datos que tengamos seleccionada como Base de
Datos por defecto en el desplegable que la herramienta presenta en la barra superior,
las tablas que creemos nos permitirn seleccionar un rango de tipos de datos
perteneciente a ese tipo de tecnologa.

Podemos establecer la base de datos que deseemos de modo general desde ese
desplegable (de manera que todas las tablas que creemos en adelante pertenecern a
ese tipo de base datos), o bien especificar uno a uno los lenguajes de cada Tabla, en su
ventana de propiedades.

Aparte de los que Enterprise Architect ofrece de fbrica (SQL Server, Oracle, MySQL,
etc) la herramienta tambin nos permite crear tipos de datos de usuario, mediante el
comando de men Settings  Database Datatypes. Esto puede ser til cuando no
queramos comprometer el diseo a una tecnologa en concreto, bien por facilitar la
comprensin al usuario o bien porque se desconoce en el momento de realizar el
modelo.

Con el mencionado comando, accedemos a esta ventana, que nos permite crear nuevos
productos mediante el botn Add Product. Una vez creado el nuevo producto de base
de datos, podemos ir asocindole tipos de datos definidos por nosotros mismos,
indicando para cada uno de ellos la longitud y precisin en caso de ser necesario:

Pg 88 de 213
 Enterprise Architect
Manual prctico

En la primera de las ventanas, existe un botn llamado Datatype Map que nos
permite definir un mapeo de conversin de tipos de datos entre diferentes productos:

Pg 89 de 213
 Enterprise Architect
Manual prctico

Ingeniera inversa de datos mediante ODBC

Enterprise Architect nos permite automatizar la creacin de Modelos de Datos a partir

de bases de datos ya existentes, mediante ODBC.

Tras especificar a la herramienta la situacin de la base de datos, sta realizar

ingeniera inversa y nos presentar el Modelo manteniendo la totalidad de la
informacin del diseo de la base de datos original, es decir, tablas, campos, relaciones,
cardinalidad, claves ajenas, ndices, triggers, etc

Para hacer uso de esta funcionalidad, iremos a la opcin de men Project  Database
Engineering  Import DB Schema from ODBC, obteniendo una ventana que nos
permitir configurar la importacin:

Pg 90 de 213
 Enterprise Architect
Manual prctico

Generacin DDL

Como soporte a la ingeniera directa de bases de datos, Enterprise Architect ofrece la

opcin de generar scripts DDL de creacin de las bases de datos (estructura de tablas,
ndices, procedimientos, funciones, etc) a partir de un modelo preexistente.

El script resultante puede ser ejecutado en cualquier tecnologa de base de datos actual,
para obtener como resultado la base de datos que se deriva del modelo relacional.

Para generar el DDL correspondiente a un modelo, haremos uso de la opcin de men

Project  Database Engineering  Generate Package DDL habiendo seleccionado el
paquete Modelo Fsico de Datos:

Tras configurar las opciones deseadas, pulsaremos el botn Generate o obtendremos

un fichero en la ruta indicada con el script SQL para crear la base de datos en cualquier
tecnologa, como en el ejemplo siguiente:

Pg 91 de 213
 Enterprise Architect
Manual prctico

DROP TABLE IF EXISTS PROYECTO;

DROP TABLE IF EXISTS PETICIN;
DROP TABLE IF EXISTS PARTE;
DROP TABLE IF EXISTS RECURSO;
DROP TABLE IF EXISTS DEPARTAMENTO;

CREATE TABLE PROYECTO

(
NUMEROPROYECTO INTEGER NOT NULL,
NOMBREPROYECTO VARCHAR(50),
ALTAPROYECTO DATE,
JEFEPROYECTO VARCHAR(50),
COSTEESTIMADO DOUBLE,
COSTEREAL DOUBLE,
FECHAESTIMADAINICIO DATE,
FECHAINCIO DATE,
PUNTOSFUNCION INTEGER,
FECHAFIN DATE,
FECHACIERRE DATE,
DESVIACION DATE,
IMPORTANCIA INTEGER,
NUMEROPETICION INTEGER,
PRIMARY KEY (NUMEROPROYECTO),
KEY (NUMEROPETICION)
);

CREATE TABLE PETICIN

(
NUMEROPETICION INTEGER NOT NULL,
FECHAALTA DATE,
DESCRIPCION VARCHAR(50),
PRIORIDAD NUMERIC(10,2),
NUMERODEPARTAMENTO INTEGER,
PRIMARY KEY (NUMEROPETICION),
KEY (NUMERODEPARTAMENTO),
INDEX INDICEFECHA ( ASC)
);

CREATE TABLE PARTE

(
NUMEROPARTE INTEGER NOT NULL,
FECHAPARTE DATETIME,
DESCRIPCIONPARTE VARCHAR(50),
NUMEROPROYECTO INTEGER,
IDRECURSO INTEGER,
PRIMARY KEY (NUMEROPARTE),
KEY (NUMEROPROYECTO),
KEY (IDRECURSO)
);

CREATE TABLE RECURSO

(
IDRECURSO INTEGER NOT NULL,
NOMBRERECURSO VARCHAR(50),
COSTEHORA DOUBLE,
PRIMARY KEY (IDRECURSO)
);

CREATE TABLE DEPARTAMENTO

(
NUMERODEPARTAMENTO INTEGER NOT NULL,
NOMBREDEPARTAMENTO VARCHAR(50),
PERSONACONTACTO VARCHAR(50),
PRIMARY KEY (NUMERODEPARTAMENTO)
);

ALTER TABLE PROYECTO ADD CONSTRAINT FK_PROYECTO_PETICIN FOREIGN KEY (NUMEROPETICION) REFERENCES PETICIN
(NUMEROPETICION);

ALTER TABLE PETICIN ADD CONSTRAINT FK_PETICIN_DEPARTAMENTO FOREIGN KEY (NUMERODEPARTAMENTO) REFERENCES
DEPARTAMENTO (NUMERODEPARTAMENTO);

ALTER TABLE PARTE ADD CONSTRAINT FK_PARTE_PROYECTO FOREIGN KEY (NUMEROPROYECTO) REFERENCES PROYECTO
(NUMEROPROYECTO);

ALTER TABLE PARTE ADD CONSTRAINT FK_PARTE_RECURSO FOREIGN KEY (IDRECURSO) REFERENCES RECURSO (IDRECURSO);

Pg 92 de 213
 Enterprise Architect
Manual prctico

5. Transformaciones MDA e Ingeniera de

Cdigo Fuente
Introduccin

La arquitectura dirigida por modelos (Model-Driven Architecture o MDA) es un

acercamiento al diseo de software, propuesto y esponsorizado por el Object
Managemente Group. MDA se ha concebido para dar soporte a la ingeniera dirigida a
modelos de los sistemas software. MDA es una arquitectura que proporciona un
conjunto de guas para estructurar especificaciones expresadas como modelos.

Usando la metodologa MDA, la funcionalidad del sistema ser definida en primer

lugar como un modelo independiente de la plataforma (Platform-Independent Model o
PIM) a travs de un lenguaje especfico para el dominio del que se trate. Dado un
modelo de definicin de la plataforma (Platform Definition Model o PDM), el modelo
PIM puede traducirse entonces a uno o ms modelos especficos de la plataforma
(Platform-Specific models o PSMs) para la implementacin correspondiente, usando
diferentes lenguajes especficos del dominio, o lenguajes de propsito general. El
proceso completo se encuentra documentado en un documento que actualiza y
mantiene OMG denominado la Gua MDA.

En resumen:

Reglas de
Transformacin
Platform Definition
Model (PDM)

Platform- Platform-
Independent Specific Model
Model Model Driven Architecture
(MDA) (PSM)
(PIM)

Por lo tanto, estamos hablando de la posibilidad de generar, por ejemplo, un Modelo

de Clases de Diseo orientado a Java a partir de un Modelo de Clases de Anlisis
independiente de la plataforma.

Para realizar la transformacin entre modelos, primero crearemos un nuevo paquete

dentro de DISEO llamado Modelo de Clases de Diseo. Despus, seleccionaremos
el paquete Modelo de Clases de Anlisis y pulsaremos la opcin Project  Model
Transformations  Transform current package:

Pg 93 de 213
 Enterprise Architect
Manual prctico

En la siguiente ventana:

En primer lugar, si es preciso, seleccionaremos la opcin Include Child Packages, para

indicar que el tratamiento se haga tambin en los subpaquetes del Modelo (ya que en
nuestro caso, existen 3 subpaquetes donde realmente estn las clases: boundary, control
y entity).

Luego, indicaremos el tipo de transformacin a realizar. En este ejemplo, se ha

seleccionado Java. Al pulsar sobre una tecnologa, la aplicacin nos solicitar el
paquete dentro del cual generar el modelo. En este caso, indicaremos nuestro paquete
recin creado Modelo de Clases de Diseo.

Pg 94 de 213
 Enterprise Architect
Manual prctico

Por ltimo, pulsaremos el botn Do Transform para que se nos aplique la

transformacin automticamente.

Existen otras opciones que se vern en otros apartados, como la opcin Generate Code
on Result que nos creara el cdigo de las clases en el modelo destino.

Como resultado de aplicar la transformacin, tendremos dentro del paquete indicado,

en este caso Modelo de Clases de Diseo un subpaquete llamado Java Model con
el catlogo de clases fruto de la aplicacin de la transformacin.

Es posible modificar las plantillas de transformacin de modelos, mediante la opcin

Transformation Templates, que muestra la siguiente ventana de modificacin de
parmetros de transformacin:

Para cualquier ampliacin de informacin sobre la gestin de plantillas de

transformacin y el manejo del editor de scripts de transformacin, se recomienda
consultar la Ayuda de la aplicacin.

Pg 95 de 213
 Enterprise Architect
Manual prctico

Tipos de datos para los diferentes lenguajes

De igual modo de hemos hecho en el apartado de Modelizacin de Datos con los tipos
de datos de los SGBDs, tambin es posible modificar los tipos de datos de los lenguajes
de programacin que la herramienta propone, o definir nuevos lenguajes de
programacin con sus propios tipos de datos definidos por el usuario.

Para ello, haremos uso de la opcin Settings  Code Datatypes del men, que nos
mostrar la ventana:

Donde podremos modificar los tipos de datos de los lenguajes de programacin

preexistentes en la herramienta (Java, C#, VB.NET, etc) o crear nuevos productos con
los tipos de datos que deseemos.

La operativa de esta ventana es obvia, por lo que no profundizaremos ms en ella.

Generacin de Cdigo Fuente a partir de un Modelo

Yendo un paso ms all, Enterprise Architect nos permite generar cdigo fuente a
partir de un modelo dado. Para este ejemplo, utilizaremos el Modelo de Clases de
Anlisis existente en el proyecto para, a partir de l, generar un Modelo de Clases de
Diseo y el cdigo fuente derivado de la transformacin de las clases, en lenguaje Java.

Para comenzar, crearemos dentro de la Vista DISEO el Paquete Modelo de Clases

de Diseo que recoger el producto de la transformacin.

Pg 96 de 213
 Enterprise Architect
Manual prctico

Ahora seleccionamos el paquete origen de la transformacin: Modelo de Clases de

Anlisis. Con el paquete seleccionado, ejecutamos la opcin Project  Model
Transformations  Transform Current Package, lo que nos muestra la siguiente ventana

En esta ventana, haremos varias verificaciones:

1. Que la casilla Include Child Packages est seleccionada si es necesario. Es decir,

si el paquete a transformar tiene subpaquetes que han de ser transformados,
hay que seleccionarlo. Es posible que la ventana no muestre ningn elemento
hasta que lo seleccionemos, ya que normalmente la organizacin de los
elementos en subsistemas hace que no haya ningn elemento en el paquete raz
a transformar (en este caso Modelo de Clases de Anlisis).

Pg 97 de 213
 Enterprise Architect
Manual prctico

2. Que en la seccin Transformations est/n marcada/s aquella/s tecnologa/s a la/s

que queremos llegar, as como el paquete de destino de la transformacin.

3. Que la casilla Generate Code on result est marcado, si queremos que se genere
el cdigo de las clases de destino al finalizar la transformacin.

Por ltimo, pulsaremos el botn Do Transform y la herramienta comenzar a crear los

modelos de destino a partir del original, y por ltimo el cdigo asociado a las clases de
destino.

En caso de haber seleccionado ms de una tecnologa (por ejemplo Java y C#), en el

paquete destino se crearn dos subpaquetes con los nombre Java Model y C#
Model para separar los modelos entre s. Por lo tanto, el resultado de la
transformacin Java del paquete Modelo de Clases de Anlisis, sera:

Y el cdigo fuente de la Clase, por ejemplo, CLAN03.CGestinPeticiones:

La ventana anterior, que muestra el cdigo asociado a las clases si ste se ha generado,
se obtiene a travs del men View  Source Code.

Pg 98 de 213
 Enterprise Architect
Manual prctico

Parametrizacin de la Ingeniera de Cdigo

Es posible modificar algunos aspectos de la generacin de cdigo fuente, a travs de la

opcin Code Generation Templates, disponible en el men Settings

Mediante la ventana que se muestra a continuacin se puede modificar, para cada

lenguaje en particular, la manera en que las declaraciones de cada seccin sern
construidas:

Para ver en detalle la manera de manejar los scripts de generacin, se recomienda

consultar la Ayuda de la aplicacin.

Pg 99 de 213
 Enterprise Architect
Manual prctico

Ingeniera inversa a partir de Cdigo Fuente o binarios

Es posible realizar ingeniera inversa de cdigo fuente (.java, .vb, .h) o ficheros
binarios (.exe, .dll. .jar) de modo que Enterprise Architect cree los diagramas de
Clases correspondientes, con las clases, atributos y operaciones contenidas en dichos
ficheros.

Hay que tener en cuenta que, cuando se trata de ficheros binarios, la importacin de las
operaciones se hace nicamente de la parte declarativa, es decir, el nombre de la
operacin y los parmetros.

Antes de realizar la ingeniera inversa, sea del tipo que sea, hemos de seleccionar el
paquete destino de los modelos fruto de la importacin, esto es, el paquete dentro de
nuestro proyecto donde se alojarn los diagramas y las clases que se generen en la
importacin.

Para realizar una importacin de cdigo fuente y la creacin del modelo asociado,
existen varias opciones, estando todas ellas recogidas dentro del men:

1. Ingeniera inversa de cdigo fuente:

a) Import Source Directory: Sirve para especificar la carpeta en la que se

encuentran los archivos a importar, adems del lenguaje a importar y otras
opciones relativas a la creacin del modelo de clases. Esta opcin, muestra la
siguiente ventana:

Pg 100 de 213
 Enterprise Architect
Manual prctico

En esta ventana configuraremos las opciones deseadas para llevar a cabo la

importacin segn nuestras necesidades.

b) Import *** files: Sirve para especificar directamente el lenguaje de

programacin de los archivos a importar. Al seleccionar esta opcin, se
mostrar una cuadro de dilogo de abrir archivo que nos permitir
seleccionar uno o varios archivos de una carpeta determinada.

2. Ingeniera inversa de archivos binarios:

La opcin Import Binary Module nos muestra la ventana en la que, tras indicar la ruta
del archivo y las opciones de importacin, nos permite realizar directamente la
importacin y creacin del modelo de clases:

Pg 101 de 213
 Enterprise Architect
Manual prctico

Un ejemplo de diagrama creado automticamente tras la importacin de un archivo

binario junit-4.1-src.jar sera el siguiente:

Creacin automtica de Diagramas de Secuencia a partir de

cdigo fuente

Es posible, a travs de la ejecucin de una traza de cdigo fuente, construir de manera

automtica el consecuente diagrama de secuencia.

Para llevar a cabo esta tarea, hay que hacer uso de las funcionalidades de construccin
y ejecucin de Enterprise Architect. Una vez tengamos debidamente configurado el
enlace con el compilador de cdigo, el Debug Workbench nos va a permitir realizar
trazas de ejecucin de igual modo que lo podemos hacer desde nuestro entorno de
programacin, con la ventaja de que, si lo deseamos, toda la informacin relativa a
mensajes entre objetos va a ser capturada por Enterprise Architect y trasladada a un
diagrama de secuencia.

En primer lugar, veamos el entorno de depuracin integrado, desde el men View 

Debug Workbecnch

Pg 102 de 213
 Enterprise Architect
Manual prctico

Desde aqu, y usando la opcin Package Build Scripts del ltimo botn de la derecha,
y luego el botn Add, configuraremos los scripts de construccin del lenguaje:

Para construccin

Ejecucin

Pg 103 de 213
 Enterprise Architect
Manual prctico

Depuracin

Una vez configurados, pulsamos Aceptar y volvemos a la ventana principal, que nos
indica con una X qu apartados han sido configurados:

Pg 104 de 213
 Enterprise Architect
Manual prctico

Llega el momento de ejecutar el paquete. Para este ejemplo, se ha importado un

paquete Java con cdigo fuente mediante la opcin Import Source Directory. Por lo
tanto, sobre el paquete importado, seleccionaremos la opcin del men contextual
Build and Run  Build:

Para seguir con el ejemplo, hemos mostrado la ventana de cdigo y establecido un

breakpoint (punto de interrupcin) en un mtodo.

Ahora, vamos a ejecutar un thread hasta el punto de interrupcin. Para ello, pulsamos
el botn:

Pg 105 de 213
 Enterprise Architect
Manual prctico

Al llegar al punto de interrupcin, la ejecucin se detiene. A partir de aqu vamos a

grabar el comportamiento del hilo de ejecucin, para generar el diagrama de
secuencia:

El histrico de la traza ya ha sido grabado. Ahora, para dibujar diagrama de secuencia,

utilizaremos el botn:

Lo que nos dar como resultado el diagrama de secuencia fruto de la ejecucin de ese
hilo:

Pg 106 de 213
 Enterprise Architect
Manual prctico

Como hemos podido ver, el realizar la transicin desde cdigo fuente a sus
correspondientes diagramas de secuencia, no es ningn problema gracias a esta
funcionalidad, que hace viable el acometer la representacin mediante modelos de
proyectos de desarrollo ya comenzados, o bien realizar comparaciones entre la
ejecucin del cdigo fuente de una aplicacin y su modelo de comportamiento
esperado.

Pg 107 de 213
 Enterprise Architect
Manual prctico

6. Gestin de Proyectos
Introduccin

Enterprise Architect ofrece soporte integrado para la gestin del proyecto, desde el
punto de vista global y tambin desde el punto de vista del mantenimiento de los
elementos y productos UML que lo constituyen.

A travs de algunas ventanas que podemos posicionar a nuestro gusto en la interfaz,

podemos gestionar aspectos como el glosario de trminos del proyecto, el banco de
recursos humanos, las tareas, incidencias, cambios y defectos en los elementos, etc

Esta informacin puede ser de mucha utilidad a algunos participantes en el proyecto, y

es automticamente mostrada en la documentacin que generemos del proyecto,
utilizando una plantilla adecuada.

Vamos a hacer un repaso breve por estas ventanas, que por comodidad y como regla
general, se aconseja alojar en la parte baja de la pantalla, bajo la seccin de Diagramas:

A nivel global

Desde el men View  System accedemos a una ventana con tres pestaas:

1. Glosario del Proyecto (Project Glossary):

Pg 108 de 213
 Enterprise Architect
Manual prctico

Aqu podemos definir un completo Glosario de Trminos, que acerquen al lector al

dominio del proyecto y sus trminos, acrnimos y definiciones ms usuales. Para
editar trminos existentes o crear nuevos, basta con hacer doble clic en cualquier fila y
completar la ventana emergente:

2. Incidencias del Proyecto (Project Issues):

En esta ventana podremos definir aquellas incidencias del proyecto a nivel global, a
travs de la siguiente ventana de trabajo:

Pg 109 de 213
 Enterprise Architect
Manual prctico

3. Tareas del Proyecto (Project Tasks):

Aqu podemos llevar, por ejemplo, un ndice general de tareas de alto nivel pendientes,
o etapas con su estado asociado, iteraciones, etc La ventana que nos permite
introducir y modificar tareas es:

A nivel de Elemento o Paquete

Tambin es posible definir valores y estados a los elementos, modelos, paquetes de

nuestro proyecto de manera individual. Para ello, haremos uso de otras ventanas, que
vemos a continuacin:

Desde el men View  Project Management accedemos a una ventana con cuatro
pestaas:

4. Asignacin de Recursos (Resource Allocation):

Pg 110 de 213
 Enterprise Architect
Manual prctico

Aqu podemos asignar recursos y especificar detalles de esa asignacin para cada
elemento del repositorio que deseemos. Por ejemplo, podemos asignar a un equipo de
personas que vayan a crear el Modelo de Casos de Uso, e indicar fechas y tiempos
estimados para la realizacin de dicho modelo

5. Esfuerzo (Effort):

para indicar el esfuerzo estimado para un determinado elemento o etapa

Nota: Se pueden definir los tipos de esfuerzo

generales al proyecto desde la opcin de men
Settings  Project Indicators

6. Riesgos (Risks):

para valorar los riesgos asociados en base a la definicin general de riesgos

Nota: Se pueden definir los tipos de riesgo generales

al proyecto desde la opcin de men Settings 
Metrics & Estimation Types  Risks

Pg 111 de 213
 Enterprise Architect
Manual prctico

7. Mtricas (Metrics):

o asignar mtricas asociadas en base a la definicin general de mtricas

Nota: Se pueden definir los tipos de mtricas

generales al proyecto desde la opcin de men
Settings  Metrics & Estimation Types 
Metrics

Otra de las ventanas que nos permiten gestionar caractersticas relacionadas con la
gestin de proyectos a nivel de elemento o paquete es la que se obtiene desde el men
View  Maintenance, que a su vez tiene cuatro pestaas:

8. Defectos (Defects):

9. Cambios (Changes):

Pg 112 de 213
 Enterprise Architect
Manual prctico

10. Incidencias (Issues):

11. Tareas (Tasks):

Soporte a las pruebas

Desde la ventana View  Testing accedemos a una completa ventana que nos
permite definir, para cada elemento o paquete de manera individual, un conjunto de
pruebas enmarcadas en cinco tipos: Unitarias, de Integracin, de Sistema, de
Aceptacin y de Escenario:

Para cada una de las pruebas que definamos en nuestra batera, podremos indicar el
nombre del test, el tipo, el estado, la persona que lo efecta y una amplia descripcin
con los valores de entrada, los criterios de aceptacin y los resultados en caso de que el
caso de prueba haya sido ejecutado.

La informacin recogida en esta ventana ser la que pase a formar parte de los
informes de pruebas que la herramienta genera automticamente en base a plantillas
propias o prediseadas.

Pg 113 de 213
 Enterprise Architect
Manual prctico

7. Importacin y Exportacin

Introduccin

Enterprise Architect utiliza, para la importacin y exportacin, el formato universal de

intercambio XMI. Gracias a este estndar, tambin es posible que la comunicacin con
otras herramientas como IBM Rational Rose se efecte de manera satisfactoria.

Dado el enfoque a paquete que tienen este tipo de herramientas, es muy sencillo el
realizar exportaciones de determinados paquetes (modelos, etapas, productos) al
exterior o realizar incorporaciones de paquetes al proyecto para, principalmente,
reutilizar elementos ya existentes en otros proyectos, por ejemplo.

XMI

Es posible configurar, a travs de las opciones, algunos aspectos de la utilizacin del

estndar, como muestra la siguiente ventana. Por defecto, trabajaremos con las
opciones que ofrece la herramienta sin ms, si bien es posible que determinados
usuarios precisen modificar algn aspecto, desde Tools  Options en la seccin XML
Specifications.

Pg 114 de 213
 Enterprise Architect
Manual prctico

Tablas de informacin de referencia

Una de las mayores utilidades de la importacin es la reutilizacin de elementos, bien

procedentes de Anlisis o Diseos realizados con anterioridad, o bien por que se trate
de elementos comunes a la organizacin como un banco de recursos, una definicin de
tipos de requisitos o un lenguaje de programacin especfico.

Las tablas a las que hace referencia este apartado son muchas, pero principalmente,
aquellas que se encuentran en el men:

Y que contienen informacin general de este tipo.

Gracias a la exportacin e importacin de estas tablas, podremos intercambiar entre

diversos proyectos las siguientes tablas:

Pg 115 de 213
 Enterprise Architect
Manual prctico

Para acceder a esta ventana de exportacin de tablas, disponemos del men Tools 
Export Reference Data

Cuando se muestre esta ventana, nicamente es cuestin de seleccionar aquellas tablas

que deseamos exportar (soporta seleccin mltiple con la tecla Control), pulsar
Export e indicar el lugar y nombre del fichero XML de salida. Por ejemplo:

Esta seleccin exportara la totalidad

de informacin relativa a las plantillas
de documentacin RTF y HTML del
proyecto.

Al finalizar, tendremos un fichero XML con la definicin y contenido de todas las

tablas que hayamos seleccionado.

Pg 116 de 213
 Enterprise Architect
Manual prctico

El proceso inverso, es decir, la importacin de estas tablas a otro proyecto diferente, se

hara desde el men Tools  Import Reference Data

e indicando en esta ventana el lugar donde est alojado el fichero .xml con las
tablas a importar. Por ltimo, habra que seleccionar qu tablas contenidas en el fichero
queremos importar, y pulsar Import.

Exportacin e Importacin de Paquetes

Aparte de lo anteriormente visto, la importacin y exportacin puede realizarse con

cualquier paquete de nuestro repositorio. Esto ofrece, por ejemplo, la posibilidad de
gestionar manualmente un desarrollo compartido, mediante la cesin y actualizacin
de paquetes por parte de diversos equipos de desarrollo a un repositorio comn. Como
es lgico, esta no es la manera ms adecuada de trabajar en un entorno de desarrollo
distribuido, pero la funcionalidad de exportacin e importacin por s sola est ms
que justificada para momentos puntuales y bien controlados, en los que la inclusin de
un paquete en el proyecto o la extraccin de una copia de uno al exterior es necesaria.

Existen mltiples maneras de exportar o importar un paquete. Como regla general, se

puede utilizar la opcin contenida en el men Project  Import / Export  Import
Package from XMI o Project  Import / Export  Export Package to XMI, si bien
generalmente pulsando el botn derecho sobre cualquier paquete del Project Browser se
nos ofrece la opcin de exportar o importar un paquete en el paquete seleccionado.

Pg 117 de 213
 Enterprise Architect
Manual prctico

Importacin de paquetes:

La opcin Import Package from XMI muestra la ventana anterior, en la que nos indica
el paquete padre bajo el cual se alojar el paquete importado (en este caso
ANLISIS), el nombre del fichero a importar y otras opciones como el importar o no
los diagramas, escribir un log de la importacin, etc

Una opcin a veces importante es la denominada Strip GUIDs que consiste en

indicar, ante un mismo GUID en un elemento existente, si debe sobrescribir este GUID
en el elemento importado o no.

Exportacin de paquetes:

De modo similar al anterior, nos muestra el paquete raz a exportar, el nombre del
fichero de salida, y otras opciones de exportacin.

Pg 118 de 213
 Enterprise Architect
Manual prctico

8. Gestin de la Configuracin en EA

Introduccin

Este captulo va a describir la Gestin de la Configuracin por dos vas. De un lado,

veremos las posibilidades que ofrece Enterprise Architect para llevar un control de
versiones como una funcionalidad contenida en la herramienta, algo limitada, pero a
veces suficiente.

De otro lado, la posibilidad de interconexin con herramientas de Gestin de la

Configuracin especficas que ofrezcan toda su potencia al servicio del control de
versiones y configuraciones de los modelos de Enterprise Architect.

Control de Versiones en Enterprise Architect

Creacin de Lneas de Base

Una de las funcionalidades que ofrece la herramienta es la creacin de lneas de base,

que son snapshots del estado actual de determinado paquete o modelo.

Podemos definir tantas lneas de base como queramos para cada paquete, subpaquete,
etc La manera en que Enterprise Architect maneja estas lneas de base es mediante
una Exportacin XMI del paquete seleccionado, asignando alguna informacin
adicional a la que se realizara mediante una exportacin manual normal.

Para crear una lnea de base de un paquete determinado, procederemos ejecutando la

opcin de men: Project  Manage Baselines:

Pg 119 de 213
 Enterprise Architect
Manual prctico

Tras pulsar el botn Create New Baseline nos aparece el dilogo:

Indicaremos el nmero de versin, y si se desea, algn comentario adicional en el

campo Note. Al aceptar, y tras ejecutarse automticamente el proceso de Exportacin
XMI, el resultado sera:

Comparacin entre Versiones

Es posible efectuar una comparacin grfica entre el estado actual del proyecto, y
alguna lnea de base almacenada. Para ello, vamos a realizar algunas modificaciones en
el paquete ANLISIS para posteriormente compararlo con la lnea de base recin
creada.

Para realizar la comparacin, mostraremos de nuevo la ventana de gestin de lneas de

base mediante el men Project  Manage Baselines y, seleccionando la lnea de base
con la que comparar (en este caso ANLISIS 1.0), pulsaremos el botn Show
Differences

Pg 120 de 213
 Enterprise Architect
Manual prctico

Al pulsar el botn, y tras unos segundos en los que la herramienta realiza la

comparacin, se nos muestra una ventana en la que, mediante iconos de distintos
colores, se nos resaltan aquellos elementos que han sido creados, modificados o
eliminados en esta versin con respecto a la lnea de base ANLISIS 1.0.

Podemos ver como la utilidad de comparacin muestra:

Con un tringulo verde, aquellos elementos nuevos (Atributo1, Atributo2,

Operacion1 en la clase CLAN02.BPantallaProyecto

Con un tringulo azul, aquellos elementos modificados (Entorno Tecnolgico

por Entorno Tecnolgico del Sistema)

Con un tringulo rojo, aquellos elementos eliminados (Node1)

Adicionalmente, en la ventana de la derecha se muestran las diferencias del elemento

creado, modificado o eliminado entre el modelo actual y la lnea de base.

NOTA: De manera manual, es posible restaurar una lnea de base al modelo actual. Para ello,
disponemos del botn Export File que, aplicado a una lnea de base existente, nos genera el
fichero XML con el contenido de esa lnea de base. Despus, bastara con importarlo al proyecto
como un paquete (cuidando de ponerlo bajo el padre correspondiente) para que sustituya a la
versin actual.

Pg 121 de 213
 Enterprise Architect
Manual prctico

Conexin de Enterprise Architect con herramientas de

gestin de la Configuracin: Ejemplo AccuRev

Enterprise Architect viene preparado para trabajar con diversas herramientas externas
de Gestin de la Configuracin a travs de XML. Entre ellas, figuran AccuRev, CVS,
Subversin, TFS, SourceSafe...

La configuracin de Enterprise Architect para trabajar con cada una de ellas vara
sensiblemente. En este apartado, vamos a trabajar sobre un ejemplo de integracin del
Repositorio Enterprise Architect con AccuRev.

Configuracin de AccuRev

En el servidor AccuRev, se ha de crear un nuevo depot con la opcin de Exclusive

Locking seleccionada (aparece pulsando el botn Advanced en el cuadro de dilogo de
creacin del nuevo depot):

Pg 122 de 213
 Enterprise Architect
Manual prctico

Una vez hecho esto, en cada mquina cliente debe crearse un workspace con la
caracterstica de Exclusive Locking tambin seleccionada:

Configuracin de Enterprise Architect

Ahora trabajaremos desde una mquina con Enterprise Architect instalado, y el cliente
AccuRev tambin instalado y con un Workspace de trabajo debidamente configurado,
como se ha indicado en el punto anterior.

En dicha mquina, y con el proyecto de Enterprise Architect que deseamos controlar

bajo AccuRev abierto, seleccionaremos el men Project  Version Control  Version
Control Settings

En la pantalla que se mostrar, crearemos una nueva configuracin como indican los
siguientes pasos, y muestra la figura:

Dar un identificador nico (un nombre a la configuracin para salvarla).

Seleccionar como tipo SCC.

Elegir como PATH la ruta donde est nuestro Workspace de AccuRev.

Escoger como SCM a AccuRev.

Pulsar Save.

Hacer log-in con nuestro usuario AccuRev

Pg 123 de 213
 Enterprise Architect
Manual prctico

Configuracin del Paquete Controlado

Una vez realizada con xito la integracin de las dos herramientas, se puede proceder a
controlar el paquete deseado:

Seleccionar el paquete a controlar.

Clic sobre l con el botn derecho del ratn.

Seleccionar la opcin Package Control  Configure.

Pg 124 de 213
 Enterprise Architect
Manual prctico

En el cuadro de dilogo que aparecer, seleccionar la casilla Control

Package.

Seleccionar, en el desplegable Version Control, la configuracin definida
y salvada en el punto anterior; aquella que integraba Enterprise
Architect con AccuRev.

Pulsar el botn OK.

Se iniciar un proceso de exportacin XML que, una vez finalizado, dar como
resultado el que ya tengamos el paquete bajo control. Se puede observar el cambio de
la imagen asociada en el paquete. Si el paquete aparece con el smbolo 8 a un lado y
una llave en su interior, es que sobre ese paquete se encuentra bloqueado, es decir, en
check-in.

Pg 125 de 213
 Enterprise Architect
Manual prctico

Si el paquete tiene un smbolo 8 nicamente, es que sobre ese paquete se ha hecho un

check-out y se encuentra, por tanto, desbloqueado.

Si se va a trabajar con ms de un usuario sobre el mismo Repositorio, hay que

configurar cada mquina para trabajar en su Workspace de AccuRev local propio. Para
ello, en la mquina de cada uno de los usuarios que vayan a trabajar conjuntamente,
abriremos el mismo proyecto de EA.

Automticamente aparecer una pantalla en la que nos informar que la gestin de

configuracin an no est configurada en esa mquina. Ante la pregunta de si
queremos completar la configuracin, pulsaremos el botn Yes.

A continuacin, aparecer una pantalla similar a la anterior en la que tendremos que

configurar de nuevo el PATH, esta vez, a nuestro workspace local (es decir, al del nuevo
usuario). El sistema tambin nos indicar que le hemos de hacer log-in en AccuRev
como antes.

Pg 126 de 213
 Enterprise Architect
Manual prctico

9. Seguridad del Proyecto

Introduccin

Es posible en Enterprise Architect configurar algunas caractersticas relacionadas con la

seguridad y los permisos a travs de la propia herramienta.

Mediante la gestin de roles y permisos, podremos asociar usuarios a grupos de

trabajo y concederles permisos internos de trabajo para realizar determinadas tareas.

Veremos tambin como algunas de estas opciones incluso van a determinar de una
manera drstica la definicin del modo de trabajo.

Activacin de la seguridad del Proyecto

Antes de poder hacer uso de las funciones de seguridad, es preciso activar la seguridad
en el proyecto. Para ello, seleccionaremos la opcin del men Project  Security 
Enable security.

En la ventana emergente, introduciremos la clave:

F08113BA-8B4F-41df-8F01-46DF2C35D249

Si la activacin se ha realizado correctamente, recibiremos el mensaje

que nos informa de que, en adelante, cuando abramos el proyecto habr que
efectuar un Login cuyos datos por defecto, hasta que los cambiemos, son:

Pg 127 de 213
 Enterprise Architect
Manual prctico

User: admin.
Password: password

Vamos a cerrar y volver a abrir el proyecto para comprobar que efectivamente nos
solicita hacer Login:

NOTA: En cualquier momento, podemos volver a deshabilitar la seguridad en el proyecto

siguiendo el mismo procedimiento que para la creacin.

Gestin de Roles y Permisos

Una vez activada la seguridad, el men Project  Security nos muestra habilitadas
todas sus opciones. Vamos a seleccionar Manage Groups.

Pg 128 de 213
 Enterprise Architect
Manual prctico

A travs de esta ventana, podemos crear, modificar y eliminar los grupos de usuarios
que participan en el proyecto. Adicionalmente, indicaremos los permisos para cada
uno de los grupos mediante el botn Set Group Permissions:

A continuacin, vamos a definir algunos usuarios mediante el men Manage Users.

Pg 129 de 213
 Enterprise Architect
Manual prctico

En el ejemplo, aparte del usuario The Administrador existente, se va a crear un

usuario Analista Uno cuyo user es analista1.

Una vez creado el nuevo usuario vamos a, en primer lugar, asignarle un password con
el botn Change Password.

En segundo lugar, vamos a asignarle un grupo mediante el botn Group Membership.

En su caso, ser Analistas.

Ntese que, adems de haber recibido una serie de permisos por el hecho de
pertenecer al grupo Analistas, se pueden establecer permisos individuales para el
usuario en concreto, mediante el botn Single Permissions.

Pg 130 de 213
 Enterprise Architect
Manual prctico

Bloqueo de Elementos

Una de las nuevas funciones que tenemos disponibles al haber activado la seguridad
del proyecto, es la de efectuar bloqueos en los elementos del repositorio.

Bloquear un elemento es similar a lo que en un gestor de configuracin sera hacer

Check-Out, es decir, impedir la edicin de el elemento por usuarios distintos a los
indicados para garantizar la integridad de la informacin en cuanto a que no se
puedan realizar varios cambios simultneamente que provoquen que el estado final
del elemento no sea el esperado por cada uno de los usuarios.

Para bloquear un elemento en Enterprise Architect, se le secciona y con el botn

derecho se pulsa Lock element, Lock o Lock Diagram segn sea el elemento a
bloquear. En cada caso, aparecera la ventana:

PAQUETE ELEMENTO / DIAGRAMA

No lock, general editing allowed: El equivalente a desbloquear un paquete

bloqueado (Check-In)
Full lock, no-one may edit: Bloqueo completo. Nadie en absolute puede
modificar el paquete.
User lock, locking user may still edit: El equivalente al Check-Out, para el
usuario que lo solicita.
Group lock, locking group may still edit: El equivalente al Check-Out, para el
grupo indicado.

Pg 131 de 213
 Enterprise Architect
Manual prctico

Las opciones de What to Process sirven para indicar qu parte del contenido del
paquete se bloquear (normalmente, todo).

Los bloqueos que los integrantes del equipo vayan realizando a lo largo del tiempo,
pueden ser gestionados de dos formas:

Gestin de mis bloqueos:

Desde el men Project  Security  My Locks se nos muestra una ventana que nos
enumera la totalidad de elementos bloqueados por mi:

Desde esta ventana, tambin es posible realizar el desbloqueo de los que se deseen,
mediante el botn Unlock Selected.

Gestin de todos los bloqueos:

Suponiendo que el usuario tenga permiso para ello, tambin se puede realizar una
gestin completa de todos los bloqueos existentes mediante el men Project  Security
 Manage Locks:

Pg 132 de 213
 Enterprise Architect
Manual prctico

En esta pantalla podemos ver los bloqueos realizados para grupos, para usuarios o
todos ellos, adems de realizar desbloqueos mediante el botn Unlock Selected.

Por ltimo, existe un modo de trabajo algo distinto pero que a veces, en funcin del
entorno de trabajo, puede resultar interesante. Mediante la opcin de men Project 
Security  Require User Lock to Edit, estamos indicando a la herramienta que por
defecto, todos los elementos estn bloqueados, y que necesariamente el usuario tiene
que desbloquearlos para poder editar cualquier contenido.

Esto obliga a los usuarios a desbloquear, editar y bloquear continuamente. En principio

puede parecer un control excesivo, si bien en algunos dominios crticos o de mucha
concurrencia es una opcin a tener en cuenta.

Pg 133 de 213
 Enterprise Architect
Manual prctico

10. Repositorios en Base de Datos

Introduccin

En la mayora de las ocasiones, los departamentos de desarrollo y los proyectos que

ejecutan estn compuestos por un gran nmero de personas, que intervienen en las
distintas etapas del ciclo de vida del software.

Algunas de estas personas sern responsables de crear y mantener modelos UML.

Otros, precisarn consultarlos continuamente para su labor de desarrollo. Los usuarios
de la aplicacin, es posible que deseen ver la documentacin y la descripcin de los
requisitos del software. Los Jefes de Proyecto se interesarn por el estado del proyecto
y su grado de avance en resumen, multitud de personas pueden hacer uso
simultneo de Enterprise Architect y los modelos pertenecientes a cada uno de los
proyectos.

Esta gran concurrencia de usuarios simultneos o el gran volumen de modelos,

diagramas, elementos, etc puede presentar problemas cuando trabajamos contra un
fichero .eap. Para solucionar esto, tendremos que recurrir a trabajar en Repositorios
soportados por Sistemas Gestores de Bases de Datos de mayor potencia, como SQL
Server, Oracle o MySQL, por ejemplo.

Este captulo va a abordar la gestin de estos repositorios, desde el punto de vista de

creacin, conexin y migracin de las estructuras de trabajo.

Creacin del Repositorio

Lo primero que debemos hacer cuando vamos a trabajar bajo este entorno, es crear el
repositorio en el SGBD acordado. En este ejemplo, vamos a trabajar en SQL Server, si
bien las descripciones que se van a efectuar son muy similares para otros entornos.

Para llevar a cabo esta tarea, tendremos que:

Crear una nueva base de datos

Ejecutar un script de definicin de tablas e ndices

Una vez hecho esto, dispondremos de un Repositorio vaco listo para alojar modelos,
diagramas, elementos, etc de Enterprise Architect.

Para abordar este ejemplo, vamos a tratar un caso genrico de configuracin. El lector
ha de tener en cuenta que esto variar en funcin de las mltiples variantes de
configuracin de SQL Server, el dominio de la red, usuarios NT o de Base de Datos,
etcCon esto siempre presente, veamos cada uno de los pasos:

Pg 134 de 213
 Enterprise Architect
Manual prctico

1. En el equipo servidor de SQL Server, hay que crear una base de datos en
blanco con todos los permisos:

y asignarle un nombre:

2. Una vez creada, accedemos a ella y ejecutamos el script correspondiente a la

versin (SQL Server 7, 2000, 2005) disponible en la web de Sparx Systems
(www.sparxsystems.com). Para ello, con la base de datos recin creada
seleccionada ejecutamos el SQL Query Analyzer

seleccionamos el archivo .sql con el script a ejecutar

y ejecutamos finalmente el script que crear la estructura de tablas e

ndices necesaria para albergar Repositorios de Enterprise Architect.

Pg 135 de 213
 Enterprise Architect
Manual prctico

Transferencia de datos al Repositorio

Habitualmente, los departamentos de T.I. desean disponer de una plantilla

adaptada a su proceso de desarrollo de software, preparada para alojar los
distintos modelos UML que se generan a lo largo de las distintas etapas e
iteraciones del ciclo de vida del software de cada uno de los proyectos.

Esta plantilla puede tener infinidad de variantes, pero su objetivo siempre ser
servir de gua a los analistas, desarrolladores, arquitectos de software, etc en
la gestin de los modelos y productos entregables dentro de cada etapa del
desarrollo.

La creacin de una plantilla de este tipo lleva asociado, tambin opcionalmente,

la adaptacin de las plantillas de documentacin RTF de Enterprise Architect al
formato de los documentos corporativos, para garantizar una adecuada
generacin automtica de la documentacin conforme a los requisitos
documentales establecidos en la organizacin.

Esta plantilla estar normalmente en un fichero con formato nativo de

Enterprise Architect .eap que deberemos subir a nuestro nuevo Repositorio
SQL Server, tantas veces como proyectos vayamos a iniciar.

Para llevar a cabo esta tarea, hay que seguir los siguientes pasos:

1. Localizar el fichero EAP con el Repositorio Modelo a subir a SQL Server.

2. Subir a la Base de Datos SQL Server recin creada y con estructura de

Repositorio Enterprise Architect, dicho Repositorio Modelo recin
localizado, mediante la opcin del men: Tools  Data management  Project
transfer  EAP to DBMS

Pg 136 de 213
 Enterprise Architect
Manual prctico

3. Seleccionar en Source Project el fichero EAP con el Repositorio Modelo, en

Target Project la Base de Datos SQL Server que alojar el Repositorio del
proyecto concreto, y pulsar el botn Transfer.

NOTA: En el momento de seleccionar el Target Project, es preciso configurar la

conexin mediante un cuadro de dilogo de conexin ODBC, que se ve en detalle en el
prximo punto: Conexin de los puestos con el Repositorio.

Conexin de los puestos con el Repositorio

Una vez disponemos de un Repositorio creado y una plantilla de trabajo, ser

necesario configurar los puestos para que puedan acceder a dicho entorno de
trabajo comn. Para ello, en los puestos con Enterprise Architect instalado:

1. Cada vez que se desee acceder desde un puesto al Repositorio del Proyecto
en SQL Server habr que, inicialmente, utilizar la opcin de Enterprise
Architect Connect to Server y seleccionar el proveedor Microsoft OLE DB
Provider for SQL Server:

NOTA: Para poder llevar a cabo esta tarea, es preciso que el equipo disponga del
MDAC 2.6 o superior instalado.

Pg 137 de 213
 Enterprise Architect
Manual prctico

2. A continuacin, pulsar Next y especificar el nombre de servidor, usuario y

password correspondientes (en caso de que la base de datos est as
configurada) o bien utilizar la opcin Use Windows NT Integrated security
(si se opta por la autenticacin NT). Con estos datos introducidos,
podremos seleccionar el Repositorio del proyecto concreto del desplegable
Select the database on the Server.

3. En lo sucesivo, Enterprise Architect recordar esta conexin mediante el

nombre que proporcionemos en la siguiente ventana, y lo mostrar en la
lista de archivos recientes, para poder conectar de manera automtica.

4. Cuando se trabaja contra un SGBD, y en el caso de que deseemos activar la

seguridad del proyecto (ver captulo 9), se debe introducir siguiente clave
cuando Enterprise Architect lo solicite:

F08113BA-8B4F-41df-8F01-46DF2C35D249

Pg 138 de 213
 Enterprise Architect
Manual prctico

Este grfico muestra un ejemplo de operativa de trabajo de un equipo de usuarios de

Enterprise Architect y un Administrador de Bases de Datos, en un entorno compartido
en LAN.

Servidor Base de Datos

Connect to Server (ODBC)

Repositorio
Proyecto 1

Repositorio
Proyecto 2

Repositorio
Proyecto n

Usuarios Enterprise
Project Transfer Architect

Repositorio
Modelo
(EAP)

Administrador Base de Datos (con

Enterprise Architect y Repositorio Modelo)

Pg 139 de 213
 Enterprise Architect
Manual prctico

11. Documentacin HTML

Introduccin

Enterprise Architect nos proporciona una excelente herramienta de generacin de

documentacin del proyecto.

En las ltimas versiones de ha reforzado este aspecto para dotar a la aplicacin de una
potencia documental comparable a las mejores herramientas especializadas.

Esta documentacin puede ser creada, principalmente, en dos formatos estndar:

1. Documentacin en formato HTML

2. Documentacin en formato RTF (texto enriquecido)

En este captulo vamos a ver la primera de las opciones. La documentacin RTF ser
abordada en el siguiente.

La documentacin generada en HTML es excelente de cara a la publicacin de los

modelos en, por ejemplo, una intranet corporativa. Cualquier persona implicada en el
proyecto podr consultar los modelos, diagramas y dems elementos prcticamente
del mismo modo que se hace desde Enterprise Architect, sin necesidad de tener la
herramienta instalada.

Es una manera perfecta de publicar la informacin del proyecto para su consulta, de un

modo rpido, efectivo y atractivo.

Plantilla de generacin

Antes de efectuar la generacin de la documentacin, vamos a ver hasta qu punto

podemos adaptar esa generacin a travs del manejo de la plantilla de generacin
HTML. Para ello, haremos uso de la seccin Templates  Web Style Templates
disponible en la ventana Resources.

Pg 140 de 213
 Enterprise Architect
Manual prctico

Por defecto, y salvo que nuestra plantilla de trabajo disponga de alguna plantilla
HTML incorporada, no existir ninguna. Para crear nuestra nueva plantilla, haremos
clic con el botn derecho del ratn sobre Web Style Templates y seleccionaremos
Create HTML Template:

Para este ejemplo, vamos a crear una plantilla donde los trminos que aparezcan en
ingls van a ser sustituidos por sus traducciones al castellano.

Al crear la plantilla, se nos muestra el siguiente editor HTML / CSS:

Este editor nos permite, dependiendo de los conocimientos de HTML y CSS de que
disponga el usuario, adaptar los estilos, ttulos, colores, etc en muchos de los
apartados y secciones de que se compondr la documentacin, y que son accesibles
mediante la lista de secciones de la izquierda. Para cada una de las secciones, existe un
cdigo asociado visible en la parte derecha, donde podremos editar trminos y estilos a
nuestro gusto.

En este ejemplo, se tratara de traducir al castellano todos los trminos que nos
vayamos encontrando en cada una de las secciones, como se ve a continuacin:

Pg 141 de 213
 Enterprise Architect
Manual prctico

Una vez hayamos finalizado la edicin de la plantilla, procederemos a guardarla

mediante el botn Save, aparecindonos ahora disponible y lista para ser usurada en
la ventana Resources.

Pg 142 de 213
 Enterprise Architect
Manual prctico

Generacin de documentacin HTML

Cabe destacar que la generacin de documentacin HTML se puede aplicar a cualquier

paquete o al proyecto completo. En este ejemplo, lo haremos sobre el proyecto
completo.

Para comenzar, entraremos en la pantalla de generacin de documentacin HTML

seleccionando en primer lugar el paquete raz PROYECTO EJEMPLO y a
continuacin seleccionando el men Project  Documentation  HTML Report.

En esta ventana nos aparece indicado el paquete a partir del cual se va a generar la
documentacin (PROYECTO EJEMPLO), el ttulo de la documentacin, la carpeta de
salida de los archivos que compondrn el web (Output to:) la plantilla de generacin a
aplicar (en este caso seleccionaremos Espaol, la plantilla que acabamos de crear), y
otras opciones como la extensin de los ficheros HTML, el formato de las imgenes de
los diagramas, etc

Tambin se nos permite incluir o excluir detalles como el Glosario del proyecto, los
casos de prueba, los elementos de mantenimiento, hipervnculos

Una vez nos hayamos asegurados que las opciones estn correctamente configuradas,
nicamente tendremos que hacer clic en Generate para que comience el proceso de
generacin del web en la carpeta especificada.

Pg 143 de 213
 Enterprise Architect
Manual prctico

El aspecto final de la documentacin generada, que podemos ver en un navegador

pulsando el botn View o accediendo manualmente a la carpeta destino, sera:

Adems del aspecto atractivo que tiene este tipo de documentacin, cabe destacar que
la navegabilidad entre elementos es completa a travs de un simple clic. Por ejemplo,
en el diagrama de secuencia, si hicisemos clic en el objeto :CLAN:BPeticiones
automticamente nos llevara a la pgina de propiedades de dicho objeto:

Pg 144 de 213
 Enterprise Architect
Manual prctico

En resumen, es una manera rpida y eficaz de generar documentacin accesible por

todos los integrantes del proyecto, de muy fcil navegacin e interpretacin por parte
de los diferentes perfiles.

Pg 145 de 213
 Enterprise Architect
Manual prctico

12. Documentacin RTF

Introduccin
En este mdulo es donde reside la verdadera potencia de generacin de documentos
de Enterprise Architect. Mediante una aplicacin especfica y completa, incrustada en
Enterprise Architect, es posible generar documentacin a travs de las plantillas
proporcionadas en el producto, o bien crear y editar nuevas plantillas de
documentacin a partir de otras existentes, o desde un documento en blanco.

A travs de este generador, podemos obtener una documentacin:

Exhaustiva
Detallada
A medida de los requisitos del proyecto
Personalizada para la organizacin.

Es decir, podemos configurar la salida en funcin de las necesidades del proyecto y el

destinatario de la documentacin. No obstante, Enterprise Architect nos suministra
algunas plantillas genricas que nos pueden ser de mucha utilidad de cara a obtener
documentacin estndar o bien para crear nuevas plantillas a partir de ellas.

Plantillas.

Enterprise Architect incorpora un editor de plantillas que conviene estudiar a fondo si

se desea obtener el mximo partido de la funcionalidad de generacin automtica de
documentacin. Antes de iniciar el editor de plantillas, vamos a ver la manera en que
ste trabaja. El aspecto general del editor es el siguiente, con dos secciones principales:

a
b

Pg 146 de 213
 Enterprise Architect
Manual prctico

a) rbol de secciones:

En l se descomponen jerrquicamente
aquellas secciones que van a ser incluidas o no
en la plantilla, as como las subsecciones que la
componen.

Es muy importante conocer la manera en que

la documentacin es generada: se trata de un
proceso recursivo que va recorriendo, desde el
paquete que le hayamos indicado, todos los
subpaquetes, diagramas y elementos que lo
componen.

Teniendo esto en cuenta, el rbol nos sirve

para indicar a la herramienta qu secciones de
cada paquete, diagrama y elemento deseamos
mostrar, en caso de que existan.

Por ejemplo: si en el rbol marcsemos la

opcin Package  File, el recorrido recursivo
que se realiza durante la generacin del
documento nos ira sacando los archivos
asociados en la pestaa Files de cada
paquete. Marcar la opcin Element 
Attribute hara lo mismo, pero esta vez
obteniendo la informacin relativa a los
atributos de las clases. Cuando el elemento a
tratar no tuviese atributos (por tratarse de un
caso de uso, por ejemplo), esa seccin quedara
en blanco, mientras que cuando el elemento
tratado fuese una clase, se incorporara la
informacion relativa a sus atributos acorde a la
definicin que exista dentro de esa seccin.

El orden de aparicin de estas secciones en el

documento final se puede establecer mediante
la utilizacin de los comandos arriba y
abajo representados por iconos con forma de
mano.

Es muy aconsejable realizar bastantes pruebas

hasta habituarnos a trabajar con el editor, ya
que configurndolo adecuadamente permite,
mediante la creacin de dos o tres plantillas
genricas, poder obtener cualquier documento
con distintos niveles de detalle, u orientado a
distintos tipos de lectores.

Pg 147 de 213
 Enterprise Architect
Manual prctico

b) Ventana del Editor:

Se trata de un editor comn, a travs del cual podremos introducir ttulos, subttulos,
texto, tablas, columnas, marcos, secciones, elementos del repositorio, etc de un modo
similar a como lo haramos en MS Word.

Si observamos un poco, veremos que el rbol de secciones y el editor se integran a

travs de Etiquetas de seccin (mostradas en el editor con fondo amarillo), que
indican el inicio y el fin de una seccin, y entre las cuales tendremos que introducir la
informacin, campos del repositorio, etc correspondientes a esa seccin en concreto.

Estas etiquetas se manejan de la siguiente manera:

Pg 148 de 213
 Enterprise Architect
Manual prctico

seccin>

Texto y campos a mostrar dentro de esta seccin

<seccin

Dentro de una seccin, como hemos dicho anteriormente, podemos incluir cualquier
tipo de texto, imgenes, tablas y lo ms importante, campos del repositorio, que es
en definitiva, la informacin del proyecto a mostrar.

La manera de introducir un campo del repositorio, es decir, atributos para los

elementos que iterativamente vayan apareciendo, es muy sencilla. El editor dispone de
un men sensible al contexto que podemos obtener pulsando el botn derecho del
ratn. Dependiendo de entre qu dos etiquetas se encuentre situado el puntero, se
desplegar un men contextual con las etiquetas disponibles para esa seccin en
concreto, teniendo nicamente que seleccionar la deseada para hacer que aparezca en
el lugar deseado del editor.

La etiqueta correspondiente al atributo del elemento aparecer sombreada en gris.

Un ejemplo de creacin de un segmento de la plantilla sera:

element >
{Element.Name}

Tipo: {Element.Type}

Operaciones:

Mtodo Notas Parmetros

{Meth.Static}{Meth.Co {Meth.Notes} parameter >
nst}{Meth.Pure}{Meth. {Meth.Behavior} {MethParameter.Type}
Name}() {Meth.Type} {MethParameter.Name}
{Meth.Scope} [{MethParameter.Kind}]
{MethParameter.Notes}

< parameter

<element

La salida de esta plantilla en el documento definitivo para una clase denominada

ClasePeticiones, sera:

Pg 149 de 213
 Enterprise Architect
Manual prctico

ClasePeticiones

Tipo: Class

Operaciones:

Mtodo Notas Parmetros

ConsultarPeticin()
void
Public

Vamos, ahora s, a iniciar el editor de plantillas. Esto lo haremos desde la seccin RTF
Style Templates de la ventana Resources:

Si no existiese ninguna plantilla, podramos crearla pulsando el botn derecho y

seleccionando Create RTF Style Template:

Al crear una nueva plantilla, podemos optar por hacerlo a partir de otra plantilla
existente o bien desde cero (opcin poco recomendable). En cualquier caso, tras aceptar
esta ventana, se abrir el editor previamente estudiado.

Pg 150 de 213
 Enterprise Architect
Manual prctico

Opciones de generacin de la documentacin

Para iniciar la aplicacin generadora de documentacin RTF, seleccionaremos la vista o

paquete a documentar y haciendo click con el botn derecho del ratn, seleccionamos
las opciones Documentation  Rich Text Format (RTF) Report (opcin tambin
disponible en el men general Project  Documentation)

NOTA: Seleccionando el nodo raz del proyecto, el men contextual es sensiblemente diferente,
habiendo que seleccionar directamente la opcin Rich Text Documentation.

Al iniciarse el generador, se nos muestra la siguiente ventana:

Pg 151 de 213
 Enterprise Architect
Manual prctico

Principales opciones:

Root Package: Muestra la vista o paquete seleccionado en el Project Browser, es decir,

el elemento o conjunto de elementos a partir del cual documentar.

Output to file: Permite introducir la ruta y nombre del archivo .rtf que se generar.

Switch Generator: Nos permite, por motivos de herencia de antiguas funcionalidades

de la herramienta, cambiar el antiguo generador de documentacin.

Resource Document: Mediante este comando, podemos asignar a esta definicin de

generacin de documentacin un nombre que aparecer en la ventana Resources,
para poder repetir la misma generacin (manteniendo las mismas opciones y valores
de salida) cuando se desee.

Para ello iremos a Resources y al rbol Documents  RTF Documents y pulsando el

botn derecho sobre el documento a obtener, seleccionaremos Generate Document o
Auto-Generate Document segn corresponda

Use template: Aqu indicamos qu plantilla vamos a utilizar para la generacin del
documento. Podemos elegir entre las que proporciona Enterprise Archirect o las que
tengamos creadas por los usuarios.

Edit current: Opcin slo disponible cuando se ha seleccionado una plantilla definida
por el usuario, estando desactivada cuando se trata de una plantilla de Enterprise
Architect. La modificacin de alguna de estas plantillas fijas se ha de hacer mediante
la creacin de una nueva plantilla a partir de (basada en) ella.

Generate: Comienza la generacin del documento. Hay que tener en cuenta que este
proceso puede durar varios minutos, dependiendo de la plantilla utilizada para
generar el documento y del nmero de paquetes, diagramas y elementos a
documentar. El progreso se muestra mediante una barra.

View: Inicia el visor de archivos interno de Enterprise Architect, que mostrar la

documentacin generada desde la propia aplicacin sin necesidad de editores externos
(en caso de estar seleccionada la opcin Use internal viewer) o desde el editor externo
por defecto para archivos .rtf (en caso de que Use internal viewer no est
seleccionada).

Use Language Substitutions: Esta opcin la veremos en detalle en el apartado

siguiente: Parametrizacin del Lenguaje.

Generate Options: Abre una nueva ventana de opciones:

Pg 152 de 213
 Enterprise Architect
Manual prctico

Esta ventana permite principalmente establecer ciertos filtros y ordenaciones para

los elementos que se van a documentar.

Permite, por ejemplo, filtrar objetos creados o modificados a partir de una

determinada fecha, los que se encuentren en algn estado o fase en concreto,
permite ordenar la salida de los paquetes, elementos y diagramas por diversos
criterios, as como indicar la exclusin de detalles exhaustivos para determinados
objetos susceptibles de ser omitidos.

La opcin Skip root package sirve para indicar si el paquete raz seleccionado
para la documentacin ha de ser incluido o nicamente su contenido (paquetes,
diagramas y elementos hijos).

Manage templates: Permite gestionar las plantillas, mediante la creacin, eliminacin y

modificacin de plantillas a partir de otras existentes. Desde esta opcin podemos
acceder al Editor de Plantillas de Enterprise Architect a travs de la siguiente ventana:

Pg 153 de 213
 Enterprise Architect
Manual prctico

Bien pulsando sobre Edit cuando exista alguna disponible, o mediante la creacin
de una nueva plantilla con New, se abrir el Editor de Plantillas.

En definitiva y a modo de integracin de todo lo visto, podemos decir que utilizando

las opciones disponibles para filtrado y ordenacin de elementos, junto con el Editor de
Plantillas, en el que definiremos secciones y atributos de los elementos a mostrar as
como la insercin de imgenes y diseos de formatos corporativos especficos,
podemos construir plantillas de documentacin completas, detalladas y a medida de
nuestras necesidades especficas.

Parametrizacin del lenguaje

Independientemente de que nuestras plantillas de documentacin estn elaboradas en

castellano, Enterprise Architect incorpora algunas etiquetas automticamente en ingls,
que podemos sustituir por sus equivalentes en castellano.

Para ver y modificar la lista con estas etiquetas, tenemos que pulsar el botn
Language de la pantalla de generacin de documentacin:

Que nos mostrar la ventana de configuracin de opciones del lenguaje, pgina de

cdigos, etc Un ejemplo de parametrizacin de algunas etiquetas y del lenguaje sera:

Pg 154 de 213
 Enterprise Architect
Manual prctico

Generacin de la documentacin

Una vez disponemos de:

Un paquete a documentar
Una plantilla que aplicar al paquete
Una configuracin de la generacin

Podemos generar nuestro documento de prueba.

Para ello, desde la ventana del generador de documentacin, pulsaremos en

Generate. Una vez ha concluido el proceso de generacin podemos ver los resultados
mediante el botn View.

Pg 155 de 213
 Enterprise Architect
Manual prctico

Documentos Virtuales

Puede haber ocasiones en que nos interese crear un documento compuesto por
distintas vistas o paquetes que no estn contenidos unos dentro de otros.

Hasta ahora hemos generado documentacin a partir de una vista o paquete del
Project Browser, y los subpaquetes que ste contena, pero en caso de que necesitemos
generar documentos algo ms complejos, que contengan informacin de distintos
paquetes no anidados, podemos recurrir a los Documentos Virtuales.

Para crear un Documento Virtual, seguiremos los siguientes pasos:

1. Creamos un nuevo Diagrama de Clases, donde aparecern representados todos

nuestros Documentos Virtuales.

2. Creamos una nueva Clase en el diagrama.

3. En el cuadro de dilogo de creacin de la nueva clase, le asignamos un nombre

y el estereotipo model document que puede no aparecer inicialmente en el
desplegable de estereotipos, pero que Enterprise Architect aceptar y
reconocer si lo introducimos manualmente.

Pg 156 de 213
 Enterprise Architect
Manual prctico

4. Una vez tengamos la clase creada, le arrastramos desde el Project Browser

aquellos paquetes que queramos que compongan el documento. Estos paquetes
aparecern mostrados como Atributos de la Clase (pudiendo ser reordenados
para obtener el documento en un orden determinado).

5. El aspecto final que tomar el Documento Virtual recin creado, en el diagrama,

ser este:

6. Para producir el documento en s mismo, basta con seleccionar el Documento

Virtual en el diagrama o en el Project Browser, y desde el men Element
seleccionar la opcin Documentation y a continuacin configurar el
documento de salida (plantilla a aplicar, nombre del fichero RTF de salida,
opciones de generacin) segn los pasos descritos anteriormente en este
captulo.

Pg 157 de 213
 Enterprise Architect
Manual prctico

Linked Documents

A la hora de documentar los artefactos de nuestro proyecto, normalmente haremos

uso del campo Notes o Details que acompaa a cada uno de ellos, y accesible
desde su propia pantalla de propiedades. Es un campo de texto plano que nos sirve
para escribir pequeas descripciones que posteriormente aparecern, si lo
deseamos, en la documentacin que generemos.

Es posible que en determinados casos esta descripcin textual sin formato no sea
suficiente, y deseemos ampliar esta funcionalidad de documentacin de artefactos.
Cuando nos suceda esto, haremos uso de los Linked Documents.

Un Linked Document es un archivo de texto enriquecido que queda incrustado en

el elemento para el que lo creemos.

Para crear un Linked Documet en cualquier elemento de Enterprise Architect,

recurriremos al men Element  Linked Document. Esto nos abrir una ventana de
seleccin de plantilla:

En esta ventana, podemos especificar, si lo deseamos, la plantilla que queremos

emplear para editar nuestro documento, o bien seleccionar None para abrir un
documento en blanco.

NOTA: Aparte de las plantillas que por defecto incorpora la herramienta, podemos crear
nuestras propias plantillas, desde la ventana Resources en la seccin Templates 
Linked Document Templates pulsando el botn derecho y seleccionando Create
Template. Todas las plantillas que generemos, se almacenarn en ese mismo lugar. Las
plantillas que vayamos a crear, tambin pueden partir de alguna preexistente, o de un
documento en blanco.

Por ltimo, aparecer un editor RTF propio de la herramienta

Pg 158 de 213
 Enterprise Architect
Manual prctico

Podemos utilizar este editor libremente, incluso copiar y pegar objetos y textos
desde cualquier otro editor, como Microsoft Word.

Es posible tener un nico Linked Document asociado a cada elemento en

Enterprise Architect, y realmente proporcionan un complemento perfecto a la
generacin de documentacin RTF.

Para eliminar un Linked Document de un elemento, pulsaremos el botn derecho

sobre dicho elemento y seleccionaremos Delete Linked Document

NOTA: Para incluir los Linked Documents en las plantillas RTF, es decir, para que en la
documentacin generada aparezcan los Linked Document de los paquetes y los elementos,
hay que seleccionar la opcin Model Document en el rbol de secciones del editor de
plantillas RTF, en la seccin Package y/o Element correspondiente.

Pg 159 de 213
 Enterprise Architect
Manual prctico

Conexin con Microsoft Word. Macrodocumentos

Los distintos documentos que se generen desde Enterprise Architect normalmente

tendrn entidad propia por s solos, si bien es posible que en determinadas ocasiones
precisemos crear un documento Maestro que contenga varios documentos generados
independientemente.

Para estos casos, es posible unir varios documentos creados independientemente desde
la herramienta en un macrodocumento de Word que, por ejemplo, contenga una
portada especfica o algunas secciones fijas entre los distintos apartados a incorporar
que sern los documentos generados automticamente desde Enterprise Architect.

Para hacer esto:

1. Crearemos un documento de Word y, desde l, vincularemos los archivos

correspondientes a los documentos generados desde Enterprise Architect
mediante la opcin de Word Insertar  Archivo indicando que queremos
insertarlo como un vnculo. De lo contrario, lo incrustara, haciendo
imposible cualquier futura actualizacin de los cambios hechos en el
documento insertado:

2. Posteriormente y cada vez que sea preciso, desde este documento Maestro
tendremos que actualizar todos los vnculos insertados para obtener la ltima
versin generada de cada uno de los archivos .rtf creados desde Enterprise
Architect. Esto lo haremos con la opcin Edicin  Actualizar vnculos:

Pg 160 de 213
 Enterprise Architect
Manual prctico

De este modo, mantendremos siempre nuestro archivo Maestro actualizado.

Documento Anlisis Funcional.rtf

de EA vinculado al documento Maestro

Pg 161 de 213
 Enterprise Architect
Manual prctico

Otros informes

Existen algunos otros informes predefinidos que permiten obtener alguna informacin
especfica del proyecto.

Estos informes no son configurables en absoluto. nicamente recolectan informacin

del repositorio de datos del proyecto, y normalmente suelen mostrarse en una ventana,
que dispone de un botn Print para posibilitar el obtener una copia impresa de esa
informacin.

Estos informes son accesibles para cada paquete individualmente o para el projecto en
conjunto, seleccionando dicho paquete o subpaquete y mediante la opcin Project 
Documentation.

Los informes de que se dispone se ven a continuacin. Se recomienda al usuario que les
eche un vistazo, y que recuerde aquellos que considere que le pueden ser de utilidad
para determinada labor de documentacin en el mbito de sus proyectos:

Pg 162 de 213
 Enterprise Architect
Manual prctico

13. Trazabilidad y Consistencia

Introduccin

Cuando en Ingeniera de Software se habla de trazabilidad y consistencia, se estn

englobando una serie de requisitos de gestin y procedimientos de control orientados a
dotar al proceso de desarrollo y al producto software en s mismo de las garantas de
coherencia y cohesin suficientes y adecuadas, comprobables por diversos medios de
validacin y verificacin.

Trazabilidad: Conjunto de medidas, acciones y procedimientos que permiten registrar

e identificar cada producto desde su origen hasta su destino final. Consiste en la
capacidad para reconstruir la historia, recorrido o aplicacin de un determinado
producto.

Consistencia: Que las implicaciones lgicas no sean contradictorias.

Matrices de Trazabilidad

Podemos controlar la trazabilidad y la consistencia de y entre nuestros modelos UML

de varias maneras en Enterprise Architect. Muchas de ellas son intuitivas, y ser el
propio usuario quien, poco a poco, vaya descubriendo mtodos y procedimientos que
le permitan asegurar y controlar estos factores.

La semntica UML es ms que suficiente para describir las relaciones lgicas o

evolutivas entre modelos o procesos. Por ello, la aplicacin dispone de una
funcionalidad llamada Matrix Profiles que nos permite, mediante UML, describir este
tipo de relaciones de una manera un tanto distinta a como lo hacamos hasta ahora en
los diagramas; esto es, en matrices.

Las Matrices de Trazabilidad (matrix profiles) son tablas de doble entrada donde se
establecen relaciones de algn tipo entre elementos.

Establecer una relacin entre dos elementos mediante una matriz o mediante su
representacin en un diagrama ES EXCTAMENTE LO MISMO: la sintaxis y la
semntica de la relacin establecida es exactamente igual.

Es posible que tengamos establecidos en nuestra organizacin una serie de

procedimientos de control en cuanto al progreso, desarrollo, incremento o relaciones
de nuestros modelos, y ser todo el equipo implicado en el proyecto el responsable de
mantener y, en algunos casos, validar y verificar la integridad de la informacin con
respecto a estos controles establecidos.

Pg 163 de 213
 Enterprise Architect
Manual prctico

Veamos un ejemplo de una matriz que enfrenta Actores contra los Casos de Uso en los
que participan, y a continuacin vamos a comentarla.

En primer lugar, para crear una matriz de trazabilidad, hemos de recurrir al men
View  Relationship Matrx. Inicialmente, ser esto lo que veamos:

Ahora hay que configurar qu elementos queremos enfrentar y cmo. En este ejemplo,
sern los Actores y los Casos de Uso, y la relacin que queremos ver es Use Case.
Para ello:

1. Pulsamos sobre el botn junto a Source, y seleccionamos nuestro paquete

1. Catlogo de Actores del Modelo de Casos de Uso.
2. Seleccionamos, en la misma fila, el tipo Actor del desplegable Type.
3. A continuacin, pulsamos sobre el botn junto a Source, y seleccionamos
nuestro paquete Modelo de Casos de Uso del ANLISIS.
4. Seleccionamos, en la misma fila, el tipo UseCase del desplegable Type.
5. En el desplegable Link Type, seleccionamos el tipo de relacin que queremos
visualizar o establecer. En este caso, UseCase.
6. El desplegable Direction lo dejamos en Source -> Target.

NOTA: Hay que ser muy cuidadoso al seleccionar los elementos Source y Target,
respetando siempre la semntica UML en cuanto a la direccionalidad de las relaciones. Un error
en la definicin del origen o el destino de la relacin puede tener un resultado no deseado, como
por ejemplo que no aparezcan marcadas relaciones que s existen en un diagrama.

Al finalizar, la matriz aparecer as:

Pg 164 de 213
 Enterprise Architect
Manual prctico

Vemos que, automticamente, la matriz nos presenta las relaciones que previamente
habamos establecido en el diagrama de Casos de Uso del subsistema 2. Gestin de
Peticiones.

Cualquier variacin (eliminacin o creacin) de una relacin en esta matriz, tendr

consecuencias inmediatas en nuestros modelos y diagramas.

Ahora vamos a proceder a guardar esta matriz como un nuevo perfil. Para ello,
pulsando el botn derecho en cualquier parte de la cabecera (por ejemplo, junto al
botn Refresh), navegamos hasta la opcin del men

y llamaremos al perfil:

Pg 165 de 213
 Enterprise Architect
Manual prctico

Podemos comprobar el correcto almacenamiento del perfil en la ventana Resources,

dentro de la seccin Matrix Profiles:

Como hemos podido ver, mantener un amplio catlogo de matrices de relacin es una
opcin muy interesante de cara a poder controlar, rpidamente y eficazmente, las
relaciones establecidas entre:

Elementos con otros elementos.

Elementos de una etapa del proceso con sus evoluciones en otra etapa.
Modelos con otros modelos.

De esta manera podemos controlar, no solo las relaciones que componen la lgica del
software, sino tambin las que componen la lgica del proceso de ingeniera de
desarrollo.

Algunos ejemplos de relaciones que hay establecer para garantizar una correcta
trazabilidad y consistencia de nuestro proyecto sern:

Dependencias entre Realizaciones entre Dependencias entre Casos de Uso y Casos de

Clases de Diseo y Tablas y Clases Uso de Negocio
Anlisis

Pg 166 de 213
 Enterprise Architect
Manual prctico

Dependencias entre Realizaciones entre Realizaciones entre Realizaciones entre

Modelos o Etapas Casos de Uso y Clases de Dominio y Clases de Anlisis y
Requisitos Casos de Uso Requisitos

Y cuantas ms se nos ocurran y nos sirvan para cubrir los objetivos anteriormente
descritos:

Representacin grfica de la trazabilidad de elementos.

Anlisis de impacto de los cambios

Una de las mltiples ventajas de gestionar correctamente la trazabilidad en nuestro

proyecto, redunda en la facilidad con la que podemos afrontar el llevar a cabo un
anlisis de impacto de un cambio, minimizando enormemente el esfuerzo y los riesgos
asociados.

En el siguiente ejemplo vamos a ver como, a travs de un diagrama, poder ver las
implicaciones que tendra un cambio en, por ejemplo, un requisito funcional de cara a
todos los elementos integrantes de nuestro proyecto.

Vamos para ello a crear un paquete de primer nivel que llamaremos

TRAZABILIDAD, del que colgar un diagrama de tipo Extended  Custom.

Pg 167 de 213
 Enterprise Architect
Manual prctico

En este diagrama, arrastraremos as simple link un requisito de nuestro catlogo. A

continuacin, sobre este requisito haremos clic con el botn derecho y seleccionaremos
Add  Insert Related Elements.

Aparecer la siguiente ventana de configuracin de esta accin. Veamos las opciones:

Insert elements to: Nos permite indicar el nmero de niveles de relacin que queremos
establecer.

For Link Type: Permite definir el filtro por tipo de vnculo que deseamos ver. En
blanco, aparecen todos.

With Link Direction: Permite establecer el filtro por direccin de las relaciones a
mostrar. En blanco, cualquier direccin

Limit to Element Type: Para mostrar solo cierto tipo de elementos con los que se
relaciona. En blanco, cualquier elemento.

Layout Diagram When Complete: Muy aconsejable, ya que el diagrama que se

generar normalmente ser complejo, y de esta manera nos jerarquiza
automticamente los niveles, y le da un aspecto legible.

Pg 168 de 213
 Enterprise Architect
Manual prctico

Al pulsar OK, el resultado, dependiendo del requisito seleccionado y de las relaciones

establecidas en el proyecto, sera este:

Un anlisis visual rpido, nos permite afirmar qu requisitos lo componen, que casos
de uso lo realizan, qu clases de dominio realizan esos casos de uso, y as podramos
seguir por las clases de anlisis, de diseo, tablas fsicas, interfaces de usuario, etc

Otra forma de ver la jerarqua de relaciones en cascada de un elemento es mediante

una til ventana denominada Hierachy (men View).

Pg 169 de 213
 Enterprise Architect
Manual prctico

14. Auditora

Introduccin

La herramienta de Auditoria es una nueva caracterstica presente en Enterprise

Architect 7.0 que permite registrar, en diferentes grados, los cambios realizados en los
elementos de un modelo especfico. De igual manera, ofrece la posibilidad de
determinar el tipo de elementos que sern auditados (paquetes, relaciones,
operaciones, etc.), guardar los Logs generados en archivos fuera del modelo, eliminar
los Logs, etc.

Para poder hacer uso de esta herramienta es necesario activarla y configurarla de

acuerdo a las necesidades que se presenten. Esto se logra a travs de la ventana de
configuraciones de auditoria. Para ello se debe:

1. Seleccionar del men principal la opcin View  Audit View. Lo cual abrir la
ventana de auditoria, tal como se muestra en la siguiente figura:

2. Hacer clic en el botn Audit Settings. Lo cual abrir la ventana para la

configuracin de la auditoria.

Pg 170 de 213
 Enterprise Architect
Manual prctico

Descripcin de la ventana Audit Settings

En las siguientes secciones se describen todos los elementos presentes en la pantalla

anterior, as como el uso de cada uno de ellos.

 Casillas de Verificacin

Enable
Permite activar la caracterstica de Auditoria dentro de EA.
Auditing
Audit XMI Al seleccionar esta opcin, es posible incluir la importacin de archivos
Import * XMI dentro de la auditoria.
Audit XMI Al seleccionar esta opcin, es posible incluir la exportacin de archivos XMI
Export * dentro de la auditoria.
Audit Reverse Al seleccionar esta opcin de incluye las acciones de ingeniera inversa
Engineering dentro de la auditoria.
Se debe seleccionar esta opcin cuando se desee emplear la Fecha/Hora del
Use Database
servidor de base de datos al registrar las operaciones y no la fecha/hora
Timestamp **
local de cada usuario.

* Opcin til cuando se trabaja con herramientas de control de versiones dentro de Enterprise
Architect, y se desea hacer el seguimiento de paquetes controlados, pues los archivos utilizados
por dichas herramientas son de tipo XMI

** Esta opcin no se encuentra disponible para proyectos almacenados en un .EAP local.

 Botones

Existen tres botones que permiten administrar los logs de auditoria. A medida que el
nmero de logs aumenta, el desempeo de la funcin de auditoria disminuye. Es por
esta razn que se recomienda que aquellos logs que no se utilicen regularmente, sean
salvados en archivos y borrados del modelo. Es posible volver a cargarlos cuando sea
necesario.

Remueve todos los logs del modelo, de forma permanente. Para mantener los
logs guardados fuera del modelo, deben salvarse previamente a travs de la
Clear Logs
opcin Save Logs. La herramienta ofrece la opcin de eliminar los logs
correspondientes a un perodo de tiempo especfico. (Ver imagen siguiente)
Guarda una copia de los logs que se encuentran guardados en la Base de Datos.
Todos estos archivos permanecern igualmente en la Base de Datos a menos
Save Logs que se utilice la opcin Clear Logs. La herramienta ofrece la opcin de guardar
los logs correspondientes a un perodo de tiempo especfico. (Ver imagen
siguiente)
Permite cargar dentro del modelo, los logs que previamente hayan sido
Load Logs guardados en un archivo externo. A travs de esta operacin no se borra el
archivo externo.

Pg 171 de 213
 Enterprise Architect
Manual prctico

 Niveles de Auditoria (Auditing Levels)

La ventana provee adems tres opciones para determinar cules son los tipos de
cambios que desean ser registrados.

Permite registrar cambios en los elementos (incluyendo atributos y operaciones),

Core
paquetes, conectores y otra informacin sobre los modelos.
Permite registrar los mismos cambios que en la opcin Core, aadiendo adems
Standard
cambios en los diagramas.
Permite registrar los mismos cambios que en la opcin Standard, aadiendo
Extended
adems cambios en la seguridad.

 Opciones de Auditora (Audit Options)

Los siguientes elementos siempre son auditados:

Paquetes
Notas
Boundary
Texto
Diagramas (si el modo es Standard)
Seguridad (si el modo es Extended)

Las opciones de auditoria permiten especificar qu tipo de elementos sern auditados.

Maintenance Permite auditar elementos de mantenimiento.

Core Structural Permite auditar elementos de mantenimiento ms elementos estructurales.
All Permite auditar todos los elementos.
Permite auditar aquellos elementos especificados por el usuario. Para ellos
Custom muestra una lista desplegable, en la que se pueden escoger los elementos
deseados.

Nota: los conectores son auditados cuando se encuentran conectados a un elemento que ha sido
incluido en las opciones de auditoria.

Pg 172 de 213
 Enterprise Architect
Manual prctico

Descripcin del men principal de Auditora

La siguiente imagen representa la Vista de Auditoria con todos sus elementos,

complementando la imagen bsica mostrada anteriormente.

Las partes principales de las que se compone se refieren al rbol de auditoria, en donde
se muestran todos los cambios realizados y que se organiza dependiendo del modo
seleccionado; el panel de botones que permite configurar la auditoria; el panel central
en el que se muestran los cambios realizados sobre cualquiera de los elementos
presentes en el rbol y el panel inferior en el que se muestran esos mismos cambios
pero en una forma ms detallada.

 Modo (Mode)

Permite configurar la forma como sern mostrados los cambios en el rbol de

auditoria. Existen tres opciones que se resumen a continuacin.

Modo Standard: muestra nicamente los cambios realizados en elementos

dentro del modelo.

Pg 173 de 213
 Enterprise Architect
Manual prctico

Modo Advanced: muestra los cambios realizados en elementos del modelo as

como cambios en la opcin de auditoria propiamente dicha (cundo se activa,
cundo se desactiva, etc.).

Modo Raw: muestra todos los cambios sin ningn tipo de agrupamiento sino
tal y como se producen en el tiempo.

Nota: es importante tener en cuenta que la marca verde indica que algo ha sido
creado, que el lpiz amarillo indica que algo ha sido modificado y que la X
roja (no aparece en la figura) indica que algo ha sido eliminado.

 Carga (Load)

Permite refrescar la informacin mostrada en el rbol de auditoria.

 Bsqueda (Search)

Permite buscar elementos en los logs de auditoria. Para ello es necesario especificar el
valor que desea buscarse. Si se refresca el rbol de auditoria, es necesario realizar la
bsqueda nuevamente.

 Ayuda (Help)

Muestra informacin referente a la vista de auditoria, la cual puede ser til y servir
como ayuda al usuario en un momento determinado.

 Ordenamiento (Sort By)

Permite organizar el contenido del rbol de auditoria bajo diferentes criterios como
usuarios, tipo u operaciones de borrado. La opcin de ordenamiento slo puede ser
utilizada cuando el modo es Standard o Advanced.

Pg 174 de 213
 Enterprise Architect
Manual prctico

Usuarios: agrupa los cambios de acuerdo al usuario que los realiz y dentro de
cada usuario agrupa los cambios por tipo de elemento.
Tipo: agrupa los cambios dependiendo del tipo de elemento, por ejemplo
requisitos o clases.
Borrado: nicamente muestra las operaciones de borrado ordenadas
cronolgicamente.

 Filtrado (Filter By Date/Time)

Permite realizar bsquedas, filtrando la informacin por periodos de tiempo

especficos. Dichos periodos de tiempo son configurados al presionar el botn Filter
Settings y seleccionar en la ventana correspondiente el periodo deseado. Dicho botn
solo se activar cuando se haya seleccionado la casilla de verificacin correspondiente
a Filter By Date/Time.

Pg 175 de 213
 Enterprise Architect
Manual prctico

15. Patrones UML

Introduccin

Los patrones UML son soluciones ptimas a problemas de diseo comunes, basadas en
la experiencia de otros diseadores.

Una vez detectada la conveniencia de aplicar un patrn de diseo para lograr un

determinado objetivo o comportamiento del sistema, el analista o programador
nicamente ha de hacer uso de l y modificar los nombres de los elementos de acuerdo
a sus propias necesidades.

Enterprise Architect dispone de la posibilidad de almacenar y gestionar esos patrones

de diseo, adems de ofrecer algunos de los ms comnmente extendidos.

Inclusin de un Patrn en el Modelo

Para acceder a la seccin de patrones de la herramienta, iremos a la ventana Resources

 UML Patterns. Por defecto, en un proyecto vaco de Enterprise Architect al menos
veremos tres carpetas que contienen los patrones GoF (Group Of Four):

Pg 176 de 213
 Enterprise Architect
Manual prctico

Vayamos ahora, por ejemplo, al patrn GoF Structural Patterns  Facade haciendo
doble clic en l. Se nos mostrar la ventana de descripcin del patrn:

Esta es una ventana que muestra la descripcin del patrn, una vista previa de su
representacin en un diagrama, y los elementos que lo componen.

Si quisiramos hacer uso de este patrn, la tarea es tan sencilla como arrastrar el icono
con el patrn que deseamos implementar a un diagrama creado previamente por
nosotros. Haciendo esto, nuestro diagrama mostrar:

Como se ha dicho anteriormente, ahora el usuario nicamente tiene la labor de adaptar

los nombres de las clases a los correspondientes elementos de su proyecto.

Pg 177 de 213
 Enterprise Architect
Manual prctico

Creacin de un Patrn

El usuario tambin puede crear sus propios patrones, y almacenarlos en la ventana

Resources. Para ello, nicamente ha de disear el patrn en un diagrama y seleccionar
una opcin especial de guardado, que se encuentra en el men Diagram  Save as
UML Pattern

La figura anterior muestra un ejemplo de diagrama genrico que va a ser guardado

como un patrn UML.

Una vez pulsada la opcin de guardar, solo nos falta indicar algunos detalles. Hay que
tener en cuenta que el patrn no se almacena automticamente en nuestro proyecto,
sino que se guarda en un archivo XML, que posteriormente podremos importar en los
proyectos que deseemos.

Pg 178 de 213
 Enterprise Architect
Manual prctico

Para importar un patrn en un Proyecto, haremos nuevamente uso de la ventana

Resources y, en la seccin UML Patterns, con el men del botn derecho del ratn
seleccionaremos Import UML Pattern

Tras esto, seleccionaremos el fichero XML cuyo contenido sea el patrn o los patrones a
importar, y como resultado final aparecer nuestro patrn importado disponible para
ser utilizado en el proyecto.

Pg 179 de 213
 Enterprise Architect
Manual prctico

16. Perfiles UML

Introduccin
Los Perfiles UML son una herramienta para extender el lenguaje UML, los cuales
permiten construir modelos UML para dominios particulares. Se basan en estereotipos
y valores etiquetados adicionales que son aplicados a Elementos, Atributos, Mtodos,
Vnculos, Finales de Vnculo, etc.

Un perfil es una coleccin de extensiones que juntas describen algn problema de

modelado en particular y facilitan la construccin de modelos en ese dominio.

Enterprise Architect tiene un mecanismo de Perfil UML genrico para cargar y trabajar
con diferentes perfiles. Los Perfiles UML para Enterprise Architect estn definidos en
archivos XML, con un formato especfico. Estos archivos XML pueden ser importados
dentro de Enterprise Architect en la pgina de Resources. Una vez importados, se
puede tomar un elemento del perfil y arrastrarlo al diagrama. Enterprise Architect
adjuntara el estereotipo, valores etiquetados y valores predeterminados, notas e incluso
un meta-archivo si es especificado, al nuevo elemento. Tambin puede arrastrar y dejar
caer los atributos y operaciones en clases existentes y agregarlas inmediatamente con el
estereotipo especfico, valores, etc.

Por lo tanto:

Un Estereotipo provee un mecanismo para variar el comportamiento y el tipo

de un elemento del modelo.

Una Metaclase se usa para crear una clase cuyas instancias son clases; una
metaclase normalmente se usa para construir metamodelos.

Una Enumeracin crea una clase estereotipada como enumeracin, que se

emplea para proveer una lista de valores nominados como el rango de un tipo
particular.

Creacin de un Perfil UML

Vamos a realizar un ejercicio de creacin de un Perfil UML para crearnos un tipo

especial de Requisito, con ciertos valores personalizados.

En primer lugar, haciendo uso del ToolBox Profile, insertaremos en un diagrama un

elemento Profile. Se nos crear automticamente en el Project Browser un nuevo
paquete con un diagrama dentro, donde construiremos nuestro perfil.

Pg 180 de 213
 Enterprise Architect
Manual prctico

En ese diagrama nuevo, incluiremos una Metaclass desde el ToolBox. En la ventana

que nos aparecer, debemos seleccionar el elemento o conector de referencia para la
metaclase. En nuestro caso, seleccionaremos el elemento Requirement.

Ahora, vamos a introducir en el diagrama un estereotipo como extensin de esa

metaclase. Para ello, utilizaremos el elemento Stereotype del ToolBox y lo colocaremos
en el diagrama. Por ltimo trazaremos una relacin extends del estereotipo a la
metaclase.

Pg 181 de 213
 Enterprise Architect
Manual prctico

A este estereotipo, podemos introducirle los valores que deseemos,

como atributos (F9). Estos valores sern en realizad Tagged Values
de los elementos Requisito que posteriormente vayamos a
emplear en nuestro proyecto.

Podemos tambin indicar rangos de valores para estos atributos, a travs de las
enumeraciones. De esta manera, cuando el usuario est trabajando con los requisitos,
podr elegir el valor para este campo desde un desplegable que le ofrecer el rango
que vamos a definir ahora.

Vamos a crear una enumeracin (enumeration) desde el ToolBox, y a indicar unos

valores para los tipos de prioridad. Estos valores son atributos (F9) de la enumeracin:

Para asignar la enumeracin al campo Prioridad de Requisito, editaremos el tipo

del atributo:

Pg 182 de 213
 Enterprise Architect
Manual prctico

Hemos finalizado la creacin de nuestro perfil. Para guardarlo, seleccionaremos la

opcin Save as profile que se obtiene haciendo clic con el botn derecho sobre el
diagrama. Indicamos una ruta donde guardar el archivo .xml con el perfil, y listo.

El procedimiento para incorporar este perfil a nuestro proyecto, es muy simple. Desde
la ventana Resources, en el apartado UML Profiles, con el botn derecho
seleccionamos Import Profile y le indicamos la ruta del fichero .xml que contenga
el perfil.

Esta ventana nos permite configurar algunos aspectos de la importacin.

Normalmente, dejaremos todo seleccionado para realizar una importacin completa.

Al acabar el proceso de importacin, el los elementos del perfil estarn disponibles, y

dispondremos de una nueva ToolBox con los elementos del perfil.

Pg 183 de 213
 Enterprise Architect
Manual prctico

El aspecto del requisito, una vez introducido en el diagrama y con la ventana de

Tagged Values visible, sera este:

Pg 184 de 213
 Enterprise Architect
Manual prctico

17. Integracin MDG

Introduccin

El MDG Integration es un instrumento que permite conectar distintos entornos de

desarrollo, como VisualStudio 2005 o Eclipse, con Enterprise Architect , ofreciendo la
posibilidad integrar as Modelos y Cdigo Fuente desde un nico entorno.

La ventaja que posee esta forma de trabajo, es que el desarrollador no debe tener
abiertas las dos herramientas al mismo tiempo, pudiendo trabajar continuamente sobre
el IDE (plataforma que ya conoce) bien sea elaborando clases y generando los Modelos
automticamente o viceversa.

Es importante tener en cuenta que la ventana de Enterprise Architect que se encuentra

dentro del IDE ofrece menos opciones que las presentes en la herramienta original,
sin embargo muestra aquellas que son bsicas para poder trabajar sobre los diagramas
como lo son: guardar, actualizar, crear nuevo elemento, entre otras. De igual manera,
se encuentra un navegador de proyecto que permite al usuario moverse dentro de los
diferentes paquetes, diagramas y elementos definidos a travs de Enterprise Architect.

Para tener una idea ms clara de cmo funciona dicha integracin, se presenta la
siguiente imagen que pretende mostrar como quedara el ambiente de trabajo una vez
realizada la integracin. La imagen est tomada desde Eclipse:

1
2

Pg 185 de 213
 Enterprise Architect
Manual prctico

Donde:

1. Es el explorador de paquetes y clases de Eclipse.

2. Es la ventana donde se muestran los Modelos UML que pueden ser creados o
modificados a travs de Enterprise Architect .
3. Es el explorador de proyecto de Enterprise Architect (Project Browser), donde se
muestran los paquetes, diagramas y elementos creados a travs de la
herramienta.

Ventajas estratgicas y valores clave:

Integracin de Enterprise Architect y UML 2.1 dentro del IDE.

Es posible navegar y refinar el modelo de desarrollo utilizando UML,
permitiendo que modelo y cdigo se conviertan en uno solo.
Permite generar docuemntacin de alta calidad en formato RTF y HTML.
Permite compartir modelos entre analistas, arquitectos y desarrolladores.
Permite modelar y visualizar el esquema de la base de datos, adems de
documentos WSDL y XSD.
Con la integracin MDG todas las tareas de sincronizacin de Modelos y Cdigo
se hacen de manera automtic, con el consiguiente aumento de productividad.
Proporciona una cultura de orientacin al modelo, de manera que la gestin
de modelos UML, diagramas, etc se convierten en una tarea cotidiana, que nos
encontramos bajo el mismo IDE al que estamos acostumbrados.
Con una integracin entre modelo, cdigo y documentacin del proyecto, se
mantienen constantemente actualizados y sincronizados los planos y los
ladrillos, minimizando el riesgo de olvidos a la hora de generar cdigo, de
actualizar modelos, etc

Integracin MDG con Eclipse

Instalacin de MDG Integration for Eclipse

1. Descargar el MDG Integration for Eclipse de la pgina web de Sparx. De este

modo, nos aseguramos de estar instalando la ltima versin disponible.

2. Si ya se haba instalado previamente, es necesario desinstalarlo. Esto se hace

desde Inicio  Panel de Control  Agregar o quitar programas. Una vez hecho
esto, podemos proceder a instalar el archivo descargado.

3. Durante el proceso de instalacin, el instalador preguntar sobre el directorio

de plug-ins de Eclipse. Por defecto, este directorio es C:\Archivos de
Programa\Eclipse\Plugins. Se puede hacer clic en Browse para cambiar la ruta
mostrada:

Pg 186 de 213
 Enterprise Architect
Manual prctico

4. Una vez finalizada la instalacin, abrir Enterprise Architect e ir a la opcin Add

Ins  Eclipse  Options

En la ventana emergente, indicar la ruta del archivo Eclipse.exe:

Pg 187 de 213
 Enterprise Architect
Manual prctico

5. Abrir Eclipse, y seleccionar Menu  Help  About Eclipse SDK. Ah, seleccionar
Plug-in Detalis. Hay que asegurarse que los plug-ins MDG Plug-in y Eclipse
Plug-In aparecen en la lista:

Si no aparecieran, hay que chequear que los archivos org.sparx.mdg.eclipse_X.X.jar y

org.sparx.eaintegration_X.X.X.jar estn en el directorio de Plug-Ins de Eclipse.

Si estuvieran, hay que cerrar Eclipse e ir al directorio de configuracin de Eclipse y

eliminar todos los archivos excepto config.ini. Al abrir Eclipse de nuevo, se deben
cargar estos dos archivos.

Conexin de Proyectos

Para conseguir la integracin hay que seguir estos pasos:

1. Abrimos en Eclipse el proyecto que deseemos integrar con Enterprise Architect.

2. Arrancamos Enterprise Architect, y creamos un proyecto nuevo y algn

paquete para alojar el proyecto Eclipse.

Pg 188 de 213
 Enterprise Architect
Manual prctico

3. Sobre este paquete, con el botn derecho, seleccionamos Add-in  Connect to

External Project  Eclipse. Aparece la ventana:

4. Seleccionamos el proyecto Eclipse que queremos enlazar, y pulsamos Connect

y luego Close.

5. Aparece una ventana que nos permite indicar qu objetos del proyecto
queremos importar. Por ejemplo, los seleccionamos todos y pulsamos Go.

6. El resultado en Enterprise Architect ser aproximadamente este:

Pg 189 de 213
 Enterprise Architect
Manual prctico

La integracin ya se ha realizado. Ahora, para mostrar la manera de trabajar de

manera unificada con modelos UML y cdigo fuente desde Eclipse, vamos a llevar
a cabo un ejemplo.

7. Cerramos Enterprise Architect, vamos a Eclipse y, con algn proyecto abierto,

seleccionamos el men:

que nos mostrar la ventana que nos permite seleccionar el proyecto

Enterprise Architect con el que queremos trabajar (seleccionando la opcin
Open an Existing Model):

8. Ahora tenemos en Eclipse una nueva ficha con los modelos Enterprise Architect
integrados.

Pg 190 de 213
 Enterprise Architect
Manual prctico

9. Para invocar a Enterprise Architect desde Eclipse, se puede hacer mediante el

botn derecho sobre cualquier elemento y seleccionando Open in Enterprise
Architect

10. Al abrirse Enterprise Architect, aparece una mini-ventana que sirve para
devolvernos a Eclipse:

11. Tambin se puede trabajar desde Eclipse directamente en algunas tareas, como
por ejemplo crear nuevos elementos:

12. Por ltimo, para Fusionar los elementos creados en Eclipse o en Enterprise
Architect, utilizaremos la funcin de EA Add-in  Merge with Eclipse (nota:
este comando slo aparece cuando abrimos Enterprise Architect independientemente, es
decir, no cuando es invocado desde Eclipse con el men Open in Enterprise Architect):

Pg 191 de 213
 Enterprise Architect
Manual prctico

Lo que nos mostrar la ventana de Fusin:

En la que podemos seleccionar qu elementos de Eclipse traer a Enterprise

Architect y qu elementos de Enterprise Architect llevar a Eclipse.

Si se desea generar cdigo automticamente a partir de los diagramas se debe:

Seleccionar el elemento del diagrama correspondiente.

Con el botn derecho seleccionar la opcin Add-Ins/Merge With Eclipse.
En la nueva ventana, seleccionar en el campo Select Type la opcin
Forward y marcar de la lista los elementos que se quieran exportar hacia
el cdigo, si es que existen.
Hacer clic en Go.

Pg 192 de 213
 Enterprise Architect
Manual prctico

Si se desea actualizar los diagramas automticamente a partir del cdigo:

Seleccionar el elemento que fue modificado a travs del cdigo en el

diagrama correspondiente.
Con el botn derecho seleccionar la opcin Add-Ins/Merge With Eclipse.
En la nueva ventana, seleccionar en el campo Select Type la opcin
Reverse y marcar de la lista los elementos que se quieran importar desde
el cdigo si es que existen.
Hacer clic en Go.

El resultado de la fusin, por ejemplo, ser este:

Integracin MDG con Visual Studio 2005

Instalacin de MDG Integration for Visual Studio 2005

1. Descargar el MDG Integration for Visual Studio 2005 de la pgina web de

Sparx. De este modo, nos aseguramos de estar instalando la ltima versin
disponible.

2. Ejecutar el archivo instalador descargado. El proceso de instalacin de este

producto no requiere ninguna otra anotacin especial, ya que es llevado a cabo
completamente por el asistente.

Pg 193 de 213
 Enterprise Architect
Manual prctico

Conexin de Proyectos

1. Crear en Visual Studio 2005 un nuevo Proyecto:

2. Incluimos un Modelo UML. Para ello, seleccionamos la opcin del men Project
 Attach UML Model

Pg 194 de 213
 Enterprise Architect
Manual prctico

3. Seleccionamos el archivo .EAP o bien nos conectamos a nuestro Repositorio en

Base de Datos.

4. Podemos mostrar el Project Browser de Enterprise Architect en el propio IDE:

5. El aspecto del IDE con Enterprise Architect enlazado, sera:

Pg 195 de 213
 Enterprise Architect
Manual prctico

6. Ahora, vamos a enlazar la solucin de Visual Studio con el Modelo UML. En

primer lugar, vamos a crear desde el propio Project Browser integrado un nuevo
paquete dentro del Modelo de Clases llamado Integracin EA-VS2005:

7. Sobre el paquete recin creado, seleccionamos la opcin:

8. Y a continuacin, seleccionamos la solucin de Visual Studio:

Pg 196 de 213
 Enterprise Architect
Manual prctico

9. Podemos ver cmo el icono del paquete nos indica que est enlazado a una
aplicacin de Visual Studio:

10. Como ltimos pasos, vamos a importar el directorio con los fuentes de la
aplicacin al paquete. Para ello, seleccionamos la opcin:

11. Aceptamos el cuadro de dilogo con las opciones por defecto:

Pg 197 de 213
 Enterprise Architect
Manual prctico

12. Tras el proceso de ingeniera inversa que se ejecutar, dispondremos en el

Modelo UML de todas las Clases existentes en Visual Studio.

Pg 198 de 213
 Enterprise Architect
Manual prctico

13. Esta sera una vista de un diagrama UML mostrado en el propio entorno de
Visual Studio. Muchas de las opciones ms importantes para trabajar con los
Modelos UML estn disponibles directamente, mediante el botn derecho del
ratn de modo contextual al elemento seleccionado.

14. Tambin son visibles las propiedades de los Artefactos UML, y existe la
posibilidad de realizar bsquedas y consultas a la ayuda o al foro integrado de
Enterprise Architect.

15. Para finalizar, vamos a realizar un ejemplo de generacin de cdigo desde una
Clase creada en Enterprise Architect. Para ello, en primer lugar creamos la Clase:

Pg 199 de 213
 Enterprise Architect
Manual prctico

16. Y en ella, agregamos un atributo y una operacin:

Pg 200 de 213
 Enterprise Architect
Manual prctico

17. Generamos su cdigo en Visual Studio seleccionando:

18. Este es el resultado de la generacin de cdigo sincronizada entre Enterprise

Architect y Visual Studio:

Pg 201 de 213
 Enterprise Architect
Manual prctico

18. Caractersticas adicionales

Vista Element List

A partir de la versin 7.0 se incorpora esta vista, muy til en procesos, por ejemplo, de
verificacin y validacin que requieran un examen secuencial de ciertas caractersticas
o propiedades de los elementos del Modelo.

Esta vista, que se inicia mediante View  Element List muestra, en la ventana principal,
una lista de los elementos que se encuentren en el paquete seleccionado en el Project
Browser y que, opcionalmente, cumplan con el filtro aplicable de Tipo de Elemento:

Una de las ventajas que proporciona, es que se pueden editar todas las propiedades de
los elementos directamente desde esta ventana. Esto facilita enormemente el trabajo
repetitivo de modificacin o actualizacin masiva de una propiedad. Tambin el hecho
de que, al seleccionar un elemento de la lista, se resalte automticamente en el Project
Browser.

Tambin es posible agregar nuevos elementos o eliminar los existentes, haciendo uso
de los botones de la barra superior de esta ventana:

Pg 202 de 213
 Enterprise Architect
Manual prctico

Ms en detalle

Crear nuevo elemento

Editar campo Notes

Eliminar elemento

Imprimir lista de elementos

Generar documentacin RTF

Obtener ayuda

Filtrar elementos por tipo

Cambiar Toolbox o Tecnologa

Opciones

Crear nuevo elemento: Aade un nuevo elemento en el paquete seleccionado.

Editar campo Notes: Permite ver y/o editar el campo Notes del elemento.
Eliminar elemento: Elimina el elemento del Modelo.
Imprimir lista de elementos: Imprime la vista Element List como un informe.
Generar documentacin RTF: Aplica el generador de documentacin RTF
nicamente a los elementos seleccionados o filtrados que aparecen en la lista.
Obtener ayuda: Muestra la ayuda de Enterprise Architect
Filtrar elementos por tipo: Muestra nicamente los elementos del tipo seleccionado
en el desplegable.
Cambiar Toolbox o Tecnologa: Modifica el rango de tipos de elemento del
desplegable de acuerdo al Toolbox o la Tecnologa seleccionada.
Opciones: Permite indicar si se desea que tambin se muestren los elementos de los
subpaquetes del paquete seleccionado (nested packages) y si se desea mostrar o no el
campo Notes de los elementos.

NOTA: Esta funcionalidad est integrada con las caractersticas de Auditora. En caso de que el
proyecto tenga habilitada dicha caracterstica, los elementos de la lista mostrarn tambin la
informacin almacenada relativa a la Auditora.

Pg 203 de 213
 Enterprise Architect
Manual prctico

Foro de discusin

Desde el men View  Discussion Forum se accede a un foro incluido en Enterprise

Architect y disponible para todos los usuarios.

El funcionamiento de este foro es similar a cualquier otro, y no vamos a entrar

demasiado en detalle en cuanto a su funcionalidad por ser altamente intuitiva y, como
hemos dicho, similar a otras herramientas de estas caractersticas.

Las ventajas que proporciona son muy claras. No existe duda de que poner en comn,
comunicar, exponer, etc ideas y soluciones entre Arquitectos, Analistas y
Desarrolladores es una excelente manera de integrar e implicar al equipo, adems de
proporcionar una va rpida de solucin a problemas expuestos, ya sean estos propios
del modelado UML como de cualquier otro mbito en el marco del proyecto.

En el panel de la izquierda, con el botn derecho del ratn, podemos crear nuevas
Categoras (Category), Tpicos (Tpic) y Entradas (Posts).

En el panel derecho, se muestra informacin acerca del elemento seleccionado (autor,

fecha de creacin y modificacin) y el texto asociado, en caso de ser una Entrada
(Post).

Pg 204 de 213
 Enterprise Architect
Manual prctico

Toda la informacin del foro se almacena, bien en el propio archivo .EAP, o en la Base
de Datos en la que tengamos alojado el Repositorio. En este segundo caso, hay que
indicar la conexin mediante un cuadro de dilogo de vnculo de datos.

Se pueden tener tantos foros como se desee, y cambiar la conexin a uno u otro en
cualquier momento, a travs de esta ventana accesible pulsando el botn derecho del
ratn sobre el panel izquierdo del foro, y seleccionando Forum Connections:

El resto de opciones que se obtienen pulsando el botn derecho, como hemos dicho
antes, son prcticamente autoexplicativas y no profundizaremos aqu en ellas.

Pg 205 de 213
 Enterprise Architect
Manual prctico

Estadsticas del proyecto

Desde el men Project  View Project Statistics se accede a una ventana que nos
muestra una relacin del nmero de elementos que componen en Modelo,
agrupndolos por tipos:

Pg 206 de 213
 Enterprise Architect
Manual prctico

Estimacin por Puntos de Casos de Uso

Enterprise Architect incorpora un mdulo de clculo para la estimacin del proyecto

por la tcnica de Puntos de Casos de Uso.

Desde el men View  Use Case Metrics se accede dicho mdulo de clculo:

La tcnica de Estimacin por Puntos de Casos de Uso se basa, para obtener el clculo,
en tres factores:

Factor de Complejidad de Actores y Casos de Uso: estos valores se configuran en las

propiedades de los Actores y los Casos de Uso, concretamente en su propiedad
Complexity, que ha de tener un valor igual a Simple, Medio o Complejo

Factor de Complejidad Tcnica: Esta tabla y sus valores estn predefinidas en la

propia tcnica, si bien son editables por el usuario.

Factor de Complejidad del Entorno: Esta tabla y sus valores estn predefinidas en la
propia tcnica, si bien son editables por el usuario.

No vamos a describir aqu la tcnica completa. nicamente haremos referencia al lugar

donde las tablas de Factores de Complejidad estn disponibles para ser consultadas o
editadas, esto es, mediante la opcin de men Settings  Estimation Factors:

Pg 207 de 213
 Enterprise Architect
Manual prctico

Como resultado de aplicar las frmulas descritas en la propia tcnica, se obtienen unos
valores estimados de tiempo y coste que se ven reflejados en la ventana anteriormente
descrita.

Pg 208 de 213
 Enterprise Architect
Manual prctico

19. ANEXO I. Enunciado del ejercicio

prctico Gestin de Proyectos

En la organizacin de la que se han estado tomando datos se quiere automatizar con el

mayor grado posible, el sistema de gestin de solicitudes y proyectos informticos. La
organizacin est estructurada en departamentos. Estos departamentos plantean
solicitudes que se recogen y almacenan debidamente. Las necesidades que pueden
plantear los departamentos, son en realidad propuestas para realizar distintos
desarrollo informticos que los departamentos detectan.

El departamento de Organizacin, es el rgano fundamental encargado de realizar la

seleccin adecuada y el filtro necesario sobre todo el conjunto de solicitudes planteadas
en base a unos criterios concretos que de momento se van a tomar de manera general.

De todas las necesidades planteadas por los departamentos y almacenadas convenientemente

para su estudio, el departamento de organizacin, establece definitivamente las que se
van a convertir en proyectos de desarrollo. Para ello, cada una de las necesidades
seleccionadas se convierte en un nuevo proyecto que queda abierto desde ese mismo
momento.

La informacin bsica que se desea guardar de los proyectos que han sido
seleccionados como tal son por el momento:

Identificador del Proyecto

Nombre del Proyecto
Fecha de creacin del proyecto
Fecha de entrada de la propuesta
Departamento que solicita la propuesta
Persona de contacto de la propuesta
Descripcin breve del proyecto
Prioridad del proyecto
Solicitud / Necesidad que origin el proyecto

Con toda esta informacin debidamente cumplimentada, el proyecto queda abierto y

preparado para las siguientes actividades.

El departamento de Desarrollo y sistemas de Informacin tiene una estructura similar a

la de cualquier otro. Desde el punto de vista del sistema de informacin que estamos
analizando, se pueden distinguir las siguientes funciones:

Jefe de Desarrollo. Es la figura encargada de tomar el proyecto por primera vez desde
que este queda abierto.

Pg 209 de 213
 Enterprise Architect
Manual prctico

Jefe de Proyecto. Figura existente en un nmero variable en funcin de las necesidades

coyunturales.

Recursos Tcnicos. Cualquiera de las personas que en sus diferentes aspectos y

funciones se encargan de desarrollar los proyectos, a travs de su actividad diaria.

Por tanto todas las actividades relacionadas con el departamento de Desarrollo y

Sistemas de Informacin sern realizadas por cualquiera de estas figuras.

Una vez que el proyecto queda abierto, el Jefe de Desarrollo recoge toda la informacin
de ese proyecto y decide quien debe ser el jefe de proyecto para ese desarrollo. Esta
asignacin del proyecto, sigue unas circunstancias muy subjetivas que pueden
modificar la situacin inicialmente decidida hasta que se produzca el comienzo real del
proyecto. El sistema no se preocupar del momento de los criterios que se seguirn
(por el momento sern personales o no definibles.

En este proceso de asignacin del proyecto a un Jefe de Proyecto, el Jefe de Desarrollo

registra la siguiente informacin:

Jefe de Proyecto inicialmente designado.

El jefe de Proyecto seleccionado para el proyecto debe encargarse de suministrar el

resto de la informacin que se desea o al menos que se entiende como importante para
el sistema de gestin:

Fecha estimada de inicio

Fecha estimada de fin del proyecto (antes de la implantacin)
Esfuerzo estimado: en horas / hombre
Coste estimado del proyecto

Todos los pasos realizados hasta ahora constituyen los datos fundamentales previos al
comienzo real del proyecto.

La actividad de cada una de las personas se refleja diariamente en unos documentos

escritos denominados hojas de actividad. De momento slo son rellenados por el
personal de desarrollo. En esta hoja de actividad se identifica la siguiente estructura:

Nmero de Parte
Fecha:
Nombre:

Identificador de Proyecto Horas Observaciones

Pg 210 de 213
 Enterprise Architect
Manual prctico

La nica informacin opcional en este documento es la correspondiente a los campos

Observaciones

Si se rellena una hoja de actividad, se deber poner por lo menos una lnea de un
proyecto en el que se haya estado trabajando. Por el momento, si una persona del
departamento de desarrollo no ha estado involucrado en un proyecto concreto no tiene
porqu rellenar esta hoja. Con esta actividad, se deseara ir registrando con la mayor
rapidez y realidad posible el nmero de horas dedicadas diariamente al proyecto
correspondiente.

Inicialmente se pretende que esta hoja de actividad sirva para ir registrando

diariamente la actividad de todas las personas involucradas en los distintos proyectos
y que sirva de base para obtener informacin desde diferentes puntos de vista.

El comienzo del proyecto real lo marca el jefe de Proyecto por lo que debe incluir
dentro de la informacin general del proyecto la fecha de comienzo.

El fin del proyecto, desde el punto de vista del sistema de gestin lo debe marcar el jefe
de proyecto, indicando la fecha de fin (no se va a entrar en las circunstancias que van
marcar este fin, puesto que queda fuera del mbito de estudio de este proyecto). Lo
ms importante es que, una vez indicada una fecha de fin de proyecto por el jefe de
proyecto no deberan admitirse ningn tipo de actividad registrable o imputable a ese
proyecto.

El fin de proyecto no significa que el proyecto est completamente cerrado, puesto que
slo significa que el Departamento de Desarrollo entiende que el proyecto ha
terminado desde el punto de vista tcnico pero an falta el visto bueno del
departamento que identific la necesidad.

Para poder concluir todo el circuito de informacin, una vez finalizado el proyecto se
debe informar al departamento que el proyecto ha terminado y que tiene va libre para
realizar las pruebas oportunas y aceptar definitivamente el mismo.

Anotar la fecha de fin de proyecto debe implicar que el proyecto ha generado una serie
de programas o aplicaciones que ya puede utilizar el usuario para comprobar su buen
funcionamiento, por tanto de manera automtica, una vez registrada la fecha, se desea
emitir una carta o documento formal al departamento que solicit el proyecto (a la
atencin del contacto que se registro en la informacin inicial), indicando que el
proyecto ha finalizado y que ya puede acceder al mismo.

Puesto que el sistema de informacin slo pretender encargarse de la gestin de la

informacin de los proyectos, las circunstancias que se producen a continuacin no
pueden ser reflejadas en este sistema. Esto significa que puede pasar un periodo de
tiempo grande desde la emisin del documento hasta la siguiente circunstancia
reflejable en el sistema.

Pg 211 de 213
 Enterprise Architect
Manual prctico

Se quiere finalizar el circuito de informacin mediante la recepcin de la carta que se

enva a los usuarios, debidamente cumplimentada. Esto supone el cierre del proyecto
con fecha de recepcin de la carta debidamente firmada.

En un inicio, y previo estudio de la cantidad de informacin que se va a tratar, no se

considera que el volumen de informacin que se vaya a general a lo largo de la vida de
este sistema sea significativo, aunque posteriormente se puede profundizar en estos
aspectos segn vaya desarrollndose el mismo.

Inicialmente se plantean una serie de informes que se desean desde el departamento de

organizacin y el jefe de desarrollo. Tienen objetivos distintos y por tanto sus formatos
sern diferentes, aunque de momento no se ha entrado en profundidad y se tendr en
cuenta para posteriores reuniones. Estos informes, son solicitados para ser realizados
durante el proceso de finalizacin del proyecto, junto (o como parte de las actividades)
a la emisin (generacin) de la carta de aceptacin.

cd Registro Peticiones

asp page
Alta de Peticiones

Nmero de Peticion

Nombre Peticion

Departamento Solicitante Fecha

Descripcion detallada

Prioridad (A/M/B)

Aceptar Cancelar

Pg 212 de 213
 Enterprise Architect
Manual prctico

cd Registro de Proyectos

Alta de Proyectos

Nmero de Proyecto Peticion Asociada Fecha

Nombre Proyecto

Jefe Proyecto

Importancia

Descripcion detallada

Coste Estimado Inicio Real Horas Reales

Inicio Estimado

Fin Real Desviacion

Fin Estimado Puntos Funcion

Cierre

Aceptar Cancelar

cd Registro de Activ idad

Parte De Trabaj o

No. Parte

Fecha

Nombre Tcnico

Detalle de proyectos trabajados

Nmero de Proyecto horas Observaciones

Aceptar Cancelar

Pg 213 de 213