2. Documentación interna ➢ Información dirigida a quienes leerán el código fuente del programa. ➢ Se incluye información sumaria para identificar el programa y describir el algoritmos, estructuras de datos y flujo de control. ➢ Usualmente esta información se ubica al comienzo de cada componente en un conjunto de comentarios que se denomina bloque de encabezamiento.
3. ➢Se considera como documentación del programa al conjunto de descripciones escritas que explican al lector qué hace el programa y cómo lo hace. ➢La documentación interna es el material descriptivo, escrito directamente dentro del código, y cualquier otra documentación es externo.
4. Dado que el diseño es solo una indicación de lo que se hace en un componente de programa, es útil avanzar por etapas, en lugar de traducir inmediatamente el diseño en código. Se puede usar pseudocódigo para adaptar el diseño al lenguaje elegido. Adoptando construcciones y representaciones de datos sin involucrarse inmediatamente en los aspectos específicos de cada comando, se puede experimentar y decidir cuál implementación es la más apropiada.
5. Revisión y remiendas reescritura, no a las Cuando se escribe código, a menudo se prepara un borrador, luego se lo revisa y reescribe hasta obtener un resultado satisfactorio. Si se descubre, que el flujo de control es complejo, que los procesos de decisión son difíciles de comprender, puede ser oportuno volver al diseño. Se debe reexaminar el diseño para determinar si los problemas que aparecen son inherentes al diseño o tienen que ver con la traducción a código.
6. Reutilización Tipos de reutilización: ✓ Reutilización productiva: cuando se crean componentes destinados a ser reutilizados en aplicaciones posteriores. ✓ Reutilización consumidora: consiste en reutilizar componentes originalmente desarrollados para otros proyectos.
7. Encabezamiento Al comienzo de los programas hay que incluir un encabezamiento
8. Otros comentarios del programa ➢El encabezamiento actúa como una introducción al programa. ➢Los comentarios adicionales iluminan a los lectores a medida que se desplazan a lo largo del programa.
9. Otros comentarios del programa ➢Hay lugares para comentarios aún cuando el código está bien escrito y claramente estructurado. A pesar que la claridad y la estructura minimizan la necesidad de otros comentarios, éstas resultan particularmente útiles toda vez que debe agregarse información de ayuda aún componente. Resulta esencial que los comentarios reflejen el comportamiento real del código. Lo ideal es que agreguen nueva información. ➢ Se debe tener atención cuando un código es difícil de documentar, ya que es complejo, por lo que sería bueno revisarlo.
10. Documentación externa: Está documentación se prepara para ser leída incluso por quienes tal vez nunca verán el código real. Este documento explica de forma más amplia el código que los comentarios.
11. Descripción del sistema: Se debe tratar el problema tratado por el componente. No como una replica de la especificación de requerimientos, sino que es una discusión general de la situación, explicando cuando se invoca el componente y por qué se lo necesita.
12. Descripción de los algoritmos Deben explicarse todos los algoritmos utilizados en el componente, incluyendo formulas, condiciones especiales o de límite, e inclusive su derivación, o bien la referencia al libro o articulo del cuál se ha extraído.
13. Descripción de los datos Los diagramas de flujo de datos deben ir acompañados por las referencias relevantes del diccionario de datos. Para los componentes de precedencia orientada a objetos, la vista general de objetos y clases debe explicar la interacción general entre los objetos.
14. Estándares para los codificadores.
15. Los estándares y procedimientos sirven para organizar los propios pensamientos y evitar errores.
16. ✓Definen métodos para documentar el código de manera que resulte claro y fácil de seguir. ✓Ayudan en la conversión del diseño a código. En consecuencia cambios en el diseño serán fáciles de implementar en el nivel código.
17. • Estándares para los demás. • Tan pronto como el código esté completo, es probable que otros participantes lo utilicen de distintas maneras. Ej.: Grupo de prueba. • Después de poner el sistema en funcionamiento, todavía pueden hacerse cambios, debido a la existencia de fallas o por modificaciones del cliente. • Es posible que el desarrollador no forme parte de los equipos de prueba o mantenimiento, por lo cuál es esencial organizar, dar formato y documentar el código de manera que otros puedan comprender qué hace y cómo opera, con facilidad.
18. Balancear diseño con la implementación. • Es necesario de establecer una correspondencia directa entre los componentes de diseño y los componentes de código del programa. • El proceso completo de diseño resulta de escaso valor si la modularidad del diseño no se traslada efectivamente al código. • Las características del diseño, como bajo acoplamiento, elevada cohesión e interfaces bien definidas, también deben ser características del programa de modo que algoritmos, funciones, interfaces y estructuras de datos puedan ser fácilmente rastreadas del diseño al código y viceversa.
19. Pautas para la programación
20. Estructuras de control • La mayoría de las estructuras de control de un componente están sugeridas por la arquitectura y el diseño, y es deseable conservarlas a medida que el diseño se convierte en código. • Algunas pautas y estándares sugieren que el código debe estar escrito de manera tal que un componente pueda leerse fácilmente desde lo general a lo particular (top-down).
21. Mantener la simplicidad del programa ➢ El diseño del programa puede especificar alguna de las estructuras de datos a utilizar en la implementación de las funciones. Por lo general se escogen porque promueven el ocultamiento de información y manejo de interfaz. ➢ La manipulación de información que tiene lugar dentro de un componente puede influir en la selección de la estructura de datos.
22. Pautas generales
23. ✓ Localización de entradas y salidas Aquellas partes de un programa que leen entradas o generan salidas, son altamente especializadas y deben reflejar características del hardware o del software subyacente. Estas secciones son difíciles de probar y muy propensas al cambio. Por está razón es bueno localizar estas secciones en componentes separados del resto del código.
24. Inclusión de pseudocódigo El diseño puede ser relativamente independiente del lenguaje, dando así varias opciones acerca de las construcciones particulares del lenguaje que se pueden ocupar.
