cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS

Transcripción

1 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

2 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.

3 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.

4

5 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 PLANTEAMIENTO DEL PROBLEMA OBJETIVO JUSTIFICACIÓN Y BENEFICIOS TRABAJOS RELACIONADOS From Use Cases to UML Class Diagrams using Logic Grammars and Constraints [HCKT07] Relaciones entre Casos de Uso en el Unified Modeling Language [SGFP00] Generating OCL Specifications and Class diagrams from Use Cases: A Newtonian Approach [BORO03] Events in Use Cases as a Basis for Identifying and Specifying Classes and Business Rules [CCPO99] From use cases to classes: a way of building object model with UML [LIAY03] Comparativa trabajos relacionados ALCANCES Y LIMITACIONES... 9 CAPÍTULO 2. MARCO TEÓRICO ANÁLISIS DE DOMINIO ANÁLISIS FODA METAMODELO DIAGRAMAS DE CASOS DE USO DIAGRAMAS DE CLASES TRANSFORMACIÓN LENGUAJE Z CAPÍTULO 3. MÉTODO DE SOLUCIÓN ANÁLISIS DE LOS METAMODELOS DEL UML Diagrama de casos de uso Descripción de conceptos Actor Descripción Restricciones Semántica Notación Caso de uso Descripción Restricciones Semántica Notación Extend Descripción Restricciones Semántica Notación i

6 ii Ejemplo Justificación Include Descripción Semántica Notación Ejemplo Nodos gráficos Diagrama de clases Descripción de conceptos Clases Descripción Semántica Notación Dependencia Semántica Notación Asociación Semántica Notación Generalización Descripción Semántica Notación Interfaz Descripción Notación Diagramas APLICACIÓN DEL MÉTODO FODA Análisis de Contexto UML Ciclo de vida del software (UML) Diagramas de casos de uso Diagramas de clase Modelado del Dominio Diagrama de casos de uso Notación: Definición de la notación: Diagrama de características: Diagrama de clases Notación Definición de la notación: Diagrama de características FORMALIZACIÓN Diagramas de Casos de Uso Declaraciones Esquema CU Diagrama de Clases Declaraciones Esquema CLASE MECANISMO DE COMPARACIÓN Comparación entre elementos Comparación entre CU, Actor, Clase, Operación y Atributo Comparación entre las relaciones pertenecientes a los DCU y DC Métodos de transformación Desarrollo de los métodos de transformación Método de transformación T0: caso de uso a clase... 64

7 Método de transformación T1: relación de generalización a relación de generalización/especialización Método de transformación T2: relación include a relación de composición CAPÍTULO 4. PRUEBAS CONVENCIÓN DE NOMBRES PLAN DE PRUEBAS a) Introducción b) Elementos de prueba c) Características a probar d) Características excluidas de las pruebas e) Pruebas realizar f) Enfoque g) Criterio éxito/fracaso de casos de prueba h) Criterios de suspensión y requerimientos de reanudación i) Tareas de pruebas j) Liberación de pruebas k) Responsabilidades l) Riesgos y contingencias m) Aprobación CASOS DE PRUEBA DESCRIPCIÓN DE LOS CASOS DE PRUEBA MDT-01 Transformación de caso de uso a clase a) Propósito b) Entorno de prueba MDT Transformación de caso de uso a clase para el sistema ATM [CBJO01] a) Propósito b) Entorno de prueba c) Proceso d) Resultado esperado MDT Transformación de caso de uso a clase para el sistema administrador de proyectos [CAFE10] a) Propósito b) Entorno de prueba c) Proceso d) Resultado esperado MDT-02 Transformación de relación de generalización a relación de generalización/especialización.81 a) Propósito b) Entorno de prueba MDT Transformación de relación de generalización a relación de generalización/especialización para el sistema ATM [CBJO01] a) Propósito b) Entorno de prueba c) Proceso d) Resultado esperado MDT 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 b) Entorno de prueba c) Proceso d) Resultado esperado Método de transformación T2: relación include a relación de composición a) Propósito b) Entorno de prueba MDT Transformación de relación include a relación de composición para el sistema ATM [CBJO01].. 83 a) Propósito b) Entorno de prueba iii

