73999

Ttol: Desarrollo de un plug-in de Eclipse para

validar los nombres de los elementos de un

esquema conceptual

Volum: 1/1

Alumne: Ral Garca Ranea

Director/Ponent: Cristina Gmez Seoane

David Aguilera Moncus

Departament: Enginyeria de Serveis i Sistemes dInformaci

Data: 1 de Julio de 2011

DADES DEL PROJECTE

Ttol del Projecte: Desarrollo de un plug-in para Eclipse para validar los nombres de

los elementos de un esquema conceptual en UML.

Nom de l'estudiant: Ral Garca Ranea

Titulaci: Ingeniera Informtica

Crdits: 37,5

Director/Ponent: Cristina Gmez Seoane

Departament: Enginyeria de Serveis i Sistemes dInformaci

MEMBRES DEL TRIBUNAL (nom i signatura)

Presidenta: Ruth Raventos Pages

Vocal: Montserrat Maureso Snchez

Secretria: Cristina Gmez Seoane

QUALIFICACI

Qualificaci numrica:

Qualificaci descriptiva:

Data:

Tabla de contenido

1. INTRODUCCIN ........................................................................................................................... 11

2. DESCRIPCIN DEL PROYECTO ...................................................................................................... 13

2.1. MOTIVACIN ................................................................................................................................ 13

2.2. OBJETIVO DEL PROYECTO................................................................................................................. 16

3. MODELIZACIN CONCEPTUAL ..................................................................................................... 19

3.1. ESQUEMAS CONCEPTUALES: QU SON Y PARA QU SIRVEN? ................................................................. 19

3.2. LENGUAJE UML ............................................................................................................................ 20

3.2.1. Definicin.......................................................................................................................... 21

4. GUAS DE NOMINACIN .............................................................................................................. 35

4.1. ENTIDADES ................................................................................................................................... 36

4.1.1. Regla Sintctica ................................................................................................................ 36

4.1.2. Regla Semntica ............................................................................................................... 36

4.2. ATRIBUTOS ................................................................................................................................... 37

4.2.1. Regla Sintctica ................................................................................................................ 37

4.2.2. Regla Semntica ............................................................................................................... 38

4.3. ASOCIACIONES .............................................................................................................................. 39

4.3.1. Regla Sintctica ................................................................................................................ 39

4.3.2. Regla Semntica ............................................................................................................... 40

4.4. INVARIANTES ................................................................................................................................. 41

4.4.1. Regla Sintctica ................................................................................................................ 41

4.4.2. Regla Semntica ............................................................................................................... 41

4.5. TIPOS DE EVENTOS Y OPERACIONES DEL SISTEMA ................................................................................. 42

4.5.1. Eventos ............................................................................................................................. 42

4.5.2. Operaciones ...................................................................................................................... 42

4.5.3. Precondiciones.................................................................................................................. 43

4.5.4. Post-Condiciones .............................................................................................................. 44

4.6. ESTADOS ...................................................................................................................................... 45

4.6.1. Regla Sintctica ................................................................................................................ 45

4.6.2. Regla Semntica ............................................................................................................... 46

5. ESTUDIO DE MERCADO................................................................................................................ 47

5.1. PROCESADO DE LA GRAMTICA INGLESA............................................................................................. 47

5.1.1. Generador Sintctico CUP ................................................................................................ 47

5.1.2. Generador Sintctico Antlr ............................................................................................... 48

5.1.3. Generador Sintctico JavaCC ............................................................................................ 49

5.1.4. Conclusiones ..................................................................................................................... 50

5.2. PROCESADO DE NOMBRES ............................................................................................................... 50

5.2.1. IDD Plug-in ........................................................................................................................ 51

6. ECLIPSE ........................................................................................................................................ 53

6.1. QU ES ECLIPSE Y PARA QU SIRVE? ................................................................................................. 53

6.2. ORGENES DE ECLIPSE ..................................................................................................................... 54

6.2.1. La fundacin Eclipse ......................................................................................................... 55

6.3. INTRODUCCIN A ECLIPSE ................................................................................................................ 57

6.3.1. Versin utilizada ............................................................................................................... 58

6.4. PLUG-INS ..................................................................................................................................... 58

6.4.1. Qu es un Plug-in? .......................................................................................................... 59

6.4.2. Estructura de los plug-ins ................................................................................................. 59

6.4.3. Plug-ins utilizados ............................................................................................................. 61

7. ANLISIS DE REQUISITOS ............................................................................................................. 63

7.1. A QUIN VA DIRIGIDO? .................................................................................................................. 63

7.2. REQUISITOS .................................................................................................................................. 63

7.2.1. Requisitos Funcionales ..................................................................................................... 64

7.2.2. Requisitos No-Funcionales................................................................................................ 65

7.2.3. Restricciones ..................................................................................................................... 66

8. ESPECIFICACIN .......................................................................................................................... 67

8.1. MODELO DE CASOS DE USO ............................................................................................................. 67

8.1.1. Casos de Uso Esenciales ................................................................................................... 69

8.2. ESQUEMA CONCEPTUAL .................................................................................................................. 72

8.3. MODELO DE COMPORTAMIENTO DEL SISTEMA .................................................................................... 76

8.3.1. Diagramas de Secuencia .................................................................................................. 76

8.3.2. Contratos para las operaciones del Sistema .................................................................... 78

9. DISEO ........................................................................................................................................ 81

9.1. MODELO DE CASOS DE USO ............................................................................................................. 82

9.1.1. Casos de Uso Concretos .................................................................................................... 82

9.2. ARQUITECTURA DEL SISTEMA ........................................................................................................... 86

9.2.1. Arquitectura de Eclipse ..................................................................................................... 86

9.2.2. Arquitectura de Plug-in .................................................................................................... 88

9.2.3. Arquitectura en 3 capas ................................................................................................... 89

9.3. DISEO DE LAS CAPAS ..................................................................................................................... 91

9.3.1. Capa de Presentacin ....................................................................................................... 92

9.3.2. Capa de Dominio ............................................................................................................ 111

9.3.3. Capa de Gestin de Datos .............................................................................................. 122

10. DISEO DE ANALIZADORES SINTCTICOS .............................................................................. 127

10.1. AUTMATAS ............................................................................................................................... 127

10.1.1. Autmata Entidad .......................................................................................................... 128

10.1.2. Autmata Atributo ......................................................................................................... 129

10.1.3. Autmata Asociacin ..................................................................................................... 130

10.1.4. Autmata Operaciones .................................................................................................. 133

10.1.5. Autmata Invariantes .................................................................................................... 134

10.1.6. Autmata Precondiciones y Post-Condiciones ............................................................... 136

10.1.7. Autmata Eventos .......................................................................................................... 138

10.1.8. Autmata Estados .......................................................................................................... 139

11. IMPLEMENTACIN ................................................................................................................ 141

11.1. LENGUAJE DE PROGRAMACIN ....................................................................................................... 141

11.2. INICIALIZACIONES DEL PLUG-IN ....................................................................................................... 142

11.3. CONTRIBUCIONES DEL PLUG-IN ....................................................................................................... 144

11.4. VISTA VERBALIZE ......................................................................................................................... 146

11.5. RECOGER INFORMACIN DE ECLIPSE ................................................................................................ 146

11.6. IMPLEMENTACIN DE LOS ANALIZADORES SINTCTICOS ....................................................................... 147

11.7. IMPLEMENTACIN WEB SERVICE..................................................................................................... 149

11.8. IMPLEMENTACIN DEL DOMINIO UMLDOMAIN ................................................................................. 150

12. TEST ...................................................................................................................................... 151

12.1. PRUEBAS DE FUNCIONALIDAD ......................................................................................................... 151

12.1.1. Verbalizar y Comprobar Nombres .................................................................................. 151

12.1.2. Mostrar Guas ................................................................................................................. 158

12.1.3. Mostrar Manual ............................................................................................................. 158

12.1.4. Configurar Opciones de Verbalizacin ........................................................................... 158

12.2. PRUEBAS DE PLUG-IN ................................................................................................................... 159

12.2.1. Ficheros Locales del Plug-in ............................................................................................ 159

12.2.2. Apariencia del Plug-in..................................................................................................... 160

13. PLANIFICACIN Y ESTUDIO ECONMICO .............................................................................. 161

13.1. PLANIFICACIN ............................................................................................................................ 161

13.1.1. Estimacin temporal estimada vs. Estimacin real ........................................................ 161

13.1.2. Diagrama de Gantt ......................................................................................................... 162

13.2. ESTUDIO ECONMICO................................................................................................................... 164

13.2.1. Costes de Material.......................................................................................................... 164

13.2.2. Coste del Personal .......................................................................................................... 164

13.2.3. Coste total del Proyecto ................................................................................................. 166

14. CONCLUSIONES ..................................................................................................................... 167

14.1. OBJETIVOS CUBIERTOS .................................................................................................................. 167

14.2. TRABAJO FUTURO ........................................................................................................................ 168

15. ANEXO: MANUAL DE USUARIO ............................................................................................. 169

