CAP 1 DE KE2 revisores - cenidet.edu.mx Alejandro... · Específicamente se propone un ambiente de modelado orientado a los diagramas de estados propuestos por el Lenguaje de Modelado

CCAAPPÍÍTTUULLOO 11

CCoonncceeppttooss GGeenneerraalleess

"Algunos ven las cosas como son y preguntan ¿Por qué?, Yo sueño en lo que nunca existió y pregunto ¿Por qué no?".

- ROBERT F. KENNEDY 1.1 Introducción 1.2 Trabajos Relacionados 1.3 Descripción del problema 1.4 Objetivo de la Tesis 1.5 Hipótesis 1.6 Referencias

2

1.1. INTRODUCCIÓN El área de aplicación de la presente tesis, cae dentro del modelado de sistemas de software. Específicamente se propone un ambiente de modelado orientado a los diagramas de estados propuestos por el Lenguaje de Modelado Unificado (UML), donde se pueda visualizar la parte dinámica de un sistema y que mantenga una relación consistente con los diagramas de clases.

El trabajo de tesis forma parte del proyecto global denominado suite cenidet-UML (SCUML), que es desarrollado por el grupo de Ingeniería de Software del Centro Nacional de Investigación y Desarrollo Tecnológico (Cenidet), Ver Figura 1.1. De la SCUML se han desarrollado los siguientes módulos: Modelado Visual Orientado a Objetos (SOODA); Generador de Código para el Lenguaje C utilizando una notación de diseño detallado (DDVi); el módulo de Ingeniería inversa de código fuente en C++ para la obtención de su diseño; un ambiente de modelado y diseño de sistemas de software utilizando diagramas de secuencia; un ambiente de modelado y documentación de sistemas de software utilizando diagramas de casos de uso; ingeniería inversa desde código escrito en java y un ambiente de modelado con diagramas de paquetes, todos estos ambientes han sido trabajos de tesis de maestría desarrollados basándose en el UML. En la tesis presente se ha propuesto el desarrollo de una de las partes de modelado dinámico de objetos desde el punto de vista del comportamiento de su estado, utilizando los diagramas de estados del UML.

Figura 1.1. Arquitectura de la Suite cenidet-UML

Dados los nuevos paradigmas de programación, es conveniente utilizar la Programación Orientada a Objetos por su utilidad y por su naturaleza, así también el Lenguaje de Modelado Unificado, los Patrones de Diseño y los Lenguajes Visuales por los beneficios que brindan.

Programación orientada a objetos (POO): Es una nueva filosofía de programación que

se basa en la utilización de objetos. El objetivo de la POO es "proponer" una serie de normas de desarrollo que aseguren y faciliten el mantenimiento y reuso del software.

Suite CENIDET-UML

Diagramas de Estados

Ke2

Diagramas de Casos de Uso

SADUC

Diagramas de Clases

SOODA

Diagramas de Paquetes

Ppkg

Ingeniería inversa de

Código C++ y Java

Diseño detallado de métodos

DDVi

Diagramas de Secuencias

Ingeniería Inversa

a diagramas de secuencias

Pendiente

Terminado

Trabajo Propuesto

3

UML: Es un lenguaje de modelado para visualizar, especificar, construir y

documentar los componentes de un sistema de software, utilizando distintos diagramas que modelan dicho sistema, estos diagramas representan el paso de mensajes entre métodos, la arquitectura de sistemas, el estado que puede tomar un objeto, etc.

Patrones de diseño: Describen un problema que ocurre repetidas veces en algún contexto determinado de desarrollo de software, y entregan una buena solución ya probada. Esto ayuda a diseñar correctamente en menos tiempo, ayuda a construir programas reusables y extendibles, y facilita la documentación.

Lenguaje visual: Características visuales (forma, tamaño, posición, orientación, color,

textura, etc.) de un conjunto de elementos de diseño (puntos, líneas, planos, volumen, etc.) y la manera en que se relacionan unos con otros (balance, ritmo, estructura, proporción, etc.) en la solución de un problema de comunicación particular.

El uso de las herramientas de ingeniería de software asistida por computadora

(CASE) puede mejorar la productividad en el desarrollo de un sistema de software. Y por productividad se entiende tanto la eficiencia en el desarrollo, como la efectividad del sistema desarrollado. La eficiencia se refiere al costo, tanto en tiempo como en dinero. La efectividad se refiere al grado en que el sistema satisface las necesidades de los usuarios. Para obtener una buena productividad, subir el nivel de efectividad puede ser más importante que aumentar la eficiencia.

El documento de tesis se encuentra organizado en el orden siguiente: (Capitulo 1)

Conceptos Generales, (Capitulo 2) Marco Teórico, (Capitulo 3) Desarrollo, (Capitulo 4) Pruebas, (Capitulo 5) Resultados y Conclusiones.

4

1.2 TRABAJOS RELACIONADOS 1.2.1 Herramientas Analizadas

Dentro de la presente tesis se muestra un estudio de diferentes herramientas comerciales, las cuales permiten el modelado de sistemas utilizando el UML (Unified Modeling Language). Existe una gran diversidad de herramientas que modelan basándose en el UML, se han elegido algunas de las más representativas que a continuación se describen.

1.2.1.1 Rational Rose [RAT04]

El Object Management Group (OMG), aceptó lanzar al mercado el UML, proyecto que Rational Co. consideró y propuso como el estándar oficial de notación para el desarrollo de software bajo el esquema Orientado a Objetos (OO). Rational Co. fue la empresa que promovió la iniciativa de unificar los distintos tipos de modelado que existían. Rational Rose es el ambiente de modelado que más herramientas incluye para facilitar el diseño de sistemas OO, teniendo como base de modelado al UML y sus extensiones.

1.2.1.2. GDPro [GDP04]

Es una herramienta de modelado que incluye ingeniería inversa a sistemas de software OO, produciendo automáticamente modelos UML, los que permiten observar la estructura del código, mapas de relaciones, objetos, métodos y propiedades. GDPro puede ser utilizado para comenzar el diseño de un sistema para después generar el código a partir del modelo. GDPro ha recibido premios como la herramienta de mejor manejo y desempeño.

1.2.1.3. Visio [VIS04]

Visio Enterprise es un producto de Microsoft. Fue diseñado pensando en la administración de aplicaciones, la administración de redes, análisis y diseños de bases de datos, diseños de Internet/Intranets, ingeniería de procesos de negocios y desarrollo de software para administrar aplicaciones complejas de tecnologías de información por medio de diagramas del UML y sus extensiones.

1.2.1.4. MagicDraw [MAG04]

MagicDraw es un ambiente visual basado en el UML para el modelado de sistemas OO. La herramienta de desarrollo es útil para los analistas de negocios, los analistas del software, los programadores o los escritores de la documentación de un sistema OO. La herramienta facilita el análisis y el diseño de los sistemas OO y de las bases de datos OO. MagicDraw provee la ayuda ida-vuelta completa para Java, C++, y de CORBA IDL.

La tabla No. 1 muestra las funciones de las herramientas analizadas anteriormente,

haciendo énfasis en la falta de consistencia entre una clase, o un conjunto de ellas, de un diagrama de clases y un diagrama de estados.

5

Tabla 1.1. Funciones de las herramientas que modelan con UML

Herramientas Soporta todos los

diagramas de UML Ingeniería inversa para obtener

diagramas en UML Consistencia entre clases y Diagramas de Estados

Rational Rose Sí Sí No

GDPro Sí Sí No Visio Sí Sí No

MagicDraw Sí Sí No

1.2.2 Artículos Analizados

1.2.2.1. State Machine Shortcuts [A1]

En el artículo se relata el modelado de sistemas a partir de los diagramas de estados. Se hace referencia a dos formas de modelado que se utilizan para determinar el comportamiento de un objeto: las máquinas de estado basadas en eventos, en las cuales sus transiciones ocurren en respuesta a eventos y, las máquinas de estado periódicas las cuales funcionan a intervalos regulares, y sus transiciones internas responden a cambios de los datos o señales de entrada, las que se encuentran en el rango de tiempo modelado.

Este artículo permitió un primer acercamiento al manejo e interpretación de los

diagramas de estados y de los elementos que lo componen. Para generar un diagrama de estados es necesario conocer su definición, por lo cual el artículo hace evidente algunos de los elementos que lo definen, lo cual permite identificar la composición de los diagramas de estados.

1.2.2.2. Describing the Syntax and Semantics of UML Statecharts in a Heterogeneous Modelling Environment [A2]

El documento describe la formalización de la semántica para los diagramas de estados en un ambiente de modelado heterogéneo, mostrándose parte de la definición de los diagramas de estados. Para la formalización de la semántica se utiliza el Graph-Type Definition Languaje (GTDL) [JAN00]. La semántica del lenguaje generado se especifica por los mismos diagramas de estados, que representan la semántica operacional del grafo sintácticamente correcto. Al final, basados en la semántica que ha sido generada, se crearon componentes ejecutables para la realización de las pruebas.

El trabajo proporciona un formalismo para la generación de los diagramas de

estados utilizando el GTDL. Sin embargo la formalización no deja de contener una parte textual, y es más difícil de relacionar con las oraciones visuales que se generan con los diagramas de estados. El resultado del trabajo fortaleció la intención de generar una gramática visual relacional para los diagramas de estados.

6

1.2.2.3. Checking General Safety Criteria on UML Statecharts [A3]

El objetivo del artículo es “especificar los errores más importantes que se presentan en el modelado con diagramas de estados, como lo es la incompletes y la inconsistencia (interna)”. El trabajo se realizó para el diseño de Clt4iT, una herramienta de seguridad crítica y multiplataforma, la cual es parte de un sistema en tiempo real. Para llevar a cabo el trabajo se ha hecho un estudio de las expresiones del Object Constraint Language (OCL) y sus limitaciones. El resultado obtenido ha sido comprobar por medio de sus métodos implementados, si el diagrama de estados está completo y es correcto.

Este grupo de desarrollo destaca la importancia que tienen los modelos bien desarrollados, haciendo mención del costo de corrección en fases posteriores. Para tener un modelado completo de los diagramas de estados, deben tomarse en cuenta varios criterios para ser implementados, muchos de estos criterios se encuentran en la parte de especificación de requerimientos de esta tesis y son los que han dado origen a un ambiente de desarrollo basado en los diagramas de estados del UML.

1.2.2.4. On the Compositional Properties of UML Statechart Diagrams [A4]

En el artículo se muestran errores de modelado comunes de los diagramas de estados de UML, como lo son las construcciones redundantes y las construcciones inconsistentes o intratables. Se especifican las propiedades básicas de una máquina de estados. Se hace una revisión de la interpretación de la semántica de los diagramas de estado del UML, evidenciando así las confusiones que existen y que pueden surgir en las transiciones o en los estados mismos.

Con el trabajo desarrollado se pueden destacar los errores de modelado en construcciones inconsistentes dentro del mismo diagrama de estados. Lo cual permite realizar un ambiente de modelado que evite errores como lo son: las transiciones vacías y construcciones redundantes.

1.2.2.5. Visualizing Graphical and Textual Formalisms [A5]

La herramienta que los autores del artículo han desarrollado llamada “Visual” produce automáticamente el diagrama de estados, tomando la información extraída de una especificación informal de los diagramas de estados, logrando con ello una formalización de dicha especificación. Se hace mención de la importancia de la formalización, lo cual respalda la necesidad de realizar una gramática que pueda validar las oraciones visuales de los diagramas de estados.

Lo importante a tomar del artículo es la observación de que “los formalismos

visuales tienden un puente sobre el espacio entre las especificaciones informales y formales, ofreciendo notaciones gráficas con semántica”. Por lo que el tener un lenguaje visual que es comprensible, puede tener una representación informal pero con bases formales de creación.

7

1.2.2.6. A Relationship Between Sequence and Statechart Diagrams [A6]

El artículo muestra a los diagramas de secuencias y la manera de verificar la coherencia (consistencia) con respecto a los diagramas de estados, por medio de cálculos “pi”, que son un proceso de álgebra donde sus subprocesos interactúan enviando vínculos de comunicación uno a otro. La consistencia que se implementa trabaja bajo lo siguiente: se buscan los mensajes dentro del diagrama de secuencias y se establece la relación de dichos mensajes con las acciones del diagrama de estados. En este artículo se reconoce también que UML carece de una semántica formal.

El trabajo que presenta el artículo hace evidente la importancia de la consistencia entre diagramas, en este caso entre diagramas de secuencias y diagramas de estados. La solución matemática que proponen no es la más sencilla, pero formaliza el vínculo de un diagrama con otro. El artículo ha permitido el estudio de una manera distinta de la consistencia entre diagramas, la cual es diferente a la presentada en la presente tesis.

1.2.2.7. Completeness and Consistency Analysis of UML Statechart Specifications [A7]

El artículo describe dos métodos y herramientas para el análisis seguro y automático de las especificaciones de los diagramas de estados de UML. Uno de los métodos revisa que el diagrama esté completo y consistente desde el punto de vista determinista, basándose en la estructura estática de la especificación. El segundo método realiza un análisis dinámico comprobando las características de acceso relacionadas con la seguridad, ayudándose de un algoritmo llamado “inspector del modelo”.

Se hace notar la importancia de la formalización que debe existir en la especificación de lenguajes, para el caso de UML. La consistencia se trata por el concepto de determinismo de los autómatas finitos. Así se deduce que el determinismo debe ser aplicado, esto sustenta tambien la naturaleza de los diagramas de estados al ser una particularidad de los autómatas finitos deterministas.

1.2.2.8. Defining a Statechart Language using UML [A8]

Aquí se muestra el uso del UML como un lenguaje para definir la sintaxis, concreta y visual para los lenguajes visuales utilizando los diagramas de estados. La intención ha sido utilizar un estándar y un lenguaje extenso para entregar definiciones más completas y precisas de los lenguajes visuales, y así obtener las bases para la generación semiautomática de herramientas.

El artículo muestra cómo a partir de los diagramas de estados se puede definir la

sintaxis de lenguajes visuales, elaborando diagramas que muestren visualmente las rutas por las que las oraciones pueden ser aceptadas o rechazadas para un lenguaje dado. Este trabajo muestra una manera más de formalizar los lenguajes visuales, y ha sido evaluado formalizando el lenguaje visual de los diagramas de estados.

8

1.2.2.9. Consistent Design of Embedded Real-time Systems with UML-RT [A9]

En el artículo el concepto de consistencia para los diagramas de estados se utiliza en la relación de los diagramas de secuencias y los diagramas de estados, desde el punto de vista de las restricciones de tiempo, según la definición de cada uno de los diagramas. Los conceptos de consistencia se distinguen en los aspectos sintáctico, semántico y de tiempo real, considerando los recursos del procesador y la programación.

El concepto de consistencia nuevamente se hace presente y se le da la importancia que merece, aunque no desde el punto de vista de la presente tesis; el artículo justifica claramente la aplicación de la consistencia y permite tener una visión objetiva del problema que se ha resuelto en esta tesis.

1.2.2.10. Semantics of the Unified Modelling Language [A10]

El UML se ha propuesto recientemente como un lenguaje estándar para expresar diseños orientados a objetos. Desafortunadamente, en su forma actual el UML carece de una semántica definida. Esto significa que es difícil determinar qué diseños son consistentes, si la modificación de un diseño es correcta y si un programa implementa correctamente un diseño.

Las técnicas de validación y verificación de los diagramas son: claridad, equivalencia y consistencia, extensibilidad, refinamiento y las pruebas. Dentro de todos estos factores a implementar, la consistencia y la formalización visual de la semántica son el caso de estudio de la presente tesis.

El artículo se enfoca a evidenciar la falta de semántica en los diagramas, indicando que ésta es necesaria para tener diseños bien definidos y comprobados. Se indica que en algunas herramientas de modelado con base en UML, es posible relacionar componentes de los diagramas de manera libre y sin control alguno. Por tanto, las restricciones para la generación de diagramas por parte de estas herramientas no son suficientes.

Para el análisis de los artículos anteriores se debe entender que unos se refieren al

manejo de la consistencia mientras que otros a la formalización de los diagramas de estados. Los trabajos que se refieren a la consistencia muestran un concepto de consistencia distinto al de la presente tesis, ya que tratan el aspecto determinista de un diagrama y la consistencia que existe entre diagramas de estados y los diagramas de secuencias, el ultimo aspecto es el mas acercado al objetivo de la consistencia de esta tesis, ya que la consistencia se mantiene a partir de los mensajes del diagrama de secuencias y las acciones de los diagramas de estados, el estudio de estos trabajos ha permitido observar otros aspectos del modelado consistente de sistemas, sin embargo no han sido desarrollados para la aplicación de la consistencia entre los diagramas de estados y los diagramas de clases.

9

Los trabajos cuyo caso de estudio es la formalización de los diagramas de estados

por algún método que no sea el que plantea el OCL, manejan algoritmos matemáticos, tratan la semántica del UML, utilizan a los diagramas de estados para formalizar lenguajes visuales. Algunos trabajos presentan una formalización que es difícil de comprender a simple vista, por lo que se fortaleció la idea de implementar una gramática visual que muestre claramente las reglas de producción para la generación de una oración visual. 1.3 DESCRIPCIÓN DEL PROBLEMA

La falta de consistencia de información puede ocasionar un costo de desarrollo mayor al momento de la implementación del sistema, dando como consecuencia una baja calidad del software. 1.3.1 Problema

A toda clase que pertenezca a un diagrama de clases que no sea abstracta, le

corresponde un diagrama de estados el cual modela el estado que puede alcanzar cada objeto instancia de la clase. En el diagrama de estados se utilizan los datos de una clase tales como: el nombre de la clase, el nombre de los atributos y el nombre de los métodos; los cambios que se puedan dar en la definición de una clase deben verse reflejados en su correspondiente diagrama de estados. Estos cambios pueden ser: el borrado de una clase, el cambio de nombre de una clase, el borrado de un atributo, el cambio de nombre de un atributo, el borrado de un método y el cambio de nombre de un método; si alguno de estos cambios se llegan a dar, podrían crearse diagramas de clase y de estado desasociados y estos pueden representar contextos diferentes de aplicaciones distintas.

La consistencia que se aplica en esta tesis debido a los cambios que se den a partir

del diagrama de estados y que pueden verse reflejados en la herramienta de los diagramas de clases, solamente es por la existencia o ausencia del diagrama de estados que representa a cada una de las clases del diagrama de clases. La definición de una clase en el diagrama de clases no es afectada por los cambios que puedan darse en el diagrama de estados; ya que el diagrama de estados, el cuerpo de sus estados y sus transiciones, se generan a partir de una estructura de datos que contiene la definición de cada una de las clases y que es generada por el mismo diagrama de clases, así, una transición es llevada a cabo por la activación de un evento que puede ser un método y que debe existir en la clase representada, si ese método no esta definido en la clase, no puede ser incluido en el diagrama de estados.

El problema que se ha planteado es el siguiente:

En la actualidad no existen herramientas CASE o prototipos académicos que establezcan la consistencia entre los diagramas de clase y los diagramas de estado. Así también en la suite Cenidet-UML no existe una forma de integración entre las herramientas que componen la suite, esta tesis pretende que la relación SOODA1

[HER03]-diagramas de Estado tengan una conexión. 1 SOODA es el nombre del ambiente en el que se modelan diagramas de clases, dentro de la Suite Cenidet-UML

10

El problema planteado ha sido resuelto en la presente tesis. 1.4 OBJETIVOS 1.4.1 Objetivo General

El objetivo General de la Tesis es diseñar e implementar un ambiente visual de modelado de objetos utilizando diagramas de estados, que permitan describir el comportamiento dinámico de los objetos de un sistema. 1.4.2 Objetivos Específicos

• Analizar los Diagramas de Estados propuestos en UML para especificar la gramática que los represente.

• Analizar e implementar la relación de datos entre un diagrama de clases y un

diagrama de estados por medio de la consistencia. 1.5 HIPÓTESIS

La hipótesis plantea que: “Es posible establecer la consistencia entre una clase (de un diagrama de clases) y un diagrama de estados. Por lo tanto si SOODA modela un diagrama de clases, entonces se podrá establecer una conexión entre SOODA y los diagramas de Estado”.

11

1.6 REFERENCIAS

[HER03] Hernández Velázquez Miguel. Ingeniería inversa de código fuente en C++ para la obtención

de su diseño. Tesis CENIDET, Agosto del 2003. [RAT04] http://www.rational.com Enero del 2004. [GDP04] http://www.embarcadero.com/ Enero del 2004. [MAG04] http://www.magicdraw.com/ Enero del 2004. [VIS04] http://www.microsoft.com Enero del 2004. [JAN00] Janneck J. W. Graph-type Definition Language (GTDL) - Specification. Technical report,

Computer Engineering and Networks Laboratory, ETH Zurich, 2000. [A1] State machine shortcuts

http://www.embedded.com/columns/ti, Noviembre del 2003. [A2] Describing the Syntax and Semantics of UML Statecharts in a Heterogeneous Modelling

Environment, http://www.springerlink.com/, Noviembre del 2003. [A3] Checking General Safety Criteria on UML Statecharts, http://www.springerlink.com/

Noviembre del 2003. [A4] On the Compositional Properties of UML Statechart Diagrams,

http://www.dcs.shef.ac.uk/~ajhs/papers/compose.pdf, Noviembre del 2003. [A5] Visualizing Graphical and Textual Formalisms,

http://csdl.computer.org/comp/proceedings/hcc/2001/0474/00/04740120.pdf, Noviembre del 2003.

[A6] A relationship between sequence and statechart diagrams.

http://www.disi.unige.it/person/ReggioG/UMLWORKSHOP/Girardet.pdf, Noviembre del 2003.

[A7] Completeness and Consistency Analysis of UML Statechart Specifications,

hobbit.inf.mit.bme.hu/FTSRG/Publications/DDECS2001a.pdf, Noviembre del 2003. [A8] Consistent Design of Embedded Real-time Systems with UML-RT, http://www.dess-

itea.org/publications/ISORC2001-C-LAB.pdf, Noviembre del 2003. [A9] Defining a Statechart Language using UML, http://www2.informatik.uni-

erlangen.de/VLFM01/Statecharts/AkKe.pdf. Noviembre del 2003. [A10] Semantics of the Unified Modelling Language, http://citeseer.nj.nec.com/398612.html.

Noviembre del 2003.


MMaarrccoo TTeeóórriiccoo

"Si el balón va a gol, y el portero no lo alcanza, es ¡¡¡GOOOL!!!"

- K GLEZ. 2.1 Introducción 2.2 Modelado de Sistemas de Software 2.3 Lenguaje de Modelado Unificado 2.4 Programación Orientada a Objetos 2.5 Patrones de Diseño 2.6 Lenguajes Visuales 2.7 Referencias

13

2.1 INTRODUCCIÓN El conjunto de conocimientos bajo los cuales se desarrolla esta tesis, se muestran en la Figura 2.1.

Ningún hecho o fenómeno de la realidad puede abordarse sin una adecuada conceptualización, por lo cual en este capítulo se presenta una breve descripción de los temas en los que se encuentra englobada esta tesis. Partiendo de todos los conocimientos que presenta cada uno de las temas, se ha obtenido una nueva propuesta de trabajo dentro del modelado de sistemas de software.

