FUNDAMENTOS DE DESARROLLO DE SISTEMAS

CATEDRTICO: RICARDO HERNNDEZ PPULOS

RESUMEN: CODIFICACIN, DOCUMENTACIN Y HERRAMIENTAS CASE

El PROCESO DE LA TRADUCCION Etapa donde un compilador acepta el cdigo fuente como entrada y como salida produce un cdigo objeto. Luego este es traducido a cdigo maquina Desde el diseo detallado del software hasta la codificacin del mismo se deben tomar en cuenta factores que pueden afectar el producto final de forma distinta: Interpretar equivocadamente las especificaciones del diseo detallado puede conducir a un cdigo fuente errneo. Complejidad o restricciones de un lenguaje pueden conducir a un cdigo fuente muy liado que resulte difcil de probar y mantener. Las caractersticas de un lenguaje deben estar ligadas a un soporte que se requiere para un software adems que tiene una influencia directa sobre la calidad y eficiencia de la traduccin. CODIGO FUENTE Es un conjunto de lneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa. El cdigo fuente de un programa est escrito por un programador en algn lenguaje de programacin, pero en este primer estado no es directamente ejecutable por la computadora. Ejemplo: cdigo de un programa escrito en java (Archivo.java) CODIGO OBJETO Es el cdigo de la compilacin del cdigo fuente. Consiste en lenguaje maquina o bytecode y se distribuye en varios archivos que corresponden a cada cdigo fuente compilado. Ejemplo: Archivo.class generado al compilar el cdigo fuente (Archivo.java) CARACTERISTICAS DE LOS LENGUAJES DE PROGRAMACION El proceso de codificacin (comunicacin mediante un lenguaje de programacin) es una actividad humana. Es por ello que las caractersticas psicolgicas del lenguaje afectan directamente a la calidad de la comunicacin, algunas son: Uniformidad. Indica en que un lenguaje usa una notacin consistente, aplica restricciones aparentemente arbitrarias o incluye excepciones a reglas sintcticas o semnticas. Ejemplo usar siempre la sentencia c.println(cadena); Si al usar despus system.out.println(cadena); entonces se pierde la uniformidad, al no llevar una sintaxis consistente.

 Ambigedad. Es cuando un compilador siempre interpreta una sentencia de una nica forma pero el lector humano puede interpretar la sentencia de formas diferentes. Ejemplo: Resolver la siguiente operacin matemtica: ( 10 * 4 + 10 ) / [ 2 +3 +( 4 / 2 )2 ] Sol. R= 50 R= 50 R= 50 R= 50 R= 50 R= 5 / / / / / [3+ [3+ [3+ [3+ 10 3+( 4 / 2 )2 ] 3 +( 2 )2 ] 3 + 22 ] 3+4] Jerarqua de Operaciones
1. [ , ], (, ) 2. , *, / 3. +, -

( 10 * 4 + 10 ) / [ 2 +3 +( 4 / 2 )2 ]

Caso Ambigedad
R= R= R= R= R= R= 140 140 140 140 140 14 / / / / / [ 3 + 3+( 4 / 2 )2 ] [ 6+ ( 4 / 2 )2 ] [ 6+ 2 2 ] [ 6+ 4] 10

Compacto. Es un indicativo de la cantidad de informacin orientada al cdigo que se debe retener en la memoria humana Tambin se cuenta con caractersticas humanas, (del programador):

Sinestatica. Nos permite recordar y conocer las cosas como un todo. Ejemplo:
cuando vemos a un conocido, con el solo hecho de verlo podramos recordar que tipo de persona era: alegre, cumplida, educada, etc... Secuencial. Proporciona una forma de reconocer el siguiente elemento de una secuencia. Ejemplo: cuando estamos cantando y viendo la letra en un karaoke, y en algn momento se va la imagen, nosotros podramos saber que sige gracias a que llevamos el ritmo (secuencia ) de la msica.