8 c) Proceso d) Resultado esperado MDT Transformación de relación include a relación de composición para el sistema administrador de proyectos [CAFE10] a) Propósito b) Entorno de prueba c) Proceso d) Resultado esperado RESULTADOS DE PRUEBAS EVALUACIÓN DE RESULTADOS CAPÍTULO 5. CONCLUSIONES CONCLUSIONES TRABAJOS FUTUROS PUBLICACIÓN REFERENCIAS iv

9 Lista de figuras Figura 1: Método de solución Figura 2: Representación de un usuario en los diagramas casos de uso Figura 3: Notación de casos de uso Figura 4: Ejemplo de una relación de extensión entre casos de uso Figura 5: Ejemplo de una relación de inclusión entre casos de uso Figura 6: Notación de clase Figura 7: Dependencia entre elementos Figura 8: Tipos de asociaciones Figura 9: Ejemplo de generalización Figura 10: Ejemplo de dependencia de la realización de un clasificador a una interfaz Figura 11: Diagramas del UML Figura 12: Diagrama de contexto de los DCU y DC Figura 13: Diagrama de características de los CU Figura 14: Diagrama de características de los actores Figura 15: Diagrama de características de los tipos de relaciones Figura 16: Diagrama de características de los DCU (elementos principales) Figura 17: Diagrama de características de los DC (elementos principales) Figura 18: Diagrama de características de las clases Figura 19: Diagrama de características de los atributos Figura 20: Diagrama de características de las operaciones Figura 21: Diagrama de Características de los parámetros Figura 22: Diagrama de características de las relaciones de los DC Figura 23: Diagrama de características de la relación de dependencia/realización Figura 24. Procedimiento de comparación heurística Figura 25: Mapeo de entidad y verbo a clase y operación Figura 26: Entidad en un actor no puede ser mapeada a clase Figura 27: Mapeo de relación de asociación (DCU) a relación de asociación (DC) Figura 28: Mapeo de relación include (DCU) a relación de composición (DC) 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 Figura 31. Diagrama de actividad para generar clases a partir de casos de uso Figura 32. Diagrama de actividad para mapear la relación de generalización (DCU) a los DC Figura 33. Diagrama de actividad para mapear relación include a los DC Figura 34. Diagrama de casos de uso de sistema ATM Figura 35. Resultado obtenido al aplicar el método de transformación T Figura 36. Diagrama de clases final del sistema ATM Figura 37. Resultado obtenido al aplicar el método de transformación T Figura 38. Resultado obtenido al aplicar el método de transformación T Figura 39. Diagrama de casos de uso del sistema administrador de proyectos Figura 40. Resultado obtenido al aplicar el método de transformación T Figura 41. Diagrama de clases final del sistema administrador de proyectos Figura 42. Posible confusión entre atributo y clase v

10 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 TABLA 3. ELEMENTOS DE UN DIAGRAMA DE CLASES TABLA 4. NOTACIÓN EMPLEADA PARA LAS CARACTERÍSTICAS DE LOS DCU TABLA 5. NOTACIÓN EMPLEADA PARA LAS CARACTERÍSTICAS DE LOS DC TABLA 6. CARACTERÍSTICAS DE CU, ACTOR, CLASE, OPERACIÓN Y ATRIBUTO DE LA SUPERESTRUCTURA TABLA 7. CARACTERÍSTICAS DE LAS RELACIONES DE LOS DCU Y DC TABLA 8. CARACTERÍSTICAS DE LAS RELACIONES DE LOS DCU Y DC TABLA 9. DESCRIPCIÓN DE LAS TAREAS DE PRUEBA TABLA 10. RESULTADOS DEL CASO DE PRUEBA MDT TRANSFORMACIÓN DE CASO DE USO A CLASE PARA EL SISTEMA ATM [CBJO01] TABLA 11. RESULTADOS DEL CASO DE PRUEBA MDT TRANSFORMACIÓN DE RELACIÓN DE GENERALIZACIÓN A RELACIÓN DE GENERALIZACIÓN/ESPECIALIZACIÓN PARA EL SISTEMA ATM [CBJO01] TABLA 12. RESULTADOS DEL CASO DE PRUEBA MDT TRANSFORMACIÓN DE RELACIÓN INCLUDE A RELACIÓN DE COMPOSICIÓN PARA EL SISTEMA ATM [CBJO01] TABLA 13. RESULTADOS DEL CASO DE PRUEBA MDT TRANSFORMACIÓN DE CASO DE USO A CLASE PARA EL SISTEMA ADMINISTRADOR DE PROYECTOS [CAFE10] TABLA 14. RESULTADOS DEL CASO DE PRUEBA MDT TRANSFORMACIÓN DE RELACIÓN DE GENERALIZACIÓN A RELACIÓN DE GENERALIZACIÓN/ESPECIALIZACIÓN PARA EL SISTEMA ADMINISTRADOR DE PROYECTOS [CAFE10] TABLA 15. RESULTADOS DEL CASO DE PRUEBA MDT TRANSFORMACIÓN DE RELACIÓN INCLUDE A RELACIÓN DE COMPOSICIÓN PARA EL SISTEMA ADMINISTRADOR DE PROYECTOS [CAFE10] vi

