Ingenieria de software
Páginas: 24 (5860 palabras)
Publicado: 23 de enero de 2011
Clase 2: Desacoplamiento I
Uno de los aspectos básicos del diseño de software es cómo descomponer un programa en partes. En esta clase introduciremos algunas nociones fundamentales que nos permitan hablar sobre las partes y sobre el modo en que éstas se relacionan entre sí. Nos centraremos en el análisis del problema del acoplamiento entre partes, y en mostrar métodos para simplificarlo. En lapróxima clase, veremos una serie de técnicas de Java pensadas específicamente para soportar el desacoplamiento.
La idea clave que presentaremos hoy es la de especificación. Es erróneo pensar que las especificaciones no son más que documentación tediosa. Por el contrario, resultan esenciales para el desacoplamiento y, por lo tanto, para el diseño de alta calidad. Veremos que en diseños másavanzados, las especificaciones se convierten por sí mismas en elementos de diseño.
El libro de texto de la asignatura trata los términos usa y depende como sinónimos. En esta clase, haremos una distinción entre los dos, y explicaremos cómo la noción depende resulta más útil que la noción usa, que es un término más antiguo. El alumno aprenderá a construir y analizar diagramas de dependencia; losdiagramas de casos de uso se tratarán sólo de pasada.
2.1 Descomposición
Un programa se construye a partir de un conjunto de partes. El problema de la descomposición consiste en descubrir qué partes integran ese conjunto y qué relación guardan entre ellas.
2.11 ¿Por qué descomponer? Dijkstra ha puesto de manifiesto que si un programa se compone de N partes, y cada una de ellas tiene unaprobabilidad de exactitud de c –es decir, si existe una probabilidad de 1 – c de 1
que el programador cometa un error –entonces la probabilidad de que toda la estructura funcione es de cN. Si N tiene un valor alto, entonces, a menos que el valor de c se halle muy cerca de uno, cN será un valor próximo a cero. Con este argumento, Dijkstra pretende mostrar lo importante que es crear un programacorrectamente, y que el grado de importancia es proporcional al tamaño del programa. Si no se logra que cada parte sea prácticamente perfecta, no se podrá esperar que el programa llegue a funcionar.
(Este razonamiento se halla en un texto ya clásico: Structured Programming, de Dahl, Dijkstra y Hoare, Academic Press, 1972. Se trata de una argumentación atractiva y sugerente, aunque tal vez un tantofalaz; ya que, en la práctica, la probabilidad de conseguir que todo el programa resulte totalmente correcto es cero. Lo verdaderamente importante es asegurar que se mantengan ciertas propiedades, limitadas pero cruciales, y puede que éstas no se hallen en cada una de las partes. Volveremos sobre esta cuestión más adelante).
Sin embargo, el argumento de Dijkstra parece insinuar que no se deberíadescomponer un programa en partes. Cuanto más pequeña sea N, mayor será la probabilidad de que el programa funcione. Por supuesto, no hablo en serio –resulta más fácil conseguir que una parte pequeña, y no una grande, funcione correctamente (por lo que el parámetro c no es independiente de N). No obstante, merece la pena preguntarse qué ventajas se derivan de la división de un programa en partespequeñas. He aquí algunas: • División del trabajo. Un programa no surge de la nada: tiene que construirse gradualmente. Si se divide en partes, el proceso de construcción se agiliza, ya que ello permite que varias personas se dediquen a trabajar en las distintas partes. • Reusabilidad. Algunas veces es posible aislar las partes que son comunes a diferentes programas, de modo que se puedan crearuna sola vez y utilizar muchas veces. • Análisis modular. Incluso si un programa haya sido construido por una única persona, resulta conveniente construirlo por partes pequeñas. De este modo, cada vez que se completa una parte puede analizarse para comprobar su exactitud (leyendo el código,
2
testeándolo o mediante métodos más sofisticados de los cuales hablaremos más adelante). Si...
Uno de los aspectos básicos del diseño de software es cómo descomponer un programa en partes. En esta clase introduciremos algunas nociones fundamentales que nos permitan hablar sobre las partes y sobre el modo en que éstas se relacionan entre sí. Nos centraremos en el análisis del problema del acoplamiento entre partes, y en mostrar métodos para simplificarlo. En lapróxima clase, veremos una serie de técnicas de Java pensadas específicamente para soportar el desacoplamiento.
La idea clave que presentaremos hoy es la de especificación. Es erróneo pensar que las especificaciones no son más que documentación tediosa. Por el contrario, resultan esenciales para el desacoplamiento y, por lo tanto, para el diseño de alta calidad. Veremos que en diseños másavanzados, las especificaciones se convierten por sí mismas en elementos de diseño.
El libro de texto de la asignatura trata los términos usa y depende como sinónimos. En esta clase, haremos una distinción entre los dos, y explicaremos cómo la noción depende resulta más útil que la noción usa, que es un término más antiguo. El alumno aprenderá a construir y analizar diagramas de dependencia; losdiagramas de casos de uso se tratarán sólo de pasada.
2.1 Descomposición
Un programa se construye a partir de un conjunto de partes. El problema de la descomposición consiste en descubrir qué partes integran ese conjunto y qué relación guardan entre ellas.
2.11 ¿Por qué descomponer? Dijkstra ha puesto de manifiesto que si un programa se compone de N partes, y cada una de ellas tiene unaprobabilidad de exactitud de c –es decir, si existe una probabilidad de 1 – c de 1
que el programador cometa un error –entonces la probabilidad de que toda la estructura funcione es de cN. Si N tiene un valor alto, entonces, a menos que el valor de c se halle muy cerca de uno, cN será un valor próximo a cero. Con este argumento, Dijkstra pretende mostrar lo importante que es crear un programacorrectamente, y que el grado de importancia es proporcional al tamaño del programa. Si no se logra que cada parte sea prácticamente perfecta, no se podrá esperar que el programa llegue a funcionar.
(Este razonamiento se halla en un texto ya clásico: Structured Programming, de Dahl, Dijkstra y Hoare, Academic Press, 1972. Se trata de una argumentación atractiva y sugerente, aunque tal vez un tantofalaz; ya que, en la práctica, la probabilidad de conseguir que todo el programa resulte totalmente correcto es cero. Lo verdaderamente importante es asegurar que se mantengan ciertas propiedades, limitadas pero cruciales, y puede que éstas no se hallen en cada una de las partes. Volveremos sobre esta cuestión más adelante).
Sin embargo, el argumento de Dijkstra parece insinuar que no se deberíadescomponer un programa en partes. Cuanto más pequeña sea N, mayor será la probabilidad de que el programa funcione. Por supuesto, no hablo en serio –resulta más fácil conseguir que una parte pequeña, y no una grande, funcione correctamente (por lo que el parámetro c no es independiente de N). No obstante, merece la pena preguntarse qué ventajas se derivan de la división de un programa en partespequeñas. He aquí algunas: • División del trabajo. Un programa no surge de la nada: tiene que construirse gradualmente. Si se divide en partes, el proceso de construcción se agiliza, ya que ello permite que varias personas se dediquen a trabajar en las distintas partes. • Reusabilidad. Algunas veces es posible aislar las partes que son comunes a diferentes programas, de modo que se puedan crearuna sola vez y utilizar muchas veces. • Análisis modular. Incluso si un programa haya sido construido por una única persona, resulta conveniente construirlo por partes pequeñas. De este modo, cada vez que se completa una parte puede analizarse para comprobar su exactitud (leyendo el código,
2
testeándolo o mediante métodos más sofisticados de los cuales hablaremos más adelante). Si...
Leer documento completo
Regístrate para leer el documento completo.