Pautas para documentar desarrollos de sistemas Basado en el documento homnimo, versin 3, generado por el GCBA (http://www.buenosaires.gov.ar/dgsinf/estandares/pautas_sistemas%203.0.

zip) Para agilizar el seguimiento de los proyectos de desarrollo de software, as como para minimizar el impacto del futuro mantenimiento que estos sistemas puedan req uerir, se han fijado pautas para su documentacin, de modo que haya un aceptable g rado de uniformidad en todo el mbito de la Administracin Pblica Provincial. La documentacin de un desarrollo de sistemas no se puede concebir como una activi dad aislada, sino como el resultado esperado de una metodologa de trabajo, de un proceso con sus etapas y tareas en cada etapa. Por lo tanto, habr distintos docum entos que se irn generando en cada etapa. Atentos a los desarrollos actuales en materia de Tecnologa de la Informacin y a la s tendencias del mercado, se permitir abordar la documentacin desde las dos estrat egias de desarrollo ms usuales, las denominadas Ciclo de vida Estructurado y Orie ntacin a Objetos. Esta eleccin no supone negar que existan otros enfoques para el desarrollo de sistemas que estamos dejando de lado, y que se podrn analizar en ca da caso. Ms all de que existen diversas metodologas, recomendamos la adopcin de la Orientacin a Objetos, ya que este tipo de metodologa, adems de estar imponindose en todos los desarrollos de un par de aos a esta parte, incorpora la idea del desarrollo incre mental con alta participacin de usuarios. Lo que sigue es, entonces, una gua para la documentacin, confeccionada con el obje tivo de reunir, compatibilizar y sintetizar los planteos ms usuales de ambas meto dologas utilizando la terminologa ms habitual para cada una. A continuacin describimos: La documentacin que, al fin de cada etapa, deber entregarse segn la metodologa de clo de Vida Estructurado. La documentacin que, al fin de cada etapa, deber entregarse segn la metodologa de ientacin a Objetos. Algunas consideraciones sobre la actualizacin de la documentacin en relacin a las areas de mantenimiento de la aplicacin, luego de su puesta en produccin. En todos los casos, la Direccin General de Gobierno Digital puede determinar que cierta documentacin es optativa en un determinado proyecto, basndose en el tamao y grado de complejidad del mismo. a.- Ciclo de vida estructurado ETAPA DOCUMENTACION TAREAS Definicin de Requerimientos Diagnstico de la situacin y necesidad del sistema Modelo del Ambiente: Declaracin de Propsitos Diagrama de Contexto Lista de Eventos o Catlogo de Requerimientos Glosario Diagrama de Gantt del proyec to (preliminar) Deteccin de objetivos y lmites del sistema y su interaccin con el a mbiente En base a entrevistas con usuarios Anlisis Modelo de Comportamiento Diagrama de Flujo de Datos Especificacin de procesos Diagrama Entidad Relacin Diccionario de Datos Diagrama de Transicin de Estados Diagrama de Gantt del proyecto (actualizacin) Formalizacin de objetivos, independiente de la naturaleza de la tecnologa a aplica r y de cualquier cuestin de implantacin Determinacin de entidades, con atributos e interrelaciones Determinacin de procesos Diseo Modelo del usuario Modelo del Procesador oDiagrama de hardware oJustificacin del entorno tecnolgico