Los temas que están relacionados con la presente tesis son: Modelado de Sistemas de Software, el Lenguaje de Modelado Unificado, los Patrones de Diseño, la Programación Orientada a Objetos, los Lenguajes Visuales y la Gramática Visual Relacional.

Figura 2.1. Esquema del marco teórico

Modelado de Sistemas de Software

Patrones de Diseño

Programación Orientada a Objetos

Lenguajes Visuales Lenguaje de Modelado Unificado

Gramática Visual Relacional

14

2.2 MODELADO DE SISTEMAS DE SOFTWARE Los modelos se crean para entender mejor la entidad que se va a construir. Cuando la entidad es algo físico como un edificio, un avión, una máquina, podemos construir un modelo idéntico en forma, pero más pequeño. Sin embargo cuando la entidad que se va a construir es software, nuestro modelo debe tomar una forma diferente. Debe ser capaz de modelar la información que transforma el software, las funciones (y subfunciones) que permiten que ocurran las transformaciones y el comportamiento del sistema cuando ocurren estas transformaciones. [PRE01]

En el desarrollo de software se involucran muchos grupos de trabajo. Cada uno está interesado en diferentes propiedades del sistema basados en el rol que juegan en el desarrollo. Para que la comunicación entre éstos grupos sea posible, las perspectivas apropiadas, o vistas en el sistema deben ser modeladas, y los lenguajes apropiados para hacerlo deben ser utilizados. Diferentes perspectivas pueden representar diferentes niveles de abstracción. [VAN01]

Varios aspectos del sistema son frecuentemente considerados y modelados por separado, un ejemplo es el aspecto de datos y la función. Durante o después del modelado de procesos, alguna integración debe tener lugar para asegurar la consistencia entre los diferentes aspectos de modelado. [VAN01]

En el nivel de lenguajes de programación, un módulo se refiere a una unidad identificable con respecto a la compilación, Se usa una definición similar del término ‘módulo’ con respecto al diseño: un módulo es una unidad identificable en el diseño. [VAN01]

Las características de diseño que comúnmente se buscan, son aquellas que facilitan el mantenimiento y el reuso: simplicidad, una clara separación de conceptos en diferentes módulos, y la visibilidad de la información. Los sistemas que tienen estas propiedades son más fáciles de mantener ya que permiten concentrar la atención en las partes que son directamente afectadas por los cambios.

Las cinco áreas interrelacionadas que tienen impacto en las características principales del modelado de sistemas son:

• Abstracción • Modularidad • Ocultamiento de datos • Complejidad • Estructura del sistema.

La abstracción significa que nos concentramos en las características esenciales y se

ignoran, desde lo abstracto, detalles que no son relevantes en el nivel en el que se está trabajando.

15

Durante el diseño, el sistema es descompuesto entre un número de módulos y se indican las relaciones entre ellos. En otro diseño del mismo sistema, módulos distintos pueden mostrarse y existir diferentes relaciones entre ellos. Se podrían comparar los diseños considerando ambas topologías para los módulos individuales y el tipo de relaciones entre ellos. Esto nos conduce a dos criterios de diseño estructurales: cohesión y acoplamiento.

La cohesión puede ser vista como el pegamento que mantiene al módulo junto. Esta es una medida de la afinidad mutua de los componentes de un módulo. Se desea que la cohesión sea lo más fuerte posible.

El segundo criterio estructural es el acoplamiento. El acoplamiento es la medida de la fuerza de las conexiones intermódulos. Un alto grado de acoplamiento entre módulos indica una fuerte dependencia entre módulos. Un alto grado de acoplamiento entre módulos indica que se puede comprender totalmente este conjunto de módulos como un todo y puede resultar perjudicial cuando un módulo tiene que ser modificado, porque tal cambio implica incurrir en cambios en otros módulos afectados. Por otro lado, los módulos con bajo acoplamiento son relativamente independientes y son más fáciles de entender y adaptar. El bajo acoplamiento es entonces una característica deseable del diseño.

El principio de ocultamiento de datos indica que cada módulo tiene algún secreto que esconde a los otros módulos. Este secreto es manipulado solamente por el módulo responsable, y éste decide si puede o no permitir el acceso al secreto a otros módulos del sistema. Este se utiliza como un principio guía en el diseño.

La complejidad de un problema se refiere a la cantidad de recursos requeridos para la solución. En este sentido, la medida que se toma para esta característica es el tiempo necesario para resolver el problema, y no se observa a la entidad por sí misma (el problema), sino en como se comporta.

En este sentido, la complejidad se refiere a los atributos de software que afectan al esfuerzo necesario para construir o modificar una parte del software.

Podemos representar en un gráfico el resultado del proceso del diseño de un sistema de módulos y de sus dependencias mutuas. Podemos pensar en muchos tipos de relaciones entre módulos, por ejemplo:

• El módulo A contiene el módulo B • El módulo A sigue del módulo B • El módulo A entrega al módulo B • El módulo A depende del módulo B

El tipo de dependencias en los que estamos interesados son los que determinan la

complejidad de las relaciones entre los módulos. La cantidad de conocimiento que los módulos tienen de los otros debe ser mínimo. Es importante saber, para cada módulo, que otros módulos lo utilizan, especificando que partes (potencialmente) lo utilizan. En un diseño apropiado, la información entre los módulos se restringe solo a llamadas a procedimientos.

16

2.3 LENGUAJE DE MODELADO UNIFICADO El UML es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema de software OO. Se ha convertido en el estándar para el diseño de sistemas OO. El UML ha sido creado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y James Rumbaugh. Éstos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que pudieran basar la construcción de sus herramientas CASE, posteriormente crearon el Rational Unified Process (RUP), para establecer una metodología de diseño de sistemas basándose en el UML.

En el proceso de creación de UML han participado empresas como: Microsoft, Hewlett-Packard, Oracle e IBM, así como grupos de analistas y desarrolladores. El UML ha sido aceptado por el prestigio de sus creadores y por que incorpora las principales ventajas de cada uno de los métodos en los que se basa: Booch, OMT (Object Modeling Technique) y OOSE (Object Oriented Software Engineer).

El UML ha puesto fin a las llamadas “guerras de métodos” que se dieron en los años

90’s, en las que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás. El UML concentra las notaciones de cada técnica, logrando especificar una notación estándar, con la cual los ingenieros de software modelan sistemas OO.

Figura 2.2. Evolución de UML

Cuando se empezó a implementar UML, el objetivo principal era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notación y semántica común. En la Figura 2.2 se puede ver como ha sido la evolución de UML hasta la creación de UML 1.1.

Booch ‘91

Booch ‘93

OMT – 1

OOSE

Otros MétodosOMT – 2

Unified Method 0.8

UML 0.9 y 0.91 Junio del 96 y octubre del 97

UML 1.0

UML 1.1

Experiencia de las empresas participantes en UML

Revisión por parte del público

Enero del 97 Septiembre del 97

OOPSLA ´95

17

Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo específico, solamente se trata de una notación para la especificación del desarrollo de software. Los objetivos propuestos y alcanzados por y para el UML son:

• El método debe ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos.

• Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas. • Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables. • Manejar los problemas típicos de los sistemas complejos de misión crítica.

El logro del UML ha sido que los métodos sigan evolucionando en conjunto y no por separado, unificando las perspectivas entre diferentes tipos de sistemas (no sólo software, sino también de negocios), evidenciando las fases de: requerimientos, análisis, diseño, implementación y los conceptos del paradigma OO.

El UML es una técnica de modelado de objetos y por tanto supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

Un modelo es una abstracción de un sistema (en nuestro caso), que se elabora para comprender ese sistema antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del sistema y así facilita la comprensión.

La definición del UML se basa en los siguientes documentos:

• UML Semantics: Define la semántica y sintaxis del UML. Para ello utiliza tres visiones consistentes:

o Abstract syntax: Representa el meta-modelo del UML, sus conceptos (meta-clases), relaciones, y restricciones utilizando diagramas de clases.

o Well-formedness rules: Definen las reglas bien formadas que describen los modelos válidos. Las reglas se expresan en lenguaje natural junto con el Object Constraint Language (OCL). El OCL es un lenguaje de especificación que utiliza lógica para especificar propiedades invariantes de sistemas que se componen de conjuntos y relaciones entre conjuntos.

o Semantics: Describe la semántica para el manejo del modelo, se describe en lenguaje natural.

Estos documentos constituyen la definición del UML. Se han creado bajo la idea de que una definición más formal conllevaría expresiones matemáticas que poca gente podría entender de una forma directa.

18

UML está compuesto por los diagramas mostrados en la Tabla 2.1: [CRE03]

Tabla 2.1. Clasificación de los diagramas de UML

Área Vista Diagramas Conceptos Principales

Vista Estática Diagrama de Clases Clase, asociación,

generalización, dependencia, realización, interfaz.

Vista de Casos de Uso Diagramas de Casos de Uso

Caso de Uso, Actor, asociación, extensión, generalización.

Vista de Implementación

Diagramas de Componentes

Componente, interfaz, dependencia, realización.

Estructural

Vista de Despliegue Diagramas de Despliegue

Nodo, componente, dependencia, localización.

Vista de Estados de máquina Diagramas de Estados Estado, evento, transición,

acción.

Vista de actividad Diagramas de Actividad Estado, actividad, transición, determinación, división, unión.

Diagramas de Secuencia

Interacción, objeto, mensaje, activación.

Dinámica

Vista de interacción Diagramas de Colaboración

Colaboración, interacción, rol de colaboración, mensaje.

Gestión de Modelos

Vista de Gestión de modelo Diagramas de Clases Paquete, subsistema, modelo.

UML puede utilizarse a través de todo el proceso de desarrollo del software, que es aplicable a proyectos que requieran conceptos OO. La Figura 2.3 muestra como puede utilizarse UML en la especificación de requerimientos, diseño y codificación. [SHA02]

Figura 2.3. Diagramas para cada fase del diseño de sistemas OO.

Especificación de Requerimientos

Escenarios

UML: Diagramas de Actividad

UML: Diagramas de Estados

UML: Diagramas de Clase

UML: Diagramas de Objetos

UML: Diagramas de Paquetes

UML: Diagramas de Secuencia

UML: Diagramas de Componentes

UML: Diagramas de Colaboración

UML: Diagramas de Distribución

Requerimientos Diseño Codificación

UML: Descripción de casos de uso y diagramas

Modelos de objeto

Diagrama de flujo de tareas

Definición de Clases y

relaciones

19

2.3.1 Diagramas de Clases

Los diagramas de clases representan elementos del modelo que son estáticos, como las clases, la definición de cada clase y las relaciones que mantienen con otras clases.

Clases: Una clase es la representación de un conjunto de objetos que tienen una

estructura y un comportamiento común para cada objeto instanciado. Sirve como plantilla para instanciar objetos que comparte los mismos atributos, operaciones, relaciones y significado. En UML, una clase es la implementación de un tipo de estructura de datos.

La definición de una clase contiene los siguientes elementos:

Nombre: Es el identificador de la clase.

Atributo. Son las propiedades o características de cada clase o un tipo de estructura de datos. Se pueden tener de 1 a n atributos, donde cada atributo tiene su propio nombre.

Operación. También es llamado método, es una acción que implemente una clase

que puede ser utilizado por otras clases o por ella misma por algún mecanismo de acceso. Relación entre clases: Las clases se relacionan entre sí de distintas formas, y son:

• Asociación • Composición • Generalización • Dependencia

2.3.2 Diagramas de estados

El diagrama de estados representa el comportamiento de un objeto del sistema a través de su ciclo de vida. Se elabora un diagrama de estados para cada clase, a partir de un diagrama de clases, que contenga elementos suficientes que permitan el modelado de su comportamiento. El comportamiento se modela de acuerdo con los estados que puede tomar el objeto, los eventos que surgen estando en un estado determinado y que evento origina un cambio de estado y así sucesivamente

En un diagrama de estados una transición causada por un evento lleva a cabo un cambio de estado, es decir, que si un objeto se encuentra en un estado y se realiza un evento que pueda modificar el estado, entonces el objeto pasa al estado que se encuentra señalado por la punta de flecha de la transición.

Métodos de modelado como UML, representan la secuencia de estados que tiene un

objeto en su ciclo de vida a través de un diagrama de estados. Los diagramas de estados son una extensión de las máquinas de estado finito en las que las acciones de la salida pueden estar asociadas con transiciones y estados que pueden estar presentados de manera jerárquica. [VAN01]

20

Para toda clase que tenga un comportamiento dinámico relevante en el sistema, debe elaborarse el diagrama de estados que le corresponde, donde se muestren todos los estados que se pueden registrar en el sistema. Así, se debe poner especial atención en las clases que tengan un rol importante, donde el modelado con estados debe de ser explícito, omitiendo aquellas clases cuya representación no demuestre un aspecto dinámico relevante para el sistema, recomendándose no llevarse a cabo el diagrama de estados para estas clases.

Un estado se representa por un rectángulo de esquinas redondeadas con el nombre del estado, atributos y eventos. La Figura 2.4 muestra un ejemplo de estado.

Las transiciones son flechas que muestran la relación entre un estado origen y un estado destino, donde la etiqueta de la transición hace referencia al nombre del evento que da lugar a la transición, teniendo en cuenta siempre que los diagramas de estado obedecen a Autómatas Finitos Deterministas, por lo que todas las transiciones de salida de un estado deben de contener etiquetas mutuamente excluyentes.

Dentro de la notación de un diagrama de estados intervienen los dos tipos de elementos de la definición de una clase, atributos y métodos (el nombre de la clase como tercer elemento es el nombre del diagrama de estados modelado), en la Figura 2.4 sólo se muestran los eventos que debieron ser definidos en la clase modelada. Algunos de estos eventos son: display_help, handle_character, set_echo_normal y set_echo invisible.

FIGURA 2.4. Elementos de un estado

Los atributos y eventos que se utilizan para modelar un diagrama de estados pueden ser los mismos tanto para un estado como para un subestado. En este caso para el estado Start de la Figura 2.5, contiene métodos que pueden ser utilizados tanto en estados como en subestados.

Figura 2.5. Subestados y transiciones entre subestados etiquetados

Typing Password

Entry / set_echo_invisible Exit / set_echo_normal Character / handle_character Help / display_help

Start Entry / start_dial_tone Exit / stop_dial_tone

Partial dial Entry / nuumber.append(d)

digit(n)

digit(n)

[number.isValid()]

21

La manera de etiquetar una transición simple es la siguiente:

event-signature ‘[’ guard-condition ‘]’ ‘/’ action-expression

El event-signature describe un evento con sus argumentos de la manera siguiente:

event-name ‘(’ comma-separated-parameter-list ‘)’

guard-condition también se encuentra definido en términos de parámetros y

eventos, la action-expression puede ser escrita en términos de eventos, atributos y vínculos a objetos.

Para las transiciones que contienen restricciones de tiempo, se considera que estos espacios de tiempo son eventos. La descripción del lapso de tiempo se define dentro de un diagrama de secuencias.

Otros elementos de modelado de los diagramas de estados sólo utilizan los elementos que ya se han nombrado, a continuación sólo los nombramos para completar la definición que UML 1.5 proporciona.

o De y desde estados concurrentes o De y desde estados compuestos o Indicador de historial

o Rutas de transición factorizada o Submáquinas de estado o Estados sincronizados

2.4 PROGRAMACIÓN ORIENTADA A OBJETOS

Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas por el hombre, en los negocios y en los productos que usamos. Pueden ser clasificados, descritos, organizados, combinados, manipulados y creados. Por esto no es sorprendente que se proponga una visión orientada a objetos para la creación de software de computadora, una abstracción que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. [PRE01]

La POO es una filosofía de programación que se basa en la utilización de objetos. El objetivo de la POO es "proponer" una serie de normas de desarrollo que aseguren y faciliten el mantenimiento y reuso del software. La visión orientada a objetos demanda un enfoque evolutivo de la Ingeniería de Software. La programación orientada a objetos es una evolución del paradigma por procedimientos basado en funciones y nos permite agrupar módulos de código con funcionalidad común.

Los objetos se crean a partir de una serie de especificaciones o normas que definen como va a ser el objeto, esto es lo que en la POO se conoce como una clase.

Los mecanismos básicos de la POO son: clases, mensajes, métodos y objetos.

22

• Clases. Una clase es la definición de un tipo de objetos. De esta manera, una clase "Empleado" representaría todos los empleados de una empresa, mientras que un objeto de esa clase (también denominado instancia) representaría a uno de esos empleados en particular.

• Objetos. Un objeto es una instancia de clase, una entidad que tiene unos atributos particulares (datos) y unas formas de operar sobre ellos (los métodos o funciones miembro), es decir, un objeto incluye, por una parte una serie de operaciones que definen su comportamiento, y una serie de variables manipuladas por esas funciones que definen su estado. Por ejemplo, una ventana Windows contendrá operaciones como "maximizar" y variables como "ancho" y "alto" de la ventana.

• Mensajes. Un mensaje es la petición de ejecución de un método de una clase desde un método de una clase distinta. En C++, un mensaje se corresponde con el nombre de uno de las funciones o métodos de un objeto. Cuando se pasa un mensaje a un objeto, este responde ejecutando el código de la función asociada.

• Método. Un método (función miembro) se implementa dentro de un objeto y determina el comportamiento del objeto cuando se produce la llamada al método. En C++ un método se corresponde con la definición de la función miembro del objeto. La estructura interna de un objeto está oculta, de tal manera que la única conexión con el exterior es a través de los mensajes.

Las principales características de la POO son: abstracción, encapsulamiento, herencia

y polimorfismo.

• Abstracción. Es un mecanismo de diseño en la POO. Nos permite extraer de un conjunto de entidades datos y comportamientos comunes para almacenarlos en clases.

• Encapsulamiento. Mediante esta técnica conseguiremos que cada clase sea una caja negra, de tal manera que los objetos de esa clase se puedan manipular como unidades básicas. Los detalles de la implementación se encuentran dentro de la clase, mientras que desde el exterior, un objeto será simplemente una entidad que responde a una serie de mensajes públicos (también denominados interfaz de la clase).

• Herencia. Es el mecanismo que nos permite crear clases derivadas (especialización) a partir de clases bases (generalización). Es decir, podríamos tener la clase "Empleado" (clase base) y la clase "Vendedor" derivando de la anterior. Una biblioteca de clases (como la Microsoft Foundation Classes) no es más que un conjunto de definiciones de clases interconectadas por múltiples relaciones de herencia.

• Polimorfismo. Esta característica nos permite disponer de múltiples implementaciones de un mismo método de clase, dependiendo de la clase en la que se realice. Es decir, podemos acceder a una variedad de métodos distintos (con el mismo nombre) mediante el mismo mecanismo de acceso. En C++ el polimorfismo se consigue mediante la definición de clases derivadas, funciones virtuales y el uso de punteros a objetos.

23

Otros dos conceptos muy importantes en la POO son relativos a la creación y destrucción de objetos. En lenguajes procedurales convencionales cuando se define una variable se le reserva espacio en memoria y si no se inicializa expresamente, se hace por defecto (por ejemplo: en C++ una variable global siempre se inicializa a 0, pero una automática no, por lo que si no se inicializa expresamente su contenido inicial será basura); por otra parte, cuando se destruye una variable se libera la memoria que estaba ocupando.

Dentro del software OO, un objeto es cualquier cosa, real o abstracta, de la que se

almacenan datos y métodos que controlan dichos datos. Un objeto puede estar compuesto por otros objetos, y sucesivamente. Esta simbiosis estructural es la que permite construir objetos complejos.

El desarrollo de la POO surge durante la década de lo 80’s, tomando en cuenta la programación procedural, y toma como pilares para la POO a la herencia, el polimorfismo, la abstracción y el encapsulamiento. Figura 2.6.

Figura 2.6. Bases de la Programación Orientada a Objetos

La figura 2.7 muestra la secuencia que el compilador de sistemas OO aplica, y hace una comparación con respecto al compilador basado en el paradigma procedural. [MON04]

Figura 2.7. Secuencias de los compiladores para el paradigma procedural y el OO.

AbstracciónEncapsulamiento

HerenciaPolimorfismo

POO

PROGRAMA

Leer Programa

Construir la Tabla de Variables

Tabla de Símbolos

Análisis

Generar Código

Código Objeto Errores

Errores

Símbolos

Símbolos

PROGRAMA

Flujo de Mandatos

Gramática

Tabla de Símbolos

Árbol de Mandatos

Código Objeto Errores

Errores

Símbolos

Entrega Símbolo

Genera Código

Comprueba

Toma Símbolo

Procedural OO

24

2.5 PATRONES DE DISEÑO

Los patrones de diseño describen un problema que ocurre repetidas veces en algún contexto determinado, y proponen una solución comprobada. Esto permite diseñar correctamente en menos tiempo, y ayuda a construir programas, en el caso del software, reutilizables y extensibles. Asimismo, el uso de patrones de diseño facilita la documentación.

Muchas personas han observado que existen soluciones para problemas específicos que aparecen repetidamente en los buenos diseños. En cualquier oficio para resolver cierto problema, una buena solución se utiliza en distintas ocasiones. En lugar de crear un diseño completamente nuevo desde el principio, los diseñadores ahorran trabajo utilizando soluciones "comunes" en sus diseños. Estas soluciones estándar pueden no ser las mejores en todos los aspectos pero son muy aplicables, y surgen de diseños útiles que han sido comprobados por la experiencia. Estas "soluciones comunes" son llamadas patrones.

Los patrones de diseño no son exclusivos del software. Toda área laboral se basa en procesos bien definidos para la solución de problemas específicos, incluso el seguimiento de procedimientos de un manual es una forma de patrón.

Los programadores se enfrentan a la desventaja de aprender a diseñar, ya que no hay "bibliotecas de programas" donde se pueda estudiar la manera en que dichos programas han sido diseñados. Para la solución de este problema, el grupo de los cuatro [GAM95] ha creado un catálogo de patrones de diseño OO, donde muestran las soluciones más comunes a problemas con características similares.

En el caso de los patrones que se presentan en sistemas OO, se ha prestado atención en el diseño de cada patrón para permitir el reuso a nivel de clases. Se creó la estructura identificando el comportamiento común y las interacciones entre los elementos que componen al patrón.

El catálogo de patrones de diseño del grupo de los cuatro, tiene una manera muy particular de presentar los patrones de diseño, a continuación se muestra el patrón Composite con algunas partes de su definición, tal como se propone en [GAM95] antes mencionado.

2.5.1 Patrón de Diseño Composite: 2.5.1.1 Intención.

Compone objetos dentro de estructuras de árboles para representar jerarquías parte-todo. Composite permite al cliente ligar objetos individuales y composiciones de objetos uniformemente.

25

2.5.1.2 Estructura

Figura 2.8. Estructura de clases del Patrón de Diseño Composite 2.5.1.3 Participantes. Component.

o Declara la interfaz de los objetos en la composición. o Implementa comportamientos por definición para la interfaz en común para

todas las clases. o Declara una interfaz para acceder y dirigir sus componentes hijo. o Define una interfaz para acceder un componente que es padre en la

estructura recursiva, y se implementa si es necesario. Leaf

o Representa objetos hoja en la composición. Una hoja no tiene hijos. o Define el comportamiento para objetos primitivos en la composición.

Composite

o Define el comportamiento para componentes que tienen hijos. o Establece los componentes hijo. o Implementa la relación entre métodos hijos a través de la interfaz