Es por esto que cada una de estas caractersticas de la memoria afecta a las de los lenguajes de programacin que son:

 La localizacin es una caracterstica Sinesttica de un lenguaje de programacin. Se potencia cuando las sentencias se pueden combinar en bloques, cuando las construcciones estructuradas se pueden implementar directamente cuando el diseo y el cdigo resultante son modulares y cohesivos. La linealidad es una caracterstica psicolgica que se asocia con el concepto de mantenimiento de un mbito funcional. Esto quiere decir que la percepcin humana se facilita cuando se encuentra una secuencia lineal de operadores lgicos. ELECCION DEL LENGUAJE Debe tener en cuenta tanto las caractersticas de ingeniera como psicolgicas. Es por esto que se aplican los siguientes criterios para la evaluacin de los lenguajes. rea de aplicacin general Complejidad algortmica y computacional. Entorno en el que se ejecutara el software. Consideraciones de rendimiento. Complejidad de las estructuras de los datos. Conocimiento de la plantilla de desarrollo de software. Disponibilidad de un buen compilador. Aparte de los criterios de evaluacin, tambin se tendr que tener en cuenta algunos elementos fundamentales en los lenguajes de programacin, los cuales son: Tipos de datos. Estos pueden ser enumerados, lgicos, cadenas, numricos y otros datos compuestos como estructuras, clases, uniones, etc. Subprogramas. Estas estn compuestas de las secciones de Especificacin, de Implementaron y de Activacin Estructuras de control. Entre las cuales estn las bsicas: Secuenciacin, Repeticin, Condicin, Recursividad, Concurrencia

 Soporte para la OO. Un lenguaje de programacin OO debe soportar: la definicin de Clases, Herencia, Encapsulacin, Paso de mensajes, Herencia mltiple y Polimorfismo TECNICAS DE CODIFICACION Evitar variables globales en subprogramas. Modularizar un programa en partes coherentes (uso amplio de subprogramas). Usar nombres significativos para identificadores. Definir constantes con nombres al principio del programa. Evitar el uso del goto y no escribir nunca cdigo spaghetti. Escribir subrutinas cortas que hagan una sola cosa y bien. Usar declaraciones de tipos. Presentacin. Manejo de errores. Uso adecuado de parmetros variable. Legibilidad. Documentacin.

http://www.ahristov.com/taller/blog/Estilo-de-Programacion-9-01.pdf EFICACIA Y EFICIENCIA

Eficacia. Es la capacidad de lograr algo esperado o deseado, no importando la cantidad

de recursos usados Eficiencia. Es la capacidad de lograr algo esperado o deseado, usando la una cantidad mnima de recursos posible Ejemplo: matar una mosca de un caonazo es eficaz (o efectivo: conseguimos el objetivo) pero poco eficiente (se gastan recursos desmesurados para la meta buscada). Pero acabar con su vida con un matamoscas, aparte de ser eficaz es eficiente. La eficiencia de un programa es una medida de cantidad de recursos consumidos por el programa. Tradicionalmente los recursos considerados han sido: Tiempo de ejecucin. Almacenamiento (ocupacin de programa en memoria). Mientras menos tiempo se utilice y menor almacenamiento, el programa ser ms eficiente. Estos dos factores suelen ser muy costosos. Aunque la eficiencia es un fin

recomendable, se deben establecer tres mximas antes de pasar a una discusin ms profunda. En general, no hay que sacrificar la claridad, legibilidad o la correccin en aras de unas mejoras en eficiencia que no sean esenciales. EFICIENCIA EN CODIGO Directrices que se deben seguir en el proceso de traduccin del diseo detallado al cdigo. Simplificar las expresiones aritmticas y lgicas antes de convertirlas en cdigo. I. Evaluar cuidadosamente los bucles anidados para determinar si se pueden sacar fuera de ellos algunas sentencias o expresiones II. III. IV. Cuando sea posible, evitar el uso de arreglos multidimensionales, el uso de punteros y listas complejas. Usar rpidas operaciones aritmticas. No mezclas tipos de datos.

EFICIENCIA EN MEMORIA Se debe tener en cuenta para la eficiencia en memoria las posibilidades de paginacin del sistema operativo. En general, la localizacin o el mantenimiento del cdigo en un campo funcional mediante construcciones estructuradas es un mtodo excelente para reducir la paginacin y, por tanto, incrementar la eficiencia. EFICIENCIA EN ENTRADA/SALIDA I. II. III. IV. Directrices para mejorar la eficiencia de las E/S. Debe minimizarse el nmero de peticiones de E/S. Toda E/S debe ser tratada con buffer para reducir el embotellamiento en la comunicacin. Para las memorias secundarias, se debe seleccionar y usar el mtodo de acceso ms simple dentro de los aceptados.