15.1.1. Manual de Instalacin .................................................................................................... 169

15.1.2. Pantalla Principal ........................................................................................................... 171

15.1.3. Configurar Opciones de Verbalizacin ........................................................................... 175

15.1.4. Mostrar Guas de Nominacin ....................................................................................... 176

15.1.5. Mostrar Manual de Ayuda ............................................................................................. 178

15.1.6. Comprobar Nombres ...................................................................................................... 179

15.1.7. Verbalizar ....................................................................................................................... 180

16. ANEXO: DESGLOSE DE LA DESVIACIN POR TAREAS ............................................................. 183

BIBLIOGRAFA .................................................................................................................................... 193

ILUSTRACIN 1: EJEMPLO DE ESQUEMA CONCEPTUAL ............................................................................................ 11

ILUSTRACIN 2: EJEMPLO DE ESQUEMA CONCEPTUAL CON NOMBRES INCORRECTOS .................................................... 15

ILUSTRACIN 3: EJEMPLO DE ESQUEMA CONCEPTUAL CON NOMBRES CORRECTOS ....................................................... 15

ILUSTRACIN 4: ESQUEMA CONCEPTUAL ............................................................................................................. 19

ILUSTRACIN 6: EVOLUCIN DE UML ................................................................................................................. 21

ILUSTRACIN 5: UML ...................................................................................................................................... 21

ILUSTRACIN 7: ESTRUCTURA DE DIAGRAMAS UML .............................................................................................. 23

ILUSTRACIN 8: EJEMPLO DE CLASE .................................................................................................................... 25

ILUSTRACIN 9: EJEMPLO DE ASOCIACIN ............................................................................................................ 26

ILUSTRACIN 10: EJEMPLO DE AGREGACIN ........................................................................................................ 27

ILUSTRACIN 11: EJEMPLO DE COMPOSICIN ....................................................................................................... 27

ILUSTRACIN 12: EJEMPLO DE GENERALIZACIN ................................................................................................... 28

ILUSTRACIN 13: EJEMPLO DE DATA TYPE ........................................................................................................... 28

ILUSTRACIN 14: EJEMPLO DE CLASE ASOCIATIVA ................................................................................................. 29

ILUSTRACIN 15: EJEMPLO DE ENUMERACIN ...................................................................................................... 30

ILUSTRACIN 16: DIAGRAMA DE ESTADOS ........................................................................................................... 31

ILUSTRACIN 17: EJEMPLO DE ESQUEMA CONCEPTUAL .......................................................................................... 32

ILUSTRACIN 18: CLASES, ATRIBUTOS, OPERACIONES Y ASOCIACIONES ....................................................................... 33

ILUSTRACIN 19: TIPOS DE DATOS ..................................................................................................................... 34

ILUSTRACIN 20: ECLIPSE ................................................................................................................................. 54

ILUSTRACIN 21: PLATAFORMA ECLIPSE .............................................................................................................. 57

ILUSTRACIN 22: ESTRUCTURA DE PLUG-INS EN ECLIPSE ......................................................................................... 58

ILUSTRACIN 23: CREACIN DE UN PLUG-IN ......................................................................................................... 61

ILUSTRACIN 24: DIAGRAMA DE CASOS DE USO.................................................................................................... 68

ILUSTRACIN 25: ESQUEMA CONCEPTUAL DEL SISTEMA ......................................................................................... 73

ILUSTRACIN 26: DIAGRAMA DE SECUENCIA DEL CASO DE USO "CHECK NAMES OF CONCEPTUAL SCHEMA" .................... 76

ILUSTRACIN 27: DIAGRAMA DE SECUENCIA DEL CASO DE USO "SHOW MANUAL" ...................................................... 77

ILUSTRACIN 28: DIAGRAMA DE SECUENCIA DEL CASO DE USO "SHOW GUIDELINES" .................................................. 77

ILUSTRACIN 29: DIAGRAMA DE SECUENCIA DEL CASO DE USO "VERBALIZE CONCEPTUAL SCHEMA"............................... 77

ILUSTRACIN 30: DIAGRAMA DE SECUENCIA DEL CASO DE USO "CONFIGURE VERBALIZATION OPTIONS" ......................... 78

ILUSTRACIN 31: ARQUITECTURA DE ECLIPSE ....................................................................................................... 86

ILUSTRACIN 32: ESQUEMA DEL SISTEMA ............................................................................................................ 88

ILUSTRACIN 33: PATRN DE 3 CAPAS ................................................................................................................ 89

ILUSTRACIN 34: DIAGRAMA DE EJEMPLO DE PATRN FACHADA .............................................................................. 91

ILUSTRACIN 35: MAPA NAVEGACIONAL ............................................................................................................. 94

ILUSTRACIN 36: PANTALLA PRINCIPAL ............................................................................................................... 95

ILUSTRACIN 37: FUNCIONALIDADES ACTIVAS ...................................................................................................... 96

ILUSTRACIN 38: FUNCIONALIDADES INHABILITADAS.............................................................................................. 97

ILUSTRACIN 39: PANTALLA DE CONFIGURACIN .................................................................................................. 98

ILUSTRACIN 40: PANTALLA DE AYUDA CON GUAS DE NOMINACIN ........................................................................ 99

ILUSTRACIN 41: PANTALLA DE AYUDA CON NDICE DEL MANUAL ............................................................................ 99

ILUSTRACIN 42: VISTA PARA VISUALIZAR ERRORES .............................................................................................. 100

ILUSTRACIN 43: PANTALLA DE SAVE AS ........................................................................................................... 100

ILUSTRACIN 44: PANTALLA DE INFORMACIN ................................................................................................... 101

ILUSTRACIN 45: PANTALLA DE ERROR .............................................................................................................. 102

ILUSTRACIN 46: DIAGRAMA DE CLASES DE LA CAPA DE PRESENTACIN .................................................................. 104

ILUSTRACIN 47: DIAGRAMA DE CLASES VISTA VERBALIZE .................................................................................... 105

ILUSTRACIN 48: DIAGRAMA DE SECUENCIA DE LA FUNCIONALIDAD VERBALIZE ......................................................... 107

ILUSTRACIN 49: DIAGRAMA DE SECUENCIA DE LA FUNCIONALIDAD SHOW MANUAL ................................................. 108

ILUSTRACIN 50: DIAGRAMA DE SECUENCIA DE LA FUNCIONALIDAD SHOW GUIDELINES .............................................. 108

ILUSTRACIN 51: DIAGRAMA DE SECUENCIA DE LA FUNCIONALIDAD CONFIGUREVERBALIZATIONOPTIONS ...................... 109

ILUSTRACIN 52: DIAGRAMA DE SECUENCIA DE LA FUNCIONALIDAD CHECKNAMES .................................................... 110

ILUSTRACIN 53: DIAGRAMA DE CLASES DE LA CAPA DE DOMINIO .......................................................................... 112

ILUSTRACIN 54: DIAGRAMA DE SECUENCIA DE LA FUNCIN ADDPROPERTY ............................................................. 116

ILUSTRACIN 55: DIAGRAMA DE SECUENCIA DE LA FUNCIN CHECKNAMES() ........................................................... 117

ILUSTRACIN 56: DIAGRAMA DE SECUENCIA DE LA FUNCIN CHECKPROPERTY .......................................................... 118

ILUSTRACIN 57: DIAGRAMA DE SECUENCIA DE LA FUNCIN VERBALIZEELEMENTS .................................................... 119

ILUSTRACIN 58: DIAGRAMA DE SECUENCIA DE LA FUNCIN LOADELEMENTS ........................................................... 120

ILUSTRACIN 59: DIAGRAMA DE SECUENCIA DE LA FUNCIN CATCHPROPERTYINFO ................................................... 121

ILUSTRACIN 60: DIAGRAMA DE SECUENCIA DE LA FUNCIN LOADMODEL ............................................................... 121

ILUSTRACIN 61: DIAGRAMA DE CLASES DE LA CAPA DE GESTIN DE DATOS ............................................................ 122

ILUSTRACIN 62: DIAGRAMA DE SECUENCIA DE LA FUNCIN LOADCONFIGFILE ......................................................... 123

ILUSTRACIN 63: DIAGRAMA DE SECUENCIA DE LA FUNCIN UPDATECONFIGFILE ...................................................... 124

ILUSTRACIN 64: DIAGRAMA DE TRANSICIONES DE UN AUTMATA ........................................................................ 128

ILUSTRACIN 65: ANALIZADOR SINTCTICO DE ENTIDADES .................................................................................... 129

ILUSTRACIN 66: ANALIZADOR SINTCTICO ATRIBUTOS NO-BOOLEANOS ................................................................ 130

ILUSTRACIN 67: ANALIZADOR SINTCTICO ASOCIACIONES BINARIAS ...................................................................... 131

ILUSTRACIN 68: ANALIZADOR SINTCTICO ASOCIACIONES N-ARIAS ....................................................................... 132

ILUSTRACIN 69: ANALIZADOR SINTCTICO OPERACIONES .................................................................................... 133