Modelo de Tareas: Diagrama de Fronteras Modelo de implantacin de programas: Diagrama estructurado Interfaces de usuario: Prototipos de pantallas y reportes Base de datos: estructura Diagrama de Gantt del proyecto (actualizacin) Eleccin del entorno tecnolgico Establecimiento de la arquitectura de la aplicacin Diseo de Interfaces de usuarios y procesos Desarrollo Normas de programacin y estndares de nomenclatura Esquema definiti vo de la Base de Datos Cdigo fuente (con documentacin incorporada) Diagrama de Gantt del proyecto (defini tivo) Implementacin Creacin base de datos Codificacin e integracin de mdulos Testeo e instalacin Cdigo fuente definitivo (con documentacin incorporada) Documentacin sobre las pruebas realizadas Manual de Usuario Pautas para migracin de datos Manual de administracin y soporte tcnico Descripcin general para el funcionario no informtico Pruebas unitarias Prueba s de Integracin Carga de tablas de configuracin Migracin de Datos e instalacin Capacitacin si corresponde NOTA 1: Cdigo fuente incluye no slo las lneas codificadas en el lenguaje en que se decida desarrollar la aplicacin, sino los posibles stored procedures, el cdigo que pudiera estar embebido en formularios y cualquier pieza de software, local a la aplicacin y necesaria para que sta funcione. Tambin se incluye el cdigo HTML, XML, ASP, JSP, PHP, o cualquier otro usado en el desarrollo web. NOTA 2: Todos los diagramas especificados se refieren a la notacin de Yourdon, qu e se puede consultar en Anlisis estructurado moderno, de Edward Yourdon, Editorial Prentice Hall, 1993, ISBN 9688803030. Tambin se puede ver en la web, en el sitio de Yourdon, http://www.yourdon.com/strucanalysis/index.html (en ingls). b.- Breve descripcin de los documentos y diagramas 1. Diagnstico de la situacin y necesidad del sistema (Objetivos): Tiene que ser una descripcin somera de la situacin actual y las mejoras que traer l a implementacin del sistema. Como a veces en esta etapa se decide que no es neces ario hacer un desarrollo, o que se va a reutilizar uno existente, hay que explic ar por qu es necesario el desarrollo en cuestin. Si se trata de un mantenimiento d e un sistema existente, se deber explicar por qu es necesario y cules son las contr as de no hacerlo. Por ejemplo: Actualmente, la Secretara de Educacin no cuenta con una forma confiable de obtener estadsticas de alumnos de las escuelas de la ciudad. Una de las causas que hace q ue las estadsticas no sean confiables proviene del hecho de que numerosos alumnos se inscriben en ms de una escuela y no hay una base de datos nica que permita det ectar esta situacin. Por otro lado, los mtodos manuales utilizados impiden saber s i los criterios utilizados en todos los relevamientos son los mismos. Adems, la o btencin de datos actual es muy costosa en trminos econmicos y de tiempo. Por todas estas consideraciones, se ha decidido desarrollar la Base nica de Datos de Alumno s, que va a permitir uniformizar criterios y mantener la informacin centralizada. 2. Modelo ambiental: Este modelo define la frontera del sistema describiendo sus lmites y alcances. Definido qu queda en el interior y qu en el exterior del sistema, se deben definir los estmulos (mensajes, acciones de usuarios u otros sistemas, etc.) del exterio r a los que el sistema responde, as como las interfaces de ese intercambio. Utili za: 2.1 Declaracin de propsitos: Es una descripcin textual, breve y concisa del propsito del sistema, de no ms de un prrafo. Debe incluirse la enumeracin de los beneficios tangibles y cuantificables que se lograrn con el nuevo sistema. Si se trata de u