DOCUMENTACIN. Una parte fundamental del software es la documentacin que lo acompaa. Esta es una pieza tan importante de un programa que en ocasiones ste ser intil sin ella. La documentacin describe la manera de utilizar el programa, la razn por la cual se describieron las tcnicas utilizadas en su construccin y debe esclarecer cualquier aspecto oscuro del programa. Cualquier persona que utiliza el software de aplicacin necesita informacin precisa acerca de cmo el software ayuda al usuario llevar a cabo una tarea. La documentacin puede ser el primer tema tangible que el usuario ve y por lo tanto, influye en las primeras impresiones del usuario del producto de software. Si la informacin se presenta en una forma cmoda y es fcil de encontrar y entender, el usuario puede rpidamente dominar la utilizacin del producto. Por lo tanto, el buen diseo no slo ayuda a la documentacin del usuario y ayuda a reducir el costo de la capacitacin y apoyo, sino que tambin mejora la reputacin del producto, su fabricante y sus proveedores. La documentacin de usuario es un componente esencial en la utilizacin productos de software. La documentacin es a menudo considerada como algo hecho despus de que el software se ha aplicado. Sin embargo, para el software de alta calidad, la documentacin, su desarrollo debe ser considerada como parte integrante del software procesos del ciclo de vida. Si se hace correctamente, la documentacin o la gestin de la informacin es una tarea lo suficientemente grande como para requerir proceso de planificacin para si misma. La documentacin del sistema abarca todo el ciclo de vida del desarrollo del software; incluye: Especificaciones originales del sistema y aquellas con las que se verifico el sistema. Los diagramas de flujo de datos (DFD). Diagramas Entidad Relacin (DER) Diccionario de datos. Diagramas o cartas de estructuras (representan la estructura modular del sistema). Quines necesitan conocer la documentacin del programa? : Programadores. Manual de mantenimiento del programa. Operadores. Manual del operador. Usuario. Manual de usuario.

Manual de mantenimiento del programa. Contiene detalles de bajo nivel acerca del sistema, que no son necesarios para comprenderlo en un nivel superior, pero que se exigen para usarlo en la prctica o para verificar afirmaciones realizadas en cualquier parte del documento. Objetivo:- Proporcionar la informacin, normas y documentacin necesaria para modificaciones o correcciones en el futuro. Contiene: Formatos. Una descripcin de todos los formatos adoptados o garantizados por el programa: para un fichero E/O (fichero para entrada y salida de datos), argumentos de la lnea de comando, dilogos de usuario, formatos de los mensajes para las comunicaciones en red, etc. stos deberan desglosarse en formatos visibles para el usuario, que son parte conceptual de los requisitos visibles para el usuario y del manual de usuario, y en formatos interiores que constituyen una parte conceptual de otros componentes de su documentacin. Especificaciones del mdulo. Debera extraer las especificaciones de su cdigo y presentarlas por separado aqu. Si escribe sus comentarios en el estilo aceptado por Javadoc con el doclet de 6.170, podr generar documentos de la especificacin de forma automtica a partir del cdigo. La especificacin de un tipo abstracto debera incluir su visin general, campos de la especificacin e invariantes abstractas (restricciones de especificacin). La funcin de abstraccin y el invariante de representacin no forman parte de la especificacin de un tipo. Casos de prueba. Idealmente, su banco de pruebas lee tests de un archivo de casos de prueba en un formato que resulta cmodo de leer y escribir. No es necesario que incluya casos de prueba muy extensos; por ejemplo, simplemente podra observar el tamao de una entrada aleatoria generada para realizar pruebas de estrs y proveer al programa que gener los tests. Indique cul es la utilidad de cada grupo de tests (ej.

"pruebas de estrs, entradas enormes", "pruebas de particin, todas las combinaciones de +/-/0 para argumentos enteros"). Manual de operador Contiene la informacin que permite al personal de operacin utilizar en forma eficiente la operacin de los sistemas de procesamiento electrnico. Contenido Diagrama general del sistema Diagrama general del flujo del proceso electrnico. Explicacin Genrica De Las Fases Del Sistema Diagrama De Pantallas Del Sistema Puntos a documentar en una pantalla: Instructivo De Operacin Por Programa Diagrama electrnico del programa.

Manual de usuario Expone los procesos que el usuario puede realizar con el sistema implantado. Para lograr esto, es necesario que se detallen todas y cada una de las caractersticas que tienen los programas y la forma de acceder e introducir informacin Permite a los usuarios conocer el detalle de qu actividades ellos debern desarrollar para la consecucin de los objetivos del sistema. Rene la informacin, normas y documentacin necesaria para que el usuario conozca y utilice adecuadamente la aplicacin desarrollada. Objetivos de la documentacin de usuario: Que el usuario conozca cmo preparar los datos de entrada. Que el usuario aprenda a obtener los resultados y los datos de salida. Servir como manual de aprendizaje. Servir como manual de referencia. Definir las funciones que debe realizar el usuario. Informar al usuario de la respuesta a cada mensaje de error.

