Centro Nacional de Investigación y Desarrollo … · Resumen Este trabajo de investigación...

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Definición de Elementos de Transformación entre Diagramas de Casos de Uso y Clases del UML

presentada por

Adán Hernández Estrada Ing. en Sistemas Computacionales por el I. T. de Cuautla

como requisito para la obtención del grado de:

Maestro en Ciencias en Ciencias de la Computación

Director de tesis: Dr. Máximo López Sánchez

Jurado:

Dr. René Santaolaya Salgado – Presidente MC. Olivia G. Fragoso Díaz – Secretario

MC. Mario Guillén Rodríguez – Vocal Dr. Máximo López Sánchez – Vocal Suplente

Cuernavaca, Morelos, México. 14 de Enero de 2011

Resumen

Este trabajo de investigación propone una solución a la transformación entre los diagramas de casos de uso y los diagramas de clases del UML, basado en la identificación de elementos en los diagramas de casos de uso que tienen consecuencia en los diagramas de clases. Logrando comprobar que es posible identificar elementos (clases, métodos, atributos y/o relaciones) de los diagramas de clases desde los requerimientos funcionales especificados en los diagramas de casos de uso. Esto con la finalidad de evitar incongruencias o incompatibilidades entre el diagrama de clases y los requerimientos del usuario.

Actualmente existen modelos que identifican clases a partir de los escenarios de casos de uso, sin embargo, pueden ser ineficientes cuando los casos de uso son

descritos con muchos escenarios con diferentes palabras. Debido a esta situación, la meta principal de este trabajo es identificar características en común entre los elementos de los diagramas de casos de uso y los elementos de los diagramas de clases.

Para cumplir tal meta se realizó una serie de análisis a los metamodelos de los diagramas de casos de uso y diagramas de clases con la finalidad de conocer con mayor profundidad la estructura y características de los elementos que los integran. Al resultado de este análisis se le aplicó la metodología de análisis de dominio orientado a características (por sus siglas en inglés FODA) para realizar la caracterización de los elementos, en donde dicha caracterización fue utilizada como base para descubrir relaciones semánticas entre elementos, con lo cual se logró crear métodos de transformación entre los diagramas de casos de uso y diagramas de clases.

Abstract

This research work proposes a solution to transformation between elements of use case diagrams and elements of class diagrams based on the identification of elements in use case diagrams that has a result in the class diagrams, achieving with it verify that is possible to identify elements (classes, methods, attributes and/or relationships) of class diagrams from the functional requirements specified in the use case diagrams. It with the purpose of to avoid inconsistencies or incompatibilities between the class diagram and user requirements.

Currently there are models that identify classes from use case descriptions; however this can be inefficient when the use cases are described with many scenarios and different words. Due to this situation, the main goal of this research work is to identify common features in the elements of use case diagrams and elements of class diagrams.

To fulfill the afore mentioned goal, several analysis were done to metamodels of use case diagrams and class diagrams with the purpose of knowing the structure and features of each element that compose them. A Feature-Oriented Domain Analysis (FODA) was applied to the result of this analysis to perform of the characterization of the elements, in which characterization was used as the basis to find semantic relationships among the elements. With which it was achieved the creation of the methods of transformation between the use case diagrams and class diagrams.

i

Tabla de contenido

TABLA DE CONTENIDO ....................................................................................................................................... I

LISTA DE FIGURAS ............................................................................................................................................. V

LISTA DE TABLAS .............................................................................................................................................. VI

GLOSARIO DE TÉRMINOS Y SIGLAS ................................................................................................................. VII

INTRODUCCIÓN ................................................................................................................................................ 1

ORGANIZACIÓN DEL DOCUMENTO ................................................................................................................................ 2

CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN ............................................................................................ 3

1.1 PLANTEAMIENTO DEL PROBLEMA ............................................................................................................................ 3 1.2 OBJETIVO .......................................................................................................................................................... 4 1.3 JUSTIFICACIÓN Y BENEFICIOS .................................................................................................................................. 4 1.4 TRABAJOS RELACIONADOS ..................................................................................................................................... 5

1.4.1 From Use Cases to UML Class Diagrams using Logic Grammars and Constraints [HCKT07]. ................. 5 1.4.2 Relaciones entre Casos de Uso en el Unified Modeling Language [SGFP00]. ......................................... 5 1.4.3 Generating OCL Specifications and Class diagrams from Use Cases: A Newtonian Approach [BORO03]. ......................................................................................................................................................................... 6 1.4.4 Events in Use Cases as a Basis for Identifying and Specifying Classes and Business Rules [CCPO99]. .... 6 1.4.5 From use cases to classes: a way of building object model with UML [LIAY03]. .................................... 7 1.4.6 Comparativa trabajos relacionados ........................................................................................................ 7

1.5 ALCANCES Y LIMITACIONES .................................................................................................................................... 9

CAPÍTULO 2. MARCO TEÓRICO .........................................................................................................................11

2.1 ANÁLISIS DE DOMINIO ........................................................................................................................................ 11 2.2 ANÁLISIS FODA ................................................................................................................................................ 12 2.3 METAMODELO ................................................................................................................................................. 12 2. 4 DIAGRAMAS DE CASOS DE USO ............................................................................................................................ 12 2.5 DIAGRAMAS DE CLASES. ...................................................................................................................................... 13 2.6 TRANSFORMACIÓN ............................................................................................................................................ 13 2.7 LENGUAJE Z ..................................................................................................................................................... 13

CAPÍTULO 3. MÉTODO DE SOLUCIÓN ...............................................................................................................15

3.1 ANÁLISIS DE LOS METAMODELOS DEL UML ............................................................................................................ 17 3.1.1 Diagrama de casos de uso .................................................................................................................... 17

3.1.1.1 Descripción de conceptos ................................................................................................................................ 17 3.1.1.1.1 Actor ........................................................................................................................................................ 17

3.1.1.1.1.1 Descripción....................................................................................................................................... 17 3.1.1.1.1.2 Restricciones .................................................................................................................................... 17 3.1.1.1.1.3 Semántica......................................................................................................................................... 18 3.1.1.1.1.4 Notación ........................................................................................................................................... 18

3.1.1.1.2 Caso de uso .............................................................................................................................................. 18 3.1.1.1.2.1 Descripción....................................................................................................................................... 18 3.1.1.1.2.2 Restricciones .................................................................................................................................... 18 3.1.1.1.2.3 Semántica......................................................................................................................................... 19 3.1.1.1.2.4 Notación ........................................................................................................................................... 19

3.1.1.1.3 Extend ...................................................................................................................................................... 19 3.1.1.1.3.1 Descripción....................................................................................................................................... 19 3.1.1.1.3.2 Restricciones .................................................................................................................................... 19 3.1.1.1.3.3 Semántica......................................................................................................................................... 19 3.1.1.1.3.4 Notación ........................................................................................................................................... 20

ii

3.1.1.1.3.5 Ejemplo ........................................................................................................................................... 20 3.1.1.1.3.6 Justificación ..................................................................................................................................... 20

3.1.1.1.4 Include ..................................................................................................................................................... 20 3.1.1.1.4.1 Descripción ...................................................................................................................................... 20 3.1.1.1.4.2 Semántica ........................................................................................................................................ 21 3.1.1.1.4.3 Notación .......................................................................................................................................... 21 3.1.1.1.4.4 Ejemplo ........................................................................................................................................... 21

3.1.1.1.5 Nodos gráficos ........................................................................................................................................ 21 3.1.2 Diagrama de clases .............................................................................................................................. 22

3.1.2.1 Descripción de conceptos ............................................................................................................................... 22 3.1.2.1.1 Clases ...................................................................................................................................................... 22

3.1.2.1.1.1 Descripción ...................................................................................................................................... 22 3.1.2.1.1.2 Semántica ........................................................................................................................................ 23 3.1.2.1.1.3 Notación .......................................................................................................................................... 23

3.1.2.1.2 Dependencia ........................................................................................................................................... 24 3.1.2.1.2.1 Semántica ........................................................................................................................................ 24 3.1.2.1.2.2 Notación .......................................................................................................................................... 24

3.1.2.1.3 Asociación ............................................................................................................................................... 24 3.1.2.1.3.1 Semántica ........................................................................................................................................ 25 3.1.2.1.3.2 Notación .......................................................................................................................................... 25

3.1.2.1.4 Generalización ........................................................................................................................................ 26 3.1.2.1.4.1 Descripción ...................................................................................................................................... 26 3.1.2.1.4.2 Semántica ........................................................................................................................................ 26 3.1.2.1.4.3 Notación .......................................................................................................................................... 26

3.1.2.1.5 Interfaz .................................................................................................................................................... 27 3.1.2.1.5.1 Descripción ...................................................................................................................................... 27 3.1.2.1.5.2 Notación .......................................................................................................................................... 27

3.1.2.1.6 Diagramas ............................................................................................................................................... 28 3.2 APLICACIÓN DEL MÉTODO FODA ......................................................................................................................... 29

3.2.1 Análisis de Contexto ............................................................................................................................. 29 3.2.1.1 UML ................................................................................................................................................................ 29 3.2.1.2 Ciclo de vida del software (UML) .................................................................................................................... 29 3.2.1.3 Diagramas de casos de uso ............................................................................................................................ 31 3.2.1.4 Diagramas de clase ......................................................................................................................................... 32

3.2.2 Modelado del Dominio ......................................................................................................................... 32 3.2.2.1 Diagrama de casos de uso. .............................................................................................................................. 33

3.2.2.1.1 Notación: ................................................................................................................................................. 33 3.2.2.1.2 Definición de la notación: ....................................................................................................................... 33 3.2.2.1.3 Diagrama de características: ................................................................................................................... 37

3.2.2.2 Diagrama de clases. ........................................................................................................................................ 40 3.2.2.2.1 Notación .................................................................................................................................................. 40 3.2.2.2.2 Definición de la notación: ....................................................................................................................... 40 3.2.2.2.3 Diagrama de características .................................................................................................................... 44

3.3 FORMALIZACIÓN ............................................................................................................................................... 50 3.3.1 Diagramas de Casos de Uso ................................................................................................................. 50

3.3.1.1 Declaraciones .................................................................................................................................................. 50 3.3.1.2 Esquema CU .................................................................................................................................................... 51

3.3.2 Diagrama de Clases .............................................................................................................................. 52 3.3.2.1 Declaraciones .................................................................................................................................................. 52 3.3.2.2 Esquema CLASE ............................................................................................................................................... 53

3.4 MECANISMO DE COMPARACIÓN .......................................................................................................................... 54 3.4.1 Comparación entre elementos ............................................................................................................. 55

3.4.1.1 Comparación entre CU, Actor, Clase, Operación y Atributo ........................................................................... 55 3.4.1.2 Comparación entre las relaciones pertenecientes a los DCU y DC. ................................................................ 58

3.4.2 Métodos de transformación ................................................................................................................. 63 3.4.2.1 Desarrollo de los métodos de transformación ................................................................................................ 63

3.4.2.1.1 Método de transformación T0: “caso de uso a clase” ............................................................................ 64

iii

3.4.2.1.2 Método de transformación T1: “relación de generalización a relación de generalización/especialización” .............................................................................................................................. 66 3.4.2.1.3 Método de transformación T2: “relación include a relación de composición” ........................................ 69

CAPÍTULO 4. PRUEBAS .....................................................................................................................................73

4.1 CONVENCIÓN DE NOMBRES ................................................................................................................................. 73 4.2 PLAN DE PRUEBAS ............................................................................................................................................. 74

a) Introducción ............................................................................................................................................... 74 b) Elementos de prueba ................................................................................................................................. 74 c) Características a probar ............................................................................................................................. 75 d) Características excluidas de las pruebas.................................................................................................... 76 e) Pruebas realizar ......................................................................................................................................... 76 f) Enfoque....................................................................................................................................................... 77 g) Criterio éxito/fracaso de casos de prueba ................................................................................................. 77 h) Criterios de suspensión y requerimientos de reanudación ........................................................................ 77 i) Tareas de pruebas....................................................................................................................................... 77 j) Liberación de pruebas ................................................................................................................................. 78 k) Responsabilidades...................................................................................................................................... 78 l) Riesgos y contingencias .............................................................................................................................. 78 m) Aprobación ............................................................................................................................................... 78

4.3 CASOS DE PRUEBA ............................................................................................................................................. 78 4.4 DESCRIPCIÓN DE LOS CASOS DE PRUEBA. ................................................................................................................ 79

4.4.1 MDT-01 Transformación de caso de uso a clase. .................................................................................. 80 a) Propósito ................................................................................................................................................................. 80 b) Entorno de prueba .................................................................................................................................................. 80 4.4.1.1 MDT-01-01 Transformación de caso de uso a clase para el sistema ATM [CBJO01]. ...................................... 80 a) Propósito ................................................................................................................................................................. 80 b) Entorno de prueba .................................................................................................................................................. 80 c) Proceso .................................................................................................................................................................... 80 d) Resultado esperado ................................................................................................................................................. 80 4.4.1.2 MDT-01-02 Transformación de caso de uso a clase para el sistema administrador de proyectos [CAFE10]. .. 81 a) Propósito ................................................................................................................................................................. 81 b) Entorno de prueba .................................................................................................................................................. 81 c) Proceso .................................................................................................................................................................... 81 d) Resultado esperado ................................................................................................................................................. 81

4.4.2 MDT-02 Transformación de relación de generalización a relación de generalización/especialización.81 a) Propósito ................................................................................................................................................................. 81 b) Entorno de prueba .................................................................................................................................................. 81 4.4.2.1 MDT-02-01 Transformación de relación de generalización a relación de generalización/especialización para el sistema ATM [CBJO01]. ............................................................................................................................................ 82 a) Propósito ................................................................................................................................................................. 82 b) Entorno de prueba .................................................................................................................................................. 82 c) Proceso .................................................................................................................................................................... 82 d) Resultado esperado ................................................................................................................................................. 82 4.4.2.2 MDT-02-02 Transformación de relación de generalización a relación de generalización/especialización para el sistema administrador de proyectos [CAFE10]. ....................................................................................................... 82 a) Propósito ................................................................................................................................................................. 82 b) Entorno de prueba .................................................................................................................................................. 83 c) Proceso .................................................................................................................................................................... 83 d) Resultado esperado ................................................................................................................................................. 83

4.4.3 Método de transformación T2: “relación include a relación de composición”. .................................... 83 a) Propósito ................................................................................................................................................................. 83 b) Entorno de prueba .................................................................................................................................................. 83 4.4.3.1 MDT-03-01 Transformación de relación include a relación de composición para el sistema ATM [CBJO01]. . 83 a) Propósito ................................................................................................................................................................. 83 b) Entorno de prueba .................................................................................................................................................. 84

iv

c) Proceso ................................................................................................................................................................... 84 d) Resultado esperado ................................................................................................................................................ 84 4.4.3.2 MDT-03-02 Transformación de relación include a relación de composición para el sistema administrador de proyectos [CAFE10]. .................................................................................................................................................... 84 a) Propósito ................................................................................................................................................................ 84 b) Entorno de prueba .................................................................................................................................................. 84 c) Proceso ................................................................................................................................................................... 84 d) Resultado esperado ................................................................................................................................................ 84

4.5 RESULTADOS DE PRUEBAS ................................................................................................................................... 85 4.6 EVALUACIÓN DE RESULTADOS ............................................................................................................................. 95

CAPÍTULO 5. CONCLUSIONES........................................................................................................................... 97

5.1 CONCLUSIONES................................................................................................................................................. 97 5.2 TRABAJOS FUTUROS......................................................................................................................................... 100 5.3 PUBLICACIÓN ................................................................................................................................................. 100

REFERENCIAS................................................................................................................................................. 101

v

Lista de figuras

Figura 1: Método de solución ........................................................................................................................ 16 Figura 2: Representación de un usuario en los diagramas casos de uso. ...................................................... 18 Figura 3: Notación de casos de uso. .............................................................................................................. 19 Figura 4: Ejemplo de una relación de extensión entre casos de uso. ............................................................. 20 Figura 5: Ejemplo de una relación de inclusión entre casos de uso. .............................................................. 21 Figura 6: Notación de clase. ........................................................................................................................... 23 Figura 7: Dependencia entre elementos. ....................................................................................................... 24 Figura 8: Tipos de asociaciones. .................................................................................................................... 26 Figura 9: Ejemplo de generalización. ............................................................................................................. 27 Figura 10: Ejemplo de dependencia de la realización de un clasificador a una interfaz. ............................... 27 Figura 11: Diagramas del UML ...................................................................................................................... 30 Figura 12: Diagrama de contexto de los DCU y DC. ....................................................................................... 31 Figura 13: Diagrama de características de los CU ......................................................................................... 37 Figura 14: Diagrama de características de los actores .................................................................................. 37 Figura 15: Diagrama de características de los tipos de relaciones ................................................................ 38 Figura 16: Diagrama de características de los DCU (elementos principales)................................................. 39 Figura 17: Diagrama de características de los DC (elementos principales). .................................................. 44 Figura 18: Diagrama de características de las clases. ................................................................................... 44 Figura 19: Diagrama de características de los atributos. .............................................................................. 45 Figura 20: Diagrama de características de las operaciones. ......................................................................... 46 Figura 21: Diagrama de Características de los parámetros. .......................................................................... 47 Figura 22: Diagrama de características de las relaciones de los DC. ............................................................. 48 Figura 23: Diagrama de características de la relación de dependencia/realización. .................................... 49 Figura 24. Procedimiento de comparación heurística. .................................................................................. 55 Figura 25: Mapeo de entidad y verbo a clase y operación. ........................................................................... 57 Figura 26: Entidad en un actor no puede ser mapeada a clase. .................................................................... 58 Figura 27: Mapeo de relación de asociación (DCU) a relación de asociación (DC). ....................................... 61 Figura 28: Mapeo de relación include (DCU) a relación de composición (DC). .............................................. 62 Figura 29: Mapeo de relación de generalización (DCU) a relación de generalización/especialización (DC). 63 Figura 30: Esquema de transformación a nivel de Metamodelos ................................................................. 63 Figura 31. Diagrama de actividad para generar clases a partir de casos de uso. ......................................... 64 Figura 32. Diagrama de actividad para mapear la relación de generalización (DCU) a los DC. .................... 66 Figura 33. Diagrama de actividad para mapear relación include a los DC. ................................................... 69 Figura 34. Diagrama de casos de uso de sistema ATM. ................................................................................ 85 Figura 35. Resultado obtenido al aplicar el método de transformación T0. .................................................. 86 Figura 36. Diagrama de clases final del sistema ATM. .................................................................................. 87 Figura 37. Resultado obtenido al aplicar el método de transformación T1. .................................................. 89 Figura 38. Resultado obtenido al aplicar el método de transformación T2. .................................................. 90 Figura 39. Diagrama de casos de uso del sistema administrador de proyectos. ........................................... 91 Figura 40. Resultado obtenido al aplicar el método de transformación T0. .................................................. 93 Figura 41. Diagrama de clases final del sistema administrador de proyectos............................................... 93 Figura 42. Posible confusión entre atributo y clase. ...................................................................................... 96

vi

Lista de tablas TABLA 1. COMPARATIVA DE TRABAJOS RELACIONADOS ......................................................................................................... 8 TABLA 2. ELEMENTOS GRÁFICOS QUE PUEDEN SER INCLUIDOS DENTRO DE LOS DIAGRAMAS DE CASOS DE USO. .............................. 21 TABLA 3. ELEMENTOS DE UN DIAGRAMA DE CLASES. .......................................................................................................... 28 TABLA 4. NOTACIÓN EMPLEADA PARA LAS CARACTERÍSTICAS DE LOS DCU. ............................................................................. 33 TABLA 5. NOTACIÓN EMPLEADA PARA LAS CARACTERÍSTICAS DE LOS DC. ............................................................................... 40 TABLA 6. CARACTERÍSTICAS DE CU, ACTOR, CLASE, OPERACIÓN Y ATRIBUTO DE LA SUPERESTRUCTURA. ..................................... 56 TABLA 7. CARACTERÍSTICAS DE LAS RELACIONES DE LOS DCU Y DC. ...................................................................................... 59 TABLA 8. CARACTERÍSTICAS DE LAS RELACIONES DE LOS DCU Y DC. ...................................................................................... 60 TABLA 9. DESCRIPCIÓN DE LAS TAREAS DE PRUEBA. ............................................................................................................ 77 TABLA 10. RESULTADOS DEL CASO DE PRUEBA MDT-01-01 TRANSFORMACIÓN DE CASO DE USO A CLASE PARA EL SISTEMA ATM

[CBJO01]. ....................................................................................................................................................... 85 TABLA 11. RESULTADOS DEL CASO DE PRUEBA MDT-02-01 TRANSFORMACIÓN DE RELACIÓN DE GENERALIZACIÓN A RELACIÓN DE

GENERALIZACIÓN/ESPECIALIZACIÓN PARA EL SISTEMA ATM [CBJO01]......................................................................... 88 TABLA 12. RESULTADOS DEL CASO DE PRUEBA MDT-03-01 TRANSFORMACIÓN DE RELACIÓN INCLUDE A RELACIÓN DE COMPOSICIÓN

PARA EL SISTEMA ATM [CBJO01]. ....................................................................................................................... 90 TABLA 13. RESULTADOS DEL CASO DE PRUEBA MDT-01-02 TRANSFORMACIÓN DE CASO DE USO A CLASE PARA EL SISTEMA

ADMINISTRADOR DE PROYECTOS [CAFE10]............................................................................................................. 91 TABLA 14. RESULTADOS DEL CASO DE PRUEBA MDT-02-02 TRANSFORMACIÓN DE RELACIÓN DE GENERALIZACIÓN A RELACIÓN DE

