Desarrollo de Software (UML)

Ciclo de Desarrollo de Software
Material para los estudiantes
Guadalupe Ibargengoitia G. Hanna Oktaba Amparo Lpez Gaona
Material realizado bajo el convenio 19403-1688-29-XI-06 Microsoft-Facultad de Ciencias, UNAM
Ciclo de Desarrollo de software
Contenido Introduccin Captulo 1 Ciclo de desarrollo de software

1.1 Introduccin al ciclo de vida del software 1.2 Definicin de Ingeniera de Software 1.3 Software, su naturaleza y caractersticas 1.4 Principios de la Ingeniera de Software 1.5 Proceso de software 1.6 Ciclo de desarrollo de software 1.7 Lenguaje de Modelado Unificado UML
Captulo 2 Especificacin de requerimientos

2.1 Entender el problema 2.2 Especificacin de Requerimientos 2.3 Requerimientos funcionales. 2.3.1 Diagramas de casos de uso 2.4 Prototipo de interfaz de usuario 2.5 Requerimientos no funcionales
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
Guadalupe Ibargengoitia G., Hanna Oktaba
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
Captulo 6 Integracin y prueba del sistema

6.1 Integracin del sistema 6.2 Prueba del sistema 6.3 Manuales
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
Introduccin al ciclo de vida del software
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
Definicin de Ingeniera de Software
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.
1.3 Software, su naturaleza y caractersticas

Se entiende por software al cdigo generado por programas, escritos en algn lenguaje de programacin, que resuelve un problema. El software no es slo el cdigo, sino tambin los documentos asociados y la configuracin de datos que se requieren para que esos programas funcionen correctamente [Sommerville] y puedan ser mantenidos. El software es un nuevo tipo de producto que no se parece a ningn otro artefacto que sea tangible como puentes, casas, telfonos, etc. El software tiene una naturaleza diferente, por lo que es necesario entenderla. Algunas caracteristicas de la naturaleza del software son: El software se desarrolla, no se fabrica en un sentido clsico [Pressman] El software no es tangible como los productos de otras ingenieras. El software es fcilmente modificable y por lo tanto corrompible. El software no se desgasta con el paso del tiempo como puede pasar con el hardware, pero se puede deteriorar si al mantenerlo se le incorporan errores al tratar de corregir otros. [Pressman] Definir cuales son las caractersticas de calidad que debe tener un producto de software no es fcil, pues depende de a quin se le pregunte: al cliente, al analista, al desarrollador, el que har el mantenimiento, etc. Las caractersticas mas reconocidas son las siguientes: Funcionalidad (Functinality): si se comporta de acuerdo a las especificaciones de las funciones que debe ejecutar. Confiabilidad (Reliability): si el usuario puede depender de l y si se comporta "razonablemente" an en circunstancias no anticipadas en la especificacin de requerimientos. Usable (Usability): Si el usuario lo encuentra fcil de entender, aprender y usar. Eficiente (Efficiency): si usa sus recursos adecuadamente y proporciona un desempeo adecuado. Mantenible (Maintainability): Si es fcil hacerle modificaciones tales como correcciones, mejoras o adaptaciones. Portable (Portability): Si es posible correrlo en diversos ambientes o plataformas. Reusable: Si se pueden usar partes o todo para el desarrollo de un nuevo producto. Interoperable: Si puede coexistir y cooperar con otros sistemas.
1.4 Principios de la Ingeniera de Software

La Ingeniera de Software es relativamente reciente, por lo que no est tan madura como otras ramas de la Ingeniera. Sin embargo, existen algunos principios ya validados por la experiencia. Los principios segn [Ghezzi] son:
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.5 Proceso de software

El Proceso de software es el conjunto de actividades que se necesitan para transformar las necesidades de un cliente en un producto de software. Permite que los desarrolladores sepan qu hacer, cundo, cmo y quin es el responsable. En la siguiente figura 1 se modela el Proceso de software [Oktaba] por medio de diagramas de clase de UML. Los rectngulos representan clases, la relacin entre clases con un pequeo rombo significa agregacin o la relacin est compuesto por. Las lneas entre clases, significan asociaciones entre clases.
Proceso de Software
1..*
Fase
1..*
Producto 1..*
Actividad 1..*
Rol
Figura 1. Modelado del Proceso de software [Oktaba]
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.
1.6 Ciclo de desarrollo de software

En estas notas nos abocamos solo a la etapa de desarrollo de software que representa el inicio del ciclo de vida . En la etapa de desarrollo se usar tecnologa orientada a objetos para hacer la construccin del software. El proceso de desarrollo del software est basado en el Proceso Unificado [Jacobson], que est guiado por los casos de uso y es iterativo e incremental. Guiado por los casos de uso: Un caso de uso es una funcionalidad del sistema que proporciona al usuario un valor o servicio. Un usuario es una persona o un sistema que interacta con el software. Por lo que los casos de uso guan el desarrollo del software para que cumpla con las necesidades del usuario. Iterativo e incremental Una iteracin es la ejecucin de todos los pasos del ciclo de desarrollo. Un Incremento es la evolucin que va teniendo el producto a lo largo del tiempo. En el desarrollo se escogen algunos casos de uso iniciales para una iteracin y en versiones posteriores del software se incrementa incorporando otros casos de uso. Las iteraciones se deben planear y controlar.
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.
1.7 Lenguaje de Modelado Unificado UML

