)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