n sistema existente que se va a modificar, debe quedar claro en este documento. El empleo de trminos que hacen a la especificidad del negocio puede requerir que se le asocien notas explicativas. Por ejemplo: La Base nica de Datos de Alumnos deber permitir el almacenamiento de los todos los datos de alumnos que hoy manejan las escuelas de la ciudad, tanto de gestin guber namental como privada, incluyendo las calificaciones e informacin de presentismo. Este sistema permitir obtener estadsticas que hacen a la gestin de la Secretara de Educacin, que hoy deben realizarse con mtodos manuales, a la vez costosos e imprec isos, adems de centralizar en una nica base de datos la informacin de alumnos de to da la ciudad. 2.2 Diagrama de contexto: Muestra en forma detallada las distintas interfaces co n el ambiente; grafica las personas, organizaciones, mquinas o sistemas con los q ue el nuevo sistema se comunica, as como los datos que recibe y produce. Debe rec ordarse que es una herramienta que debe permitir una comprensin con un golpe de v ista. A continuacin se muestra un diagrama de contexto (algunos lo llaman DFD de nivel 0): En el mismo, el sistema se representa como un crculo en el centro, y las entidade s externas son rectngulos que lo rodean, con las interacciones entre ambos repres entadas por flechas. Debe recordarse que debe ser entendido por el usuario, por lo que los trminos deben ser afines a su vocabulario. 2.3 Listado de eventos: Es especialmente importante en sistemas interactivos, no justificndose su aplicacin en desarrollos batch. Es un listado de estmulos que ocu rren en el ambiente a los cuales el sistema debe responder; debe incluir situaci ones de fallo o error de los agentes que estimulan al sistema. Puede reemplazars e con el catlogo de requerimientos. 2.4 Catlogo de requerimientos: Incluye los requerimientos, tanto funcionales como de cualquier otro tipo, que pudieran haberse detectado en las entrevistas con u suarios. Este documento suele ser un texto escrito en los trminos de los usuarios , con posibles aclaraciones que hagan al lenguaje de los desarrolladores. Dicho en forma coloquial, es como el pasaje en limpio y en forma organizada de las ent revistas con los usuarios. Puede reemplazarse por el listado de eventos recin des cripto. 3. Glosario: Es una descripcin de trminos que hacen al negocio, cuya comprensin es necesaria por parte de diseadores y programadores, y tiene la forma de un diccionario, poniend o los trminos y sus significados. Esto a veces no es necesario, ya sea porque los trminos son lo suficientemente corrientes o porque ya hubieran sido explicados e n otros documentos. 4. Diagrama de Gantt del proyecto: Debe hacerse el plan de trabajo del proyecto en forma de Diagrama de Gantt o sim ilar, que luego se ir actualizando al final de cada etapa. 5. Modelo de comportamiento: Define el comportamiento del sistema para manejarse con xito en el ambiente. Ese comportamiento se establece tomando como unidad cada una de los estmulos de la Li sta de Eventos ya comentada. Incluye el contenido de los datos que el sistema almacena y que se mueven a travs de l. Se traduce en: 5.1 Diagrama de Flujo de Datos (DFD): Es un diagrama que muestra los procesos y los flujos de datos entre los mismos. Se lo llama tambin diagrama de burbujas. Es fundamental cuando las funciones o pr ocesos son ms importantes que los datos. Debe caber en una pgina y no tener ms de 6 burbujas. Si no, hay que nivelarlo en ms diagramas. En esta etapa se trata de un diagrama preliminar, que se ir actualizando. A conti

nuacin hay un DFD de ejemplo: Las burbujas son los procesos, los rectngulos almacenamientos de datos y las flec has representan los flujos de informacin. ste es otro diagrama para interactuar co n usuarios, por lo que tambin deben usarse trminos de su dominio. 5.2 Especificacin de procesos: Es la especificacin de los procesos que se diagraman en el DFD. De todas maneras, slo tiene sentido realizarlo cuando los procesos tengan cierta complejidad. En una versin preliminar, la especificacin se puede hacer con tablas de decisin, de modo de no condicionar el diseo futuro. Los refinamientos sucesivos llevarn esta especificacin a lenguaje estructurado o pseudocdigo. Una tabla de decisin es una tabla de doble entrada como la que sigue, que muestra 5 casos distintos en funcin de valores de diferentes variables: IVA a aplicar 1 2 3 4 5 Emisor responsable inscripto X X X Emisor responsable no inscripto X Emisor exento X Receptor responsable inscripto X X X Receptor responsable no inscripto X X X Receptor consumidor final X X X Receptor exento X X X 21% en fact A X 31,5% en fact A X 21% en fact B 0% en fact C

X X X