ILUSTRACIN 70: ANALIZADOR SINTCTICO INVARIANTES ..................................................................................... 135

ILUSTRACIN 71: ANALIZADOR SINTCTICO PRE/POST-CONDICIONES ..................................................................... 137

ILUSTRACIN 72: ANALIZADOR SINTCTICO EVENTOS .......................................................................................... 138

ILUSTRACIN 73: ANALIZADOR SINTCTICO ESTADOS ........................................................................................... 139

ILUSTRACIN 74: DIAGRAMA DE GANTT ............................................................................................................ 163

ILUSTRACIN 75: ASISTENTE INSTALL ................................................................................................................ 170

ILUSTRACIN 76: ASISTENTE REPOSITORIOS ....................................................................................................... 171

ILUSTRACIN 77: PANTALLA PRINCIPAL DE ECLIPSE .............................................................................................. 172

ILUSTRACIN 78: ASISTENTE NEW .................................................................................................................... 173

ILUSTRACIN 79: ASISTENTE NEW (2) ............................................................................................................... 173

ILUSTRACIN 80: FUNCIONES ACTIVAS .............................................................................................................. 174

ILUSTRACIN 81: FUNCIONALIDADES PLUG-IN .................................................................................................... 174

ILUSTRACIN 82: FUNCIONALIDADES DESACTIVADAS ............................................................................................ 175

ILUSTRACIN 83: PANTALLA DE CONFIGURACIN................................................................................................. 176

ILUSTRACIN 84: PANTALLA DE AYUDA: NDICE DE LAS GUAS DE NOMINACIN ........................................................ 177

ILUSTRACIN 85: PANTALLA DE AYUDA DE ECLIPSE: MANUAL DE AYUDA ................................................................. 178

ILUSTRACIN 86: SELECCIN DEL EDITOR UML .................................................................................................. 179

ILUSTRACIN 87: VENTANA DE AVISO ............................................................................................................... 180

ILUSTRACIN 88: VISTA DE ERRORES ................................................................................................................. 180

ILUSTRACIN 89: VENTANA DE ERROR: CONFIGURACIN ...................................................................................... 181

ILUSTRACIN 90: VENTANA GUARDAR ........................................................................................................... 181

ILUSTRACIN 91: VENTANA DE AVISO: DOCUMENTO GENERADO CON XITO ............................................................ 182

Introduccin Plug-in Verbalize

11 | P g i n a

1. Introduccin

Un esquema conceptual es el conocimiento general que un sistema debe conocer para

realizar sus funciones [1]. Representa, grficamente, conceptos y las relaciones del mundo

real.

Para desarrollar un sistema de informacin es necesario definir su esquema conceptual

Principio de necesidad de esquemas conceptuales.

Como podemos extraer del principio de necesidad, los esquemas conceptuales son una

parte importante a la hora de desarrollar un sistema de informacin. Los esquemas

conceptuales son creados y utilizados en el proceso de anlisis y diseo de los sistemas.

Un esquema conceptual tiene dos partes: parte estructural y parte de comportamiento. La

parte estructural especifica las entidades que forman parte del dominio, sus relaciones, sus

atributos, las restricciones de integridad. La parte de comportamiento define el tipo de

eventos que pueden producirse en el dominio [2].

Ilustracin 1: Ejemplo de Esquema Conceptual1

En la Ilustracin 1 podemos ver un ejemplo de un Esquema Conceptual, donde se nos

muestra informacin relacionada con Trabajadores (Employee) y Departamentos

(Department). Existen relaciones entre estas dos entidades que nos informan de que los

trabajadores estn asignados a un departamento (WorksIn), y que un trabajador es el

encargado de gestionar el departamento (Manages). En el captulo 1 se explica con ms

detalle la modelizacin conceptual, as como la meta-modelizacin.

1 Siempre que no se indique mediante un flecha (< o ^), las asociaciones se leen de izquierda a derecha y

de arriba a abajo. Las multiplicidades con valor 1 no aparecen debido a que Eclipse (la herramienta con la que estn generadas las ilustraciones de los esquemas conceptuales) las omite.


12 | P g i n a

Un esquema conceptual no solo sirve para ayudar al desarrollador a implementar el

sistema sino que sus usos van ms all. Idealmente, cualquier persona ajena al sistema debera

poder entender la informacin y el conocimiento que muestra el esquema conceptual. Esto no

solo se consigue especificando correctamente las relaciones, sino que tambin hay que utilizar

las palabras que mejor representan ese conocimiento, para no ofrecer ninguna ambigedad.

Los nombres que se le dan a los diferentes elementos de un esquema conceptual juegan

un papel muy importante a la hora de entender dicho esquema. La eleccin de nombres

correctos hace ms fcil la tarea de entender los esquemas no slo a los desarrolladores sino

tambin a usuarios menos tcnicos. El problema reside en elegir nombres correctos para los

elementos del esquema conceptual.

Esta memoria est divida en diferentes captulos que se describen brevemente a

continuacin:

Captulo 2: Descripcin del proyecto. Explicacin de las motivaciones y objetivos

del proyecto.

Captulo 3: Modelizacin Conceptual. Descripcin de los conceptos bsicos de la

modelizacin conceptual para entender el proyecto en su contexto.

Captulo 4: Guas de nominacin. Explicacin de las guas de nominacin

utilizadas en el mbito del proyecto.

Captulo 5: Estudio de Mercado. Anlisis de las herramientas existentes en el

mercado.

Captulo 6: Eclipse. Introduccin a la herramienta Eclipse y definicin de su

estructura basada en plug-ins.

Captulo 7: Anlisis de Requisitos. Definicin de los requisitos del sistema y de sus

restricciones.

Captulo 8: Especificacin. Se detalla el comportamiento externo del sistema visto

desde la perspectiva del usuario.

Captulo 9: Diseo. Se explica el diseo del sistema y las decisiones tomadas en

esta fase.

Captulo 10: Diseo de Analizadores Sintcticos. Diseo de los analizadores

sintcticos utilizados en la aplicacin.

Captulo 11: Implementacin. Explicacin de los aspectos ms relevantes en la

fase de implementacin.


13 | P g i n a

Captulo 12: Test. Pruebas realizadas para la comprobacin del funcionamiento

de la aplicacin.

Captulo 13: Planificacin y Estudio Econmico. Valoracin temporal y econmica

del desarrollo del proyecto.

Captulo 14: Conclusiones. Valoracin cualitativa del desarrollo del proyecto y

especificacin de posibles ampliaciones.

Anexos. Manual de Usuario y desglose de tareas.

Bibliografa. Referencias web, libros y artculos consultados en las diferentes

etapas del proyecto.

Las guas de nominacin utilizadas en este proyecto estn realizadas en ingls y pensadas

para comprobar nombres escritos en ingls. Por este motivo, en el captulo 4, los ejemplos

utilizados y las frases de nominacin estn en ingles. Tambin, en el captulo 10, se han

utilizado ejemplos de nombres en ingls ya que los analizadores sintcticos son para la

gramtica inglesa. Las ilustraciones de los Esquemas Conceptuales que aparecen en la

memoria contienen todos los nombres en ingls debido a que la aplicacin est pensada para

la gramtica inglesa.

2. Descripcin del Proyecto

2.1. Motivacin

Habitualmente, cuando estamos creando esquemas conceptuales, no resulta sencillo

darles nombres a los elementos que componen el esquema. Es normal poner nombres a

elementos pensando que nicamente personas involucradas en el proyecto, o con

conocimientos tcnicos, leern el esquema. Tampoco es inusual nominar elementos creyendo

que los nombres son claros y concisos, aunque en verdad los vemos as porque somos

nosotros los que estamos trabajando con el esquema y conocemos el dominio del problema.

Por estos motivos es importante definir unas reglas que nos ayuden a elegir nombres

correctos, que no slo entienda una persona involucrada en el proyecto sino que ayude a

explicar la informacin contenida en el esquema a alguien ajeno.

Motivacin Plug-in Verbalize

14 | P g i n a

La etapa que se encarga de la modelizacin conceptual se llama Ingeniera de Requisitos.

La Ingeniera de Requisitos es la fase que precede al diseo del sistema. Es un proceso

complejo, debido a que envuelve un nmero elevado de participantes (usuarios, diseadores,

directivos, etc.) que tienen puntos de vista, necesidades e intereses diferentes. La Ingeniera de

Requisitos est compuesta de tres etapas: requirements elicitation, requirements specification

y requirements validation. Durante la fase elicitation, los futuros usuarios y los diseadores

analizan sus problemas y necesidades, y las caractersticas del dominio. De este anlisis salen

los cambios a introducir en el dominio y las funciones que debe realizar el nuevo sistema. Este

proceso es crucial ya que determina una parte importante del xito final o el fracaso del

proyecto. En la fase specification se definen los requisitos del sistema. Describen el sistema

que los usuarios requieren y que los diseadores tienen que disear y construir. En esta fase se

crea el esquema conceptual que especifica todas las funciones que el sistema debe realizar y,

