Академический Документы
Профессиональный Документы
Культура Документы
Captulo 3 Anlisis
3.1 Introduccin al Anlisis 3.2 Vista esttica. 3.2.1 Diagrama de clases 3.3 Vista dinmica. 3.3.1 Diagramas de secuencia 3.3.2 Diagramas de estados
Captulo 4 Diseo
4.1 Introduccin al Diseo 4.1.1 Principios del diseo 4.2 Arquitectura de software 4.2.1 Diagrama de paquetes 4.2.2 Diagrama de distribucin 4.3 Construccin de componentes 4.4 Diseo de la base de datos 4.4.1 Conversin del diagrama de clases al modelo de datos de una base de datos relacional
Captulo 5 Construccin
5.1 Diseo detallado de clases 5.2 Estndares de codificacin 5.3 Revisin de cdigo y programacin entre pares 5.4 Pruebas unitarias 5.4.1 Pruebas caja blanca 5.4.2 Pruebas caja negra
Introduccin
Los productos de software apoyan gran cantidad de las actividades humanas. Estos productos responden a las necesidades de personas, empresas, organizaciones, etc. Los defectos en sistemas de software pueden causar daos no solamente econmicos sino tambin de vidas humanas. Por lo tanto, la forma en que se desarrolle el software para cumplir con las necesidades de sus usuarios y para evitar el mayor nmero de defectos, es de vital importancia. La Ingeniera de Software comprende los mtodos, tcnicas y herramientas necesarias para la construccin de sistemas de software con calidad. El objetivo de este Material para los Estudiantes es ensear las prcticas bsicas de Ingeniera de Software para la concepcin y desarrollo de software. Las notas describen las principales fases de un ciclo de desarrollo y las tcnicas bsicas que sirvan de gua a los alumnos que construyen estos productos de software por primera vez. El material est dirigido principalmente a los estudiantes de licenciaturas, que ya saben programar en un lenguaje orientado a objetos. La estructura de las notas es la siguiente: En el captulo 1, se introducen los conceptos bsicos de Ciclo de desarrollo de software e Ingeniera de Software. Se analiza la naturaleza del software, los principios de la Ingeniera de Software, el Proceso de software. Se presenta brevemente el Lenguaje de Modelado Unificado (UML por sus siglas en ingls) que ser la herramienta de modelado en todos los captulos de las notas. El captulo 2, trata sobre la especificacin de los requerimientos y propone varios diagramas de UML para el modelado. El captulo 3 est dedicado al anlisis de requerimientos, se explica su objetivo y las representaciones esttica y dinmica con los diagramas de UML correspondientes. En el captulo 4, se presentan varias tcnicas para hacer el diseo del software que comprende desde la arquitectura hasta el diseo de la base de datos. El captulo 5 habla de diseo detallado para la construccin del software y de las pruebas unitarias. El captulo 6 se plantea la forma de integrar y probar el sistema. Tambin, incluye una seccin sobre la construccin de manuales. El presente Material para los Estudiantes ha sido elaborado bajo el convenio 19403-168829-XI-06 entre Microsoft y la Facultad de Ciencias de la UNAM y est acompaado con el Material para el maestro, ambos en su versin preliminar.
Captulo 1
Ciclo de desarrollo de software
1.1
Los productos de software apoyan gran cantidad de las actividades humanas. Estos productos responden a las necesidades de personas, empresas, organizaciones, etc. Los productos de software tienen un ciclo de vida que consta de dos etapas: Etapa de concepcin y desarrollo Alguien define las necesidades que deber cubrir el software. Se analiza y disea el producto que las cumplir Se construye y prueba el producto Etapa de operacin, mantenimiento y retiro Se pone en operacin Se va modificando y mejorando Eventualmente se deshecha Las personas que construyen estos productos de software se llaman Ingenieros de Software. Es la Ingeniera de Software, la rama de las Ciencias de la Computacin que se encarga de estudiar las teoras, mtodos y herramientas que se necesitan para desarrollar el software.[Sommerville] En estas notas plantearemos las bases de la Ingeniera de software y nos enfocaremos en la etapa de concepcin y desarrollo.
1.2
Las definiciones de la Ingeniera de Software consideran diversos aspectos de lo que contempla esta disciplina: Enfoque en el ciclo de vida de software: Es la aplicacin sistemtica, disciplinada y cuantificable del desarrollo, operacin y mantenimiento de software. [IEEE Standard Glossary of Software Engineering Terminology, std610.12-1990] Enfoque en las personas involucradas: Es la construccin de productos de software por grupos de personas, para que sean usados por otras. El cliente es quien solicita el desarrollo del producto y plantea el problema a resolver. El equipo de desarrollo construye y entrega el producto solicitado.
Ciclo de Desarrollo de software Generalidad: Consiste en descubrir los aspectos ms generales que existen en un problema. Este principio es fundamental cuando se trata de desarrollar herramientas y paquetes genricos. Abstraccin: Es identificar inicialmente los aspectos ms importantes e ir incorporando los detalles gradualmente. Modularidad: Es dividir el problema en subproblemas. Incluye los conceptos de cohesin y acoplamiento. Incrementabilidad: Consiste en obtener el producto de software incrementando la funcionalidad en varios ciclos (iteraciones). Separacin de conceptos: Es manejar diferentes aspectos de un problema concentrndose en cada uno por separado. Anticipacin al cambio: Es disear el software para que pueda evolucionar a nuevas versiones, que se administran de manera controlada.
El Software Engineering Body Of Knowledge [SWEBOK] es un esfuerzo de la comunidad de Ingeniera de Software que recoge principios, tcnicas y mejores prcticas reconocidas por los acadmicos y profesionales del rea.
1..*
Fase
1..*
Producto 1..*
Actividad 1..*
Rol
Un Proceso de software est compuesto por fases y debe incluir al menos una fase. Las fases estn compuestas de al menos una actividad, que tiene asociado uno o varios productos y uno o varios roles. Un rol es responsable de al menos una actividad. Las Fases constituyen pasos significativos del proceso de software. Tienen un objetivo dentro del desarrollo. Para cada fase se identifican: los roles, actividades y productos que son necesarios cabo para cumplir el objetivo de la fase. Actividades definen las acciones que se llevan a cabo en el desarrollo del software y utilizan y/o generan los productos. Productos son las entradas y salidas de las actividades. Pueden ser documentos, diagramas de diseo, cdigo, planes de pruebas, reportes, manuales de usuario, o conjuntos de ellos. Roles son los responsables por llevar a cabo las actividades del proceso.
Una iteracin del ciclo de desarrollo consta de las siguientes fases: Especificacin de requerimientos (captulo 2). El objetivo de esta fase es entender, capturar y especificar los requerimientos para tener una descripcin clara y no ambigua de lo que ser el producto. Esta especificacin debe proporcionar criterios para validar el producto terminado. Se usarn los casos de uso para especificar los requerimientos. Anlisis (captulo 3). Se analizan los requisistos para tener un mejor entendimiento de lo que se pretende y se construye el modelo del anlisis para identificar los elementos que servirn de base para estructurar todo el sistema. Se establecen las clases con que
Ciclo de Desarrollo de software se construir el software. Se construyen dos modelos: la vista esttica (diagramas de clases) y dinmica (diagramas de secuencia y de estados). Diseo (captulo 4). Los objetivos de esta fase son: describir las partes de las cuales se va a componer el sistema y mostrar sus relaciones en la arquitectura, se identifican los paquetes principales del software y la forma en que se distribuirn en las computadoras que intervienen en una aplicacin. Construccin (captulo 5). El objetivo de esta fase es hacer la construccin del software y entregar el cdigo probado de las unidades. Integracin y pruebas (captulo 6). El objetivo de esta fase es hacer la integracin del sistema y probar que cumpla con sus requerimientos.
A lo largo del ciclo de desarrollo de software que usaremos, se irn construyendo diversos diagramas de UML.
Referencias bibliogrficas
Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Languaje. Users guide. Addison Wesley 1999. Ghezzi C., Jazayeri M., Mandrioli D. Fundamentals fo Software Engineering. Prentice Hall 1991. IEEE Standard Glossary of Software Engineering Terminology, std610.12-1990. Jacobson I., Booch G., Rumbaugh J. The Unified Software Development Process. Addison Wesley 1999. Oktaba H., Ibargengoitia G. Software Processes Modeled with Objects: Static View, Computacin y Sistemas, Iberoamerican Journal of Computer Science, CIC-IPN, Mxico, 1, 4 (1998), p.228-238. Pressman R.S. Ingeniera del Software. Un enfoque prctico. McGraw Hill. Sommerville I. Ingeniera de Software 6 edicin. Addison wesley 2002. SWEBOK. Guide to the Software Engineering Body of Knowlwdge. Trial version Mayo 2001. www.swebok.org
10
11
12
Ciclo de Desarrollo de software La definicin del problema permite establecer un acuerdo y entendimiento comn entre el equipo de desarrollo y el cliente sobre lo que se va a hacer. En esta definicin se sugiere que participen todos los miembros del equipo de desarrollo para entender el propsito del software que van a desarrollar.
Glosario de trminos
La definicin del problema es difcil pues el del cliente usa los trminos relacionados con el problema y el tcnico el lenguaje de los desarrolladores. Para que se puedan comunicar ms fcilmente todos los involucrados, se recomienda construir un glosario de trminos que establece un vocabulario comn. El glosario de trminos es un diccionario donde se pone cada trmino y su significado para este proyecto. En este glosario se deben incluir tambin los trminos familiares para el desarrollador con su significado. La construccin del glosario es un trabajo continuo a lo largo del proyecto, se inicia en esta fase y se concluye al finalizar el proyecto. En la figura 2.2 se muestra un extracto del glosario de trminos del sistema de bolsa de trabajo.
GLOSARIO DE TRMINOS Sistema de Bolsa de trabajo Actor: Es una entidad que interacciona con el sistema para obtener un resultado.
Puede ser una persona, otro sistema, un dispositivo, etc. Bolsa de Trabajo: En este caso, es la concentracin de informacin acerca de empresas que tienen puestos disponibles (vacantes) y de personas que tienen la necesidad de conseguir un empleo. Caso de uso: Es la descripcin de un conjunto de secuencias de acciones que un sistema lleva a cabo para regresar un resultado observable a un actor. Contrasea: Clave de seguridad que se le asigna a un usuario. Desempleado: Persona que no tiene trabajo y est en busca de un empleo. Empresa: Organizacin que tiene la necesidad de contratar a personas con capacidades especificas para su correcto funcionamiento. Nombre de usuario: Identificacin del usuario para poder acceder al sistema. Vacante: Puesto disponible para ser ocupado por un desempleado por parte de una empresa. Visitante: Persona que abre las pginas del sistema y revisa la informacin que se presenta en este sitio Web, la informacin la podr ver sin tener que registrar sus datos. Figura 2.2. Glosario de trminos.
13
14
Ciclo de Desarrollo de software El proceso para la especificacin de los requerimientos es: 1. Entender las necesidades del software. 2. Identificar a los interesados en el sistema y solicitar los requerimientos. 3. Identificar y negociar los requerimientos funcionales y los no funcionales. 4. Hacer el prototipo de interfaz para que los interesados confirmen si esos son sus requerimientos. 5. Documentar la Especificacin de requerimientos. La especificacin de requerimientos termina cuando se obtiene el documento de Especificacin de los requerimientos, que resume lo que cliente necesita y que servir de gua a los desarrolladores para analizar esos requerimientos, validarlos, administrarlos y generar el software. Validar un requerimiento implica comprobar que el software lo cumpla. Administrar los requerimientos significa que se lleve un control de los cambios que van surgiendo. La especificacin de requerimientos es un documento donde se establece el acuerdo de lo que har el software. Para hacer este documento se puede seguir lo que proponen los modelos de referencia como MoProSoft [MoProSoft], para la estructura de este documento: Introduccin. Es una descripcin general del software y su propsito. Descripcin de requerimientos. o Funcionales. o Prototipo de interfaz de usuario. o No funcionales como: confiabilidad, portabilidad, restricciones de diseo o construccin, de mantenimiento, interfaces con otro software o con hardware.
15
Ciclo de Desarrollo de software Caso de uso. Un caso de uso es una descripcin de un conjunto de secuencias de acciones que realiza el sistema para entregar un resultado o valor observable a un actor. [Booch, 1999]. Se representa por una elipse con el nombre del caso de uso. El nombre del caso de uso deber iniciarse, preferentemente, con un verbo en infinitivo. Consultar vacante Actor. Es algo externo al software que intercambia informacin con el sistema, puede ser un usuario u otro sistema. El objetivo de un actor es completar una funcionalidad con el software para obtener un valor o servicio. Se representa con una figura humana con el nombre del actor en singular. Los sistemas externos con los que interacciona el software que se est desarrollando tambin son actores. Un caso de uso puede proporcionar un valor a uno o ms actores. En el ejemplo del sistema para la Bolsa de Trabajo, un actor es el Desempleado.
Desempleado
Alcance del sistema. Representa la frontera del sistema y contiene los casos de uso que se realizan en cada ciclo de desarrollo. Se representa por un rectngulo que incluye los casos de uso dentro del alcance del sistema. Diagrama de casos de uso. Un diagrama de casos de uso incluye los actores identificados, los casos de uso para cada actor y el alcance del sistema. En el diagrama general se ponen las funcionalidades o casos de uso ms generales que posteriormente se detallan en diagramas en los que se desglosa cada funcionalidad. Este diagrama general tiene por objetivo mostrar de forma grfica y clara las funcionalidades del sistema por lo que deber ser simple, para mostrar a golpe de vista el alcance. Se recomienda que siempre se incluya un caso de uso para entrar al sistema y uno de salir de los actores. El diagrama general se discute con el cliente y los usuarios del software. En la figura 2.3 se muestra el diagrama general de casos de uso del sistema de la Bolsa de trabajo. En este diagrama se aprecian 8 casos de uso generales para 3 actores que posteriormente se detallarn. El alcance del sistema est encuadrado en el rectngulo. Este diagrama permite entender la funcionalidad general del sistema y su alcance.
16
Proceso para la creacin de diagramas de casos de uso 1. Identificar los actores del sistema. Esto es, los que interaccionarn con el software para obtener un resultado de l. 2. Identificar las funcionalidades o casos de uso generales para cada actor. 3. Definir el alcance o los casos de uso que se desarrollarn. 4. Detallar cada caso de uso.
17
18
Descripcin: Un Visitante entra al sistema para consultar las vacantes que estn disponibles. Precondiciones: El visitante conoce la direccin Web del sistema de software SIBOT. El visitante desea ver las opciones de trabajo que estn disponibles.
Flujo de eventos normales: Usuario Sistema Accin Paso Accin El usuario da clic en el 2 Muestra la pantalla de Todas vnculo Ver Vacantes. las Vacantes. Selecciona la Vacante de la cual desea ver los datos a ms detalle. Da clic en el botn Ver 5 Se muestra la pantalla de Detalle de Vacante con los datos de la vacante seleccionada.
Paso 1 3
Excepcin E1
E1,E2
Flujo de eventos alternativos: Id E1 Nombre La conexin con la base de datos no esta establecida o se interrumpi. No se ha seleccionado ninguna vacante Accin Se manda un mensaje de error, el cual indica que los datos no se pueden mostrar debido a que no hay conexin con la base de datos. No hace nada.
E2
Poscondiciones: Los datos de la vacante se muestran a detalle. Figura 2.4. Ejemplo del detalle de un caso de uso.
19
Ciclo de Desarrollo de software prototipo es un elemento muy importante para la comunicacin con el usuario en la definicin de los requerimientos, pues al revisar la interfaz, el usuario puede refinar sus necesidades y comunicarlas al desarrollador.Se llama pantalla o interfaz al mecanismo con el cual interacta el usuario con el sistema. Cuando se diseen estas pantallas podrn ser cdigo html, o ventanas o entradas a modo texto. Para disear el prototipo de la interfaz se consideran los casos de uso planteados en el diagrama general y se puede construir al mismo tiempo que se detallan los casos de uso. Si el diagrama general tiene los casos de uso X, Y y Z, en la pantalla principal del sistema debern estar las opciones del men X, Y y Z. Si en la descripcin del flujo de un caso de uso dice el sistema presenta la pantalla de P..., en el prototipo deber haber esa pantalla. Si en el flujo dice el usuario oprime el botn M..., deber haber un botn M en la pantalla. En resumen, se debe cuidar que exista coincidencia entre el detalle de los casos de uso y el prototipo. Deben coincidir: Las opciones del men y los casos de uso Los nombres de las pantallas Los nombres de los botones Ejemplo del prototipo de la interfaz del detalle de caso de uso anterior.
20
Ciclo de Desarrollo de software 1. El sistema debe de ser fcil de usar, adems deber tener una interfaz grfica agradable y con colores suaves para no daar en algn sentido visual al usuario. 2. El funcionamiento del sistema deber estar activo las 24 horas del da y los 365 das del ao. Confiabilidad 3. Este sistema deber de tener una alta confiabilidad e integridad con los datos de los usuarios. 4. Para poder modificar, dar de alta o eliminar datos, el usuario debe de proporcionar al sistema un nombre de usuario y una contrasea. Eficiencia 5. La velocidad para mostrarle los datos al usuario debe de ser considerable, lo cual implica que la pagina no debe de contener imgenes muy pesadas que haga que el sistema se retarde. Restricciones de diseo y construccin 6. El sistema de software ser construido para funcionar en ambiente Web. 7. El sistema deber estar codificado en lenguaje de programacin C#. 8. La base de datos del sistema de software deber estar construida con el manejador de bases de datos SQL-server 2000. 9. Para el desarrollo de este sistema se utilizarn las siguientes herramientas a. Star UML para modelado del sistema. b. Visual Studio 2003 (C#) para la codificacin. c. Microsoft Word para hacer la documentacin. d. ASP.NET para el desarrollo del sitio web. e. SQL-Server para la creacin de la Base de Datos. f. Internet Information Server para la configuracin del sitio Web.
Referencias bibliogrficas
Booch G., J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley. 1999 Coad P. at. al. Object Models, Strategies, Patterns and Applications. Yourdon Press Computing Series, Prentice Hall. 1995 SWEBOK. Guide to the Software Engineering Body of Knowlwdge. Trial version Mayo 2001. www.swebok.org Tomayko J. E., Hazzan O. Human Aspects of Software Engineering. Charles River Media, Computer Engineering Series. 2004.
22
Captulo 3 Anlisis
23
Ciclo de Desarrollo de software Los diagramas de clases se usan para modelar grficamente la vista esttica del software. Describen los tipos de objetos que son importantes para modelar un sistema y cmo se relacionan [Arlow]. Contienen los siguientes elementos: Clase es la descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, mtodos, relaciones y comportamiento [Rumbaugh]. Se representa grficamente por un rectngulo con 3 compartimentos, uno para el nombre, otro para los atributos y el tercero para los mtodos.
Desempleado
Nombre Direccin Telfono Email Curriculum Alta() Modificar() Consultar Datos() Eliminar() Postularse vacante()
Relacin muestra la dependencia entre dos o ms clases. Los tipos principales de relaciones entre clases son: asociacin, agregacin y generalizacin. Asociacin es una relacin estructural que describe ligas entre objetos de las clases. Se representa por una lnea que conecta a las clases asociadas. Esta liga puede tener adornos como la multiplicidad que denota cuntos objetos de una clase pueden estar relacionados con objetos de la otra.
Vacante Desempleado
Nombre Direccin Telfono Email Curriculum Nombre Requisitos Sueldo HoraInicio HoraFin Descripcin
1..*
Alta() Modificar() Consultar Datos() Eliminar() Postularse vacante()
1..*
Esta asociacin entre las clases Desempleado y Vacante indica que uno o mas Desempleados pueden postularse para una o ms Vacantes.
24
Agregacin es un tipo de asociacin que denota que los objetos de una clase B forman parte de un objeto de otra clase A. O sea que una clase A est compuesta por objetos de la clase B. Se denota por una lnea con un rombo del lado de la clase compuesta, un ejemplo de este tipo de relacin, es un libro que est compuesto por varias pginas.
ClaseA
1 * ClaseB
Generalizacin relaciona a una clase general o abstracta que comparte sus atributos y operaciones con clases que los especializan. Las subclases heredan todos los atributos y operaciones de la superclase. La relacin entre la clase general y sus especializaciones se denota por una lnea con un tringulo del lado de la general. Un ejemplo de esta relacin es una figura geomtrica que puede especializarse en un tringulo, cuadrado, crculo, etc. A todas estas figuras se les puede medir el permetro, el rea pero cada una tiene su forma de calcularse.
ClaseGeneral
Clase
Identificacin de clases Para identificar las clases, se analiza cada caso de uso para imaginar qu clases se necesitan de cada estereotipo. Se recomienda iniciar por la identificacin de las clases de control. Por ejemplo, si se tiene un caso de uso de Administrar Desempleado, seguramente se necesitar una clase que represente a los desempleados en la aplicacin. Entonces se propone la clase Desempleado como una clase de control. Los atributos de esta clase sern los datos necesarios de los desempleados y sus mtodos pueden ser: alta, modificar, eliminar, consultar datos, etc. Guadalupe Ibargengoitia G., Hanna Oktaba 25
Una tcnica para identificar las clases son las tarjetas CRC [Beck, Cunningham]. Las tarjetas CRC (Clase-Responsabilidad-Colaboracin) se usan para determinar tanto las clases como sus responsabilidades. Para cada responsabilidad se busca la colaboracin con otras clases y as se identifican nuevas clases. Estas tarjetas tienen la forma: Nombre de clase Responsabilidad Colaboracin
Se llaman tarjetas porque inicialmente se usaban tarjetas de fichas bibliogrficas, pero actualmente se usan tablas. Proceso para identificar las clases de control: 1. Seleccionar un caso de uso y sus flujos de eventos. 2. Por cada paso de la interaccin del actor con el sistema, se analizan los sustantivos ms significativos como candidatos a clases que se requieren para realizar cada accin. Para cada clase candidata se escribe en una tarjeta su nombre, por ejemplo A. El nombre debe ser un sustantivo. 3. Cada accin asociada a la clase A, es una responsabilidad de esta clase y se anota en la columna Responsabilidad. La descripcin de una responsabilidad deber empezar con un verbo en infinitivo. 4. Se analiza la responsabilidad R y se trata de identificar qu otras clases deben colaborar con la clase A para poder cumplir con esa responsabilidad. a. En caso de identificar a las clases B y C como colaboradoras de esa responsabilidad se apuntan sus nombres en la columna de Colaboracin de la clase A para la responsabilidad R. Para las clases B y C se repite el proceso de crear sus tarjetas y se anotan las responsabilidades de estas clases requeridas para la colaboracin. b. En caso de no necesitar de colaboracin, la columna de Colaboracin se queda vaca. 5. Se regresa al punto 2 para analizar el siguiente paso de la interaccin. 6. El proceso para un caso de uso termina cuando se finaliza la secuencia de pasos en sus flujos de eventos. 7. Se regresa al punto 1 para seleccionar al siguiente caso de uso. 8. El proceso termina cuando ya se analizaron todos los casos de uso. Durante este proceso se van refinando y corrigiendo las tarjetas. Cuando ya se tiene un conjunto de tarjetas para la realizacin de todos los casos de uso, se construye el diagrama de clases a partir de stas.
26
1. Para cada tarjeta se crea una clase en el diagrama, con el mismo nombre, en singular y empezando con mayscula. 2. Por cada responsabilidad de la clase, se define el mtodo correspondiente, nombrado como verbo en infinitivo y en minsculas. 3. Para cada colaboracin entre clases, se dibuja una relacin de asociacin entre ambas clases.
Figura 3.3. Diagrama de clases de control. En la figura 3.3 se muestra el diagrama de clases de control para el sistema de Bolsa de trabajo. La clase general Visitante se puede especializar en Desempleado por lo que esas clases tienen una relacin de herencia. La clase Desempleado tiene una relacin de agregacin con la clase Currculum, porque cada Desempleado tiene un Currculum. La clase Vacante est asociada con las clases Empresa y Desempleado. Es necesario remarcar, que este diagrama se ir detallando y modificando conforme se avanza en el diseo.
27
Ciclo de Desarrollo de software Al analizar todos los casos de uso, se puede construir uno o varios diagramas de clases de control para los casos de uso con las clases que son indispensables. Clases de Interfaz. Una vez teniendo las clases de control, se identifican las clases de interfaz de usuario. Para encontrarlas, se revisa el prototipo de interfaz de usuario creado en la fase de Especificacin de requerimientos y se dibuja una clase para cada pantalla. Las clases de interfaz se podrn implementar con diversas tecnologas como sern ventanas, cdigo html, jsp, etc. que se decidirn en el diseo.
Clases de Interfaz
<<Forma de entrada>> AltaEmpresaIH -Empresa +Abrir() +Maximizar() +Minimizar() +Cerrar() <<Forma de entrada>> ModificarVacanteIH -Vacante +Abrir() +Maximizar() +Minimizar() +Cerrar()
<<Forma de entrada>> ModificarEmpresaIH -Empresa +Abrir() +Maximizar() +Minimizar() +Cerrar() <<Pantalla>> VerTodasVacantesIH -Vacante[] +Abrir() +Maximizar() +Minimizar() +Cerrar()
<<Pantalla>> VerDatosEmpresaIH -Empresa +Abrir() +Maximizar() +Minimizar() +Cerrar() <<Pantalla>> VerDetalleVacanteIH -Vacante +Abrir() +Maximizar() +Minimizar() +Cerrar()
<<Pantalla>> <<Pantalla>> EliminarEmpresaIH PostularVacanteIH -Empresa +Abrir() +Maximizar() +Minimizar() +Cerrar() <<Pantalla>> EliminarVacanteIH -Vacante +Abrir() +Maximizar() +Minimizar() +Cerrar() -Vacante -Desempleado +Abrir() +Maximizar() +Minimizar() +Cerrar()
Clases de Entidad. Para identificar las clases de Entidad, se escogen las clases de control cuyos atributos deben ser guardados. Para cada una de estas clases, se dibuja una clase de tipo entidad, que se encargue de resguardar estos atributos en una base de datos o un archivo.
28
29
Mensajes que son enviados de un objeto fuente a otro receptor a travs del tiempo. Representa la invocacin del mtodo del objeto receptor. Se modela como una lnea con la flecha del objeto fuente al receptor con el nombre del mtodo sobre la lnea el cual puede o no contener los parmetros del mtodo.
:Vacante :VacanteDB : BufferedWriter guardar()
Actor es el iniciador de la primera invocacin del mtodo en la secuencia de mensajes que se envan los objetos entre si.
Visi tante
En un diagrama de secuencia se coloca arriba a la izquierda al actor o al objeto que inicia la interaccin entre objetos y hacia la derecha se ponen los dems objetos que participan en la interaccin. Los mensajes que los objetos se envan se dibujan con flechas entre las lneas de vida de los objetos, etiquetados con los mtodos. Los mensajes fluyen de izquierda a derecha y de arriba hacia abajo representando el orden en el tiempo.
Construccin de diagramas de secuencia para los casos de uso Para cada flujo normal y alternativo de eventos en los casos de uso, se construye un diagrama de secuencia. Estos diagramas representan la vista dinmica de los casos de uso especificados en los requerimientos. Para su construccin se parte del detalle de los casos de uso.
30
Ciclo de Desarrollo de software Por cada flujo de un caso de uso se identifican las clases de cada tipo necesarias para su realizacin y se crea un diagrama de secuencia de la siguiente manera: 1. Se representa al actor que corresponde al caso de uso ponindolo arriba en el extremo izquierdo del diagrama. 2. El actor inicia las acciones del caso de uso enviando un mensaje a un objeto de una clase de interfaz identificada para este flujo. 3. Enseguida se pone uno o mas objetos de clases de control y si es necesario, uno o mas objetos de entidad. 4. Cada mensaje entre objetos aparece como una flecha dirigida del objeto solicitante al objeto receptor, etiquetado con el nombre del mtodo correspondiente. 5. Para visualizar el orden temporal del envo de los mensajes, la flecha de un mensaje posterior se dibuja un poco mas abajo que la del mensaje anterior. En la figura 3.6, se muestra un diagrama de secuencia para el caso de uso de Consultar Vacante, en que el Visitante (1) abre un objeto de la clase de interfaz de VerTodasVacantesIH, (2) consulta los datos del objeto de la clase Vacante, quien (3) los extrae de un objeto de la clase entidad VacanteDB, se los entrega al objeto de Vacante (4), quien los pasa a un objeto de la clase de interfaz de VerTodasVacantes (5) para que los vea el visitante. El actor selecciona una vacante (6) de la interfaz y se muestra su detalle en un objeto de la clase de interfaz de VerDetalleVacante (7).
Es comn que al hacer los diagramas de secuencia surjan nuevas clases y mtodos no identificados durante la construccin de los diagramas de clase. Por lo tanto, una vez
31
Ciclo de Desarrollo de software terminados los diagramas de secuencia para todos los casos de uso, se revisa la consistencia entre ambos los diagramas de clase y de secuencia. Se modifican los diagramas de clases segn lo encontrado durante la construccin de los diagramas de secuencia. Los cambios en los diagramas, significan que se est entendiendo mejor el problema y el proceso se avanza de manera iterativa en la construccin de la solucin computacional.
Un evento es algo significativo que ocurre en un momento y que causa el cambio de estado. Una transicin modela el cambio de estado a causa de un evento. Se representa por una flecha que va de un estado a otro. La flecha se puede etiquetar con el nombre del evento.
El estado final que se denota por un crculo con un punto negro en el centro. Puede haber varios estados finales o ninguno.
32
Construccin de diagramas de estado para la navegacin Para modelar la navegacin en la interfaz de usuario, que es un aspecto dinmico de la construccin del sistema de software, se usan diagramas de estados. La navegacin en la interfaz de usuario es el cambio de pantallas que ve el usuario a causa de eventos que cambian el estado del sistema, como por ejemplo, la seleccin de una opcin en un men cambia el estado y puede aparecer otra pantalla. Para construir el diagrama de estados, que modela la navegacin, se parte del prototipo de interfaz de usuario construido en la fase de Especificacin de requerimientos. Las pantallas se representan por estados y los eventos, que ocasionan el cambio de un estado a otro, por las transiciones entre estados. Para modelar la navegacin en la interfaz de usuario con diagramas de estado, el estado inicial del diagrama, apunta al estado que representa a la pantalla de principal del sistema. En esta pantalla, por lo general, se tienen varias opciones para navegar. Cada opcin representa a un evento que puede llevar a otra pantalla. En el diagrama, cada pantalla se representa por un estado y los eventos etiquetan a las transiciones entre los estados.
Figura 3.7. Diagrama de navegacin. En la figura 3.7 se muestra el diagrama de estados para el sistema de Bolsa de trabajo. El estado inicial representa a la pantalla Principal. Dependiendo de las opciones del men que
33
Ciclo de Desarrollo de software se elijan, se pasa a los estados correspondientes. Si en el estado Principal, el evento es que se tiene un Registro Errneo, la transicin lleva al mismo estado.. Otro uso de los diagramas de estado, es modelar el orden vlido de ejecucin de casos de uso. Por ejemplo, el caso de uso de Autentificar al usuario que debe realizarse antes de cualquier otro caso de uso. Para modelar el orden vlido de ejecucin de los casos de uso, se parte del diagrama general de casos de uso. Cada caso de uso se modela como un estado y el paso de un caso de uso a otro a consecuencia de un evento, se modela por una transicin.
Referencias bibliogrficas
Arlow J., Neustadt I. UML2 and the Unified Process. Practical Object-Oriented Analysis and Design. 2a edicin. Addison Wesley 2005. Beck K., Cunningham W., SIGPLAN Notices October 1989, vol. 24 (10). Rumbaugh J., Jacobson I., Booch G. The Unified Software Development Process. Addison Wesley 1999.
34
Captulo 4 Diseo
35
Ciclo de Desarrollo de software Cohesin. Es el grado de relacin entre los elementos que pertenecen a un componente. Un buen diseo tiene un grado de cohesin fuerte entre los elementos de sus componentes. El libro de [Pressman] proporciona algunos criterios sencillos para medir el grado de cohesin de un componente: Escribir una frase que describa el objetivo de un componente. Si la frase tiene un solo verbo, el componente tiene un fuerte grado de cohesin. Si la frase es compuesta, contiene mas de un verbo o contiene comas, probablemente tiene una cohesin dbil y habra que definir un componente para cada verbo. Acoplamiento. Es el grado de relacin entre los componentes. Un buen diseo tiene un acoplamiento dbil entre sus componentes. Esto es, cada componente se relaciona con otros con pocas interacciones.
Un diseo es bueno si la cohesin de sus componentes es fuerte y el acoplamiento entre ellos es dbil. Los principios del diseo pueden usarse como criterios para evaluar los diseos. Es importante aclarar que no existe El buen diseo.
36
Ciclo de Desarrollo de software Una vez definida la arquitectura del producto de software, se representa con diagramas de paquetes de UML.
37
En la figura 4.1 se muestra un diagrama con las 3 capas de la arquitectura. Los paquetes de la capa de Presentacin son DesempleadosIH, VacantesIH y EmpresaIH. Los siguientes paquetes pertenecen a la capa de Lgica de la aplicacin, las relaciones que se muestran entre estos paquetes son dependencias. Por ejemplo el Paquete Postulaciones depende de Vacantes y de Desempleado. El paquete de Base de Datos contiene la capa del Almacenamiento.
38
Ciclo de Desarrollo de software Los elementos de estos diagramas son: los nodos y las conexiones entre ellos. Un nodo es un elemento fsico que existe y representa un recurso computacional [Booch]. Se representa por un cubo que debe nombrarse. Las conexiones son relaciones que representan las comunicaciones entre los nodos. Pueden etiquetarse con un protocolo de comunicacin. En la figura 4.2 se muestran los nodos de un sistema en web. La conexin entre servidor y el cliente es por el protocolo http.
Figura 4.2 Ejemplo de diagrama de distribucin Proceso para definir la arquitectura: 1. Seleccionar el tipo de arquitectura del software segn la aplicacin. Inicialmente se puede elegir la arquitectura de tres capas. Posteriormente, se puede revisar otras arquitecturas alternativas. 2. Identificar los paquetes para la arquitectura del sistema. 3. Construir el diagrama de paquetes. 4. En el caso de que sea un sistema distribuido, identificar la lgica de la distribucin. 5. Construir el diagrama de distribucin con los nodos y sus conexiones.
Un diagrama de componentes muestra la organizacin y las dependencias entre un conjunto de componentes. Cubre la vista de implementacin esttica y se relaciona con los diagramas de clase puesto que un componente puede contener una o ms clases. De hecho se puede construir un componente para cada caso de uso, de forma que contenga las clases de las capas de presentacin, lgica y de almacenamiento correspondientes. Algunos componentes pueden contener lo especfico de la plataforma de implementacin. A continuacin se muestra el diagrama de componentes del sistema.(Figura 4.3)
Figura 4.3. Diagrama de componentes El desarrollo de software basado en componentes favorece la reutilizacin de componentes y facilita el cambio.
40
Ciclo de Desarrollo de software En el diagrama de Entidad-Relacin, se mapea cada clase persistente a una Entidad. Los atributos de las clases se convierten en los atributos de las Entidades. Las relaciones entre las Entidades se construyen a partir de las relaciones entre clases.
4.4.1 Conversin del diagrama de clases al modelo de datos de una base de datos relacional
La estructura de una base de datos relacional es muy sencilla, pero esta sencillez dificulta el proceso de representar objetos completos. Cada clase del diagrama de clases se convierte en el esquema de una tabla en la base de datos relacional (figura 4.4). Se puede utilizar el mismo nombre de la clase para la tabla, aunque se acostumbra que ese nombre est en plural. Esta tabla tendr como campos los atributos de la clase, es decir, cada atributo se convierte en una columna de la tabla.
Figura 4.4 Clase Empresa. La clase Empresa del diagrama de clases se transforma en un esquema como el mostrado en la figura 4.5.
Figura 4.5 Relacin Empresas. En sistemas manejadores de bases de datos relacionales la visibilidad de cada atributo es siempre es pblica, as que esta parte se puede ignorar. Para el dominio de los atributos, es necesario tener una forma de relacionar los tipos UML con los tipos de datos de SQL. Es importante tratar de que las transformaciones sean sencillas, por ejemplo un tipo cadena en
41
Ciclo de Desarrollo de software UML podra traducirse como un VARCHAR (254) en SQL. Para tipos enumerados, y sobre todo si no se tienen dominios, se puede crear una tabla para el tipo y poner los valores en ella, pues de esta forma se podra adicionar nuevos valores cuando se requiera. Una sugerencia de transformacin es la siguiente:
Tabla 4.1. Equivalencia de tipos entre UML y SQL. Los manejadores relacionales dependen completamente de identidad explcita, por lo que no puede existir un identificador de objeto que no sea un valor de una columna de la tabla, ni puede haber apuntadores a valores o renglones. Transformar la identidad explcita de atributos marcados con la propiedad {OID} significa poner los atributos como columnas y establecer la restriccin de llave primaria sobre tales columnas. Una llave primaria en el campo de las bases de datos es el conjunto mnimo de atributos que definen de manera nica a todo el rengln de la tabla. La transformacin de la identidad implcita a identidad relacional explcita requiere agregar una columna de tipo entero a la tabla con la restriccin de unicidad. Para los atributos marcados con {OID alterno}, slo es necesario crear los atributos como columnas y poner restricciones de unicidad. Si el atributo no tiene la propiedad {nulo} significa que, en la definicin de la columna correspondiente, se debe establecer la restriccin de rechazar valores nulos para tal columna. En la creacin de tablas no hay nada con respecto a las operaciones, sin embargo existe la posibilidad de representar conducta en el esquema a travs de procedimientos almacenados. Conversin de interfaces. Ya que una interfaz contiene operaciones nicamente es necesario implementar los procedimientos almacenados correspondientemente, siempre u cuando sean adecuados para ejecutarse en el servidor de base de datos. Conversin de asociaciones. Una base de datos relacional contiene tablas, no asociaciones, por lo que las asociaciones deben integrarse a las tablas a travs de columnas especiales. En la conversin de una asociacin binaria a un esquema relacional se debe utilizar el concepto de llave externa. Una llave externa, es un conjunto de columnas cuyo valor debe estar en la llave primaria de la tabla con la que se est conectando.
42
Figura 4.6. Relacin de asociacin entre dos clases En el ejemplo de la figura 4.6, se est especificando que una empresa coloca de 1 a varias vacantes, y que cada vacante es colocada por una y slo una empresa. Las caractersticas de la multiplicidad, en la clase relacionada, se dividen en dos aspectos de inters para la transformacin relacional: en qu tabla generar columnas y cmo generar las restricciones de nulidad sobre las columnas. Si la multiplicidad contiene un mximo de 1 entonces la tabla correspondiente a esa clase tendr columnas como llave primaria que se incluirn en la tabla correspondiente a la clase asociada como llave externa.
Figura 4.7. Llaves externas. Notar en la figura 4.7, que en la tabla Empresas se define nombre como llave primaria (PK) y en la tabla Vacantes se tiene nombreE como llave externa (FK) con lo cual se especifica que nombreE debe ser el nombre de alguna empresa en la tabla Empresas y si es el mismo ambas tuplas estn relacionadas. En cada vacante slo hay una nombreE, es decir cada vacante es colocada por una empresa. Como el nombre de empresa se puede repetir en la llave externa se tiene que cada empresa puede colocar ms de una vacante. Si la multiplicidad contiene un cero (0..*,*,0..1) entonces se pueden permitir valores nulos en la llave externa.
43
Ciclo de Desarrollo de software Si la multiplicidad es de varios a varios como en la figura 4.8, no se puede representar directamente en el esquema relacional, es necesario crear una tabla en la base de datos para esta asociacin, como se muestra en la figura 4.9.
Figura 4.8. Asociacin n: n La asociacin varios a varios entre Desempleados y Vacantes se convierte en una relacin uno a varios entre Desempleados y DesempleadosVacantes ms una relacin muchos a uno entre DesempleadosVacantes y Vacantes como se muestra en la figura 4.9.
Figura 4.9. Tablas para la asociacin n: n Conversin de relaciones de agregacin La agregacin corresponde directamente a una llave externa en la tabla dependiente con acciones de actualizacin y borrado. Por ejemplo, cuando se borra un rengln en la tabla duea, debe borrarse los renglones asociados a su llave primaria en todas las tablas dependientes, esto es un borrado en cascada.
44
Figura 4.10. Relaciones de agregacin entre clases. Todo desempleado tiene un currculo y la informacin de ste se encuentra en la tabla Curriculum. Se crea la tabla para la informacin del currculo debido a que en una base de datos no puede haber columnas con atributos no-atmicos.(Figura 4.10)
Figura 4.11. Tablas para la relacin de agregacin entre clases. En este acaso, se agreg a cada tabla Currculum, figura 4.11, un identificador para facilitar la manipulacin de las llaves. De tal manera que en la tabla Desempleados se tiene un identificador de currculo como llave externa que debe corresponder con el identificador de algn currculum en la tabla de ellos. Conversin de relaciones de generalizacin Se crea una tabla para cada clase en la jerarqua de herencia, incluyendo las clases abstractas, despus se crean las llaves externas para cada relacin de generalizacin. Si la llave primaria de la superclase consta de varias columnas, se deben crear esas mismas columnas en cada subclase.
45
Figura 4.12. Jerarqua de clases. Tomando como ejemplo la jerarqua de herencia mostrada en la figura 4.12 se tienen las tres tablas mostradas en la figura 4.13. En tabla usuarios se tiene como llave primaria un identificador para cada usuario, ste se utiliza como llave externa en cada una de las tablas que representa a cada una de las subclases.
46
Ciclo de Desarrollo de software Lo importante en la conversin del modelo de datos UML al esquema relacional es ser muy sistemtico en el mtodo. Si se entiende como mapear cada concepto UML en conceptos relacionales es posible representar fcilmente la mayora de los aspectos del modelo.
Referencias bibliogrficas
Arlow J., Neustadt I. UML2 and the Unified Process. Practical Object-Oriented Analysis and Design. 2a edicin. Addison Wesley 2005. Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Languaje. Users guide. Addison Wesley 1999. Humphrey Watts S., Introduction to Team Software Process, SEI Series in Software Engineering, Addison Wesley, 2000. Jacobson I., Booch G., Rumbaugh J. The Unified Software Development Process. Addison Wesley 1999. Pressman
47
Captulo 5 Construccin
No todas las clases se codifican en un lenguaje de programacin. Por ejemplo, en una aplicacin web, las clases de interfaz pueden implementarse como cdigo html. Por otro lado, a partir de las clases de entidad, se disea la base de datos. En los paquetes se incluyen las clases necesarias del ambiente de programacin o las bibliotecas disponibles para la construccin de las clases. Algunas herramientas de diagramacin de UML ayudan a completar el diseo detallado a partir de los diagramas de clases, generando un esqueleto de cdigo. Cuando se tienen dichas herramientas la tarea de codificar consiste en detallar los diagramas y completar los esqueletos con el cdigo. Otra ventaja de estas herramientas es que se mantiene la
48
Ciclo de Desarrollo de software integridad entre los diagramas y el cdigo, por lo que los cambios en uno se reflejan en los otros.
49
Ciclo de Desarrollo de software Por ejemplo, un estndar de comentario de encabezado de una clase puede pedir que ste contenga los siguientes elementos: el propsito de la clase, sus autores, la fecha de creacin, su versin actual y referencias cruzadas a otras clases o archivos. Se recomienda usar estndares de codificacin ya existentes para el lenguaje de programacin que se va a usar. En su defecto, se sugiere generar el estndar propio acordado por el equipo de desarrollo y documentarlo.
50
Ciclo de Desarrollo de software resultado esperado para ese conjunto. Para cada mtodo se pueden definir uno o ms casos de prueba segn la complejidad del mtodo. Para hacer las pruebas unitarias de clases cada ingeniero define su Plan de las pruebas unitarias para las clases que est construyendo. En el Plan de pruebas unitarias se define: las clases que se probarn, los mtodos y los casos de prueba para cada mtodo. Una forma de especificar este plan es hacer una tabla con 4 columnas: La clase que se probar. Mtodo a probar. Los casos de prueba con los conjuntos de valores para los parmetros para cada mtodo. El resultado esperado de cada caso de prueba.
Resultado Esperado UsuarioRegistrado setNombre(nombre) Guarda el nombre UsuarioRegistrado setDireccion(calle,colonia, miCalle Guarda delegacin, CP) 1 los miColonia campos 1 de la MiDelegacion direccion 12345 Figura 5.3 Ejemplo de Plan de pruebas unitarias.
Clase
Mtodo
Realizacin de la prueba unitaria segn el Plan Para realizar la prueba unitaria de una clase, se crea un objeto de esa clase. Se invoca cada mtodo a probar con los parmetros definidos en sus casos de prueba. Si el resultado obtenido coincide con el esperado, el mtodo pasa esa prueba. Si no coincide, se revisa el cdigo del mtodo para encontrar la causa del defecto y corregirlo. Se vuelve a aplicar el mismo caso de prueba hasta que pase. Cuando una clase pasa todas las pruebas definidas en el Plan de pruebas unitarias, es aceptada. Tcnicas para definir los casos de prueba. Para definir los casos de prueba se usan dos tcnicas: las de caja blanca (transparente) y las de caja negra. En las pruebas de caja blanca se toma en cuenta la estructura del cdigo de un mtodo y se busca que durante las pruebas cada instruccin se ejecute al menos una vez. Las de caja negra, consideran al cdigo del mtodo como un todo oculto, verificando que para cada conjunto de valores de los parmetros se obtenga el resultado esperado.
51
A continuacin se explican en que consisten ambos tipos de prueba y algunas tcnicas para planear ese tipo de pruebas.
52
Ciclo de Desarrollo de software //Revisar si un estudiante ya tiene calificado un curso con anterioridad Public boolean yaCalificado (Curso c1, cursos) { 1 Boolean calificado = falso; // cursos es la lista de los cursos llevados por el estudiante 2 while (existen cursos del estudiante por revisar) { // se revisan todos los cursos llevados por el estudiante cursos c2 = otro curso llevado 3 if curso1 = curso2 { 4 if (c2.getCalificacion no es null){ 5 calificado = true; 6 break; 7 } // fin del segundo if 8 } // fin del primer if 9 } // fin del while 10 return calificado; 11 }
53
# 1 2
Casos de prueba
Resultado esperado
No hay cursos llevados por el estudiante (la condicin del while es falsa) falso falso
Hay un solo curso y no coincide con c1 (la condicin del while es verdadera y del primer if falsa)
Hay un solo curso, coincide con c1 y ya est calificado ( las condiciones del while y los dos if son verdaderas)
3 4
verdadero
falso
Hay un curso, coincide con c1 y no est calificado (las condiciones del while y del primer if son verdaderas y la del segundo if es falsa)
54
Ciclo de Desarrollo de software Condiciones de parmetros de entrada c1 es uno de los cursos del verdadero verdadero falso estudiante verdadero falso falso c1 tiene calificacin Resultados esperados El mtodo yaCalificado sea X verdadero El mtodo yaCalificado sea X X falso Figura 5.5 Ejemplo de tabla de decisin El Plan de pruebas unitarias de caja negra, creado a partir de la tabla de decisin, es una tabla que tiene como casos de prueba la combinacin de condiciones de valores cierto y falso para los parmetros de entrada y los resultados esperados. En la figura 5.6 se muestra el Plan de pruebas para la tabla de decisiones.
# 1 2 3
Casos de prueba
c1 est en los cursos y c1 tiene calificacin
falso
55
Otro tipo de sustituto es un Driver que es un programa que inicializa variables no locales y los parmetros para activar a la unidad que se est probando.
Referencias bibliogrficas
Beck K., Extreme Programming Explained, Addison Wesley, 2000. Humphrey Watts S., Introduction to Team Software Process. SEI Series in Software Engineering, Addison Wesley, 2000. Pressman R.S. Ingeniera del Software. Un enfoque prctico. McGraw Hill. Sommerville I. Ingeniera de Software. 6 Edicin, Addison Wesley, 2002.
56
No existe una estrategia adecuada para todos los sistemas, decidir cul usar es decisin del proyecto y el nivel de diseo efectuado. El elemento del paquete que no dependa de otros, es el primero que se integra. En el caso de las clases, una clase depende de otra si invoca alguno de sus mtodos. Bajo esta regla, se puede crear una grfica de dependencias entre clases que sirve de gua para definir el orden de integracin.
57
Al integrar los componentes se identifican los mtodos que se invocan entre clases. Estos mtodos deben ejecutarse para comprobar que el paso de parmetros y los resultados devueltos son los adecuados.
Tcnicas para la prueba funcionales del sistema. Al probar el sistema se debe comprobar que cumplan con los requerimientos y asegurar que todas las funcionalidades estn cubiertas. Una tcnica para documentar lo que se quiere probar son las tablas cruzadas. Una tabla cruzada contiene en los renglones los requerimientos y en las columnas los componentes del sistema. En el interior de la tabla se pone X si el requerimiento i est cubierto en el componente j para indicar en qu componentes estn cubiertos los requerimientos. requerimientos/componente componente 1 componente 2 Req. 1 X Req. 2 X Req. 3 X Req. 4 X Figura 9.1 Ejemplo de tabla cruzada. componente 3 X
58
Ciclo de Desarrollo de software De esta manera se tiene una lista de comprobacin de que se estn cumpliendo todos los requerimientos, pues ningn rengln deber estar vaco, lo que indica que al menos algn componente del sistema cubre ese requerimiento. Por otro lado, al revisar las columnas ninguna estar en blanco, lo que significa que los componente cooperan con al menos un requerimiento. Esta tabla documenta qu componentes cubren a qu requerimientos, lo que es til para mantener el sistema al hacer cambios a los requerimientos. Planeacin de las pruebas del sistema El plan de pruebas que debe incluir: Qu se va a probar. En qu orden. El material de prueba, esto es, el componente a probar, los datos de prueba, el software que se necesita. El resultado esperado para cada dato de prueba. Responsable de la prueba, los participantes en la prueba, la fecha y lugar en que se har la prueba. Plantilla para el informe de los resultados obtenidos indicando el nmero de defectos encontrados. Efectuadas las pruebas, se corrigen los defectos encontrados. Se vuelven a aplicar pruebas, conocidas como pruebas de regresin. Las pruebas de regresin sirven para detectar defectos al hacer cambios a componentes ya probados. Al iniciar un nuevo ciclo de desarrollo, se generan nuevos componentes o se modifican los que se tenan para incluir nuevas funcionalidades o caractersticas. Esos componentes pueden ocasionar fallas en lo que ya funcionaba por efectos laterales o nuevas interacciones. Si el sistema pasa todas las pruebas, se libera y entrega al cliente.
6.3 Manuales
Al construir un sistema, siguiendo el ciclo de desarrollo, se ha generando la documentacin del sistema para los desarrolladores en siguientes ciclos o para el mantenimiento. Sin embargo, generalmente se requiere de manuales para otros involucrados en el sistema, principalmente sus usuarios. Los manuales debern estar escritos en el lenguaje del lector a quien est dirigido.
59
Manual de usuario
Este manual debe contener informacin que permita usar el sistema. Es un documento electrnico o impreso que describe la forma de uso del software, organizado con base a la interfaz de usuario. El contenido debe incluir: Cmo se entra, qu aparece en la interfaz, qu se espera en cada opcin o campo, qu responder el sistema, cmo resolver problemas a la hora de la ejecucin. Este manual tambin podra contener informacin sobre la instalacin que pueda ser til al usuario.
Referencias bibliogrficas
Binder R. V. Testing Object-oriented Systems. Models, patterns and Tools. Addison Wesley 2000.
60