GENERALIZACIÓN/ESPECIALIZACIÓN PARA EL SISTEMA ADMINISTRADOR DE PROYECTOS [CAFE10]. .................................... 94 TABLA 15. RESULTADOS DEL CASO DE PRUEBA MDT-03-02 TRANSFORMACIÓN DE RELACIÓN INCLUDE A RELACIÓN DE COMPOSICIÓN

PARA EL SISTEMA ADMINISTRADOR DE PROYECTOS [CAFE10]. .................................................................................... 94

vii

Glosario de términos y siglas OMG (Object Management Group) Grupo de Gestión de Objetos, es un

consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML. Promueve el uso de tecnología orientada a objetos mediante guías y especificaciones para las mismas [OMG09].

MOF (Meta-Object Facility) es un estándar aprobado por la OMG para

la definición, representación, intercambio y gestión de metadatos [MOFS06].

UML (Unified Modeling Language) es un lenguaje unificado de

modelado de propósito general para especificar, visualizar, construir y documentar un sistema de software [OMG09].

OCL (Object Constraint Language) Lenguaje de Restricciones de

Objetos, define un lenguaje simple para escribir restricciones y expresiones sobre elementos de un modelo. El OCL brinda la posibilidad de definir en los elementos de un diagrama, entre otros: invariantes, precondiciones, poscondiciones y restricciones.

FODA (Feature-Oriented Domain Analysis) es una metodología de análisis de dominio basado en la identificación de las características distintivas o prominentes de la clase de un sistema [KCHN09].

Introducción

1

Introducción Cuando se inicia el desarrollo de un proyecto de software, los diagramas de modelado existentes se vuelven importantes para comprender la funcionalidad del sistema; para la comunicación y entendimiento entre el cliente, el analista y cada una de las personas involucradas en el proceso del desarrollo de software.

Es común utilizar el lenguaje unificado de modelado (por sus siglas en inglés UML) para modelar cada una de las fases del ciclo de vida del desarrollo de software, para representar el comportamiento del sistema (análisis, diseño, codificación,

pruebas e integración).

Siendo el análisis de requisitos la primera y más importante de las fases involucradas en el ciclo de vida del desarrollo de software, debido a que se determina el comportamiento que el futuro sistema debe tener. En esta fase se utilizan los diagramas de casos de uso (DCU) para capturar los requerimientos del sistema sin revelar la estructura interna del mismo.

Los diagramas de casos de uso, son más que una herramienta de especificación, debido a que tienen una gran influencia sobre todas las demás fases del proceso de desarrollo, tales como el diseño, codificación y pruebas del sistema.

Introducción

2

La fase de diseño, como se mencionó anteriormente, debe tener presente lo especificado en los DCU, en ésta se modela la parte estática del desarrollo del software mediante los diagramas de clases (DC), dichos DC son utilizados para distinguir las entidades de software que participan en el sistema y cómo deberán de colaborar para alcanzar un objetivo en común.

Por lo anterior resulta interesante conocer qué elementos de un DCU pueden

ser potencialmente clases y analizar si las relaciones de los elementos de estos diagramas tienen una consecuencia en el DC, debido a que en ocasiones se presentan inconsistencias al representar los requerimientos del usuario en la fase de análisis, ya que éstos no se reflejan directamente en los diagramas de clases.

Organización del documento La organización del presente documento de tesis se describe a continuación:

En el capítulo 1 se presenta la descripción de la investigación, la cual consta del planteamiento del problema; el objetivo perseguido; la justificación de este trabajo y los beneficios que con él se obtienen; trabajos relacionados y por último los alcances y limitaciones consideradas para el desarrollo de esta investigación.

En el capítulo 2 se presenta el marco teórico, el cual contiene los conceptos relevantes para la comprensión de este documento de tesis, como superestructura, infraestructura, FODA, entre otros.

En el capítulo 3 se aborda el método de solución para el desarrollo de esta investigación, se describe a detalle cada una de las actividades realizadas para dar solución al problema planteado en esta tesis.

En el capítulo 4 se presentan las pruebas de funcionalidad aplicadas a los métodos de transformación, se describe el plan de pruebas utilizado; los casos de prueba y los resultados obtenidos de la aplicación de las pruebas. Por último en el capítulo 5 se presentan las conclusiones generadas con la evaluación de este trabajo de tesis; las aportaciones logradas durante esta investigación; los trabajos futuros y publicaciones obtenidas durante el desarrollo de este trabajo de tesis.

Capítulo 1. Descripción de la Investigación

3

Capítulo 1. Descripción de la Investigación En este capítulo se presenta el contexto de este trabajo de tesis, el problema que se analiza, el objetivo perseguido, la justificación, los beneficios que con ella se obtienen, el estado del arte y por último los alcances y limitaciones considerados para el desarrollo de esta investigación.

1.1 Planteamiento del problema Cuando se desarrollan aplicaciones de software, es necesario modelar cada una de las fases involucradas en el desarrollo de software mediante las diferentes vistas que el lenguaje unificado de modelado (UML) proporciona para facilitar y llevar el control del desarrollo de sistemas. Sin embargo, en ocasiones no se logra plasmar totalmente los requerimientos funcionales en la vista estática, dando como resultado

incompatibilidades o incongruencias entre el diagrama de clases (DC) y los diagramas de casos de uso (DCU).

Es decir, podríamos especificar en un DCU, la información necesaria para identificar las actividades, tareas o funcionalidades que se requiere que el sistema realice (requerimientos funcionales) y no reflejar dicha información en los DC. También podríamos modelar algo en la vista estática que no sea requerido o que contradiga la especificación funcional.

Debido al problema mencionado anteriormente, esta tesis se enfoca en determinar si existe relación directa o indirecta de las características o elementos entre los DCU y DC.


4

1.2 Objetivo Identificar los elementos de los diagramas de casos de uso (DCU), que puedan ser representados o tengan relación en los diagramas de clases (DC). Analizando las características de los elementos de los DCU y DC, explicando de manera racional el por qué de su uso.

1.3 Justificación y beneficios UML es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema de software orientado a objetos, el cual se ha convertido en el estándar de facto de la industria del desarrollo de software.

Actualmente muchos de los flujos de trabajo involucrados en el desarrollo de sistemas de software se pueden representar bajo diferentes niveles de abstracción y tipos de diagramas del UML.

Siendo los diagramas de casos de uso el punto de partida para el desarrollo de software, debido a que con ellos se modelan los requisitos del sistema desde la perspectiva del usuario. Sin embargo no especifica la arquitectura de clases necesaria para satisfacer los requerimientos del cliente (diagramas de casos de uso).

Por lo que hacen falta mecanismos que permitan conocer si los requerimientos funcionales, especificados en los diagramas de casos de uso se reflejan de manera coherente en los diagramas de clases.

Los beneficios que se obtienen con este proyecto son:

Conocer los elementos de un diagrama de casos de uso que pueden ser o no, elementos de un diagrama de clases.

El proceso que se lleve a cabo para poder realizar la caracterización de los elementos de los diagramas de casos de uso y diagramas de clases, servirá como referencia para poder seguir un proceso similar en la caracterización de otros modelos del UML.

Contar con mecanismos de transformación entre DCU y DC.

Darle el formalismo necesario a los DCU y DC del UML para evitar cometer ambigüedades o inconsistencias al momento de modelar las fases de análisis de requerimientos y diseño de sistemas de software.

Además de los beneficios listados anteriormente, se establecen las bases

necesarias para la automatización de métodos de transformación entre los DCU y DC.


5

1.4 Trabajos relacionados En esta sección se describen los trabajos más representativos que permiten definir elementos o realizar la transformación entre diagramas de casos de uso y clases del UML, se presentan sus características más sobresalientes y las diferencias que existen con el presente trabajo.

Los trabajos cumplen con las siguientes características:

Enfoque en la generación de diagramas de modelado de objetos a partir de diagramas de casos de uso o escenarios de casos de uso.

Identificación de clases, métodos, atributos y/o relaciones a partir de casos de uso o escenarios de casos de uso.

Formalización de elementos que integran los diagramas de casos de uso y/o diagramas de clases.

1.4.1 From Use Cases to UML Class Diagrams using Logic Grammars and Constraints [HCKT07]. Este trabajo presenta una forma de automatizar la trasformación de casos de uso a diagramas de clases del UML, se utiliza un lenguaje natural restringido por reglas gramaticales, el cual es mapeado para la construcción de bloques de la programación orientada a objetos (POO) como son clases, objetos, métodos y/o propiedades. Se analizan frases en lenguaje natural, en las cuales se identifican verbos y sustantivos, estos son mapeados al diagrama de clases como métodos y clases respectivamente.

El sistema propuesto mantiene una actualización constante de la representación esquemática del texto actual del caso de uso en una pantalla de usuario, con lo cual se pretende fomentar un modo interactivo de trabajo, tan pronto como el usuario agrega una frase para describir un caso de uso, éste se refleja en términos de modelado de objetos (clases, objetos y métodos).

1.4.2 Relaciones entre Casos de Uso en el Unified Modeling Language [SGFP00]. Este trabajo presenta una formalización de las principales relaciones entre casos de uso, aportando precisión en su definición con el desarrollo de un álgebra para casos de uso.

Las principales relaciones consideradas en este trabajo son:

Generalización

Inclusión.

Extensión. Además se realiza una comparación semántica entre las relaciones de

Inclusión y Extensión.


6

1.4.3 Generating OCL Specifications and Class diagrams from Use Cases: A Newtonian Approach [BORO03].

Este artículo propone un método para generar diagramas de clases (DC) a partir de los diagramas de casos de uso (DCU), mediante la utilización de invariantes algebraicas como medio para descubrir clases, relaciones y especificaciones OCL de las descripciones de los casos de uso.

El enfoque está básicamente basado en los modelos de máquinas de estado como punto intermedio entre la transformación de los DCU a DC.

Básicamente esta propuesta se basa en la experiencia de cada uno de las personas involucradas en el desarrollo de software (stakeholders) y de los valores

esperados, en donde, los stakeholders analizan los casos de uso que le atañen a cada uno y desde su punto de vista y de acuerdo con su experiencia determinan el valor esperado de cada caso de uso que ellos utilizan y a cada caso de uso se le identifican los actores y contra-actores, los actores y contra-actores son las entidades que utilizan, esperan algún resultado del caso de uso o intercambian valores (invariantes algebraicas) entre sí.

Una vez que se identificaron todos los agentes del caso de uso, estos son descritos con mayor detalle mediante una máquina de estados, representando la evolución que cada uno de ellos sufre. En donde básicamente cada actor o contra-actor (agentes) es mapeado como una clase y los valores ganados y perdidos también son modelados como clases, después extiende el DC con la máquina de estado de otro agente, utilizando los valores ganados y perdidos en común para relacionar agentes.

1.4.4 Events in Use Cases as a Basis for Identifying and Specifying Classes and Business Rules [CCPO99].

Este artículo describe cómo los eventos en los casos de uso pueden ser la base para la identificación de clases y reglas de negocio. Utiliza un proceso conocido como secuencia de eventos, para describir y analizar los eventos. En este proceso se identifican los objetos, clases, atributos y operaciones, así como las reglas de negocio asociadas con los eventos.

Determina que una secuencia de eventos contiene secciones como: nombre del evento, significado breve, origen, conjunto de participante, condiciones de pre-evento, entradas, cambios, post-eventos, políticas derivadas.

En donde la información en el origen, el conjunto de participantes, las condiciones de pre eventos, y los cambios de secciones se utilizan para identificar objetos y clases; los atributos se pueden encontrar en las condiciones de pre-evento, entrada, cambios, pos eventos y secciones de políticas derivadas.


7

1.4.5 From use cases to classes: a way of building object model with UML [LIAY03].

El principio de este enfoque es identificar clases de los objetivos de los caso de uso en lugar de los escenarios. Este enfoque provee un proceso de siete pasos para generar el diagrama de clases a partir del diagrama de casos de uso.

En donde cada paso a su vez cuenta con una serie de preguntas que se hacen a los actores en lugar del analista. El resultado obtenido de cada pregunta se plasma en un diagrama entidad-caso de uso para ir completando el DC a través de los siete pasos que se proponen.

En donde:

Paso 1: Se cuestiona al actor sobre los resultados o valores que espera de aplicar el caso de uso en cuestión. Paso 2: Se cuestiona al actor sobre las entidades y sus características que él considera necesarias para la realizar el objetivo del caso de uso. Paso 3: De acuerdo con el nivel de conocimiento del actor este plasma las características que él considera necesarias para complementar las clases como atributos de éstas. Paso 4: Identifican posibles relaciones o dependencias entre clases. Paso 5: Identifican posibles colaboraciones entre entidades las cuales proporcionan a una entidad algún elemento para que éste se realice de manera adecuada. Paso 6: Se establecen operaciones para las entidades identificando comportamientos necesarios para que las entidades alcancen los objetivos de los casos de uso. Paso 7: Se cuestiona al analista sobre la totalidad de los requerimientos cumplidos con el diagrama de clases obtenido, así como si las entidades y relaciones cumplen con los requerimientos plasmados en los DCU.

1.4.6 Comparativa trabajos relacionados

En la tabla 1 se aprecia una comparativa entre los trabajos relacionados (filas) en donde se contemplan características (columnas) como: objeto base a analizar, método de solución, elementos que identifica, desventajas y producto final.


8

Tabla 1. Comparativa de trabajos relacionados

Trabajo relacionado Analiza Método de solución Identifica Limitaciones Producto

From Use Cases to UML Class Diagrams using Logic Grammars and

Constraints [HCKT07].

Escenarios de casos de uso.

La semántica del lenguaje natural, Procesamiento de lenguaje natural.

Verbos, Sustantivos, Relaciones.

Lenguaje restringido

Herramienta para la generación

automática de DC.

Relaciones entre Casos de Uso en el Unified Modeling Language

[SGFP00].

Casos de uso Formalización

(Algebra para CU)

Relación extends, uses y

generalización.

Se basan únicamente en

elementos sintácticos del

sistema.

Reglas formales

Generating OCL

Specifications and Class diagrams from

Use Cases:A Newtonian Approach [BORO03].

Narrativa de especificación de

CU.

Generación de máquinas de estado a

partir de CU. Generación de clases a partir de las máquinas

de estados.

Clases y relaciones No métodos. No atributos.

Diagrama de clases

Events in Use Cases as a Basis for Identifying and Specifying Classes

and Business Rules [CCPO99].

Eventos de los casos de uso

Secuencia de eventos Clases, Operaciones, Atributos, Relaciones y reglas del negocio.

Descripción de los eventos con

diferentes palaras. Diagrama de clases

From use cases to classes: a way of

building object model with UML [LIAY03].

Casos de uso

Metodología de 7 pasos, basada en los objetivos

de los casos de uso.

Diagramas entidad-caso de uso, clases, métodos y atributos.

Depende del nivel de conocimiento de los actores acerca del dominio que se pretenda modelar.

Diagrama de clases

Definición de Elementos de

Transformación entre Diagramas de Casos de Uso y Clases del UML

(Tesis).

Diagramas de casos de uso, diagramas de

clase.

Análisis FODA, Formalización basada

en conjuntos, relaciones y funciones,

Comparación heurística.

Características de los elementos de los DCU que tengan

relación con los DC

La identificación de elementos de los DC depende del

nivel de detalle del DCU.

Formalización de los elementos de DCU y

DC. Explicación racional sobre la relación de los elementos de los DC y DC del UML.

Métodos de transformación.


9

1.5 Alcances y limitaciones

Alcances: Los alcances considerados dentro de este trabajo de tesis se mencionan a continuación:

La caracterización realizada corresponde a los elementos de los modelos de DCU y DC del UML.

La formalización realizada corresponde a los elementos y/o relaciones que integran a los modelos de los DCU y DC.

Los mecanismos de comparación evalúan las características de los DCU y DC.

Conocimiento sobre los elementos de los DCU que se relacionan o no, con los DC del UML.

Métodos de transformación capaces de mapear elementos de los DCU como elementos de los DC.

Limitaciones: A continuación se mencionan las limitaciones consideradas dentro de este trabajo de tesis:

Sólo se analizaron los metamodelos de los DCU y DC del UML para realizar las mecanismos de comparación y transformación.

No se implementaron a nivel de código mediante algún lenguaje de programación forma la automatización de la transformación.

Capítulo 2. Marco Teórico

11

Capítulo 2. Marco teórico En este capítulo se describen los conceptos necesarios para la clara comprensión de este trabajo, abarcando superestructura, infraestructura, FODA, entre otros.

2.1 Análisis de dominio El termino Análisis de dominio “es la actividad que consiste en identificar los objetos y operaciones de un tipo de sistemas similares, dentro de un dominio de problema particular” [NEIG81].

Otra definición es la propuesta por Prieto-Díaz (1990), como “el proceso por el cual la información utilizada para el desarrollo de sistemas de software se identifica, captura y organiza con el fin de hacerlo reutilizable en la creación de nuevos sistemas” [PRIE 90].

A partir de estas dos definiciones, se pueden identificar las principales características del análisis de dominio:

Se trata de una disciplina orientada a la captura y gestión de información y conocimiento.

Pretende abstraer los aspectos que describen y caracterizan un área de actividad o proceso, es decir un “dominio” específico.


12

Parte de un conjunto de sistemas de software existentes.

Tiene como objetivo identificar información que pueda reutilizarse en el diseño de futuros sistemas.

2.2 Análisis FODA “FODA es una metodología de análisis de dominio basado en la identificación de las características distintivas o prominentes de la clase de un sistema” [KCHN09].

En esta metodología se define a una característica como una “propiedad prominente y distinguible por el usuario de un sistema". Las características son el medio idóneo para diferenciar los aspectos comunes y las diferencias que presentan los distintos sistemas de información sobre los que se ha realizado el análisis de

dominio. Los aspectos comunes se plasman como características obligatorias y las diferencias o variaciones como características opcionales.

FODA es utilizado para analizar aplicaciones existentes buscando:

Características indispensables

Implementaciones alternativas

Funciones opcionales

Dependencias entre características

Crear diccionario del dominio

Establecer terminología

Explorar alternativas

Interactuar con usuarios poco comunicativos

2.3 Metamodelo El metamodelo es la capa donde se define el lenguaje que sirve para especificar los modelos que crean los usuarios del UML. En otras palabras, el metamodelo sirve para describir los elementos que van a componer nuestros diagramas. Esta capa es propia del UML y es aquí donde se definen los objetos del lenguaje unificado: Clase, Atributo, TipoDato... etc.

2. 4 Diagramas de casos de uso

La especificación del UML de la OMG (UML 2.0 Superstructure) establece:

Diagrama de casos de uso: “Describe los requerimientos funcionales del sistema y las relaciones entre los actores y el sujeto (sistema), y los casos de uso” [OMG09]. En otras palabras, los diagramas de casos de uso son una técnica para especificar el comportamiento de un sistema.


13

2.5 Diagramas de clases. La especificación del UML de la OMG (UML 2.0 Superstructure ) establece:

"Es un diagrama que muestra una colección de elementos de modelado declarativos (estáticos), tales como clases, tipos y sus contenidos y relaciones" [OMG09]. En otras palabras, los diagramas de clases son una técnica para representar la estructura estática de un sistema.

2.6 Transformación Una transformación es un “mapeo” que permite partir de un modelo de un dominio determinado (modelo fuente) y arribar a un modelo que pertenece a otro dominio

(modelo destino). En esta tesis el dominio fuente es el diagrama de casos de uso y el modelo destino es el diagrama de clases.

2.7 Lenguaje Z El lenguaje Z, es un lenguaje utilizado para construir documentos de especificación formal que contienen texto en lenguaje natural intercalado con código Z. El lenguaje Z está basado en lógica, conjuntos, relaciones y funciones para definir qué es lo que un sistema debe hacer y en qué orden hacerlo, sin indicar la forma en que ha de hacerse. Debido a esto, el lenguaje Z es considerado un lenguaje declarativo en comparación con uno de procedimientos o imperativo como puede ser Java, C++, etc.

Capítulo 3. Método de Solución

15

Capítulo 3. Método de Solución Para dar solución al problema planteado en esta tesis se realizaron las siguientes actividades, las cuales se describen a detalle en las secciones siguientes.

Análisis de los DCU y DC. Se realizó un estudio sobre los metamodelos de los DCU y DC para conocer la estructura, características de los modelos a trasformar y la manera en que se relacionan los elementos que los componen.

Estudio de FODA. Se realizó un estudio sobre la metodología de Análisis de Dominio Orientado a Características (FODA), para conocer y entender el

proceso que se realiza cuando se aplica FODA a un dominio en específico.

Caracterización de los elementos de los DCU y DC. Se realizó la caracterización de los elementos de los DCU y DC mediante la aplicación del método FODA, la caracterización comprendió los siguientes puntos:

Adaptación de FODA. Se realizó una adaptación del método FODA, la cual consistió en omitir algunos de los modelos que ofrece este método, al no ser necesarios para analizar o representar nuestros dominio (DCU y DC).


16

Análisis del contexto. Se analizó el contexto del dominio, alcance y restricciones para los DCU y DC del UML.

Modelado del dominio. Se identificaron las características obligatorias, opcionales y alternativas distintivas de cada elemento que comprenden tanto a los DCU como a los DC del UML. Así mismo se representaron dichas características mediante los modelos de características de FODA.

Formalización de los DCU y DC. Se formalizaron las características de los elementos que integran tanto a los DCU como a los DC, dicha formalización se llevo a cabo mediante el lenguaje de especificación formal Z. Esto con el fin de describir de manera precisa las características de los

elementos tanto de los DCU como de los DC, logrando con ello que los diagramas estén libres de inconsistencias, ambigüedades y declaraciones incompletas.

Establecer mecanismos de comparación entre los DCU a DC. Se establecieron mecanismos de comparación para analizar los elementos de los diagramas de casos de uso (DCU) y diagramas de clases (DC) del UML, mediante los cuales se identificaron relaciones de semejanza entre los elementos de dichos diagramas.

Explicación racional sobre la existencia o falta de relación entre los elementos de los DCU y DC.