El Lenguaje de Modelado Unificado (UML por sus siglas en ingls) [Booch] es el estndar de la OMG (Object Management Group) para el modelado orientado a objetos y ser la herramienta de modelado en el curso por las siguientes razones: - Provee de un lenguaje de modelado expresivo y visual. - Es independiente de lenguajes de programacin y los procesos de desarrollo. - Cubre los requerimientos de modelado de los sistemas actuales, por ejemplo, sistemas concurrentes y distribuidos. - Est enfocado a proporcionar un lenguaje de modelado estndar y no a un proceso estndar. Hay dos tipos de diagramas en UML Diagramas estructurales. Muestran la estructura esttica y los elementos del sistema. Se dividen en los siguientes diagramas: Clases. Objetos Componentes Paquetes Distribucin Diagramas de comportamiento. Muestran la dinmica de la funcionalidad del sistema. Se dividen en los siguientes diagramas: Casos de uso Interaccin: Secuencia Comunicacin Tiempo Actividades Estados Para construir buenos diagramas se tienen las siguientes recomendaciones: Cada diagrama debe contener un aspecto del sistema. Contiene lo esencial para entender ese aspecto. Los diagramas se mantienen consistentes con su nivel de abstraccin.
Ciclo de Desarrollo de software Muestran lo necesario para transmitir su semntica.
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
Captulo 2 Especificacin de requerimientos
2.1 Entender el problema

Para construir un producto de software, es necesario contar con la cooperacin del cliente, entender cul es el problema que se desea resolver y cules son sus necesidades reales. La mayor parte de las veces, el cliente no tiene claro qu es lo que realmente necesita. Es el desarrollador el responsable de ayudar al cliente a entender y expresar sus necesidades para que el software las pueda satisfacer. Para identificar los requerimientos se consultan a los interesados a travs de varias tcnicas [Tomayco] como son: Hacer entrevistas. Aplicar cuestionarios. Observar a los futuros usuarios al realizar las tareas que apoyar el software. Revisar documentos o sistemas ya existentes que se pretenden mejorar. El cliente expresa de manera oral sus necesidades sobre el software que desea se le construya. Escribir un texto, entre el cliente y el desarrollador, que defina el problema, es una buena prctica que permite poner en blanco y negro las necesidades del software y ayuda al cliente a precisarlas. Por lo que la entrada inicial al proceso de desarrollo de software es escribir en un texto la Definicin del problema. El texto deber escribirse preferentemente en un lenguaje que entienda el cliente sin trminos tcnicos computacionales. Coad [Coad] propone una serie de estrategias al redactar ese texto para ayudar a aclarar el objetivo del software. Una de ellas es escribir una frase del tipo para ayudar a o para apoyar a que permiten saber el tipo de usuarios que tendr el software y para qu se usar. Otra estrategia que propone es que el desarrollador se d una vuelta por el ambiente de trabajo donde se usar el software, esto permite ver a los usuarios y el tipo de cosas que necesitan que el sistema haga para apoyarlos en su trabajo diario. Una estrategia ms, indica que se haga una lista de caractersticas o cualidades que deber tener el software, la que se puede escribir en orden de importancia. En el texto de la figura 2.1 se muestra una definicin del problema para construir un sistema para una bolsa de trabajo en internet. En l se aplican dos de las estrategias propuestas por Coad, usar la frase para apoyar a y hacer una lista de caractersticas.
11
DEFINICION DEL PROBLEMA: Bolsa de trabajo

Se desarrollar un sistema de bolsa de trabajo que apoye a desempleados y a empresas. Este sistema podr ser usado por desempleados que estn en busca de algn empleo y por empresas que estn en busca de empleados para ocupar una vacante. Los desempleados podrn ver las vacantes disponibles sin tener que registrarse, pero si el desempleado quiere postularse para una vacante tendr que registrarse forzosamente. Las empresas podrn publicar sus vacantes por medio de un contacto, el cual ser el responsable de los datos de la empresa, la empresa podr revisar quin se registr para ocupar la vacante publicada. La empresa podr contactarlo despus de revisar su solicitud y el currculo del desempleado.
Lista de caractersticas deseadas

1. Cualquier usuario podr ver las vacantes disponibles en el sistema de software. 2. El usuario que se interese por alguna vacante en el sistema y quiera postularse a ella tendr que registrar sus datos y agregar su currculo. 3. Las empresas tendrn que tener una clave de usuario y una contrasea para poder ver los postulados para su vacante. 4. Las empresas tendrn un representante, el cual ser el encargado de la administracin de los datos de la empresa y sus vacantes. 5. Las empresas slo podrn ver a los desempleados que se registraron para sus vacantes. 6. El sistema estar creado en ambiente Web y podr ser accedido mediante cualquier explorador Web. 7. El sistema deber de ser fcil de usar por algn usuario an sin tener ningn tipo de capacitacin para usar el sistema.
Figura 2.1. Ejemplo de Definicin del problema.
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
2.2 Especificacin de Requerimientos