11 Glosario de términos y siglas OMG MOF (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]. (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 FODA (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. (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]. vii

12

13 Introducción 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. 1

14 Introducción 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. 2

15 Capítulo 1. Descripción de la Investigación 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. 3

16 Capítulo 1. Descripción de la Investigación 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. 4

17 Capítulo 1. Descripción de la Investigación 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 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) 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. 5

18 Capítulo 1. Descripción de la Investigación 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 contraactor (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 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 preevento, 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. 6

19 Capítulo 1. Descripción de la Investigación 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 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. 7

20 Capítulo 1. Descripción de la Investigación 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]. Relaciones entre Casos de Uso en el Unified Modeling Language [SGFP00]. Generating OCL Specifications and Class diagrams from Use Cases:A Newtonian Approach [BORO03]. Escenarios de casos de uso. Casos de uso Narrativa de especificación de CU. La semántica del lenguaje natural, Procesamiento de lenguaje natural. Formalización (Algebra para CU) Generación de máquinas de estado a partir de CU. Generación de clases a partir de las máquinas de estados. Verbos, Sustantivos, Relaciones. Relación extends, uses y generalización. Clases y relaciones Lenguaje restringido Se basan únicamente en elementos sintácticos del sistema. No métodos. No atributos. Herramienta para la generación automática de DC. Reglas formales 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 entidadcaso 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. 8

21 Capítulo 1. Descripción de la Investigación 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. 9

22

23 Capítulo 2. Marco Teórico 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. 11

24 Capítulo 2. Marco Teórico 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 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. 12

25 Capítulo 2. Marco Teórico 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. 13

26

27 Capítulo 3. Método de Solución 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). 15

28 Capítulo 3. Método de Solución 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. Análisis de Metamodelos del UML Estudio de FODA Formalizar la caracterización de los elementos Caracterización de elementos DCU y DC 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 Figura 1: Método de solución 16

29 Capitulo 3. Método de Solución 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 Language TM (OMG UML), Infrastructure versión 2.2 y OMG Unified Modeling Language TM (OMG UML), Superstructure versión 2.2, publicadas por el Grupo de Gestión de Objetos (OMG) 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 Descripción de conceptos Actor Un actor especifica un rol desempeñado por un usuario o por otro sistema que interactúa con el sujeto 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 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. 17

30 Capítulo 3. Método de Solución Semántica Cuando una entidad externa interactúa con el sujeto, ésta desempeña el rol de actor específico 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. <<actor>> Cliente Cliente Usuario Figura 2: Representación de un usuario en los diagramas casos de uso. De [SUPE09], p.589, 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 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 poscondiciones, también mediante texto en lenguaje natural e inclusive estas descripciones pueden ser combinadas Restricciones Un caso de uso debe tener un nombre. Sólo puede estar involucrado en asociaciones binarias 18

31 Capítulo 3. Método de Solución Semántica La ejecución de un caso de uso es una ocurrencia de un comportamiento emergente 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. Depositar Dinero Transferir Dinero Extend Figura 3: Notación de casos de uso. De [SUPE09], p.598. 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 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 Restricciones 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 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á. 19

