Your SlideShare is downloading. ×
0
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Unidad 2.2 Escribiendo El Programa

963

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
963
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
47
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Ingeniería de Software Unidad II Escribiendo los programas Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática Docente Jornada Parcial Universidad Viña del Mar
  • 2. Introducción
    • Durante la codificación, debemos centrarnos en la implementación de la solución como software. Es decir, deben escribirse los programas que implementen el diseño.
    • Está tarea puede resultar intimidante:
      • Los diseñadores pueden no haber tenido en cuenta las particularidades de la plataforma y del ambiente de programación. Además las estructuras e interrelaciones que son fáciles de describir mediante diagramas y tablas no siempre resultan sencillas de escribir en forma de código.
      • Es indispensable escribir el código que sea comprensible no solo para el autor, sino también para otras personas que intervienen a medida que el sistema evoluciona en el tiempo.
      • Se debe sacar beneficio de las características del diseño, de las estructuras de datos y de las construcciones del lenguaje de programación, creando sin embargo, código que sea reutilizable.
  • 3. Estándares de programación y procedimientos
    • Los estándares y procedimientos de la organización deben conocerse antes de comenzar a escribir el código.
    • Estándares para los codificadores.
    • Los estándares y procedimientos sirven para organizar los propios pensamientos y evitar errores.
    • Estos permiten:
      • 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.
  • 4. Estándares de programación y procedimientos
    • 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 .
  • 5. Estándares de programación y procedimientos
    • Balancear diseño con la implementación.
    • El más critico de los estándares es la necesidad 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.
  • 6. Pautas para la programación
    • Sin importar que lenguaje de programación se utilice, cada componente de un programa implica al menos tres aspectos principales estructuras de control, algoritmos y estructuras de datos.
    • 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).
  • 7. Pautas para la programación Estructuras de Control
    • Ejemplo de un código ordenado del más general al más particular.
    beneficio = mínimo; if (año < 75 ) goto A; beneficio = máximo; goto C; If ( año < 65 ) goto B; If ( año < 55 ) goto C; A: if ( año < 65 ) goto B; beneficio = beneficio * 1.5 + bono; goto C; B: if ( año < 55) goto C; beneficio = beneficio * 1.5; C: siguiente paso if ( año < 55 ){ beneficio = mínimo; } else { if ( año < 65 ){ beneficio = mínimo + bono; } else { if ( año < 75 ){ beneficio = mínimo * 1.5 + bono; } else { beneficio = máximo; } } }
  • 8.
    • La modularidad es un buen atributo del diseño. Estas mismas ventajas se transfieren también al código. Construyendo un programa a partir de bloques modulares, se ocultan los detalles de implementación, haciendo que el sistema en su totalidad sea más fácil de entender, probar y mantener.
    • Al escribir el código es necesario tener en mente que la generalidad es una virtud y no hacer que el código resulte más especializado que lo necesario.
    • Otras características del diseño que se trasladan a los componentes del código, son el acoplamiento y cohesión. Al escribir un programa, deben usarse nombres de parámetros y comentarios para exhibir el acoplamiento entre componentes.
    Pautas para la programación Estructuras de Control
  • 9.
    • El diseño del programa a menudo especifica una clase de algoritmos a ser utilizados al codificar el componente que está escribiendo.
    • Por ejemplo: el diseño puede indicar el uso de un algoritmo Quicksort o puede proporcionar los pasos lógicos del algoritmo Quicksort.
    • Sin embargo, quien programa dispone de una gran dosis de flexibilidad, para la conversión del algoritmo a código, sujeto a las restricciones del lenguaje de implementación y del hardware.
    Pautas para la programación Algoritmos
  • 10.
    • Uno de los aspectos que con lleva mayor prudencia es el rendimiento de la implementación.
    • Hacer más rápido el código puede tener costos ocultos:
      • el costo de escribir código más veloz, ya que puede ser más complejo y por lo tanto llevará más tiempo escribirlo.
      • el costo del tiempo para probar el código, cuya complejidad requiere más casos de prueba y datos de prueba.
      • costo de tiempo para que los usuarios comprendan.
      • costo de tiempo para modificar el código, si es necesario.
    • Se recomienda no sacrificar claridad y corrección en beneficio de velocidad
    Pautas para la programación Algoritmos
  • 11. Pautas para la programación Estructuras de Datos Al escribir programas, se debería fijar el formato y almacenar datos de modo que la gestión y manipulación de datos sea directa. Existen varias técnicas que utilizan las estructuras de datos para indicar como debería organizarse el programa. 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.
  • 12. Pautas para la programación Estructuras de Datos
    • Mantener la simplicidad del programa
    • Ejemplo: La reestructuración de datos puede simplificar los cálculos que realiza un programa.
    • Para calcular el impuesto. Como entrada, se da el monto de la renta imponible y se dice lo siguiente:
      • Para los primeros $ 10.000 de ingreso la tasa es 10%.
      • Para los siguientes $ 10.000, por encima de 10.000, la tasa es 12%.
      • Para los siguientes $ 10.000, por encima de 20.000, la tasa es 15%.
      • Para los siguientes $ 10.000, por encima de 30.000, la tasa es 18%.
      • Para cualquier ingreso por encima de 40.000, la tasa es 20%.
    • Quien tenga un ingreso imponible de 35000 tributa el 10% de los primeros 10000, el 12% por los siguientes 10000, un 15% por los siguientes 10000 y un 18% por los 5000 restantes.
  • 13. Pautas para la programación Estructuras de Datos Mantener la simplicidad del programa - Ejemplo imp = 0; If ( imponible == 0) exit(0); If (imponible > 10000) imp = imp + 1000; Esle { imp = imp + 0.10 * imponible; exit(0); } If ( imponible > 20000) imp = imp + 1200; Else { imp = imp + 0.12 * (imponible – 10000); exit(0);} If (imponible > 30000) imp = imp +1500; Else { imp = imp + 0.15 * (imponible -20000); exit(0);} If (imponible < 40000){ imp = imp + 0.18 * (imponible -30000); exit (0); } else imp = imp + 1800 + 0.20 * (imponible – 40000); Mejorando con estructuras de datos el código anterior. Considerando: for (int i = 1, level =0; i <= 5; i++){ if (imponible > franja [i]){ level = level +1; } } Imp = base[level] + porcentaje [level] * (imponible – franja [level]); 20 5500 40000 18 3700 30000 15 2200 20000 12 1000 10000 10 0 0 Porcentaje Base Franja
  • 14. Pautas para la programación Estructuras de Datos Determinar una estructura de programa utilizando una estructura de datos. En general, las estructuras de datos pueden influir en la organización y flujo de un programa. En algunos casos, las estructuras incluso pueden influir en la selección del lenguaje. Ejemplo: LISP: lenguaje preparado para operar con un procesador de listas. Contiene estructuras que lo hacen más atractivo para el trabajo con listas. ADA y EIFFEL: contienen estructuras apropiadas para el manejo de excepciones. En general, es conveniente considerar cuidadosamente las estructuras de datos, en el momento de decidir qué lenguaje se usará para la implementación del diseño.
  • 15. Pautas para la programación Pautas Generales
    • Estrategias útiles para conservar la calidad del diseño en la codificación.
    • 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.
    • 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.
  • 16. Pautas para la programación Pautas Generales
    • Inclusión de pseudocódigo
    • 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.
    • Revisión y reescritura, no a las remiendas
    • Cuando se escribe código, a menudo se prepara un borrador, luego se lo revisa y reescribe hasta obtener un resultado satisfactorio.
  • 17. Pautas para la programación Pautas Generales
    • Revisión y reescritura, no a las remiendas
    • 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.
    • 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.
  • 18. Documentación 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. 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.
  • 19. Documentación Documentación interna
    • Encabezamiento
    • Al comienzo de los programas hay que incluir un encabezamiento que posea la siguiente información:
      • Que denominación tiene el componente.
      • Quién a escrito el componente (incluye teléfono y e-mail).
      • Dónde va ubicado el componente en el diseño general de sistemas.
      • Cuándo fue escrito, revisado y modificado.
      • Por que existe el componente (explicar con diagramas o descripciones simples).
      • Como utilizar sus estructuras de datos, algoritmos y control.
  • 20. Documentación Documentación interna
    • 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.
    • 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.
  • 21. Documentación Documentación interna Nombres de variables y etiquetas con significado Seleccionar nombres de variables y enunciados que reflejen su utilización o significado. Dar formato para mejorar la comprensión Mediante indentado y espaciado se puede reflejar la estructura básica del sistema. Weinberg (1971) recomienda un formato para las sentencias donde los comentarios aparezcan en uno de los lados de la pagina y la sentencia en el otro. int i =0; If ( i++ == 0) { //comentario 1 acción; //comentario 2 }
  • 22. Documentación 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. 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. 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 extraido.
  • 23. Documentación Documentación externa 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.
  • 24. Bibliografía
    • Guía del Tópico:
    • Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000.
    • Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002.
    • Solo referencial:
    • Ingeniería de Software: Un enfoque práctico - Roger S. Pressman - Mc Graw Hill – 2002.

×