Los requerimientos son el punto de partida para la construccin de un producto de software. Los Requerimientos de software son un rea de la Ingeniera de Software dedicada al estudio de la adquisicin, anlisis, especificacin, validacin y administracin de los requerimientos o necesidades de un software. [SWEBOK 2001]. Es una fase fundamental para la construccin de software con calidad. Se entiende por calidad en un producto de software aquel que cumple con las necesidades del usuario. Un requerimiento o necesidad es lo que el cliente, o un usuario necesitan que haga el software para resolver un cierto problema. Para definir los requerimientos deben colaborar conjuntamente varios roles: el equipo de desarrollo, el cliente (quien paga el software), los usuarios (quienes lo usarn en su trabajo diario). Muchas veces el cliente y el usuario son la misma persona. A todas estas personas se les llama en ingls stakeholders que se traduce por interesados o involucrados. La especificacin de requerimientos es como un mapa para entender el problema a resolver. Los mapas son una ayuda a llegar ms rpido al lugar deseado. Si no se tiene el mapa, se puede manejar a toda velocidad pero no necesariamente se llegar a la meta. Una caracterstica de los requerimientos es que cambian constantemente por muchas razones: se modifican las necesidades del cliente, cambia el ambiente, la tecnologa, etc. por lo que establecer los requerimientos es un proceso de negociacin entre el cliente y los desarrolladores, donde ambos entienden y acuerdan el objetivo del software. Los requerimientos deben formularse de forma clara, precisa y no ambigua. Para eso pueden usarse varias tcnicas al mismo tiempo: el lenguaje natural, que es claro para el cliente pero ambiguo; el modelado grfico, que es mas claro para el desarrollador y no es ambiguo, pero puede no ser claro para el cliente; prototipo de interfaz de usuario, til para ambos pues es una representacin visual de lo que har el software. Hay dos tipos de requerimientos: los funcionales y los no funcionales. Los funcionales incluyen: Las entradas y salidas de datos, los clculos o las funciones del software. Los no funcionales son las caractersticas o restricciones que se le piden al software: Necesidades de la interfaz externa como: tipo de usuario, hardware, software, comunicaciones, facilidad de uso por sus usuarios. Atributos del software tales como: eficiencia, disponibilidad, seguridad, conversin, portabilidad, mantenimiento. Restricciones del diseo: de formatos, de archivos, lenguajes, estndares, compatibilidad. Otros: base de datos, instalacin, etc.
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.
2.3 Requerimientos funcionales

Para especificar los requerimientos funcionales se usarn los casos de uso los que sern el hilo conductor de todo el proceso de desarrollo. Esta tcnica se utiliza para identificar los requerimientos funcionales y a partir de ellos se disea, implementa y prueba el software. Permite rastrear los requerimientos a travs de todo el proceso de desarrollo hasta el producto terminado.
2.3.1 Diagramas de casos de uso

Los casos de uso proporcionan una manera incremental y modular de describir software. Definen como utilizan el software sus usuarios. El conjunto de casos de uso conforma el modelo de casos de uso que describe el comportamiento general del sistema. Los casos de uso proporcionan una representacin que puede ser fcilmente comprendida por todos los interesados. Se representan grficamente con Diagramas de caso de uso de UML.
Elementos de los diagramas de casos de uso
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
Figura 2.3 Diagrama general del sistema de Bolsa de trabajo.
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
Criterios para identificar los actores y casos de uso:

1. Para identificar un actor se revisa la definicin del problema a fin de definir el tipo de usuarios u otros sistemas que interactan con el software. Se nombran con mayscula y en singular. 2. Los candidatos para actores son roles generales, no personas concretas. Por ejemplo, Desempleado y no Juan Prez. 3. Los casos de uso representan las necesidades de los usuarios del sistema que podrn ser modeladas y validadas en uno o varios casos de uso. 4. Para identificar los casos de uso, se revisa la definicin del problema para cada actor, buscando las funcionalidades generales que requiere.
Detalle de los casos de uso

Una vez identificados los principales casos de uso para cada actor, se describe en detalle cada uno. La plantilla que se propone para esta descripcin es: Nombre: El nombre deber ser un verbo en infinitivo representativo de la funcionalidad del caso de uso. Actor: Nombre del actor encargado de iniciar la accin y que recibe el resultado del caso de uso. Diagrama detallado del caso de uso indicando el actor y sus variantes o detalles. Descripcin: Texto breve describiendo la accin. Precondiciones: Acciones previas del estado del sistema para que se pueda iniciar el caso de uso. Flujo de eventos normales: Tabla que describe el flujo de acciones entre el actor y el sistema durante el caso de uso. Flujo de eventos alternativos: Tabla con las acciones que ocurren en situaciones alternativas o excepcionales. Postcondiciones: Define el estado del sistema despus de la terminacin exitosa del caso de uso. Ejemplo del detalle del caso de uso de Consultar vacante
Caso de uso: Consultar Vacante

Actor: Visitante
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.
2.4 Prototipo de interfaz de usuario