En la figura (1) se representa la metodología anteriormente descrita.

Figura 1: Método de solución

Análisis de

Metamodelos del

UML

Estudio de FODA

Caracterización de

elementos DCU y

DC

Formalizar la

caracterización de los elementos

Establecer

mecanismos de

comparación entre

los DCU y DC

Explicación racional

sobre la existencia o

falta de relación entre

los elementos de los DCU y DC

Capitulo 3. Método de Solución

17

3.1 Análisis de los metamodelos del UML En esta sección se presentan los resultados del estudio realizado sobre los metamodelos de los diagramas de casos de uso (DCU) y diagramas de clases (DC), con la finalidad de conocer a mayor detalle la estructura y características de los metamodelos, ya que en esta tesis son utilizados para definir aquellos elementos de los DCU que tienen relación en los DC.

Cabe mencionar que el contenido de esta sección se basa en las siguientes especificaciones: OMG Unified Modeling LanguageTM (OMG UML), Infrastructure versión 2.2 y OMG Unified Modeling LanguageTM (OMG UML), Superstructure versión 2.2, publicadas por el Grupo de Gestión de Objetos (OMG).

3.1.1 Diagrama de casos de uso

Los diagramas de casos de uso son un medio para especificar los usos requeridos de un sistema, es decir lo que se supone que el sistema debe hacer. Los conceptos clave asociados a este tipo de diagrama son: actor, casos de uso y sujeto. El sujeto es el sistema en consideración, en el que los casos de uso se aplican.

Los usuarios y otros sistemas que pueden interactuar con el sujeto son representados como actores. Los actores siempre modelan entidades que están fuera del sistema. El comportamiento que se requiere del sistema se especifica por uno o más casos de uso, los cuales son definidos de acuerdo a las necesidades de los actores.

3.1.1.1 Descripción de conceptos

3.1.1.1.1 Actor

Un actor especifica un rol desempeñado por un usuario o por otro sistema que interactúa con el sujeto.

3.1.1.1.1.1 Descripción Un actor modela un tipo de rol desempeñado por una entidad que interactúa con el sujeto, el cual es externo al sujeto. Los actores pueden representar el rol desempeñado por usuarios humanos, hardware externo o de otro tipo. Se debe tener en cuenta que la especificación de la superestructura UML, v2.2 indica que un actor no necesariamente representa una entidad física específica, sino simplemente un aspecto particular (“rol”) de una entidad que es relevante para la especificación de sus casos de uso asociados.

3.1.1.1.1.2 Restricciones

Un actor sólo puede tener asociaciones con casos de uso, componentes y clases. Además estas asociaciones deben ser binarias.

Un actor debe tener un nombre.


18

3.1.1.1.1.3 Semántica Cuando una entidad externa interactúa con el sujeto, ésta desempeña el rol de actor específico. 3.1.1.1.1.4 Notación En la figura (2) podemos observar las diferentes maneras en las que un actor puede ser representado. Puede ser representando por un icono que representa un hombre con el nombre del actor, este nombre generalmente está ubicado arriba o por debajo del icono. Un actor también puede ser mostrado como una clase, una caja rectangular con la palabra clave <<actor>>. Otro icono que puede también ser usado para denotar un actor es el icono de una computadora, generalmente usado para los

actores no humanos.

Figura 2: Representación de un usuario en los diagramas casos de uso. De [SUPE09], p.589, 590.

3.1.1.1.2 Caso de uso

Un caso de uso es la especificación de un conjunto de acciones desempeñadas por un sistema, el cual produce un resultado observable que es típicamente de valor para uno o más actores de un sistema.

3.1.1.1.2.1 Descripción

Un caso de uso es un tipo de comportamiento que representa la declaración de un comportamiento ofrecido por el sistema sin referencia a la estructura interna.

El sujeto de un caso de uso puede ser un sistema físico o cualquier otro elemento que pueda tener comportamiento, tal como un componente, subsistema o

clase. El comportamiento de un caso de uso puede ser descrito mediante una especificación, como interacciones, actividades o mediante pre-condiciones y pos-condiciones, también mediante texto en lenguaje natural e inclusive estas descripciones pueden ser combinadas.


Un caso de uso debe tener un nombre.

Sólo puede estar involucrado en asociaciones binarias

<<actor>>

Cliente Cliente

Usuario


19

3.1.1.1.2.3 Semántica La ejecución de un caso de uso es una ocurrencia de un comportamiento emergente.

3.1.1.1.2.4 Notación Un caso de uso se muestra como una elipse que contiene el nombre del caso de uso o el nombre del caso de uso puede ir debajo de la elipse, tal como se muestra en la figura (3) en donde se aprecia la manera en que pueden ser nombrados los casos de uso.

Figura 3: Notación de casos de uso. De [SUPE09], p.598.

3.1.1.1.3 Extend

Una relación de un caso de uso extensión a un caso de uso extendido, especifica cómo y cuándo, el comportamiento definido en el caso de uso extensión puede ser insertado dentro del comportamiento definido en el caso de uso extendido. 3.1.1.1.3.1 Descripción Esta relación especifica que el comportamiento de un caso de uso puede ser extendido por el comportamiento de otro caso de uso. La extensión toma lugar en uno o más puntos de extensión definidos en el caso de uso extendido. El mismo caso de uso extensión puede extender más de un caso de uso.


Los puntos de extensión a los que hace referencia la relación de extensión deben pertenecer al caso de uso que está siendo extendido.

3.1.1.1.3.3 Semántica Un caso de uso extensión consiste de uno o más fragmentos de comportamiento que han de ser insertados dentro del caso de uso extendido.

Una ubicación de extensión es la especificación de puntos (extensión) dentro de un caso de uso, donde comportamientos adicionales pueden ser insertados. Si la condición de la extensión es verdadera en el momento en que el primer punto de extensión es alcanzado durante la ejecución del caso de uso extendido, entonces todos los fragmentos de comportamiento de los casos de uso extensión también serán ejecutados. Si la condición es falsa la extensión no ocurrirá.

Depositar

Dinero

Transferir

Dinero


20

3.1.1.1.3.4 Notación Una relación de extensión entre casos de uso es mostrada por una flecha discontinua con una punta de flecha abierta desde el caso de uso que provee la extensión hasta el caso de uso base. La flecha es etiquetada como <<extend>>. La condición de la relación así como las referencias a los puntos de extensión son opcionalmente mostradas en una nota adjunta a la correspondiente relación de extensión.

3.1.1.1.3.5 Ejemplo En la relación extend representada en la figura (4), el caso de uso “Realizar Transacción ATM” tiene un punto de extensión “Selección”. Este caso de uso está

extendido a través del punto de extensión por el caso de uso “Ayuda on-line” siempre que ocurra la ejecución del caso de uso “Realizar Transacción ATM” y esté en la ubicación referenciada por el punto de extensión “Selección” y el cliente seleccione la ayuda.

Figura 4: Ejemplo de una relación de extensión entre casos de uso. De [SUPE09], p.593.

3.1.1.1.3.6 Justificación Esta relación está destinada a ser usada cuando hay algún comportamiento que debería ser agregado, posiblemente condicionalmente, al comportamiento definido en otro caso de uso.

3.1.1.1.4 Include

Una relación include define que un caso de uso contiene el comportamiento definido en otro caso de uso. El caso de uso incluyente sólo puede depender del resultado (valor) del caso se uso incluido.

3.1.1.1.4.1 Descripción Include es una relación directa entre dos casos de uso, implica que el comportamiento del caso de uso incluido es insertado dentro del comportamiento del caso de uso incluyente.

Ayuda

on-line

<<extend>>

Selección

Puntos extensión

Realizar Transacción ATM

Condición: {cliente seleccionó AYUDA

Punto de extensión: Selección}


21

3.1.1.1.4.2 Semántica

Una relación de include entre dos casos de uso significa que el comportamiento definido en el caso de uso incluido, es incluido en el caso de uso incluyente. La relación de include es usada cuando hay partes de comportamientos en común entre dos o más casos de uso. Esta parte en común es extraída a un caso de uso separado y es incluida por todos los casos de uso base tomando esta parte común.

3.1.1.1.4.3 Notación Una relación include entre casos de uso se muestra por una flecha punteada con una punta de flecha abierta del caso de uso base al caso de uso incluido. La flecha es etiquetada con la palabra clave <<include>>.

3.1.1.1.4.4 Ejemplo En la figura (5) se puede observar un ejemplo de inclusión entre casos de uso, en donde el caso de uso “Retirar” incluye un caso de uso definido independientemente “Presentar Identificación”.

Figura 5: Ejemplo de una relación de inclusión entre casos de uso. De [SUPE09], p.596.

3.1.1.1.5 Nodos gráficos

Los nodos gráficos que pueden ser incluidos dentro de los diagramas de casos de uso son mostrados en la tabla (2).

Tabla 2. Elementos gráficos que pueden ser incluidos dentro de los diagramas de casos de uso. De [SUPE09], p.601, 602 y 603.

Tipo de nodo Notación

Actor

Caso de Uso

Extend

Personalizado

Selección

Puntos extensión

<<extend>>

Caso de uso extendido Caso de uso extensión

Retirar Presentar

Identificación

<<include>>

Retirar


22

Include

Generalización

Para mayor detalle sobre la descripción de cada uno de los elementos que integran a los DCU consultar el reporte de avance de tesis “Análisis de los metamodelos de DCU y DC del UML” que comprende el periodo de Septiembre a Diciembre del 2009.

3.1.2 Diagrama de clases

Los diagramas de clases se utilizan para mostrar la estructura estática del sistema modelado. Pueden contener clases, interfaces, relaciones e incluso instancias, como objetos o enlaces. Los diagramas de clases son una potente herramienta de diseño, ayudando a los desarrolladores a planificar y establecer la arquitectura, estructura del sistema y subsistemas, antes de escribir cualquier código. Esto permite que el sistema esté bien diseñado desde el principio del proceso de desarrollo del software.

3.1.2.1 Descripción de conceptos

3.1.2.1.1 Clases

Una clase describe un conjunto de objetos que comparten las mismas especificaciones de características, restricciones y semántica.

3.1.2.1.1.1 Descripción

Clase es un tipo de clasificador cuyas características son atributos y operaciones. Los atributos de una clase son representados por instancias de propiedades exclusivas de la clase.

Una operación es una característica de comportamiento de las clases que especifica el nombre, tipo, parámetros y restricciones para invocar un comportamiento asociado.

Atributo describe un rango de valores de instancias que las clases pueden tener. Es definido por un nombre y un tipo. Los atributos tienen asociados: nombre, tipo de dato, valor por defecto y otros modificadores que indican si el atributo es de

Retirar Presentar Identificación

<<include>>

Caso de uso que incluye Caso de uso incluido

Persona

Hombre

Generalización


23

sólo lectura, escritura, estático o cualquier otra cosa; adicionalmente un atributo puede tener propiedades como visibilidad (para otras clases) y multiplicidad. 3.1.2.1.1.2 Semántica El propósito de una clase es especificar una clasificación de objetos y especificar las características de la estructura y el comportamiento de estos objetos.

Las operaciones de una clase pueden ser invocadas desde un objeto o instancia. Una invocación de operaciones puede causar cambios a los valores de los atributos de un objeto. 3.1.2.1.1.3 Notación Una clase se muestra usando el símbolo de clasificador. Como la clase es el clasificador más utilizado, la palabra clave “class” no necesita ser mostrada sobre el nombre.

En la figura (6) se muestran las posibles representaciones de una clase, la cual a menudo es representada con tres compartimentos. El compartimento de en medio tiene una lista de atributos, mientras que el compartimento de abajo tiene una lista de operaciones.

Los atributos y las operaciones pueden ser presentados agrupados por su visibilidad. Pueden utilizarse compartimentos adicionales para mostrar otros detalles como las limitaciones o para dividir funciones.

Figura 6: Notación de clase. De [SUPE09], p.51.

Ventana

+ tamaño: Area = (100, 100) # visibilidad: Boolean = true

+ tamañodefault: Rectángulo

+ Desplegar () + Ocultar ()

Ventana

Ventana

Public tamaño: Area = (100, 100) + tamañodefault: Rectángulo Protegido

# visibilidad: Boolean = true

Public Desplegar () Ocultar ()


24

3.1.2.1.2 Dependencia

Una dependencia es una relación que significa que un elemento o un conjunto de elementos del modelo requieren otro elemento del modelo para su especificación o implementación. Esto significa que la semántica completa de la dependencia de elementos es dependiente semántica o estructuralmente de la definición de los elementos provistos.

3.1.2.1.2.1 Semántica Una dependencia significa una relación cliente-proveedor entre elementos del modelo, donde la modificación del proveedor puede impactar los elementos del modelo del cliente. Una dependencia implica que la semántica del cliente no es

completa sin el proveedor. La presencia de relaciones de dependencia en un modelo no tiene consecuencias semánticas en tiempo de ejecución. 3.1.2.1.2.2 Notación Una dependencia se muestra como una flecha punteada entre dos elementos del modelo como se muestra en la figura (7) en donde los elementos del modelo en la cola de la flecha (el cliente) dependen del elemento del modelo en la punta de la flecha (proveedor). La flecha puede ser etiquetada con un estereotipo opcional y un nombre opcional. Es posible tener un conjunto de elementos para el cliente o el proveedor. En este caso uno o más flechas con sus colas, los clientes son conectados a las colas de una o más flechas con las puntas en los proveedores.

Figura 7: Dependencia entre elementos. De [SUPE09], p.63.

3.1.2.1.3 Asociación

Una asociación binaria especifica una relación semántica que puede ocurrir entre clasificadores (incluye la posibilidad de una asociación de un clasificador a sí mismo).

Una asociación es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro. Dada una asociación entre dos clases, se puede navegar desde un objeto de una de ellas hasta uno de los objetos de la otra y viceversa. Es posible que la asociación se dé de manera recursiva en un objeto, esto significa que dado un objeto de la clase se puede conectar con otros objetos de la misma clase. También es posible, aunque menos

Cliente Proveedor

<<Nombre de la dependencia>>


25

frecuente, que se conecten más de dos clases, estas se suelen llamar asociaciones n-arias. Las relaciones de asociación se utilizan cuando se quieren representar relaciones estructurales.

Una asociación normal entre dos clases representa una relación estructural entre iguales, es decir, ambas clases están conceptualmente al mismo nivel. A veces interesa representar relaciones del tipo “todo/parte”, en las cuales una cosa representa la cosa grande (el “todo”) que consta de elementos más pequeños (las “partes”). Este tipo de relación se denomina de agregación la cual representa una relación del tipo “tiene-un”.

Una agregación es sólo un tipo especial de asociación, esta se especifica añadiendo simplemente un rombo vacío en la parte del todo.

Una composición es una variación de la agregación simple que añade una semántica importante. La composición es una forma de agregación, con una fuerte relación de pertenencia y vidas coincidentes de la parte del todo. Las partes con una multiplicidad no fijada puede crearse después de la parte que representa el todo (la parte compuesta), una vez creadas pertenecen a ella de manera que viven y mueren con ella. Las partes pueden ser eliminadas antes que el todo sea destruido pero una vez que este se elimine todas sus partes serán destruidas. El todo, además, se ha de encargar de toda la gestión de sus partes, creación, mantenimiento, disposición.

3.1.2.1.3.1 Semántica Una asociación declara que puede haber una relación entre instancias de los tipos de asociación. Una relación es una tupla con valor para cada extremo de la asociación, donde cada valor es una instancia del tipo del extremo.

Una asociación puede representar una agregación compuesta. Sólo asociaciones binarias pueden ser agregaciones. Una agregación compuesta es una forma fuerte de agregación en donde si es eliminada la composición, todas las partes de la composición son borradas con ella.

3.1.2.1.3.2 Notación Cualquier asociación puede ser dibujada como un diamante con una línea continua para cada extremo de la asociación, conectando el diamante al clasificador que es el

extremo del tipo. Una asociación con más de dos extremos puede ser sólo dibujada de esta manera.

Una asociación binaria normalmente es dibujada con una línea continua conectando dos clasificadores o una línea continua conectando a un solo clasificador al mismo. Una línea puede consistir de uno o más segmentos conectados. El segmento individual en si no tiene ningún significado semántico pero puede ser gráficamente significativa para una herramienta de arrastre o en cambiar el tamaño a un símbolo de asociación.


26

Una punto de flecha abierta en el extremo de una asociación indica el extremo es navegable. Una pequeña x en el extremo de una asociación indica que el extremo no es navegable.

En la figura (8) muestra las posibles representaciones de asociaciones de agregación o composición.

Figura 8: Tipos de asociaciones. De [SUPE09], p.43.

3.1.2.1.4 Generalización

3.1.2.1.4.1 Descripción Una generalización es una relación taxonómica entre un clasificador más general y uno más específico. 3.1.2.1.4.2 Semántica Donde una relación de generalización, relaciona un clasificador específico a un clasificador general, cada instancia del clasificador específico es también una instancia del clasificador general. Por lo tanto, características especificadas para instancias del clasificador general son implícitamente especificadas para instancias del clasificador específico. Cualquier restricción que se le aplique a instancias del clasificador general también se aplicará a las instancias del clasificador específico.

3.1.2.1.4.3 Notación Una generalización se muestra como una línea con un triángulo hueco, como una punta de flecha entre los símbolos que representan a los clasificadores involucrados. La punta de flecha apunta al símbolo que representa el clasificador general.

En la figura (9) se muestra la representación de generalización, donde se aprecia que se relacionan clasificadores específicos a un clasificador general, en donde la clase persona puede ser especializada como una persona femenina o persona masculina o puede ser especializada como un empleado.

A B Asociación Binaria AB

A B

A B


27

Figura 9: Ejemplo de generalización. De [SUPE09], p.74.

3.1.2.1.5 Interfaz

3.1.2.1.5.1 Descripción Una interfaz es un tipo de clasificador que representa una declaración de un conjunto coherente de características y funciones públicas. Una interfaz especifica un contrato, cualquier instancia de un clasificador que se dé cuenta de la interfaz debe cumplir con ese contrato.

Dado de que las interfaces son declaraciones las cuales no pueden ser instanciables. En su lugar, una especificación de interfaz es implementada por una instancia de un clasificador instanciable, lo que significa que el clasificador instanciable presenta una fachada pública que se ajusta a la especificación de interfaz. Se debe tener en cuenta que un clasificador dado puede implementar más de una interfaz y que una interfaz puede ser implementada por un número de diferentes clasificadores.

3.1.2.1.5.2 Notación Como un clasificador, una interfaz puede ser mostrada usando un símbolo en forma de rectángulo con la palabra clave <<interface>> que precede al nombre.

La dependencia de la realización de interfaz de un clasificador a una interfaz

se muestra mediante la representación de la interfaz como un circulo etiquetado con el nombre de la interfaz unida por una línea sólida al clasificador que se da cuenta de esta interfaz, lo anterior se puede apreciar en la figura (10).

Figura 10: Ejemplo de dependencia de la realización de un clasificador a una interfaz. De [SUPE09], p.87.

género

Persona

Empleado Persona Femenina

Persona

Masculina

género estatus

Sensor de Proximidad

ISensor


28

3.1.2.1.6 Diagramas

En la tabla (3) se muestra un resumen de los nodos gráficos así como las relaciones que pueden representarse en un diagrama de clases. Tabla 3. Elementos de un diagrama de clases. De [SUPE09], p.140 y 141.

Tipo de nodo / relación

Notación

Clase

Interfaz

Asociación

Agregación

Composición

Dependencia

Generalización

Realización de interfaz

Realización

Para mayor detalle sobre la descripción de cada uno de los elementos que integran a los DC, consultar el reporte de avance de tesis “Análisis de los metamodelos de DCU y DC del UML” que comprende el periodo de Septiembre a Diciembre de 2009.


29

3.2 Aplicación del método FODA En esta sección se presentan los resultados obtenidos tras la aplicación del método FODA sobre los diagramas de casos de uso (DCU) y los diagramas de clases (DC) del UML.

Cabe mencionar que la metodología FODA no fue utilizada en su totalidad, sino que se realizó una adaptación de la misma. La cual consiste en eliminar algunos de los modelos que no son útiles para analizar el dominio y por ende llevar a cabo la caracterización.

El reporte abarca las dos primeras fases del método FODA, debido a que la fase de modelado de arquitectura no se aplica a este dominio, y no se pretende crear

una arquitectura de software en este trabajo de investigación.

Las fases utilizadas de la metodología FODA son:

Análisis del contexto, en cuya fase se identificó el alcance del dominio, Para este trabajo el alcance son los modelos de DCU y DC.

Modelado de dominio, en cuya fase se identificaron las características distintivas de cada uno de los modelos de los DCU y DC, los cuales son representadas mediante un diagrama de características en el que se modelan características opcionales, obligatorias y alternativas de dichos modelos.

3.2.1 Análisis de Contexto En esta fase se definió el contexto del dominio, así como el alcance y las restricciones para los diagramas de casos de uso y diagramas de clases.

3.2.1.1 UML

UML es un lenguaje estándar que sirve para escribir los planos del software, puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema de software.

UML ayuda a interpretar sistemas mediante gráficos o texto, obteniendo

modelos explícitos que ayudan a la comunicación durante el desarrollo, ya que al ser estándar los modelos podrán ser interpretados por personas que no participaron en su diseño. En este contexto, UML sirve para especificar modelos concretos, no ambiguos y completos.

3.2.1.2 Ciclo de vida del software (UML)

Para esta investigación entendemos por ciclo de vida de un proyecto de software a todas las etapas por las que pasa un proyecto, desde la concepción de la idea que hace surgir la necesidad de diseñar un sistema de software, pasando por el análisis,


30

desarrollo, implantación, mantenimiento del mismo y hasta que finalmente es sustituido por otro sistema.