El pseudocdigo equivalente sera algo as: Si emisor es responsable inscripto Si receptor es responsable inscripto Factura A IVA <- 21% Si receptor es responsable no inscripto Factura A IVA <- 31.5% Si receptor es consumidor final Factura B IVA <- 21% Si emisor es responsable no inscripto o exento Factura C IVA <- 0% Fin 5.3 Diagrama de Entidad Relacin (DER): Describe la distribucin de datos en un sistema. Es fundamental en sistemas centrados en datos. No es necesario si el sistema tiene poco o ningn acceso a bas es de datos, como algunos sitios web. Lo que sigue es un DER simple, a modo de ejemplo: En un DER, los rectngulos son tipos de objetos y los rombos relaciones. 5.4 Diccionario de datos: Define de manera formal los datos del sistema. Como con los diagramas, es importante seguir una notacin, como la de Yourdon, de modo que la documentacin sea comprensible por cualquier potencial lector. A continuacin se muestra un diccionario de datos elemental (la primera lnea muestr a una composicin e iteracin, la segunda slo una composicin, la tercera una especific acin de rango y la cuarta una seleccin entre dos posibilidades): Factura = cliente + direccin + { tem de factura } Cliente = nombre + DNI

DNI = rango 0 a 30.000.000 Direccin = [domicilio laboral | domicilio particular] 5.5 Diagrama de Transicin de Estados (DTE): Muestra los cambios de estado de los datos del sistema o de una parte del mismo. Es importante en sistemas reactivos (los que suelen estar inactivos mientras no reciban estmulos externos), con eventos, o para mostrar la vida de un objeto o cm o es afectado un objeto en un determinado escenario. Hay casos de sistemas o pro cesos en los cuales los DTE no aportan informacin. A continuacin se muestra un DTE simple de un contestador telefnico: En un DTE, las elipses son estados y las flechas transiciones entre los mismos. 6. Modelo del procesador: Es lo que permite pasar del modelo de anlisis a los distintos componentes de hard ware, con sus comunicaciones. Habr que incluir un diagrama de hardware, en el cua l se muestre el hardware sobre el que se implementar el sistema, y una justificac in de la eleccin del entorno tecnolgico, en la cual se explican las consideraciones que se hicieron para elegir dicho hardware. A continuacin se muestra un diagrama de hardware, en el cual se detallan qu proces os se realizan en cada procesador: 7. Modelo de tareas: Se puede resumir en un Diagrama de Fronteras, que indique en forma grfica los com ponentes del hardware y las tareas que se hacen en cada uno de ellos. Es importa nte para dar una idea general con un simple vistazo. En general, este es un diag rama importante en sistemas distribuidos, de arquitectura de varias capas o aqull os en los cuales haya que mostrar claramente la frontera con otros sistemas de i nformacin. De no ser as, se podra omitir, quedando el diagrama de contexto, el diag rama de hardware y los DFDs como sucedneos. Vanse el siguiente diagrama de fronteras de ejemplo: 8. Modelo de implantacin de programas Organizacin jerrquica de mdulos en una tarea. Se realiza con un Diagrama estructura do. A continuacin hay un diagrama estructurado de ejemplo: El diagrama estructurado no es apto para mostrar el comportamiento de sistemas b asados en eventos o reactivos. En estos casos conviene pasar directamente a diag ramas en UML u otra notacin OO. 9. Interfaces de usuario Se especifican con prototipos de las interfaces de usuario y reportes. stas puede n consistir en dibujos o bocetos que muestren cmo van a ser las interfaces, aun c uando luego estos sean modificados luego. A continuacin hay un prototipo de pantalla: 10.Esquema de la Base de Datos A continuacin se muestra uno: 11.Cdigo fuente con documentacin incorporada La documentacin incorporada se refiere a la documentacin embebida en el cdigo. Tamb in deben documentarse las configuraciones que se deban hacer en la mquina de desar rollo para que esos fuentes corran, como directorios especiales, variables de en torno, DLLs y dems. 12.Documentacin sobre las pruebas realizadas Debe incluir una descripcin de la metodologa de pruebas (centradas en verificacin o en validacin, de caja blanca o de caja negra, lotes de prueba, revisiones de cdig o, pruebas unitarias, de integracin, de sistema y de aceptacin). 13.Manuales Manual de procedimientos del usuario: puede reemplazarse por informacin sobre tut oriales y ayudas en lnea.

 Pautas para la migracin de datos, si la hubiese Manual de administracin y soporte tcnico: Es necesario que tenga una descripcin de los errores posibles del sistema, as como los procedimientos de recuperacin ante f allas y una gua de los problemas ms comunes que se pueden plantear. Descripcin general para el funcionario no informtico: puede ser un simple diagrama que indique la funcionalidad general del sistema y su despliegue en los distint os componentes de hardware, pero escrito en trminos lo ms corrientes que sea posib le. c.- Orientacin a objetos Debe tenerse especialmente en cuenta que las metodologas de orientacin a objetos n o se basan en un enfoque algortmico tradicional. Son metodologas dirigidas por cas os de uso, centradas en la arquitectura, iterativas e incrementales. Todas las etapas se entienden como consecutivas pero parcialmente superpuestas ( por ejemplo, se comienza el testeo antes del fin de toda la programacin) y con re alimentacin a etapas anteriores (por ejemplo, durante el diseo y la programacin se producen reajustes en la especificacin de funcionalidades). Por lo tanto, las pautas para documentar se han fijado en funcin de las fases, ut ilizando la divisin en fases del Proceso Unificado de Desarrollo de Software. FASE DOCUMENTACIN TAREAS Inicio Diagnstico de la situacin y necesidad del sistema Aspectos funcionales: Declaracin de propsitos Diagrama de Contexto Listas de casos de uso y actores, con diagramas de casos de uso Glosario Aspectos Tecnolgicos: Diagrama de despliegue tentativo Diagrama de Gantt del proyecto Deteccin de objetivos y lmites del sistema y su in teraccin con el ambiente Despliegue tentativo Planificacin de las iteraciones en que se ir construyendo el sistema Formalizacin de requisitos de escalabilidad, disponibilidad, seguridad, mantenimi ento y desempeo. Elaboracin Aspectos funcionales Diagrama de la base de datos Modelo de casos de uso para los ms importantes: lista y descripcin de casos de uso, con sus diagramas de actividades , de interaccin o de estado, si corresponde Diagrama de clases conceptual (parcial), esquemtico y con responsabilidades Aspectos no funcionales: Justificacin del entorno tecnolgico Prototipos de pantallas y reportes Diagrama de componentes mostrando la arquitectura Prioridades de los casos de uso descriptos Normas de programacin y estndares de nomenclatura Descripcin detallada de los de uso ms importantes. Priorizacin de los mismos. Determinacin de las clases de anlisis (parcial), a partir de los participantes de los casos de uso descriptos. Descripcin de su comportamiento. Determinacin de las interfaces de usuario para cada caso de uso descripto. Establecimiento de la arquitectura de la aplicacin. Determinacin de las clases de arquitectura ms importantes. Diseo de la base de datos. Determinacin de las normas de programacin y estndares de nomenclatura. Construccin Aspectos funcionales Modelo de casos de uso para los restantes: lista y descripcin de casos de uso, con sus diagramas de actividades, de interacc in o de estado, si corresponde Diagrama de clases completo Diagramas de comportamiento en los casos