Un prototipo de interfaz de usuario es una representacin parcial de la interfaz de usuario que tendr el software, que muestra la forma en que el usuario interaccionar con l. Este
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
Figura 2.5 Pantalla para Dar de alta una vacante
2.5 Requerimientos no funcionales

Los requerimientos no funcionales tienen que ver con los atributos o caractersticas que el cliente solicita para el funcionamiento del software. Los requerimientos no funcionales pueden ser: Interfaz con el usuario: descripcin de las caractersticas que permitan al software apoyar al usuario en sus tareas. Interfaz externa: relacin o conexin con otros sistemas. Confiabilidad: solicitud del desempeo respecto a seguridad, tolerancia a fallas y su recuperacin. Eficiencia: lmites de tiempo de respuesta. Mantenimiento: facilidad de comprensin y realizacin de modificaciones futuras. Portabilidad: facilidad de transferencia de un ambiente de ejecucin a otro. Restricciones de diseo y construccin: las que imponga el cliente. Legales y reglamentarios: necesidades impuestas por leyes o reglamentos de otros. Ejemplo de la descripcin de requerimientos no funcionales: Interfaz con usuarios Guadalupe Ibargengoitia G., Hanna Oktaba 21
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.
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
3.1 Introduccin al Anlisis

El objetivo del anlisis es revisar los requerimientos para crear una descripcin abstracta del sistema a construir, as como entender mejor los requerimientos e identificar omisiones. El enfoque en la fase de anlisis es descubrir qu har el sistema y no cmo, dejando esta tarea para la fase de diseo. El trabajo en el anlisis es construir el modelo del anlisis que consiste en identificar los elementos con los que se construir el sistema y estructurarlos de tal forma que conformen una primera versin de la arquitectura del sistema. En el caso del anlisis orientado a objetos los elementos del modelo sern clases. Para documentar los resultados del anlisis orientado a objetos se construyen dos vistas: la vista esttica, formada por diagramas de clase que representan los elementos estructurales y sus relaciones; y la vista dinmica con las interacciones de los objetos de esas clases que se modela con diagramas de secuencia.
3.2 Vista esttica

Para identificar distintos tipos de clases se usan tres estereotipos: Clases de interfaz (interfaz con el usuario). Son los elementos con los que interacta directamente el usuario: las ventanas, pginas, informes, etc. Al identificar estas clases, se les puede poner al nombrarlas el sufijo IH para diferenciarlas de las clases de los otros estereotipos. Clases de control (reglas del negocio o aplicacin). Son los elementos que implementan las reglas del negocio y la lgica de la aplicacin. Clases de entidad (bases de datos, archivos). Son los elementos que guardan la informacin para asegurar su persistencia. Estas clases pueden tener en su nombre el sufijo BD. Estos tres estereotipos estn definidos por UML para facilitar la identificacin de las clases del sistema que se incluyen en los diagramas de clases, que forman la vista esttica del modelo del anlisis.
3.2.1 Diagramas de clases
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..*
Alta() Modificar() ConsultarDatos() Eliminar()
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.
Construccin del diagrama de clases a partir de las tarjetas CRC:
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
<<Pantalla>> VerPostuladosIH -Vacante -Empresa -Desempleado +Abrir() +Maximizar() +Minimizar() +Cerrar()
<<Forma de enrada>> AltaDesempleadoIH -Desempleado +Abrir() +Maximizar() +Minimizar() +Cerrar() +CapturarDatos()
<<Forma de entrada>> ModificarDesempleadoIH -Desempleado +Abrir() +Maximizar() +Minimizar() +Cerrar() +CapturarDatos()
<<Pantalla>> VerDatosPersenalesIH -Desempleado +Abrir() +Maximizar() +Minimizar() +Cerrar()
<<Pantalla>> EliminarDesempleadoIH -Desempleado +Abrir() +Maximizar() +Minimizar() +Cerrar()
<<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()
<<Pantalla>> PrincipalIH +Abrir() +Maximizar() +Minimizar() +Cerrar()
<<Forma de entrada>> AltaVacanteIH -Vacante +Abrir() +Maximizar() +Minimizar() +Cerrar()
Figura 3.4 Diagrama de clases de Interfaz
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
Figura 3.5 Diagrama de clases de Entidad.
3.3 Vista dinmica

La vista dinmica describe cmo interactan los objetos para entregar la funcionalidad requerida del sistema. Hay varios diagramas de UML para representar esta vista. Los diagramas de secuencia describen la interaccin entre los objetos de las clases que intervienen en cada caso de uso. Los diagramas de estado modelan el cambio de estados de entidades del sistema.
3.3.1 Diagramas de secuencia

Los diagramas de secuencia muestran la interaccin entre los objetos de las clases como una secuencia de envo de mensajes entre ellos ordenados en el tiempo. Los elementos de estos diagramas son: Objetos son instancias de las clases. Se representan por un rectngulo con el nombre subrayado de la clase a la que pertenecen. En el diagrama, cada objeto tiene una lnea vertical que representa su lnea de tiempo que avanza de arriba abajo.
29

:vacante
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).
3.6 Ejemplo de diagrama de secuencia vlido
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.
3.3.2 Diagramas de estados