Teniendo en cuenta esto, el desarrollo de un sistema de software requiere ser visto desde diferentes perspectivas, ya que las personas involucradas en el desarrollo del software (usuario final, analistas, desarrolladores, integradores, jefes de proyecto...) siguen actividades en diferentes momentos del ciclo de vida del proyecto, lo que da lugar a diversas vistas del proyecto, dependiendo de qué interese más en cada instante de tiempo.

Es por ello que UML proporciona una variedad de diagramas, dependiendo de qué interese representar en cada momento, ya sea para ajustar el nivel de detalle o conocer los estados de un objeto, etc.

En la figura (11) se muestran las vistas que proporciona UML para el modelado de las diferentes vistas del desarrollo de un sistema.

Figura 11: Diagramas del UML De [SUPE09], p.601, 602 y 603.

En la figura (12) se aprecian las fases de desarrollo de software, así como los

modelos que intervienen en cada fase. Estas fases van del problema (abstracto) a la solución (concreto). Para propósitos de esta investigación sólo se presenta la ubicación de los diagramas de casos de uso y diagramas de clases en las fases de requerimientos y diseño respectivamente, cabe mencionar que en cada modelo pueden utilizarse más de un diagrama del UML, dependiendo de las necesidades del usuario.

Modelos

Diagramas de

casos de uso Diagramas de

clases

Diagramas de

objetos

Diagramas de

componentes

Diagramas de difusión

Diagramas de

actividades

Diagramas de estados

Diagramas de

colaboración

Diagramas de

secuencias


31

Figura 12: Diagrama de contexto de los DCU y DC.

3.2.1.3 Diagramas de casos de uso

Complementando la definición y descripción de los DCU presentada en el capítulo 2 “Marco Teórico” y capitulo 4 “Descripción de elementos utilizados” de esta tesis, un diagrama de casos de uso muestra los distintos requisitos funcionales que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones). Los diagramas sólo se limitan a representar la manera de usar el sistema sin revelar la estructura interna del mismo.

Análisis

Pruebas

Implementación

Diseño

Requerimientos

Modelo de

casos de uso

Modelo de

análisis

Modelo de

diseño

Modelo de

pruebas

Modelo de

implementación

Fases de desarrollo de software

Diagramas de

casos de uso

Diagramas de

clases

Problema

Solución

Diagramas de

difusión

Diagramas de

actividades

Diagramas de

estados

Diagramas de

colaboración

Diagramas de

secuencia

Diagramas de

objetos

Diagramas de

componentes


32

La utilización de este tipo de diagramas proporciona diversos beneficios como los que se mencionan a continuación.

Proporciona una forma para representar los requerimientos funcionales.

Ayuda a descomponer el sistema en partes más pequeñas y manejables.

Proporciona un lenguaje común entre los usuarios del sistema, el analista y el diseñador de sistemas.

Proporciona un medio para identificar, asignar, rastrear, controlar y gestionar las actividades para el desarrollo de sistemas.

3.2.1.4 Diagramas de clase

Complementando la definición y descripción de los DC presentada en el capítulo 2 “Marco Teórico” y capitulo 4 “Descripción de elementos utilizados” de esta tesis, los diagramas de clases son una potente herramienta de diseño, ayudando a los desarrolladores a planificar y establecer la arquitectura, estructura del sistema y subsistemas, antes de escribir cualquier código. Esto permite que el sistema esté bien diseñado desde el principio del proceso de desarrollo del software.

3.2.2 Modelado del Dominio

En esta fase se realizó un análisis a los diagramas de casos de uso y clases del UML, capturando en modelos de características, las características distintivas tanto de los elementos de DCU como de los DC del UML. En dichos modelos se muestran las características obligatorias, opcionales y alternativas de cada elemento que integra a dichos diagramas. Estas características son los atributos de los elementos y relaciones que integran tanto a los DCU como a los DC.

La simbología utilizada para la representación de características alternativas, opcionales y obligatorias es la siguiente:

Característica opcional.

Característica alternativa.

Característica obligatoria.


33

3.2.2.1 Diagrama de casos de uso.

3.2.2.1.1 Notación:

Tabla 4. Notación empleada para las características de los DCU.

ACTOR => actor

ACTORP => actor padre

ACTORH => actor hijo

ACTOR-ACTOR => relación entre dos actores

ACTOR-CU => relación entre un actor y un CU ASOCIACION => tipo de relación (asociación)

comp => comportamiento

compB => comportamiento propio del CUB

compE => comportamiento propio del CUE

compI => comportamiento propio del CUI CU => caso de uso

CUB => CU base

CUE => CU extensión

CUH => CU hijo

CUI => CU incluido

CUP => CU padre CU-CU => relación entre dos casos de uso

DCU => diagrama de casos de uso

D-CUB => elimina del caso de uso base

D-CUI => elimina del casos de uso incluido

E-compO => extendido por el comportamiento de CUO

externo => externo al sistema (sujeto) EXTENDS => tipo de relación (extend)

fc => fragmento de comportamiento

GENERALIZACION=>relación de

generalización

hardware => hardware externo (actor)

HP-ACTORP => herencia de las

propiedades del actor padre

HP-CUP=> herencia de las propiedades

del caso de uso padre humano => humano

I-compI => inclusión del comportamiento

del CUI INCLUDE => tipo de relación (include)

interactúa => interactúa con el sujeto de

tipo booleano interno => interno la sistema

nombre => nombre único

otro tipo => otro tipo de actor

P-ACTOR => participación del actor.

pe => punto de extensión RELACION => elemento de los DCU

representa => representa

Rest => Restricción

rol => especifica un rol

tipo => tipo de elemento

ubicación => lugar de ubicación del actor

3.2.2.1.2 Definición de la notación:

ACTOR: especifica un rol desempeñado por un usuario o por cualquier otro sistema que interactúa con el sistema. ACTORP: actor padre, desempeña un rol dentro de un DCU. ACTORH: actor hijo, en una relación de generalización el actor de tipo hijo hereda las propiedades del actor de tipo padre, lo que significa que el actor hijo puede relacionarse con el conjunto de casos de uso con los que se relacione el actor padre. ASOCIACION: la relación de asociación define que dos elementos pueden comunicarse entre sí. ASOC-A-CU: indica la relación entre un actor y un caso de uso, es decir, un actor participa de manera activa en el caso de uso. comp: indica la existencia de comportamiento.


34

compB: indica que existe un comportamiento que pertenece a un CUB. compE: indica que existe un comportamiento que pertenece a un CUE. compI: indica que existe un comportamiento que pertenece a un CUI. CU: un caso de uso es la especificación de un conjunto de acciones (comportamiento) desempeñadas por un sistema, que produce un resultado observable que es típicamente, de valor para uno o más actores o para las personas involucradas en el desarrollo del software (usuario final, analistas, desarrolladores, integradores, jefes de proyecto...) de un sistema. CUB: indica que un caso de uso es base en una relación (include, extends) y este caso de uso será extendido por el comportamiento del CUE o incluirá el comportamiento del CUI, en cuyo caso este caso de uso dependerá del resultado del CUI. Así mismo el significado de este caso de uso base, dependerá del tipo de relación (extend o include) a la que pertenezca este caso de uso. CUH: representa un caso de uso hijo en una relación de generalización, el cual hereda la estructura y comportamiento del caso de uso padre. CUE: es un caso de uso extensión en una relación extends, consiste de uno o más fragmentos de comportamiento que han de ser utilizados tanto para extender un caso de uso de tipo base en una relación extends. CUI: es un caso de uso incluido que pertenece a una relación de tipo include, contiene su propio comportamiento, el cual puede ser incluido en el comportamiento de un caso de uso base. CUP: indica que un caso de uso es de tipo padre, el cual comparte su estructura y comportamiento con un caso de uso de tipo hijo. DCU: Son un medio para capturar los requerimientos de un sistema, esto es, lo que se supone que un sistema debe hacer. Los conceptos utilizados son: casos de uso, actores y relaciones. D-CUB: eliminación de un caso de uso de tipo base, forma parte de la restricción de una relación de tipo include.

DE-CUI eliminación de un caso de uso incluido, forma parte de la restricción de eliminación de un caso de uso de tipo base. E-compE: indica que es extendido por el comportamiento que pertenece a un CUE. EXTENDS: la relación extend especifica cómo y cuándo el comportamiento definido en el caso de uso extensión puede ser insertado dentro del comportamiento del caso de uso extendido (base). externo: representa la característica de ubicación, la cual indica que el actor debe de ser externo al sistema (sujeto).


35

fc: fragmentos de comportamiento que han de ser insertados en el caso de uso de tipo destino. GEN-ACTORES: indica la relación entre dos actores GEN-CU: indica la relación entre dos casos de uso GENERALIZACION: es una relación entre un elemento más general con un elemento más especifico, lo que implica que el caso de uso más especifico (hijo) hereda todos los atributos, secuencias de comportamiento, puntos de extensión y relaciones definidos en el caso de uso más general (padre) con el que se relaciona. hardware: representa un tipo de actor, en este caso un hardware externo (actor). HP-ACTORP : indica herencia de las propiedades de un actor padre a un actor hijo. Es decir, el actor hijo podrá desempeñar el mismo rol que el actor padre (comunicarse con el mismo conjunto de casos de uso con los que el actor padre se comunica) HP-CUP: representa la característica de herencia, indica que un caso de uso hereda las propiedades de un caso de uso padre, ambos pertenecientes a una relación de generalización. I-compI: indica la inclusión del comportamiento que pertenece a un CUI en el comportamiento de un CUB. INCLUDE: la relación include define que el comportamiento definido en el caso de uso incluyente es incluido en el comportamiento del caso de uso base. interactúa: representa la característica de interacción entre un actor y el sujeto. interno: representa la característica de ubicación, la cual indica si un actor es interno o no al sistema (sujeto). nombre: los elementos de los DCU deben tener un nombre único distinguible de los demás. otro tipo: representa un tipo de actor diferente a un humano o hardware externo. P-ACTOR: denota la participación del actor para la realización de un caso de uso o de otro actor. pe: un punto de extensión identifica un punto en el comportamiento de un CU donde el comportamiento puede ser extendido por el comportamiento de algún otro caso de uso. RELACION: la relación es una posible interacción entre elementos utilizados para modelar usando UML.


36

representa: esta característica puede tomar los valores que puede representar un actor. Rest: indica la existencia de restricción. rol: indica la existencia de un rol dentro del sistema. tipo: indica que un elemento de los DCU puede ser de un tipo de elemento en especifico. ubicación: esta característica representa la ubicación del actor dentro del sistema.


37

3.2.2.1.3 Diagrama de características:

Figura 13: Diagrama de características de los CU

En la figura (13) se representan las características que pertenecen al

elemento caso de uso (CU), en la cual se pueden observar características obligatorias, opcionales y alternativas para este elemento, en esta figura se aprecia entre otras características, que el elemento caso de uso debe contar con un nombre obligatorio.

Figura 14: Diagrama de características de los actores

En la figura (14) se representan las características que pertenecen al elemento actor (ACTOR), en la cual se pueden observar características obligatorias y alternativas para este elemento, en esta figura se aprecia entre otras características, que el elemento actor debe contar con un nombre obligatorio y un rol a desempeñar.

CU

nombre pe fc comp

rol

ACTOR

nombre

humano

representa

hardware otro tipo

ubicación

externo interno

interactúa

true false


38

Figura 15: Diagrama de características de los tipos de relaciones

En la figura (15) se representan las características que pertenecen al elemento relación (RELACION), en la cual se

pueden observar características obligatorias, opcionales y alternativas para este elemento, en esta figura se aprecia entre otras características, que el elemento relación debe ser de algún tipo de relación y tomar el valor de alguna de las opciones disponibles para los diagramas de casos de uso.

GENERALIZACION

nombre tipo

CUP CUH

GEN-CU GEN-ACTORES

ACTORP ACTORH

HP-CUP HP-ACTORP

INCLUDE

CUB CUI

compB

I-compI

EXTENDS

CUB CUE

compB

E-compE

Rest

D-CUB

D-CUI

ASOCIACION

CU ACTOR

ACTOR-CU ASOC-ACTORES

ACTOR ACTOR-2

P-ACTOR P-ACTOR

compI compE

RELACION


39

Figura 16: Diagrama de características de los DCU (elementos principales)

En la figura (16) se representan las características que pertenecen a los diagramas de casos de uso (DCU), en la cual se pueden observar características obligatorias para este tipo de diagramas, en esta figura se aprecia entre otras características, que los diagramas de casos de uso deben tener elementos como son: casos de uso, actor y relaciones.

DCU

CU ACTOR RELACION


40

3.2.2.2 Diagrama de clases.

3.2.2.2.1 Notación

Tabla 5. Notación empleada para las características de los DC.

ABS => abstracto

AGREGACION => relación de agregación ASOCIACION => relación de asociación

ATRIBUTO => atributo de clase

CLASE => clase (tipo de clasificador)

CLC => clase de tipo cliente

CLCOM => clase compuesta

CLP => clase proveedor COMPOSICION => relación de

composición

CONC => concreta

CLCOMP => clase componente

CL1 => clase 1

CL2 => clase 2 DC => diagrama de clases

DEP/REAL => relación de

dependencia/realización

DF => visibilidad por defecto (publica)

DE-CLP => depende de los elementos de la clases proveedor

dirección => dirección de parámetro

D-CLCOM => eliminación de CLCOM

D-CLCOMP => eliminación de CLCOMP

GEN/ESP => relación de generalización

/especialización HP-SPCL => hereda propiedades de la

superclase

IE-CLP => implementación de los

elementos de la clase

proveedor. in => entrada

inout => entrada y salida

INT => interfaz modificadores => modificador del elemento

multiplicidad => multiplicidad del elemento

ND-CLCOMP => no se elimina la CLCOMP

nombre => nombre del elemento

OPERACION => operación de una clase

ordered => valor de retorno ordenado OT => otro tipo de dato

out => salida

PAQ => visibilidad de paquete

PARAMETRO => parámetro de método

PRIV => visibilidad privada

PROT => visibilidad protegida PUB => visibilidad publica

query => operación de sólo búsqueda

readOnly => sólo lectura

redefines => redefinir una característica

RELACION => elemento relación del DC RE-CL1 => relación con los elementos de la

clase 1

RE-CL2=> relación con los elementos de la

clase 2

Rest => restricciones

SBCL => subclase SPCL => superclase

tipo => tipo del elemento

unique => valor de retorno único

valor-DF => valor por defecto

visibilidad => visibilidad del elemento

3.2.2.2.2 Definición de la notación:

ABS: característica de abstracción del método o clase. AGREGACION: relación de agregación, muestra cómo los elementos más complejos se construyen de una colección de elementos simples. ASOCIACION: representa una relación de asociación, define una relación semántica que puede ocurrir entre tipos de instancias, determina que los objetos de una clase están relacionados con elementos de otra clase.


41

ATRIBUTO: describe una característica que las instancia de la clase pueden tener, es definido por un nombre y un tipo. Adicionalmente un atributo puede tener propiedades como visibilidad, multiplicidad, valor inicial y otras propiedades. CLASE: describe un conjunto de objetos que comparten las mismas especificaciones de características, restricciones y semántica. Las características de una clase son los atributos y operaciones. CLC: clase cliente, es la clase que solicita servicios a las clases proveedoras (representa la implementación). CLCOM: representa una clase compuesta, la cual puede estar compuesta por una o más clases componente (CLCOMP). CLP: clase proveedor, es la clase que proporciona los servicios a las clases cliente (representa la especificación). CLCOMP: representa una clase componente, la cuál es utilizada como componente en una clase compuesta en una relación de agregación o composición. CL1, CL2: representa dos clases diferentes no especificando sus características CONC: indica que una clase es de tipo concreta, es decir, estas clases proveen implementación a cada método o propiedad que definen. COMPOSICION: relación de composición, se usa para describir que un elemento está hecho de componentes más pequeños. Si se elimina una clase compuesta, usualmente todas sus piezas se eliminan con ella; sin embargo, se puede quitar individualmente una parte de la composición sin tener que eliminar la composición entera. DC: diagrama de clases, es una grafica de clasificadores conectados por varios tipos de relaciones. Un DC puede también contener interfaces. Describe la estructura estática de un sistema o parte de un sistema. DEP/REAL: es una relación que significa que un elemento o conjunto de elementos del modelo requieren de otro elemento o elementos para su especificación o realización. Es decir una dependencia significa una relación cliente-proveedor entre elementos del modelo, donde la modificación del proveedor puede impactar los elementos del modelo del cliente. DE-CLP: representa la existencia de dependencia de la clase proveedor. DF: representa el tipo de visibilidad por defecto (pública). dirección: indica la dirección del parámetro de una operación. D-CLCOM: representa la eliminación de una clase compuesta, en la cual, pueden o no eliminarse las clases que la componen, dependiendo de la relación en la que participe la clase compuesta (agregación o composición).


42

D-CLCOMP: representa la eliminación de una clase componente, siempre y cuando la clase compuesta que participa en una relación de composición sea eliminada. GEN/ESP: es una relación taxonómica entre clasificadores generales y específicos. Cuando se establece una relación de este tipo entre dos clases, una es una superclase y la otra es una subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber más de una clase que se comporte como subclase. HP-SPCL: representa las propiedades de la superclase (métodos, atributos, etc.) IE-CLP: esta característica representa la implementación de los elementos (servicios) de la clase proveedor. in: indica si el parámetro es de entrada. inout: indica si el parámetro es de entrada y salida. INT: es un tipo de clase, representa la declaración de un conjunto de características y obligaciones públicas. Una interface especifica un contrato y cualquier instancia de un clasificador que realice la interface debe cumplir con el contrato. modificador: representa un modificador que afecta a la naturaleza del parámetro, atributo y operación. multiplicidad: es la definición de un intervalo que incluye números enteros no negativos, empezando con un número que representa el límite inferior y terminando con otro número que representa el límite superior (posiblemente infinito). Un elemento de multiplicidad especifica la cardinalidad disponible para una instancia de este elemento. Cuando se omite este término implica una multiplicidad de exactamente 1. ND-CLCOMP: indica que no se eliminará la clase componente en caso de que se elimine la clase compuesta a la que se relaciona. nombre: representa el nombre único que identifica a un elemento del diagrama de clase. OPERACIÓN: es una característica del comportamiento de una clase que especifica el nombre, tipo, parámetros y restricciones para invocar un comportamiento asociado. ordered: significa que el valor del parámetro de retorno es ordenado. OT: son otros tipos de datos o modificadores disponibles para el elemento, dependiendo del lenguaje de programación. out: indica si el parámetro es de salida.


43

PAQ: representa el tipo de visibilidad, en este caso la visibilidad es de paquete. Indica que el elemento es visible para aquellas clases que son declaradas dentro del mismo paquete.

PARAMETRO: es la especificación de un argumento usado para pasar información dentro y fuera de una invocación de una característica de comportamiento, este tiene un tipo y puede tener multiplicidad y opcionalmente un valor por defecto.

PRIV: representa el tipo de visibilidad privada, lo cual indica que el elemento será accesible desde dentro de la clase.

PROT: representa el tipo de visibilidad protegida, lo cual indica que el elemento no será accesible desde fuera de la clase, pero si podrá ser manipulado por métodos de la clase y de sus subclases.

PUB: representa el tipo de visibilidad pública, lo que indica que el elemento será visible tanto fuera como dentro de la clase, es decir, es accesible desde todos lados.

query: significa que la operación no cambia el estado del sistema.

readOnly: indica que la característica es de sólo lectura.

redefines: significa que redefine una característica heredada, identificada por un nombre.

RELACION: representa al elemento relación del DC.

Rest: indica las restricciones que se aplican a los elementos de los DC.

RE-CL2: Relaciona con los elementos de la clase 2.

RE-CL1: Relaciona con los elementos de la clase 1.

SBCL: representa una subclase o clase derivada que hereda la estructura y comportamiento de una clase base.

SPCL: representa una superclase, la cual tiene un nivel de abstracción mayor a la de la SBCL.

tipo: representa el tipo de un elemento del DC, el cual puede tomar diferentes valores dependiendo del lenguaje de programación (datos simples o compuestos).

unique: significa que el valor regresado por el parámetro no tiene duplicados.

valor-DF: es una expresión que evalúa el valor por defecto o valores de la propiedad.

visibilidad: determina la característica de visibilidad de los elementos en un modelo.

{byte, boolean, char, doublé, float e int}: son tipos de datos que definen los métodos de almacenamiento disponibles para representar información.


44

3.2.2.2.3 Diagrama de características

Figura 17: Diagrama de características de los DC (elementos principales).

En la figura (17) se representan las características que pertenecen a los

diagramas de clases (DC), en la cual se pueden observar características obligatorias y opcionales para este tipo de diagramas. En esta figura se aprecia entre otras características, que los diagramas de clases deben tener los siguientes elementos obligatorios: clases y relaciones, así como de interfaz (INT) como elemento opcional.

Figura 18: Diagrama de características de las clases.

En la figura (18) se representan las características que pertenecen al elemento clase (CLASE), en la cual se pueden observar características obligatorias, opcionales y alternativas para este elemento. Se aprecia entre otras características, que el elemento clase debe contar con un nombre obligatorio así como atributos y operaciones opcionales.

CLASEAS

OPERACIONERACIONES

nombre ATRIBUTO tipo

CONCR

ABS

DC

CLASE RELACION INT


45

Figura 19: Diagrama de características de los atributos.

En la figura (19) se representan las características que pertenecen al elemento atributo (ATRIBUTO), en la cual se observan características obligatorias, opcionales y alternativas para este elemento. Se aprecia que el elemento atributo debe contar con un nombre, visibilidad y tipo de manera obligatoria, así como la característica de multiplicidad la cual es opcional.

ATRIBUTO

nombre multiplicidad valor-DF modificador

readOnly redefines

unique OT

visibilidad

PUB PROT PRIV PAQ DF

tipo

OT int float byte double boolean char


46

int redefines ABS OT