32 Capítulo 3. Método de Solución 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 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. Condición: {cliente seleccionó AYUDA Punto de extensión: Selección} Puntos extensión Selección <<extend>> Ayuda on-line Realizar Transacción ATM Figura 4: Ejemplo de una relación de extensión entre casos de uso. De [SUPE09], p 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 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 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. 20

33 Capítulo 3. Método de Solución 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 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>> 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. Retirar <<include>> Presentar Identificación Nodos gráficos Figura 5: Ejemplo de una relación de inclusión entre casos de uso. De [SUPE09], p.596. 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 Personalizado Caso de Uso Retirar Extend <<extend>> Puntos extensión Selección Caso de uso extendido Caso de uso extensión 21

34 Capítulo 3. Método de Solución Include Retirar <<include>> Presentar Identificación Caso de uso que incluye Caso de uso incluido Generalización Generalización Persona Hombre 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 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 Descripción de conceptos Clases Una clase describe un conjunto de objetos que comparten las mismas especificaciones de características, restricciones y semántica 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 22

35 Capítulo 3. Método de Solución sólo lectura, escritura, estático o cualquier otra cosa; adicionalmente un atributo puede tener propiedades como visibilidad (para otras clases) y multiplicidad 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 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. 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 () Figura 6: Notación de clase. De [SUPE09], p

36 Capítulo 3. Método de Solución 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 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 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. <<Nombre de la dependencia>> Cliente Proveedor Figura 7: Dependencia entre elementos. De [SUPE09], p 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 24

37 Capítulo 3. Método de Solución 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 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 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. 25

38 Capítulo 3. Método de Solución 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. A Asociación Binaria AB B A B A B Figura 8: Tipos de asociaciones. De [SUPE09], p Generalización Descripción Una generalización es una relación taxonómica entre un clasificador más general y uno más específico 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 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. 26

39 Capítulo 3. Método de Solución Persona género género estatus Persona Femenina Persona Masculina Empleado Figura 9: Ejemplo de generalización. De [SUPE09], p Interfaz 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 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). ISensor Sensor de Proximidad Figura 10: Ejemplo de dependencia de la realización de un clasificador a una interfaz. De [SUPE09], p

40 Capítulo 3. Método de Solución 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

41 Capítulo 3. Método de Solución 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 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 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 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, 29

42 Capítulo 3. Método de Solución 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. Diagramas de secuencias Diagramas de casos de uso Diagramas de clases Diagramas de colaboración Modelos Diagramas de objetos Diagramas de componentes Diagramas de estados Diagramas de actividades Diagramas de difusión 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. 30

43 Capítulo 3. Método de Solución Problema Fases de desarrollo de software Requerimientos Modelo de casos de uso Diagramas de casos de uso Análisis Modelo de análisis Diagramas de objetos Diagramas de componentes Diseño Implementación Modelo de diseño Modelo de implementación Diagramas de clases Diagramas de difusión Diagramas de actividades Pruebas Solución Modelo de pruebas Diagramas de colaboración Diagramas de secuencia Diagramas de estados Diagramas de casos de uso Figura 12: Diagrama de contexto de los DCU y DC. 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. 31

44 Capítulo 3. Método de Solución 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 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 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. 32

45 Capítulo 3. Método de Solución Diagrama de casos de uso 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 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. 33

46 Capítulo 3. Método de Solución 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). 34

47 Capítulo 3. Método de Solución 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. 35

48 Capítulo 3. Método de Solución 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. 36

49 Capítulo 3. Método de Solución Diagrama de características: CU nombre fc pe comp 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. ACTOR nombre ubicación interactúa rol representa interno externo false true humano hardware otro tipo 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. 37

50 Capítulo 3. Método de Solución RELACION tipo nombre GENERALIZACION ASOCIACION INCLUDE EXTENDS GEN-CU GEN-ACTORES ACTOR-CU ASOC-ACTORES Rest CUB CUI CUB CUE CUP CUH ACTORP ACTORH ACTOR CU ACTOR ACTOR-2 D-CUB compb compi compb compe HP-CUP HP-ACTORP P-ACTOR P-ACTOR D-CUI I-compI E-compE 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. 38