Para modelar el cambio de estados de entidades del sistema, que es otro aspecto de la vista dinmica, se usan los diagramas de estados de UML. Un diagrama de estados modela una mquina de estados finitos o autmata, que enfatiza el flujo de control de un estado a otro. Es una grfica con nodos que representan estados y arcos dirigidos que representan transiciones entre los estados a causa de eventos. Los elementos de estos diagramas son: Un estado es la condicin de una entidad del sistema. Puede caracterizar a un objeto o representar a una pantalla, que cambian de estado a causa de eventos. Los estados se representan por rectngulos con esquinas redondeadas con el nombre del estado.
Principal
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 inicial se dibuja como un punto negro.
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.
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
4.1 Introduccin al Diseo

El diseo de software es un proceso creativo para decidir cmo se construir el producto de software [Humphrey]. Los objetivos del diseo son: identificar y caracterizar las partes o componentes principales del software, definir su interaccin e integracin en el producto. En esta fase el enfoque es definir cmo se construir el sistema. El proceso del diseo tiene dos niveles de abstraccin: el arquitectnico y el detallado. El diseo arquitectnico identifica los componentes principales partiendo de la especificacin de requerimientos y del anlisis. El diseo detallado especifica en detalle los componentes tomando en cuenta el ambiente en que se codificar.
4.1.1 Principios del diseo

Algunos principios del diseo [Humphrey] son los siguientes: Disear para el cambio. Como se indic en los principios de la Ingeniera del software, el software cambia constantemente, por lo que es fundamental anticiparse a los cambios. Esto significa que el diseo debe ser flexible para permitir cambios con relativa facilidad. Disear para facilitar el uso del software. Es importante disear teniendo en mente a los usuarios del software y sus aptitudes. Considerar algunos escenarios del uso del software, puede ayudar en la identificacin de los componentes que deber tener. Disear para facilitar la prueba. Este principio est enfocado en el desarrollador que probar el sistema. Se identifican los componentes del sistema como unidades que se puedan probar sin necesidad de incluir a otros componentes. Disear para la reutilizacin. Una manera de mejorar la productividad del equipo en proyectos futuros o en ciclos siguientes, es definir partes genricas que puedan volver a usarse. Para aplicar este principio, se deben identificar los componentes comunes que se podrn reutilizar. El reuso incluye no solo el nivel del diseo, sino de cdigo, casos de prueba, modelos o diagramas. Para apoyar la aplicacin estos principios del diseo, se tienen dos medidas que ayudan a estructurar e identificar los componentes:
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.
4.2 Arquitectura de software

La arquitectura de software es el diseo del ms alto nivel. Consiste en definir cules sern los componentes que formarn el software. La arquitectura debe favorecer el cumplimiento de los requerimientos funcionales y no funcionales especificados para el producto. Las cualidades que debe tener la arquitectura son: Sencillez. Que sea fcil de comprender y de implementar. Extensin. La posibilidad de agregar nuevos componentes. Cambio. Que los cambios en los requerimientos no afecten mucho a la arquitectura. El modelo de capas, es la base de la arquitectura de un sistema cuando es posible estructurar la solucin en grupos de tareas, donde cada grupo tiene un nivel de abstraccin particular. Una capa es una abstraccin que toma el resultado de la capa inferior, efecta su funcin y entrega ese resultado a la capa superior. La regla en este modelo es que cada capa se comunica solamente con las capas adyacentes. Para definir la arquitectura se usarn las siguientes capas: Capa de Presentacin. En esta capa se ponen los elementos con los que interacta directamente el usuario: las ventanas, pginas, informes, etc. Capa Lgica de la aplicacin. Son los elementos que implementan las reglas del negocio y la lgica de la aplicacin. Capa de Almacenamiento. Contiene los elementos que guardan la informacin para asegurar su persistencia tales como bases de datos o archivos.
36
Ciclo de Desarrollo de software Una vez definida la arquitectura del producto de software, se representa con diagramas de paquetes de UML.
4.2.1 Diagrama de paquetes

Un paquete es un mecanismo general de UML para organizar elementos en grupos. Los paquetes sirven para representar las capas de la arquitectura. Un paquete se representa con una carpeta con su nombre. Los paquetes pueden contener otros paquetes, clases, interfaces, cdigo html, etc. Los elementos de cada paquete deben tener una alta cohesin y bajo acoplamiento con los elementos de otros paquetes. Un diagrama de paquetes contiene los paquetes y las relaciones entre ellos. Tipos de relaciones entre paquetes: Dependencia (se representa por una flecha punteada). Un paquete B depende de otro paquete A, si un cambio en A, puede afectar al que depende de l, o sea el B. En este caso, la flecha de dependencia parte de B y apunta al paquete A. Asociacin (se representa por una lnea continua). Establece una relacin entre dos paquetes que requieren de los servicios uno del otro. Esta relacin es bidireccional. Generalizacin (se representa por una lnea continua con tringulo transparente que apunta hacia el paquete ms general). Un paquete representa los aspectos ms generales y otro los especializa, es la relacin de herencia. Realizacin (se representa por una lnea punteada con triangulo transparente que apunta hacia el paquete que va a ser realizada por otro). Es un contrato que promete que un paquete va a ser implementado por otro. La arquitectura de 3 capas se representa por paquetes que son una refinacin de las capas del Anlisis: Capa de Presentacin. Esta capa puede contener uno o varios paquetes que contengan la interfaz de usuario. Por ejemplo, el paquete de la interfaz en el servidor y el paquete con la interfaz del cliente. Los paquetes de la capa de Presentacin tienen el sufijo IH. Capa de Lgica de la aplicacin. En general, esta capa contiene varios paquetes, uno para cada funcionalidad del sistema. Estos paquetes pueden tener relaciones de dependencia, asociacin o generalizacin. Capa de Almacenamiento. En este paquete puede estar la base de datos o archivos en uno o ms paquetes. Las relaciones entre estos tres paquetes sern de asociacin del paquete de nivel inferior (Almacenamiento), al intermedio (Lgica de la aplicacin) y de ste al superior (Presentacin).
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.
Fig. 4.1 Ejemplo de diagrama de paquetes.
4.2.2 Diagrama de distribucin

