Especificación formal en OCL de reglas de consistencia entre el modelo de clases y de casos de uso de UML
Resumen: En el ciclo de vida del software, durante las fases de definición y análisis se realiza una especificación de los requisitos. Para ello, es necesario realizar un proceso de captura de las necesidades y expectativas de los interesados, que se traduce posteriormente en un conjunto de modelos...
- Autores:
-
González Calderón, Guillermo
- Tipo de recurso:
- Fecha de publicación:
- 2007
- Institución:
- Universidad Nacional de Colombia
- Repositorio:
- Universidad Nacional de Colombia
- Idioma:
- spa
- OAI Identifier:
- oai:repositorio.unal.edu.co:unal/20176
- Acceso en línea:
- https://repositorio.unal.edu.co/handle/unal/20176
http://bdigital.unal.edu.co/10621/
- Palabra clave:
- 0 Generalidades / Computer science, information and general works
Desarrollo del software
Ingeniería de software
- Rights
- openAccess
- License
- Atribución-NoComercial 4.0 Internacional
Summary: | Resumen: En el ciclo de vida del software, durante las fases de definición y análisis se realiza una especificación de los requisitos. Para ello, es necesario realizar un proceso de captura de las necesidades y expectativas de los interesados, que se traduce posteriormente en un conjunto de modelos que representan tanto el problema como su solución. Por lo general, la mayoría de esos modelos se expresan en el Lenguaje Unificado de Modelamiento (UML), dirigido por el Grupo de Gestión de Objetos (Object Management Group, OMG). UML define un conjunto de artefactos que permiten especificar los requisitos del software, los cuales deberían guardar consistencia cuando se traten del mismo modelo, ya que están definidos bajo las reglas de buena formación (Well-Formedness Rules, WFR), las cuales se encuentran definidas dentro de la especificación de UML en el Lenguaje de Restricciones de Objetos (Object Constraint Language, OCL). La consistencia interna de cada artefacto está por tanto definida en la especificación de UML y algunas de las herramientas CASE (Computer-Aided Software Engineering) utilizan esas reglas intramodelo para validar este tipo de consistencia. Sin embargo la consistencia entre diferentes artefactos no se encuentra definida en la especificación de UML y poco se ha trabajado con este tipo de consistencia; además, los trabajos que se han realizado en este tema se identifican por: • No se suele definir de manera formal la consistencia entre los diferentes artefactos. • Por lo general se estudia sólo la consistencia entre alguno de los artefactos y el código resultante. •Algunos establecen reglas formales de consistencia, pero únicamente a nivel de intramodelo. Entre los artefactos más utilizados para especificar una pieza de software se encuentran el diagrama de clases y el diagrama de casos de uso, los cuales suministran dos perspectivas diferentes del desarrollo de software: por un lado el diagrama de clases, de tipo estructural, muestra los objetos del mundo y sus relaciones; por otro lado, el diagrama de casos de uso, de tipo comportamental, se concentra en las funciones que realizan los actores del mundo para lograr un resultado en el software. Estos dos puntos de vista deberían ser complementarios y, por ello, tener información común, susceptible de ser sometida a un análisis de consistencia. En esta Tesis se propone un método para verificar la consistencia entre el diagrama de clases y el diagrama de casos de uso de UML de una manera formal. Dicho proceso se lleva a cabo evaluando una serie de reglas definidas en OCL que se deben cumplir para garantizar que la información brindada por dichos modelos sea consistente. Como se reconoce la participación de los dos diagramas en la elaboración de las Interfaces Gráficas de Usuario (Graphical User Interfaces, GUI), se define adicionalmente la consistencia con este artefacto. Las reglas se implementaron en XQuery, utilizando como diagramas de entrada representaciones en XML generadas con la herramienta CASE ArgoUML® (en el caso del diagrama de clases y de casos de uso) y con Microsoft Visio® (en el caso de las GUI). Finalmente, se muestra un caso de estudio donde se aplican estas reglas y se muestran los posibles errores y advertencias que se tienen entre los elementos de tales artefactos. |
---|