s.e.p. s.e.i.t. - cenidet.edu.mx nubia cabrera... · ... por consentirme a 1á hora de ... uml,...
TRANSCRIPT
S.E.P. S.E.I.T. D. G.I.T.
Centro Nacional de Investigación y Desarrollo Tecnológico
Sistema Nacional de Institutos Tecnolbgicos
r r r tF Dirección General de Institutos Tecnolbgicos
AMBIENTE DE MODELADO Y DOCUMENTACI~N DE SISTEMAS
DE SOFTWARE UTILIZANDO DAGRAMAS DE CASOS DE USO.
TESIS
Que para obtener el grado de MAESTRO EN CIENCIAS EN
CIENCIAS DE LA COMPUTACIÓN
Presenta
Nubia Cabrera Santiago
0 4 - 0 3 4 4 Director de tesis Dr. Máximo López Sánchez
CENTRO DE INFORMACION """I SEP CENIDET I Cuernavaca, Moreloc Mayo del 2004
Centro Nacional de Invesiigacion cenidet y Desanolio Tecnológico
ANEXO No.1 I
Sistema Nacional de Institutos Tecnológicos
M10 ACEPTACI~N DEL DOCUMENTO DE TESIS
Cueriiavaca, Mor., a 29 de Abril del 2004
Dr. Rodolfo A. Pazos Rangel Jefe del departamento de Ciencias Compiitacionales Presente.
At'n: Dr. Gerard0 Reyes 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 soinetido a revisión académica la tesis titulada: Ambiente de modelado y documentación de sistemas de software utilizando diagramas de casos de USO, realizada por la C. Nubia Cabrera Santiago, 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
. ---
- Ortiz. M.C Reynddo Alanis Caiitú M.C dl"¡fir&W&&Ó Diaz.
Revisor Revisor
C.C.P. Si ibd i recc ih ,\cadeiiiicn Departatliento de Servicios Escolares Directores de tesis
jdet Centro Nacional de lnvestigacion y Desarrollo Tecnológico Sistema Nacional de institutos Tecnológicos
Estudiante
ANEXO No. 12 M11
AUTORIZACI~N DE IMPRESI~N DE TESIS
Cueriiavaca, Mor., a 29 de Abril del 2004
C. Nubia Cabrera Santiago Candidato al grado de Maestro en Ciencias en Computación Presente.
Después de haber atendido las indicaciones sugeridas por la Coinisió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 documentación de sistemas de software utilizando diagramas de casos de uso, me es grato comunicarle que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias eii este centro se le concede la autorización para que proceda con la impresión de su tesis.
Jefe del Departamento de Ciencias Computacionales
c.c.p. Subdireccióii Acadéiiiica Presidente de la Acadeniin de Ciencias Coiiiptitacioiiales Departamento de Servicios Escolares Expediente
1 3 Programa de 101 programar #a Maestea en ciencias del CENlDET
AcadCmlco. Reglamento y Pmctdimlentm ~Lademlc~.Admini.frltivor
,NcOS%"y a la SEq por tírindame su apoyo económico como 6ecari0, y a que sin su ayuda no hutíiera sido posi61é 1á terminación dé esta tesis dé Maestría.
AC Centro Nacional de Investigación y (l)esarroClo lecnologico (?E.?WiXq y a todo eC personalque en esta institución latíora, por permitirme formar parte dé esta gran f a m i l i .
A mi Director dé Tesis, Dr. Mk@no López Sánchez, porque más que mi director dé tesrc ha sido para mi un gran amigo, que ha estado alpendiente dé mi, y en todo momento he recitído su apoyo.
pCDr. @ne Santaolaya Sahado por ser un ejemplo a seguir, por sus vallosos comentarios, por eccariño y respeto que 1é tengo.
A l Comité dé @visión: Dr. c u i h r m o Qánguez Ortiz, M.C. ReynaHo glanis, M.C Ollvia c. Fragoso, por su vallosa d í o s i c w n en la revisión d i este tratíajo de tesis y por sus comentarios y sugerencias que contritíuyeron a mejorarlo.
A Anita y a Don Mario, por Ias facilldádés otorgadas en e l préstamo dé m a t e d 6ibllográjÚo. la Lic. Ollvia, la Sra. Adellna y a ima, por su enorme ama6illáady estar altanto dé nuestra situación escolar.
A mis compañeros dé generación: Mario, E&aráo, Juan José, Emillo, Alonso, César, Qtíerto, Jesús, Yanet, Marisela, Seléne, Lupita, Leonor y Vianey, por d i f i t a r dé su compañúl y de a1égres momentos.
A mis amigos Janeth, Vianey, Leonor, Amando, Isaac, Isaias, por tírindame su amistad y confianza, por escucharme en momentos ái$ci1és y por resolver muchos protí1émas juntos.
,fl Emin mi so6rino por acompañame en mis momentos dijcilés, por sus consejos, por sus favores y por su cariño.
A 1á Sra. Eluatíeth Márqu.ez Flores por ser una persona muy agraáa<, por estar a l pendrente de ml; por consentirme a 1á hora de 1á comida.
Y a todas a q u e l í personas qu.e contri6uyeron de abuna manera, a que 1á realkación de este tra6ajo dé tesis pudíra convertirse en otra meta, hecha reafiáad..
,
Dedicatorias.
j l DWS
Todo lo que tengo y soy se lo debo a dios. No ha existido un momento en mi vida en que no me encomiende a el.
Dios se ha manifestado en mi vida de dferentes formas. Estoy eternamente agradecida con el señor,
cada día le doy las gracias por esta hermosa vida que tengo, por tener salud, por los padres que me dio, por todas las oportunidades
que me ha brindado, por mis grandes amigos. Por todo, mil gracias señor. Te amo.
j l mis quendos padru: Naatúis ca6reray Virginia ..iantiago Por su amor incondicional, por su apoyo en todos los seniido. por su entrega,
por creer en mi a pesar de mis defectos, por sus acertados consejos, porque siempre encuentro una palabra de aliento, consuelo y paz
en mis momentos difíciles, por que nadie como ellos me amarrin por siempre. Padres los amo y me siento muy orgullosa de ustedes.
j l mri hermanos: Ruiiét~, Qúl; mque, NigueCjlngel; ma< t d y , Patrkizy @ec@
vivido experiencias inolvidables. Ellos son la mejor compañía que he tenido en mi vida, juntos hemos formado un gran equipo y
ellos han sido muchas veces mi fuente de motivación. Hermanos gracias, los admiro y amo.
Mis mejores amigos han sido mis hermanos, juntos hemos
j l mi esposo: Joséángelcabgos pea. Sin duda alguna. la persona que me inspira y me protege,
le estoy agradecida por el apoyo que me ha brindado durante mis estudios, por esperarme, por la enorme paciencia que me tiene
por ese amor incondicional, porque cada vez que lo he necesitado ha esta conmigo.
Amor te amo.
AMBIENTE DE MODELADO Y DOCUMENTACIÓN DE SISTEMAS DE SOFTWARE
Para desarrollar software de calidad es necesario seguir los pasos de un
modelo del proceso del software’, ya sea el modelo en cascada, el modelo
en espiral u otro que proponga la ingeniería de sofiware, cualquiera que sea el
modelo a seguir, éste nos exige realizar una análisis y especificación de
requisitos del software, siendo la primera etapa a desarrollar y a la que se le
atribuye la responsabilidad del buen éxito del sistema, ya que un mal
entendimiento del problema y una especificación errónea de requisitos nos da
como resultado un software incompleto y por consiguiente clientes
insatisfechos. Una tarea importante que debe realizar el ingeniero de software
es evitar que los errores provocados en el análisis de requerimientos sean
propagados en etapas posteriores de desarrollo, esto es posible lograrlo realizando validaciones de los requerimientos especificados, y desarrollando
casos de pruebas para el software.
La idea central de este trabajo de tesis es ofrecerle al desarrollador de
software un ambiente visual con el que pueda generar el modelo de
requerimientos de un sistema de software, usando diagramas de casos de uso
propuesto por el estandar UML y a través de ellos documentar casos de prueba
por cada requisito especificado. El producto de software que surge de este
trabajo de tesis es denominado SADUC “Sistema de análisis y documentación
de software usando casos de uso” y la documentación que genera SADUC es
denominado documento “Requisitos-Pruebas”.
‘ Pressman define a un proceso de softwarc como un marco de trabajo de las tareas que se requieren para construir software de alta calidad.
1
AMBIENTE DE MODELADO Y DOCUMENTACI~N DE SISTEMAS DE SOFTWARE
Para el desarrollo de esta tesis fue necesario estudiar diferentes temas
como: conceptos de ingeniería de requisitos, UML, pruebas del software con
casos de uso, patrones de diseño y gramáticas visuales.
En el capítulo 1 se analizan y comparan los trabajos relacionados, la
definición del problema, el objetivo de la tesis, los beneficios esperados, los
límites y alcances de la herramienta, así como la hipótesis de investigaciÓn. En
el capítulo 2 se describe el marco teórico en el que se fundamenta el
desarrollo de SADUC. En el capítulo 3 se describe el modelo conceptual del
sistema. En el capítulo 4 se presentan casos de estudios donde se modelan
requerimientos de sistemas de software y se presentan los documentos
obtenidos con la herramienta. Y por último en el capítulo 5 se describen las
conclusiones y los trabajos futuros.
.. I I
AMBIENTE DE MODELADO Y DOCUMENTACIÓN DE SISTEMAS DE SOFTWARE
CONTENIDO GENERAL ., Intr&uccion., ........ Contenido general., ..... índice de figuras.. .. indice de tablas ....... .................
cApíTuLo 1 : Conceptos Generales.
...........................
.................... ..................
.............. ...................... ............................ 4 ..........................
1.5 Trabajos relacionados.. ........... ............................ 1.6 Beneficios esperados.. ...... ............................ 1.7 Justificación.. ................... .......................... 1.8 Alcances y limitaciones ........ 1.9 Metodología de solución 1.1 O Referencias ................
CAPíTULO 2: Marco Teórico.
2.1 Modelado d 2.2 Captura de requisitos con casos de uso.. 2.3 Pruebas del softwar 2.4 Lenguajes y 2.5 lnterfaz de u ...................... 34 2.6 Referencias.. ........................... 36
.....................................
........................................................................... 17
........................................................
CAPÍTULO 3: El Modelo Conceptual del Sistema.
3.1 Vista conceptual de SADUC ............... 3.2 Diagrama de clases de SADUC 3.3 Formalismo aplicado a los casos 3.4 Desarrollo del documento Requisitos-Pruebo.. ................................................. .53 3.5 Referencias.. ................ ............... .59
CAPíTULO 4 Desarrollo y Pruebas de la Herramienta.
4.1 Características funcionales de SADUC ..................... 4.2 Manejo de la interfaz gráfica de usuario .................. 4.3 Pruebos ........................... 4.4 Referencias ............... .90
... ......................... ..............................
....... ..... .....
........... .........
CAPíTULO 5: Conclusiones.
5.1 Análisis de resultados., ........................ 5.2 Conclusiones.. ................. 5.4 Trabajos futuros. .................. 94 5.5 Referencias., ....................... ............... .95
........................ ..................................
..... ............................... ......... .............
... 111
AMBIENTE DE MODELADO Y DOCUMENTACI~N DE SISTEMAS DE SOFTWARE
INDICE DE FIGURAS.
Figura.
Figura 2.1 Suite Cenidet-UML
Figura 3 Vista conceptual de SADUC
Figura 3.1 Diagrama de clases de SADUC
Figura 3.2 Diagrama de clases de los patrones composite e iterator
Figura 3.3 Diagrama de clases del patrón de diseño command
Figura 3.4 Diagrama derivado del punto 1
Figura 3.5 Diagrama derivado del punt0 2
Figura 3.6 Diagrama derivado del punto 3
Figura 3.7 Diagrama derivado del punto 4
Figura 3.8 Diagrama Final del SRBTJ
Figura 3.9 Diseño de las relaciones de la tabla TBLREQUISITE
Figura 4.1 Funciones integradas en la GUI de SADUC
Figura 4.2 Pantalla inicial
Figura 4.3 lnterfaz gráfica de usuario
Figura 4.4 Diagrama de casos de uso para modelar con SADUC
Figura 4.5 Caso de uso identificar requisitos
Figura 4.6 Caso de uso identificar actores
Figura 4.7 Caso de uso identificar caso de uso
Figura 4.8 Caso de uso identificar relaciones
Figura 4.9 Caso de uso crear modelo de caso de uso
Figura 4.10 Caso de uso identificar requisito
Figura 4.1 1 Caso de uso relacionar objetos
Figura 4.12 Caso de uso nombrar objetos
Figura 4.13 Caso de uso nombrar caso de uso
Figura 4.13.1 Nombrar objetos
Figura 4.1 4 Caso de uso nombrar actor
Figura 4.14.1 Nombrar actor
Figura 4.1 5 Caso de uso modificar relación
Figura 4.1 5.1 Modificar relación
Figura 4.1 6 Caso de uso mover objeto
Figura 4.17 Caso de uso borrar objeto
Página.
20
38
40
42
45
50
51
51
52
52
58
64
65
66
68
68
69
69
69
70
70
71
71
72
72
73
73
74
74
75
75
iv
AMBIENTE DE MODELADO Y DOCUMENTACI~N DE SISTEMAS DE SOFTWARE
Figura 4.1 7.1 Borrar objeto
Figura 4.18 Caso de uso crear caso de prueba
Figura 4.1 8.1 Especificor casos de prueba
Figura 4.1 9 Caso de uso insertar articulo
Figura 4.20 Caso de uso especificar entradas
Figura 4.21 Caso de uso especificar salidas
Figura 4.22 Caso de uso generar documento
Figura 4.22.1 Generar documento
Figura 4.23 Submodulol: Páginas web
Figura 4.24 Módulo2: Operaciones sobre la BD
Figura 4.25 MÓdulo3: Programa de aplicación
Figura 4.26 Documento Requisitos-Pruebas. Caso de estudio 1
Figura 4.27 Modelo del sistema bancario
Figura 4.28 Documento Requisitos-Pruebas. Caso de estudio 2
76
76
78
77
77
7a
79
79
a4
85
85
87
a8
a9
V
AMBIENTE DE MODELADO Y DOCUMENTACIÓN DE SISTEMAS DE SOFTWARE
INDICE DE TABLAS
Tabla
Tabla 1 .1 Tabla cornpurativa
Tabla 3.1 Estructura de tblrequisito
Tabla 3.2 Estructura de tblariiculo Tabla 3.3 Estructura de tblpruebas
Tabla 4.1 Lista de casos de prueba. Caso de estudio 1
Tabla 4.2 Lista de casos de mueba. Caso de estudio 2
Página
13
57
57
57 a6
aa
Y1
CAPíTULO 1
CONCEPTOS GENERALES
1 .1 Objetivos. 1.2 Planteamiento del problema. 1.3 Problemas técnicos. 1.4 Hipótesis. 1.5 Trabajos relacionados. 1.6 Beneficios esperados. 1 .7 Justificación. 1.8 Alcances y Limitaciones. 1.9 Metodología de solución. 1.1 O Referencias.
Capítulo I : Conceptos generales
Introducción.
El contexto que rodea este proyecto de tesis es el modelado, análisis de requisitos de software con casos de uso, y la especificación de casos de prueba de un sistema de software. Sin duda, una de las fases de mayor importancia dentro del ciclo de desarrollo del software es la especificación y el análisis de requisitos, porque de este depende la obtención de un software de calidad. Un mal análisis o un análisis defectuoso repercuten en una implernentación errónea y por ende en un software que no cumple con las expectativas del cliente.
En este capítulo hacemos una descripción de los trabajos relacionados, definición del Problema, el objetivo de la tesis, los beneficios esperados, los límites y alcances del estudio, la hipótesis de investigación y la metodología de solución propuesta para el desarrollo de este proyecto.
1.1 Objetivos.
1.1.1 Objetivo general.
E l objetivo principal de este proyecto, es desarrollar un ambiente de software que permita al usuario modelar visual e interactivamente parte de un sistema de software con diagramas de casos de uso propuestos por el Lenguaje de Modelado Unificado (UML), y que permita asociar a cada requisito de software un conjunto de casos de prueba de validación y con esto el desarrollador sea capaz de establecer un común entendimiento con el cliente sobre los requisitos del sistema.
1.1.2 Objetivos particulares.
1. Desarrollar una gramática visual que describa como se construyen los
2. lmplementar una interfaz gráfica que permita ai usuario manipular
3. Permitir al usuario especificar casos de prueba por cada requisito del
diagrama de casos de uso.
visualmente el modelo que se esta desarrollando.
sistema que se esta modelando.
1.2 Planteamiento del problema.
La vida de un producto de software abarca ciclos de desarrollo inicial, incremental, de actualización y mantenimiento. Cada ciclo consiste de la especificación de nuevos requerimientos, determinación de nuevos diseños, modificación o reuso del código y probar que el código modificado se comporta como es requerido.
2
Capitulo I : Conceplos generales
Lo falto de documentación necesaria para emplear métodos modernos de ingeniería a 10 largo de la vida de un producto de software, ha sido el
obstáculo en la mejora de la confiabilidad del Software Y disminución de costos de mantenimiento.
La propagación de errores en el desarrollo del Software causados Por especificaciones incompletas, imprecisas o ambiguas, se pueden minimizar Si se realizan revisiones durante el desarrollo de cada etapa del software. Es por esta razón que el presente proyecto de tesis pretende proporcionar al desarrollador de software en la etapa de análisis, un documento de pruebas que silva de guía para ir validando el sistema en el transcurso de su desarrollo.
Las causas principales de fallas y fracasos de un proyecto es la pobre administración de requisitos y la pobre administración en los cambios de estos, debido a que no se cuentan con herramientas que faciliten al desarrollador la tarea de organizar, documentar y controlar cambios en las especificaciones de los requisitos, además de lo complicado que es para el desarrollador establecer un común entendimiento con el cliente sobre los requisitos del sistema. Los diagramas de casos de uso tienen la característica de ser un modelo fácil de entender por todo tipo de personas.
El problema que se pretende resolver es el siguiente:
En la actualidad no existe prototipos académicos que proporcione al desarrollador de software el documento de requisitos y el documento de pruebas en la etapa de análisis mediante los diagramas de casos de uso propuestos por el estándar UML. Por lo tanto es necesario desarrollar una herramienta que Permita al desarrollador de software crear el modelo de requerimientos con casos de uso y a traves de ella especificar casos de prueba permitiéndole generar el documento de requisitos asociado estrechomente 01 documento de pruebas en la etapa de análisis del sistema.
1.3 Problemas técnicos,
Algunos fueron:
de los problemas técnicos presentados en el desarrollo de esta tesis
1) Seleccionar una gramática visual que se adecue para los diagramas de casos de uso.
2) Desarrollar las formas de producción de la gramática considerando la eliminación de un objeto del diagrama, la inserción de un nuevo objeto, y los tipos de relaciones entre cada elemento de los diagramas de casos de uso.
3
Capítulo 1: Concepios generales
3) Desarrollar un algoritmo para recuperar io información proporcionada Por
4) Elegir el formato indicado para mostrar el documento de requisitos y el
5) Desarrollar un algoritmo que permita relacionar cada requisito con Su
el usuario que permita estructurar el documento de requisitos.
documento de pruebas.
respectivo conjunto de pruebas.
6) Elegir una técnica de almacenamiento de imágenes
1.4 Hipótesis.
Mediante el diagrama de casos de uso se pueden modelar partes de un SiStema de software y obtener el documento de requerimientos y de casos de prueba.
1.5 Trabajos relacionados.
1.5.1 Métodos orientados a objetos.
OMT: Rumbaugh y sus colegas desarrollaron la técnica de modelado de objetos (OMT, Object Modelling Techniques) para el análisis, diseño del sistema y diseño del nivel de objetos. La actividad de análisis crea tres modelos: el modelo de objeto (una representación de objetos, clases, jerarquías y relaciones), el modelo dinámico (una representación del comportamiento del sistema y los objetos) y el modelo funcional [una representación de alto nivel del flujo de información a traves de un sistema similar al diagrama de flujo de
Ventajas:
datos),,,,,,,.
1 . Proporciona una serie de pasos perfectamente definidos al desarrollador.
2. Tratamiento especial de la herencia. 3. Facilita el mantenimiento dada la gran cantidad de información que se
genera en el a,nálisis.
Inconvenientes:
1 . Hay pocos métodos para encontrar inconsistencias en los modelos. 2. InteracciÓn de objetos no soportada explícitamente en ninguna
herramienta gráfica.
4 I
Capiiuio I : Conceptos generales
Booth: ES una metodología de propósito general en la que se parte de que cada etapa de desarrollo no es un proceso aislado que ha de interactuar Con sus precedentes y consecuentes etapas, en una especie de bucle que finaliza cuando se esté satisfecho con el modelo conseguido. En un principio se tienen una serie de objetos y clases que forman el sistema, a continuación se construye el modelo de interfaz y se examinan las relaciones entre las Clases, 10 que, a su vez, genera la adición de nuevas interfaces que generarán nuevas relaciones, iterándose hasta llegar al estado de refinamiento deseado. El método Booch proporciona un conjunto de herramientas gráficas y notaciones que ayudan a representar visualmente los modelos definidos en las fases de OnÓliSiS y diseño. Algunas de ellas son: Diagramas de clase, diagramas de objetos, diagramas temporales, diagramas de módulo y proceso ,Mig031.
Ventajas:
1 . Es una metodología de propósito general. 2. Herramientas y notaciones comprensibles. 3. Proporciona una gran cantidad de información sobre la semántica de
los objetos.
Inconvenientes:
1. Notaciones poco precisas. 2. Las herramientas que implementan esta metodología estan orientadas al
Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un método de diseño orientado a objetos. Este método toma los mejores aspectos de cada uno de las metodologías anteriores. Por ejemplo: de la OMT toma los modelos de objetos, de Booch sus gráficos de visibilidad, incluso toma los cuadros de pre y postcondición de las metodologías estructuradas. Además, aunque se pueda aplicar a cualquier tipo de desarrollo, esta especialmente diseñado para proporcionar técnicas y herramientas al anolista de sistemas industriales y de producción. Las distintas tareas de las que consta, tanto en el análisis como en el diseño son: Modelo de objetos, Modelo operacional, Modelo de ciclo de vida, Gráficos de visibilidad, Descriptores de clase, Gráficos de herencia ,Mig031.
Ventajas:
texto más que a los gráficos.
1. Proporciona una gran cantidad de herramientas para comprobar la validez y consistencia de los modelos realizados en el análisis y diseño.
2. El proceso de modelado es sistemático y están definidos todos sus pasos. 3. Es posible modelar el flujo de control, la creación y destrucción
dinámica de objetos. 5
Capitulo I : Conceptos generales
Inconvenientes:
1. A veces es un método excesivamente riguroso. 2. No es un proceso iterativo.
Objectory. Un método guiado por casos de uso creado por lvar Jacobson “Objectory” es una abreviatura de “Object Factory”, fabrica de objetos. Objectoty plantea el desarrollo en dos dimensiones: ,,ocool
1. A través de los componentes, descrito en términos de actividades, flujos de trabajos, artefactos (resultados) y participantes (aspecto estático del sistema).
2. A través del tiempo, expresado en términos de ciclos, fases, iteraciones e hitos (aspecto dinámico del sistema) [M,g031.
Método de Jacobson. También llamado I S 0 0 (ingeniería de software orientado a objetos), el método de Jacobson es una versión simplificada de Objectoty, un método potentado, también desarrollado por Jacobson. Este método se diferencia de otros por la importancia que da al caso de uso. A continuación se describe de forma breve el método de Jacobson:
1. Identificar los usuarios del sistema y sus responsabilidades globoles. 2. Construir un modelo de requisitos. 3. Construir un modelo de análisis [V,r021.
Catalysis: Un método orientado a objetos que fusiona mucho de los trabajos recientes en tecnologías orientadas a objetos, y ademas ofrece técnicas especificas para modelar componentes distribuidos
Adoosi versión 5: Metodología para el desarrollo de aplicaciones con tecnología orientada a objetos utilizando notación UML (Unified Modeling Language).
Desarrollado en México por: la Dra. Sofía Áivarez y la M.C. Anaisa Hernandez González. Esta metodología se basa en el desarrollo incremental e iterativo, lo que significa que el desarrollo no se realiza de una sola vez, sino que se realiza por ciclos en cada uno de los cuales se agrega la funcionalidad adicional, se comienza con la funcionalidad correspondiente al núcleo central de la aplicaciÓn(de manera general el núcleo central de la aplicación se corresponde con la funcionalidad que determina la arquitectura de la aplicación y se van agregando funcionalidades en cada ciclo hasta alcanzar la aplicación final. ,
6
capítulo i: Conceptos generales
La metodología' incluye toda la documentación a obtener para la aplicación de cada etapa haciendo uso de ejemplos ilustrativos. La documentación propuesta corresponde con la establecida en la norma I S 0 9000. Los artefactos(diagramas, documentos y productos asociados al desarrollo son los correspondientes a la notación UML para el análisis y el disetio orientado a objetos pero con algunas modificaciones para tener en Cuenta las características especiales del desarrollo de la aplicación.
A continuación se mencionan las fases de las etapas de la metodología [N"02] . 1. Estudio preliminar:
Identificación de las necesidades del usuario. Elaboración del prototipo inicial. Definir los casos de uso. Seleccionar los casos de uso para cada ciclo. Estudio de factibilidad. Elaboración del plan de desarrollo.
Balancear los artefactos. Analizar Diseñar. Construir. Probar. Implantor. Elaborar el plan para el próximo ciclo.
2. Ciclo de n desarrollo:
1 5.2 Prototipos académicos.
A UML editor in java:! Datos: Department of Computing Science, University of Glasgow, Lilybank Gardens, , Glasgow, G12 8QQ .
Es un proyecto que se encuentra en desarrollo; la finalidad de este proyecto es crear una herramienta en Java para modelar con todos los diagromas Propuestos Por el estandor UML poro que puedan ser usados como una base en el diseño de aplicaciones. Con esta herramienta es posible construir diagramac definidos en UML, pero presenta muchas limitantes lAumOil.
Copiiu/o I : Concepios generales
1.5.3 Herramientas comerciales.
A continuación se describen 4 Herramientas CASE consideradas 10s importantes que modelan con UML.
1.5.3.1 Microsoft WSIO.
Una de las herramientas que existen en el mercado para realizar la administración y plandación de proyectos es Microsoft Visio, este paquete no está dedicado exclusivamente a la ploneación de proyectos, sino que es un conjunto de plantillas con varios fines, siendo uno de ellos la Planeación de Proyectos. Cada una' de estas plantillas contiene una serie de modelos o diagramas diferentes que pueden dibujarse y cumplen diferentes propósitos.
más
I
Visio Enterprise 2002 es la última y más completa versión de los productos Visio de Microsoft. Fue diseñado pensando en la administración de aplicaciones y desar/ollos propios de administradores de redes, anolistas y diseñadores de bases de datos, diseñadores de internetlintronets, ingenieros de procesos de negocios y desarrolladores de software; en suma, para administrar aplicaciones complejas de tecnologías de información por medio de diagramas. I
Características:
1 . Diagromoción e importación de servicios de directorio. 2. Reingeniería del bases de datos 3. Diseño y documentación de bases de datos 4. Diagramación de software 5. Ingeniería normal e inversa de código a nivel de diseño conceptual. 6. Diagramación automatizada 7. Ambiente colatiorativo 8 . Compatibilidad con aplicaciones de Microsoft
En concreto, se utiliza para crear esquemas organizacionales, líneas de tiempo, mapas geográficos y direccionales, y permite modelar con todos los diagramas de UML. [Vir021
1. 5.3.2 GDPro.
Es una herramienta de modelado que brinda ahorro de tiempo en todas las fases del desarrollo del proceso de software. Desde el código, GDPro puede aplicar ingeniería inversa al sistema de software, produciendo modelos UML automáticamente, permitiendo observar la estructura del código, mapas de relaciones, objetos, métodos y propiedades: o simplemente GDPro puede ser
I 8
Copítu/o I : Concepios generales
utilizado para comenzar el diseño de un sistema para después generar ei código a partir de este modelo.
La herramienta GDPRO 5.1 tiene las siguientes características: I
1. Maneja dos notaciones UML Y OM1 2. Realiza generación de código en C++ y Java a través del diseño
conceptual. 3. Permite la ejecución de ingeniería inversa para obtener diversos
diogramos de UML y OM1 a partir de código fuente. 4. Permite mantener sincronizados los diagramas obtenidos con el
código desde donde se obtuvieron. 5. Cuenta con soporte multiusuario. 6. Genera documentos en formatos HTML y ASCII. 7. Genera reportes del modelo de objetos, dinámico, funcional y otros
definibles por el usuario. lGdp021 I
1.5.3.3 MagicDraw. ,
MagicDraw es una herramienta de modelado visual en UMi y una herramienta CASE. La herramienta de desarrollo fue pensada para los analistas de negocios, los anolistas del software, los programadores o los escritores de la documentación. I
La herramienta facilita el análisis y el diseño de los sistemas (00) y de las bases de datos orientadas a objetos. MagicDraw está provista del mejor mecanismo de ingeQiería de código de la industria, ayuda completa para Java, lenguajes de programación de C+ +, y de CORBA IDL.
Características:
1 . Modelado de 'sistemas de software con todos los diagramas propuestos Por UML (diogramos de: clases, casos de uso, colaboración, actividad, secuencia, componentes, paquetes)
2. Mecanismos de extensión de UML (Estereotipos, Etiquetas) 3. Ingeniería aplicada a código Java (Generación de código e ingeniería
inversa con JavacDoc, Ingeniería inversa con los archivos de clases de Java).
4. Ingeniería apli,cada a código en C++ (generación de código en ANSI C+ + e ingeniería inversa.
5. Ingeniería aplicada a código CORBA IDL (Generación de código e ingeniería inversa de la versión 2.3 CORBA IDL)
6. Generación de diagramas de clases de un esquema de base de datos.
9
capitulo 1: Conceptos generales ,
1.5.3.4 Rational Rose.
El Object Management, Group (OMG], aceptó el proyecto de Rational Co. de lanzar a UML como la notación estandar oficial para el desarrollo de software bajo el esquema orientado a objetos. Rational fue la empresa que promovió la iniciativa y con ello confirma el liderazgo que posee dentro de este campo [nalozl
Características generales de Rational Rose:
1. Capacidad de mezclar múltiples lenguajes dentro de un mismo modelo. 2. Ingeniería inversa sobre los componentes COM, ActiveX y Java. 3. Perfeccionamiento en generación de código para el desarrollo de
interfaces. 4. Integración con1 herramientas de administración de la configuración. 5 . Automatización de funciones. 6. Integración con' herramientas de prueba. 7. Integración con herramientas de administración de requerimientos. 8. Notación UML. 9. Biblioteca de Frameworks.
UML ha evolucionado por lo que Rational Rose 2001, 2001A, 2002 incluyen nuevas funcionalidades como soporte para desarrollo de aplicaciones Web, que ayuda a mejorar el proceso de diseno, algunas de las nuevas características de Rational Rose 2001, 2001A, 2002 incluye:
I
I
1. Modelado para negocios 2. Diagrama de actividades 3. Modelado para web 4. Soporte mejorado para Java y J2EE 5. Soporte mejorado para XML DTA 6. Soporte para ANSI C+ + 7. Soporte para SQL Server 2000 8. Soporte para Sun Java Server Sun Java Server Pages y Microsofl Active Server
I Pages.
10
capiiulo 1: Conceptos generales
GDPro, Micosofl Visio, Magic Draw tienen características importantes Y de mucha utilidad pero no le permiten al usuario crear documentación de requisitos de software mucho menos documentación de casos de prueba, solo Rational Rose permite generar documentación de requisitos y de pruebas de sistemas de software, la desventaja de esta herramienta es que es muy costosa, además las herramientas que permiten gestionar requisitos de software son externas al software y tienen un costo adicional al Rational Rose, y para aprender a usarla requiere de un buena y costosa capacitación, en cambio SADUC es fácil de usar, la generación del documento de requisitos y de pruebas esta inmerso en ella no requiere de un costo adicional y usa el estándar 829 de la IEE'para generar los casos de prueba.
I
A continuación, realizamos una descripción de algunas herramientas existentes en el mercado para la documentación de requisitos del software.
1.5.3.5 Doors: Herramienta de administración de requisitos.
I
DOORS es una herramienta de administración de requisitos creada por Quality Systems and Software: Esta herramienta permite capturar, relacionar, analizar y administrar un rango de información para asegurar el cumplimiento del proyecto en materia 'de requerimientos. DOORS permite el acceso de un gran número de usuarios ,concurrentes en la red, manteniendo en línea un gran número de requerimientos así como su información asociada. También ayuda ai usuario a procesa/ las solicitudes de cambios de requerimientos en línea, y permite realizar cualquier modificación vía remota cuando la base de datos esta off-line, incorporando sus actualizaciones a la base de datos maestra. Esta herramienta proporciona rastreabilidad multi-nivel para aquellas relaciones entre requerimientos que poseen gran tamario. DOORS cuenta con un asistente que permite generar enlaces a reportes de muchos niveles, con el tin de desplegarlos en la misma vista [Ma,03l.
DOORS No genera documentación estandarizado, no ayuda al desarrollador a crear casos de prueba y no esta basada en UML.
1.5.3.6 IRqA Millenium: Herramienta para la captura, análisis y construcción de especificación de requisitos.
La firma española TCP Sistemas e Ingeniería ha creado un software denominado lRqA Millenium, una herramienta que pretende soportar no solo la elaboración de especificaciones de requisitos, sino todo el proceso de ingeniería de requisitos.
La herramienta proporciona funcionalidades avanzadas para capturar requisitos, analizarlos y construir especificaciones detalladas, verificarlas y gestionar toda la infiormaciÓn del proceso.
I I
I
I
i I
- 0 4 - 0 3 4 4
Capitulo I : Conceptos generales
En se cont&plan fundamentalmente IOS aspectos de validación de 10s requisitos y de verificación de la especificación [MorOJ]'
NO genera documentación estandarizado, no est0 basada en UML.
1.5.3.7 Rafionol Requistepro: Herramienta para el control sobre requerimientos.
Es la herramienta que ofrece Rational Software para tener un mayor control sobre los requerimie'ntos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos de usuario que surjan durante el ciclo de vida de un lproyecto. Este software permite que los requerimientos se encuentren documentados bajo un esquema organizado iMolD3J'
Requisitepro se encuentra integrado por aplicaciones para la administración de cambios, herramientas de modelado de sistemas y con herramientas de pruebas. Esta integración asegura que los diseñadores conocen los requerimientos del usuario, del sistema y del software en el momento de su desarrollo. Además permite el desarrollo en equipo: gracias a esto, se pueden conservar juntos todos los requerimientos y ser manipulados Por todos y cada unb de los miembros del equipo. Todos los requerimientos tienen atributos y estos son la principal fuente de información para ayudar a Planear, comunicar yl rastrear IQS actividades del proyecto a traves del ciclo de
1.5.3.8 Smart Trace: Herramienta para el seguimiento de requisitos en proyectos basados en UML.
I
I
I
I vido [EIrnZ]'
El seguimiento de requisitos se define como la habilidad para describir y seguir la vida de un requisito a lo largo de un proyecto, y es clave para conseguir una exitoso gestiónl de requisitos. SmartTTrace de Rational Rose, es una herramienta que hace uso de los mecanismos de extensión para integrar especificaciones UML y la gestión de requisitos, resolviendo problemas de duplicación y sincronización de requisitos, mediante un metamodelo que provee un marco de seguimiento adaptable y extensible a las necesidades especificas de un 'proyecto, inclusive en la definición de requisitos no considerados en su metamodelo
Estas dos últimas herramientas pertenecen a Rational Software Co. Para usarlas se requiere komprar la licencia aparte, es importante aclarar que SADUC no fue creado con el objetivo de cumplir con todas las tareas que propone la ingeniería de requisitos Por lo que no cuenta con muchas de las características que cuentan las herramientas antes analizadas. SADUC cumple con el principal objetivo por lo que fue creado que es el modelar con casos de uso parte de un sistema de software que en este caso se trata de los requisitos funcionales y la especificación de casos de prueba a traves de ellos.
Capíiuio I : Conceptos generales
Mecanismos Ingeniería inversa de extensión para obtener
de UML diagramas en
La principal característica con la que cuenta SADUC a diferencia de estas dos Últimas herramientas, es que SADUC contiene las dos funcionalidades (Modelado con casos de uso y Generación de documento) en la misma herramienta, y los casos de prueba son creados bajo al estandar de la IEEE 829’.
I
Documento Documento de de pruebas
requisitos
1 S.4 Tabla comparativa de las herramientas analizadas en el texto anterior.
si
los diagramas de UML
si No No I I
Rational Rose I si
Si
si
si
+ GDPro 5.1 Si No No
si No No
si No No
I VIS10 2002 I si I
No
No No
No
I
IRqA Millenium I No Rational I NO
No si No
No Si NO No si si
No si No
. .- Requisitepro I SmartTrace 1
Tabla 1.1: Tabla comparativa I
En los objetivns del proyedto de tesis no se menciona l a aplicación de un estandar, ya que en un principio no
13
I
se contemplaba usar u n estándar para generar la documentación de SADUC. I
~ap i iu lo I : Conceptos generales'
1.6 Beneficios esperados.
1 . Contar con un desarrollo basado en UML para que estudiantes del sistema tecnológico puedan aplicar conocimientos de desarrollo de sistemas, a partir de una herramienta accesible en su manelo.
I 2. Contar con un ambiente de modelado visual que permita la elaboración de diagramas de casos de uso para modelar requisitos funcionales de un sistema de software que ayude en la etapa de análisis y especificación de requisitos de software y en la planeación de casos de prueba.
3. Reducir el esfuerzol dedicado al desarrollo de documentos: documento de requisito y de pruebas.
I 4. Contar con una herramienta didáctica dentro de la enseñanza- aprendizaje, aplicada a materias de diseño y modelado de sistemas de software, del nivel superior y postgrado
I
I
1.7. Justificación.
Un cliente que solicita el desarrollo de un sistema de software espera recibir un sistema que cumpla con todas las funcionalidades expresadas en la especificación de los requisitos que con frecuencia cambian, por esta razón, es importante que el desarrollador cuente con un herramienta que modele los requisitos del sistema y que le permita manipular los cambios que se vayan presentando, pero también debe contar con una herramienta que permita construir las pruebas asociadas a cada requisito desde la etapa de especificación, y qbe permita verificar cada requisito especificado por el cliente.
Los principales motivbs para la realización de este proyecto son:
1 . La mayoría de los desarrolladores de software no documentan sus sistemas de software debidol a que consume gran cantidad de tiempo y si realizan la documentación lo hacen cuando el software esta finalizado. La importancia de documentar cada fase del ciclo de vida del software se traduce en reducción de costos'de desarrollo y mantenimiento del software.
2. Proporcionar un ambiente visual al desarrollador de sistemas que le permita manipular visual e interactivamente el modelo de requisitos, y que le facilite establecer y mantener los acuerdos con el cliente.
I
I
14
8 , Capitulo I : Conceptos generales
3. Las herramientas CASE existentes para modelar con UML son costosas, por IO que este proyecto de software esta diseñado para ser usado por empresas y entidades educativas que lo podrán adquirir a un bajo costo.
I
1.8. Alcances y limitac\ones.
1.8.1 Los alcances del presente proyecto de tesis son:
1. SADUC permite manipular visualmente el modelo desarrollado en su
interfaz gráfica,,moviendo los objetos de un lado a otro en el área de
modelado, eliminando objetos no deseados, agregando nuevos objetos
requeridos. ~
2. SADUC permite ireaiizar una impresión del modelo de casos de uso, así como tambiéri imprimir en pantalla y en papel el documento
Requisitos - Pruebas'.
modelo de casos de uso generado. 3. SADUC permite’ guardar, recuperar, modificar y borrar el archivo del
4. SADUC no genera código a través del diagrama de casos de uso y de
5. SADUC no perFite modelar con Otro diagrama propuesto por UML que
6. SADUC no permite realiZar modificaciones directamente desde el
ninguna otra forma. I
no sea el diagr,ama de casos de uso.
documento generado, sólo desde el modelo de casos de uso.
7. SADUC no trabbja en un ambiente de red o multiusuario. 8. SADUC no recupera diagramas de casos de uso a partir de código
fuente y bajo ningún otro formato,
I Docuniento Requisitos-Pruebas es CI nombre que se le fuc asignado al documento que genera SADUC.
I 15
Capiruio I : Concepios generales ' 1. 9. Metodología de solución.
1. Análisis y estudio del ;estado del arte desarrollando un texto descriptivo que compare cada uno de los productos del estado del arte.
2. Estudio del Lenguaje de Modelado Unificado (UML).
I
i
3. Estudio del Lenguaje de Programación visual c++.
4. Definir arquitectura del sistema usando patrones de diseño.
5. Generación de un ' prototipo de software que cumpla con los objetivos planteados de la propuesta, lo cual incluye los siguientes puntos:
i
I a) Definir y desarrollar una gramática visual para los diagramas de casos
b) Basarse en los c!íiagramas de casos de uso para proponer los modelos
c) Analizar e investigar la técnica a utilizar para generar el documento de
d) Diseñar y programar una interiaz gráfica que permita manipular el
e) Diseñar el documento para los requisitos y los casos de prueba.
de uso.
de diseño a usar.
requisitos y el documento de pruebas.
modelado con diagramas de casos de uso.
16
capítulo I : Conceptos generales,
I I
1.1 O Referencias.
(Migo31
[JacOO]
[Aum02]
[ViSO2]
IGdPO21
[Mogo21
[Rat021
[Alv02]
[Mar031
[Elf021
I Miguélez C&hlleira Gustavo. Comparación de rnetodologíw Enero 2003. Universidad $e Vigo (hnp://usuarios.alsernet.es/gustavO/A~a~~~~~.~D~l.
Jacobson, Booch, Rumbaugh., "El Proceso Unificado de Desarrollo de Software". Addison Wekiey, Madrid, 2000.
A UML editor in javo. 2002 http://studerls.dcs.gla.ac. uk/students/painjf/project~report/proJect~report~html\4t hYearReport.html).
I
visi02002. ,'
(http://www~microsof.com/office/visio/default .asp]
Advanced 'Software Technologies. 2002 http://wwwi.advancedsw.com/products/gdpro.html
AdvancedlSoftware Technologies, 2002 http://www.advancedsw.com/products/magicdraw. html
Rational Sqftware Co., www.rational.com
Áivarez Cardenas Sofía, Hernández Anaisa, Memoria del 3er. Taller Internacional de minería de datos, México 2002.
Marlon Mujica, Edwin Logreira. Metodologías y herramientas de soporte en ingeniería.de requisitos. Universidad Industrial de Santander, Colombia 2003. http://wwvj.cldlisuis.org/aedo/RGTiN2Vl/RGTI - O6.pdf
Elfriede D h n . At look at Rational's RequisitePro. the software testing and quality engineerieg magazine. Junio 2002, www.stqemagazine.com
i
I
I
17
I CAPíTULO 2
I I MARCO TEÓRICO
I 2.1 Modelado de sistemas. 2.2 Captura de requisitos con casos de uso. 2.3 Pruebas del software. 2.4 Lenguajes y gramáticas visuales. 2.5 lnterfaz de usuario. 2.6 Referencias. I
I
i
I
Copiiulo 2: Marco ie0rico
I Introducción.
El desarrollo de sistemas de software implica una serie de actividades de producción en las que /as posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar desde el primer momento del proceso, en el que los objetivos pueden estar especificados de forma errónea o imperfecta, así como en posteriores pasos de diseño y desarrollo, debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo del software 'ha de ir acompaíiado de una actividad que garantice la calidad: todas las etapas del proceso de software que se elija (ya sea el Modelo en Cascada, ;el Modelo Incremental u otro para el desarrollo de un sistema son importantes, pero si empezamos mal desde el principio es garantía que estaremos desarrbllando una solución que resuelva incorrectamente el Problema, por esto y 'por otros motivos como reducción de costos y tiempo, clientes satisfechos, hay que darle la importancia que tiene una correcta especificación de requisitos y a la ploneación temprana de los casos de prueba. I
Este capítulo describe los temas de interés que se relacionan con la investigación presentada, en la cual son abordados temas como: Modelado de sistemas, Modelado orientado a objetos con UML, Requisitos con casos de uso, Lenguajes y gramáticas visuales y Técnicas de prueba.
Antecedentes i
El grupo de ingeniería de software del cenidet ha estado desarrollando a la fecha, un ambiente de desarrollo de software orientado a objetos denominado Suite Cenidet-UML. El proyecto involucra como parte medular al Lenguaje Unificado de Modelado (UML). Mediante el uso del UML se pretende auxiliar el desarrollo de software evolutivo orientado a objetos.
La Suite Cenidet UML, busca la integración de herramientas CASE automáticas o sem)au6máticas basadas en métodos y tecnologías de vanguardia como son: programación visual, ingeniería inversa, análisis y diseño orientado a objetos. 1
I A continuación se muestra la ubicación de la tesis propuesta dentro de la Suite cenidet-UML: 1
I
19
Copiiulo 2: Marco leórico I I
Arquitectura de la Suite Cenidet-UML A t , - - - - -. . - - -
Diagramas de : Diagramasde ; Actividad I IPao"clcP I ._.______...,
I SOODA
Código fuente
Diagramas
lngcnicria .~. -: lnvcna de
cbdigo fuentc
i b _ _ _
Invcr-SOODA
I i i
Herramienta integrada 1 + Salidas del sistema i - b
+ I -.. Entradas del sistema
Trabajo propuesto ,I i 0 Trabajo Terminado '0 I : " ' .:
I Trabajo en desarrollo : .... . . . . j
i Fig. 2.1 Suite Cenidet-UML
20
I Capiiulo 2: Marco ie&¡CO
I I
Descripción de algunos,mÓdulos de la Suite Cenidet-UML.
a) SOODA: Modela diagramas de clases del estandar UML y genera código fuente en C+ + a partir del modelado de diagramas de clases.
b) InverDDVi: Modela diseño detallado con diagramas de Warnier. Auxilia a SOODA para generar el código fuente de métodos de ClaSeS en lenguaje C+ +. ,
C) InverSOODA: es una herramienta que se encuentra integrada a SOODA, la cual, mediante la aplicación de ingeniería inversa a código fuente en lenguaje C++, ,genera el diagrama de clases y el diseño detallado de los métodos basado en diagramas de Warnier. DDVi es una herramienta para el diseñoldetallado basado en diagramas de Warnier, que fue desarrollada para ajustarse a las necesidades de SOODA e InverSOODA.
2.1 Modelado de sistemas.
Un modelo de software proporciona los planos de un sistema. Los modelos pueden involucrar planos detallados, así como planos más generales que ofrecen una visión global del sistema considerado. Un buen modelo incluye aquellos elementos que tienen una gran influencia y omite aquellos elementos menores que no son relevantes para el nivel de abstracción dado.
E l modelado de sistemas de software es una parte importante de todas las actividades que conducen a la producción de software de calidad [8a0991.
Construimos modelos para comprender mejor el sistema que estamos desarrollando. I A traves del modelado conseguimos 4 objetivos:
I 1. Los modelos nos ayudan a visualizar cómo es que queremos que sea un
2. Los modelos nios permiten especificar la estructura o el comportamiento
3. Los modelos, nos proporcionan plantillas que nos guían en la
4. Los modelos dpcumentan las decisiones que hemos adoptado [Bw991.
Un modelo de soifbare ayuda a los desarrolladores a explorar arquitecturas y soluciones de disefio antes de escribir código, o bien, rescatar por medio del modelo el diseño de, un sistema ,Ram9PI.
sistema.
de un sistema.1
construcción de un sistema.
I 21
2.1.1. Modelado orientado a objetos.
LOS desarrollos de sisteinas orientados a objetos promueven una nueva forma de pensar. La palabrp desarrollo hace alusión ai ciclo vital del software: análisis, diseño e implantación. El modelado y diseño orientado a objetos también constituye una nueva forma de pensar acerca de los problemas empleando modelos yue se organizan tomando como base conceptos del mundo real. Los modelos orientados a objetos son útiles para comprender problemas, comunicarse con expertos en esa aplicación, modelar empresas y diseñar programas y bases de datos.
La tecnología O 0 se apoya en los sólidos fundamentos de la ingeniería, cuyos elementos reciben el nombre global de modelo de objetos. El modelo de objetos abarca los principios de abstracción, encapsulación, modularidad, jerarquía, tipos, concurrencia y persistencia. Ninguno de estos principios es nuevo por si mismo. 10 importante del modelado de objetos es el hecho de conjugar todos estos elementos de forma sinérgica [Jom971.
I
2.1.2 Modelado con :UML.
Cuando construimos/ sistemas con UML no necesariamente se construye un simple modelo. Existen distintos modelos en las diferentes fases del desarrollo, y cada modelo tiene propósitos distintos. En la fase de análisis, el propósito del modelo es capturar1 los requerimientos del sistema y modelar las clases y colaboraciones básicas del mundo real. En la fase de diseño el propósito del modelado es extenber los modelos del análisis a través de una solución técnica, con consideraciones para el ambiente de implementación. En la fase de implementación, el modelado es el código fuente actual, el cual es programado y compilado en algún lenguaje de programación Inomo31,
El proceso deirnodelado con UML no es una tarea sencilla. Cuando se inicia se realizan varias propuestas que modelan la solución del problema que se quiere resolver en las diferentes fases del desarrollo. En ocasiones los primeros modelos s e hacen de manera informal, donde se dan ideas por el grupo de desarrolladores para considerar posibles cambios. Un modelo por lo regular se va detallando poco a poco, a traves de este proceso se van detectando mas detalles sobre la solución del problema y se van documentando. Cuando el modelo es terminado, se realiza una integración y verificación, lo que permite que el modelo o diagrama inicie una integración con otros diagramas o mÓdel~s~~""~~~.
I
1 I I
2 2
2.1.2.1 El modelo de casos de USO.
EI modelo de Casos de USO ayuda ai cliente, a 10s usuarios Y a 10s
desarrolladores a llegar a un acuerdo sobre cómo utilizar el sistema, Y proporciona la entradb fundamental para el análisis, el diseño y las pruebas. La mayoría de los sistemas tienen muchos tipos de usuarios. Cada tipo de usuario se representa mediante un actor. Los actores utilizan el sistema ai interactuar con los cakos de uso. Todos los actores y casos de uso del Sistema forman un modelo delcasos de uso. El modelo de casos de uso captura todos los requisitos funcionalles del sistema
El modelo de Jasos de uso puede hacerse bastante grande y difícil de entender, por lo que les necesario dividir el modelo en partes pequeñas, UML permite dividir el sistema en paquetes.
2.1.2.1.1. Fundamenth de casos de uso.
Los diagramas de casos de uso son importantes para visualizar, especificar y documentar el comportamiento de un elemento de un sistema de software. Estos diagramas fakiliton que los sistemas, subsistemas y clases sean elaboradas y comprensibles, al presentar una vista externa de cómo pueden utilizarse estos elementos en un contexto dado [800991.
2.1 2.1.1.1 Propiedabes comunes.
I
I
i
I
Un diagrama de casos de uso es un tipo especial de diagrama y comparte las propiedades comunbs al resto de los diagramas, un nombre y un contenido gráfico que es una Groyección de un modelo. Lo que distingue a un diagrama de casos de uso de los otros diagramas es su contenido particular lem991.
Normalmente un diagrama de casos de uso contiene:
1. Casos de ,.so.
3. Relaciones de dependencia (inclusión y Extensión, generalización y
Los diagramak de casos de uso se emplean para modelar la vista de casos de uso estática de un sistema. Esta vista cubre principalmente el comportamiento del sistema.
Cuando se modela la vista de casos de uso estática de un sistema, normalmente se em;plearán los diagramas de casos de uso de una de las dos formas siguientes: ,Bw991
2. Actores. I
asociación). I
1
23
1. Para modela; el contexto de un sistema. Modelar el contexto de un sistema implica dibujar una línea alrededor de todo el sistema y asegurar que.' actores quedan fuera del sistema e interactúan con él. Aquí, se emp/earan los diagramas de casos de uso para especificar los actores y el significado de sus roles.
2. Para model$r los requisitos de un sistema: El modelado de los requisitos de; un sistema implica especificar que debería hacer el sistema (desde un punto de vista externo), independientemente de cómo se haga. Aquí se emplearan los diagramas de casos de uso, Para especificar el comportamiento deseado del sistema. De esta forma, un diagrama .de casos de uso permite ver el sistema entero como una baja negra; se puede ver que hay fuera del sistema y Cómo reac&iona a los elementos externos, pero no se puede ver cómo funciona dentro.
I
2.1.2.1.1.2 Identificando elementos del modelo de casos de uso.
La identificación de actores y casos de uso es la actividad mas decisiva para obtener adecuadamente los requisitos y es responsabilidad del analista de sistemas, pero el anblista de sistemas no puede realizar este trabajo solo. El analista requiere infdrmación de un equipo que incluye al cliente, los usuarios, y otros analistas que participan en talleres de modelado dirigidos por el analista del sistema r ~ o o o i .
2.1.2.1.1.3 Identificando actores.
Los actores son CuaÍquier entidad que interactúa con el sistema, por ejemplo: personas, otro software, hardware y dispositivos, almacenes de datos o redes. Cada Actor define un rol particular. Cada entidad fuera del sistema puede ser representado por uno o más actores. Una persona física puede ser representada por varios actores, ya que una persona toma diferentes roles en el sistema o varias(pers0nas físicas pueden ser representadas por un actor, porque todos ellos toman un mismo rol en el sistema.
I
Los actores Sdn externos al sistema, ellos nunca serán parte del sistema. A continuación se dnlistan algunas preguntas que pueden ayudar a encontrar actores [Baiool. i
1. 2. 3. 4. 5. 6 .
¿Quién usa el sistema? ¿Quien instala el sistema? ¿Quién inicia el sistema? ¿Quién dantiene el sistema? ¿Quién aboga el sistema? ¿Que otros sistemas usan el sistema?
i
24
I Copilpilulo 2 Momo leónco I
I
7. ¿Quién obtieAe información del sistema? 8. ¿Quién provde información al sistema. 3 W 0 1 l
I 2.1.2.1.1.4 Identificando casos de uso.
El siguiente paso es ir ;a través de todos los actores e identificar casos de USO para cada uno de eiiys. Un caso de uso es una descripción de un conjunto de secuencias de acciones, incluyendo variantes que ejecutan un sistema para producir un resultadd obsetvable de valor para un actor, un caso de USO involucra la interocdión de actores y el sistema, en cualquier sistema interesante se pue/en encontrar casos de uso que son versiones especializadas de otros casos de uso, y casos de uso que extienden el comportamiento de dtros casos de usos básicos [SchOll .
En UML un caso de uso es siempre iniciado por un actor. A continuación se listan algunas preguntas que pueden ayudar a encontrar casos de uso [Xholl ' I
1. ¿Qué funciónes deseara el actor del sistema? 2. LEI sistema almacena información? 3. ¿Qué actor'es crearan, leeran, actualizaran o eliminaran información? 4. ¿El sistemalnecesita notificar a un actor acerca de los cambios en el
sistema? I 5. ¿Existe algún evento externo que el sistema deba conocer? 6. ¿Qué actor informa al sistema acerca de estos eventos?
2.1.2.1.1.5 Describi4ndo actores y casos de uso.
Cada actor y casb de uso necesita un nombre descriptivo y una breve
El analista de sistemas da nombre a los actores y describe brevemente los papeles de caüa actor y para que utiliza el actor al sistema. Encontrar nombres relevantes para los actores resulta importante para comunicar la semántica deseada. La descripción breve de cada actor debe esbozar sus necesidades y resp~nsabilidades ~Bcoool.
descripción de una I o dos oraciones de largo ISchOl,.
I
1 Se debe el&r un nombre para cada caso de uso. de forma que de
idea de la secuenkia de acciones concretas que añade valor a un actor. El nombre de un caso de uso a menudo comienza con un verbo, y debe reflejar cual es el objetivo de la interacción entre el actor y el sistema [Bwool.
25
i copiiulo 2: Momo ieórico
2.2. Captura de requisit@ con casos de uso.
Los casos de uso propjrcionan un medio intuitivo y sistemático para capturar los requisitos funcionales, con énfasis especial en el valor añadido para cada usuario individual o para cada sistema externo. Mediante la utilización de casos de uso, los analiktas se ven obligados a pensar en términos de quiénes son los usuarios y qué nkcesidades u objetivos de la empresa puedan cumplir.
El esfuerzo principal de requisitos es desarrollar un modelo que se va a construir, y la utilización de los casos de uso es una forma adecuada de crear ese modelo. Esto es debido a que los requisitos no funcionales son específicos de un solo caso de udo, y pueden tratarse en el contexto de ese caso de uso
I I [BWOO]'
2.2.1 Fundamentos de requisitos.
2.2.1.1 Concepto de requisito ,Ku,02,.
1. Una condición o capacidad que es necesaria para un usuario, para resolver un problema o llevar b cabo un objetivo.
2. Una condición o capacidad que debe tener un sistema o un componente del sistema Para stitisfacer un contrato, estandar, especificación u otros documentos formales.
I
I
2.2.1.2 Requisitos funcionales [KU,021.
1 . Incluyen las cosasi que los usuarios y los desarrolladores requieren que haga
2. La identificación y definición de los requerimientos funcionales no es un ejercicio de cómo el sistema soportará las funciones, actividades y tareas, sino un ejercicio de detallar como verán y usarán el sistema los usuarios.
2.2.1 .3 Requisitos nd funcionales lKu,021.
1. Están relacionados con las características de calidad, como seguridad, portobilidad, confiabilidad entre otras.
2. Propiedad que debe tener el producto resultante. Son las propiedades de comportamiento que las funciones establecidas deben tener, tales como desempeño y utilidad.
I
el sistema I 1
I
I
i
I 1
I 26
2.2.1.4 Especificación ;de requisitos [Ku,02,.
La especificación de requisitos contempla:
1 . El establecimiento! y mantenimiento de acuerdos entre el cliente y el desarrollador en relación a lo que se va entregar y a los criterios que se van a utilizar.
2. La mayor contribulión de problemas en el desarrollo y mantenimiento se debe a una inadecuada especificación de requerimientos.
La especificación de kequisifos es necesaria por las siguientes razones:
1 . Permite tener unal visión clara entre el dominio del negocio y el sistema a
I I
I
1
desarrollar. I 2. La especificación puede ser parte de los arreglos contractuales.
3. La especificació? puede ser usada para evaluar el producto final y se puede utilizar en las .pruebas de aceptación acordadas entre el proveedor y el
I
cliente. I
2.3 Pruebas del sohare.
El software debe sdr probado para descubrir y corregir el máximo de errores posibles antes de su entrega al cliente, el objetivo es diseñar una serie de casos de prueba Que tengan una alta probabilidad de encontrar errores y puedan ser corregidos a tiempo.
2.3.1 Fundamentos /de pruebas.
2.3.1.1 Objetivos de las pruebas. I
El objetivo de las pruebas es descubrir errores en el software, como ventaja secundaria, IO prueba demuestra hasta que punto las funciones del software
los requisitos establecidos. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba, proporcionan una buena indicación de la fiabilidad del software y, de alguna manera indican la calidad del software como un todo. Sin embargo, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software ,P,eO,l.
parecen funcionar, I de acuerdo con las especificaciones y parecen alcanzarse
I
27
Tom Gilb plantea bue se deben tomar en cuenta los siguientes aspectos
1. EspecifiLar los requisitos del producto de manera cuantificable mucho bntes de que comiencen las pruebas.
2. Estableyer los objetivos de la prueba de manera explícita. 3. Comprender que usuarios van a manejar el software y
desarrdllar un perfil para cada categoría de usuario. 4. Desorrbllar un plan de prueba que haga hincapié en la prueba
del cidlo rápido, para controlar los niveles de calidad y las correspondientes estrategias de pruebas.
5. Construir I un software robusto diseñado para probarse a si mismo.
6. Usar revisiones técnicas formales efectivas como filtro antes de la prueba
7. Llevar’ a cabo revisiones técnicas formales para evaluar la estratc!?gia de prueba y los propios casos de prueba.
8. Desartollar un enfoque de mejora continua al proceso de
para implementor con éxito una estrategia de prueba del software: ‘
I prueba [ReOl]’
I 2.3.1.2 Caso de prueba.
Un caso de prueba especifica una forma de probar el sistema, incluyendo la entrada o resultado con la que se ha de probar y las condiciones bajo las que ha de probarse. En ¡la práctica lo que se prueba puede venir dado por un requisito o colección de requisitos del sistema cuya implementación justifica una prueba que es dosible realizar y que no es demasiado cara de realizar. Los siguientes son casos de prueba comunes
I 1. Un caso dk prueba que especifica cómo probar un caso de uso o
cómo prodar un escenario específico de un caso de prueba. Un caso de pruebd de este tipo incluye la verificación del resultado de la interacción entre los actores y el sistema, satisfacen las condiciones y postcondidiones especificadas por el caso de uso y que sigue la secuencialde acciones especificadas por el COSO de uso. Un caso de prueba basado en un caso de uso especifica típicamente una prueba del sistema como “caja negra”.
2. Un caso de prueba que especifica cómo probar una realización de un caso de uso o un escenario específico de la realización. Un caso de prueb¿ de este tipo puede incluir la verificación de la interacción entre los componentes que implementan dicho caso de uso.
I
I
28 I
I . .
, 2.3.1.2.1 Prueba de los c I osos de uso.
Mediante la identificocibn temprana de los casos de uso, podemos comenzar pronto la planificación( de las actividades de prueba, y podremos proponer casos de prueba desde el comienzo. Estos casos de prueba pueden detallarse más durante el disefio,'cuando sepamos más sobre como el sistema llevará a cabo los casos de uso.
Las pruebas de 10s casos de uso pueden llevarse a cabo bien desde la perspectiva de un actor que considera el sistema como una caja negra, o bien desde una perspectiva de diseño, en la cual el caso de prueba se construye Para verificar que las instancias de las clases participantes en la realización del caso de us0 hacen lo 'Sue deberían hacer. Las pruebas de caja negra pueden identificarse, especifidarse y planificarse tan pronto como los requisitos sean algo estables [Bmaol, I
I I
2.3.1.3 Procedimientolde prueba.
Un procedimiento delprueba especifica cómo realizar varios casos de prueba o partes de estos. Por ejemplo, un procedimiento de prueba puede ser una instrucción para un individuo sobre cómo ha de realizar un caso de prueba manualmente, o ppede ser una especificación de cómo interactuar manualmente con uqa herramienta de automatización de pruebas para crear componentes ejecutybles de prueba.
E l cómo llevar cabo un caso de prueba puede ser especificado por un procedimiento de prueba, pero es a menudo Útil reutilizar un procedimiento de prueba para variosl casos de prueba y reutilizar varios procedimientos de prueba para un caso de prueba
2.3.1.4 Defecto.
Un defecto es una dnomaiía del sistema, como por ejemplo un síntoma de un fallo en el softwarel o un problema descubierto en una revisión. Un defecto puede ser utilizadó para localizar cualquier cosa que los desarrolladores necesitan registrar como un síntoma de un problema en el sistema que ellos necesitan controlar y resolver lBooOO],
2.3.1.5 Plan de prueba.
I I I
I
I
E l plan de prueba describe las estrategias, recursos y planificación de la prueba. La estrategia de prueba incluye la definición del tipo de pruebas a realizar para cadaiciclo de desarrollo y sus objetivos, el nivel de cobertura de prueba y de cÓd(go necesario y el porcentaje de pruebas que deberían ejecutarse con un resultado específico fBooool.
I
29
2.3.2 Técnicas de prueda
2.3.2.1 Prueba de unidad.
Antes de iniciar cualqúier prueba es necesario probar el flujo de datos de la interfaz del módulo de Isoftware. Si los datos no entran correctamente, todas las demás pruebas no tieden sentido.
I
I
I
Durante la pruebo de unidad, la comprobación selectiva de los caminos de ejecución es una tarea esencial. Se deben disefiar casos de prueba para detectar errores debidos a cálculos incorrectos, comparaciones incorrectas O flujos de control inapiopiados. Las pruebas básicas y de bucles, son técnicas muy efectivas para descubrir una gran cantidad de errores en los caminos.
I Errores más comunes:l
1. Precedencia aritmética incorrecta o mal interpretada 2. Operaciones de modo mezcladas 3. iniciaiizaciones incorrectas 4. Falta de; precisión 5. lncorredta representación simbólica de una expresión
1
Los casos de Drueboideben descubrir errores como: 1. 2. 3.
4. 5. 6 . 7.
Comparación entre dos tipos de datos distintos Operadores lógicos o de precedencia incorrectos Igualdad esperada cuando los errores de precisión lo hacen poco p:robable Variables o comparaciones incorrectas Termin?ciÓn de bucles inapropiado o inexistente Fallo de salida cuando se encuentra una iteración divergente Variab('es de bucles modificadas de forma inapropiado
1 1
2.3.2.2 Prueba de iitegración.
La prueba de injegración es una técnica sistemática para construir la estructura del programa, al mismo tiempo se llevan a cabo pruebas para detectar errores asociados con la interacción. Se hacen pruebas con integración incremkntal, el programa se construye y se prueba en pequerios segmentos, hacienhose más fácil identificar y aislar los errores.
I
1. Integración 1 descendente: Es un planteamiento incremental a lo construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de lcontrol principal, ya sea primero en profundidad o primero en anchura!
I
1
30
2.
3.
4.
I
Integración ascehdente: Las pruebas se llevan a partir de los módulos atómicos, existe, la necesidad de construir un controlador para los módulos para las pruebas, estos controladores son eliminados según se van integrando los módulos probados. Prueba de regresión: Es volver a ejecutar el conjunto de pruebas que se han ejecutado lada que se agrega un módulo, para asegurar que los cambios no han1 producido efectos colaterales. Prueba de hum?: Es un método de prueba de integración continua que es comúnmente utilizada cuando se ha desarrollado un producto de software empaquetado. Minimiza los riesgos de integración, y perfecciona la calidad del producto final: se simplifican el diagnóstico y la corrección de errores, y el progreso es fácil de observar.
I
I 2.3.2.3 Prueba de voli'doción.
La validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. La validación permite descubrir errores, pero su enfoque esta en el nivel de requisitos. La validación del software se consigue mediante h a serie de pruebas de caja negra que demuestran la conformidad con los'requisitos.
I
I Existen dos tipos de druebas de validación, la prueba alfa y la prueba beta.
I
La prueba a/f$ se lleva a cabo por el cliente específicamente en el lugar de desarrollo. Se uso el software de manera natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. La prueba befa se lleva a cat30 por los usuarios finales en los lugares de trabajo, registra los errores e informa a intervalos regulares a los desarrolladores.
descubiertos en esta fase del proyecto raramente se puedh corregir antes de la terminación planificada, a menudo es necesario negokiar con el cliente un método para resolver las deficiencias.
2.3.2.4 Prueba del bistema.
La prueba del sis(ema esta constituida por una serie de pruebas diferentes cuyo propósito pr(mordia1 es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propósito diferente, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
I Las desviaciones o errores 1
I
I
1. Prueba de recuperación: Es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperación se lleve a cabo aprqpiadamente. Si la recuperación es automática hay que evaluar la1 corrección de la inicialización, de los mecanismos de
I I 31
I recuperación del estado del sistema, de la recuperación de datos y del proceso de oqranque. Si se requiere intervención humana en la recuperación hay que evaluar los tiempos medios de reparación para determinar si están dentro de los límites aceptables.
2. Prueba de sdguridad: Intenta verificar que los mecanismos de protección incbrporados en el sistema lo protegerán de accesos impropios. I
1
I
3. Prueba de resistencia: Ejecuta un sistema de forma que demande recursos en 1 cantidad, frecuencia o volúmenes anormales. Esencialmente; el responsable de la prueba intenta romper el programa.
I
4. Prueba de reddimiento: Esta diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado. La brueba de rendimiento se da durante todos los pasos del proceso de ptueba. Estas pruebas van frecuentemente acompañadas por pruebas de resistencia, y frecuentemente requieren instrumentación de software y hardware.
2.4 Lenguajes y gramáticas visuales. I
Los lenguajes visuales han llegado a ser una nueva herramienta para los programadores de ,computadoras, estos permiten mejorar la interacción con los usuarios y sus aplicaciones, escribir un menor número de líneas de código y agilizar el tiempo dk implementoción. Con esta nueva forma de programar ha surgido un nuevo paradigma: la programación basada en iconos, en donde el desarrollador puede crear, modificar y combinar pequeños objetos pictóricos llamados iCOnOS cox propiedades definidas y capaces de ejecutar una acción computacionai. 1
Actualmente! muchos de los lenguajes de programación visual utilizan el paradigma de io$ iconos, pero ¿qué es la programación visual?. Ésta se entiende como el ius0 de expresiones visuales tales como dibujos, gráficas e iconos, o lo que se refiere a cualquier sistema que permita especificar un programa en forma de dos dimensiones [Kim9B1,
I 2.4.1 Definición de I lenguaje visual.
Un lenguaje visual^ consiste de oraciones visuales. Cada oración visual es una colocación espacial de objetos gráficos o iconos relacionados que comunican algo. De acuerdo io esta definición, un lenguaje visual puede ser aplicado a un número diferente tie representaciones, en donde su significado está dado por las relaciones que; guardan los elementos visuales [um981.
I 32 I
2.4.2 Conceptos y aplicaciones.
2.4.2.1 Especificación de lenguajes visuales,
Dentro de la especificación formal de los lenguajes de programación visual, la composición espacial de iconos que constituye una instrucción visual, es la contraparte bidimensional de la composición de muestras en los lenguajes de programación textuales. En estos Últimos, un programa se expresa como una cadena de muestras concatenadas que forman una instrucción, cuya estructura y significado son analizados sintáctica y semanticamente. Por su parte, en los lenguajes visuales se pueden distinguir tres reglas generales de construcción que se usan para componer los iconos espacialmente: la concatenación horizontal, la concatenación vertical, las que representan las relaciones de enlace entre objetos gráficos y la sobre posición espacial [c05971.
Existen tres principales aproximaciones para la especificación de lenguajes visuales: El enfoque gramatical, el enfoque de la lógica y el enfoque algebraico. Aquí se hora referencia a la forma gramatical para la especificación de un lenguaje visual. Una gramática para un lenguaje visual esta basada en el formalismo gramatical usado para la especificación de lenguajes de cadenas. Los lenguajes de cadenas están formados por un conjunto de símbolos no terminales y terminales, un símbolo inicial y un conjunto de reglas de producción
Desde la aparición de los lenguajes visuales, han surgido nuevas gramáticas que permiten definir de una manera formal las expresiones de dichos lenguajes. Una de las principales motivaciones para el desarrollo y formolización de gramáticas visuales fue la gran necesidad de procesar imágenes. Por más de treinta años de investigaciones han sido dedicadas a las gramáticas gráficas y a sus aplicaciones para el procesamiento de imágenes y reconocimiento de diagrama~[~~"'~~~.
Para poder definir una gramática visual, primero se debe identificar el lenguaje visual que es, considerando los siguientes puntos: primero debe delimitarse el dominio de aplicación, después se deben identificar los elementos que forman parte de ese dominio, definir las relaciones válidas con elementos dentro del mismo dominio y, finalmente, determinar el comportamiento de las relaciones [Kim981. Con esto se puede determinar que tipo de gramática visual se puede utilizar para definir dicho lenguaje.
33
2.4.3 Clasificación de las gramáticas visuales.
Existen muchas gramáticas que son consideradas como métodos formales para la especificación formal de lenguajes visuales. Aquí se hará referencia a algunas de ellas.
1. Gramáticas de cadena generalizada. Estas modifican las gramáticas de cadenas proporcionando una generalización de la concatenación de dos dimensiones. La ventaja de utilizar esta gramática es que representa un soporte para la teoría de cadenas y del eficiente algoritmo de parseo. Su desventaja es, que son gramáticas que no son muy poderosas porque solamente especifican clases restrictivas de lenguajes visuales. No pueden aplicarse de manera general a los lenguajes visuales, porque sus composiciones son limitadas.
2. Gramáticas de relación de símbolos [SR). Esta permite la reescritura de sentencias a partir de los símbolos terminales y no terminales mediante la representación de objetos gráficos, así como reglas de evaluación para reescribir las restricciones. É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 ellos [c0s971.
3. Gramáticas relacionales. Estas gramáticas heredan ideas de la lingüística computocional. Usa restricciones basadas en unificación para expresar restricciones especiales y permitir la computación de estructuras características en atributos de gramática pasiva.
4. Gramáticas posicionales. Las gramáticas posicionales extienden de manera natural a las gramáticas libres de contexto (GLC) para lenguajes textuales, al considerar nuevas relaciones aparte de la concatenación de cadenas. De manera transitiva, la conocida eficiencia de los analizadores LR para GLC puede llevarse a las gramáticas posicionales. Estas gramáticas ayudan a definir ubicaciones espaciales de objetos, así como las relaciones de enlace entre ellos 1Kim9*1.
2.5 lnterfaz de usuario
Se define como lnterfaz de usuario al conjunto de componentes empleados por los usuarios para comunicarse con las computadoras. Una interfaz está relacionada con la estructura subyacente, la arquitectura y el código que hace el trabajo del software pero no se confunde con ellos
34
Dentro de las Interfaces de usuario se distinguen básicamente dos tipos:
1 . Una inferfaz de hardware a nivel de los dispositivos utilizados para ingresar, procesar y entregar los datos: teclado, ratón y pantalla visualizadora; y
2. Una inferfaz de soiiware destinada a entregar información acerca de los procesos y herramientas de control, a través de lo que el usuario ObSeNa habitualmente en la pantalla IUnOll.
AI diseñar interfaces de usuario debe tenerse en cuenta las habilidades cognitivas y de percepción de las personas, y adaptar el programa a ellas.
Así, una de las cosas mas importantes que una interfaz puede hacer es reducir la dependencia de las personas de su propia memoria, no forzándoles a recordar cosas innecesariamente (por ejemplo: información que apareció en una pantalla anterior) o a repetir operaciones ya realizadas (por ejemplo, introducir un mismo dato repetidas veces) Iru,oll.
Una persona tiene unas habilidades distintas de la máquina y esta debe utilizar las suyas para soslayar las de aquella (como por ejemplo la escasa capacidad de la memoria de corto alcance).
Algunas características que se atienden dentro de las interfaces de usuario son:
1 . Velocidad de aprendizaje: Se pretende que la persona aprenda a usar el sistema lo más pronto posible.
2. Velocidad de respuesta: El tiempo necesario para realizar una operación en el sistema.
3. Tasa de errores: Porcentaje de errores que comete el usuario. 4. Retención: Cuánto recuerda el usuario sobre el uso del sistema en un
período de tiempo. 5. Satisfacción: Se refiere a que el usuario esté a gusto con el sistema
35
2.6 Referencias.
[Boo991
[Ram991
[Kui02]
(Gra941
[PreOl]
[TUtOl]
[LinOl]
[Kim981
[BooOO]
[SchOl]
(Jam971
[Cos971
[RomOJ]
[Her031
Booch, Jacobson, Rumbaugh., El lenguaje Unificado de Modelado (Addison Wesley Iberoamericana, Madrid, 1999.)
Rumbaugh James.. The Untied Modeling ianguaje Reterence Manual, Addison-Wesley. l a . Edición en inglés 1999.
Kulak, Guiney ., Uses Cases " Requirements in Context" Addison Wesley Iberoamericana, 2002.
Grady Booch. Object-oriented analysis and design with aplications. 2da. Edición; USA: BenjaminlCumrnings Publishing Co., 1994
Pressman Roger S., Ingeniería del Soflware; un enfoque práctico.(5ta edición; España: MC Grow Hill. 2001)
Tutorial "Diseño de una interfaz gráfica", 2001, Universidad Autónoma de Guadalajara , http://www.uag.mx/óólprocesol .htm
Lineback. graphical user interface timeiine. 2001 http://pla-netx.com/linebackn/guis/guitimeline. html
Kim Marriot, Bernd Meyer, Visual Languaje Theory Springer-Verlag New York, 1998.
Booch. Jacobson, Rumbaugh.. El Proceso Unificado de Desarrollo de Soflware Addison Wesley Iberomaericana, Madrid, 2000.
Schneider, Winters., Applying Use Cases, Second Edition Addison Wesley Iberomaericana, 2001.
James Rumbaugh. Michael Blaha, W. Premerlani, F. Eddy. Modelado y diserio orientado a objetos. Prentice Haii. España 1991
G. Costangliola. A de Lucia y G. Tortora, "A Framework of Syntactic Models for de Implementation of visual Languages", Universidad de Salermo italia 1997.
Roman Castatieda Javier; "Sistema visual para el disetio detallado de métodos con closes con UML". Tesis de maestría, Enero 2003.
Hernandez Velázquez Miguel.. "ingeniería Inversa de código fuente en c++ para la obtención de su diseño", tesis de maestria, cenidet. agosto del 2003
36
CAPITULO 3
EL MODELO CONCEPTUAL DEL SISTEMA
3.1 Arquitectura de SADUC. 3.2 Diagrama de clases de SADUC. 3.3 Formalismo aplicado a los casos de uso. 3.4 Desarrollo del documento Requisitos - Prueba. 3.5 Referencias.
Capitulo 3: El modelo conceptual del sistema.
Introducción.
SADUC (Sistema de Análisis y Documentación utilizagido Diagramas de Casos de Uso), es el resultado de esta tesis; uno de los objetivos por el cual fue creado SADUC es permitir al usuario manipular visualmente el diagrama de casos de uso, y especificar por cada requisito un conjunto de casos de prueba. Para lograr este objetivo fue necesario desarrollar una gramática visual para los diagramas de casos de uso. una interfaz gráfica del sistema, diseñar las cajas de dialogo para la entrada de datos y el formato de documentación de casos de Drueba.
En este capítulo se explica el modelo conceptual de SADUC, la arquitectura y la gramática desarrollada, el manejo de los datos de los casos de prueba, el uso de Crystal Report para la generación del documento Requisitos - Pruebas y detalles importantes para la comprensión del sistema.
3.1 Vista Conceptual de SADUC.
En la figura 3 puede observarse en forma general cómo funciona SADUC internamente y cuáles son los resultados que genera.
1. Generar Diagramas 2. Generar Documento
+(A] Requisitos [-]I Drta. De
Dcto. De pruebas
Fig. 3 Vista conceptual de SADUC.
Capítulo 3: El modelo conceptual del sistema.
SADUC esta dividido en dos partes importantes: la primera se encarga de brindar Servicios ai usuario para que este pueda generar el diagrama de Casos de uso, de acuerdo a 10s requerimientos del sistema que se desea modelar. E l usuario debe suministrar a SADUC las especificaciones de 10s requerimientos del sistema y 10s Casos de prueba que le corresponden a cada requerimiento.
L ~ S Servicios que proporciona SADUC al usuario a través de SU lnterfaz Gráfica son:
1. Crear diagramas de casos de uso. 2. Guardar en medios persistentes [Archivos] el diagrama de
casos de uso modelado. 3. Generar el documento Requisitos-Pruebas.
La segunda parte se encarga de obtener la información almacenada en cada caso de uso para trasladarla a una base de datos, y finalmente generar el documento Requisitos-Pruebas. Esta actividad es transparente para el usuario, el debe decidir en que momento debe generar la documentación Requisitos Pruebas, la información que se encuentra almacenada en los casos de uso serán plasmadas en el formato tal como el usuario los insertó, por lo tanto la validez y claridad del documento dependerán del usuario,
3.2 Diagrama de clases de SADUC.
Un diagrama de clases provee la vista estática de un software orientado a objetos, recordando que la programación orientada a objetos es un método de implementoción, en que los programas se organizan como colecciones cooperativas de objetos, cada una de las cuales representa una instancia de alguna clase, y cuyas clases son todas ellas miembros de una jerarquía de clases, unidas mediante relaciones de herencia
Dentro de la arquitectura estática de SADUC se encuentran implementodos patrones de diseño los cuales son mencionados en la siguiente sección. La Figura 3.1 muestra las principales clases de SADUC.
39
Capitulo 3: El modelo conceptual del sistema.
I-
Fig. 3.1 Diagrama de clases de SADUC.
40
Capítulo 3: El modelo conceptual del sistema.
3.2.1 Aspectos de diseño orientados 0 Objetos.
diseño orientado a objetos define una notación y un proceso paro construir sistemas de software complejos, y ofrece un amplio conjunto de modelos lógicos y físicos, con los cuales se pueda razonar sobre diferentes aspectos del sistema que se está considerando.
SADUC utiliza en su arquitectura patrones de diseño debido a las ventajas que los patrones proporcionan al diseño de clases de un sistema de software. Los patrones son un mecanismo de reutilización utilizado en la fase de diseño y uno de los objetivos de los patrones es la creación de un cuerpo de conocimientos, que ayude a los desarrolladores a resolver problemas comunes encontrados a través del desarrollo de sistemas de softWarelam95t.
3.2.2 Uso de patrones de diseño.
3.2.2.1 Composite e lterator.
Gamma recomienda utilizar estos patrones en los siguientes C Q S O S I ~ ~ ~ ~ ~ :
Composite
1 ) Cuando se requiere representar jerarquías de objetos todo-parte. 2) Se quiere ignorar la diferencia entre composiciones de objetos y objetos individuales y trata ambos tipos uniformemente.
iterator IHero31.
1 ) Acceder al contenido de un objeto agregado en estructuras Composite (o simplemente en listas o vectores de objetos) sin exponer la representación interna de dicho objeto.
2) Se quiere proveer múltiples formas de recorrido de listas o vectores de objetos.
3) Proveer una interfaz biforme para realizar los recorridos.
La Fig. 3.2 Muestra los diagramas de clases composite e iterator.
41
-
Fig.3.2 Diagrama de clases de los patrones Composite e Iterator.
Descripción de clases que intervienen en el patrón composite.
Este patrón Permite construir objetos complejos mediante composición recursiva de objetos similares. El patrón Composite también permite que los objetos del árbol sean manipulados Por un manejador consistente, para requerir todos los objetos hay una superclase o un interfaz común. Permite a los clientes tratar de manera uniforme tanto a objetos individuales como a compuestos.
CGrafico LHm031: Representa la clase padre en el patrón composite, es la clase base para los elementos que forman el diagrama de casos de uso que son:
1. Objetos: Actor, Caso de uso, Nota, Paquete. 2. Relaciones: Asociación, Generalización, Inclusión y Extensión.
Esta clase deriva de CObject para obtener los siguientes beneficios: soporte para serealización, disponibilidad de información en tiempo de ejecución, despliegue de información para diagnósticos de objetos, creación dinámica de objetos. Sus principales métodos son: Crearlterator, Dibujar, GetPosicion. SetPosicion. Todas las clases que de ella se derivan tienen su propio método Dibujar ya que cada símbolo debe dibujarse de una manera distinta debido a que son diferentes.
42
Capilulo 3: El modelo conceptual del sistema.
(-Diagrama Hereda de CGrafico y representa Un objeto Compuesto por otros objetos simples que heredan también de CGrafico. De manera intuitiva aterriza la idea de que un diagrama se componga de gráficos n-& simples. Respecto al objeto Iterator, representa el punto de entrada lo estructura de datos del diagrama. Esto es el recorrido de un lterator comienza siempre en el objeto diagrama y prosigue con los objetos almacenados en las estructuras de datos del mismo objeto diagrama. El tipo de lterator que crea CDiagrama se denomina CListlterator, pues la estructura en la que almacena las referencias a otros objetos es una lista lineal doblemente ligada.
CObieto: Deriva de CGrafico, es la clase base para los símbolos: Caso de uso, Actor, Nota y Paquete. La principal función de esta clase es la de obtener y proveer coordenadas que son necesarias para dibujar símbolos gráficos en Pantalla. Sus principales métodos son: GetPunto, Setpunto, GetRect, SetRect, GetMedida, SetMedida.
CCOSOUSO: Deriva de CObjeto y encapsula el comportamiento y estado de la entidad gráfica COSO de uso de un diagrama de caso de USO. Un caso de uso es una Elipse. por 10 que esta clase hace uso de la función Elipse miembro de la Clase CDC (clase Propia de la MFC); esta función recibe un parametro de tipo CRect.
CActor: Deriva de CObjeto, representa la entidad gráfica Actor. E l Actor esta formado por Una elipse y 3 líneas. La cabeza del Actor es la elipse, y las manos, cuerpo y pies son líneas que dan forma a una estructura humana.
CNota, CPaquete: Derivan de CObject, Estos objetos no son fundamentales en un diagrama de casos de uso, pero son importantes para detallar el modelo que se esta realizando; Los símbolos Nota y Paquete están representados gráficamente por un rectángulo.
CRelacion: La clase CRelacion deriva de la clase CGrafico y es la clase base para los diferentes tipos de relaciones que existen en un diagrama de caso de uso como: Asociación, Generalización, Inclusión y Extensión; la función principal de esta clase es la de encapsular comportamiento y estado de los objetos de forma lineal (relaciones).
CRelActorCaso CRelActor CRelCasoUso CRelNota: Estas clases derivan de CRelaciÓn y representan las relaciones permitidas entre los objetos que componen un diagrama de casos de uso.
43
Capitulo 3: El modelo conceptual del sistema.
1. CRelActorCaso: Encapsula el comportamiento y estado de Una relación de Asociación entre actores y casos de uso. 2. CRelActor: Encapsula el comportamiento y estado de una relación de Generalización entre los actores de un diagrama de casos de uso. 3. CRelCasoUso: Encapsula el comportamiento y estado de una relación de Extensión/lnclusiÓn entre casos de uso. 4. CRelNota: Encapsula el comportamiento y estado de una relación de asociación entre los elementos del diagrama de casos de uso (Actor, Caso de Uso y Relaciones) y una Nota.
Closes que intervienen en el patron iterator
lterator define un interfaz que declara métodos para acceder Secuencialmente a los objetos de una estructura de datos
Iterator: Es una clase abstracta parametrizada con apuntadores a objetos de tipo CGrafico. Define en su interfaz los métodos necesarios para recorrer estructuras Composite de tipo CGrafico. E l recorrido de objetos simples se realiza dependiendo del objeto lterator concreto que defina dichos objetos compuestos. El uso de templates de C++ en el patrón de diseño lterator obedece a que la estructura de datos utilizada para definir el patrón Composite también debe ser parametrizada. Cada objeto compuesto es capaz de crear objetos lterator concretos específicos a sus necesidades de recorrido.
CListlterotor: Es una implementación concreta de la clase Clterator. Realiza un recorrido lineal de la estructura de datos del objeto diagrama.
3.2.2.2 Command
Se recomienda usar el patron de diseño Command cuando:
1) Se parametrizan objetos que llevan implícita la acción a ejecutar. 2) Especificar, almacenar y ejecutar peticiones en momentos diferentes.
Un objeto Command puede tener un tiempo de vida independiente de la petición original.
3) Permitir operaciones de deshacer/rehocer. Un objeto Command puede almacenar el estado de ciertas variables para revertir el efecto de las operaciones del objeto realizadas.
44
Capítulo 3: El modelo conceptual del sisiema.
El uso del patrón de diseño Command permite desacoplar las dependencias directas del código de los métodos del objeto Vista que responde a eventos, con cualquier otro objeto involucrado en el proceso de respuestas a eventos. Se puede intercambiar el tipo de comando que se quiera ejecutar desde determinado método del objeto Vista, sin hacer mayor cambio aue el intercambio del constructor adecuado. La Figura 3.3 muestra el diagrama de clases de este patrón de diseño Command.
CCmrnsndLBullonUp CCommandLBullonOblClk
I' Fig.3.3 Diagrama de clases del patrón Command.
Descripción de las clases que intervienen en el patrón de diseño command.
CCommand: Representa la clase padre en el patrón Command, es la clase base para el manejo de los diferentes eventos que se manejan en la interfaz de usuario de SADUC (DobleClic, Clic al botón izquierdo del ratón, Arrastrar y Soltar y Clic sobre suprimir]
CCommandLButtonDown, CommandLButtonDblClick, CommandLButtonKeySupr: Estas clases derivan de CCommand y representan los eventos que se manejan en la interfaz de SADUC.
45
Capítulo 3: El modelo conceptual del sistema.
CCommandLButtonDown: Encapsula el comportamiento y estado del evento de ”presionar el botón izquierdo del ratón”, para seleccionar un símbolo del diagrama o para moverlo y/o redimensionarlo.
CCommandLButtonDblClick: Encapsula el comportamiento y estado del evento “doble-clic”. Determina sobre que símbolo se hizo doble clic y manda llamar al dialogo que corresponde a tal símbolo para modificar sus propiedades.
CCommandLButtonKeySupr: Encapsula el comportamiento y estado del event0 “clic-suprimir”. Determina sobre que objeto presionamos suprimir y Pregunta al usuario si esta seguro de borrar dicho objeto.
3.3 Formalismo aplicado a los diagramas de casos de USO[^'^^^^.
Los trabajos y notaciones existentes difícilmente describen el formalismo utilizado para la construcción de los diagramas propuestos por UML, la Semántica estática de UML es descrita por un lenguaje formal conocido como OCL [The Object Constraint Language), mientras que la semántica dinámica de UML es expresada en lenguajes naturales, por lo que existen problemas que han sido identificados en su semántica, tales problemas son: ambigüedad e inconsistencia.
La presente sección resalta la importancia de los diagramas de casos de uso en el modelado de sistemas de software y como caso específico en la definición de los requerimientos del sistema. Dentro de este punto se definen los elementos que forman parte de dicho diagrama, especificando la gramático que es utilizada como base formal en la construcción de los diagramas de casos de uso de UML. Una gramótica relaciona/ (GR) es la base formal propuesta para la construcción de los diogramos de casos de uso. Por Último se utiliza la gramática relacional obtenida, para desarrollar una aplicación del diagrama de casos de uso.
46
Capiiulo 3: El modelo conceptual del sistema.
3.3.1 Elementos que componen los diagramas de casos de uso.
Normalmente un diagrama de caso de uso contiene los siguientes elementos: Actor: Un actor representa un rol en el sistema. Cualquier entidad que se ajuste a un actor puede actuar como una instancia de un actor. (Ejemplos: una Persona, un subsistema, un servidor, etc).
6 -> 77 Nolmibn:
Caso de uso: Un caso de uso es una secuencia de iteraciones entre un sistema y alguien u algo que utiliza sus servicios. Un caso de uso es iniciado por un actor, a partir de ese momento ese actor junto con otros actores intercambian datos o control con el sistema, participando de ese caso de uso.
c> Notación:
Etiqueta: Representa un nombre significativo para identificar al caso de uso o al actor. R ’ o I ~ c ~ ~ ~ :
Relación1 (asociación): Relación entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado.
Nnlaribn:
Relación2 (extensión): Relación entre dos casos de uso. E l caso de uso origen extiende el comportamiento del caso de uso destino. Sobre la línea que representa esta relación es insertada una etiqueta con el texto <<extend> z el cual lo diferencia de la relación de inclusión.
Ni,IaCióii: . . . - . . . . . .\ r
Relación3 (Generalización): Relación entre dos casos de uso. E l caso de uso origen hereda la especificación del caso de uso destino y posiblemente la modifica y/o amplía.
Notacih,,: * Relación 4(lnclusión): una instancia del caso de uso origen incluye también el comportamiento descrito por el caso de uso destino.
NolariOn: . . . . ~. . . .\ r
47
Copifulo 3: El modelo conceptual del sistema.
3.3.2 Gramática relacional.
Se eligió la gramática relacional para desarrollar la gramática de 10s diogramos de casos de uso ya que consideramos tiene ciertas ventajas en IO especificación de lenguajes visuales con respecto a otros lenguajes visuales como lo es la gramático posicionol, ya que permite definir la relación de un objeto con otro sin importar el número de relaciones entre ellas, y sin importar IO posición espacial de los mismos.
3.3.2.1 Definición de la gramático relacional [Klm981.
La gramático relacional (RGs) es una 6-tuple G(N, C, S, R, Atir, P) donde: 1. N: Es un conjunto finito de símbolos no terminales 2. c: Es un conjunto de símbolos terminales. 3. S: Es un símbolo distinguido en N llamado símbolo inicial. 4. R: Es un conjunto finito de símbolos de relación. 5. Atrr: Es un conjunto finito de símbolos de atributos. 6. P: Es un conjunto de producciones de la forma A-> a/p/F, donde:
A E N; Q E (nlo)' Donde n E N, O E C;
p: Es un conjunto de relaciones de la forma (w) donde r E R y x,y son enteros que hacen referencia a un miembro de a y también una expresión de IO forma (a,¡] donde a E Atrr e i es un entero que hace referencia a un miembro de a. F: Es un conjunto de declaraciones de asignación de características de la forma (a, O)=x donde a E Atrr y x es un entero que hace referencia a un miembro de a o a una expresión de la forma (a, i).
3.3.3 Aplicación de la gramática relacional para la construcción de los diagramas de caso de uso.
Para desarrollar la gramática de los diogramos de casos de uso es necesario definir los elementos de la misma, quedando de la siguiente forma:
G=(N, C,S, R. Attr, P) N= Diagrama
S=Diagrama R= Asociacion,Generalizacion,lnclusion,Extension Attr=in, out
48
Capítulo 3: El modelo conceptual del sisiema.
3.3.3.1 Reglas de producción.
P =( 1.Diagrama. ,_~_ : 2 Diagrama -f .y. 1 ......
(Asociación 1 (in 2)+) ,' ~
2.R.Actores.
(Generalización l( in 2)') 3.R.CasosUsos. R.CasosUsos + T j :..-..J. 2 (inclusión i(in 2)') (Extensión 2(in 1)') (Generalización l(in 2)')
R.Actores. + y 1 ,,3 2
, -.,
1
3.3.4 Construcción de un diagrama de casos de. uso aplicando las reglas gramaticales.
Aplicando las reglas gramaticales descritas en la sección anterior, construiremos paso a paso un diagrama de casos de uso para un SRBTJ "Sistema para el control de una maquina' recicladora de botellas, tarros y jabas.
Características del Sistema.
Registrar el número de Artículos o ítems ingresados. Los artículos o ítems registrados pueden ser: botellas, tarros o jabas'.
Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. E l valor de cada artículo. c. Total.
Existe un operador que desea saber lo siguiente: a. Cuántos Artículos han sido retornados en el día. b. AI final de cada día el operador solicita un resumen de todo lo
depositado en el día.
El operador debe además poder cambiar a. Información asociada a los Artículos
' Las jabas son un tipo especial de botellas
49
Capítulo 3: El modelo concepiual del sistema.
Desarrollo del Ejemplo: (Diagrama, 0)
1. El cliente registra el número de Artículos ingresados: para este primer punto, Aplicamos la regla de Asociación entre un Actor (Objeto 1 ) y caso de uso (Objeto 2)
Producción derivada de la regla num. 1:
(Asociación 1 (in 2)))
Obtenemos:
Fig.3.4 Diagrama derivado del punto I
2. El cliente (objeto 1 ) y el operador (objeto 2) realizan impresiones de información, por lo que imprimir (objeto 3) es un caso de uso que incluye o usa a otros casos de uso como lo son la generación de reportes (Objeto 4) y el depósito de artículos (Objeto 5).
Producción derivadas de las reglas 1,2 y 3
(Asociación 1 (in 3)), (Asociación 2 (in 3)), (inclusión 3 (in 4)), (Inclusión 3 (in 5)))
50
Capifulo 3: El modelo concepfual del sisfema.
Obtenemos:
I \ I ,. (d Operador Depositar Hem
Fig. 3.5 Diagrama derivado del punto 2.
3. E l cliente puede realizar tres tipos de depósitos de ArtÍculos [objeto 1): depósito de botellas (Objeto 2), de tarros[Objeto 3) y de jabas(0bjeto 4) , por lo que depósito de artículos extiende a 3 casos de uso.
Producción derivada de la regla 3.
(Extensión 2 (in i)), (Extensión 3 (in i)), (Extensión 4 (in I)) )
Obtenemos:
51
Capíiulo 3: El modelo conceptual del sisiema.
4. Por Último tenemos que el operador (Objeto 1) genera los reportes (Objeto 2) y realiza cambios de artículos (Objeto 3).
Producción derivada de la regla 1.
(Asociación 1 (in 2)), (Asociación 1 (in 3)))
Obtenemos:
C a m b i a r I t e m s
Fig. 3.7 Diagrama derivado del punto 4.
Diagrama Final:
Cupifulo 3: El modelo conceptual del sistema.
3.4 Desarrollo del documento Requisitos-Pruebas.
Unas de las características principales de SADUC es permitir 01 desarrolmor de software describir conjuntos de casos de prueba Por cada requisito especificado en su modelo de casos de uso y obtener la d0CUmentaCiÓn de requisitos y de pruebas del software. En este apartado se describe el estándar seleccionado, la base de datos diseñada y el uso del reporteador Crystal Report par la generación del documento Requsitos-Pruebas de SADUC.
Es importante responder a las siguientes preguntas. ¿Qué estándar de documentación de pruebas utiliza SADUC para especificación de casos de prueba?, ¿Cómo genera SADUC el documento Requisitos Pruebas? Y ¿Cómo esta diseñada la base de datos que almacena la informa&n de los requisitos y las pruebas?. En el transcurso de este apartado se dará respuesta a cada una de estas preguntas.
Antes de dar respuesta a las preguntas planteadas, es importante mencionar las propiedades del modelo de cusos de uso y responder a la siguiente pregunta "¿por qué utilizar casos de uso para modelar requisitos y no otro diagrama?", IO respuesta es: porque los casos de uso proporcionan un medio sistemático e intuitivo para capturar requisitos funcionales, centrándose en el valor añadido para el usuario y el modelo de casos de uso se utiliza para conseguir un acuerdo con los usuarios y clientes a cerca del funcionamiento del sistema.
El diagrama de casos de uso cuenta con las siguientes propiedades Mco31:
1 . Son un vehículo muy eficaz para capturar, organizar y visualizar requerimientos.
2. Representan el fundamento para una definición no ambigua de los requerimientos funcionales.
3. Son muy útiles para delimitar claramente el comportamiento de un sistema.
4. Representan un lenguaje de comunicación eficaz entre clientes y desarrolladores.
5. Son el punto de partida para prototipar y diseñar las interfaces gráficas de usuario y las interfaces de comunicación con sistemas externos.
6. Su revisión permite una comprensión detallada de la funcionalidad global de una aplicación.
53
Capítulo 3: El modelo conceptual del sistema.
7. pueden acotarse 10s niveles de acceso a la información Y las capacidades de manipulación, con lo que se define de manera Precisa la habilitación de cada usuario que interactúa con el sistema.
8. La gestión del riesgo de un proyecto es mucho más eficiente debido a su capacidad de hacer más visible la complejidad de una aplicación.
9. Facilitan una estimación más exacta de los recursos necesarios para implementor cada pieza funcional del proyecto.
10. Son 10s piezas clave para controlar el desarrollo de un proyecto en lotes de implementación dentro de un Plan Director de Iteraciones.
1 1 . Sus especificaciones son ceriificables por los agentes internos y externos del proyecto con respecto a su coherencia, completitud y usabilidad en la aplicación.
12. Facilitan la elaboración de documentación de la aplicación: Helps, Manuales de Usuario y Administrador, además de los Manuales de Procedimientos orientados a la calidad.
13. Introducen elementos trazables para las pruebas y la garantía de calidad del software desarrollado.
14. Son la base a partir de la cual podemos averiguar los objetos que configurarán el sistema y cómo interactuarán en los distintos escenarios posibles y escenarios probables.
15. Permiten la definición del comportamiento de los objetos y componentes a través de sus interfaces y facilitan la descomposición del sistema en una arquitectura de n capas.
16. Son una herramienta excelente para implementor un seguimiento real entre requerimientos, análisis, diseíio e implementación.
17. Suministran una vista dinámica del sistema a la manera de una red semántica desde donde es posible invocar cualquier funcionalidad y comprobar sus vinculaciones.
18. Se han convertido en el estandar de facto para describir los flujos de trabajo asociados a los procesos de negocio.
19. Facilitan la abstracción de patrones y frameworks de funcionalidad reusables dentro de un mismo proyecto, o bien de manera transversal, en múltiples proyectos de dominios distintos.
54
Copítulo 3: El modelo concepiirol del sistema.
Ahora ya conocemos por qué es importante y útil el diagrama de casos de uso, como medio para capturar, especificar y analizar requisitos de software.
3:4.1 Estandar para la documentación de casos de prueba.
E l estándar 829-1 998 de la IEEE se aplica en SADUC para documentar casos de prueba'. E l estándar 829 es un estándar para la documentación de pruebas de software y tiene como propósito prescribir el alcance, enfoque, recursos y calendario de las actividades de prueba, para identificar los artículos y las características que se probarán, las tareas de pruebas que serán efectuadas, el personal responsable para cada tarea y los riesgos asociados con el plan de pruebas.
Un plan de prueba debe tener la estructura siguiente:
ldentificador del plan de pruebas. Introducción. Casos de prueba. Características a ser probadas. Enfoque. Criterio posalno-pasa de los casos de prueba. Criterio de suspensión y requisitos de continuación Pruebas de liberación. Tareas de prueba. Nécesidades am bientales. Responso bilidades. Necesidades de entrenamiento y asesoría. Calendario. Riesgos y Contingencias. Aprobación.
De acuerdo al estándar 829 un plan de pruebas debe considerar los puntos arriba mencionados, para los objetivos de SADUC nos enfocamos al inciso (c) que son la especificación de casos de prueba.
Una especificación de casos de prueba debe tener la siguiente estructura:
a) Identificación de la especificación del caso de prueba. b) Artículos de Prueba. c) Especificación de Entrada. d) Especificación de salida.
' L a iiiforniacion del cstáiidar fuc proporcionada por el Dr. Rciie Santa Olnlla dcl grupo (IC lngcnicria dc soltwarc dci ccnidct.
55
Capitulo 3: E l modelo concepiual del sisiemo.
e) Necesidades ambientales. 9 Requerimientos procedurales especiales. g) Dependencias entre casos.
En el próximo capítulo se explica cada uno de estos inCiSOS Y Como son manejados por SADUC.
Por el momento SADUC solo contempla en la especificación de casos de prueba los primeros 4 incisos 3(ldentificaciÓn del caso de prueba, artículos de prueba y las especificaciones de entrada y salida).
Conociendo la estructura de un caso de prueba el otro aspecto a considerar es cómo almacenarlos en una base de datos, de tal forma que podamos recuperar la información en el momento que se requiera, y plasmar dicha información en el documento Requsitos Pruebas. Quizás se hagan la Pregunta del por qué no generar un documentode requisitos y un documento de pruebas por separado?, habíamos considerado dicha posibilidad, pero después de analizarlo se llegó a la conclusión que era más fácil y manejable para el usuario tener un solo documento, ya que de la especificación de requisitos, solo necesitamos como datos para el documento, el nombre o indentificador de requsitos y una descripción de este, en dado caso que el usuario haya hecho tal descripción.
El documento Requisitos - Pruebas de SADUC contiene los siguientes datos4.
a) ldentificador del Requisito b) Nombre del Requisito c) Artículos de Prueba. d) Especificación de Salida e) Especificación de Entrada. f) Descripción.
De acuerdo con estos datos fue creada una base de datos en Access con el nombre "BüRequisite", la cual esta compuesta de 3 tablas: tblrequisitos, tblarticulos y tblpruebas. Cada una con sus campos correspondientes.
' Se esta dcsarrollando una nueva vcrsiún dc SADUC en la quc ya no sc usa cl rcportcador Crystal Rcport, y donde se coiilemplarán todos los incisos del estándar.
Se encuentra una explicación dclallada cn el próximo capitulo.
56
Capítulo 3: El modelo conceptual del sisterno.
idr ida articulos
TBLREOUISITO:
Texto Identificador Requisito Texto Identificador Articulo Texto Articulos
idr nombre Texto Nombre Requisito descripcion Texto Descripcion
ida eentrada esalida
Tabla 3.1 Estructura de tblreouisito.
Texto Identificador Articulo Texto Especificación de entrada Texto Especificación de salida
Tabla 3.2 Estructura de tblraniculos.
Estas tablas están relacionadas por una relación de una a muchas, el diseño de estas relaciones es mostrada en la figura 3.9.
57
Capítulo 3: El modelo concepiudl del sisiema.
" .
Figura 3.9. Disefio de las relaciones de la tabla BDRequisite.
Antes de explicar las relaciones entre las tablas de BDRequiste, se deben considerar los siguientes puntos:
1 . Un requisito puede tener un conjunto de casos de prueba. 2. Un caso de prueba puede tener un conjunto de artículos a
probar. 3. Un artículo de prueba puede tener un conjunto de
especificaciones de entrada. 4. Un artículo de prueba puede tener un conjunto de
especificaciones de salida. 5. Una especificación de entrada puede tener diferentes
especificaciones de salidas 6. Una especificación de salida puede tener un conjunto de
especificaciones de entrada.
58
Capíiulo 3: El modelo conceptual del sistema.
Por lo tanto las relaciones entre las tablas de la base de datos BDRequisfe se encuentran de la siguiente manera: la tabla fblrequisito tiene una relación de una a muchas con la tabla tbL4articulos y a su vez la tabla tblArticulo tiene una relación de una a muchas con la tabla tblpruebas tal como se muestra en la figura 3.9.
El documento Requisitos-Pr~ebos~ fue diseñado en Crystal Report versión 8.5. Crystal Report es una herramienta poderosa para diseñar diferentes tipos de reportes para diferentes necesidades. Dentro de las plantillas que contiene se encuentran: reportes estándar, reportes en forma de cartas, reportes en forma de tablas, reportes para etiquetas de e-mails y demás.
Crystal Report da oportunidad al usuario de crear reportes personalizados, como es el caso del documento Requisito Pruebas que fue un diseño personalizado. Para usar Crystal Report es necesaio configurarla para conectarla a la base de datos donde se encuentra la información que sera mostrada en el documento diseñado, y para que sea posible actualizar dicha información cada vez que la información de la base de datos sea modificada.
3.5 Referencias.
[Her031 Hernandez Velázquez Miguel.. "Ingeniería Inversa de código fuente en c+ + para la obtención de su diseno, tesis de maestría. agosto 2003.
Kim Marriot, Bernd Meyer. Visual Languaje Theory Springer-Verlag New York. 1998.
[Kim981
[Gam951 Gamma Erich. Design Patterns-Elments of reusable Object Oriented Software. E.U Addison-Wesley-tongman, 1995.
[ViCO3] Vico.org, Especiticaciones con casos de uso www.vico.org.
El diseíio del documcnto Requisito-Pr~iebas sc c~icucntri~ cii cI capitulo 4 scccióii 4.3
59
CAPíTULO 4
DESARROLLO Y PRUEBAS DE LA H E RRAM I E NTA
4.1 Características funcionales de SADUC. 4.2 Manejo de la interíaz gráfica de usuario. 4.3 Pruebas. 4.4 Referencias.
Capítulo 4: Desorrollo y pruebas de la herramienia.
Introducción.
Este capítulo tiene la finalidad de dar a conocer la funcionalidad de SADUC, para lograr este objetivo es necesario explicar los siguientes puntos: La interfaz gráfica de usuario, especificando cuales son los elementos que proporciona SADUC al desarrollador para modelar requisitos de software, que condiciones tiene que cubrir el desarrollador para obtener dicho modelo y poder generar el documento Requisitos-Pruebas, además establecer las restricciones de SADUC en términos de lo que el usuario puede y no puede hacer con este ambiente visual. Por último para tener un mejor entendimiento de cómo modelar requisitos de software con SADUC, se presentan dos casos de estudio mediante los cuales se verifica su funcionamiento y la validez de la hipótesis de esta tesis.
4.1 Características funcionales de SADUC.
SADUC debe ser capaz de cubrir las siguientes funcionalidades:
1 . Modelar requisitos funcionales. 2. Ayudar al desarrollador a llegar a un acuerdo común con el cliente
3. Crear casos de prueba por cada requisitos especificado. 4. Generar el documento Requisitos - Pruebas.
sobre lo que debe de hacer el sistema a construir.
SAUDC cuenta con estas funcionalidades, por las siguientes razones:
Modelar requisitos funcionales: La técnica inmediata para identificar los requisitos del sistema se basa en los casos de uso, los casos de uso proporcionan un medio intuitivo y sistemático para capturar los requisititos funcionales, esto es debido a que los requisitos funcionales se estructuran de forma natural mediante casos de uso [JOcOO1. Por lo que el desarrollador de software puede utilizar a SADUC para modelar requisitos funcionales.
Ayudar al desarrollador a llegar a un a cuerdo común con el cliente: E l modelo de casos de uso permite que los desarrolladores de software y los clientes lleguen a un acuerdo sobre los requisitos. Cada usuario quiere que el sistema haga algo para el o para ella, es decir, que lleve a cabo ciertos casos de uso. Para el usuario, un caso de uso es un modo de utilizar el sistema. En consecuencia, si los analistas pueden describir todos los casos de uso que necesita el usuario, entonces saben lo que debe hacer el sistema (Jcicool.
61
Capitulo 4: Desarrollo ypruebas de la herramienta.
c) Crear casos de prueba por cada requisito: Parece razonable establecer una estrategia sistemática para probar el software. En un proyecto de software, las pruebas a veces requieren más esfuerzo que cualquier otra actividad de la ingeniería de software, si se efectúan sin un plan, el tiempo se desaprovecho y el esfuerzo es consumido innecesariamente y, en el Deor de los casos, los errores inadvertidos quedarán sin detectar [Pieoil, los casos de uso permiten especificar casos de prueba y un caso de prueba debe especificar entradas, resultados esperados y otras condiciones relevantes para verificar un requisito funcional .
Generar el documento Requisitos-Pruebas: Si los casos de us0 nos permiten especificar requisitos funcionales de software y diseñar casos de prueba por cada requisito, el siguiente paso es crear un formato para plasmar esta información que ayudara a organizar cada uno de los requisitos y permitirá seguir los cambios que se presenten en el modelo, ya que cada documento generado tendrá la fecha en que fue generado y por consiguiente las últimas modificaciones hechas al modelo. Por lo que el documento Requisitos Pruebas de SADUC contiene la información más importante de los requisitos del software.
La primera actividad que debemos desarrollar con SADUC es modelar requisitos funcionales de software: no podemos generar casos de pruebas si no tenemos el modelo de requisitos, y tampoco podemos generar el documento Requisitos - Pruebas si no tenemos las dos últimas actividades desarrolladas,
E l análisis de requisitos es la primera fase técnica del proceso de ingeniería de software. En este punto se refina la declaración general del ámbito del software en una especificación concreta que se convierte en el fundamento de todas las actividades siguientes de la ingeniería de softwarel”ea’l, de acuerdo a la ingeniería de requisitos antes de pasar al análisis de requisitos debemos identificar estos requisitos mediante alguna técnico de obtención de requisitos, una vez identificados los requisitos podemos pasar al siguiente punto que es el análisis y posteriormente especificar los requisitos mediante los diagramas de casos de uso: es importante considerar los pasos del proceso de ingeniería de requisitos, dando a conocer al usuario de SADUC que para modelar requisitos de software, se debe haber cubierto una primera etapa que es la captura e identificación de requisitos con los clientes y usuarios del software.
¿Cómo podemos asegurar que hemos realizado una correcta especificación de requisitos?
No hay una respuesta segura a esta pregunta, pero un sólido proceso de ingeniería de requisitos es la mejor solución que se dispone actualmente ,PreO,l.
62
Capitulo 4: Desarrollo y pruebas de la herramienta.
Un proceso de ingeniería de requisitos es descrito en los siguientes POSOS
1. Identificación de requisitos: Investigar las necesidades el cliente, cómo los sistemas o productos se ajustan a las necesidades del negocio, y finalmente, cómo el sistema o producto va ser utilizado.
2. Análisis y negociación de requisitos: Se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, Completes y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios.
3. Especificación de requisitos: Una especificación puede ser un documento escrito, un modelo gráfico, un modelo matemático formal, una colección de escenarios de uso, un prototipo o una combinación de lo anteriormente citado.
4. Validación de requisitos: La validación de requisitos examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el producto.
5. Gestión de requisifos: La géstión de requisitos es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento.
SADUC ayuda 01 desarrollador en el proceso de ingeniería de requisitos permitiendo al desarrollador modelar requisitos funcionales que antes fueron capturados y analizados, además de permitirle validar los requisitos, creando casos de prueba para cada uno de ellos.
63
Capirulo 4. Desarrollo y pruebas de la herrarnienfa.
4.2 Manejo de la interfoz gráfico de usuario.
La figura 4.1 muestra algunas funciones que se encuentran integradas en la interfaz gráfica de SADUC.
Usuario
,--...-.ir- - -.*--.-.- f .Inscrl?r’nombre 1 ,~ i Especificar ~ . tipos de relaciones ’ 1 , [ k c ? d ; 1)
entre los elementos del diagrama *t del casu de uso ’
P..--.--’-
IniDrimir Archivo 1
c..”-- ->-- iL Modificar Archivo J
Fig. 4.1 Funciones integradas en la GUI de SADUC
Cada una de estas funciones serán comentadas ampliamente en posteriores secciones de este capítulo.
AI ingresar a SADUC, se presenta una pantalla inicial que muestra el nombre del provecto y una pequeña imagen de un diagrama de casos de uso. tal como se muestra en la Figura 4.2
64
59
Capitulo 4: Desarrollo y pruebas de la herramienta.
............................................ i Menú i principal ....
........................................................ ; Barrademenú ~
PI0 J ,I. rornol rea dr modelado .---_.m.
. . . . .. .... ......... i / . . . . . . ........................................
. . . . . . . . . ;... .... . . . . . . . . ........................... ,..., _ .... ! Barrade : herramientas j
.... ........ ............. .. <:. ...
...... i Barrade ~ Barradeestado ..............................................
.,.: desplazamiento ..
..................................................................................................
Fig. 4.3 lnterfaz grkfica de usuario.
Barra de menú: Es la barra de menú que proporciona Visual C++ a los proyectos que fueron creados en el, el cual contiene los rnenús estandar Archivo, Edición, Ver, Ventana y Ayuda, en dónde el usuario podrá usar cada una de las opciones que son desplegadas en cada menú, excepto las opciones del menú Edición que están deshabilitadas. De forma predeterminada, al iniciar SADUC se presenta la barra de menú, es posible activar o desactivar esta barra de acuerdo a lo que el usuario requiera.
Barra de herramientas: Proporcionan un rápido acceso a los elementos usados en un diagrama de casos de uso. Seleccione un objeto ya sea actor, caso de uso, relación u otro objeto que se requiera de la barra y arrástrelo al area de modelado para insertarlo en el modelo que se esta desarrollando. De forma predeterminada, al iniciar SADUC se presenta la barra de herramientas de casos de uso. No es Dosible activar o desactivar esta barra de herramientas.
..... .....
66
Capiriilo 4 Desorrollo y pruehus de lu herrunirentu.
Área de modelado: Como su nombre lo indica es el área en dónde el usuario puede realizar el modelo de caso de uso, las actividades que el usuario puede llevar a cabo en el área de modelado son: Agregar objetos, relacionar objetos, modificar tipo de relaciones insertar nombre de objetos, modificar nombre de objetos, eliminar objetos, mover objetos, e insertar casos de prueba.
Barra de estado: A traves de la barra de estado se muestra en forma textual la acción que se esta desarrollando en ese momento.
4.2.1 Modelando con SADUC.
¿Cómo modelamos requisitos con SADUC?: En forma general para desarrollai un modelo de casos de uso debemos llevar a cabo las siguientes tareas’:
1 . Identificar requisitos. 2. Identificar actores 3. Identificar casos de uso. 4. Identificar relaciones entre casos de uso.
Cuando contemos con esta información los otros pasos a desarrollar son:
5. Crear el modelo de casos de uso con SADUC. 6. Crear casos de prueba por cada requisito. 7. Generar el documento Requisitos - Pruebas.
En la figura 4.4, se describe mediante un diagrama de casos de uso los pasos que se requieren para modelar los requerimientos de un sistema de software con SADUC.
No podemos crcar un modelo de casos de uso, si antes no han sido idcntificados, los actores del sistema, los I
casos dc uso y las rclaciones entre ellos.
67
Capitula 4: Desarrollo ypruebas de la herramienta.
F1. Identificar requisitos casos de uso
F5,Crear el modelo de casos de uso
Desarrollador de
F2. Identificar actores
sistemas software
/
F6.Crear casos de prueba por cada requisito. F3. Identificar casos de uso
F7. Generar el documento Requisitos-Pruebas.
Fig. 4.4 Diagrama de casos de uso para modelar con SADUC.
A] Caso de Uso: Identificar requisitos Identificador: F1
F I . I d e n t i f i c a r i e q u i i i t a s U 5" ar io
Fig. 4.5 Caso de uso identificar requisitos.
Descripción: Este caso de uso es iniciado por el usuario (analista de sistema o desarrollador) y tiene como finalidad identificar los requisitos del sistema de software a desarrollar. Luego de haber obtenido la lista de requisitos, estos deberán ser clasificados en dos grupos (powo21: requisitos funcionales y requisitos no funcionalesz.
En el capítulo 2 encontraremos las definiciones de: requisitos funcionales y no funcionales 2
68
Capíiulo 4: Desarrollo y pruebas de la herrarnienfa.
B) Caso de Uso: Identificar actores. Identificador: F2
Fig. 4.6 Caso de uso identificar actores
Descripción: Este caso de uso tiene el objetivo de encontrar e identificar actores del sistema. Para encontrar actores del sistema se puede buscar en las categorías de personas, otro software, dispositivos de hardware o redes de computadoras.
C) Caso de Uso: Identificar casos de uso. ldentificador: F3
F 3 . I d e n t i f i c a r c a r o s d e " $ 0
.A U su a ,io
Fig. 4.1 Caso de uso identificar casos de uso.
Descripción: Este caso de uso tiene la finalidad de encontrar casos de uso. El analista de sistemas va repasando los actores uno por uno y proponiendo los casos de uso para cada actor, los casos de uso deben mostrar lo que el usuario necesita del sistema. Hay que recordar que se intenta crear casos de uso fáciles de modificar, revisar y probar
D) Caso de Uso: Identificar relaciones entre casos de uso. Identificador: F4
usva rio F4. lden ti fica r re la cio nes en t e casos de uso
Fig. 4.8 Caso de uso identificar relaciones.
69
Capiiulo 4: Desarrollo ypruebas de la herrarnienla.
Descripción: En esta actividad se identifican, en base a las especificaciones de casos de uso. las relaciones inclusión y extensión entre casos de uso.
E) Caso de Uso: Crear modelo de casos de uso. Identificador: F5
objetos t i ~ o s d e relación
F5.2 Relac ionar obietos F5.5 Moverobjetos
u F5.3 N o m b r a r objetos
u F5.6 Borra objetos
Fig. 4.9 Caso de uso crear modelo de casos de uso.
Descripción: Este caso de uso tiene la finalidad de usar la información generada en las actividades antes mencionadas para realizar el modelo de casos de uso con SADUC, el usuario realiza dicho modelo insertando elementos en el área de modelado, asignándole nombres a los objetos insertados, relacionando los objetos de acuerdo a las relaciones permitidas en el diagrama de casos de uso.
E . l ) Caso de Uso: Insertar objetos, Identificador: F 5 . 1
Fig. 4.10 Caso de uso identificar requisitos.
70
Capífulo 4: Desarrollo ypruebas de la herramienta.
Descripción: Este caso de uso es iniciado por el usuario de SADUC y tiene la finalidad agregar objetos (actor, caso de uso, relaciones) al área de modelado. El usuario debe seleccionar el objeto requerido de la barra de herramienta y arrastrarlo al área de modelado.
E.2) Caso de Uso: Relacionar objetos. Identificador: F5.2
Fig. 4.1 I Caso de uso relacionar objetos.
Descripción: Este caso de uso es iniciado por el usuario y tiene la finalidad de relacionar (relación entre actor y casos de uso y relación entre casos de uso) elementos del diagrama de casos de uso. El usuario selecciona el tipo de relación que requiera de la barra de herramientas, presiona con el puntero del mouse al objeto origen y arrastra la relación hacia el objeto destino.
E.3) Caso de Uso: Nombrar objetos. Identificador: F5.3
Fig. 4.12 Caso de uso nombrar objetos.
Descripción: Este caso de uso es iniciado por el usuario de SADUC y tiene la finalidad de asignarle un nombre a cada uno de los elementos del modelo de casos de uso que se esta modelando. El usuario selecciona el objeto puntero de la barra de herramientas, selecciona con el puntero el objeto al que se le asignará un nombre, da doble clic sobre el, aparece un cuadro de dialogo correspondiente 01 objeto y le asigna un nombre al objeto colocándolo en io caja de texto correspondiente.
71
Capíiulo 4: Desarrollo y pruebas de la herramienia.
E.3.1) Caso de Uso: Insertar nombre a un caso de uso. Identificador: F5.3.1
F5 3 1 Inieflarnombre d e un caso de up>
Fig. 4. I3 Caso de uso nombrar caso de uso
Descripción. Este caso de uso es una extensión de caso de uso nombrar objetos y tiene la finalidad de asignarle un nombre a un caso de uso. El nombre del caso de uso a menudo comienza con un verbo yOcOol.El usuario debe seleccionar un caso de uso con el puntero, dar doble clic sobre el, inmediatamente después aparecerá una caja de dialogo correspondiente ai caso de uso, tal como se muestra en la figura 4.1 3.1.
Fig.4.13.1 Nombrar caso de uso
12
Capitulo 4: Desarrollo y pruebas de la herramienta.
E.3.2) Caso de Uso: Insertar nombre a un actor. Identificador: F5.3.2
Fig. 4.14 Caso de uso nombrar actor.
Descripción. Este caso de uso es una extensión del caso de uso nombrar objetos y tiene la finalidad de asignarle un nombre a un actor. El usuario debe seleccionar un actor con el puntero, dar doble clic sobre el, inmediatamente después aparecerá una caja de diálogo correspondiente al actor, tal como se muestra en la figura 4.14.1.
Fig. 4.14.1 Nombrar actor.
73
Capitulo 4: Desarrollo y pruebas de la herramienta.
E.4) Caso de Uso: Modificar tipos de relación. Identificador: F5.4
F 5 4 M o d l f i s a r I i p o % d e r e I r s i 6 n Y s u s r 1 0
Fig. 4.15 Caso de uso modificar relación.
Descripción: Este caso de uso es iniciado por el usuario y tiene la finalidad de modificar el tipo de relación entre elementos del diagrama de casos de uso. Los tipos de relaciones que aparecen en la barra de herramientas de SADUC son:
1 . Relación entre actores. 2. Relación entre actores y casos de uso. 3. Relación entre casos de uso: Este último puede ser de Inclusión y Extensión o Generalización, el valor por definición para este tipo de relación es de Extensión. Para poder asignar relaciones de Inclusión y Generalización a casos de uso, es necesario seleccionar la relación asignada y presionar doble clic sobre este, aparecerá una caja de dialogo "tipos de relación entre casos de uso", en la cual el usuario podrá seleccionar el tipo de relación que desee tal como se muestra en la figura 4.1 5.
L*kQW ................................... . . . . . . . . . . . . . . . . . . . . . . . .
^I I 'I ................................................................. I '!
A ! ! !
"
i Caja de dia1ogo"tip ~ de relaciones entre
........ casos de uso" ....... ......
i: ........................................................ ......
"."..lo
. . . . ,p' ...... .... ..... _-"- , B~ ".*..e; 1 L LL I ~..- ."-.j _ _
Fig.4.15.1 Modificar relación.
74
Ca&ulo 4: Desarrollo Y pruebas de la herrarnienla
E S ) Caso de Uso: Mover objetos. Identificador: F5.5
o F 5 5 M o r e r a b i s t o s
77 Y t" * , I O
Fig. 4.16 Caso de uso mover objetos
Descripción: Este caso de uso es iniciado por el usuario de SADUC y tiene la finalidad mover un objeto en un área diferente. E l usuario debe seieccionar el objeto con el puntero de io barra de herramientas y arrástralo a la nueva posición que desee.
E.6) Caso de Uso: Borrar objetos. Identificador: F5.6
Fig. 4.17 Caso de uso borrar objetos
Descripción: Este caso de uso es iniciado por el usuario de SADUC y tiene la finalidad de borrar un objeto insertado en el área de modelado. El usuario debe seleccionar el objeto con el puntero de la barra de herramienta y oprimir la tecla <Del> o <Suprimir>, si el objeto se encuentra relacionado con otro objeto este también será eliminado; cuando el usuario oprima dichas teclas SADUC preguntará si el usuario se encuentra seguro de borrar el objeto seleccionado: ver figura 4.1 7.1 .
75
Capítulo 4: Desarrollo y pruebas de la herramienta.
. . . . _ . . . . . . . . . . . ,,culo . [nr"wl"*; . . . . . . . . . . . . . . . . ~ . . .
..............................................
Fig.4.17.1 Borrar objeto.
F) Caso de Uso: Crear casos de prueba por requisito. Identificador: F6.
Fig. 4. I8 Caso de uso crear casos de prueba.
76
CaDíiuío 4: Desarrolla v Druebas de la herramienta.
Descripción. Este caso de uso es iniciado por el usuario de SADUC y tiene la finalidad de crear casos de prueba por cada requisito especificado en el modelo de casos de uso. Un caso de prueba esta compuesto por artículos a probar, especificaciones de entrada y especificaciones de salida. El usuario presiona clic sobre el caso de uso que desee especificarle un caso de prueba, inmediatamente después aparece la caja de dialogo correspondiente al caso de uso, en dónde el usuario doró clic al botón describir prueba, después será mostrada la caja de dialogo correspondiente a las pruebas tal como se muestra en la figura 4.1 8.1.
F.l) Caso de Uso: Insertar artículo. Identificador: F6.1
Fig. 4.19 Caso de uso insertar artículo.
Descripción. Este caso de uso esta incluido en el caso de uso crear caso de prueba, tiene la finalidad de agregar artículos a probar en un caso de prueba. Un artículo de prueba puede ser un módulo de código, una interfaz gráfica, u otra unidad del software que sea factible probar. F.2) Caso de Uso: Especificar entradas.
Identificador: F6.2
F6.2 Erpeulicar entradas US"afl0
Fig. 4.20 Caso de uso especificar entradas.
Descripción. Este caso de uso esta incluido en el caso de uso crear caso de prueba, tiene la finalidad de agregar entradas de prueba. Una entrada de prueba puede ser: datos numéricos y datos tipo cadena.
CaDiluio 4: Desarrollo v Druebas de la herramienia.
F.3) Caso de Uso: Especificar salidas. Identificador: F6.3
F 6 . 3 E i ~ e c ~ i f i c a r % a l i d a s /'\ U ," 8 ,,o
Fig. 4.21 Caso de uso especificar salidas.
Descripción. Este caso de uso esta incluido en el caso de uso crear caso de prueba, y tiene la finalidad de especificar las salidas de las entradas insertadas. Una salida puede ser: datos numéricos, datos tipo cadena.
. . . . . . . . . . . . . . . . . . . .
...... i I ..5-.?%'.!z!?-!.eJ - 5 2 I u-- B, ...... ............................ ___
~ pruebas ......................... ...... ....- ..........................
, /;SF..... ..........
". . . . . . . . I I< I ._.I_I -.-.-. .I-.-. . . . . ......-....- . . . . . . . . . . . . i l *.?^CL._ ......................... . . . O)"m>. w.. , L O . . . . . . . . . .
Pi&. 4 18 I Especificar casos de prucha
En la figura 4.1 8.1 Muestra un caso de prueba en donde: El requerimiento a ser probado es: Vender E l artículo de prueba es un módulo de software: módulo 1 La especificación de entrada son datos numéricos: 100, 100 La especificación de salida es un dato numérico: 100
78
Capítulo 4: Desarrollo y pruebas de la herramienta.
G] Caso de Uso: Generar el documento Requisitos - Pruebas. Identificador: F7.
F I G e n e r a r d o c u r n s n l o R e qui B 1-y. P RI eba U IUBr lo
Fig. 4.22 Caso de uso generar documento.
Descripción: Este caso de uso es iniciado por el usuario de SADUC y tiene la finalidad de generar el documento Requisitos Pruebas. El usuario debe seleccionar el botón generar documento de io barra de herramientas, enseguida aparecerá el documento Requisitos-Pruebas con la información de los requisitos del sistema con los casos de prueba especificados.
..... ....
,- .".- . DOCUi\IIKTO D I RiQUIslTOS-PRLXBAS Err. 829-1998 "rrt
DI PRliIM
Fig. 4.22.1 Generar documento.
79
Capífulo 4: Desarrollo y pruebas de la herraniienia.
4.3 Pruebas.
El objetivo de las pruebas, expresado en forma sencilla, es encontrar el mayor número posible de errores, con una cantidad razonable de esfuerzo íPreO’l. En esta sección se presentan dos casos de estudio que tienen la finalidad de probar la funcionalidad de SADUC y de constatar la validez de la hipótesis de esta tesis que es: Mediante el uso de diagramas de casos de uso se pueden modelar partes de un sistema de sofhvare y obtener el documento de requerimiento y el docurnento de casos de prueba. Además se explica cómo usar a SADUC en el modelado de requisitos de software y en la especificación de casos de prueba con el estandar 829 de la IEEE.
En cada caso de estudio aplicado a SADUC se realizarán las siguientes actividades.
1 . Crear modelo de casos de uso 2. Especificar casos de prueba por cada caso de uso. 3. Obtener el documento Requisitos - Pruebas.
En cada caso de estudio fue creada una lista de requisitos funcionales para generar el modelo de casos de uso y una lista de casos de prueba para generar el documento Requisitos-Pruebas. Las listas de casos de prueba especificados por cada caso de estudio, son listas que solo especifican casos de prueba para ciertos requerimientos, debido que no es posible contar con todas las pruebas al inicio, ya que el modelo de requerimientos del sistema puede ser modificado a lo largo del proceso del desarrollo de acuerdo a las necesidades del cliente; SADUC sirve de apoyo para que el desarrollador inicie a planear dichas pruebas, y continue creando y agregando casos de prueba a lo largo del desarrollo del software, de tal manera que al final se tengan todos los casos de prueba posibles.
4.3.1 Caso de estudio 1 . E l primer caso de estudio consiste en crear el modelo de casos de uso con SADUC del SRCA (Sistema de Registro y Consulta de Aspirantes del ~enidet)~,
4.3.1.1 Descripción. El sistema SRCA se divide en dos principales módulos de software:
A. Módulo de operaciones de aspirante B. Módulo programa de Aplicación
’ El SRCA fue desarrollado por el M.C Miguel Hernandez, cgresado del ccnidct. quicn con ayuda dc el realizamos la lista de requisitos funcioiialcs de dicho sistcma.
80
Capítulo 4: Desarrollo Y wuebas de la herramienia
Los dos módulos de software deberán realizar una serie de operaciones básicos sobre una base de datos.
4.3.1.2 Módulo de operaciones de aspirante.
El módulo A se divide en los siguientes submódulos o paquetes:
A.l Paginas Web A.2 Operaciones sobre la base de datos
Los actores de/ módulo A. 1 se identifican como:
1 . Navegador 2. Servidor HTTP 3. Programa CGI
Los actores del módulo A.2 se identifican como:
1. Programa CGI 2. SMBD (Sistema Manejador de Bases de Datos)
4.3.1.2.1 Listado de requisitos:
1. El Navegador requiere del Servidor HTTP la pagina Web denominada inicioCaptura.html, para mostrarla al aspirante como página de bienvenida con hipervínculos hacia los siguientes servicios:
o Alta de aspirante. o Modificaciones de los datos de aspirantes registrados. o Listado de aspirantes registrados que efectuaron el pago del examen de
admisión. o Listado de las claves de login de aspirantes.
2. El Navegador requiere del Servidor H J J P la página Web denominada formulario.html, para mostrar en ella un formulario que le permita al aspirante introducir información personal para darse de alta en la base de datos.
2.1 Enseguida de haber llenado y enviado el formulario el Programa CGI realiza la alta del aspirante bajo ciertas políticas. Posteriormente el Navegador requiere del Servidor H77P io ejecución del Programa CGI para generar dinámicamente una página Web con un formulario que permita al aspirante seleccionar una línea de investigación del programa de maestría elegido en la Fase 1, esto es, si dicho programa ofrece diferentes líneas de investigación.
81
Capiiulo 4: Desarrollo y pruebas de la herramienta
3. El Navegodor requiere del Servidor HTTP la página Web denominada login.html, para mostrar en ella un formulario que le permita al aspirante llenar solamente los dos siguientes campos: la clave de login y la contraseña. Esto capacita al aspirante para acceder al SeWiCiO de modificación de sus datos.
3.1 El Navegador requiere del Servidor H i i f la ejecución del Programo CGI para generar dinámicamente una página Web con un formulario que presente los datos del aspirante almacenodos en la base de datos. E l aspirante registrado estora capacitado para realizar modificaciones a los datos presentados en dicho formulario.
4. El Novegodor requiere del Servidor HTTP la ejecución del Progromo CGI para generar dinámicamente una página Web con los datos de todos los aspirantes registrados que realizaron su pago de examen de admisión, organizados de la siguiente manera:
SEDE: Programa de Maestría: Nombre, Línea de Investigación e Institución de procedencia
5. El Novegodor requiere del Servidor H i i f la ejecución del Progromo CGI para generar dinámicamente una página Web con el listado total de las claves y los respectivos nombres de todos los aspirantes registrados.
A.2 Operaciones sobre la base de datos.
1 . Altas. El Programo CGI gestiona con el SMBD la realización de una alta de aspirante, a partir de los datos proporcionados previamente por este ultimo desde la actividad.
2. Consultas. El Programo CGI gestiona con el SMBD la realización de una serie de consultas a la base de datos. Enseguida se enlistan las consultas realizadas y la actividad previa que las detona:
2.1Verificar la existencia de un registro de determinado aspirante, para no dorlo de alto mas de una vez.
2.2Consultar el valor de la última clave paro generar una clave apropiada para el nuevo aspirante en el proceso de su alta.
2.3Consultar la clave del aspirante recién registrado para incluirla de manera furtivo en la pagina dinarnica que permite seleccionar una especialidad de moestrío.
82
Capitulo 4: Desarrollo ypruebas de la herramienta:
2.4Consultar los datos apropiados para generar dinámicamente la página que muestra el listado de los aspirantes que pagaron.
2.5Consultar los datos apropiados para generar dinámicamente la página que muestra el listado de las claves de todos los aspirantes registrados.
3. Modificaciones. El Programa CGl gestiona con el SMBD la realización de una serie de consultas a la base de datos. Enseguida se enlistan las modificaciones realizadas y la actividad que las detona:
3.1 Modificar el valor inicial por default, previamente asignado durante el proceso de alta, de las especialidades escogidas por los aspirantes.
3.2Modificar los nuevos valores que introduzca el aspirante mediante el formulario de la página web para actualizar sus datos.
4.3.1.3 Módulo programa de aplicación.
El módulo B se divide en el siguiente submódulo:
8.1 Reportes
Los actores del módulo B. l se identifican como:
Programa de Aplicación SMBD (Sistema Manejador de Boses de Datos)
4.3.1.3.1 Reportes.
1. El Administrador de la información utiliza el Programa de aplicación para generar los siguientes reportes generales:
1.1 Listado total. Se consulta la base de datos para listar en pantalla la totalidod de los dotos del total de los aspirantes registrados.
1.2 Listado por claves. Se consulta la base de datos para listar en pantalla la clave, el nombre y apellidos de todos los aspirantes registrados.
1.3 Listado por sede de presentación de examen. Se consulta la base de datos para listar en pantalla el nombre y los apellidos, el programa de maestría, Io institución de procedencia, el teléfono y los correos electrónicos de todos los aspirantes registrados, ordenados por sede.
83
Capítulo 4: Desarrollo y pruebas de la herramienia.
1.4 Listado por programa de maestría. Se consulta la base de datos para listar en pantalla el nombre y los apellidos, la institución de procedencia, la sede solicitada, el teléfono y los correos electrónicos de todos los aspirantes registrados, ordenados por programa de maestría.
Contamos con la lista de requisitos funcionales del SRCA por lo que creamos el modelo de casos de uso con SADUC, para este caso de estudio fueron creados un modelo de casos de uso por cada módulo del sistema como podemos ver en las figuras 4.23, 4.24, 4.25, en ellas podemos constatar que es posible crear modelos de casos de uso con SADUC que cumplen con las características de los diagramas de casos de uso del UML. En estas figuras también podemos ver que las relaciones entre los elementos del diagrama tienen un color que 10s distingue como:
La relación de asociación es pintada de color rosa La relación entre casos de uso es pintada de color azul
Esto es con la finalidad de no confundir dichas relaciones en el modelo de casos de uso. Decidimos abreviar las etiquetas de las relaciones entre casos de uso quedando de la siguiente manera:
< <ext> > = <<extensión> > <<in>> = << inclusión>>
. . . .. . . . . . . .. .. . .... . . . . . . . . . . . . .. . . . .. . . .. ...... . . .
Fig. 4.23 Submodulol: Paginas Web
84
Capitulo 4: Desarrolla y pruebas de la herramienia.
............................. ..................................................... ...................................................
................................................ .................. ........
I*/
<<sa>>
L. Clavrs 0
Fig. 4.25 Módulo3: Programa de aplicación. 85
Capitulo 4: Desarrollo y pruebas de la herramienta
Una vez creado el modelo de casos de uso procedemos a planear los casos de prueba; la intención de SADUC es motivar a los desarrolladores a iniciar con esta etapa del proceso de desarrollo de software una vez terminado el modelo de requerimientos, por lo que el desarrollador podrá planear y agregar los casos de prueba al modelo de requerimientos que considere definitivos para validar los requerimientos del sistema y podrá ir agregando a lo largo del desarrollo del software nuevos casos de prueba conforme sean creados.
Para este caso de estudio creamos una lista de casos de prueba del módulo 2 (“Operaciones sobre la base de datos”) del SRCA, de acuerdo a lo que explicamos anteriormente, la lista de casos de prueba de la tabla 4.1 solo muestra algunos casos de prueba de los requerimientos de este módulo, posteriormente de acuerdo a las necesidades del desarrollador del SRCA podrán agregarse nuevos casos de prueba.
Finalmente el desarrollador se encarga de vaciar la lista de casos de prueba al modelo de requerimientos y generar la documentación del sistema dándole clic al botón generar documento, dando como resultado el documento Requisitos-Pruebas del software tal como se muestra en la figura 4.26.
Tabla 4. I . Lista de casos de prueba. Caso de estudio I
86
Capítulo 4: Desarrollo y pruebas de la herramienta.
La figura 4.27 muestra el modelo de casos de uso del sistema bancario en la que podemos encontrara relaciones de inclusión y extensión entre casos de uso además de las relaciones de asociación. En la tabla 4.2 son enlistados los casos de prueba del modelo de requerimientos y finalmente la figura 4.28 muestra el documento Requisitos-Pruebas de dicho sistema.
I Méndez Méndez Registrar Módulo1 I VianeySánchez I VianeySánchez I
Tabla 4.2. Lista de casos de prueba. Caso de estudio 2.
88
Capítulo 4: Desarrollo ypruebos de la herrarnienla.
I Ei
..
~S.REOLTRiUlIS10 I.4.Di PRUIE.4 I i.DEEsTR4D.I
Fig. 4.28. Documcnto Requisito-Prueba: Caso de estudio 2
89
Copífulo 4: Desarrollo ypruebas de la herramienta.
4.4 Referencias.
[JacOO] Jacobson. Booch, Rurnbaugh., El proceso unificado de desarrollo de software. 1 ra. Edición en Espoñol: Addison Wesley, Madrid 2000
Pressman Roger S., ingienierio del Software; un enfoque práctico. 5ta edición; España: Mc Graw Hill, 2001.
Pow Sang José Antonio., "La especificación de requisitos con casos de uso, buenas y malos prácticas", Grupo de investigación y desarrollo en ingenieria de software, Pontificia universidad católica de perú, 2002.
[PreOl]
[POWO2]
90
CAPITULO 5
CONCLUSIONES
5.1 Análisis de resultados. 5.2 Conclusiones. 5.3 Trabajos futuros. 5.4 Referencias.
Capítulo 5: Conclusiones.
Introducción.
En este capitulo presentamos el análisis de resultados, las conclusiones generadas de este trabajo de tesis, y finalmente los trabajos futuros que puedan desarrollarse con SADUC.
5.1 Análisis de resultados.
SADUC sirve de apoyo importante para los Ingenieros de Software y en general para cualquier persona dedicada al diseño y análisis de sistemas de software, debido a que cumple con el objetivo por el cual fue desarrollado, además de su facilidad de uso y su bajo costo de desarrollo.
5.1.1 Resultados.
1. Se obtuvo un lenguaje de modelado visual, basado en la notación de los diagramas de casos de uso de UML. Dicho lenguaje se define en base al formalismo de las gramáticas relacionales,
2. Se diseñó un formato de documentación “Requisitos - Pruebas” fácil de entender por el analista y los clientes del sistema.
3. Se desarrolló una herramienta para el modelado visual de los requisitos y especificación de pruebas de un sistema orientado a objetos.
4. SADUC es de gran utilidad dentro de la enseñanza-aprendizaje de materias de diseño y modelado de requisitos de sistemas de software, de nivel superior y postgrado. SADUC también esta diseñado para ser usado en ámbitos empresariales para modelar procesos de negocios.
5. SADUC es importante para el área de Ingeniería de Software por ser el primero en relacionar estrechamente a cada requisito un conjunto de casos de prueba en forma estandarizado además de aportar bases para futuras investigaciones y desarrollos en las áreas de especificación de requisitos con diagramas de casos de uso.
92
Caoíiulo 5: Conclusiones.
SADUC ha sido probado por instituciones educativas como lo es la Universidad Loyola de America de la ciudad de Cuernavaca Morelos y hemos comprobado que los alumnos y maestros quedan satisfechos con la funcionalidad de SADUC, además de aportarles conocimientos con diagramas de casos de uso y facilitarles sus tareas en el área de modelado y especificación de requisitos de software.
5.2 Conclusiones.
1 . A traves de SADUC podemos comprobar que es posible describir un conjunto de casos de prueba por cada requisito especificado en el modelo de casos de uso desarrollado.
2. Los desarrolladores de software trabajan para comprender los requisitos del sistema en colaboración con el cliente, los futuros usuarios y otras partes interesadas [Preo’l. SADUC ayuda a que los desarrolladores lleguen a un acuerdo común sobre lo que el sistema debe de hacer y cómo debe funcionar debido a que el modelo de requisitos generado en SADUC esta basada en los diagramas de casos de uso’.
3. SADUC ayuda al desarrollador en el proceso de ingeniería de requisitos permitiendo al desarrollador modelar requisitos funcionales que antes fueron capturados y analizados, además de permitirle validar los requisitos, creando casos de prueba para ellos que le permitan llevar un adecuada gestión de requisitos.
‘ Revisar el capítulo 4 cn el apartado 4.2
93
Capíiulo 5: Conclusiones.
4. Debemos considerar que los requisitos del software sufrirán cambios durante todo el proceso de desarrollo, pero el impacto del cambio varia según el momento en que se introduzca. Si tenemos una comunicación frecuente con el usuario estos cambios serán introducidos en el momento oportuno, cuando aún puedan ser manejables y no causen perdida de tiempo, dinero, frustración personal y clientes descontentos, aquí la importancia de una herramienta como SADUC que proporciona una interfaz fácil de manejar por el desarrollador, que genera un modelo susceptible a cambios, que permite describir detalles de los requisitos en cualquier momento, que permite generar e imprimir la documentación cuando se requiera, sobre todo que permite organizar y llevar el control de dichos cambios a traves del documento Requistos-Pruebas, este es uno de los aspectos más relevantes de SADUC debido que la creación de documentación consume mucho tiempo, y SADUC nos facilita esta tarea, solo basta con hacer clic en “generar documento” para obtenerla.
5. SADUC toma aún más relevancia cuando de alguna forma obliga al desarrollador a describir sus casos de prueba facilitándole las entradas de los mismos y como ngenieros de Software reconocemos la importancia de documentar los casos de prueba ya que las pruebas del software son un elemento critico para la garantía de calidad del software. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos ,preo,l.
5.3 Trabajos futuros. ~
Este apartado propone mejoras a la herramienta y trabajos futuros que enriquecerán la funcionalidad de SADUC.
1 . Desarrollar un módulo que permita obtener un prototipo de la lnterfaz de usuario de un sistema de software a través de los diagramas de casos de uso, en donde se generen vistas por actores, formularios y pantallas por casos de uso; ya existen trabajos que hablan de este tema, sería interesante que SADUC contemplara esta característica.
94
Capítulo 5: Conclusiones.
2. Desarrollar un módulo que permita generar una plantilla del modelo de casos de uso con la siguiente información: Flujo principal de eventos del actor, Flujo principal de eventos del sistema, Variaciones - Extensiones, Excepciones. (Ver. Anexo B).
3. Idear una estrategia en la que se vincule el diagrama de paquetes con el diagrama de casos de uso, en donde pueda ser posible ver el conjunto de casos de uso que corresponde a un determinado paquete de clases, de tal forma que cuando se valide el código se tenga conocimiento a que casos de uso corresponde.
4. Añadir código que permita validar que no existan requisitos duplicados en el diagrama de casos de uso.
5. Integrar al menú edición de la interíaz de CADUC las opciones de copiar Y pegar.
6. Integrar capacidad de zooming al diagrama.
7. Integrar SADUC a SCUML2
5.5 Referencias.
[PreOl] Pressman Roger S. Ingeniería del Software; un enfoque práctico. 5ta edición; España: Mc Graw Hill, 2001
’ SCUML: Suite cciiidct UML
95
ANEXO A
Glosario de términos.
97
Glosario de términos.
i
Análisis: Flujo de trabajo fundamental cuyo propósito principal es analizar los requisitos descritos en la captura de requisitos, mediante su refinamiento y estructuración. E l objetivo de esto es (1) lograr una comprensión más precisa de los requisitos, y (2) obtener una descripción de los requisitos que sea fácil de mantener y que nos ayude a dar estructura al sistema en su conjunto.
Caso de Prueba: Especificación de un caso para probar el sistema, incluyendo que probar, con que entradas y resultados y bajo que condiciones.
I/ 11
Clase: Es la descripción de un conjunto de objetos. Consta de métodos y datos que resumen las características comunes de un conjunto de objetos. Muestra el comportamiento general de un grupo de objetos.
98
Defecto: Anomalía del sistema, por un ejemplo un síntoma de un error en el software descubierto durante las pruebas, o un problema descubierto, o un problema descubierto durante la reunión de revisión.
Diagrama de Clases: Parte de la notación orientada a objetos, utilizada para mostrar la existencia de las clases y sus relaciones en el diseño lógico de un sistema. Un diagrama de clases puede representar todo o parte de la estructura de clases de un sistema.
Diseño: Es el procelo de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realización física.
Dirigido por los casos de uso: En el contexto del ciclo de vida del software, indica que los casos de uso de utilizan como artefacto principal para definir el comportamiento deseado para el sistema, y para comunicar este comportamiento entre las personas involucradas en el sistema También indica que los casos de uso son la entrada principal para el análisis, diseño, implementación y pruebas del sistema, incluyendo la creación, verificación y validación de la arquitectura del sistema.
I/ Gestión de Requisitos. La gestión de requisitos es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento.
Herramientas CASE: Las herramientas CASE (Computer Assisted Software Engineering) son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.
Implementación: Flujo de trabajo fundamental cuyo propósito esencial es implementar el sistema en términos de componentes, es decir, código fuente, ficheros binarios, etc".
Ingeniería directa: En el contexto de desarrollo de software, la transformación de un modelo en código a traves de su traducción a un determinado lenguaje de implementación.
Ingeniería inversa: Transformación del código en un modelo a través de su traducción desde un determinado lenguaje de implementación.
lnterfaz de usuario: lnterfaz a través de la cual un usuario interactúa con un sistema.
Lenguaje Unificado pe Modelado (UML): Lenguaje estandar para el modelado de software. Lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema con una gran cantidad de software.
Plan de pruebas: Plan que describe las estrategias, recursos y programación de las pruebas.
I
I/
Proceso de negocio: Conjunto total de actividades necesarias para producir un resultado de valor percibido y medible para un cliente individual de un negocio.
Prototipo de interfaz de usuario: Fundamentalmente, un prototipo ejecutable de una interfaz de usÚario, pero que puede, en los momentos iniciales del desarrollo, consistir únicamente en dibujos en papel, 'diseños de pantallas, etc.
Pruebas: Flujo de trabajo fundamental cuyo propósito esencial es comprobar el resultado de la implementación mediante las pruebas de cada construcción, incluyendo tanto construcciones tanto construcciones internas como intermedias, así como las versiones finales del sistema.
99
Requisito: Condición o capacidad que debe cumplir un sistema.
Requisitos Funcional: ,Requisitos que especifica una acción que debe ser capaz de realizar el siste'ma, sin considerar restricciones físicas; requisito que especifica comportamiento de entrada/salida de un sistema.
Requisito no funcional: Requisito que especifica propiedades del sistema, como restricciones del entorno o de implementación, rendimiento, dependencias de la plataforma, mantenibilidad, extensibilidad o fiabilidad. Requsito que especifica restricciones físicas sobre un requisito funcional.
Validación de Requisitos: La validación de requisitos examina las especificaciones poro asegurar que todos los requisitos del sistema han sido establecidos sin am$igüedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que .el resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el producto.
Validación: Se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.
Verificación: Se refiere al conjunto de actividades que aseguran que el software implemento una función específica.
11
.I
I O0
ANEXO B
Plantillas de casos de uso.
0 4 - 0 3 4 4
101
Proyecto: Proyecto TPV Documento: CU ReaUrar Venta3 Historkt 02/12m12O:44- 1.0 SinissiEin: Abletill pn>ceSO:
AUIOI: jvilalta(eivico.org- www.vico.org OZWI Clclo de actividad: Espmllicaddn Cawn de UsoModelo ñcha- ref.- LIMIT-3
._ _. ... ,- . . . . . . . . .... ... . . . -. .- ... . . . _. ... -. ....... j Activación A discreción del Cajero y po;ei CU Seleccionar Venta
. .-_____-.-I.. ".- .._I__-- . _ ~ I _ _ _ _ I .......... ................ .- . . . ~ . . CU Realizar Venta ______.I Propbsito Registrar una ventacumplimentando las siguientes variables: Id. Venta, Id. Vendedor. FechaiHora de venta, Id. TPV, Id. Caj&o, Importe total de la venta y ' modalidad de cobro en efectivo o por tarjeta de crbdito. Mostrar Is datos de una venta en modo de consulta.
_____.. .. . . . . . . . . . . . . . . . . . . . . . . __-_ -~- ,c___I-..-
Fluj&p@bzpaide eventos SISTEMA--i--- . - Variaciones . Extensiones CompNeba quien activa el CU
i I o~&:i(in 50 cwso Y m i r l i i j -&-- ... i
.i
i
j
.......... ................... 3 Ventana Realizar VenIas Mueslra FechaiHora de venta, identifica TPV y Cajero I
... . - .
...... ... - J
I . _ _ - . 4
---L Muestra Vendedores dispnibles . ~ _ _ ~ _ r ~ , . 3 CU Entrar Linea de Venta ~.
modalidad de cobro en efectivo ........
-1 i
.- .... + ... ... . . . . . . . . . . . . . . . . . . . . .. ...... -__ . . . . . . . . . . . . . . . . . . . . . . .
. ............ 3 CU ImprimirTicket deventa I- Registra la venta con todo su detalle de la Venta
I ... ____ . , . i I '
I
: I ; a . /Realizar otra venta O-:-;-:-
lineas de venta ______ Selecciona opción:
~ - - . - : b. ic~ 1 Consultar venta: 3 c. onsultar arilculo:
1 Catálogo de Ariicu íi. 1 Finalizar. '
! I I L. .............. ....... ..- 1.. ... L.
-.
.- .
. . . . . . . . . . . .. . 1 ... . . . . -. J . . ._ ... - . . .
.. ....... 4 __ - . . . .