Un sistema es distribuido si se ejecuta en ms de una mquina y sus componentes se encuentran distribuidos en ellas. Los diagramas de distribucin representan los componentes que se instalarn en cada mquina y las conexiones entre ellos. Para mostrar este aspecto de la arquitectura, UML tiene los diagramas de distribucin (deployment).
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.
4.3 Construccin de componentes

Para disear en detalle el sistema se usarn componentes a fin de organizar el diseo en piezas manejables. Un componente es como una caja negra con un comportamiento bien definido que encapsula una cierta parte del diseo y que proporciona interfaces para interaccionar con l. Los componentes tienen interfaces de entrada que especifican lo que se debe proporcionar para su ejecucin e interfaces de salida que especifican lo que entregan al ejecutarse. Pueden contener otros componentes relacionados entre s por dependencias. Hay varios tipos de componentes:[Arlow] Subsistemas que son formas de descomponer sistemas grandes en unidades jerrquicas De construccin, definen un conjunto de cosas para organizar la construccin. De entidad, son componentes persistentes que representan algn concepto que debe almacenarse. Guadalupe Ibargengoitia G., Hanna Oktaba 39
Ciclo de Desarrollo de software Proceso, es un componente basado en una transaccin. Etc.
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.
4.4 Diseo de la base de datos

A partir de las clases de tipo persistente de la capa de almacenamiento, se disea la base de datos. Para modelar la base de datos se usan los conocimientos y tcnicas de un curso de Bases de Datos.
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.
Figura 4.13. Tablas para una jerarqua de clases.
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.
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
5.1 Diseo detallado de clases

En el diseo detallado se completan los diagramas de clases incluyendo los detalles necesarios para su codificacin. El nivel al que se detallan estos diagramas debe ser suficiente para que se construya su cdigo. El detalle de las clases de control incluye: nombres y tipos de todos los atributos, para los mtodos se especifican los parmetros con sus tipos y el tipo del valor de retorno. Si algn mtodo requiere para su implementacin de un algoritmo ms complejo, ste se especifica en seudo-cdigo. La Figura 5.1. muestra un ejemplo de diseo detallado de una clase.
Figura 5.1 Ejemplo del diseo detallado de una clase.
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.
Figura 5.2 Diagrama de clases detalladas
5.2 Estndares de codificacin

El cdigo de un lenguaje de programacin se genera con el fin de que sea compilado y ejecutado por la mquina. Sin embargo, este mismo cdigo tambin tiene que ser comprendido por los seres humanos. En primer lugar debe de entenderlo el propio autor del programa aunque pase un mes desde que lo cre por primera vez. Tambin deben de entenderlo otros desarrolladores, que forman parte del equipo, o gente que dar el mantenimiento al programa. Con tal objetivo se establecen estndares de codificacin y documentacin de sistemas de software. Un estndar de codificacin es un conjunto de normas para hacer los programas ms legibles. Define las convenciones para escribir los encabezados de los paquetes o clases, para nombrar clases, atributos, mtodos y parmetros, para estructurar de manera legible las instrucciones de control, manejo de errores etc.
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.
5.3 Revisin de cdigo y programacin entre pares

Para evitar defectos en el cdigo que se genera a partir del diseo detallado, [Humphrey] propone leer el cdigo antes de la compilacin para eliminar defectos de forma temprana. Es una actividad que es poco practicada por las prisas de compilar para encontrar los defectos en el cdigo recin escrito. Pero al compilador se le escapan los defectos de la lgica del programa. La lectura detenida del cdigo por una persona antes de compilar puede detectar esa clase de defectos y corregirlos de manera oportuna. Una alternativa para generar el cdigo y leerlo a la vez por dos personas, es la programacin entre pares [Beck]. La idea principal de la programacin entre pares es que el cdigo se escribe entre dos personas sentadas frente de una sola mquina. Un miembro de la pareja tiene el control sobre el teclado y el ratn y es el que est codificando. La otra persona lee lo que se va escribiendo, analiza el cdigo, revisa la lgica y la sintaxis, y comenta posibles alternativas y errores a su pareja. Este trabajo es dinmico, los roles dentro de la pareja pueden cambiar constantemente. Con esta prctica se hacen revisiones constantes al cdigo pues quien no tiene el control del teclado, est leyndolo en cuanto se teclea y detecta errores que sera difcil y tardado de encontrar posteriormente. Aunque aparentemente con la programacin entre pares se avanza mas lento, la prctica ha demostrado que esto no necesariamente es verdad y que el cdigo que se obtiene est mas libre de errores lo que hace que tenga mejor calidad.
5.4 Pruebas unitarias