51 Capítulo 3. Método de Solución DCU CU ACTOR RELACION 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. 39

52 Capítulo 3. Método de Solución Diagrama de clases 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 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. 40

53 Capítulo 3. Método de Solución 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). 41

54 Capítulo 3. Método de Solución 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. 42

55 Capítulo 3. Método de Solución 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. 43

56 Capítulo 3. Método de Solución Diagrama de características DC CLASE INT RELACION 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. CLASE AS nombre ATRIBUTO OPERACION tipo ERACIONES ABS Figura 18: Diagrama de características de las clases. CONC R 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. 44

57 Capítulo 3. Método de Solución ATRIBUTO visibilidad nombre tipo multiplicidad valor-df modificador PUB PRIV PROT PAQ DF int byte boolean char float double OT readonly redefine s unique OT 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. 45

58 Capítulo 3. Método de Solución OPERACION ERACIONES visibilidad nombre PARÁMETRO tipo-retorno propiedad PUB PRIV PROT PAQ DF void int byte boolean char float double OT unique query ordered 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. 46

59 Capítulo 3. Método de Solución PARAMETRO dirección nombre tipo valor-df modificador in out inout DF int byte boolean char float double OT readonly redefine s 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. 47

60 Capítulo 3. Método de Solución RELACION tipo nombre GEN/ESP ASOCIACION COMPOSICION AGREGACION DEP/REAL SPCL SBCL CL1 CL2 Rest CLCOM CLCOMP CLCOM CLCOMP Rest D-CLCOM D-CLCOM HP-SPCL RE-CL2 RE-CL1 D-CLCOMP CLCOMP ND-CLCOMP 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. 48

61 Capítulo 3. Método de Solución DEP/REAL CLC CLP DE-CLP IE-CLP 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. 49

62 Capítulo 3. Método de Solución 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 Diagramas de Casos de Uso 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] 50

63 Capítulo 3. Método de Solución Esquema CU El siguiente esquema contempla las características que pertenecen a un CU. CU. nombre : NomCU fc : P FC pe : P 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)) 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 : P FC fc denota el subconjunto de los fragmentos de comportamiento existentes para el caso de uso. pe : P 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. 51

64 Capítulo 3. Método de Solución 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 Diagrama de Clases 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 52

65 Capítulo 3. Método de Solución Esquema CLASE El siguiente esquema contempla las características que pertenecen a las clases. CLASE. nombre : NomCL atributos : P ATRIBUTO At, At 1 : atributos operaciones : P OPERACION Op, Op 1 : operaciones tipo: TipoClase nombre {Ø} At, At 1 atributos At.nombre=At 1.nombre At=At 1 Op, Op 1 operaciones Op.nombre=Op 1.nombre Op=Op 1 tipo=abstracta tipo=concreta (tipo=abstracta tipo=concreta) tipo= abstracta Ǝ Op OperacionAbstracta(Op) tipo= concreta Op OperacionConcreta(Op) {At, At 1} atributos (At {At, At 1} At atributos) {Op, Op 1} operaciones (Op {Op, Op 1} Op operaciones) 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 : P ATRIBUTO atributos denota el conjunto de los atributos disponibles para la clase. At. At 1 : atributos At, At 1 son declaradas como variables extraídas del conjunto atributos. operaciones : P OPERACION operaciones denota el conjunto de las operaciones disponibles para la clase. Op, Op 1 : operaciones Op, Op 1 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) 53