necesarios: de estados y de interaccin Cdigo fuente (con documentacin Descripcin detallada de los casos de uso res s. Priorizacin de los mismos. Determinacin de las clases de anlisis restantes, a partir de los participantes de los casos de uso descriptos. Descripcin de su comportamiento. Determinacin del resto de las incorporada) Documentacin sobre pruebas realizadas Esquema definitivo de la base de datos Aspectos no funcionales: Prioridades de los casos de uso restantes Prototipos de las interfaces de usuario Diagrama de despliegue y componentes definitivo Transicin Manual de Usuario Pautas para migracin de datos Manual de administracin y soporte tcnico Descripcin general para el funcionario no informtico Actualizacin de toda la documentacin que sea necesario actualizar de sistema y de aceptacin Cargas de tablas de configuracin Migracin de Datos Afinacin

NOTA 1: Cdigo fuente incluye no slo las lneas codificadas en el lenguaje en que se decida desarrollar la aplicacin, sino los posibles stored procedures, el cdigo que pudiera estar embebido en formularios y cualquier pieza de software, local a la aplicacin y necesaria para que sta funcione. Tambin se incluye el cdigo HTML, XML, ASP, JSP, PHP, o cualquier otro usado en el desarrollo web. NOTA 2: Todos los diagramas especificados se refieren a la notacin UML, que se pu ede consultar en UML gota a gota, Martin Fowler, Editorial Addison Wesley, 1999, I SBN 9684443641. Tambin se recomiendan los libros sobre UML (El lenguaje unificado de modelado) escritos en conjunto por Booch, Rumbaugh y Jacobson. NOTA 3: El Proceso Unificado de Desarrollo de Software, que no necesariamente se recomienda, pero del cual se ha extrado la divisin en fases, puede consultarse en El Proceso Unificado de Desarrollo de Software, Ivar Jacobson, Grady Booch, James Rumbaugh, Editorial Addison Wesley, 2000, ISBN 8478290362. NOTA 4: Un buen curso de UML puede obtenerse en la Web, en castellano, en http:/ /www.dsic.upv.es/~uml/, tanto como presentacin PowerPoint como en formato PDF.