Figura 20: Diagrama de características de las operaciones.

En la figura (20) se representan las características que pertenecen al elemento operación (OPERACION), se observan características obligatorias, opcionales y alternativas para este elemento. Se aprecia que el elemento operación debe tener un nombre y visibilidad de manera obligatoria, así como parámetros opcionales.

OPERACIONERACIONES

nombre PARÁMETRO visibilidad

PUB PROT PRIV PAQ DF

tipo-retorno

void float byte double boolean char OT

propiedad

query ordered unique


47

valor-DF nombre dirección

in inout out DF

tipo

OT int float byte double boolean char

modificador

readOnly redefines

unique OT

Figura 21: Diagrama de Características de los parámetros.

En la figura (21) se representan las características que pertenecen al elemento parámetro (PARAMETRO), en la cual se observan características obligatorias, opcionales y alternativas para el elemento. En donde el parámetro debe contar con un nombre y tipo de parámetro de manera obligatoria, así como las características de dirección y modificador las cuales son opcionales.

PARAMETRO


48

Figura 22: Diagrama de características de las relaciones de los DC.

En la figura (22) se muestran las características que pertenecen al elemento relación (RELACION), se observan

características obligatorias, opcionales y alternativas para el elemento. En donde el elemento relación debe ser definido de algún tipo de relación en especifico, así como el elemento relación puede o no tener un nombre que lo identifique.

GEN/ESP

SPCL SBCL

HP-SPCL

RELACION

nombre tipo

ASOCIACION

CL1 CL2

RE-CL2 RE-CL1

COMPOSICION

CLCOM CLCOMP

CLCOMP

Rest

D-CLCOM

D-CLCOMP

DEP/REAL AGREGACION

CLCOM CLCOMP Rest

D-CLCOM

ND-CLCOMP


49

Figura 23: Diagrama de características de la relación de dependencia/realización.

La figura (23) muestra las características que pertenecen a la relación dependencia/realización (DEP/REAL), en la cual se observan características obligatorias y opcionales, se aprecia que la relación debe estar compuesta por dos clases (cliente y proveedor), en donde la clase cliente depende de los elementos de la clase proveedor y puede o no implementar los elementos de la clase proveedor.

DEP/REAL

CLC CLP

DE-CLP

IE-CLP


50

3.3 Formalización En esta sección se describe la formalización realizada a los diagramas de características de los elementos que integran a los DCU y a los DC del UML. Cabe mencionar que dicha formalización se realizó mediante el lenguaje de especificación formal Z, el cual está basado en lógica, conjuntos, relaciones y funciones, permitiendo definir los elementos y la semántica de los DCU y DC, logrando con ello que UML cuente con un sentido formal, una mejor claridad en los modelos, eficiencia, consistencia y extensibilidad del UML.

3.3.1 Diagramas de Casos de Uso

3.3.1.1 Declaraciones

Para formalizar los Diagramas de Casos de Uso se cuentan con las siguientes declaraciones:

Tipos básicos:

[Verbo] El conjunto de todos los posibles verbos identificables de manera única.

[Sustantivo] El conjunto de todos los posibles sustantivos identificables de manera única.

[PE] El conjunto de todos los posibles puntos de extensión de comportamiento identificables de manera única.

[FC] El conjunto de todos los posibles fragmentos de comportamiento identificables de manera única.

[Comportamiento] el conjunto de todos los posibles comportamientos de los casos de uso.

Tipos compuestos:

[NomCU] ==[Verbo]x[Sustantivo]


51

3.3.1.2 Esquema CU

El siguiente esquema contempla las características que pertenecen a un CU.

Donde las declaraciones:

nombre : NomCU

“nombre” es declarada como variable extraída del conjunto NomCU (con la finalidad de asignarle un único nombre al CU).

fc : ℙ FC

“fc” denota el subconjunto de los fragmentos de comportamiento existentes para el caso de uso.

pe : ℙ PE

“pe” denota el subconjunto de los puntos de extensión existentes para el caso de uso.

comp : Comportamiento

“comp” es declarada como variable extraída del conjunto Comportamiento (con la finalidad de asignarle un comportamiento al CU). Donde los predicados

nombre ≠{Ø} Hace referencia a la característica obligatoria que indica que cada caso de uso en un DCU debe contar con un nombre.