Las pruebas unitarias consisten en probar cada unidad lgica de cdigo que se va terminando. En la orientacin a objetos, la unidad lgica de prueba es la clase. Se deber asegurar la calidad de las clases probndolas detenidamente. Las clases se prueban a travs de la invocacin de sus mtodos. Para probar los mtodos de una clase se definen casos de prueba. Un caso de prueba de un mtodo consiste en definir un conjunto representativo de valores para los parmetros del mtodo y el valor del
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
Caso de Prueba miNombre
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.
5.4.1 Pruebas de caja blanca

Las pruebas de caja blanca tambin se conocen como pruebas estructurales. Se revisa la estructura lgica de la unidad a probar tratando de definir casos de prueba que permiten ejecutar por lo menos una vez, cada una de las instrucciones del mtodo. Una tcnica que se usa como gua para saber cuntos casos de prueba se deben definir para recorrer todas las instrucciones de la unidad por lo menos una vez, es la complejidad ciclomtica de McCabe. La complejidad ciclomtica se define como el nmero de condiciones encontradas en el cdigo ms 1. Una condicin es un punto de decisin, como por ejemplo if, while, for, etc. Para planear las pruebas de caja blanca usando la complejidad ciclomtica se determina el nmero de casos de prueba necesarios usando la frmula de la complejidad ciclomtica. Segn este nmero, se definen los casos de prueba como conjuntos de valores de las variables, que permitan recorrer las diferentes trayectorias del cdigo. Para cada condicin, se eligen valores de las variables para que sea en una ocasin verdadera y en otra falsa. Para cada conjunto de valores se define el resultado esperado. Ejemplo de un plan de pruebas con la complejidad ciclomtica: En la figura 5.4, se muestra un seudocdigo de un mtodo que revisa si un alumno ya tiene calificacin para un curso c1. Se tiene una condicin (while) para buscar en todos los cursos calificados del alumno y dos condiciones (if) para identificar si fue o no calificado. La complejidad ciclomtica de este cdigo es por lo tanto de 4. Los casos de prueba para este cdigo seran: 1. No hay cursos llevados por el estudiante (la condicin del while es falsa) 2. Hay un solo curso y no coincide con c1 (la condicin del while es verdadera y del primer if falsa) 3. Hay un curso, coincide con c1 y ya est calificado (las condiciones del while y de los dos if son verdaderas) 4. Hay un solo 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)
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 }
Figura 5.4 Ejemplo de un seudocdigo
El plan de prueba para este mtodo es:
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)
5.4.2 Pruebas caja negra

Este tipo de prueba, tambin conocida como prueba funcional, revisa que la unidad cumpla con la funcionalidad esperada sin considerar el detalle del cdigo. Para definir los casos de prueba, se establecen los posibles resultados esperados de la unidad y se identifican los conjuntos de valores de los parmetros, para que se generen estos resultados. Una tcnica para disear los casos de prueba de caja negra son las Tablas de decisin. Las tablas de decisin ayudan a describir combinaciones de datos de entrada que generan diferentes salidas. Una tabla de decisin tiene 2 secciones: Condiciones de parmetros de entrada: En la parte superior de la tabla se define la lista de condiciones de los parmetros de entrada y sus posibles combinaciones de valores cierto y falso. Resultados esperados: Las dos secciones de abajo especifican los resultados esperados para las combinaciones de valores de las condiciones de entrada. Se marca con X que resultado se espera para cada posible combinacin de valores de los parmetros. En la figura 5.5 se muestra la tabla de decisiones para el ejemplo de la figura 5.3.
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
Resultado esperado verdadero

falso
c1 est en los cursos y no tiene calificacin

c1 no est en los cursos y no tiene calificacin
falso
Figura 5.6 Plan de prueba caja negra.

Las tablas de decisin es una tcnica que se puede emplear durante el desarrollo del software, en diferentes etapas, cuando hay combinaciones de condiciones para ayudar en la toma de decisiones. Efectuar las pruebas Para efectuar las pruebas unitarias, se recomienda primero ejecutar los casos de prueba de caja negra. Posteriormente se agregan otros casos de prueba que permitan revisar la estructura, segn la tcnica de caja blanca. Muchas veces al querer probar una operacin o mtodo requiere de otros que no estn disponibles. Para simular su comportamiento se declaran mtodos sustitutos llamados Stubs. Los sustitutos no hacen nada excepto regresar el valor esperado, por lo que se puede programar una pequea interfaz por el cual el programador simula que se invoc el mtodo y que eventualmente proporciona el resultado esperado.
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.
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
Captulo 6 Integracin y prueba del sistema 6.1 Integracin del sistema