Pasos a seguir para definir como desarrollar el manual de usuario. Identificar los usuarios del sistema: personal que se relacionar con el sistema.

Definir los diferentes tipo de usuarios: se de usuarios que usaran el sistema. indirectos. Definir los mdulos en que cada usuario mdulos o procesos que se ejecutarn narrativa breve y clara. Importancia Del Manual De Usuario

presentan los diferentes tipos Ejemplo: usuarios directos, participar: Se describen los por cada usuario en forma

El Manual de Usuario facilita el conocimiento de: Los documentos a los que se puede dar entrada por computadora. Los formatos de los documentos. Las operaciones que utiliza de entrada y salida de los datos. El orden del tratamiento de la computadora con los datos introducidos. El momento en que se debe solicitar una operacin deseada. Los resultados de las operaciones realizadas a partir de los datos introducidos.

En la documentacin existen los siguientes tipos: 1. 2. 3. 4. Documentacin del software. Calidad de la documentacin. Mantenimiento de la documentacin. Transportabilidad de la documentacin.

2.5.1.- DOCUMENTACIN DEL SOFTWARE. La documentacin del software se clasifica en dos: documentacin del usuario o documentacin del sistema. La informacin proporcionada, junto con el sistema deben satisfacer los siguientes requisitos : 1. 2. 3. 4. Como usar el sistema. Como instalar y operar el sistema. Los requisitos y diseo de todo el sistema. La aplicacin del sistema y los procedimientos de prueba para poderles dar mantenimiento.

2.5.1.1.- Documentacin del usuario. Se compone de aquellos documentos relacionados con las funciones del sistema, sin referirse a la forma de aplicarlas. Son cinco documentos que se pueden considerar dentro de la documentacin de usuario:

1. Una documentacin formal de los que puede hacer el sistema. 2. Un documento que explique como instalar el sistema y adecuarlo para configuraciones particulares del hardware. 3. Un manual de introduccin que ex 4. plique en trminos sencillo como poder inicializar el sistema. 5. Un manual de referencia que describa con detalle, las ventajas del sistema disponible para el usuario y como poderlas usar. 6. Una gua de operador que explique como debe reaccionar ante situaciones adversas, surgidas mientras el sistema se encuentra en uso. 2.5.1.2.- Documentacin del sistema. Describe todos los aspectos del diseo, implantacin y pruebas del sistema y deben incluir: 1. Definicin de requisitos. 2. Por cada programa del sistema, una descripcin de cmo se descompone ese programa y una declaracin sobre la especificacin de cada componente. 3. Por cada unidad de programa una descripcin de cada operacin. 4. Un plan de pruebas que describa como se prueba cada unidad de programa. 2.5.1.3.- . Unidad de programa. Una unidad de programa es una unidad de cdigo fuente que es desarrollada y/o mantenida por una persona; y esa persona es la responsable de la unidad. Una unidad de programa es un subprograma o grupo de subprogramas que cumplen una funcin bien definida. 2.5.1.4.- Diccionario de datos. Proporciona detalles de todas y cada una de las entidades relevantes para el sistema que se describe. Son una parte importante de la documentacin, sobre todo de aquellas que implican sistemas de control de base de datos. 2.5.2.- CALIDAD DE LA DOCUMENTACIN. Es muy importante ya que sin informacin sobre la utilizacin del sistema o sobre su comprensin, la utilidad del sistema queda mermada. Las sugerencia para que la produccin de documentacin de software sea de buena calidad son las siguientes : Seguir un procedimiento estndar para producir, revisar y acomodar la documentacin es de gran ayuda para la actividad de la documentacin.

 Que la documentacin no sea pobre ya que posiblemente pueda confundir mas que ayudar al usuario. Los estndares tiene que describir con exactitud lo que debe incluir la documentacin Descripcin de un formato para la cubierta frontal de las convenciones para la numeracin y anotacin de pagina. 2.5.2.1.- Estilos de redaccin. Los principios generales, dispuestos con un estilo que se pueda usar en los manuales de instruccin del software son : Concreto. Ser preciso y definir los trminos utilizados. Utilizar prrafos cortos. Utilizar ttulos y subttulos. No emplear frases largas que presenten hechos distintos. No hacer referencia a una informacin solamente con el nmero de referencia.