junto con los requisitos no-funcionales, detallan la especificacin del sistema. En la fase

validation, las especificaciones son comprobadas para asegurar que se cumplen los requisitos

del usuario. En esta fase, es vital que los usuarios entiendan exactamente lo que el futuro

sistema har antes de que est construido. Una manera de validarlo es mostrando al usuario el

esquema conceptual en un lenguaje y forma que sea fcilmente comprensible para el usuario.

Si el esquema conceptual no es del todo comprensible para el usuario, ser necesario prestar

atencin al lenguaje utilizado, utilizar un lenguaje ms familiar (sin excluir el lenguaje natural),

o proveer al usuario de una explicacin del esquema conceptual y de su comportamiento[2

pgs. 27-28].

Como hemos indicado, la nominacin de los elementos del esquema conceptual juega un

papel importante a la hora de entenderlo. La eleccin de los nombres no es (o no debera ser)

un proceso trivial y carente de importancia. Actualmente existen muchas referencias en

documentos donde se indican guas de nominacin a seguir para una correcta nominacin

dependiendo del elemento UML con el que estemos trabajando, por ejemplo:

Un nombre comn (como persona, silla) en Ingls corresponde a un tipo Entidad

en un diagrama[3].

Cualquier nombre de un atributo tiene que ser simple y singular, y no debe

contener el nombre de la entidad contenedora[4].

Para este proyecto se ha utilizado un documento [5] donde ofrecen, a travs de un

estudio de diferentes documentos, unas guas de nominacin completas e ntegras de los

elementos UML. Completas ya que se incluyen todos los elementos UML, e ntegras ya que

para todos ellos, se ofrece una gua que sigue la misma lgica.

Las guas de nominacin de cada elemento, al que el usuario puede dar nombre, en UML

definen la forma sintctica de su nombre y una frase patrn que sirve para generar el

documento de verbalizacin. Un nombre, dado por el usuario que crea el esquema, cumple

con la gua de nominacin en cuestin si tiene la forma sintctica correspondiente, y la frase

generada a partir del patrn est gramaticalmente bien formada y tiene significado semntico.

Ms adelante en el captulo 4 se detallan, elemento a elemento, las guas de nominacin.

Descripcin del Proyecto

Plug-in Verbalize

15 | P g i n a

A continuacin veremos con unos ejemplos como se puede malinterpretar un esquema

conceptual debido a una mala eleccin de nombres.

Ilustracin 2: Ejemplo de Esquema Conceptual con nombres incorrectos

Podemos observar en la Ilustracin 2 un esquema conceptual relacionado con usuarios y

mensajes. Cuando el analista crea este esquema conceptual tiene que tener muy claro qu es

lo que desea expresar. A pesar de ser un esquema sencillo, cambiando simplemente el nombre

de la asociacin, la informacin que desprende cambia por completo. La informacin que

contiene la Ilustracin 2 no es la misma que la del esquema de la Ilustracin 3.

Ilustracin 3: Ejemplo de Esquema Conceptual con nombres correctos

En el primero se expresa que un usuario responde con un mensaje, en cambio en el

segundo se expresa que un usuario responde a un mensaje. Por lo tanto, es tarea del analista

tener especial cuidado en poner nombres, ya que puede alterar el significado de la

informacin del esquema.

Hemos ilustrado, con un ejemplo muy sencillo, como se puede malinterpretar

informacin de un esquema conceptual debido a una mala eleccin de nombres. El ejemplo

descrito contiene poca informacin, el problema se agrava cuando los esquemas conceptuales

son grandes y contienen muchos elementos. En ese punto, la eleccin de nombres correctos se

torna vital para un buen entendimiento del esquema conceptual.

Objetivo del Proyecto Plug-in Verbalize

16 | P g i n a

2.2. Objetivo del Proyecto

El objetivo principal del proyecto es la definicin, especificacin, diseo e implementacin

de una herramienta que, dado un esquema conceptual:

Indique qu nombres no cumplen con las guas de nominacin.

Genere un documento donde se verbalice los elementos para ayudar a entender

la informacin y el conocimiento del esquema.

La herramienta est pensada para ser una extensin del IDE (Integrated Development

Environment) Eclipse. Eclipse es una herramienta de programacin que ofrece servicios

integrales a los programadores para el desarrollo de software. Una de las grandes ventajas de

Eclipse es su comunidad de usuarios, que se encargan de extender las funcionalidades del

programa. En este caso, se utiliza el paquete Eclipse Modeling Project que cubre todas las

reas de la metodologa de desarrollo de software centrada en la creacin de modelos. En el

captulo 6 se hace una breve introduccin a Eclipse.

Para conseguir el objetivo del proyecto son imprescindibles una serie de sub-objetivos

que a continuacin expondremos:

Estudio de las tecnologas, lenguajes y especificaciones que se utilizarn para el

desarrollo del proyecto. Incluye el estudio de:

o Especificacin UML 2.2: UML es un lenguaje grfico para visualizar,

construir y documentar un sistema de informacin. Ofrece un estndar

para describir un esbozo de la estructura del sistema. En la seccin 3.2 se

explica con ms detalle este lenguaje.

o Eclipse Plug-ins: Eclipse es un entorno de desarrollo integrado de cdigo

abierto para el desarrollo de aplicaciones. El proyecto est pensado para

ser un plug-in de Eclipse, por lo tanto, se utiliza este entorno para su

desarrollo. En el captulo 6 se explica con ms detalle.

o Web Services: Permiten la comunicacin entre aplicaciones o

componentes de aplicaciones de forma estndar a travs de protocolos

comunes y de manera independiente al lenguaje de programacin,

sistema operativo o plataforma de implementacin utilizado. En la

seccin 9.3.2 se explica la justificacin de su uso.

o XSL-FO: es un lenguaje, basado en XML, que permite especificar el

formato visual con el que se quiere representar un documento XML. Se

utiliza para generar el documento PDF de verbalizacin.

Descripcin del Proyecto

Plug-in Verbalize

17 | P g i n a

Diseo de las guas de nominacin. Constituyen un punto clave del proyecto, ya

que son las encargadas de comprobar los nombres, de los elementos que

componen un esquema conceptual, y de generar las verbalizaciones de dichos

elementos. En el captulo 10 se detallan los analizadores sintcticos creados para

la implementacin de las guas y en la seccin 9.3.2 se especifica el diseo de las

guas.

Integracin de la herramienta en el plug-in de Eclipse creado.

Documentacin de todo el proceso de desarrollo del sistema.

Modelizacin Conceptual Plug-in Verbalize

19 | P g i n a

3. Modelizacin Conceptual

En este captulo explicaremos el concepto de Esquema Conceptual e introduciremos el

lenguaje UML as como una pequea explicacin del metamodelo UML. El objetivo de este

captulo no es dar una explicacin exhaustiva de estos conceptos, sino proporcionar los

conocimientos bsicos para entender el proyecto. Por lo tanto, en el apartado del metamodelo

explicaremos solo el subconjunto de elementos que interviene en el proyecto.

3.1. Esquemas Conceptuales: Qu son y para qu sirven?

La definicin y creacin de esquemas conceptuales es una parte muy importante en el

diseo y desarrollo de un Sistema de Informacin. Su propsito principal es mejorar la

comunicacin entre las partes implicadas en el proceso de desarrollo de un Sistema de

Informacin [1].

Un Esquema Conceptual es una representacin visual de las clases conceptuales u objetos

del mundo real en un dominio de inters[6]. Describe el conocimiento que un sistema de

informacin necesita para cumplir los objetivos.

Ilustracin 4: Esquema Conceptual

Un Esquema Conceptual est formado por dos partes:

Parte Estructural: define el conocimiento sobre el dominio, independientemente

de la implementacin. Este esquema muestra, principalmente, clases de objetos,

asociaciones entre clases de objetos, atributos de las clases de objetos,

restricciones de integridad, etc. En la Ilustracin 4 el dominio seria:

o Existen Empleados y Departamentos

o Los Empleados tienen un nombre y edad.

o Los Empleados trabajan en un Departamento.

o etc.

Parte de Comportamiento: definen los tipos de eventos que se pueden producir

en el dominio y su efecto sobre el sistema.

Lenguaje UML Plug-in Verbalize

20 | P g i n a

El anlisis y generacin de Esquemas Conceptuales es un proceso dirigido completamente

a los datos. Permite una mejor comunicacin entre usuarios, analistas, diseadores y

programadores durante todas las fases de diseo y, adems, proporciona una buena base para

el diseo de una base de datos del sistema en cuestin.

Un buen Esquema Conceptual ayuda a reconocer cmo van a afectar posibles cambios en

el futuro y, adems, ayuda a la hora de realizar cambios. Permite ver a los usuarios cules

sern sus resultados finales en el sistema antes de que haya finalizado. Tambin ofrece una

visin del sistema y de sus necesidades.

3.2. Lenguaje UML

Para que el proyecto pueda cumplir con sus objetivos, es necesario que pueda trabajar