El objetivo de la integracin es unir todos los componentes construidos y probados para comprobar que funcionen bien juntos. Para hacer la integracin, se usa como gua el diseo arquitectnico, y se asegura que se tienen todos los componentes definidos en el diseo en la ltima versin aprobada. Cuando ya se tienen todos los componentes en los paquetes de la arquitectura, se planea como se irn integrando en un sistema completo. Se planea la integracin identificando el orden en que se unirn los paquetes de la arquitectura. A esto se le conoce como integracin del sistema. Adems, se proponen las pruebas que se aplicarn para verificar la correcta interaccin entre estos componentes. Estrategias para la integracin del sistema Para definir el orden de integracin de los elementos del sistema, se puede seguir alguna de estas estrategias [Binder] Estrategia de paquetes. La idea es hacer las integraciones segn los paquetes del diseo. Por ejemplo, se integran todos los elementos del paquete de interfaz de usuario para un actor. Este enfoque tiene la ventaja, de que se integran los componentes de un paquete y posteriormente se unen a otros paquetes ya integrados, siguiendo la arquitectura. Estrategia por funcionalidad o casos de uso. La idea es integrar los paquetes de las tres capas que corresponden a la realizacin de un caso de uso. Se puede hacerlo para varios casos de uso en paralelo, cuando no hay dependencia entre ellos.
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.
6.2 Prueba del sistema

En la prueba del sistema ya integrado, se trata de comprobar que el sistema cumple con todos los requerimientos establecidos, tanto los funcionales como los no funcionales. Como es muy difcil probar al cien por ciento todos los aspectos del sistema, se debe planear a qu se le dar prioridad. Por ejemplo, se puede decidir primero asegurar que cumple con sus funciones, luego evaluar la usabilidad, posteriormente comprobar el sistema bajo condiciones de estrs y medir el desempeo. Se prueban los siguientes aspectos definiendo casos de prueba para: La instalacin del sistema. Funcionalidades segn los casos de uso La usabilidad del sistema con la participacin de usuarios reales. Se deben incluir pruebas de los otros requerimientos no funcionales como: Rendimiento Robustez recuperacin de errores de hardware Tiempo de respuesta Capacidad de carga (memoria, accesos)
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.
Manual de operacin o instalacin

Debe estar escrito de forma que lo entienda el encargado de la instalacin del software. Puede estar en formato impreso o electrnico. Su contenido ser: La versin que se est instalando. Necesidades de hardware indicando capacidades y velocidades mnimas. Necesidades de software con versiones mnimas. Procesos para la instalacin. A quin recurrir en caso de problemas. Se aplican pruebas de usuario a cada manual para asegurarse que la escritura es clara, precisa, completa y entendible.
Binder R. V. Testing Object-oriented Systems. Models, patterns and Tools. Addison Wesley 2000.
60

Desarrollo de Software (UML)

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Desarrollo de Software (UML)

Uploaded by

Copyright:

Available Formats

Ciclo de Desarrollo de Software

Material para los estudiantes

Guadalupe Ibargengoitia G. Hanna Oktaba Amparo Lpez Gaona

Material realizado bajo el convenio 19403-1688-29-XI-06 Microsoft-Facultad de Ciencias, UNAM

Ciclo de Desarrollo de software

Contenido Introduccin Captulo 1 Ciclo de desarrollo de software

Captulo 2 Especificacin de requerimientos

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

Captulo 6 Integracin y prueba del sistema

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

Introduccin al ciclo de vida del software

Definicin de Ingeniera de Software

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

1.3 Software, su naturaleza y caractersticas

1.4 Principios de la Ingeniera de Software

Guadalupe Ibargengoitia G., Hanna Oktaba

1.5 Proceso de software

Figura 1. Modelado del Proceso de software [Oktaba]

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

1.6 Ciclo de desarrollo de software

Guadalupe Ibargengoitia G., Hanna Oktaba

1.7 Lenguaje de Modelado Unificado UML

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software Muestran lo necesario para transmitir su semntica.

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

Captulo 2 Especificacin de requerimientos

2.1 Entender el problema

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

DEFINICION DEL PROBLEMA: Bolsa de trabajo

Lista de caractersticas deseadas

Figura 2.1. Ejemplo de Definicin del problema.

Guadalupe Ibargengoitia G., Hanna Oktaba

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

2.2 Especificacin de Requerimientos

Guadalupe Ibargengoitia G., Hanna Oktaba

2.3 Requerimientos funcionales

2.3.1 Diagramas de casos de uso

Elementos de los diagramas de casos de uso

Guadalupe Ibargengoitia G., Hanna Oktaba

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

Figura 2.3 Diagrama general del sistema de Bolsa de trabajo.

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

Criterios para identificar los actores y casos de uso:

Detalle de los casos de uso

Caso de uso: Consultar Vacante

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

2.4 Prototipo de interfaz de usuario

Guadalupe Ibargengoitia G., Hanna Oktaba

Guadalupe Ibargengoitia G., Hanna Oktaba

Ciclo de Desarrollo de software

Figura 2.5 Pantalla para Dar de alta una vacante