2.5.3.- EL MANTENIMIENTO DE LA DOCUMENTACIN. Otra caracterstica de la documentacin del software es que la misma debe acompaar el desarrollo o evolucin del software que documenta. Es decir, de la misma forma que el software avanza y se desarrolla, la documentacin debe avanzar y desarrollarse conjuntamente, de manera que la ltima versin de la documentacin refleje las caractersticas y el estado de la ltima versin del software. A medida que se modifica un sistema de programacin, la documentacin asociada se debe de modificar para que refleje los cambios en el sistema. Si el cambio es transparente, el usuario solo deber modificar aquellos documentos que describan la aplicacin del sistema. Cuando la modificacin es ms que la simple correccin de un error de codificacin, habr que hacer una revisin del diseo y de la documentacin. 2.5.4.- LA TRANSPORTABILIDAD DE LA DOCUMENTACIN. Cuando un sistema de computacin se pasa de una maquina a otra, la documentacin asociada al el se debe de modificar para ajusta el nuevo sistema. Las partes del sistema que causan problemas en la transportabilidad del sistema de programas incluye,la organizacin de archivos, las conversiones para nombrar archivos, el control de procesos, la entrada y salida.

Ejemplo:La documentacin del sistema abarca todo el ciclo de vida del desarrollo del software; a continuacin un ejemplo de lo que podra incluir la documentacin de un sistema de software: 1. Requisitos La seccin de requisitos describe el problema que se est solventando junto con la solucin. Esta seccin de la documentacin resulta interesante tanto para los usuarios como para los implementadores; no debera contener detalles sobre la estrategia de implementacin en concreto. Las otras partes de la documentacin del sistema no sern de inters para los usuarios, nicamente para los implementadores, los encargados del mantenimiento y dems personal. 1. Visin general (hasta 1 pgina) Una explicacin del objetivo del sistema y de la funcionalidad del mismo. 2. Especificacin revisada. Si le facilitaron especificaciones detalladas del comportamiento del sistema, es probable que encuentre que ciertas partes del mismo se encuentran infraespecificadas o son ambiguas. En esta seccin debera aclarar tanto cualquier suposicin que haya hecho sobre el significado de los requisitos, como cualquier extensin o modificacin de los mismos. 3. Manual de usuario (1 - 5 pginas). Una descripcin detallada sobre cmo el usuario puede utilizar el sistema, qu operaciones puede llevar a cabo, cules son los argumentos de la lnea de comando, etc. Las especificaciones detalladas de los formatos deberan relegarse al Apndice. Cualquier suposicin relativa al entorno debera explicitarse aqu: por ejemplo, observe si el programa slo se ejecuta en ciertas plataformas, si supone que la jerarqua de un cierto directorio est presente, si existen otras aplicaciones, etc. Junto con la visin general, este manual debera proporcionar toda la informacin que un usuario del sistema necesita. 4. Funcionamiento (1/2 pgina). Qu recursos necesita el sistema para una operacin normal y qu espacio y tiempo se espera que consuma? 5. Anlisis del problema (2 - 10 pginas). Una descripcin clara del problema subyacente. Esto incluye el modelo conceptual que hay detrs del diseo (y posiblemente la interfaz de usuario), si no se ha tratado ya. El anlisis del problema generalmente incluye uno o ms modelos de objeto del problema, definiciones de sus conjuntos y relaciones y una discusin de asuntos complicados.Los objetos en los modelos de objeto del problema proceden del dominio del problema, no del cdigo. Los modelos de objeto deberan incluir tanto diagramas como cualquier restriccin textual fundamental, y deberan