con Esquemas Conceptuales. As que, el sistema tiene que ser capaz de recoger la informacin

de un Esquema Conceptual y tratarla para generar el resultado. Habitualmente, los Esquemas

Conceptuales se representan en lenguaje UML.

Desde los inicios de la informtica se han estado utilizando distintas formas de

representar los diseos, ya sea utilizando algn modelo grfico o con una forma personal. La

falta de un estndar en la manera de representar un modelo, ha hecho que los diseos grficos

fueran difciles de compartir entre los diseadores. Si nos centramos en los usuarios el

problema se agrava. Al no haber estandarizacin, a los usuarios les resultaba complicado

entender la informacin que se expresaba en un diseo grfico.

Comenzaron a aparecer lenguajes de modelado orientado a objetos entre mediados de

1970 y finales de 1980. El nmero de lenguajes aument de menos de 10 a ms de 50 durante

el perodo comprendido entre 1989 y 1994. Muchos usuarios de mtodos orientados a objetos

tuvieron problemas para encontrar un lenguaje adecuado a sus necesidades. A mediados de

los 90, nuevas revisiones de estos mtodos comenzaron a aparecer, y algunos empezaron a

destacar por encima de los dems.

Con el objetivo de comunicar las ideas de un diseo grfico de un diseador a otro y hacer

que el diseo grfico sirva de apoyo en los procesos de anlisis y diseo de un problema, y,

adems, ofrecer un lenguaje nico para el modelado, se cre el Unified Modeling Language,

ms conocido como UML.

A continuacin explicaremos los orgenes del lenguaje UML. Se ha realizado un resumen

de [7] para detallar los orgenes del lenguaje.


21 | P g i n a

3.2.1. Definicin

UML es un lenguaje que permite visualizar, especificar, construir y

documentar los elementos que forman parte de un sistema de

informacin orientado a objetos. El objetivo de UML es proveer a los

arquitectos de sistemas, ingenieros de software y desarrolladores de

software, una serie de herramientas para el anlisis, diseo e

implementacin de sistemas de informacin. El lenguaje UML comenz a crearse en 1994

cuando James Rumbaugh, autor del mtodo OMT (Object Modeling Tool), se uni a la

compaa Rational fundada por Grady Booch, autor del mtodo BOOCH. El objetivo de ambos

era unificar los dos mtodos que haban desarrollado: el mtodo Booch y el OMT. El primer

borrador apareci en 1995. En esa misma poca otro investigador, Ivar Jacobson, se uni a

Rational y se incluyeron ideas suyas. Adems, este lenguaje se abri a la colaboracin de otras

empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definicin

de la primera versin de UML. UML deriva y unifica las tres metodologas de anlisis y diseos

ms extendidas:

Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus

relaciones.

Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object -

Modelling Technique).

Aproximacin de Ivar Jacobson (OOSE: Object- Oriented Software Engineering)

mediante la metodologa de casos de uso.

Ilustracin 6: Evolucin de UML

Ilustracin 5: UML

Definicin Plug-in Verbalize

22 | P g i n a

La Ilustracin 6 muestra la evolucin del lenguaje UML. Las primeras versiones de UML se

originaron con los tres mtodos anteriormente descritos e incorporaron una serie de buenas

prcticas de diseo de lenguajes de modelado, programacin orientada a objetos y lenguajes

arquitectnicos. Los objetivos de UML son muy amplios, pero se pueden sintetizar en cuatro

aspectos:

Visualizar: permite expresar grficamente un sistema para que otra persona lo

pueda entender.

Especificar: permite especificar cules son las caractersticas de un sistema antes

de su construccin.

Construir: a partir de los modelos especificados se puede construir los sistemas

diseados.

Documentar: los propios elementos grficos sirven como documentacin del

sistema desarrollado.

Los principales beneficios de UML son[8]:

Modelar sistemas (no slo de software) utilizando conceptos de Orientacin a

Objetos.

Crear un lenguaje para modelar que lo pueden utilizar tanto mquinas como

personas.

Aumentar la reutilizacin y reducir los costes.

Mejorar la planificacin y el control de los proyectos.

Establecer conceptos y artefactos ejecutables.

UML es un lenguaje que goza de mucho prestigio. Esto es debido a que muchas empresas

han participado en el desarrollo del lenguaje (IBM, Microsoft, HP y Oracle). Adems, sus

creadores son personas de gran reconocimiento y los mtodos en los que se basa (Booch, OMT

y OOSE) tienen mucha reputacin. An as, UML no es un estndar oficial aunque es

ampliamente utilizado.

Un modelo UML est compuesto por tres clases de bloques:

Elementos: son abstracciones de objetos reales o ficticios (objetos, acciones, etc.)

Relaciones: indican la interaccin entre elementos.


23 | P g i n a

Diagramas: colecciones de elementos con sus relaciones.

Diagramas UML

UML est formado por una serie de elementos grficos que se combinan para generar

diagramas. El lenguaje cuenta con una serie de reglas y mtodos de combinacin de elementos

UML para formar diagramas de diferentes tipos.

Un diagrama es la representacin grfica de un conjunto de elementos con sus relaciones.

UML ofrece una serie de diagramas para visualizar el sistema desde varias perspectivas. El

objetivo de los diagramas es ofrecer diversas perspectivas de un sistema, ayudando a definir

un esbozo de lo que sera un sistema de informacin.

Ilustracin 7: Estructura de Diagramas UML

La Ilustracin 7 muestra la estructura jerrquica de los diagramas en UML. Vemos que los

diagramas se estructuran en dos grandes bloques: Structure Diagram y Behavior Diagram.

Structure Diagram

Estos diagramas muestran la estructura esttica de los objetos en un sistema.

Representan los elementos de una especificacin con independencia del tiempo. Los

elementos de estos diagramas muestran conceptos significativos de una aplicacin, y puede

incluir conceptos abstractos, de implementacin o del mundo real[9 pg. 684].

A continuacin se detallan los diagramas tpicos que componen Structure Diagram:

Diagrama de Clases: muestra un conjunto de clases, interfaces y sus relaciones. Es

el diagrama ms comn a la hora de describir el diseo de los sistemas orientados

a objetos.

Diagramas UML Plug-in Verbalize

24 | P g i n a

Diagrama de Colaboracin: ilustran las interacciones entre objetos en un formato

de grafo o red, en el cual los objetos se pueden colocar en cualquier lugar del

diagrama.

Diagrama de Objetos: es un diagrama de clases en el que se muestran instancias

especficas de clases en un momento concreto.

Diagrama de Componentes: muestra cmo un sistema software est dividido en

componentes y las dependencias entre ellos.

Diagrama de Distribucin: muestra la arquitectura fsica de un sistema

informtico.

Behavior Diagram

Estos diagramas muestran el comportamiento dinmico de los objetos en un sistema,

incluyendo mtodos, colaboraciones, actividades y estados. El comportamiento dinmico de

un sistema se puede describir como la serie de cambios del sistema a lo largo del tiempo[9

pg. 684].

A continuacin se detallan los diagramas tpicos que componen Structure Diagram:

Diagrama de Casos de Uso: representa los casos de uso que tiene un sistema. Es

una descripcin de las acciones de un sistema desde el punto de vista del usuario.

Utilizando este diagrama, los desarrolladores del sistema pueden obtener los

requisitos desde el punto de vista del usuario. En la seccin 8.1 veremos un

ejemplo de este diagrama.

Diagrama de Secuencia: muestra la interaccin de los objetos que componen un

sistema de forma temporal.

Diagrama de Estados: representa los eventos y estados de un objeto, y el

comportamiento de un objeto como reaccin a un evento.

Diagrama de Actividad: representa los flujos de trabajo de negocio y

operacionales de los componentes de un sistema.

UML cubre todo el entorno de diseo de un sistema, no solo la modelizacin de datos.

Para ver una anlisis completo de UML se puede consultar [10].


25 | P g i n a

El diagrama UML que se centra en la modelizacin de datos es el Esquema Conceptual y,

por lo tanto, es el que entra dentro del contexto del proyecto. Tambin daremos una breve

introduccin de los diagramas de Estados, ya que los estados entran dentro del contexto de

nuestro proyecto. Seguidamente se explica con ms detalle estos diagramas y los elementos

que lo componen.

Esquema Conceptual

Los esquemas conceptuales nos permiten tener una representacin esttica de una parte

del mundo real, para solucionar el problema. Cualquier objeto del mundo real se puede

clasificar en una categora, que llamaremos clases. Estos objetos del mundo real tienen una

serie de caractersticas, llamados atributos, y se relacionan con otros objetos del mundo real,

esta relacin se conoce como asociaciones.

A continuacin veremos los elementos que intervienen en un esquema conceptual y que

son relevantes en el contexto del proyecto.

CLASES

Una clase representa una serie de objetos que comparten las mismas caractersticas,

invariantes y semntica. Sus caractersticas son los atributos y las operaciones. El propsito de

las clases es especificar la clasificacin y los rasgos que caracterizan la estructura y el