Component. Client

o Manipula objetos en la composición a través de la interfaz Component.

Client

Component +Operation() +Add(in Component) +Remove(in Component) +GetChild(in index:int)

Leaf +Operation()

For each child in children child.Operation()

Composite +Operation() +Add(in Component) +Remove(in Component) +GetChild(in index:int)

26

2.5.1.4 Colaboraciones

Client utiliza la clase Component para interactuar con objetos en la estructura Composite. Si el recipiente es un Leaf, entonces la solicitud es manejada directamente. Si el recipiente es un Composite, entonces normalmente le siguen peticiones a sus componentes hijo, posiblemente mejorando métodos adicionales. 2.5.1.5 Patrones Relacionados

Frecuentemente el vínculo componente padre es utilizado para compartir la responsabilidad.

Decorator es utilizado frecuentemente con el Composite. Cuando Decorators y Composites son utilizados juntos, normalmente tienen una clase padre en común. Así los Decorators tienen que apoyar la interfaz Component con operaciones como Add, Remove y GetChild.

Flyweight permite compartir los componentes, pero puede hacer una referencia no muy lejana a sus padres.

Iterator puede ser utilizado para recorrer Composites.

Visitor localiza operaciones y comportamiento que podría, por otro lado, ser distribuido a través de clases Composite y Leaf. 2.5.1.6 Aplicaciones Un Composite puede aplicarse cuando se requiere utilizar, en una clase heredada, la funcionalidad de otras clases hija de la clase padre mutua. Permitiendo realizar estructuras de datos tipo Árbol, originada por la lógica de composición de la clase compuesta.

Cuando se desea trabajar con estructuras de datos anidadas, es conveniente utilizar este tipo de patrón, o simplemente cuando se necesita la funcionalidad de clases “hermanas”, se debe aplicar el patrón de diseño Composite, logrando con esto hacer uso de los métodos de clases “hermanas”. El siguiente fragmento ha sido tomado de [PRO04]:

¿Qué es lo que nos han proporcionado los patrones de diseño? Estos elementos nos han dado la posibilidad de organizar nuestras clases en estructuras comunes y bien probadas; modificando el sistema para mejorar su flexibilidad y extensibilidad. En otras palabras, incrementando la facilidad para adaptar el software a los cambios de especificación e incrementando su posible reutilización. De alguna forma, los mismos beneficios producidos por la programación orientada a objetos pero mejorando aún más la calidad del diseño, y por lo tanto el software en sí.

El principal objetivo de los patrones de diseño es capturar buenas prácticas que nos permitan mejorar la calidad del diseño de sistemas, determinando objetos que soporten

27

roles útiles en un contexto específico, encapsulando complejidad, y haciéndolo más flexible.

Podemos decir que los beneficios que un patrón produce pueden ser medidos en varios sentidos:

• Contribuyen a reutilizar el diseño, identificando aspectos clave de la estructura de un diseño que puede ser aplicado en una gran cantidad de situaciones. La importancia de la reutilización del diseño no es despreciable, ya que ésta nos provee de numerosas ventajas: reduce los esfuerzos de desarrollo y mantenimiento, mejora la seguridad, eficiencia y consistencia de nuestros diseños, y nos proporciona un considerable ahorro en la inversión.

• Mejoran (aumentan, elevan) la flexibilidad, modularidad y extensibilidad, factores internos e íntimamente relacionados con la calidad percibida por el usuario.

• Incrementan nuestro vocabulario de diseño, ayudándonos a diseñar desde un mayor nivel de abstracción.

Los patrones de diseño son una herramienta de gran valor para el desarrollo de software en general. Presentan soluciones estándares a problemas que se plantean en diferentes entornos. Sin embargo, su uso descuidado puede presentar una serie de problemas que pueden provocar el efecto contrario al prometido por estos artilugios: retrasos en el desarrollo de los proyectos, escasa reutilización, problemas en la mantenibilidad, etc.

Saber ajustarnos al dominio del problema tratado limitando nuestras capacidades "artísticas", mantener nuestros modelos lo más simples posibles, realizar desarrollos en equipo eludiendo patrones complejos e incomprensibles por gran parte de sus miembros, saber ajustarnos al modelo del dominio que estamos tratando y tener una formación continua ya sea a base de aprender nuevos patrones, de consultoría especializada o del estudio constante, son algunas de las medidas que pueden evitar los problemas asociados a los patrones de diseño.

En resumen: hemos de tratar de ser más ingenieros y menos ingeniosos.

2.6 LENGUAJES VISUALES (LV)

Desde el punto de Ingeniería de Software, la interfaz de usuario juega uno de los papeles principales en el desarrollo y puesta en marcha del sistema. La interfaz que el usuario tiene con el sistema es la carta de presentación del sistema, y debe de ser lo más accesible posible para que el usuario se sienta cómodo con su utilización.

Un término utilizado en el diseño de la interfaz es el de lenguaje visual, el cual atiende las características visuales (forma, tamaño, posición, orientación, color, textura, etc.) de un conjunto de elementos de diseño (puntos, líneas, planos, volumen, etc.) y la manera en que se relacionan unos con otros (balance, ritmo, estructura, proporción, etc.) en la solución de un problema de comunicación particular. Cualquier lenguaje define un universo de signos y un conjunto de reglas para usarlos. [CIN04]

28

Las metas de los lenguajes visuales son: • Resolver problemas de comunicación de manera efectiva tanto funcional como

estéticamente. • Reducir tiempos de asimilación, tiempos de respuesta, de diseño, entre otros. • Promover el uso de estándares. [CIN04]

Un LV es una estructura formal que consta de:

• Un conjunto de elementos gráficos, en este caso, primitivas de una interfaz tales como: botones, texto, zonas de dibujo, imágenes, etc.

• Un conjunto de reglas que nos guían en la combinación del conjunto anterior. • Una métrica para evaluar las construcciones dentro del LV. [CIN04]

Los LV se han extendido desde medios de comunicación en general hasta sistemas

de definición de tareas o sistemas de software. Algunos de los aspectos propuestos como guía en el diseño de interfaces gráficas de

usuario son: • Elegancia y simplicidad. • Escala, contraste y proporción. • Organización de estructura visual. • Modularización. • Representación de imágenes.

Desde el punto de vista computacional, un lenguaje visual es un lenguaje que manipula información visual de manera interactiva y/o permite programar con ayuda de expresiones visuales. Los lenguajes de programación visual pueden ser clasificados de acuerdo a la función y del grado de expresión visual utilizado, en:

• lenguajes basados en iconos, • lenguajes basados en formularios y • lenguajes basados en diagramas (con frecuencia grafos orientados).

Los entornos visuales proporcionan elementos gráficos o icónicos, que pueden ser manipulados por el usuario en función de una gramática espacial específica para construir un diagrama.

Un lenguaje visual también puede definirse como un conjunto de disposiciones espaciales de símbolos textuales o gráficos, con una interpretación semántica que se utiliza para efectuar acciones de comunicación con el mundo. [UCB04]

29

Un tipo de gramática que puede formalizar el lenguaje visual de los diagramas de estados, es una gramática visual del tipo relacional. De acuerdo a [SHU88], una gramática relacional pertenece a las gramáticas libres de contexto y se define por una 6-tupla G (N, ∑, S, R, Attr, P) donde: N:es un conjunto finito de símbolos no terminales. ∑:es un conjunto de símbolos terminales. S:es un símbolo distinguido en N llamado símbolo inicial. R:es un conjunto finito de símbolos de relación. Attr: es un conjunto finito de símbolos de atributos. P: es un conjunto de producciones. 2.7 REFERENCIAS [GAM95] Gamma Erich, Helm Richard, Vlissides John, Jonson Ralpg, Designed by Grady Booch.

Design Paterrns, Elements of Reusable Object Oriented Software. Addison Wesley Longman, Inc. 1995.

[PAR00] Parra, Isaac. Modelado Visual Orientado a Objetos. Tesis del Cenidet. 2000. [PRE01] Pressman Roger S. Ingeniería del Software, un enfoque práctico. Quinda Edicion. Mc Graw

Hill. 2001. [SHA02] Shari, Lawrence Pfleeger. Ingeniería de Software. Teoría y Práctica. Prentice Hall. 2002. [SHU88] Shu, Nan C.: Visual Programming, Van Nostrand Reinhold. 1988. [UML99] Booch, Grady / Rumbaugh, James / Jacobson, Ivar , El lenguaje unificado de modelado,

Addison Wesley.1999. [VAN01] Van Vliet , Hans. Software Engineering principles and practice. Second Edition. WILEY.

2001. [CRE03] www.creangel.com/uml/diagramas.php Noviembre 2003. [CIN04] Diseño de Interfaces Visuales.

www.cs.cinvestav.mx/CursoVis/IntroduccionVis.html. www.cs.cinvestav.mx/CursoVis/Parte16.html. www.cs.cinvestav.mx/CursoVis/Parte16a.html Mayo 2004.

[PRO04] Java en Castellano. www.programacion.com/java/articulo/corej2ee_patterns/. Mayo 2004. [MON04] www.monografias.com/trabajos14/progorie/progorie.shtml. Mayo 2004. [UCB04] www.ucbcba.edu.bo/carreras/ingsis/web/Visual/ProgVisuelle.html . Mayo 2004.

ANEXO A

KEDOS- FASE I

Especificación de requerimientos de software

Versión 1 (Las versiones se controlan de 0.1 a 1,

siendo un avance de .1 cuando se haga revisión y corrección)

Proyecto: Tesis de Maestria – Ke2. Versión: 1 Especificación de Requerimientos de Software. Fecha: Noviembre-2004RQ-ke2.doc

Página . RQ-Ke2

97

Historial de las revisiones.

Fecha Versión Descripción Autor Empresa

10/02/2004 0.1 Versión Inicial del análisis de Ke2 Alejandro Cenidet

20/02/2004 0.1 Revisión por parte del analista Alejandro Cenidet

22/03/2004 0.3 Revisión del Jefe de Proyecto. Máximo Cenidet

10/06/2004 0.4 Ajuste a los cambios Alejandro Cenidet

5/11/2004 1 Ajuste a los cambios Revisores de Tesis Cenidet


Página . RQ-Ke2

98

Índice. 1. Introducción. 99

1.1 Propósito. 99 1.2 Alcance. 99

2. Descripción general. 99 2.1 Escenarios 100 2.2 Panorama de los casos de uso. 100

2.2.1 Actores. 100 2.2.2 Casos de uso. 101

2.3 Suposiciones y dependencias. 106

3. Requerimientos específicos. 107 3.1 Funcionalidad. 107

3.1.1 Realizar el diagrama consistente con los diagramas de clases (CU-R010). 107 3.1.2 Deshabilitar self_transitions para los estados inicial y final. (CU-R020) 107 3.1.3 Operar los elementos del diagrama con cuadros de diálogo utilizando el mouse como acceso (CU-R030). 107 3.1.4 Deshabilitar el modelado con subestados (CU-R040) 107 3.1.5 Algunas restricciones (CU-R050) 108

3.2 Requerimientos suplementarios. 108 3.2.1 Facilidad de uso. 108 3.2.2 Estándares aplicables. 108

4. Información de soporte. 108 Deshabilitar self_transitions para los estados inicial y final. (CU-R020) 121 Deshabilitar el modelado con subestados (CU-R040) 122 Algunas restricciones (CU-R050) 122


Página . RQ-Ke2

99

Especificación de Requerimientos de Software.

1. Introducción.

1.1 Propósito. El propósito de este documento es definir los requerimientos del desarrollo del sistema de software registrados como versión 0.4 de la herramienta de Diagramas de Estados llamada Ke2, la cual forma parte de la suite Cenidet UML, de acuerdo con las especificaciones de la tesis “Ambiente Visual de modelado del estado de Objetos de una clase Utilizando los Diagramas de Estado propuestos por UML”.

1.2 Alcance. Esta especificación de requerimientos aplica para el proyecto denominado Ke2, el cual tiene por objetivo el establecer la consistencia entre diagramas de clases y diagramas de estados basándose en herramientas prototipo integradas en la Suite Cenidet UML, donde el modulo de diagramas de estado debe de ser implementado.

2. Descripción general.

El área de Ingeniería de Software de la maestría en Ciencias en Ciencias de la Computación del Centro Nacional de Investigación y Desarrollo Tecnológico (Cenidet) implementa la Suite Cenidet UML (SCUML) como un ambiente que permita solucionar problemas en tiempo de análisis y diseño de sistemas de información, haciendo una aportación, promoción, mejora y corrección a los vicios del diseño, así como la creación de herramientas que faciliten el análisis y diseño basándose en los diagramas que UML propone.

SCUML ha venido evolucionando desde la creación de herramientas que modelaban el comportamiento dinámico del sistema, madurando la intención y tomando a UML como base. Estos trabajos se han venido desarrollando desde el año de 1997 y madurando con UML en el año 2000.

Dentro de los diagramas que UML propone se encuentran los Diagramas de Estados, que son los que modelan el ciclo de vida de un objeto desde el punto de vista de su estado. El objetivo de este proyecto es el crear un ambiente basándose en una herramienta que permita crear diagramas de estados y que estos mantengan consistencia con los diagramas de clases que ya existen en SCUML.


Página . RQ-Ke2

100

2.1 Escenarios Un escenario, según Bruegge [BRU02] ”es una descripción concreta e informal de una sola caracterıstica del sistema desde el punto de vista de un solo actor” ; es decir, un escenario muestra la los pasos que se realizan cuando un actor interactúa con el sistema en una situación particular y en un tiempo determinado.

No es necesario documentar los escenarios de manera formal. Esta afirmación es en el sentido de que carece de gran importancia documentar todos los escenarios posibles del sistema, ya que los escenarios son utilizados para identificar los casos de uso del sistema.

Un escenario es un camino particular a través de la descripción abstracta y general dada por el caso de uso. Un caso de uso agrupa una familia de escenarios de uso según un criterio funcional. Los casos de uso se ven como clases cuyas instancias son los escenarios

Un escenario es un proceso particular como una serie de eventos y/o operaciones. Los escenarios ayudan determinar los objetos que componen al sistema. Son útiles en la captura de requisitos y pueden ser un tipo de casos de prueba, ayudando con esto a validar el sistema

Los escenarios que se registran para Ke2 se presentan a continuación y se da una descripción usando

diagramas de secuencias para cada uno de ellos en el ANEXO A.1, los nombres entre paréntesis son los nombres de los diagramas que los representan.

• Generar Diagrama de Estados (Ke2_Diagramas.mdl / Generar_DE) • Conectar notas con estados y transiciones (Ke2_Diagramas.mdl / Conectar_Notas)

• Generar un Elemento en el diagrama (Ke2_Diagramas.mdl / Generar_ElementoX)

• Realizar el diagrama consistente con los diagramas de clases (Ke2_Diagramas.mdl /

Diagramas_Consistentes)

• Modificar un estado (Ke2_Diagramas.mdl / modif._State)

• Etiquetar una transición con eventos y sus argumentos (Ke2_Diagramas.mdl / Etiquetar_Transición)

• Etiquetas múltiples (Ke2_Diagramas.mdl / Etiquetas_multiples)

• Contraer horizontalmente las regiones del estado (Ke2_Diagramas.mdl / contraer_regiones)

2.2 Panorama de los casos de uso.

2.2.1 Actores. Diseñador: El usuario de Ke2 es la persona física que realiza los diagramas de estados modelando el estado de un objeto. SOODA: Sistema que permite generar diagramas de clases y con el que Ke2 debe de mantener consistencia. Los diagramas de casos de uso se encuentran dentro del anexo A.2


Página . RQ-Ke2

101

2.2.2 Casos de uso.

Caso de uso: Modelar Diagrama de Estados Identificador: CU-C010 Actores: Diseñador Descripción: Este caso de uso representa lo más general en el sistema, modelar el diagrama de estados implica muchos casos de uso definidos en este documento, el usuario podrá generar directamente los diagramas de Estado consistentes con los Diagramas de Clases. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Genera el diagrama de estados 2 El diagrama es mostrado Id Nombre Acción E1 Consistencia Se genera solo si es consistente con la clase involucrada Caso de uso: Permitir Notas en el diagrama Identificador: CU-C020 Actores: Diseñador Descripción: El caso de uso hace referencia a las notas de las transiciones y los estados mismos. En ocasiones, el usuario desea poner notas aclaratorias en el diagrama que se refieran a la descripción de un estado o transición etc. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Creación de una nota 2 Se muestra la nota Caso de uso: Conectar notas con estados Identificador: CU-C030 Actores: Diseñador Descripción: Conecta o relaciona una nota con un estado. El usuario para saber que nota se refiere a que estado relaciona ambos elementos por medio de una línea discontinua; en la mayoría de los casos una nota se refiere a un elemento del diagrama y por ello es conveniente conectarlos. Una nota libre en el diagrama puede presentarse. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Creación de un estado del diagrama 2 Se muestra el estado 3 Creación de una nota 4 Se muestra la nota 5 Se relaciona la nota con el estado 6 Se muestra la relación Caso de uso: Conectar notas con transiciones


Página . RQ-Ke2

102

Identificador: CU-C040 Actores: Diseñador Descripción: Conecta o relaciona una transición con una nota. El usuario para saber qué nota se refiere a que transición, relaciona ambos elementos por medio de una línea discontinua. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Creación de una transición del

diagrama 2 Se muestra la transición

3 Creación de una nota 4 Se muestra la nota 4 Se relaciona la nota con una transición 6 Se muestra la relación Caso de uso: Diagramar con Estado Inicial Identificador: CU-C050 Actores: Diseñador Descripción: Se establece siempre un estado inicial en el diagrama, todo objeto tiene un ciclo de existencia, por lo tanto tiene siempre un inicio. Ke2 insertara automáticamente el estado inicial en el diagrama. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Crear un nuevo diagrama de estados 2 Generar automáticamente el

estado inicial

Caso de uso: Diagramar con Estado Final Identificador: CU-C060 Actores: Diseñador Descripción: Se establece siempre un estado final en el diagrama. Para modelar los estados de un objeto, un diagrama de estados debe de incluir un estado final que indique el final del modelado del objeto. Ke2 insertara automáticamente el estado final en el diagrama Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Crear un nuevo diagrama de estados 2 Generar automáticamente el

estado final


Página . RQ-Ke2

103

Caso de uso: Diagramar con estados Identificador: CU-C070 Actores: Diseñador Descripción: Todo diagrama de estados tiene al menos un elemento estado, así, el diagrama de estados debe contener de 1 a N estados necesarios. Ke2 insertara de entrada un estado, que estará conectado por medio de una transición simple con el estado inicial. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Crear un nuevo diagrama de estados 2 Generar automáticamente un

estado

3 Mostrar el estado 4 Generar más estados 5 Mostrar los nuevos estados Caso de uso: Permitir el entry/exit/do del compartimiento de actividades Identificador: CU-C080 Actores: Diseñador Descripción: Permitir elementos de actividad básicos del compartimiento de acciones del estado definidos por la semántica de UML. entry/exit/do llevan a cabo un evento a la entrada, salida o durante un estado. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Definir las actividades 2 Definir sus acciones 3 Mostrar actividades y acciones Caso de uso: Permitir otras acciones del compartimiento de actividades Identificador: CU-C090 Actores: Diseñador Descripción: Permitir acciones no establecidas por la semántica de UML. Pueden existir otras acciones dentro del compartimiento de actividades además de entry/exit/do, esto con el fin de dar robustez al sistema. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Definir las actividades 2 Definir sus acciones Mostrar actividades y acciones


Página . RQ-Ke2

104

Caso de uso: Diagramar con Transiciones Identificador: CU-C100 Actores: Diseñador Descripción: Permitir en el diagrama tener transiciones entre estados. Para indicar el cambio de un estado a otro se utilizan las transiciones entre los estados, estas transiciones están etiquetadas con elementos que hacen que se ejecute la transición de estado. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Generar el estado 2 Mostrar el estado 3 Generar otro estado 4 Mostrar el estado 5 Realizar la transición entre estados 6 Mostrar la transición Caso de uso: Permitir etiquetar la transición con eventos y sus argumentos Identificador: CU-C110 Actores: Diseñador Descripción: Permitir etiquetar la transición con elementos eventos y argumentos. Una transición en sus eventos, pueden presentar los argumentos que los componen, incluyendo el tipo de los argumentos y del evento mismo. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Crear la transición 2 Mostrar la transición 3 Hacer doble clic sobre la transición 3 Mostrar cuadro de diálogo 4 Actualizar la información de la

definición de la clase, en el cuadro de diálogo mostrado

3 Etiquetar con eventos y/o argumentos 4 Mostrar la etiqueta Caso de uso: Diagramar con Self_Transiciones Identificador: CU-C120 Actores: Diseñador Descripción: Permitir tener transiciones entre un mismo estado. Existen eventos dentro de un objeto que no modifican el estado de un objeto, estos se representan con una transición hacia el mismo objeto. El usuario puede tener las self_transiciones modeladas que necesite, el único inconveniente es el espacio en el área de modelado. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Generar el estado 2 Mostrar el estado 3 Generar la self_transition 3 Mostrar el self_transition


Página . RQ-Ke2

105

Caso de uso: Etiquetar las transiciones con Send Clause Identificador: CU-C130 Actores: Diseñador Descripción: Permitir etiquetar la transición con elementos Send Clause. Una de las etiquetas que una transición puede tener es el Send Clase que es utilizado cuando se necesita modelar la ejecución de un evento de un objeto (o varios) especifico. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Crear la transicion 2 Mostrar la transición 3 Etiquetar con Send Clause 4 Mostrar la etiqueta Caso de uso: Permitir a los Send_Clause ser múltiples Identificador: CU-C140 Actores: Diseñador Descripción: Este caso de uso permite tener más de un Send Clause en la etiqueta. Se debe indicar que varios eventos de objetos serán ejecutados delimitándolos con su separador respectivo. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Etiquetar con Send Clause 2 Mostrar la etiqueta 3 Anexar un Send Clause 4 Mostrar la etiqueta Caso de uso: Etiquetar las transiciones con Time Expressions Identificador: CU-C150 Actores: Diseñador Descripción: : Permitir etiquetar la transición con elementos Time Expressions. Las expresiones de tiempo son retardos en el sistema que se modela, para que se ejecute una acción o una serie de acciones después de cierto tiempo Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Crear la transición 2 Mostrar la transición 3 Etiquetar con time expression 4 Mostrar la etiqueta


Página . RQ-Ke2

106

Caso de uso: Etiquetar las transiciones con Guard_Condition Identificador: CU-C160 Actores: Diseñador Descripción: Permitir etiquetar la transición con elementos Guard_Condition. Una de las etiquetas que una transición puede tener es el elemento Guard_Condition que es utilizado cuando se necesita que se cumpla una o más condiciones para que las acciones de una transición se lleven a cabo. Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Crear la transición 2 Mostrar la transición 3 Etiquetar con guard conditions 4 Mostrar la etiqueta Caso de uso: Permitir a los Guard condition ser múltiples en la etiqueta de una transición Identificador: CU-C170 Actores: Diseñador Descripción: Este caso de uso permite tener mas de un guard condition en la etiqueta. Los guard condition son elementos condicionales que llevan a cabo acciones después de haber sida satisfecha cierta condición Flujo: ACTOR SISTEMA Paso Acción Paso Acción Excepción1 Etiquetar con Guard condition 2 Mostrar la etiqueta 3 Anexar un Guard condition 4 Mostrar la etiqueta