estar claramente expuestos para una correcta legibilidad. Esta parte tambin debera describir alternativas que hayan sido consideradas pero que se han rechazado, con razones, asuntos no resueltos o aspectos que no hayan sido totalmente aclarados y que vayan a solventarse ms tarde. Puede que los casos de uso le resulten tiles cuando escriba la especificacin revisada y/o el manual de usuario. Un caso de uso es un objetivo especfico y una lista de acciones que un usuario lleva a cabo para conseguir dicho objetivo. Un cliente puede, entre otras cosas, examinar la lista de acciones para decidir si la interfaz de usuario es aceptable. Si la coleccin de casos de uso abarca todos los objetivos deseados por el usuario, el cliente puede tener la seguridad de que el sistema cumplir con su objetivo. 2. Diseo La seccin de diseo de su documentacin proporciona un cuadro de alto nivel de su estrategia de implementacin. 1. Visin general (1/2 - 3 pginas). Una visin general del diseo: organizacin de alto nivel, cuestiones de diseo especialmente interesantes, uso de libreras y otros mdulos de terceros e indicadores de aspectos no resueltos o proclives al cambio. Tambin incluye problemas con el diseo: decisiones que pueden resultar errneas y los anlisis de las consecuencias entre la flexibilidad y el funcionamiento que pueden ser juzgadas negativamente. 2. Estructura en tiempo de ejecucin (1 - 5 pginas). Una descripcin de la estructura del estado del programa en ejecucin, expresada como un modelo de objeto de cdigo. ste debera ocultar las representaciones de los tipos de datos abstractos; su propsito consiste en mostrar las relaciones entre objetos. Los modelos de objeto deberan incluir tanto diagramas como cualquier restriccin textual fundamental, y deberan estar claramente expuestos para una correcta legibilidad. Las representaciones de los tipos de datos deberan explicarse (con sus funciones de abstraccin e invariantes de representacin) si esas representaciones son poco comunes, especialmente complejas o decisivas para el diseo global. Observe que las funciones de abstraccin y los invariantes de representacin deberan aparecer an as en su sitio normal en el propio cdigo. 3. Estructura del mdulo (1 - 5 pginas). Una descripcin de la estructura sintctica del texto del programa, expresada como un diagrama de dependencia entre mdulos. Debera incluir la estructura del paquete y mostrar tanto las interfaces de Java del programa, calendario, material de clase, trabajos, exmenes, lecturas obligatorias, otras fuentes, prcticas, presentaciones, herramientas y proyectos, como las clases. No es necesario exhibir las dependencias de las clases en la API de Java del programa, calendario, material de clase, trabajos, exmenes, lecturas obligatorias, otras fuentes, prcticas, presentaciones, herramientas y proyectos. Su MDD (diagrama de

dependencia entre mdulos) debera estar claramente expuesto para una correcta legibilidad. Explique por qu se eligi esa estructura sintctica en particular (ej.: introduccin de interfaces para el desacoplamiento: qu desacoplan y por qu), y cmo se utilizaron los patrones de diseo concretos. Para explicar la descomposicin y otras decisiones de diseo, exponga que aportan simplicidad, extensibilidad (facilidad para aadir caractersticas nuevas), particionalidad (los distintos miembros del equipo pueden trabajar en las diferentes partes del diseo sin necesidad de mantener una comunicacin constante) u objetivos similares relativos a la ingeniera de software. 3. Pruebas La seccin de pruebas de su documentacin indica el enfoque que usted ha elegido para verificar y validar su sistema. (En un sistema real, esto podra incluir tanto las pruebas de usuario para determinar la idoneidad del sistema como solucin al problema descrito en la seccin de requisitos, como la ejecucin de suites de prueba para verificar la correccin algortmica del cdigo). Del mismo modo que no debera comunicar el diseo de su sistema presentando el cdigo o incluso enumerando las clases, no debera nicamente enumerar las pruebas realizadas. En vez de hacer esto, explique cmo se seleccionaron las pruebas, por qu stas bastaron, por qu un lector debera creer que no se ha omitido ninguna prueba importante y por qu debera creer que el sistema realmente funcionar como se desee cuando se ponga en prctica. 1. Estrategia (1 - 2 pginas). Una explicacin de la estrategia general de las pruebas: blackbox y/o glassbox, top down (de arriba hacia abajo) y/o bottom up (de abajo hacia arriba), tipos detest beds (bancos de prueba) y manejadores de tests que se han utilizado, fuentes de datos del test, suites de prueba, mtrica de cobertura, comprobacin en tiempo de compilacin frente a sentencias en tiempo de ejecucin, razonamientos sobre su cdigo, etc. Es posible que quiera usar tcnicas distintas (o combinaciones de tcnicas) en las diferentes partes del programa. Justifique su decisin en cada caso. Explique qu tipo de errores espera encontrar (y cules no!) con su estrategia. Comente qu aspectos del diseo dificultaron o facilitaron la validacin. 2. Resultados del test (1/2 - 2 pginas). Resumen de qu pruebas se han realizado y cules no, si es que queda alguna: qu mdulos se han probado, y si se han probado a fondo. Indique el grado de confianza del cdigo: Qu tipo de defectos se han eliminado? Cules son los que podran quedar? 4. Reflexin