comportamiento de los objetos. Los objetos de una clase deben contener valores para cada

atributo de la clase. Las operaciones de una clase se pueden invocar en un objeto, pudiendo

provocar cambios en los atributos del objeto[9 pgs. 49-52].

Ilustracin 8: Ejemplo de Clase

La Ilustracin 8 muestra la representacin en UML de una clase. Consiste en un

rectngulo con tres divisiones. La superior contiene el nombre de la clase, en la central se

indican los atributos y en la inferior las operaciones. Los atributos, en UML, tienen que tener

siempre un nombre y, opcionalmente, pueden indicar su tipo, el valor inicial y otras

propiedades.

Esquema Conceptual Plug-in Verbalize

26 | P g i n a

RELACIONES

Las clases de un esquema conceptual se pueden relacionar de diferentes maneras.

Dependiendo de la cardinalidad de la relacin hay tres tipos de relaciones:

o 1 a 1: un elemento de una clase se relaciona, como mximo, con un elemento de otra

clase.

o 1 a n: un elemento de una clase se relaciona con n elementos de otra clase.

o m a n: un elemento de una clase se relaciona con n elementos de la otra clase. A su

vez, la otra clase se relaciona con m elementos de la primera clase.

Dependiendo del tipo de la relacin, se pueden clasificar en cuatro tipos:

Asociacin

Una asociacin especifica una relacin semntica que puede ocurrir entre instancias.

Tiene al menos dos extremos, representados como atributos, y cada uno est relacionado con

el tipo del extremo. Una asociacin declara que puede haber enlaces entre instancias de las

entidades asociadas. En una asociacin binaria, un tringulo al lado del nombre (o en lugar del

nombre) apuntando a un extremo indica que la asociacin debe ser leda en esa direccin, es

decir, se asocia el extremo que no apunta el tringulo con el extremo apuntado por el

tringulo[9 pg. 39].

Ilustracin 9: Ejemplo de Asociacin

La Ilustracin 9 muestra la representacin UML de una asociacin. Tenemos los dos

conceptos Departament y Employee. Entre ellos existe una relacin, llamada WorksIn, que nos

indica el hecho de que un Employee trabaja en un Departament. La asociacin tiene un

nombre y, adems, se puede especificar el rol y la multiplicidad de los participantes en esa

relacin.

Agregacin

Una agregacin es una asociacin ms especfica. Es una asociacin usada para modelar

relaciones parte-todo entre objetos. El todo se llama compuesto y las partes

componentes. Las agregaciones tienen que ser asociaciones binarias y las cadenas de

agregaciones, entre instancias de objetos, no pueden formar ciclos[11].


27 | P g i n a

Ilustracin 10: Ejemplo de Agregacin

La Ilustracin 10 muestra la representacin UML de la agregacin. Es parecida a la

representacin de una asociacin, a excepcin que se dibuja un rombo sin relleno en el

extremo de la clase contenedora. En el ejemplo vemos que un Departament usa unas

Database. Si eliminamos el Departament no tiene sentido eliminar las Database ya que

pueden ser utilizadas por otros departamentos, o reasignarse.

Composicin

Una composicin es una agregacin fuerte que requiere que la instancia est incluida en

el compuesto, de tal manera que si el compuesto es eliminado, todas las instancias que forman

parte del compuesto, tambin son eliminadas[9 pg. 39].

Es un tipo especial de asociacin que indica una relacin entre el todo y sus partes. El

tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye.

Existe una relacin de dependencia crear-borrar de la parte respecto del todo. Si un elemento

forma parte de un todo y el todo se elimina entonces el elemento tambin se tiene que

eliminar. En la composicin, la multiplicidad del compuesto tiene que ser como mximo 1.

Ilustracin 11: Ejemplo de Composicin

La Ilustracin 11 muestra la representacin UML de la composicin. Es idntica a la de la

asociacin, con la excepcin de que se dibuja un rombo con relleno en el extremo de la clase

contenedora. Suponemos que tenemos dos clases, Company y Department. Una Empresa est

compuesta por Departamentos. La relacin de estas dos clases es de composicin ya que si

eliminamos la empresa, no tiene sentido mantener los departamentos asociados a esa

empresa.


28 | P g i n a

Generalizacin

Una generalizacin es una relacin taxonmica entre una clase ms general y una clase

ms especfica. Cada instancia de la clase especfica es tambin una instancia indirecta de la

clase general. Por lo tanto, la clase especfica hereda las caractersticas de la clase general[9

pg. 71].

Ilustracin 12: Ejemplo de Generalizacin

La Ilustracin 12 muestra la representacin UML de la generalizacin. Es parecida a la de

la asociacin, con la excepcin de que se dibuja un triangulo sin relleno en la clase que acta

de clase general. Vemos la generalizacin que existe entre Employee y sus dos herederos,

Salesman y Engineer. Salesman tiene un atributo propio llamado assignment, pero tambin

tiene las caractersticas de la clase Employee.

TIPOS DE DATOS (DATA TYPES)

Los tipos de datos son elementos del modelo que definen valores de datos. Normalmente,

se utilizan para representar tipos primitivos (boolean, integer, string, etc), enumeraciones y

tipos de datos definidos por el usuario. Un Tipo de Dato es similar a una clase, a excepcin de

que las instancias de un Tipo de Dato se identifican por su valor, es decir, si dos tipos de datos

tienen el mismo valor se consideran idnticos. Pueden contener atributos que apoyen la

modelizacin del tipo de dato [9 pg. 61]. Un tipo de dato no se puede relacionar con las clases

del diagrama, en cambio, las clases s que pueden relacionarse con ellos.

Ilustracin 13: Ejemplo de Data Type


29 | P g i n a

La Ilustracin 13 muestra la representacin UML de un tipo de dato. Es idntica a la de las

clases, a excepcin de que se indica en la cabecera que es un tipo de dato incluyendo

.

CLASES ASOCIATIVAS

Una clase asociativa es una declaracin de una relacin semntica entre clases, que tiene

un conjunto de caractersticas propias[9 pg. 46].

Una clase asociativa es una clase creada de una asociacin. Se usa una clase asociativa

cuando una asociacin no es suficiente para definir la relacin y se necesita la inclusin de

atributos u operaciones.

Ilustracin 14: Ejemplo de Clase Asociativa

La Ilustracin 14 muestra la representacin UML de una clase asociativa. Vemos que

tenemos los conceptos Man y Woman. La relacin Marriage entre ellos necesita guardar cierta

informacin, como por ejemplo el da y el mes de la boda, adems puede ser interesante

relacionarla con otros conceptos como Church o Priest. Por este motivo se crea la clase

asociativa Marriage entre Man y Woman.

ENUMERACIONES

Una enumeracin es un DataType cuyos valores se enumeran en el modelo como

literales. Sus instancias pueden ser cualquier combinacin de literales definidos por el

usuario[9 pg. 67].


30 | P g i n a

Ilustracin 15: Ejemplo de Enumeracin

La Ilustracin 15 muestra la representacin UML de una enumeracin. La representacin

es parecida a la de las clases, a excepcin de que se indica en la cabecera que es un

enumeracin incluyendo .

Estos elementos son los que se pueden visualizar en un diagrama de clases. Aun as,

existen ms elementos que intervienen en un diagrama de clases aunque no sean visibles. A

continuacin procedemos a explicarlos dado que pertenecen al contexto del proyecto.

Restricciones: es una restriccin o una condicin, expresada en lenguaje natural o

en un lenguaje mquina entendible, que sirve para representar informacin

semntica al elemento que la contiene[9 pg. 58].

Las restricciones pueden ser Invariantes, Precondiciones o Post-condiciones:

o Precondiciones: es una condicin que se tiene que satisfacer cuando el evento

o la operacin, a la que est vinculada, es invocada.

o Post-condiciones: es una condicin que el sistema tiene que satisfacer

despus de que el evento o la operacin, a la que est vinculada, haya

sucedido o ejecutado.

o Invariantes: es una condicin sobre una clase que debe cumplirse siempre

durante el ciclo de vida de la clase.

context Department inv hasSeniorEmployees:

self.employee->forAll(e |e.age>=18)

El invariante anterior est escrito en lenguaje OCL2. Especifica que un

departamento no puede tener empleados menores de 18 aos.

context Employee::AssignDepartment(Department: department)

post AnAssociationBetweenEmployeeAndDepartmentHasBeenCreated:

self.employer = department

La post-condicin anterior especifica que, despus de ejecutarse la operacin, se crea la asociacin entre empleado y departamento.

2 Object Constraint Language. Es un lenguaje que sirve para describir formalmente expresiones en los

modelos UML.


31 | P g i n a

Operaciones de Sistema: una operacin es una caracterstica de comportamiento de un clasificador que especifica el nombre, el tipo, los parmetros, y las restricciones para invocar un comportamiento asociado. Una operacin es invocada en la instancia del clasificador para el que la operacin es una caracterstica. Las precondiciones de una operacin definen condiciones que tienen que ser ciertas antes de que la operacin se invoque. Las post-condiciones de una operacin definen las condiciones que sern ciertas despus de que la operacin haya finalizado con xito. Una operacin puede provocar excepciones. Cuando se produce una excepcin, no podemos asumir que las post-condiciones de la operacin se satisfagan[9 pgs. 103-106].