comp’= ((comp ˅ pe) ˄ fc={Ø} ˄ # pe ≥ 1) ˅ ((comp ˅ fc) ˄ pe={Ø} ˄ # fc ≥ 1) ˅ comp

Hacen referencia al comportamiento que el caso de uso (comp) tendrá, lo cual es equivalente a un “o excluyente” debido a que el caso de uso sólo puede tener uno de estas tres opciones y no dos o más al mismo tiempo.

CU .

nombre : NomCU

fc : ℙ FC

pe : ℙ PE comp : Comportamiento

nombre≠{Ø}

comp’= ((comp ˅ pe) ˄ fc={Ø} ˄ # pe ≥ 1) ˅ ((comp ˅ fc) ˄ pe={Ø} ˄ # fc ≥ 1) ˅ comp

˄ ¬ ((comp ˅ pe) ˄ fc={Ø} ˄ # pe ≥ 1) ˄ (((comp ˅ fc) ˄ pe={Ø} ˄ # fc ≥ 1) ˅ comp)

¬ ((comp ˅ fc) ˄ pe={Ø} ˄ # fc ≥ 1) ˄ (((comp ˅ pe) ˄ fc={Ø} ˄ # pe ≥ 1) ˅ comp) ˄ ¬ comp ˄ (((comp ˅ pe) ˄ fc={Ø} ˄ # pe ≥ 1) ˅ ((comp ˅ fc) ˄ pe={Ø} ˄ # fc ≥ 1))


52

1. El comportamiento del caso de uso (comp), no contará con fragmentos de comportamiento y el comportamiento del caso de uso es igual a la unión del comportamiento del caso de uso y los puntos de extensión, lo que es equivalente a un “o inclusivo” en el que el comportamiento del caso de uso es igual al comportamiento propio del caso de uso destino o los puntos de extensión o ambos.

2. El comportamiento del caso de uso (comp), no contará con puntos de

extensión y el comportamiento del caso de uso es igual a la unión del comportamiento del caso de uso y los fragmentos de comportamiento, lo que es equivalente a un “o inclusivo” en el que el comportamiento del caso de uso es igual al comportamiento propio del caso de uso origen o los fragmentos de comportamiento o ambos.

3. El comportamiento del caso de uso es igual al comportamiento sin puntos

de extensión y sin fragmentos de comportamiento. Para mayor detalle de la formalización de cada uno de los diagramas de

características de los elementos que integran a los DCU consultar el reporte de avance de tesis que comprende el periodo de Enero a Abril del 2010.

3.3.2 Diagrama de Clases

3.3.2.1 Declaraciones

Para formalizar los diagramas de clases se cuentan con las siguientes declaraciones: Tipos básicos:

[NomCL] : Es el conjunto de todos los nombres (sustantivos) identificables de manera única, válidos para las clases que pertenecen a un DC.

[NomOP] : Es el conjunto de todos los nombres válidos identificables de manera única para las operaciones que pertenecen a una clase.

Tipos libres:

[TipoClase] ::= abstacta|concreta


53

3.3.2.2 Esquema CLASE

El siguiente esquema contempla las características que pertenecen a las clases.

Donde las declaraciones:

nombre : NomCL

“nombre” es declarada como variable extraída del conjunto NomCL (con la finalidad de asignarle un único nombre a la clase).

atributos : ℙ ATRIBUTO

“atributos” denota el conjunto de los atributos disponibles para la clase.

At. At1 : atributos

“At, At1” son declaradas como variables extraídas del conjunto atributos.

operaciones : ℙ OPERACION

“operaciones” denota el conjunto de las operaciones disponibles para la clase.

Op, Op1 : operaciones

“Op, Op1” son declaradas como variables extraídas del conjunto operaciones.

tipo: TipoClase

“tipo” es declarada como variable extraída del conjunto TipoClase (con la finalidad de asignarle un tipo a la clase)

CLASE .

nombre : NomCL

atributos : ℙ ATRIBUTO At, At1 : atributos

operaciones : ℙ OPERACION

Op, Op1 : operaciones tipo: TipoClase

nombre≠{Ø}

∀ At, At1 ∈ atributos | At.nombre=At1.nombre ⇒ At=At1

∀ Op, Op1 ∈ operaciones | Op.nombre=Op1.nombre ⇒ Op=Op1

tipo=abstracta ˅ tipo=concreta ˄ ¬ (tipo=abstracta ˄ tipo=concreta)

tipo= abstracta ⇒ Ǝ Op OperacionAbstracta(Op)

tipo= concreta ⇒ ∀ Op OperacionConcreta(Op)

{At, At1} ⊆ atributos ≡ (At ∈ {At, At1} ⇒ At ∈ atributos)

{Op, Op1} ⊆ operaciones≡ (Op ∈ {Op, Op1} ⇒ Op ∈ operaciones)


54

Donde los predicados:

nombre ≠{Ø} Hace referencia a la característica obligatoria que indica que cada clase debe contar con un nombre.

∀ At, At1 ∈ atributos | At.nombre=At1.nombre ⇒ At=At1

∀ Op, Op1 ∈ operaciones | Op.nombre=Op1.nombre ⇒ Op=Op1

Hace referencia a la unicidad de los atributos y operaciones definidos para la

clase.

tipo=abstracta ˅ tipo=concreta ˄ ¬ (tipo=abstracta ˄ tipo=concreta)

Hace referencia a la unicidad del tipo de clase, es decir, una clase puede

tener un sólo tipo, ya sea de tipo abstracta o concreta, pero no ambas al mismo tiempo.

tipo= concreta ⇒ ∀ Op OperacionConcreta (Op) tipo= abstracta ⇒ Ǝ Op OperacionAbstracta(Op)

Define que por lo menos existe una operación abstracta en una clase cuando

la clase es definida de tipo abstracta y que todos los métodos son concretos en caso de que sea definida de tipo concreta.

{Op, Op1} ⊆ operaciones≡ (Op ∈ {Op, Op1} ⇒ Op ∈ operaciones)

{At, At1} ⊆ atributos ≡ (At ∈ {At, At1} ⇒ At ∈ atributos) Afirman que el conjunto de los atributos y operaciones extraídos del conjunto

atributos y operaciones son un subconjunto del conjunto de atributos y operaciones definidos para el DC.

Para mayor detalle de la formalización de cada uno de los diagramas de características de los elementos que integran a los DC consultar el reporte de avance de tesis que comprende el periodo de Enero a Abril del 2010.

3.4 Mecanismo de Comparación En esta sección se presenta el mecanismo utilizado para comparar los elementos de los diagramas de casos de uso (DCU) y diagramas de clases (DC) del UML, con la finalidad de establecer una relación de semejanza entre los elementos de dichos diagramas.

Se presentan los resultados obtenidos al aplicar el mecanismo de comparación, siendo el principal objetivo de este trabajo de investigación, observar si existe semánticamente relación entre los elementos de los DCU y los DC, es decir, identificar si los elementos (casos de uso, actores, relaciones) de los DCU pueden ser potencialmente clases, métodos, atributos y/o relaciones de los DC. Además explicar de manera racional la existencia o falta de relación entre los elementos de los DCU y DC.


55

3.4.1 Comparación entre elementos

La comparación entre los elementos de los DCU y DC se llevó a cabo de manera manual debido a que se requería analizar las características y semántica de cada elemento que integra a los DCU y DC, haciendo de esto un análisis heurístico con la finalidad de descubrir la existencia de relación semántica entre dichos elementos.

En la figura (24) se ilustra el procedimiento que se llevó a cabo para comparar los elementos de los DCU y DC, del cual se obtuvo como resultado la explicación racional del porqué de la existencia o falta de relación entre dichos elementos, la cual es descrita a continuación.

Se realizó un análisis heurístico a los diagramas de características obtenidos

al aplicar el método FODA a los DCU y DC del UML con la finalidad de observar y cotejar características en común entre los elementos de un diagrama en otro.

Sin embargo se consideró que era necesario contar con mayor información por lo cual se analizó la descripción, las restricciones y la semántica de cada elemento descrito en la superestructura de dichos diagramas, así como los resultados de algunas investigaciones realizadas, siendo las más destacadas las siguientes publicaciones: [JAIV03], [HCKT07] y [LIAY03], con el objetivo de contar con una mayor descripción de los elementos que comprenden los DCU y DC.

El resultado de esta serie de análisis fue la creación de tablas comparativas de cada elemento de los DCU y DC, las cuales son complemento del análisis FODA (diagramas de características obligatorias, opcionales y alternativas de cada elemento que integran a los DCU y DC). Dichas tablas fueron analizadas heurísticamente, lo que permitió descubrir características similares entre elementos de cada diagrama, dichas características se presentan más adelante.

Figura 24. Procedimiento de comparación heurística.

3.4.1.1 Comparación entre CU, Actor, Clase, Operación y Atributo

Los elementos analizados en esta sección son: casos de uso, actores, clases,

métodos y atributos de los DCU y DC. Para esto se utilizaron los diagramas de características de CU, ACTOR, CLASE, OPERACIÓN y ATRIBUTO así como las características obtenidas de la descripción, restricciones y semántica de cada elemento descrito en la superestructura de dichos diagramas del UML (ver capitulo 3), en [JAIV03], [HCKT07] y [LIAY03] complementado la descripción de los elementos.

Análisis

Diagramas

Características

DCU y DC

Creación

Tablas

Comparativas

Análisis

Semántica de

elementos

DCU y DC

Análisis

Tablas

Comparativas


56

Tabla 6. Características de CU, Actor, Clase, Operación y Atributo de la superestructura.

Elemento Composición

Nombre Objetivo

Se compone

de

Tipo Clasificador

Tipo Se relaciona

con Observación Similitud

CU verbo +

sustantivo

Especificar un

conjunto de acciones

(comportamiento)

desarrolladas por un sistema.

Objetivo y Escenarios

Comportamiento. Restringido a

casos de uso

Abstracto o

concreto

CU y actores (Asociaciones

binarias)

Las acciones

recaen sobre una entidad

para lograr un objetivo.

Clase y Operación

Clase sustantivo

Describir un conjunto de objetos que

comparten las misma

especificación de características, restricciones y

semántica

Atributos y operaciones

Estructura. Restringido a

clases

Abstracto o

concreto.

Clases (Asociaciones

binarias)

Es una entidad que

participa para lograr un objetivo

CU

Operación verbo

Definir un comportamiento de una clase de

objetos

Atributos y Parámetros

---

Abstracto no

Abstracto

Operaciones

Representa un comportamiento sobre una

entidad

Característica de

comportamiento (acciones de un

CU)

Atributo sustantivo

Describir característica de

una clase de objetos

Propiedades

y modificado-

res

--- --- --- Característica

de clase

CU, atributos de tipo definidos

por el usuario o clase o de tipo

primario

Actor sustantivo interactuar con

el sistema Rol

Comportamiento. Restringido a

actores

Abstracto o

concreto

CU, Actor, Componentes

y Clases (Asociaciones

binarias)

Representa una entidad

que interactúa con el sujeto

relevante para un caso de

uso. Externo al

sistema

---


57

En la tabla (6) se presentan las características de los elementos de DCU y DC con la finalidad de analizar la semántica de los elementos de dichos diagramas, poniendo énfasis en las similitudes que se presentan entre los elementos, con la finalidad de mapear aquellos elementos de los DCU (caso de uso, actores) que tengan relación semántica con los elementos de los DC (clases, operaciones o atributos).

Una vez analizadas estas características se observó lo siguiente.

Los casos de uso cuentan con un nombre obligatorio (objetivo del caso de uso) [SUPE09], el cual de acuerdo con [HCKT07] y [LIAY03] está compuesto por un verbo seguido por un sustantivo, cuyo nombre implica un comportamiento que recae sobre una entidad (sustantivo).

Analizando la semántica del nombre del CU se aprecia que tiene similitud con una clase debido a lo siguiente:

El verbo explícito en el nombre del CU implica una acción (comportamiento) a ser desarrollada por el sujeto (sustantivo), lo cual es similar a la operación (comportamiento) de una clase (sustantivo), en la que se define precisamente el comportamiento de la clase.

Como se puede apreciar ambos (caso de uso y clase) tienen explícitamente

características de comportamiento el cual recae sobre una entidad. Por tal motivo, una entidad identificada en el objetivo del caso de uso (sustantivo) puede ser mapeada a las definiciones de clases en el DC y a su vez, el verbo explícito en el objetivo del caso de uso también puede ser mapeado como un método de la clase representada por el sustantivo del caso de uso. Algunas otras similitudes entre casos de uso y clases son:

o Son clasificadores, uno de comportamiento y el otro de estructura. o Pueden ser abstractos o concretos [JAIV03]. o En los CU las acciones recaen sobre una entidad, en donde al igual

que las clases (entidad) ambas participan dentro del sistema para lograr un objetivo.

Por lo anterior se deduce que semánticamente un sustantivo explícito en el

nombre del caso de uso puede ser potencialmente una clase en el DC final (diagrama de clases que cumple por completo los requerimientos del usuario), esto se puede apreciar en la figura (25) en donde se ilustra las propiedades del nombre de un caso de uso, las cuales son mapeadas a una clase que posteriormente pertenecerá al DC final.

Figura 25: Mapeo de entidad y verbo a clase y operación.

Verbo Operación

Entidad Entidad


58

Por otra parte, se considera que el elemento actor a pesar de ser una entidad que está presente y participa en el DCU, éste no puede ser mapeado como una clase en los DC, debido a que es una entidad externa al sistema, siendo que los DC modelan sólo la estructura estática e interna del sistema y el actor sólo interactúa con el sujeto (entidad no necesariamente física), sin embargo, el actor al igual que en los diagramas de casos de uso también puede relacionarse con clases por lo que pudiera ser mapeado tal como se presenta en un diagrama de casos de uso (ver la notación del elemento actor); esto se puede apreciar en la figura (26) en donde se ilustra que no es posible mapear el nombre del actor al nombre de una clase que posteriormente pertenecerá al DC final.

Figura 26: Entidad en un actor no puede ser mapeada a clase.

También se considera que es posible identificar atributos de clase siempre y

cuando el objetivo del caso de uso (nombre) sea descrito con un nivel de detalle suficiente que permita atribuirle características a alguna entidad en específico.

3.4.1.2 Comparación entre las relaciones pertenecientes a los DCU y DC.

En esta sección se analizan las características de las relaciones definidas para los DCU y DC, se utilizaron los diagramas de características de ASOCIACION, GENERALIZACION, INCLUDE, EXTENDS de los DCU y ASOCIACION, COMPOSICION, AGREGACION, DEP/REAL Y GEN/ESP de los DC (ver capitulo 3), así como las características obtenidas de la descripción, restricciones y semántica (tabla 7 y 8) de cada relación descrita en la superestructura de dichos diagramas del UML.

Entidad Entidad


59

Tabla 7. Características de las relaciones de los DCU y DC.

Tipo de relación

Especifica Implica Relaciona/Asociación Restricción Similitud

Asociación (DCU)

Dos elementos pueden comunicarse entre sí.

Participación activa de un elemento en

otro. Actor-CU y Actor-Actor Asociación binaria ---

Generalización (DCU)

Relación entre un elemento general con un elemento

especifico.

El elemento especifico hereda las

propiedades del elemento general

CU-CU y Actor-Actor Asociación binaria. Gen/Esp

(DC)

Extend

Cómo y cuándo el comportamiento definido en un CU extensión será

insertado dentro del comportamiento definido

en un CU base

Posible extensión de comportamiento del

CU base CU-CU

Asociación binaria. La extensión se lleva a cabo en

puntos de extensión definidos en el CU base

----

Include

Un caso de uso contiene el comportamiento definido

en otro caso de uso (entidad sobre la cual recae

la acción)

Asociación fuerte. El CU base puede sólo depender del

resultado del caso de uso incluido.

CU-CU

Asociación binaria. Caso de uso incluido no es

opcional y siempre es requerido por el caso de uso base para su

correcta ejecución. Es usada cuando hay partes de comportamiento en común para

dos o más casos de uso. Si se elimina el CUB se elimina el CU incluido. Si se elimina el CUB

se elimina el CU incluido.

Composición

Composición

(Agregación fuerte)

Un elemento está

compuesto por partes más pequeñas que influencian

en su comportamiento.

Asociación fuerte entre un todo y sus

partes.

Las partes sólo pueden participar en una composición a la

vez

Clase-Clase

Asociación binaria. Si se elimina una clase

compuesta, usualmente todas

sus piezas se eliminan con él; sin embargo se puede quitar

individualmente una parte de la composición sin tener que

eliminar la composición entera.

Include


60

Tabla 8. Características de las relaciones de los DCU y DC.

Tipo de relación

Especifica Implica Relaciona/Asociación Restricción Similitud

Agregación Débil

Cómo los elementos más complejos se construyen de una colección de

elementos simples.

Asociación entre un todo y sus componentes dentro del cual una

o más clases son partes de un

conjunto.

Clase-Clase Asociación

binaria.

---

Asociación (DC)

Relación semántica que puede ocurrir entre 2 elementos.

Los elementos de una clase están relacionados con los elementos de

otra clase. Clase-Clase

Asociación binaria.

----

Dep/Real

Un elemento o conjunto de elementos del modelo requieren de otro elemento o elementos para su

especificación o realización.

Una relación cliente-proveedor entre elementos del modelo, donde la modificación del

proveedor puede impactar los elementos del modelo del cliente.


binaria. ---

Gen/Esp

Relación taxonómica entre clasificadores generales y unos

específicos. Cuando se establece una relación de este tipo entre dos clases, una es una superclase y la

otra es una subclase.

La subclase comparte la estructura y el comportamiento de la superclase. Puede haber

más de una clase que se comporte como subclase.


binaria. Generalización

(DCU)


61

En las tablas 7 y 8 se presentan las características de las relaciones de los DCU y DC con el objetivo de analizar la semántica de estas relaciones, poniendo énfasis en las similitudes que se presentan entre ellas, con la finalidad de mapear aquellas relaciones de los DCU que tienen relación semántica con las relaciones de los DC.

Una vez analizadas las características de estas relaciones se observó lo siguiente.

La relación de asociación tanto de los DCU y DC tienen similitudes en cuanto a características como son:

En ambas relaciones existe una relación semántica entre dos elementos, en donde los objetos de un elemento se relacionan con los objetos de otro elemento (existe participación o comunicación de un elemento en el otro).

Son asociaciones binarias.

Los elementos relacionados se encuentran en el mismo nivel de abstracción.

Aun con lo anterior no es posible mapear esta relación de los DCU a los DC

como una relación entre clases debido a que la relación de asociación en los DCU relaciona a actores con actores y actores con CU, siendo que en este trabajo de investigación consideramos que los actores no pueden ser mapeados como clases debido a que éstos sólo interactúan con el sistema (hacen uso del sistema). Sin embargo el actor al igual que en los diagramas de casos de uso también puede relacionarse con clases por lo que pudiera ser mapeado tal como se presenta en un diagrama de casos de uso (ver la notación del elemento actor), esto se ilustra en la figura (27) en donde el actor no puede ser mapeado como una clase.

Figura 27: Mapeo de relación de asociación (DCU) a relación de asociación (DC).

La relación extend no tiene similitud semántica con alguna relación de los DC

debido a que esta relación especifica cómo y cuándo el comportamiento de un caso de uso es extendido por el comportamiento de otro, siendo que ninguna de las relaciones pertenecientes a los DC especifica cuando y en qué circunstancias una clase extiende su comportamiento con otra clase, por tal motivo se considera que la relación extend no puede ser mapeada como relación en los DC.

Verbo Entidad

Entidad

Entidad

Entidad

Operación


62

La relación include tiene similitud semántica con la relación de composición debido a lo que a continuación se describe:

Son asociaciones binarias.

Son relaciones fuertes entre un todo y sus partes, debido a que en una relación include el caso de uso base requiere forzosamente de un caso de uso incluido para su correcta realización y una relación de composición implica que una clase depende de clases más pequeñas para su correcta operación.

Las partes que conforman a un elemento influencian en su comportamiento.

Por tanto, se deduce que semánticamente una relación include en los DCU

tiene similitud semántica con la relación de composición de los DC, por lo que la relación include puede ser potencialmente una relación de composición.

Esta similitud semántica se aprecia en la figura (28), en donde las entidades explícitas en los nombres de los casos de usos que participan en la relación include son mapeadas para formar las clases compuesta y componente, la relación include se mapea a una relación de composición y a través de esta relación, se relacionan las clases compuesta y componente en el DC.

Figura 28: Mapeo de relación include (DCU) a relación de composición (DC).

La relación de generalización de los DCU tiene similitud semántica con la

relación de generalización/especialización de los DC debido a:

o Son asociaciones binarias o Relacionan dos elementos, uno más general y el otro más específico. o El elemento más específico hereda las propiedades del más general.

Por lo que se deduce que semánticamente una relación de generalización en

los DCU tiene similitud semántica con la relación de generalización/especialización de los DC, por lo que la relación de generalización puede ser potencialmente una relación de generalización/especialización.

Esta similitud semántica se aprecia en la figura (29), en donde las entidades

explícitas en los nombres de los casos de usos que participan en la relación de generalización son mapeadas para formar las clases superclase y subclase, la relación de generalización se mapea a una relación de generalización/especialización y a través de esta relación, se relacionan las clases superclase y subclase en el DC.


63

Métodos Transformación

Figura 29: Mapeo de relación de generalización (DCU) a relación de generalización/especialización (DC).

Las relaciones de dependencia/realización y agregación no tienen similitud semántica con ninguna relación de los DCU, debido a que ninguna relación de los DCU especifica que un elemento depende semántica de otro elemento para su implementación o realización.

3.4.2 Métodos de transformación En esta sección se presenta la descripción de los métodos de transformación entre los elementos de los DCU que tienen relación con los elementos de los DC, para que en un trabajo futuro sean implementados en un procedimiento de transformación entre los elementos de los DCU y DC.

3.4.2.1 Desarrollo de los métodos de transformación

Para desarrollar los métodos de transformación entre los elementos de los DCU que tienen relación con los elementos de los DC, se tomaron como base los resultados del análisis heurístico realizado a los diagramas de características de los DCU y DC del UML, el resultado del análisis heurístico aplicado a la semántica, restricciones y descripción de cada elemento y la relación descrita en la superestructura de dichos diagramas del UML.

Los métodos de transformación definidos se especifican a nivel de metamodelos como se aprecia en la figura (30), no sólo para hacerlos más genéricos sino también por los siguientes motivos:

Esta es la capa donde se define el lenguaje que sirve para especificar los modelos.

Definen los objetos del lenguaje unificado: Clase, Atributo, TipoDato, entre otros.

Figura 30: Esquema de transformación a nivel de Metamodelos

Metamodelo Fuente

(Casos de Uso)

Metamodelo Destino

(Diagrama de Clases)


64

3.4.2.1.1 Método de transformación T0: “caso de uso a clase”

El método consiste en generar clases a partir de un caso de uso. Intención: Identificar elementos en los diagramas de casos de uso y mapearlos como elementos (métodos o clases) de los diagramas de clases a partir del método de transformación en cuestión.

Figura 31. Diagrama de actividad para generar clases a partir de casos de uso.


65

Proceso:

1 Utilizar un procesamiento de lenguaje natural (PLN) para realizar un análisis sintáctico y semántico para identificar el verbo y el sustantivo (sobre el cual recae la acción) explícito en el nombre del caso de uso.1

a. Si el caso de uso sólo cuenta con sustantivo pero el caso de uso pertenece a una relación de generalización como caso de uso hijo y el caso de uso padre al que se relaciona cumple con la sintaxis básica requerida, entonces el caso de uso hijo heredara el verbo explícito en el nombre del caso de uso padre, por consiguiente el caso de uso hijo cumplirá con la sintaxis básica necesaria para poder identificar elementos de los DC.

2 Extraer el verbo y sustantivo explícitos en el nombre del CU.

3 Identificar si el sustantivo extraído del nombre del caso de uso:

a. Está siendo utilizado como nombre de clase, en este caso la clase será

tomada como referencia de aquí en adelante.

b. Si no es utilizado como nombre de clase, crear una clase con tres compartimientos (nombre, operaciones y atributos) y nombrar a esta clase con el sustantivo extraído del nombre del caso de uso.

4 Identificar si el verbo extraído del nombre del CU:

a. Está mapeado como método de la clase creada en el paso 4, en cuyo

caso, ya no se crea un método con el verbo explícito en el nombre del caso de uso.

b. En caso contrario, el verbo explícito en el caso de uso será mapeado como método de la clase creada en el paso 4.

5 La clase creada pertenecerá al diagrama de clases del sistema modelado

mediante el diagrama de casos de uso.

6 Los pasos anteriores se repetirán hasta analizar todos los casos de uso que pertenecen al diagrama de casos de uso.

Nota: En esta tesis no se realiza el procesamiento de lenguaje natural, el cual se requiere para realizar la identificación de los elementos implícitos en el nombre del caso de uso que pueden ser mapeados como elementos de los diagramas de clases.

1 El nombre del caso de uso debe estar compuesto por un verbo y un sustantivo (sintaxis básica) como

requisito indispensable para poder identificar elementos pertenecientes a los diagramas de clases.


66

3.4.2.1.2 Método de transformación T1: “relación de generalización a relación de generalización/especialización”

El método consiste en mapear una relación de tipo generalización perteneciente a los diagramas de casos de uso a una relación de generalización/especialización en los diagramas de clases.

Intención: Mapear la relación generalización de los diagramas de casos de uso a una relación de generalización/especialización en los diagramas de clases, con la finalidad de ver reflejada la relación generalización perteneciente a los diagramas de casos de uso como relación de generalización/especialización en los diagramas de clases.

Figura 32. Diagrama de actividad para mapear la relación de generalización (DCU) a los DC.


67

Proceso:

1. Identificar en un diagrama de casos de uso, los casos de uso padre (CUP) y caso de uso hijo (CUH) que pertenezcan a una relación binaria de generalización.

2. Analizar los casos de uso mediante un procesamiento de lenguaje natural

(PLN) para identificar que el nombre del caso de uso padre y el nombre del caso de uso hijo cumplan con la sintaxis y semántica básica requerida.2

3. Extraer los verbos y sustantivos (sustantivos sobre los cuales recaen las

acciones) de cada caso de uso para poder utilizar dichos verbos y sustantivos como métodos y nombres de clase.3

4. Identificar si el sustantivo explícito en el nombre del caso de uso padre:

a. Es utilizado como nombre de clase, en este caso la clase nombrada con

el sustantivo del caso de uso padre será referenciada como superclase de aquí en adelante.

b. En caso contrario, crear la superclase dentro del DC, con sus tres

compartimentos básicos (nombre, operaciones y atributos) y nombrar a la superclase con el sustantivo explícito en el nombre del caso de uso padre.

5. Identificar si el sustantivo explícito en el nombre del caso de uso hijo:

a. Es utilizado como nombre de clase, en este caso la clase nombrada

con el sustantivo del caso de uso hijo será referenciada como subclase de aquí en adelante.

b. No es utilizado como nombre de clase, crear la subclase dentro del DC,

con sus tres compartimentos básicos (nombre, operaciones y atributos) y nombrar a la subclase con el sustantivo explícito en el nombre del caso de uso hijo.

6. Identificar si el verbo explícito en la caso de uso padre:

a. Es utilizado como método de la superclase, en este caso ya no se crea

un método con el verbo explícito en el nombre del caso de uso padre.

b. Caso contrario, mapear el verbo explícito en el nombre del caso de uso padre como método de la superclase.

2 La sintaxis básica requerida consta de por lo menos un verbo seguido de un sustantivo para el caso

de uso padre y de un sustantivo explícito en el nombre del caso de uso hijo (sobre el cual recae la acción del caso de uso padre).

3 Es posible que el nombre de los casos de uso tengan más de un sustantivo por lo que es necesario

realizar un análisis semántico para identificar el sustantivo que puede ser potencialmente clase en los diagramas de clases.


68

7. Identificar si el verbo explícito en la caso de uso hijo:

a. Es utilizado como método de la subclase, en tal caso ya no se crea un método con el verbo explícito en el nombre del caso de uso hijo.

b. En caso contrario, mapear el verbo explícito en el nombre del caso de uso hijo como método de la subclase.

8. Relacionar la superclase con la subclase a través de la relación de

generalización/especialización, en donde, el extremo de la relación con el triangulo se conectará a la superclase y el extremo contrario de la relación se conectará a la subclase.

9. Las operaciones en la superclase serán heredadas a la subclase, siempre y

cuando estas clases pertenezcan a una relación de generalización/especialización en común.


69

3.4.2.1.3 Método de transformación T2: “relación include a relación de composición”

El método consiste en mapear una relación de tipo include perteneciente a los DCU a una relación de composición en los DC.

Intención: Mapear la relación include de los diagramas de casos de uso a una relación de composición en los diagramas de clases, con la finalidad de ver reflejada la relación include como una relación de composición en los diagramas de clases.

Figura 33. Diagrama de actividad para mapear relación include a los DC.


70

Proceso:

1. Identificar en un diagrama de casos de uso, los casos de uso base (CUB) y caso de uso incluido (CUI) que pertenezcan a una relación binaria include.

2. Analizar los casos de uso mediante un procesamiento de lenguaje natural

(PLN) para identificar que los nombres de los casos de uso cumplan con la sintaxis básica (verbo y sustantivo).4

3. Extraer los verbos y sustantivos (sustantivos sobre los cuales recaen las

acciones) de cada caso de uso para poder utilizar dichos verbos y sustantivos como métodos y nombres de clase.

4. Identificar si el sustantivo explícito en el nombre del caso de uso base:

a. Es utilizado como nombre de clase, en este caso la clase nombrada con

el sustantivo del caso de uso base será referenciada como clase compuesta.

b. No es utilizado como nombre de clase, en este caso crear la clase

dentro del DC, con sus tres compartimentos básicos (nombre, operaciones y atributos) y nombrar a la clase con el sustantivo explícito en el nombre del caso de uso padre, esta clase será referenciada como clase compuesta.

5. Identificar si el sustantivo explícito en el nombre del caso de uso incluido:

a. Es utilizado como nombre de clase, en este caso la clase nombrada

con el sustantivo del caso de uso incluido, esta clase será referenciada como la clase componente.

b. No es utilizado como nombre de clase, crear la clase dentro del DC, con

sus tres compartimentos básicos (nombre, operaciones y atributos) y nombrar a la clase con el sustantivo explícito en el nombre del caso de uso incluido, esta clase será referenciada como clase componente.

6. Identificar si el verbo explícito en la caso de uso base:

a. Es utilizado como método de la clase compuesta, en tal caso ya no se

creará un método con el verbo explícito en el nombre del caso de uso base.

b. Caso contrario, mapear el verbo explícito en el nombre del caso de uso base como método de la clase compuesta.

4 Es necesario tener presente que el caso de uso base o el caso de uso incluido o ambos pueden ser

casos de uso hijo en una relación de generalización por lo que es necesario realizar el paso 1 del método de transformación T0.


71

7. Identificar si el verbo explícito en el caso de uso incluido:

a. Es utilizado como método de la clase componente, en este caso ya no se creará un método con el verbo explícito en el nombre del caso de uso incluido.

b. No es utilizado como método de la clase componente, para este caso mapear el verbo explícito en el nombre del caso de uso hijo como método de la clase componente.

8. Relacionar la clase compuesta con la clase componente a través de la relación

de composición, en donde, el extremo de la relación con el rombo relleno se conectará a la clase compuesta y el extremo contrario de la relación se conectará a la clase componente.

Capítulo 4. Pruebas

73

Capítulo 4. Pruebas Para probar que existe relación entre los elementos de los diagramas de casos de uso (DCU) y los diagramas de clases (DC), así como para ver reflejados elementos de los diagramas de casos de uso (casos de uso, actores y/o relaciones) en los diagramas de clases (clases, métodos, atributos y/o relaciones) a través de los métodos de transformación generados en el capítulo anterior, se desarrolló un plan de pruebas de acuerdo al estándar IEEE 829-1998 [IEEE98].

El objetivo de este plan de pruebas como se menciona anteriormente es

constatar que es posible identificar elementos de los DCU que pueden ser representados o que tengan relación en los DC.

4.1 Convención de nombres La convención de nombres que se utilizan para realizar la ejecución de los métodos de transformación se presenta a continuación.

PLN: procesamiento de lenguaje natural UML: Unified Modeling Language (Lenguaje Unificado de Modelado) CU: caso de uso DC: diagrama de clases DCU: diagrama de casos de uso


74

4.2 Plan de pruebas

a) Introducción

El presente plan de pruebas está basado en el estándar IEEE 829-1998 [IEEE98] para pruebas de software, el cual permite verificar los métodos de transformación, creados para mapear los elementos de los DCU a elementos en los DC.

Para evaluar los métodos de transformación, se utiliza el diagrama de casos de uso como metamodelo fuente, al cual se le aplican los métodos de transformación para mapear aquellos elementos de los DCU que tienen relación semántica con elementos de los DC, cuyo resultado es comparado con el DC final. Esto con la finalidad de determinar si los elementos de los DCU mapeados pertenecen al DC final y poder así demostrar que es posible la identificación de elementos de los DC desde los DCU.

Cabe mencionar que tanto los DCU como los DC son modelos que

representan la fase de análisis y diseño de sistemas de software y no de otras actividades ajenas al desarrollo de sistemas. El plan de pruebas contiene los siguientes puntos: elementos de prueba, características a ser probadas, características excluidas de las pruebas, enfoque, criterio de éxito/fracaso de los casos de prueba, criterio de suspensión y requisitos de reanudación, tareas de pruebas, liberación de pruebas, responsabilidades, riesgos y contingencias, aprobación, casos de prueba, especificación de casos de prueba, especificación de procedimiento de pruebas y resultados obtenidos.

b) Elementos de prueba Para realizar las pruebas es necesario contar con los DCU y DC de sistemas creados con anterioridad, los cuales son utilizados como base para esta investigación. Para las pruebas se seleccionaron 8 casos de estudio, los cuales se mencionan a continuación:

1. Sistema simulador de cajero automático (ATM, Automated Teller Machine) [CBJO01].

2. Sistema administrador de proyectos de desarrollo, donde se llevará el

control de los avances de sus diferentes etapas [CAFE10].

3. Sistema administrador de libretas de direcciones, donde se llevará el registro de las personas y sus direcciones [CBJO08].

4. Sistema que permite la compra de boletos para espectáculos [HEOR08].

5. Sistema para librería que permite el préstamo de libros y revistas

[NASH07].


75

6. Sistema que permite la compra de boletos para el cine [CHWA04].

7. Sistema que permite monitorear el tiempo [PAPR03].

8. Sistema Comercializador de Libros [LIAY03].

Para mayor detalle sobre la ejecución de las pruebas de los casos de estudio

que no se presentan en esta tesis, consultar el reporte de avance de tesis que comprende el periodo de Mayo a Agosto del 2010.

Los métodos de transformación que se utilizan en esta investigación son los creados en el capítulo 4, los cuales permiten mapear elementos de los DCU a elementos de los DC.

c) Características a probar

Las características a probar se enlistan a continuación:

Casos de uso (sustantivo). Se evaluará que el sustantivo (sobre el cual recae la acción) explícito en el nombre de los casos de uso tengan consecuencia en el DC, es decir, que el sustantivo explícito en el nombre del caso de uso sea mapeado como una clase en el DC final.

Casos de uso (verbo). Se evaluará que el verbo explícito en los casos de uso tenga consecuencia en los DC, es decir, que cada verbo sea mapeado como un método en la clase respectiva.

Relación Include (DCU). Se evaluará que la relación include en el DCU tenga consecuencia en el DC, es decir, que la relación include en el DCU sea mapeada al DC como una relación de composición.

Relación de Generalización (DCU). Se evaluará que la relación de generalización en el DCU tenga consecuencia en el DC, es decir, que la relación de generalización en el DCU sea mapeada al DC como una relación de generalización/especialización.

Que el resultado obtenido de la aplicación de los métodos de transformación tenga consecuencia en el DC final, es decir, que el resultado se vea reflejado en el DC final.


76

d) Características excluidas de las pruebas

Las siguientes características no formarán parte del criterio de evaluación:

Creación de DCU. No se generan DCU en esta investigación.

Escenarios de casos de uso. Esta investigación no se apoya en los escenarios de los casos de uso para la generación de la aproximación al DC final.

Creación del DC Final. No se genera ni evalúa el DC final.

Creación de DS. No se crean ni evalúan diagramas de secuencia como punto intermedio en la obtención de clases.

Utilización de patrones de diseño. No se utilizan patrones de diseño para relacionar a los elementos resultantes de la aplicación de los métodos de transformación.

No se evalúa que los nombres de los casos de uso sean semánticamente correctos y que cumplan con la sintaxis básica (verbo y sustantivo) necesaria para identificar elementos pertenecientes a los DC.

No se aplica ni evalúa el procesamiento del lenguaje natural aplicado al nombre del caso de uso.

e) Pruebas realizar

MDT-01 Transformación de caso de uso a clase.

MDT-01-01 Transformación de caso de uso a clase para el sistema ATM [CBJO01].

MDT-01-02 Transformación de caso de uso a clase para el sistema administrador de proyectos [CAFE10].

MDT-02 Transformación de relación de generalización a relación de generalización/especialización.

MDT-02-01 Transformación de relación de generalización a relación de generalización/especialización para el sistema ATM [CBJO01].

MDT-02-02 Transformación de relación de generalización a relación de generalización/especialización para el sistema administrador de proyectos [CAFE10].

MDT-03 Transformación de relación include a relación de composición.

MDT-03-01 Transformación de relación include a relación de composición para el sistema ATM [CBJO01].

MDT-03-02 Transformación de relación include a relación de composición para el sistema administrador de proyectos [CAFE10].


77

f) Enfoque

Las pruebas a realizar son para comprobar el resultado de la aplicación de los métodos transformación, los cuales mapearán elementos en los DCU que tienen relación en los DC.

g) Criterio éxito/fracaso de casos de prueba La decisión de éxito o fracaso para cada uno de los casos de prueba descritos en el presente documento, se basa en la comparación de los resultados esperados contra los resultados obtenidos.

Se considera que una prueba ha pasado con éxito cuando los resultados obtenidos coincidan con los resultados esperados descritos para cada uno de los casos de prueba.

En caso de que la prueba no resulte con éxito, se analizarán las causas y se explicará el por qué no se obtuvieron los resultados esperados.

h) Criterios de suspensión y requerimientos de reanudación

No se establece ningún criterio de suspensión de prueba.

i) Tareas de pruebas

En este apartado se describen las tareas a desarrollar para preparar y aplicar las pruebas de este plan (ver tabla 9). Tabla 9. Descripción de las tareas de prueba.

Tarea Tarea

precedente Habilidades Responsabilidad

1. Diseño de

pruebas Tarea 1

Conocimiento sobre modelado de sistemas con UML.

Autor de tesis

2. Ejecución de

pruebas Tarea 2

Conocimiento sobre modelado de sistemas con UML y métodos

de transformación creados en el capítulo 5.

Autor de tesis

3. Evaluación de

resultados Tarea 2

Conocimiento del objetivo,

alcances, limitaciones de

prueba para este trabajo de

investigación.

Autor de tesis


78

j) Liberación de pruebas

La liberación de las pruebas se realizará cuando se obtengan y evalúen los resultados de la ejecución de los métodos de transformación T0, T1 y T2 para cada caso de prueba.