La seccin de reflexin (vulgarmente conocida como "post mortem") del documento es donde puede hacer generalizaciones partiendo de xitos o fallos concretos, hasta llegar formular reglas que usted u otros puedan utilizar en el futuro desarrollo de software. Qu fue lo que ms le sorprendi? Qu hubiera deseado saber cuando comenz? Cmo podra haber evitado los problemas que encontr durante el desarrollo? 1. Evaluacin (1/2 - 1 pginas). Lo que usted considere xitos o fracasos del desarrollo: problemas de diseo no resueltos, problemas de funcionamiento, etc. Identifique cules son los rasgos importantes de su diseo. Seale tcnicas de diseo o implementacin de las que se sienta especialmente orgulloso. Explique cules fueron los errores que cometi en su diseo y los problemas que causaron. 2. Lecciones (0,2 - 1 pgina). Qu lecciones ha aprendido de la experiencia: cmo podra haberlo hecho de otra forma una segunda vez, y cmo los errores de diseo e implementacin pueden corregirse. Describa qu factores causaron problemas, como hitos errados, o errores y limitaciones conocidos. 3. Errores y limitaciones conocidos. De qu manera su implementacin no llega a alcanzar la especificacin? Sea exacto. Aunque perder puntos por errores y caractersticas no presentes, obtendr puntos parciales por identificar de manera exacta esos errores y el origen del problema. 5. Apndice El apndice contiene detalles de bajo nivel acerca del sistema, que no son necesarios para comprenderlo en un nivel superior, pero que se exigen para usarlo en la prctica o para verificar afirmaciones realizadas en cualquier parte del documento. 1. Formatos. Una descripcin de todos los formatos adoptados o garantizados por el programa: para un fichero E/O (fichero para entrada y salida de datos), argumentos de la lnea de comando, dilogos de usuario, formatos de los mensajes para las comunicaciones en red, etc. stos deberan desglosarse en formatos visibles para el usuario, que son parte conceptual de los requisitos visibles para el usuario y del manual de usuario, y en formatos interiores que constituyen una parte conceptual de otros componentes de su documentacin. 2. Especificaciones del mdulo. Debera extraer las especificaciones de su cdigo y presentarlas por separado aqu. Si escribe sus comentarios en el estilo aceptado por Javadoc con el doclet de 6.170, podr generar documentos de la especificacin de forma automtica a partir del cdigo. La especificacin de un tipo abstracto debera incluir su visin general, campos de la especificacin e invariantes abstractas (restricciones de especificacin). La funcin de abstraccin y el invariante de representacin no forman parte de la especificacin de un tipo.

3. Casos de prueba. Idealmente, su banco de pruebas lee tests de un archivo de casos de prueba en un formato que resulta cmodo de leer y escribir. No es necesario que incluya casos de prueba muy extensos; por ejemplo, simplemente podra observar el tamao de una entrada aleatoria generada para realizar pruebas de estrs y proveer al programa que gener los tests. Indique cul es la utilidad de cada grupo de tests (ej. "pruebas de estrs, entradas enormes", "pruebas de particin, todas las combinaciones de +/-/0 para argumentos enteros"). Documentacin del cdigo Comentarios a nivel de especificacin Tipos de datos abstractos. Cada tipo de datos abstractos (clase o interfaz) debera tener: 1. Una seccin de visin general que d una explicacin de una o dos lneas sobre qu objetos del tipo representan y si son mutables. 2. Una lista de campos de especificacin. Podra haber slo uno; por ejemplo, un conjunto podra tener el campo elemsrepresentando al conjunto de elementos. Cada campo debera tener un nombre, un tipo y una breve explicacin. Podra resultarle til definir campos derivados adicionales que facilitaran la escritura de las especificaciones de los mtodos; para cada uno de stos, debera indicar que es derivado y explicar cmo se ha obtenido a partir de los otros campos. Puede que haya invariantes de especificacin que restrinjan los posibles valores de los campos de la especificacin; si es as, debera precisarlos. Especificaciones del mtodo. Todos los mtodos pblicos de las clases deberan tener especificaciones; los mtodos privados complicados tambin deberan especificarse. Las especificaciones del mtodo deberan seguir la estructura requires (requiere), modifies (modifica), throws (lanza), effects (resulta), returns (devuelve). Comentarios a nivel de implementacin Notas para la implementacin. Los comentarios de una clase deberan incluir los siguientes elementos: 1. Una funcin de abstraccin que defina cada campo de la especificacin en funcin de los campos de representacin. Las funciones de abstraccin solamente son necesarias para las clases que son tipos de datos abstractos, y no para clases de tipo excepciones o como cualquier objeto de la GUI.