Diagrama de Estados

Un diagrama de estados UML representa los eventos y estados de un objeto, y el

comportamiento de un objeto como reaccin a un evento. Las transiciones se representan con

flechas, etiquetadas con sus eventos. El diagrama de estados muestra el ciclo de vida de un

objeto: qu eventos experimenta, sus transiciones y los estados en los que se encuentra entre

los eventos.

Ilustracin 16: Diagrama de Estados

En la Ilustracin 16 vemos un ejemplo de un diagrama de estados. Este diagrama muestra

los eventos y los estados asociados al objeto Telephone. El estado inicial de Telephone es Idle.

Cuando se recibe el evento NewPhoneCall el objeto Telephone pasa al estado Ringing. Una vez

se haya cogido el telfono, es decir el evento PickUp ocurra, se pasa al estado Answered.

Finalmente cuando se cuelgue el telfono, el evento HangUp suceda, el telfono retorna al

estado Idle.

Metamodelo UML Plug-in Verbalize

32 | P g i n a

Hemos visto un ejemplo sencillo que ilustra la utilidad de un diagrama de estados. En los

diagramas de estados intervienen tres componentes:

Estados: un estado representa una situacin en la cual alguna condicin no vara.

Esta condicin puede representar una condicin esttica, como un objeto

esperando a que un evento externo ocurra[9 pg. 548].

Eventos: un evento es la especificacin de algn acontecimiento que

potencialmente puede desencadenar algn efecto a un objeto. Un evento

describe un conjunto de sucesos posibles. Un suceso es algo que sucede que tiene

cierta importancia dentro del sistema [9 pgs. 13, 440]. UML ofrece esta

extensin para poder representar los eventos de un Esquema Conceptual.

Transiciones: es la relacin entre dos estados que indica que cuando tiene lugar

un evento, el objeto pasa del estado anterior al estado siguiente [6 pg. 408].

Metamodelo UML

En la seccin anterior hemos visto los elementos que intervienen en un diagrama de

clases. En esta seccin introduciremos el concepto de metamodelo y explicaremos, con una

serie de ejemplos, el conjunto de elementos del metamodelo UML que intervienen en el

mbito del proyecto.

Ilustracin 17: Ejemplo de Esquema Conceptual

En la Ilustracin 17 vemos un ejemplo de un esquema conceptual y asociaremos las clases

del metamodelo con las instanciaciones de sus elementos en el esquema conceptual. En este

apartado no se pretende explicar en detalle la estructura completa del metamodelo, sino que

se pretende dar una idea de cmo UML representa el modelo. Se incluyen, en la explicacin,

solamente los elementos ms comunes a la hora de trabajar con esquemas conceptuales. Para

ver la especificacin completa del metamodelo UML se puede consultar[9].

El Esquema Conceptual de la Ilustracin 17 nos muestra un dominio relacionado con

Empleados (Employee) y Departamentos (Department). Los empleados tienen una serie de


33 | P g i n a

caractersticas y pueden ser de dos tipos, Ingenieros (Engineer) o Vendedores (Salesman),

dependiendo del rol que desempean en la empresa. El dominio tambin muestra el hecho de

que los empleados trabajan en Departamentos concretos.

Vemos que el esquema conceptual trabaja con cuatro conceptos. Tenemos los conceptos

Employee, Department, Salesman y Engineer. A los conceptos los llamamos Clases y UML los

representa como Class.

Cada concepto contiene una serie de caractersticas que son compartidas por todos los

objetos que pertenezcan al concepto. Por ejemplo, todo empleado tiene como caractersticas

name y age. A las caractersticas las llamamos atributos y UML las representa como Property.

A parte de las caractersticas, los conceptos se pueden relacionar entre ellos. Vemos que

los conceptos Employee y Department se relacionan para indicar el hecho de que un empleado

trabaja en un departamento concreto. La relacin WorksIn nos proporciona esa informacin ya

que relaciona los dos conceptos. Las relaciones las llamamos asociaciones y UML las

representa como Association.

Los elementos con los que representa UML (Class, Property, Association,etc.) un Esquema

Conceptual son los elementos que componen el metamodelo de UML.

En la Ilustracin 18 podemos ver el conjunto de elementos del metamodelo que

intervienen en la instanciacin de las clases, atributos y asociaciones.

Ilustracin 18: Clases, atributos, operaciones y asociaciones

La metaclass Class hace referencia a las clases de los esquemas conceptuales. Vemos que

Class se relaciona con Property y Operation. Property es la metaclass de los atributos y los

roles de las asociaciones. Operation son las operaciones que tienen las clases. La clase

Association es el molde de las asociaciones. Vemos que existe una relacin entre Property y

Metamodelo UML Plug-in Verbalize

34 | P g i n a

Association con multiplicidad en Property de como mnimo dos, que guarda la informacin

sobre los atributos identificados como roles de las asociaciones (member ends). La

multiplicidad mnima es 2 ya que una asociacin tiene que tener, como mnimo, dos roles.

Las clases Department y Employee son instancias de la metaclass Class. De forma anloga,

el atributo name es una instancia de Property.

Para representar los tipos de datos se utiliza el conjunto de metaclasses mostrado en la

Ilustracin 19 .

Ilustracin 19: Tipos de Datos

Los tipos de datos estn representados por la metaclass DataType. Esta metaclass hace

referencia a los tipos bsicos (boolean, string,), representados por PrimitiveType, a las

enumeraciones, representadas por Enumeration, y a los tipos de datos definidos por el

usuario. Vemos que, como las clases, se relaciona con Property y Operation.

El tipo de dato Date es una instancia de DataType y sus atributos son instancias de

Property. Adems, todos los datos bsicos del esquema son instancias de PrimitiveType.

Un metamodelo es un modelo que sirve para definir un lenguaje. En este caso, UML es un

lenguaje que sirve para especificar modelos. Por lo tanto, el metamodelo UML es un modelo

que describe el lenguaje UML, en otras palabras, sirve para describir los elementos que van a

componer los diagramas que queramos disear. Por ejemplo, cuando creamos el objeto

Departament en un esquema conceptual estamos creando una instancia de la metaclass Class;

es decir, estamos usando Class como un molde para producir un concepto propio (en el

ejemplo, Departament) con caractersticas propias. De forma similar, si a Departament le

aadimos la propiedad name, en realidad estamos instanciando la metaclass Property.

La Ilustracin 18 y la Ilustracin 19 han sido extradas de la especificacin del lenguaje

UML [9 pgs. 31-33].

Guas de Nominacin Plug-in Verbalize

35 | P g i n a

4. Guas de Nominacin

En este captulo explicaremos las guas de nominacin que se encargan de comprobar si

los nombres de los elementos UML de un esquema conceptual son correctos o no. Para una

correcta comprensin de este captulo, es de suma importancia entender el metamodelo UML

explicado en la seccin anterior, ya que en este captulo haremos referencia a los elementos

del metamodelo.

Las guas de nominacin son una serie de normas que se tienen que aplicar a la hora de

dar nombres a los elementos de un esquema conceptual.

En este captulo detallaremos las guas de nominacin utilizadas en el mbito del

proyecto. Para cada elemento UML, que interviene en el contexto del proyecto, indicaremos

las reglas de la gua asociada. Cada gua de nominacin se compone de dos reglas:

Regla Sintctica: Esta regla indica la forma sintctica que tiene que cumplir el

nombre del elemento.

Regla Semntica: Esta regla ofrece una frase patrn para generar la verbalizacin

con el nombre del elemento.

Para facilitar la comprensin de las guas se ha utilizado una nomenclatura para abreviar

ciertas funcionalidades. A continuacin procedemos a explicar estas funciones:

Lower(E): esta funcin se encarga de, dado un nombre, escribir el nombre

separado y en minscula.

Lower(isCooking) =is cooking

Plural(E): esta funcin se encarga de, dado un sintagma nominal, convertir el

ncleo del sintagma nominal en plural.

Plural(Car) = Cars

Plural(PathForWheeledVehicles) = PathsForWheeledVehicles

WithOrNeg(E): esta funcin se encarga de, dado un nombre que contiene un

verbo, extender el nombre con la insercin de la forma negativa del verbo.

WithOrNeg(isAbstract)=is or is not abstract

Expanded(E): esta funcin se encarga de sustituir *a|an] (Ei) para cada rol pi.

Esta seccin es un resumen de los aspectos ms importantes del documento [5], en el

cual se han generado las guas de nominacin de los elementos UML a partir de la literatura

existente.

Entidades Plug-in Verbalize

36 | P g i n a

A continuacin veremos, para cada elemento UML que interviene en el proyecto, las

reglas que tienen que cumplir sus nombres.

4.1. Entidades

La gua de nominacin de las entidades engloba a clases, clases asociativas,