66 Capítulo 3. Método de Solución Donde los predicados: nombre {Ø} Hace referencia a la característica obligatoria que indica que cada clase debe contar con un nombre. At, At 1 atributos At.nombre=At 1.nombre At=At 1 Op, Op 1 operaciones Op.nombre=Op 1.nombre Op=Op 1 clase. Hace referencia a la unicidad de los atributos y operaciones definidos para la 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, Op 1} operaciones (Op {Op, Op 1} Op operaciones) {At, At 1} atributos (At {At, At 1} 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 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. 54

67 Capítulo 3. Método de Solución 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. Análisis Diagramas Características DCU y DC Análisis Semántica de elementos DCU y DC Creación Tablas Comparativas Análisis Tablas Comparativas Figura 24. Procedimiento de comparación heurística 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. 55

68 Capítulo 3. Método de Solución Tabla 6. Características de CU, Actor, Clase, Operación y Atributo de la superestructura. Elemento CU Clase Operación Atributo Actor Composición Nombre verbo + sustantivo sustantivo verbo sustantivo sustantivo Objetivo Especificar un conjunto de acciones (comportamiento) desarrolladas por un sistema. Describir un conjunto de objetos que comparten las misma especificación de características, restricciones y semántica Definir un comportamiento de una clase de objetos Describir característica de una clase de objetos interactuar con el sistema Se compone de Objetivo y Escenarios Atributos y operaciones Atributos y Parámetros Propiedades y modificadores Rol Tipo Clasificador Comportamiento. Restringido a casos de uso Estructura. Restringido a clases --- Tipo Abstracto o concreto Abstracto o concreto. Abstracto no Abstracto Se relaciona con CU y actores (Asociaciones binarias) Clases (Asociaciones binarias) Operaciones Comportamiento. Restringido a actores Abstracto o concreto CU, Actor, Componentes y Clases (Asociaciones binarias) Observación Las acciones recaen sobre una entidad para lograr un objetivo. Es una entidad que participa para lograr un objetivo Representa un comportamien to sobre una entidad Característica de clase Representa una entidad que interactúa con el sujeto relevante para un caso de uso. Externo al sistema Similitud Clase y Operación CU Característica de comportamiento (acciones de un CU) CU, atributos de tipo definidos por el usuario o clase o de tipo primario

69 Capítulo 3. Método de Solución 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. Entidad Entidad Verbo Operación Figura 25: Mapeo de entidad y verbo a clase y operación. 57

70 Capítulo 3. Método de Solución 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. Entidad Entidad 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 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. 58

71 Capítulo 3. Método de Solución Tabla 7. Características de las relaciones de los DCU y DC. Tipo de relación Asociación (DCU) Generalización (DCU) Extend Include Composición (Agregación fuerte) Especifica Implica Relaciona/Asociación Restricción Similitud Dos elementos pueden comunicarse entre sí. Relación entre un elemento general con un elemento especifico. Cómo y cuándo el comportamiento definido en un CU extensión será insertado dentro del comportamiento definido en un CU base Un caso de uso contiene el comportamiento definido en otro caso de uso (entidad sobre la cual recae la acción) Un elemento está compuesto por partes más pequeñas que influencian en su comportamiento. Participación activa de un elemento en otro. El elemento especifico hereda las propiedades del elemento general Posible extensión de comportamiento del CU base Asociación fuerte. El CU base puede sólo depender del resultado del caso de uso incluido. Asociación fuerte entre un todo y sus partes. Las partes sólo pueden participar en una composición a la vez Actor-CU y Actor-Actor Asociación binaria --- CU-CU y Actor-Actor CU-CU CU-CU Clase-Clase Asociación binaria. Asociación binaria. La extensión se lleva a cabo en puntos de extensión definidos en el CU base 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. 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. Gen/Esp (DC) ---- Composición Include 59

72 Capítulo 3. Método de Solución Tabla 8. Características de las relaciones de los DCU y DC. Tipo de relación Agregación Débil Asociación (DC) Dep/Real Gen/Esp Especifica Implica Relaciona/Asociación Restricción Similitud Cómo los elementos más complejos se construyen de una colección de elementos simples. Relación semántica que puede ocurrir entre 2 elementos. Un elemento o conjunto de elementos del modelo requieren de otro elemento o elementos para su especificación o realización. 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. Asociación entre un todo y sus componentes dentro del cual una o más clases son partes de un conjunto. Los elementos de una clase están relacionados con los elementos de otra clase. Una relación cliente-proveedor entre elementos del modelo, donde la modificación del proveedor puede impactar los elementos del modelo del cliente. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber más de una clase que se comporte como subclase. Clase-Clase Clase-Clase Clase-Clase Clase-Clase Asociación binaria. --- Asociación binaria. Asociación binaria. Asociación binaria Generalización (DCU) 60

73 Capítulo 3. Método de Solución 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. Verbo Entidad Entidad Entidad Operación Entidad 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. 61

74 Capítulo 3. Método de Solución 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. 62

75 Capítulo 3. Método de Solució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 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 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. Metamodelo Fuente (Casos de Uso) Métodos Transformación Metamodelo Destino (Diagrama de Clases) Figura 30: Esquema de transformación a nivel de Metamodelos 63

76 Capítulo 3. Método de Solución 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. 64

77 Capítulo 3. Método de Solución 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. 65

78 Capítulo 3. Método de Solución 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. 66

79 Capítulo 3. Método de Solución 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 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 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. 67

80 Capítulo 3. Método de Solución 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. 68

81 Capítulo 3. Método de Solución 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. 69

82 Capítulo 3. Método de Solución 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) 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. 70