2.3 Suposiciones y dependencias. Las suposiciones y dependencias importantes para efectos de este documento de visión son las siguientes:

La existencia de un compilador (fases de él) que analice la definición de las clases que contiene el diagrama de clases.

La definición de las clases es tomada a partir de una estructura de datos dada por SOODA.

La consistencia que Ke2 implementa depende de haber generado previamente al diagrama de clases.


Página . RQ-Ke2

107

3. Requerimientos específicos.

3.1 Funcionalidad.

3.1.1 Realizar el diagrama consistente con los diagramas de clases (CU-R010).

La parte medular de Ke2 como un herramienta integrada a SCUML, es la consistencia que debe de mantener entre los diagramas de clases y los diagramas de estado, la consistencia debe existir para que exista coherencia de diseño entre los diferentes diagramas que UML presenta, en este caso se da para dos tipos de diagrama. La consistencia debe llevarse a cabo desde el inicio del modelado; para Ke2 la consistencia se da de manera unidireccional, es decir, se presenta para que a partir de la definición de las clases de un diagrama de clases pueda llevarse a cabo el modelado de un diagrama de estados, desde el punto de vista de las etiquetas de los elementos como son las transiciones y los estados mismos.

El implementar la consistencia debe de darse para una sola clase, ya que a una clase le corresponde un solo diagrama de estados, así, el usuario debe elegir la clase que se debe modelar, es el momento en que Ke2 como sistema forma su estructura de elementos con la cual se modelará el comportamiento de un objeto con diagrama de estados.

3.1.2 Deshabilitar self_transitions para los estados inicial y final. (CU-R020) Ke2 en sus elementos de estado inicial y estado final que todo diagrama de estados debe contener, no debe permitir que existan self_transitions para dichos estados. Esto se da, obedeciendo a la semántica de la versión 1.5 de los diagramas de estados de UML. El insertar una self_transition a un estado inicial o final no representa algo dentro del modelado, debido a que no son estados que puedan llegar a tener acciones por si mismos, ya que son “terminales”.

3.1.3 Operar los elementos del diagrama con cuadros de diálogo utilizando el mouse como acceso (CU-R030). Para poder etiquetar a los elementos que componen un diagrama de estados, se utilizarán los cuadros de diálogo como medios para insertar las etiquetas, se ingresará a los cuadros de diálogo de cada elemento del diagrama con un doble clic sobre el elemento, apareciendo entonces los cuadros de texto, listas desplegables o cualquier otro elemento que sea necesario para la descripción del elemento deseado.

3.1.4 Deshabilitar el modelado con subestados (CU-R040) Ke2 no proporcionará el trabajo con subestados, es decir, el diagrama de estados modelado solo contendrá la posibilidad de modelar en un solo plano, la intención de Ke2 como herramienta es establecer la consistencia entre diagramas, por lo que formas de modelado que define la semántica de UML y que son poco utilizadas, pasan a estar en un segundo plano.


Página . RQ-Ke2

108

3.1.5 Algunas restricciones (CU-R050) Debido al propósito de la creación de Ke2 y que se explica en el párrafo del punto 3.1.4, existen algunas restricciones dentro de Ke2 que se aplicarán, esto con el fin de enfocarse a solucionar solo uno de lo problemas que los diagramas de estados presentan. Las restricciones son:

o No se implementarán transiciones complejas o No se implementarán transiciones a estados jerarquizados o No se implementarán transiciones truncadas o No se implementarán indicadores de historia o No mensajes entre diagramas de estados u otro sistema

3.2 Requerimientos suplementarios.

3.2.1 Facilidad de uso.

3.2.1.1 Manejo cómodo de ventanas. El sistema deberá proporcionar un manejo cómodo de los formatos (pantallas) que sobre este aplique (nuevas pantallas), permitiendo que la presentación de las mismas no afecten a las pantallas actuales del SCUML.

3.2.2 Estándares aplicables. Los estándares aplicables son los siguientes:

La interfaz de usuarios deberá ser compatible con Windows bajo especificaciones de Visual C++ 6.0.

El sistema de modelado del estado de objetos debe de apegarse a la semántica que UML versión 1.5 estandariza.

Debido a que se trata de un modulo de la Suite Cenidet UML, el desarrollo se llevará a cabo en Visual C++ 6.0, ya que dicho sistema fue desarrollado en este lenguaje de programación, por lo que se deberá respetar los estándares para el desarrollo de aplicaciones en Lenguaje Visual C++.

4. Información de soporte. Ninguna.


Página . RQ-Ke2

109

ANEXO A.1 Diagramas de Secuencias de los Escenarios Generar Diagrama de Estados (Ke2_Diagramas.mdl / Generar_DE)

Usuario SCUML Ke2 Elementos de modelado de Ke2

Ke2 GUI Definic ion en SOODA

IngresaCarga los elementos

Ingresa

¿Que Clase de un DC se modelara?

Clase X

Pide la definic ion de las c lases del Diagrama de Clases X

Notifica la definic ion de las c lases

M anipu la los elementos

Se muestran los elementos

Indica la terminacion del diagrama

Cede el control


Página . RQ-Ke2

110

Conectar notas con estados y transiciones (Ke2_Diagramas.mdl / Conectar_Notas)

Usuario Ke2 Diagrama Ke2 GU I Notas

Ingresa

GeneraSe Muestra

Genera

Conectars e con una transicion X

Indica con quien se realizo la conexion

Actualiza el diagramaSe muestra

Conectarse con el Estado Y

Indica con quien se realizo la conexion

Actualiza el diagramaSe muestra


Página . RQ-Ke2

111

Generar un Elemento en el diagrama (Ke2_Diagramas.mdl / Generar_ElementoX)

Usuario SOODA Ke2 Barra de Herramientas

Diagrama

Ingres aCarga

IngresaGenera Estado Inic iay y Estado Final

Seleccion del E lem ent o X (Transic ion , Est ado, .. .)

En espera de la insercion del Elemento con un Click

Inserta el elemento en el Diagrama

Genera Estado Inicial y final


Página . RQ-Ke2

112

Realizar el diagrama consistente con los diagramas de clases (Ke2_Diagramas.mdl / Diagramas_Consistentes)

Usuario Sooda Ke2 Definic ion de Clases

Diagrama de Estados

Genera un diagrama de Clases

Genera estructura de Datos con la definic ion de Clases

Termina Sesion

Ingresa

Pide la definic ion de las c lases

Notifica la definic ion de clases

Pide la Clase de un diagrama de Clases a modelar

Clase X

Carga la definicion con la que s e modelará el Diagrama de Estados

Restringe a un m odelado consisten te basandose en la definic ion

G enera un Diagram a de Estados consist ente con un Diagrama de Clases

Termina Sesion


Página . RQ-Ke2

113

Modificar un estado (Ke2_Diagramas.mdl / modif._State)

Usuar io Ke2 Objeto Estado Cuadro de Dialogo del Estado

Ingresar

Inserta el estado en el diagrama

Doble c l ic k en el est ado insertado

Notifica el doble c lick

Abre el cuadro de dialogo

Modifica los campos necesarios en el cuadro de dialogo


Página . RQ-Ke2

114

Etiquetar una transición con eventos y sus argumentos (Ke2_Diagramas.mdl / Etiquetar_Transición)

Usua rio Ke2 Objeto Transic ion

Cuadro de Dialogo de la Transic ion

Ingresar

Inserta la transic ion en el diagrama

Doble c lick en la transic ion insertado


Modifica los campos necesarios en el cuadro de dialogo

Abre el cuadro de dia logo


Página . RQ-Ke2

115

Etiquetas múltiples (Ke2_Diagramas.mdl / Etiquetas_multiples)

Usuario Ke2 Objeto Transic ion

Cuadro de Dialogo de la Transic ion

Ing resar

Insert a la transic ion en el diagrama

Doble c li ck en la transic ion ins ertado


Abre el cuadro de dialogo

Insertar la primer et iqueta send clause, time clause . ..

Se act iva la opcion de mul tiples et iquetas

El usuario decide s i extender la etiqueta


Página . RQ-Ke2

116