enumeraciones y tipos de datos.

4.1.1. Regla Sintctica

El nombre de una entidad debe ser un sintagma nominal cuyo ncleo debe ser contable

y singular. Debe estar escrito en forma Pascal3.

Nombres Correctos: Plane, Car, PathForWheeledVehicles

Nombres Incorrectos: Planes, MakeASearch, car

La regla establece que el ncleo del sintagma nominal tiene que ser un nombre contable y

singular. Es decir, nombres como Agua u Oro son invlidos, ya que son incontables. Las

instancias de estos conceptos son porciones.

4.1.2. Regla Semntica

Si N es el nombre de la entidad entonces la siguiente frase tiene que ser gramaticalmente

correcta:

An instance of the entity type named N is [a|an] lower(N).

Para la clase PathForWheeledVehicles la frase generada seria:

An instance of the entity type named PathForWheeledVehicles is a path for wheeled

vehicles.

que es gramaticalmente correcta.

3 Prctica de escribir nombres compuestos o frases cuyas palabras estn unidas sin espacios y la primera

letra de cada palabra es mayscula.


37 | P g i n a

4.2. Atributos

Para esta gua de nominacin se han diferenciado los atributos booleanos de los no-

booleanos

Sea E::A:T [min..max] una atributo llamado A de tipo T de un tipo de entidad E y las

multiplicidades mnima y mxima del atributo son min y max.


Para Atributos No Booleanos

El nombre del atributo debe ser un sintagma nominal cuyo ncleo sea contable y

singular, y debe estar escrito en forma Camel4.

Nombres Correctos: name, surname

Nombres Incorrectos: Name, surnames

Atributos Booleanos

El nombre del atributo debe ser un sintagma verbal en tercera persona del singular,

escrito en forma Camel.

Nombres Correctos: isMarried, isYoung

Nombres Incorrectos: areHandsome, IsOld

4 Prctica de escribir nombres compuestos o frases cuyas palabras estn unidas sin espacios y la primera

letra de cada palabra es mayscula, exceptuando la primera.

Atributos Plug-in Verbalize

38 | P g i n a


Para Atributos No Booleanos

Siendo E el nombre del contenedor del atributo, una de las siguientes frases tiene que

tener sentido semntico:

If min= 0 and max= 1:

[A|An] lower (E) may have [a|an] lower (A).

If min= 0 and max> 1:

[A|An] lower (E) may have zero or more lower (plural(A)).

If min=max= 1:

[A|An] lower (E) has [a|an] lower (A).

If min> 0 and max> 1:

[A|An] lower (E) has one or more lower (plural(A)).

Vemos que las frases generadas dependen de las multiplicidades de los atributos. Esto es

debido a que dependiendo de la multiplicidad, la informacin del esquema conceptual cambia.

Cuando tratamos un atributo debemos conocer el elemento al que pertenece para

modificar las frases patrn. En caso de pertenecer a un Evento, se aade la palabra event

antes del nombre del evento. De forma anloga, cuando estamos tratando un parmetro, que

se evala como un atributo de la operacin, se aade la palabra operation antes del nombre

de la operacin.

Para el atributo Person::name:String[1] la frase seria:

A person has a name.


Atributos Booleanos

Si el atributo es booleano, entonces asumimos que la multiplicidad mnima es 0 o 1, y la

mxima es 1.

Siendo E el nombre del contenedor del atributo, la siguiente frase tiene sentido

semntico:

[A|An] lower(E) lower(withOrNeg(A)) [, or it may be unknown]


39 | P g i n a

Para el atributo Class::isAbstract:Boolean[1] la frase seria:

A class is or is not abstract.

4.3. Asociaciones

Sea R(p1:E1 [min1,max1], p2:E2 [min2,max2]) una asociacin binaria entre dos entidades

llamadas E1 y E2, que actan como roles p1 y p2, con multiplicidades [min1,max1] y [min2,max2]

respectivamente.

Las agregaciones y composiciones tienen nombres predefinidos y no necesitan que se les

ponga nombre. En cambio, las asociaciones no tienen nombre implcito.

Sea Rn(p1:E1,...,pn:En) una asociacin n-aria, donde n>2, entre las entidades llamadas

E1,,En, cuyos roles son p1,,pn respectivamente. Hay n+1 nombre explcitos asociados a esta

asociacin: el nombre de la asociacin y los n nombres de los roles.

Los nombres de los roles siempre tienen un nombre implcito que se usa en caso de no

existir un nombre explcito. El nombre implcito de los roles es el nombre del tipo de entidad,

al que pertenece, escrito en minscula.

En una asociacin, cuando Ei=Ej entonces pi, o pj, o los dos roles tienen que tener un

nombre explcito.


Asociaciones Binarias

El nombre de la asociacin debe ser un sintagma verbal en tercera persona del singular,

escrito en forma Pascal.

Nombres Correctos: Publishes, Writes

Nombres Incorrectos: publishes, Write

Distinguimos dos tipos de nombres de roles explcitos: los externos y los internos. Los

externos deben seguir la gua de nominacin de los atributos. Los internos son utilizados con

fines tcnicos y no necesitan ser tratados. Los internos se tienen que diferenciar utilizando un

prefijo especial, como por el ejemplo underscore (_).

Los roles pueden ser vistos como atributos no booleanos de la entidad situada en el otro

extremo de la asociacin. Por este motivo, utilizamos la gua de nominacin de los atributos no

booleanos para tratar los roles de las asociaciones.

Asociaciones Plug-in Verbalize

40 | P g i n a

Asociaciones N-Arias

El nombre de la asociacin debe ser un sintagma verbal en tercera persona del singular,

escrito en forma Pascal. El nombre debe incluir n-1 sub-cadenas de texto con la forma ,

donde pi es el nombre de los roles. Los roles deben estar escritos en forma Camel.

Nombres Correctos: SuppliesTo


Asociaciones Binarias

Una de las siguientes frases tiene que tener sentido semntico:

If min2 = 0 and max2 = 1:

[A|An] lower (E1) lower (R) at most one lower (E2).

If min2 = 1 and max2 = 1:

[A|An] lower (E1) lower (R) [a|an] lower (E2).

If min2 = 0 and max2 = *:

[A|An] lower (E1) lower (R) zero or more lower (plural(E2)).

If min2 = 1 and max2 = *:

[A|An] lower (E1) lower (R) one or more lower (plural(E2)).

Para la asociacin Publishes(editor:Editor[1],paper:Paper[0..*]) la frase seria:

An editor publishes zero or more papers.


Asociaciones N-Arias

La siguiente frase tiene sentido semntico:

[A|An] lower(E1) lower(Expanded(R))

Para la asociacin SuppliesTogenera:

A vendor supplies a product to a project.



41 | P g i n a

4.4. Invariantes

Un invariante es una restriccin esttica vinculada a un tipo entidad. La restriccin puede

estar definida como una expresin OCL el contexto de la cual es el tipo de entidad. Los

invariantes pueden tener nombre, por ejemplo:

context Department inv hasSeniorEmployees:

self.employee->forAll(e |e.age>=18)

es un invariante llamado hasSeniorEmployees.


El nombre de un invariante debe ser un sintagma verbal en tercera persona del singular,

escrito en forma Camel o, si no utiliza ninguna palabra que pueda genera ambigedad,

escrita en forma normal.

Nombres Correctos: isIdentifiedByHisName, has enough employees


Sea I el nombre del invariante y E el contexto, la siguiente frase tiene sentido semntico:

[A|An] lower(E) lower(I)

Para el invariante anterior con nombre hasSeniorEmployees la frase seria:

A department has senior employees.


Eventos Plug-in Verbalize

42 | P g i n a

4.5. Tipos de Eventos y Operaciones del Sistema

Los elementos que vienen a continuacin se centran en la parte de comportamiento de

los esquemas conceptuales.

4.5.1. Eventos

Los tipos evento tienen caractersticas, que son la lista de atributos y asociaciones en los

que participa. Los atributos de un evento son similares a los atributos de una entidad, y

pueden ser tratados con la gua de nominacin de los atributos detallada en la seccin 4.2. De

la misma manera, las asociaciones de un evento pueden seguir la gua de nominacin de las

asociaciones explicada en la seccin 4.3.

Regla Sintctica

El nombre de un tipo de evento debe ser un sintagma nominal cuyo ncleo debe ser

contable y singular, escrito en forma Pascal.

Nombres Correctos: NewSale, EndOfSale

Regla Semntica

Si Ev es el nombre del evento entonces la siguiente frase tiene que ser gramaticalmente

correcta:

An instance of the event type named Ev is [a|an] lower(Ev) event.

Para el evento llamado NewSale la frase seria:

An instance of the event type named NewSale is a new sale event.


4.5.2. Operaciones

Las operaciones tienen parmetros. Los parmetros son parecidos a los atributos de una

entidad y se pueden tratar con la gua de nominacin descrita en la seccin 4.2.


43 | P g i n a

Regla Sintctica

El nombre de una operacin de sistema

73999

Documents