TESIS DE MAESTRÍA EN CIENCIAS - CENIDET · Caracterización de las Fronteras de los Modelos MDA...
187
cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Caracterización de las Fronteras de los Modelos MDA Mediante UML presentada por Edna Daniela López López Lic. en Informática por la Universidad Autónoma de Sinaloa Como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación Director de tesis: Dr. Moisés González García Co-Director de tesis: Dr. Máximo López Sánchez Cuernavaca, Morelos, México. 10 de Diciembre de 2007
Transcript of TESIS DE MAESTRÍA EN CIENCIAS - CENIDET · Caracterización de las Fronteras de los Modelos MDA...
cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Caracterización de las Fronteras de los Modelos MDA Mediante UML
presentada por
Edna Daniela López López Lic. en Informática por la Universidad Autónoma de Sinaloa
Como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis: Dr. Moisés González García
Co-Director de tesis:
Dr. Máximo López Sánchez Cuernavaca, Morelos, México. 10 de Diciembre de 2007
cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Caracterización de las Fronteras de los Modelos MDA Mediante UML
presentada por
Edna Daniela López López Lic. en Informática por la Universidad Autónoma de Sinaloa
Como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis: Dr. Moisés González García
Co-Director de tesis:
Dr. Máximo López Sánchez
Jurado: Dr. René Santaolaya Salgado – Presidente M.C. Reynaldo Alanis Cantú – Secretario
M.C. Felipe de Jesús Alaníz Quezada – Vocal Dr. Moisés González García – Vocal Suplente
Cuernavaca, Morelos, México. 10 de Diciembre de 2007
i
Dedicatoria
A Dios por todo lo que me da (familia, amigos, amor, bienestar, salud, alegrías, tristezas).
A mis padres: Julián Tomás López Mendivil y Dionicia López Leyva por darme la vida, ser mis amigos, por estar siempre unidos en cualquier circunstancia, por su infinito amor,
esfuerzo y apoyo incondicional.
A mis hermanos Juan Carlos López López y Julián Rafael López López por sus consejos, cariño, apoyo y amistad.
A mi amor Erwin por su apoyo, comprensión, amor y por que siempre esta a mi lado.
A toda mi familia (abuelos, tíos, primos, sobrinos, suegros y mis curruñis) por ser parte de mi vida.
ii
Agradecimientos
A CONACYT por su apoyo económico que ayudó a alcanzar mi meta.
A CENIDET por darme la oportunidad de seguir preparándome en mis estudios.
A mis directores de tesis: Dr. Moisés González García y Dr. Máximo López Sánchez por su
guía, formación y consejos.
A mis revisores Dr. Rene Santaolaya Salgado, M.C. Reynaldo Alanís Cantú y M.C. Felipe de Jesús Alaniz Quezada por sus comentarios y revisiones para que se logrará la presente tesis.
A todos los maestros del área de Ingeniería de Software: Moisés, Máximo, Olivia, Rene y
Hugo por sus consejos.
Al Dr. Andrés Rodríguez, Dulce y Devora del IIE, por su apoyo en la primer etapa de esta investigación.
Al jefe del centro de información Ing. Mario A. Moreno Amado por su colaboración para la
realización de la demostración.
A todos los compañeros de la generación 2005-2007 por su amistad y todas las vivencias compartidas juntos. Por laboratorio, Ingeniería de Software: Cindy, Jazmín, Elvia, Luz, Silvana, Erick y Lalo; Inteligencia Artificial: Erwin, Héctor, Ricardo, Gerardo, Arturo,
Rubén, Chan, Zucy y Perla; Sistemas Distribuidos: Lirio, Adriana, Pedro, Chuy y Daniel.
A mis hermanas Cindy, Elvia y a mis hermanos Erick, Pedro y a la ñoñita por compartir momentos especiales juntos.
A todas las integrantes del equipo de basketball femenil de CENIDET por compartir tantos
partidos juntas y entrenamientos.
A todas las personas que conocí durante mi estancia en CENIDET y en Morelos en general.
iii
Resumen
Este trabajo de investigación propone una solución al problema de la transformación entre modelos en el proceso de desarrollo de software realizado bajo el enfoque MDA1. Esta solución será implementada dentro de un ambiente conocido como AGDE2. MDA dirige el proceso de desarrollo de software a través de las transformaciones entre modelos cada vez más detallados, hasta la entrega de un producto ejecutable. Debido a este hecho, existe la necesidad de identificar la estructura de los modelos implicados y sus características, así como técnicas y métodos que permitan el desarrollo de transformaciones y su mantenimiento.
Cuando se desarrolla un software específico usando el enfoque MDA, es difícil determinar cuando un modelo adquiere nuevas características y se convierte en un nuevo modelo de diverso tipo con diversas características, por ejemplo: un modelo del CIM3 se convierte en un modelo del PIM4, un modelo del PIM se convierte en un modelo del PSM5 o un modelo del PSM se convierte en código, ya que las transformaciones se realizan de manera progresiva. Actualmente, la información relacionada con MDA tiene diversas representaciones, no tiene bien definido cómo se deben de llevar a cabo las transformaciones ni qué información debe contener cada uno de sus modelos. Debido a esta situación, la meta principal de este trabajo es la delimitación de las fronteras de los modelos MDA para utilizarla en el diseño e implementación del ambiente AGDE, para soportar el desarrollo de software dirigido por modelos.
Para cumplir tal meta se realizó una serie de análisis para definir cada uno de los modelos (CIM, PIM, PSM e IM), así como la caracterización de sus fronteras. El resultado de estos análisis se aplicó al desarrollo de software requerido para solucionar el problema clásico de biblioteca, con lo que se demostró que es factible utilizar los resultados de esta investigación para orientar la construcción de los modelos y su colocación dentro de las fronteras caracterizadas, para implementar el producto de software ejecutable.
1 MDA (Model Driven Architecture) 2 AGDE (Architectural and Group Development-Environment) 3 CIM (Computation Independent Model) 4 PIM (Platform Independent Model) 5 PSM (Platform Specific Model)
iv
Abstract
This research work proposes a solution to the transformation problem among models in the software development process performed under the MDA6 approach. This solution will be implemented within an environment known as AGDE7. MDA drives a software development process trough the transformation among models more and more detailed every time, up to delivering an executable product. Due to this fact, there exists a need to identify the structure of the involved models and their characteristics, as well as the techniques that allow the development of transformations and their maintenance.
When a specific software is developed using the MDA approach, it is difficult to determine when a model acquires new characteristics and becomes a new model of different type with different characteristics. For example: a model from CIM8 becomes a model of PIM9, a model from PIM becomes a model of PSM10, or a model from PSM becomes a code, since transformations occur in a progressive way. Currently, the information related with MDA has diverse representations, but it does not define how the transformations should be done, or what information each model must contain. Due to this situation, the main goal for this work is delimitation of frontiers of MDA models, to use them in the design and implementation of AGDE environment, to support model driven software development.
To fulfill the mentioned goal, several analyses were done to define each one of the models (CIM, PIM, PSM and IM), as well as the characterization of their frontiers. The result of this analysis was applied to the software development required to solve the classical library problem, with the that was demonstrated that is feasible to use the results of this research to guide the construction of the models and their placement within the characterized frontiers, in order to implement the executable software product.
6 MDA (Model Driven Architecture) 7 AGDE (Architectural and Group Development-Environment) 8 CIM (Computation Independent Model) 9 PIM (Platform Independent Model) 10 PSM (Platform Specific Model)
v
Índice Glosario de términos y siglas..................................................................................................... xi Capítulo 1 Introducción .............................................................................................................. 1
1.1 Introducción ...................................................................................................................... 1 Capítulo 2 Marco conceptual ...................................................................................................... 4
2.1 Descripción de los conceptos............................................................................................ 4 Capítulo 3 Antecedentes y Descripción de la Investigación....................................................... 8
3.1 Antecedentes ..................................................................................................................... 8 3.1.1 Método de Desarrollo Arquitectónico en Grupo ....................................................... 8 3.1.2 Tesis de Maestría en Ciencias, relacionadas............................................................ 12
3.2 Estado del arte................................................................................................................. 12 3.2.1. Herramientas MDA................................................................................................. 14 3.2.2. Trabajos relacionados ............................................................................................. 16
3.2.2.1 Trabajos relacionados a la especificación de los modelos MDA ..................... 16 3.2.2.2 Trabajos relacionados a las transformaciones entre fronteras de los modelos MDA ............................................................................................................................. 17 3.2.2.3 Trabajos relacionados tanto a la especificación de modelos como a las transformaciones entre fronteras de los modelos MDA ............................................... 18 3.2.2.4 Comparación entre trabajos .............................................................................. 19
3.3 Descripción de la Investigación ...................................................................................... 20 3.3.1 Problema .................................................................................................................. 20 3.3.2 Idea de solución ....................................................................................................... 21 3.3.3 Objetivos .................................................................................................................. 21 3.3.4 Justificación ............................................................................................................. 21 3.3.5 Alcances y Limites................................................................................................... 22
3.3.5.1 Alcances............................................................................................................ 22 3.3.5.2 Limites .............................................................................................................. 22
Capítulo 4 Análisis del problema.............................................................................................. 24
4.1 Contexto del problema.................................................................................................... 25 4.2 Análisis comparativo de AGD con otros enfoques......................................................... 28 4.3 Análisis de UML (Unified Modeling Language) 2.0...................................................... 32
4.3.1 Análisis de los diagramas de UML 2.0 a seleccionar .............................................. 32 4.3.2 Análisis de los diagramas seleccionados con respecto a los diagramas restantes de UML 2.0............................................................................................................................ 35 4.3.3 Análisis de los elementos de cada uno de los diagramas seleccionados.................. 36
4.4 Análisis de lenguajes de transformación......................................................................... 45 Capítulo 5 Solución propuesta .................................................................................................. 50
5.1 XMI para los diagramas seleccionados de UML............................................................ 51 5.1.1 Análisis de etiquetas XMI para los diagramas de UML 2.0 .................................... 51 5.1.2 Desarrollo de la representación interna (en XMI) ................................................... 53
5.2 Definición de los modelos y las fronteras de MDA en el AGDE................................... 72
vi
5.2.1 Definición del modelo CIM..................................................................................... 75 5.2.1.1 Modelo del negocio........................................................................................... 75
5.2.1.1.1 Modelo de dominio .................................................................................... 76 5.2.1.1.2 Modelo funcional ....................................................................................... 76 5.2.1.1.3 Modelo no funcional .................................................................................. 77
5.2.1.2 Vista del nivel CIM a través de los diagramas y sus transformaciones............ 79 5.2.2 Definición de la frontera CIM-PIM ......................................................................... 81 5.2.3 Definición del modelo PIM ..................................................................................... 82
5.2.3.1 Modelo de análisis ............................................................................................ 83 5.2.3.2 Modelo de diseño.............................................................................................. 83 5.2.3.3 Vista del nivel PIM a través de los diagramas y sus transformaciones ............ 84
5.2.4 Definición de la frontera PIM-PSM......................................................................... 85 5.2.5 Definición del modelo PSM..................................................................................... 86
5.2.5.1 Modelo de diseño.............................................................................................. 87 5.2.5.2 Vista del nivel PSM a través de los diagramas y sus transformaciones ........... 87
5.2.6 Definición de la frontera PSM-IM........................................................................... 88 5.2.7 Definición del modelo IM........................................................................................ 89
5.2.7.1 Vista del nivel IM a través del código generado en base a los diagramas del nivel PSM y sus transformaciones................................................................................ 90
5.3 Caracterización de las fronteras ...................................................................................... 91 Capítulo 6 Demostración .......................................................................................................... 98
6.1 Tesis de la demostración................................................................................................. 99 6.2 Fundamentos o argumentos ............................................................................................ 99 6.3 Procedimiento ................................................................................................................. 99
6.3.1 Explicación de la demostración ............................................................................. 100 6.3.1.1 Nivel general................................................................................................... 100 6.3.1.2 Nivel CIM ....................................................................................................... 101 6.3.1.3 Cruce de la frontera CIM-PIM........................................................................ 106 6.3.1.4 Nivel PIM........................................................................................................ 112 6.3.1.5 Cruce de la frontera PIM-PSM ....................................................................... 122 6.3.1.6 Nivel PSM....................................................................................................... 128 6.3.1.7 Cruce de la frontera PSM-IM ......................................................................... 133 6.3.1.8 Nivel IM.......................................................................................................... 138
6.4 Conclusión .................................................................................................................... 142 Capítulo 7 Conclusiones ......................................................................................................... 143
7.1 Conclusiones ................................................................................................................. 143 7.2 Aportaciones ................................................................................................................. 144 7.3 Trabajos futuros ............................................................................................................ 145
Anexo A ............................................................................................................................. 146 Anexo B ............................................................................................................................. 158 Referencias.............................................................................................................................. 167
vii
Índice de ilustraciones Ilustración 3-1. Ubicación de la tesis dentro de AGD .............................................................. 10 Ilustración 3-2. Diagrama Nassi-Shneiderman del AGDE ....................................................... 11 Ilustración 3-3. Incremento de los niveles de abstracción en el que trabaja el desarrollador. El
proceso de MDD automatiza la abstracción/ refinamiento [IBM05]................................ 13 Ilustración 3-4. Representa todo el esquema de MDA con sus modelos y transformaciones .. 21 Ilustración 4-1. Procedimiento general de la metodología de solución .................................... 25 Ilustración 4-2. Contexto de la investigación en el ambiente AGDE ....................................... 26 Ilustración 4-3. Propuesta para el proceso general de MDA en AGDE ................................... 28 Ilustración 4-4. UML dentro del enfoque MDA en el AGDE .................................................. 34 Ilustración 5-1. Arquitectura de cuatro niveles para metadatos de MOF ................................. 53 Ilustración 5-2. Documento XMI para el diagrama de casos de uso ........................................ 56 Ilustración 5-3. DTD para el documento XMI del diagrama de casos de uso .......................... 57 Ilustración 5-4. Prueba de documento bien formado para el documento XMI del diagrama de
casos de uso....................................................................................................................... 58 Ilustración 5-5. Prueba de documento válido para el documento XMI del diagrama de casos de
uso ..................................................................................................................................... 58 Ilustración 5-6. Documento XMI para el diagrama de clases................................................... 59 Ilustración 5-7. DTD para el documento XMI del diagrama de clases .................................... 61 Ilustración 5-8. Prueba de documento bien formado para el documento XMI del diagrama de
clases ................................................................................................................................. 62 Ilustración 5-9. Prueba de documento válido para el documento XMI del diagrama de clases62 Ilustración 5-10. Documento XMI para el diagrama de secuencia........................................... 64 Ilustración 5-11. DTD para el documento XMI del diagrama de secuencia ............................ 66 Ilustración 5-12. Prueba de documento bien formado para el documento XMI del diagrama de
secuencia ........................................................................................................................... 67 Ilustración 5-13. Prueba de documento válido para el documento XMI del diagrama de
secuencia ........................................................................................................................... 67 Ilustración 5-14. Documento XMI para el diagrama de actividad............................................ 69 Ilustración 5-15. DTD para el documento XMI del diagrama de actividad ............................. 70 Ilustración 5-16. Prueba de documento bien formado para el documento XMI del diagrama de
actividad............................................................................................................................ 72 Ilustración 5-17. Prueba de documento válido para el documento XMI del diagrama de
actividad............................................................................................................................ 72 Ilustración 5-18. Representación visual de la definición de los modelos y de las fronteras de
los modelos MDA hasta el modelo de implementación ................................................... 73 Ilustración 5-19. Representación visual de la definición del modelo CIM............................... 75 Ilustración 5-20. Representación visual del nivel CIM en base a diagramas y sus
transformaciones ............................................................................................................... 79 Ilustración 5-21. Frontera CIM-PIM en base a diagramas y sus transformaciones.................. 81 Ilustración 5-22. Representación visual de la definición del modelo PIM............................... 82 Ilustración 5-23. Representación visual del nivel PIM en base a diagramas y sus
transformaciones ............................................................................................................... 85 Ilustración 5-24. Frontera PIM-PSM en base a diagramas y sus transformaciones ................. 86 Ilustración 5-25. Representación visual de la definición del modelo PSM .............................. 86
viii
Ilustración 5-26. Representación visual del nivel PSM en base a diagramas y sus transformaciones ............................................................................................................... 88
Ilustración 5-27. Frontera PSM-IM en base a diagramas y sus transformaciones.................... 89 Ilustración 5-28. Representación visual de la definición del modelo IM ................................. 89 Ilustración 5-29. Representación visual del nivel IM en base el código generado a través de los
diagramas y sus transformaciones .................................................................................... 91 Ilustración 6-1. Nivel general de la demostración .................................................................. 101 Ilustración 6-2. Diagrama de casos de uso del negocio a nivel CIM...................................... 104 Ilustración 6-3. Sub-diagrama de casos de uso de la Ilustración 6-2...................................... 105 Ilustración 6-4. Documento XMI para el diagrama de casos de uso de la Ilustración 6-3 ..... 105 Ilustración 6-5. Diagrama de casos de uso "Administrar préstamo de acervo" a nivel PIM.. 108 Ilustración 6-6. Sub-sub caso de uso de "Registrar préstamo" del diagrama de la Ilustración
6-5 ................................................................................................................................... 108 Ilustración 6-7. Documento XMI para el diagrama de casos de uso de “Administrar préstamo
de acervo” en la parte de “Registrar préstamo” .............................................................. 109 Ilustración 6-8. Diagrama de secuencia para el caso de uso “CU-4.1 Registrar préstamo” a
nivel PIM ........................................................................................................................ 114 Ilustración 6-9. Documento XMI para el diagrama de secuencia de la Ilustración 6-8.......... 116 Ilustración 6-10. Diagrama de actividad “Registrar” a nivel PIM.......................................... 117 Ilustración 6-11. Documento XMI para el diagrama de actividad de la Ilustración 6-10 ...... 118 Ilustración 6-12. Diagrama de actividad “AceptarRegistro” a nivel PIM .............................. 120 Ilustración 6-13. Documento XMI para el diagrama de actividad de la Ilustración 6-12 ...... 121 Ilustración 6-14. Diagrama de actividad “Registrar” a nivel PSM......................................... 124 Ilustración 6-15. Documento XMI para el diagrama de actividad de la Ilustración 6-14 ..... 125 Ilustración 6-16. Diagrama de actividad “AceptarRegistro” a nivel PSM ............................. 126 Ilustración 6-17. Documento XMI para el diagrama de actividad de la Ilustración 6-16 ...... 127 Ilustración 6-18. Diagrama de Clases nivel PSM ................................................................... 130 Ilustración 6-19. Documento XMI para el diagrama de clases de la Ilustración 6-18............ 131 Ilustración 6-20. Código generado para el método jButtonRegistrar_actionPerformed nivel IM
......................................................................................................................................... 134 Ilustración 6-21. Código generado para el método AceptarRegistro nivel IM....................... 136 Ilustración 6-22. Código de la clase “PrestamoAcervo” a nivel IM....................................... 139 Ilustración 6-23. Pantalla de “Administrar prestamos” en la opción “Registrar”................... 141 Ilustración B-1. Estructura taxonómica de UML 2.0.............................................................. 159
ix
Índice de tablas Tabla 3-1. Comparación de herramientas MDA [AHS06, GAR04, COR06] .......................... 15 Tabla 3-2. Comparativa de trabajos relacionados..................................................................... 19 Tabla 4-1. Conjunto de modelos a nivel CIM del PS con respecto a los enfoques comparados
........................................................................................................................................... 29 Tabla 4-2. Conjunto de modelos a nivel PIM del PS con respecto a los enfoques comparados
........................................................................................................................................... 30 Tabla 4-3. Conjunto de modelos a nivel PSM del PS con respecto a los enfoques comparados
........................................................................................................................................... 30 Tabla 4-4. Conjunto de modelos a nivel IM (Modelo de Implementación) del PS con respecto
a los enfoques comparados ............................................................................................... 31 Tabla 4-5. Selección de los diagramas de UML para MDA..................................................... 33 Tabla 4-6. Número de elementos exclusivos y repetidos de los 13 diagramas UML............... 35 Tabla 4-7. Relaciones entre los elementos del diagrama de Casos de uso ............................... 37 Tabla 4-8. Relaciones entre los elementos del diagrama de Clases.......................................... 37 Tabla 4-9. Relaciones entre los elementos del diagrama de Secuencia.................................... 38 Tabla 4-10. Relaciones entre los elementos del diagrama de Actividad .................................. 41 Tabla 4-11. Comparativa de lenguajes de transformación........................................................ 48 Tabla 5-1. Revisión de XMI ..................................................................................................... 52 Tabla 5-2. Estructura general de XMI para los 4 diagramas .................................................... 53 Tabla 5-3. Correspondencia de los elementos del diagrama de casos de uso con su
representación interna en el documento XMI................................................................... 55 Tabla 5-4. Correspondencia de los elementos del diagrama de clases con su representación
interna en el documento XMI ........................................................................................... 59 Tabla 5-5. Correspondencia de los elementos del diagrama de secuencia con su representación
interna en el documento XMI ........................................................................................... 63 Tabla 5-6. Correspondencia de los elementos del diagrama de actividad con su representación
interna en el documento XMI ........................................................................................... 68 Tabla 5-7. Caracterización de las fronteras CIM-PIM, PIM-PSM y PSM-IM a través del
diagrama de casos de uso.................................................................................................. 93 Tabla 5-8. Caracterización de las fronteras CIM-PIM, PIM-PSM y PSM-IM a través del
diagrama de clases ............................................................................................................ 94 Tabla 5-9. Caracterización de las fronteras CIM-PIM, PIM-PSM y PSM-IM a través del
diagrama de secuencia ...................................................................................................... 95 Tabla 5-10. Caracterización de las fronteras CIM-PIM, PIM-PSM y PSM-IM a través del
diagrama de actividad ....................................................................................................... 96 Tabla 6-1. Objetivos internos y externos de la biblioteca....................................................... 102 Tabla 6-2. Trazabilidad para el diagrama de casos de uso de la Ilustración 6-3 a nivel CIM 106 Tabla 6-3. Trazabilidad para el sub-subcaso de uso “Registrar préstamo” a nivel PIM ........ 112 Tabla 6-4. Trazabilidad para el Diagrama de secuencia del caso de uso “CU-4.1 Registrar
préstamo” nivel PIM....................................................................................................... 116 Tabla 6-5. Trazabilidad para el Diagrama de actividad “Registrar” nivel PIM...................... 119 Tabla 6-6. Trazabilidad para el Diagrama de actividad “AceptarRegistro” nivel PIM .......... 122 Tabla 6-7. Trazabilidad para el Diagrama de actividad “Registrar” a nivel PSM.................. 125 Tabla 6-8. Trazabilidad para el Diagrama de actividad “AceptarRegistro” a nivel PSM ...... 127
x
Tabla 6-9. Trazabilidad para el Diagrama de Clases nivel PSM ............................................ 132 Tabla 6-10. Trazabilidad para el método jButtonRegistrar_actionPerformed nivel IM......... 134 Tabla 6-11. Trazabilidad para el método AceptarRegistro nivel IM...................................... 136 Tabla 6-12. Trazabilidad para el código de clases a nivel IM ................................................ 140 Tabla A-1. AGD en el nivel CIM comparado con CMMI...................................................... 150 Tabla A-2. AGD en el nivel PIM comparado con CMMI ..................................................... 150 Tabla A-3. AGD en el nivel PSM comparado con CMMI .................................................... 151 Tabla A-4. AGD en el modelo de implementación (IM) comparado con CMMI .................. 151 Tabla A-5. AGD en el nivel CIM comparado con RUP ........................................................ 153 Tabla A-6. AGD en el nivel PIM comparado con RUP ........................................................ 154 Tabla A-7. AGD en el nivel PSM comparado con RUP........................................................ 154 Tabla A-8. AGD en el modelo de implementación (IM) comparado con RUP .................... 155 Tabla A-9. AGD en el nivel CIM comparado con IDEF....................................................... 156 Tabla A-10. AGD en el nivel PIM comparado con IDEF ..................................................... 156 Tabla A-11. AGD en el nivel PSM comparado con IDEF .................................................... 157 Tabla A-12. AGD en el modelo de implementación (IM) comparado con IDEF ................. 157 Tabla B-1. Breve descripción de diagramas UML 2.0 [AMB04]........................................... 159 Tabla B-2. Elementos del diagrama de Casos de Uso y su relación con otros diagramas..... 160 Tabla B-3. Elementos del diagrama de Actividad y su relación con otros diagramas............ 161 Tabla B-4. Elementos del diagrama de Maquina de Estado y su relación con otros diagramas
......................................................................................................................................... 161 Tabla B-5. Elementos del diagrama de Cronometraje o Tiempos y su relación con otros
diagramas ........................................................................................................................ 162 Tabla B-6. Elementos del diagrama de Secuencia y su relación con otros diagramas ........... 162 Tabla B-7. Elementos del diagrama de Revisión de la Interacción y su relación con otros
diagramas ........................................................................................................................ 163 Tabla B-8. Elementos del diagrama de Comunicación y su relación con otros diagramas .... 164 Tabla B-9. Elementos del diagrama de Paquetes y su relación con otros diagramas ............. 164 Tabla B-10. Elementos del diagrama de Clases y su relación con otros diagramas ............... 164 Tabla B-11. Elementos del diagrama de Objeto y su relación con otros diagramas .............. 165 Tabla B-12. Elementos del diagrama de Estructura Compuesta y su relación con otros
diagramas ........................................................................................................................ 165 Tabla B-13. Elementos del diagrama de Componentes y su relación con otros diagramas ... 165 Tabla B-14. Elementos del diagrama de Despliegue y su relación con otros diagramas ....... 166
xi
Glosario de términos y siglas MDA (Model Driven Architect):
Es un enfoque dirigido por modelos para el desarrollo de software. XMI (XML Metadata Interchange):
El propósito de XMI es facilitar el intercambio de metadatos, en entornos distribuidos heterogéneos, entre diferentes tipos de herramientas de software y en especial entre herramientas de modelado basadas en UML y repositorios de metadatos basados en la propuesta MOF. Estos estándares de facto son: XML, UML, MOF. XMI permite que los metadatos puedan ser intercambiados como flujos o archivos con un formato estándar basado en XML.
MOF (Meta-Object Facility): MOF es una norma aprobada por el OMG para la definición, representación y gestión de metadatos.
XML (eXtensible Markup Language): Es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). El XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades.
UML (Unified Model Lenguaje): Es el lenguaje de modelado de sistemas de software. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software.
JMI (Java Metadata Interface): JMI define las interfaces estándares de Java a componentes que modelan y permite así el descubrimiento de la plataforma-independiente y el acceso de meta datos. Es el estándar que define como tener acceso a metamodelos basados en MOF y su metadato usando Java.
WSDL (Web Services Description Language): WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo.
J2EE (Java 2 Enterprise Edition): Una plataforma de programación para desarrollar y ejecutar software de aplicaciones en el lenguaje de programación Java con arquitectura de n niveles distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. J2EE es también considerada informalmente como un estándar, debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a J2EE.
Struts: Es una herramienta de soporte para el desarrollo de aplicaciones Web bajo el patrón MVC bajo la plataforma J2EE. Los Struts se desarrollaban como parte del proyecto Jakarta de la Apache Software Foundation, pero actualmente es un proyecto independiente conocido como Apache Struts.
Glosario de términos y siglas
xii
MDR (Netbeans Metadata Repository): MDR se está desarrollando como parte del proyecto de NetBeans. NetBeans puede servir como plataforma para básicamente cualquier clase de uso de Java, pero es específicamente muy útil como marco para las herramientas de desarrollo integradas modulares. Es una implementación extendida de MOF, XMI y los estándares de JMI.
ANT: Es un proyecto de código abierto de la Apache Software Foundation. Es una herramienta hecha en Java, tiene la ventaja de no depender de las órdenes del shell (intérprete de comandos) de cada sistema operativo, sino que se basa en archivos de configuración XML (eXtensible Markup Language) y clases Java para la realización de las distintas tareas, siendo idónea como solución multi-plataforma.
Hybernate: Es la colección de las clases y de las interfaces que se pueden utilizar para comunicarse entre los objetos de Java y la base de datos, el código de JDBC se escribe directamente en las clases de Hybernate y se puede utilizar directamente en código propio.
Velocity (Velocity Template Language): Es un motor de plantilla basado en java. Permite a diseñadores de página Web referirse a métodos definidos en código Java. Velocity separa el código Java de las páginas Web, haciendo el sitio Web más conservable utilizando el modelo MVC.
xDocle: Es un motor para la generación de código abierto. Permite la programación orientada al atributo (Attribute-Oriented Programming) para Java, que significa que se puede agregar más significancia al código agregando metadatos (atributos) a fuentes de Java. Esto se hace en las etiquetas especiales de JavaDoc.
Maven: Es una herramienta de administración y comprensión de proyecto de software. De acuerdo con el concepto de un Modelo de Objeto del Proyecto (POM por sus siglas en inglés), Maven puede administrar la estructura de un proyecto, el informe y la documentación desde una parte de la información central.
1
Capítulo 1
Introducción 1.1 Introducción A través de los años el desarrollo de software ha evolucionado, debido a que cada periodo es caracterizado por el tipo de lenguajes de programación (desde el lenguaje de ensamble pasando por los lenguajes orientados a objetos y de cuarta generación, hasta llegar al desarrollo dirigido por modelos) dominante que se construye en base a las ventajas de los lenguajes del periodo previo. Debido a esta evolución se usa actualmente la ingeniería de modelos, que se considera como un nuevo paso en el camino hacia lenguajes de programación más expresivos y hacia una mayor automatización. Como consecuencia de todo esto, en la ingeniería de software se ha apostado por un Desarrollo Dirigido por Modelos (MDD, Model-Driven Development), donde uno de los enfoques que lo aplica es la Arquitectura Dirigida por Modelos (MDA, Model Driven Architecture).
La utilización de MDA toma cada vez más fuerza en el desarrollo de software y esto se ve reflejado tanto en las herramientas (AndroMDA [AND06], OptimalJ [OPT06], ArcStyler [ARC06],…) y trabajos (MIDAS [CAC03-1], AspectMDA [AMA05], AGD [GON04],…) que han ido apareciendo para su aplicación y/o mejoramiento, debido a los beneficios (productividad, portabilidad, interoperatividad, mantenimiento y documentación) que proporciona (§ 3.2.1 y 3.2.2).
Acorde con la necesidad actual de mejorar el enfoque MDA y ayudar a su mejor interpretación, delimitación y definición tanto de sus modelos (CIM, PIM, PSM, IM), como de sus fronteras (CIM-PIM, PIM-PSM, PSM-IM) y transformaciones entre ellos, se realizó el
Capítulo 1 Introducción
2
presente trabajo de investigación con el propósito de especificar la definición de las fronteras de MDA, para utilizar sus resultados en el diseño e implementación del tratamiento del PS (Products Set, productos del trabajo) dentro del método de Desarrollo Arquitectónico en Grupo (AGD, Architectural and Group Development, ver capítulo 3 y 4 § 3.1.1 y 4.1).
Debido a lo anteriormente mencionado, el objetivo principal de esta investigación es determinar las características distintivas de cada una de las fronteras a través de la definición de cada uno de los modelos, de sus transformaciones y características de las mismas (como trazabilidad y consistencia, ver capítulo 3), utilizando para cada uno de los modelos una representación permanente estándar. Se necesita determinar el nivel de detalle máximo en cada uno de los modelos para que todo lo representado en estos modelos también este presente en la implementación y no existan inconsistencias entre ellos, además para que el resultado del sistema generado sea el esperado.
Por lo tanto, la contribución de esta tesis es proponer un esquema general que se pueda
utilizar para determinar los lenguajes a utilizar en el proceso de desarrollo de MDA, además de la definición de cada uno de sus modelos y la diferenciación de sus fronteras, necesario todo esto para obtener la implementación (código).
Posteriormente, a lo antes mencionado, se procedió a demostrarlos a través del problema clásico de biblioteca. Mediante esta demostración se evaluó la tesis de demostración (§ 6.1) que dice “Con la información definida en los modelos y la caracterización de las fronteras, es posible llegar a una implementación funcional, a través de transformaciones pudiendo distinguir cuando un modelo se convierte en otro de un nivel más detallado”. Los resultados de la demostración fueron la secuencia de modelos necesarios para implementar un sistema para una biblioteca y corroborar la factibilidad de usar la definición de los modelos MDA y sus fronteras para soportar el desarrollo.
Con la definición de los modelos, sus fronteras, caracterización y su demostración se aporta un primer acercamiento a la parte de herramientas de transformación de modelo a modelo y de modelo a código para obtener una implementación en el ambiente AGDE (AGD-Enviroment), que utiliza los conceptos de AGD. Además de aportar al refinamiento y validación del PS dentro del AGD para el enfoque MDA.
El contenido de la tesis se estructura de la siguiente manera:
• Capítulo 2 Marco conceptual, en el se muestran las descripciones de los conceptos
relevantes para comprender mejor el presente documento. Este capítulo se divide en las seccione siguiente: 2.1 Descripción de los conceptos.
• Capítulo 3 Antecedentes y Descripción de la investigación, se da una panorámica de los antecedentes del presente trabajo de investigación, de todos los aspectos que tienen que ver con el planteamiento de esta investigación y de los trabajos que se han desarrollado. Este capítulo se divide en las secciones siguientes: 3.1 Antecedentes, 3.2 Estado del arte, 3.3 Descripción de la investigación.
• Capítulo 4 Análisis del problema, en este capítulo se realizaron una serie de análisis con respecto a AGD, UML y lenguajes de transformación para poder posteriormente,
Capítulo 1 Introducción
3
desarrollar una representación interna en XMI de los diagramas seleccionados y definir los modelos de MDA, sus fronteras y caracterización por medio de los resultados de los análisis realizados. Este capítulo se divide en las secciones siguientes: 4.1 Contexto del problema, 4.2 Análisis comparativo de AGD con otros enfoques, 4.3 Análisis de UML 2.0 y 4.4 Análisis de lenguajes de transformación.
• Capítulo 5 Solución propuesta, en este capítulo se presenta el desarrollo de la representación interna en XMI de los diagramas elegidos, la definición de los modelos (CIM, PIM, PSM, IM) y de las fronteras de MDA representadas por medio de un esquema y su correspondiente caracterización de las fronteras (CIM-PIM, PIM-PSM y PSM-IM) que servirán como fundamento para realizar las transformaciones necesarias y obtener una implementación funcional en el ambiente AGDE. Este capítulo se divide en las secciones siguientes: 5.1 XMI para los diagramas seleccionados de UML, 5.2 Definición de los modelos y fronteras de MDA en el AGDE y 5.3 Caracterización de las fronteras.
• Capítulo 6 Demostración, en este capítulo se muestra la descripción tanto del procedimiento que se siguió para comprobar la tesis de demostración, así como los factores en los cuales se basó y que resultados se obtuvieron. Este capítulo se divide en las secciones siguientes: 6.1 Tesis de demostración, 6.2 Fundamentos o argumentos, 6.3 Procedimiento y 6.4 Conclusiones.
• Capítulo 7 Conclusiones, este capítulo refleja si se cumplió parcial o totalmente los objetivos de la presente investigación, así como las aportaciones que se realizaron, además de mencionar los posibles trabajos futuros a desarrollar. Este capítulo se divide en las secciones siguientes: 7.1 Conclusión, 7.2 Aportaciones y 7.3 Trabajos futuros.
• Finalmente en la sección de anexos se muestran algunos análisis a detalle, como es el análisis comparativo de AGD con otros métodos con respecto a la información contenida en el PS (basado en el enfoque MDA) del AGD y el análisis de UML 2.0 considerando los 13 diagramas pero comparando 9 de ellos contra 4 diagramas (casos de uso, clases, secuencia y actividad) elegidos para trabajarlos en esta investigación, además como para obtener el grado en que los 4 diagramas cubren a los 9.
4
Capítulo 2
Marco conceptual Los conceptos relevantes que se mencionan a continuación son importantes para comprender mejor el presente trabajo de investigación y el orden de presentación elegido es para ayudar a entenderlos. 2.1 Descripción de los conceptos La base de la presente investigación esta situada en el enfoque de Arquitectura Dirigida por Modelos (MDA, Model Driven Architecture) [MIL03], que a continuación se explica.
La MDA es un enfoque para el desarrollo de software, definido por la OMG (Object Management Group). La clave de MDA es la importancia de los modelos en el proceso de desarrollo de software. Dentro de MDA el proceso de desarrollo de software se dirige por la actividad del modelado de los sistemas de software.
Por lo tanto, MDA se dirige por modelos debido a que los usa como entradas y salidas en el proceso de conceptualización, diseño, construcción, despliegue, operación, mantenimiento y modificación. Hasta este momento se ha estado hablando de que MDA se basa fundamentalmente en los modelos, pero ¿Qué es un modelo?
Un modelo [STE02] es una representación abstracta de todos o algunos de los aspectos relevantes de un sistema. A menudo se representa gráficamente mediante uno o más diagramas y se escribe en un lenguaje. Un modelo tiene que tener un significado preciso y bien entendido. Por la naturaleza del proceso de desarrollo que va de lo general a lo detallado, un
Capítulo 2 Marco conceptual
5
modelo implica la consideración de diferentes elementos a distintos niveles de abstracción, donde cada uno de los elementos, a su vez, se organiza mediante nuevos modelos.
MDA separa la especificación funcional de la especificación de implementación y provee
un enfoque abierto independiente del proveedor de tecnología, para enfrentar el reto de cambios en el negocio y en la tecnología. MDA está compuesto por tres modelos: Modelo Independiente de Cómputo (CIM, Computation Independent Model), Modelo Independiente de Plataforma (PIM, Platform Independent Model) y Modelo de Plataforma Especifica (PSM, Platform Specific Model), los cuales representan el proceso de desarrollo con MDA y a continuación se describen:
• Primero, los requerimientos para el sistema se presentan en un modelo CIM, que
describe la situación en la que el sistema se usará. • Posteriormente, este modelo se transforma en un modelo PIM que describe el sistema,
pero no muestra los detalles de su uso, en una plataforma tecnológica particular. • Después de obtener el modelo PIM, se realiza otra transformación hacia un modelo
PSM, el cual contiene el detalle necesario para utilizar la plataforma tecnológica en la que el sistema funcionará.
• Por último, teniendo el modelo PSM se realiza una transformación que resulta en la generación de código para lograr una solución o modelo de implementación (IM).
Una vez especificado el sistema a través de los modelos, desde ellos se obtiene el producto
final en base a la realización sucesiva de transformaciones. Donde una transformación [KLE03] es un conjunto de reglas que describen cómo un modelo en un lenguaje origen puede ser convertido en otro modelo de lenguaje objetivo, donde una regla es una descripción de cómo una o más construcciones en el lenguaje origen pueden convertirse en una o más construcciones del lenguaje objetivo.
Existen, en MDA, dos tipos de transformaciones, las cuales son:
• Transformaciones verticales: son realizadas entre modelos de diferente nivel de
abstracción. Por ejemplo, de los modelos CIM a PIM, de PIM a PSM y de PSM a IM. • Transformaciones horizontales: son realizadas entre modelos del mismo nivel de
abstracción. Por ejemplo, de los modelos CIM a CIM, de PIM a PIM, de PSM a PSM.
Ampliando la descripción de cada uno de los modelos que integran a MDA para su mejor comprensión a continuación se detalla cada uno de ellos.
El primer modelo a definir con el que se inicia el proceso de MDA, es el CIM [MIL03].
Éste describe la situación en la cual el sistema se usará y los requerimientos a modelarse. Tal modelo es con frecuencia llamado modelo de dominio o modelo de negocio. Este modelo es independiente de como se implementa el sistema.
Por otra parte, el CIM es un modelo que muestra el ambiente y funcionamiento de un
sistema, de tal manera que ayuda a la exacta representación de lo que se espera que realice el
Capítulo 2 Marco conceptual
6
sistema. Es útil, no sólo para ayudar al entendimiento de un problema sino también como una fuente de vocabulario compartido para el uso en otros modelos.
Del modelo CIM se pasa al modelo PIM [MIL03] que describe el sistema, pero no muestra
los detalles de su uso en una plataforma o tecnología. La estructura de la información en este modelo podría ser bastante diferente de la estructura de la información desde el punto de vista del modelo CIM.
Para la empresa el modelo PIM podría representar información y datos específicos desde
el punto de vista computacional, el cual será satisfactorio para uno o varios estilos arquitectónicos particulares.
Por último, se pasa al modelo PSM [MIL03] que es un modelo de un subsistema que
incluye información sobre la tecnología que se usa en su realización, sobre una plataforma específica y que hace posible contener los elementos específicos a la plataforma.
El modelo PSM será una implementación si provee toda la información necesaria para construir un sistema y ponerlo en operación. Se puede tratar como un PIM que se usa para el refinamiento a un PSM, que directamente puede implementarse (IM).
Cuando se habló de modelos en los puntos anteriores, se mencionó que un modelo siempre
se escribe en un lenguaje. Ese lenguaje debe ser bien definido, debido a que tiene una gran importancia para MDA, pues el modelo debe tener asociada una sintaxis (forma) y semántica (significado) bien establecidas (definidas). Lo que permite la interpretación automática por medio de herramientas de transformación o compiladores de los modelos, fundamentales en MDA.
Uno de los lenguajes bien definido es el Lenguaje de Modelado Unificado (UML, Unified
Modeling Language), el cual se ha adoptado como el principal lenguaje de modelado en MDA, pero esto no implica que no se pueda usar cualquier otro lenguaje bien definido.
Para aplicar UML en MDA un desarrollador debe ser capaz de usar UML para crear un
modelo del sistema. Debería conocer cómo y dónde aplicar UML para desarrollar modelos que sean precisos y consistentes. Por todo esto a continuación se explica el lenguaje UML.
UML [STE02] “es un lenguaje usado para especificar, visualizar y documentar los
diferentes aspectos relativos a un sistema de software en desarrollo, así como para el modelado de negocios y otros sistemas que no son de software”. Puede utilizarse a lo largo del proceso de desarrollo de software, con cualquier metodología y en cualquier plataforma tecnológica de implementación. El UML está conformado por 13 diagramas, los cuales son:
Diagramas estructurales:
• Diagrama de Clases (Class Diagram) • Diagrama de Objetos (Object Diagram) • Diagrama de Componentes (Component Diagram)
Capítulo 2 Marco conceptual
7
• Diagrama de Distribución (Deployment Diagram) • Diagrama de Paquetes (Package Diagram) • Diagrama de Estructura Compuesta (Composite Structure Diagram)
Diagramas dinámicos o de comportamiento:
• Diagrama de Casos de Uso (Use Case Diagram) • Diagrama de Interacción (Interaction Diagram)
o Diagrama de Secuencia (Sequence Diagram) o Diagrama de Comunicación (Communication Diagram) o Diagrama de Revisión de la Interacción (Interaction Overview
Diagram) o Diagrama de Cronometraje o Tiempos (Timing Diagram)
• Diagrama de Actividad (Activity Diagram) • Diagrama de Máquinas de Estado (State Machine Diagram)
Los diagramas UML requieren intercambiarse entre herramientas de diseño y/o
aplicaciones, por lo tanto necesitan tener una representación estándar para tal intercambio, que contenga la información adecuada a los diagramas. Por esta razón se necesita del estándar XML de Intercambio de Metadatos (XMI, XML Metadata Interchange), que a continuación se explica.
XMI [XMI05] es un estándar de la OMG cuyo propósito principal es permitir el intercambio fácil de meta datos entre diferentes tipos de herramientas de software, en especial herramientas de modelado (basadas en UML) y repositorios de metadatos (basados en MOF) dentro de ambientes heterogéneos distribuidos. XMI está integrado por UML, Lenguaje de Marcas Extensible “XML por sus siglas en inglés” y Facilidad para Meta–Objetos “MOF por sus siglas en inglés”.
XMI es un modelo conducido por el marco de integración XML para la definición, el intercambio, la manipulación y la integración de datos y objetos XML. Los estándares basados en XMI están en uso para integrar herramientas, repositorios, aplicaciones y depósitos de datos.
Para terminar este capítulo cabe mencionar que cada uno de estos conceptos interviene en el desarrollo de la presente investigación de la siguiente manera: la parte central del trabajo es el proceso del enfoque MDA, el cual contiene modelos que pueden ser transformados entre sí, conformados por una serie de diagramas de UML cuya representación interna se realiza mediante XMI. Por lo tanto, los conceptos presentados son importantes y se utilizan en el capítulo siguiente para mostrar la situación actual de MDA.
8
Capítulo 3
Antecedentes y Descripción de la Investigación En este capítulo se muestra una panorámica tanto de los trabajos de antecedentes relacionados en el CENIDET (Centro Nacional de Investigación y Desarrollo Tecnológico) que de alguna manera, han influido en la presente tesis, realizados por otros grupos de investigación, así como las herramientas y trabajos relacionados con el enfoque de esta tesis, que parten de los conceptos presentados en el capítulo anterior, que son la base conceptual del presente trabajo. Se describe además de donde parte la investigación, cuál es su área, contexto y ubicación, qué problema o situación se trata de resolver por medio de qué objetivo se establecen los alcances de la investigación y se mencionan los beneficios que se obtendrán atacando este problema. 3.1 Antecedentes 3.1.1 Método de Desarrollo Arquitectónico en Grupo El antecedente principal de esta investigación reside en el método AGD (Architectural and Group Development), producto de la investigación doctoral del profesor Moisés González García, miembro de la línea de investigación en Ingeniería de Software de CENIDET (Centro Nacional de Investigación y Desarrollo Tecnológico).
Capítulo 3 Antecedentes y Descripción de la Investigación
9
El AGD es un método de desarrollo de software que da más importancia a los productos y que subordina al proceso de software en relación a los resultados que se obtienen. En el AGD se asume que se pueden obtener productos de mejor calidad como resultado de: la importancia dada a los productos y su arquitectura; y la sinergia obtenida al integrar los modos de trabajo en grupo [GON04]. El método AGD está compuesto por: 1.- El Conjunto de Productos (PS, Products Set) que se fundamenta en:
• Modelo de referencia11 de Trabajo Cooperativo: Almacenamiento, Lógica y Recursos (CWSLR por sus siglas en inglés), el cual proporciona una estructura para el dominio de los sistemas de información, con la finalidad de soportar el trabajo cooperativo, representando la división de la funcionalidad y el flujo de datos de los elementos que lo constituyen
• Y un estilo arquitectónico basado en MDA con sus modelos CIM, PIM y PSM, que proporciona la estructura estándar que permitirá sustituir procesos mediante transformaciones de un modelo a otro.
El PS tiene una arquitectura de software explícita, donde todos sus elementos se conocen y
se pueden desarrollar en el orden que se requiera y está conformado como un árbol invertido que abarca los productos de cuatro categorías de procesos: Administración de Procesos, Administración de Proyectos, Ingeniería y Soporte. Enfocándose en el conjunto de productos de ingeniería que incluye los modelos necesarios para la concepción del producto de software y su desarrollo hasta alcanzar la operación del producto ejecutable.
El conjunto de productos de ingeniería abarca los modelos de MDA: CIM, PIM y PSM,
además incluye el IM (Modelo de Implementación) y el OM (Modelo de Operación). Los modelos CIM, PIM, PSM, IM y OM son los elementos del primer nivel (más abstracto) denominado PS1Set, de cuatro niveles. El segundo nivel (más especifico) se denomina PS2Set y está constituido por 20 modelos, el tercer nivel denominado PS3Set consta de 152 modelos y el cuarto nivel lo constituyen los productos del trabajo (modelos específicos), presentando una sugerencia del contenido de los modelos MDA: CIM, PIM y PSM. 2.- El Proceso Dirigido por Modelos (MDP, Model Driven Process): está compuesto de cuatro modos de trabajo en grupo:
• Un trabajo en equipo • Y tres modos de trabajo en grupo complementarios (de colaboración, de cooperación y
de control)
El MDP es un proceso generalizado de la iteración de los cuatro modos de trabajo, es sistemático e iterativo y está organizado en sub-procesos de forma que facilite el trabajo en equipo.
Algunos de los conceptos importantes que maneja el AGD son:
11 Modelo de referencia es una estructura que soporte el funcionamiento y el flujo de datos para el tipo de aplicación a desarrollar.
Capítulo 3 Antecedentes y Descripción de la Investigación
10
• El Ciclo de Vida de un Producto: es el período de tiempo que comienza cuando un
producto de software es concebido y se termina cuando el software ya no está disponible para su uso.
• Rol: es el papel que desempeña una persona o un grupo de personas en cualquier actividad del desarrollo del sistema.
• Iteración: el proceso de realizar una secuencia de pasos repetidamente. • Sub-proceso: es parte de un proceso, que sigue un conjunto de actividades o
procedimientos que están enlazadas para realizar una tarea dentro del desarrollo de software.
En la Ilustración 3-1 se muestra la ubicación del presente trabajo de investigación, el cual esta enmarcado con puntos y líneas en el área del PS del AGD.
AGDPS (Conjunto de Productos)
MDP (Proceso Dirigido por Modelos) Modos de trabajo en grupo: en equipo, colaborativo, cooperativo y control
CIM
PIM
Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
Class1
Class1
Class2
Class3
Class1
Class2
Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
Class1
Class1
Class2
Class3
Class1
Class2 Class1
Class1
Class2
Class3
Class1
Class2
PSMClass1
Class1
Class2
Class3
Class1
Class2 Class1
Class1
Class2
Class3
Class1
Class2Class 1
Class1
Class2
Class3
Class1
Class2
…
…
…
Implementación
Problema
Sistema
……
CIM
PIM
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2 Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
PClass1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2 Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2Class 1Class 1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
…
…
…
Implementación
Problema
Sistema
……
AGDPS (Conjunto de Productos)
MDP (Proceso Dirigido por Modelos) Modos de trabajo en grupo: en equipo, colaborativo, cooperativo y control
CIM
PIM
Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
Class1
Class1
Class2
Class3
Class1
Class2
Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
Class1
Class1
Class2
Class3
Class1
Class2 Class1
Class1
Class2
Class3
Class1
Class2
PSMClass1
Class1
Class2
Class3
Class1
Class2 Class1
Class1
Class2
Class3
Class1
Class2Class 1
Class1
Class2
Class3
Class1
Class2
…
…
…
Implementación
Problema
Sistema
……
CIM
PIM
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2 Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
PClass1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2 Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2Class 1Class 1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
…
…
…
Implementación
Problema
Sistema
……
CIM
PIM
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2 Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
PSMClass1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2 Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2Class 1Class 1Class 1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
…
…
…
Implementación
Problema
Sistema
……
CIM
PIM
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Class1Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
Class1
Class2
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2
UseCase3«uses»
Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2Actor1
UseCase1
UseCase2
Class1Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
Class1
Class2 Class1Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
Class1
Class2
PClass1Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
Class1
Class2 Class1Class1Class1Class1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
Class1
Class2Class 1Class 1Class 1Class 1
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class3
Class1
Class2
Class1
Class2
Class1
Class2
Class1
Class2
…
…
…
Implementación
Problema
Sistema
……
Ilustración 3-1. Ubicación de la tesis dentro de AGD
A partir del método AGD surgió la propuesta de desarrollar un ambiente de herramientas
para el soporte del desarrollo de software dirigido por modelos denominado AGDE (Ambiente AGD).
El AGDE retoma el método AGD para identificar factores que se pueden configurar en el proceso y los elementos presentes en la transformación entre modelos, en la Ilustración 3-2 se muestra la estructura general del AGDE.
Capítulo 3 Antecedentes y Descripción de la Investigación
11
Herramienta de transformación de modelo a código
Editor de código
CodificaciónManual Automática
Herramienta de transformación de modelo a modelo
Modelo PSM suficiente
Validación del modelo
Editor de modelos
Modelo y código sin defectos
Herramienta de transformación decódigo a modelo
Modelado Manual Automático
Compilación y depuración
Integración y complementación del producto de software
Sistema de historial de proyectos de software
IngenieríaDirecta Inversa
Sistema de Soporte para el Proceso de Software en equipo(SiSoProS)
Herramienta de adecuación del desarrollo
Herramienta de transformación de modelo a código
Editor de código
CodificaciónManual Automática
Herramienta de transformación de modelo a modelo
Modelo PSM suficiente
Validación del modelo
Editor de modelos
Modelo y código sin defectos
Herramienta de transformación decódigo a modelo
Modelado Manual Automático
Compilación y depuración
Integración y complementación del producto de software
Sistema de historial de proyectos de software
IngenieríaDirecta Inversa
Sistema de Soporte para el Proceso de Software en equipo(SiSoProS)
Herramienta de adecuación del desarrollo
Ilustración 3-2. Diagrama Nassi-Shneiderman del AGDE
Los componentes del AGDE son los siguientes:
• Herramienta de adecuación del desarrollo. Ayuda en la toma de decisión para elegir el
proceso adecuado para resolver problemas específicos de software, mediante un procedimiento que permita configurar el proceso de software a las circunstancias que influyan en el desarrollo de un proyecto.
• Sistema de Soporte para el Proceso de Software en equipo (SiSoProS). Es una herramienta que permite el registro y monitoreo del proceso, así como el desarrollo de software en equipo para la mejora continua del proceso y del producto.
• Editor de modelos. Se utiliza para crear y/o modificar los modelos (CIM, PIM, PSM) realizados durante el proceso de desarrollo de un software.
• Herramienta de transformación de modelo a modelo. Esta herramienta permite obtener un modelo destino a partir de un modelo origen, el cual es la entrada para la transformación. La transformación se puede dar entre distintos niveles de abstracción (CIM a PIM, PIM a PSM) o igual nivel de abstracción (CIM a CIM, PIM a PIM, PSM a PSM).
• Validación del modelo. Los modelos usados para la generación de otros modelos deben estar extremadamente bien definidos. Por medio de las validaciones se pueden verificar los modelos contra un conjunto de reglas (predefinido o definido por el usuario) para asegurar que se puedan utilizar en una transformación.
• Editor de código. Herramienta diseñada para crear o editar código de un programa. Este componente soporta al humano para generar las líneas de código nuevas y cambiadas, así como para eliminar líneas del código fuente, pertenecientes al modelo IM. Esta
Capítulo 3 Antecedentes y Descripción de la Investigación
12
herramienta considera los aspectos del lenguaje y plataforma, es decir, los aspectos de implementación para obtener el código.
• Herramienta de transformación de modelo a código. Esta herramienta tiene como entrada un modelo PSM y como salida se obtiene el código (IM) que representa a dicho modelo por medio de la transformación de PSM a IM.
• Compilación y depuración. La compilación es el proceso que traduce programas en código fuente a programas en código objeto. La depuración permite detectar errores en el programa y de esta manera proceder a modificar el código.
• Integración y complementación del producto de software. En este componente se procede a unir los elementos de la estructura del sistema.
• Herramienta de transformación de código a modelo. Parte del código (IM) para obtener el modelo PSM equivalente, aplicándole una transformación de IM a PSM.
• Sistema de historial de proyectos de software. Sistema que tiene la finalidad de capturar la información histórica del desarrollo de proyectos de software y almacenarla en una base de datos para su posterior análisis y comparación.
Con el propósito de iniciar el desarrollo del ambiente AGDE, este trabajo de investigación
aporta un primer acercamiento a las bases requeridas en el área de desarrollo dirigido por modelos, esencialmente en las herramientas de transformación y los modelos presentes en el PS del AGD (CIM, PIM, PSM e IM), los cuales se basan en el enfoque MDA. 3.1.2 Tesis de Maestría en Ciencias, relacionadas Dos tesis de maestría realizadas en el área de ingeniería de software de CENIDET relacionadas con esta investigación, son: “Modelado visual orientado a objetos” [PAR00] y “Sistema para el diseño detallado de métodos de clases con UML” [ROM03], que ayudaron a la presente investigación a determinar qué información utilizar dentro de los elementos de los diagramas de actividad y clases de los modelos PIM y PSM para llegar a generar código. La primera tesis genera código en C++ que corresponda tanto al diagrama de clases como al diseño detallado de los métodos de las clases y, la segunda tesis trata sobre el diseño detallado de los métodos de las clases por medio de diagramas de actividad para posteriormente generar el código correspondiente. 3.2 Estado del arte [MDA03, SEL06, LAR06] El uso de modelos en disciplinas tradicionales de la ingeniería tiene una historia amplia y acertada. A través de los años se ha mejorado el uso de modelos para obtener representaciones abstractas que ayuden a comprender un determinado problema. Se fue desarrollando un enfoque de Desarrollo Dirigido por Modelos (MDD, Model-Driven Development), el cual representa un paso adelante de la Ingeniería de Software (IS), en la que la mayoría de las metodologías utilizan modelos como herramienta principal. La mayoría de los términos utilizados en MDD no son nuevos, pero ahora se usan con un enfoque diferente.
En la Ilustración 3-3 se muestra una gráfica del incremento de los niveles de abstracción en el que trabaja el desarrollador partiendo de un nivel bajo (con mucho detalle) hasta un nivel alto (a menor detalle). En el eje vertical se muestran los niveles de abstracción desde el
Capítulo 3 Antecedentes y Descripción de la Investigación
13
lenguaje de ensamble (manejo simbólico de operaciones y operándoos), pasando por el pseudocódigo, después por los lenguajes de tercera generación “3GL” (que agrupa varias instrucciones del lenguaje de ensamble, en una instrucción, ejemplos de 3GL son C, Cobol, Foltran,..) y posteriormente por el modelado visual hasta llegar al Desarrollo Dirigido por Modelos. El eje horizontal representa el tiempo, que en combinación con el nivel de abstracción, muestra cómo han evolucionado estos niveles de abstracción a través del tiempo.
Ilustración 3-3. Incremento de los niveles de abstracción en el que trabaja el desarrollador. El proceso de MDD
automatiza la abstracción/ refinamiento [IBM05]
Existen varios enfoques que aplican el MDD de diferente manera tales como: MDA y
MIC (Model-Integrated Computing) entre otros. El enfoque utilizado en esta investigación es MDA, considerando principalmente sus modelos y fronteras.
MDA es una iniciativa de la Object Management Group (OMG), que representa un nuevo paradigma de desarrollo de software en el que los modelos guían todo el proceso de desarrollo, apegándose al MDD y se basa en estándares de la industria como: UML, XMI, MOF (MetaObject Facility) y CWM (Common Warehouse Metamodel).
La idea clave de MDA es que si el desarrollo está guiado por modelos de software se obtendrán beneficios importantes en aspectos fundamentales como son: la productividad, portabilidad, interoperabilidad y mantenimiento a través de sus modelos (CIM, PIM, PSM).
A medida que ha evolucionado el enfoque MDA, a través de los años han surgido tanto
herramientas como trabajos relacionados que aplican o dan soporte a este enfoque. A continuación se hace una breve descripción de las herramientas y trabajos relacionados de acuerdo a la definición de los modelos MDA y sus transformaciones con el propósito de identificar el avance y áreas de mejora y comparar estos trabajos con respecto a esta tesis.
Capítulo 3 Antecedentes y Descripción de la Investigación
14
3.2.1. Herramientas MDA Debido al auge de MDA se han desarrollado herramientas tanto open source como comerciales que dan soporte parcial o total al enfoque. En [DSDM06] y [OMG06] se muestran dichas herramientas. El soporte para MDA puede darse en diversas formas, como son: en la generación de código a partir de modelos y en las transformaciones de modelo a modelo, donde ambas formas pueden ser implementadas por distintas herramientas: herramientas de transformación de PIM a PSM, PSM a código, PIM a código, ajustables y de definición de transformaciones. Las herramientas analizadas que se destacan debido a su madurez, uso y mayor soporte al enfoque son: ArcStyler, OptimalJ, AndroMDA, Codagen Architect y Together Architect. Los tipos de herramientas presentadas son de transformaciones de modelo a modelo (PIM a PSM) y de modelo a código (PIM a código y PSM a código).
El estudio de estas herramientas permite conocer las características de una herramienta MDA, sus limitaciones actuales y su aplicabilidad, mostrando un panorama de lo que falta mejorar e implementar en ellas respecto a las transformaciones, definiciones de sus modelos, forma de construcción y tecnologías (Ej. UML, XMI, MOF,…) que utilizan.
En la Tabla 3-1 se ilustra la comparativa entre las herramientas donde se presentan las características a evaluar (renglones) y los nombres de las herramientas (columnas). La intersección de un renglón con una columna es representada con el símbolo “√” ó “*”. A continuación se describen los símbolos y renglones de la Tabla 3-1.
Símbolos: • El símbolo “√” significa que es verdadera la condición. • El símbolo “ “ indica que es falsa la condición. • El “*” significa que cumple indirectamente la característica. Es decir, existen
mecanismos que aparentemente lo realizan.
Renglones: • Entrada. Tipo de entrada que admite para desarrollar la aplicación. • Salida. Tipo de lenguaje o plataforma en la cual genera el código. • Estándares. Estándares en que se basa la herramienta. • Soporte de CIM. Creación de modelos independientes de cómputo. • Soporte PIM. Creación de modelos independientes de plataforma. • Soporte PSM. Creación de modelos de plataforma específica. • CIM a PIM. Soporte a transformaciones del modelo independiente de cómputo al
modelo independiente de plataforma. • PIM a PSM. Soporte a transformaciones del modelo independiente de plataforma al
modelo de plataforma específico. • PSM a IM. Soporte a transformaciones del modelo de plataforma específica al modelo
de implementación (Generación de código). • Consistencia. Es importante para mantener la información adicional que se requiere
para transformar un modelo en otro, de manera que pueda reutilizarse cuando se requiera una modificación o actualización del modelo fuente para volver a realizar su transformación al modelo objetivo.
Capítulo 3 Antecedentes y Descripción de la Investigación
15
• Trazabilidad. Implica conocer el elemento origen a partir del cual se ha generado cualquier elemento del modelo destino.
Tabla 3-1. Comparación de herramientas MDA [AHS06, GAR04, COR06]
H
erra
mie
ntas
A
rcSt
yler
[A
RC
06]
O
ptim
alJ
[OPT
06]
A
ndro
MD
A
[AN
D06
, MIC
06]
C
odag
en
Arc
hite
ct
To
geth
er
Arc
hite
ct
Entrada
UML
XMI v1.1 XMI v1.1
XMI v1.1, MDD de Racional,
Visio, together.
XMI
Lenguaje de
salida
Todos
En J2EE Todos
Java,C#,C++,
Visual Basic.
Java,C#,C++,Corba,
Visual Basic
6,Visual Basic .Net
Estándares
XMI, UML, MOF, JMI
XMI, UML, MOF, XML,
WSDL, J2EE
Struts, Netbeans MDR, ant, Hybernate, Velocity, xDoclet y Maven.
Struct
XMI
Soporte CIM * Soporte PIM √ √ √ √ * Soporte PSM * √ √ * √ CIM a PIM * PIM a PSM √ √
PIM a Código √ √ PSM a Código √ √ √
Consistencia √ √ * √ * Trazabilidad √ √ * * *
Los diagramas UML que soportan las herramientas es importante conocerlos, para
determinar los diagramas más utilizados en el desarrollo de aplicaciones a través del enfoque MDA. Los diagramas de UML que soportan las herramientas analizadas son: casos de uso, clases, secuencia, comunicación, actividad, máquina de estado, componente, objeto, tiempo, revisión de la interacción, estructura, así como el diagrama de distribución. La herramienta OptimalJ utiliza todos excepto los diagramas de tiempo, revisión de la interacción y estructura. Arcstyler no utiliza el diagrama de objeto, tiempo, revisión de la interacción y estructura. Together Architect no utiliza los diagramas de máquina de estados, objeto, tiempo, estructura. Codagen Architect y AndroMDA utilizan los diagramas de clases, casos de uso y maquina de estado. Además AndroMDA usa el diagrama de secuencia y Codagen Architect el diagrama de actividad. Los resultados del análisis de la Tabla 3-1, que se resaltan son:
• Los diagramas que utilizan entre el 80% y el 100% de las herramientas son: Casos de
uso, Clases, Secuencia, Actividad y Maquinas de estado, mientras que los diagramas usados por el 60% de las herramientas son: Comunicación, Componente y distribución.
Capítulo 3 Antecedentes y Descripción de la Investigación
16
• La mayoría de las herramientas no implementan en su totalidad la especificación completa de MDA, pueden realizar las transformaciones entre los modelos de PIM a PSM, de PSM a Código, pero no de CIM a PIM o simplemente realizan las transformaciones directas de PIM a código (por ejemplo ArcStyler, Codagen Architect).
• Ninguna de las herramientas tiene soporte a la definición de todos los modelos de MDA, solamente soportan a PIM y PSM, y Together Architect solamente considera al CIM indirectamente.
• El atributo de consistencia, a pesar de ser un punto relevante para el enfoque MDA con respecto a las transformaciones, lo cumplen solamente: ArcStyler, OptimalJ y Codagen Architect, las demás herramientas tienen un soporte ligero a esta característica.
• El atributo de trazabilidad, aunque es relevante para las transformaciones, sólo lo consideran OptimalJ y ArcStyler. Tratarlo es importante para la búsqueda y corrección de errores.
• Debido a que la base del estándar MDA son UML, MOF y XMI, es importante que las herramientas consideren estos estándares para encontrar uniformidad en la interpretación del enfoque MDA. Las herramientas analizadas que consideran estos estándares son ArcStyler y OptimalJ.
3.2.2. Trabajos relacionados Con el objetivo de revisar el avance y áreas de mejora conque se cuenta en la actualidad en los diversos trabajos entorno al enfoque MDA, considerando la delimitación y definición de cada uno de sus niveles (CIM, PIM, PSM), fronteras (CIM-PIM, PIM-PSM y PSM-IM) y transformaciones, es necesario estudiar los trabajos relacionados.
Se buscaron trabajos que cumplieran con algunas o todas las características siguientes: por una parte trabajos que se enfocarán en la especificación de uno o más de los niveles de MDA y/o que se enfocarán en las transformaciones entre dichos niveles. Además se buscaban características como la utilización de UML en éste proceso. Estas características fueron las que influyeron para seleccionar los trabajos relacionados ya que son las más importantes en la presente investigación. Además, en estos trabajos se consideran las características de consistencia y trazabilidad. Todas las características mencionadas se detallan posteriormente (§ 3.2.2.4) y a continuación se describen brevemente los trabajos de acuerdo al enfoque que presentan. 3.2.2.1 Trabajos relacionados a la especificación de los modelos MDA Estos trabajos sólo presentan la especificación de uno o varios de los modelos CIM, PIM y PSM de MDA, es decir, mencionan la información que deberían contener los modelos. A continuación se mencionan los trabajos.
• Primeramente en el trabajo de “PIM Definition and Description” [EXE04] se presenta un enfoque de Ingeniería Dirigida por Modelos (MDE por sus siglas en inglés), que utiliza la visión MDA. El MDE toma en consideración dos aspectos importantes de un sistema: la separación de aspectos funcionales (requerimientos) de los no funcionales (calidad) y los aspectos de plataforma independiente de los de plataforma específica.
Capítulo 3 Antecedentes y Descripción de la Investigación
17
Se definen las partes que conforman a un PIM como: Contexto (el alcance del sistema a ser desarrollado); Requerimientos; Análisis (especifica la vista interna del sistema); y Diseño del componente (solución independiente de plataforma expresada en términos de componentes de software).
• Y en el trabajo de “Una Propuesta de Proceso Explícito de V&V en el Marco de MDA” [LUC05] se presenta un proceso V&V (Validación & Verificación) genérico para ser aplicado en el ámbito de metodologías basadas en MDA o MDD, donde el proceso se usa para detectar errores e inconsistencias en las etapas tempranas del desarrollo, evitando así la propagación de esos errores a las etapas posteriores, ya que un defecto en el PIM se transmite a uno o más defectos en el PSM hasta llegar a defectos en el código. Además el proceso sugerido sirve para identificar funciones importantes que deberían cumplir las herramientas de soporte de MDA respecto a realizar modelos correctos por medio de la verificación y validación. Para pasar al modelado del PSM el proceso de verificación y validación debe realizarse tanto para el análisis de requisitos (no se especifica en que modelo debería estar ubicado) como para el modelado del PIM.
3.2.2.2 Trabajos relacionados a las transformaciones entre fronteras de los modelos MDA A continuación se mencionan los trabajos que sólo presentan transformaciones entre las fronteras de los modelos MDA, es decir, consideran transformaciones entre distintos niveles de abstracción como son: de CIM a PIM, de PIM a PSM y de PSM a IM.
• En el trabajo de “Reflective Model Driven Engineering” [BEZ03] se propone aplicar el enfoque MDA a si mismo, con las nociones de PIT (Transformaciones Independientes de Plataforma) y PST (Transformaciones de Plataforma Especifica) que dan a MDA dos pasos nuevos en el ciclo de vida de transformaciones de modelos, el primero expresa las transformaciones de modelo de una manera independiente del instrumento (herramienta) y el segundo marca está expresión independiente del instrumento real. En éste artículo, las plataformas se entienden como instrumentos que permiten la especificación, diseño y ejecución de transformaciones. Con el objetivo de transformar de PIM a PSM se utilizan PIT y PST. Se basa en el enfoque orientado a objetos y toma a UML como un metamodelo para definir lenguajes de transformación de tipo PIT y PST.
• El trabajo de “AspectMDA: Hacia un desarrollo incremental consistente integrando MDA y Orientado a Aspectos” [AMA05] se basa en la idea de especificar diferentes modelos que corresponden con distintos aspectos del sistema (como seguridad, restricciones de tiempo real), éste integra a MDA, DSOA12 (Desarrollo de Software Orientado a Aspectos) y xlinkit13 de una forma adecuada y beneficiosa para el MDD. Los objetivos de este artículo son: modelar esos aspectos (artefactos o propiedades de un sistema) por cada equipo de trabajo desde el CIM hasta el PSM con el mínimo de comunicación; verificar la consistencia; mejorar la trazabilidad entre los diferentes niveles de abstracción; y controlar el impacto al cambio. De éste modo, los niveles de
12 Modela los componentes y aspectos como dos entidades separadas donde los aspectos se mezclan o componen de forma automática con el comportamiento funcional del sistema. 13 Es una propuesta para administrar la consistencia de documentos XML heterogéneos distribuidos por la red que son centrales para el desarrollo de sistemas de software.
Capítulo 3 Antecedentes y Descripción de la Investigación
18
MDA se especifican en diferentes facetas del sistema que modela los aspectos y los mantienen separados durante todo el marco (MDA).
• Y en el trabajo de “Transformation from CIM to PIM: A Feature-Oriented Component-Based Approach” [ZHA05] se presenta un enfoque de transformaciones de CIM a PIM, considerando al CIM como un modelo de características y al PIM como la arquitectura de software (componentes). Se resuelven parcialmente 2 problemas con respecto a la transformación de CIM a PIM: el seguimiento de CIM a PIM (manera en que los elementos en el CIM pueden ser mapeados a elementos en el modelo PIM) y la construcción de PIM basado en CIM (cómo los elementos en el modelo destino del PIM son formados en la transformación, Ej. se usan responsabilidades como conector entre los requerimientos en el CIM y los elementos de diseño en el PIM).
3.2.2.3 Trabajos relacionados tanto a la especificación de modelos como a las transformaciones entre fronteras de los modelos MDA En éste punto se presentan trabajos que contemplan tanto la especificación de los modelos como las transformaciones entre los modelos, es decir, mencionan como debe ser la información contenida en un determinado modelo y como transformarlo a otro modelo. A continuación se describen brevemente cada uno.
• Tanto en el trabajo de "PIM to PSM mapping techniques" [MASTER-03-1] como en el trabajo de "PSMs Concepts and Techniques” [MASTER-03-2] son proyectos de MASTER (Model-driven Architecture inSTrumentation, Enhancement and Refinement) que es el nombre de un proyecto cuyo objetivo es realizar una revisión de los conceptos de MDA. En [MASTER-03-1] se mencionan las características que debe tener un modelo de PSM para ser construido de acuerdo al perfil de la plataforma, librerías, conjunto de reglas, patrones y metamodelos. El trabajo de [MASTER-03-2] se centra en las transformaciones de PIM a PSM que deben considerar las características de trazabilidad, bidireccionalidad, consistencia y simplicidad (para facilitar las pruebas o verificación en la transformación). Utilizan separación de aspectos para el mapeo de PIM a PSM, refiriéndose a que el PSM aborda tanto cuestiones tecnológicas como de negocios, por lo que se deben separar, para que la parte del negocio no se disperse en la tecnología, sino que el modelo PIM del negocio se enriquezca de la tecnología.
• En el trabajo de “Separación de Aspectos en MDA: Una aproximación basada en múltiples vistas” [AMA04] se propone integrar técnicas de múltiples perspectivas (se basan en percibir un sistema de software desde diferentes ángulos/posiciones, por ejemplo con perspectiva CIM, PIM o PSM) con MDA y separación de aspectos multidimencionales (dimensión de clases y otra de casos de uso) en cada una de dichas perspectivas. La representación de los modelos que utiliza es con los estereotipos de UML para especificar las vistas de CIM, PIM y PSM. Los objetivos que cubre son: lograr una separación de aspectos (lógica del negocio, requerimientos,…) en el nivel CIM (se utilizan casos de uso) y eliminar los Crosscutting Concerns14 que aparecen dentro de cada punto de vista que modela el sistema.
14 Crosscutting Concerns, es un problema que se presenta cuando aparecen aspectos en el sistema que no pueden ser modelados de forma independiente a otros aspectos.
Capítulo 3 Antecedentes y Descripción de la Investigación
19
3.2.2.4 Comparación entre trabajos Con el fin de bosquejar las características que presentan los trabajos mencionados se realiza una comparativa entre ellos, del presente trabajo de investigación para visualizar la diferencia con respecto a los modelos, transformaciones de los modelos de MDA, consistencia y trazabilidad, en la Tabla 3-2, donde las columnas representan las características a evaluar y los renglones los trabajos identificados mediante sus referencias. A continuación se describen las columnas y símbolos de la Tabla 3-2.
Columnas: • Diagramas UML. Se utilizan diagramas UML para el modelado. • Consistencia. Trata el atributo consistencia, que se refiere a mantener la información
adicional que se requiere para transformar un modelo en otro. De manera que pueda reutilizarse, dicha información, cuando se requiera una modificación o actualización del modelo fuente para volver a realizar su transformación al modelo objetivo.
• Trazabilidad. Trata el atributo trazabilidad, que implica conocer el elemento origen a partir del cual se ha generado cualquier elemento del modelo destino.
• Especificación. Se define la información requerida en los modelos de MDA: CIM, PIM y PSM.
• Transformaciones. Se soportan las transformaciones entre diferentes niveles de abstracción como: CIM a PIM, PIM a PSM y de PSM a IM (Modelo de Implementación).
Símbolos:
• El símbolo “√” significa que es verdadera la condición. • El símbolo “ “ indica que es falsa la condición. • El símbolo “G” indica que especifica de manera general, no detallada, lo que contiene
el modelo (ejemplo, PSM). • El símbolo “I” indica que especifica de manera incipiente lo que contiene el modelo
(ejemplo, CIM).
Tabla 3-2. Comparativa de trabajos relacionados
Especificación Transformación
Artículos
Dia
gram
as
UM
L
Con
sist
enci
a
Traz
abili
dad
CIM
PIM
PSM
CIM
-PIM
PIM
-PSM
PSM
-IM
[AMA04] √ √ I √ [BEZ03] √ √ [LUC05] √ √ I [AMA05] √ √ √ √ √ √ [EXE04] √ G [MASTER-03-1] y [MASTER-03-2] √ G √ [ZHA05] √ √ Tesis √ √ √ √ √ √ √ √ √
En la comparativa de la Tabla 3-2 todos los trabajos utilizan el UML para el modelado,
excepto [ZHA05] que utiliza un modelo de características para representar su proceso de transformación. Las dos características deseables como consistencia y trazabilidad solamente
Capítulo 3 Antecedentes y Descripción de la Investigación
20
las considera [AMA05], el cual realiza los 3 tipos de transformaciones, aunque no define ningún modelo. Ninguno de los trabajos abarca la especificación detallada de algún modelo, y ninguno describe los 3 modelos MDA, ni sus 3 principales transformaciones (CIM a PIM, PIM a PSM y PSM a IM). Lo que significa que hace falta detallar la definición y descripción de los modelos y sus transformaciones, para encontrar una manera homogénea de representarlos, entenderlos y utilizarlos.
Existe un trabajo presentado en “A MDA-Based Approach for Web Information System
Development” [CAC03-1] y en “Hacía un proceso metodológico dirigido por modelos para el desarrollo ágil de sistemas de información Web” [CAC03-2] basado en MDA que trata de la definición de sus modelos y de sus transformaciones, el cual es un marco metodológico basado en modelos para el desarrollo de Sistemas de Información Web (SIW) llamado MIDAS. Este marco combina el enfoque MDA con el desarrollo ágil y define que para cada uno de sus modelos (CIM, PIM, PSM) propone utilizar una notación única para modelar el sistema entero, la cual es representada por UML, pero extendido. Comparando MIDAS con la presente tesis coinciden en que ambas consideran tanto la definición y las fronteras entre los modelos y la utilización de UML para representarlos, así como las transformaciones entre los modelos, la diferencia es que MIDAS esta dirigido a SIW, por lo tanto las definiciones para cada uno de los modelos MDA cambia igual que sus transformaciones, ya que representa las diferentes vistas del SIW en los modelos PIM y PSM por medio del hipertexto (Ej. modelo lógico de presentación), contenido (Ej. modelo lógico de datos) y la funcionalidad (Ej. modelo de composición de servicios), y en el nivel CIM utiliza el modelo de negocio y de dominio (Ej. modelado conceptual del contexto).
3.3 Descripción de la Investigación 3.3.1 Problema Cuando se está desarrollando un software mediante el enfoque MDA (que contiene tres tipos heterogéneos de modelos: CIM, PIM y PSM, con diferente nivel de abstracción), es difícil determinar cuándo un tipo de modelo se convierte en otro, por ejemplo: de CIM a PIM, de PIM a PSM o de PSM a IM, ya que las transformaciones se realizan de manera gradual. Es decir, que para alcanzar ya sea un PIM se tendría que llevar acabo varias transformaciones por ejemplo de CIM a CIM, o bien para un PSM se tendrían que realizar varias transformaciones por ejemplo de PIM a PIM, etc., debido a que cada uno de estos modelos (CIM, PIM, PSM e IM) pueden estar constituidos por varios modelos. En la Ilustración 3-4 se bosqueja como se relaciona cada modelo y como se realizan las transformaciones para entender mejor los puntos mencionados.
Capítulo 3 Antecedentes y Descripción de la Investigación
21
… … …
Dominio Plataforma
Problema SistemaEnfoque dirigido por modelo
CIM PIM PSM Implementación
Requerimientos Análisis Diseño Implementación
Rep
rese
ntac
ión
Rep
rese
ntac
ión
CIM1 CIM2 CIMn PIM1 PIM2 PIMn PSM1 PSM2 PSMn
Transformaciones
verticales
Transformaciones
verticalesTransformaciones
verticales
Transfo
rmac
iones
verti
cales Tran
sform
acion
es
verti
cales
Transfo
rmac
iones
verti
cales
Transformaciones horizontales están representadas por la siguiente línea:… … …
Dominio Plataforma
Problema SistemaEnfoque dirigido por modelo
CIM PIM PSM Implementación
Requerimientos Análisis Diseño Implementación
Rep
rese
ntac
ión
Rep
rese
ntac
ión
CIM1 CIM2 CIMn PIM1 PIM2 PIMn PSM1 PSM2 PSMn
Transformaciones
verticales
Transformaciones
verticalesTransformaciones
verticales
Transfo
rmac
iones
verti
cales Tran
sform
acion
es
verti
cales
Transfo
rmac
iones
verti
cales
Transformaciones horizontales están representadas por la siguiente línea:
Dominio Plataforma
Problema SistemaEnfoque dirigido por modelo
CIM PIM PSM Implementación
Requerimientos Análisis Diseño Implementación
Rep
rese
ntac
ión
Rep
rese
ntac
ión
CIM1 CIM2 CIMn PIM1 PIM2 PIMn PSM1 PSM2 PSMn
Transformaciones
verticales
Transformaciones
verticalesTransformaciones
verticales
Transfo
rmac
iones
verti
cales Tran
sform
acion
es
verti
cales
Transfo
rmac
iones
verti
cales
Dominio Plataforma
Problema SistemaEnfoque dirigido por modelo
CIM PIM PSM Implementación
Requerimientos Análisis Diseño Implementación
Rep
rese
ntac
ión
Rep
rese
ntac
ión
CIM1 CIM2 CIMn PIM1 PIM2 PIMn PSM1 PSM2 PSMn
Transformaciones
verticales
Transformaciones
verticalesTransformaciones
verticales
Transfo
rmac
iones
verti
cales Tran
sform
acion
es
verti
cales
Transfo
rmac
iones
verti
cales
Transformaciones horizontales están representadas por la siguiente línea:
Transformaciones horizontales están representadas por la siguiente línea:
Ilustración 3-4. Representa todo el esquema de MDA con sus modelos y transformaciones
Para pasar de un nivel a otro se necesita tanto de lenguajes para describir transformaciones
entre modelos, cómo de una forma de representación permanente de los modelos, que permitan mantener la consistencia, el orden adecuado y el grado de relación establecido entre ellos.
El problema que se abordó fue el siguiente: Debido a que en el conjunto ordenado de modelos (CIM, PIM, PSM) utilizado para desarrollar productos de software, cada elemento tiene un grado de abstracción diferente, es difícil pasar de un tipo de modelo a otro tipo de modelo de manera consistente, conservando los detalles específicos necesarios para realizar una implementación.
3.3.2 Idea de solución Elaborar un esquema con la información establecida para cada uno de los modelos (CIM, PIM, PSM) y la delimitación mediante fronteras bien definidas, para poder especificar transformaciones, auxiliándose de representaciones permanentes de los modelos, de tal manera que se pueda conservar la consistencia y trazabilidad entre ellos. 3.3.3 Objetivos Definir mediante representaciones permanentes estándar, la arquitectura de modelos de productos de software apegados a MDA, de manera que permita determinar las características distintivas de cada una de las fronteras, de manera que se distingan claramente entre ellas. 3.3.4 Justificación Existen diversas herramientas que realizan transformaciones entre modelos. Pero ninguna de ellas toman en cuenta los mismos conceptos o características, además que no consideran todo
Capítulo 3 Antecedentes y Descripción de la Investigación
22
el proceso completo, es decir, sólo se utilizan los modelos PIM y PSM pero no CIM. El esquema que se propone permitirá que se tenga el nivel de detalle suficiente de los elementos pertenecientes a cada uno de los modelos, con esto se podrán establecer detalladamente los límites entre cada una de las fronteras, y tener una base sólida común sin traslapes entre la forma en que se percibe cada una de ellas. Se asegura además que sean seguibles los elementos del modelo objetivo al modelo fuente, cuidando la bidireccionalidad de las transformaciones y manteniendo la consistencia mediante mecanismos que permitan que información agregada al modelo objetivo persista cuando se regenere el modelo objetivo. Que las transformaciones sean seguibles y bidireccionales es necesario para que los elementos en común entre los modelos se identifiquen y no haya contradicciones. En el desarrollo de software dirigido por modelos las transformaciones de modelos están siendo cada vez más consideradas como activos importantes que deben ser manejados con principios sólidos de ingeniería de software: estas transformaciones deben ser analizadas, diseñadas, implementadas, probadas, mantenidas y estar sujetas a la administración de configuración. Debido a éste hecho, la definición detallada de las fronteras, permitirá identificar técnicas y métodos que permitan el desarrollo de transformaciones y su mantenimiento. 3.3.5 Alcances y Limites 3.3.5.1 Alcances Los alcances del presente trabajo de tesis se basan en la definición de los modelos (CIM, PIM, PSM e IM) y la delimitación de sus fronteras de CIM a PIM, de PIM a PSM de MDA, así como de PSM a IM. Donde se consideró a cuatro (casos de uso, clases, secuencia y actividad) diagramas de UML, así como a los diagramas de entidad y línea de producción del AGD (para modelar el negocio), para determinar la aportación que realizan a cada una de las fronteras. Los cuatro diagramas de UML fueron definidos mediante una representación interna realizada en XMI para describir todas las fronteras.
Para demostrar que la información definida en cada frontera (CIM a PIM, PIM a PSM y PSM a IM) fue la necesaria para transformar de una hacia la otra y poder transformar de un modelo a otro (ejemplo de un modelo CIM a uno PIM), se realizó la validación de las fronteras a través del ejemplo de un problema clásico de arquitectura de software.
3.3.5.2 Limites Las limitaciones que tiene el presente trabajo de tesis residen en el ejemplo de la utilización de los modelos y sus fronteras que se realizó manualmente, así como en las transformaciones entre los modelos de un mismo nivel de abstracción y diferente nivel de abstracción, ya que no se efectuaron por medio de un lenguaje de transformación, ni por una herramienta que diera soporte a dichas modelos, fronteras y transformaciones, debido a que lo alcanzado en este trabajo de investigación son las bases para el proceso propuesto para MDA en el ambiente AGDE.
Capítulo 3 Antecedentes y Descripción de la Investigación
23
En las transformaciones fueron contempladas las caracteristicas de consistencia y trazabilidad de manera explícita, las cuales se describieron en forma textual y no se formalizaron como verificarlas y representarlas.
Todo el contenido de este capítulo permitió presentar el problema establecido (§ 3.3.1) para ver su viabilidad de acuerdo a las características que se están considerando en esta investigación, y se concluye que principalmente hace falta:
• Considerar al nivel CIM dado que tanto en las herramientas como en los
trabajos enfocados a MDA se da más importancia a los niveles PIM y PSM. • Tener una interpretación homogénea con respecto a cada uno de los modelos y
la información contenida en cada uno de ellos, así como de sus fronteras, ya que cada quien lo interpreta de acuerdo a su perspectiva.
• Refinar el conjunto de productos del método AGD, para establecer una base de partida del desarrollo del ambiente AGDE.
Todo lo mencionado aquí es antecedente para, en el capítulo siguiente, describir
detalladamente el análisis del problema.
24
Capítulo 4
Análisis del problema
En este capítulo se procede a realizar varios análisis a la información existente acerca del problema planteado con el propósito de identificar elementos a utilizar en la solución propuesta, que se explica en el capítulo 5. Con un enfoque a la definición de los modelos y las fronteras de MDA, se realizó el siguiente procedimiento: • Análisis comparativo de AGD con otros enfoques (CMMI, RUP e IDEF) para refinar los
modelos contenidos en el Conjunto de Productos (PS) del método AGD, • Partiendo del análisis anterior se realizó un análisis de UML 2.0 para seleccionar un
conjunto mínimo de los diagramas que se van a utilizar dentro de los modelos de MDA en el ambiente AGDE,
• Por último, se realizó un análisis de lenguajes de transformación para encontrar el lenguaje que se adecué tanto a los análisis anteriormente mencionados como a las características del proceso propuesto para MDA en el AGDE.
Todos los análisis que se realizaron se complementan en forma progresiva, ya que el
resultado del primero sirve de punto de partida para el segundo y así sucesivamente, como se muestra en la Ilustración 4-1, en la cual se enmarca con líneas punteadas el área que se presentará en este capítulo.
El procedimiento general para el análisis del problema se orientó hacia el objetivo
establecido para esta investigación, la definición de los modelos, de las fronteras y su caracterización.
Capítulo 4 Análisis del problema
25
Cabe mencionar que en este capítulo sólo se presentarán los análisis realizados de AGD, UML y lenguajes de transformación, por lo cual en el capítulo 5 se presentará la solución partiendo del desarrollo de la representación interna (XMI) a utilizar, así como la definición de los modelos y de las fronteras de MDA en el AGDE. Dado que el AGD y su estructura sirvieron de contexto para esta tesis, es por ello que se inicia con el análisis del mismo.
Análisis comparativo de AGD con otros enfoques (§ 4.2)
Análisis de UML 2.0 (§ 4.3)
Análisis de lenguajes de transformación (§ 4.4)
Definición de los modelos y de las fronteras de MDA en el
AGDE (§ 5.2)
XMI para los diagramas seleccionados de UML (§ 5.1)
Caracterización de las fronteras (§ 5.3)
Análisis comparativo de AGD con otros enfoques (§ 4.2)
Análisis de UML 2.0 (§ 4.3)
Análisis de lenguajes de transformación (§ 4.4)
Análisis de lenguajes de transformación (§ 4.4)
Definición de los modelos y de las fronteras de MDA en el
AGDE (§ 5.2)
Definición de los modelos y de las fronteras de MDA en el
AGDE (§ 5.2)
XMI para los diagramas seleccionados de UML (§ 5.1)
XMI para los diagramas seleccionados de UML (§ 5.1)
Caracterización de las fronteras (§ 5.3)
Ilustración 4-1. Procedimiento general de la metodología de solución
4.1 Contexto del problema
Del análisis de la base conceptual del AGD resultó la definición de un ambiente de desarrollo que se denomina AGDE, representado en el diagrama de actividad de la Ilustración 4-2, en la cual se identifican dos áreas bien delimitadas:
1) La que trata con los modelos o productos del trabajo que se obtienen mediante
transformaciones sucesivas (delimitada mediante una frontera de línea punteada) y 2) La que configura, monitorea y controla el proceso (fuera de la frontera de línea
punteada).
Capítulo 4 Análisis del problema
26
act Ambiente AGDE detallado
Ingresar información delproyecto a la herramienta
de adecuación deldesarrollo
Registrar y monitorear elproceso (SiSoProS)
Utilizar herramienta detransformación de modelo a
modeloEditar modelos
Validar modelo resultante
Editar código Utilizar herramienta detransformación de modelo a
código
Compilación y depuración
Ingresar la información delproyecto al sistema dehistorial de proyectos
Utilizar herramienta detransformación de código a
modelo
«datastore»Historial de
proyectos
«datastore»Déposito de modelos v álido
del producto destino
«datastore»Déposito de código
fuente
Se identifica el patrón del proyecto de entrada
«datastore»Déposito de modelos de
producto fuente
«datastore»Déposito de modelos de
producto destino
«datastore»Déposito de
definición de transformaciones
«datastore»Déposito de modelos v alido del producto
destino
«datastore»Déposito de código
fuente
Integrar y completar elproducto de software
[Ingeniería directa]
[Codificación automática]
[Ingenieria inversa]
[Modelo PSM es suficiente]
[Modeladoautomático]
[Presencia dedefectos]
[Codificación manual]
[Modelado manual]
[Modelo PSM insuficiente]
Ilustración 4-2. Contexto de la investigación en el ambiente AGDE
El área delimitada por la línea puntada en la Ilustración 4-2 es donde se aplica el proceso
de modelado a través del enfoque MDA en el ambiente AGDE, donde se tiene un editor de modelos que permite realizar y guardar los modelos CIM, PIM y PSM, así como una herramienta de transformación de modelo a modelo, donde se obtienen cada uno de los modelos a partir de otros por medio de transformaciones.
Cada uno de los modelos realizados (tanto por el editor como por la herramienta de
transformación) debe ser validado contra un conjunto de reglas (predefinidas o definidas por el usuario). Una vez obtenidos los modelos válidos, se procede a verificar que el modelo PSM
Capítulo 4 Análisis del problema
27
sea lo suficiente para poder generar código, ya sea de forma manual o automática, por medio de una herramienta de transformación de modelo a código, para después ser compilado y depurado.
Todo este proceso se puede realizar cuando es ingeniería directa, ya que cuando es
ingeniería inversa se utilizaría una herramienta de transformación de código a modelo, es decir, a partir del código se necesita obtener un modelo que lo represente.
Por lo tanto, en el área de modelado, en el AGD se adopta la estructura de MDA y se
definen los modelos (CIM, PIM, PSM, IM) y fronteras (CIM a PIM, PIM a PSM y PSM a IM). Se utilizan las transformaciones entre el mismo nivel de abstracción (CIM a CIM, PIM a PIM, PSM a PSM) y entre diferente nivel de abstracción (CIM a PIM, PIM a PSM, PSM a IM), donde la mayoría de las transformaciones son de modelo a modelo y de modelo a código.
Todo lo mencionado anteriormente se realiza con el objetivo de desarrollar la propuesta para el proceso general de MDA en el ambiente AGDE, a través de lenguajes como: UML, XMI/XML y el lenguaje de transformación a seleccionar.
La forma en que se relacionan las representaciones de los lenguajes mencionados para
realizar el proceso de MDA en AGDE hasta la implementación en código se muestra en la Ilustración 4-3. Esta idea se mencionó parcialmente en el capítulo 2, mientras se analizaban los conceptos necesarios para entender mejor el presente trabajo de investigación.
En la Ilustración 4-3 se muestra horizontalmente, la relación entre las representaciones de
los modelos, desde la concepción de la aplicación, sin considerar dependencias computacionales (modelo CIM, a la izquierda de la figura), pasando por los modelos independientes de plataforma (modelo PIM) y los modelos de plataforma especifica (modelo PSM), hasta la generación del código (modelo IM, en la parte derecha de la figura).
Recorriendo la ilustración verticalmente, de arriba hacia abajo, UML se usa en los
modelos (CIM, PIM y PSM) de MDA mediante sus diagramas; XMI se utiliza para la representación interna de los diagramas UML y por último un lenguaje de transformación se usa para describir las transformaciones que se realizan mediante el motor de transformación para pasar de un modelo a otro hasta obtener una implementación (código fuente).
UML y XMI se pretenden utilizar tanto para la definición de los modelos como para la
definición de sus transformaciones.
Capítulo 4 Análisis del problema
28
XMLXMI
XMLXMI
XMLXMI
MDAR
epre
sent
ació
n
Rep
rese
ntac
ión
Rep
rese
ntac
ión
CIM(UML)
PIM(UML)
PSM(UML)
Especificación de transformación(Lenguaje de transformación)
Entrada Salid
a
Salid
a
Entrada
IM
XMLXMI
Entrada Salid
a
Rep
rese
ntac
ión
Motor de transformación
Especificación de transformación(Lenguaje de transformación)
Especificación de transformación(Lenguaje de transformación)
XMLXMI
XMLXMI
XMLXMI
MDAR
epre
sent
ació
n
Rep
rese
ntac
ión
Rep
rese
ntac
ión
CIM(UML)
PIM(UML)
PSM(UML)
Especificación de transformación(Lenguaje de transformación)
Entrada Salid
a
Salid
a
Entrada
IM
XMLXMI
Entrada Salid
a
Rep
rese
ntac
ión
Motor de transformación
Especificación de transformación(Lenguaje de transformación)
Especificación de transformación(Lenguaje de transformación)
Ilustración 4-3. Propuesta para el proceso general de MDA en AGDE 4.2 Análisis comparativo de AGD con otros enfoques El objetivo de este análisis es refinar los modelos contenidos en el Conjunto de Productos (PS) del método AGD, con la finalidad de partir de un conjunto de productos del trabajo (modelos), lo más completo posible, asegurando que se consideran los modelos necesarios y más utilizados en el desarrollo de software. Abarcando desde el grado de abstracción requerido para el modelado del negocio y la obtención de modelos intermedios, hasta la forma de obtener el código necesario para producir una aplicación computacional.
Se compara el AGD con respecto a los enfoques de desarrollo CMMI (Capability Maturity Model Integration), RUP (Rational Unified Process) e IDEF (Integrated DEFinition).
Los pasos que se siguieron para cumplir el objetivo antes mencionado fueron:
• Se realizó la comparativa de AGD con CMMI, RUP e IDEF (ver Anexo A) a través de los
distintos modelos de MDA (CIM, PIM, PSM y también IM) en el PS del AGD, para posteriormente,
• Analizar los resultados obtenidos de dichas comparaciones, para obtener qué tan completos están los modelos CIM, PIM, PSM e IM en el PS del AGD.
La descripción de todo este proceso se presenta en el anexo A y en esta sección sólo se
explican los resultados obtenidos del análisis. Por lo cual, en el anexo A se muestran las comparativas del conjunto de productos del trabajo (modelos) definidos en AGD con lo definido en CMMI, RUP e IDEF respectivamente, donde se elaboran unas tablas comparativas de AGD con cada enfoque. Los resultados de este análisis comparativo, sirven como
Capítulo 4 Análisis del problema
29
fundamento de un análisis posterior realizado con el propósito de integrar los diagramas de UML al esquema de modelos y fronteras de MDA (§4.3).
De las comparativas de AGD con otros enfoques se concluye que en el nivel CIM se presenta el negocio, sus restricciones, objetivos y estructura, así como su interacción con el problema.
Del modelado del negocio surgen poco a poco los requerimientos de los actores que
indirecta o directamente tienen que ver con el sistema. Se identifican los datos de entradas y salidas del sistema, que complementados con las opciones para capturarlos o generarlos, sirven para construir un prototipo a nivel abstracto.
Analizando el modelo CIM, además del IDEF fue necesario revisar una Notación de
Modelado de Proceso de Negocios (BPMN, Business Process Modeling Notation), para entender mejor los aspectos del negocio y cómo poder mapearlo hacia el nivel CIM del enfoque MDA.
En el nivel PIM se concluye que contiene el resultado del análisis de los requerimientos para transformarlos a un nivel de detalle menos abstracto y además se obtienen los casos de uso a mayor nivel de detalle, una representación de la interacción entre el usuario y el sistema, el proceso a seguir, así como los requerimientos del software y una especificación de las pruebas a realizar.
En el nivel PSM se muestra (en la mayoría de las comparaciones) el enfoque hacia el diseño detallado y la obtención de la arquitectura y los componentes del sistema.
Por último, a nivel de implementación se ubica el código fuente, la verificación y especificación de pruebas unitarias, de integración y de aceptación.
A continuación de la Tabla 4-1 a la Tabla 4-4, se presentan los resultados obtenidos, del
análisis descrito referente al conjunto de modelos que se ratificó son los más utilizados con respecto al AGD y los enfoques comparados en la parte del PS en el AGD. Las tablas mencionadas representan los modelos utilizados en cada nivel (CIM, PIM, PSM e IM), por cada uno de los enfoques. Mostrando en dichas tablas los productos principales a obtener en el desarrollo de software (Ej. Inicialización) y el contenido de los productos principales (Ej. Entender la estrategia).
El símbolo de “√”, cuando aparece en la intersección del renglón (correspondiente a un
producto del trabajo) con una columna (correspondiente a un enfoque), significa que se utiliza el producto del trabajo en ese enfoque. Por ejemplo, en el caso del producto de Inicialización en su contenido de dependencias con otros proyectos, RUP es el único que utiliza dicho producto del trabajo.
Tabla 4-1. Conjunto de modelos a nivel CIM del PS con respecto a los enfoques comparados
AGD en el nivel CIM CMMI RUP IDEF Identificación del proyecto √ √ √ Inicialización
Dependencias con otros proyectos √
Capítulo 4 Análisis del problema
30
Determinación del equipo del proyecto Entender la estrategia √ Entender el negocio √ √
Problemas/Oportunidades Obtener solicitudes del cliente √ √ √
Comparación cuantitativa de compañía nueva Áreas de Usuarios
Planificación-Visión
Alcance y prioridades √ √ Diagrama de entidades a nivel de usuario √ √
Diagrama de entidades combinado a nivel de usuario √ √ Negocio existente
Diagrama de entidad a nivel de aplicación √ √ Compilación de resultados principales Compilación de entradas principales √
Dependencias de resultados y entradas √ √ Compilación de opciones principales √
Dependencias de opciones Objetivos √ √
Alcance funcional √ √ √ Definición de resultados √ √ Definición de entradas √ √ √ Definición de opciones
Definición del diccionario de datos del sistema √
Identificación de componentes
Elementos de datos en interfase hombre-máquina √ Prototipo del sistema Integración del prototipo del sistema √ √
Tabla 4-2. Conjunto de modelos a nivel PIM del PS con respecto a los enfoques comparados
AGD en el nivel PIM CMMI RUP IDEF Definición de resultados en ingeniería inversa Definición de entradas en ingeniería inversa Ingeniería inversa flujo funcional y persistencia Opciones en ingeniería inversa Diccionario de datos Casos de uso Procesos funcionales Control de retro alimentación Tareas y procedimientos Cooperación Control administrativo Memoria organizacional
Ingeniería inversa
Diagrama de ciclos del sistema Diccionario de datos √ Flujo funcional y persistencia Resultados software Opciones Software Alcance incluyendo software Casos de uso √ √ Procesos funcionales √ Control de retroalimentación Procesos Cooperación Presentación de la interacción hombre-máquina √ √ √ Control administrativo Memoria organizacional
Ingeniería directa
Diagrama de ciclos del sistema Prototipo de software Integración del prototipo del sistema √ √ √
Requerimientos del software √ √ Requerimientos del software Especificación de prueba de aceptación √ √
Tabla 4-3. Conjunto de modelos a nivel PSM del PS con respecto a los enfoques comparados
AGD en el nivel PSM CMMI RUP IDEF Resultado usado por rol
Resultado producido en procesador y dispositivo de salida Restricciones en requerimientos
Entrada capturada en
Capítulo 4 Análisis del problema
31
Opciones funcionales procesadas en Datos almacenados √
Restricciones √ √ √ Soluciones alternativas √ Solución recomendable √
Riesgos/Beneficios √ √ Ciclo de negocio para Arquitectura
Árbol cálida para proyecto Especificación de calidad del componente
Calidad vs. estilos arquitectónicos Estructura de la arquitectura √ √ √
Fólder de arquitectura
Arquitectura del componente
Especificación de la prueba de integración √ √ √ Directores del negocio √ √
Extracción y análisis de estilos arquitectónicos Generación de escenarios √ √
Escenarios vs. Estilos arquitectónicos
Análisis de arquitectura
Reporte de análisis de arquitectura √ √ √
Tabla 4-4. Conjunto de modelos a nivel IM (Modelo de Implementación) del PS con respecto a los enfoques
comparados AGD en el nivel IM CMMI RUP IDEF
Estructura de división del trabajo √ Creación y mantenimiento de unidades
Asignación de unidades √
Diseño detallado
Creación y mantenimiento de carpeta de unidades Servicios a utilizar Diseño detallado: servicios normales
Servicios a usar por funciones Diseño detallado: métricas Programar eventos de monitoreo
Normas para procesos √ Normas computacionales
Procesos Diccionario de datos
Diseño detallado: datos de proceso
Especificación de prueba de aceptación √ √ Codificar unidad
Compilación √ Ligado √ Carga √ √
Codificación
Prueba de unidad √ Integración de código √ √
Estructurar componentes Prueba de integración √ √
Operación inicial
Elaborar documentación de usuario √ √
Al analizar la Tabla 4-1 a la Tabla 4-4 se obtuvieron los siguientes resultados: Primero, al analizar la Tabla 4-1 se tiene que a nivel CIM, el conjunto de productos del
trabajo en relación con los enfoques comparados en su mayoría está completo, debido a que este nivel contiene un total de 26 productos del trabajo, de los cuales en 7 no se encontró relación en forma directa con los enfoques comparados. Además, los 7 productos del trabajo puede que en los enfoques no se mencionen, pero se sobreentiende que deben de estar presentes, por ejemplo, el producto del trabajo “determinación del equipo del proyecto”, es necesario debido a que todo proyecto tiene personal que se va encargar de desarrollarlo.
Segundo, al analizar la Tabla 4-2, se obtuvo como resultado del nivel PIM, lo siguiente: el
total de productos del trabajo que contiene este nivel es de 30, de los cuales solamente 7 productos del trabajo se encontraron relacionados con los enfoques comparados, por lo tanto se podría decir que este nivel no está muy completo, pero 13 de los productos del trabajo que
Capítulo 4 Análisis del problema
32
no tienen relación con los enfoques comparados, deben estar presentes en este nivel, debido a que tratan sobre ingeniería inversa, la cual ninguno de los enfoques comparados la contempla (por lo menos en forma directa). Por lo tanto este nivel se puede decir que en su mayoría está completo.
Tercero, al analizar la Tabla 4-3 referente al nivel PSM, se tiene lo siguiente: de un total de
22 productos del trabajo, sólo 10 tienen relación con los enfoques comparados, por lo que este nivel, se podría decir que un poco menos de la mitad de productos del trabajo está completo (con respecto a los enfoques comparados) pero considerando la estructura del AGD, se tiene que los productos del trabajo que no se encontró una relación directa con los enfoques comparados, también deben de estar presentes en este nivel, por ejemplo, el producto del trabajo de “fólder de arquitectura”.
Por último, al analizar la Tabla 4-4 del nivel IM, se obtuvo que la mayoría de productos
del trabajo de este nivel está completo, debido a que el total de productos del trabajo de este nivel es de 21, dentro de los cuales 11 tienen relación con los enfoques comparados. Los productos del trabajo que no tiene relación también deben estar presentes en este nivel, debido a la estructura del PS del AGD, por ejemplo, creación y mantenimiento de carpetas de unidades. 4.3 Análisis de UML (Unified Modeling Language) 2.0 Con el propósito de seleccionar los diagramas a utilizar en MDA en el ambiente AGDE e identificar la forma en que se relacionan los elementos de cada uno de los diagramas elegidos, se realiza el análisis de UML 2.0, el cual consta de tres subsecciones.
Las primeras dos subsecciones, se refieren al análisis de los diagramas de UML 2.0 a seleccionar (§ 4.3.1) y al análisis de los diagramas seleccionados con respecto a los diagramas restantes de UML 2.0 (§ 4.3.2), donde el propósito de la primera es seleccionar el conjunto mínimo de diagramas UML que se van a utilizar en MDA en el ambiente AGDE y el de la segunda es reafirmar los diagramas seleccionados a través del porcentaje de elementos que cubren estos diagramas con respecto a los diagramas restantes de UML.
Por último, la tercera subsección describe el análisis de los elementos de cada uno de los diagramas seleccionados (§ 4.3.3), con el propósito de identificar la manera en que se relacionan los elementos de cada uno de los diagramas elegidos, para su posterior utilización en la representación interna de dichos diagramas (XMI, § 5.1). A continuación se explica cada una de las subsecciones que conforman el análisis de UML 2.0. 4.3.1 Análisis de los diagramas de UML 2.0 a seleccionar Habiendo identificado el conjunto de modelos manejados por el AGD y los enfoques de mayor utilización, se realizó un análisis de MDA con respecto al UML para ilustrar de qué manera colaboran los diferentes diagramas para obtener la implementación de una aplicación computacional. De está manera se establecieron las bases para seleccionar un conjunto
Capítulo 4 Análisis del problema
33
mínimo de los diagramas de UML que se van a usar dentro del esquema MDA en el ambiente AGDE. Los pasos que se siguieron para cumplir el objetivo mencionado, fueron: • Primero, se analizó la frecuencia de uso de los diagramas UML en el enfoque MDA, (a
través de lo anteriormente analizado en este capítulo y en el capítulo anterior) y en otros trabajos relacionados que siguen un desarrollo dirigido por modelos, para
• Posteriormente, realizar una tabla donde se reporta la frecuencia de uso, y del análisis de dicha tabla extraer un primer grupo de los diagramas a seleccionar.
Para elaborar la Tabla 4-5 y obtener las frecuencias de uso de los diagramas UML
utilizados en MDA como en trabajos que siguen un desarrollo dirigido por modelos, se analizaron las herramientas MDA (§3.2.1), los trabajos relacionados (§3.2.2), el AGD ([GON06]), el RUP ([RUP05]) y otros artículos revisados ([GAR06], [TRO03], [ZUN02], [ULR06]), con el propósito de determinar los diagramas a seleccionar de acuerdo a los diagramas que más se utilizaron en ellos.
A continuación se presenta la Tabla 4-5, donde la primera columna representa el nombre
de cada uno de los 13 diagramas de UML 2.0 y de la segunda columna hasta la sexta columna se muestra el número de frecuencia de uso de cada uno de los diagramas con respecto a los trabajos y herramientas que aplican MDA o un desarrollo dirigido por modelos. Por último, la séptima columna es la del total, donde se contabilizó el número de veces que se utilizan los diagramas a partir de la segunda columna hasta la sexta columna.
Tabla 4-5. Selección de los diagramas de UML para MDA
Diagramas UML Herramientas MDA (§3.2.1)
Trabajos relacionados
(§3.2.2)
AGD [GON06]
RUP [RUP05]
Otros artículos [GAR06], [TRO03], [ZUN02], [ULR06]
Total
Diagrama de clases 4 4 1 1 4 14 Diagrama de objetos 1 1 2 Diagrama de componentes 3 1 4 Diagrama de paquetes 1 1 2 Diagrama de estructura compuesta Diagramas de distribución o despliegue 3 1 1 1 1 7 Diagramas de máquina de estados 3 1 2 6 Diagramas de casos de uso 4 3 1 1 4 13 Diagramas de actividad 4 3 4 11 Diagramas de secuencia 4 1 1 4 10 Diagramas de comunicación 3 1 3 7 Diagramas de cronometraje o tiempos Diagramas de la revisión de la interacción
Como resultado del análisis de la Tabla 4-5 se obtuvo que los diagramas que tienen un
mayor número de repeticiones son: diagramas de clases, de casos de uso, de actividad y de secuencia. Además, cabe mencionar que en [AMB04] se señala que los diagramas que tienen alta prioridad de aprendizaje (indica cuán importante es para un desarrollador de aplicaciones del negocio aprender el diagrama) son: el de clases, secuencia y actividad, coincidiendo con la conclusión de la Tabla 4-5 correspondiente a los diagramas a utilizar. Aunque se menciona en [AMB04] que el diagrama de casos de uso presenta una prioridad media.
A partir de la conclusión de la Tabla 4-5 (los diagramas más utilizados), se tiene un primer
acercamiento al conjunto mínimo de diagramas de UML a manejar en las herramientas del AGDE y así acotar el universo inicial de los modelos y sus transformaciones.
Capítulo 4 Análisis del problema
34
En la Ilustración 4-4, se muestra el conjunto de diagramas, a través de un esquema que muestra la distribución de los diagramas seleccionados de UML en los distintos niveles (CIM, PIM, PSM, IM) del enfoque MDA (en el AGDE) y cómo se relacionan entre sí, donde no se abarca la utilización de los diagramas de entidad y línea de producción del AGD (ver capítulo 5), debido a que estos diagramas ya están ubicados dentro de MDA en el AGD.
Diagrama de casos de uso
Escenarios de los diagramas de casos de uso
Desglose de los diagramas de casos de uso
Especificación adicional
Diagramas de secuencia
Especificación adicional
Especificación adicional
Diagramas de clases
Especificación adicional
Especificación adicional
Diagramas de actividad
Diagramas de clases
Generación de código
Diagramas de actividad
Especificación adicional
Nivel CIM
Nivel PIM
Nivel PSM
Implementación
Ilustración 4-4. UML dentro del enfoque MDA en el AGDE
La Ilustración 4-4 presenta en el nivel CIM la utilización de los diagramas de casos de uso
y sus escenarios, así como el desglose de cada uno de los casos de uso, ya que los casos de uso iniciales son más abstracto y el desglose representa un segundo nivel de abstracción más detallado. En el nivel PIM se muestra la utilización de los diagramas de secuencia y de clases que se obtienen mediante el diagrama de secuencia, el cual se origina a partir de los diagramas de casos de uso del nivel CIM. Los diagramas de actividad se obtienen del diagrama de secuencia y del diagrama de clases, todo a nivel PIM. En el nivel PSM se muestra la utilización otra vez del diagrama de clases y actividad que surgen a través de los diagramas de clases y secuencia del nivel PIM. Por último, el nivel IM (Modelo de Implementación), que contiene el código, se obtiene a partir del diagrama de actividad y clases del nivel PSM. Todos los niveles tienen una especificación adicional para complementar cada uno de los diagramas, para pasar de un nivel a otro.
Capítulo 4 Análisis del problema
35
4.3.2 Análisis de los diagramas seleccionados con respecto a los diagramas restantes de UML 2.0
Una vez obtenido el conjunto mínimo de los diagramas de UML a utilizar, es necesario realizar otro análisis para corroborar que los diagramas seleccionados cubren la mayoría de los elementos definidos en UML, con el objetivo de reafirmar los diagramas seleccionados. Para ello se realizaron los pasos siguientes:
• Se determinó, para cada uno de los elementos de los 13 diagramas, los elementos en
común que tiene un determinado diagrama con respecto a los demás diagramas (por ejemplo, el elemento “Línea de vida” en el diagrama de secuencia también se utiliza en el diagrama de cronometraje o tiempos, ver anexo B) con la finalidad de obtener el número de elementos en común de los 4 diagramas seleccionados (casos de uso, clases, secuencia y actividad) con los 9 diagramas (componente, objeto, paquete, estructura compuesta, despliegue, máquina de estado, comunicación, tiempo y revisión de la interacción) restantes de UML (esto se presenta en el anexo B).
• Como resultado del paso anterior, se obtuvo el número de elementos exclusivos de cada diagrama (los elementos que sólo se presentan en uno de los diagramas y por lo tanto no tienen un uso en común con otros) y el número de elementos repetidos de cada diagrama contando una sola vez el elemento repetido (ver Tabla 4-6). Todos estos pasos se realizaron con el propósito de obtener como resultado el porcentaje
que cubren los diagramas de: casos de uso, clases, secuencia y actividad con respecto a los 9 diagramas restantes de UML 2.0 y con ello corroborar que los diagramas seleccionados usan la mayoría de los elementos definidos en UML.
En el anexo B se muestra el análisis de los 13 diagramas de UML 2.0 con los elementos
correspondientes a cada diagrama, donde se denotan los elementos que son exclusivos al diagrama, así como los elementos que tienen en común con otros diagramas.
La Tabla 4-6 presenta a los 13 diagramas de UML 2.0 en relación al número de elementos
exclusivos (elementos únicos en un diagrama determinado) y al número de elementos repetidos contabilizados una sola vez un elemento repetido, así como el total de elementos exclusivos y el total de elementos repetidos, para con toda esta información calcular el porcentaje de elementos que cubren los diagramas de casos de uso, clases, secuencia y actividad con respecto al total de elementos de los 13 diagramas de UML 2.0 (que representan el 100%, contando elementos repetidos una sola vez y elementos exclusivos).
Tabla 4-6. Número de elementos exclusivos y repetidos de los 13 diagramas UML Diagrama # de elementos
exclusivos # de elementos
repetidos Casos de uso 5 2 Clases 2 9 Secuencia 9 8 Actividad 11 8 Componentes 1 1 Objetos 0 0 Paquete 3 0 Estructura Compuesta 7 1
Capítulo 4 Análisis del problema
36
Despliegue 4 0 Máquina de estados 13 0 Comunicación 0 0 Tiempo 4 0 Revisión de la interacción 1 0
Total 60 29
De la información de la Tabla 4-6, se derivan los siguientes datos necesarios para el
cálculo del porcentaje de elementos a considerar con los 4 diagramas seleccionados: • Primero, para obtener el total de elementos de los 13 diagramas de UML 2.0, se
sumaron el total de elementos exclusivos que es de 60 y el total de elementos repetidos (contando una sola vez el elemento repetido) que es de 29, lo que dio como resultado que el total de elementos de los 13 diagramas es de 89 (correspondiente al 100%).
• Posteriormente, para obtener el total de elementos de los 4 diagramas seleccionado se sumaron los números de los elementos exclusivos que es de 27 y los números de los elementos repetidos que es de 27, de los diagramas de casos de uso, clases, secuencia y actividad, lo que dio como resultado que el total de elementos de los 4 diagramas seleccionados es de 54.
Con todos los datos anteriormente calculados se obtiene que el porcentaje de elementos a
considerar es de 60.67%, proveniente del cálculo (54/89)*100 y el porcentaje de elementos no considerados es de 39.33%, proveniente del cálculo ((89-54)/89)*100.
Hasta el momento, se tiene como conclusión de todo el análisis de UML 2.0 que los
diagramas elegidos son: casos de uso, clases, secuencia y actividad, y el porcentaje total de elementos que cubren dichos diagramas con respecto al total de los elementos de los 13 diagramas del UML 2.0 es de 60.67%.
4.3.3 Análisis de los elementos de cada uno de los diagramas seleccionados Con el propósito de desarrollar una representación interna (en XMI, § 5.1) que contenga la información adecuada a los diagramas elegidos de UML 2.0, para especificar las fronteras entre los modelos, se requiere del análisis de los elementos de cada uno de los diagramas seleccionados, con la finalidad de identificar la manera en que se relaciona cada uno de los elementos de cada diagrama y a través de qué conector. Todo este análisis servirá para estructurar la representación interna (los documentos XMI y DTD’s, § 5.1) de cada uno de los diagramas elegidos.
De la Tabla 4-7 a la Tabla 4-10 se muestran los diagramas de casos de uso, clases, secuencia y actividad con las relaciones entre sus elementos y conectores.
Todas las tablas simplemente reflejan la forma en que se pueden diagramar los elementos
de los 4 diagramas seleccionados, para posteriormente reflejarlos en la estructura de XMI para la representación interna de estos diagramas.
Las tablas están divididas en tres columnas, donde la primera representa el elemento
origen (del cual se parte para conectarlo con otro elemento), la segunda representa el tipo de
Capítulo 4 Análisis del problema
37
conector que se puede utilizar para un par de elementos y por último la tercera columna representa el elemento al cual se quiere llegar (elemento destino).
Por ejemplo, en la Tabla 4-7 de diagrama de casos de uso, el elemento “Actor” (elemento
origen), indica que este elemento se puede relacionar sólo con los elementos “actor”, “caso de uso” o “subject” (elementos destino) y el tipo de conector a utilizar serían los elementos conectores de “uso” o “generalización”, pero cuándo el destino sea el elemento “subject” sólo se utilizará el elemento conector de “uso”.
Esta misma lógica se sigue para los demás elementos y para las demás tablas de los
diagramas clases, secuencia y actividad.
Tabla 4-7. Relaciones entre los elementos del diagrama de Casos de uso Origen Conector Destino
Uso, Generalización Actor
Caso de uso
Actor
Uso Subject
Uso, Generalización
Incluye, Extiende
Caso de uso
Punto de extensión
Caso de uso
Uso Actor
Subject
Subject Uso Actor
Caso de uso
Subject
Punto de extensión Uso, Generalización
Incluye, Extiende
Caso de uso
Subject
Tabla 4-8. Relaciones entre los elementos del diagrama de Clases
Origen Conector Destino
Generalización Clase Clase
Asociación Composición Agregación
Dependencia
Realización
Realización de la interfaz Rastro
Anidar
Clase
Interfaz
Interfaz Generalización Interfaz
Capítulo 4 Análisis del problema
38
Asociación Composición Agregación
Dependencia
Realización
Realización de la interfaz Rastro
Anidar
Clase
Interfaz
En la Tabla 4-9 se muestran los elementos del diagrama de secuencia. Sin embargo los
elementos de “stop”, “coregion”, “restricción de duración” (“duración”, “observación”), “restricciones” y “observaciones de tiempo” no se muestran en la tabla, debido a que éstos se representan a través del elemento de “mensaje” y “línea de vida” (en cualquiera de sus representaciones), excepto el elemento “stop” que sólo se representa en el elemento de “línea de vida” (en cualquiera de sus representaciones).
Tabla 4-9. Relaciones entre los elementos del diagrama de Secuencia
Origen Conector Destino
Línea de vida
Actor
Límite
Control
Entidad
Estado Invariante / Continuaciones
Fragmento combinado
Marco
Gate
Mensaje perdido, mensaje encontrado
Stop
Empleo de interacción
Restricciones de tiempo, Observaciones de tiempo
Actor
Línea de vida
Límite
Control
Entidad
Mensaje
Ordenamiento general
Restricciones de duración, Duración, Observación
Capítulo 4 Análisis del problema
39
Coregion
Actor Actor
Línea de vida Línea de vida
Límite Límite
Control Control
Entidad
Self- Message
Entidad
Empleo de interacción
Gate
Mensaje perdido, mensaje encontrado
Actor
Línea de vida
Límite
Control
Entidad
Fragmento combinado
Fragmento combinado
Marco
Empleo de interacción
Mensaje
Marco
Empleo de interacción
Fragmento combinado
Marco
Mensaje perdido, mensaje encontrado
Actor
Línea de vida
Límite
Control
Entidad
Gate
Mensaje
Gate
Actor
Línea de vida
Límite
Control
Estado Invariante / Continuaciones
Mensaje
Entidad
Mensaje perdido, mensaje encontrado Mensaje Empleo de interacción
Capítulo 4 Análisis del problema
40
Gate
Fragmento combinado
Marco
Actor
Línea de vida
Límite
Control
Entidad
Mensaje perdido, mensaje encontrado
Actor
Línea de vida
Límite
Control
Restricciones de duración, Duración, Observación
Mensaje
Entidad
Actor
Línea de vida
Límite
Control Restricciones de tiempo, Observaciones de tiempo
Mensaje
Entidad
Restricciones de duración, Duración, Observación
Restricciones de tiempo, Observaciones de tiempo
Actor
Línea de vida
Límite
Control
Coregion
Mensaje
Entidad
Capítulo 4 Análisis del problema
41
Tabla 4-10. Relaciones entre los elementos del diagrama de Actividad Origen Conector Destino
Actividad
Nodo de decisión
Nodo Final
Acción
Nodo merge
Flujo final
Nodo de bifurcación
Flujo de control, Flujo de interrupción
Nodo de unión
Almacén de datos
Acción de señal enviada
Acción de evento recibido
Flujo de control, Flujo de
interrupción, Flujo de objeto
Excepción
Actividad
Flujo de control, Flujo de objeto
Nodo de objeto
Actividad
Nodo de decisión
Nodo de bifurcación
Nodo de unión
Nodo merge
Acción de señal enviada
Acción de evento recibido
Flujo de control
Acción
Nodo de objeto Flujo de control, Flujo de objeto
Almacén de datos
Nodo inicial
Flujo de control, Flujo de
interrupción, Flujo de objeto
Excepción
Actividad
Acción
Excepción
Nodo de decisión
Nodo Final
Excepción
Flujo de control, Flujo de objeto Acción de señal
enviada
Capítulo 4 Análisis del problema
42
Acción de evento recibido
Nodo merge
Nodo de bifurcación
Nodo de unión
Almacén de datos
Nodo de objeto
Flujo final
Actividad
Acción
Nodo de decisión
Nodo Final
Nodo merge
Nodo de bifurcación
Nodo de unión
Flujo de control, Flujo de interrupción
Flujo final
Excepción
Acción de señal enviada
Acción de evento recibido
Flujo de control, Flujo de
interrupción, Flujo de objeto
Almacén de datos
Acción
Flujo de control, Flujo de objeto
Nodo de objeto
Actividad
Acción
Excepción
Nodo de decisión
Nodo Final
Nodo de bifurcación
Nodo de unión
Flujo final
Nodo merge
Acción de señal enviada
Acción de evento recibido
Nodo de objeto
Flujo de control, Flujo de objeto
Almacén de
Capítulo 4 Análisis del problema
43
datos
Nodo de objeto
Actividad
Acción
Excepción
Nodo de decisión
Nodo Final
Nodo de bifurcación
Nodo de unión
Flujo final
Acción de señal enviada
Acción de evento recibido
Nodo merge
Almacén de datos
Flujo de control, Flujo
de interrupción, Flujo de objeto
Nodo de objeto
Almacén de datos
Flujo de control, Flujo de objeto
Actividad
Acción Flujo de control, Flujo de interrupción Excepción
Nodo de decisión
Nodo Final
Nodo de bifurcación
Nodo de unión
Nodo merge
Flujo final
Acción de señal enviada
Acción de evento recibido
Almacén de datos
Flujo de control, Flujo de
interrupción, Flujo de objeto
Nodo de objeto
Nodo de decisión
Flujo de control, Flujo de objeto
Actividad
Acción
Excepción
Nodo de decisión
Acción de señal enviada
Acción de evento recibido
Flujo de control, Flujo de
interrupción, Flujo de objeto Nodo Final
Capítulo 4 Análisis del problema
44
Nodo de bifurcación
Nodo de unión
Nodo merge
Flujo final
Acción de señal enviada
Acción de evento recibido
Almacén de datos
Nodo de objeto
Flujo de control, Flujo de objeto
Actividad
Actividad
Nodo inicial
Región
Excepción
Acción
Nodo de decisión
Nodo Final
Acción de señal enviada
Acción de evento recibido
Nodo merge
Nodo de bifurcación
Nodo de unión
Almacén de datos
Nodo de objeto
Partición
Flujo de control,
Flujo de interrupción,
Flujo de objeto
Flujo final
Actividad
Región
Excepción
Acción
Nodo de decisión
Acción de señal enviada
Acción de evento recibido
Región
Flujo de control, Flujo de
interrupción, Flujo de objeto
Nodo merge
Capítulo 4 Análisis del problema
45
Nodo de bifurcación
Nodo de unión
Almacén de datos
Nodo de objeto
Para terminar con la sección 4.3 del análisis de UML 2.0, se tiene que los elementos que
no se consideraron de los 9 diagramas restantes (diagramas no seleccionados, que es de un 39.33%) de UML 2.0, no se ocuparán, en la validación mediante un caso de estudio, debido a que el dominio del problema es el de sistemas de información. Estos sistemas solamente se utilizan para controlar las principales funciones de una empresa o negocio (ejemplos, la contabilidad, la mercadotecnia, ventas, el personal) [LAY04]. Además, otra razón para utilizar sólo los 4 diagramas elegidos, es que de los 9 diagramas no seleccionados los diagramas de tiempo y máquina de estado son más especificos para algún tipo de sistema, como sistemas en tiempo real o sistemas embebidos, por otro lado, los diagramas de revisión de la interacción, objetos, comunicación y estructura compuesta engloban o parten de alguno de los 4 diagramas seleccionados por ejemplo, el diagrama de revisión de interacción es una forma de diagrama de actividad, y por último, los diagramas de paquete, despliegue y componentes agrupan u organizan a otros diagramas, como al diagrama de clases. 4.4 Análisis de lenguajes de transformación Debido a que los elementos esenciales del enfoque MDA son los modelos15 y las transformaciones entre modelos16, se requiere identificar un lenguaje específico, para la definición de dichas transformaciones, debido a que son importantes en MDA para los procesos de transformación que automatizan la transformación de modelos de alto nivel de abstracción en modelos de más bajo nivel de abstracción.
Existen varios lenguajes de transformación de modelo a modelo o de modelo a código, donde cada uno tiene sus propias características y contemplan algunos aspectos que MDA persigue para la realización de las transformaciones. El objetivo de este análisis es encontrar un lenguaje de transformación que se adecue a la idea propuesta para el proceso apegado a MDA en el ambiente AGDE, mostrado al inicio del capítulo, en la Ilustración 4-3.
La información para realizar el análisis se presenta en la Tabla 4-11, la cual muestra la información a comparar de los distintos lenguajes de transformación de modelo a modelo y sus características. El símbolo “√” en la intersección de un renglón con una columna, significa que la condición es verdadera y cuando está en blanco significa que la condición es falsa. A continuación se explica cada una de las columnas de la tabla.
15 Ya que los utiliza para dirigir el proceso de desarrollo de software. 16 Porque a partir del primer modelo se obtiene el segundo por medio de transformaciones y así sucesivamente para obtener los demás modelos hasta la implementación ejecutable.
Capítulo 4 Análisis del problema
46
1er. columna: Lenguaje de transformación. Contiene las siglas de los siguientes lenguajes de transformación: Model Transformation Framework (MTF), Atlas Transformation Languaje (ATL), XSL Transformations (XSLT), The Bidirectional Object oriented Transformation Language (BOTL), The Attributed Graph Grammar System (AGG), A Tool for Multi-Formalism Modelling and Meta-Modelling (AToM3), VIsual Automated model TRAnsformations (VIATRA), Query-View Transformation (QVT), Visual Modeling and Transformation System (VMTS) y Graph Rewriting and Transformation language (GreAT).
2da. Columna: Enfoque de transformación. Se basa en los enfoques de transformación presentados en el trabajo de “Classification of Model Transformation Approaches” [CZA03], en el cual se menciona una clasificación de enfoques de transformación que pueden ser: de modelo a modelo y de modelo a código. En este análisis sólo se considera la categoría de enfoques de transformación de modelo a modelo, debido al objetivo planteado para esta investigación y a que el enfoque MDA se basa principalmente en modelos y las transformaciones entre ellos. A continuación se describen los enfoques que se encuentran dentro de esa categoría:
• Enfoque de manipulación directa. Este enfoque ofrece al usuario el acceso a una
representación interna del modelo y la capacidad de manipular la representación mediante un conjunto de API’s. Normalmente éste es implementado como un marco orientado a objetos, que puede proporcionar alguna infraestructura mínima para organizar la transformación (Ej. la clase abstracta para transformaciones). Por lo que, básicamente todo el trabajo tiene que ser hecho por el usuario, debido a que tienen que aplicar reglas de transformación y planificar en su mayor parte la utilización de un lenguaje de programación (tal como Java) desde el principio. Ejemplos: Jamda, JMI.
• Enfoque relacional. Este enfoque se basa en relaciones matemáticas (como concepto principal), enfoques declarativos y reglas de mapeo. La idea es declarar el tipo de elemento del origen y del elemento objetivo de una relación y especificarlo usando una restricción. En su forma pura, tal especificación no es ejecutable (Ej. reglas de mapeo). Ejemplos: MTF, VIATRA, ATOM, GreAT, UMLX y BOTL.
• Enfoque a base de transformación de grafos. Este enfoque se basa en el trabajo teórico de transformaciones de grafos. En particular en grafos específicamente diseñados para representar modelos como UML. Las transformaciones de grafos consisten en aplicar una regla de transformación a un grafo e iterar este proceso. Cada regla de transformación es aplicada a un grafo (izquierdo) mediante la sustitución de una parte de éste por un grafo (derecho). Este enfoque es poderoso y declarativo, pero también uno de los enfoques más complejos. La complejidad se deriva del no determinismo en la planificación y en la estrategia de aplicación, que requiere la consideración cuidadosa de la terminación del proceso de transformación y del orden de aplicación de las reglas. Ejemplos: AToM3, VMTS.
• Enfoque dirigido por estructura. Su característica principal es que tiene una regla de organización orientada al objetivo. Este enfoque tiene dos fases: la primera crea la estructura jerárquica del modelo objetivo y la segunda establece los atributos y referencias en el objetivo. El marco total determina la planificación y la estrategia de aplicación; los usuarios sólo se preocupan por proveer las reglas de transformación.
Capítulo 4 Análisis del problema
47
Un ejemplo sería el marco de transformación de modelo a modelo proporcionado por OptimalJ. Algunos ejemplos de lenguajes de transformación de este tipo son: Kermeta, IOPT (Interactive Objects and Project Technology).
• Enfoque híbrido. Este enfoque emplea la combinación de diversas técnicas de las categorías anteriores, debido a que está conformado por enfoques declarativos e imperativos. Permite al usuario igualar conceptos diferentes y paradigmas dependiendo de la aplicación. Ejemplos: XDE, ATL.
3er. Columna: Tipo de lenguaje. Estos pueden ser de dos tipos o una combinación de ambos, los cuales son:
• Declarativos [TUC03]. “El usuario tiene que declarar los objetivos del cálculo en
lugar del algoritmo detallado con el que se consiguen dichos objetivos. Los objetivos se expresan como un grupo de reglas y restricciones de cálculo. El orden en que se ejecuten los cálculos no influye en el resultado”.
• Imperativos [TUC03]. “Es el más utilizado y mejor desarrollado. El usuario tiene que detallar la manipulación explicita del estado del sistema de la computadora. Las instrucciones son realizadas de manera secuencial”.
• Declarativo-Imperativo. Son aquellos lenguajes que hacen uso de ambos tipos de lenguajes para obtener el beneficio de ambos y que se les conoce como lenguajes híbridos.
4ta. Columna: Lenguajes propuestos de representación del proceso MDA en el AGDE. Las características adicionales que se consideran de acuerdo a la idea de desarrollo propuesta para el enfoque MDA del AGDE, son las que a continuación se mencionan, con el propósito de ver si los lenguajes de transformación utilizan estos lenguajes para llevar a cabo las transformaciones, debido a que estos lenguajes son relevantes para la presente investigación.
• Soporte de UML. Se realizan transformaciones entre diagramas UML, es decir, a
partir de un diagrama es obtenido otro de igual o diferente nivel de abstracción. Ubicar este lenguaje en nuestra investigación, es necesario debido a que cada modelo de MDA contendrá varios diagramas UML.
• Soporte de XML ó XMI. Las transformaciones son entre documentos XML ó XMI. Ubicar estos lenguajes en la presente investigación, es necesario debido a que se utilizan para guardar la información contenida en los diagramas UML.
5ta. Columna: Características deseables para las transformaciones. Existen características deseables para el proceso de transformación dentro del enfoque MDA que se encuentran en el libro “MDA Explained: The Model Driven Architecture: Practice and Promise” [KLE03] y que para el AGDE se adoptan, debido a que se requiere tener el control y las ventajas de contar con las características que definan la transformación, para que se pueda generar de forma automática. A continuación se describen las características deseables:
• Control y acuerdo de transformaciones. Al realizar transformaciones el
desarrollador debería tener cierto control sobre el proceso de transformación. Esto
Capítulo 4 Análisis del problema
48
puede lograrse de varias formas por ejemplo: control manual, condiciones en las transformaciones, parámetros de transformación.
• Trazabilidad. Implica que pueda conocerse el elemento origen a partir del cual se ha generado cualquier elemento del modelo destino.
• Consistencia. Es importante para mantener la información adicional que se requiere para transformar un modelo en otro, de manera que pueda reutilizarse cuando se requiera una modificación o actualización del modelo fuente para volver a realizar su transformación al modelo objetivo.
• Bidireccionalidad. Implica que las transformaciones puedan operar en ambas direcciones. Estas pueden lograrse de dos formas:
o Ambas transformaciones se ejecuten de acuerdo con una única definición de
transformación. o Una transformación y su inversa se especifican mediante dos definiciones
de transformación diferentes. Entre las características que se desean en el ambiente AGDE primordialmente son la trazabilidad y consistencia, debido a que se necesita la definición de la transformación, es decir, qué elementos del modelo origen implican qué elementos del modelo destino y cuál es la información adicional que se agrega para obtener el modelo destino, que no se contempla en el modelo origen, pero que es derivada del mismo incluyendo más detalle en la información contenida en dicho modelo.
Tabla 4-11. Comparativa de lenguajes de transformación
Lenguajes propuestos de
representación del proceso MDA en el
AGDE
Características deseables para las transformaciones
Lenguaje de transformación
Enfoque de transformación
Tipo de lenguaje
Sopo
rte
para
UM
L
Sopo
rte
para
XM
L
Sopo
rte
para
XM
I
Con
trol
y a
cuer
do d
e tr
ansf
orm
acio
nes
Tra
zabi
lidad
Bid
irec
cion
abili
dad
Con
sist
enci
a
AGG [AGG07] Grafo Declarativo √ √ √ VIATRA2 [VIATRA06, CSE02] Grafo Declarativo √ √ √ √ AToM3 [ATOM07] Grafo Declarativo √ Kermeta [KERMETA07] Dirigido por estructura Imperativo √ √ √ VMTS [VMT07] Grafo Declarativo √ √ √ √ Tefkat [TEFKAT07] Relacional Declarativo √ √ ATL [ATL06] Híbrido Declarativo-Imperativo √ √ UMLX [WIL04] Grafo Declarativo √ √ √ QVT [QVT05] Híbrido Declarativo-Imperativo √ √ √ √ MTF [DEM05] Relacional Declarativo √ √ √ √ XSLT [XSLT07, QUE06] Híbrido Imperativo-Declarativo √ √ √ √ BOTL [BRA03] Grafo Declarativo √ √ √ √ √ GReAT [AGR03] Grafo Declarativo √ √ RubyTL [SAN06-A], [SAN06-B] Híbrido Declarativo-Imperativo √ √ √ √
El criterio o razonamiento utilizado para obtener el lenguaje de transformación que se
usará, de la Tabla 4-11, que más se adecue al proceso propuesto para MDA en el AGDE, se presenta a continuación:
Capítulo 4 Análisis del problema
49
• Se considerará en primer lugar que el lenguaje cumpla por lo menos con tres características deseables para la transformación y específicamente que incluya las características de trazabilidad y consistencia. Por lo tanto los lenguajes que cumplieron este primer criterio fueron: VIATRA2, MTF, BOLT y RubyTL.
• Una vez obtenido este primer grupo de lenguajes seleccionados mediante el criterio anterior, se seleccionan aquellos lenguajes que realicen las transformaciones mediante XMI (debido a que este será el formato tanto de entrada como de salida para el lenguaje de transformación, de acuerdo al proceso propuesto para MDA en el AGDE). Por lo tanto los lenguajes que cumplieron este criterio fueron: VIATRA2 y RubyTL.
• Por último, si existiera empate entre los lenguajes se revisa la característica del tipo de lenguaje, la cual será preferentemente el que sea tanto declarativo como imperativo (para tener los beneficios de ambos tipos). Por lo tanto el lenguaje de transformación seleccionado fue RubyTL.
Dado los criterios mencionados RubyTL es el candidato seleccionado para estudiarse a
fondo, ya que cumple con la mayoría de las características deseadas de un lenguaje de transformación como: consistencia, trazabilidad y control de las transformaciones, además de realizar transformaciones entre XMI y tener la característica de ser un lenguaje extendible, que se puede adaptar a nuestras necesidades de agregar reglas, necesarias para realizar las transformaciones entre los diferentes niveles de abstracción, que representan cada uno de los modelos de MDA.
Los resultados obtenidos de los análisis de AGD, UML y lenguajes de transformación,
explicados en este capítulo tienen un gran impacto en el capítulo siguiente, para especificar la representación interna a utilizar, y el desarrollo de la definición de los modelos y fronteras de MDA en el AGDE. A través de los análisis reportados se obtuvo la información necesaria para cada modelo y sus fronteras a través del conjunto de modelos a utilizar, el conjunto mínimo de diagramas y el lenguaje de transformación para realizar transformaciones entre los distintos modelos de MDA. El lenguaje de transformación se pretende adecuar a los requerimientos del AGDE, aunque esto es un trabajo futuro, de acuerdo a los alcances definidos para esta investigación.
50
Capítulo 5
Solución propuesta
Como resultado de los análisis de AGD con otros enfoques (§ 4.2), de UML 2.0 (§ 4.3) y de lenguajes de transformación (§ 4.4), explicados en el capítulo anterior, se obtiene en este capítulo la definición de la representación interna, la definición de los modelos (CIM, PIM, PSM, IM), así como una representación visual de dicha definición por medio de un esquema y la delimitación de las fronteras de MDA con su correspondiente caracterización (CIM a PIM, PIM a PSM y PSM a IM) que servirán como fundamento para realizar las transformaciones necesarias y obtener una implementación ejecutable mediante el ambiente AGDE. Se utiliza UML (los diagramas de casos de uso, clases, secuencia y actividad) en cada modelo MDA. Y se usa también un subconjunto de XMI para la representación interna de los diagramas. La definición de los modelos se basa mediante el análisis del AGD.
El objetivo que se persigue con todo lo mencionado es delimitar y determinar las características distintivas de cada una de las fronteras, de manera que se distingan claramente entre ellas, para tomarlas como referencia cuando se definan las transformaciones necesarias entre cada modelo ayudando a determinar cuando un tipo de modelo (Ej. CIM) se convierte en otro modelo (Ej. PIM). El procedimiento que se realizó para cumplir tal objetivo fue:
• Desarrollar una representación interna (en XMI) que contenga la información adecuada a los diagramas seleccionados de UML. La representación interna se usará para especificar las fronteras entre los modelos (CIM a PIM, PIM a PSM y PSM a IM), así como para almacenar la información de los modelos (diagramas UML) a utilizar como fuente y destino de las transformaciones.
• Definir cada uno de los modelos (CIM, PIM, PSM e IM) de MDA y sus fronteras, a través de los diagramas seleccionados y de otros del AGD, para obtener la información
Capítulo 5 Solución propuesta
51
que contendrá cada uno de los modelos y cómo ayudará ésta a la transformación de los mismos.
• Obtener la caracterización de las fronteras (CIM a PIM, PIM a PSM y PSM a IM) a través de las características de los distintos diagramas utilizados en cada uno de los modelos, para diferenciar las características distintivas entre cada frontera.
Todo esto con el fin de tener las características de cada modelo para diferenciarlos uno de
otro y así guiarse para transformar un modelo (Ej. PSM) a otro modelo (Ej. IM), es decir, cuando un modelo cruza una frontera, para convertirse en otro modelo de diferente nivel de abstracción (más detallado). 5.1 XMI para los diagramas seleccionados de UML Una vez obtenido el conjunto mínimo de diagramas de UML 2.0 a utilizar dentro de cada uno de los modelos de MDA en el AGDE y la manera en que sus elementos se representarán, cuyo proceso de determinación se presentó en el capítulo 4 (§ 4.3), es necesario tener una representación interna que contenga la información adecuada a dichos diagramas, ya que estos diagramas utilizados en el proceso de desarrollo de software requerirán ser transformados a través de los diferentes modelos (CIM, PIM, PSM) de MDA. Por esta razón, se propone utilizar un subconjunto de XMI (XML Metadata Interchange) para la representación interna, ya que XMI permite el intercambio fácil de información y de meta-datos entre diferentes tipos de herramientas de software, en especial herramientas de modelado basadas en UML, además XMI resulta de integrar UML, XML y MOF.
Se pretende que la representación interna sea una notación común que facilite la integración de herramientas y la definición normalizada de las fronteras (§ 5.2 y 5.3). Los pasos que se realizaron para obtener la estructura de la representación interna son:
• Debido a que existen diferentes alternativas de etiquetas XMI fue necesario realizar un análisis de etiquetas para los diagramas de UML 2.0 (§ 5.1.1), para seleccionar el tipo de etiqueta a utilizar en los documentos XMI, para posteriormente,
• Desarrollar la representación interna de los diagramas de casos de uso, clases, secuencia y actividad, explicada en la subsección 5.1.2.
5.1.1 Análisis de etiquetas XMI para los diagramas de UML 2.0
Antes de empezar a desarrollar la representación interna (en XMI, § 5.1.2), fue necesario realizar un pequeño análisis de las alternativas que existen de etiquetas (etiqueta uml, etiqueta ownedmember) XMI, para utilizarlas en la representación de los diagramas UML elegidos, a través de XMI. Este análisis se muestra en la Tabla 5-1.
De acuerdo a los trabajos y herramientas revisadas que contienen ejemplos de XMI para representar diagramas UML se obtuvo la Tabla 5-1, donde la mayoría de las versiones tanto para UML y XMI están entre la 2.0 y 2.1. En la columna manejo de la etiqueta “ownedMember” solamente “06-10-06-UML 2.1.1 XMI file” y la herramienta de “Altova Umodel” la utilizan. Los demás trabajos o herramientas utilizan ya sea etiquetas “uml” o
Capítulo 5 Solución propuesta
52
“xmi” dependiendo del contexto a representar, pero en su mayoría son etiquetas “uml”. La terminología “NE”, en la columna versión de UML y en la columna de versión de XMI, significa que no especifica la versión de UML o de XMI que utilizan.
Tabla 5-1. Revisión de XMI
Trabajos / herramientas revisadas
Man
ejo
de
owne
dMem
ber
Año
de
publ
icac
ión
Ver
sión
de
UM
L
Ver
sión
de
X
MI
MANTIS: Definición de un Entorno para la Gestión del Mantenimiento de Software [RUI03]
2003 NE NE
MOF 2.0/XMI Mapping Specification, v2.1 [OBJ05] 2005 1.4, 2.0 2.1 Mastering XMI Java Programming with XMI, XML, and UML [GRO02] 2002 NE 2.0 XMI de UML 1.4 [OMG07] 2001 1.4 1.1 06-10-06-UML 2.1.1 XMI file [OMG07] √ 2006 2.1.1 2.1 XMI: XML Metadata Interchange [XMI01] 2001 NE 1.1 Enterprise Architect 6.5 [ENT06] 2006 2.0 2.1 Altova Umodel 2007 [ALT07] √ 2007 2.0 2.1 Visual Paradigm for UML 6.0 [VIS07] 2007 2.0 2.1
Como conclusión de la información presentada en la Tabla 5-1, se tiene como resultado
que la etiqueta que más se presentó tanto en los trabajos como herramientas fue la etiqueta “uml”, por lo tanto la etiqueta a elegir para desarrollar la representación interna será dicha etiqueta.
Otro aspecto que reafirma dicha elección, es que de acuerdo a la arquitectura conceptual
de cuatro niveles de abstracción de MOF mostrada en la Ilustración 5-1, el trabajo de esta tesis está ubicado entre los niveles M2, M1 y M0, donde se representa el nivel M2 como el metamodelo de UML por medio de etiquetas XML/XMI, al nivel M1 como modelos UML por medio de datos XML/XMI o propiedades de las etiquetas XML/XMI y a nivel M0 los datos que se introducen en los modelos UML y se guardan en las etiquetas XML/XMI. Debido a esto se decidió ocupar los documentos XMI para representar los diagramas UML con etiquetas “uml”, ya que se está trabajando sobre la representación en XMI de los diagramas UML y se dan por hecho los niveles de abstracción que dan soporte a los modelos UML, debido a que en el nivel M0 se representan los datos, a nivel M1 se representan los modelos, a nivel M2 se incluye las descripciones que definen la estructura y semántica de los modelos y por último, a nivel M3 se incluye la descripción de la estructura y semántica del nivel M2.
Capítulo 5 Solución propuesta
53
Ilustración 5-1. Arquitectura de cuatro niveles para metadatos de MOF
5.1.2 Desarrollo de la representación interna (en XMI) Una vez explicado el por qué de XMI y el tipo de etiqueta a utilizar (§ 5.1.1), se procede a explicar la representación interna en XMI de los cuatro diagramas seleccionados (§ 4.3), mostrando primeramente la estructura general de XMI para los diagramas, en la Tabla 5-2. Todas las representaciones internas de los diagramas (documentos XMI) tienen la misma estructura general de XMI, pero contienen diferentes elementos y propiedades. Lo único que cambia en cada diagrama son las etiquetas para la definición de los elementos y propiedades contenidos en la etiqueta “xmi:content”, ya que dependiendo del tipo de diagrama serán sus elementos y propiedades (ver Ilustración 5-2, Ilustración 5-6, Ilustración 5-10 y Ilustración 5-14).
Tabla 5-2. Estructura general de XMI para los 4 diagramas <?xml version="1.0"?> Éste es el encabezado donde se indica la versión de XML
usada en el documento. <!DOCTYPE xmi:XMI SYSTEM "DTDCasosUso.dtd">
Indica que el documento esta regido por un DTD para darle validez al documento XMI.
<xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI">
A partir de este elemento se estructura el resto de elementos. Esta etiqueta contiene la versión de xmi, las referencias a los esquemas uml y xmi.
<XMI.header> Contiene los elementos XML que identifican el modelo. <XMI.model xmi.name="UML" xmi.version="2.0"/> Identifica el modelo del nivel M1, donde los atributos
‘XMI.name’ y ‘XMI.version’ son el nombre y la versión del modelo que es descrito en detalle en el elemento XMI.content.
<XMI.content> Contiene los metadatos, que pueden representar información correspondiente a un modelo (nivel M1) o a un metamodelo (nivel M2). Dentro de esta etiqueta irán los elementos y propiedades correspondientes a cada diagrama.
<uml:Package xmi:id=” “ name=” “>
Indica el tipo de paquete y nombre.
Capítulo 5 Solución propuesta
54
Para saber que los documentos XMI a definir para los diagramas fueran bien formados se tuvo que revisar su estructura sintáctica básica, es decir, que cumplieran con todas las definiciones básicas de formato del documento. Además se verificó su validez mediante un DTD (Document Type Definition) para especificar exactamente la relación a verificar entre los distintos elementos presentes en el documento.
Antes de mostrar cada uno de los documentos XMI para cada diagrama con su respectivo
DTD, se explica la estructura general de los DTD´s a continuación. El DTD está conformado por etiquetas ELEMENT y etiquetas ATTLIST, donde las
etiquetas ELEMENT (elemento) inician los bloques primarios de todo documento, dentro de éste se pueden definir más elementos y las etiquetas ATTLIST (atributos) permiten añadir información adicional a los elementos de un documento. Las palabras claves que puede contener un ATTLIST son:
• Un valor por defecto. Por ejemplo, se tiene en la etiqueta ATTLIST el elemento
“mensaje” y tiene como atributo "prioridad" y este atributo puede tener el valor "normal" o "urgente", siendo "normal" el valor por defecto si no se especifica el valor del atributo.
• #REQUIRED. Significa que no tiene valor por defecto, ya que es obligatorio especificar este atributo.
• #IMPLIED. Significa un atributo opcional.
Los tipos de atributos que estan presentes en el DTD son:
• CDATA.-Los atributos CDATA (Character DATA) son los más sencillos, y pueden contener casi cualquier cosa.
• ID e IDREF.- El tipo ID permite que un tipo determinado tenga un nombre único que podrá ser referenciado por un atributo de otro elemento que sea de tipo IDREF.
• ANY.- Puede tener cualquier contenido. • EMPTY: el elemento no tiene contenido. • El símbolo “+” significa que el elemento aparece una o más veces. • El símbolo “*” significa que el elemento es opcional y puede aparecer cualquier
número de veces. • El símbolo “¿” significa que el elemento es opcional y puede aparecer una sola vez. • El elemento aparece sólo una vez cuando no tiene ninguno de los símbolos
anteriores. Una vez explicado tanto la estructura general del documento XMI como de su
correspondiente DTD, se procede a presentar la representación interna y DTD’s de cada uno de los diagramas seleccionados que se muestran en la Ilustración 5-2, Ilustración 5-3, Ilustración 5-6, Ilustración 5-7, Ilustración 5-10, Ilustración 5-11, Ilustración 5-14 y Ilustración 5-15, donde cada una de las ilustraciones son documentos formateados con dos columnas, donde la segunda columna es continuación de la primera columna.
Capítulo 5 Solución propuesta
55
Todos los documentos XMI de cada diagrama presentados en dichas ilustraciones tienen asociadas pruebas con respecto a si el documento es bien formado y si es válido, las cuales se presentan en la Ilustración 5-4, Ilustración 5-5, Ilustración 5-8, Ilustración 5-9, Ilustración 5-12, Ilustración 5-13, Ilustración 5-16 y Ilustración 5-17. Donde la prueba de documento bien formado, consiste en verificar que el documento este bien estructurado, es decir, que su sintaxis esté bien, y la prueba de documento válido consiste en verificar tanto la sintaxis como la semántica del documento por medio de un DTD, lo cual se realiza mediante los elementos y atributos especificados en el DTD. Ambas pruebas mostradas en cada una de las ilustraciones, se realizaron a través de la herramienta Stylus Studio17 2007 [STY07], la cual contiene opciones para verificarlas.
En la Ilustración 5-2 se presenta el documento XMI para el diagrama de casos de uso, en el
cual se incluye en la etiqueta “xmi:content” las etiquetas correspondientes a los elementos y propiedades de dicho diagrama.
Los elementos a incluir se presentan en la Tabla 5-3, la cual representa la correspondencia
de los elementos del diagrama de casos de uso con respecto a su representación en el documento XMI.
En dicha tabla la primera columna muestra los elementos del diagrama de casos de uso y la
segunda columna muestra la correspondencia de dichos elementos con las etiquetas del documento XMI para diagramas de casos de uso (Ej. el elemento “Actor” corresponde a la etiqueta “uml:Actor” en el documento XMI).
Tabla 5-3. Correspondencia de los elementos del diagrama de casos de uso con su representación interna en el
documento XMI Elementos del diagrama
de casos de uso Correspondencia en el documento XMI
Actor uml:Actor
Caso de uso uml:UseCase
Punto de extensión uml:ExtensionPoint
Subject uml:Subject
Uso
Generalización
Incluye
Extend
Se encuentran en la etiqueta uml:Association en la propiedad type como: Use Generalize Include Extend
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDCasosUso.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/>
ExtensionPoint="" subject=""> <Association xmi:idref=""/> <Association xmi:idref=""/> </uml:ExtensionPoint> <uml:Subject xmi:id="" name=""> <Association xmi:idref=""/> <Association xmi:idref=""/>
17 Es un entorno de desarrollo interactivo (IDE, Interactive Development Environment) para trabajar con XML y las tecnologías relacionadas con XSLT, XQuery, XML Schema, SQL/XML, WSDL, SOAP, y otras.
Capítulo 5 Solución propuesta
56
</XMI.header> <XMI.content> <uml:Package xmi:id="CasosUso" name="CasosUso"> <uml:Actor xmi:id="" name="" subject=""> <Association xmi:idref=""/> </uml:Actor> <uml:UseCase xmi:id="" name="" subject=""> <Association xmi:idref=""/> <Association xmi:idref=""/> </uml:UseCase> <uml:ExtensionPoint xmi:id="" name=""
</uml:Subject> <uml:Association xmi:id="" name="" subject="" type="Include"> <Source xmi:idref=""/> <Target xmi:idref=""/> </uml:Association> <uml:Comment xmi:id="" name="Note" value=""/> </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 5-2. Documento XMI para el diagrama de casos de uso
Para explicar la Ilustración 5-2 en relación con la Tabla 5-3, se presenta el siguiente
ejemplo: El elemento “Actor” de la Tabla 5-3, se representa de la siguiente manera en la Ilustración
5-2, la etiqueta para este elemento es “uml:Actor” que contiene un atributo “xmi:id”, que es el identificador de la etiqueta, así como contiene un atributo “name” que se refiere al nombre del actor y el atributo “subject” que significa que dicha etiqueta está contenida en la etiqueta “uml:subject”.
Por otro lado la etiqueta “uml:Actor”, contiene otra etiqueta denominada “Association”,
la cual tiene asociado un atributo “xmi:idref”, que contiene la referencia hacia la etiqueta “uml:Association”, en donde se encuentra el “xmi:id” de la etiqueta, con la cual se relaciona la etiqueta “uml:Actor”, esto se representa por medio de las etiquetas “Source” (etiqueta origen) y “Target” (etiqueta destino) en sus atributos “xmi:idref” contenidas dentro de la etiqueta “uml:Association”.
Al igual que la etiqueta “uml:Actor” la etiqueta “uml:Association” tienen los atributos de
“xmi:id” y de “name”, pero además esta etiqueta tiene el atributo de “type” que representa a los tipos de conectores (“use”, “generalize”, “extend” y “incluye”) que existen en los diagramas de casos de uso para unir a sus elementos (en este caso a las etiquetas “Source” y “Target”).
Para los demás elementos del diagrama de casos de uso se representan de manera
semejante lo que varía son sus atributos y/o etiquetas que pueden contener. En la Ilustración 5-3 se presenta el DTD para dar validez al documento XMI para el
diagrama de casos de uso. En el DTD están los tipos de elementos y sus atributos, así como las relaciones entre ellos, recordando que dichos elementos y sus relaciones se presentaron en la Tabla 4-7 (§ 4.3.3).
<?xml version="1.0" encoding="UTF-16LE"?> <!ELEMENT XMI.model EMPTY> <!ATTLIST XMI.model xmi.name CDATA #REQUIRED xmi.version CDATA #REQUIRED> <!ELEMENT XMI.header (XMI.model)> <!ELEMENT Association ANY> <!ATTLIST Association xmi:idref CDATA #REQUIRED> <!ELEMENT uml:Actor ((Association)*)>
name CDATA #REQUIRED> <!ELEMENT Source EMPTY> <!ATTLIST Source xmi:idref CDATA #REQUIRED> <!ELEMENT Target EMPTY> <!ATTLIST Target xmi:idref CDATA #REQUIRED> <!ELEMENT uml:Association (Source,Target)> <!ATTLIST uml:Association xmi:id CDATA #REQUIRED name CDATA #REQUIRED subject CDATA #IMPLIED
Capítulo 5 Solución propuesta
57
<!ATTLIST uml:Actor xmi:id CDATA #REQUIRED name CDATA #REQUIRED subject CDATA #IMPLIED> <!ELEMENT uml:UseCase ((Association)*)> <!ATTLIST uml:UseCase xmi:id CDATA #REQUIRED name CDATA #REQUIRED subject CDATA #IMPLIED> <!ELEMENT uml:ExtensionPoint ((Association)*)> <!ATTLIST uml:ExtensionPoint xmi:id CDATA #REQUIRED name CDATA #REQUIRED ExtensionPoint CDATA #REQUIRED subject CDATA #IMPLIED> <!ELEMENT uml:Subject ((Association)*)> <!ATTLIST uml:Subject xmi:id CDATA #REQUIRED
type (Extend|Include|Use|Generalize) #REQUIRED> <!ELEMENT uml:Comment EMPTY> <!ATTLIST uml:Comment xmi:id CDATA #REQUIRED name (Note|Other) #REQUIRED value CDATA #REQUIRED> <!ELEMENT uml:Package ((uml:Actor)+,(uml:UseCase)+,(uml:ExtensionPoint)*,(uml:Subject)*,(uml:Association)*,(uml:Comment)*)> <!ATTLIST uml:Package xmi:id CDATA #REQUIRED name CDATA #REQUIRED> <!ELEMENT XMI.content (uml:Package)> <!ELEMENT xmi:XMI (XMI.header,XMI.content)> <!ATTLIST xmi:XMI xmi:version CDATA #REQUIRED xmlns:uml CDATA #REQUIRED xmlns:xmi CDATA #REQUIRED>
Ilustración 5-3. DTD para el documento XMI del diagrama de casos de uso
Para explicar la relación de la Ilustración 5-3 y la Ilustración 5-2, se presenta a
continuación el siguiente ejemplo: Retomando el ejemplo del elemento “Actor” presentado anteriormente con respecto a la
etiqueta “uml:Actor”, se tiene que el DTD para el documento XMI del diagrama de casos de uso que lo representa es “ELEMENT uml:Actor” que tiene asociado como forma opcional al elemento “Association” que puede aparecer cualquier número de veces en dicha etiqueta y los atributos de la etiqueta “uml:Actor”, se representan por medio de la etiqueta “ATTLIST uml:Actor” que tiene los atributos “xmi:id” y “name”, como atributos requeridos y al atributo “subject”, como atributo opcional.
Para los demás elementos del diagrama de casos de uso se representan de manera
semejante lo que varía son sus atributos y/o etiquetas que pueden contener. A continuación se muestra de forma ilustrativa la correspondencia de la etiqueta
“uml:Actor” con la parte del DTD que le corresponde.
Documento XMI DTD <uml:Actor xmi:id="" name="" subject=""> <Association xmi:idref=""/> </uml:Actor>
<!ELEMENT uml:Actor ((Association)*)> <!ATTLIST uml:Actor xmi:id CDATA #REQUIRED name CDATA #REQUIRED subject CDATA #IMPLIED>
A continuación en la Ilustración 5-4 y la Ilustración 5-5 se muestran las pruebas del
documento bien formado y de documento válido del documento XMI del diagrama de casos de uso presentado en la Ilustración 5-2.
En dichas ilustraciones se muestra que ambas pruebas resultaron correctas, debido a que en
la parte inferior de las ilustraciones se presenta el resultado de aplicar la opción de verificar si el documento esta bien formado aparece “The XMI document CasoUso.xml is well formed” y si es verificar que el documento es válido aparece “The XML document CasoUso.xml is valid”, de lo contrario aparecería error en tal parte del documento o si es de validar el documento aparecería “The XML document CasosUso.xml is NOT valid (1 errors)”.
Capítulo 5 Solución propuesta
58
En la parte superior de las ilustraciones aparece el documento XMI al cual se le aplican
dichas pruebas.
Ilustración 5-4. Prueba de documento bien formado para el documento XMI del diagrama de casos de uso
Ilustración 5-5. Prueba de documento válido para el documento XMI del diagrama de casos de uso
Capítulo 5 Solución propuesta
59
En la Ilustración 5-6 se presenta el documento XMI para el diagrama de clases, en el cual se representan dentro de la etiqueta “xmi:content” las etiquetas correspondientes a los elementos y propiedades de dicho diagrama, que se presentan en la Tabla 5-4, mostrando la correspondencia de los elementos del diagrama de clases con respecto a su representación en el documento XMI.
En dicha tabla la primera columna muestra los elementos del diagrama de clases y la
segunda columna muestra la correspondencia de dichos elementos con las etiquetas del documento XMI para diagramas de clases (Ej. el elemento “Interfaz” corresponde a la etiqueta “uml:Interface” en el documento XMI).
Tabla 5-4. Correspondencia de los elementos del diagrama de clases con su representación interna en el
documento XMI Elementos del diagrama de clases Correspondencia en el documento XMI
Clase uml:Class
Interfaz uml:Interface
Asociación
Generalización
Composición Agregación
Dependencia
Realización
Realización de la interfaz Rastro
Anidar
Se encuentran en la etiqueta uml:Association en la propiedad type como: Associate Generalize Compose Agregate Dependency Realize InterfaceRealization Trace Nesting
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDClases.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Class" name="Class"> <uml:Class xmi:id="" name="" isAbstract="false" Visibility="Public" isDerived="false" isRoot="false" Template="" Stereotype=""> <uml:Attribute xmi:id="" type="" name="" visibility="Public" Stereotype=""> </uml:Attribute> <uml:Operation xmi:id="" type="" name="" visibility="Protected" Stereotype=""> <uml:Parameter xmi:id="" type="" name=""> </uml:Parameter>
</uml:Operation> <Association xmi:idref="" /> <Association xmi:idref=""/> </uml:Class> <uml:Interface xmi:id="" name="" isAbstract="false" isDerived="false" isRoot="true" Visibility="Private" Stereotype=""> <Association xmi:idref="" /> <Association xmi:idref=""/> </uml:Interface> <uml:Association xmi:id="" name="" Direction="Unspecified" type="Dependency"> <Source xmi:idref=""/> <Target xmi:idref=""/> <Multiplicity lower="" upper=""/> </uml:Association> <uml:Comment xmi:id="" name="Note" value=""/> </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 5-6. Documento XMI para el diagrama de clases
Para explicar la Ilustración 5-6 en relación con la Tabla 5-4, se presenta el siguiente
ejemplo:
Capítulo 5 Solución propuesta
60
El elemento “Interfaz” de la Tabla 5-4, se representa de la siguiente manera en la Ilustración 5-6, la etiqueta para este elemento es “uml:Interface” que contiene un atributo “xmi:id”, que es el identificador de la etiqueta, así como contiene un atributo “name” que se refiere al nombre de la interfaz, además contiene atributos que indican si es abstracta, derivada, si es raíz y el tipo de visibilidad que tiene, además si tiene algún estereotipo.
Por otro lado la etiqueta “uml:Interface”, contiene otra etiqueta denominada
“Association”, la cual tiene asociado un atributo “xmi:idref”, que contiene la referencia hacia la etiqueta “uml:Association”, en donde se encuentra el “xmi:id” de la etiqueta, con la cual se relaciona la etiqueta “uml:Interface”, esto se representa por medio de las etiquetas “Source” (etiqueta origen) y “Target” (etiqueta destino) en sus atributos “xmi:idref” contenidas dentro de la etiqueta “uml:Association”, esta etiqueta también contiene a la etiqueta “Multiplicity”, que representa el tipo de multiplicidad.
Al igual que la etiqueta “uml:Interface” la etiqueta “uml:Association” tienen los atributos
de “xmi:id” y de “name”, pero además esta etiqueta tiene el atributo de “type” que representa a los tipos de conectores (“Associate”, “Generalize”, “Compose”, “Agregate”, “Dependency”, “Realice”, “InterfaceRealization”, “Trace” y “Nesting”) que existen en los diagramas de clases para unir a sus elementos (en este caso a las etiquetas “Source” y “Target”).
Para los demás elementos del diagrama de clases se representan de manera semejante lo
que varía son sus atributos y/o etiquetas que pueden contener.
En la Ilustración 5-7 se presenta el DTD para dar validez al documento XMI para el diagrama de clases. En el DTD están los tipos de elementos y sus atributos, así como las relaciones entre ellos, recordando que dichos elementos y sus relaciones se presentaron en la Tabla 4-8 (§ 4.3.3).
<?xml version="1.0" encoding="UTF-16LE"?> <!ELEMENT XMI.model EMPTY> <!ATTLIST XMI.model xmi.name CDATA #REQUIRED xmi.version CDATA #REQUIRED> <!ELEMENT XMI.header (XMI.model)> <!ELEMENT uml:Attribute ANY> <!ATTLIST uml:Attribute xmi:id CDATA #REQUIRED type CDATA #REQUIRED name CDATA #REQUIRED visibility (packageLocal|Public|Private|Protected) #REQUIRED Stereotype CDATA #IMPLIED> <!ELEMENT uml:Parameter ANY> <!ATTLIST uml:Parameter xmi:id CDATA #REQUIRED type CDATA #REQUIRED name CDATA #REQUIRED> <!ELEMENT uml:Operation ((uml:Parameter)*)> <!ATTLIST uml:Operation xmi:id CDATA #REQUIRED type CDATA #REQUIRED name CDATA #REQUIRED visibility (Public|Private|Protected) #REQUIRED Stereotype CDATA #IMPLIED> <!ELEMENT Association ANY> <!ATTLIST Association
xmi:id CDATA #REQUIRED name CDATA #REQUIRED isAbstract (true|false) #REQUIRED isDerived (true|false) #REQUIRED isRoot (true|false) #REQUIRED Visibility (Public|Private|Protected) #REQUIRED Stereotype CDATA #IMPLIED> <!ELEMENT Source EMPTY> <!ATTLIST Source xmi:idref CDATA #REQUIRED> <!ELEMENT Target EMPTY> <!ATTLIST Target xmi:idref CDATA #REQUIRED> <!ELEMENT Multiplicity EMPTY> <!ATTLIST Multiplicity lower CDATA #REQUIRED upper CDATA #REQUIRED> <!ELEMENT uml:Association (Source,Target,(Multiplicity)*)> <!ATTLIST uml:Association xmi:id CDATA #REQUIRED name CDATA #REQUIRED Direction (Unspecified|Bi-directional|Source-Destination|Destination-Source) #REQUIRED type (Associate|AssociationClass|Generalize|Compose|Agregate|Dependency|Realize|Trace|Nesting|InterfaceRealization|Link) #REQUIRED> <!ELEMENT uml:Comment EMPTY> <!ATTLIST uml:Comment xmi:id CDATA #REQUIRED
Capítulo 5 Solución propuesta
61
xmi:idref CDATA #REQUIRED> <!ELEMENT uml:Class ((uml:Attribute)*,(uml:Operation)*,(Association)*)> <!ATTLIST uml:Class xmi:id CDATA #REQUIRED name CDATA #REQUIRED isAbstract (true|false) #REQUIRED isDerived (true|false) #REQUIRED isRoot (true|false) #REQUIRED Visibility (Public|Private|Protected) #REQUIRED Template CDATA #IMPLIED Stereotype CDATA #IMPLIED> <!ELEMENT uml:Interface ((Association)*)> <!ATTLIST uml:Interface
name (Note|Other) #REQUIRED value CDATA #REQUIRED> <!ELEMENT uml:Package ((uml:Class)+,(uml:Interface)*,(uml:Association)*,(uml:Comment)*)> <!ATTLIST uml:Package xmi:id CDATA #REQUIRED name CDATA #REQUIRED> <!ELEMENT XMI.content (uml:Package)> <!ELEMENT xmi:XMI (XMI.header,XMI.content)> <!ATTLIST xmi:XMI xmi:version CDATA #REQUIRED xmlns:uml CDATA #REQUIRED xmlns:xmi CDATA #REQUIRED>
Ilustración 5-7. DTD para el documento XMI del diagrama de clases
Para explicar la relación de la Ilustración 5-7 y la Ilustración 5-6, se presenta a
continuación el siguiente ejemplo: Retomando el ejemplo del elemento “Interfaz” presentado anteriormente con respecto a la
etiqueta “uml:Interface”, se tiene que el DTD para el documento XMI del diagrama de clases que lo representa es “ELEMENT uml:Interface” que tiene asociado como forma opcional al elemento “Association” que puede aparecer cualquier número de veces en dicha etiqueta y los atributos de la etiqueta “uml:Interface”, se representan por medio de la etiqueta “ATTLIST uml:Interface” que tiene atributos “xmi:id” y “name”, como atributos requeridos y atributos como “isAbtract”, “isDerived”, “isRoot”, “Visibility”, que son también atributos requeridos pero que tienen valores ya establecidos, por último el atributo “Stereotype”, es un atributo opcional.
Para los demás elementos del diagrama de clases se representan de manera semejante lo
que varía son sus atributos y/o etiquetas que pueden contener. A continuación se muestra de forma ilustrativa la correspondencia de la etiqueta “uml:
Interface” con la parte del DTD que le corresponde.
Documento XMI DTD <uml:Interface xmi:id="" name="" isAbstract="false" isDerived="false" isRoot="true" Visibility="Private" Stereotype=""> <Association xmi:idref="" /> </uml:Interface>
<!ELEMENT uml:Interface ((Association)*)> <!ATTLIST uml:Interface xmi:id CDATA #REQUIRED name CDATA #REQUIRED isAbstract (true|false) #REQUIRED isDerived (true|false) #REQUIRED isRoot (true|false) #REQUIRED Visibility (Public|Private|Protected) #REQUIRED Stereotype CDATA #IMPLIED>
A continuación en la Ilustración 5-8 y la Ilustración 5-9 se muestran las pruebas de
documento bien formado y de documento válido del documento XMI del diagrama de clases presentado en la Ilustración 5-6.
En dichas ilustraciones se muestra que ambas pruebas resultaron correctas, debido a que en
la parte inferior de las ilustraciones se presenta el resultado de aplicar la opción de verificar si el documento esta bien formado aparece “The XMI document Clases.xml is well formed” y si es verificar que el documento es válido aparece “The XML document Clases.xml is valid”, de
Capítulo 5 Solución propuesta
62
lo contrario aparecería error en tal parte del documento o si es de validar el documento aparecería “The XML document Clases.xml is NOT valid (1 errors)”.
En la parte superior de las ilustraciones aparece el documento XMI al cual se le aplican
dichas pruebas.
Ilustración 5-8. Prueba de documento bien formado para el documento XMI del diagrama de clases
Ilustración 5-9. Prueba de documento válido para el documento XMI del diagrama de clases
Capítulo 5 Solución propuesta
63
En la Ilustración 5-10 se presenta el documento XMI para el diagrama de secuencia, en el cual se representan dentro de la etiqueta “xmi:content” las etiquetas correspondientes a los elementos y propiedades de dicho diagrama, donde dichos elementos se presentan en la Tabla 5-5, la cual representa la correspondencia de los elementos del diagrama de secuencia con respecto a su representación en el documento XMI.
En dicha tabla la primera columna muestra los elementos del diagrama de secuencia y la
segunda columna muestra la correspondencia de dichos elementos con las etiquetas del documento XMI para diagramas de secuencia (Ej. el elemento “Marco” corresponde a la etiqueta “uml:Frame” en el documento XMI).
Tabla 5-5. Correspondencia de los elementos del diagrama de secuencia con su representación interna en el documento XMI
Elementos del diagrama de secuencia Correspondencia en el documento XMI
Actor
Línea de vida
Límite
Control
Entidad
Se encuentran en la etiqueta uml:Lifeline en la propiedad type como: Actor Lifeline Boundary Control Entity
Coregion
Restricciones de duración, Duración, Observación
Restricciones de tiempo, Observaciones de tiempo
Se encuentran en la etiqueta uml:Lifeline en la parte de etiquetas internas de él se encuentran Coregion DurationConstraint TimeConstraint TimeObservation Por otro lado en la etiqueta uml:Association también se encuentran: DurationObservation DurationConstraint
Fragmento combinado uml:CombinedFragment
Marco
uml:Frame
Gate uml:Gate
Empleo de interacción uml:InteractionUse
Estado Invariante / Continuaciones Se encuentran en la etiqueta uml: InteractionState en la propiedad type como: StateInvariant Continuation
Capítulo 5 Solución propuesta
64
Stop Se encuentra en la etiqueta uml:Lifeline en la propiedad stop
Mensaje
Self- Message
Mensaje perdido, mensaje encontrado Ordenamiento general
Se encuentran en la etiqueta uml:Association en la propiedad type como: Message Self-Message Lost-Message Found-Message GeneralOrdering
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDSecuencia.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Sequence" name="Sequence"> <uml:Lifeline xmi:id="" name="" stop="" type="Lifeline" covered="" frame=""> <Coregion xmi:id="" name=""> <Association xmi:idref=""/> </Coregion> <DurationConstraint xmi:id=""> <Segment> <Start xmi:idref=""/> <End xmi:idref=""/> </Segment> </DurationConstraint> <TimeConstraint xmi:id="" name="" association=""/> <TimeObservation xmi:id="" name="" association=""/> <Association xmi:idref=""/> </uml:Lifeline> <uml:InteractiveUse xmi:id="" interaction="" name="" association="" frame=""> <Association xmi:idref=""/> </uml:InteractiveUse> <uml:CombinedFragment xmi:id="" interaction="" name="" type="alt" association="" frame="">
<Interaction xmi:id="" name="" association=""/> <InternalStructure xmi:id="" name="" association=""/> <Condition xmi:id="" name="" association=""/> <Association xmi:idref=""/> </uml:CombinedFragment> <uml:Gate xmi:id="" name="" frame=""> <Association xmi:idref=""/> </uml:Gate> <uml:InteractionState xmi:id="" name="" association="" frame=""> <Condition xmi:id="" name="" association=""/> <Type name=""/> </uml:InteractionState> <uml:EndPoint xmi:id="" name="" association="" frame=""> </uml:EndPoint> <uml:Frame xmi:id="" name=""> <Association xmi:idref=""/> </uml:Frame> <uml:Association xmi:id="" frame="" type="Lost-Message"> <Source xmi:idref=""/> <Target xmi:idref=""/> <Message name="" kind="Call"> <Parameter name="" type=""/> </Message> </uml:Association> <uml:Comment xmi:id="" name="Note" value=""/> </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 5-10. Documento XMI para el diagrama de secuencia
Para explicar la Ilustración 5-10 en relación con la Tabla 5-5, se presenta el siguiente
ejemplo: El elemento “Marco” de la Tabla 5-5, se representa de la siguiente manera en la
Ilustración 5-10, la etiqueta para este elemento es “uml:Frame” que contiene un atributo “xmi:id”, que es el identificador de la etiqueta, así como contiene un atributo “name” que se refiere al nombre del marco.
Por otro lado la etiqueta “uml:Frame”, contiene otra etiqueta denominada “Association”,
la cual tiene asociado un atributo “xmi:idref”, que contiene la referencia hacia la etiqueta “uml:Association”, en donde se encuentra el “xmi:id” de la etiqueta, con la cual se relaciona la etiqueta “uml:Frame”, esto se representa por medio de las etiquetas “Source” (etiqueta origen) y “Target” (etiqueta destino) en sus atributos “xmi:idref” contenidas dentro de la etiqueta “uml:Association”.
Capítulo 5 Solución propuesta
65
Al igual que la etiqueta “uml:Frame” la etiqueta “uml:Association” tienen los atributos de “xmi:id” y de “name”, pero además esta etiqueta tiene el atributo de “type” que representa a los tipos de conectores que existen en los diagramas de secuencia para unir a sus elementos (en este caso a las etiquetas “Source” y “Target”). Para los demás elementos del diagrama de secuencia se representan de manera semejante lo que varía son sus atributos y/o etiquetas que pueden contener.
En la Ilustración 5-11 se presenta el DTD para dar validez al documento XMI para el
diagrama de secuencia. En el DTD están los tipos de elementos y sus atributos, así como las relaciones entre ellos, recordando que dichos elementos y sus relaciones se presentaron en la Tabla 4-9 (§ 4.3.3).
<?xml version="1.0" encoding="UTF-16LE"?> <!ELEMENT XMI.model EMPTY> <!ATTLIST XMI.model xmi.name CDATA #REQUIRED xmi.version CDATA #REQUIRED> <!ELEMENT XMI.header (XMI.model)> <!ELEMENT Coregion ((Association)*)> <!ATTLIST Coregion xmi:id CDATA #REQUIRED name CDATA #IMPLIED> <!ELEMENT Start EMPTY> <!ATTLIST Start xmi:idref CDATA #REQUIRED> <!ELEMENT End EMPTY> <!ATTLIST End xmi:idref CDATA #REQUIRED> <!ELEMENT Segment (Start,End)> <!ELEMENT DurationConstraint (Segment)> <!ATTLIST DurationConstraint xmi:id CDATA #REQUIRED> <!ELEMENT TimeConstraint EMPTY> <!ATTLIST TimeConstraint xmi:id CDATA #REQUIRED name CDATA #REQUIRED association CDATA #IMPLIED> <!ELEMENT TimeObservation EMPTY> <!ATTLIST TimeObservation xmi:id CDATA #REQUIRED name CDATA #REQUIRED association CDATA #IMPLIED> <!ELEMENT uml:Lifeline ((Coregion)*,(DurationConstraint)*,(TimeConstraint)*, (TimeObservation)*,(Association)*)> <!ATTLIST uml:Lifeline xmi:id CDATA #REQUIRED name CDATA #REQUIRED type (Actor|Boundary|Control|Entity|Lifeline) #REQUIRED stop CDATA #IMPLIED covered CDATA #IMPLIED frame CDATA #IMPLIED> <!ELEMENT uml:InteractiveUse ((Association)*)> <!ATTLIST uml:InteractiveUse xmi:id CDATA #REQUIRED interaction CDATA #REQUIRED name CDATA #REQUIRED association CDATA #IMPLIED frame CDATA #IMPLIED> <!ELEMENT Interaction EMPTY> <!ATTLIST Interaction xmi:id CDATA #REQUIRED name CDATA #IMPLIED association CDATA #IMPLIED> <!ELEMENT InternalStructure EMPTY> <!ATTLIST InternalStructure xmi:id CDATA #REQUIRED
name CDATA #REQUIRED frame CDATA #IMPLIED> <!ELEMENT Condition ((Association)*)> <!ATTLIST Condition xmi:id CDATA #REQUIRED name CDATA #REQUIRED association CDATA #IMPLIED> <!ELEMENT Type EMPTY> <!ATTLIST Type name (StateInvariant | Continuation) #REQUIRED><!ELEMENT uml:InteractionState (Condition,Type)> <!ATTLIST uml:InteractionState xmi:id CDATA #REQUIRED name CDATA #REQUIRED association CDATA #IMPLIED frame CDATA #IMPLIED> <!ELEMENT uml:EndPoint ANY> <!ATTLIST uml:EndPoint xmi:id CDATA #REQUIRED name CDATA #REQUIRED association CDATA #IMPLIED frame CDATA #IMPLIED> <!ELEMENT Association EMPTY> <!ATTLIST Association xmi:idref CDATA #REQUIRED> <!ELEMENT uml:Frame ((Association)*)> <!ATTLIST uml:Frame xmi:id CDATA #REQUIRED name CDATA #REQUIRED> <!ELEMENT Source EMPTY> <!ATTLIST Source xmi:idref CDATA #REQUIRED> <!ELEMENT Target EMPTY> <!ATTLIST Target xmi:idref CDATA #REQUIRED> <!ELEMENT Parameter EMPTY> <!ATTLIST Parameter name CDATA #REQUIRED type CDATA #REQUIRED> <!ELEMENT Message ((Parameter)*)> <!ATTLIST Message name CDATA #REQUIRED kind (Asynchronous|Call|Signal|Return) #REQUIRED> <!ELEMENT uml:Association (Source,Target,Message)> <!ATTLIST uml:Association xmi:id CDATA #REQUIRED frame CDATA #IMPLIED type (Message|DurationObservation|DurationConstraint|Self-Message|General Ordering|Lost-Message|Found-Message) #REQUIRED association CDATA #IMPLIED> <!ELEMENT uml:Comment EMPTY> <!ATTLIST uml:Comment xmi:id CDATA #REQUIRED name (Note|Other) #REQUIRED value CDATA #REQUIRED>
Capítulo 5 Solución propuesta
66
name CDATA #IMPLIED association CDATA #IMPLIED> <!ELEMENT uml:CombinedFragment ((Interaction)*,(InternalStructure)*,(Condition)+,(Association)*)> <!ATTLIST uml:CombinedFragment xmi:id CDATA #REQUIRED interaction CDATA #IMPLIED name CDATA #REQUIRED type (alt|loop|opt) #REQUIRED association CDATA #IMPLIED frame CDATA #IMPLIED> <!ELEMENT uml:Gate ((Association)*)> <!ATTLIST uml:Gate xmi:id CDATA #REQUIRED
<!ELEMENT uml:Package ((uml:Lifeline)+,(uml:InteractiveUse)*,(uml:CombinedFragment)*, (uml:Gate)*, (uml:InteractionState)*,(uml:EndPoint)*,(uml:Frame)*, (uml:Association)*, (uml:Comment)*)> <!ATTLIST uml:Package xmi:id CDATA #REQUIRED name CDATA #REQUIRED> <!ELEMENT XMI.content (uml:Package)> <!ELEMENT xmi:XMI (XMI.header,XMI.content)> <!ATTLIST xmi:XMI xmi:version CDATA #REQUIRED xmlns:uml CDATA #REQUIRED xmlns:xmi CDATA #REQUIRED>
Ilustración 5-11. DTD para el documento XMI del diagrama de secuencia
Para explicar la relación de la Ilustración 5-11 y la Ilustración 5-10, se presenta a
continuación el siguiente ejemplo: Retomando el ejemplo del elemento “Marco” presentado anteriormente con respecto a la
etiqueta “uml:Frame”, se tiene que el DTD para el documento XMI del diagrama de secuencia que lo representa es “ELEMENT uml:Frame” que tiene asociado como forma opcional al elemento “Association” que puede aparecer cualquier número de veces en dicha etiqueta y los atributos de la etiqueta “uml:Frame”, se representan por medio de la etiqueta “ATTLIST uml:Frame” que tiene atributos “xmi:id” y “name”, como atributos requeridos.
Para los demás elementos del diagrama de secuencia se representan de manera semejante
lo que varía son sus atributos y/o etiquetas que pueden contener. A continuación se muestra de forma ilustrativa la correspondencia de la etiqueta
“uml:Frame” con la parte del DTD que le corresponde.
Documento XMI DTD <uml:Frame xmi:id="" name=""> <Association xmi:idref=""/> </uml:Frame>
<!ELEMENT uml:Frame ((Association)*)> <!ATTLIST uml:Frame xmi:id CDATA #REQUIRED name CDATA #REQUIRED>
A continuación en la Ilustración 5-12 y la Ilustración 5-13 se muestran las pruebas de
documento bien formado y de documento válido del documento XMI del diagrama de secuencia presentado en la Ilustración 5-10.
En dichas ilustraciones se muestra que ambas pruebas resultaron correctas, debido a que en
la parte inferior de las ilustraciones se presenta el resultado de aplicar la opción de verificar si el documento esta bien formado aparece “The XMI document Secuencia.xml is well formed” y si es verificar que el documento es válido aparece “The XML document Secuencia.xml is valid”, de lo contrario aparecería error en tal parte del documento o si es de validar el documento aparecería “The XML document Secuencia.xml is NOT valid (1 errors)”.
En la parte superior de las ilustraciones aparece el documento XMI al cual se le aplican
dichas pruebas.
Capítulo 5 Solución propuesta
67
Ilustración 5-12. Prueba de documento bien formado para el documento XMI del diagrama de secuencia
Ilustración 5-13. Prueba de documento válido para el documento XMI del diagrama de secuencia
En la Ilustración 5-14 se presenta el documento XMI para el diagrama de actividad, en el
cual se representan dentro de la etiqueta “xmi:content” las etiquetas correspondientes a los elementos y propiedades de dicho diagrama, los elementos se presentan en la Tabla 5-6, la cual representa la correspondencia de los elementos del diagrama de actividad con respecto a su representación en el documento XMI.
Capítulo 5 Solución propuesta
68
En dicha tabla la primera columna muestra los elementos del diagrama de actividad y la segunda columna muestra la correspondencia de dichos elementos con las etiquetas del documento XMI para diagramas de actividad (Ej. el elemento “Actividad” corresponde a la etiqueta “uml:Activity” en el documento XMI).
Tabla 5-6. Correspondencia de los elementos del diagrama de actividad con su representación interna en el
documento XMI Elementos del diagrama de
actividad Correspondencia en el documento XMI
Actividad uml:Activity
Acción uml:Action
Partición uml:Partition
Nodo de objeto uml:ObjectNode
Almacén de datos uml:DataStore
Nodo de decisión
Nodo merge
Se encuentra en la etiqueta uml:DecisionNode en la propiedad type como: Decisión Merge
Acción de señal enviada uml:SendSignalAction
Acción de evento recibido uml:ReceiveEventAction
Nodo inicial uml:InitialNode
Nodo Final uml:FinalNode
Flujo final uml:FlowFinal
Región uml:Region
Excepción uml:Exception
Nodo de bifurcación uml:ForkNode
Nodo de unión uml:JoinNode
Flujo de control
Flujo de objeto
Flujo de interrupción
Se encuentran en la etiqueta uml:Association en la propiedad type como: ControlFlow ObjectFlow InterruptFlow
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDActividad.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Activity" name="Activity"> <uml:InitialNode xmi:id="" name="" partition=""> <Association xmi:idref=""/> </uml:InitialNode> <uml:Activity xmi:id="" name="" partition="" region=""> <Association xmi:idref=""/>
<uml:SendSignalAction xmi:id="" name="" partition="" region=""> <Association xmi:idref=""/> </uml:SendSignalAction> <uml:ReceiveEventAction xmi:id="" name="" partition="" region=""> <Association xmi:idref=""/> </uml:ReceiveEventAction> <uml:ForkNode xmi:id="" partition="" region=""> <Association xmi:idref=""/> </uml:ForkNode> <uml:JoinNode xmi:id="" partition="" region=""> <Association xmi:idref=""/> </uml:JoinNode> <uml:FlowFinal xmi:id="" name="" partition="">
Capítulo 5 Solución propuesta
69
</uml:Activity> <uml:Exception xmi:id="" name="" partition="" region=""> <Association xmi:idref=""/> </uml:Exception> <uml:Action xmi:id="" name="" partition="" region=""> <Association xmi:idref=""/> </uml:Action> <uml:ObjectNode xmi:id="" name="" partition="" region=""> <Association xmi:idref=""/> </uml:ObjectNode> <uml:DataStore xmi:id="" name="" partition="" region=""> <Association xmi:idref=""/> </uml:DataStore> <uml:DecisionNode xmi:id="" name="" type="Decision" partition="" region=""> <Association xmi:idref=""/> </uml:DecisionNode>
<Association xmi:idref=""/> </uml:FlowFinal> <uml:FinalNode xmi:id="" name="" partition=""> <Association xmi:idref=""/> </uml:FinalNode> <uml:Partition xmi:id="" name="" region=""> <Association xmi:idref=""/> </uml:Partition> <uml:Region xmi:id="" name="" partition=""> <Association xmi:idref=""/> </uml:Region> <uml:Association xmi:id="" name="" type="ObjectFlow" partition="" region=""> <Source xmi:idref=""/> <Target xmi:idref=""/> </uml:Association> <uml:Comment xmi:id="" name="Note" value=""/> </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 5-14. Documento XMI para el diagrama de actividad
Para explicar la Ilustración 5-14 en relación con la Tabla 5-6, se presenta el siguiente
ejemplo: El elemento “Actividad” de la Tabla 5-6, se representa de la siguiente manera en la
Ilustración 5-14, la etiqueta para este elemento es “uml:Activity” que contiene un atributo “xmi:id”, que es el identificador de la etiqueta, así como contiene un atributo “name” que se refiere al nombre de la actividad, un atributo “partition” y un atributo “region” que significan que la etiqueta “uml:Activity” se encuentra dentro de alguna de estas etiquetas.
Por otro lado la etiqueta “uml:Activity”, contiene otra etiqueta denominada “Association”,
la cual tiene asociado un atributo “xmi:idref”, que contiene la referencia hacia la etiqueta “uml:Association”, en donde se encuentra el “xmi:id” de la etiqueta, con la cual se relaciona la etiqueta “uml:Activity”, esto se representa por medio de las etiquetas “Source” (etiqueta origen) y “Target” (etiqueta destino) en sus atributos “xmi:idref” contenidas dentro de la etiqueta “uml:Association”.
Al igual que la etiqueta “uml:Activity” la etiqueta “uml:Association” tienen los atributos
de “xmi:id” y de “name”, pero además esta etiqueta tiene el atributo de “type” que representa al tipo de conector que existe en los diagramas de actividad para unir a sus elementos (en este caso a las etiquetas “Source” y “Target”).
Para los demás elementos del diagrama de actividad se representan de manera semejante lo
que varía son sus atributos y/o etiquetas que pueden contener. En la Ilustración 5-15 se presenta el DTD para dar validez al documento XMI para el
diagrama de actividad. En el DTD están los tipos de elementos y sus atributos, así como las relaciones entre ellos, recordando que dichos elementos y sus relaciones se presentaron en la Tabla 4-10 (§ 4.3.3).
Capítulo 5 Solución propuesta
70
<?xml version="1.0" encoding="UTF-16LE"?> <!ELEMENT XMI.model EMPTY> <!ATTLIST XMI.model xmi.name CDATA #REQUIRED xmi.version CDATA #REQUIRED> <!ELEMENT XMI.header (XMI.model)> <!ELEMENT uml:Activity ((Association)*)> <!ATTLIST uml:Activity xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:InitialNode ((Association)*)> <!ATTLIST uml:InitialNode xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED > <!ELEMENT uml:Exception ((Association)*)> <!ATTLIST uml:Exception xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:Action ((Association)*)> <!ATTLIST uml:Action xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:ObjectNode ((Association)*)> <!ATTLIST uml:ObjectNode xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:DataStore ((Association)*)> <!ATTLIST uml:DataStore xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:DecisionNode ((Association)*)> <!ATTLIST uml:DecisionNode xmi:id CDATA #REQUIRED name CDATA #REQUIRED type (Decision|Merge) #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:SendSignalAction ((Association)*)> <!ATTLIST uml:SendSignalAction xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:ReceiveEventAction ((Association)*)> <!ATTLIST uml:ReceiveEventAction xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:ForkNode ((Association)*)> <!ATTLIST uml:ForkNode
xmi:id CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:JoinNode ((Association)*)> <!ATTLIST uml:JoinNode xmi:id CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:FlowFinal ((Association)*)> <!ATTLIST uml:FlowFinal xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED> <!ELEMENT uml:FinalNode ((Association)*)> <!ATTLIST uml:FinalNode xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED > <!ELEMENT uml:Partition ((Association))*> <!ATTLIST uml:Partition xmi:id CDATA #REQUIRED name CDATA #REQUIRED region CDATA #IMPLIED> <!ELEMENT Association EMPTY> <!ATTLIST Association xmi:idref CDATA #REQUIRED> <!ELEMENT uml:Region ((Association)*)> <!ATTLIST uml:Region xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED> <!ELEMENT Source EMPTY> <!ATTLIST Source xmi:idref CDATA #REQUIRED> <!ELEMENT Target EMPTY> <!ATTLIST Target xmi:idref CDATA #REQUIRED> <!ELEMENT uml:Association (Source,Target)> <!ATTLIST uml:Association xmi:id CDATA #REQUIRED name CDATA #REQUIRED type (ControlFlow|ObjectFlow|InterruptFlow) #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED> <!ELEMENT uml:Comment EMPTY> <!ATTLIST uml:Comment xmi:id CDATA #REQUIRED name (Note|Other) #REQUIRED value CDATA #REQUIRED> <!ELEMENT uml:Package ((uml:InitialNode)*,(uml:Activity)*,(uml:Exception)*, (uml:Action)*,(uml:ObjectNode)*,(uml:DataStore)*, (uml:DecisionNode)*, (uml:SendSignalAction)*,(uml:ReceiveEventAction)*, (uml:ForkNode)*, (uml:JoinNode)*,(uml:FlowFinal)*,(uml:FinalNode)*, (uml:Partition)*,(uml:Region)*,(uml:Association)*, (uml:Comment)*)> <!ATTLIST uml:Package xmi:id CDATA #REQUIRED name CDATA #REQUIRED> <!ELEMENT XMI.content (uml:Package)> <!ELEMENT xmi:XMI (XMI.header,XMI.content)> <!ATTLIST xmi:XMI xmi:version CDATA #REQUIRED xmlns:uml CDATA #REQUIRED xmlns:xmi CDATA #REQUIRED>
Ilustración 5-15. DTD para el documento XMI del diagrama de actividad
Capítulo 5 Solución propuesta
71
Para explicar la relación de la Ilustración 5-15 y la Ilustración 5-14, se presenta a continuación el siguiente ejemplo:
Retomando el ejemplo del elemento “Actividad” presentado anteriormente con respecto a
la etiqueta “uml:Activity”, se tiene que el DTD para el documento XMI del diagrama de actividad que lo representa es “ELEMENT uml:Activity” que tiene asociado como forma opcional al elemento “Association” que puede aparecer cualquier número de veces en dicha etiqueta y los atributos de la etiqueta “uml:Activity”, se representan por medio de la etiqueta “ATTLIST uml:Activity” que tiene los atributos “xmi:id” y “name”, como atributos requeridos y a los atributos “partition” y “region”, como atributos opcionales.
Para los demás elementos del diagrama de actividad se representan de manera semejante lo
que varía son sus atributos y/o etiquetas que pueden contener. A continuación se muestra de forma ilustrativa la correspondencia de la etiqueta
“uml:Activity” con la parte del DTD que le corresponde.
Documento XMI DTD <uml:Activity xmi:id="" name="" partition="" region=""> <Association xmi:idref=""/> </uml:Activity>
<!ELEMENT uml:Activity ((Association)*)> <!ATTLIST uml:Activity xmi:id CDATA #REQUIRED name CDATA #REQUIRED partition CDATA #IMPLIED region CDATA #IMPLIED>
A continuación en la Ilustración 5-16 y la Ilustración 5-17 se muestran las pruebas de
documento bien formado y de documento válido del documento XMI del diagrama de actividad presentado en la Ilustración 5-14.
En dichas ilustraciones se muestra que ambas pruebas resultaron correctas, debido a que en
la parte inferior de las ilustraciones se presenta el resultado de aplicar la opción de verificar si el documento esta bien formado aparece “The XMI document Actividad.xml is well formed” y si es verificar que el documento es válido aparece “The XML document Actividad.xml is valid”, de lo contrario aparecería error en tal parte del documento ó si es de validar el documento aparecería “The XML document Actividad.xml is NOT valid (1 errors)”.
En la parte superior de las ilustraciones aparece el documento XMI al cual se le aplican
dichas pruebas.
Capítulo 5 Solución propuesta
72
Ilustración 5-16. Prueba de documento bien formado para el documento XMI del diagrama de actividad
Ilustración 5-17. Prueba de documento válido para el documento XMI del diagrama de actividad
5.2 Definición de los modelos y las fronteras de MDA en el AGDE Antes de iniciar con esta sección, se indica que los ejemplos que se incluyen en cada una de las subsecciones de esta sección corresponden a un sistema de biblioteca, el cual se utilizó en la etapa de demostración descrita en el capítulo 6.
Capítulo 5 Solución propuesta
73
Es importante mencionar que para esta sección se consultaron las referencias [BRU02] y [LAR97] para indagar la forma en que se utilizan los diagramas UML para desarrollar una aplicación.
En la Ilustración 5-18 se presenta el esquema (representación visual) de la definición de los modelos (CIM, PIM, PSM e IM) MDA y de sus fronteras (CIM a PIM, PIM a PSM y PSM a IM). La ilustración muestra cada una de las fronteras mediante una flecha de herencia, pues el modelo PIM esta heredando la información definida en el modelo CIM; el modelo PSM esta heredando la información del modelo PIM y del modelo más abstracto CIM y el modelo IM esta heredando la información del modelo PSM y por consecuencia hereda también información del modelo PIM y del modelo CIM.
A medida que se recorre cada una de las fronteras se realiza una especialización en cada
uno de los modelos, ya que van de lo abstracto a lo específico. Debido a la herencia mostrada en la Ilustración 5-18 todos los modelos funcionales y no funcionales definidos en el modelo CIM se heredan y refinan en cada uno de los demás modelos.
Documentación estructurada
Modelo PSM
Modelo de diseño
Modelo PIM
Modelo de análisis
Modelo de diseño
Modelo IM
Modelo de Implementación
Representación permanente
Frontera CIM-PIM
Frontera PIM-PSM
Frontera PSM-IM
Modelo CIM
Modelo del negocio
Modelo funcional
Modelo no funcional
Modelo de dom
inio
Documentación estructurada
Modelo PSM
Modelo de diseño
Modelo PIM
Modelo de análisis
Modelo de diseño
Modelo IM
Modelo de Implementación
Representación permanente
Frontera CIM-PIM
Frontera PIM-PSM
Frontera PSM-IM
Modelo CIM
Modelo del negocio
Modelo funcional
Modelo no funcional
Modelo de dom
inio
Ilustración 5-18. Representación visual de la definición de los modelos y de las fronteras de los modelos MDA
hasta el modelo de implementación
En la parte derecha de la Ilustración 5-18 aparece “Documentación estructurada” que se
refiere a la documentación de cada una de las fronteras de forma organizada para su mejor
Capítulo 5 Solución propuesta
74
entendimiento y presentación, con el propósito de servir de referencia a los diagramas en el nivel (modelo) que les corresponda. Contiene la información permitida de cada uno de los modelos para cada frontera, es decir, el máximo permitido de detalles para que un diagrama pertenezca a un nivel de abstracción o modelo (Ej. CIM) o el nivel de detalle mínimo para que un modelo cruce la frontera y se considere parte del modelo más detallado. Conforme se pasa a modelos menos abstractos, se añaden elementos y/o características de dichos elementos.
Por otro lado, en la parte izquierda de la ilustración aparece “Representación permanente”
(XML/XMI), que es la representación almacenable en dispositivo magnético de los diagramas UML y que se utiliza como fuente de los elementos a transformar de un diagrama y como destino de las transformaciones realizadas para obtener el diagrama objetivo.
Tanto la “Documentación estructurada” como la “Representación permanente” se utilizan
para procesar los modelos y refinar la información contenida en ellos. Es importante definir exactamente qué es una frontera (entre modelos), para esta
investigación. La frontera entre modelos (uno más abstracto que otro) es la especificación detallada de los elementos y características que puede tener una instancia del modelo más abstracto, pues si se agrega alguna característica de un elemento existente en el modelo, o un nuevo elemento, se convertiría en una instancia del modelo más detallado.
Cada frontera especifica los elementos y características necesarios y suficientes para un
modelo antes de cruzar la frontera correspondiente (CIM a PIM, PIM a PSM, PSM a IM), por ejemplo, una clase a nivel CIM tendría las características de nombre de la clase y algunos de sus atributos, con sus respectivos tipos de dato sin especificar sus rangos; y una clase a nivel PIM contendría las características de nombre de la clase, sus atributos y métodos, además de tener especificadas algunas propiedades como su visibilidad, si utiliza plantillas, el rango de sus atributos y/o métodos etc.
La frontera también es la base a partir de la cual, la agregación de mayor detalle
(refinación) a un modelo, lo transforma al siguiente nivel de detalle menos abstracto, por ejemplo, un diagrama de clases a nivel CIM (representa las clases vistas desde la información relevante del negocio y/o dominio) se transforma a un diagrama de clases a nivel PIM (representa las clases vistas desde una aplicación computacional, sin considerar cuestiones de lenguaje, plataforma o ambiente de desarrollo).
En las secciones siguientes se explicará cada una de las definiciones de los modelos, así
como los diagramas que los conformarán y sus transformaciones, las cuales se realizan, con el propósito de indicar que a partir de un determinado diagrama se obtiene otro, ya sea en el mismo nivel o hacia otro nivel. Además se presentarán las definiciones de cada una de las fronteras a través de los diagramas definidos para cada modelo.
Las transformaciones solamente son vistas como trazabilidad y éstas se mencionan,
debido a que se debe mostrar el origen y destino de la información contenida en los diagramas para ir obteniendo cada una de las fronteras hasta alcanzar un sistema ejecutable. Dichas transformaciones se representan en las ilustraciones de los diagramas (§ 5.2.1.2, 5.2.3.3,
Capítulo 5 Solución propuesta
75
5.2.5.2 y 5.2.7.1) y de las fronteras (§ 5.2.2, 5.2.4 y 5.2.6) como una línea con flecha, donde la flecha indica el diagrama destino que se obtiene del diagrama origen.
5.2.1 Definición del modelo CIM Una representación visual de los componentes y sus relaciones, del modelo CIM, se muestra en la Ilustración 5-19, que está constituida por el modelo del negocio en su modelo funcional y no funcional, así como una generación de modelos de dominio que se utilizan como base para los modelos funcional y no funcional.
Todos los modelos dentro del CIM son el punto inicial para la comprensión de lo que el cliente quiere y de cual es su contexto. La información que se tiene en este modelo CIM esta definida en los incisos siguientes.
Modelo CIM
Modelo del negocio
Modelo funcional
Modelo no funcional
Modelo de dom
inio
Modelo CIM
Modelo del negocio
Modelo funcional
Modelo no funcional
Modelo de dom
inio
Ilustración 5-19. Representación visual de la definición del modelo CIM
El modelo del negocio es la parte principal de la definición del modelo CIM y donde se
dan las bases del sistema a desarrollar.
5.2.1.1 Modelo del negocio Este modelo describe las funciones y los procesos que componen el negocio y las relaciones del negocio con procesos externos. Los procesos del negocio describen cómo se realiza el trabajo en la empresa y se caracterizan por ser observables, medibles, mejorables y repetitivos. Este modelo contiene:
• Reglas del negocio • Objetivos y metas del negocio • Definición de la estrategia del negocio • Funciones del negocio • Procesos del negocio (entradas, salidas, roles, actividades, entidades, atributos
relaciones)
Capítulo 5 Solución propuesta
76
Dentro de un negocio existen por ejemplo, dominios como administración, recursos humanos, finanzas, etc.
El modelo de negocio (Ej. CENIDET) contendrá los modelos funcional y no funcional, así como el modelo de dominio (Ej. dominio de administración de tecnología de la información aplicable al centro de cómputo, dominio de una biblioteca aplicable al centro de información, dominio de un departamento académico de postgrado aplicable al depto. de Ciencias Computacionales) que se utiliza como referencia para obtener los modelos funcional y no funcional, así también son referencia para las áreas dentro del negocio. Los modelos funcional (§ 5.2.1.1.2) y no funcional (§ 5.2.1.1.3) hacen referencia a los requerimientos generales del negocio y los requerimientos específicos a cada área, los cuales se encuentran en los modelos de dominio (§ 5.2.1.1.1) del negocio.
5.2.1.1.1 Modelo de dominio El modelo de dominio ayudará a capturar las entidades y acontecimientos asociados con el área (dominio), el cual contendrá los términos básicos (entidades, acciones, actores, etc.) y sus relaciones en correspondencia a su contexto.
Cabe mencionar que al término dominio se le considerará como un área de conocimiento o actividad caracterizada mediante el conjunto de conceptos y terminología entendida por los expertos del área (dominio).
La información del modelo de dominio, se obtendrá en general de los expertos del dominio (mediante una entrevista) o mediante el modelado de los involucrados y sus procesos, para obtener un conjunto de mejores prácticas avaladas por dichos expertos. Esta información contribuirá a una mejor comprensión del problema que se quiere resolver en relación a su contexto. Este modelo contiene:
• Glosario, que define los términos utilizados en el área/dominio del negocio, para comprenderlos mejor y evitar malos entendidos, así como usarlos en un determinado proyecto. Además éste describe a las clases de los objetos y sus atributos relevantes en el espacio del problema.
• Contenido de relaciones entre objetos. • Requerimientos funcionales. • Requerimientos no funcionales. • Mejores prácticas.
5.2.1.1.2 Modelo funcional El modelo funcional se refiere a las operaciones que transforman de entradas a salidas en cada actividad de los procesos involucrados y en última instancia a las salidas de una aplicación computacional hacia su ambiente, ya sea dentro de un dominio o hacia entidades externas al negocio.
Capítulo 5 Solución propuesta
77
El ambiente incluye al usuario y cualquier otra aplicación computacional con la cual interactúe. Es decir, especifica tanto los objetivos internos como externos que se realizan para llevar a cabo una determinada actividad dentro del negocio o en un dominio particular. Por lo tanto en este punto se debe de identificar la siguiente información:
• Identificación del proceso. El conjunto ordenado de resultados, entradas y procedimientos requeridos.
• Identificación de actores y clases potenciales. Un actor puede ser una aplicación computacional y/o un humano. Una clase describe un conjunto de objetos que tienen un rol o roles equivalentes y que representa información relevante que los actores del negocio entienden.
• Identificación de escenarios. Es una representación de lo que los actores hacen y experimentan cuando realizan actividades.
• Identificación de casos de uso. Representa las funciones del negocio o de un dominio en particular, vistas desde la perspectiva de los actores externos, que proporcionan un resultado notable, es decir, de valor para uno o varios actores u otros stakeholders18.
• Identificación de las relaciones entre casos de uso. Se refiere al tipo de relación (include, extend, use,…) y cuáles casos de uso se relacionan.
5.2.1.1.3 Modelo no funcional El modelo no funcional se refiere a los requerimientos que describen características relacionadas a una aplicación computacional (entradas, salidas, procedimientos, actores y recursos) que no tienen que ver con su funcionalidad y algunas características pueden ser visibles para el usuario. Un requerimiento no funcional impone restricciones sobre un requerimiento funcional, pero también describe atributos, restricciones, consideraciones de funcionamiento, diseño, calidad, consideraciones de ambiente, de fracaso y recuperación. Este modelo puede contener [STD98]:
• Interfaces externas.- Debe ser una descripción detallada de todas las entradas y salidas del sistema del software. Las interfaces externas son:
o Interfaces de usuario. o Interfaces de hardware. o Interfaces de software. o Interfaces de comunicación.
• Requisitos de rendimiento.- Debe especificar los requerimientos estáticos y dinámicos que se pusieron en el software o en la interacción humana con el software en conjunto.
o Estáticos.- Número de terminales y número de usuarios simultáneos a ser apoyados, así como cantidad y tipo de información que se manejará.
o Dinámicos.- Número de transacciones, tareas y la cantidad de datos a ser procesado dentro de ciertos periodos de tiempo para las condiciones del trabajo normales y máximas.
• Atributos del software.- Son un conjunto de cuestiones de calidad, las cuales son:
18 Los stakeholder engloba a todas las personas externas e internas que tienen que ver con una aplicación computacional.
Capítulo 5 Solución propuesta
78
o Disponibilidad o Factores de calidad [ISO91]
Funcionalidad ♦ Aplicabilidad ♦ Precisión ♦ Interoperatibilidad ♦ Seguridad ♦ Conformidad de funcionalidad
Fiabilidad ♦ Madurez ♦ Tolerancia a fallos ♦ Recuperabilidad (Los atributos de software que tienen que ver
con la capacidad de reestablecer su nivel de rendimiento y recuperar los datos directamente afectados en caso de un fracaso, durante el tiempo y esfuerzo necesario para ello. Por ejemplo datos, proceso, tecnología.)
Usabilidad ♦ Entendibilidad ♦ Facilidad de aprendizaje ♦ Operabilidad
Eficiencia ♦ Comportamiento en el tiempo ♦ Utilización de recursos
Facilidad de mantenimiento ♦ Analizabilidad (Los atributos de software que tienen que ver con
el esfuerzo necesario para el diagnóstico de las deficiencias o causas de los fracasos, o para la identificación de partes para ser modificadas.)
♦ Cambiabilidad (Los atributos de software que tienen que ver con los esfuerzos necesarios para la modificación, eliminación del defecto o para cambios ambientales.)
♦ Estabilidad ♦ Testeabilidad (Los atributos de software que tienen que ver con
el esfuerzo necesario para validar el software modificado.) Portabilidad
♦ Adaptabilidad ♦ Instabilidad (Los atributos de software que tienen que ver con el
esfuerzo necesario para instalar el software en un ambiente específico.)
♦ Reemplazabilidad ♦ Conformidad de portabilidad
• Restricciones de diseño.- Debe especificar las restricciones del diseño que pueden imponerse por otros estándares, las limitaciones del hardware, etc.
Capítulo 5 Solución propuesta
79
La información de los modelos presentados en el modelo CIM es un primer acercamiento a la definición de los casos de uso y posibles escenarios, así como de las clases participantes. A partir del modelo funcional, durante el desarrollo del modelo PIM, se derivan las clases, asociaciones y atributos, debido a que para llegar a este nivel se tuvo que haber especificado bien los elementos del nivel CIM, para ser transformados a nivel PIM y estando en dicho nivel agregar la información adicional necesaria para obtenerlos. 5.2.1.2 Vista del nivel CIM a través de los diagramas y sus transformaciones Una vez definido el modelo CIM en cuanto a la información que incluye, es necesario mostrar cómo se encuentra conformado por los diagramas seleccionados (casos de uso, clases, secuencia y actividad § 4.3) y otros diagramas utilizados dentro del AGD (de comunicación y de línea de producción) para el nivel CIM. Esto permite determinar la información que contiene dicho nivel, que será transformada a otro nivel (PIM), en su momento.
En la Ilustración 5-20 se muestra el nivel CIM en base a los diagramas que lo conforman: de comunicación, de línea de producción, de clases, de actividad y de casos de uso, los cuales serán transformados entre sí y hacia otros niveles.
Diagrama de comunicación
combinado
Diagramas de comunicación a
nivel usuario
Diagrama de comunicación a nivel aplicación
Definición de los objetivos del
negocio y/o dominio
Diagramas de línea de
producción
Diagramas de actividad
Diagrama de clases del negocio
Diagrama de casos de uso del negocio y
escenarios
Definición de losobjetivos a automatizar
Requerimientos funcionales
Modelo no funcional
Diagrama de comunicación
combinado
Diagramas de comunicación a
nivel usuario
Diagrama de comunicación a nivel aplicación
Definición de los objetivos del
negocio y/o dominio
Diagramas de línea de
producción
Diagramas de actividad
Diagrama de clases del negocio
Diagrama de casos de uso del negocio y
escenarios
Definición de losobjetivos a automatizar
Requerimientos funcionales
Modelo no funcional
Ilustración 5-20. Representación visual del nivel CIM en base a diagramas y sus transformaciones
Por otra parte la ilustración también muestra información necesaria (Ej. requerimientos
funcionales) para realizar la transformación entre los diagramas (Ej. de la definición de los objetivos del negocio y/o dominio se transforma a diagramas de línea de producción).
Como se mencionó en la sección 5.2.1.1 este nivel empieza con el modelo del negocio y
posteriormente con los modelo de las áreas/dominios, que se obtienen en base al análisis de documentos y/o entrevistas.
Capítulo 5 Solución propuesta
80
La conformación de los modelos mencionados, se inician con los diagramas de comunicación a nivel usuario, con el objetivo de identificar y especificar todas las actividades y relaciones que realiza una determinada entidad/actor con respecto al cargo que desempeña. Todos los diagramas de comunicación a nivel usuario están vistos desde la perspectiva de un diagrama de entidades.
Una vez obtenidos los diagramas de comunicación a nivel usuario, estos se fusionan para
obtener el diagrama de comunicación combinado, con la finalidad de evitar inconsistencias y mostrar las interacciones entre todas las entidades involucradas.
Para identificar los objetivos internos y externos (con respecto a todas las entidades
involucradas) se realiza el diagrama de comunicación a nivel aplicación, donde se enmarcan todas las entidades internas y se unen en una sola, como si fuera una aplicación computacional. Cabe mencionar en este punto que los objetivos (para AGD) son la recepción o envío de información, a veces agrupada en documentos o pantallas de captura. El diagrama de comunicación a nivel aplicación surge del diagrama de comunicación combinado.
Del diagrama de comunicación a nivel aplicación se obtienen los objetivos internos y
externos, así como las entidades involucradas en ellos. De los objetivos se procede a obtener los diagramas de línea de producción y la definición de los objetivos que se van a automatizar (para el siguiente nivel PIM enfocarlos a una aplicación computacional).
Con los diagramas de línea de producción, representados mediante diagramas de clases,
donde la clase representa el producto y los métodos el proceso relacionado con el producto, se obtiene de forma general, lo que se necesita para obtener un determinado servicio (que se ofrece a un usuario) y cuáles entidades intervienen en él. Por medio del diagrama de línea de producción se obtiene lo siguiente:
• Diagramas de actividad donde se muestran las actividades y tareas que se realizan
dentro del negocio y/o área/dominio actualmente, por cada diagrama de línea de producción. Por medio del diagrama de actividad se describe el procedimiento que se realiza para obtener los productos del diagrama de línea de producción. Este diagrama estará relacionado con los escenarios tanto del diagrama de casos de uso a nivel CIM, como del nivel PIM.
• Diagramas de casos de uso del negocio, se generan a partir de los diagramas de línea de producción y los escenarios de dicho diagrama se obtienen de los diagramas de actividad correspondientes a la línea de producción. Los diagramas de casos de uso representarán a los servicios que ofrece un determinado negocio y/o área/dominio, a usuarios.
• Diagrama de clases del negocio, donde se representa la información relevante que manejan las personas dentro del negocio y/o dominio vista desde su perspectiva. Para obtener las clases se analizan los productos, principalmente aquellos que no tienen derivados, así como los que sean más abstractos.
• Requerimientos funcionales se obtienen de la definición de los objetivos a automatizar, y se verifican con la línea de producción.
Capítulo 5 Solución propuesta
81
La definición de los objetivos a automatizar (lo que se requiere que realice el sistema a desarrollar) abarca tanto las actividades internas que realiza el personal involucrado en el negocio y/o área/dominio en el que se va a trabajar, así como las actividades externas que se realizan para ofrecer los servicios a los usuarios del negocio y/o dominio.
Por último, en el modelo no funcional es donde se especifican las restricciones a los requerimientos del modelo funcional. Con la obtención de este modelo termina el desarrollo a nivel CIM.
Cabe aclarar que para cada uno de los niveles se puede requerir, dependiendo del tamaño del producto de software a desarrollar más de una iteración ya que se necesitaran ir refinando para poder pasar al siguiente nivel. Para cumplir con el nivel CIM se sugiere la realización de un prototipo, el cual debe ser aceptado por la persona a la cual se le pretende desarrollar una aplicación. 5.2.2 Definición de la frontera CIM-PIM En la Ilustración 5-21 se muestra tanto el nivel CIM como el nivel PIM con sus respectivos modelos y diagramas, donde la especificación de máximo detalle del modelo CIM, y el mínimo del modelo PIM representa la frontera CIM-PIM. Se muestran los diagramas de ambos niveles, así como de las transformaciones que pueden existir entre ambos. Además las transformaciones que se tienen que realizar para obtener el nivel PIM a partir del CIM se ilustran con las líneas: continúa, punteada y discontinua (contiene líneas y puntos) respectivamente. Las líneas continúa y punteada representan que a partir del glosario de términos y del diagrama de clases del negocio a nivel CIM se obtienen el diagrama de clases y el diagrama de la base de datos del nivel PIM. Por último, las líneas discontinuas indican que del diagrama de casos de uso del negocio y de los requerimientos funcionales se obtienen los diagramas de casos de uso a nivel PIM.
PIMModelo de análisis
Diagramas de Casos de UsoDiagramas de secuencia
Modelo de diseñoDiagrama de clases Diagrama de base de datosDiagramas de actividad
CIMModelo del negocio
Modelo del dominio de bibliotecaGlosario de términos
Modelo funcionalDiagramas de comunicación a nivel usuarioDiagrama de comunicación combinadoDiagrama de comunicación a nivel aplicaciónDefinición de objetivos de la bibliotecaLínea de producción Diagramas de actividadDiagrama de casos de uso del negocioDiagrama de clases del negocioDefinición de objetivos de la biblioteca a automatizarRequerimientos funcionales
Modelo no funcional
PIMModelo de análisis
Diagramas de Casos de UsoDiagramas de secuencia
Modelo de diseñoDiagrama de clases Diagrama de base de datosDiagramas de actividad
CIMModelo del negocio
Modelo del dominio de bibliotecaGlosario de términos
Modelo funcionalDiagramas de comunicación a nivel usuarioDiagrama de comunicación combinadoDiagrama de comunicación a nivel aplicaciónDefinición de objetivos de la bibliotecaLínea de producción Diagramas de actividadDiagrama de casos de uso del negocioDiagrama de clases del negocioDefinición de objetivos de la biblioteca a automatizarRequerimientos funcionales
Modelo no funcional
Ilustración 5-21. Frontera CIM-PIM en base a diagramas y sus transformaciones
Después de haber dado la semblanza de la frontera CIM-PIM, es necesario presentar la caracterización de la misma a través de los diagramas seleccionados (§ 4.3), para presentar las características distintivas entre ambos niveles CIM y PIM, para ello en la sección 5.2 se
Capítulo 5 Solución propuesta
82
presenta dicha caracterización mostrando una comparación con todas las fronteras a través de los distintos niveles. 5.2.3 Definición del modelo PIM En la Ilustración 5-22 se muestra la representación visual del modelo PIM con su modelo de análisis (§ 5.2.3.1) y modelo de diseño (§ 5.2.3.2), los cuales son modelos independientes de plataforma que representan información y datos específicos desde el punto de vista computacional, sin mostrar los detalles de su uso en una plataforma o tecnología.
Como se muestra en la Ilustración 5-18, el modelo PIM hereda del modelo CIM todos sus elementos y estructura.
Para obtener el modelo PIM se toma como entrada principal un subconjunto de los
elementos del CIM (Ej. diagrama de casos de uso, requerimientos funcionales) y se añaden detalles para completar el diseño.
Los detalles de diseño se refieren a información del sistema acerca de sus componentes y relaciones entre ellos, que no son especificadas todavía en un lenguaje de implementación o incluyendo características propias de una plataforma. La información que se tiene en el modelo PIM esta definida en los incisos siguientes.
Modelo PIM
Modelo de análisis
Modelo de diseño
Modelo PIM
Modelo de análisis
Modelo de diseño
Ilustración 5-22. Representación visual de la definición del modelo PIM
Mediante los modelos de análisis (Ej. diagrama de casos de uso) y diseño (Ej. diagrama de
clases) del modelo PIM se transforman los modelos presentes en el modelo CIM (Ej. diagrama de casos de uso, diagrama de clases), para extenderlos y modificarlos para estructurar y formalizar la información obtenida en ellos, además de preparar la arquitectura del sistema. El modelo de diseño se crea en base al modelo de análisis (Ej. diagrama de secuencia) como entrada principal, pero se adapta a un refinamiento más especifico para poderlo migrar posteriormente a cualquier entorno de implementación.
Todos los modelos del PIM se obtienen refinando y especializando el modelo funcional y
no funcional del modelo CIM.
Capítulo 5 Solución propuesta
83
5.2.3.1 Modelo de análisis Parte de la información de este modelo se obtiene de un subconjunto de elementos del modelo CIM, agregando la especialización de dichos elementos (Ej. glosario de términos, requerimientos funcionales). Se usan el modelo de análisis y los requerimientos no funcionales, para preparar la arquitectura del sistema que se desarrolla durante el diseño. Este modelo contiene:
• Refinamiento y estructuración de los elementos obtenidos del modelo CIM (Ej. casos de uso, requerimientos funcionales, clases, glosario de términos)
• Flujo de dato. Se refiere a la secuencia en que los datos se transfieren, usan y transforman en el sistema.
• Flujo de control. Es el ordenamiento de las acciones en un sistema. Las acciones a ordenar incluyen la decisión de cuáles operaciones deben ejecutarse y en qué orden. Estas decisiones se basan en eventos externos provocados por un actor o en el paso del tiempo.
5.2.3.2 Modelo de diseño Este modelo se refiere a detalles de diseño independientes de la plataforma (Ej. tipos de datos, métodos). Se especifica información que es necesaria para desarrollar una aplicación computacional pero sin utilizar ningún lenguaje de programación para especificarlo. El modelo está conformado por:
• Arquitectura del sistema. Conjunto de decisiones significativas acerca de la organización de un sistema de software, la selección de los elementos estructurales a partir de los cuales se compone el sistema y las interfaces entre ellos, junto con su comportamiento [JAC00].
• Modelo de clases. En el cual se especifica el nombre de las clases, atributos y métodos asociados a ellas, además de ver el tipo de clases (Ej. si es clase plantilla) y sus tipos de relaciones (Ej. agregación, composición,…).
• Estilo arquitectónico. Modelo de diseño de sistema general que puede usarse como punto inicial para el diseño del sistema. Éste guía la organización de la arquitectura: sus elementos y sus interfaces, sus colaboraciones y su composición.
• Modelo lógico. Procedimientos (algoritmos) detallados sin restricciones de plataforma. Ejemplo: tipos de operadores (no vistos desde el lenguaje como +, -, *, /, ≤, ≥, =, ≠, etc.
• Modelo de especificaciones. Como la especificación de los siguientes aspectos: o Alcance (protegido, privado, publico) o Valores por defecto o Objetos o Variables o Tipo de relaciones entre métodos o Especificación de tipo, firma y visibilidad o Definición de estructuras, matrices, vectores, etc.
Capítulo 5 Solución propuesta
84
Una vez definido el modelo PIM es necesario pasar los elementos a un nivel más especializado y enfocado el sistema en una plataforma y lenguaje específico, se ejecutará. Debido a esto es necesario definir el modelo PSM.
5.2.3.3 Vista del nivel PIM a través de los diagramas y sus transformaciones Después de haber definido la información que contendrá y/o se manejará a nivel PIM, se procede a mostrar los diagramas seleccionados (§ 4.3) a través de los cuales se representará dicha información, la cual será transformada posteriormente hacia el siguiente nivel, más detallado (PSM).
El nivel PIM se conforma a partir de los elementos obtenidos en el CIM, logrando diagramas más refinados de casos de uso, secuencia, clases, base de datos y actividad a nivel general, del que se puedan obtener versiones diferentes del modelo PSM, uno para cada plataforma requerida.
En la Ilustración 5-23 se muestra el nivel PIM en base a los diagramas que lo conforman, tales como: clases, actividad, casos de uso, secuencia y el diagrama para la base de datos, todos los diagramas se transformarán entre un mismo nivel y hacia otro nivel más específico. La ilustración también muestra los diagramas y documentos necesarios del nivel CIM para obtener los diagramas en este nivel PIM, donde los círculos con línea continua representan el nivel PIM y los círculos con líneas discontinuas representan el nivel CIM, que es la entrada para el nivel PIM. A continuación se describe el nivel PIM.
Los diagramas de casos de uso en este nivel representan tanto los objetivos internos y
externos de las actividades o tareas a automatizar. Los diagramas de casos de uso se obtienen de los requerimientos funcionales representados en los diagramas de comunicación y línea de producción y del diagrama de casos de uso a nivel CIM, en el cual se reflejan los servicios que ofrece el negocio y/o área/dominio.
De cada uno de los diagramas de casos de uso a nivel PIM se realizan sus correspondientes
escenarios (tomando información de los diagramas de actividad del nivel CIM). Estos escenarios se diferencian de los del nivel CIM ya que en el nivel PIM se describen en base a las actividades a automatizar, computacionalmente y en el nivel CIM sólo representan el conjunto de actividades que se realizan en el negocio y/o área/dominio actualmente, o la manera en que se pretenden realizar.
Una vez obtenidos los diagramas de casos de uso y escenarios, se procede a obtener el
diagrama de secuencia que contiene los detalles de los algoritmos involucrados en los escenarios de los casos de uso, ya que estos fueron descritos como una secuencia de pasos (en [DIA04] se realiza la construcción del diagrama de secuencia a partir de la especificación textual de los casos de uso). Con el diagrama de secuencia se pueden identificar clases y objetos. El diagrama de secuencia se utilizó como entrada para los siguientes diagramas:
• Diagrama de clases, se obtiene a partir del diagrama de secuencia (del nivel PIM), del diagrama de clases del negocio y del glosario de términos (se utiliza para identificar clases y sus atributos relevantes), estos últimos del nivel CIM. Este diagrama de clases
Capítulo 5 Solución propuesta
85
ya representa cómo está conformado el sistema sin considerar cuestiones de lenguaje, plataforma o ambiente de desarrollo.
• Diagrama de actividad, se obtiene tanto del diagrama de secuencia como del diagrama de clases del nivel PIM. En el diagrama de actividad, se representan las instrucciones para cada uno de los métodos que se utilizarían dentro de la aplicación computacional a desarrollar. En el nivel PIM no se están considerando todavía aspectos del lenguaje de programación.
El diagrama de base de datos se obtiene tomando información del diagrama de clases del negocio y el glosario de términos ambos del nivel CIM, donde los términos del glosario se utilizan dentro del diagrama de base de datos para identificar tablas y sus atributos. En este diagrama se representa el diseño de la base de datos con los elementos y relaciones que se utilizarían vistos desde una perspectiva independiente del lenguaje de base de datos a utilizar. Dos diagramas que no tienen trazabilidad directa, pero que tienen relación (en base a los atributos), son el diagrama de clases y el diagrama de base de datos, debido a que tienen como entrada el glosario de términos y el diagrama de clases del negocio.
Diagramas de secuencia
Diagramas de casos de uso y
escenariosDiagrama de clases
Diagramas de actividad
Diagrama de la base
de datos
Diagrama de clases del
negocio
Diagrama de casos de uso del negocio y
escenarios
Requerimientos funcionales Glosario de
términos
Diagramas de secuencia
Diagramas de casos de uso y
escenariosDiagrama de clases
Diagramas de actividad
Diagrama de la base
de datos
Diagrama de clases del
negocio
Diagrama de casos de uso del negocio y
escenarios
Requerimientos funcionales Glosario de
términos
Ilustración 5-23. Representación visual del nivel PIM en base a diagramas y sus transformaciones
5.2.4 Definición de la frontera PIM-PSM En la Ilustración 5-24 se muestran los niveles PIM y PSM con los diagramas que los representan, donde la frontera PIM-PSM es el nivel de detalle máximo de los modelos PIM y el mínimo para los modelos PSM, se muestran los diagramas que se utilizan para pasar de un nivel a otro.
De los diagramas de clases a nivel PIM se obtienen los diagramas de clases a nivel PSM, lo cual se representa en la ilustración a través de la línea continúa, después del diagrama de base de datos a nivel PIM surge el diagrama de base de datos a nivel PSM representado en la ilustración por la línea punteada y por último, del diagrama de actividad a nivel PIM se origina el diagrama de actividad a nivel PSM representado en la ilustración por la línea discontinua.
Capítulo 5 Solución propuesta
86
PIMModelo de análisis
Diagramas de Casos de UsoDiagramas de secuencia
Modelo de diseñoDiagrama de clases Diagrama de base de datosDiagramas de actividad
PSMModelo de diseño
Diagrama de clases Diagrama de base de datosDiagramas de actividad
PIMModelo de análisis
Diagramas de Casos de UsoDiagramas de secuencia
Modelo de diseñoDiagrama de clases Diagrama de base de datosDiagramas de actividad
PIMModelo de análisis
Diagramas de Casos de UsoDiagramas de secuencia
Modelo de diseñoDiagrama de clases Diagrama de base de datosDiagramas de actividad
PSMModelo de diseño
Diagrama de clases Diagrama de base de datosDiagramas de actividad
PSMModelo de diseño
Diagrama de clases Diagrama de base de datosDiagramas de actividad
Ilustración 5-24. Frontera PIM-PSM en base a diagramas y sus transformaciones
Una vez mostrada la frontera PIM-PSM a través de los diagramas que conforman a cada
uno de los niveles que intervienen en ella, es necesario presentar la caracterización de la misma a través de los diagramas seleccionados (§ 4.3), mediante las características distintivas entre ambos niveles PIM y PSM. En la sección 5.2 se presenta dicha caracterización mostrando una comparación con todas las fronteras a través de los distintos niveles.
5.2.5 Definición del modelo PSM En la Ilustración 5-25 se muestra la definición del modelo PSM con su modelo de diseño que es dependiente de la plataforma y contiene información acerca de la tecnología que se usa sobre una plataforma específica.
El modelo PSM está conformado por los elementos heredados del modelo PIM mapeados a elementos específicos de la plataforma a utilizar.
Un aspecto que se considera en este modelo PSM es el modelo no funcional descrito en el modelo CIM, para lograr apegarse a estas especificaciones utilizando características de la plataforma.
En el modelo PSM se especifica cómo implementar en el modelo de IM. La información
que se tiene en el modelo PSM esta definida en los incisos siguientes.
Modelo PSM
Modelo de diseño
Modelo PSM
Modelo de diseño
Ilustración 5-25. Representación visual de la definición del modelo PSM
El modelo de diseño describe la realización práctica de los requisitos funcionales y no funcionales y su impacto en la aplicación computacional a desarrollar.
Capítulo 5 Solución propuesta
87
5.2.5.1 Modelo de diseño Se toman los aspectos del diseño del modelo PIM, para ser refinados según el lenguaje y herramientas computacionales en las que se implementará. El modelo esta conformado por:
• Modelo de clases. Se tiene las características de una clase ya sea normal o con plantillas (nombre, atributos, métodos).
• Modelo lógico. Como estructuras de repetición (Ej. en C++, for, while, do-while, etc.), estructuras de selección (Ej. en C++, if, select case, etc.) y tipos de operadores.
• Modelo de especificaciones. Como la especificación de los siguientes aspectos: o Alcance (protegido, privado, público). o Valores por defecto. o Objetos. o Variables. o Tipo de relaciones entre métodos. o Especificación de tipo, firma y visibilidad. o Definición de estructuras, matrices, vectores, etc. o Apuntadores. o Llamadas a funciones.
• Arquitectura del sistema. • Flujo de datos. • Flujo de control. • Lenguaje de programación. • Almacenamiento de la información (BD, archivos, etc.).
En el modelo PSM se define el modelo de diseño que sirve de abstracción de la
implementación del sistema, que se utiliza para obtener el modelo IM. 5.2.5.2 Vista del nivel PSM a través de los diagramas y sus transformaciones Posteriormente, a la definición de la información que se maneja a nivel PSM, se procede a mostrar los diagramas seleccionados (§ 4.3) a través de los cuales se representará dicha información, la cual será transformada hacia el nivel IM.
El nivel PSM se conforma de los elementos obtenidos en el PIM, alcanzando diagramas de clases, actividad y de la base de datos, todos descritos por el lenguaje y plataforma a utilizar.
En la Ilustración 5-26 se muestra el nivel PSM en base a los diagramas que lo conforman, tales como: clases, actividad y diagramas para la base de datos, todos los diagramas serán transformados entre un mismo nivel y hacia otros niveles.
La ilustración también muestra los diagramas del nivel PIM necesarios para obtener los
diagramas en este nivel PSM, donde el nivel PSM es representado por los círculos de línea punteada y el nivel PIM por círculos con línea continúa. Se considera los círculos de línea continúa debido a que es la entrada para cada círculo de línea punteada. A continuación se explica el nivel PSM.
Capítulo 5 Solución propuesta
88
La diferencia del nivel PIM y PSM para estos diagramas es que en PSM el tipo de dato ya fue transformado de acuerdo al lenguaje a utilizar y al manejador de base de datos respectivamente.
El diagrama de base de datos a nivel PSM se obtiene del diagrama de base de datos a nivel PIM, siendo más específico, de acuerdo al manejador de base de datos a utilizar.
Posteriormente, el diagrama de clases a nivel PSM se obtiene del diagrama de clases del
nivel PIM, agregando más relaciones y clases debido al ambiente en el que se va a desarrollar. Se agregan clases prefabricadas necesarias para el desarrollo del sistema, de acuerdo al ambiente seleccionado.
Por último, los diagramas de actividad a nivel PSM se obtienen de los diagramas de
actividad a nivel PIM, de igual forma, se consideran los detalles de implementación necesarios en el manejo de instrucciones de acuerdo al lenguaje y ambiente de desarrollo.
Diagrama de clases
Diagramas de actividad
Diagrama de la base
de datosDiagrama de clases
Diagramas de actividad
Diagrama de la base
de datos
Diagrama de clases
Diagramas de actividad
Diagrama de la base
de datosDiagrama de clases
Diagramas de actividad
Diagrama de la base
de datos
Ilustración 5-26. Representación visual del nivel PSM en base a diagramas y sus transformaciones
5.2.6 Definición de la frontera PSM-IM En la Ilustración 5-27 se muestra la frontera PSM-IM en base a los diagramas que se encuentran en los niveles PSM e IM y las transformaciones que se tienen que realizar para obtener del nivel PSM el nivel IM. En esta frontera, del diagrama de clases a nivel PSM se obtiene el código de las clases a nivel IM representado por la línea continúa, del diagrama de base de datos a nivel PSM surge el código de la base de datos representado por la línea punteada y por último, de los diagramas de actividad a nivel PSM se origina el código de los métodos a nivel IM de una determinada clase representado por la línea discontinua.
Capítulo 5 Solución propuesta
89
PSMModelo de diseño
Diagrama de clases Diagrama de base de datosDiagramas de actividad
IMCódigo base de datosCódigo de los métodosCódigo de las clases
PSMModelo de diseño
Diagrama de clases Diagrama de base de datosDiagramas de actividad
PSMModelo de diseño
Diagrama de clases Diagrama de base de datosDiagramas de actividad
IMCódigo base de datosCódigo de los métodosCódigo de las clases
IMCódigo base de datosCódigo de los métodosCódigo de las clases
Ilustración 5-27. Frontera PSM-IM en base a diagramas y sus transformaciones
Después de haber mostrado la frontera PSM-IM en base a los diagramas y
transformaciones entre los niveles involucrados, es necesario presentar la caracterización de la misma a través de los diagramas seleccionados (§ 4.3), para ello en la sección 5.2 se explica dicha caracterización mostrando una comparación con todas las fronteras a través de los distintos niveles.
5.2.7 Definición del modelo IM En la Ilustración 5-28 se muestra la representación visual del modelo IM con su modelo correspondiente a la implementación, el cual representa información acerca de la tecnología que se usa en su realización sobre una plataforma específica.
Este modelo contiene los elementos que son específicos a la plataforma, junto con la codificación de la aplicación computacional, para obtener la aplicación ejecutable de la misma.
El modelo IM hereda del modelo PSM más la información agregada para la
implementación.
Modelo IM
Modelo de Implementación
Modelo IM
Modelo de Implementación
Ilustración 5-28. Representación visual de la definición del modelo IM
El modelo IM representa el código de una aplicación computacional que se genera
mediante la información del modelo PSM y los aspectos del lenguaje de implementación. Para obtener el modelo IM se considerará el modelo no funcional del modelo CIM, para
refinar aspectos inconclusos del modelo PSM, con respecto a los factores de calidad. Se usan herramientas para construir el sistema fuente, objeto y ejecutable, así como de la
utilización de un dbms19 (Ej. Oracle, MySQL, Access, PostgreSQL).
19 Sistema de gestión de base de datos, DBMS por sus siglas en inglés
Capítulo 5 Solución propuesta
90
En la implementación se retoman los resultados del modelo PSM de diseño y se implementa el sistema en términos de componentes (código fuente, código binario, ejecutables,…). La información que se tiene en el modelo IM abarca los elementos siguientes:
• Interfaces de usuario. • Seguridad del sistema (ejemplo, acceso restringido por contraseña, etc.). • Lenguaje de programación. • Sistema operativo. • Marcos de trabajos prefabricados (Ej. Visual C++). • Funciones predefinidas. • Librerías del lenguaje. • Manejo de excepciones. • Palabras reservadas. • Integración de los componentes del sistema. • Manejo de memoria. • Ambiente de desarrollo (Ej. Fases de ejecución como compilación, enlace, carga,
ejecución). • Todo lo definido en el modelo de diseño del modelo PSM pasado a código.
5.2.7.1 Vista del nivel IM a través del código generado en base a los diagramas del nivel PSM y sus transformaciones Una vez definido el nivel IM, se procede a presentar su información y cómo se llegó a ella (por medio de que transformación). Este nivel contiene elementos del nivel PSM, donde se obtiene el código para la parte del sistema correspondiente; se consideran detalles como librerías, aspectos generados por el ambiente (clases, métodos), aspectos de usabilidad (color, estilo de la letra de algún campo a mostrar), etc.
En la Ilustración 5-29 se muestra el nivel IM, donde los círculos de línea continúa representa al nivel IM y los círculos de línea punteada al nivel PSM, que es la entrada para el nivel IM.
El nivel IM incluye el código correspondiente al diagrama de clases a nivel PSM, en el que
se considerarán clases prefabricadas, declaraciones de objetos y métodos que el ambiente provee, además de librerías.
Con respecto al código de la base de datos éste se origina del diagrama de la base de datos a nivel PSM. La trazabilidad entre ambos es casi directa ya que al pasar a código lo que cambiará es la forma en que se declaran las claves primarias o foráneas y el agregado de campos “null” o “not null”, con el propósito de especificar si el atributo es requerido o opcional.
El código de las clases surge del diagrama de clases a nivel PSM y el código de los
métodos es obtenido de los diagramas de actividad a nivel PSM.
Capítulo 5 Solución propuesta
91
Diagrama de clases
Diagramas de actividad
Diagrama de la base
de datos
Código de la base de datos
Código de los métodos
Código de las clases
Diagrama de clases
Diagramas de actividad
Diagrama de la base
de datos
Código de la base de datos
Código de los métodos
Código de las clases
Ilustración 5-29. Representación visual del nivel IM en base el código generado a través de los diagramas y sus
transformaciones
5.3 Caracterización de las fronteras Como se mencionó en las secciones 5.2.2 (frontera CIM-PIM), 5.2.4 (frontera PIM-PSM) y 5.2.6 (frontera PSM-IM) referentes a cada una de las fronteras, en esta sección se mostrará la caracterización de las fronteras a través de los diagramas seleccionados (§ 4.3), mediante las características distintivas entre cada frontera a través de los distintos niveles. Por ello, de la Tabla 5-7 a la Tabla 5-10 se presenta dicha caracterización. Las tablas muestran al diagrama de casos de uso, clases, secuencia y actividad, indicando el nivel de detalle o presencia de elementos, propiedades y atributos de los diagramas en las fronteras. Dichos elementos, propiedades y atributos que se presentan en cada una de las tablas están de acuerdo a los elementos, propiedades y atributos necesarios para describir cada frontera, debido a que representan la delimitación de cada frontera, especificando lo máximo que pueden contener en cada nivel (presente en cada columna de los niveles en cada tabla), es por ello que no se presenta la estructura completa utilizada en la sección 5.1.2.
En las tablas se presentan todos los elementos con los atributos de un identificador, un nombre y una o varias propiedades. En la columna de elementos, propiedades y atributos, las etiquetas que comienzan con “uml”, son elementos y las que comienzan con “*”, son propiedades contenidas dentro de los elementos y las que no comienzan con ninguna de las antes mencionadas, son atributos que tiene un determinado elemento o propiedad.
Los atributos que tengan al final de su nombre un paréntesis, significa que dentro del
paréntesis están los valores que puede tener el atributo, donde el símbolo “|” significa “o”. Por ejemplo el atributo “type” en el elemento “uml:DecisionNode” del diagrama de secuencia, puede tener sólo el valor “Decision” o “Merge”.
Los símbolos utilizados en las intersecciones de renglones y columnas, en las columnas de
niveles, se muestran a continuación con su significado:
Capítulo 5 Solución propuesta
92
• “∆” Indica un número de elementos o propiedades o atributos que puede tener un determinado nivel.
• “√” Indica un número opcional de elementos o propiedades o atributos que pueden estar presente en un determinado nivel.
• “|”, “<”, “>”, “=” Son operadores lógicos que indican comparación de elemento o propiedades o atributos, el primer operando es el modelo de la columna izquierda inmediata y el segundo operando es el modelo de la columna donde está este operador. Por ejemplo, en el elemento “uml:UseCase” del diagrama de casos de uso en el nivel PIM, el símbolo “<”, indica que dicho elemento se va a presentar un menor número de veces en el nivel CIM que en el PIM.
Si dos o más símbolos se juntan en una misma columna, se leerá de la siguiente manera:
por ejemplo, se tiene “<=>” en una determinada columna, esto se leería como, se presenta menor o igual o mayor número de veces en el nivel X que en el Y.
El nivel de anidamiento de las tablas esta dado por como están estructurados
jerárquicamente los elementos, propiedades y atributos, delimitados por los espacios que tienen en la tabla cada uno de ellos. Por último, cuando en la intersección de un renglón con una columna, sea “ ” significa que no se especifica dicho elemento o propiedades o atributos en una determinada frontera o nivel. A continuación se inicia con la explicación y presentación de cada una de las tablas.
De la Tabla 5-7 se puede decir que en el nivel CIM el elemento “uml:UseCase o “uml:Actor” representa la perspectiva de los objetivos externos del dominio, es decir, los servicios que se ofrecen y, en el nivel PIM esos elementos representan, tanto los servicios como la forma en que se llega a ellos, es decir, los objetivos externos e internos al dominio del negocio.
Un ejemplo para explicar la Tabla 5-7, es el siguiente: se tiene el elemento
“uml:Association” que está presente en la frontera CIM-PIM solamente, donde a nivel CIM está presente un determinado número de veces y a nivel PIM con respecto al CIM, puede estar un número igual o menor de veces presente en el nivel CIM que en el nivel PIM, lo que significa que a nivel PIM este elemento puede tener igual número de veces presente que en el CIM o mayor número de veces en el PIM. Con respecto a su atributo “type” en el valor “Extend” solamente va estar en el nivel PIM un determinado número de veces. Tomando el atributo “subject” de dicho elemento, se tiene que a nivel CIM puede o no estar presente dicho atributo al igual que a nivel PIM, donde este atributo se representa un número opcional de veces en el nivel CIM y puede estar presente igual o menor número de veces (opcional) en el nivel CIM que en el PIM, lo que significa que puede ser igual o mayor el número de veces que aparezca dicho atributo en el PIM. La misma lógica presentada para este ejemplo se aplicaría para interpretar la tabla para los demás elementos, propiedades y atributos.
Capítulo 5 Solución propuesta
93
Tabla 5-7. Caracterización de las fronteras CIM-PIM, PIM-PSM y PSM-IM a través del diagrama de casos de uso
Niveles Elementos, propiedades y
atributos CIM PIM PSM IM
uml:UseCase ∆ < ∆ subject ∆ =<∆ uml:Actor ∆ < ∆ subject √ =<√ uml:ExtensionPoint √ ExtensionPoint √ subject √ uml:Subject ∆ <∆ uml:Association ∆ =< ∆ subject √ =<√ type ( Extend | ∆ Include | ∆ Use | ∆ =<∆ Generalize ) ∆ =<√
De la Tabla 5-8 se concluye lo siguiente, en el nivel CIM el elemento “uml:Class”,
representa el nombre de la clase visto desde la perspectiva del experto del dominio y en los demás niveles (PIM, PSM e IM) representa el nombre de la clase enfocado hacia el sistema a desarrollar.
Por todo lo anterior, se dice que, la propiedad “uml:Atribute” (en su atributo “type”)
contenida en el elemento “uml:Class”, tiene ó no tiene cierta característica en cada uno de los niveles, que a continuación se mencionan: en el nivel CIM no se tiene definido el rango a utilizar (debido a que se trabaja a nivel de negocio); en el nivel PIM se tiene una aproximación al rango a utilizar; en el nivel PSM o IM se tiene ya la restricción del rango o el rango deseado dependiendo del lenguaje.
Por último, cabe mencionar que en el nivel CIM las propiedades “uml:Atribute” e
“uml:Operation” se obtendrán sólo los atributos u operaciones necesarias para imponer restricciones que se obtengan a nivel de las actividades que se realizan en el dominio del negocio. Sin embargo en los niveles más detallados, se tendrán más atributos u operaciones que se irán refinando a través de cada nivel.
Para explicar mejor la Tabla 5-8, a continuación se presenta un ejemplo: se tiene al
elemento “uml:Class” que contiene a su vez atributos y propiedades, donde las propiedades son: “uml:Attribute” y “uml:Operation”, la cual contiene la propiedad “uml:Parameter”. El elemento “uml:Class” está especificado (presente) en los cuatro niveles, por lo tanto, en las tres fronteras, donde comparando el nivel CIM y PIM de la tabla en este elemento, se tiene que éste se va a presentar menor o igual o mayor número en el nivel CIM que en el PIM, lo que significa que en el nivel PIM ese elemento puede ser mayor o igual o menor que en el CIM. Pasando al nivel PIM y PSM, se indica que dicho elemento se va a presentar menor o igual número de veces en el PIM que en el PSM, lo que significa que en el nivel PSM se presentará un mayor o igual número de veces que en el nivel PIM. Por último, a nivel PSM e IM, se tiene que dicho elemento se presentará igual o menor número de veces en el nivel PSM que en el IM, lo que significa que en el nivel IM, se presentará igual o mayor número de veces
Capítulo 5 Solución propuesta
94
que en el PSM. La misma lógica presentada para este ejemplo se aplicaría para interpretar la tabla para los demás elementos, propiedades y atributos.
Tabla 5-8. Caracterización de las fronteras CIM-PIM, PIM-PSM y PSM-IM a través del diagrama de clases
Niveles Elementos, propiedades y atributos
CIM PIM PSM IM
uml:Class ∆ <=>∆ <=∆ <=∆ isAbstract(true|false) ∆ <=∆ <=∆ isDerived(true|false) ∆ <=∆ <=√ isRoot (true|false) ∆ <=∆ Visibility (Public|Private|Protected) ∆ =∆ =∆ Template √ =√ =√ Stereotype √ =√ *uml:Attribute √ <∆ <=∆ =∆ type √ <∆ <=∆ =∆ visibility (packageLocal|Public|Private|Protected) ∆ <=∆ =∆ Stereotype √ =√ *uml:Operation ∆ <∆ <=∆ =∆ type ∆ <∆ <=∆ =∆ visibility (packageLocal|Public|Private|Protected) ∆ =∆ =∆ Stereotype √ =√ *uml:Parameter √ <=√ =√ type √ <=√ =√ uml:Interface √ <=√ =√ isAbstract(true|false) √ <=√ =√ isDerived(true|false) √ <=√ √ isRoot (true|false) √ <=√ Visibility (Public|Private|Protected) √ =√ =√ Stereotype √ =√ uml:Association ∆ <=>∆ <=∆ =∆ direction ( Unspecified ∆ Bi-directional √ <√ =√ Source-Destination ∆ <=>∆ <∆ =∆ Destination-Source √ <√ type ( Associate | ∆ <=>∆ =<∆ =∆ AssociationClass | ∆ <=>√ =<√ Generalize | ∆ <=>√ =<∆ =∆ Compose | ∆ =<∆ =∆ Agregate | √ =<√ =√ Dependency | ∆ =<∆ =∆ Realize | √ =<√ Trace | √ =<√ Nesting | √ =<√ InterfaceRealization ) √ =<√ *Multiplicity √ =<√
En la Tabla 5-9 se muestra que en el nivel PIM solamente se presentan los elementos del
diagrama de secuencia, debido a que éstos sólo se utilizarán para representar los detalles de implementación de los escenarios de los casos de uso y con ello también los objetos y clases necesarias para implementar el escenario, debido a que los escenarios fueron descritos como una secuencia de pasos.
En forma general, en la Tabla 5-9 en todos sus elementos, propiedades y atributos del diagrama de secuencia se presentan solamente en el nivel PIM y estos en su mayoría pueden o no pueden estar presentes. Todo esto indica que este diagrama se utiliza sólo para realizar transformaciones en el nivel PIM.
Capítulo 5 Solución propuesta
95
Tabla 5-9. Caracterización de las fronteras CIM-PIM, PIM-PSM y PSM-IM a través del diagrama de secuencia Niveles
Elementos, propiedades y atributos CIM PIM PSM IM
uml:Lifeline ∆ stop √ covered √ frame √ type ( Actor | ∆ Boundary | ∆ Control | √ Entity | ∆ Lifeline ) ∆ *Coregion √ *DurationConstraint √ *TimeConstraint √ *TimeObservation √ uml:CombinedFragment ∆ interaction √ Frame √ type ( alt | ∆ loop | √ opt ) √ *condition ∆ *Interaction √ *InternalStructure √ uml:Gate √ frame √ uml:InteractionState √ frame √ *Condition √ *Type √ name( StateInvariant | √ Continuation ) √ uml:EndPoint √ frame √ uml:Frame √ uml:InteractionUse √ interaction √ frame √ uml:Association ∆ Frame √ type ( Message | ∆ DurationObservation | √ DurationConstraint | √ Self-Message | √ GeneralOrdering | √ Lost-Message | √ Found-Message ) √ *Message ∆ kind( Asynchronous | √ Call | ∆ Signal | ∆ Return ) ∆
De la Tabla 5-10 se concluye que en el nivel CIM se reflejarán las tareas o actividades que
se realizan en la actualidad en el dominio del negocio. En el nivel PIM todo iniciará con los objetivos a automatizar a través del sistema a desarrollar y por último en el nivel PSM se utilizará la especificación del lenguaje, en el cual se va a implementar el sistema, con las opciones o bondades que brinda dicho lenguaje.
Capítulo 5 Solución propuesta
96
El elemento “uml:Activity” y “uml:Action” en el nivel IM, representan las instrucciones descritas en un lenguaje de programación determinado. Y el elemento “uml:DecisionNode” en su atributo “type” en sus valores “Decision” y “Merge” en el nivel IM, representaran a los comandos (como if, else, while) descritos por un lenguaje de programación.
Un ejemplo para explicar la Tabla 5-10, es el siguiente: se tiene el elemento
“uml:FinalNode”, el cual tiene el atributo “partition” que solamente opcionalmente puede estar presente en el nivel CIM. Dicho elemento esta presente en el nivel CIM, PIM y PSM, aunque en el nivel IM pudiera estar presente en el código como “}”. Comparando el nivel CIM y PIM de ese elemento, se tiene que se presenta igual o menor número de veces en el CIM que en el PIM, lo que significa que a nivel PIM éste se presentará igual o mayor número de veces que en el CIM. Por último, comparando el nivel PIM y PSM, se tiene que dicho elemento se presenta igual o menor número de veces en el PIM que en el PSM, lo que significa que a nivel PSM éste se presentará igual o mayor número de veces que en el PIM. La misma lógica presentada para este ejemplo se aplicaría para interpretar la tabla para los demás elementos, propiedades y atributos. Tabla 5-10. Caracterización de las fronteras CIM-PIM, PIM-PSM y PSM-IM a través del diagrama de actividad
Niveles Elementos, propiedades y
atributos CIM PIM PSM IM
uml:Activity ∆ <=>∆ =<∆ =< partition ∆ region √ =<√ uml:InitialNode ∆ =<∆ =<∆ partition ∆ uml:Partition ∆ uml:Region √ =<√ uml:Exception √ =<√ region √ =<√ uml:Action √ <√ =< region √ =<√ uml:DecisionNode ∆ <=>∆ <∆ partition ∆ region √ =<√ type ( Decision | ∆ <=>∆ <∆ =< Merge ) ∆ <=>∆ <∆ uml:FinalNode ∆ =<∆ =<∆ partition √ uml:SendSignalAction √ =<√ region √ =<√ uml:ReceiveEventAction √ =<√ region √ =<√ uml:ForkNode ∆ <=>√ =<√ partition ∆ region √ =<√ uml:JoinNode ∆ <=>√ =<√ partition ∆ region √ =<√ uml:DataStore √ =<√ region √ =<√ uml:ObjectNode √ =<√ region √ =<√ uml:FlowFinal √ =<√ uml:Association ∆ <=>∆ =<∆ partition ∆ region √ =<√
Capítulo 5 Solución propuesta
97
type ( ControlFlow | ∆ =<>∆ =<∆ ObjectFlow | √ =<√ InterruptFlow ) √ =<√
Como resultado de este capítulo se obtuvo una representación visual de la definición de los
modelos (CIM, PIM, PSM e IM), la caracterización y definición de las fronteras (CIM a PIM, PIM a PSM y PSM a IM) que se definieron en base a la especificación de los modelos y su representación interna, donde todo esto fue esencial para cubrir los aspectos de la estructura de MDA en el ambiente AGDE.
Todo lo presentado en este capítulo se utiliza en la demostración, que se presenta en el
siguiente capítulo. Se presentó la información que se requiere cubrir en cada uno de los modelos para obtener cada una de las fronteras y lograr una implementación que contenga todo lo reflejado en los modelos, cuidando de la trazabilidad entre ellos.
98
Capítulo 6
Demostración Una vez mostrada la propuesta de solución en el capítulo 5, con respecto a los análisis pertinentes para obtener la definición de los modelos, fronteras y su caracterización, es necesario demostrar la utilidad del contenido de los tres niveles de modelos y la caracterización de las fronteras, propuestos en esta investigación (§ 5.2 y 5.3). Para ubicar el porqué de la demostración, se realiza una breve descripción a continuación.
El presente trabajo de investigación esta dirigido a un estudio de factibilidad en la descripción de cada una de las fronteras que integran al enfoque MDA. Para este fin se verifica que la información definida en cada modelo es adecuada y las fronteras delimitan un modelo de otro. Que se pasa de un modelo a otro por medio de la definición de las fronteras, hasta alcanzar la implementación.
Esta demostración, se realiza a través del desarrollo de software para resolver el problema
clásico de biblioteca. Con las definiciones mencionadas, se ayuda a delimitar el nivel de detalle requerido en los
modelos y en sus fronteras, comparando la información de cada elemento de los modelos con la definición de cada frontera (CIM a PIM, de PIM a PSM y de PSM a IM).
Capítulo 6 Demostración
99
6.1 Tesis de la demostración20 “Con la información definida en los modelos y la caracterización de las fronteras, es posible llegar a una implementación funcional, a través de transformaciones pudiendo distinguir cuando un modelo se convierte en otro de un nivel más detallado”. Es decir, se quiere demostrar que el apegarse a la definición de las fronteras (contemplando la definición de los modelos), se puede transformar de un modelo a otro y obtener como resultado final un sistema ejecutable. Así el desarrollador esta conciente, al realizar cada diagrama, del modelo en el que se encuentra, gracias a las fronteras definidas. 6.2 Fundamentos o argumentos El enfoque MDA está conformado por 3 modelos (CIM, PIM, PSM) y a través de ellos realiza el desarrollo de software dirigido por modelos. Cada uno de estos modelos tiene diferente nivel de abstracción, que va de lo más general a lo más específico. Estos modelos son transformados hasta obtener el código fuente del sistema de software final. Cuando se trabaja, en cada uno de los modelos, se debe considerar la consistencia y trazabilidad entre ellos.
Este enfoque se apoya en múltiples tecnologías como UML para el modelado de sistemas, MOF que define diversos metamodelos y extiende a UML para que sea aplicado en el modelado de diferentes sistemas de información y además XMI que facilita el intercambio de metadatos en entornos distribuidos heterogéneos entre diferentes tipos de herramientas de software y en especial, entre herramientas de modelado basadas en UML y repositorios de metadatos basados en MOF. 6.3 Procedimiento Para llevar a cabo la demostración se eligió el problema de biblioteca de los casos de prueba presentados en [SHA95], que presenta distintos problemas clásicos de arquitectura de software, pero el problema se basó específicamente en la biblioteca de CENIDET para que fuera un caso real. Este problema fue abordado con el enfoque MDA. Mostrando que los diagramas UML desarrollados cumplen con el contenido del nivel de modelo correspondiente y con cada una de sus fronteras (de CIM a PIM, de PIM a PSM y de PSM a IM), hasta llegar a través de transformaciones a un nivel bajo de abstracción (implementación).
Se consideraron los requerimientos del problema de biblioteca de [WIN88] y [KEM07],
pero el punto de partida para la demostración fueron dichos requerimientos, adecuados a las necesidades y/o requerimientos de la biblioteca de CENIDET.
Como se mencionó al inicio de este capítulo, se demostrará, por medio del problema clásico de biblioteca, que apegarse a la definición de las fronteras es útil para guiar las transformaciones hasta llegar a un sistema ejecutable. Agregando los diagramas (definidos para cada modelo) necesarios para pasar del detalle que delimita los modelos CIM y PIM
20 Es el juicio, pensamiento, idea, opinión o hipótesis cuya veracidad o falsedad trata de explicarse por medio de la demostración.
Capítulo 6 Demostración
100
(frontera CIM-PIM), al detalle que delimita los modelos PIM y PSM (frontera PIM-PSM), hasta llegar a la implementación, que se obtiene transformando el modelo PSM al modelo IM (frontera PSM-IM). En los incisos siguientes se explica una parte de la demostración (referente a registrar un préstamo), ya que la demostración completa se encontrará en el Reporte Técnico RT-DCC-1-2007, cuyo titulo es Desarrollo de la demostración de la tesis: “Caracterización de las fronteras de los modelos MDA mediante UML” [LOP07]. 6.3.1 Explicación de la demostración Cabe reiterar que la demostración completa se documenta en el Reporte Técnico: Desarrollo de la demostración de la tesis: “Caracterización de las fronteras de los modelos MDA mediante UML” (RT-DCC-1-2007) [LOP07] y que en este documento sólo se mostrarán fragmentos de dicha demostración, enfocándose al registro de prestamos en la biblioteca de CENIDET.
Cada uno de los niveles contiene los diagramas correspondientes con su representación interna (XMI) y su tabla de trazabilidad, que indica a partir de que diagrama origen y que elemento se obtuvo un determinado elemento de un diagrama destino. Utilizando la definición de las fronteras como referencia para verificar que cada diagrama pertenece al modelo especificado.
En las representaciones internas que se presentan en las subsecciones siguientes sólo se
muestran fragmentos de cada documento XMI correspondiente a cada diagrama, donde dichas representaciones son documentos formateados con dos columnas, donde la segunda columna es la continuación de la primera. 6.3.1.1 Nivel general En la Ilustración 6-1 se muestra la representación visual en forma general del procedimiento de la demostración y a continuación se hace una descripción del mismo.
Como primer paso se tuvo que realizar una entrevista con el jefe del centro de información del CENIDET donde se obtuvo la información necesaria para dar comienzo al nivel CIM, donde se tocaron los puntos de modelo del negocio (CENIDET), modelo del dominio (biblioteca de CENIDET), modelo funcional y no funcional donde se comenzó con la realización de los diagramas de comunicación a nivel usuarios, a nivel combinado y a nivel aplicación, así como diagramas de casos de uso del negocio, línea de producción, actividad y diagrama de clases del negocio .
Una vez terminado el nivel CIM se paso al nivel PIM que tuvo como entrada el modelo funcional y no funcional del nivel CIM para obtener el modelo de análisis a nivel PIM y que a partir de éste se derivó el modelo de diseño en el mismo nivel. Los diagramas en este nivel PIM fueron diagramas casos de uso, de secuencia, de clases, de base de datos y de actividad, que se enfocaron a la integración de objetivos internos y externos a automatizar por medio del sistema de biblioteca.
Capítulo 6 Demostración
101
En el modelo de diseño no se especificó nada que tenga que ver con un lenguaje de programación, plataforma o ambiente, debido a que se está trabajando en el nivel PIM, el cual es independiente del lenguaje o plataforma.
Para pasar al nivel PSM fue necesario que el nivel PIM estuviese completo (verificado mediante la caracterización de las fronteras), ya que el modelo de diseño de nivel PIM es la entrada para el nivel PSM, el cual contiene diagramas de clases, base de datos relacional y de actividad. Una vez complementada la frontera (PIM-PSM), del nivel PSM se procedió a obtener el nivel IM, en el cual se obtiene el código tomando como entrada el modelo de diseño del nivel PSM.
Estos dos últimos niveles presentan características del lenguaje, plataforma, ambientes de
desarrollo y otros aspectos referentes a la generación de código.
Cabe mencionar que cada una de las definiciones de los niveles para los diagramas trae asociada una tabla de trazabilidad para pasar de un modelo a otro en un mismo nivel (Ej. CIM a CIM) y de un nivel a otro (Ej. cruzando la frontera CIM-PIM), verificando con ello la definición para cada una de las fronteras.
De acuerdo a las características que se requerían (Ej. Soporte a los elementos de UML) se
eligieron los diagramadores siguientes: Altova, Enterprise Architect y together, el que más se utilizó debido a sus ventajas en cuanto a elementos de UML fue Enterprise Architect.
CIM PIM PSM IM
Modelo de análisis Modelo de diseño
Modelo del negocio-Modelo de dominio
Modelo funcional Modelo no funcional
Modelo de diseño
CIM PIM PSM IM
Modelo de análisis Modelo de diseño
Modelo del negocio-Modelo de dominio
Modelo funcional Modelo no funcional
Modelo de diseño
Ilustración 6-1. Nivel general de la demostración
6.3.1.2 Nivel CIM Este nivel inició con los documentos, que el personal tiene que manipular en la biblioteca, para ofrecer un servicio a los usuarios. Como se mencionó en la sección anterior se realizó una entrevista al Jefe del centro de información para obtener datos relacionados con todas las actividades que se desempeñan en la biblioteca. Por ello, se inicia con los diagramas de comunicación a nivel usuario, para los usuarios: Auxiliares de biblioteca, Jefa de organización bibliográfica y Jefe del centro de información.
Capítulo 6 Demostración
102
Posteriormente, los tres diagramas de comunicación a nivel usuario sirvieron de entrada para realizar el diagrama de comunicación combinado, el cual une a los tres diagramas de comunicación a nivel usuario.
A partir del diagrama de comunicación a nivel combinado de todas las entidades
involucradas en la biblioteca (auxiliares, jefa de organización bibliográfica y jefe del centro de información), se logró el diagrama de comunicación a nivel aplicación, obteniendo por medio de éste, los objetivos internos y externos de la biblioteca. Los objetivos para esta tesis están relacionados directamente con la recepción y entrega de documentos/resultados, donde dichos objetivos se obtienen de los diagramas de comunicación relacionados con las actividades que se realizan en una determinada área/dominio. En la Tabla 6-1 se presentan en los objetivos de la biblioteca.
Tabla 6-1. Objetivos internos y externos de la biblioteca Objetivo externo Entidades externas involucradas
A-1 Recepción de solicitud de préstamo bibliotecario de acervo (no único ni 1er ejemplar) A-2 Proporciona servicio bibliotecario A-3 Entrega ficha de prestamos de acervo A-4 Entrega credencial B-1 Entrega ficha de préstamo B-2 Entrega credencial C-1 Recepción de solicitud de préstamo bibliotecario de acervo único o 1er ejemplar C-2 Proporciona servicio bibliotecario C-3 Entrega ficha para préstamo de acervo único o 1er ejemplar para firma C-4 Entrega ficha de acervo único o 1er ejemplar firmada C-5 Entrega credencial D-1 Retorna acervo único o 1er ejemplar D-2 Entrega credencial I-1 Recepción de solicitud del catálogo interbibliotecario I-2 Envía catálogo interbibliotecario I-3 Recepción de solicitud del formato de préstamo interbibliotecario I-4 Proporciona el formato de préstamo interbibliotecario I-5 Envía formato de préstamo interbibliotecario llenado I-6 Recibe formato de préstamo interbibliotecario firmado y sellado J-1 Entrega acuse del formato de préstamo interbibliotecario para archivarlo
Usuarios (alumnos, organización y seguimiento, gestión tecnológica, servicios escolares, desarrollo académico, recursos humanos, recursos financieros, recursos materiales y de servicio, planeación, Depto. Académico, comunicación y eventos)
L-1 Proporciona formato de no adeudo L-2 Envía formato de no adeudo
Usuarios (alumnos)
M-1 Recepción de solicitud de necesidades bibliográficas M-2 Envía necesidades bibliográficas
Usuarios (alumnos, gestión tecnológica, desarrollo académico, planeación, Depto. Académico)
O-1 Envió de tesis para exhibición Depto. Académico R-1 Recepción de solicitud de estadísticas R-2 Envío de estadísticas
Planeación
DD-1 Recepción de solicitud de lista de alumnos inscritos DD-2 Envío de lista de alumnos inscritos
Servicios escolares
Objetivos internos Entidades internas involucradas
Capítulo 6 Demostración
103
E-1 Envía libros comprados o tesis E-2 Recepción de solicitud de revisión de catalogación y clasificación de libros o tesis (fichas de acervo) E-3 Envía la revisión de catalogación y clasificación para ser capturada en el sistema F-1 Envía revisión de usuarios para ser modificados o eliminados G-1 Envía lista de usuarios para dar de alta (realizar sus credenciales) H-1 Envía revisión de acervo para ser modificado o eliminado en el sistema
Jefa de organización bibliográfica, jefe del centro de información
N-1 Envía revistas para ser selladas y registradas en kardex N-2 Envía el kardex para ser capturado
Auxiliares de biblioteca y jefe del centro de información
EE-1 Envía libros, tesis o revistas registradas para ser exhibidos
Jefa de organización bibliográfica, auxiliares de biblioteca
De los objetivos internos y externos de la biblioteca se obtuvo el diagrama de línea de
producción (conformado por 10 diagramas) y la definición de los objetivos a automatizar. Por medio del diagrama de línea de producción de la biblioteca se obtuvo lo siguiente:
• Diagramas de actividad (conformado por 10 diagramas), donde se muestran las
actividades, tareas que se realizan dentro de la biblioteca actualmente por cada diagrama de la línea de producción, es decir, se describió el procedimiento que se realizó para obtener los productos del diagrama de línea de producción.
• Diagrama de casos de uso (conformado por 1 diagrama principal y 8 sub-casos de uso), se generaron a partir de los diagramas de línea de producción y los escenarios (conformado por 8 escenarios) correspondientes a cada caso de uso, se obtuvieron de los diagramas de actividad de la línea de producción.
• Diagrama de clases del negocio (conformado por 12 clases), donde se representó la información relevante que maneja el personal de biblioteca vista desde su perspectiva. Para obtener las clases se analizaron los productos de la línea de producción, de la cual se seleccionaron sólo aquellos productos que eran más abstractos, también se seleccionaron aquellos productos que son relevantes que no tienen productos derivados.
• Requerimientos funcionales se obtuvieron de la definición de los objetivos a automatizar y se verificaron de acuerdo al problema modelo de biblioteca y a los diagramas de línea de producción.
A continuación se muestra el diagrama de casos de uso principal del negocio en la
Ilustración 6-2 y después se muestra el sub-caso de uso “Solicitar préstamo de acervo”, que como ya se dijo en la sección 6.3.1, solamente se muestran fragmentos de “Registrar préstamo”, a través de los distintos niveles y fronteras, posteriormente se presenta en la Ilustración 6-4 el documento XMI (§ 5.1) de dicho diagrama. Por último, en la Tabla 6-2 se presentan los elementos que dieron origen a los elementos de este diagrama, con lo que se muestra una parte del nivel CIM.
En la Ilustración 6-2 se presenta el diagrama de casos de uso general a nivel CIM, donde
se puede observar que está conformado por ocho subcasos de uso provenientes del diagrama de línea de producción. Este diagrama de casos de uso contiene tres actores externos que influyen en dichos casos de uso.
Capítulo 6 Demostración
104
Las relaciones del actor “usuario”, “planeación” y “alumno”, están relacionadas con los
casos uso por medio del conector “use”, y el actor “planeación” y “alumno” están heredando del actor “usuario” el acceso a los demás casos de uso con que el actor “usuario” tiene relación.
El actor “usuario” engloba a los demás tipos de usuarios (organización y seguimiento,
gestión tecnológica, servicios escolares, desarrollo académico, recursos humanos, recursos financieros, recursos materiales y de servicio, Depto. Académico, comunicación y eventos) externos que tienen relación con los casos de uso mostrados en la ilustración.
uc CU-Negocio-CIM
Biblioteca
Usuario
AlumnoPlaneación
CU-8 Solicitar estadísticas
CU-7 Solicitar formato de no
adeudo
CU-1 Solicitar préstamo de
acerv o
CU-2 Retornar acerv o
CU-3 Solicitar necesidades bibliográficas
CU-4 Solicitar préstamo
interbibliotecario
CU-5 Rev isar catálogo
interbibliotecario
CU-6 Obtener credencial
Ilustración 6-2. Diagrama de casos de uso del negocio a nivel CIM
Posterior al diagrama de casos de uso principal del negocio, es necesario presentar la parte
que se va a tratar en este documento, por ello a continuación en la Ilustración 6-3 se presenta el sub-diagrama de caso de uso de “Solicitar préstamo de acervo”, realizado a partir de la Ilustración 6-2, para ir acotando la parte que se presentará en este documento a nivel CIM, que es presentar lo referente a “Registrar préstamo”.
Capítulo 6 Demostración
105
uc CU-Negocio-CIM
Usuario
CU-1 Solicitar préstamo de
acerv o
Ilustración 6-3. Sub-diagrama de casos de uso de la Ilustración 6-2
La representación interna del diagrama antes mostrado, se presenta en la Ilustración 6-4.
En dicha representación se especifican los elementos y propiedades del diagrama, donde se tiene al elemento “Usuario” contenido en la etiqueta “uml:Actor”, cuyo identificador es “A1” y al elemento “CU-1 Solicitar préstamo de acervo” contenido en la etiqueta “uml:UseCase”, cuyo identificador es “CU1”, como ambos elementos están relacionados en cada una de sus etiquetas que los representan, se agrega una sub-etiqueta “Association” que contiene una referencia que es “R1” hacia la etiqueta “uml:Association”, donde se describe la relación entre el actor “usuario” y el caso de uso “CU-1 Solicitar préstamo de acervo”.
La etiqueta “uml:Association” tiene un identificador que es “R1”, un nombre que en este
caso no se especificó y una propiedad “type” que indica el tipo de relación que existe entre los elementos, la cual es de “Use”, además esta etiqueta contiene dos etiquetas que especifican el origen de la relación por medio del identificador del elemento origen que es “A1” y otra etiqueta que especifica el destino de la relación, por medio del identificador del elemento destino que es “CU1”, ambos identificadores corresponden al actor “usuario” y al caso de uso “CU-1 Solicitar préstamo”.
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDCasosUso.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="CasosUso" name="Casos de uso del negocio"> <uml:Actor xmi:id="A1" name="Usuario"> <Association xmi:idref="R1"/>
</uml:Actor> <uml:UseCase xmi:id="CU1" name="CU-1 Solicitar préstamo de acervo" subject="S1"> <Association xmi:idref="R1"/> </uml:UseCase> <uml:Association xmi:id="R1" name="" type="Use"> <Source xmi:idref="A1"/> <Target xmi:idref="CU1"/> </uml:Association> </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 6-4. Documento XMI para el diagrama de casos de uso de la Ilustración 6-3
A continuación se presenta el escenario de la Ilustración 6-3 para “Solicitar préstamo de
acervo”, el cual proviene de los diagramas de actividad de préstamo de acervo de la línea de producción préstamo de acervo.
ID: CU-1 Nombre de
caso de uso:
Solicitar préstamo de acervo
Creador: Edna D. López López Ultima modificación: Edna D. López López Fecha de creación:
05/06/07 Fecha de última modificación:
20/06/07
Actores: Iniciado por el usuario, se comunica con el personal de biblioteca.
Capítulo 6 Demostración
106
Descripción: El objetivo de este caso de uso es obtener en préstamo un acervo bibliográfico. Precondiciones: El usuario solicita el préstamo de acervo con su credencial (si tiene prestamos no es
necesaria) y la (s) ficha(s) llena(s) para el préstamo correspondiente al tipo de acervo. Poscondiciones: El personal de biblioteca le presta el acervo solicitado al usuario y dependiendo del tipo de
acervo le entrega la ficha del acervo. Escenario principal
de éxito: • El usuario solicita el préstamo de acervo al personal de biblioteca. • Si el usuario tiene prestamos entrega solamente la(s) ficha(s) para el préstamo
dependiendo del tipo de acervo. 1. El personal de biblioteca verifica los prestamos del usuario. 2. El número de prestamos es correcto.
• Si no, el usuario entrega credencial y dependiendo del tipo de acervo entrega la(s) ficha(s) para el préstamo.
• Se sella (n) la(s) ficha(s), se entrega la ficha del acervo dependiendo del tipo de acervo.
• El personal de biblioteca le presta el acervo al usuario. Escenario de
fracaso (1): • El usuario solicita el préstamo de acervo al personal de biblioteca. • Si el usuario tiene prestamos entrega solamente la(s) ficha(s) para el préstamo
dependiendo del tipo de acervo. 1. El personal de biblioteca verifica los prestamos del usuario. 2. El número de prestamos es igual o superior al permitido. 3. El personal de biblioteca no le presta el acervo al usuario.
Escenario de fracaso (2):
• El usuario solicita el préstamo de acervo al personal de biblioteca. • Si el usuario tiene prestamos entrega solamente la(s) ficha(s) para el préstamo
dependiendo del tipo de acervo. 1. El personal de biblioteca verifica los prestamos del usuario. 2. El número de prestamos es correcto. 3. El titulo del ejemplar que solicita el usuario ya lo tiene prestado. 4. El personal de biblioteca no le presta el acervo al usuario.
Prioridad: Alta Subcasos de uso:
En la Tabla 6-2 se presenta la trazabilidad para el diagrama de casos de uso de la
Ilustración 6-3, en el cual se presentan los elementos del diagrama de línea de producción para préstamo de acervo a partir de los cuales surgieron los elementos de dicho diagrama de casos de uso.
Tabla 6-2. Trazabilidad para el diagrama de casos de uso de la Ilustración 6-3 a nivel CIM
Objetivos externos de la biblioteca Elementos del subdiagrama de Casos de uso “Solicitar préstamo de acervo” a nivel CIM
10.- Acervo prestado (no único ni 1er ejemplar) 12.- Acervo prestado (único o 1er ejemplar)
CU-1 Solicitar préstamo de acervo
Por último, de la definición de los objetivos a automatizar para la biblioteca se sacaron los
requerimientos funcionales (Ej. Registrar préstamo) y refinando estos últimos se obtuvieron algunos de los requerimientos no funcionales de la biblioteca (Ej. Sólo se puede prestar un máximo de 3 libros a un usuario). 6.3.1.3 Cruce de la frontera CIM-PIM Esta frontera se inició con la transformación de los casos de uso del negocio a nivel CIM (conformado por 1 diagrama principal y 8 sub-casos de uso) a los casos de uso a nivel PIM (conformado por 1 diagrama principal, 8 sub-casos de uso, de los cuales se desglosan 6 de ellos), ya enfocados al sistema de biblioteca a desarrollar. Además que para obtener todos los casos de uso de este nivel también se revisa la lista de requerimientos funcionales obtenida a nivel CIM.
Capítulo 6 Demostración
107
Cabe mencionar que a partir de los diagramas de casos de uso en el nivel PIM la demostración presentada en el Reporte Técnico RT-DCC-1-2007, se enfocó en la parte de “Administrar préstamo de acervo” y que en este capítulo solamente se presentan partes seleccionadas de “Registrar préstamo”, para explicar cada uno de los niveles y fronteras.
Posteriormente, se transformó el diagrama de clases del negocio a nivel CIM (conformado por 12 clases) al diagrama de clases a nivel PIM (conformado por 10 clases), donde influyó también el glosario de términos a nivel CIM. Cabe mencionar que esta desigualdad en el número de clases manejada en cada nivel, es debido a que en el nivel CIM, dicho diagrama representa la información relevante que el personal de biblioteca entiende y que no tiene que ver con el diseño o programación y en el nivel PIM, es como estará con respecto al sistema a desarrollar, es decir, en términos del desarrollador del sistema.
Por último, para obtener el diagrama de base de datos (nivel PIM) se realizó una
transformación del diagrama de clases del negocio (nivel CIM), a dicho diagrama de la base de datos (base de datos relacional elaborada con la herramienta SQL Management Studio 2006 for PostgreSQL), pero también existe otra transformación para completar este diagrama, la cual se obtiene del glosario de términos, que consiste en obtener los términos para el nombre de las tablas relevantes a utilizar, así como los atributos que contendrán, para poder manipular la información de cada tabla a través del sistema de biblioteca.
A continuación se muestra el diagrama principal de casos de uso “Administrar préstamo
de acervo” a nivel PIM en la Ilustración 6-5, después en la Ilustración 6-6 se presenta el sub-sub caso de uso “Registrar préstamo”, posteriormente se muestra en la Ilustración 6-7 el documento XMI (§ 5.1) correspondiente a “Registrar préstamo”, así como, se describe el escenario de dicho sub-sub caso de uso, que como ya se dijo en la sección 6.3.1, solamente se muestran fragmentos de “Registrar préstamo”, a través de los distintos niveles y fronteras. Además, en la Tabla 6-3 se presentan los elementos que dieron origen a los elementos de este diagrama, con lo que se muestra una parte de la frontera CIM-PIM.
En la Ilustración 6-5, se muestra el diagrama de casos de uso “Administrar préstamo de
acervo” a nivel PIM, donde se presentan los subcasos de uso que puede contener como: “Registrar préstamo”, “Eliminar préstamo”, “Modificar préstamo”, “Consultar préstamo” y “Obtener estadísticas de préstamo”, donde todos estos casos de uso los realiza el actor “Jefe del centro de información”, pero también los actores “Jefa de organización bibliográfica” y “Auxiliares de biblioteca” pueden realizar todos los casos de uso, excepto el caso de uso “Obtener estadísticas de préstamo”.
Las relaciones que se presentan de los actores a los casos de uso es de “use” y las
relaciones que tienen los casos de uso “CU-4.1”, “CU-4.2”, “CU-4.3”, “CU-4.4” y “CU-4.5” con respecto al caso de uso “CU-4” es de “extend”, ya que estos representan las opciones que pueden realizar los actores que intervienen en este diagrama, la otra relación que existe entre los casos de uso de este diagrama es “include”, por ejemplo, para registrar un préstamo, se tiene que validar que el usuario este registrado (CU-1.1.1) y que no exceda el número de prestamos permitidos (CU-4.2.1). El diagrama de casos de uso de la Ilustración 6-5 fue obtenido del diagrama general de casos de uso del nivel PIM y los casos de uso “CU-1.1.1
Capítulo 6 Demostración
108
Validar usuario” y “CU-2.1.1 Validar acervo” provienen de los casos de uso “CU-1 Administrar usuario” y “CU-2 Administrar acervo”, todo esto se presentan en [LOP07].
uc CU-Prestamos
CU-4 Administrar préstamo de
acervo
CU-4.1 Registrar préstamo
CU-4.2 Eliminar préstamo
CU-4.3 Modificar préstamo
CU-4.4 Consultar préstamo
Jefa de organización bibliografica
Jefe del centro de información
Auxiliares de biblioteca
CU-1.1.1 Validar usuario
CU-2.1.1 Validar acervo
CU-4.5 Obtener estadística de
prestamos
CU-4.2.1 Validar préstamo de
acervo
Jefa de organización bibliografica
Auxiliares de biblioteca
«extend»
«extend»
«extend»
«extend»
«extend»
«include»
«include»
«include»
«include»
«include»
Ilustración 6-5. Diagrama de casos de uso "Administrar préstamo de acervo" a nivel PIM
Una vez mostrado el diagrama de casos de uso para “Administrar préstamo de acervo”, se
procede a presentar la parte del diagrama de “Registrar préstamo”, la cual se presenta en la Ilustración 6-6. En este sub-subcaso de uso intervienen los actores “Jefe del centro de información”, “Jefa de organización bibliográfica” y “Auxiliares de biblioteca”, correspondientes al personal de la biblioteca de CENIDET, dicho caso de uso tiene incluidos al caso de uso “Validar usuario”, “Validar acervo” y “Validar préstamo”.
uc CU-4.1 Registrar prestamo
CU-4.1 Registrar préstamo
Jefa de organización bibliografica
Auxiliares de biblioteca
CU-1.1.1 Validar usuario
CU-2.1.1 Validar acervo
CU-4.2.1 Validar préstamo de
acerv oJefe del centro de información
«include»
«include»
«include»
Ilustración 6-6. Sub-sub caso de uso de "Registrar préstamo" del diagrama de la Ilustración 6-5
Capítulo 6 Demostración
109
Basado en la Ilustración 6-6, se presenta el documento XMI para “Administrar préstamo de acervo” en el sub-subcaso de uso “Registrar préstamo”, dicho documento se muestra en la Ilustración 6-7.
Para explicar un poco la representación interna, se tiene que cada actor que interviene en el
diagrama, se representó a través de la etiqueta “uml:Actor”, por ejemplo, el actor “Jefa de organización bibliográfica” esta representado en la etiqueta “uml:Actor” con el identificador “A2” y esa etiqueta contiene la etiqueta “Association” que tiene los identificadores “R2”, “R3”, “R16” y “R17”, que representan cada uno una referencia hacia la etiqueta “uml:Association”, donde se especifica el origen y destino de una determinada relación del actor con otro elemento, por ejemplo, con el caso de uso “Registrar préstamo” descrito en la etiqueta “uml:UseCase” con el identificador “CU2”, en la etiqueta “Association” tiene el identificador “R2” , que también tiene el actor “Jefa de organización bibliográfica”, entonces esto indica que ambos elementos están relacionados y esto se especificó en la etiqueta “uml:Association” que tiene el identificador “R2” y la propiedad “type” con “Use” que es el tipo de relación entre los identificadores “A2” y “CU2” que se especifican por medio de las etiquetas “Source” y “Target” respectivamente al origen y destino de la relación.
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDCasosUso.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="CasosUso" name="Administrar préstamo de acervo"> … … … <uml:Actor xmi:id="A2" name="Jefa de organización bibliográfica"> <Association xmi:idref="R2"/> <Association xmi:idref="R3"/> <Association xmi:idref="R16"/> <Association xmi:idref="R17"/> </uml:Actor> … … … <uml:UseCase xmi:id="CU2" name="CU-4.1 Registrar préstamo"> <Association xmi:idref="R2"/> <Association xmi:idref="R11"/> <Association xmi:idref="R12"/> <Association xmi:idref="R13"/>
<Association xmi:idref="R6"/> </uml:UseCase> … … … <uml:UseCase xmi:id="CU7" name="CU-1.1.1 Validar usuario"> <Association xmi:idref="R11"/> </uml:UseCase> … … … <uml:Association xmi:id="R2" name="" type="Use"> <Source xmi:idref="A2"/> <Target xmi:idref="CU2"/> </uml:Association> … … … <uml:Association xmi:id="R11" name="" type="Include"> <Source xmi:idref="CU2"/> <Target xmi:idref="CU7"/> </uml:Association> … … … </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 6-7. Documento XMI para el diagrama de casos de uso de “Administrar préstamo de acervo” en la parte de “Registrar préstamo”
A continuación se muestra el escenario de la Ilustración 6-6 para “Registrar préstamo”, el
cual proviene del diagrama de “Administrar préstamo de acervo” y específicamente este sub-subcaso surge del caso de uso “Solicitar préstamo de acervo” a nivel CIM mostrado en la Ilustración 6-3.
Capítulo 6 Demostración
110
ID: CU-4.1 Nombre de caso
de uso: Registrar préstamo
Creador: Edna D. López López Ultima modificación: Edna D. López López
Fecha de creación:
05/06/07 Fecha de última modificación:
18/06/07
Actores: Jefa de organización bibliográfica, jefe del centro de información o auxiliares de biblioteca.
Descripción: Permite el registro de prestamos de acervo solicitados por un usuario en el Sistema de biblioteca.
Precondiciones: Entrada.- Se introduce el folio del acervo y el número de control del usuario para ser validados. Mecanismo.- Desplegar la ventana “Registrar préstamo” del Sistema de biblioteca.
Poscondiciones: Salida.- Se muestra un mensaje de préstamo registrado. Escenario principal de
éxito: • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
• Se introducirá la información del préstamo como: fecha de préstamo y fecha de entrega.
• Una vez introducida la información correspondiente se presiona en “Registrar”.
• El sistema presenta un mensaje de préstamo registrado. Escenario de fracaso (1): • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
• El sistema manda un mensaje de información incompleta. Escenario de fracaso (2): • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán
Capítulo 6 Demostración
111
validados presionando “Aceptar”. • El sistema manda un mensaje de que el préstamo ya existe.
Escenario de fracaso (3): • La jefa de organización bibliográfica, jefe del centro de información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
• El sistema manda un mensaje de ejemplar repetido. Escenario de fracaso (4): • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
• El sistema manda un mensaje de que el usuario ya tiene 3 prestamos.
Escenario de fracaso (5): • La jefa de organización bibliográfica, jefe del centro de información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
• El sistema manda un mensaje de usuario no encontrado. Escenario de fracaso (6): • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
• El sistema manda un mensaje de acervo no encontrado. Escenario de fracaso (7): • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
Capítulo 6 Demostración
112
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
• El sistema manda un mensaje de acervo no disponible. Escenario de fracaso (8): • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
• Se muestra la ventana de “Administrar préstamo de acervo”. • Posteriormente se seleccionará “Registrar préstamo”. • El sistema presentará una interfaz que permitirá registrar el
préstamo. • La jefa de organización bibliográfica, jefe del centro de
información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
• Se introducirá la información del préstamo como: fecha de préstamo y fecha de entrega.
• Una vez introducida la información correspondiente se presiona en “Registrar”.
• El sistema manda un mensaje indicando que fallo la conexión. Prioridad: Alta
Subcasos de uso: CU-1.1.1, CU-2.1.1, CU-4.2.1
En la Tabla 6-3 se presenta la trazabilidad para el sub-subcaso de uso “Registrar préstamo”, en dicha tabla se muestran los elementos del subdiagrama de casos de uso “Solicitar préstamo de acervo” en el nivel CIM, a partir de los cuales surgieron los elementos del sub-subcaso de uso “Registrar préstamo” a nivel PIM.
Tabla 6-3. Trazabilidad para el sub-subcaso de uso “Registrar préstamo” a nivel PIM Elementos del subdiagrama de Casos de uso “Solicitar
préstamo de acervo” a nivel CIM Elementos del sub-subcaso de uso “Registrar
préstamo” a nivel PIM CU-1 Solicitar préstamo de acervo CU-4.1 Registrar préstamo
6.3.1.4 Nivel PIM Este nivel hereda de los elementos obtenidos en el CIM. El inicio de este nivel empezó con el diagrama de casos de uso (conformado por 1 diagrama principal y 8 sub-casos de uso, de los cuales se desglosan 6), que como se mencionó en el inciso anterior, se obtuvo mediante el diagrama de casos de uso del negocio y de los requerimientos funcionales, ambos del nivel CIM.
Una vez obtenido el diagrama de casos de uso a nivel PIM a través del diagrama de casos de uso del negocio y de los requerimientos funcionales ambos a nivel CIM, se procedió a desarrollar uno de sus casos de uso de “Administrar préstamo de acervo” (conformado por 5 subcasos de uso con sus respectivos escenarios) del cual surgieron los diagramas de secuencia (conformado por 5 diagramas).
Capítulo 6 Demostración
113
Después a partir de los diagramas de secuencia se obtuvieron los diagramas de actividad (conformado por 8 diagramas) y el de clases, el cual también es obtenido mediante el diagrama de clases del negocio y del glosario de términos, ambos a nivel CIM (§ 6.3.1.3). Los diagramas de actividad están relacionados con los diagramas de clases de este nivel.
Por último, el diagrama de la base de datos (base de datos relacional elaborada con la herramienta SQL Management Studio 2006 for PostgreSQL) de este nivel como se mencionó en la sección 6.3.1.3, se obtiene al igual que el diagrama de clases del glosario de términos (ya que a través de éste se obtienen los posibles nombres de las tablas y sus atributos) a nivel CIM y del diagrama de clases del negocio (nivel CIM).
En este nivel se mostrará la trazabilidad entre el diagrama de secuencia y el diagrama de
actividad, para posteriormente bosquejar este último diagrama en la frontera PIM-PSM. Para ello primero se presenta el diagrama de secuencia y después el diagrama de actividad, pues se requiere especificar primero los elementos (del diagrama de secuencia a nivel PIM) que dieron origen al diagrama de actividad a nivel PIM, para posteriormente tomarlos como los elementos origen del diagrama de actividad a nivel PSM.
A continuación se muestra el diagrama de secuencia en la Ilustración 6-8 y posteriormente
se presenta en la Ilustración 6-9 el documento XMI (§ 5.1) de dicho diagrama. Por último, en la Tabla 6-4 se presentan los elementos que dieron origen a los elementos de este diagrama, con lo que se muestra una parte del nivel PIM.
La Ilustración 6-8 presenta el diagrama de secuencia para el sub-subcaso de uso
“Registrar préstamo” a nivel PIM. En este diagrama se reflejan los escenarios especificados para “Registrar préstamo” presentado en la sección 6.3.1.3. El diagrama de secuencia contiene las líneas de vida de “Actor” representada por “Personal de biblioteca” (que engloba a los actores Jefe del centro de información, Jefa de organización bibliográfica y Auxiliares de biblioteca), la línea de vida “Límite” que está representada por “MenuPrincipal”, la “Línea de vida” representada por “PrestamoAcervo” y por último, la línea de vida “Entidad” representada por “ManejoBD”, estas últimas tres líneas de vida representan interfaces, clases y captura de información respectivamente en el diagrama.
Por otro lado, a través de las cuatro líneas de vida del diagrama, se muestra el uso de los
distintos tipos de mensajes con lo que se comunican como: mensajes de llamada “Call” (Ej. “clic en aceptar”), mensajes de retorno “Return” (Ej. Mensaje: (“Información incompleta”)) y mensajes planos “Signal” (Ej. crear pantalla).
Capítulo 6 Demostración
114
sd D-Secuencia(CU-4.1 Registrar préstamo)
PrestamoAcervo
Personal de biblioteca Menu principal ManejoBD
alt
[Respuesta=1]
[else]
alt
[Respuesta=0]
[else]
alt
[Respuesta=1]
[else]
alt
[Respuesta=-1]
[else]
alt
[Respuesta<>0]
alt
[fol io="" OR num_control=""]
[else]
alt
[Respuesta<>1]
clic en administrar préstamo de acervocrear pantalla
Selecciona registrar prestamo
Introduce folio y num_control
cl ic en aceptar
Message:("Información incompleta")
Respuesta=ValidarPrestamo(folio,num_control,0)Respuesta
Message:("Préstamo ya registrado")
Respuesta=.ValidarPrestamo(folio,num_control,3)
Respuesta
Message:("Ejemplar repetido")
Respuesta=ValidarUsuario(num_control)
Respuesta
Message:("Usuario no encontrado")
Respuesta=ValidarPrestamo(folio,num_control,1)
Respuesta
Message:("El usuario ya tiene 3 prestamos")
Respuesta=ValidarAcervo(folio)
Respuesta
Message:("Acervo no encontrado")
Message:("Acervo no disponible")
Introduce fecha de préstamo y fecha de entrega
clic en registrarRegistra los datos
Message:("Préstamo registrado")
Ilustración 6-8. Diagrama de secuencia para el caso de uso “CU-4.1 Registrar préstamo” a nivel PIM
La representación interna del diagrama de secuencia, se presenta en la Ilustración 6-9,
donde se muestran los elementos de línea de vida del diagrama de secuencia a través de la etiqueta “uml:Lifelive”, donde en la propiedad “type” se especifica el tipo de línea de vida, en este caso son: actor, límite, línea de vida y entidad. Para explicar la representación interna de este diagrama, se presenta el siguiente ejemplo: se requiere representar el mensaje de “Acervo no disponible” que sale de la línea de vida “PrestamoAcervo”, para llegar a la línea de vida actor “Personal de biblioteca” y este mensaje esta contenido en el elemento fragmento combinado a través de la condición “Respuesta <> 0”. Esto se representa de la siguiente manera en el documento XMI de dicho diagrama. Primeramente, se representa cada una de las líneas de vida que intervienen a través de la etiqueta “uml:Lifelive” con el identificador “LV1” y el tipo de línea de vida es “Actor” para “Personal de biblioteca” y “uml:Lifelive”
Capítulo 6 Demostración
115
con el identificador “LV3” y el tipo de línea es “Lifelive” para “PrestamoAcervo”, dentro de cada una de estas etiquetas se agrega la etiqueta “Association” para guardar la referencia hacia la etiqueta “uml:Association”, donde se describe la relación (mensaje), la cual tiene el identificador “R19”. La etiqueta “uml:Association”, entonces contiene un identificador “R19” y en la propiedad “type” tiene el tipo “Message”, además tiene otra propiedad que es “Association”, la cual contiene “FN5” que es la referencia al fragmento combinado, donde se encuentra la condición que produce el mensaje. Esta etiqueta también tiene a las etiquetas “Source” y “Target” que especifican los identificadores del origen (PrestamoAcervo) y destino (Personal de biblioteca) del mensaje que son “LV3” y “LV1” respectivamente. El fragmento combinado entonces se representa con la etiqueta “uml:CombinedFragment”, cuyo identificador es “FD5” y el tipo de este fragmento combinado es “alt” (que representa una condición “if”) que se especifica a través de la etiqueta “condition”, que tiene el identificador “C1” y la descripción de la condición en la propiedad “name” para “Respuesta <> 0”, donde los símbolos “<” y “>”, se codifican como “<” y “>” (todos los símbolos que aparezcan en un determinado diagrama serán codificados de acuerdo al lenguaje XMI/XML).
La etiqueta “Condition” tiene contenida otra etiqueta “Association”, cuyo identificador de
referencia es “R19” que es la referencia hacia la etiqueta “uml:Association” que tiene el identificador “R19”.
<xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Sequence" name="Registrar préstamo"> <uml:Lifeline xmi:id="LV1" name="Personal de biblioteca" type="Actor"> <Association xmi:idref="R1"/> <Association xmi:idref="R3"/> <Association xmi:idref="R4"/> <Association xmi:idref="R5"/> <Association xmi:idref="R8"/> <Association xmi:idref="R11"/> <Association xmi:idref="R14"/> <Association xmi:idref="R17"/> <Association xmi:idref="R19"/> <Association xmi:idref="R20"/> <Association xmi:idref="R21"/> <Association xmi:idref="R23"/> <Association xmi:idref="R24"/> <Association xmi:idref="R27"/> </uml:Lifeline> <uml:Lifeline xmi:id="LV2" name="Menu principal" type="Boundary"> <Association xmi:idref="R2"/> </uml:Lifeline> <uml:Lifeline xmi:id="LV3" name="PrestamoAcervo" type="Lifeline"> <Association xmi:idref="R2"/> <Association xmi:idref="R3"/> <Association xmi:idref="R4"/> <Association xmi:idref="R5"/> <Association xmi:idref="R6"/> <Association xmi:idref="R7"/> <Association xmi:idref="R8"/> <Association xmi:idref="R9"/>
<Association xmi:idref="R17"/> <Association xmi:idref="R19"/> <Association xmi:idref="R20"/> <Association xmi:idref="R21"/> <Association xmi:idref="R22"/> <Association xmi:idref="R23"/> <Association xmi:idref="R24"/> <Association xmi:idref="R25"/> <Association xmi:idref="R26"/> <Association xmi:idref="R27"/> </uml:Lifeline> … … … <uml:CombinedFragment xmi:id="FC5" name="" type="alt"> <Condition xmi:id="C1" name="Respuesta<>0"> <Association xmi:idref="R19"/> </Condition> </uml:CombinedFragment> … … … <uml:Association xmi:id="R1" type="Message"> <Source xmi:idref="LV1"/> <Target xmi:idref="LV2"/> <Message name="clic en administrar préstamo de acervo" kind="Signal"/> </uml:Association> … … … <uml:Association xmi:id="R19" type="Message" association="FN5"> <Source xmi:idref="LV3"/> <Target xmi:idref="LV1"/> <Message name="Message:("Acervo no disponible")" kind="Return" /> </uml:Association>
Capítulo 6 Demostración
116
<Association xmi:idref="R10"/> <Association xmi:idref="R11"/> <Association xmi:idref="R12"/> <Association xmi:idref="R13"/> <Association xmi:idref="R14"/> <Association xmi:idref="R15"/> <Association xmi:idref="R16"/>
… … … </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 6-9. Documento XMI para el diagrama de secuencia de la Ilustración 6-8
A continuación se presenta en la Tabla 6-4 la trazabilidad para el diagrama de secuencia de
la Ilustración 6-8. Esta tabla muestra los elementos del escenario del caso de uso “Registrar préstamo”, a partir de los cuales se obtienen los elementos del diagrama de secuencia. Tabla 6-4. Trazabilidad para el Diagrama de secuencia del caso de uso “CU-4.1 Registrar préstamo” nivel PIM
Escenarios del Diagrama de Casos de uso CU-4 Administrar préstamo de acervo subcaso CU-4.1 Registrar préstamo a nivel PIM
Elementos del Diagrama de Secuencia para el caso de uso “CU-4.1 Registrar préstamo” a nivel PIM
La jefa de organización bibliográfica, jefe del centro de información o auxiliares de biblioteca seleccionan “Administrar préstamo de acervo”.
clic en administrar préstamo de acervo
Se muestra la ventana de “Administrar préstamo de acervo”.
crear pantalla
Posteriormente se seleccionará “Registrar préstamo”.
El sistema presentará una interfaz que permitirá registrar el préstamo.
Selecciona registrar préstamo
Introduce folio y num_control La jefa de organización bibliográfica, jefe del centro de información o auxiliares de biblioteca introducirán el folio del acervo y el número de control del usuario los cuales serán validados presionando “Aceptar”.
clic en aceptar
folio="" OR num_control="" El sistema manda un mensaje de información incompleta. Message:("Información incompleta") else Respuesta=ValidarPrestamo(folio,num_control,0) Respuesta Respuesta=1
El sistema manda un mensaje de que el préstamo ya existe.
Message:("Préstamo ya registrado") else Respuesta=.ValidarPrestamo(folio,num_control,3) Respuesta Respuesta=1
El sistema manda un mensaje de ejemplar repetido.
Message:("Ejemplar repetido") else Respuesta=ValidarUsuario(num_control) Respuesta Respuesta=0
El sistema manda un mensaje de usuario no encontrado.
Message:("Usuario no encontrado") else Respuesta=ValidarPrestamo(folio,num_control,1) Respuesta Respuesta=1
El sistema manda un mensaje de que el usuario ya tiene 3 préstamos.
Message:("El usuario ya tiene 3 prestamos") else Respuesta=ValidarAcervo(folio) Respuesta Respuesta=-1
El sistema manda un mensaje de acervo no encontrado.
Message:("Acervo no encontrado") else Respuesta<>0
El sistema manda un mensaje de acervo no disponible.
Message:("Acervo no disponible") Se introducirá la información del préstamo como: fecha de préstamo y fecha de entrega.
Introduce fecha de préstamo y fecha de entrega
clic en registrar
Capítulo 6 Demostración
117
clic en registrar Una vez introducida la información correspondiente se presiona en “Registrar”. Registra los datos El sistema presenta un mensaje de préstamo registrado. Message:("Préstamo registrado")
Después de mostrar el diagrama de secuencia, es hora de presentar los diagramas de
actividad que tienen trazabilidad con el diagrama de secuencia. El primer diagrama de actividad a mostrar es el de “Registrar” que se presenta en la
Ilustración 6-10 y posteriormente se presenta en la Ilustración 6-11 el documento XMI (§ 5.1) de dicho diagrama. Por último, en la Tabla 6-5 se presentan los elementos que dieron origen a los elementos de este diagrama, con lo que se muestra una parte del nivel PIM.
A continuación se presenta el diagrama de actividad “Registrar” a nivel PIM en la Ilustración 6-10, donde se describe una de las partes del diagrama de secuencia presentado en la Ilustración 6-8. En este diagrama de actividad, se realizan las actividades en base a las instrucciones para guardar el préstamo de acervo en la tabla “PrestamoAcervo”, además se actualiza la tabla “Acervo”, para ponerlo en estado ocupado en un determinado acervo y por último, se guarda información del préstamo en la tabla de “Estadísticas de préstamo”, de forma general es lo que presenta este diagrama. El elemento “nodo inicial” contiene “PrestamoAcervo::Registrar():default”, que significa que antes de los cuatro puntos se pone el nombre de la clase y después de los cuatro puntos va el nombre del método que se va a desarrollar y por último, después de los dos puntos irá el tipo de retorno del método.
act Registrar
PrestmoAcervo::Registrar():default
ResultSet RespuestaAcerv o String titulo=""
Principal.MBD.Actualizar("Insert into PrestamoAcerv o v alues('" +Folio+ "','" +NumControl+ "','" +FechaPrestamo+ "','"+FechaEntrega+"')")
Principal.MBD.Actualizar("update Acerv o set Estatus=true where Folio='"+Folio+"'")
RespuestaAcerv o=Principal.MBD.EjecutarQuery("select Titulo from Acerv o where Folio= '"+Folio+"'")
titulo=RespuestaAcerv o("Titulo")
Principal.MBD.Actualizar("Insert into EstadisticasPrestamos v alues('" +titulo+ "','" +FechaPrestamo+ "')")
Message:("Préstamo registrado")
[else]
[RespuestaAcervo<>""]
Ilustración 6-10. Diagrama de actividad “Registrar” a nivel PIM
En la Ilustración 6-11 se presenta el documento XMI para el diagrama de actividad
“Registrar” a nivel PIM. Para explicar la representación interna, se muestra un pequeño
Capítulo 6 Demostración
118
ejemplo de dicho diagrama. Por ejemplo, se requiere presentar la relación del elemento de “Decisión” al elemento “Merge”, relacionados a través de la condición “else”, lo cual se realiza de la siguiente manera: primero se utiliza la etiqueta “uml:DecisionNode”, la cual contiene el identificador “DN1” que representa al elemento “Decisión”, dicha etiqueta contiene otras etiquetas como “Association”, donde se especifican los identificadores de referencia hacia la etiqueta “uml:Association”. La etiqueta “uml:DecisionNode” contiene tres etiquetas “Association” que tienen los identificadores “R5”, “R6” y “R8” que son las referencias hacia cada una de las etiquetas “uml:Association”, donde se describe cada una de las relaciones del elemento “Decisión”. El identificador que define la relación del elemento “Decisión” al elemento “Merge” a través de la condición “else” es la etiqueta “uml:Association” con el identificador “R6”, esta etiqueta contiene dos etiquetas que son “Source” que tiene el identificador “DN1” que hace referencia al identificador del elemento “Decisión” y “Target” con el identificador “DN2” que hace referencia al identificador del elemento “Merge”. Las propiedades de la etiqueta “uml:Association” son “type” donde se especifica el tipo de línea con la cual se relacionan los dos elementos que es “ControlFlow” y la propiedad “name”, donde se introduce la condición “else”, referente al nombre del mensaje. Ambos elementos “Decisión” y “Merge” se representan con la etiqueta “uml:DecisionNode” respectivamente y lo que los distingue uno de otro es por la propiedad “type” de dicha etiqueta, donde se especifica si es “Decisión” o “Merge”, además de sus respectivos identificadores.
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDActividad.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Activity" name="Registrar"> <uml:InitialNode xmi:id="IN1" name="PrestamoAcervo::Registrar():default"> <Association xmi:idref="R1"/> </uml:InitialNode> … … … <uml:Activity xmi:id="AN4" name="RespuestaAcervo=Principal.MBD.EjecutarQuery("select Titulo from Acervo where Folio= '"+Folio+"'")"> <Association xmi:idref="R4"/> <Association xmi:idref="R5"/> </uml:Activity> … … … <uml:Activity xmi:id="AN7" name="Message:("Préstamo registrado")"> <Association xmi:idref="R10"/> <Association xmi:idref="R11"/> </uml:Activity> <uml:DecisionNode xmi:id="DN1" name="" type="Decision"> <Association xmi:idref="R5"/> <Association xmi:idref="R6"/> <Association xmi:idref="R8"/>
</uml:DecisionNode> <uml:DecisionNode xmi:id="DN1" name="" type="Merge"> <Association xmi:idref="R6"/> <Association xmi:idref="R7"/> <Association xmi:idref="R11"/> </uml:DecisionNode> <uml:FinalNode xmi:id="FN1" name=""> <Association xmi:idref="R6"/> <Association xmi:idref="R7"/> </uml:FinalNode> … … … <uml:Association xmi:id="R6" name="else" type="ControlFlow"> <Source xmi:idref="DN1"/> <Target xmi:idref="DN2"/> </uml:Association> <uml:Association xmi:id="R7" name="" type="ControlFlow"> <Source xmi:idref="DN2"/> <Target xmi:idref="FN1"/> </uml:Association> … … … <uml:Association xmi:id="R11" name="" type="ControlFlow"> <Source xmi:idref="AN7"/> <Target xmi:idref="DN2"/> </uml:Association> </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 6-11. Documento XMI para el diagrama de actividad de la Ilustración 6-10
Capítulo 6 Demostración
119
Una vez presentado el diagrama de actividad “Registrar” y su representación interna, se procede a mostrar la trazabilidad de dicho diagrama en la Tabla 6-5, donde los elementos parten de un fragmento del diagrama de secuencia, ya que de este diagrama, se obtuvieron dos diagramas de actividad, de los cuales aquí se presentan los elementos del diagrama de actividad “Registrar” que surgieron del diagrama de secuencia.
Tabla 6-5. Trazabilidad para el Diagrama de actividad “Registrar” nivel PIM
Elementos del Diagrama de Secuencia para el caso de uso “CU-4.1 Registrar préstamo” a nivel PIM
Elementos del Diagrama de actividad “Registrar” a nivel PIM
Introduce fecha de préstamo y fecha de entrega clic en registrar
PrestamoAcervo::Registrar():default
ResultSet RespuestaAcervo String titulo="" Principal.MBD.Actualizar("Insert into PrestamoAcervo values('" +Folio+ "','" +NumControl+ "','" +FechaPrestamo+ "','" +FechaEntrega+"')") Principal.MBD.Actualizar("update Acervo set Estatus=true where Folio='"+Folio+"'") RespuestaAcervo=Principal.MBD.EjecutarQuery ("select Titulo from Acervo where Folio= '"+Folio+"'") RespuestaAcervo<>”” titulo=RespuestaAcervo("Titulo")
Registra los datos
Principal.MBD.Actualizar("Insert into EstadisticasPrestamos values('" +titulo+ "','" +FechaPrestamo+ "')")
Message:("Préstamo registrado") Message:("Préstamo registrado")
El segundo diagrama de actividad a mostrar es el de “AceptarRegistro” que se presenta en
la Ilustración 6-12 y posteriormente se presenta en la Ilustración 6-13 el documento XMI (§ 5.1) de dicho diagrama.
Por último, en la Tabla 6-6 se presentan los elementos que dieron origen a los elementos
de este diagrama, con lo que se muestra otra parte del nivel PIM.
En la Ilustración 6-12, se presenta el diagrama de actividad “AceptarRegistro” que representa las instrucciones para verificar cada una de las alternativas que pudieran impedir el préstamo de acervo para pasarlo a registrar. El elemento “nodo inicial” contiene “PrestamoAcervo::AceptarRegistro():default”, que significa que antes de los cuatro puntos se pone el nombre de la clase y después de los cuatro puntos va el nombre del método que se va a desarrollar y por último, después de los dos puntos irá el tipo de retorno del método.
Capítulo 6 Demostración
120
act AceptarRegistro
PrestamoAcervo::AceptarRegistro():default
Respuesta=Principal.MBD.ValidarPrestamo(Folio,NumControl,0)
Respuesta=Principal.MBD.ValidarUsuario(NumControl)
Message:("Usuario no encontrado")
Message:("Préstamo ya registrado")
Respuesta=Principal.MBD.ValidarPrestamo(Folio,NumControl,1)
Message:("El usuario ya tiene 3 prestamos")
Respuesta=Principal.MBD.ValidarAcervo(Folio)
Message:("Acervo no encontrado")
Message:("Acerv o no disponible")
Respuesta=Principal.MBD.ValidarPrestamo(jTextFieldFolio,jTextFieldNumControl,3)
Message:("Ejemplar repetido")
Message:("Información incompleta")
[Respuesta==1][else]
[Respuesta==0]
[else]
[Respuesta==1]
[else]
[Respuesta==-1]
[else]
[else]
[Respuesta<>0]
[else]
[Respuesta==1]
[folio="" OR num_control=""]
Ilustración 6-12. Diagrama de actividad “AceptarRegistro” a nivel PIM
A continuación en la Ilustración 6-13, se presenta la representación interna del diagrama
de actividad “AceptarRegistro”. Dicha representación interna se explica a través de unos elementos del diagrama de actividad. Por ejemplo, el elemento “nodo inicial” se relaciona con el elemento “Decisión” al principio del diagrama de actividad. Para plasmar esto en la representación interna, se realizó lo siguiente: se especifica la etiqueta “uml:InitialNode” para representar al elemento “nodo inicial”, donde va a contener el identificador “IN1” y en la propiedad “name” tiene “PrestamoAcervo::AceptarRegistro():default”, posteriormente esta etiqueta contiene a la etiqueta “Association” para guardar la referencia “R1” hacia la etiqueta “uml:Association” que tiene la descripción de la relación de “nodo inicial” con el nodo de “Decisión”.
Después se especifica la etiqueta “uml:DecisionNode” con el identificador “DN1” y el
tipo de nodo de decisión en la propiedad “type” de esta etiqueta es “Decision”, esta etiqueta al igual que la etiqueta “uml:InitialNode” contendrá la etiqueta “Association” con el identificador de referencia “R1” hacia la etiqueta “uml:Association”, donde dicha etiqueta tiene el identificador “R1” y en la propiedad “type” el tipo de línea es “ControlFlow”, esa
Capítulo 6 Demostración
121
etiqueta también contiene dos etiquetas que son “Source” y “Target” que representan el identificador del origen y destino de la relación, que es “IN1” que hace referencia a la etiqueta “uml:InitialNode” y “DN1” que hace referencia a la etiqueta “uml:DecisionNode” respectivamente.
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDActividad.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Activity" name="AceptarRegistro"> <uml:InitialNode xmi:id="IN1" name="PrestamoAcervo ::AceptarRegistro():default"> <Association xmi:idref="R1"/> </uml:InitialNode> ... ... ... <uml:Activity xmi:id="AN3" name="Respuesta=Principal.MBD.ValidarUsuario(NumControl)"> <Association xmi:idref="R24"/> <Association xmi:idref="R5"/> </uml:Activity> <uml:Activity xmi:id="AN4" name="Message:(" Usuario no encontrado")"> <Association xmi:idref="R6"/> <Association xmi:idref="R18"/> </uml:Activity> <uml:Activity xmi:id="AN5" name="Respuesta=Principal.MBD.ValidarPrestamo(Folio,NumControl,1)"> <Association xmi:idref="R7"/> <Association xmi:idref="R8"/> </uml:Activity> ... ... ... <uml:DecisionNode xmi:id="DN1" name="" type="Decision"> <Association xmi:idref="R1"/> <Association xmi:idref="R2"/> <Association xmi:idref="R3"/> </uml:DecisionNode> ... ...
... <uml:DecisionNode xmi:id="DN6" name="" type="Merge"> <Association xmi:idref="R17"/> <Association xmi:idref="R18"/> <Association xmi:idref="R19"/> ... ... ... </uml:DecisionNode> ... ... ... <uml:FinalNode xmi:id="FN1" name=""> <Association xmi:idref="R21"/> </uml:FinalNode> ... ... ... <uml:Association xmi:id="R1" name="" type="ControlFlow"> <Source xmi:idref="IN1"/> <Target xmi:idref="DN1"/> </uml:Association> ... ... ... <uml:Association xmi:id="R18" name="" type="ControlFlow"> <Source xmi:idref="AN4"/> <Target xmi:idref="DN6"/> </uml:Association> ... ... ... <uml:Association xmi:id="R21" name="" type="ControlFlow"> <Source xmi:idref="DN6"/> <Target xmi:idref="FN1"/> </uml:Association> ... ... ... </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 6-13. Documento XMI para el diagrama de actividad de la Ilustración 6-12
En la Tabla 6-6, se muestra la trazabilidad para el diagrama de actividad
“AceptarRegistro” de la Ilustración 6-12. En dicha tabla, se presentan los elementos que provienen de los fragmentos restantes del diagrama de secuencia mostrado en la Ilustración 6-8 (la otra parte de este diagrama, se presento en el diagrama de actividad “Registrar”) a partir de los cuales se obtuvieron los elementos del diagrama de actividad “AceptarRegistro”.
Capítulo 6 Demostración
122
Tabla 6-6. Trazabilidad para el Diagrama de actividad “AceptarRegistro” nivel PIM Elementos del Diagrama de Secuencia para el caso de uso “CU-4.1 Registrar préstamo” a nivel PIM
Elementos del Diagrama de actividad “AceptarRegistro” a nivel PIM
clic en administrar préstamo de acervo crear pantalla Selecciona registrar préstamo Introduce folio y num_control clic en aceptar
PrestamoAcervo::AceptarRegistro():default
folio="" OR num_control="" folio="" OR num_control="" Message:("Información incompleta") Message:("Información incompleta") else else
Respuesta=ValidarPrestamo(folio,num_control,0) Respuesta
Respuesta=Principal.MBD.ValidarPrestamo (Folio,NumControl,0)
Respuesta=1 Respuesta==1 Message:("Préstamo ya registrado") Message:("Préstamo ya registrado") else else Respuesta=.ValidarPrestamo(folio,num_control,3) Respuesta
Respuesta=Principal.MBD.ValidarPrestamo (jTextFieldFolio,jTextFieldNumControl,3)
Respuesta=1 Respuesta==1 Message:("Ejemplar repetido") Message:("Ejemplar repetido") else else Respuesta=ValidarUsuario(num_control) Respuesta
Respuesta= Principal.MBD.ValidarUsuario(NumControl)
Respuesta=0 Respuesta==0 Message:("Usuario no encontrado") Message:("Usuario no encontrado") else else Respuesta=ValidarPrestamo(folio,num_control,1) Respuesta
Respuesta= Principal.MBD.ValidarPrestamo (Folio,NumControl,1)
Respuesta=1 Respuesta==1 Message:("El usuario ya tiene 3 prestamos") Message:("El usuario ya tiene 3 prestamos") else else Respuesta=ValidarAcervo(folio) Respuesta
Respuesta= Principal.MBD.ValidarAcervo(Folio)
Respuesta=-1 Respuesta==-1 Message:("Acervo no encontrado") Message:("Acervo no encontrado") else else Respuesta<>0 Respuesta<>0 Message:("Acervo no disponible") Message:("Acervo no disponible")
6.3.1.5 Cruce de la frontera PIM-PSM Esta frontera se inició con la transformación del diagrama de clases a nivel PIM al diagrama de clases del nivel PSM, en la cual las clases que se muestran están enfocadas solamente a mostrar la parte de “Administrar préstamo de acervo” que se desarrolló en la demostración del Reporte Técnico RT-DCC-1-2007.
Después, del diagrama de base de datos del nivel PIM se obtuvo el diagrama de bases de datos del nivel PSM y por último, del diagrama de actividad (conformado por 8 diagramas) del nivel PIM se obtuvo el diagrama de actividad (conformado por 8 diagramas) del nivel PSM.
Es importante mostrar los tipos de datos, operadores y otras definiciones que se
especificaron, para utilizarlas a nivel PIM en los diagramas, para realizar la trazabilidad con el nivel PSM, que a continuación se muestran:
Capítulo 6 Demostración
123
Tipos de datos Nombre Descripción
String Cadena de caracteres (char, string, etc.) Integer Número entero (int, long, etc.) Real Número real (float, double, etc.) Bolean Falso o verdadero Date Tipo fecha Text Tipo texto, se utilizara primordialmente para la descripción de la base de datos.
Operadores aritméticos, de comparación y lógicos Símbolo Descripción
+ Suma - Resta * Multiplicación / División =, == Igual de asignación , igual de comparación <> Diferente <,>,<=,>= Menor que, mayor que, menor o igual que, mayor o igual que AND La expresión será verdadera si y sólo si ambas expresiones son verdades. OR La expresión será verdadera si al menos una expresión es verdadera.
Otros Nombre Descripción
Default Es como tipo void en C++ o java, dependiendo del lenguaje es el default que tendrá a nivel PSM.
else Significa “sino” en un condicional, ya sea diagramas de secuencia o actividad. “” Vació ResultSet Proporciona el acceso a una tabla de datos generados mediante la ejecución de una
sentencia. Message Que significa que se va a mostrar un mensaje en el sistema, por ejemplo, cuando en C++
se pone cout ó en jBuilder se pone JOptionPanel.ShowMessageDialog, etc.
En la Ilustración 6-14 y en la Ilustración 6-16 se presentan los diagramas de actividad a nivel PSM para mostrar como se obtuvieron a partir de los diagramas de actividad del nivel PIM, donde con todo esto se ve reflejado un fragmento de la frontera PIM-PSM.
A continuación se presenta la Ilustración 6-14 del diagrama de actividad “Registrar” a nivel PSM que se obtiene a partir del diagrama de actividad “Registrar” a nivel PIM. El diagrama de actividad a nivel PSM proviene de la clase “PrestamoAcervo” del método “jButtonRegistrar”.
Posteriormente, a dicha ilustración se muestra en la Ilustración 6-15 el documento XMI (§
5.1) de dicho diagrama y por último, en la Tabla 6-7 se presentan los elementos que dieron origen a los elementos de este diagrama, con lo que se muestra una parte de la frontera PIM-PSM.
De la misma forma en que se mostró el diagrama de actividad “Registrar” a nivel PIM
(Ilustración 6-10), se presenta el diagrama de actividad “Registrar” a nivel PSM en la Ilustración 6-14, donde la diferencia entre ambos es que en el nivel PSM, se realizaron las instrucciones en cada uno de los elementos de acuerdo al lenguaje java y a PostgreSQL para la base de datos, además que se agrega un elemento más a este diagrama con respecto al manejo de fechas.
Capítulo 6 Demostración
124
act Registrar
PrestamoAcervo::jButtonRegistrar_actionPerformed(e:ActionEvent):void
Date FechaA = this.jDateChooserFechaEntrega.getDate(); SimpleDateFormat Formato = new SimpleDateFormat("yyyy/MM/dd");
String FechaEntrega = Formato.format(FechaA);
ResultSet RespuestaAcerv o; String titulo="";
Principal.MBD.Actualizar("Insert into PrestamoAcerv o v alues('" +jTextFieldFolio.getText() + "','" +jTextFieldNumControl.getText() + "','" +jTextFieldFechaPrestamo.getText() + "','" +FechaEntrega+ "')");
Principal.MBD.Actualizar("update Acerv o set Estatus=true where Folio='"+jTextFieldFolio.getText()+"'");
RespuestaAcerv o=Principal.MBD.EjecutarQuery("select Titulo from Acerv o where Folio= '"+ jTextFieldFolio.getText()+"'");
titulo=RespuestaAcerv o.getString("Titulo");
Principal.MBD.Actualizar("Insert into EstadisticasPrestamos v alues('" +titulo+ "','" +jTextFieldFechaPrestamo.getText() + "')");
JOptionPane.showMessageDialog(null,"Préstamo registrado", "Sistema Biblioteca",JOptionPane.INFORMATION_MESSAGE);
[else]
[RespuestaAcervo.next()]
Ilustración 6-14. Diagrama de actividad “Registrar” a nivel PSM
En la Ilustración 6-15 se muestra el documento XMI para el diagrama de actividad “Registrar” a nivel PSM, donde se representan los mismos elementos que en el diagrama de actividad “Registrar” a nivel PIM (Ilustración 6-10), pero agregando un elemento más que tiene este diagrama a nivel PSM con respecto al diagrama del nivel PIM, por lo cual la diferencia del diagrama a nivel PIM con el diagrama a nivel PSM es en cuanto a los identificadores de cada elemento y de sus relaciones, ya que se añadió un nuevo elemento, se modifican, así como la información contenida en cada etiqueta, cambia debido a que ahora está enfocada hacia el lenguaje “java” y al manejador de la base de datos en “PostgreSQL”.
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDActividad.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Activity" name="Registrar"> <uml:InitialNode xmi:id="IN1" name="PrestamoAcervo::jButtonRegistrar_actionPerformed(e:ActionEvent):void"> <Association xmi:idref="R1"/> </uml:InitialNode> … … … <uml:Activity xmi:id="AN5" name="RespuestaAcervo=Principal.MBD.EjecutarQuery("select Titulo from Acervo where Folio= '"+
<Association xmi:idref="R6"/> <Association xmi:idref="R7"/> <Association xmi:idref="R9"/> </uml:DecisionNode> <uml:DecisionNode xmi:id="DN1" name="" type="Merge"> <Association xmi:idref="R7"/> <Association xmi:idref="R8"/> <Association xmi:idref="R14"/> </uml:DecisionNode> <uml:FinalNode xmi:id="FN1" name=""> <Association xmi:idref="R8"/> </uml:FinalNode> … … ... <uml:Association xmi:id="R7" name="else" type="ControlFlow"> <Source xmi:idref="DN1"/> <Target xmi:idref="DN2"/> </uml:Association> <uml:Association xmi:id="R8" name=""
Capítulo 6 Demostración
125
jTextFieldFolio.getText()+"'");"> <Association xmi:idref="R5"/> <Association xmi:idref="R6"/> </uml:Activity> … … … <uml:Activity xmi:id="AN10" name="JOptionPane.showMessageDialog(null,"Préstamo registrado", "Sistema Biblioteca",JOptionPane.INFORMATION_MESSAGE);"> <Association xmi:idref="R11"/> <Association xmi:idref="R14"/> </uml:Activity> <uml:DecisionNode xmi:id="DN1" name="" type="Decision">
type="ControlFlow"> <Source xmi:idref="DN2"/> <Target xmi:idref="FN1"/> </uml:Association> ... ... ... <uml:Association xmi:id="R14" name="" type="ControlFlow"> <Source xmi:idref="AN10"/> <Target xmi:idref="DN2"/> </uml:Association> </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 6-15. Documento XMI para el diagrama de actividad de la Ilustración 6-14
Una vez obtenido el diagrama de actividad “Registrar” a nivel PSM y su representación
interna (documento XMI), es necesario mostrar los elementos del diagrama de actividad “Registrar” a nivel PIM, de los cuales surgieron los elementos de este diagrama a nivel PSM, por ello en la Tabla 6-7, se presenta dicha trazabilidad.
Tabla 6-7. Trazabilidad para el Diagrama de actividad “Registrar” a nivel PSM Elementos del Diagrama de actividad “Registrar” a nivel PIM
Diagrama de actividad “Registrar” a nivel PSM
PrestmoAcervo::Registrar():default PrestamoAcervo::jButtonRegistrar_ actionPerformed(e:ActionEvent):void
ResultSet RespuestaAcervo String titulo="" ResultSet RespuestaAcervo; String titulo=""; Date FechaA = this.jDateChooserFechaEntrega. getDate(); SimpleDateFormat Formato = new SimpleDateFormat("yyyy/MM/dd"); S String FechaEntrega = Formato.format(FechaA);
Principal.MBD.Actualizar("Insert into PrestamoAcervo values('" +Folio+ "','" +NumControl+ "','" +FechaPrestamo+ "','" +FechaEntrega+"')")
Principal.MBD.Actualizar("Insert into PrestamoAcervo values('"+jTextFieldFolio.getText() + "','" +jTextFieldNumControl.getText() + "','" + jTextFieldFechaPrestamo.getText() + "','" + FechaEntrega+ "')");
Principal.MBD.Actualizar("update Acervo set Estatus=true where Folio='"+Folio+"'")
Principal.MBD.Actualizar("update Acervo set Estatus=true where Folio='"+jTextFieldFolio.getText()+"'");
RespuestaAcervo= Principal.MBD.EjecutarQuery("select Titulo from Acervo where Folio= '"+Folio+"'")
RespuestaAcervo=Principal.MBD.EjecutarQuery(" select Titulo from Acervo where Folio= '"+ jTextFieldFolio.getText()+"'");
RespuestaAcervo<>”” RespuestaAcervo.next() titulo=RespuestaAcervo("Titulo") titulo=RespuestaAcervo.getString("Titulo"); Principal.MBD.Actualizar("Insert into EstadisticasPrestamos values('" +titulo+ "','" +FechaPrestamo+ "')")
Principal.MBD.Actualizar("Insert into EstadisticasPrestamos values('" +titulo+ "','" + jTextFieldFechaPrestamo.getText() + "')");
Message:("Préstamo registrado") JOptionPane.showMessageDialog (null, "Préstamo registrado", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
A continuación se presenta la Ilustración 6-16 del diagrama de actividad
“AceptarRegistro” (nivel PSM) que se obtuvo a partir del diagrama de actividad “AceptarRegistro” (nivel PIM). Donde la diferencia entre estos diagramas es el tipo de datos y instrucciones que se manejaron, a nivel PSM son de acuerdo al lenguaje java y al manejador de base de datos de PostGreSQL y a nivel PIM no se enfocaron a ningún lenguaje, ni manejador, ya que es un nivel independiente de plataforma. El diagrama de actividad a nivel PSM proviene de la clase “PrestamoAcervo” del método “jButtonAceptarRegistro”. En este
Capítulo 6 Demostración
126
diagrama a nivel PSM se agregaron dos elementos (con respecto al manejo de fechas) más que no se tenían a nivel PIM. Posteriormente, a dicha ilustración se muestra en la Ilustración 6-17 el documento XMI (§ 5.1) de dicho diagrama y por último, en la Tabla 6-8 se presentan los elementos que dieron origen a los elementos de este diagrama, con lo que se muestra otra parte de la frontera PIM-PSM.
act AceptarRegistro
PrestamoAcervo::jButtonAceptarRegistro(e:ActionEvent):void
JOptionPane.showMessageDialog(null,"Información incompleta", "Sistema
Biblioteca",JOptionPane.INFORMATION_MESSAGE);
Respuesta=Principal.MBD.ValidarPrestamo(jTextFieldFolio.getText(),jTextFieldNumControl.getText(),0);
Respuesta=Principal.MBD.ValidarUsuario(jTextFieldNumControl.getText());
JOptionPane.showMessageDialog(null,"Usuario noencontrado","Sistema
Biblioteca",JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null,"Préstamo yaregistrado", "Sistema
Biblioteca",JOptionPane.INFORMATION_MESSAGE);
Respuesta=Principal.MBD.ValidarPrestamo(jTextFieldFolio.getText(),jTextFieldNumControl.getText(),1);
JOptionPane.showMessageDialog(null,"El usuario yatiene 3 prestamos", "Sistema
Biblioteca",JOptionPane.INFORMATION_MESSAGE);
Respuesta=Principal.MBD.ValidarAcerv o(jTextFieldFolio.getText());
JOptionPane.showMessageDialog(null,"Acerv o noencontrado","Sistema
Biblioteca",JOptionPane.INFORMATION_MESSAGE);
Date FechaActual= new Date();
JOptionPane.showMessageDialog(null,"Acervo nodisponible","Sistema
Biblioteca",JOptionPane.INFORMATION_MESSAGE);
SimpleDateFormat FormatoFecha=new SimpleDateFormat("yyyy/MM/dd"); jTextFieldFechaPrestamo.setText(FormatoFecha.format(FechaActual));
Respuesta=Principal.MBD.ValidarPrestamo(jTextFieldFolio.getText(),jTextFieldNumControl.getText(),3);
JOptionPane.showMessageDialog(null,"Ejemplarrepetido", "Sistema
Biblioteca",JOptionPane.INFORMATION_MESSAGE);
[else]
[else]
[Respuesta==1]
[Respuesta==0]
[else]
[Respuesta==1]
[else]
[Respuesta==-1]
[jTextFieldFolio.getText().equals("") II jTextFieldNumControl.getText().equals("")]
[else]
[Respuesta<>0]
[else]
[else]
[Respuesta==1]
Ilustración 6-16. Diagrama de actividad “AceptarRegistro” a nivel PSM
En la Ilustración 6-17, se presenta el documento XMI para el diagrama de actividad “AceptarRegistro” a nivel PSM, donde se representan los mismos elementos que en el diagrama de actividad “AceptarRegistro” a nivel PIM (Ilustración 6-12), pero añadiendo dos elementos más que tiene este diagrama a nivel PSM. Lo único que diferencia a dichos diagramas en el documento XMI es con respecto a los identificadores de cada elemento y de sus relaciones, así como la forma en que se expresa la información contenida en cada elemento, está de acuerdo al lenguaje java y al manejador PostgreSQL (para la base de datos).
Capítulo 6 Demostración
127
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDActividad.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Activity" name="AceptarRegistro"> <uml:InitialNode xmi:id="IN1" name="PrestamoAcervo::jButtonAceptarRegistro(e:ActionEvent):void"> <Association xmi:idref="R1"/> </uml:InitialNode> … … … <uml:Activity xmi:id="AN4" name="Respuesta=Principal.MBD.ValidarUsuario(jTextFieldNumControl.getText());"> <Association xmi:idref="R29"/> <Association xmi:idref="R7"/> </uml:Activity> <uml:Activity xmi:id="AN5" name="JOptionPane.showMessageDialog(null,"Usuario no encontrado","Sistema Biblioteca",JOptionPane.INFORMATION_MESSAGE);"> <Association xmi:idref="R8"/> <Association xmi:idref="R22"/> </uml:Activity> <uml:Activity xmi:id="AN6" name="Respuesta=Principal.MBD.ValidarPrestamo(jTextFieldFolio.getText(),jTextFieldNumControl.getText(),1);"> <Association xmi:idref="R9"/> <Association xmi:idref="R10"/> </uml:Activity> … … … <uml:DecisionNode xmi:id="DN1" name="" type="Decision"> <Association xmi:idref="R1"/> <Association xmi:idref="R2"/>
<Association xmi:idref="R3"/> </uml:DecisionNode> … … … <uml:DecisionNode xmi:id="DN7" name="" type="Merge"> <Association xmi:idref="R20"/> <Association xmi:idref="R21"/> <Association xmi:idref="R22"/> <Association xmi:idref="R23"/> <Association xmi:idref="R24"/> <Association xmi:idref="R25"/> <Association xmi:idref="R26"/> <Association xmi:idref="R30"/> </uml:DecisionNode> … … … <uml:FinalNode xmi:id="FN1" name=""> <Association xmi:idref="R26"/> </uml:FinalNode> … ... ... <uml:Association xmi:id="R22" name="" type="ControlFlow"> <Source xmi:idref="AN5"/> <Target xmi:idref="DN7"/> </uml:Association> ... ... ... <uml:Association xmi:id="R26" name="" type="ControlFlow"> <Source xmi:idref="DN7"/> <Target xmi:idref="FN1"/> </uml:Association> ... … … </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 6-17. Documento XMI para el diagrama de actividad de la Ilustración 6-16
En la Tabla 6-8, se muestra la trazabilidad para el diagrama de actividad
“AceptarRegistro” a nivel PSM, de acuerdo a los elementos del diagrama de actividad “AceptarRegistro” a nivel PIM, surgen los elementos de este diagrama a nivel PSM.
Tabla 6-8. Trazabilidad para el Diagrama de actividad “AceptarRegistro” a nivel PSM Elementos del Diagrama de actividad “AceptarRegistro” a nivel PIM
Diagrama de actividad “AceptarRegistro” a nivel PSM
PrestamoAcervo::AceptarRegistro():default PrestamoAcervo::jButtonAceptarRegistro (e:ActionEvent):void
folio="" OR num_control="" jTextFieldFolio.getText().equals("") II jTextFieldNumControl.getText().equals("")
Message:("Información incompleta") JOptionPane.showMessageDialog(null," Información incompleta", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
else else Respuesta= Principal.MBD.ValidarPrestamo(Folio,NumControl,0)
Respuesta=Principal.MBD.ValidarPrestamo (jTextFieldFolio.getText(), jTextFieldNumControl.getText(),0);
Capítulo 6 Demostración
128
Respuesta==1 Respuesta==1 Message:("Préstamo ya registrado") JOptionPane.showMessageDialog(null,"Préstamo ya
registrado", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
else else Respuesta=Principal.MBD.ValidarPrestamo (jTextFieldFolio,jTextFieldNumControl,3)
Respuesta=Principal.MBD.ValidarPrestamo (jTextFieldFolio.getText(), jTextFieldNumControl.getText(),3);
Respuesta==1 Respuesta==1 Message:("Ejemplar repetido") JOptionPane.showMessageDialog(null,"Ejemplar repetido",
"Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
else else Respuesta= Principal.MBD.ValidarUsuario(NumControl) Respuesta=Principal.MBD.ValidarUsuario
(jTextFieldNumControl.getText()); Respuesta==0 Respuesta==0 Message:("Usuario no encontrado") JOptionPane.showMessageDialog(null,"Usuario no
encontrado","Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
else else Respuesta= Principal.MBD.ValidarPrestamo(Folio,NumControl,1)
Respuesta=Principal.MBD.ValidarPrestamo (jTextFieldFolio.getText(), jTextFieldNumControl.getText(),1);
Respuesta==1 Respuesta==1 Message:("El usuario ya tiene 3 prestamos") JOptionPane.showMessageDialog(null,"El usuario ya tiene 3
prestamos", "Sistema Biblioteca" ,JOptionPane.INFORMATION_MESSAGE);
else else Respuesta= Principal.MBD.ValidarAcervo(Folio) Respuesta=Principal.MBD.ValidarAcervo
(jTextFieldFolio.getText()); Respuesta==-1 Respuesta==-1 Message:("Acervo no encontrado") JOptionPane.showMessageDialog(null,"Acervo no
encontrado","Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
else else Respuesta<>0 Respuesta<>0 Message:("Acervo no disponible") JOptionPane.showMessageDialog(null,"Acervo no
disponible","Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE); else Date FechaActual= new Date();
(Sirve para poner la fecha de préstamo actual, sirviendo para la captura de información)
SimpleDateFormat FormatoFecha=new SimpleDateFormat("yyyy/MM/dd"); jTextFieldFechaPrestamo.setText (FormatoFecha.format(FechaActual));
6.3.1.6 Nivel PSM Este nivel se conformó de los elementos obtenidos en el nivel PIM. El desarrollo de este nivel esta dirigido por el lenguaje de programación de “java”, la base de datos por “PostgreSQL” y el ambiente de desarrollo por “JBuilder”.
Este nivel se inició con el diagrama de base de datos a nivel PSM que se obtuvo del diagrama de base de datos a nivel PIM, donde intervienen cuestiones de tipos más específicos de acuerdo a “PostgreSQL”.
Posteriormente, el diagrama de clases a nivel PSM se obtuvo a partir del diagrama de
clases del nivel PIM, en el cual se agregan más relaciones y clases debido al ambiente en el que se está desarrollando (JBuilder), ya que se agregan clases prefabricadas necesarias para el desarrollo del sistema.
Capítulo 6 Demostración
129
Por último, los diagramas de actividad a nivel PSM se obtuvieron de los diagramas de actividad a nivel PIM, de igual forma, se consideran los detalles de implementación necesarios en el manejo de las instrucciones de acuerdo al lenguaje y ambiente de desarrollo para el sistema de biblioteca.
Para bosquejar una parte de los diagramas utilizados en este nivel, a continuación se
presenta en la Ilustración 6-18 el diagrama de clases que en la clase “PrestamoAcervo” incluye los métodos “jButtonRegistrar” y “jButtonAceptarRegistro” que provienen (son trazables) desde el diagrama de clases a nivel PIM, de los métodos “Registro” y “AceptarRegistro” (desarrollados en los diagramas de actividad mostrados en la sección anterior). Posteriormente, a dicha ilustración, se muestra en la Ilustración 6-19 el documento XMI (§ 5.1) de dicho diagrama y por último, en la Tabla 6-9 se presentan los elementos que dieron origen a los elementos de este diagrama, con lo que se muestra una parte del nivel PSM.
En la Ilustración 6-18, se muestra el diagrama de clases a nivel PSM, con respecto a todas
las clases que intervienen en dicho diagrama para mostrar la parte de “Préstamo de Acervo”, por lo cual no se mencionan las clases usuario, acervo, convenio, necesidades bibliográficas, préstamo interbibliotecario y revista, debido a que esta demostración está enfocada solamente a “Administrar préstamo de acervo” y específicamente en este capítulo a “Registro de préstamo”. En dicha ilustración las clases que tiene el ambiente de “JBuilder” son “JFrame” y “JDialog”. La clase de “SistemaBiblioteca” es la clase que se crea una vez proporcionados los datos para el proyecto en “JBuilder”, esta clase contiene al “main” y es donde se manda llamar a “IniciarSesion”, que es la clase que representa la captura del tipo de usuario que quiere ingresar, la clave y contraseña con las que iniciará el sistema. Las clases “ManejoVentanas” y “ModeloTabla” se utilizan para dar formateo a las ventanas y tablas que se presenten en el sistema de biblioteca. La clase “Principal” se utiliza para presentar todas las opciones a las que puede tener acceso un determinado tipo de usuario y por último la clase “ManejoBD” contiene los métodos necesarios para conectarse o desconectarse de la base de datos, así como para validar, guardar, consultar o modificar información de la base de datos.
Capítulo 6 Demostración
130
Ilustración 6-18. Diagrama de Clases nivel PSM
Capítulo 6 Demostración
131
En la Ilustración 6-19, se representa el documento XMI para el diagrama de clases a nivel PSM, el cual se explica con el siguiente ejemplo. Se quiere especificar la clase “PrestamoAcervo” y la clase “Principal”, así como la relación entre ellas en el documento XMI del diagrama de clases. Primero, es necesario representar cada una de las clases a través de la etiqueta “uml:Class”, donde la primera clase tiene el identificador “C8”, cuya propiedad “name” contiene “PrestamoAcervo” y además en esta etiqueta se especifican otras propiedades como la visibilidad, etc. y otras etiquetas que tiene esta etiqueta son “uml:Attribute” y “uml:Operation”, donde se colocan por cada una de estas etiquetas los atributos y métodos de la clase con sus propiedades respectivamente. La segunda clase tiene el identificador “C5” y en la propiedad “name” tiene el nombre de la clase “Principal”. Ambas clases “PrestamoAcervo” y “Principal” tienen la etiqueta “Association”, donde se tiene el identificador “R10” que es la referencia hacia la etiqueta “uml:Association”, que contiene la descripción de la relación entre estas clases, a través de las etiquetas “Source” y “Target”, que tienen los identificadores “C8” y “C5” respectivamente a las clases mencionadas y por último la propiedad del tipo de relación se especifica en la propiedad “type” como “Dependency” de la etiqueta “uml:Association”.
<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDClases.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id="Class" name="Class"> … … … <uml:Class xmi:id="C5" name="Principal" isAbstract="false" Visibility="Public" isDerived="false" isRoot="false"> <Association xmi:idref="R5" /> <Association xmi:idref="R6"/> <Association xmi:idref="R7"/> <Association xmi:idref="R8"/> <Association xmi:idref="R10"/> <Association xmi:idref="R11"/> </uml:Class> … … … <uml:Class xmi:id="C8" name="PrestamoAcervo" isAbstract="false" Visibility="Public" isDerived="false" isRoot="false"> <uml:Attribute xmi:id="A1" type="JTextField" name="jTextFieldFolio" visibility="packageLocal"/> … … ... <uml:Attribute xmi:id="A6" type="JTextField" name="jTextFieldFechaEntrega" visibility="packageLocal"/> ... ... ... <uml:Attribute xmi:id="A9" type="JTextField" name="jTextFieldFechaPrestamo" visibility="packageLocal"/>... ...
... <uml:Attribute xmi:id="A54" type="jTextField" name="jTextFieldNumControl" visibility="packageLocal"/> ... ... ... <uml:Operation xmi:id="O7" type="void" name="jButtonAceptarRegistro_actionPerformed" visibility="Public"/> <uml:Operation xmi:id="O8" type="void" name="jButtonRegistrar_actionPerformed" visibility="Public"/> <Association xmi:idref="R4" /> <Association xmi:idref="R9"/> <Association xmi:idref="R10"/> <Association xmi:idref="R11"/> <Association xmi:idref="R12"/> </uml:Class> <uml:Class xmi:id="C9" name="ModeloTabla" isAbstract="false" Visibility="Public" isDerived="false" isRoot="false"> <Association xmi:idref="R12" /> </uml:Class> ... ... ... <uml:Association xmi:id="R10" name="" Direction="Source-Destination" type="Dependency"> <Source xmi:idref="C8"/> <Target xmi:idref="C5"/> </uml:Association> ... ... ... <uml:Association xmi:id="R12" name="MT" Direction="Source-Destination" type="Associate"> <Source xmi:idref="C8"/> <Target xmi:idref="C9"/> </uml:Association> </uml:Package> </XMI.content> </xmi:XMI>
Ilustración 6-19. Documento XMI para el diagrama de clases de la Ilustración 6-18
Capítulo 6 Demostración
132
La Tabla 6-9, muestra la trazabilidad para el diagrama de clases a nivel PSM, que está enfocado hacia el lenguaje java, donde de los elementos del diagrama de clases a nivel PIM se obtienen los elementos de ese diagrama a nivel PSM. Debido a como va estar conformado el sistema de biblioteca, que se empieza a ver en este nivel PSM con el lenguaje java, fueron necesarios todos los atributos mostrados en el diagrama de clases a nivel PSM, debido a que se pensó en una pantalla con diferentes secciones como: “registrar”, “eliminar”, “modificar”, “consultar” y “estadísticas de préstamo”, por ello se repiten los atributos mostrados en el diagrama de clases a nivel PIM en el diagrama de clases a nivel PSM, por cada una de las secciones que se manejó en el sistema en la parte de “Administrar préstamo de acervo”. Los elementos a nivel PSM que no tienen correspondencia con los elementos a nivel PIM en la tabla, son debido a que algunas clases son prefabricadas (“JFrame”, “JDialog”, “SistemaBiblioteca”) por el ambiente que se utiliza y otras clases se requieren para cubrir aspectos de formateo de la información o pantallas (como “ManejoVentanas”, “ModeloTabla”, etc.).
Tabla 6-9. Trazabilidad para el Diagrama de Clases nivel PSM
Elementos del Diagrama de clases a nivel PIM Elementos del Diagrama de Clases nivel PSM PrestamoAcervo FechaPrestamo : date FechaEntrega : date NumControl : string Folio : string
PrestamoAcervo jTextFieldFolio : JTextField jTextFieldFolio1 : JTextField jTextFieldFolio2 : JTextField jDataChooserFechaEntrega2 jDataChooserFechaEntrega jTextFieldFechaEntrega : JTextField jTextFieldFechaPrestamo2 : JTextField jTextFieldFechaPrestamo1 : JTextField jTextFieldFechaPrestamo : JTextField jTextFieldNumControl2 : JTextField jTextFieldNumControl1 : JTextField jLabelTotalPrestamo:jLabel jLabelTipoConsulta:jLabel jLabelFinal:jLabel jLabelInicial:jLabel jLabelFechaFinal:jLabel jLabelFechaInicial:jLabel jLabelFechaPrestamo2:jLabel jLabelFechaPrestamo1:jLabel jLabelFechaPrestamo:jLabel jLabelFechaEntrega2:jLabel jLabelFechaEntrega1:jLabel jLabelFechaEntrega:jLabel jLabelNumControl2:jLabel jLabelNumControl1:jLabel jLabelNumControl:jLabel jLabelFolio2:jLabel jLabelFolio1:jLabel jLabelFolio:jLabel jComponentRegistrar:jComponent jComponentModificar:jComponent jComponentEstadistica:jComponent jComponentEliminar:jComponent jComponentConsultar:jComponent jButtonRegistrar:jButton jButtonModificar:jButton jButtonEstadistica:jButton jButtonEliminar:jButton jButtonConsultar:jButton jButtonAceptarRegistro:jButton jButtonAceptarModificacion:jButton jButtonAceptarEliminacion: jButton
Capítulo 6 Demostración
133
+Estadistica:default +Consultar:default +AceptarModificacion:default +Modificar:default +AceptarEliminacion:default +Eliminar:default +AceptarRegistro:default +Registrar:default
TipoConsulta:String[] Respuesta:int jTextFieldTotalPrestamos : JTextField jTextFieldFinal : JTextField jTextFieldInicial : JTextField jDataChooserFechaFinal: jDataChooser jDataChooserFechaInicial: jDataChooser MT:ModeloTabla jTableConsulta: jTable jTextFieldCapturaInformacion: jTextField jComboBoxTipoConsulta: jComboBox jTextFieldNumControl : JTextField +jButtonEstadistica_actionPerformed:void +jButtonConsultar_actionPerformed:void +jButtonAceptarModificacion_actionPerformed:void +jButtonModificar_actionPerformed:void +jButtonAceptarEliminacion_actionPerformed:void +jButtonEliminar_actionPerformed:void +jButtonAceptarRegistro_actionPerformed:void +jButtonRegistrar_actionPerformed:void
IniciarSesion IniciarSesion ManejoBD ManejoBD ModeloTabla JDialog Principal Principal JFrame ManejoVentanas SistemaBiblioteca
6.3.1.7 Cruce de la frontera PSM-IM Esta frontera se inició con la transformación del diagrama de clases a nivel PSM al código de la clase “PrestamoAcervo” del nivel IM, el cual contiene el código de los atributos y métodos de dicho diagrama y su correspondiente transformación del lenguaje a partes especificas de la implementación en el ambiente de “JBuilder” (Ej. los atributos y métodos que genera al introducir un componente gráfico).
Después del diagrama de base de datos (base de datos relacional) del nivel PSM se obtuvo el código correspondiente a la bases de datos del nivel IM (Ej. al pasar el nombre de una tabla a nivel PSM a nivel IM se le agrega “create table” y enseguida se pone el nombre de la tabla), y por último de los diagramas de actividad (conformado por 8 diagramas) del nivel PSM se obtuvo el código correspondiente a cada uno de ellos del nivel IM (Ej. a nivel IM en el código se agregan las llaves correspondiente al inicio y fin de alguna condición, las instrucciones de este diagrama se pasaron en su totalidad directamente).
En la Ilustración 6-20 y en la Ilustración 6-21 se presentan los códigos a nivel IM correspondientes a los diagramas de actividad presentados en el nivel PSM, donde por cada método de tipo “jButton” el ambiente generó una clase para dar soporte a dicho método.
A continuación se presenta en la Ilustración 6-20 el código a nivel IM del diagrama de actividad “Registrar” (nivel PSM). El código generado a nivel IM proviene de la clase “PrestamoAcervo” del método “jButtonRegistrar_actionPerformed”. Posteriormente, a dicha ilustración en la Tabla 6-10 se presentan los elementos que dieron origen a los elementos del código del método “jButtonRegistrar_actionPerformed”, con lo que se muestra una parte de la frontera PSM-IM.
Capítulo 6 Demostración
134
public void jButtonRegistrar_actionPerformed(ActionEvent e) { ResultSet RespuestaAcervo; String titulo=""; Date FechaA = this.jDateChooserFechaEntrega.getDate(); SimpleDateFormat Formato = new SimpleDateFormat("yyyy/MM/dd"); String FechaEntrega = Formato.format(FechaA); try{ Principal.MBD.Actualizar("Insert into PrestamoAcervo values('" +jTextFieldFolio.getText() + "','" +jTextFieldNumControl.getText() + "','" +jTextFieldFechaPrestamo.getText() + "','" +FechaEntrega+ "')"); Principal.MBD.Actualizar("update Acervo set Estatus=true where Folio='"+jTextFieldFolio.getText()+"'"); RespuestaAcervo=Principal.MBD.EjecutarQuery("select Titulo from Acervo where Folio= '"+ jTextFieldFolio.getText()+"'"); if(RespuestaAcervo.next()) titulo=RespuestaAcervo.getString("Titulo"); Principal.MBD.Actualizar("Insert into EstadisticasPrestamos values('" +titulo+ "','" +jTextFieldFechaPrestamo.getText() + "')"); jLabelFolio.setEnabled(true); jLabelNumControl.setEnabled(true); jTextFieldFolio.setEnabled(true); jTextFieldFolio.setText(""); jTextFieldNumControl.setEnabled(true); jTextFieldNumControl.setText(""); jButtonAceptarRegistro.setEnabled(true); jLabelFechaPrestamo.setEnabled(false); jLabelFechaEntrega.setEnabled(false); jDateChooserFechaEntrega.getComponent(0).setEnabled(false); jTextFieldFechaPrestamo.setEnabled(false); jTextFieldFechaPrestamo.setText(""); jButtonRegistrar.setEnabled(false); JOptionPane.showMessageDialog(null,"Préstamo registrado", "Sistema Biblioteca",JOptionPane.INFORMATION_MESSAGE); } catch(Exception Excepcion){ JOptionPane.showMessageDialog(null,Excepcion.getMessage()+"Fallo el Registro", "Sistema Biblioteca",JOptionPane.ERROR_MESSAGE); } }
Ilustración 6-20. Código generado para el método jButtonRegistrar_actionPerformed nivel IM
En la Tabla 6-10, se muestra la trazabilidad para el código del método “Registrar” a nivel IM, el cual proviene de los elementos del diagrama de actividad “Registrar” a nivel PSM. En esta tabla el código “try” y “catch” no tienen correspondencia con ningún elemento a nivel PSM, debido a que estos provienen del escenario del caso de uso “CU-4.1 Registrar préstamo” a nivel PIM, en la parte de “error en la conexión” y esto se represento por medio del código “try” y “catch”. Por otra parte, el otro renglón que no tiene correspondencia con el nivel PSM, es debido a que ese conjunto de instrucciones representan aspectos de usabilidad, como el habilitar y deshabilitar ciertos datos, campos o botones en la pantalla.
Tabla 6-10. Trazabilidad para el método jButtonRegistrar_actionPerformed nivel IM
Diagrama de actividad “Registrar” a nivel PSM Código generado para el método Registro a nivel IM PrestamoAcervo::jButtonRegistrar_ actionPerformed(e:ActionEvent):void
public void jButtonRegistrar_actionPerformed (ActionEvent e) {
ResultSet RespuestaAcervo; String titulo=""; ResultSet RespuestaAcervo; String titulo="";
Date FechaA = this.jDateChooserFechaEntrega. getDate(); SimpleDateFormat Formato = new SimpleDateFormat("yyyy/MM/dd"); S String FechaEntrega = Formato.format(FechaA);
Date FechaA = this.jDateChooserFechaEntrega.getDate(); SimpleDateFormat Formato = new SimpleDateFormat("yyyy/MM/dd"); String FechaEntrega= Formato.format(FechaA);
try{ Principal.MBD.Actualizar("Insert into PrestamoAcervo values('"+jTextFieldFolio.getText() + "','" +jTextFieldNumControl.getText() + "','" + jTextFieldFechaPrestamo.getText() + "','" + FechaEntrega+ "')");
Principal.MBD.Actualizar("Insert into PrestamoAcervo values('" +jTextFieldFolio.getText() + "','" +jTextFieldNumControl.getText() + "','" +jTextFieldFechaPrestamo.getText() + "','" +FechaEntrega+ "')");
Principal.MBD.Actualizar("update Acervo set Estatus=true where Folio='"+jTextFieldFolio.getText()+"'");
Principal.MBD.Actualizar("update Acervo set Estatus=true where Folio='"+jTextFieldFolio.getText()+"'");
RespuestaAcervo=Principal.MBD.EjecutarQuery(" select Titulo from Acervo where Folio= '"+ jTextFieldFolio.getText()+"'");
RespuestaAcervo=Principal.MBD.EjecutarQuery ("select Titulo from Acervo where Folio= '"+ jTextFieldFolio.getText()+"'");
RespuestaAcervo.next() if(RespuestaAcervo.next())
Capítulo 6 Demostración
135
titulo=RespuestaAcervo.getString("Titulo"); titulo=RespuestaAcervo.getString("Titulo"); Principal.MBD.Actualizar("Insert into EstadisticasPrestamos values('" +titulo+ "','" + jTextFieldFechaPrestamo.getText() + "')");
Principal.MBD.Actualizar("Insert into EstadisticasPrestamos values('" +titulo+ "','" +jTextFieldFechaPrestamo.getText() + "')");
jLabelFolio.setEnabled(true); jLabelNumControl.setEnabled(true); jTextFieldFolio.setEnabled(true); jTextFieldFolio.setText(""); jTextFieldNumControl.setEnabled(true); jTextFieldNumControl.setText(""); jButtonAceptarRegistro.setEnabled(true); jLabelFechaPrestamo.setEnabled(false); jLabelFechaEntrega.setEnabled(false); jDateChooserFechaEntrega.getComponent(0). setEnabled(false); jTextFieldFechaPrestamo.setEnabled(false); jTextFieldFechaPrestamo.setText(""); jButtonRegistrar.setEnabled(false);
JOptionPane.showMessageDialog (null, "Préstamo registrado", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null,"Préstamo registrado", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);}
catch(Exception Excepcion){ JOptionPane.showMessageDialog (null,Excepcion.getMessage()+"Fallo el Registro", "Sistema Biblioteca", JOptionPane.ERROR_MESSAGE);}
}
A continuación se presenta en la Ilustración 6-21 el código a nivel IM del diagrama de actividad “AceptarRegistro” (nivel PSM). El código generado a nivel IM proviene de la clase “PrestamoAcervo” del método “jButtonAceptarRegistro_actionPerformed”. Posteriormente, a dicha ilustración en la Tabla 6-11 se presentan los elementos que dieron origen a los elementos de este diagrama, con lo que se muestra otra parte de la frontera PSM-IM.
public void jButtonAceptarRegistro_actionPerformed(ActionEvent e) { if(jTextFieldFolio.getText().equals("") || jTextFieldNumControl.getText().equals("") ){ JOptionPane.showMessageDialog(null,"Información incompleta", "Sistema Biblioteca",JOptionPane.INFORMATION_MESSAGE); } else{ try{ Respuesta=Principal.MBD.ValidarPrestamo(jTextFieldFolio.getText(),jTextFieldNumControl.getText(),0); if (Respuesta==1){ JOptionPane.showMessageDialog(null,"Préstamo ya registrado", "Sistema Biblioteca",JOptionPane.INFORMATION_MESSAGE); jTextFieldFolio.setText(""); jTextFieldNumControl.setText(""); } else{ Respuesta=Principal.MBD.ValidarPrestamo(jTextFieldFolio.getText(),jTextFieldNumControl.getText(),3); if (Respuesta==1) { JOptionPane.showMessageDialog(null,"Ejemplar repetido", "Sistema Biblioteca",JOptionPane.INFORMATION_MESSAGE); jTextFieldFolio.setText(""); jTextFieldNumControl.setText(""); } else { Respuesta = Principal.MBD.ValidarUsuario(jTextFieldNumControl. getText()); if (Respuesta == 0) { JOptionPane.showMessageDialog(null, "Usuario no encontrado","Sistema Biblioteca",JOptionPane.INFORMATION_MESSAGE); jTextFieldNumControl.setText(""); } else { Respuesta = Principal.MBD.ValidarPrestamo(jTextFieldFolio. getText(), jTextFieldNumControl.getText(), 1); if (Respuesta == 1) { JOptionPane.showMessageDialog(null, "El usuario ya tiene 3 prestamos", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE); jTextFieldFolio.setText(""); jTextFieldNumControl.setText(""); } else {
Capítulo 6 Demostración
136
Respuesta = Principal.MBD.ValidarAcervo(jTextFieldFolio. getText()); if (Respuesta == -1) { JOptionPane.showMessageDialog(null, "Acervo no encontrado", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE); jTextFieldFolio.setText(""); } else { if (Respuesta != 0) { JOptionPane.showMessageDialog(null, "Acervo no disponible", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE); jTextFieldFolio.setText(""); jTextFieldNumControl.setText(""); } else { jLabelFolio.setEnabled(false); jLabelNumControl.setEnabled(false); jTextFieldFolio.setEnabled(false); jTextFieldNumControl.setEnabled(false); jButtonAceptarRegistro.setEnabled(false); Date FechaActual = new Date(); SimpleDateFormat FormatoFecha = new SimpleDateFormat("yyyy/MM/dd"); jTextFieldFechaPrestamo.setText(FormatoFecha. format(FechaActual)); jDateChooserFechaEntrega.getComponent(0). setEnabled(true); jButtonRegistrar.setEnabled(true); } } } } } } } catch(Exception Excepcion){ JOptionPane.showMessageDialog(null,Excepcion.getMessage()+"Acción no completada", "Sistema Biblioteca",JOptionPane.ERROR_MESSAGE); } } }
Ilustración 6-21. Código generado para el método AceptarRegistro nivel IM
En la Tabla 6-11, se presenta la trazabilidad para el código del método “AceptarRegistro” a nivel IM. De acuerdo a los elementos del diagrama de actividad “AceptarRegistro” a nivel PSM, se obtienen los elementos del código generado a nivel IM. Al igual que en la Tabla 6-10, en esta tabla se presenta el código “try” y “catch” provenientes del escenario del caso de uso “CU-4.1 Registrar préstamo” para cachar el error en la conexión de la base de datos, así como se presentan aspectos de usabilidad en los demás renglones de la tabla que no tienen correspondencia con el diagrama a nivel PSM.
Tabla 6-11. Trazabilidad para el método AceptarRegistro nivel IM Diagrama de actividad “AceptarRegistro” a nivel PSM Código generado para el método AceptarRegistro a
nivel IM PrestamoAcervo::jButtonAceptarRegistro (e:ActionEvent):void
public void jButtonAceptarRegistro_ actionPerformed(ActionEvent e) {
jTextFieldFolio.getText().equals("") II jTextFieldNumControl.getText().equals("")
if(jTextFieldFolio.getText().equals("") || jTextFieldNumControl.getText().equals("") ){
JOptionPane.showMessageDialog(null," Información incompleta", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null, "Información incompleta", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE); }
Else else{
try{ Respuesta=Principal.MBD.ValidarPrestamo Respuesta=Principal.MBD.ValidarPrestamo
Capítulo 6 Demostración
137
(jTextFieldFolio.getText(), jTextFieldNumControl.getText(),0);
(jTextFieldFolio.getText(), jTextFieldNumControl.getText(),0);
Respuesta==1 if (Respuesta==1){ JOptionPane.showMessageDialog(null,"Préstamo ya registrado", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null,"Préstamo ya registrado", "Sistema Biblioteca" ,JOptionPane.INFORMATION_MESSAGE);
TextFieldFolio.setText(""); jTextFieldNumControl.setText("");}
else else{ Respuesta=Principal.MBD.ValidarPrestamo (jTextFieldFolio.getText(), jTextFieldNumControl.getText(),3);
Respuesta=Principal.MBD.ValidarPrestamo (jTextFieldFolio.getText(), jTextFieldNumControl.getText(),3);
Respuesta==1 if (Respuesta==1) { JOptionPane.showMessageDialog(null,"Ejemplar repetido", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null,"Ejemplar repetido", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
jTextFieldFolio.setText(""); jTextFieldNumControl.setText("");}
else else { Respuesta=Principal.MBD.ValidarUsuario (jTextFieldNumControl.getText());
Respuesta = Principal.MBD.ValidarUsuario (jTextFieldNumControl.getText());
Respuesta==0 if (Respuesta == 0) { JOptionPane.showMessageDialog(null,"Usuario no encontrado","Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null, "Usuario no encontrado","Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
jTextFieldNumControl.setText("");} else else { Respuesta=Principal.MBD.ValidarPrestamo (jTextFieldFolio.getText(), jTextFieldNumControl.getText(),1);
Respuesta = Principal.MBD.ValidarPrestamo (jTextFieldFolio.getText(), jTextFieldNumControl.getText(), 1);
Respuesta==1 if (Respuesta == 1) { JOptionPane.showMessageDialog(null,"El usuario ya tiene 3 prestamos", "Sistema Biblioteca" ,JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null, "El usuario ya tiene 3 prestamos", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
jTextFieldFolio.setText(""); jTextFieldNumControl.setText("");}
else else { Respuesta=Principal.MBD.ValidarAcervo (jTextFieldFolio.getText());
Respuesta = Principal.MBD.ValidarAcervo (jTextFieldFolio.getText());
Respuesta==-1 if (Respuesta == -1) { JOptionPane.showMessageDialog(null,"Acervo no encontrado","Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null, "Acervo no encontrado", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
jTextFieldFolio.setText(""); } else else { Respuesta<>0 if (Respuesta != 0) { JOptionPane.showMessageDialog(null,"Acervo no disponible","Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
JOptionPane.showMessageDialog(null, "Acervo no disponible", "Sistema Biblioteca", JOptionPane.INFORMATION_MESSAGE);
jTextFieldFolio.setText(""); jTextFieldNumControl.setText("");}
else else { jLabelFolio.setEnabled(false);
jLabelNumControl.setEnabled(false); jTextFieldFolio.setEnabled(false); jTextFieldNumControl.setEnabled(false); jButtonAceptarRegistro.setEnabled(false); jDateChooserFechaEntrega.getComponent(0). setEnabled(true); jButtonRegistrar.setEnabled(true);
Date FechaActual= new Date(); Date FechaActual = new Date(); SimpleDateFormat FormatoFecha=new SimpleDateFormat("yyyy/MM/dd"); jTextFieldFechaPrestamo.setText (FormatoFecha.format(FechaActual));
SimpleDateFormat FormatoFecha = new SimpleDateFormat("yyyy/MM/dd"); jTextFieldFechaPrestamo.setText(FormatoFecha. format(FechaActual));
}
Capítulo 6 Demostración
138
} } } } } } catch(Exception Excepcion){
JOptionPane.showMessageDialog (null,Excepcion.getMessage()+"Acción no completada", "Sistema Biblioteca", JOptionPane.ERROR_MESSAGE);}
} }
6.3.1.8 Nivel IM Este nivel se inició con el código para la base de datos, el cual surge del diagrama de la base de datos (base de datos relacional) a nivel PSM. Posteriormente, el código de la clase “PrestamoAcervo” del nivel IM se obtiene desde el diagrama de clases del nivel PSM. Por último, el código que se genera para los métodos a nivel IM, es a partir de los diagramas de actividad de “Registrar” y “AceptarRegistro” del nivel PSM. El código de los métodos se mostró en la sección anterior.
Para bosquejar una parte de los diagramas utilizados en este nivel, a continuación se presenta en la Ilustración 6-22 el código de la clase “PrestamoAcervo” de este nivel, del cual surgen los códigos correspondientes a los métodos “jButtonRegistrar_actionPerformed” y “jButtonAceptarRegistro_actionPerformed”. Posteriormente, a dicha ilustración, en la Tabla 6-12 se presentan los elementos que dieron origen a los elementos del código de la clase “PrestamoAcervo”, con lo que se muestra una parte del nivel IM.
public class PrestamoAcervo extends JDialog { private int Respuesta; XYLayout xYLayout1 = new XYLayout(); JTabbedPane jTabbedPane1 = new JTabbedPane(); JComponent jComponentRegistrar = makeTextPanel(); JComponent jComponentModificar = makeTextPanel(); JComponent jComponentConsultar = makeTextPanel(); JComponent jComponentEliminar = makeTextPanel(); JComponent jComponentEstadistica = makeTextPanel(); XYLayout xYLayout2 = new XYLayout(); XYLayout xYLayout4 = new XYLayout(); XYLayout xYLayout5 = new XYLayout(); XYLayout xYLayout6 = new XYLayout(); XYLayout xYLayout7 = new XYLayout(); XYLayout xYLayout3 = new XYLayout(); JPanel jPanel1 = new JPanel(); JTextField jTextFieldFechaEntrega1 = new JTextField(); JTextField jTextFieldFechaPrestamo1 = new JTextField(); JLabel jLabelFechaPrestamo1 = new JLabel(); JLabel jLabelFechaEntrega1 = new JLabel(); JButton jButtonEliminar = new JButton(); JTextField jTextFieldFolio1 = new JTextField(); JButton jButtonAceptarEliminacion = new JButton(); JLabel jLabelFolio1 = new JLabel(); JLabel jLabelNumControl1 = new JLabel(); JTextField jTextFieldNumControl1 = new JTextField(); XYLayout xYLayout8 = new XYLayout(); Border border1 = BorderFactory.createEtchedBorder(Color.white, Color.blue); JPanel jPanel2 = new JPanel(); JLabel jLabelFechaPrestamo2 = new JLabel(); JLabel jLabelFechaEntrega2 = new JLabel(); JTextField jTextFieldFechaPrestamo2 = new JTextField(); JButton jButtonModificar = new JButton(); JDateChooser jDateChooserFechaEntrega2 = new JDateChooser(); JTextField jTextFieldNumControl2 = new JTextField(); JButton jButtonAceptarModificacion = new JButton(); JLabel jLabelFolio2 = new JLabel();
Capítulo 6 Demostración
139
JLabel jLabelNumControl2 = new JLabel(); JTextField jTextFieldFolio2 = new JTextField(); XYLayout xYLayout9 = new XYLayout(); Border border2 = BorderFactory.createEtchedBorder(Color.white, Color.blue); JLabel jLabelTipoConsulta = new JLabel(); JTextField jTextFieldCapturaInformacion = new JTextField(); JButton jButtonConsultar = new JButton(); JScrollPane jScrollPane1 = new JScrollPane(); private String [] TipoConsulta={ "# Control", "Titulo" }; ModeloTabla MT=new ModeloTabla(); JTable jTable1 = new JTable(MT); JComboBox jComboBoxTipoConsulta = new JComboBox(TipoConsulta); JPanel jPanel3 = new JPanel(); JTextField jTextFieldFInicial = new JTextField(); JTextField jTextFieldFFinal = new JTextField(); JLabel jLabelTotalPrestamos = new JLabel(); JTextField jTextFieldTotalPrestamos = new JTextField(); JLabel jLabelFFinal = new JLabel(); JLabel jLabelFInicial = new JLabel(); JButton jButtonEstadistica = new JButton(); JDateChooser jDateChooserFechaInicial = new JDateChooser(); JLabel jLabelFechaInicial = new JLabel(); JDateChooser jDateChooserFechaFinal = new JDateChooser(); JLabel jLabelFechaFinal = new JLabel(); XYLayout xYLayout10 = new XYLayout(); Border border3 = BorderFactory.createEtchedBorder(Color.white, Color.blue); JPanel jPanel4 = new JPanel(); JLabel jLabelFechaPrestamo = new JLabel(); JLabel jLabelFechaEntrega = new JLabel(); JTextField jTextFieldFechaPrestamo = new JTextField(); JButton jButtonRegistrar = new JButton(); JDateChooser jDateChooserFechaEntrega = new JDateChooser(); JTextField jTextFieldFolio = new JTextField(); JButton jButtonAceptarRegistro = new JButton(); JLabel jLabelFolio = new JLabel(); JLabel jLabelNumControl = new JLabel(); JTextField jTextFieldNumControl = new JTextField(); XYLayout xYLayout11 = new XYLayout(); Border border4 = BorderFactory.createEtchedBorder(Color.white, Color.blue); Border border5 = BorderFactory.createEtchedBorder(Color.white, Color.blue); public PrestamoAcervo (Frame owner, String title, boolean modal); public PrestamoAcervo(); protected JComponent makeTextPanel(); private void jbInit(); public void jButtonAceptarRegistro_actionPerformed(ActionEvent e); public void jButtonRegistrar_actionPerformed(ActionEvent e); public void jButtonAceptarEliminacion_actionPerformed(ActionEvent e); public void jButtonEliminar_actionPerformed(ActionEvent e); public void jButtonAceptarModificacion_actionPerformed(ActionEvent e); public void jButtonModificar_actionPerformed(ActionEvent e); public void jButtonConsultar_actionPerformed(ActionEvent e); public void jComboBoxTipoConsulta_actionPerformed(ActionEvent e); public void jButtonEstadistica_actionPerformed(ActionEvent e); }
Ilustración 6-22. Código de la clase “PrestamoAcervo” a nivel IM
En la Tabla 6-12, se presenta la trazabilidad para el código de las clases específicamente para el código de la clase “PrestamoAcervo” a nivel IM, el cual surge de los elementos del diagrama de clases a nivel PSM. Las partes de la columna del código a nivel IM que no tengan correspondencia con el diagrama clases a nivel PSM, significa que son atributos generados por default al agregar un componente gráfico o métodos que se requieren para aplicar los aspectos de usabilidad (Ej. métodos para activar o desactivar un determinado elemento en la pantalla).
Capítulo 6 Demostración
140
Tabla 6-12. Trazabilidad para el código de clases a nivel IM Diagrama de Clases nivel PSM Código de clases a nivel IM
PrestamoAcervo jTextFieldFolio : JTextField jTextFieldFolio1 : JTextField jTextFieldFolio2 : JTextField jDataChooserFechaEntrega2 jDataChooserFechaEntrega jTextFieldFechaEntrega : JTextField jTextFieldFechaPrestamo2 : JTextField jTextFieldFechaPrestamo1 : JTextField jTextFieldFechaPrestamo : JTextField jTextFieldNumControl2 : JTextField jTextFieldNumControl1 : JTextField jLabelTotalPrestamo:jLabel jLabelTipoConsulta:jLabel jLabelFinal:jLabel jLabelInicial:jLabel jLabelFechaFinal:jLabel jLabelFechaInicial:jLabel jLabelFechaPrestamo2:jLabel jLabelFechaPrestamo1:jLabel jLabelFechaPrestamo:jLabel jLabelFechaEntrega2:jLabel jLabelFechaEntrega1:jLabel jLabelFechaEntrega:jLabel jLabelNumControl2:jLabel jLabelNumControl1:jLabel jLabelNumControl:jLabel jLabelFolio2:jLabel jLabelFolio1:jLabel jLabelFolio:jLabel jComponentRegistrar:jComponent jComponentModificar:jComponent jComponentEstadistica:jComponent jComponentEliminar:jComponent jComponentConsultar:jComponent jButtonRegistrar:jButton jButtonModificar:jButton jButtonEstadistica:jButton jButtonEliminar:jButton jButtonConsultar:jButton jButtonAceptarRegistro:jButton jButtonAceptarModificacion:jButton jButtonAceptarEliminacion: jButton TipoConsulta:String[] Respuesta:int jTextFieldTotalPrestamos : JTextField jTextFieldFinal : JTextField jTextFieldInicial : JTextField jDataChooserFechaFinal: jDataChooser jDataChooserFechaInicial: jDataChooser MT:ModeloTabla jTableConsulta: jTable jTextFieldCapturaInformacion: jTextField jComboBoxTipoConsulta: jComboBox jTextFieldNumControl : JTextField
PrestamoAcervo jTextFieldFolio : JTextField jTextFieldFolio1 : JTextField jTextFieldFolio2 : JTextField jDataChooserFechaEntrega2 jDataChooserFechaEntrega jTextFieldFechaEntrega : JTextField jTextFieldFechaPrestamo2 : JTextField jTextFieldFechaPrestamo1 : JTextField jTextFieldFechaPrestamo : JTextField jTextFieldNumControl2 : JTextField jTextFieldNumControl1 : JTextField jLabelTotalPrestamo:jLabel jLabelTipoConsulta:jLabel jLabelFinal:jLabel jLabelInicial:jLabel jLabelFechaFinal:jLabel jLabelFechaInicial:jLabel jLabelFechaPrestamo2:jLabel jLabelFechaPrestamo1:jLabel jLabelFechaPrestamo:jLabel jLabelFechaEntrega2:jLabel jLabelFechaEntrega1:jLabel jLabelFechaEntrega:jLabel jLabelNumControl2:jLabel jLabelNumControl1:jLabel jLabelNumControl:jLabel jLabelFolio2:jLabel jLabelFolio1:jLabel jLabelFolio:jLabel jComponentRegistrar:jComponent jComponentModificar:jComponent jComponentEstadistica:jComponent jComponentEliminar:jComponent jComponentConsultar:jComponent jButtonRegistrar:jButton jButtonModificar:jButton jButtonEstadistica:jButton jButtonEliminar:jButton jButtonConsultar:jButton jButtonAceptarRegistro:jButton jButtonAceptarModificacion:jButton jButtonAceptarEliminacion: jButton TipoConsulta:String[] Respuesta:int jTextFieldTotalPrestamos : JTextField jTextFieldFinal : JTextField jTextFieldInicial : JTextField jDataChooserFechaFinal: jDataChooser jDataChooserFechaInicial: jDataChooser MT:ModeloTabla jTableConsulta: jTable jTextFieldCapturaInformacion: jTextField jComboBoxTipoConsulta: jComboBox jTextFieldNumControl : JTextField border1:Border border2:Border border3:Border border4:Border border5:Border jPanel1:JPanel jPanel2:JPanel jPanel3:JPanel jPanel4:JPanel jScrollPane1:JScrollPane
Capítulo 6 Demostración
141
+jButtonEstadistica_actionPerformed:void +jButtonConsultar_actionPerformed:void +jButtonAceptarModificacion_actionPerformed:void +jButtonModificar_actionPerformed:void +jButtonAceptarEliminacion_actionPerformed:void +jButtonEliminar_actionPerformed:void +jButtonAceptarRegistro_actionPerformed:void +jButtonRegistrar_ actionPerformed:void
jTabbedPane1:JTabbedPane jTable1:JTable XYLayout1:XYLayout XYLayout2:XYLayout XYLayout3:XYLayout XYLayout4:XYLayout XYLayout5:XYLayout XYLayout6:XYLayout XYLayout7:XYLayout XYLayout8:XYLayout XYLayout9:XYLayout XYLayout10:XYLayout XYLayout11:XYLayout public void jButtonEstadistica_actionPerformed(ActionEvent e); public void jButtonConsultar_actionPerformed(ActionEvent e); public void jButtonAceptarModificacion_actionPerformed (ActionEvent e); public void jButtonModificar_actionPerformed (ActionEvent e); public void jButtonAceptarEliminacion_actionPerformed (ActionEvent e); public void jButtonEliminar_actionPerformed (ActionEvent e); public void jButtonAceptarRegistro_actionPerformed (ActionEvent e); public void jButtonRegistrar_actionPerformed (ActionEvent e); public void jComboBoxTipoConsulta_actionPerformed(ActionEvent e); public PrestamoAcervo (Frame owner, String title, boolean modal); public PrestamoAcervo(); protected JComponent makeTextPanel(); private void jbInit();
IniciarSesion IniciarSesion ManejoBD ManejoBD ModeloTabla ModeloTabla JDialog JDialog Principal Principal JFrame JFrame ManejoVentanas ManejoVentanas SistemaBiblioteca SistemaBiblioteca
Por último en la Ilustración 6-23, se muestra la pantalla asociada al código de los métodos
(§ 6.3.1.7) “jButtonAceptarRegistro_actionPerformed” y “jButtonRegistrar_ actionPerformed ” a nivel IM.
Ilustración 6-23. Pantalla de “Administrar prestamos” en la opción “Registrar”
Capítulo 6 Demostración
142
6.4 Conclusión En el nivel CIM los modelos (diagramas) representan las actividades o tareas que se realizan en el dominio del negocio, que soportan aspectos de los objetivos internos y externos.
En el nivel PIM se mostró algunos tipos de datos, operadores y otras definiciones (§ 6.3.1.5) para especificar el nivel PIM en los diagramas y con ello poder realizar la trazabilidad a nivel PSM. Pero dichas especificaciones se necesitan refinar para representar la información contenida en los elementos de los diagramas del nivel PIM y con esto controlar las transformaciones en la frontera PIM-PSM, ya que el nivel PSM, se expresa apegándose a la sintaxis y semántica de un lenguaje de programación.
La mayor parte del nivel PSM es construido en base al nivel PIM, durante el proceso de
transformación. Sin embargo, son necesarios los expertos de la plataforma para conducir el proceso de transformación, aplicar el modelo específico y refinar los modelos generados.
En cualquiera de los diagramas, a través de los distintos modelos, la utilización de los
elementos que conforman a cada diagrama dependerá de la experiencia en el manejo de dichos elementos, ya que los actores que modelen los diferentes modelos lo tratarán de expresar de acuerdo a los conocimientos que tengan de cada uno de los diagramas, por lo cual teniendo estructuras bien definidas de los elementos para representar una determinada acción, se podría contribuir a que no existan diferencias en la forma de expresar dichos elementos de los diagramas, ya que estos serán transformados en forma automática y lo único que tendrían que realizar los actores en dado caso sería refinar el modelo transformado.
En el Reporte técnico RT-DCC-1-2007 [LOP07] se muestran las tablas que documentan el origen y destino de cada diagrama del procedimiento completo de la demostración. Se demuestra la trazabilidad que existe entre diagramas en un mismo nivel y diagramas en diferente nivel, debido a que se presentan los elementos que dieron origen a los elementos destino.
Con respecto a la consistencia, cuando se está definiendo la trazabilidad se está originando
información adicional que no se encontraba en el elemento origen, pero en el elemento destino está presente.
Por medio del desarrollo de la demostración del problema clásico de biblioteca se verificó
la tesis de demostración, ya que el apegarse a la definición de las fronteras mientras se realizaban las transformaciones manualmente, permitió llegar hasta el sistema ejecutable, por medio de las transformaciones entre diagramas del mismo nivel (CIM a CIM, PIM a PIM, PSM a PSM) y entre diagramas de diferentes niveles (CIM a PIM, PIM a PSM, PSM a IM).
143
Capítulo 7
Conclusiones Una vez expuesta la propuesta de solución (capítulo 4 y 5) y su demostración (capítulo 6), en este capítulo se muestran las conclusiones obtenidas del análisis e interpretación de los resultados de esta investigación, así como las aportaciones que se realizaron y la descripción de trabajos futuros que darán refinamiento y continuidad al presente trabajo de investigación en el campo de desarrollo dirigido por modelos en el ambiente AGDE. 7.1 Conclusiones El resultado principal de esta tesis es la definición de los modelos (CIM, PIM, PSM e IM) y la caracterización de las fronteras por medio de los elementos de los diagramas UML seleccionados (casos de uso, clases, secuencia y actividad). Se obtienen así las características distintivas de cada una de las fronteras, de manera que se distingan claramente entre ellas, para facilitar las transformaciones necesarias entre cada modelo (CIM a PIM, PIM a PSM y PSM a IM), en el proceso de obtención de una implementación funcional. Conociendo en forma precisa cuándo un tipo de modelo (Ej. PIM) se convierte en otro tipo de modelo (Ej. PSM).
Debido a que el objetivo de esta investigación es determinar las características distintivas de cada una de las fronteras entre los modelos MDA, de manera que se diferencien claramente, se demostró que mediante la definición de los modelos y la caracterización de las fronteras propuestas, se pudo desarrollar a través de una secuencia de transformaciones, el problema modelo de biblioteca, específicamente para la biblioteca de CENIDET.
En la demostración se desarrolló el problema de biblioteca realizando cada uno de los modelos, uno a partir de otro, hasta obtener la implementación. Verificando que lo mostrado
Capítulo 7 Conclusiones
144
en los modelos está también presente en el código y que apegándose a la definición de las fronteras, se pudo transformar de un modelo a otro y obtener un sistema ejecutable, como resultado final. Por consiguiente, la caracterización de las fronteras fue suficiente para lograr una implementación funcional a través de los diagramas de casos de uso, clases, secuencia y actividad.
A medida que se profundice más en las transformaciones se logrará una especificación
más detallada de la caracterización de las fronteras, en esta investigación no se analizaron a fondo las transformaciones.
La representación interna sólo se elaboró para los diagramas de casos de uso, clases,
secuencia y actividad, por lo tanto para los diagramas de línea de producción y entidad utilizados por el AGD no se elaboró su representación interna, debido a que la representación interna se basó únicamente en los elementos de los diagramas de UML seleccionados.
Se aportaron las bases para el proceso propuesto para MDA en el ambiente AGDE, a través de la definición de los modelos, de sus fronteras y su caracterización, así como ejemplificar las posibles transformaciones entre diagramas en un mismo modelo (CIM, PIM, PSM e IM) y entre diagramas en diferentes modelos (cruzando fronteras), considerando la trazabilidad (§ 3.2.1, § 3.2.2.4 y § 4.4) y la consistencia (§ 3.2.1, § 3.2.2.4 y § 4.4) entre ellos.
7.2 Aportaciones Durante el desarrollo de la presente investigación se identificaron algunas aportaciones de los resultados obtenidos que a continuación se mencionan.
• Se refinó y confirmo el conjunto de modelos contenidos en el Conjunto de Productos (PS) del AGD, mediante una comparación con los modelos utilizados en otros enfoques de desarrollo, para partir de un conjunto de modelos lo más completo posible (§ 4.2).
• Se obtuvo un conjunto reducido de diagramas (casos de uso, clases, secuencia y actividad) UML que permiten desarrollar un producto de software con un 60.67% de los elementos del conjunto completo de los diagramas de UML (§ 4.3), para utilizarse inicialmente en el proceso de MDA en el AGDE.
• Se efectuó la representación interna en XMI, con sus correspondientes DTD’s del conjunto reducido de los diagramas de UML, para guardar la información de dichos diagramas y utilizarla para transformarlos a través de los diferentes modelos (§ 5.1).
• Se elaboró un esquema general para representar el proceso de MDA, de forma abstracta de acuerdo a los lenguajes propuestos, bosquejando la forma en que se llega a una implementación funcional (capítulo 4).
• Se produjo la definición de los modelos (CIM, PIM, PSM e IM) y de sus fronteras (CIM-PIM, PIM-PSM, PSM-IM) mediante su caracterización, para delimitar y determinar las características distintivas entre cada modelo (frontera) y dirigir las transformaciones entre ellos, hasta alcanzar un sistema ejecutable (capítulo 5).
• Las aportaciones anteriores son la base del ambiente AGDE en la parte del proceso MDA, específicamente para las herramientas de transformación (modelo a modelo y
Capítulo 7 Conclusiones
145
modelo a código), para soportar el desarrollo de software dirigido por modelos (§ 3.1 y capítulo 4).
7.3 Trabajos futuros Los trabajos futuros para continuar mejorando y refinando el campo de desarrollo dirigido por modelos a través del ambiente AGDE, son los siguientes:
• Refinar el trabajo realizado detallando más cada nivel (CIM, PIM, PSM e IM), las fronteras y su caracterización, considerando a detalle las transformaciones.
• Identificar las transformaciones necesarias de modelo a modelo y de modelo a código, así como de código a modelo, utilizando un lenguaje de transformación (§ 4.4), así como una representación formal para verificar y validar la consistencia y trazabilidad en las transformaciones.
• Diseñar e implementar una familia de herramientas del AGDE que den soporte a todo el proceso que se llevó a cabo en la demostración de esta investigación, que soporte la diagramación y configuración de cada uno de los modelos, sus transformaciones en cada nivel y frontera, utilizando y refinando la representación interna propuesta.
146
Anexo A A-1 Comparando AGD con otros enfoques Con el propósito de presentar de forma detallada la comparativa de AGD con CMMI, RUP e IDEF, cuyo resultado se muestra en el capítulo 4 en la sección 4.1, se desarrollo este anexo, el cual contiene una breve descripción de cada uno de los enfoques, así como las tablas correspondientes a cada comparativa.
Primeramente, se comenzará esta comparativa mostrando a grandes rasgos el método AGD y posteriormente se describirá cada una de las comparaciones de AGD con otros enfoques, dentro de los cuales se explicará brevemente cada enfoque a comparar. Con la finalidad de analizar como está conformado el AGD con respecto a otros enfoques, es necesario hacer este análisis y así ubicar las características de cada uno de ellos en la comparativa del PS del AGD en el enfoque MDA. Las comparaciones de AGD con los enfoques son de acuerdo al conjunto de productos de la categoría de Ingeniería en el primer nivel, que representa a un tipo de modelo/nivel (CIM, PIM, PSM, IM, OM) del PS1Set (Conjunto de productos). Las tablas comparativas de AGD con otros enfoques están divididas en tres columnas, donde las primeras dos representan al AGD con respecto a los productos principales a obtener en el desarrollo (establecidos en el PS2Set) y la segunda corresponde al contenido de los productos principales (definida en el PS3Set) y por último, la tercera columna son los productos del trabajo del enfoque con que se este comparando (CMMI, RUP ó IDEF). Cabe mencionar que en las tablas comparativas de AGD con cada enfoque sólo se presentan los productos del trabajo con los que tienen relación.
Anexo A
147
A-1.1 AGD El método AGD se desarrolló como resultado principal de la investigación doctoral del profesor Moisés Gonzáles García, miembro de la línea de investigación en ingeniería de software del CENIDET.
Mediante AGD se enfocan los modelos como metas a obtener mediante un proceso sistemático, que permite a desarrolladores de software diseñar y obtener productos de software de buena calidad, mediante un proceso eficiente. Las prácticas principales del enfoque son: desarrollo de software mediante iteraciones, administrar los requerimientos, usar un estilo arquitectónico dirigido por modelos, construir siguiendo un modelo de referencia, especificar y verificar la calidad del software, controlar los cambios aplicados al software y usar la sinergia de cuatro modos de trabajo en grupo. El objetivo de AGD es dirigir un proceso para la ingeniería de un producto de software, es decir, un método centrado en el producto, el cual es descrito por un conjunto de reglas para mantener: su estructura y las relaciones entre sus partes (arquitectura). Esta descripción constituye la arquitectura de software mediante la cual se establece una referencia para organizar el proceso de desarrollo. Este método está formado por:
a) el Conjunto de Productos (PS), el cual está basado en el enfoque MDA, donde desde un
modelo se puede obtener el siguiente modelo a partir de la información y características de dicho modelo y así sucesivamente hasta llegar a obtener una implementación funcional.
b) el Proceso Dirigido por Modelos (MDP) otorga mayor importancia al análisis del
producto deseado y su descomposición en subproductos. Mediante el MDP se elabora cualquier producto o subconjunto de productos usando en forma sistemática los subprocesos del modo en equipo, asignando roles orientados a administrar el trabajo en equipo. El camino que tomará este análisis será por el conjunto de productos del trabajo ya que en éste se enfoca la presente investigación. El PS a grandes rasgos se desarrolla de la siguiente forma:
• Se captura la información del proyecto y las dependencias con otros proyectos
mediante unas formas Web. • Se llena otra forma Web con los datos de los integrantes, donde se lleva el control por
cada participante del proyecto a través de cuadernos del ingeniero. • En una forma Web se presenta la misión, visión y objetivos de la organización, además
se realiza la estructura de la organización, los programas y los portafolios del proyecto donde se lleva el control del desarrollo del proyecto.
• Se extraen los requerimientos del cliente, los usuarios que intervienen, con lo cual se van realizando diagramas de colaboración para posteriormente pasar a los casos de uso, donde se ve el alcance de los usuarios, los actores y sus respectivas descripciones o especificaciones de los casos de uso.
• Con respecto al negocio existente se ven los aspectos funcionales del mismo, se realiza una serie de diagramas de entidad a nivel de usuario, aplicación o un combinado de entidades de usuario con el propósito de sacar sólo las partes funcionales y de ahí obtener el diagrama de entidad a nivel de aplicación.
Anexo A
148
• De todo lo anterior se logra identificar los componentes, dependencias, relaciones, alcances, la definición de resultados, para poder llegar a un prototipo del sistema, el cual se va refinando a medida que se avanza en nivel de detalle tomando la información obtenida durante el desarrollo del proyecto.
• Se obtiene el plan de pruebas, restricciones a los requerimientos, la arquitectura, el diseño detallado hasta llegar a la codificación, entrega del producto y su evaluación.
Cabe destacar que los puntos mencionados anteriormente no tienen en si un orden, los PS
pueden ser realizados en el orden deseado con respecto a las expectativas o necesidades que se tengan.
A-1.2 Comparación de AGD y CMMI (Capability Maturity Model Integration) [CMMI02] Breve descripción de CMMI CMMI es un modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon.
Este modelo puede ser usado para dirigir la mejora del proceso a través de un proyecto, una división o una organización entera. Además ayuda a integrar funciones tradicionalmente separadas de la organización, poner objetivos de mejora de proceso y prioridades, proporcionar la dirección para procesos de calidad y proporcionar un punto de referencia para la valoración de procesos actuales.
CMMI está conformado por 4 categorías de áreas de proceso, de las cuales este análisis se
centra en la categoría de área de proceso de ingeniería. A continuación se enlistan las categorías del CMMI.
• Soporte • Gestión de proyectos • Gestión de procesos • Ingeniería
Las áreas de proceso dentro de la categoría de ingeniería cubren el desarrollo y el
mantenimiento de las actividades que son compartidas a través de las disciplinas de ingeniería (por ejemplo, ingeniería de sistemas e ingeniería de software). Las áreas de proceso en la categoría de ingeniería son:
1. Gestión de requerimientos 2. Desarrollo de requerimientos 3. Solución técnica 4. Integración del producto 5. Verificación 6. Validación
Anexo A
149
Comparativa Al comparar AGD con CMMI en la categoría de ingeniería con respecto a las áreas de procesos y a sus metas, prácticas especificas y productos del trabajo, fue necesario ver la comparación desde diferentes niveles de abstracción, debido tanto a la diferencia en los productos del trabajo como en las clasificaciones por lo que se decidió realizar este análisis comparativo tomando en cuenta los fines para alcanzar los objetivos correspondientes a los modelos y productos del trabajo de AGD. Los términos de codificación para las tablas en la parte de CMMI se manejan de la siguiente manera:
I= Categoría de Ingeniería C= Área de proceso de la categoría de Ingeniería con su respectivo número M= Meta ubicada dentro del área de proceso de la categoría de Ingeniería con su
respectivo número SP= Prácticas especificas con su respectivo número derivado de la meta
Un ejemplo para ilustrar dicha codificación es el siguiente: La codificación I-C1-M1-SP1-
1 se entendería así:
I se refiere a que es la categoría de Ingeniería C1 se refiere al área de proceso de gestión de requerimientos M1 se refiere a la meta 1 de esta área de proceso C1 SP1 es una práctica específica de M1 1 es el número del producto del trabajo correspondiente a SP1 A continuación se muestran en la siguiente tabla todas las codificaciones utilizadas en la
comparación de AGD con CMMI, donde en la primera columna se coloca la meta a la cual se hace referencia en la codificación para posteriormente mostrar el correspondiente producto del trabajo ó las prácticas específicas a dicha meta. Esta tabla específica tanto las metas y productos del trabajo de CMMI.
Metas Descripción (producto del trabajo) Codificación
Resultados de las revisiones de los requerimientos
I-C1-M1-SP1-1 Mantener los requerimientos
Listado de requerimientos I-C1-M1-SP1-2 Declaración de necesidades I-C2-M1-SP1-1 Declaración de necesidades I-C2-M1-SP2-1 Casos de prueba y resultados esperados I-C2-M1-SP3-3
Recoger y traducir las necesidades a requerimientos del cliente.
Desarrollar los conceptos operacionales y escenarios
I-C2-M1-SP5
Reducir los costos del producto y los riesgos I-C2-M2-SP3 Arquitectura funcional I-C2-M2-SP2-1
Refinar el problema Refinar el problema
Actualizar la arquitectura funcional I-C2-M2-SP3-6 Limitaciones tecnológicas I-C3-M1-SP4-7 Evolución de los requerimientos de los drivers y la tecnología
I-C3-M1-SP4-10 Seleccionar un diseño
Conceptos detallados operacionales y escenarios
I-C3-M1-SP1-6
Resultados de la simulación I-C3-M2-SP11-2 Resultados del prototipo I-C3-M2-SP11-3 Casos de uso I-C3-M2-SP4-4 Diseño de documentos de la interfaz I-C3-M2-SP7-2 Conceptos operacionales y escenarios I-C3-M2-SP4-1
Establecer y mantener el diseño del producto
Hojas de asignación de requerimientos I-C3-M2-SP6-1
Anexo A
150
Construir y entregar el producto Implementación de los componentes I-C3-M3-SP1-1 Establecer y mantener las interfaces Tabla de relaciones entre los diferentes
elementos del producto I-C4-M2-SP1-2
Soporte a la documentación para la integración del ambiente
I-C4-M3-SP1-1 Ensamble, pruebas y integración de los elementos del producto
Realizar las pruebas de aceptación I-C4-M3-SP6 Secuencia de integración y una exposición razonable para seleccionar o rechazar cada escenario unido
I-C4-M1-SP1-1
Integración del producto preliminar y del plan de prueba
I-C4-M1-SP1-3
Desarrollar una estrategia de integración
Procedimientos de la integración I-C4-M1-SP1-6 Ensamble, pruebas y integración de los elementos del producto
Informes de resumen de integración I-C4-M3-SP5-4
Simuladores (para el ambiente, interfaces hombre maquina, etc.)
I-C6-M1-SP2-3
Prototipos o maquetas I-C6-M1-SP2-1
Planear y preparar la validación del producto del trabajo
Aceptación de los procedimientos de prueba I-C6-M1-SP4-2
En la Tabla A-1 se muestra la comparativa del método AGD a nivel CIM con CMMI, en el
cual se obtienen las restricciones y los requerimientos, la identificación del proyecto, casos de uso con respecto a los alcance y prioridades en el punto de CIM del AGD, además de las entradas y salidas del sistema, las relaciones entre los diferentes elementos del producto. Cabe mencionar que una práctica específica de CMMI en I-C2-M1-SP5-4, es utilizada para la parte de prototipos pero no se mencionó en la tabla por que no contiene un producto del trabajo.
Tabla A-1. AGD en el nivel CIM comparado con CMMI
AGD en el nivel CIM CMMI Inicialización Identificación del proyecto I-C2-M1-SP1-1
I-C1-M1-SP1-1 I-C1-M1-SP1-2
Planificación-Visión
Obtener solicitudes del cliente
I-C2-M1-SP2-1 Negocio existente
Definición de resultados Definición de entradas
I-C2-M1-SP3-3
I-C3-M2-SP11-2 Alcance funcional I-C3-M2-SP11-3 I-C3-M2-SP11-2 Elementos de datos en interfase
hombre-máquina I-C3-M2-SP11-3
Identificación de componentes (nivel 1)
Dependencias de resultados y entradas I-C4-M2-SP1-2 Prototipo del sistema
En la Tabla A-2 se muestra la comparativa del método AGD en el nivel PIM con CMMI,
donde se presentan los casos de uso en ingeniería directa, diseño de la interfaz a un nivel alto de abstracción, la interacción entre el usuario y el sistema, un prototipo del software a desarrollar, la aceptación de los casos de prueba y su especificación, así como los requerimientos del software.
Tabla A-2. AGD en el nivel PIM comparado con CMMI AGD en el nivel PIM CMMI
Ingeniería inversa Casos de uso I-C3-M2-SP4-4
I-C3-M2-SP7-2
Ingeniería directa Presentación de la interacción hombre-máquina I-C6-M1-SP2-3
I-C3-M2-SP11-2 I-C3-M2-SP11-3
Prototipo de software Integración del prototipo del sistema
I-C6-M1-SP2-1 I-C6-M1-SP4-1
Anexo A
151
Especificación de prueba de aceptación
I-C6-M1-SP4-2
I-C3-M1-SP4-7
Requerimientos del software
Requerimientos del software I-C3-M1-SP4-10
En la Tabla A-3 se muestra la comparativa del método AGD a nivel PSM con CMMI,
donde se obtienen las restricciones en requerimientos, riesgos, diseño de restricciones, así como la estructura de la arquitectura, implementación y especificación de los componentes, los conceptos detallados operacionales y escenarios, con los cuales se forma la arquitectura del sistema con sus restricciones de acuerdo a los requerimientos.
Tabla A-3. AGD en el nivel PSM comparado con CMMI AGD en el nivel PSM CMMI
Riesgos/Beneficios I-C2-M2-SP3 Restricciones en requerimientos Restricciones I-C3-M2-SP6-1
Estructura de la arquitectura I-C2-M2-SP2-1 Arquitectura del componente Especificación de la prueba de integración I-C4-M3-SP1-1
I-C2-M2-SP2-1 Reporte de análisis de arquitectura I-C2-M2-SP3-6 I-C3-M1-SP1-6 I-C3-M2-SP4-1
Análisis de arquitectura
Generación de escenarios
I-C2-M1-SP5
En la Tabla A-4 se ilustra la comparativa del método AGD en el nivel IM con CMMI a nivel de implementación, el cual muestra la integración del producto, su instalación, mantenimiento y documentación, las pruebas de aceptación, además de la secuencia y procedimientos para la integración.
Tabla A-4. AGD en el modelo de implementación (IM) comparado con CMMI
AGD en el nivel IM CMMI Diseño detallado
Diseño detallado: servicios normales Diseño detallado: métricas
Diseño detallado: datos de proceso Especificación de prueba de aceptación I-C4-M3-SP6 Codificación Carga I-C3-M3-SP1-1
Elaborar documentación de usuario I-C3-M3-SP2-1 I-C4-M1-SP1-1 Integración de código I-C4-M1-SP1-3 I-C4-M1-SP1-3 I-C4-M1-SP1-6
Operación inicial
Prueba de integración
I-C4-M3-SP5-4
A-1.3 Comparación de AGD y RUP (Rational Unified Process) [RUP05] Breve descripción de RUP RUP proporciona las mejores prácticas y la dirección para el desarrollo de software acertado, además tiene tres características esenciales:
• Dirigido por casos de uso: En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba.
Anexo A
152
• Centrado en la arquitectura: En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento. Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura.
• Proceso iterativo e incremental: Consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina.
Este enfoque está conformado por una colección de dominios que son agrupaciones de
productos del trabajo, los cuales están divididos en subdominios. Los dominios de RUP son:
• Modelado del negocio • Requerimientos • Análisis y diseño • Implementación • Pruebas • Despliegue • Configuración y administración del cambio • Administración del proyectos • Ambiente
Comparativa Tanto AGD como RUP están enfocados al desarrollo de software y por lo tanto al realizar la comparativa entre ambos, RUP fue comparado a partir de los dominios, subdominios y productos del trabajo correspondientes para la comparación. Debido a la diferencia tanto de nombres del producto del trabajo y para realizar este análisis comparativo se tuvo que pasar a un nivel abstracto donde en ocasiones se realizó una mezcla de dominio, subdomino y productos del trabajo para ver la posible correspondencia con el AGD, por lo tanto quedo ese nivel de abstracción que se muestra en las tablas. Los términos de codificación para las tablas en la parte de RUP se manejan de la siguiente manera:
R= Indica que se refiere a RUP D= Se refiere al dominio con su respectivo número SD= Indica el subdominio de un dominio con su respectivo número
Un ejemplo para ilustrar dicha codificación es el siguiente: La codificación R-D1-SD1.1 se
entendería así: R identifica que es RUP D1 se refiere al dominio dentro de RUP SD1.1 es un subdominio de D1con su respectivo número, donde después del punto va el
número referente al producto del trabajo.
Anexo A
153
A continuación se muestra en la siguiente tabla, todas las codificaciones utilizadas en la comparación de AGD y RUP, donde en la primera columna se presenta el dominio al cuál esta haciendo referencia la codificación dentro de RUP y la segunda representa el producto del trabajo ó subdominio de dicho dominio. Esta tabla específica los dominios y productos del trabajo dentro de RUP.
Dominio Descripción (producto del trabajo) Codificación
Modelo de análisis del negocio R-D1-SD1.1 Reglas del negocio R-D1-SD1.8 Metas del negocio R-D1-SD1.7 Modelo de diseño del negocio R-D1-SD1.5 Documento de la arquitectura del negocio R-D1-SD1.3 Visión del negocio R-D1-SD1.10 Prueba de concepto arquitectónico del negocio
R-D1-SD1.2
Modelado del negocio
Especificación suplementaria del negocio R-D1-SD1.11 Peticiones de los Stakeholder R-D2-SD2.6 Glosario R-D2-SD2.1 Modelo de casos de usos R-D2-SD2.9 Storyboard R-D2-SD2.7 Requerimientos de software R-D2-SD2.4 Especificación de los requerimientos del software
R-D2-SD2.5
Atributos de los requerimientos R-D2-SD2.2
Requerimientos
Visión R-D2-SD2.10 Modelo de análisis R-D3-SD3.1 Mapa de navegación R-D3-SD3.7 Prototipo de la interfaz de usuario R-D3-SD3.11 Prueba de concepto arquitectónico R-D3-SD3.2 Arquitectura de referencia R-D3-SD3.8
Análisis y diseño
Documento de la arquitectura de software R-D3-SD3.10 Modelo de implementación R-D4-SD4.3 Construcción R-D4-SD4.1 Pruebas de desarrollo R-D4-SD4.2
Implementación
Plan de construcción de la integración R-D4-SD4.4 Especificación de la prueba de la interfaz R-D5-SD5.8 Plan de la prueba R-D5-SD5.10 Conjunto de pruebas R-D5-SD5-14
Pruebas
Resumen de la evaluación de la prueba R-D5-SD5.6 Despliegue Material de soporte de usuario R-D6-SD6.3
Administración del proyecto Lista de riesgos R-D8-SD8.8
En la Tabla A-5 se muestra la comparativa del método AGD a nivel CIM con RUP, donde
encontramos la captura de las peticiones realizadas en el proyecto, es decir se identifica el proyecto y sus requerimientos, se tiene el modelo del negocio, las reglas, las metas, el modelo de casos de uso, aspectos relevantes del negocio, un glosario de términos, análisis de los casos de uso, mapas de navegación para la interfaz a nivel abstracto, además de un prototipo de la interfaz de usuario. Todo esto sirve para definir la identificación del proyecto, las personas involucradas, los objetivos que se persiguen, la obtención de los requerimientos y una posible solución a nivel de requerimientos.
Tabla A-5. AGD en el nivel CIM comparado con RUP AGD en el nivel CIM RUP
Inicialización Identificación del proyecto Dependencias con otros proyectos
R-D2-SD2.6
Entender la estrategia Entender el negocio
R-D1-SD1.1
Planificación-Visión Alcance y prioridades R-D1-SD1.8
Anexo A
154
R-D1-SD1.7
Obtener solicitudes del cliente R-D2-SD2.6
Diagrama de entidades a nivel de usuario Diagrama de entidades combinado a nivel
de usuario
R-D1-SD1.1 R-D1-SD1.5
Negocio existente
Diagrama de entidad a nivel de aplicación R-D1-SD1.5 Definición de resultados Definición de entradas
R-D1-SD1.1
R-D1-SD1.3 Objetivos R-D1-SD1.10
Definición del diccionario de datos del sistema
R-D2-SD2.1
Dependencias de resultados y entradas Compilación de opciones principales
R-D3-SD3.1
R-D3-SD3.7
Identificación de componentes
Alcance funcional R-D3-SD3.1 R-D1-SD1.2
Prototipado Integración del prototipo del sistema
R-D3-SD3.11
En la Tabla A-6 se muestra la comparativa del método AGD en el nivel PIM con RUP,
donde al igual que en el nivel CIM se mantiene un glosario de términos, se tienen modelos de casos de uso en ingeniería directa, además de un prototipo del sistema a un nivel de detalle y los requerimientos o especificación del software.
Tabla A-6. AGD en el nivel PIM comparado con RUP
AGD en el nivel PIM RUP Ingeniería inversa
Diccionario de datos R-D2-SD2.1 Casos de uso R-D2-SD2.9
Ingeniería directa
Presentación de interacción hombre-máquina R-D2-SD2.7 Prototipado del software Integración del prototipo del sistema R-D3-SD3.11
R-D2-SD2.4 Requerimientos del software R-D2-SD2.5 R-D5-SD5.8
Requerimientos del software
Especificación de prueba de aceptación R-D5-SD5.10
En la Tabla A-7 se muestra la comparativa del método AGD en el nivel PSM con RUP,
contiene un repositorio de los requerimientos, una solución conceptual, restricciones y riesgos del proyecto. Se tiene por otro lado la arquitectura del sistema y su desarrollo. Los directores del negocio que están inmersos en el problema, así como la descripción de escenarios específicos entre los usuarios y el sistema.
Tabla A-7. AGD en el nivel PSM comparado con RUP AGD en el nivel PSM RUP
Datos almacenados R-D2-SD2.2 R-D2-SD2.10 Restricciones R-D1-SD1.11 R-D3-SD3.2 R-D1-SD1.2
Soluciones alternativas Solución recomendable
R-D2-SD2.10
Restricciones en requerimientos
Riesgos/Beneficios R-D8-SD8.8 R-D3-SD3.8 Estructura de la arquitectura
R-D3-SD3.10 Arquitectura del
componente Especificación de prueba de integración R-D5-SD5-14
Directores del negocio R-D1-SD1.1 Generación de escenarios R-D2-SD2.7
Análisis de arquitectura Reporte de análisis de arquitectura R-D3-SD3.10
Anexo A
155
En la Tabla A-8 se muestra el nivel de implementación, en el cual la codificación va en la
construcción del código, compilación y ligado, las pruebas de unidad, pruebas de integración, el resultado de la evaluación de las pruebas, así como documentación para el usuario. La integración de código esta en el PS2Set de Operación inicial.
Tabla A-8. AGD en el modelo de implementación (IM) comparado con RUP AGD en el nivel IM RUP
Estructura de división del trabajo Diseño detallado Asignación de unidades
R-D4-SD4.3
Diseño detallado: servicios normales Diseño detallado: métricas
R-D5-SD5.6 Diseño detallado: datos de proceso Especificación de pruebas de aceptación R-D5-SD5.10
Compilación Ligado Carga
R-D4-SD4.1 Codificación
Prueba de unidad R-D4-SD4.2 R-D4-SD4.1 Integración de código R-D4-SD4.4
Elaborar documentación de usuario R-D6-SD6.3
Operación inicial Prueba de integración R-D4-SD4.2
A-1.4 Comparación AGD e IDEF (Integrated DEFinition) [IDEF06] Breve descripción de IDEF Los métodos de IDEF proveen a los individuos y equipos un enfoque disciplinado y confiable a la solución de problemas en apoyo a los esfuerzos tales como: la ingeniería de la empresa, reingeniería, el desarrollo de sistemas de información en gran escala y la integración de la empresa. El IDEF es una técnica de modelado estándar creada por la Fuerza Aérea Norteamericana y utilizada para:
– Crear diagramas y documentos. – Describir operaciones de una empresa
Todos los métodos de IDEF se muestran en la tabla siguiente, categorizados de acuerdo a
su evolución en generaciones. Donde los métodos más usados son del IDEF0 hasta el IDEF4. Además del IDEF0 al IDEF5 son equivalentes a diferentes diagramas UML (como: actividad, clases, objetos, colaboración y estados) y el metamodelo UML (IDEF5).
Métodos de Primera Generación (ICAM21-1981)
Modelado Funcional (IDEF0) (Lo que se hace en la empresa)
Modelado de Información (IDEF1) Modelado de Simulación (IDEF2)
Métodos de Segunda Generación (ICAM-1985) Modelado de Datos(IDEF1X (IDEF1 Extended))
Métodos de Tercera Generación (IICE22-1992…) Captura de Descripción de Procesos (IDEF3) (Define como la empresa hace lo que hace)
Diseño Orientado a Objetos (IDEF4) Captura de Descripción Ontológica (IDEF5)
21 Integrated Computer-Aided Manufacturing 22 Information Integration for Concurrent Engineering
Anexo A
156
Otros Métodos Captura de las bases del Diseño (IDEF6) (dice por que, por que no y como un diseño llego a su configuración final)
Auditoria de Sistemas de Información (IDEF7)
Diseño de Interacción Hombre-Sistema (IDEF8)
Descripción de Restricciones (IDEF9) Modelado de Artefactos de Información (IDEF10)
Diseño Organizacional (IDEF12)
Diseño de Redes (IDEF14)
Comparativa Al comparar AGD con IDEF se hizo desde un punto de vista abstracto, ya que en IDEF no se especifican con claridad los posibles productos del trabajo y éste en su mayoría está enfocado hacia el proceso de negocio, hay algunos métodos IDEF que quedan fuera debido a que no corresponden con los del AGD. Los resultados de esta comparación fueron con respecto a la definición de cada método y su posible aplicabilidad con los productos del trabajo del AGD, visto desde un nivel más abstracto.
Al comparar AGD en el nivel CIM con IDEF mostrado en la Tabla A-9 se ven: la identificación del proyecto, las interacciones que hay entre las personas de la organización, la obtención de los requerimientos, todo lo del proceso de negocio, así como las restricciones. Además de ver un pequeño prototipo de la funcionalidad de acuerdo a los requerimientos.
Tabla A-9. AGD en el nivel CIM comparado con IDEF
AGD en el nivel CIM IDEF Inicialización Identificación del proyecto IDEF1
Obtener solicitud del cliente IDEF1X Alcances y prioridades IDEF9
Planificación-Visión
Entender el negocio IDEF3 Diagrama de entidades a nivel de usuario IDEF0
Diagrama de entidades combinado a nivel de usuario IDEF3 Negocio existente
Diagrama de entidades a nivel aplicación IDEF8 Compilación de entradas principales
Objetivos Definición de entradas
IDEF1 Identificación de componentes
Alcance funcional IDEF3 Prototipado Integración del prototipo del sistema IDEF2
En la Tabla A-10 se muestra el método IDEF contra AGD desde el nivel PIM, donde
podemos encontrar aspectos del prototipo en cierto nivel de detalle, los requerimientos del software derivados del análisis de los requerimientos preliminares, además de la presentación de la interacción entre el usuario y el sistema.
Tabla A-10. AGD en el nivel PIM comparado con IDEF AGD en el nivel PIM IDEF
Ingeniería inversa Procesos funcionales Ingeniería directa
Presentación interacción hombre-máquina IDEF8
Prototipado del software Integración del prototipo del sistema IDEF2 Requerimientos del software
En la Tabla A-11 se muestra la comparación del AGD en el nivel PSM contra el IDEF, en
el cual se puede encontrar que se relacionan ambos en los aspectos de definición de descripciones, los datos que se ocupan para el desarrollo del sistema, como está conformado
Anexo A
157
de acuerdo a la interacción con el sistema para realizar un diseño de la arquitectura por medio de analizar esa interacción. Se menciona el IDEF0 debido a que para sacar un producto del trabajo de AGD se requiere de los actores del negocio.
Tabla A-11. AGD en el nivel PSM comparado con IDEF AGD en el nivel PSM IDEF
Restricciones en requerimientos Restricciones IDEF9 Estructura de la arquitectura Arquitectura del componente
Especificación de prueba de integración IDEF8
Reporte de análisis de arquitectura IDEF8 Análisis de arquitectura Directores del negocio IDEF0
La Tabla A-12 se refiere a qué aspectos de la implementación considera AGD contra
IDEF, la única similitud o aproximación que se encontró fue en como son los procesos y su posible estandarización.
Tabla A-12. AGD en el modelo de implementación (IM) comparado con IDEF AGD en el nivel IM IDEF
Diseño detallado Diseño detallado: servicios normales
Diseño detallado: métricas Diseño detallado: datos de proceso Normas para procesos IDEF3
Codificación Operación inicial
158
Anexo B B-1 Análisis de los 13 diagramas de UML 2.0 con respecto al uso en común de sus elementos. Con el fin de mostrar los elementos de los 13 diagramas de UML 2.0 que se utilizaron para obtener los datos mostrados en el capítulo 4 sección 4.3.2, con respecto al número de elementos exclusivos y al número de elementos en común en cada uno de los diagramas, se realizó este análisis de los elementos de los 13 diagramas, específicamente para obtener los elementos en común de un diagrama con otros diagramas, mostrado en este anexo. Primero, se mostrará una breve semblanza de UML 2.0 y posteriormente se presentarán las tablas de cada uno de los 13 diagramas.
En el transcurso de los años han surgido varias versiones de UML, cada una con un plus. En la actualidad existe la versión de UML 2.0, la cual es el producto del refinamiento y revisiones de las versiones anteriores que se van mejorando. UML está conformado por:
• Superestructura.- En ella se encuentran todos los diagramas que se utilizan al
desarrollar un sistema, es decir, es aquí donde se definen los diagramas y los elementos que lo componen. Es la definición formal de los elementos de UML.
• Infraestructura.- Es un metamodelo que da soporte a la superestructura y en el que se definen los conceptos centrales y de más bajo nivel.
Anexo B
159
• OCL.- Define un lenguaje simple para escribir restricciones y expresiones sobre elementos de un modelo.
• y XMI.- Permite compartir diagramas entre diferentes herramientas de modelado UML.
A continuación se presenta en la ilustración B-1 la estructura taxonómica de UML 2.0 y en
la Tabla B-1 una breve descripción de sus diagramas.
Ilustración B-1. Estructura taxonómica de UML 2.0
Tabla B-1. Breve descripción de diagramas UML 2.0 [AMB04] Diagramas UML 2.0 Que puede ser modelado Prioridad Diagramas de Estructura
Destacan los elementos que deben existir en el sistema modelado.
- Clases Clases, tipos, interfaces y relaciones entre ellos. Alta - Componentes Los componentes importantes dentro de un sistema y las interfaces que ellos usan para
interactuar con otros. Media
- Objetos Los casos de objeto de las clases definidos en el diagrama de clases en configuraciones que son importantes para el sistema.
Baja
- Paquetes La organización jerárquica de grupos de clases y componentes. Baja - Estructura de composición
Las clases o componentes internos y pueden describir relaciones de clases dentro de un contexto dado.
Baja
- Distribución o despliegue
Como el sistema es finalmente desplegado en una situación dada del mundo real. Media
Diagramas de Comportamiento
Enfatizan en lo que debe suceder en el sistema modelado o proceso de negocios.
- Maquina de estados El estado de un objeto en todas partes de su vida y los acontecimientos que pueden cambiar ese estado.
Media
- Actividades Actividades secuenciales y paralelas dentro del sistema. Representa los procesos de negocios de alto nivel, incluidos en el flujo de datos.
Alta
- Casos de uso Interacciones entre un sistema y usuarios u otros sistemas externos. También ayuda al mapeo de los requerimientos al sistema.
Media
- Diagramas de interacción
Es un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado, es decir, la interacción entre objetos.
Secuencia Interacciones entre objetos donde el orden de las interacciones es importante. Alta Comunicación Los modos en los cuales los objetos interactúan y las conexiones que son necesarias para
soportar esa interacción. Baja
Anexo B
160
Cronometraje o tiempos
Las interacciones entre objetos donde el tiempo es un aspecto importante. Baja
Revisión de la interacción
Usa una colección de diagrama de secuencia, comunicación y cronometraje juntos para capturar una importante interacción que ocurre dentro del sistema.
Baja
En la información mostrada en la Tabla B-1 se observa el nivel de prioridad de aprendizaje
de cada uno de los diagramas [AMB04], los que tienen un nivel alto son: de clases, secuencia y actividad, además el diagrama de casos de uso es de prioridad media, pero éste especifica el valor que el sistema entrega a los usuarios y capturan una parte de la funcionalidad que el sistema proporciona, este diagrama afecta y dirige todos los elementos dentro del diseño del sistema.
Una vez presentada la semblanza de UML 2.0 a nivel general, se muestra a continuación
cada uno de los 13 diagramas del UML [UML05] con sus respectivos elementos, además del uso común que se les da en cada uno de los diagramas a partir de la Tabla B-2 a la Tabla B-14, donde la notación para indicar cada uno de los diagramas es la siguiente:
• Casos de Uso = CU • Clases = C • Actividad = A • Secuencia = S • Paquete = P • Objeto = O • Estructura Compuesta = EC • Componentes = Co • Despliegue = D • Comunicación = Com • Revisión de la Interacción = RI • Maquina de Estado = ME • Cronometraje o Tiempo = T
Tabla B-2. Elementos del diagrama de Casos de Uso y su relación con otros diagramas
Elementos Diagramas donde se utiliza
Actor CU, S, Com
Caso de uso CU
Punto de extensión CU
Subject CU
Uso CU,Co
Generalización C, O, CU, D
Incluye CU
Extend CU
Anexo B
161
Tabla B-3. Elementos del diagrama de Actividad y su relación con otros diagramas Elementos Diagramas
donde se utiliza
Actividad A
Acción A
Partición A
Nodo de objeto A
Almacén de datos A
Nodo de decisión A, RI, ME
Nodo merge A
Acción de señal enviada A, ME
Acción de evento recibido A, ME
Nodo inicial A, ME, RI
Nodo Final A, ME, RI
Flujo final A
Región A
Excepción A
Nodo de bifurcación A, RI
Nodo de unión A, RI
Flujo de control A
Flujo de objeto A, RI
Flujo de interrupción A
Tabla B-4. Elementos del diagrama de Maquina de Estado y su relación con otros diagramas
Elementos Diagramas donde se utiliza
Estado ME
Sub máquina de estado ME
Máquina de estado
ME
Estado inicial ME, A, RI
Estado final A, ME, RI
shallowHistory ME
DeepHistory ME
Acción ME
Pseudo estado escogido A, RI, ME
Pseudo estado unido ME
Anexo B
162
Estado compuesto
ME
Acción de señal enviada A, ME
Acción de evento recibido A, ME
Nodo terminado ME
Punto de entrada ME
Región
ME
Punto de salida ME
Transición ME
Tabla B-5. Elementos del diagrama de Cronometraje o Tiempos y su relación con otros diagramas
Elementos Diagramas donde se utiliza
Estado o condición de la línea de tiempo T
Valor general de la línea de vida T
Etiqueta de mensaje T
Evento de destrucción T
Marco
T, S, Com, RI
Línea de vida
T, S, Com, O
Mensaje T, S, Com
Ordenamiento general S, T
Tabla B-6. Elementos del diagrama de Secuencia y su relación con otros diagramas Elementos Diagramas
donde se utiliza
Actor CU, S
Línea de vida S, T, Com, O
Restricciones de duración, Duración, Observación
S
Límite S, Com
Control S, Com
Anexo B
163
Restricciones de tiempo, Observaciones de tiempo
S
Entidad S, Com
Fragmento combinado S
Marco
S, Com, T, RI
Mensaje perdido, mensaje encontrado S
Gate S
Empleo de interacción S, RI
Estado Invariante / Continuaciones S
Stop S
Coregion
S
Mensaje S, Com, T
Self- Message S
Ordenamiento general S, T
Tabla B-7. Elementos del diagrama de Revisión de la Interacción y su relación con otros diagramas
Elementos Diagramas donde se utiliza
Marco
S, Com, T, RI
Decisión A, RI, ME
Nodo inicial ME, A, RI
Nodo final A, ME, RI
Empleo de interacción
RI, S
Interacción
RI
Nodo de bifurcación A, RI
Nodo de unión A, RI
Flujo de objeto A, RI
Anexo B
164
Tabla B-8. Elementos del diagrama de Comunicación y su relación con otros diagramas Elementos Diagramas
donde se utiliza
Actor CU, S, Com
Límite S, Com
Control S, Com
Entidad S, Com
Marco
S, Com, T, RI
Mensaje
S, Com, T
Línea de vida
S, T, Com, O
Tabla B-9. Elementos del diagrama de Paquetes y su relación con otros diagramas
Elementos Diagramas donde se utiliza
Paquete P
Dependencia P, C, O, D
Package Merge P
Package Import P
Tabla B-10. Elementos del diagrama de Clases y su relación con otros diagramas
Elementos Diagramas donde se utiliza
Clase C, EC, Co
Interfaz EC, C, Co
Asociación C, O, D
Generalización C, O, D, CU
Composición C, O
Agregación C, O
Dependencia P, C, O, D
Realización Co, C, O
Realización de la interfaz C, O, Co
Rastro C
Anidar C
Anexo B
165
Tabla B-11. Elementos del diagrama de Objeto y su relación con otros diagramas Elementos Diagramas
donde se utiliza
Especificación de instancia O, S, T, Com
Asociación C, O, D
Generalización C, O, CU, D
Composición C, O
Agregación C, O
Dependencia P, C, O, D
Realización de la interfaz C, O, Co
Realización Co, C, O
Tabla B-12. Elementos del diagrama de Estructura Compuesta y su relación con otros diagramas
Elementos Diagramas donde se utiliza
Clase C, EC, Co
Interfaz EC, C, Co
Parte EC
Puerto EC, Co
Colaboración EC
Empleo de colaboración EC
Conector EC
Role binding EC
Representa EC
Ocurrencia EC
Tabla B-13. Elementos del diagrama de Componentes y su relación con otros diagramas
Elementos Diagramas donde se utiliza
Componente Co
Clase C, EC, Co
Interfaz EC, C, Co
Puerto EC, Co
Artefacto D, Co
Realización de la interfaz C, O, Co
Realización Co, C, O
Uso Co, CU
Anexo B
166
Tabla B-14. Elementos del diagrama de Despliegue y su relación con otros diagramas Elementos Diagramas
donde se utiliza
Nodo D
Artefacto D, Co
Especificación de despliegue D
Asociación C, O, D
Generalización C, O, CU, D
Despliegue D
Manifestación D
Dependencia P, C, O , D
167
Referencias [AGG07] AGG The Attributed Graph Grammar System, http://tfs.cs.tu-berlin.de/agg/, Revisada el 4 de Febrero de 2007. [AGR03] A. Agrawal, G. Karsai and F. Shi, Graph Transformations on Domain-Specific Models, http://www.isis.vanderbilt.edu/publications/archive/Agrawal_A_11_0 _2003_Graph_ Tran.pdf, 2003. [AHS06] Naveed Ahsan Tariq, Naeem Akhter, “Comparison of Model Driven Architecture (MDA) based tools (A Thesis document)”, http://dis.dsv.su.se/~emisnat/CMDA/MDATools_ KTH_KUH_MasterThesis2004_ Telemed5.pdf, 2004, Revisada septiembre de 2006. [ALT07] Altova Umodel, http://www.altova.com/download/umodel/uml_tool.html, 2007. [AMA04] Pablo Amaya, Carlos González, Juan M. Murillo, “Separación de Aspectos en MDA: Una aproximación basada en múltiples vistas”, Actas del I Taller sobre Desarrollo Dirigido por Modelos, MDA y Aplicaciones (DSDM’04), Málaga, España, 9 de noviembre de 2004. [AMA05] Pablo Amaya Barbosa, Carlos González y Juan M. Murillo Rodríguez, “AspectMDA: Hacia un desarrollo incremental consistente integrando MDA y Orientado a Aspectos”, Actas del II Taller sobre Desarrollo Dirigido por Modelos, MDA y Aplicaciones (DSDM’05), Málaga, España, 13 de septiembre de 2005. [AMB04] Scott W. Ambler, “The Object Primer, Agile Model-Driven Development with UML 2.0”, Cambridge University Press, 3
rd edition, 2004.
[AND06] AndroMDA, www.andromda.org2, Revisada septiembre de 2006. [ATOM07] AToM3 A Tool for Multi-Formalism Modelling and Meta-Modelling, http://atom3.cs.mcgill.ca/, Revisada Febrero 2007. [ATL06] ATLAS group LINA & INRIA Nantes, ATL: Atlas Transformation Language, “ATL User Manual version 0.7“, http://www.eclipse.org/m2m/atl/doc/ATL_User_Manual [v0.7].pdf, Febrero 2006. [ARC06] ArcStyle, http://www.arcstyler.com/, Revisada el septiembre de 2006. [BEZ03] Jean Bézivin, Nicolas Farcet, Jean-Marc Jézéque, Benoıt Langlois, and Damien Pollet, “Reflective Model Driven Engineering”, Proceedings of UML 2003, San Francisco, volume 2863 of LNCS, pag. 175-189, Springer (10/2003).
Referencias
168
[BRA03] Peter Braun, Frank Marschall, “BOTL The Bidirectional Object oriented Transformation Language”, http://wwwbib.informatik.tu-muenchen.de/infberichte/2003/TUM -I0307.pdf, Mayo 2003. [BRU02] Bernd Bruegge, Allen H. Dutoit, “Ingeniería de software orientada a objetos”, Prentice Hall, México, 2002. [CAC03-1] Cáceres, P.; Marcos, E.; Vela, B. “A MDA-Based Approach for Web Information System Development”, Workshop in Software Model Engineering (WiSME@UML'2003) in conjunction with UML Conference. San Francisco, USA. http://www.metamodel.com/wisme-2003/07.pdf Octubre, 2003. [CAC03-2] Paloma Cáceres y Esperanza Marcos, “Hacía un proceso metodológico dirigido por modelos para el desarrollo ágil de sistemas de información Web”, Taller de Metodologías Ágiles en el Desarrollo de Software, Alicante, http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf, del 12 al 14 de Noviembre de 2003. [COR06] Luis Enrique Corredera de Colsa, “Arquitectura dirigida por modelos para J2ME”, http://personal.telefonica.terra.es /web/lencorredera/mda_j2me.pdf, Revisada septiembre de 2006. [CMMI02] Carnegie Mellon Software Engineering Institute, Libro: Capability Maturity Model® Integration (CMMISM), Version 1.1, Continuous Representation, Marzo de 2002. [CSE02] Csertan, G. Huszerl, G. Majzik, I. Pap, Z. Pataricza, A. Varro, D. , “VIATRA - Visual Automated Transformations for Formal Verification and Validation of UML Models”, In Proceedings 17th IEEE International Conference on Automated Software Engineering (ASE 2002), Edinburgh, Scotland, 23-27 September 2002. [CZA03] Krzysztof Czarnecki and Simon Helsen, “Classification of Model Transformation Approaches”, http://www.swen.uwaterloo.ca/~kczarnec/ECE750T7/ czarnecki_helsen.pdf , University of Waterloo, Canada, 2003. [DEM05] Sebastien Demathieu, Catherine Griffin, and Shane Sendall, “Model Transformation with the IBM Model Transformation Framework”, http://www-128.ibm.com/developerworks/ rational/library/05/503 _sebas/, 2005. [DIA04] Isabel Díaz, Oscar Pastor, Lidia Moreno, Alfredo Matteo, “Una aproximación Lingüística de Ingeniería de Requisitos para OO-Method”, IDEAS’ 2004, 7º Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes Software, Mayo 2004. [DSDM06] DSDM: Desarrollo de Software Dirigido por Modelos. MDA y Aplicaciones, http://www.lcc.uma.es/~av/MDD-MDA/, revisada agosto de 2006. [ENT06] Enterprise Architect, http://www.sparxsystems.com.au/, 2006.
Referencias
169
[EXE04] Daniel Exertier, Benoit Langlois Xavier Le Roux, "PIM Definition and Description",Proceedings First European Workshop on Model Driven Architecture with Emphasis on Inductrial Application, Univ. Twente, Netherlands , pag. 17-18, Marzo 2004. [GAR04] J. García Molina, J. Rodríguez, M. Menárguez, M.J. Ortín, J. Sánchez, “Un estudio comparativo de dos herramientas MDA: OptimalJ y ArcStyler”, Actas del I Taller sobre Desarrollo Dirigido por Modelos, MDA y Aplicaciones (DSDM’04), Málaga, España, 9 de noviembre de 2004. [GAR06] Jesús García Molina, M. José Ortín, Begoña Moros, Joaquín Nicolás, Ambrosio Toval, “De los Procesos del Negocio a los Casos de Uso”, http://www.willydev.net/ descargas/ WillyDev_modeladodenegocio.pdf, Revisado en Noviembre de 2006. [GON04] Moisés González-García y Ana María Martínez Enríquez, “Método de Desarrollo Arquitectónico en Grupo”, Reporte técnico de la sección de Computación del CINVESTAV, RT-DE-SC-2004-EMOL, 2004. [GON06] Moisés González García, “Método de Desarrollo Arquitectónico en Grupo”, Tesis Doctoral del Área de Computación del Departamento de Ingeniería Eléctrica, del CINVESTAV, agosto del 2006. [GRO02] Timothy J. Grose, Gary C. Doney, Stephen A. Brodsky, Libro: “Mastering XMI Java Programming with XMI, XML, and UML”, 2002. [IBM05] IBM Software Group, “MDA Overview Applied MDA”, http://www.omg.org/ news/meetings/workshops/SOA_MDA_WS_Workshop_CD/00-T-03_Amsden-Part1.pdf, Noviembre de 2005. [IDEF06] Integrated DEFinition Methods “IDEF”, http://www.idef.com/, 2006. [ISO91] ISO/IEC 9126, Software product evaluation - Quality characteristics and guidelines for their use, 1991. [JAC00] Ivar Jacobson, Grady Booch, James Rumbaugh, “El proceso unificado de desarrollo de software”, Pearson education, Madrid, 2000. [KEM07] Case Study – Kemmerer's Library Problem, http://www.dcs.shef.ac.uk/~ajc/ dfa/slides/slides8.pdf, Revisado el 16 de Febrero de 2007. [KERMETA07] Kermeta, http://www.kermeta.org/documents/, Revisada 2 de Febrero de 2007. [KLE03] Anneke Kleppe, Jos Warmer y Wim Bast, Libro titulado: MDA Explained: The Model Driven Architecture: Practice and Promise, Pearson Education, 2003.
Referencias
170
[LAR06] Xabier Larrucea, Ana Belen García Díez, Jason Xabier Mansell, "Practical Model Driven Development process", http://www.cs.kent.ac.uk/projects/kmf/mdaworkshop/ submissions/Larrucea.pdf, Revisado octubre 2006. [LAR97] Larman, C.: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall, primera edición, 1997. [LAY04] L. Williams, L. Layman, “Extreme programming evaluation framework for Object-Oriented LanguagesVersion 1.4”, North Carolina State University, Department of Computer Science, 2004. ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2004/TR-2004-18.pdf Revisada en Enero de 2006. [LOP07] Edna D. López L., Moisés González G., Máximo López S., Desarrollo de la demostración de la tesis: “Caracterización de las fronteras de los modelos MDA mediante UML”, Reporte técnico de la sección de Ingeniería de Software del CENIDET, RT-DCC-1-2007, 2007. [LUC05] Francisco Javier Lucas Martínez, Fernando Molina Molina, Ambrosio Toval Álvarez, “Una Propuesta de Proceso Explícito de V&V en el Marco de MDA”, Actas del II Taller sobre Desarrollo Dirigido por Modelos, MDA y Aplicaciones (DSDM’05), Málaga, España, 13 de septiembre de 2005. [MASTER-03-1] Model-driven Architecture inSTrumentation, Enhancement and Refinement (MASTER),"PIM to PSM mapping techniques", http://modeldrivenarchitecture.esi.es/mda _publicDocuments.html#D2.1, Diciembre 2003. [MASTER-03-2] Model-driven Architecture inSTrumentation, Enhancement and Refinement (MASTER),"PSMs Concepts and Techniques”, http://modeldrivenarchitecture.esi.es/mda_ publicDocuments.html#D2.1 Junio 2003. [MDA03] Object Management Group, Model Driven Architecture Guide 1.0.1, 2003. [MIC06] Chris Micali, “Introduction to Model Driven Development with AndroMDA (Part 1)”, http://www.codeproject.com/ useritems/intro_to_andromda_1.asp, Revisada septiembre de 2006. [MIL03] Joaquín Miller y Jishnu Mukerji, MDA Guide Version 1.0.1, http://www.omg.org/ docs/omg/03-06-01.pdf, 12 de Junio de 2003. [OBJ05] Object Management Group, “MOF 2.0/XMI Mapping Specification, v2.1”, OMG Document formal/2005-09-01, http://www.omg.org/docs/formal/05-09-01.pdf, septiembre 2005. [OPT06] OptimalJ, http://www.compuware.com/products/optimalj/, Revisada septiembre de 2006.
Referencias
171
[OMG06] OMG, Committed Companies and Their Products, http://www.omg.org/mda /committed-products.htm, revisada agosto de 2006. [OMG07] OMG Modeling Specifications, http://www.omg.org/technology/documents/vault. htm #modeling, revisada en el 2007. [PAR00] Isaac Alberto Parra Ramírez, Tesis: Modelado visual orientado a objetos, CENIDET, Diciembre de 2000. [QUE06] Pascual Queralt, Luís Hoyos, Artur Boronat, José Á. Carsí e Isidro Ramos, “Un motor de transformación de modelos con soporte para el lenguaje QVT Relations”, http://www.dsic.upv.es/workshops/dsdm06/files/dsdm06-14-Queralt.pdf, DSDM: Desarrollo de Software Dirigido por Modelos. MDA y Aplicaciones DSDM’06, España, 3 de Octubre de 2006. [QVT05] Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, http://www.omg.org/docs/ptc/05-11-01.pdf, Noviembre de 2005. [ROM03] Javier Román Castañeda, Tesis: Sistema para el diseño detallado de métodos de clases con UML, CENIDET, Marzo de 2003. [RUI03] Francisco Ruiz González, “MANTIS: Definición de un Entorno para la Gestión del Mantenimiento de Software”. Tesis Doctoral. Depto. de Informática, Universidad de Castilla-La Mancha, junio de 2003. [RUP05] IBM Corporation, Rational Unified Process (Evaluation) “RUP” Version 7.0.1.E, 2005. [SAN06-A] Jesús Sánchez Cuadrado, Jesús García Molina, Marcos Menárguez, “RubyTL: A Practical, Extensible Transformation Language”, In 2nd European Conference on Model Driven Architecture, Lecture Notes in Computer Science, June 2006, volume 4066, pages 158–172. [SAN06-B] Jesús Sánchez Cuadrado, Jesús J. García Molina y Marcos Menárguez Tortosa, “RubyTL: un lenguaje de transformación de modelos extensible”, XV Jornadas de Ingeniería del Software y Bases de Datos JISBD, Barcelona, 2006. [SEL06] Bran Selic,"Model-Driven Development: Its Essence and Opportunities",Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing, http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10852/34193/01 630494.pdf , 2006. [SHA95] Mary Shaw, David Garlan, Robert Allen, Dan Klein, John Ockerbloom, Curtis Scott, Marco Schumacher, “Candidate Model Problems in Software Architecture”, http://www.cs. cmu.edu/afs/cs/project/vit/ftp/pdf/ModPrb1-3.pdf, Enero de 1995.
Referencias
172
[STD98] IEEE, “IEEE Recommended Practice for SoftwareRequirements Specifications”, IEEE Std. 830-1998, 1998. [STE02] Perdita Stevens y Rob Pooley, Libro titulado: Utilización de UML en Ingeniería del Software con Objetos y Componentes, Pearson Educación, S.A., Madrid, 2002. [STY07] Progress Software Corporation, “Stylus Studio 2007 XML Enterprise Suite”, http://www.stylusstudio.com/, 2007. [TEFKAT07] Tefkat The EMF Transformation Engine, http://tefkat. sourceforge.net/ publications.html, Revisada Enero 2007. [TRO03] Dinh Trong Thanh Trung, “Rules for generating code from UML collaboration diagrams and activity diagrams”, http://www.cs.colostate.edu/~trungdt/code_generation/ Thesis.pdf , 2003. [TUC03] Allen Tucker, Robert Noonan, “Lenguajes de programación. Principios y Paradigmas”, MC Graw Hill, Madrid, 2003, Pág. 89, 271. [ULR06] Ulrich A. Nickel, Jörg Niere, Jörg P. Wadsack, Albert Zündorf, “Roundtrip Engineering with FUJABA”, http://www.coobra.cs.uni-kassel.de/fileadmin/se/publications/ NNWZ00.pdf , 2000, Revisada el 25 de octubre de 2006. [UML05] Object Management Group, “Unified Modeling Language: Superstructure”, http://www.omg .org/docs/formal/05-07-04.pdf, Agosto de 2005. [VIATRA06] VIATRA 2 Model Transformation Framework User’s Guide, http://dev. eclipse.org/viewcvs/indextech.cgi/gmt-home/subprojects/VIATRA2/doc/viatratut_October20 06.pdf, Octubre de 2006. [VIS07] Visual Paradigm for UML, http://www.visual-paradigm.com/product/vpuml/, 2007. [VMT07] VMTS Web Site, http://avalon.aut.bme.hu/~tihamer/research/vmts/, Revisada 23 de enero de 2007. [WIL04] Edward D. Willink,“Towards a Formalization of UMLX”, http://dev.eclipse.org/ viewcvs/indextech.cgi/gmt-home/subprojects/UMLX/doc/UmlxFormalization/UmlxFormaliza tion.pdf, 19 de Diciembre de 2004. [WIN88] Jeannette Wing, A Study of 12 Specifications of the Library Problem, IEEE Software, July 1988, pp. 66-76. [XMI01] XMI Reference,http://www.zvon.org/xxl/XMI/Output/index.html, 2001. [XMI05] Object Management Group, MOF 2.0/XMI Mapping Specification, v2.1, http:// www.omg .org/docs/formal/05-09-01.pdf, Septiembre 2005.
Referencias
173
[XSLT07] W3C; “XSL Transformations version 1.0”. URL: http://www.w3.org/ TR/xslt, Revisada el 15 de enero de 2007. [ZHA05] Wei Zhang, Hong Mei, Haiyan Zhao, Jie Yang, “Transformation from CIM to PIM: A Feature-Oriented Component-Based Approach”, Models 2005, Jamaica, volume 3713 of LNCS, pag. 248-263, 2005. [ZUN02] Dr. Albert Zündorf, “Rigorous Object Oriented Software Development”, http://www.se.eecs.uni-kassel.de/se/fileadmin/se/publications/Zuen02.pdf, 2002.