Contraer horizontalmente las regiones del estado (Ke2_Diagramas.mdl / contraer_regiones

Usuario Ke2 Objeto Estado

Ingresar

Inserta el estado en el diagrama

Un click en el s imbolo de contraer del Estado

Notifica el c lick

Contrae las regiones

Un click en el s imbolo de "expandir"

No ti fi ca el cl ick

Expande las regiones


Página . RQ-Ke2

117

ANEXO A.2 Diagramas de Casos de Uso. Diagrama Inicial

Genera estructura de Datos de la definic ion de clases

SOODA

Diseñador

Basarse en UML 1 .5

Realizar el diagrama consistente con los diagramas de clases

<<include>>

M odelar diagrama de Estados

<<include>>

<<include>>

Participantes: Generar un diagrama de estados (CU-C010).


Página . RQ-Ke2

118

Diagramar con Estados

Permitir el entry/exit/do del com partimiento de actividades

Diagramar con estados

<<extend>>

P ermi ti r otras acciones de l com partimient o de actividades

<<extend>>

Participantes: Diagramar con estados (CU-C070) Permitir el entry/exit/do del compartimiento de actividades (CU-C080). Permitir otras acciones del compartimiento de actividades (CU-C090). Modelar visualmente (Requerimientos)

Operar los elementos del diagrama con cuadros de dialogo

Operar los elementos con cuadros de dialogo desde el mouse

Modelar visualmente

<<include>>

<<include>>

Participantes: Operar los elementos del diagrama con cuadros de diálogo utilizando el mouse como acceso (CU-R030).


Página . RQ-Ke2

119

Diagramar con transiciones

Et iqueta r las transiciones con Time Expressions

Et iquetar las transiciones c on eventos y argumentos

Diagramar con Transic iones

<<ex tend>>

<<extend>>

Et iquetar las transiciones c on Send clause

<<extend>>

Permitir a los Send_Clause ser múltiples

<<extend>>

Et iqueta r las transiciones con Guard Condition

<<extend>>

Permiti r a los Guard condition ser múltiples

<<extend>>

Participantes: Diagramar con Transiciones (CU-C100). Permitir etiquetar la transición con eventos y sus argumentos (CU-C110). Etiquetar las transiciones con Send clause (CU-C130). Permitir a los Send_Clause ser múltiples (CU-C140). Etiquetar las transiciones con Time Expressions (CU-C150). Etiquetar las transiciones con Guard Condition (CU-C160). Permitir a los Guard condition ser múltiples en la etiqueta de una transición (CU-C170).


Página . RQ-Ke2

120

Modelar Diagramas de Estados

Permitir Notas en el diagramaDiagramar con Estado Inic ial

Diagramar con Estado Final

Diagramar con estados

Diagramar con Transic iones

Diagramar con Self_Transic iones

Modelar visualmente

Aplicar c iertas restricciones

Modelar diagrama de Estados

<<extend>><<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Participantes: Generar un diagrama de estados (CU-C010) Permitir Notas en el diagrama (CU-C020). Diagramar con Estado Inicial (CU-C050). Diagramar con Estado Final (CU-C060). Diagramar con estados (CU-C070). Diagramar con Transiciones (CU-C100). Diagramar con Self_Transiciones (CU-C120).


Página . RQ-Ke2

121

Notas en Diagramas

Conectar notas con estados

Permitir Notas en el diagrama

<<extend>>

Conect ar notas con transic iones

<<extend>>

Participantes: Permitir Notas en el diagrama (CU-C020). Conectar notas con estados (CU-C030). Conectar notas con transiciones (CU-C040). Self_Transition

Desabititar self_transitions para los estados inic ial y final

Diagramar con Self_Transiciones

<<include>>

Participantes: Diagramar con Self_Transiciones (CU-C120).

Deshabilitar self_transitions para los estados inicial y final. (CU-R020)

Deshabilitar self_transitions para los estados inicial y final


Página . RQ-Ke2

122

Restricciones

Modelar en un solo Documento

No mensajes ent re diag ramas de estados u otro s istema

No habrán transic iones c omplejasDeshabilitar el modelado con s ubestados

Mode lar en un plano

No transic iones a estados jerarquizados

No transic iones truncadasAplicar c iertas restricc iones

<<include>>

<<include>><<include>><<include>>

<<include>>

<<include>>

Participantes:

Deshabilitar el modelado con subestados (CU-R040)

Algunas restricciones (CU-R050)

Algunos escenarios y algunos casos de uso relacionados a ese escenario, no han sido tomados como requerimientos para el desarrollo de Ke2, la razón de no haberlos implementado es por el tiempo que se invertía en el desarrollo del ambiente. Ke2 solo ha sido realizado como un prototipo académico. Los escenarios no implementados son:

• Conectar notas con estados y transiciones • Etiquetas múltiples • Contraer horizontalmente las regiones del estado

Por consiguiente sus casos de uso relacionados, tampoco han sido realizados.


Página . RQ-Ke2

123

Referencias [UML04] http://www.omg.org/cgi-bin/doc?formal/03-03-01 JUNIO DEL 2004 [BRU02] Bruegge B., Allen, S., Ingenierıa de Software Orientado a Objetos, Addison-Wesley, USA, 2002. [GAM95] Gamma, E., Design Patterns: elements of reusable object-oriented software, Addison-Wesley, USA, 1995. [OMG99] Object Management Group, OMG Unified Modeling Language, http://www.uml.org, USA, 1999 [BIT00] Bittner, K., Why Use Cases Are Not Functions, http://www.therationaledge.com, USA, 2000.


DDeessaarrrroolllloo

“Why is it I get my best ideas while shaving?”

- ALBERT EINSTEIN

3.1 Requerimientos del ambiente de Ke2 3.2 Modelo conceptual del sistema 3.3 Consistencia 3.4 Gramática de los Diagramas de Estados 3.5 Referencias

31

3.1 REQUERIMIENTOS DEL AMBIENTE DE Ke2 Algunos requerimientos del ambiente son:

o Permitir la creación de un diagrama de estados con sus elementos.

o Realizar el diagrama de estados consistente con una clase del diagrama de clases.

o Deshabilitar self_transitions para los estados inicial y final.

o Operar los elementos del diagrama con cuadros de diálogo utilizando el mouse como acceso.

o No habilitar el modelado con subestados

Los requerimientos del ambiente se han documentado en el ANEXO A de la presente tesis. 3.2 MODELO CONCEPTUAL DEL SISTEMA 3.2.1 Introducción

Si bien el sistema resultante es importante, es fundamental el diseño del mismo. Los diagramas ofrecen la posibilidad de visualizar el contexto general y particular de los módulos de un sistema. Uno de los aspectos más relevantes del diseño de un sistema es la consistencia entre los elementos de los diagramas que lo modelan.

Para llegar a aplicar un diseño se requiere de la existencia de una estrategia sustentada por métodos formales adecuados al sistema. En este caso, UML por medio de Diagramas de Clases y Diagramas de Estado permite modelar parte del aspecto estático y dinámico de un sistema orientado a objetos.

La consistencia entre los Diagramas de Estado y Diagramas de Clase mejora el diseño, logrando una correcta interpretación del modelo del sistema en etapas posteriores como lo es la implementación. La interpretación de los diagramas cuando no son consistentes entre sí, pueden ocasionar problemas de interpretación si sus elementos en común no se encuentran definidos en un diagrama y en otro sí, mientras que un diseño consistente permite interpretar correctamente los elementos que ambos diagramas comparten. El diseño que tiene consistencia entre diagramas no implica que los diagramas se vayan a interpretar de manera correcta, pero sí implica que la corrección del problema de la inconsistencia ayude a mejorar el diseño del sistema. Recordemos que estos diagramas se pasan entre grupos de trabajo, por lo que deben de ser lo más explícitos y coherentes posibles.

Las herramientas de modelado de sistemas comerciales no han tomado en cuenta esta importante característica del modelado, sin duda es un problema grave al momento del desarrollo de los sistemas de software, hecho que debe ser corregido para evitar errores en tiempo de diseño con consecuencias en otras etapas del desarrollo. Debe existir una diferencia entre una herramienta de modelado y un simple sistema de graficación.

32

3.2.2 Arquitectura de Solución Propuesta (mapa conceptual) La manera como Ke2 resuelve el problema de la consistencia se muestra en las

siguientes figuras. La figura 3.1 muestra al diseñador en la forma de generar los diagramas con SCUML. En una manera general para la creación de diagramas consistentes, el diseñador debe elaborar los diagramas de clases y luego generar los diagramas de estados para las clases del diagrama de clases. La Figura 3.1 muestra un panorama general de creación de diagramas de UML, particularizando en los diagramas de clases y estados.

Figura 3.1. Creación de diagramas de UML

El manejo de la consistencia que Ke2 propone entre ambos diagramas se muestra en la Figura 3.2, donde se representa la creación de un diagrama de estados para una clase de un diagrama de clases. En primer lugar, el usuario genera un diagrama de clases por medio del ambiente de SOODA y se genera una estructura de datos que contiene la definición de cada una de las clases que intervienen en el diagrama de clases. Como segundo paso, el usuario se dispone a generar el diagrama de estados con Ke2. Ke2 verifica la definición del diagrama de clases para tener conocimiento de los elementos con los que puede modelar el usuario.

Figura 3.2. Creación de diagramas de estados y clases consistentes

Ke2 al tener toda la definición de la clase bajo su control, permite mostrar los elementos de esa definición para la realización de diagramas de estados por medio de sus cuadros de diálogo, los cuales permiten etiquetar a los elementos gráficos que lo componen. Esta es la forma lógica de creación de los diagramas de estados consistentes con los diagramas de clases.

Diseñador

KE2 Diagramas de Estados

Diagrama de Clases (SOODA)

GeneraGenera

Consistente Otros Diagramas

Conjunto de Diagramas de UML

Genera el Diagrama de Clases Genera el Diagrama de Estados

Estructura de Datos

Diseñador

33

3.2.3 Diagrama de Clases del Ambiente de Ke2

La creación de Ke2 se ha realizado a partir del diagrama de clases del ambiente de los diagramas de clases de SCUML. Es decir, se ha aplicado la reutilización de sus clases y se ha originado un nuevo ambiente para la generación de diagramas de estados. La arquitectura de los diagramas de clases se puede estudiar en el capítulo 3 de [HER03], donde se muestra el diagrama de clases de InverSOODA, los aspectos orientados a objetos como lo es el diseño de aplicaciones con la MFC (Microsoft Foundation Classes) y la arquitectura Documento-Vista, además del uso de los patrones de diseño Composite, Iterator y Visitor.

El diagrama de clases del que se reutilizaron clases se muestra en la Figura 3.3. Naturalmente existieron modificaciones al diagrama de clases reutilizado, lo cual se define a continuación.

CCommand

CIterator<CGrafico>

CDiagrama

CGrafico

CLinea

CClaseB1 CHerenciaB1 CAsociacionB1CAgregacionB1 CDependenciaB1 CVisitor

CSooLButtonDown CSoodaLButtonDblClk

CRectangulo

CSoodaLButtonUp

CSoodaDiagramaBuilderCGenerador

CVista CDocumento

CVisitorLDblClk CVisitorSelectivo CVisitorSelectivoNombre CVisitorSelectivoNumNodoCVisitorApuntador

CGrafico CListIterator

Parser

CInverSoodaDiagramaBuilder

CDiagramaBuilder

CSoodaDiagrama

Figura 3.3. Diagrama de clases de InverSOODA

34

La región marcada es sobre la que se seleccionaron las clases para ser reutilizadas en Ke2. Sin embargo, InverSOODA se trasladó a un ambiente integrado junto con los diagramas de secuencias; al hacer el traslado del ambiente de los diagramas de clases, el conjunto de clases que genera a los diagramas de clases fue reestructurado. En la Figura 3.4 se muestra la arquitectura de clases para la generación de diagramas de clases en el ambiente integrado de SCUML, omitiendo la ingeniería inversa que InverSOODA implementa, el conjunto de clases de la figura 3.4 muestra la arquitectura de SOODA, como el ambiente que modela con diagramas de clases.

Figura 3.4. Diagrama de clases de SOODA en el ambiente integrado de la SCUML.

CIterator<CGrafico>

CDiagramaDC

CGrafico

CAgregacionDC

CLineAttributesDC

CAsociacionDC

CLineOperationsDC

CVista CDocumento

CLDblClkDC CConexantDC CSelectorDCCApuntadorDC

CGrafico

CListIterator

CDiagramaDC

CVisitorDC

CAsocAdjusterDC

CDependenciaDC CHerenciaDC

CClaseDC

35

En el diagrama de clases de la Figura 3.4 observamos un error de diseño en el diagrama, para indicar el error analicemos el fragmento de clases tomado de la Figura 3.4 mostrado en la Figura 3.5.

En la Figura 3.5 se observa que las clases CagregacionDC, CasociacionDC,

CdependenciaDC y CherenciaDC tienen una triple herencia desde Cgrafico, ClineAttributesDC y ClineOperationsDC, aunque realmente ClineOperationsDC no tiene métodos que heredar a las clases de relaciones mencionadas. Naturalmente, desde el punto de vista de diseño es incorrecto, ya que CLineAttributesDC y CLineOperationsDC son clases aisladas en la arquitectura y solo contienen atributos y métodos respectivamente, concentrar dichos atributos y métodos en CGrafico puede eliminar a las clases CLineAttributesDC y CLineOperationsDC.

Un error que se presentó al reutilizar la arquitectura de la figura 3.4 se observo

cuando CClaseDC se utilizó como base para crear las figuras estado. En los diagramas de estados se tiene el estado inicial, el estado final y el estado común, lo cual ha sido un problema para redefinir los elementos heredados a partir de CGrafico, es decir, CClaseDC tiene muchas propiedades como clase que son similares al estado inicial, al estado final y al estado común, por lo cual es conveniente reutilizar esa clase para los tres elementos del diagrama de estados, naturalmente, a cada estado le correspondería la reutilización de CClaseDC, así que se implementó la estructura del patrón de diseño Strategy, pero no su intención, para redefinir el diseño y así generar las tres clases que son necesarias para los tres tipos de estados, lo cual se muestra en la Figura 3.6, esto permitió también eliminar la triple herencia, ya que los atributos comunes fueron agrupados en la clase padre del patrón Strategy. Lo mismo sucedió con los elementos de las relaciones, ya que heredaban directamente de CGrafico, también se les aplicó el patrón de diseño Strategy para que las clases CTransicionDE y CSelfTransicionDE de los diagramas de estados pudieran ser manejadas de la misma manera.

CGrafico

CAgregacionDC

CLineAttributesDC

CAsociacionDC

CLineOperationsDC

CDependenciaDC CHerenciaDC

CClaseDC

Figura 3.5. Fragmento del diagrama de clases de la Figura 3.2.4

36

La Figura 3.6 muestra la reestructuración de las clases que se ha aplicado para el ambiente de Ke2.

La definición completa del patrón de diseño Strategy se puede consultar en

[GAM95]. El apartado 3.2.4 explica brevemente el patrón de diseño Strategy por medio de mapas mentales. 3.2.4 Justificación del Uso del Patrón de Diseño Strategy

La palabra estrategia (Strategy) significa el arte para dirigir un asunto y coordinarlo. Éste patrón de diseño permite establecer una organización lógica de las clases desde el punto de vista de la arquitectura para poder tener un correcto orden en la visibilidad. Así se organiza y da sentido al conjunto de procesos. 3.2.4.1 Descripción del Contexto del Mapa Mental

Cuando una persona se encuentra con un malestar de salud acude al médico general para detectar el problema, cuando el problema se resuelve con una especialidad, el médico general se lo indica al paciente. Es entonces cuando el paciente debe acudir al especialista correspondiente.

CIterator<CGrafico>

CDiagramaDE

CGrafico

CRelaciones EstrategiaDE

CEstadoDE

CSelfTransicoinDE

CEstadoFinalDE

CTransicionDE

CEstadoInicialDE

CEstadosEstrategiaDE

CVista CDocumento

CLDblClkDE CConexantDE CSelectorDECApuntadorDE

CGrafico CListIterator

CDiagramaDE

CVisitorDE

CAsocAdjusterDE

Figura 3.6. Diagrama de clases de Ke2

37

3.2.4.2 Problema que se Presenta y se Soluciona en el Mapa Mental

En el mapa mental se muestra el médico general que es visitado por el paciente para que sea solucionado su problema de salud.

La Figura 3.7 muestra el mapa mental del patrón de diseño Strategy.

Figura 3.7. Mapa mental del patrón de diseño Strategy

3.2.4.3 Participantes del Mapa Mental

Médico General: Es el encargado de decidir con que especialidad se puede resolver el problema de salud del paciente.

Especialidad: Es el método con el que se resuelve el problema de salud del paciente. 3.2.4.4 Descripción del Mapa Mental en Etapas de la Secuencia de Interpretación

El cliente consulta al Médico General y según el problema del paciente se envía al

especialista correspondiente. Cada especialista puede atender el problema que el paciente presenta. Si el paciente tiene problemas de gripa puede mandarse con el especialista en homeopatía o alopatía o a un tratamiento de aromaterapia.

3.2.4.5 Relación del Mapa Mental con Respecto al Patrón de Diseño Strategy

El medico general es invocado por el cliente para que le solucione el problema. Dentro de términos orientados a objetos, el cliente invoca a un proceso de una clase concreta (especialidad) por medio de una clase abstracta (médico general), la clase abstracta direcciona la petición del cliente al proceso invocado de la clase concreta. 3.2.4.6 Motivación del Uso, Aplicabilidad y Consecuencias del Patrón de Diseño Strategy

La motivación de uso del patrón de diseño Strategy se apoya en la anterior explicación acerca del mapa mental.

Lo que se pretendió y se logró con el uso del patrón, es hacer más reutilizable el

conjunto de clases para la creación de ambientes visuales de modelado, ya que con la

Médico General

El Paciente Acude al Médico

Aromaterapia Homeópata Alópata

38

arquitectura del ambiente integrado de SOODA sólo se tenía un único tipo de objetos con las mismas características (CClaseDC), y su extensibilidad no era la más conveniente; la nueva arquitectura permite tener una mayor reutilización y extensibilidad de la función de la arquitectura.

El principal motivo de esta reestructuración ha sido que en trabajos futuros se pueda tomar la estructura de clases de los diagramas de estados para crear nuevos ambientes como los diagramas de actividad, los diagramas de objetos, etc. Sin la reestructuración hubiera sido más complicada la realización de éstos ambientes. La arquitectura de los diagramas de estados se puede extender con elementos como los rombos condicionales, los rectángulos con esquinas redondeadas de procesos, los óvalos de inicio y fin y los diferentes elementos de los diagramas de actividad.

La aplicabilidad del patrón Strategy se ha dado para resolver el problema de la extensibilidad de la arquitectura, el direccionamiento de los diferentes estados de los diagramas de estados, así como de las relaciones entre los estados. Las consecuencias de la aplicación del patrón de diseño Strategy son:

• La posibilidad de extender la arquitectura para generar más elementos visuales del diagrama.

• Mejorar la reutilización de la arquitectura.

• Mejorar el mantenimiento.

• Realizar el direccionamiento de los objetos creados a partir de las clases

concretas del patrón de diseño Strategy de manera dinámica.

• Eliminación de la triple herencia, conjuntando las características en la clase padre del patrón de diseño Strategy.

3.2.5 Aplicación del determinismo en los diagramas de estados

Un Autómata Finito Determinista (AFD) es un método alterno para verificar la correcta formación de cadenas. En nuestro caso, el determinismo permite elaborar oraciones visuales con una correcta representación. En una explicación simple del determinismo, se puede decir que “de un estado no pueden salir dos ni más transiciones etiquetadas de la misma manera” para evitar ambigüedad en la interpretación del diagrama de estados. De tal manera que es conveniente aplicar el determinismo dentro del ambiente visual que ésta tesis presenta, sin embargo por razones de tiempo esta característica no ha sido implementada.

En algún momento existió la controversia de aplicar o no el determinismo en la presente tesis, en la discusión se concluyó que podría aplicarse en el ambiente de Ke2, ya que se pretende comercializarlo y aplicarlo directamente al modelado de sistemas de software.

39

Se ha observado que el determinismo no es aplicado en la mayoría de las herramientas que modelan basándose en UML, decimos mayoría porque no se puede llegar a afirmar que ninguna lo ha hecho, evidenciando así una falla más de la formalización de los diagramas que UML propone, específicamente en los diagramas de estados. Pudiendo ser éste un aporte más para facilitar el modelado de sistemas y hacerlo más confiable. Al tema del determinismo le puede corresponder una explicación muy amplia, sin embargo la explicación no corresponde al objetivo de la presente tesis, si el lector desea ahondar en el tema, sólo tendría que investigar la teoría de los Autómatas Finitos Deterministas para ampliar su conocimiento. En la tesis se trata al determinismo como una característica que heredan los diagramas de estados de los Autómatas Finitos Deterministas, por lo que el determinismo es una propiedad de los diagramas de estados.

En un AFD, el determinismo también se da en el sentido de que todos los elementos del alfabeto deben salir por medio de transiciones de cada uno de los estados, y los elementos que no cumplan con el lenguaje dado, salen del estado hacia un estado de error. Naturalmente que aplicar dicha característica del determinismo en los diagramas de estado que propone UML, haría que los diagramas generados fueran más difíciles de interpretar por su poca comprensión visual, ya que se crearían muchos estados de error. 3.2.6 MDI (Interfaz de Múltiples Documentos)

La SCUML integrada ha sido desarrollada a partir de la lógica multi-documentos de

la MFC, donde se tiene un tipo de documento para cada tipo de diagrama, como lo son los diagramas de clases, los diagramas de secuencias y los diagramas de estados. A continuación se describe la Interfaz de Multi-Documentos de la MFC.

Para administrar el complejo proceso de crear documentos, sus vistas y ventanas de marco asociadas, el marco de trabajo utiliza dos clases de plantilla de documento: CSingleDocTemplate para aplicaciones SDI (Interfaz de documento único) y CMultiDocTemplate para aplicaciones MDI (Interfaz de Múltiples Documentos). Un objeto CSingleDocTemplate puede crear y almacenar un documento de un solo tipo. Un objeto CMultiDocTemplate mantiene una lista de muchos documentos abiertos de uno o varios tipos.

Algunas aplicaciones admiten múltiples tipos de documentos. Por ejemplo, una aplicación puede admitir documentos de texto y documentos gráficos. En tal aplicación, cuando el usuario elige el comando Nuevo en el menú Archivo, un cuadro de diálogo muestra una lista de tipos posibles de nuevos documentos. Para cada uno de los tipos de documentos posibles, la aplicación utiliza un objeto distinto de plantilla de documento.

La Figura 3.8 muestra la configuración de una aplicación MDI que admite dos tipos

de documento y presenta varios documentos abiertos.

40

Figura 3.8. Una aplicación MDI con dos tipos de documento

El objeto de aplicación crea y mantiene las plantillas de documento. Una de las

tareas clave realizadas durante la función InitInstance de la aplicación, es crear una o varias plantillas de documento del tipo adecuado. El objeto de aplicación almacena un puntero a cada plantilla de documento en su lista de plantillas y proporciona una interfaz para agregar plantillas de documento.

Si se necesita la compatibilidad con dos o más tipos de documento, deberá agregar una llamada adicional a AddDocTemplate por cada tipo de documento.

Se registra un icono por cada plantilla de documento a partir de su posición en la lista de plantillas de documento de la aplicación. El orden de las plantillas de documento lo determina el orden en que se agregan mediante llamadas a AddDocTemplate [MSD04].

Una aplicación SDI tiene, desde el punto de vista del usuario, sólo una ventana. Si la aplicación depende de <<documentos>> de archivo en disco, sólo se puede cargar un documento a la vez. El Bloc de Notas MDI tiene múltiples ventanas hijas, cada una de las cuales corresponde a un documento individual. Microsoft Word es un buen ejemplo de una aplicación MDI [KRU99].

Objeto de Aplicación

Plantilla de documento A Plantilla de documento B

Doc1 Doc2 Doc3 Doc1

CMyDocA CMyDocB

CMultiDocTemplate CMultiDocTemplate

Abrir Documentos

Instancias de una clase Instancias de una clase diferente

41

3.2.7 Función de los diagramas de estados

Se han mencionado los diagramas de estados y los diagramas de clases, pero antes de continuar, debe de tenerse muy clara la funcionalidad de los diagramas de estados. ¿Para qué me sirve un diagrama de estados?, ¿Qué representa en el modelado de un sistema?, ¿Qué sucede si no realizo un diagrama de estados?.

Se pueden encontrar muchas definiciones de lo que es un diagrama de estados, sin embargo, se hablaría nuevamente de que muestra una secuencia de estados o que los estados se representan de una manera y se relacionan por medio de transiciones que se activan por medio de eventos, los cuales contienen un estado final y uno inicial, etc. Sin embargo, en palabras no tan técnicas se puede decir lo siguiente. Así como en un AFD existe un único camino que reconoce cada palabra u oración perteneciente al lenguaje que reconoce un AFD y dicho camino va del estado inicial a un estado final, también en los diagramas de estados existe un único camino que reconoce las acciones que un objeto puede llevar a cabo y que van desde un comienzo (estado inicial) hasta un final (estado final). Lo anterior muestra la verdadera intención de los diagramas de estados, servir como guía para entender como debe operar el sistema desde un punto de vista dinámico, reconociendo “un lenguaje” de acciones que pueden llevarse a cabo en el sistema.

Ha existido un punto de discusión de si se deben modelar primero los diagramas de estados y después los diagramas de clases, o viceversa; en primer lugar, no existe dentro de la definición del UML un orden en la elaboración de los diagramas, naturalmente hay cierta lógica en el orden de los diagramas, ya que sería incorrecto si se realizan los diagramas de clases y después los diagramas de casos de uso, o crear un diagrama de objetos sin haber realizado el diagrama de clases.

Al final cada diseñador adopta el proceso de modelado para la creación de

diagramas que más le convenga o ajuste mejor a su manera de trabajo, en el caso de los diagramas de clases y los diagramas de estados es conveniente que la creación de dichos diagramas se haga de manera que primero se realicen los diagramas de clases y posteriormente los diagramas de estados, ya que el diagrama de estados representa el comportamiento de un objeto de una clase desde el punto de vista de su estado. Modelar los estados de un objeto de una clase sin tener la definición correcta de la clase, sería como decir que un bebé cuando nazca va a tener los ojos azules y llorará fuertemente al nacer sin antes conocerlo, no se puede afirmar un hecho cuando no se tiene la certeza de lo que va a suceder. Modelar un diagrama de estados antes que el diagrama de clases es viable como un “acercamiento” o suposición de cómo se van a comportar los objetos, y es como realizar dicha suposición, pero al final se debe adecuar la suposición a la realidad, los mismo sucede con los diagramas de estados y los diagramas de clases, ya que el diagrama de estados tendrá que ajustarse a la definición de la clase.

42

3.3 CONSISTENCIA “Por un signo, se han caído puentes”, alguna vez se escuchó la frase anterior de la boca de un profesor de matemáticas al cuestionarle su alumno: “¿Por qué estoy mal?, ¡sólo me equivoqué por un signo!”. Lo anterior es un ejemplo de la importancia del diseño. 3.3.1 Describiendo la Consistencia

Entre los problemas que se presentan en el manejo de las relaciones entre los diagramas hay uno de gran importancia y éste es, la consistencia.

Cuando se tiene consistencia entre los diagramas del UML, se puede decir que el diseño del sistema de software modelado es mas completo, considerándose desde el punto de vista de la coherencia, ya que se cubre en cada diagrama los cambios realizados en uno u otro diagrama y que al momento de ser interpretados por los desarrolladores y/o programadores no existan dudas en la información establecida dentro de los diagramas. La consistencia entre diagramas puede ser considerada fácil de identificar en modelos pequeños. Cuando los sistemas son complejos, es muy probable que detalles de la relación entre diagramas (como la consistencia) lleguen a pasarse por alto. Utilizar el modelado de sistemas con todos los cambios que su desarrollo implica, es de gran importancia tanto en el desarrollo del sistema como en la finalización del mismo, debido a que cuando realizamos el mantenimiento del sistema resulta más confiable y sencillo.

Uno de los errores de modelado de sistemas es que se toma como correcta la primera versión de un diseño o parte del diseño del sistema, sin establecer un proceso de revisión en el cual se apruebe un diseño en particular. Otro problema es dedicar poco tiempo al análisis y diseño, ya que aquí es donde se forma el problema de la inconsistencia entre los diagramas, haciendo que a la postre los problemas se conviertan en procesos costosos y tardados.

La consistencia normalmente hace referencia a secuencias de acciones, términos,

unidades comunes dentro de un mismo programa de aplicación o un mismo escenario, y se refiere inherentemente a un concepto relacional. Modelar consistentemente entre diagramas permite tener un mejor diseño del sistema, atendiendo así la necesidad de mantener una coherencia entre la especificación de los elementos de cada diagrama.

Existen conceptos básicos de creación de diagramas que están relacionados por los

elementos que los componen, uno de ellos es la consistencia. No debe permitirse la creación de diagramas independientes en los cuales no se considere la consistencia, hacerlo acarrea la posibilidad de crear diagramas aislados que no respeten sus elementos en común, es decir, que representen una parte del sistema sin tomar en cuenta la relación que guardan con otros diagramas.

La falta de consistencia de información puede ocasionar un costo de desarrollo mayor al momento de la implementación del sistema, dando como consecuencia una baja fiabilidad del proceso de desarrollo de software.

43

Los cambios del diagrama de clases que pueden repercutir en el diagrama de estados son: el borrado de una clase, el borrado de un método, el borrado de un atributo, el cambio de nombre de la clase, el cambio de nombre de un atributo y el cambio de nombre de un método. Los cambios repercuten directamente en las etiquetas de los elementos del diagrama de estados, y los elementos son las transiciones y los estados. Particularmente a las etiquetas de las transiciones se les aplica la consistencia en los elementos de “guard condition” por los atributos de la clase y el “Send Event” para los métodos de la clase; mientras que para los estados la consistencia se aplica en la condición por los atributos de la clase, y en el método de “On Event” y Nombre del “Send Event” para los métodos de la clase.

En nuestro caso de estudio no se debe permitir que se elaboren diagramas independientes en los cuales no se aplique la consistencia. Rational Rose no ha tomado en cuenta esta forma de modelado, sin duda es un problema grave al momento del desarrollo de los sistemas de software, que debe de ser corregido para evitar errores en tiempo de diseño y que acarreen el problema a otras etapas del desarrollo.

El Modelado de sistemas inconsistentes generan problemas de interpretación e

implementación, por tanto, los costos se incrementan y la calidad del producto puede disminuir, contrario al objetivo esencial de la Ingeniería de software.

Es importante crear prototipos que propongan la solución para el problema de la

consistencia basándose en métodos formales.

Si bien toda herramienta debe cumplir con más validaciones y más aún cuando se trata de un ambiente de modelado de sistemas, en el momento en el que no se cumpla con dichas validaciones, debe ser indicado para que el usuario tenga cuidado al momento de modelar los sistemas, recordemos que los diagramas se pasan entre grupos de trabajo, por lo que deben de ser lo más explícitos y coherentes posibles.

Toda herramienta que se relacione con el modelado de sistemas debe tratar en la mayor medida de lo posible alejarse de ser un simple sistema de modelado graficador como lo es Visio, con el fin de no caer en errores de modelado que a la postre repercutan en gastos económicos que pudieron ser evitados.

¿Que es la consistencia? Se dice que dos diagramas son consistentes cuando los elementos que los definen tienen una relación coherente entre sí. La consistencia propuesta en la tesis es entonces, la manera de hacer que los diagramas de clases y los diagramas de estados sean definidos a partir de los mismos elementos en común, como son la clase, los atributos y los métodos.

3.3.2 ¿Cómo se Trata la Consistencia?

Si en el diagrama de clases original se borra alguna clase, un diagrama de estados para una instancia de clase borrada ya creado no representará ninguna instancia de clase dentro del modelo. Este es un problema común, se crean diagramas independientes y éstos pueden representar contextos diferentes de aplicaciones distintas, claramente se observa que se pueden hacer diagramas sin consistencia.

44

La presente tesis aplica la consistencia unidireccional de diagrama de clases a

diagrama de estados, donde cualquier cambio que se de en los diagramas de clases y que repercuta en el diagrama de estados, debe verse reflejado en la definición de los elementos del diagrama de estados. Los cambios que se pueden ver reflejados se muestran en la Figura 3.9.

Figura 3.9 Acciones sobre las que se implementa la consistencia.

La consistencia por los cambios que se den a partir del diagrama de estados y que se pueden ver reflejados en la herramienta de los diagramas de clases, solamente es: la existencia o ausencia del diagrama de estados que represente a cada una de las clases del diagrama de clases. La definición de una clase en el diagrama de clases no se verá afectada por los cambios que se puedan dar en el diagrama de estados, ya que el diagrama de estados, el cuerpo de sus estados y sus transiciones, se generará a partir de una estructura de datos que contendrá la definición de cada una de las clases y que es generada por el mismo diagrama de clases, así, una transición que utilice un método o atributo debe ser verificada para ver si existe ese método o atributo en la clase representada por el diagrama de estados al que pertenece la transición, si ese método o atributo no está definido en la clase, no puede ser incluido en el diagrama de estados.

La Figura 3.10 muestra un diagrama de flujo en el cual se muestra como el ambiente trata el borrado de una clase para mantener la consistencia.

Borrado

Cambio de Nombre

Clase MétodoAtributo

Clase MétodoAtributo

Desde el diagrama de Clases

45

Figura 3.10. Proceso del borrado de una clase.

En el borrado de una clase el ambiente sólo refleja la existencia o ausencia de una clase, y procura mantener la consistencia sugiriendo la selección de alguna otra clase para asociarla con el diagrama de estados que pudo quedar aislado. Si no se logra asociar el diagrama de estados con alguna clase, entonces el diagrama queda aislado del modelado del sistema.

Inicio

El usuario borra la clase

La estructura de datos se actualiza

Indicar que el diagrama de estados no tiene clase asociada

Mostrar las clases que pueden ser asociadas al diagrama de estados

Fin Se asocian los diagramas

Se aísla el diagrama de estados

¿Existe el diagrama de

estados para la clase?

1

¿Se escoge alguna clase para asociar

al diagrama de estados?

1

SI

NO

NO

SI

46

La Figura 3.11 muestra un diagrama de flujo en el cual se muestra como el ambiente trata el cambio de nombre de una clase para mantener la consistencia.

Figura 3.11. Cambio de nombre de una clase

El cambio de nombre de una clase sugiere un nuevo nombre al diseñador para la clase modificada y así mantener la consistencia; en caso de que la sugerencia no sea aceptada por el diseñador, entonces el ambiente muestra la lista de clases con las que podría asociar el diagrama de estados.

Si no se asocia ninguna clase al diagrama de estados entonces el diagrama de

estados se aísla, a partir de ese momento el ambiente no tiene control sobre la consistencia entre los diagramas.

El usuario modifica el nombre de la clase

Inicio


Se aísla el diagrama de estados

Fin

¿Se escoge alguna clase?

1

1

NO

SI



NO

SI

Se sugiere el cambio de nombre de la clase

¿Se acepta la sugerencia

del cambio?

Se muestra la lista de clases posibles a asociar

NO

SI Se asocian los diagramas

SI

47

La Figura 3.12 muestra un diagrama de flujo en el cual se muestra como el ambiente

trata el borrado de un atributo o de un método para mantener la consistencia.

Figura 3.12. Borrado de un atributo/método

El diagrama de flujo de la Figura 3.12 también se aplica al cambio de nombre de un atributo/método, ya que para ambos casos el proceso para mantener la consistencia es el mismo.

El usuario borra el atributo/método

Inicio


Se indica la inconsistencia

Fin

¿Se escoge algún atributo /

método?

1

SI

NO



NO

SI

¿Se utilizó? Se muestra la lista de atributos / métodos posibles a remplazar

NO

SI

Se sugiere el cambio de nombre del atributo/método

¿Se acepta la sugerencia

del cambio?

NO

SI

Se hace un análisis de algún atributo/método similar

¿Se encuentra algún atributo / método similar? NO

SI

Se analiza si el atributo/método se utilizó en el diagrama de estados

1

48

Cuando se realiza el borrado de un atributo o de un método, el ambiente analiza si el elemento eliminado ha sido utilizado en el diagrama de estados, si no ha sido utilizado no existe problema de inconsistencia, en caso de que si haya sido utilizado para la definición de algún elemento del diagrama de estados, entonces el sistema busca algún elemento similar por el cual reemplazar al eliminado, si lo encuentra lo sugiere, si se acepta la sugerencia al cambio se mantiene la consistencia, si no se acepta la sugerencia, el ambiente muestra la lista de los atributos/métodos disponibles por remplazar, si se utiliza algún método/atributo se mantiene la consistencia, en caso contrario el modelado se vuelve inconsistente.

Existen algoritmos desarrollados en los cuales se determina si ha existido algún cambio desde el diagrama de clases y que afecte a la definición del diagrama de estados. Para determinar si la clase ha sido borrada se hace un recorrido de la estructura de datos de la definición del diagrama de clases, haciendo una comparación de la clase de la cual se realiza el diagrama de estados con cada clase de la estructura de datos mencionada.

Cuando se hace el cambio de nombre de una clase el ambiente logra sugerir a la

clase que se le cambió el nombre una comparación simple: en el diagrama de estados se tiene toda la definición de la clase modificada, así se puede comparar con cada una de las clases del diagrama de clases y determinar sobre que clase se ha hecho el cambio. Existe una excepción, y es en el caso de que se le cambie el nombre a una clase que no contiene métodos, ya que la comparación se da por los métodos similares, y si no existen métodos no se tendría punto de comparación.

En el caso de los atributos y los métodos cuando son eliminados o se les cambia el

nombre, el ambiente hace una búsqueda dentro de la definición de la clase de la manera siguiente: si se ha cambiado de nombre a un atributo se hace una comparación uno a uno de los métodos o atributos de la definición de la clase para encontrar uno similar y sugerir el cambio, si se ha identificado que el método o atributo ha sido borrado, es porque no se encuentra algún método similar y debe de actualizarse el diagrama de estados para mantener la consistencia.

La forma de sugerir el cambio de algún método/ atributo es mediante el análisis textual del elemento, y se toman las siguientes consideraciones para identificar el cambio de nombre de un método / atributo:

• Las primeras dos letras y las últimas dos letras sean iguales • Comparar la palabra completa excepto la última letra • Que se haya agregado algún guión bajo • Que se haya quitado algún guión bajo • Que el 50% del inicio de los elementos sea similar

Las anteriores son las consideraciones para determinar si un atributo o método

eliminado o modificado de nombre puede ser remplazado por algún otro atributo o método similar existente en al clase.

49

3.3.3 Aplicando la consistencia en otras áreas de diseño.

El concepto de consistencia no sólo es aplicable al modelado de sistemas de software, sino también es aplicable a cualquier área que modele en base a diagramas que representen el mismo contexto y que se realicen a partir de las mismas primitivas, como es el caso de la arquitectura. En la Figura 3.13 se muestran dos figuras de la cocina de una casa habitación, la Figura 3.13.a se refiere al plano común de una casa, mientras que la Figura 3.13.b se refiere a la parte eléctrica de la misma casa. ¿Dónde se encuentra la inconsistencia?, dentro de la Figura 3.13.a en la parte de la cocina se observa que una pared ha sido eliminada, mientras que en la 3.13.b el diagrama indica que esa pared sí existe, el anterior es un claro problema de inconsistencia, ya que en un diagrama se define la pared mientras que el otro no, sin embargo, no termina aquí, en la Figura 3.13.b sobre la pared se indica que debe de ponerse un apagador en la pared.

Desde el punto de vista de la construcción, el primer plano es el que se sigue para

construir la casa, imaginemos que ya se encuentra la casa construida y que es tiempo de realizar la instalación eléctrica, ahora el problema es que el apagador tiene que ponerse en una pared que no existe, naturalmente el electricista se dirigirá con el arquitecto para mostrarle el error que es donde surge la inconsistencia, tiene que hacerse nuevamente el diseño de la posición en la que debe ir el apagador, lo que trae como consecuencia una pérdida de tiempo.

(a) (b) Figura 3.13. Planos de una casa.

Otras áreas como la electrónica, la geografía, la ingeniería civil, etc., son casos en

los que a partir de los diagramas que emplean, puede aplicarse el concepto de consistencia como se muestra en la presente tesis, sólo que las primitivas sobre las cuales se aplica la consistencia son distintas para cada caso de uso. 3.3.4 Impactos de la Consistencia

El impacto social se evidencia desde el punto de vista laboral, la empresa entrega sus proyectos lo más apegado posible al tiempo en que fueron planeados, los trabajadores disminuyen sus esfuerzos al emplear menor tiempo en las correcciones y naturalmente se evitan costos a la empresa al evitar más tiempo y esfuerzo.

50

El impacto tecnológico que la aplicación de la consistencia conlleva, es que se

propone una nueva manera de realizar el diseño de sistemas en general, donde el error de la inconsistencia es corregido y se mantiene actualizado para mantener un diseño confiable.

El impacto educativo se visualiza desde el punto de vista del aprendizaje del modelado de sistemas de software utilizando el UML, donde los estudiantes pueden ver la relación directa que existe entre los diagramas de clase y los diagramas de estado, diseñando así de manera correcta y evitando el error de la inconsistencia.

Tres de los principales beneficios de tener un ambiente de modelado de sistemas que aplique la consistencia, son: el costo, el tiempo y el esfuerzo; ya que la aportación principal de ésta tesis puede evitar estos tres factores en el desarrollo del sistema, lo que contrae una mejor manera de desarrollo. 3.3.5 Ejemplo de Consistencia entre un Diagrama de Clases y Diagrama de Estados

El siguiente es un ejemplo de un diagrama de estados que es consistente con la clase

que representa, siendo un objetivo específico de la presente tesis, mantener la consistencia entre ambos diagramas. El contexto se da para un auto que es automático y los estados por los que éste pasa cuando es manejado. “Cuando manejo mi automóvil naturalmente lo primero que hago es subirme en él, tomo mi llave y arranco el auto, piso el freno, pongo la velocidad normalmente en Drive y el auto comienza a avanzar. En cada esquina debo de frenar mi auto hasta hacer alto total para observar si no viene algún auto en el cruce de la avenida, lo anterior es para evitar accidentes, una vez que observé que no vienen autos, presiono el acelerador, tomo el volante y sigo avanzando. Cuando voy en una pendiente cuesta abajo, comúnmente pongo neutral para ahorrar un poco de gasolina, así avanzo y a la vez ahorro, claro que si el auto no se encuentra en movimiento y en una carretera sin pendiente, si la palanca de velocidades esta en neutral no avanzo. Cuando me voy a estacionar debo frenar totalmente mi auto, para poder colocar la velocidad en parking y así poder apagar el auto con toda seguridad. Hay ocasiones en las que he encendido mi carro pero olvido hacer algunas cosas en la casa, por lo que apago el motor para poder terminar lo que tenía pendiente”.

Dado el contexto anterior se presentan los estados por los que pasó el automóvil desde el punto de vista de movimiento. El diagrama de estados que le corresponde se muestra en la Figura 3.14

51

Figura 3.14. Diagrama de estados de un Automóvil Automático

La definición de la clase del diagrama de estados de la Figura 3.14 se muestra en la

Figura 3.15. Entre las dos figuras se puede observar la consistencia implementada, ya que en primer lugar todos los eventos y atributos tienen el mismo nombre en ambos diagramas, en segundo los elementos que participan en el diagrama de estados se encuentran definidos correctamente en la clase. La tercera forma correcta de consistencia es que el diagrama de estados representa los estados de una clase y se encuentran dentro del mismo contexto.

Cabe destacar que no necesariamente todos los

elementos de la definición de la clase deben participar en un diagrama de estados, sólo participan aquellos que influyen directamente en el cambio de estado o en su permanencia. En el ejemplo se han utilizado todos los elementos, ya que todos han intervenido en el comportamiento del Auto.

Auto Encendido

Activar_Switch

Auto Avanzando

Auto Detenido

Activar_Velocidad[ Freno_Mano_Puesto=0 AND Freno_Pie_Presionado=0 ]

Pisar_freno[ velocidad!=0 ]

P isar_Acelerador

Activar_Neutral[ velocidad!=0 ]

Poner_ParkingDesactivar_Switch

Pisa r_A celerador[ V elocidad_Activada ]

Desactivar_Switch

Pisar_freno[ velocidad=0 ]

Activar_Neutral[ velocidad=0 ]

Auto_Autom atico

Veloc idadFreno_Mano_PuestoFreno_Pi e_Pres ionadoVel oc idad_Activada

Activar_Switch()Desactivar_Switch()Activar_Veloc idad()A c ti var_Neut ral ()P i sar_Freno()P isar_Acelerador()Poner_Park ing()

Figura 3.15. Clase Automóvil Automatico

52

3.4 GRAMÁTICA DE LOS DIAGRAMAS DE ESTADOS 3.4.1 El UML y su Formalización

Los documentos publicados [ALC04] acerca de UML definen una semántica, pero no existen definiciones formales para la construcción de los diagramas. La falta de formalización de los diagramas de UML puede provocar problemas de inconsistencia entre los modelos, creación de oraciones visuales incorrectas, mala interpretación de la semántica de UML, etc. Existe una gramática textual que define el OCL (Object Constraint Language) en UML [ALC03], éste es exclusivamente un lenguaje de expresiones que se utiliza para definir reglas bien formadas en la especificación de: clases y tipos en los modelos de clases, estereotipos, precondiciones y poscondiciones en operaciones y métodos, y restricciones en operaciones. [CON03] El uso de los lenguajes visuales dentro de la Ingeniería de Software se ha incrementado, ya que son más expresivos para representar modelos de software, como lo propone UML. En el trabajo de esta tesis se presenta una formalización para los Diagramas de Estados utilizando una gramática visual.

UML fue creado para la industria del software como una notación de modelado que integra varias metodologías enfocadas al paradigma de sistemas OO, pero su falta de formalidad, ha hecho que muchos investigadores se den a la tarea de estudiar y presentar propuestas para evitar las inconsistencias y ambigüedades en los modelos, así como otros problemas. Algunos trabajos relacionados con ésta formalización de UML son: los basados en especificaciones algebraicas, donde se logra probar o desmentir matemáticamente [FER00] la validez del diagrama que se ha construido; el modelo matemático “pi-calculus” [DUM02] es usado para la verificación de consistencia entre dos tipos de diagramas de UML; también, se hace uso de sistemas de verificación como lo es PVS (Prototype Verification System) [[ARE02], [TSI01]], éste es grande y complejo, el cual consiste de un lenguaje integrado de especificación con herramientas de soporte (analizador, probador, librerías de especificación y herramientas de navegación); Lenguajes de Alto Nivel para descripción y especificación [VER01] como el SDL (Specification and Description Language) que es un lenguaje gráfico utilizado en la descripción de sistemas de comunicación complejos, conducidos por eventos y de tiempo real, y transformaciones a modelos de comportamiento[UCH01], en donde el objetivo primordial es facilitar el modelado de comportamientos en conjunto con los escenarios; Lenguajes de Acción [ALC01] como: el Action Specification Language (ASL), BridgePoint Action Language (AL), Kabira Actions Semantic (Kabira AS); todos ellos orientados a técnicas de modelado de objetos y, también a formalismos basados en reglas de transformación a grafos [HEC01].

Aún con todo lo anterior, no ha sido suficiente para expresar el modelado de sistemas en UML para dominios requeridos, por eso es que cada día se le hacen extensiones para lograr interpretar lo que los modeladores quieren manifestar en sus desarrollos [CON03].

53

Desarrollado dentro de la IBM Insurace Division para definir un lenguaje de modelado de negocio, el OCL es un lenguaje formal diseñado para ser fácil de leer y de escribir. El OCL es más funcional que el lenguaje natural pero no tan preciso como un lenguaje de programación. No puede ser usado para escribir lógicas de programación o control de flujo, ya que OCL es un lenguaje para la expresión pura. El OCL no puede ser utilizado para definir restricciones del modelo visualmente. El OCL nos ayuda a describir el contexto y a establecer las restricciones del contexto en el que se trabaja. Aunque OCL define tipos de datos (Lógico, Real, Entero y Cadena de caracteres), operaciones (relacionales, algebraicas, lógicas y matemáticas), OCL solamente es un lenguaje de navegación no es un lenguaje de programación [ALC03]. 3.4.2 Describiendo los diagramas de estados

El diagrama de estados representa el comportamiento de un objeto del sistema a

través de su ciclo de vida. Se elabora un diagrama de estados para cada clase, de un diagrama de clases que contenga elementos suficientes que permitan el modelado de su comportamiento, si no tiene atributos que representen un cambio en el estado del objeto de la clase, no es conveniente realizarlo para esa clase. El comportamiento se modela de acuerdo a los estados que puede tomar el objeto, los eventos que surgen estando en un estado determinado, que evento origina un cambio de estado y así sucesivamente.

Los elementos de los diagramas de estados pueden clasificarse de la siguiente forma:

1. Los elementos básicos que permiten el modelado de un sistema a partir de los diagramas de estados del UML son: el estado, estado final y el estado inicial. 2. Los elementos de extensión como son el estado histórico, el estado de concurrencia y el estado de sincronización, además de los estados compuestos que tienen su propia formalización definida por la semántica de UML. 3. Las relaciones que se establecen en un diagrama de secuencias pueden ser: una transición, éste es un elemento que une un estado desde el inicio de la flecha con otro elemento en la punta de la flecha; otra relación es la auto transición que es una flecha que une un mismo elemento desde el inicio de la flecha hasta la punta de la flecha, es decir se dirige hacia sí mismo. Ambas relaciones se etiquetan con los mismos elementos definidos en la semántica de OMG UML 1.5 4. Los comentarios se representan visualmente con un cuadro con el borde doblado, dentro de él se indica una nota textual. Los comentarios se pueden colocar en cualquier parte del diagrama y pueden ser libres o ligados mediante una línea punteada a un elemento descrito.

54

3.4.3 La gramática Visual Relacional

La gramática que se propone es una gramática visual del tipo relacional según se especifica en [SHU88]. Una gramática relacional pertenece a las gramáticas libres de contexto. Es una 6-tupla G (N, ∑, S, R, Attr, P) donde:

N: es un conjunto finito de símbolos no terminales. ∑: es un conjunto finito de símbolos terminales. S: es un símbolo distinguido en N llamado símbolo inicial. R: es un conjunto finito de símbolos de relación. Attr: es un conjunto finito de símbolos de atributos. P: es un conjunto de producciones.

Para entender los símbolos visuales de la gramática, se menciona el nombre de cada uno:

Estado Inicial. Estado Estado Final

Estado de Concurrencia Estado Histórico

Estado de sincronización

También se definen las relaciones de transición:

Transición: Es una flecha que une a un elemento desde el inicio de la flecha, con otro elemento en la punta de la flecha. Transición_Self: Es una flecha que une a un mismo elemento (un mismo estado) desde el inicio de la flecha hasta la punta de la flecha. Es decir, se dirige hacia si mismo.

Los atributos son entrada y salida, donde ambos entrada y salida se encuentran en el contorno del elemento.

H

*

55

3.4.4 Gramática Visual de los Diagramas de Estados. G ( N, S, T, R, Attr, P) N = { Diagrama, Conjunto_de_Estados } S = { Diagrama } T = { , , , , , , } R = { Transición, Transición_Self } Attr = { Entrada, Salida}

Los atributos se encuentran en el contorno de cada elemento visual, como se muestra en los siguientes símbolos: P = {

(Transición, Salida 1, Entrada 2 )




Diagrama Conjunto_de_Estados

H *

Salida

H *

Diagrama


Diagrama Conjunto_de_Estados H

Desde Estado Inicial

Entrada , Salida

Entrada , Salida

Entrada , Salida

Entrada

Entrada , Salida

56





(Transición_Self, Salida 1, Entrada 1 )

Conjunto_de_Estados Conjunto_de_Estados

Conjunto_de_Estados


Conjunto_de_Estados Conjunto_de_Estados H

Desde Estado


57







Conjunto_de_Estados




H

*

Desde Estado de Concurrencia

58





(Transición, Salida 1, Entrada 2 ) }

Figura 3.16. Gramática de los diagramas de estados


Conjunto_de_Estados




H

*

Desde Estado Histórico

H

H H

H

Desde Estado de Sincronización

59

3.4.5 Gramática Relacional Acotada para los Diagramas de Estados Manejados por Ke2

La Suite Cenidet-UML limita los símbolos para la creación de diagramas de estados que propone UML. Esta acotación se reduce a tres elementos básicos para la creación de los diagramas de estados, que son: el estado inicial, el estado final y el estado.

Para entender los símbolos visuales de la gramática, se menciona el nombre de cada uno: Estado Inicial. Estado Estado Final

También definimos las relaciones de transición:

Transición: Es una flecha que une a un elemento desde el inicio de la flecha con otro elemento en la punta de la flecha. Transición_Self: Es una flecha que une a un mismo elemento (un mismo estado) desde el inicio de la flecha hasta la punta de la flecha. Es decir, se dirige hacia si mismo.

Los atributos son entrada y salida, donde ambos entrada y salida se encuentra en el

contorno del elemento. La gramática acotada que describe a los diagramas de estado para Ke2 es:

G ( N, S, T, R, Attr, P) N = { Diagrama, Conjunto_de_Estados } S = { Diagrama } T = { , , } R = { Transición, Transición_Self } Attr = { Entrada, Salida}

Los atributos se encuentran en el contorno de cada elemento visual, como se muestra en los siguientes símbolos: Salida Entrada , Salida Entrada

60

P={





(Transición_Self, Salida 1, Entrada 1 ) }

Figura 3.17. Gramática acotada de los diagramas de estados

En las gramáticas relacionales una producción está acompañada de las posibles relaciones que puedan generarse. En la primera producción “Diagrama” produce un Estado Inicial, un Estado y un Conjunto_de_Estados, el Estado Inicial inicia la interacción con una Transición desde su salida hacia la entrada del Estado, se pueden generar más relaciones entre elementos gracias al no terminal Conjunto_de_Estados.


Diagrama

Desde Estado Inicial


Conjunto_de_Estados

Desde Estado


61

Generalizando se puede definir lo siguiente:

Del primer terminal de la regla de producción se realiza una transición al segundo elemento de la misma regla, realizándose en la mayoría de los casos. En sólo algunos casos se representa una transición del segundo terminal de la regla de producción al primer terminal de la misma regla.

Existe sólo un caso donde se utiliza la relación Transición_Self, y es cuando una acción no modifica el estado del objeto pero se representa para verificar que se ha realizado o se debe de realizar. La regla de producción referente a Transición_Self contiene sólo un símbolo terminal Estado, el cual dirige una transición desde su salida hacia su misma entrada. 3.4.6 Conclusiones de la gramática visual

En todos los ámbitos de la ingeniería se construyen modelos, en realidad son simplificaciones de la realidad que nos ayudan a comprender mejor el sistema que vamos a desarrollar. Construir modelos formalmente es importante para una buena documentación del sistema.

La Gramática Visual Relacional permite obtener una nueva manera de formalización de los diagramas, donde es más fácil la generación de la oración visual siguiendo las reglas de producción de la gramática, así mismo alguna oración visual del lenguaje que resulta puede ser evaluada con la gramática planteada, tal y como se utiliza cualquier gramática que representa un lenguaje.

No se ha encontrado ningún documento donde se formalice a través de Gramáticas Visuales los diagramas de estados del UML. La gramática definida en éste trabajo funciona como guía en la construcción segura de los Diagramas de Estados. Los Diagramas de Estados pueden ser usados para modelar el comportamiento de cualquier sistema desde el punto de vista del cambio de su estado. Los diagramas de estados describen una parte del aspecto dinámico del sistema, la otra parte la componen diagramas como los de secuencia, los de actividad, etc. [CON03].

Otras especificaciones formales surgirán para fortalecer el modelado con los diagramas de UML y se tendrá que elegir o excluir algunas de ellas, pero todo ello con la finalidad que el trabajo de los modeladores de sistemas de software sea realizado con mayor calidad, y se reduzca el esfuerzo y el tiempo de desarrollo.

62

3.5 REFERENCIAS [MSD04] Microsoft. msdn.Microsoft.com. Junio 2004. [KRU99] Kruglinski David J., Shepherd George, Wingo Scot. Programación Avanzada con Visual

C++. McGraw Hill. 1999. [ALC03] Alcatel / Computer Associates International Inc. / Electronic Data Systems Corporation /

Hewlett-Packard Company / IBM Corporation / I-Logix / IntelliCorp / Kabira Technologies / Kennedy Carter / Microsoft Corporation / Object Management Group / Oracle Corporation / Project Technology / Ptech Inc. / Rational Software Corporation / Reich Technologies / Softeam Taskon A/S / Telelogic / Unisys Corporation.: OMG Unified Modeling Language Specification, March 2003, Version 1.5, formal/03-03-01, Unified Modeling Language, 2003

[CON03] Construcción de Diagramas de Secuencias de UML Basados en una Gramática Visual

Relacional. 2003. [FER00] Fernández Alemán, José Luis / Toval Álvarez, Ambrosio.: Can Intuition Become Rigorous?,

Foundations for UML Model Verification Tools, Proceedings of the ISSRE 2000 The Eleventh International Symposium on Software Reliability Engineering. October 8-11 2000. San José, California, USA. IEEE Computer Press (October 2000) ISBN 0-7695-0807-3; ISSN 1071-9458, {aleman, atoval}@dif.um.es, 2000

[DUM02] Dumond, Yves / Girardet, Didier / Oquendo, Flavio.: A relationship between sequence and

statechart diagrams, LLP/CESALP Laboratory – University of Savoy, Campus Scientifique F-73376 Le Bourget-du-Lac Cedex, ESIA B.P. 806 F-74016 Annecy Cedex, 2002

[TSI01] Tsiolakis, Aliki.: Semantic Analysis and Consistency Checking of UML Sequence

Diagrams, partially supported by the German Research Council, project IOSIP, 2001 [ARE02] B. Aredo, Demissie.: Semantics of UML Sequence Diagram in PVS, Departament of

Informatics, University of Oslo, Institute for Energy Technology, P.O. Box 173, N-1751 Halden, Norwal, [email protected], 2002

[VER01] Verschaeve, Kurt.: Combining UML and SDL, System and Software Engineering Lab, Vrije

Universiteit Brussel, Pleinlaan 2, B 1050 Brussel, Belgium, [email protected] 2001 [UCH01] Uchitel, Sebastián / Magee, Jeff / Kramer, Jeff.: From Sequence Diagrams to Behaviour

Models, Department of Computing, Imperial College, 180 Queen’s Gate, London SW7 2Bz, UK, 2001

[ALC01] Alcatel / I-Logix / Kennedy-Carter / Kabira Technologies, Inc. / Project Technology, Inc /

Rational Software Corporation / Telelogic AB.: Action Semantic for UML, OMG ad/2001-08-04, 2001

[HEC01] Heckel, Reiko / Saber, Stefan.: Strengthening the semantics of UML Collaboration

Diagrams, University of Paderborn, Dept. of Mathematics and Computer Science, D-33095 Paderborn, Germany, 2001

[SHU88] Shu, Nan C.: Visual Programming, Van Nostrand Reinhold, 1988


PPrruueebbaass

"En los momentos de crisis sólo la imaginación es más importante que el conocimiento".

-ALBERT EINSTEIN 4.1 Introducción 4.2 Plan de Pruebas 4.3 Procedimiento de pruebas 4.4 Pruebas

64

4.1 INTRODUCCIÓN Este capítulo muestra las pruebas a las que se ha sometido el ambiente Ke2. El formato de las pruebas se ha dado de acuerdo al estándar para la Documentación de Pruebas de Software IEEE 829-1998 (Rev. del Std 829-1983). Las pruebas realizadas obedecen al manejo de la consistencia y la generación de diagramas como se ha documentado en el Capítulo III de ésta tesis. También presenta de manera breve cómo es la interacción de la interfaz gráfica de la herramienta con el usuario.

Se presenta un caso de estudio a manera de prueba. El caso de estudio se ha tomado del Diagrama de Clases de lab3D1, que es un sistema simulador de procesos químicos. De estas pruebas se desprende un análisis de resultados obtenidos para constatar la validez de la hipótesis que sostiene el presente trabajo.

El identificador del plan de pruebas es “PKe2-n”, donde n es el número de prueba a

realizar. 4.2 PLAN DE PRUEBAS Propósito: Definir el alcance, enfoque, recursos y el calendario de las actividades de prueba. Identificar los artículos a ser probados, las características a ser probadas, las tareas de pruebas a ser efectuadas, el personal responsable para cada tarea y los riesgos asociados con el plan. 4.2.1 Casos de Prueba

• PKe2-1. Crear un Diagrama Aislado • PKe2-2. Asociar un Diagrama Aislado con una Clase Definida • PKe2-3. Seleccionar de Toda la Lista de Clases una Clase a Asociar • PKe2-4. Verificar la Clase Asociada o por Asociar • PKe2-5. Asociar la Clase Definida por Asociar • PKe2-6. Desasociar la Clase Asociada • PKe2-7. Generar un Diagrama de Estados Consistente con una Clase de un

Diagrama de Clases • PKe2-8. Generar múltiples Documentos del Tipo de Diagramas de Estados • PKe2-9. Guardado y Recuperación

A partir de un diagrama de estados consistente, que se muestre el manejo de la

inconsistencia por:

• PKe2-10. El Cambio de Nombre de una Clase • PKe2-11. El Borrado de una Clase • PKe2-12. El Cambio de Nombre de un Atributo • PKe2-13. El Borrado de un Atributo

1 http://javalab.chem.virginia.edu/lab3d/ Revisado en Junio del 2004.

65

• PKe2-14. El Cambio de Nombre de un Método • PKe2-15. El borrado de un método

4.2.2 Características a ser Probadas

• La generación de los diagramas debe ser correcta. • La consistencia debe mantenerse para las acciones definidas (borrado o cambio de

nombre de una clase, un atributo y / o un método). • Los diagramas pueden aislarse o asociarse a una clase en cualquier momento. • La generación de múltiples Diagramas de Estados para un Diagrama de Clases. • Guardado de documentos, recuperación e impresión.

4.2.3 Criterio Pasa / No-Pasa de los Casos de Prueba Pasa:

• Se generan correctamente los elementos de un Diagrama de Estados. • Se mantiene la consistencia entre diagramas. • En caso de inconsistencia se desasocia el Diagrama de Estados. • Se generan múltiples Diagramas de Estados que mantienen independencia en sus

datos. • Se guarda o se recupera o se imprime correctamente un documento.

No pasa:

• No cumplimiento de los puntos de aceptación (pasa). 4.2.4 Tareas de Prueba

Se realizaron las pruebas correspondientes al ambiente de modelado del estado de objetos de una clase, tomándose como base el caso de prueba definido. Las tareas consisten en ejecutar el ambiente y realizar todas las posibles acciones de un usuario final para generar los Diagramas de Estados consistentes con los Diagramas de Clases. 4.2.5 Aprobación

La aprobación del sistema es dada cuando los criterios “Pasa” han sido cubiertos satisfactoriamente.

66

4.3 PROCEDIMIENTO DE PRUEBAS Propósito: Especificar los pasos para ejecutar un conjunto de casos de prueba para el ambiente de Ke2 y SOODA a fin de evaluar un conjunto de características que deben de ser cubiertas. 4.3.1 PKe2-1. Crear un Diagrama de Estados Aislado Pasos:

• Abrir la SCUML. • Crear un proyecto. • Crear un Diagrama de Estados. • Generar el Diagrama de Estados.

4.3.2 PKe2-2. Asociar un Diagrama de Estados Aislado con una Clase Requerimientos especiales (prerrequisitos):

• Tener un Proyecto generado. • Tener un Diagrama de Clases. • Tener un Diagrama de Estados. • Que exista la clase por asociar en el Diagrama de Clases.

Pasos:

• Abrir o generar el proyecto que contiene el Diagrama de Clases. • Abrir el Diagrama de Estados a asociar. • Desde el Diagrama de Estados, hacer clic en el botón que asocie el Diagrama de

Estados con la clase por asociar del Diagrama de Clases. 4.3.3 Ke2-3. Seleccionar de Toda la Lista de Clases una Clase a Asociar Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases. • Tener un Diagrama de Estados.

Pasos:

• Desde el Diagrama de Estados, hacer clic en el botón que muestre la ventana de clases por asociar, y que contiene la lista de clases del Diagrama de Clases.

• Seleccionar una clase a asociar. • Verificar que la nueva clase seleccionada por asociar haya sido asociada.

67

4.3.4 PKe2-4. Verificar la Clase Asociada o por Asociar Requerimientos especiales (prerrequisitos):


Pasos:

• Desde el Diagrama de Estados, hacer clic en el botón que verifica la clase asociada o por asociar. Cuando un Diagrama de Estados está Asociado, se dice que la clase que se muestra “Se asocia con”, mientras que cuando un Diagrama de Estados está desasociado, se dice que la clase que se muestra “Está por ser asociada”

4.3.5 PKe2-5. Asociar la Clase Definida por Asociar Requerimientos especiales (prerrequisitos):


Pasos:

• Desde el Diagrama de Estados, hacer clic en el botón que asocia un Diagrama de Estados con una clase de un Diagrama de Clases.

4.3.6 PKe2-6. Desasociar la Clase Asociada Requerimientos especiales (prerrequisitos):


Pasos:

• Desde el Diagrama de Estados, hacer clic en el botón que desasocia un Diagrama de Estados con una clase de un Diagrama de Clases.

4.3.7 PKe2-7. Generar un Diagrama de Estados Consistente con una Clase de un

Diagrama de Clases Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases.

68

Pasos: • Generar el Diagrama de Estados. • Seleccionar una clase a asociar con el Diagrama de Estados para generar la

consistencia. • Crear el Diagrama de Estados consistente con los diagramas de clases desde los

cuadros de diálogos que muestra el ambiente, seleccionando los métodos y atributos existentes en la clase asociada.

4.3.8 PKe2-8. Generar Multi-Documentos del Tipo de Diagramas de Estados Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases.

Pasos:

• Generar un Diagrama de Estados con una clase asociada. • Generar uno o más Diagramas de Estados con una clase asociada.

4.3.9 PKe2-9. Guardado y Recuperación Guardado: Requerimientos especiales (prerrequisitos):


Para guardar un proyecto: Pasos:

• Activar la ventana del proyecto. • Presionar el botón Guardar y continuar con los pasos comunes del guardado de un

archivo.

69

Recuperación: Pasos:

• Para recuperar un proyecto. • Hacer clic en el botón abrir y, continuar los pasos comunes de la apertura de un

documento. 4.3.10 PKe2-10. El cambio de Nombre de una Clase Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases. • Tener un Diagrama de Estados. • Tener definida la clase en el Diagrama de Clases a la que se modificará el nombre. • Tener asociado el Diagrama de Estados con la clase a la que se modificará el

nombre. Pasos:

• Cambiar el nombre de la clase desde el Diagrama de Clases. • Ke2 mostrará como sugerencia las clases que muestran una estructura similar a la

clase modificada. • Si no existe alguna estructura similar, Ke2 muestra la lista de clases posibles a

asociar. • El usuario debe de seleccionar alguna clase a asociar para mantener la consistencia,

en caso de no seleccionar alguna, el Diagrama de Estados se aísla. • Se revisa si el diagrama está aislado por medio de la verificación de la clase

asociada o por asociar. 4.3.11 PKe2-11. El Borrado de una Clase Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases. • Tener un Diagrama de Estados. • Tener definida la clase en el Diagrama de Clases que se va a borrar. • Tener asociado el Diagrama de Estados con la clase que se borrará.

Pasos:

• Borrar la clase desde el Diagrama de Clases. • Ke2 mostrará como sugerencia las clases que muestran una estructura similar a la

clase modificada. • Si no existe alguna estructura similar, Ke2 muestra la lista de clases posibles a

asociar.

70

• El usuario debe de seleccionar alguna clase a asociar para mantener la consistencia, en caso de no seleccionar alguna, el Diagrama de Estados se aísla.

• Se revisa si el diagrama esta aislado por medio de la verificación de la clase asociada o por asociar.

4.3.12 PKe2-12. El Cambio de Nombre de un Atributo Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases. • Tener un Diagrama de Estados. • Tener definida la clase en el Diagrama de Clases que contiene el atributo a cambiar

de nombre. • Tener asociado el Diagrama de Estados con la clase que contiene el atributo.

Pasos:

• Modificar el nombre del atributo desde el Diagrama de Clases. • Ke2 mostrará como sugerencia los atributos de la clase que muestran una estructura

similar al atributo modificado. • Si no existe algún atributo similar, Ke2 muestra la lista de atributos posibles a

reemplazar por el atributo modificado. • El usuario debe de seleccionar algún atributo de la clase para mantener la

consistencia, en caso de no seleccionar alguno, el diagrama pregunta si se borra el atributo. Si se borra el atributo la consistencia se mantiene, en caso contrario se aísla el Diagrama de Estados.

• Si no se escoge algún atributo por modificar, el ambiente indica lo siguiente: Si se desea eliminar para mantener la consistencia o si se desea dejar pero aislando el diagrama.

• Si se mantiene la consistencia, el Diagrama de Estados se actualiza con la nueva definición.

• Se revisa si el diagrama está aislado por medio de la verificación de la clase asociada o por asociar.

4.3.13 PKe2-13. El Borrado de un Atributo Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases. • Tener un Diagrama de Estados. • Tener definida la clase en el Diagrama de Clases que contiene el atributo a borrar. • Tener asociado el Diagrama de Estados con la clase que contiene el atributo a

borrar. Pasos:

• Borrar el atributo desde el Diagrama de Clases.

71

• Ke2 mostrará como sugerencia los atributos de la clase que muestran una estructura similar al atributo borrado.

• Si no existe algún atributo similar, Ke2 muestra la lista de atributos posibles a reemplazar por el atributo borrado.

• El usuario debe seleccionar algún atributo de la clase para mantener la consistencia, en caso de no seleccionar alguno, el diagrama pregunta si se borra el atributo. Si se borra el atributo la consistencia se mantiene, en caso contrario se aísla el Diagrama de Estados.




4.3.14 PKe2-14. El Cambio de Nombre de un Método Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases. • Tener un Diagrama de Estados. • Tener definida la clase en el Diagrama de Clases que contiene el método a cambiar

de nombre. • Tener asociado el Diagrama de Estados con la clase que contiene el método.

Pasos:

• Modificar el nombre del método desde el Diagrama de Clases. • Ke2 mostrará como sugerencia los métodos de la clase que muestran una estructura

similar al método modificado. • Si no existe algún método similar, Ke2 muestra la lista de métodos posibles a

reemplazar por el método modificado. • El usuario debe de seleccionar algún método de la clase para mantener la

consistencia, en caso de no seleccionar alguno, el diagrama pregunta si se borra el método. Si se borra el método la consistencia se mantiene, en caso contrario se aísla el Diagrama de Estados.

• Si no se escoge algún método por modificar, el ambiente indica lo siguiente: Si se desea eliminar para mantener la consistencia o si se desea dejar pero aislando el diagrama.



72

4.3.15 PKe2-15. El Borrado de un Método Requerimientos especiales (prerrequisitos):

• Tener un proyecto generado. • Tener un Diagrama de Clases. • Tener un Diagrama de Estados. • Tener definida la clase en el Diagrama de Clases que contiene el método a borrar. • Tener asociado el Diagrama de Estados con la clase que contiene el método.

Pasos:

• Borrar el método desde el Diagrama de Clases. • Ke2 mostrará como sugerencia los métodos de la clase que muestran una estructura

similar al método modificado. • Si no existe algún método similar, Ke2 muestra la lista de métodos posibles a

reemplazar por el método borrado. • El usuario debe de seleccionar algún método de la clase para mantener la





73

4.4 PRUEBAS Propósito: Mostrar cómo el ambiente de Ke2 cumple con las pruebas antes especificadas. Las pruebas han sido realizadas utilizando el caso de estudio mencionado al inicio de éste Capítulo, cuyo diagrama de clases se muestra en la Figura 4.2. 4.4.1 PKe2-1. Crear un Diagrama Aislado Pasos:

• Abrir la SCUML. • Crear un proyecto. • Crear un Diagrama de Estados. • Generar el Diagrama de Estados. La Figura 4.1 muestra un diagrama de estados que fue generado de manera aislada.

Figura 4.1. Diagrama de estados generado de manera aislada.

74

4.4.2 PKe2-2. Asociar un Diagrama Aislado con una Clase Para realizar la asociación, es necesario contar con un diagrama de clases que no esté vacío, para este caso de prueba se utilizó el diagrama de clases mostrado en la Figura 4.2, que corresponde al diagrama de clases de lab3D. Pasos:

• Abrir o generar el proyecto que contiene el Diagrama de Clases.

Figura 4.2. Parte del diagrama de clases de el ambiente de Lab3D que contiene la clase

TestTube

• Abrir el Diagrama de Estados a asociar (Ver Figura 4.1) • Desde el Diagrama de Estados, hacer clic en el botón que asocie el Diagrama de

Estados con la clase por asociar. (Ver Figura 4.3). Si no existe una clase a asociar, entonces se deberá escoger dicha clase de la lista de clases (Ver Figura 4.4)

Figura 4.3. Botón de asociar diagrama de estados con la clase definida del diagrama de clases

75

Figura 4.4. Lista de clases posibles a asociar con el diagrama de estados de la clase TestTube

4.4.3 PKe2-3. Seleccionar de Toda la Lista de Clases una Clase a Asociar Pasos:

• Desde el Diagrama de Estados, hacer clic en el botón que muestre la ventana de clases por asociar, y que contiene la lista de clases del Diagrama de Clases (Ver Figura 4.5)

Figura 4.5. Botón que muestra la lista de clases posibles a asociar

• Seleccionar una clase a asociar (Ver Figura 4.4)

76

• Verificar que la nueva clase seleccionada por asociar, ha sido asociada.

Para verificar si una clase se encuentra asociada o se puede asociar, es necesario presionar el botón de información de asociación como se muestra en la Figura 4.6.

Figura 4.6. Botón de información de la asociación

Se verifica que la clase haya sido asociada (Ver Figura 4.7).

Figura 4.7. Mensaje de la clase asociada 4.4.4 PKe2-4. Verificar la Clase Asociada o por Asociar Pasos:

• Desde el Diagrama de Estados hacer clic en el botón que verifica la clase asociada o por asociar. Cuando un Diagrama de Estados está Asociado, se dice que la clase que se muestra “Se asocia con” (Figura 4.7), mientras que cuando un Diagrama de Estados está desasociado, se dice que la clase que se muestra “Está por ser asociada” (Figura 4.8)

Figura 4.8. Mensaje de la clase por asociar.

77

4.4.5 PKe2-5. Asociar la Clase Definida por Asociar Pasos:

• Desde el Diagrama de Estados, hacer clic en el botón que asocia un Diagrama de Estados con una clase de un Diagrama de Clases.

Primero se observa que se tiene una clase por asociar como lo muestra la Figura 4.8,

enseguida se presiona el botón de “asociar el diagrama” como lo muestra la Figura 4.3, y se revisa si la clase ha sido asociada por medio del botón de “asociar el diagrama”, mostrando que ya ha sido asociado como lo muestra la Figura 4.7. 4.4.6 PKe2-6. Desasociar la Clase Asociada Pasos:

• Desde el Diagrama de Estados, hacer clic en el botón que desasocia un Diagrama de Estados con una clase de un Diagrama de Clases.

Teniendo una clase asociada como lo muestra la Figura 4.7, se hace clic sobre el

botón de “desasociar diagramas” que es mostrado en la Figura 4.9. Una vez desasociados, se revisa si existe asociación entre diagramas, entonces se muestra la ventana de la Figura 4.8 donde se indica que se va a asociar, es decir, que no se encuentra asociada.

Figura 4.9. Botón de desasociar diagramas. 4.4.7 PKe2-7. Generar un Diagrama de Estados Consistente con una Clase de un

Diagrama de Clases Para generar un Diagrama de Clases y un Diagrama de Estados consistentes entre sí, según la manera de tratar a la consistencia que propone ésta tesis, se debe de tener primeramente un diagrama de clases (Ver Figura 4.10).

78

Figura 4.10. Parte del diagrama de clases de Lab3D. Pasos:

• Generar el Diagrama de Estados • Seleccionar una clase a asociar con el Diagrama de Estados para generar la

consistencia (Ver Figura 4.11)

Figura 4.11. Selección de la clase TestTube para generar su diagrama de estados consistente.

• Crear el Diagrama de Estados consistente con los diagramas de clases desde los

cuadros de diálogos que muestra el ambiente, seleccionando los métodos y atributos existentes en la clase asociada (Ver Figura 4.12 y Figura 4.13)

79

Figura 4.12. Selección de un método del diagrama de clases para realizar un modelado consistente, para una transición.

Figura 4.13. Selección de un método del diagrama de clases para realizar un modelado consistente, para un estado.

Cuando se crean los Diagramas de Estados de esta manera, la consistencia se

mantiene entre los diagramas, el resultado es un diagrama confiable desde el punto de vista de la consistencia (Ver Figura 4.14).

80

Figura 4.14. Diagrama de estados creado de manera consistente con la clase TestTube 4.4.8 PKe2-8. Generar Multi-Documentos del Tipo de Diagramas de Estados Pasos:

• Generar un Diagrama de Estados con una clase asociada. • Generar uno o más Diagramas de Estados con una clase asociada.

81

Figura 4.15. SCUML con multi- diagramas de estados para Lab3D 4.4.9 PKe2-9. Guardado y Recuperación El guardado y recuperación de los archivos se hace de la misma manera que cualquier archivo desde un editor de texto. 4.4.10 PKe2-10. El Cambio de Nombre de una Clase Pasos:

• Cambiar el nombre de la clase desde el Diagrama de Clases. • Ke2 mostrará como sugerencia las clases que muestran una estructura similar a la

clase modificada.

Del Diagrama de Clases de lab3D, se cambia de nombre de “TestTube” a “TestTubes” como lo muestra la Figura 4.16.

82

Figura 4.16. Cambio de nombre de la clase “TestTube” por “TestTubes”

• Si no existe alguna estructura similar, Ke2 muestra la lista de clases posibles a asociar. Lo que realiza el ambiente, es un recorrido para encontrar las clases similares. La

Figura 4.17 muestra las clases similares encontradas.

Figura 4.17. Mensajes de las clases similares encontradas que pueden sustituir a TestTube

83

• El usuario debe seleccionar alguna clase a asociar y así mantener la consistencia, en caso de no seleccionar ninguna el Diagrama de Estados se aísla.

Si no se acepta TestTubes el ambiente muestra la lista de clases que se pueden

asociar como lo muestra la Figura 4.18.

Figura 4.18. Lista de clases a asociar


Si se selecciona la clase TestTubes ya sea por la sugerencia o por la selección de la

clase, la consistencia se mantiene, si no se toma una clase para asociar el ambiente envía el mensaje de la Figura 4.19.

Figura 4.19. Mensaje de inconsistencia y de aislamiento del diagrama de estados

84

4.4.11 PKe2-11. El Borrado de una Clase Pasos:

• Borrar la clase desde el Diagrama de Clases (Ver Figura 4.10 y Figura 4.20).

Figura 4.20. Diagrama de clases de Lab3D sin la clase TestTube

• Ke2 mostrará como sugerencia las clases que tienen una estructura similar a la clase modificada. (Ver Figura 4.21).

Figura 4.21. Sugerencia de la clase por la que puede ser asociado el diagrama de estados

• Si no existe alguna estructura similar, Ke2 muestra la lista de clases posibles a asociar. (Ver Figura 4.22).

85

Figura 4.22. Lista de clases por asociar cuando la clase TestTube ha sido borrada • El usuario debe de seleccionar alguna clase a asociar para mantener la consistencia,

en caso de no seleccionar ninguna el Diagrama de Estados se aísla.

Si no se selecciona una clase o si se cancela la operación, el ambiente de Ke2 aísla el diagrama.

• Se verifica si el diagrama está aislado por medio de la verificación de la clase asociada o por asociar (Ver Figura 4.23).

Figura 4.23. Mensaje que indica que la clase por asociar es TestTube 4.4.12 PKe2-12. El Cambio de Nombre de un Atributo

Para realizar esta prueba, a la clase TestTube del Diagrama de Clases, se le agrega el atributo “epzilon” (Ver Figura 4.24).

Figura 4.24. Clase TestTube con el atributo epzilon

86

Se crea en el Diagrama de Estados en la transición de Vaciar(), el uso del atributo de epzilon (Ver Figura 4.25 y Figura 4.26).

Figura 4.25. Uso del atributo epzilon en el diagrama de estados

Figura 4.26. Diagrama de estados con el uso del atributo epzilon Pasos:

87

• Modificar el nombre del atributo desde el Diagrama de Clases.(Ver Figura 4.27)

Figura 4.27. Cambio de nombre del atributo “epzilon” por “epsilon”

• Ke2 presentará como sugerencia los atributos de la clase que muestran una estructura similar al atributo modificado. (Ver Figura 4.28).

Figura 4.28. Mensaje de modificación de “epzilon” por “epsilon” en el diagrama de estados

• Si no existe algún atributo similar, Ke2 muestra la lista de atributos posibles a

reemplazar por el atributo modificado. Para este ejemplo no existen más atributos en la clase.

• El usuario debe seleccionar algún atributo de la clase para mantener la consistencia, en caso de no seleccionar alguno el diagrama pregunta si se borra el atributo. Si se borra el atributo la consistencia se mantiene, en caso contrario se aísla el Diagrama de Estados.


88

Figura 4.29. Mensaje indicando si se desea eliminar el atributo • Si se mantiene la consistencia, el Diagrama de Estados se actualiza con la nueva

definición

Figura 4.30. Diagrama de estados modificado eliminando el atributo no encontrado “epsilon” para mantener la consistencia

• Se revisa si el diagrama está aislado por medio de la verificación de la clase

asociada o por asociar.

89

4.4.13 PKe2-13. El Borrado de un Atributo El trato de consistencia que se le da a esta acción es la misma que para el cambio de nombre del atributo. Pasos:

• Borrar el atributo desde el Diagrama de Clases. • Ke2 presentará como sugerencia los atributos de la clase que muestran una

estructura similar al atributo borrado. • Si no existe algún atributo similar, Ke2 muestra la lista de atributos posibles a

reemplazar por el atributo borrado. • El usuario debe seleccionar algún atributo de la clase para mantener la consistencia,

en caso de no seleccionar alguno, el diagrama pregunta si se borra el atributo. Si se borra el atributo la consistencia se mantiene, en caso contrario se aísla el Diagrama de Estados.




4.4.14 PKe2-14. El Cambio de Nombre de un Método La consistencia para el cambio de nombre de un método se trata igual que el cambio de nombre de un atributo. Pasos:

• Modificar el nombre del método desde el Diagrama de Clases. • Ke2 presentará como sugerencia los métodos de la clase que muestran una

estructura similar al método modificado. • Si no existe algún método similar, Ke2 muestra la lista de métodos posibles a

reemplazar por el método modificado. • El usuario debe de seleccionar algún método de la clase para mantener la





90

4.4.15 PKe2-15. El Borrado de un Método La consistencia para el borrado de un método se trata como el cambio de nombre de un método. Pasos:

• Borrar el método desde el Diagrama de Clases. • Ke2 presentará como sugerencia los métodos de la clase que muestran una

estructura similar al método modificado. • Si no existe algún método similar, Ke2 muestra la lista de métodos posibles a

reemplazar por el método borrado. • El usuario debe seleccionar algún método de la clase para mantener la consistencia,

en caso de no seleccionar alguno, el diagrama pregunta si se borra el método. Si se borra el método la consistencia se mantiene, en caso contrario se aísla el Diagrama de Estados.





RReessuullttaaddooss yy CCoonncclluussiioonneess

“Todo lo que empieces, lo debes terminar” - ELSA MIRANDA LÓPEZ

5.1 Análisis del resultado de las pruebas 5.2 Conclusiones 5.3 Trabajos Futuros 5.4 Publicaciones y Premios

92

5.1 ANÁLISIS DEL RESULTADO DE LAS PRUEBAS

Las pruebas realizadas al ambiente de Ke2 han resultado satisfactorias para los objetivos que la tesis presenta, existen algunas limitaciones ya que el ambiente se presenta como un desarrollo académico, limitaciones que se proponen como trabajos a futuro.

El mantener la consistencia depende finalmente del diseñador, ya que la solución propuesta solo se limita a indicar por medio del ambiente que el modelado puede o no ser inconsistente y sugiere cambios para mantener la consistencia.

A continuación se describen algunas características que han sido implementadas tanto en Ke2 como en el ambiente integrado de SCUML:

• Un diagrama de estados solo puede crearse dentro de un proyecto, ya sea de manera aislada o de manera asociada con un diagrama de clases.

• Un diagrama de estados sólo puede asociarse con una clase existente dentro del diagrama de clases del mismo proyecto al que pertenezca el diagrama de estados.

• En la SCUML puede existir sólo un diagrama de clases por proyecto y múltiples diagramas de estados.

• Uno o más diagramas de estados pueden asociarse, o representar, a una misma clase. Ya que es incorrecto que dos o más diagramas de estados representen a una misma clase la corrección se propone como trabajo a futuro.

• Un diagrama de estados no puede guardarse de manera aislada, sólo se guarda el proyecto que contiene a dicho diagrama de estados, y los diagramas que la suite contiene.

5.2 CONCLUSIONES

Este apartado describe las conclusiones y productos que ha arrojado la presente tesis.

Las principales conclusiones son:

• El desarrollo de software que ha surgido de la tesis, es el ambiente de Ke2, el cual se ha integrado dentro del ambiente de la SCUML en conjunto con los diagramas de clases, los diagramas de secuencias y los diagramas de paquetes.

• Como se muestra en el capitulo 3, es posible mantener la consistencia entre diagramas, por lo cual la primera conclusión que se ha originado de la presente tesis es haber comprobado la hipótesis planteada que sostiene que: Es posible establecer la consistencia entre una clase (de un diagrama de clases) y un diagrama de estados. Por lo tanto, si SOODA modela un diagrama de clases, entonces se podrá establecer una conexión (consistente) entre SOODA y los diagramas de Estado.

• La suite cenidet-UML es casi una realidad, y ya pueden realizarse modelados de sistemas completos, limitado solamente por los diagramas que la suite emplea para poder probar la eficiencia de la suite en un ambiente de modelado real.

93

Las aportaciones del trabajo de tesis son las siguientes: • La aportación principal de la presente tesis es mantener la consistencia entre los

diagramas de estado y los diagramas de clase, repercutiendo directamente en el modelado de sistemas de software y por tanto también al proceso de ingeniería de software, ya que la aplicación de la consistencia auxilia al diseñador a realizar modelos que mantienen una relación coherente entre diagramas. Lo anterior permite obtener diseños mas confiables y de mayor calidad y confiabilidad.

• La creación de la formalización de una gramática a través de una gramática visual

relacional acotada, fue implementada satisfactoriamente dentro del ambiente de Ke2. Su seguimiento a través de la creación de un diagrama de estados puede verse comprobado desde Ke2.

• La arquitectura de clases con la que ahora cuenta el ambiente de Ke2 permite la creación de nuevos ambientes de modelado basados en los diagramas de UML, para extender los diagramas que maneja la SCUML, como lo son los diagramas de objetos, de actividad, entre otros. La arquitectura ha sido diseñada para que sea más fácil extender la funcionalidad e implementar más elementos visuales.

La tendencia que podría surgir a partir de esta tesis, es la de ambientes de modelado de cualquier tipo de sistema que implemente la consistencia entre diagramas, los diagramas que propone UML normalmente tienen las mismas primitivas de modelado, mantener a dichas primitivas consistentes en todos los diagramas seria un gran avance dentro del modelado de sistemas de software.

Este trabajo es una propuesta para mejorar el proceso de modelado de un sistema de software, y se sugiere atender a la consistencia con la importancia que merece y llevarla a cabo tanto al documento que define al UML, como en las herramientas creadas para modelar con UML.

La ingeniería de software es aun una disciplina inmadura, las diversas investigaciones han ido fortaleciendo a la Ingeniería de software, la tesis presentada propone una manera de dar mas robustez al proceso de diseño dentro de la ingeniería de software por medio de la consistencia.

5.2.1 Beneficios Obtenidos

1. Se cuenta con los ambientes de SOODA y Ke2, módulos que permiten un modelado consistente.

2. Se cuenta con un ambiente de modelado con el cual se puede evitar costo, tiempo, y/o esfuerzos no programados.

3. Se ha obtenido un ambiente visual que permite modelar los aspectos de diseño estático y dinámico de software.

4. Se han formalizado los diagramas de estados a partir de una gramática visual.

94

5.2.2 Limitaciones

Limitaciones del ambiente de Ke2.

• Un diagrama de estados puede ser creado siempre y cuando pertenezca a un proyecto.

• Un diagrama de estados aislado puede asociarse con una clase de un diagrama de clases si y sólo si ambos diagramas pertenecen al mismo proyecto.

• El ambiente no indica las clases que ya tienen un diagrama de estados asociado. • Las transiciones no son deformables, es decir, su dirección sólo implica trayectorias

en línea recta. • No trabaja en un ambiente de red o multiusuario. • Se estableció un límite en cuanto al nivel de profundidad de un Diagrama de

Estados, es decir, un estado no contendrá un diagrama de estados anidado.

5.3 TRABAJOS FUTUROS

Sin duda el campo de aplicación de SCUML y de los diagramas de estados tiene mucho futuro, algunos de los trabajos que podrían realizarse para mejorar el ambiente de modelado de Ke2 son:

• Actualizar la Gramática Visual Relacional según los cambios que se generen para versiones posteriores de la definición del UML.

• Implementar la generación de diagramas de estados para un estado, es decir, la generación de los subestados.

• Implementar la gramática visual completa en el ambiente de Ke2, agregando los elementos de estado de concurrencia, estado de sincronización y estado de historial.

• Implementar que las clases virtualmente puras no puedan ser elegidas para generar su diagrama de estados, ya que realizarlo sería incorrecto, así como el modelado de una clase que no contenga métodos tambien sería un error.

• La verificación del determinismo de un diagrama de estados. • Implementar las condiciones múltiples en la condición de los elementos de los

estados y las transiciones. • Implementar la visibilidad que alcanzan las clases heredadas con respecto a las

clases padre, para que un atributo privado de la clase padre no pueda ser modelado desde el diagrama de estados de una clase hija.

• Validar que una clase solo tenga asociad a un diagrama de estados. • Implementar que se inserte en la clase modelada por un diagrama de estados, un

método o atributo utilizado en los diagramas de estados que no exista en la clase. • Implementar la consistencia entre los distintos diagramas que UML propone.

95

5.4 PUBLICACIONES Y PREMIOS

Las publicaciones que la presente tesis ha tenido son:

Artículo: “Inconsistencia entre los diagramas de clase y los diagramas de estado propuestos por UML” dentro de la 14ª Reunión de Otoño de Comunicaciones, Comunicación, Electrónica y Exposición Industrial (ROC&C´03), Acapulco, Guerrero. Noviembre del 2003.

Artículo: “Modelado consistente entre los diagramas de clase y los diagramas de estado propuestos por UML.” Dentro del X Congreso de Informática en la Educación de la Convención Informática 2004. La Habana, Cuba. Mayo 2004.

Conferencia: “Consistencia entre los diagramas de clase y los diagramas de estado que propone UML”. Dentro del XXV aniversario de la Universidad Fray Luca Paccioli. Cuernavaca, Morelos, México. Junio 2004.

Artículo: “Ke2: a tool that establishes consistency between UML class diagrams and UML statechart diagrams”. Por proponer a algún congreso. Artículo: “Ke2: Una herramienta que establece consistencia entre los diagramas de clases y los diagramas de estados propuestos por UML”. Por proponer a algún congreso. Artículo: “Una gramática visual relacional para formalizar los diagramas de estados propuestos por UML”. Por proponer a algún congreso. Los premios obtenidos son:

Primer lugar en el XIX Concurso Nacional de Creatividad en su fase local, dentro del Centro Nacional de Investigación y Desarrollo Tecnológico. Nivel Postgrado. Mayo del 2004. Cuernavaca, Morelos.

Tercer lugar en el XIX Concurso Nacional de Creatividad en su fase regional, dentro del Instituto Tecnológico de Orizaba. Nivel Postgrado. Junio del 2004. Orizaba, Veracruz. Participaciones:

Participación en el XIX Concurso Nacional de Creatividad en su fase Nacional, dentro del Instituto Tecnológico de Villahermosa. Nivel Postgrado. Junio del 2004. Villahermosa, Tabasco.

i

TABLA DE CONTENIDO Tabla de Contenido.................................................................................................... i Índice de Figuras .......................................................................................................v Índice de Tablas.........................................................................................................vii Glosario de Acrónimos..............................................................................................viii Capitulo 1. Conceptos Generales 1.1 Introducción ........................................................................................................2 1.2 Trabajos Relacionados.........................................................................................4

1.2.1 Herramientas Analizadas.........................................................................4

1.2.1.1 Rational Rose ..............................................................................4 1.2.1.2. GDPro ........................................................................................4 1.2.1.3. Visio ..........................................................................................4 1.2.1.4. MagicDraw ................................................................................4

1.2.2 Artículos Analizados ...............................................................................5

1.2.2.1. State Machine Shortcuts ............................................................5 1.2.2.2. Describing the Syntax and Semantics of UML

Statecharts in a Heterogeneous Modelling Environment ...........5 1.2.2.3. Checking General Safety Criteria on UML Statecharts ............6 1.2.2.4. On the Compositional Properties of UML Statechart

Diagrams .....................................................................................6 1.2.2.5. Visualizing Graphical and Textual Formalisms ........................6 1.2.2.6. A Relationship Between Sequence and Statechart Diagrams ...7 1.2.2.7. Completeness and Consistency Analysis of UML Statechart

Specifications .............................................................................7 1.2.2.8. Defining a Statechart Language using UML .............................7 1.2.2.9. Consistent Design of Embedded Real-time Systems with

UML-RT .....................................................................................8 1.2.2.10. Semantics of the Unified Modeling Language ........................8

1.3 Descripción del problema....................................................................................9

1.3.1 Problema..................................................................................................9 1.4 Objetivo de la Tesis .............................................................................................10

1.4.1 Objetivo General ....................................................................................10 1.4.2 Objetivos Específicos .............................................................................10

1.5 Hipótesis ..............................................................................................................10

ii

1.6 Referencias ..........................................................................................................11 Capitulo 2. Marco Teórico 2.1 Introducción.........................................................................................................13 2.2 Modelado de Sistemas de Software.....................................................................14 2.3 Lenguaje de Modelado Unificado .......................................................................16

2.3.1 Diagramas de Clases................................................................................19 2.3.2 Diagramas de estados ..............................................................................19

2.4 Programación Orientada a Objetos......................................................................21 2.5 Patrones de Diseño ..............................................................................................24

2.5.1 Patrón de diseño Composite ....................................................................24

2.5.1.1 Intención ...................................................................................24 2.5.1.2 Estructura..................................................................................25 2.5.1.3 Participantes .............................................................................25 2.5.1.4 Colaboraciones .........................................................................26 2.5.1.5 Patrones relacionados ...............................................................26 2.5.1.6 Aplicaciones .............................................................................26

2.6 Lenguajes Visuales ..............................................................................................27 2.7 Referencias ..........................................................................................................29 Capitulo 3. Desarrollo 3.1 Requerimientos del ambiente ..............................................................................31 3.2 Modelo conceptual del sistema............................................................................31

3.2.1 Introducción.............................................................................................31 3.2.2 Arquitectura de Solución Propuesta (mapa conceptual) .........................32 3.2.3 Diagrama de clases del ambiente de los diagramas de estados ...............33 3.2.4 Justificación del uso del patrón de diseño Strategy.................................36

3.2.4.1 Descripción del contexto del Mapa mental ................................36 3.2.4.2 Problema que se presenta y se soluciona en el mapa mental ......37 3.2.4.3 Participantes del mapa mental ....................................................37 3.2.4.4 Descripción del mapa mental en etapas de la secuencia de

interpretación...............................................................................37 3.2.4.5 Relación del mapa mental con respecto al patrón de diseño

Strategy........................................................................................37 3.2.4.6 Motivación del uso, aplicabilidad y consecuencias del patrón

de diseño Strategy........................................................................37 3.2.5 Aplicación del determinismo en los diagramas de estados .....................38 3.2.6 MDI (Interfaz de Múltiples Documentos) ...............................................39 3.2.7 Función de los diagramas de estados ......................................................41

iii

3.3 Consistencia.........................................................................................................42

3.3.1 Describiendo la consistencia ...................................................................42 3.3.2 ¿Cómo se trata la consistencia? ...............................................................43 3.3.3 Aplicando la consistencia en otras áreas de diseño .................................49 3.3.4 Impactos de la consistencia .....................................................................49 3.3.5 Ejemplo de Consistencia entre un Diagrama de Clases y Diagrama

de Estados................................................................................................50 3.4 Gramática de los Diagramas de Estados..............................................................52

3.4.1 El UML y su formalización.....................................................................52 3.4.2 Describiendo los diagramas de estados ..................................................53 3.4.3 La gramática Visual Relacional...............................................................54 3.4.4 Gramática visual de los diagramas de estados.........................................55 3.4.5 Gramática Relacional acotada para los Diagramas de Estados

manejados por Ke2 ..................................................................................59 3.4.6 Conclusiones de la gramática visual........................................................61

3.5 Referencias ..........................................................................................................62 Capitulo 4. Pruebas 4.1 Introducción.........................................................................................................64 4.2 Plan de Pruebas....................................................................................................64

4.2.1 Casos de prueba.......................................................................................64 4.2.2 Características a ser probadas..................................................................65 4.2.3 Criterio pasa / no-pasa de los casos de prueba ........................................65 4.2.4 Tareas de prueba......................................................................................65 4.2.5 Aprobación ..............................................................................................65

4.3 Procedimiento de pruebas ...................................................................................66

4.3.1 PKe2-1. Crear un Diagrama de Estados aislado......................................66 4.3.2 PKe2-2. Asociar un Diagrama de Estados aislado con una clase............66 4.3.3 Ke2-3. Seleccionar de toda la lista de clases una clase a asociar ............66 4.3.4 PKe2-4. Verificar la clase asociada o por asociar ...................................67 4.3.5 PKe2-5. Asociar la clase definida por asociar ........................................67 4.3.6 PKe2-6. Desasociar la clase asociada .....................................................67 4.3.7 PKe2-7. Generar un Diagrama de Estados consistente con una

clase de un Diagrama de Clases ..............................................67 4.3.8 PKe2-8. Generar multi-documentos del tipo de Diagramas de Estados .68 4.3.9 PKe2-9. Guardado y recuperación .........................................................68 4.3.10 PKe2-10. El cambio de nombre de una clase ........................................69 4.3.11 PKe2-11. El borrado de una clase .........................................................69 4.3.12 PKe2-12. El cambio de nombre de un atributo ....................................70 4.3.13 PKe2-13. El borrado de un atributo ......................................................70 4.3.14 PKe2-14. El cambio de nombre de un método .....................................71

iv

4.3.15 PKe2-15. El borrado de un método .......................................................72 4.4 Pruebas ...............................................................................................................73

4.4.1 PKe2-1. Crear un diagrama aislado.........................................................73 4.4.2 PKe2-2. Asociar un diagrama aislado con una clase ..............................74 4.4.3 PKe2-3. Seleccionar de toda la lista de clases una clase a asociar..........75 4.4.4 PKe2-4. Verificar la clase asociada o por asociar ...................................76 4.4.5 PKe2-5. Asociar la clase definida por Asociar .......................................77 4.4.6 PKe2-6. Desasociar la clase asociada .....................................................77 4.4.7 PKe2-7. Generar un Diagrama de Estados consistente con una clase

de un Diagrama de Clases .......................................................77 4.4.8 PKe2-8. Generar multi-documentos del tipo de Diagramas de Estados .80 4.4.9 PKe2-9. Guardado y recuperación .........................................................81 4.4.10 PKe2-10. El cambio de nombre de una clase ........................................81 4.4.11 PKe2-11. El borrado de una clase .........................................................84 4.4.12 PKe2-12. El cambio de nombre de un atributo ....................................85 4.4.13 PKe2-13. El borrado de un atributo ......................................................89 4.4.14 PKe2-14. El cambio de nombre de un método .....................................89 4.4.15 PKe2-15. El borrado de un método .......................................................90

Capitulo 5. Conclusiones 5.1 Análisis del resultado de las pruebas...................................................................92 5.2 Conclusiones........................................................................................................92 5.2.1 Beneficios Obtenidos........................................................................................93 5.2.2 Limitaciones .....................................................................................................94 5.3 Trabajos Futuros ..................................................................................................94 5.4 Publicaciones y Premios......................................................................................95 Anexo A.....................................................................................................................96

v

ÍNDICE DE FIGURAS Figura 1.1. Arquitectura de la Suite cenidet-UML....................................................2 Figura 2.1. Esquema del marco teórico .....................................................................13 Figura 2.2. Evolución de UML..................................................................................16 Figura 2.3. Diagramas para cada fase del diseño de sistemas OO. ...........................18 Figura 2.4. Elementos de un estado...........................................................................20 Figura 2.5. Subestados y transiciones entre subestados etiquetados .........................20 Figura 2.6. Bases de la Programación Orientada a Objetos ......................................23 Figura 2.7. Secuencias de los compiladores para el paradigma procedural y el OO.23 Figura 2.8. Estructura de clases del Patrón de Diseño Composite. ...........................25 Figura 3.1. Creación de Diagramas de UML.............................................................32 Figura 3.2. Creación de diagramas de estados y clases consistentes........................32 Figura 3.3. Diagrama de clases de InverSOODA......................................................33 Figura 3.4. Diagrama de clases de SOODA en el ambiente integrado de la

SCUML. ..................................................................................................34 Figura 3.5. Fragmento del diagrama de clases de la Figura 3.4 ..............................35 Figura 3.6. Diagrama de clases de Ke2 ....................................................................36 Figura 3.7. Mapa mental del patrón de diseño Strategy ...........................................37 Figura 3.8 Una aplicación MDI con dos tipos de documento ...................................40 Figura 3.9. Acciones sobre las que se implementa la consistencia. ..........................44 Figura 3.10. Proceso del borrado de una clase. .........................................................45 Figura 3.11. Cambio de nombre de una clase ...........................................................46 Figura 3.12. Borrado de un atributo/método ............................................................47 Figura 3.13. Planos de una casa.................................................................................49 Figura 3.14. Diagrama de estados de un Automóvil Automático ...........................51 Figura 3.15. Clase Automóvil_Automático...............................................................51 Figura 3.16. Gramática de los diagramas de estados.................................................58 Figura 3.17. Gramática acotada de los diagramas de estados ...................................60 Figura 4.1. Diagrama de estados generado de manera aislada .................................73 Figura 4.2. Parte del diagrama de clases de el ambiente de Lab3D que

contiene la clase TestTube.......................................................................74 Figura 4.3. Botón de asociar diagrama de estados con la clase definida del

diagrama de clases ..................................................................................74 Figura 4.4. Lista de clases posibles a asociar con el diagrama de estados

de la clase TestTube ...............................................................................75 Figura 4.5. Botón que muestra la lista de clases posibles a asociar .........................75 Figura 4.6. Botón de información de la asociación ...................................................76 Figura 4.7. Mensaje de la clase asociada...................................................................76 Figura 4.8. Mensaje de la clase por asociar...............................................................76 Figura 4.9. Botón de desasociar diagramas ...............................................................77 Figura 4.10. Parte del diagrama de clases de Lab3D.................................................78

vi

Figura 4.11. Selección de la clase TestTube para generar su diagrama de estados consistente..............................................................................78

Figura 4.12. Selección de un método del diagrama de clases para realizar

un modelado consistente, para una transición ......................................79 Figura 4.13. Selección de un método del diagrama de clases para realizar

un modelado consistente, para un estado..............................................79 Figura 4.14. Diagrama de estados creado de manera consistente con la clase

TestTube ...............................................................................................80 Figura 4.15. SCUML con multi- diagramas de estados para Lab3D .......................81 Figura 4.16. Cambio de nombre de la clase “TestTube” por “TestTubes” ...............82 Figura 4.17. Mensajes de las clases similares encontradas que pueden

sustituir a TestTube ..............................................................................82 Figura 4.18. Lista de clases a asociar ........................................................................83 Figura 4.19. Mensaje de inconsistencia y de aislamiento del diagrama de estados ..83 Figura 4.20. Diagrama de clases de Lab3D sin la clase TestTube ............................84 Figura 4.21. Sugerencia de la clase por la que puede ser asociado el diagrama de

estados ..................................................................................................84 Figura 4.22. Lista de clases por asociar cuando la clase TestTube ha sido borrada..85 Figura 4.23. Mensaje que indica que la clase por asociar es TestTube.....................85 Figura 4.24. Clase TestTube con el atributo epzilon.................................................85 Figura 4.25. Uso del atributo epzilon en el diagrama de estados ..............................86 Figura 4.26. Diagrama de estados con el uso del atributo epzilon ............................86 Figura 4.27. Cambio de nombre del atributo “epzilon” por “epsilon” ......................87 Figura 4.28. Mensaje de modificación de “epzilon” por “epsilon” en el

diagrama de estados..............................................................................87 Figura 4.29. Mensaje indicando si se desea eliminar el atributo...............................88 Figura 4.30. Diagrama de estados modificado eliminando el atributo no

encontrado “epsilon” para mantener la consistencia ............................88

vii

ÍNDICE DE TABLAS Tabla 1.1. Funciones de las herramientas que modelan con UML ..........................5 Tabla 2.1. Clasificación de los diagramas de UML .................................................18

viii

GLOSARIO DE ACRÓNIMOS

TERMINO SIGNIFICADO TRADUCCIÓN CASE Computer Aided Software Engineering Ingeniería de Software Asistida

por Computadora CORBA Command Object Request Broker

Architecture Arquitectura Común del Agente de Petición de Objetos

DDVi Diseño Detallado Visual GTDL Graphic Type Definition Language Lenguaje de Definición de Tipo

Grafico IBM International Business Machine Maquina de Negocios

Internacional IDL Interfaz Definition Language

Lenguaje de Definición de Interfaces

Ke2 Ambiente de Modelado de Diagramas de Estados

LV Lenguaje Visual MFC Microsoft Foundation Classes Clases de la Fundación de

Microsoft OCL Object Constraint Language Lenguaje de Restricción de

Objetos OMG Object Management Group Grupo de Administración de

Objetos OMT Object Modeling Technique

Técnica de Modelado de Objetos

OO Orientado a Objetos OOSE Object Oriented Software Enginerring

Ingeniería de Software Orientada a Objetos

POO Programación Orientada a Objetos PVS Prototype Verification System

Sistema de Verificación de Prototipos

RUP Rational Unified Process Proceso Unificado de Rational SCUML Suite cenidet-UML SDL Specification and Description Language Lenguaje de Descripción y

Especificación SOODA Sistema Orientado a Objetos de Diseño y

Análisis

UML Unified Modeling Language Lenguaje de Modelado Unificado

Documents

CAP 1 DE KE2 revisores - cenidet.edu.mx Alejandro... · Específicamente se propone un ambiente de modelado orientado a los diagramas de estados propuestos por el Lenguaje de Modelado