83 Capítulo 3. Método de Solución 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. 71

84

85 Capítulo 4. Pruebas 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 [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 73

86 Capítulo 4. Pruebas 4.2 Plan de pruebas a) Introducción El presente plan de pruebas está basado en el estándar IEEE [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]. 74

87 Capítulo 4. Pruebas 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 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. 75

88 Capítulo 4. Pruebas 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 Transformación de caso de uso a clase para el sistema ATM [CBJO01]. MDT 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 Transformación de relación de generalización a relación de generalización/especialización para el sistema ATM [CBJO01]. MDT 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 Transformación de relación include a relación de composición para el sistema ATM [CBJO01]. MDT Transformación de relación include a relación de composición para el sistema administrador de proyectos [CAFE10]. 76

89 Capítulo 4. Pruebas 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 77

90 Capítulo 4. Pruebas 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 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 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. 78

91 Capítulo 4. Pruebas MDT 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 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 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 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. 79

92 Capítulo 4. Pruebas 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 MDT 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. 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 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. 80

93 Capítulo 4. Pruebas MDT 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. 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 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. d) Resultado esperado 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 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. b) Entorno de prueba 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 81

94 Capítulo 4. Pruebas generalización/especialización, se tiene como requisito que tanto los DCU como los DC de los sistemas se encuentren modelados MDT 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. b) Entorno de prueba 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. d) Resultado esperado 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 MDT 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. 82

95 Capítulo 4. Pruebas b) Entorno de prueba 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. d) Resultado esperado 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 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. b) Entorno de prueba 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 MDT 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. 83

96 Capítulo 4. Pruebas b) Entorno de prueba 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. d) Resultado esperado 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 MDT 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. b) Entorno de prueba 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. d) Resultado esperado 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. 84

97 Capítulo 4. Pruebas 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 Transformación de caso de uso a clase para el sistema ATM [CBJO01]. Caso de prueba: MDT 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 85

98 Capítulo 4. Pruebas 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. 86

99 Capítulo 4. Pruebas Figura 36. Diagrama de clases final del sistema ATM. 87

100 Capítulo 4. Pruebas 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 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 Transformación de relación de generalización a relación de generalización/especialización 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 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) 88

101 Capítulo 4. Pruebas 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: Figura 37. Resultado obtenido al aplicar el método de transformación T1. 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 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 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). Responsable de la prueba: Adán Hernández Estrada Cargo: Autor 89

102 Capítulo 4. Pruebas Tabla 12. Resultados del caso de prueba MDT Transformación de relación include a relación de composición para el sistema ATM [CBJO01]. Caso de prueba: MDT Transformación de relación include a relación de composición 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 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). Figura 38. Resultado obtenido al aplicar el método de transformación T2. 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 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 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. Responsable de la prueba: Adán Hernández Estrada Cargo: Autor 90

103 Capítulo 4. Pruebas Tabla 13. Resultados del caso de prueba MDT Transformación de caso de uso a clase para el sistema administrador de proyectos [CAFE10]. Caso de prueba: MDT 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. 91

104 Capítulo 4. Pruebas 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 92

105 Capítulo 4. Pruebas 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 40. Resultado obtenido al aplicar el método de transformación T0. Observaciones: Figura 41. Diagrama de clases final del sistema administrador de proyectos. 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 93