2. Un invariante de representacin. Las RIs (implementaciones de referencia) son necesarias para cualquier clase que posea una representacin (ej. no la mayora de las excepciones). Es muy recomendable que pruebe los invariantes en un mtodocheckRep() donde sea viable. Tenga cuidado al incluir en sus invariantes suposiciones acerca de lo que puede o no puede ser nulo. 3. Para las clases con representaciones complejas, aada una nota que explique la eleccin de la representacin (tambin conocida como representacin racional): qu anlisis de ventajas y desventajas se realizaron y qu alternativas se han considerado y cules se han rechazado (y por qu). Sentencias en tiempo de ejecucin. stas deberan utilizarse juiciosamente, ya que estas pueden mejorar la calidad de su cdigo. Comentarios. Debera comentar su cdigo cuidadosamente y con buen gusto. HERRAMIENTAS CASE HISTORIA Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje y por lo tanto un producto que analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en cuestin se denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem Statemente Analyzer). Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos informticos, la primera herramienta CASE fue Excelerator que sali a la luz en el ao 1984 y trabajaba bajo una plataforma PC. Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM haba conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas ms especficas para cada fase del ciclo de vida del software. CONCEPTO HERRAMIENTA CASE El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarcar esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asistida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cuales se hacen tiles a las personas comprender las capacidades de las

computadoras, por medio de programas, de procedimientos y su respectiva documentacin. Otra definicin de Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Ordenador) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, calculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras.

Clasificacin Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parmetros: 1. 2. 3. 4. Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad.

El propsito de esta tecnologa es acelerar el proceso de desarrollo de sistemas y mejorar la calidad de los sistemas resultantes. Existen diversas taxonomas de las herramientas case, que utilizan varios criterios para su clasificacin. Una clasificacin por funcin se divide en dos grandes reas: case superiores (u-case) y case inferiores (l-case). Los u-case (case superiores) abarcan las etapas de planeacin, anlisis y diseo. Los l-case (case inferiores) comprenden las etapas de codificacin, pruebas, y mantenimiento. De esta manera se cubren las grandes reas del desarrollo de sistemas. Las herramientas case individuales pueden estar enfocadas a un rea de la ingeniera de software mas especifica, como lo son: .La ingeniera de informacin. El modelado de procesos. Planificacin de proyectos. Administracin de proyectos. Anlisis de riesgos. Seguimientos de requisitos. Mtricas. Documentacin.

Control de calidad. Gestin de bases de datos. Desarrollo de interfaz. Generacin de prototipos entre otros

CARACTERSTICAS Case es una filosofa que se orienta a la mejor comprensin de los modelos de empresa, sus actividades y el desarrollo de los sistemas de informacin. Esta filosofa involucra adems el uso de programas que permiten: .Construir los modelos que describen la empresa. Describir el medio en que se realizan las actividades. Llevar a cabo la planificacin. Generar cdigos de programas, etc. Una herramienta CASE suele incluir:

Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin de bases de datos. Herramientas de diseo para dar apoyo al anlisis de datos. Herramientas que permitan desarrollar el modelo de datos corporativo, as como los esquemas conceptual y lgico. Herramientas para desarrollar los prototipos de las aplicaciones.

Componentes de una herramienta CASE De una forma esquemtica podemos decir que una herramienta CASE se compone de los siguientes elementos:

Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestin se realiza mediante el apoyo de un Sistema de Gestin de Base de Datos (SGBD) o de un sistema de gestin de ficheros. Metamodelo (no siempre visible), que constituye el marco para la definicin de las tcnicas y metodologas soportadas por la herramienta. Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona as un medio de comunicacin con otras herramientas.

Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta. Interfaz de usuario, que constar de editores de texto y herramientas de diseo grfico que permitan, mediante la utilizacin de un sistema de ventanas, iconos y mens, con la ayuda del ratn, definir los diagramas, matrices, etc. que incluyen las distintas metodologas.

Estructura general de una herramienta CASE La estructura CASE se basa en la siguiente terminologa :

CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificacin de sistemas, el anlisis de sistemas y el diseo de sistemas. CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseo detallado de sistemas, la implantacin de sistemas y el soporte de sistemas. CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestin de proyectos y la estimacin.

Objetivos 1. Mejorar la productividad en el desarrollo y mantenimiento del software. 2. Aumentar la calidad del software. 3. Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos. 4. Mejorar la planificacin de un proyecto 5. Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos. 6. Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las pruebas de errores y la gestin del proyecto. 7. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la documentacin 8. Gestin global en todas las fases de desarrollo de software con una misma herramienta. 9. Facilitar el uso de las distintas metodologas propias de la ingeniera del software. Integracin de las Herramientas CASE en el futuro

Las herramientas CASE evolucionan hacia tres tipos de integracin: 1. La integracin de datos permite disponer de herramientas CASE con diferentes estructuras de diccionarios locales para el intercambio de datos. 2. La integracin de presentacin confiere a todas las herramientas CASE el mismo aspecto. 3. La integracin de herramientas permite disponer de herramientas CASE capaces de invocar a otra herramientas CASE de forma automtica.