k) Responsabilidades La responsabilidad de realizar e implementar las pruebas que se han especificado en este plan recae sobre el autor de esta tesis, ISC. Adán Hernández Estrada. Quien se encargará de aplicar los métodos de transformación a los DCU y comparar los resultados obtenidos con los esperados.

l) Riesgos y contingencias

En caso de presentarse problemas no considerados, deberán ser resueltos por el responsable de la tesis. Por ejemplo que los DCU y DC tomados como base no estén bien diseñados o que los nombres de los CU no cumplan con la sintaxis requerida para poder identificar clases y/o métodos del DC.

m) Aprobación

El plan de pruebas debe ser aprobado por el director de esta tesis, el Dr. Máximo López Sánchez.

4.3 Casos de prueba En esta sección se describe el propósito de cada caso de prueba desarrollado para evaluar los métodos de transformación generados. MDT-01-01 Transformación de caso de uso a clase para el sistema ATM [CBJO01]. La prueba consiste en identificar elementos del diagrama de casos de uso del sistema ATM y mapearlos como clases y/o métodos ejecutando el método de transformación T0: “casos de uso a clases” y observar si el resultado de la ejecución del método se ve reflejado en el DC final del sistema en cuestión.

MDT-01-02 Transformación de caso de uso a clase para el sistema administrador de proyectos [CAFE10]. La prueba consiste en identificar elementos del diagrama de casos de uso del sistema administrador de proyectos y mapearlos como clases y/o métodos ejecutando el método de transformación T0: “casos de uso a clases” y observar si el resultado de la ejecución del método se ve reflejado en el DC final del sistema en cuestión.


79

MDT-02-01 Transformación de relación de generalización a relación de generalización/especialización para el sistema ATM [CBJO01]. La prueba consiste en identificar las relaciones de generalización y los casos de uso que pertenecen a dicha relación en el DCU del sistema ATM y mapearla como una relación de generalización/especialización de los DC mediante la ejecución del método de transformación T1: “relación de generalización a relación de generalización/especialización” y observar si el resultado del método se ve reflejado en el DC final del sistema en cuestión.

MDT-02-02 Transformación de relación de generalización a relación de generalización/especialización para el sistema administrador de proyectos [CAFE10]. La prueba consiste en identificar las relaciones de generalización y los casos de uso que pertenecen a dicha relación en el DCU del sistema administrador de proyectos y

mapearla como una relación de generalización/especialización de los DC mediante la ejecución del método de transformación T1: “relación de generalización a relación de generalización/especialización” y observar si el resultado del método se ve reflejado en el DC final del sistema en cuestión.

MDT-03-01 Transformación de relación include a relación de composición para el sistema ATM [CBJO01]. La prueba consiste en identificar las relaciones de tipo include y los casos de uso que pertenecen a dicha relación en el DCU del sistema ATM y mapearla como una relación de composición de los DC mediante la ejecución del método de transformación T2: “relación include a relación de composición” y observar si el resultado del método se ve reflejado en el DC final del sistema en cuestión. MDT-03-02 Transformación de relación include a relación de composición para el sistema administrador de proyectos [CAFE10]. La prueba consiste en identificar las relaciones de tipo include y los casos de uso que pertenecen a dicha relación en el DCU del sistema administrador de proyectos y mapearla como una relación de composición de los DC mediante la ejecución del método de transformación T2: “relación include a relación de composición” y observar si el resultado del método se ve reflejado en el DC final del sistema en cuestión.

4.4 Descripción de los casos de prueba.

En esta sección se describen de forma completa los procedimientos de los casos de prueba para los métodos de transformación presentados en el capítulo 4 de esta tesis. Estas pruebas tienen como objetivo validar y verificar que los métodos de transformación se comporten de forma adecuada.

Para cada caso de prueba se describe el propósito, entorno, proceso y resultado esperado.


80

4.4.1 MDT-01 Transformación de caso de uso a clase.

a) Propósito

Mapear elementos de los diagramas de casos de uso como clases, ejecutando el método de transformación T0: “caso de uso a clase” y observar si el resultado de la ejecución del método se ve reflejado en los DC final para cada sistema utilizado.

b) Entorno de prueba

El mapeo de los elementos de los diagramas de casos de uso a clases se debe realizar mediante el método de transformación T0: “caso de uso a clase”, se tiene como requisito que tanto los DCU como los DC de los sistemas se encuentren modelados.

4.4.1.1 MDT-01-01 Transformación de caso de uso a clase para el sistema ATM [CBJO01].

a) Propósito

La prueba consiste en identificar elementos del diagrama de casos de uso del sistema ATM y mapearlos como clases y/o métodos ejecutando el método de transformación T0: “casos de uso a clases” y observar si el resultado de la ejecución del método se ve reflejado en el DC final del sistema en cuestión.


El mapeo de los elementos de los diagramas de casos de uso a clases se debe realizar mediante el método de transformación T0: “caso de uso a clase”, se tiene como requisito que tanto los DCU como los DC del sistema ATM se encuentren modelados.

c) Proceso

1. Seleccionar el DCU del sistema ATM para analizarlo. 2. Ejecutar manualmente el método de transformación T0. 3. Comparar el resultado de la ejecución del método con el DC final del sistema

ATM.

d) Resultado esperado

El método de transformación T0 identificará elementos pertenecientes al DCU del sistema ATM que pudieran ser elementos de los diagramas de clases y los mapeará como clases o métodos de los DC, en donde dichos elementos creados pudieran o no pertenecer al DC final del sistema en cuestión, dependiendo del nivel de detalle del diagrama de casos de uso utilizados para la prueba.


81

4.4.1.2 MDT-01-02 Transformación de caso de uso a clase para el sistema administrador de proyectos [CAFE10].

a) Propósito

La prueba consiste en identificar elementos del diagrama de casos de uso del sistema administrador de proyectos y mapearlos como clases y/o métodos ejecutando el método de transformación T0: “casos de uso a clases” y observar si el resultado de la ejecución del método se ve reflejado en el DC final del sistema en cuestión.


El mapeo de los elementos de los diagramas de casos de uso a clases se debe realizar mediante el método de transformación T0: “caso de uso a clase”, se tiene como requisito que tanto los DCU como los DC del sistema administrador de proyectos se encuentren modelados.

c) Proceso

1. Seleccionar el DCU del sistema administrador de proyectos para analizarlo. 2. Ejecutar manualmente el método de transformación T0. 3. Comparar el resultado de la ejecución del método con el DC final del sistema

administrador de proyectos.


El método de transformación T0 identificará elementos pertenecientes al DCU del sistema administrador de proyectos que pudieran ser elementos de los diagramas de clases y los mapeará como clases o métodos de los DC, en donde dichos elementos creados pudieran o no pertenecer al DC final del sistema en cuestión dependiendo del nivel de detalle del diagrama de casos de uso utilizados para la prueba.

4.4.2 MDT-02 Transformación de relación de generalización a relación de generalización/especialización.

a) Propósito

Mapear las relaciones de Generalización pertenecientes a los DCU como relaciones de generalización/especialización de los DC, mediante la ejecución del método de transformación T1 y observar si el resultado del método se ve reflejado en el DC final de cada sistema utilizado.


El mapeo de las relaciones de generalización de los diagramas de casos de uso a relaciones de generalización/especialización se realizará mediante el método de transformación T1: “relación de generalización a relación de


82

generalización/especialización”, se tiene como requisito que tanto los DCU como los DC de los sistemas se encuentren modelados.

4.4.2.1 MDT-02-01 Transformación de relación de generalización a relación de generalización/especialización para el sistema ATM [CBJO01].

a) Propósito

La prueba consiste en identificar las relaciones de generalización y los casos de uso que pertenecen a dicha relación en el DCU del sistema ATM, mapearla como una relación de generalización/especialización de los DC mediante la ejecución del método de transformación T1: “relación de generalización a relación de

generalización/especialización” y observar si el resultado del método se ve reflejado en el DC final del sistema en cuestión.


El mapeo de las relaciones de generalización de los diagramas de casos de uso a relaciones de generalización/especialización se debe realizar mediante el método de transformación T1: “relación de generalización a relación de generalización/especialización”, se tiene como requisito que tanto los DCU como los DC del sistema ATM se encuentren modelados.

c) Proceso

1. Seleccionar el DCU del sistema ATM para analizarlo. 2. Ejecutar el método de transformación T1. 3. Comparar el resultado de la ejecución del método con el DC final.


El método de transformación T1, identificará relaciones de generalización pertenecientes al DCU y las mapeará como relaciones de generalización/especialización pertenecientes al DC del sistema ATM.

4.4.2.2 MDT-02-02 Transformación de relación de generalización a relación de generalización/especialización para el sistema administrador de proyectos [CAFE10].

a) Propósito

La prueba consiste en identificar las relaciones de generalización y los casos de uso que pertenecen a dicha relación en el DCU del sistema administrador de proyectos, mapearla como una relación de generalización/especialización de los DC mediante la ejecución del método de transformación T1: “relación de generalización a relación de generalización/especialización” y observar si el resultado del método se ve reflejado en el DC final del sistema en cuestión.


83


El mapeo de las relaciones de generalización del diagrama de casos de uso a relaciones de generalización/especialización se debe realizar mediante el método de transformación T1: “relación de generalización a relación de generalización/especialización”, se tiene como requisito que tanto los DCU como los DC del sistema administrador de proyectos se encuentren modelados.

c) Proceso

1. Seleccionar el DCU del sistema administrador de proyectos para analizarlo. 2. Ejecutar el método de transformación T1. 3. Comparar el resultado de la ejecución del método con el DC final.


El método de transformación T1, identificará relaciones de generalización pertenecientes al DCU y las mapeará como relaciones de generalización/especialización pertenecientes al DC del sistema administrador de proyectos.

4.4.3 Método de transformación T2: “relación include a relación de composición”.

a) Propósito

Mapear las relaciones de tipo include pertenecientes a los DCU como relaciones de composición de los DC de los sistemas utilizados, mediante la ejecución del método de transformación T2 y observar si el resultado del método se ve reflejado en el DC final de cada sistema utilizado.


El mapeo de las relaciones de tipo include de los diagramas de casos de uso a relaciones de composición de los diagramas de clases se realizará mediante el método de transformación T2: “relación include a relación de composición”, se tiene como requisito que tanto los DCU como los DC de los sistemas se encuentren modelados.

4.4.3.1 MDT-03-01 Transformación de relación include a relación de composición para el sistema ATM [CBJO01].

a) Propósito

La prueba consiste en identificar las relaciones de tipo include y los casos de uso que pertenecen a dicha relación en el DCU del sistema ATM y mapearla como una relación de composición de los DC mediante la ejecución del método de transformación T2: “relación include a relación de composición” y observar si el resultado del método se ve reflejado en el DC final del sistema en cuestión.


84


El mapeo de las relaciones de tipo include de los diagramas de casos de uso a relaciones de composición de los diagramas de clases se debe realizar mediante el método de transformación T2: “relación include a relación de composición”, se tiene como requisito que tanto los DCU como los DC del sistema en cuestión se encuentren modelados.

c) Proceso

1. Seleccionar el DCU del sistema ATM para analizarlo. 2. Ejecutar el método de transformación T2. 3. Comparar el resultado de la ejecución del método con el DC final.


El método de transformación T2, identificará relaciones de tipo include pertenecientes al DCU y las mapeará como relaciones de composición pertenecientes al DC del sistema ATM.

4.4.3.2 MDT-03-02 Transformación de relación include a relación de composición para el sistema administrador de proyectos [CAFE10].

a) Propósito

La prueba consiste en identificar las relaciones de tipo include y los casos de uso que pertenecen a dicha relación en el DCU del sistema administrador de proyectos, mapearlas como una relación de composición de los DC mediante la ejecución del método de transformación T2: “relación include a relación de composición” y observar si el resultado del método se ve reflejado en el DC final del sistema en cuestión.


El mapeo de las relaciones de tipo include de los diagramas de casos de uso a relaciones de composición de los diagramas de clases se debe realizar mediante el método de transformación T2: “relación include a relación de composición”, se tiene como requisito que tanto los DCU como los DC del sistema en cuestión se encuentren modelados.

c) Proceso

1. Seleccionar el DCU del sistema administrador de proyectos para analizarlo. 2. Ejecutar el método de transformación T2. 3. Comparar el resultado de la ejecución del método con el DC final.


El método de transformación T2, identificará relaciones de tipo include pertenecientes al DCU y las mapeará como relaciones de composición pertenecientes al DC del sistema administrador de proyectos.


85

4.5 Resultados de pruebas A continuación se presentan los resultados obtenidos una vez realizadas las pruebas descritas en la sección anterior. Tabla 10. Resultados del caso de prueba MDT-01-01 Transformación de caso de uso a clase para el sistema ATM [CBJO01].

Caso de prueba: MDT-01-01 Transformación de caso de uso a clase

para el sistema ATM [CBJO01]. Resultado: OK

Se seleccionó el DCU del sistema ATM (figura 34) y se ejecutó el método de transformación

T0.

Figura 34. Diagrama de casos de uso de sistema ATM.

Los resultados de la ejecución del método de transformación se muestran a continuación.

1. Se identificaron los siguientes nombres de casos de uso:

a. Iniciar Sistema

b. Cerrar Sistema

c. Iniciar Sesión


86

d. Realizar Transacciones e. Retiro

f. Depósito

g. Consultas

h. Transferencia

2. Se extrajeron los siguientes sustantivos:

a. Sistema (2)

b. Sesión

c. Transacciones

d. Retiro

e. Depósito f. Consultas

g. Transferencia

3. Se extrajeron los siguientes verbos:

a. Iniciar (2)

b. Cerrar c. Realizar

4. Se crearon las siguientes clases con sus tres compartimentos cada una:

a. Sistema

b. Sesión c. Transacciones

d. Retiro

e. Depósito

f. Consultas

g. Transferencia

5. Se creó el siguiente método, el cual fue asignado a su respectiva clase:

a. Realizar Transacciones

Una vez ejecutado el método se produjo el resultado mostrado en la figura (35), el cual es

comparado con el diagrama de clases final ilustrado en la figura (36).

Figura 35. Resultado obtenido al aplicar el método de transformación T0.


87

Figura 36. Diagrama de clases final del sistema ATM.


88

Observaciones:

Las clases (Sesión, Sistema, Transacciones, Retiro, Transferencia, Depósito y Consultas) generadas a partir de la ejecución del método pertenecen al diagrama

de clases final (figura 36).

Los nombres de los casos de uso deben contar con una sintaxis básica (verbo y sustantivo) que permitan identificar elementos de los DC.

La clase Sistema creada por el método de transformación hace referencia a la clase ATM la cual comprende el diagrama de clases final (figura 36), dichas clases tienen en común el método Iniciar generado por el método de transformación en cuestión.

Los métodos identificados son una aproximación al total de los métodos o comportamientos que una clase podría ofrecer.

Los nombres de los casos de uso “Retiro, Transferencia, Depósito y Consultas”, no cuentan con un verbo explícito, sin embargo, pertenecen a una relación de

generalización por lo que el verbo explícito en el caso de uso padre (Realizar

Transacción) es heredado por los casos de uso hijo (Retiro, Transferencia, Depósito

y Consultas) esto de acuerdo a lo especificado por la superestructura del UML que señala que las características especificadas para un elemento general son

implícitamente especificadas para el elemento específico, haciendo que los

nombres de los casos de uso hijo cumplan con la sintaxis requerida por el método

de transformación.

Mientras más detallado sea el DCU mayor será la posibilidad de identificar clases, métodos y/o relaciones pertenecientes a los DC.

Responsable de la prueba: Adán Hernández Estrada Cargo: Autor

Tabla 11. Resultados del caso de prueba MDT-02-01 Transformación de relación de generalización a relación de generalización/especialización para el sistema ATM [CBJO01].

Caso de prueba: MDT-02-01 Transformación de relación de

generalización a relación de generalización/especialización para el sistema ATM [CBJO01].

Resultado: OK


T1. Los resultados de la ejecución del método se muestran a continuación.

1. Se identificaron 4 relaciones de generalización entre casos de uso (padre e hijo) teniendo en común el caso de uso padre:

a. Caso de uso padre:

1. Realizar Transacciones

b. Casos de uso hijo:

1. Retiro

2. Transferencia 3. Depósito

4. Consultas

2. Se identificaron y extrajeron los verbos y sustantivos explícitos en los casos de

uso padre e hijos. a. Realizar (verbo)

b. Transacciones (sustantivo)

c. Retiro (verbo)

d. Transferencia (verbo)

e. Depósito (verbo)


89

f. Consultas (verbo)

3. Se identificó la superclase (Transacciones) y las subclases (Retiro, Transferencia,

Depósito, Consultas) con sus métodos, las cuales fueron creadas anteriormente

mediante el método de transformación T0.

4. Se relacionó la superclase con cada una de las subclases a través de la relación de

generalización/especialización, en donde, el extremo de cada relación con el

triangulo se conectó a la superclase y el extremo contrario de cada relación se

conectó a una subclase, por lo que se obtuvieron 4 relaciones de

generalización/especialización.

5. Las operaciones de la superclase se heredan a cada una de las subclases que se

relacionan con la superclase.

6. Una vez ejecutado el método de transformación se produjo el resultado mostrado

en la figura (37), el cual es comparado con el diagrama de clases final ilustrado en

la figura (36).


Observaciones:

El mapeo de la relación de generalización de los DCU a los DC que se realiza mediante el método de transformación pertenecen al diagrama de clases final (figura 36).


Los nombres de los casos de uso deben cumplir con la sintaxis básica (verbo y sustantivo) para poder identificar elementos de los DC.

El verbo explícito en el caso de uso padre es heredado por los casos de uso hijo por lo que por herencia el nombre del caso de uso cumple con la sintaxis requerida por

el método.

Las relaciones son binarias (superclase-subclase).



90

Tabla 12. Resultados del caso de prueba MDT-03-01 Transformación de relación include a relación de composición para el sistema ATM [CBJO01].

Caso de prueba: MDT-03-01 Transformación de relación include a

relación de composición para el sistema ATM [CBJO01]. Resultado: OK


T2. Los resultados de la ejecución del método se presentan a continuación.

1. Se identificaron los casos de uso (base e incluido) pertenecientes a la relación include:

a. Iniciar Sesión

b. Realizar transacciones.

2. Se identificaron y extrajeron los verbos y sustantivos explícitos en los casos de

uso base e incluido.

a. Iniciar

b. Realizar

c. Sesión d. Transacciones

3. Se identificaron las clases Sesión y Transacciones con sus respectivos métodos, creadas anteriormente mediante el método de transformación T0.

4. Se relacionó la clase compuesta con la clase componente a través de la relación de

composición.

Una vez ejecutado el método de transformación se produjo el resultado mostrado en la figura (38), el cual es comparado con el diagrama de clases final ilustrado en la figura

(36).


Observaciones:

El mapeo de la relación include de los DCU a los DC que se realiza mediante el

método de transformación pertenece al diagrama de clases final (figura 36) como relación de composición entre la clase Sesión y Transacción.


Los nombres de los casos de uso deben cumplir con la sintaxis básica requerida por los métodos de transformación, es decir, el nombre del caso de uso debe estar

compuesto por un verbo y un sustantivo, en donde el verbo indica un

comportamiento el cual recae sobre el sustantivo para identificar posibles clases

con su comportamiento.



91

Tabla 13. Resultados del caso de prueba MDT-01-02 Transformación de caso de uso a clase para el sistema administrador de proyectos [CAFE10].

Caso de prueba: MDT-01-02 Transformación de caso de uso a clase para el sistema administrador de proyectos [CAFE10].

Resultado: OK

Se seleccionó el DCU del sistema administrador de proyectos (figura 39) y se ejecutó el método de transformación T0.

Figura 39. Diagrama de casos de uso del sistema administrador de proyectos.

Los resultados de la ejecución del método se presentan a continuación.


92

1. Se identificaron los siguientes nombres de casos de uso: a. Manejar Proyectos

b. Manejar Etapas

c. Manejar Actividades

d. Manejar Responsables

e. Registrar Movimientos f. Imprimir

g. Ingresar Proyectos

h. Modificar Proyectos

i. Eliminar Proyectos

j. Ingresar Etapas

k. Modificar Etapas l. Eliminar Etapas

m. Ingresar Responsables

n. Modificar Responsables

o. Eliminar Responsables

p. Ingresar Movimientos

q. Modificar Movimientos r. Eliminar Movimientos

s. Ingresar Actividades

t. Modificar Actividades

u. Eliminar Actividades

v. Calcular avance de proyectos. w. Calcular avance de etapas.

2. Se extrajeron los siguientes sustantivos:

a. Proyectos (5) b. Etapas (5)

c. Actividades (4)

d. Responsables (4)

e. Movimientos (4)

3. Se extrajeron los siguientes verbos:

a. Manejar (4)

b. Ingresar (6) c. Modificar (6)

d. Eliminar(6)

e. Calcular (2)

f. Imprimir

g. Registrar

4. Se crearon las siguientes clases con sus tres compartimentos cada una:

a. Proyectos b. Etapas

c. Actividades

d. Responsables

e. Movimientos

5. Se crearon los siguientes métodos, los cuales fueron asignados a sus respectivas

clases: a. Ingresar, Modificar y Eliminar Proyectos

b. Ingresar, Modificar y Eliminar Etapas

c. Ingresar, Modificar y Eliminar Actividades

d. Ingresar, Modificar y Eliminar Responsables

e. Ingresar, Modificar y Eliminar Movimientos

f. Calcular avance Proyectos


93

g. Calcular avance Etapas

Una vez ejecutado el método de transformación se produjo el resultado mostrado en la

figura (40), el cual es comparado con el diagrama de clases final ilustrado en la figura

(41).


Figura 41. Diagrama de clases final del sistema administrador de proyectos.

Observaciones:

Las clases (Proyectos, Etapas, Movimientos, Actividades, Responsables) generadas a partir de la ejecución del método de transformación pertenecen al diagrama de

clases final (figura 41).

Los nombres de los casos de uso deben cumplir con la sintaxis básica (verbo y


94

sustantivo) necesaria para la identificación de elementos de los DC.

Mientras más detallado sea el DCU mayor será la posibilidad de identificar clases, métodos y/o relaciones pertenecientes a los DC.

Los verbos identificados en los nombres de los casos de uso extensión son utilizados como métodos de la clase identificada en el caso de uso extendido

debido a que explícitamente el verbo tanto del caso de uso extensión y extendido

recaen sobre la misma entidad.



Tabla 14. Resultados del caso de prueba MDT-02-02 Transformación de relación de generalización a relación de generalización/especialización para el sistema administrador de proyectos [CAFE10].

Caso de prueba: MDT-02-02 Transformación de relación de generalización a relación de generalización/especialización para el

sistema administrador de proyectos [CAFE10].

Resultado: OK

Se seleccionó el DCU del sistema administrador de proyectos (figura 39) y se ejecutó el

método de transformación T1. Los resultados de la ejecución del método se presentan a

continuación.

1. No se identificaron relaciones de generalización entre casos de uso (padre e hijo).

Observaciones:

No se identificaron casos de uso (padre e hijo) pertenecientes a la relación de generalización, por lo cual no se produjeron resultados al ejecutar el método de

transformación en cuestión.


Tabla 15. Resultados del caso de prueba MDT-03-02 Transformación de relación include a relación de composición para el sistema administrador de proyectos [CAFE10].

Caso de prueba: MDT-03-02 Transformación de relación include a

relación de composición para el sistema administrador de proyectos [CAFE10].

Resultado: OK

Se seleccionó el DCU del sistema administrador de proyectos (figura 39) y se ejecutó el

método de transformación en cuestión. Los resultados de la ejecución del método se

muestran a continuación.

1. No se identificaron relaciones include entre casos de uso (base e incluido).

Observaciones:

No se identificaron casos de uso (base e incluido) pertenecientes a la relación include por lo cual no se produjeron resultados al ejecutar el método de

transformación en cuestión.



95

4.6 Evaluación de Resultados Al finalizar la aplicación del plan de pruebas se pudo comprobar que es posible identificar elementos de los diagramas de clases (fase de diseño) desde los diagramas de casos de uso (fase de análisis de requerimientos) y mapearlos a través de los métodos de transformación creados en esta tesis, debido a que existen métodos y clases creadas mediante los métodos de transformación que pertenecen al diagrama de clases final de cada uno de los sistemas utilizados en las pruebas.

Sin embargo, para poder obtener clases es necesario que el objetivo del caso de uso cumpla con la sintaxis básica, necesaria para la identificación de elementos de los DC, es decir, que el nombre del caso de uso cuente de manera explícita de mínimo un verbo y un sustantivo, en donde, el verbo indica una acción que recae sobre una entidad (sustantivo). La entidad (sobre la cual recae la acción) puede ser mapeada como una clase candidata y el verbo como método de clase.

Los métodos identificados sólo son una aproximación al total de los métodos o comportamientos que una clase podría ofrecer, por lo que estos deben ser complementados por el analista de software.

Así mismo y de acuerdo con los resultados obtenidos es posible mapear las relaciones include y de generalización de los DCU a los DC como relaciones de composición y de generalización/especialización respectivamente, teniendo en cuenta que el nombre de los casos de uso deben cumplir con la sintaxis básica requerida.

Se considera que los nombres de los casos de uso que no cuenten con un verbo explícito (solo un sustantivo) pero pertenezcan a una relación de generalización como casos de uso hijo, el verbo explícito en el caso de uso padre es heredado por los casos de uso hijo, haciendo que los nombres de los casos de uso hijo cumplan con la sintaxis básica requerida y pueda ser analizado por los métodos de transformación en busca de clases y/o métodos.

Por otra parte, se observa que existen clases creadas mediante la ejecución de los métodos de transformación que no tienen consecuencia en el DC final, por lo cual se deduce que esto se debe a: el nombre del caso de uso no tiene la sintaxis o la semántica requerida, es decir el nombre del caso de uso debería contener

explícitamente un sustantivo (sobre el cual recae una acción representada por el verbo explícito en el nombre del caso de uso) y un verbo (potencialmente método de clase) lo cual no ocurre en casos específicos dentro de las pruebas debido a que sólo se presentan nombres de casos formados por un verbo y un sustantivo sin embargo el sustantivo es considerado como atributo de una clase ó argumento del verbo y no como la entidad sobre la cual recae la acción, tal como se muestra en la figura (42), en donde el verbo “Actualizar” indica una acción y puede ser mapeado como método de clase, el sustantivo “Dirección” es un atributo del “Cliente” por lo cual no puede ser mapeado como clase y el “Cliente” es la entidad sobre la cual recae la acción del verbo la cual si puede ser mapeada como clase, por tal motivo, es importante realizar un procesamiento de lenguaje natural a los nombres de los casos de uso


96

para poder identificar tanto verbos como sustantivos y diferenciar si un sustantivo puede ser clase o atributo.

Figura 42. Posible confusión entre atributo y clase.

Por lo anterior se infiere que mientras más detallado sean los DCU, mayor

será el número de elementos de los DC que puedan ser identificados desde la fase de análisis de requerimientos. Esto con la finalidad de evitar incongruencias o incompatibilidades entre el diagrama de clases y los requerimientos del usuario (DCU).

Atributo y no Clase

Atributo

Clase

Método Método

Capítulo 5. Conclusiones

97

Capítulo 5. Conclusiones En este capítulo se presentan las conclusiones obtenidas a través de la investigación y desarrollo de este trabajo de tesis, las aportaciones que con ella se dejan, los trabajos futuros que se pueden implementar para mejorar y complementar los resultados obtenidos y las publicaciones y reconocimientos obtenidos durante su desarrollo.

5.1 Conclusiones El lenguaje de modelado unificado (UML) ha sido adoptado como estándar en el

desarrollo de software debido a que es un lenguaje de modelado visual que permite modelar cada una de las fases del ciclo de vida del desarrollo de software, sin embargo ha existido un brecha entre los requerimientos funcionales plasmados en los diagramas de casos de uso (DCU) y la vista estática (diagramas de clases), por lo que esta tesis ha tenido como objetivo proponer un nuevo enfoque que permita definir si los elementos de los DCU pueden ser representados o tienen relación en los diagramas de clases (DC), analizando las características de los elementos de estos dos tipos de diagramas del UML con el fin de evitar incompatibilidades o incongruencias entre los especificado en los DCU y los DC.


98

Para alcanzar el objetivo planteado se realizó un estudio detallado sobre la especificación de los DCU y DC del UML (infraestructura y superestructura) al cual se le aplicó el análisis de dominio orientado a características (FODA) identificando con ello las características (obligatorias, alternativas y opcionales) de cada elemento que integra a dichos diagramas. Tras este estudio se desarrolló un modelo de solución, el cual consistió en formalizar mediante el lenguaje Z las características de los DCU y DC con el fin de darles un sentido formal a dichos diagramas, así mismo se realizó un análisis heurístico a las características de los elementos que integran tanto a los DCU como de los DC identificando con ello relaciones entre los elementos de un diagrama en otro, permitiendo con ello el desarrollo de métodos de transformación que nos permiten mapear elementos de los DCU como elementos de los DC.

La funcionalidad de los métodos de transformación desarrollados en esta tesis fue evaluada en base a un plan de pruebas basado en el estándar IEEE 829-1998 para pruebas de software. Al analizar los resultados obtenidos por las pruebas realizadas se demostró que mediante los métodos de transformación es posible mapear elementos de los DCU como elementos de los DC. Así mismo en este trabajo de investigación se llego a las siguientes conclusiones específicas:

Los casos de uso deben contar con un nombre obligatorio que especifiquen el objetivo del caso de uso.

El nombre del caso de uso debe cumplir con la sintaxis básica (verbo seguido de un sustantivo) necesaria para identificar operaciones y/o clases del nombre del caso de uso, para lo cual es necesario aplicarle un PLN al nombre del caso de uso poniendo énfasis en el análisis lingüístico para identificar el verbo y el sustantivo del nombre del caso de uso.

En esta investigación se considera que el verbo explícito en el nombre del CU implica una acción (comportamiento) a ser desarrollada por una entidad, lo cual es semánticamente similar a la operación de una clase. Por tal motivo una entidad identificada en el objetivo del caso de uso (sustantivo) pueden ser mapeada como nombre de clase y a su vez, el verbo explícito en el nombre del caso de uso también puede ser mapeado como un método de clase representada por el sustantivo.

Las relaciones include y generalización tienen similitudes semánticas con las relaciones de composición y generalización respectivamente, por lo que las relaciones de los DCU pueden ser mapeadas a los DC.

Las relaciones de asociación y extend no tienen similitud semántica con alguna relación de los DC debido a que ninguna relación de los DC tienen la posibilidad de especificar cómo y cuándo el comportamiento en una clase podrá ser extendido por el comportamiento de otra clase.


99

Debido al nivel de abstracción de los DCU, es imposible determinar la cardinalidad en las relaciones de los DC.

La identificación de elementos pertenecientes a los DC dependerá de qué tan detallado o abstracto sea el DCU.

La formalización de las características de los elementos que integran tanto a los DCU como a los DC permite que estos diagramas estén libres de inconsistencias, ambigüedades y declaraciones incompletas.

Tomando en cuenta las conclusiones anteriores se llegó a la siguiente

conclusión general.

Es posible identificar elementos del DC a partir de los requerimientos funcionales plasmados en los DCU, debido a que existen elementos de los DCU que tienen relación semántica con elementos de los DC. Logrando con ello que elementos identificados en los requerimientos del usuario especificados en los diagramas de casos de uso, sean contemplados en la estructura estática (DC), acortando con ello la brecha existente entre los DCU y DC. Este enfoque muestra las siguientes ventajas con respecto a otros trabajos estudiados durante el estado del arte presentado en el primer capítulo:

El análisis de los elementos que integran a los DCU y DC se realiza a nivel de metamodelo ya que es aquí donde se definen las características de los elementos (basado en la especificación del UML).

Caracteriza y formaliza los elementos de los meta-modelos de los DCU y DC logrando con ello reducir los riesgos asociados con el desarrollo de software, aumentar la seguridad, fiabilidad y claridad de lo expresado en los DCU y DC, evitando cometer inconsistencias, declaraciones incompletas y/o ambigüedades, logrando hacer del UML un lenguaje con sintaxis y semántica formal.

No es necesario identificar clases desde los escenarios de casos de uso lo cual provocaría descubrir muchas clases al hacer de cada sustantivo una clase e inclusive se pueden cometer ambigüedades debido a que la redacción de los escenarios de los casos de uso pueden ser descritos con diferentes palabras.

No es necesaria que exista iteración con cada uno de los actores que hacen uso del sistema.

Sin embargo, aún con las ventajas mencionadas anteriormente, este enfoque

es solo una primera aproximación a la transformación entre los DCU y DC, es por esto que se recomienda continuar con los puntos presentados en trabajos futuros.


100

5.2 Trabajos futuros

Automatización de los métodos de transformación para la generación del DC a partir de los DCU mediante una herramienta de software escrita en cualquier tipo de lenguaje orientado a objetos.

Formalización de los métodos de transformación para darle un sentido formal a las reglas de transformación creadas a partir de mecanismos semánticos.

Formalización de los diagramas del UML restantes, para darles un sentido formal a lo especificado por la OMG (superestructura e infraestructura) con respecto a los diagramas del UML.

Definir el nivel de abstracción o detalle en los diagramas de casos de uso que nos permita una mejor identificación de los elementos pertenecientes a los diagramas de clases.

5.3 Publicación

Adán Hernández Estrada, Máximo López Sánchez. “Definición de Elementos de Transformación entre Diagramas de Casos de Uso y Clases del UML”. Conferencia Iberoamericana en Sistemas, Cibernética e Informática CISCI 2010.

Referencias

101

Referencias [ALRA00] Alarcón Raúl, “Diseño Orientado a Objetos con UML” Grupo EIDOS Consultaría

y Documentación Informática, S.L.,2000, ISBN 84-88457-03-0, [fecha de

consulta: 21 de Enero 2009].

[BEGH09] Arif Bilgin, John Ellson, Emden Gansner, Yifan Hu, Yehuda Koren, StephenNorth, “Graphviz - Graph Visualization Software”, año de publicación:

2009. http://www.graphviz.org/ AT&T Research, [fecha de consulta: 1 de

Noviembre 2009].

[BORO03] Boris Roussev, "Generating OCL Specifications and Class Diagrams from Use

Cases: A Newtonian Approach," hicss, vol. 9, pp.321b, 36th Annual Hawaii International Conference on System Sciences (HICSS'03) - Track 9, 2003, [fecha

de consulta: 21 de Febrero 2010].

[BOOC94] Booch, G., “Object-Oriented Analysis and Design with Applications” segunda

edición, Addison-Wesley. 1994. ISBN-13: 978-0-8053-5340-2, [fecha de consulta: 21 de Febrero 2010].

[CCPO99] Danny C.C. Poo, "Events in Use Cases as a Basis for Identifying and Specifying

Classes and Business Rules," tools, pagina 204, Technology of Object-Oriented

Languages and Systems, 1999. Publicado en IEEE Computer Society

Washington, DC, USA. ISBN:0-7695-0275-X. [fecha de consulta: 2 de Febrero 2010].

[CBJO01] C.Bjork Rusell, “A simulation of an Automated Teller Machine (ATM)” Gordon

College in Wenham, Massachusetts, 2001. http://www.math-

cs.gordon.edu/courses/cs211/ATMExample/. [fecha de consulta: 4 de Agosto 2010].

[CBJO08] C.Bjork, “Maintaining a very simple address book” Rusell Gordon College in

Wenham, Massachusetts, 2008.

http://www.cs.gordon.edu/courses/cs211/AddressBookExample/index.html,

[fecha de consulta: 4 de Agosto 2010].

[CAFE10] Canchala Fernandez Luis Armando “Sistema administrador de proyectos”,

2010. http://msdn.microsoft.com/es-es/library/bb972214.aspx Universidad

del Valle de Cali Colombia, [fecha de consulta: 4 de Agosto 2010].

[CARC01] Cárcamo Caramazana Alberto, “Tecnologias MDA (Model Driven Architecture)

para el desarrollo de Software”, European Conference on Object-Oriented

Programming, Budapest Hungría, 2001. [fecha de consulta: 9 Noviembre 2009].

[CHWA04] Chi Wa Lai, Wang Leong Chung. “E-ticket System”, Apuntes de la materia:

“Object-Oriented Analysis & Design with Unified Modeling Language”, Hong Kong 2004, http://www.docstoc.com/docs/3804399/E-ticket-System, [fecha

de consulta: 4 de Agosto 2010].

[GRAE99] Graeme Smith “The Object-Z Specification Language” Software Verification

Research Centre University of Queensland, Brisbane, Australia. Julio, 1999. ISBN: 978-0-7923-8684-1, [fecha de consulta: 8 de Abril 2010].

http://www.graphviz.org/

http://www.cs.gordon.edu/courses/cs211/AddressBookExample/index.html

http://www.docstoc.com/docs/3804399/E-ticket-System

Referencias

102

[HCKT07] Henning Christiansen, Christian Theil Have, Knut Tveitane, “From Use Cases to

UML Class Diagrams using Logic Grammars and Constraints”, Roskilde

University, IT University of Copenhagen, International Conference: Recent

Advances in Natural Language Processing, paginas 128-132, Shoumen,

Bulgaria, INCOMA Ltd. 2007, [fecha de consulta: 17 de Octubre 2009].

[HEOR08] Hernández Orallo Enrique, “El Lenguaje Unificado de Modelado (UML)”

http://www.todoprogramas.com/manuales/ficheros/2008/4.3359.4702.pdf,

año de publicación 2008. [fecha de consulta: 4 de Agosto 2010].

[INFR09] OMG Unified Modeling Language TM (OMG UML), Infrastructure Version 2.2 Standard document URL: http://www.omg.org/spec/UML/2.2/Infrastructure,

fecha de publicación: 4 de febrero del 2009. [fecha de consulta: 9 de Noviembre

2009].

[IEEE98] Software Engineering Technical Committee of the IEEE Computer Society, USA,

“IEEE standard for software test documentation”, 16 de diciembre de 1998, E-ISBN: 0-7381-1444-8, ISBN: 0-7381-1443-X, [fecha de consulta: 4 de Agosto

2010].

[JAIV03] Jacobson Ivar, “Use Cases and Aspects –Working Seamlessly Together” Journal

of Object Technology, Vol. 2, No. 4, Julio-Agosto 2003 http://www.jot.fm/issues/issue_2003_07/column1.pdf, [fecha de consulta: 1

Julio 2010].

[KACO90] Kang C. Kyo, Cohen G. Sholom, “Technical Report CMU/SEI-90-TR-21 ESD-

90-TR-222 Feature-Oriented Domain Analysis (FODA) Feasibility Study”,

Instituto de Ingenieria de Software, Universidad Carnegie Mellon, Noviembre 1990, [fecha de consulta: Noviembre 2009].

[KRUT93] Krut, Jr. Robert W., “Technical Rep CMU/SEI-93-TR-11, Integrating 001 Tool

Support into, the Feature-Oriented Domain Analysis Methodology”, Instituto de

Ingenieria de Software, Universidad Carnegie Mellon, Mayo 1993, [fecha de consulta: Noviembre 2009].

[KCHN09] Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak, “Feature-

Oriented Domain Analysis” publicado por el Instituto de Ingeniería de software

de la Universidad de Carnegie Mellon Pittsburgh Pensilvania, Noviembre 2009

http://www.sei.cmu.edu/library/abstracts/reports/90tr021.cfm, [fecha de consulta: 4 Noviembre 2009].

[LIAY03] Ying Liang. “From use cases to classes: a way of building object model with

UML” Information and Software Technology, Volume 45, Number 2, 1 Febrero

2003 , pp. 83-93. Elseiver. ISSN 0950-5849, [fecha de consulta: 10 de Septiembre 2009].

[MOFS06] Meta Object Facility (MOF) Core Specification OMG Available Specification

Versión 2.0. fecha de publicación: Junio 2006.

http://www.omg.org/spec/MOF/2.0/, [fecha de consulta: 20 Noviembre 2009].

[NASH07] Nazar Jason, Shwartz Alon. “Use Case Diagram Library System” año de

publicación: 2007.. http://www.docstoc.com/docs/4212157/Use-Case-

Diagram--Library-System, [fecha de consulta: 4 de Agosto 2010].

http://www.todoprogramas.com/manuales/ficheros/2008/4.3359.4702.pdf

http://www.omg.org/spec/UML/2.2/Infrastructure

http://www.jot.fm/issues/issue_2003_07/column1.pdf

http://www.sei.cmu.edu/library/abstracts/reports/90tr021.cfm

http://www.omg.org/spec/MOF/2.0/

http://www.docstoc.com/docs/4212157/Use-Case-Diagram--Library-System

http://www.docstoc.com/docs/4212157/Use-Case-Diagram--Library-System

Referencias

103

[NEIG81] Neighbors, J. Software “Construction Using Components” Tesis Doctoral,

Departamento de Información y ciencias Computacionales, Universidad de

California, Irvine, 1981, [fecha de consulta: Noviembre 2009].

[NUOR08] Núñez Ortega Eduardo Lorenzo “Definición de métodos heurísticos para

reestructurar marcos de aplicación orientados a objetos hacia el patrón de diseño Modelo-Vista-Controlador” Tesis de Maestría Centro Nacional de

Investigación y Desarrollo Tecnológico, Departamento de Ciencias

Computacionales, fecha de publicación: Febrero del 2008 [fecha de consulta: 19

de Julio 2010].

[OMG09] Unified Modeling Language Specification OMG, www.omg.org, Object

Management Group, fecha de actualización: Enero del 2009 [fecha de consulta:

1 de Noviembre 2009].

[PAPR03] Patchi Prasath S. Arul “UML Diagrams Example-Weather Monitoring System”.

http://www.scribd.com/doc/10481203/UML-Diagrams-ExampleWeather-Monitoring-System, año de publicación: 2003. [fecha de consulta: 4 de Agosto

2010].

[PRIE 90] Prieto Díaz, “Domain Analysis En: Software engineering Notes”, ACM

SIGSOFT,1990, vol.15,n.. 02, p.47-54, [fecha de consulta: Noviembre 2009].

[PEAR85] Pearl, J., “Heuristicas: estrategias de búsqueda inteligente para resolver

problemas computacionales”, Addison Wesley, pp.3., año de publicación: 1985

[fecha de consulta: Noviembre 2009].

[SUPE09] OMG Unified Modeling Language TM (OMG UML), Superstructure Version 2.2 Standard document, fecha de publicación: 2 de febrero del 2009.

http://www.omg.org/spec/UML/2.2/Superstructure, [fecha de consulta: 9 de

Noviembre 2009].

[SPIV92] Spivey, J.M. “The Z Notation: A Reference Manual” segunda edición, Prentice Hall. Object Orientation and Z. 1992 ISBN : 0-139-78529-9, [fecha de consulta:

8 de Abril 2010].

[SGFP00] S. Giandin Roxana, F. Pons Claudia. “Relaciones entre Casos de Uso en el

Unified Modeling Language”, The Colombian Journal of Computation ,Vol 1 No. 1, ISSN 1657-2831, Bucaramanga, Diciembre de 2000, [fecha de consulta:

10 de Septiembre 2009].

http://www.omg.org/spec/UML/2.2/Superstructure

Centro Nacional de Investigación y Desarrollo … · Resumen Este trabajo de investigación...

Documents

Transcript of Centro Nacional de Investigación y Desarrollo … · Resumen Este trabajo de investigación...