d.- Breve descripcin de los documentos y diagramas 1. Documentos similares a los de la metodologa estructurada Hay algunos elementos que no cambian por utilizar una metodologa OO. Por lo tanto , su descripcin puede encontrarse ms arriba, en la metodologa estructurada. stos son : Declaracin de propsitos. Diagrama de contexto (aunque puede hacerse con un diagrama de casos de uso, que veremos luego). Glosario. Especificacin de procesos con tablas de decisin (aunque tambin puede hacerse con d agramas de interaccin, los que veremos luego). Diagrama de Gantt o similar. Justificacin del entorno tecnolgico. Prototipos de pantallas y reportes. Normas de programacin y estndares de nomenclatura. Documentacin sobre las pruebas. Manual del usuario. Manual de administracin y soporte tcnico. Descripcin general para el funcionario no informtico.

2. Modelo de casos de uso: Es una lista de los casos de uso, con sus descripciones, incluyendo flujos alter nativos, requisitos funcionales y no funcionales, pre y postcondiciones, algn dia grama de actividades o de interaccin si fuera necesario para aclarar el flujo de control y los participantes (que se utilizarn para encontrar las clases de anlisis ). A continuacin se muestra una ficha tpica de un caso de uso: Nombre de Caso de Uso: AUTENTICACIN DE USUARIO Actualizaciones: Original Juan Prez 17/6/2003 Prioridad: Alta. Actores: Todos Descripcin: El usuario se conecta al sistema. Ingresa su nombre de usuario y contrasea. El si stema lo identifica e ingresa a su entorno. Flujos alternativos: El nombre de usuario no es vlido, se informa al usuario y se blanquean los campos . La contrasea no es vlida, se informa al usuario y se blanquean los campos. El usuario ya se encuentra usando el sistema, se informa al usuario y se blanque an los campos. Requisitos no funcionales: El sistema no puede tardar ms de 30 segundos en autenticar a un usuario. Precondiciones: Ninguna Postcondiciones: El usuario tiene una sesin abierta en el sistema. Se rechaza la solicitud. Diagrama de Actividades: No es necesario. Participantes: Usuario, Base de datos de usuarios autenticados. Clases de anlisis, responsabilidades, atributos: A rellenar luego. Prototipos de IU y reportes: No es necesario especificarlos en este caso. 3. Diagramas de casos de uso: Se usan para modelar: especificaciones de servicios contexto del sistema capturan requerimientos funcionales tiles en la interaccin con el usuario El que sigue es un diagrama de casos de uso: En el diagrama, los actores se representan como un esquema de persona, los casos de uso como elipses y las comunicaciones con lneas. Los actores pueden ser cualq uier entidad externa, incluyendo otros sistemas. 4. Diagramas de actividades: Se usan para modelar: flujos de procesos especificacin de comportamiento de alto nivel especificacin de algoritmos mostrar actividades concurrentes mostrar distintos agentes u objetos en un flujo generar casos de prueba Vase el diagrama de actividades presentado en la prxima pgina. Los objetos se representan por calles en sentido vertical (slo en el segundo de los diagramas), y cada estado por el que van pasando por rectngulos redondeados. Las flechas representan transiciones de estados. Hay nodos especiales para represen tar el comienzo y fin de la actividad, as como rombos que representan ramificacio nes, con el mismo significado que tenan en los antiguos diagramas de flujo. 5. Diagramas de interaccin: Se usan para modelar:

 cmo un escenario puede ser realizado a travs de un conjunto de mensajes entre obje tos ayudan a encontrar las operaciones (mtodos) de las clases distintos objetos trabajando en conjunto mensajes asncronos Para ello existen: Diagrama de colaboracin: enfatiza relaciones estructurales entre objetos etos Diagrama de secuencia: enfatiza el paso del tiempo o el ciclo de vida de los obj

