Citation preview
)i S.E.P. S.E.I.T. D.G.1.T
CENTRO NACIONAL DE INVESTIGACI~N Y DESARROLLO T E C N O L ~ G I C
O
cenídet AMBIENTE DE MODELADO Y DISENO DE SISTEMAS DE SOFTWARE
UTILIZANDO DIAGRAMAS DE SECUENCIAS
3 CUERNAVACA, MORELOS
T E S I S PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS
EN CIENCIAS DE LA COMPUTACIÓN
P R E S E N T A JOSÉ ALONSO MACíAS MONTOYA
Director de Tesis DR. MÁXIMO LÓPEZ SÁNCHEZ
”““I CE i\l I DET (,,,O DE INFORMACION
e - 0 4 - o s 1 %
AGOSTO 2004
M10 ANEXO No.11
Cuernavaca, Mor., a 25 de Agosto del 2004
Dr. Gerard0 Reyes Salgado Jefe del departamento de Ciencias
Computacionales Presente.
At'n: Dr. René Santaolaya Salgado. Presidente de la Academia
de Ciencias Computacionales
Nos es grato comunicarle, que conforme a los lineamientos para la
obtención del grado de Maestro en Ciencias de este Centro, y
después de haber sometido a revisión académica la tesis titulada:
Ambiente de modelado y diseño de sistemas de software utilizando
diagramas de secuencias, realizada por el C. José Alonso Macías
Montoya, y dirigida por el Dr. Máximo López Sánchez, y habiendo
realizado las correcciones que le fueron indicadas, acordamos
ACEPTAR el documento final de tesis, así mismo le solicitamos tenga
a bien extender el correspondiente oficio de autorización de
impresión,
Atentamente La Comisión de Revisión de Tesis
Revisor
. . ~ . . . .. >
1 Rosrama de k mramar da &-ma en C i e d i * del CWlDET
Wd6mlco. Rwisimsn<o Y P W l m l s n l o r
&zad6mlso.MminlsuIüy.I
4 r cenidet Centro Nacional de lnvestigaclon Sistema Nacional de
Institutos Tecnologicos y Desarrollo Tecnologico
ANEXO No. 12
M11 AUTORIZACI~N DE IMPRESI~N DE TESIS
Cueniavaca, Mor., a 27 de Agosto del 2004
C. José Alonso Macías Montoya Candidato al grado de Maestro en
Ciencias en Computación
i .. Presente.
Después de haber atendido las indicaciones sugeridas por la
Comisión Revisora de la Academia de Ciencias de la Computación en
relación a su trabajo de tesis cuyo titulo es: Ambiente de modelado
y diseño de sistemas de software utilizando diagramas de
secuencias, me es grato comunicarle que conforme a los lineamientos
establecidos para la obtención del grado de Maestro en Ciencias en
este centro se le concede la autorización para que proceda con la
impresión de su tesis.
i -:
Atentamente
C.C.P. Subdirección Académica Presidente de la Academia de Ciencias
Computacionales Departamento de Servicios Escolares
Expediente
- .
A mis padres, aún con la distancia Siempre han estado a mi lado. a
toda mi familia, por el apoyo en todo momento.
Agradecimientos:
A mis padres, por que me han dado todo
A toda nii familia por el apoyo que en su momento recibi de cada
uno.
AI Centro Nacional de Investigación y Dcsarrollo Tccnológico por la
oportunidad que me han dado.
A Cosnet (Consejo del Sistema Nacional de Educación Tecnológica)
por el apoyo económico otorgado durante la realización del programa
de maestría.
A la SEP (Secretaría de Educación Pública) por ser parte importante
con su apoyo económico para la culminación de mis estudios.
A mi director de tesis, Dr. Máximo López Sánchez, por compartirme
sus conocimientos y guiarme.
A mis revisores, Dr. René Santaolaya Salgado, Dr. Guillermo
Rodriguez Ortiz, y M.C. Humberto Hemández Garcia. Gracias por sus
observaciones y consejos para mejorar este trabajo.
A Miguel Ramirez por los conocimientos técnicos y amistad.
A Leo, Sele, Lupita, César, Emilio, Vianey, Armando y Marisela, por
el tiempo que vivimos!
3
i 4
Resu men
La investigación y el producto de la tesis están inmersos en la
etapa del diseño de sistemas de software.
El prototipo S3C (producto de la tesis) permite la obtención de
diagramas de secuencias de UML tomando como base la información de
un diagrama de clases y de varios documentos modelados con
diagramas de Warnier (diseño detallado de los métodos).
S3C realiza un proceso automático para la obtención de los
diagramas de secuencias, La construcción de los diagramas de
secuencias en S3C está soportada con una gramática visual
relacional. El propósito de la gramática es validar la construcción
de los diagramas de secuencias de UML.
En el ámbito de los diagramas de secuencias de UML, no existen
aplicaciones comerciales ó proyectos educativos que se apoyen en
una gramática visual para soportar la construcción de los diagramas
de secuencias, y tampoco existen aplicaciones que permitan a partir
de los diagramas de clases y del diseño detallado de los métodos,
generar automáticamente los diagramas de secuencias.
4 _.
Abstract
The research and the product of this thesis are immersed in the
phase of design of software systems.
Prototype S3C (product of this thesis) allows to obtain UML
sequence diagrams based on the information of a class diagram and
several documents modeled with wamier diagrams (detailed design of
the methods).
S3C makes an automatic process in order to obtain sequence
diagrams, the construction of sequence diagrams in S3C is supported
with a relational visual grammar. The purpose of the grammar is to
validate the construction of UML sequence diagrams.
il
In the scope of UML sequence diagrams, do not cxist commercial
applications or educative projects that are based on a visual
grammar to support the construction of sequence diagrams. Also
there aren’t applications that allow the automatic generation of
secuence diagrams from class diagrams and the detailed design of
methods.
Tabla de Contenido
Tabla de Contenido
Listado de Figuras
Listado de Tablas
1.4.1. Objetivos específicos de la tesis
1.5. Hipótesis de investigación
Capitulo 2. Marco Teórico
2.2. Interfaz de usuario (Mecanismos de interacción)
2.3. Lenguajes Visuales
2.5. Lenguaje de Modelado Unificado (UML)
Capitulo 3. Desarrollo de la herramienta
3.1. Diseño de la Arquitectura
3.1.1. Requisitos (Diagrama de Casos de uso)
3.1.2.Modelo Conceptual
21 23 23 25 25
1
3.2.2.Arquitectura Documento / Vista
3.2.3.Integrando Ambientes en Visual c++ 3.2.4. Interfaz de
Múltiples Documentos (MDI)
3.2.5.Recursos: Diálogos, Menus y Barras de Herramientas
3.2.6. Notación estándar
3.2.8.Patrones de diseño utilizados
3.3. Diagrama de secuencias
3.4. Elementos atómicos de la Gramática
3.4.1 .Representación visual
3.5. Gramática desarrollada
Tabla de Contenido
3.6. El proceso de creación automática de los Diagramas de
Secuencias
Capitulo 4. Pruebas y Resultados
4.1. Recursos técnicos utilizados
4.3. Resultados
Tabla de Contenido
Figura 2.1 -Programación Visual
Figura 3.1 -Modelo de Ingeniería Directa Automática de los
Diagramas de Secuencias Figura 3.2 -Diagrama de Casos de Uso para
el S3C
Figura 3.3 -Modelo Conceptual
Figura 3.4 - Diagrama de Clases -Control del Diagrama -
Figura 3.5 - Diagrama de Clases - Patrón Visitor - Figura 3.6
-Jerarquía de las principales clases de la arquitectura Documento /
Vista Figura 3.7 -Modelo: Interfaz de Múltiples Documentos
(MDI)
Figura 3.8 -Dialogo: Características del Objeto
Figura 3.9 -Dialogo: Mensaje
Figura 3. I O - Menú de los Diagramas de Secuencias
(estándar)
Figura 3. I 1 - Barra de Herramientas de los Diagramas de
Secuencias
Figura 3.12 - Vista de Clases del proyecto SCUML (división en
Carpetas)
Figura 3.13 - Serialización
Figura 3.14 -Modelo de cascada del ciclo de vida del software
Figura 4.1 - Resultado del caso de prueba 1
Figura 4.2 -Resultado del caso de prueba 2
Figura 4.3 -Resultado del caso de prueba 3
Figura 4.4 -Resultado del caso de prueba 4
Página
3
13
22
23
25
26
26
29
30
31
32
32
32
34
35
37
45
Tabla 4.1 - Resumen de los resultados de las pruebas
realizadas
Listado de Tablas
V
Notación
La siguiente es la notación de la que se hará uso:
<CObject>
<GetDocunteizt>
Línea o Bloque de código
Elemento del Diagrama de Secuencia
vi
I Introducción
L~ tesis se enfoca hacia el desarrollo de sistemas de software
centrados en el modelado mediante diagramas de secuencias definidos
por el Lenguaje de Modelado Unificado (UML). La investigación y el
producto de la tesis están inmersos en la etapa del diseño de
sistemas de software.
El producto (prototipo) de la tesis denominado S3C permite la
obtención de diagramas de secuencias de UML tomando como base la
información de un diagrama de clases y de varios documentos
modelados con diagramas de Wamier (diseño detallado de los
métodos).
Para la elaboración de los diagramas de clases se hace uso del
ambiente existente InverSOODA [HER,03]. Y para el modelado de los
documentos Wamier se ha tomado el ambiente InverDDVi [WEN,02].
Ambos ambientes visuales son productos de tesis anteriores y se han
integrado en un solo prototipo denominado SCUML (Suite cenidet -
UML).
(i
S3C realiza un proceso automático para la obtención de los
diagramas de secuencias, en este proceso solo se requiere indicar
el diagrama de clases del que se basará. La construcción de los
diagramas de secuencias en S3C está soportada con una gramática
visual relacional. El propósito de la gramática es validar la
construcción de los diagramas de secuencias de UML.
En el ámbito de los diagramas de secuencias de UML, no existen
aplicaciones comerciales ó proyectos educativos que se apoyen en
una gramática visual para soportar la construcción de los diagramas
de secuencias, y tampoco existen aplicaciones que permitan a partir
de los diagramas de clases y del diseño detallado de los métodos,
generar automáticamente los diagramas de secuencias.
3
Los temas relacionados a esta tesis son: Modelado de Sistemas, UML,
Interfaz de Usuario, Programación Orientada a Objetos y Gramáticas
Visuales.
El capítulo 1 es de conceptos generales, se dan a conocer los
antecedentes del proyecto, los trabajos relacionados, hipótesis,
alcances y limitaciones.
En el capítulo 2 se define el marco teórico de la tesis, se
describen temas como: Modelado de sistemas de software, diseño de
sistemas de software, modelado visual, lenguajes visuales,
programación orientada a objetos y lenguaje de modelado
unificado.
El capítulo 3 describe el desarrollo del ambiente visual, se
detalla el modelo conceptual, la arquitectura y sus elementos, los
diagramas de secuencias y la gramática visual relacional que se
desarrolló.
En el capítulo 4 se muestran los casos de pruebas y los resultados
obtenidos. Y al final se establecen las conclusiones, y se dan
propuestas para algunos trabajos futuros. 3
1
Capítulo I
Conceptos generalis
En éste capítulo se dan a conocer los antecedentes del proyecto de
tesis, los trabajos relacionados, el problema que resolverá, la
hipótesis a comprobar, los alcances y limitaciones.
Conceptos generales
1.1. Antecedentes
Actualmente en el cenidet (Centro Nacional de Investigación y
Desarrollo Tecnológico), se trabaja en la construcción de un
conjunto de ambientes visuales para dar soporte al desarrollo con
diagramas que define el estándar UML para elaborar sistemas de
software de manera completa, rápida y eficaz. El ambiente de
modelado principal se ha denominado "suite cenidet-UML" y su
arquitectura general se muestra a continuación en la Figura
1.1.
Arquitectura de la suite cenidet-UML
Figura 1.1 Arquitectura de la suite cenidet-UML
a? El producto de software resultante de ésta tesis lleva por
nombre: S3C, y como se .. indica en la figura 1.1. Las tesis
directamente relacionadas son: InverSOODA [HER,03] e
InverDDVi [WEN,02].
InverSOODA (Sistema Orientado a Objetos para Diseño y Análisis,
incluyendo Ingeniería Inversa) es un Ambiente Visual que permite la
elaboración de diagramas de clases de un sistema de software. Los
diagramas de clases son una vista estática, y en ella se describe
las relaciones que existen entre las entidades llamadas 'clases'.
Cada una de las clases se divide en tres partes: nombre de la
clase, métodos y atributos. Este ambiente permite generar el código
fuente en lenguaje C++ de un diagrama construido y también
aplicando la ingeniería inversa es posible obtener un diagrama a
partir de un código en C++ existente.
InverDDVi (Diseño Detallado Visual, incluyendo Ingeniería Inversa)
es un Ambiente Visual cuyo objetivo es apoyar en la elaboración de
diagramas de diseño detallado, utilizando una notación basada en
Warnier. Los diagramas de Warnier sirven para describir una
secuencia lógica de acciones, y mediante su simbología se logra
plasmar: definiciones de métodos, llamadas a otros métodos, ciclos,
comparaciones, lectura de información y escritura de información.
Este ambiente permite generar el código fuente en C de un diagrama
construido y también aplicando la ingeniería inversa se puede
obtener un diagrama de Warnier a partir de un código en C que ya
exista.
i ."
3
Rational Rose de Rafional
Una de las herramientas mas populares del mercado que utiliza la
notación UML y tiene la capacidad de reingeniería de software para
integrar sistemas existentes, capacidad de mezclar diferentes
lenguajes dentro de un mismo modelo, además de ingeniería inversa
sobre los componentes COM (Component Object Model), ActiveX y Java;
y con soporte de las arquitecturas MicrosoWCOM y CORBA/IDL (The
Common Object Request Broker Architecture).
Con Rational Rose se puede trabajar en grupo, con capacidades para
modelar y visualizar procesos de negocios y requerimientos de
sistemas. Tiene soporte para generar esquemas objetos-relaciones de
bases de datos para realizar análisis de datos. Cuenta con el
soporte para analizar sitios Web en ASP (Active Server Pages) y JSP
(Java Server Pages). Además soporta los lenguajes: Java, C/C++,
Visual C/C++. [RAT,02]. 9
SI ..-
Visio de Microsoft
Visio Enterprise 2002 permite crear diferentes tipos de diagramas,
como son:
1. Diagramas de flujo 2. Planos de oficinas 3. Diagramas de árbol
4. Diagramas de organización 5 . Líneas de tiempo 6 . Mapas
geográficos y direccionales 7. Diagramas de sitios Web 8. Diagramas
de red 9. Diagramas de UML
Tiene las siguientes características: diagramación e importación de
servicios de directorio, reingenieria de bases de datos, diseño y
documentación de bases de datos, diagramación de software,
ingeniería directa e inversa de código, replicación exacta por
medio de diagramas de equipos y configuraciones de red,
diagramación automatizada y ambiente colaborativo.
Visio da un conjunto completo de herramientas de diagramación de
redes para planear y documentar claramente las redes existentes.
Además, para crear esquemas eléctricos, mecánicos y de procesos;
pueden crearse diagramas complejos con facilidad y poco
entrenamiento.
A las aplicaciones existentes se les puede realizar la ingeniería
inversa para obtener el diseño, y también crear nuevos diseños.
Proporciona herramientas para crear diagramas de bases de datos, y
es posible realizar ingeniería inversa de esquemas existentes en
bases de datos cliente /servidor como: SQL Server, IBM, Oracle, y
otros. [MIC,02]. ?:
4
? e JVision 2.1 de Object Insight
JVision permite en la ingeniería directa la creación de clases,
variables y métodos, con lo cual genera plantillas de código para
programadores en Java. Los diagramas se pueden exportar a HTML. La
documentación puede integrarse con JavaDoc de Sun. JVision da el
soporte para ingeniería inversa, para el lenguaje Java.
Se pueden crear todos los diagramas definidos por UML, en los
diagramas de secuencias da la oportunidad de dibujar clases,
líneas, líneas de tiempo de vida y marca de destrucción de objetos,
ofrece además el soporte para las acciones de: llamada, regresar
valor, enviar acción, crear acción, y eliminar acción.
[OBJ,O2].
MagicDraw 6 de No Magic
Es una herramienta CASE con soporte para trabajo en grupo. Esta
diseñado para analistas 6 de negocios, analistas de software,
programadores, ingenieros de calidad y
documentadores. Esta aplicación provee la capacidad para crear los
diagramas definidos por UML (soporta UML 1.4). Cuenta con el
soporte de ingeniería inversa y generación de código para C++, C#,
Java y CORBNIDL. Tiene integración con NetBeans; se actualiza
automáticamente, disponible en: árabe, portugués, francés,
italiano, ingles (US), alemán, español, japonés y coreano.
Tiene la característica de soportar la adaptación de los elementos
a colores que el usuario defina. Los diagramas pueden exportarse a
imágenes JPG, EMF, WMF, EPS y DXF. En los diagramas de secuencia da
oportunidad de definir roles, textos, notas, mensajes de varios
tipos: al mismo objeto, recursivo; además de la relación a las
notas, y las líneas de vida. Es posible guardar los diagramas como
imágenes de mapas de bits, o vectores. Mantiene además una vista
pequeña a escala del diagrama completo. [NoA4,02].
e *:
SmariDraw Professional Plus de SmariDraw
Todos los dibujos pueden agregarse en las aplicaciones de
Microsoft, como son: Word, Excel, PowerPoint. Contiene más de
50,000 (1,000 en la versión estándar) formas predefinidas, ejemplos
y plantillas. Los diagramas pueden ser exportados a imágenes WMF,
BMP, JPG, GIF, TIF, y otros. Incluye un convertidor de archivos de
VISIO.
Con esta herramienta es posible crear diagramas de flujo, diagramas
de bloque, diagramas de flujos de datos, diagramas de organización,
árboles de decisión, diseño de redes, Gantt, diagramas de flujo de
procesos, diagramas de administración de calidad, diagramas
eléctricos, diagramas mecánicos, diagramas químicos, líneas de
tiempo planes de espacio, posters, mapas, formas, y también da
soporte para UML, es posible dibujar objetos, actores, activación
de los objetos, mensaje, mensaje de retorno, mensaje asíncrono,
mensaje con tiempo, línea de vida del objeto, marca de destrucción
del objeto, y ciclos (descrito con un rectángulo y una condición de
salida) [SMA,02].
5
Creación automática de diagramas de
El Rational Rose El Visio
Jvision
a a El Fl El a El El
I ~
I ~
I -
Ambiente de modelado de
a a SmartDraw El
Tabla I.! Tabla comparativa
Todas las herramientas descritas anteriormente cuentan con
características sobresalientes para el diseño y modelado de
sistemas de software, pero ninguna de ellas genera automáticamente
los diagramas de secuencia con base en los diagramas de clases y el
diseño detallado de los métodos, así también, ninguna de ellas
realiza un cálculo de los canales de comunicación abiertos entre
las clases que conforman el sistema.
¡a la A UML Editor in Java
1.3. Definición del problema
El modelado de sistemas utilizando el estándar de UML en diversos
productos comerciales, prototipos de laboratorio elaborados en
universidades y centros de investigación, atienden la perspectiva
básica de la abstracción general del modelo, esto es, documentar el
modelo del sistema que se requiere; sin atender puntos importantes
tales como:
La generación automática de los diagramas de secuencias La
corrección de inconsistencias en los diagramas al crearlos de forma
separada.
El
6
Conceptos generales
Se hace necesaria la creación de un ambiente visual que permita
obtener de forma automática los diagramas de secuencias en base a
los diagramas de clases y al diseño detallado de los métodos para
facilitar la documentación, la generación de código y el
mantenimiento de los sistemas.
La obtención de los diagramas de secuencias está basada en los
Diagramas de Clases definidos por UML que son construidos con la
herramienta InverSOODA; junto con el diseño detallado de los
métodos construidos con Diagramas de Wamier elaborados con la
herramienta InverDDVi.
En el estándar UML para la construcción de los diagramas, no existe
actualmente una sintaxis explícita definida, solo existe
implícitamente en el uso de los elementos del diagrama; por lo que
se ha descrito una gramática visual de tipo relaciona1 como soporte
para la construcción de los Diagramas de Secuencias.
n ai 1.4. Objetivo de la Tesis
Construir un ambiente visual que permita al usuario obtener el
diagrama de secuencias de manera automática.
1.4.1. Objetivos específicos de la tesis Crear una gramática que
soporte la construcción del diagrama de secuencias. Construir de
forma automática el diagrama de secuencias con base en el diagrama
de clases y el diseño detallado de los métodos.
1.5. Hipótesis de investigación
Es posible construir automáticamente diagramas de secuencias con
base en el diagrama de clases y el diseño detallado de los
métodos.
1.6. Alcances y limitaciones del trabajo de tesis
Los alcances de la tesis se especifican a continuación:
Se elaboró la arquitectura del sistema. Se definió la gramática de
soporte. Se desarrolló la interfaz en Visual C++ haciendo uso de
las MFC. Se interactúa con los diagramas de clases de InverSOODA.
Se interachía con el diseño detallado de los métodos realizados por
InverDDVI. Se genera el diagrama de secuencias de forma
automática..
7
0 No se genera código
La investigación se limita a los diagramas de clases para la vista
estática de los sistemas de software y a los diagramas de Warnier
para la vista dinámica de los métodos. El ambiente no trabaja en
red
No se modifican los archivos de InverSOODA No se modifican los
archivos de InverDDVI No se recuperan diagramas de secuencias a
partir de código legado.
4
8
Capítulo 2
Narc0 teórico
En éste capítulo se describen los temas usados para el desarrollo
de la tesis. ¿Que son los modelos?, ¿En que parte del proceso de
Ingeniería del Software se usan los modelos o el modelado?. Se
estudia la interfaz de usuario, los lenguajes visuales, y las
gramáticas visuales. Se describe el Lenguaje de Modelado Unificado
(UML), además de la programación orientada a objetos por ser este
paradigma en donde se enfoca este trabajo.
Marco teórico
2.1. Modelado de sistemas de software
un modelo es una abstracción de algo con el propósito de entenderlo
antes de construirlo. El modelo omite detalles no esenciales,
haciendo más fácil su manipulación que la entidad original
[BLA,98]. Un modelo es la simplificación de la realidad [RUM,99].
Los propósitos de los modelos son:
. Probar una entidad fisica antes de construirla Establecer mejor
comunicación con los clientes Visualizar el problema y el sistema
desde una mejor perspectiva Reducir la complejidad. [BLA,98]
Capturar y precisar requerimientos, y conocimiento del dominio
Pensar acerca del diseño del sistema Capturar decisiones de diseño
en una fomia separada, que cambia a partir de los requerimientos
Generar productos Organizar, buscar, filtrar, obtener, examinar y
editar información acerca de un sistema Explorar múltiples
soluciones económicas Manejar sistemas complejos. [RUM,99]
El modelado es una probada y bien aceptada técnica de Ingeniería de
Software [RUM,99]. El modelado es parte central de todas las
actividades que conducen a la producción de buen software. Se
construyen modelos para comunicar la estructura deseada y revisar
el comportamiento de nuestro sistema. Se construyen modelos para
visualizar y controlar la arquitectura del sistema. Se construyen
modelos para comprender mejor el sistema que estamos construyendo,
muchas veces descubriendo oportunidades para la simplificación y la
reutilización. Se construyen modelos para controlar el riesgo
[BOO,99]. La razón fundamental por la que modelamos es porque
nosotros construimos modelos que nos ayudan a entender mejor el
sistema que estamos desa'rrollando [RUM,99].
El modelado nos permite [RUM,99]: 1. Visualizar como es el sistema,
o como queremos que sea. 2. Especificar la estructura del sistema
3. Plantear nuestras guías en la construcción del'sistema 4.
Documentar las decisiones que hemos tomado
En las etapas del desarrollo del software, el modelado es usado en
el diseño, el diseño del sistema es la primera etapa en donde se da
la aproximación básica de la solución al problema seleccionado;
además, se decide por la estructura (arquitectura del sistema) y el
estilo de la solución.
La arquitectura del sistema provee el contexto sobre el cual se
tomarán decisiones mas detalladas en las etapas subsecuentes del
diseño [BLA,98]. En el diseño modelamos el sistema y encontramos su
forma (incluida la arquitehra) para que soporte todos los 3 -
10
requisitos -incluyendo los requisitos no funcionales y otras
restricciones- que se le suponen [JAC,99]. Los propósitos del
diseño son:
Adquirir una comprensión en profundidad de los aspectos
relacionados con 10s requisitos no funcionales y restricciones
relacionadas con los lenguajes de programación, componentes
reutilizables, sistemas operativos, tecnologías de distribución y
concurrencia, tecnologías de interfaz de usuario, tecnologías de
gestión de transacciones, etc. Crear una entrada apropiada y un
punto de partida para actividades de implementación subsiguientes,
capturando los requisitos o subsistemas individuales, interfaces y
clases. Ser capaces de descomponer los trabajos de implementación
en partes mas manejables, que puedan ser llevadas a cabo por
diferentes equipos de desarrollo, teniendo en cuenta la posible
concurrencia. Capturar las interfaces entre los subsistemas. Esto
ayuda cuando reflexionamos sobre la arquitectura y cuando
utilizamos interfaces como elementos de sincronización entre
diferentes equipos de desarrollo. Ser capaces de visualizar y
reflexionar sobre el diseño utilizando una notación común. Crear
una abstracción independiente de la implementación del sistema, en
el sentido de que la implementación es un refinamiento directo del
diseño que rellena lo existente sin cambiar la estructura. Esto
permite la utilización de tecnologías como la generación de código
y la ingeniería de ida y vuelta entre el diseño y la implementación
[JAC,99].
2.2. Interfaz de usuario (Mecanismos de interacción)
El crecimiento de las computadoras personales vendidas en los ~ O ’
S , lanzó con fuerza el “fácil de usar” como una de las
características mas importante de un producto de computadora.
Las interfaces gráficas de usuario no son nuevas, se pueden
encontrar en las paredes de cuevas al sur de Francia, en las
pirámides de Egipto y en las paredes de muchas ciudades [iUM,92].
Para el usuario de un sistema interactivo la comunicación es tan
importante como la computación. Para los usuarios, regularmente la
interfaz es el sistema [HIX,93].
Diseño de Interfaz: Según Hackos [HAC,98], las interfaces están en
todo donde se trabaja con:
o Controles en productos de hardware o Etiquetas y señales en el
hardware o Pequeñas pantallas de cristal liquido en máquinas de
cualquier tipo o Pantallas para aplicaciones de software para
terminales de computadoras centrales
Marco teórico
o pantallas para aplicaciones de software en computadoras
Personales sistemas operativos como: Windows, OS/2. DOS. Macintosh.
U n b Y Otros.
0 Páginas de un sitio WEB 0 Sistemas de ayuda y manuales en-línea 0
Tutoriales incrustados y otros tipos de soporte de funcionamiento O
Esquemas de formas y otros documentos
una interfaz es el medio con el cual los usuarios interactúan con
el producto 0
sistema para lograr SUS objetivos.
Interfaz Usable:
Para que una interfaz sea usable, debe ser transparente, y darles a
los usuarios la capacidad de lograr cumplir sus metas de forma
efectiva y eficiente.
Los beneficios presentados en el uso de las interfaces de usuario
[TH1,90]: Disfrutar el sistema. El usuario disfruta trabajar con un
sistema que cuenta con una interfaz bien diseñada y que le da la
funcionalidad y acceso a los recursos de una manera clara y
sencilla. Proporciona nuevas habilidades. Elimina al usuario
concentrarse en acciones que la propia interfaz y el sistema hacen,
dando como resultado que el usuario solo se concentre en lo
importante del trabajo. Delegación de tareas. La interfaz de
usuario permite al usuario no conocer los detalles de la tarea;
esto es, la computadora atiende los detalles de las tareas,
mientras que el usuario se concentra en asuntos de más alto nivel.
Seguridad. El usuario no necesita estar en lugares'peligrosos para
hacer su trabajo.
Se da la mayor posibilidad para que el usuario tenga acceso al
conocimiento utilizando un sistema interactivo. Haciendo las cosas
a la primera. Las tareas se ejecutan en un orden correcto definido,
lo que da como resultado un trabajo bien terminado sin necesidad de
repetir, evitando así altos costos. Computando. LOS usuarios pueden
calcular datos sin necesidad de conocer el proceso para obtener los
resultados.
Desarrollo.
El diseño de interfaz es un negocio bastante dificil. Éste combina
dos complicadas disciplinas: psicología y ciencias de la
computación. Estas disciplinas tienen un fondo cultural muy.
diferente: la psicología atiende a la gente (comprensión y
entendimiento); las ciencias computacionales a las máquinas
(matemáticas y precisión). El diseño de las buenas interfaces
requiere que estas dos perspectivas estén unidas [THi,90].
Hackos dice que las interfaces dan simplicidad y elegancia al
trabajo necesario, y a la vida e los usuarios. Si no es obvio al
usuario, pero es rápida para aprender [HAC,98], además define
características comunes de las interfaces usables:
o Hacen que el flujo de trabajo sea familiar o confortable o
Soportan el estilo de aprendizaje de los usuarios
12
Visualización de Entrenamiento visual Para controlar Soportar
interaccioncs Programar con información visual visuales expresiones
visuales
o Compatibles con los ambientes de trabajo de los usuarios o Se
extienden sobre un concepto de diseño que es familiar al usuario o
Tienen consistencia de presentación que los hace parecer más
confiable y fáciles de
aprender. o Usan lenguaje y figuras familiares al usuario o fáciles
de aprender.
Datos o información acerca de datos
2.3. Lenguajes Visuales
Los lenguajes visuales son un nuevo paradigma para expresar los
sistemas computacionales. Ellos ofrecen la posibilidad de manipular
directamente los objetos. Un lenguaje visual consiste de sentencias
visuales. Para lenguajes visuales basados en íconos, cada sentencia
visual es un arreglo espacial de objetos O íconos gráficos
[CHA.90].
Un lenguaje visual es concebido como una colección de figuras
obtenidas por un arreglo gráfico de objetos en dos o más
dimensiones. Los lenguajes visuales pueden ser modelados
sintácticamente a través de un vocabulario, ,un conjunto de
relaciones usadas para componer las figuras y un conjunto de reglas
describiendo las figuras pertenecientes al lenguaje. Los objetos
gráficos de un vocabulario de un lenguaje visual se caracterizan
por contar con un conjunto de atributos. Los atributos de un objeto
gráfico pueden ser: atributos gráficos, atributos sintácticos y
atributos semánticos [MAR,98].
Un lenguaje de programación visual puede ser informalmente definido
como un lenguaje el cual usa algunas representaciones visuales
[SHV,88].
Programa ylo Diseño de Lenguajes de programación visual ejecución
software Diagramas iconos Formas
Programación Visual [SHU,88]
Gramáticas para la especificación de lenguajes visuales
[MAR,98]:
a) Gramáticas texfuales generalizadas. Este tipo de gramática
provee una adaptación apropiada de la concatenación de símbolos
para dos dimensiones. Su principal ventaja es que conservan los
elementos teóricos de las gramáticas textuales y los eficientes
algoritmos de análisis de éstos últimos. Su principal desventaja es
que éstas gramáticas no son tan poderosas y sólo pueden especificar
clases restringidas de lenguajes visuales.
13
Marco teorico
b) Métodos basados en gramáticas de grafos. Un ejemplo de este tiPo
de gramáticas son las gramáticas de red. Las oraciones generadas
con gramáticas de red son grafos dirigidos con símbolos en los
nodos. Estos grafos son llamados redes. Una producción de éste tipo
de gramáticas es de la siguiente forma:
a - t p E
donde a y p son redes y E es una forma de conectar a p cuando a es
conectada a otra red anfitriona.
La mayor desventaja, es que las gramáticas de red no han probado
ser totalmente útiles para la especificación de gramáticas
arbitrarias, por la complejidad para rescribir grafos y al hecho de
que no todo lenguaje visual está compuesto exclusivamente por
grafos.
C) Gramáticas de multiconjuntos de atributos. En estas gramáticas,
las producciones rescriben conjuntos o multiconjuntos de símbolos
que tienen atributos con información sobre geometría o semántica.
La reescritura se controla con restricciones sobre los atributos de
los símbolos en el lado derecho de las producciones.
Un ejemplo de éstas gramáticas es la Gramática Coordinada, que
especifica notación matemática de dos dimensiones. En esencia, las
producciones en una gramática coordinada n-coordinada libre del
contexto tienen la siguiente forma:
A -t a donde C F '
Todos los símbolos de éste tipo de gramática tienen n atributos
geométricos, A es un símbolo no terminal, a es una cadena no vacía
de símbolos, C es una restricción sobre los atributos de los
símbolos en a, y F es una expresión que computa los atributos de
los símbolos de A en términos de los atributos de los símbolos en
a, no importando el orden de los símbolos en a.
d) Gramáticas PosicionaZes. Las gramáticas posicionales son un
formalismo para la definición e implementación de lenguajes
visuales, las gramáticas posicionales extienden naturalmente a las
gramáticas libres de contexto. Una gramática libre de contexto
posicional PG es una six-tupla (N, T, S, P, POS, PE) donde:
N es un conjunto finito no vacío de símbolos no terminales T es un
conjunto finito no vacío e símbolos terminales, con N n T = $I S E
N es el símbolo no terminal de inicio P es un conjunto finito de
producciones POS es un conjunto finito de identificadores de
relación binaria PE es un evaluador pictórico
14
Cada producción en P tiene la siguiente forma:
A -+ X I R I X* R2 ... X ~ . I Rm.1 xm, A
e) Gramáticas de Relación de símbolos. Éste es un formalismo
sintáctico para describir un lenguaje visual, donde cada oración
dentro del lenguaje se representa como un conjunto de objetos
visuales y un conjunto de relaciones entre objetos.
El alfabeto de símbolos Vt y el conjunto de relaciones entre
símbolos Vr, una oración de relación de símbolos w sobre Vt y Vr es
un par ( M, R) donde:
M es un conjunto de elementos-s (v, i) con v E Vt y i es un número
natural. R es un conjunto de elementos-r de la forma r (Xi, Yj) con
Xi, Yj E M, r E Vr y una relación r esta contenida entre Xi y
Yj
Una gramática de relación de simbolos es el conjunto de seis
elementos G = (Vn, Vt, Vr, S, P, R) donde: Vn es un conjunto de
símbolos no terminales; Vt es un conjunto de símbolos terminales;
Vr es un conjunto de relaciones entre símbolos; S es el símbolo
inicial y P es un conjunto de reglas de reescritura (producciones
de elementos-s)
f) Gramáticas relacionales. Este tipo de gramática pertenecen a las
gramáticas libres de contexto.
La gramática relaciona1 (RG’s) es una 6-tupla G (N, C, S, R, Attr,
P) donde:
N: C: S: R: Attr: P:
es un conjunto finito de símbolos no terminales es un conjunto de
símbolos terminales. es un símbolo distinguido en N llamado símbolo
inicial. es un conjunto finito de símbolos de relación. es un
conjunto finito de símbolos de atributos. es un conjunto de
producciones de la forma A-> a/p/F, donde: A E N , . a E (nlo)+
Donde n E N, cr E E;
8: Es un conjunto de relaciones de la forma (r x y) donde r E R y
x,y son enteros que hacen referencia a un miembro de a y también
una expresión de la forma (a i) donde a E Attr e i es un entero que
hace referencia a un miembrode a.
F: Es un conjunto de declaraciones de asignación de características
de la forma (a O)=x donde a E Attr y x es un entero que hace
referencia a un miembro de a o a una expresión de la forma (a
i).
15
2.4. Programación orientada a objetos
L~~ métodos orientados a objetos organizan la información Y el
procesamiento que manipula esta información, de acuerdo a los
objetos del’mundo real que la información describe [BRO,97l.
Beneficios de las técnicas orientadas a objetos [BR0,97]:
Estabilidad del sistema Mantenibilidad Componentes reusables
Confiabilidad Accesibilidad de los datos Participación del
usuario
Según Graddy Booch la programación orientada a objetos es: “un
método de implementación en el que los programas se organizan como
colecciones cooperativas de objetos, cada uno de los cuales
representan una instancia de alguna clase, y cuyas clases son todas
miembros de una jerarquía de clases unidas mediante relaciones de
herencia” [JOY, 981.
Programación orientada a objetos esencialmente significa
programación usando objetos [JAC,93]. Los lenguajes orientados a
objetos deben soportar los siguientes conceptos:
Objetos Abstracción de datos Encapsulamiento Clases e Instancias
Herencia entre clases Polimorfismo
Las propiedades fundamentales de la Programación Orientada a
Objetos son:
a. Abstracción. Son ideas, conceptos y propiedades que se describen
en forma general, eliminando los detalles. Es una estructura de
datos y los métodos que manipulan a esos datos.
b. Encapsulamiento. Son las fronteras propias de un objeto bien
definidas, las cuales protegen los detalles de su representación
interna.
c. Ocultación de la información. Es la propiedad en la que los
objetos pueden hacer uso para impedir que otros objetos, los
usuarios, o incluso los programadores conozcan cómo está
distribuida la información.
d. Herencia. Es la propiedad que tiene una .clase para heredar
atributos y comportamiento, a otras clases.
e. Polirnorfismo. Es la propiedad que permite que una entidad pueda
cambiar a diferentes formas, efectuándose de manera dinámica en
tiempo de ejecución.
16
t!
Clases. Es la especificación de una familia de objetos, es la
declaración de un tipo de objetos. También se dice que una clase es
la descripción de un conjunto de objetos con un comportamiento
similar y que esta compuesta de: Datos (o atributos) y Métodos o
(rutinas, acciones, operaciones).
Objeto. Un objeto es una entidad en la cual se almacenan datos y
los métodos o funciones que controlan dichos datos. Un objeto es
una abstracción de alguna cosa del mundo real, que contiene datos
que lo describen y operaciones que solo tienen acceso a esos datos
[BR0,97l. Los elementos de los que esta conformado un objeto,
son:
a. Las relaciones permiten que el objeto se integre en la
organización. b. Las propiedades son los datos que caracterizan el
estado de un objeto, distinguiendo
así, a un objeto determinado de los restantes que forman parte de
la misma organización.
c. Los métodos son las operaciones que pueden realizarse sobre la
estructura del objeto, es decir, las acciones que cambian el estado
de un objeto y, que el objeto es capaz de ejecutar a través de
mensajes y que también pone a disposición de sus descendientes a
través de la herencia.
Mensajes. Son solicitudes para que se lleve a cabo la operación
indicada y se produzca un resultado.
Las razones principales para introducir la tecnología de objetos,
son los beneficios de dicha tecnología:
Aumento de la fiabilidad Aumento de la productividad del
desarrollador. Desarrollo más rápido Mejor calidad más alta
Incremento en escalabilidad Mejores estructuras de información
Incremento de adaptabilidad Reducción del código fuente
Mantenimiento más fácil y reducción de costo
Los elementos de reutilización son las clases y objetos.
2.5. Lenguaje de Modelado Unificado (UML)
UML (Unified Modeling Language por sus siglas en inglés, Lenguaje
de Modelado Unificado) es un lenguaje de modelado visual de
propósito general que es utilizado para especificar, visualizar,
construir y documentar las partes de un sistema de software. El
lenguaje está basado en un pequeño número de conceptos centrales
que la mayoría de los desarrolladores de tecnología orientada a
objetos pueden aprender y aplicar fácilmente. [RUM,99].
17
y UML: Pasado, Presente y Futuro
L~~ lenguajes de modelado orientado a objetos aparecieron a
mediados de 10s 70’s. Varias técnicas influenciaron estos
lenguajes. El número de lenguajes de modelado incrementó desde
menos de 10 hasta más de 50 entre 1989 y 1994. Muchos modeladores
tenían problemas para encontrar un lenguaje de modelado que
satisficiera todas sus necesidades. Notablemente apareció Booch’93,
y la evolución continuó a OMT, y Fusión.
OOSE (Object-Oriented Software Engineering) está enfocado a la
ingeniería de negocios y análisis de requerimientos dando un
excelente soporte orientado a casos de uso. OMT-2 es especialmente
expresivo para análisis y sistemas de información de datos grandes.
Booch’93 fue particularmente expresivo para el diseño y fases de
construcción de proyectos y popular para aplicaciones de ingeniería
intensiva.
Grady Booch y Jim Rumbaugh iniciaron el desarrollo de UML en 1994
al unificar sus métodos independientes Booch y OMT. En 1995 Ivar
Jacobson se unió a Racional, ésta unión logró que el método OOSE se
incorporara. La unificación estableció que debían activar el
modelado de sistemas utilizando conceptos orientados a objeto, así
como crear un lenguaje usable tanto para las máquinas como para los
humanos.
A .:
Muchas organizaciones se unieron al consorcio UML y dedicaron
recursos al trabajo hacia el fortalecimiento de la definición de
UML. Esta colaboración produjo un lenguaje de modelado expresivo,
poderoso y generalmente aplicable. En la forma actual de UML se
espera que sea base de muchas herramientas, incluidas las de
modelado visual, simulación y ambientes de desarrollo.
R. UML es abierto y no-propietario, y aunque define un lenguaje
preciso, no es barrera para futuras mejoras en conceptos de
modelado. Se usan muchas técnicas de punta, pero se esperan
técnicas adicionales que influencien futuras versiones de UML,
puede ser extendido sin redefinir el núcleo.
c
Mientras el rehúso basado en componentes se ha favorecido
ampliamente cada vez mas, esto no significa que las técnicas
basadas en componentes reemplazarán las técnicas orientadas a
objetos. Hay solo sutiles diferencias entre la semántica de
componentes y clases. [ALC,03]
Un opaco rendimiento caracterizó el mercado de análisis, modelado y
diseño en el 2000 en su transición de las viejas herramientas CASE
(Computer Aided Software Engineering) a algo más dinámico y mejor
adaptado para satisfacer las necesidades de los desarrolladores
para el cambio rápido en los ambientes de negocio.
El mercado de análisis, modelado y diseño logrará obtener un
crecimiento positivo en varios de los siguientes años por varias
razones. El mercado será manejado principalmente por la necesidad
de desarrolladores a obtener aplicaciones para .lanzarse al mercado
rápidamente, así también por el interés creciente y uso de una
nueva especie de herramienta y por el interés creciente de los
desarrolladores en usar UML, reglas de negocios y adaptadores de
componentes para construir aplicaciones. [RIK,UI]
z -
18
Marco teórico
UML se ha hecho el estándar para los desarrollos de modelado de
negocios, administración de requerimientos, análisis y diseño,
programación y pruebas. Los objetivos primarios de UML en el diseño
[RAT,97j:
o Dar a los usuarios un lenguaje visual expresivo de modelado listo
para usarse, para que puedan desarrollar y cambiar los significados
de sus modelos.
o Suministrar mecanismos de extensibilidad y especialización para
extender los conceptos centrales.
o Ser independiente de lenguajes de programación particulares y
procesos de desarrollo.
o Impulsar el desarrollo de las herramientas Orientadas a Objeto en
el mercado. o Soportar conceptos de desarrollo de alto nivel como
colaboración, marcos de
componentes reutilizables, patrones y componentes. o Integrar las
mejores prácticas
9 El ámbito de UML
UML es un lenguaje para especificación, construcción,
visualización, y documentación de artefactos de un sistema de
software. UML es la fusión de los conceptos de Booch, OMT y OOSE.
El resultado es un simple, común y ampliamente usado lenguaje de
modelado para usuarios de estos y otros métodos. UML se enfoca en
un lenguaje de modelado estándar, no en un proceso estándar; los
autores de UML recomiendan un proceso de desarrollo manejado por
casos de uso, de arquitectura central, iterativo e incremental.
[i¿4T,97l.
Para la definición de sistemas de software en UML se definen
diagramas. Un diagrama es la representación gráfica de un conjunto
de elementos, este se visualiza la mayoría de las veces como un
grafo conexo de nodos (elementos) y arcos (relaciones). Los
diagramas se dibujan para visualizar un sistema desde diferentes
perspectivas, de forma que un diagrama es la proyección de un
sistema. üML incluye nueve diagramas [B00,99] .
4 -
I . Diagrama de clases 2. Diagrama de objetos 3. Diagrama de casos
de uso 4. Diagrama de secuencias 5 . Diagrama de colaboración 6 .
Diagrama de estados 7. Diagrama de actividades 8. Diagrama de
componentes 9. Diagrama de despliegue
Diagramas de secuencias: Un diagrama de secuencias es un diagrama
de interacción que describe cómo los grupos de objetos colaboran en
algún comportamiento.
Un diagrama de secuencias muestra un conjunto de mensajes
acomodados en una secuencia de tiempo; éste diagrama muestra la
interacción en un esquema de dos - dimensiones [RUM,99].
19
Y -
Un diagrama de secuencia es un diagrama de interacción que resalta
la ordenación temporal de los mensajes. Un diagrama de secuencia
presenta un conjunto de objetos y los mensajes enviados y recibidos
por ellos. Los objetos suelen ser instancias (con nombre o sin
nombres) de clases, pero también pueden representar instancias de
otros elementos, tales como colaboraciones, componentes y nodos.
Los diagramas de secuencia se utilizan para describir la vista
dinámica de un sistema [B00,99].
Usar los diagramas de secuencia es mostrar la secuencia que existe
en un caso de uso [RUM, 991.
Los diagramas de secuencia tienen dos dimensiones: Una dimensión
que representa el tiempo Otra dimensión que representa los
diferentes objetos que participan en la secuencia de eventos
requeridos para completar el propósito [MOü,98].
El principal uso de los diagramas de secuencia de la notación UML
es en el modelo de especificaciones, donde se requieren las
interacciones de los objetos; y en el modelo de implementación,
donde se diseña las interacciones de los objetos [DAN,02].
20
DesawoCCo de Ia herramienta
En este capítulo se describe el desarrollo del Ambiente Visual. Se
describe el modelo conceptual del sistema, la arquitectura, así
como también los elementos que componen la Arquitectura. Se
estudian los Diagramas de Secuencias de UML y algunos Patrones de
Diseño de los que se hace uso para el mejor desarrollo del sistema.
Se describe a detalle la Gramática Visual Relaciona1 utilizada para
el de Ambiente de desarrollo.
"""I CENIOET 1F;NTRO DE INFORMACION
Desarrollo de la herramienta
t i i
Actualmente existe en el cenidet un Ambiente Visual de Modelado de
Clases llamado InverSOODA; este Ambiente Visual tiene la capacidad
de realizar la generación automática de código de las clases en C++
a partir del modelo especificado. Además, se puede realizar la
Ingenieria Inversa de un código legado para obtener el modelo de
clases. Aunado a este trabajo existe el Ambiente Visual denominado
InverDDVi, con el cual se puede realizar el Diseño Detallado de los
Métodos de las Clases con diagramas de Warnier. Así también es
posible obtener el modelo aplicando la Ingeniería Inversa a un
código legado en C++.
Ambos trabajos son retomados en este proyecto para la
automatización en la obtención de los Diagramas de Secuencias de
UML. La figura 3.1 muestra el modelo propuesto de ingeniería
directa.
Extraer información del diagrama de
,’ ,’
.................................................................
I
Figura 3.1. Modelo de Ingenieria Directa Autombtica de los
Diagramas de Secuencias
Para la construcción automática de un diagrama de secuencias se
toma como base a un diagrama de Clases. El modulo “Extraer
información del diagrama de Clases” sirve para obtener el nombre y
los métodos descritos en cada uno de las clases que existan en el
diagrama de Clases.
22
Desarrollo de la herramienta
Con base en la información que se tiene se abren los archivos
correspondientes a los diagramas de Warnier. El proceso que se
emplea sobre cada uno los diagramas de Warnier llamado “Extraer
información de los diseños detallados de los métodos” sirve para
recopilar el conjunto de las llamadas de cada método
definido.
En el siguiente paso (“Reconocer llamadas a métodos”) consiste en
identificar si los métodos que están descritos en los diagramas de
Warnier también lo están en el diagrama de Clases
correspondiente.
El paso: “Construir los diagramas de secuencias automáticamente”
realiza una validación de los métodos definidos en los diagramas de
Clases con los métodos definidos en los diagramas de Warnier. Este
paso crea una estructura de datos con la secuencia de las llamadas
y la recorre para crear los objetos y los mensajes en el diagrama
de secuencias.
AI terminar la creación automática del diagrama de secuencias se
dispone de la r\ .. opción de guardar.
3.1. Diseño de la Arquitectura
Para definir los procesos que el sistema va a realizar, es
necesario llevar a cabo un análisis de requisitos, los cuales
pueden ser expresados mediante diagramas de Casos de Uso. Los Casos
de Uso son una descripción textual narrativa de los procesos de un
sistema.
3.1.1.Requisitos (Diagrama de Casos de uso)
Los casos de uso en realidad no son un artefacto de análisis
orientado a objetos, estos describen simplemente procesos y pueden
ser igualmente efectivos en un proyecto tecnológico no orientado a
objetos. Son usados en un paso preliminar a la descripción de
requerimientos de un sistema [LAR,971. La Figura 3.2 muestra el
diagrama de casos de uso que especifica al S3C.
9
Figura 3.2. Diagrama de Casos de Uso para el S3C
23
Descripción de los Casos de Uso
Caso de Uso: “Diagramas de Secuencias”. Se inicia cuando el actor
“usuario” solicita la creación de un Diagrama de Secuencias. Se
establece la forma de la construcción automática de los diagramas
de secuencias de UML. Se hace uso del Modelado de Clases y del
Modelado del diseño detallado de los métodos.
Escenario de Éxito 1. Se obtiene la información de las clases del
modelado de clases 2. Se obtiene la información del modelado del
diseño detallado de los métodos 3. Se realiza la construcción
automática de los diagramas de secuencias
1. En el modelo de clases no hay información o está incompleta 2.
En el modelo del diseño detallado de los métodos no hay información
o está
incompleta
Escenario de Falla
Caso de Uso: “Modelado de Clases”. El diagrama de Clases se utiliza
para obtener los nombres de clases y los nombres de los métodos de
cada clase.
Escenario de Éxito 1. Se abre el modelo 2. Se procesa para obtener
la información de las clases (nombres de clases y nombres
de métodos)
Escenano de Falla h 1. No se puede abrir el modelo J 2. El modelo
esta vacío
Caso de Uso: “Modelado del Diseño detallado 1 los métodos”. El
diseño detallado de los métodos se realiza con diagramas de
Warnier, aquí se establecen las llamadas a funciones dentro del
sistema, y es aquí donde se identifica el dinamismo que se
representará en los diagramas de secuencias.
Escenario de Éxito 1. Se abre el modelo 2. Se realiza la
identificación de las llamadas existentes
Escenario de Falla 1. No se puede abrir el modelo 2. El modelo esta
vacío
24
i ,
Mensaje
Tipo
En el Análisis Orientado a Objetos se crea una especificacióii del
dominio del problema y de los requeriinientos, desde la perspectiva
de una clasificación por objetos y del entendimiento de los
términos usados en el dominio del problema. Una descomposición del
dominio del problema involucra una identificación de conceptos,
atributos y asociaciones que son considerados importantes dentro
del dominio. El resultado puede ser expresado en un Modelo
Corzcepttraf, el cual es ilustrado en un conjunto de diagramas que
definen conceptos (objetos) [LAR,97].
3.1.2.Modelo Conceptual
El modelo conceptual visto en la Figura 3.3, no es una descripción
de componentes de software, representa conceptos en el domino del
problema en el mundo Teal [LAR,97l.
3.1.3.Diagramas de clases
Por cuestiones dc espacio, las clases de la arquitectura del
sistema estarán referidas en varios diagramas, que de alguna manera
están relacionados entre si.
Una de las partes más importantes del Ambiente Visual S3C es la
estructura de clases <CCraJico>, la cual se refiere al
control de los diagramas, ésta por su naturaleza podría
considerarse el núcleo del sistema. La manipulación y control de
los diagramas está definido en una estructura de clases organizada
con el patrón de diseño Composite que se muestra en la Figura
3.4.
25
n 3.2. Elementos de la arquitectura
Es necesario describir los elementos que dan soporte a la
arquitectura del ambiente donde se implementará el sistema, en este
caso Microsoft Visual (MV) C++ 6. El MV C++ es un marco de
aplicación poderoso basado en Windows, se integran además del
lenguaje C++ (compilador y enlazador), el programa de desarrollo de
programas en lenguaje C para Windows (SDK), la Microsoft Foundation
Class Library, AppWizzard, Classwizard, AppStudio y
WorkBencli.
La Microsoft Foundation Class Library comprende una biblioteca de
clases de C++ y es considerada como el núcleo del MV C++.
3.2.1.Microsoft Foundation Class (MFC)
La librería Microsoft Foundation Class (MFC) es una interfaz
orientada a objetos que tiene las siguientes metas de diseño:
o
Reducción significante de esfuerzo al escribir una aplicación para
Windows. Velocidad de ejecución comparable a las API’s del lenguaje
C. Mínimo tamaño de código. Capacidad para llamar cualquier función
de Windows en C directamente. Fácil conversión de aplicaciones
existentes en C a C++. Fácil uso de API’s de Windows con C++ como
con C. Fácil uso de complicadas características de abstracciones
poderosas como ActiveX, soporte para base de datos, impresión,
barras de herramientas, y barras de estado. El API de Windows en
C++ si: usa tan efectivamente como las características mismas del
lenguaje C++.
La mayoría de las clases de la Librería de la Microsoft Foundation
Class son derivadas de una clase base <CObject> que es la
raíz de la jerarquía de clases. <CObject> da útiles
capacidades a las clases que derivan de ella.
La jerarquía que existe en las clases derivadas de <CObject>
es la siguiente:
Arquitectura de Aplicación Excepciones Servicios de Archivos
Arreglos Listas Mapas Servicios de Internet Sockets Sincronización
Soporte para base de datos D A 0
27
i
?. r
Línea de Comandos Menú Dibujo Gráfico Dibujo Gráfico de Objetos
Soporte de Control Soporte de Ventanas
Soporte para base de datos ODBC
o Marco de Ventanas o Barras de control o Hojas de propiedades o
Cajas de Dialogo o Vistas o Controles
3.2.2.Arquitectura Documento / Vista
Por defecto las aplicaciones creadas con la MFC usan un modelo de
aplicación que separa los datos del programa de las vistas de
interacción con el usuario. En éste modelo un objeto documento de
MFC lee y escribe datos en un almacenamiento persistente. Un objeto
vista administra el despliegue de datos, suministrando al usuario
los datos para ser seleccionados o editados. La vista le comunica
al documento cualquier cambio en los datos. La razón más
conveniente para seguir este modelo es cuando se necesita múltiples
vistas del mismo documento (como en una hoja de cálculo y un
gráfico)
La arquitectura documento/vista hace fácil el soporte de múltiples
vistas y múltiples tipos de documentos, así como la división de
ventanas, y otras características de interfaz de usuario. Pero, el
corazón de la arquitectura son cuatro clases (Mostradas en el árbol
de clases de la Figura 3.6):
<CDocumerrt> (o <COleDocuinent>) - Se instancia un
objeto de este tipo para almacenar y controlar los datos del
programa. <CView> (o una de sus clases derivadas
<CScrotlView>, <CFormView>, <CEditView?
<CRecordView>, <CDaoRecordView, <CtreeView>,
<CListView> b <CrichEditView>) - Un objeto es usado
para desplegar los datos y administrar la interacción del usuario
con los datos. <CFrameWnd> (o una de sus variantes) -
Establece el marco sobre el que trabajarán una o mas vistas de un
documento. <CDocTemolate> (o <CSingIeDocTemplate> o
<CMultiDocTemplate>) - Coordina la existencia de uno o más
documentos de un tipo dado y administra la correcta creación de los
documentos, vistas y objetos ventanas para cada tipo.
i
28
3.2.3.Integrando Ambientes en Visual C t t
Las aplicaciones de Interfaz de Documento Único (SDI) soporta
múltiples tipos de documentos, pero, este soporte es para un solo
objeto documento. Debido a esta restricción y aunado a la necesidad
de tener varios objetos documentos a la vez, se determina la
utilización del modelo Interfaz de Múltiples Documentos (MDI),
indicado en la Figura 3.7.
3.2.4.Interfaz de Múltiples Documentos (MDI)
Una aplicación de Interfaz de Múltiples Documento (MDI) permite la
creación de plantillas para el manejo de los documentos, ésta
plantilla tiene la forma:
rn-pDocTemplate = new CMultiDocTernplate ( I DR-SCUMLTY PE,
RUNTIME-CLASS (CSCUMLDoc), RUNTIME-CLASS (CChildFrarne),
RUNTIME-CLASS (CTheView));
AddDocTernplate ( rn-pDocTemplate ):
Cada plantilla describe una relacion del tipo de documento con la
vista asociada. La definición de la plantilla para el ambiente que
controla los diagramas de secuencias es la siguiente:
29
AddDocTernplate( rn-pTernplateSeqDiag ):
Esta plantilla hace uso de la clase CCliildFrame que por defecto el
ambiente Visual C++ construye, y esto es debido a que no se
requieren características extras en las ventanas de las que
proporciona dicha clasc. En un caso en el que se requiriera un
comportamiento diferente de la vista tendría que crearse una nueva
clase con las características deseadas.
Vista Documento
L Figura 3.7. Modelo: Interfaz de Múltiples Documentos (MDI)
Para integrar otro Ambiente que utilice otro tipo de documento es
necesario definir otra plantilla de la misma forma mencionada. Debe
tomarse en cuenta los siguientes puntos:
-
Desarrollo de la herramienta
En la última línea referente a RUNTIME-CLASS se debe indicar la
clase <CView> que desea usar. Para finalizar se usa la
instrucción AddDocTernplate para finalizar la definición del
template (mgTemplateNOMBRE).
3.2.5. Recursos: Diálogos, Mertús y Barras de Herrattriertias
Son varios los recursos con los que se puede contar al crear un
proyecto en Microsoft Visual C++. Los diálogos son un recurso
disponible que son utilizados para visualizar, ingresar y/o
modificar información que se requiera. En el Ambiente Visual que se
desarrolla son varios los diálogos que se utilizarán, y éstos se
describen a continuación:
El Diálogo “Características del Obieto” (Figura 3.8) identifica el
nombre del Objeto y la descripción del mismo. Este diálogo se
muestra cuando se presiona doble clic sobre un objeto del
diagrama.
....................................................................................................................................................
: I Nombre
Figura 3.8. Dialogo: Características del Objeto
El Diálogo “Mensaie” (Figura 3.9) muestra el nombre del mensaje que
puede ser modificado, además se visualizan el Identificador del
Mensaje, el tipo de Mensaje, así también el origen y destino del
mensaje.
31
' /Edit Objeto Origen:
Objeto Destino: IEdit '
....................................... i25El
...................... A ................. Figura 3.9. Dialogo:
Mensaje
El menú es otro de los recursos del que se puede disponer para
organizar el ambiente que se está creando. Para éste caso en
particular no se hizo modificaciones al menú estándar (Figura 3.10)
que Visual C++ presenta. Los cambios significativos son el manejo
del tipo de documento para los Diagramas de Secuencias.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . Archivo Editar Yer VenLana AyGda
Figura 3.10. Menú de los Diagramas de Secuencias (estándar)
. .
Figura 3.11. Barra de Herramientas de los Diagramas de
Secuencias
Es recomendable que al utilizar barras de herramienta personalizada
se defina en el tamaño estándar, ya que puede experimentar
problemas al momento de ejecutar la aplicación.
Además puede usar la propiedad TBBS-CHECKGROUP en una barra de
herramientas para establecer que los botones puedan quedar
presionados hasta que un botón diferente sea presionado. No olvide
que la numeración inicia con cero ( O ) .
vuriableToolBur.SetButtonStyle(O,TBBSCHECKGROUP);
32
3.2.6. Notación estándar
Los nombres descriptivos de los recursos se asocian a un valor
único. Para una mayor claridad éstos nombres mantienen un prefijo
que describe el tipo de recurso asociado (vea la Tabla 3.1)
[MIC,99].
Tipo de Recurso Comandos de Menú Controles y recursos Cuadros de
diálogo Cadenas de solicitud para cuadros de mensaje Menú
principal, barras de herramienta, tabla aceleradora y el icono
Cadenas
IDR / IDD IDC ID
200 - 299 3000 - 3999 34000 - 34999
Estos son los rangos de valores establecidos para el proyecto S3C.
Si se utiliza el código fuente y se planea agregar otro proyecto
verifisue que no se invadan estos números para evitar
problemas.
Para facilitar aún más los trabajos futuros, se ha definido una
estructura de carpetas (ver Figura 3.12) para incluir en cada una
las Clases correspondientes a cada tesis en desarrollo.
33
ill ~~ -
,-I SCUML classes +, U A N T L R .+, U App .+, 0 ClassDiagrams +, 0
Common + a Java
t. $2 SequenceDiagiams
. . ~ . .. ~
Figura 3.12. Vista de Clases del proyecto SCUML (división en
Carpetas)
3.2.7.Estructura de datos, persistencia y recuperación
Existe una gran cantidad de tipos de datos, estructuras, clases y
métodos de los que se puede hacer uso para una mejor y más fácil
obtención de los resultados. A continuación hago comentarios en
tipos de datos y métodos en los que podría tener problemas.
CTypedPtrList
AI usar este tipo de dato, o alguno relacionado que le permita
utilizar el método <CTvr>edPtrList::GetNext> tenga
especial precaución al usarlo, ya que al devolver el valor
requerido la variable POSITION usada no se queda apuntando a ese
valor en particular, salta al inmediato siguiente de la
lista.:
Si se realiza una creación dinámica con punteros para los elementos
de una CTypedPtrList. Después de haberlo agregado a la lista evite
el "delete" para borrar, esta Usted deseando liberar la memoria?,
no lo haga!!!, ya que eliminara directamente el elemento de la
lista.
POSITION
Es un valor usado para denotar una posición de un elemento en una
colección. Pero CUIDADO!, no se refiere a un índice, es una
referencia (no consecutiva) de punteros muy diferente a un
índice.
CString
Aún cuando el operador de comparación "==" (igual a) es permitido
para ser utilizado en las cadenas evite su uso, ya que en
ocasiones, aunque cuando la e
34
Desarrollo de la herramienta
compilación no indique error alguno, en la ejecución no realizará
lo que se necesita. Recomiendo que utilice CString.Compare ()
Para eliminar el contenido de un CString utilice CString.Empty(),
ya que asignar a la cadena un “\n” podría causarle problemas.
Serialización
Una forma en que se puede guardar información y recuperarla de
manera eficaz, es mediante la serialización de objetos. La
serialización es un proceso que permite escribir un objeto en un
archivo, y también leerlo.
Para que la serialización se lleve a cabo son necesarios tres
objetos: un objeto de tipo <CFile> que represente el archivo,
un objeto de tipo <CArchive> que ofrece el entorno para la
serialización y la clase del objeto a ser serializado debe ser
heredada de <CObject> y sobrescribir el método
<Serialize> para que se encuentre de tal forma en que pueda
ser serializado (vea la Figura 3.13).
Objeto a ser serializado 1
1 CArchive
[f. --=I- ---7 Archivo.exi
:u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . Figura 3.13.
Serialización
3.2.8.Patrones de diseño utilizados
Se ha planteado la definición de una arquitectura de clases
utilizando patrones de diseño, debido a que algunos de ellos hacen
más fácil la extensión de la funcionalidad y mantenimiento.
35
Desarrollo de la herramienta
El patrón Composite es utilizado para crear de manera uniforme el
diagrama sobre el que se trabaja (ver Figura 3.4), manteniendo una
jerarquía de clases uniforme, las clases más bajas en la jerarquía
definen primitivas de objetos gráficos.
Se aplica el patrón de diseño Iterator, para hacer recorridos en
listas de objetos para realizar diversas operaciones. Otro patrón
de diseño del que se hace uso, es el Visilor (ver Figura
3.5).
Para otras actividades que se realizan podría pensarse en que se
deberían aplicar otros patrones, pero se han evitado algunos (como
el patrón de diseño Builder) para evitar incrementar la complejidad
en la arquitectura, ya que ai mantener el modelo de la MFC de
documento/vista, la funcionalidad del patrón de diseño Builder es
fácilmente reemplazado, si se hiciera Uso de éste, se aumentaría la
complejidad excesivamente (nos llevaría a perdemos en ocasiones en
el paso de mensajes entre clases), dañando la facilidad de la
arquitectura.
3.3. Diagrama de secuencias
Un Diagrama de Secuencias es un diagrama de interacción que
describe cómo los grupos de objetos colaboran en algún escenario Ó
comportamiento, se usan para definir el curso lógico de acción de
un posible camino a seguir en la resolución de un problema. Según
John Daniels [DAN,O2], “el principal uso de los diagramas de
secuencia de la notación UML es en el modelo de especificaciones,
donde se requieren las interacciones de los objetos; y en el modelo
de implementación donde se diseñan las interacciones de los
objetos”.
Los Diagramas de Secuencias se utilizan en el modelado de la
implementación de sistemas de software, además, son aplicables en
el modelado de requisitos para establecer las comunicaciones
existentes entre actores y/o clases del sistema. Con éstos
diagramas se logran hacer descripciones de los escenarios y los
comportamientos del sistema. Con los Diagramas de Secuencias es
posible definir protocolos de comunicación con paso de mensajes, ya
que dan esa flexibilidad que se requiere. Además, los Diagramas de
Secuencias contienen información suficiente para que puedan ser
transformados a los diagramas de colaboración [RUM, Ol][BOO,
Oil.
3.3.1.Ciclo de vida del software
Considerando cualquier modelo de ciclo de vida del software (en la
figura 3.14 se muestra el Modelo de cascada), el ámbito directo de
éste Ambiente Visual es en el diseño, aunque tiene sus vertientes
en la codificación y mantenimiento.
36
I I I I Mantenimiento I
igura 3.14. Modelo de cascada del ciclo de vida del software
3.4. Elementos atómicos de la Gramática
Definición de los elementos atómicos del lenguaje y su
contenido
1. Actor.- Representa roles de entidad externos al sistema con el
que interactúa directamente. Los actores pueden ser humanos,
dispositivos u otros sistemas.
2. Clase/Objeto.- Determina una Clase u Objeto participante en la
interacción.
3. Mensaje.-Es una comunicación entre objetos que contiene
información. Éste se representa con la finalidad a que una acción
sea llevada a cabo.
4. Mensaje con tiempo.- Tiene la misma finalidad que el mensaje, la
diferencia es que con él se representa un atributo de tiempo.
5 . Mensaje asíncrono, Es un mensaje que ocurre en el tiempo de
manera independiente a otros mensajes.
6. Mensaje de destrucción de objeto.- Es un mensaje cuya finalidad
es indicar la destrucción del objeto destino.
7. Mensaje de creación de objeto.- Es un mensaje que indica la
creación de un objeto .
8. Llamada al mismo objeto (Recursividad).- Es usado para modelar
llamadas recursivas en el que una operación es invocada por el
mismo objeto.
37
9. Destrucción del objeto (AutodestrucciÓn).- Puede o no modelarse;
es representada con una X al final de la línea de vida del
objeto.
Elementos aulomáticos
1 . Línea de Vida.- Representa la vida del objeto durante la
interacción.
2. Activación.- Muestra el período de tiempo en el cual el objeto
alguna operación.
3.4.1.RepresentaciÓn visual
Actor
, ,. _- A,
Mensaje
numero)' letra:= A..Z I a..z numero := 0..9
I
Recursividad ~
I
Conector de Comentario
3.5. Gramática desarrollada
La gramática que se propone es una gramática visual del tipo
relacional. Una gramática relacional pertenece a las gramáticas
libres de contexto, es una 6-iupla G (N, C S, R, Attr, P)
donde:
N: es un conjunto finito de símbolos no terminales. C: 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.
Entonces, definiendo nuestra gramática G (N, C, S, R, Attr,
P)
N = {Diagrama, GrupoClaseObjeto}
R
Definiendo la posición de los atributos en los elementos
visuales:
entradacrea Ob,etaClase
(salida 1) (entrada 2) ) (salida 2) (entrada 1) )
- Diagrama 0 ' GrupoClaseObjeto
(mensaje (mensaje (mensajeRetomo (mensajeRetomo (mensajeTiempo
(mensajeTiempo (mensajeAsincrono (mensajeAsincrono (mensajecrea
(mensajeDestruye (mensajeDestruye (autodestrucción
(recursividad
(salida 1) (entrada 2) ) (salida 2) (entrada 1) ) (salida 1)
(entrada 2) ) (salida 2) (entrada 1) ) (salida I ) (entrada 2) )
(salida 2) (entrada 1) ) (salida 1) (entrada 2) ) (salida 2)
(entrada 1) ) (salida 1) (entradacrea 2) ) (salida 1) (entrada 2) )
(salida 2) (entrada 1) ) (salida 1) (entrada 1) ) (salida 1)
(entrada 1) )
entrada
salida
40
GrupoClaseObjeto - 1 1 I 2 (mensaje (mensaje (mensajeRetorno
(mensajeRetorno (mensajeTiempo (mensajeTiempo (mensajeAsincrono
(mensajeAsincrono (mensajecrea (mensajeDestruye (mensajeDestruye
(autodestrucción (recursividad
(salida I ) (entrada 2) ) (salida 2) (entrada I ) ) (salida 1)
(entrada 2) ) (salida 2) (entrada I ) ) (salida I ) (entrada 2) )
(salida 2) (entrada 1) ) (salida 1) (entrada 2) ) (salida 2)
(entrada I ) ) (salida 1) (entradacrea 2) ) (salida I ) (entrada 2)
) (salida 2) (entrada I ) ) (salida 1) (entrada 1) ) (salida I )
(entrada I ) )
1 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 a un Actor seguida de un GrupoClaseObjeto, el Actor inicia
la interacción con un mensaje y recibe el mensaje de retorno al
finalizar la interacción. La segunda y tercera producción son
similares debido a que un GrupoClaseObjeto contiene dos
Clase/Objeto que se relacionan de la misma forma.
Existe un elemento de la gramática llamado Attr (Atributo) el cual
define la parte de los elementos visuales donde se establecen las
relaciones. Se han determinado dos atributos (entrada y salida),
que para nuestro propósito estarán establecidos en la línea de vida
de cada elemento visual (Actor y Clase/Objeto).
Los Comentarios y la Activación no se consideran en la gramática.
Los comentarios son libres de incluirse y relacionarse con
cualquier elemento y relación mencionada anteriormente; y la
activación existe siempre que se presente un mensaje (o podría
omitirse). Estas consideraciones se realizaron para hacer aún más
fácil la gramática, ya que si se trata de realizar un sistema, las
restricciones de estos elementos pueden mantenerse en el lenguaje
de programación en el que se desarrolle el sistema.
3.6.
Precondiciones
El proceso de creación automática de los Diagramas de
Secuencias
1. El diagrama de Clases debe existir y estar completo 2. Debe
existir un archivo con un diagrama de Warnier por cada diagrama de
Clases, y
con el mismo nombre de archivo (excepto la extensión del archivo).
3. En el único diagrama de Warnier de cada Clase se deben modelar
todos los métodos
de la Clase. 4. No realizar declaraciones de métodos
41
Desarrollo de la herramienta
5. Debe existir un método ‘main()’ en el diagrama de Clases
Restricciones
Los métodos deben mantener nombres distintos en las diferentes
Clases.
Metodología para la obtención automática de los Diagramas de
Secuencias
1. Seleccionar el diagrama de Clases.
2. Se construye una lista con los nombres de las Clases y los
Métodos.
3. Se verifica si exista el método ‘main()’ en alguna Clase. Se
busca la existencia de una única Clase.
a. La Clase que contenga ‘main()’ se va al inicio de la lista de
Clases
b. Si no existe ‘main()’ SE TERMINA EL PROCESO
4. Se verifica la existencia de los archivos que contienen el
Diseño Detallado de los métodos en Wamier para cada una de las
Clases, si alguno falta, SE TERMINA EL PROCESO
5. Se procesa cada uno de los modelos del Diseño Detallado de los
Métodos generando una lista de secuencias de llamadas por cada uno
de los métodos.
6 . Se verifica que cada llamada corresponda a algún método
existente (del diagrama de Clases). De no existir ese método la
llamada entra a una estructura que
7. Se crea una lista de secuencia
a. Se inicia con ‘main()’ b. Se recorre cada una de las llamadas de
los métodos c. Se considera inválido el caso de que un método
intente una llamada
recursiva al método ‘main()’.
8. Se muestra un diálogo de resultados en el que se indican las
llamadas que no se encnotraron definidas y que pueden ser: Llamada
a librería ó Llamada Errónea.
42
Prue6as y @su6taáos
En éste capítulo se da a conocer el detalle de las pruebas y de los
resultados obtenidos. Se describen los casos de prueba con los que
se realizó la evaluación del sistema, así también se presentan
comentarios acerca de los resultados obtenidos.
Pruebas y Resultados
4.1. Recursos técnicos utilizados
Para llevar a cabo las pruebas al sistema S3C, se utilizaron los
siguientes equipos de Cómputo:
Computadora de escritorio. *
AMD Athlon XP 1600+ I.4Ghz
Computadora de escritorio. Intel Pentium 4 - 128MB RAM Disco Duro
40G Monitor 15” i .-
4.2. Descripción del plan de pruebas
Las pruebas establecen el Último paso desde donde es posible
evaluar la calidad y descubrir los errores. Las pruebas y la
validación del software se utilizan para comprobar que el sistema
cumple con las expectativas del usuario.
En esta sección se describen los casos de prueba que se realizaron
al prototipo de S3C en conjunto a la suite cenidet-UML. Para cada
uno de los casos se presenta: el objetivo, el procedimiento que se
siguió para la prueba y se muestran los resultados obtenidos. -
._
Las pruebas a realizar son los siguientes:
Caso 1. Mostrar la funcionalidad del Sistema S3C a partir de un
diagrama de Clases existente.
Caso 2. Mostrar la funcionalidad del Sistema S3C a partir de un
Diagrama de Clases que se
construye al momento y los diagramas de Wamier.
Caso3. Mostrar que S3C no realiza la construcción del Diagrama de
Secuencias si falta alguno
de los diagramas de Wamier.
Caso4. Mostrar que S3C no realiza la construcción del Diagrama de
secuencias si hace falta el
método “main 0”. 5
IZ .=/
Objetivo Mostrar la funcionalidad del Sistema S3C a partir de un
diagrama de Clases existente
Procedimiento I . Seleccionar “Nuevo Proyecto SCUML“. 2.
Seleccionar “Diagrama de Clases”. 3. En el cuadro de diálogo:
“Abrir Archivo Existente”. Seleccionar la opción “Si” 4.
Seleccionar el archivo “VENTAS” en el cuadro de diálogo “Abrir”. 5.
Seleccionar la ventana “SCUMLI”. 6. Seleccionar “Diagrama de
Secuencias”. 7. Seleccionar la ventana S3C para visualizar el
diagrama que se ha construido
automáticamente.
Resultado En la figura 4.1 se muestra la pantalla del diagrama de
secuencia construido
automáticamente.
45
Pruebas y Resultados
4.3.2. Caso 2
Objetivo Mostrar la funcionalidad del Sistema S3C a partir de un
Diagrama de Clases que se
construye al momento, y los diagramas de Warnier (almacenwar,
caja.war, vendedor.war) que ya cxisten (del caso de prueba I )
.
Procedimiento I . Seleccionar “Nuevo Proyecto SCUML“. 2.
Seleccionar “Diagrama de Clases”. 3. En el cuadro de diálogo:
“Abrir Archivo Existente”. Seleccionar la opción “No” 4. Agregar
las siguientes Clases, con los respectivos métodos y
atributos.
a. Clase:“vendedor”, Métodos: “venta, main” b. Clase:“almacen”,
Métodos: “entrada, salida” c. Clase:“caja”, Métodos:
“ventagrod”
5 . Seleccionar la ventana “SCUMLI”. 6. Seleccionar “Diagrama de
Secuencias”. 7. Seleccionar la ventana S3C para visualizar el
diagrama que se ha construido
automáticamente.
Resultado En la figura 4.2 se muestra la pantalla del diagrama de
secuencia construido
automáticamente.
MOIDOC Anivo
venta prod
I 4 vc”lD~o1cn. venta prod >
salida 6 . . i Figura 4.2. Resultado del caso de prueba 2
46
4.3.3. Caso 3
Objetivo Mostrar que S3C no realiza la construcción del Diagrama de
Secuencias si falta alguno
de los diagramas de Warnier.
Procedimiento I . Seleccionar “Nuevo Proyecto SCUML“. 2.
Seleccionar “Diagrama de Clases”. 3. Seleccionar la opción “Si” en
el cuadro de diálogo: “Abrir Archivo Existente”. 4. Seleccionar el
archivo “CLASES2” en el cuadro de diálogo “Abrir”. 5. Seleccionar
la ventana “SCUMLI”. 6. Seleccionar “Diagrama de Secuencias”. 7.
Seleccionar la ventana S3C para visualizar lo que se ha
construido.
Resultado En la figura 4.3 se muestra la pantalla del diagrama de
secuencia construido
automáticamente.
5
Aceptar i .................................
Faltan Archivos de Diseños Detallados de Métodos 1 1 A No se puede
crear el diagrama de secuencias
Figura 4.3. Resultado del caso de prueba 3
47
Pruebas y Resultados
4.3.4. Caso 4
Objetivo Mostrar que S3C no realiza la construcción del Diagrama de
secuencias si hace falta el
método “main 0”.
Procedimiento I . Seleccionar “Nuevo Proyecto SCUML“. 2.
Seleccionar “Diagrama de Clases”. 3. Seleccionar la opción “Si” en
el cuadro de diálogo: “Abrir Archivo Existente” 4. Seleccionar el
archivo “CLASES2” en el cuadro de diálogo “Abrir”. 5. Seleccionar
la ventana “SCUMLI”. 6 . Seleccionar “Diagrama de Secuencias”. 7.
Seleccionar la ventana S3C para visualizar lo que se ha
construido.
Resultado En la figura 4.4 se muestra la pantalla del diagrama de
secuencia construido
automáticamente.
‘ I
~ _ i i _ l _ . Repaado ~~ ~ ~ 6~ ,&A Figura 4.4. Resultado del
caso