Pg. 18 de 23 Ambos diagramas son semnticamente equivalentes, es decir, se puede reemplazar uno por el otro sin prdida de informacin. En el de colaboracin, el paso del tiempo est representado por nmeros asociados a los mensajes. Los mensajes, en ambos casos, s e representan con flechas, y los objetos con rectngulos, cuyo nombre se subraya. El diagrama de secuencia muestra el ordenamiento temporal mediante un eje vertic al, representando la lnea de vida de los objetos. En ambos es factible representa r iteraciones, concurrencia, mensajes sncronos y asncronos, as como la muerte de un objeto. 6. Diagramas de estado: Se usan para modelar: comportamiento complejo de los objetos estados concurrentes pruebas de caja blanca A continuacin hay un diagrama de estados que muestra el juego del ajedrez: / Juegan las blancas Ganan las blancas Ganan las negras Un diagrama de estados est compuesto por nodos y los arcos, ms un nodo especial pa ra indicar el comienzo y otro para indicar la finalizacin. En los nodos y los arc os se pone una descripcin del estado o evento que corresponda. Dentro del nodo que corresponde a cada estado se puede poner un texto adicional que especifique si el objeto se encuentra realizando alguna accin. Asimismo, en l a descripcin de las transiciones se puede poner una condicin que se deba satisface r, entre corchetes, o incluso parmetros que acompaen al evento. 7. Diagramas de clases: Se usan para modelar: la visin esttica de todo el sistema vocabulario de dominio del problema (sin operaciones) clases de anlisis con responsabilidades clases de diseo (con atributos y operaciones) estructura de la base de datos analizar acoplamiento entre clases y paquetes Lo que sigue es un diagrama de clases de ejemplo: Las clases son rectngulos, con divisiones para el nombre de la clase, los atribut os y los mtodos. Las asociaciones entre clases se representan con lneas, mientras las jerarquas de herencia con flechas dirigidas hacia la clase ancestro. Se puede n especificar roles, multiplicidad y grados de visibilidad. De todas maneras, es importante recordar que un diagrama de clases debe ser simp le y orientado a mostrar no ms de un tipo de relacin (herencia, asociacin o colabor acin). Por lo tanto, lo ideal va a ser separar los diagramas que muestren las jer arquas de las clases de los que muestren las asociaciones. Un diagrama de clases se puede hacer tambin en forma ms esquemtica en las primeras etapas del desarrollo. A continuacin se muestra un diagrama de clases conceptual, en el que no se indican atributos, mtodos ni relaciones de herencia: cPedido cCliente * 1

+Artculos de lnea cLineaDePedido 8. Diagramas de componentes y despliegue Se usan para modelar el despliegue de los distintos componentes de software sobr e el hardware. A continuacin se muestra un diagrama de despliegue con sus componentes: Cada cubo representa un nodo de hardware, y las lneas que los unen son conexiones . Dentro de cada nodo se han representado componentes software, que son rectngulo s con bisagras, que a menudo implementan una interfaz, representada con crculo pe queo. Las dependencias se representan con flechas discontinuas. e.- Sobre el mantenimiento de la aplicacin luego de su puesta en produccin Denominamos mantenimiento a las tareas de correccin de errores, evolucin por cambi o de requerimientos y preservacin para mantener operable un sistema, una vez que se encuentra en produccin. El mantenimiento debe incluir siempre la actualizacin de la documentacin asociada, amn de mantener la documentacin de versiones anteriores. Los procesos de modificacin pueden variar en su grado de complejidad, desde corre cciones de errores pequeos hasta cambios funcionales que impliquen la inclusin de nuevos procedimientos o funciones; a continuacin se presenta una lista de eventos que derivan en procesos de modificacin: Identificacin de errores (bugs) de programas. Necesidad de adicionar nuevas caractersticas o capacidades. Cambios de requerimientos funcionales. Aumento / disminucin en el mbito de aplicacin del sistema. Adaptaciones por cambios en el entorno operativo del mismo. Ms all del tipo de cambio (correctivo ante errores, adaptativo a cambios en el ent orno del funcionamiento de la aplicacin o perfectivo, ya sea en funcionalidad o a finacin), importa su grado de impacto. Y ello determinar el nivel de documentacin d e respaldo necesario. Para la resolucin de errores que no afecten la estructura modular de las aplicaci ones y para cambios estticos en las interfaces de usuario (tipo de letras, color) , como ejemplo, ser suficiente habilitar un Anexo a la Documentacin, el Registro d e Modificaciones. El Registro contendr, para cada modificacin, fecha del pedido, s olicitante, descripcin del cambio, fecha de concrecin y versin en la que es incluid o. Los cambios funcionales (agregado de nueva funcionalidad o modificacin en las car actersticas de la que el sistema ya provee) implican, para su concrecin, un volver a recorrer las etapas de desarrollo de la aplicacin; por consiguiente, y en form a paralela a su realizacin, esos cambios impactarn en la documentacin, desde la que refleja el anlisis de requerimientos hasta el Manual del Usuario. Por ello nueva s versiones de la documentacin acompaarn las nuevas versiones de la aplicacin. Es factible que estos cambios impliquen tambin cambios estructurales. Los cambios estructurales darn lugar a nuevas versiones de los modelos que reflejan las estr ucturas de datos, desde el Diccionario de Datos o Diagrama de Clases al Esquema definitivo de la Base de Datos. Si impactasen en el diseo de pantallas o la funci onalidad, el cambio se reflejar tambin en el Manual del Usuario. No se reflejar en la documentacin para el usuario todo aquello que no impacte en su forma de uso de l sistema, como, por ejemplo, optimizaciones. Los cambios en el entorno tecnolgico se reflejarn en la documentacin que alude al e ntorno tecnolgico. En cualquier caso se deber generar una nueva versin del cdigo fuente, con el respec tivo nmero de versin, que tambin forma parte de la documentacin. f.- Forma de entregar la documentacin Cuando deba entregarse, la documentacin se presentar en CD.

Los formatos de los archivos a entregar debern ser alguno de los siguientes: Texto puro: extensin .TXT, o la extensin que corresponda en el caso de ser cdigo f ente. Documentacin textual: preferentemente en PDF, de otra manera Microsoft Word (.DOC ) u OpenOffice (.ODT). Planillas de clculo y tablas: Microsoft Excel (.XLS) u OpenOffice (.ODS) Presentaciones: Microsoft Powerpoint (.PPT) u OpenOffice (.ODP) Diagramas: Microsoft Visio Drawing (.VSD), Dia (.DIA), OpenOffice (.ODG) u otro formato vectorial, pero preferentemente envindolo tambin en PDF. Si se envan archivos compactados, se utilizar un formato estndar, como zip o tar.g . El cdigo fuente debe entregarse tambin en CD, con la estructura de directorios o c arpetas con que est implementado, de modo de garantizar que se pueda chequear ant es de dar la aprobacin. Tambin deben documentarse las configuraciones que se deban hacer en la mquina de desarrollo para que esos fuentes corran, como directorios especiales, variables de entorno, DLLs y dems.