La mirada clásica del desarrollo de software
DSN_XP entra en contacto con las ideas de David L Parnas cuando nos era necesario descubrir aquellos aspectos importantes en el proceso de desarrollar software para terceros y la necesidad de trabajar en equipos multidisciplinares.
Por otro lado, las nociones de modularidad del software no eran muy bien comprendidas tanto por nosotros al venir de la programación estructurada como por parte de quienes nos enseñaban o conversaban sobre los criterios con los cuales se descompone un escenario que requiere automatización y control y la gestión de datos usualmente asociados a reportes tipo.
Para poder responder adecuadamente a todas las inquietudes que surgen del estudio del desarrollo de software, era necesario crear como herramienta una nueva perspectiva que como tal, daría el apoyo académico necesario para sostener nuestro mirar arquitectónico que en esencia pregunta:
- ¿Cómo se diseña software modularmente?
- ¿Cómo se organiza el software desarrollado para una reutilización apropiada?
M. Broy, E. Denert (Eds.): Software Pioneers
© Springer-Verlag Berlin Heidelberg 2002
David L. Parnas
Professor of Software Engineering
McMaster University
parnas@qusunt.cas.mcmaster.ca
La historia secreta de la ocultación de información
El concepto de "ocultar información" como principio de diseño de software es ampliamente aceptado en los círculos académicos. Muchos diseños exitosos pueden verse como aplicaciones exitosas de abstracción u ocultación de información. Por otro lado, la mayoría de los desarrolladores de software industrial no aplican la idea y muchos lo consideran poco realista.
Este artículo describe cómo se desarrolló la idea, discute las dificultades en su aplicación y especula sobre por qué no ha sido completamente exitoso.
Una aventura holandesa
La cuestión de cómo dividir los sistemas en módulos no estaba en mi mente en 1969 cuando tomé un año de excedencia de mi puesto académico para trabajar con una nueva empresa, Philips Computer Industry, en los Países Bajos.
Estaba interesado en el uso de la simulación en el desarrollo de software y quería ver si mis ideas podían funcionar en la industria. Nunca me encontré afuera. En cambio, llegué a comprender que el desarrollo de software en la industria estaba en un nivel mucho más primitivo de lo que mi experiencia académica habría sugerido. Las ideas que había ido a Holanda a explorar eran obviamente poco realistas.
Había escuchado y leído muchos argumentos a favor de la programación modular y esos argumentos parecían obviamente correctos. El mensaje fue claro; el software debe diseñarse como un conjunto de componentes. Con experiencia en ingeniería eléctrica, ni siquiera podía imaginarme a cualquiera que intente construir un producto complejo excepto como un ensamblaje de componentes o módulos más pequeños. Además, estaba acostumbrado a tener módulos con interfaces bien diseñadas y relativamente simples.
Estaba desconcertado por la flexibilidad y naturaleza arbitraria de las interfaces que se estaban discutiendo. En ese momento, en ingeniería eléctrica, los módulos o componentes se presentaban a nosotros; aprendimos cómo ensamblarlos en circuitos. Nunca tuvimos ocasión de debatir la naturaleza de un componente. Era la exposición al desarrollo de software industrial real lo que me hizo darme cuenta que en software, la naturaleza de un componente o módulo no es obvia.
De hecho, la gente rara vez puede definir esos términos a menos que las herramientas los definan. En la academia y en los periódicos había visto algunos sistemas bien organizados (El sistema
THE de Dijkstra, por ejemplo [5]), pero a medida que me familiaricé con software comercial,
comencé a darme cuenta de que se necesita una comprensión profunda y mucho esfuerzo para mantener el software simple y fácil de entender.
Frases como "Diseño limpio" o "Hermoso" no son significativas
Philips me dio la oportunidad de ver el diseño de un nuevo producto. Como se desarrolló, me hacía sentir cada vez más incómodo y comencé a confiar mis inquietudes a mi supervisor. Le dije repetidamente que los diseños no eran "limpios" y que deben ser "hermosos" en la forma en que los diseños de Dijkstra eran hermosos.
No le pareció un comentario útil. Él me recordó que éramos ingenieros, no artistas. En su mente yo estaba simplemente expresando mi gusto y quería saber qué criterio estaba usando para elaborar mi juicio. ¡No pude decírselo! Porque no pude explicar qué principios estaban siendo violados, mis comentarios fueron simplemente ignorados y el trabajo continuó.
Sintiendo que debe haber una manera de explicar y proporcionar motivación para mi "gusto", comencé a
tratar de encontrar un principio que distinguiría los buenos diseños de los malos.... Los ingenieros son muy pragmáticos; pueden admirar la belleza, pero buscan la utilidad. Traté de encontrar una explicación de por qué la "belleza" era útil.
La servilleta fatal
El primer atisbo de comprensión llegó durante el almuerzo. Dos miembros del equipo de software comenzaron a discutir el trabajo. Jan, que estaba creando un compilador, preguntó a Johan, el experto en bases de datos, "¿Qué significa abrir un archivo de todas formas?"
Johan y yo lo miramos con extrañeza; seguramente él sabía lo que "abrir" era. No podía hacer nada con un archivo hasta que lo hubiera abierto. Johan dijo eso y Jan respondió: “No, ¿Qué significa realmente? Tengo que implementar el comando de apertura y necesito saber qué código generar".
Johan agarró una servilleta del dispensador de la mesa y empezó a dibujar un diagrama de un bloque de control. Mientras dibujaba,
explicó el significado de cada campo e indicó dónde se ubicaban las direcciones específicas y los
bits de control.
Sentí que dibujar el diagrama era un error y traté de
detenerlos. les dije que se arrepentirían si continuaban. Cuando
preguntaron por qué?, yo sólo respondí que no deberían tener que intercambiar dicha
información. Ellos insistieron en que los redactores del compilador necesitaban
esa información y trataron de deshacerse de mí porque estaba interfiriendo con su
progreso.
¿Por qué no pude ni explicar? ¿Por qué pensé que estaban cometiendo un error y ni les ofrecí una mejor manera de resolver el problema?, me quedé
extrañamente silencioso y observé mientras se completaba la discusión.
La
servilleta fue llevada arriba, se le perforaron dos agujeros y se la insertó en una
carpeta. Más tarde, otro de los miembros del equipo del compilador hicieron copias de la
servilleta y las pusieron en sus propios archivos.
Meses después, tenía pruebas de que había tenido
razón.
Johan se olvidó de la servilleta. Cuando era necesario cambiar el formato
del bloque de control, la servilleta no se actualizó. El equipo de Jan
continuó trabajando como si el bloque de control no había cambiado. Cuando se integraron los dos
productos, no funcionaron correctamente y tomó algún tiempo averiguar por
qué e incluso más para corregir el compilador.
Cada cambio en el formato
del bloque de control desencadenaba un cambio tanto en el compilador como en el sistema de base
de datos; este acoplamiento no deseado a menudo consumía un tiempo valioso.
En este punto, estaba claro para mí que había tenido razón,
pero todavía estaba molesto por lo que habían dicho Jan y Johan. Ellos
también tenían razón. El grupo del compilador necesitaba alguna información que permitiera que el
código necesario sea generado. No pude decirles lo que podrían haber
hecho en lugar de intercambiar los detalles de la servilleta.
Distribución de información en el software
Cuando mi tiempo en Europa llegó a su fin, tenía algo del concepto pero no todo ello. Mi primer trabajo sobre "ocultación de información" se presentó en la conferencia IFIP en 1971 [8]. Aunque estas conferencias están destinadas a juntar personas de todo el mundo, las sesiones no cuentan con una amplia asistencia ni los procedimientos son bien leídos. No obstante, el periódico explicó que fue la distribución de información lo que ensució los sistemas al establecer conexiones casi invisibles entre módulos supuestamente independientes.
Impartición de un curso temprano de ingeniería de software
Cuando volví a la docencia, me dijeron que, como era ingeniero1 y ahora tenía experiencia en desarrollo de software industrial, debería enseñar el nuevo curso de “ingeniería de software”. Nadie pudo decirme cual es el contenido que debería ser de ese curso o cómo debería diferenciarse de un curso de programación avanzada. Me dijeron que enseñara lo que pensara que era importante2, después pensé, me quedó claro que la distribución de información y cómo evitarlo, tenía que ser una gran parte de ese curso.
- En realidad, yo no era un ingeniero pero tenía títulos de ingeniería. Para esa vez no había aplicado para una licencia en ingeniería como yo no practicaba la ingeniería. Como la mayoría de los científicos, el jefe de departamento no entendería la diferencia.
me temo que lo mismo sucede en muchos departamentos de ciencias de la computación actualmente
Decidí hacer esto por medio de un proyecto con distribución de información limitada y demostrar los beneficios de un diseño “limpio” [11]. También encontré una definición de "módulo" que era independiente de cualquier herramienta, una asignación de trabajo para un individuo o un grupo.
Para impartir este primer curso, decidí tomar el concepto de modularidad seriamente. Diseñé un proyecto que se dividió en cinco módulos y dividió la clase en cinco grupos. Cada individuo en un grupo tendría la misma asignación de trabajo (módulo) pero usaría un método diferente para completarlo. Con cuatro miembros por grupo, esperábamos obtener cuatro implementaciones de cada módulo. Las implementaciones de un módulo fueron requeridas para ser intercambiables para que (si todo funcionara) terminarían con 1024 combinaciones ejecutables. Veinticinco seleccionados al azar, se probaron combinaciones y (eventualmente) se ejecutaron.
Los resultados de este experimento me parecieron importantes porque la construcción de módulos de software intercambiables parecía inalcanzable por otros en ese momento. De hecho, incluso hoy veo lo difícil que puede ser instalar una actualización del software que todos usamos. El intercambio de una implementación de un módulo a otro rara vez va bien. Casi siempre hay interfaces complejas y muchos pequeños detalles que mantienen ocupadas las "líneas de ayuda" siempre que se instalen nuevas versiones de módulos menores.
Lo que Johan debería haberle dicho a Jan
Al realizar el experimento como ejercicio educativo, finalmente había encontrado la respuesta al problema planteado un año antes por Jan y Johan.
Debido a que cada módulo tenía cuatro implementaciones realmente diferentes, mis estudiantes no podían intercambiar hablado el tipo de información detallada que Jan y Johan habían discutido. En su lugar, diseñé una interfaz abstracta, una que todas las versiones de un módulo podrían tener en común. Tratamos la descripción de la interfaz como una especificación, es decir, todas las implementaciones fueron necesarias para satisfacer esa descripción. Porque no les dijimos a los estudiantes qué combinaciones serían probadas, no podrían utilizar ninguna información adicional.
De hecho, los detalles de implementación se mantuvieron en secreto. Se publicó el artículo que describía el experimento y su resultado en una conferencia importante, pero no ha sido ampliamente leído ni citado [12].
Dos artículos de revistas sobre ocultación de información
Hubieron dos artículos de revistas que siguieron y estos son ampliamente citados aunque a veces parece que quienes los citan no los han leído y muchos de los que los han leído se refieren a ellos sin citarlos. Lo mejor de los dos artículos [10] fue rechazado por primera vez por la revista. El revisor declaró: “Obviamente, Parnas no sabe de qué está hablando porque nadie lo hace de esa manera". Me opuse señalando que uno no debería rechazar una idea que dice ser nueva simplemente porque es nueva. El editor luego publicó el artículo sin mayores cambios.
Lenguaje: a menudo es un problema incorrecto
Debido a que había tardado tanto en encontrar una solución al dilema planteado por Jan y Johan, lo primero que pensé fue que era la notación de la especificación, eso fue significativo. En consecuencia, las primeras comunicaciones de la ACM El artículo [9] discutió la técnica de especificación e ilustró la idea por publicar las especificaciones con muchos errores tipográficos introducidos en el proceso de composición tipográfica (manual).
Fueron necesarias varias discusiones con personas que habían leído el artículo antes que me de cuenta de la importancia del hecho (obvio) de que el método de especificación no funcionaría con un conjunto arbitrario de módulos. Lo más importante, sería no haber trabajado con módulos de diseño convencional. El secreto del éxito del experimento no fue la notación de especificación sino la descomposición.
A lo largo de los años, he propuesto y estudiado enfoques más generales para la especificación del módulo [1, 18]. Muchos otros también han examinado este problema. Lentamente me he dado cuenta de que la notación estándar de las matemáticas es mejor que la mayoría de los lenguajes que pueden inventar los científicos informáticos. He aprendido que es más importante aprender a utilizar los conceptos matemáticos y su notación que inventar nuevas notaciones ad hoc.
Lo que realmente importa es el diseño
Fue el hecho de que la modularización limitó la cantidad de información que tenía que ser compartida por los implementadores del módulo que hicieron del esfuerzo un éxito. Después de reflexionar me di cuenta de que había encontrado la respuesta a la pregunta que me había hecho mi gerente en Philips. La diferencia entre entre los diseños que encontré "hermosos" y los que encontré feos, fue que los hermosos diseños encapsulaban información cambiante o arbitraria. Debido a que las interfaces contenían solo información "sólida" o duradera, parecían simples y podían llamarse hermosas. Para mantener las interfaces "Hermosas", es necesario estructurar el sistema de modo que toda información arbitraria o cambiante o muy detallada está oculta.
El segundo artículo explicó esto, aunque nunca usó la frase "ocultación de información". Es posible formalizar el concepto de información escondida usando la teoría de la información de Shannon.
Las interfaces son un conjunto de suposiciones que un usuario puede hacer sobre el módulo. Cuanto menos probable sea que estas suposiciones deban cambiar (es decir, cuanto más arbitrarias son las suposiciones), cuanto más "bellas" parecen. Por tanto, las interfaces que contienen menos información en el sentido de Shannon son más "hermosas". Desafortunadamente, esta formalidad no es muy útil. Las aplicaciones de las teorías de Shannon nos exigen para estimar la probabilidad de las "señales" y nunca tenemos tales datos.
De los módulos de Parnas a los módulos de ocultación de información
El primer grupo grande que se basó en la idea de ocultar la información fue SRI Internacional. Introdujeron el HDM o método de desarrollo jerárquico descrito en [19-22]. Se refirieron a los módulos como “Módulos de Parnas”. Solicité que cambiaran a una terminología más descriptiva, "módulos de información, "ocultación" y el término "ocultación de información" es el que ha sido aceptado. Este término ahora se usa a menudo en libros y artículos ya sea cita o explicación.
Ocultar información es más difícil de lo que parece
Ocultar información, como hacer dieta, es algo que se describe más fácilmente que hacerlo. El principio es simple y se explica fácilmente en términos de la matemática y la teoría de la información. Cuando se aplican correctamente suelen tener éxito. Abstracciones como tuberías Unix, postscript o X-windows logran el objetivo de permitir varias implementaciones de la misma interfaz. Sin embargo, aunque el principio se publicó hace 30 años, el software actual está lleno de lugares donde la información no está oculta, las interfaces son complejas y los cambios son irracionalmente difíciles.
En parte, esto puede ser atribuido a la falta de estándares educativos para profesionales desarrolladores de software. Es bastante fácil conseguir un trabajo desarrollando software con poca o sin exposición al concepto. Además, si el gerente y los compañeros de trabajo no conocen el concepto, no apoyarán el esconder el uso de la información por alguien que lo entienda. Ellos argumentarán que, "nadie lo hace de esa manera" y que no pueden permitirse experimentar con nuevas ideas.
Además del hecho de que los estándares educativos de ingeniería de software son mucho más bajos que los de otros campos de la ingeniería, he observado otras razones de fallo al aplicar la ocultación de información.
El instinto del diagrama de flujo
Mis experimentos originales con el índice KWIC revelaron que la mayoría de los los firmantes diseñan software pensando en el flujo de control. A menudo ellos comienzan con un diagrama de flujo. Los cuadros de los diagramas de flujo se les denomina módulos. Desafortunadamente, los módulos desarrollados de esta manera intercambian grandes cantidades de información en estructuras de datos complejas y tienen interfaces "feas".
La descomposición basada en diagramas de flujo casi siempre viola el principio de ocultación de la información. El hábito de comenzar con un diagrama de flujo termina mal. Puedo enseñar el principio, advertir contra la modularización en base de un diagrama de flujo y ver a mis alumnos hacer exactamente eso una hora más tarde.
La planificación para el cambio parece ser demasiada planificación
La aplicación adecuada del principio de ocultamiento de información requiere mucho de análisis. Hay que estudiar la clase de aplicaciones y determinar qué es poco probable que los aspectos cambien al identificar decisiones cambiantes.
La simple intuición no es adecuada para esta tarea. Al diseñar software, yo he identificado ciertos hechos como susceptibles de cambiar solo para saber más tarde que había razones fundamentales por las que no cambiarían. Peor aún, uno podría asumir que ciertos hechos nunca cambiarán (por ejemplo, la longitud de un número de teléfono local o la longitud de un Postleitzahl). Diferenciando lo que no cambiará de las cosas que se pueden mencionar en la descripción de la interfaz tome mucho tiempo. A menudo, un desarrollador se preocupa mucho más por reducir el costo de desarrollo, o el tiempo de comercialización, que reducir el costo de tenencia y mantenimiento. Esto es especialmente cierto cuando el grupo de desarrollo no es responsable del mantenimiento. ¿Por qué un gerente debería gastar dinero de su propio presupuesto para ahorrar dinero a algún otro gerente en el futuro?
Malos modelos
Los ingenieros de cualquier campo no siempre son innovadores. A menudo toman un producto como modelo haciendo el menor número de cambios posible. La mayor parte de nuestros productos de software, fueron diseñados sin el uso de ocultar información y sirven como malos modelos cuando se usan de esta manera. Ocultación de información innovadora los diseños a menudo se rechazan porque no son convencionales.
Ampliación de software defectuoso
Dada la gran base de software instalado, la mayoría de los productos nuevos se desarrollan como extensiones a esa base. Si el software antiguo tiene interfaces complejas, el software extendido tendrá el mismo problema. Hay formas de evitar esto, pero no se aplican con frecuencia. Por lo general, si no se ha aplicado la ocultación de información en el software base, las extensiones futuras tampoco la aplicarán .
Las suposiciones a menudo pasan desapercibidas
Mi ejemplo original de ocultamiento de información fue el índice KWIC simple programa descrito en [10]. Este programa todavía se utiliza como ejemplo del principio. Solo una vez alguien ha notado que contiene un defecto causado por no ocultar una suposición importante. Cada módulo del sistema fue escrito con el conocimiento de que los datos comprendían cadenas de strings.
Esto llevó a un algoritmo de clasificación muy ineficiente porque comparar dos strings, es una operación que se repetiría muchas veces y es relativamente lenta. Se podría obtener una aceleración considerable si las palabras se ordenaran una vez y reemplazadas por un conjunto de números enteros con la propiedad de que si dos palabras son ordenados alfabéticamente, los enteros que los representan tendrán el mismo orden. La clasificación de cadenas de números enteros se puede hacer mucho más rápido que clasificación de cadenas de strings. Las interfaces del módulo descritas en [9] no permiten que esta simple mejora se limite a un módulo.
Mi error ilustra lo fácil que es distribuir información innecesariamente. Este es un error muy común cuando las personas intentan utilizar el principio de ocultación de la información. Si bien la idea básica es ocultar información que probablemente cambie, a menudo uno puede beneficiarse ocultando otra información también porque permite la reutilización de algoritmos o el uso de algoritmos más eficientes.
Reflejo del entorno del sistema en la estructura del software
Varios "expertos" en diseño de software han sugerido que uno debería reflejar emocionantes estructuras comerciales y estructuras de archivos en la estructura del software. En mi experiencia, esto acelera el proceso de desarrollo de software (tomando decisiones rápidamente) pero conduce a un software que es una carga sobre sus propietarios si intentan actualizar sus estructuras de datos o cambiar su organización.
Reflejar hechos cambiantes en la estructura del software es una violación del principio de ocultamiento de la información. Al determinar los requisitos, es muy importante conocer el entorno, pero rara vez es el "movimiento" correcto para reflejar ese entorno en la estructura del programa.
"Oh, es una lástima que lo cambiamos"
Incluso cuando la ocultación de información se ha aplicado con éxito, a menudo falla a largo plazo debido a una documentación inadecuada. He visto firmas donde los criterios de diseño no se explicaron al programa de mantenimiento. En estos casos, la estructura del sistema se deterioró rápidamente porque las buenas decisiones de diseño, que no tenían sentido para los encargados del mantenimiento, fueron invertidos. En un caso, señalé las ventajas de una particular estructura de software sólo para ver un rayo de comprensión en los ojos de mi oyente cuando dijo: "Oh, qué lástima que lo cambiamos".
Una estructura modular jerárquica para sistemas complejos
Mis artículos originales usaban sistemas muy pequeños como ejemplos. Sistemas con 5, la mayoría de los programadores pueden comprender 10 o 15 módulos. Sin embargo, al aplicar el principio a un problema con cientos de decisiones de diseño cambiantes, detalles de interfaz y requisitos, reconozco que sería difícil para un programador de mantenimiento tener la visión general necesaria para encontrar partes relevantes del código cuando se necesitaba un cambio. Para superar esto, organizamos los módulos en un jerarquía. Cada uno de los módulos de nivel superior tenía un secreto claramente definido y se dividió en módulos más pequeños utilizando el mismo principio. Esto resultó en una estructura de árbol. El programador puede encontrar los módulos relevantes por seleccionar un módulo en cada nivel y pasar a una descripción más detallada de composición. La estructura y el documento se describen en detalle en [16].
¡No hay "niveles de abstracción"!
Algunos autores y profesores han utilizado la frase "niveles de abstracción" cuando se habla de sistemas en los que la abstracción o el ocultamiento de la información ha sido aplicado. Aunque la terminología parece inocente, no está claramente definida y puede dar lugar a errores de diseño graves. El término "niveles" se puede utilizar correctamente sólo si se ha definido una relación libre de bucles [13].
Ninguno de los autores que utilizan esta frase han definido la relación, “más abstracto que”, que se necesita para comprender los niveles. ¿Qué haría tal relación realmente qué significa? Es un módulo que oculta la representación de ángulos más (o menos) abstracto que un programa que oculta los detalles de un periférico ¿dispositivo? Si no es así, ¿deberían ambos módulos estar al mismo nivel? Si es así, ¿Qué significa eso? Usar la frase "niveles de abstracción" sin una definición útil la inicialización de la relación definitoria es un signo de confusión o descuido.
A menudo, la frase "niveles de abstracción" es utilizada por aquellos que no entienden claramente distinguir entre módulos (colecciones de programas) y los programas en sí mismos. Se ha demostrado que es útil organizar programas en un orden jerárquico de estructura basada en la relación "usos" donde A utiliza B significa que B debe estar presente cuando A ejecuta [5]. Sin embargo, como se muestra en [15] no suele ser derecho a poner todos los programas en un módulo al mismo nivel en la jerarquía de "usos". Algunas partes de un módulo pueden utilizar programas a un nivel superior al de otros programas en ese módulo. Se puede encontrar una ilustración de esto en [15].
Ideas más recientes: tipos de datos abstractos, OO, componentes
El concepto de ocultamiento de información es la base de tres más recientes conceptos. Los siguientes párrafos los describen brevemente.
Tipos de datos abstractos
La noción de tipos de datos abstractos corrigió un descuido importante en mi tratamiento original de la ocultación de información. En los ejemplos que motivaron mi trabajo, solo había una copia de cada estructura de datos oculta. Otros (más notablemente Barbara Liskov y John Guttag) reconocieron que podríamos quieren muchas copias de tales estructuras y que esto haría posible para implementar nuevos tipos de datos en los que la implementación (representación más algoritmos) estaba oculto. Pudiendo utilizar variables de estas nuevas, tipos de datos abstractos definidos por el usuario exactamente de la manera en que usamos variables de tipos de datos integrados es obviamente una buena idea. Desafortunadamente, nunca he visto un lenguaje que logró esto.
Lenguajes orientados a objetos
Un efecto secundario de la aplicación del ocultamiento de información es la creación de nuevos objetos que almacenan datos. Los objetos se pueden encontrar en el sistema THE de Dijkstra [5] y muchos ejemplos posteriores. Se pueden crear objetos que oculten información en cualquier lenguaje; mis primeros experimentos utilizaron versiones primitivas de FORTRAN.
Algunos lenguajes posteriores, como Pascal, hicieron las cosas un poco más difícil al introducir restricciones sobre dónde se pueden declarar las variables por lo que es necesario globalizar los datos ocultos. Se descubrió que un familia de lenguajes inicialmente diseñados con fines de simulación, SIMULA [3] y SIMULA 67 [4], resultaron convenientes para este tipo de programación.
El concepto de proceso se introdujo para modelar las actividades en curso en el sistema que se está simulando. Cada proceso podía almacenar datos y había formas en que otros procesos envían "mensajes" que alteran estos datos. Así, sobre los criterios que se utilizarán en la descomposición de sistemas en módulos las características de los lenguajes SIMULA se adaptaban bien a la escritura de software que ocultaba datos y algoritmos. Más tarde se encontraron ideas similares en Smalltalk [6].
En ambos lenguajes, el concepto de módulo (clase) y proceso estaban enlazados, es decir, los módulos podrían funcionar en paralelo. Esto introduce innecesaria sobrecarga en muchas situaciones. Los lenguajes más recientes han agregado nuevos tipos de funciones (conocidas como herencia) diseñadas para hacer posible el compartir representaciones entre objetos. A menudo, estas funciones se utilizan incorrectamente y dan lugar a una infracción de la ocultación de información y a programas difíciles de cambiar. El efecto más negativo del desarrollo de los lenguajes OO ha sido distraer a los programadores de los principios del diseño.
Muchos parecen creer que si escriben su programa en un lenguaje OO, escribirán OO programas. Nada mas lejos de la verdad.
Diseño orientado a componentes
Los viejos problemas y sueños todavía están con nosotros. Solo las palabras son nuevas.
Investigaciones futuras: información estándar - Ocultar diseños
Treinta años después de que pude formular el principio de ocultación de información, me queda claro que este es el principio correcto. Además, veo pocas preguntas abiertas sobre el principio. Sin embargo, como se describe en la Sección 8, ocultar información no es fácil. Como se analiza en [2], [14] y [16], diseñar tales módulos requieren mucha investigación. Espero que en el próximo diciembre, veremos investigadores académicos girar en esta dirección (útil) y las revistas que presentan estructuras de módulos e interfaces de módulos para dispositivos, estructuras de datos, clases de requisitos y algoritmos. Ejemplos de Los diseños de módulos reutilizables se pueden encontrar en [17].
Referencias
[1] Bartussek, W., Parnas, D.L., “Using Assertions About Traces to Write Abstract
Specifications for Software Modules”, UNC Report No. TR77-012, December 1977;
Lecture Notes in Computer Science (65), Information Systems Methodology, Proceedings
ICS, Venice, 1978, Springer Verlag, pp. 211-236.
Also in Software Specification Techniques edited by N. Gehani & A.D. McGettrick, AT&T
Bell Telephone Laboratories, 1985, pp. 111-130 (QA 76.6 S6437).
Reprinted as Chapter 1 in item .
[2] Britton, K.H., Parker, R.A., Parnas, D.L., “A Procedure for Designing Abstract Interfaces for
Device Interface Modules”, Proceedings of the 5th International Conference on Software
Engineering, 1981.
[3] Dahl, Ol.-J., Nygaard, K., “SIMULA - An Algol-based Simulation Language”,
Communications of the ACM, vol. 9, no. 9, pp. 671-678, 1966.
[4] Dahl, O-J., et al., “The Simula 67 Common Base Language”, 1970, Norwegian Computing
Centre, publication S22.
[5] Dijkstra, E.W., “The Structure of the THE Multiprogramming System”, Communications of
the ACM, vol. 11, no. 5, May 1968.
[6] Goldberg, A., “Smalltalk-80: The Interactive Programming Environment”, Addison-
Wesley, 1984.
[7] Hoffman, D.M., Weiss, D.M. (eds.), “Software Fundamentals: Collected Papers by David L.
Parnas”, Addison-Wesley, 2001, ISBN 0-201-70369-6.
[8] Parnas, D.L., “Information Distributions Aspects of Design Methodology”, Proceedings of
IFIP Congress ‘71, 1971, Booklet TA-3, pp. 26-30.
[9] Parnas, D.L., “A Technique for Software Module Specification with Examples”,
Communications of the ACM, vol. 15, no. 5, pp. 330-336, 1972;
Republished in Yourdon, E.N. (ed.), Writings of the Revolution, Yourdon Press, 1982,
pp. 5-18:
in Gehani, N., McGettrick, A.D. (eds.), Software Specification Techniques, AT&T Bell
Telephone Laboratories (QA 76.7 S6437), 1985, pp. 75-88 .
[10] Parnas, D.L., “On the Criteria to be Used in Decomposing Systems into Modules”,
Communications of the ACM, vol. 15, no. 12, pp. 1053-1058, 1972;.
Republished in Laplante P. (ed.), Great Papers in Computer Science, West Publishing Co,
Minneapolis/St. Paul, 1996, pp. 433-441.
Translated into Japanese - BIT, vol. 14, no. 3, pp. 54-60, 1982.
Republished in Yourdon, E.N. (ed.), Classics in Software Engineering, Yourdon Press, 1979,
pp. 141-150.
Reprinted as Chapter 7 in item [7].
[11] Parnas, D.L., “A Course on Software Engineering Techniques”, in Proceedings of the ACM
SIGCSE, Second Technical Symposium, 24-25 March 1972, pp. 1-6.
[12] Parnas, D.L., “Some Conclusions from an Experiment in Software Engineering Techniques”,
Proceedings of the 1972 FJCC, 41, Part I, pp. 325-330.
[13] Parnas, D.L., “On a ‘Buzzword’: Hierarchical Structure”, IFIP Congress ‘74, North-Holland,
1974, pp. 336-339.
Reprinted as Chapter 8 in item [7].
[14] Parnas, D.L., “Use of Abstract Interfaces in the Development of Software for Embedded
Computer Systems”, NRL Report No. 8047, June 1977;
Reprinted in Infotech State of the Art Report, Structured System Development, Infotech
International, 1979.
[15] Parnas D.L., “Designing Software for Ease of Extension and Contraction”, IEEE
Transactions on Software Engineering, Vol. SE-5 No. 2, pp. 128-138, March 1979;
In Proceedings of the Third International Conference on Software Engineering, May 1978,
pp. 264-277.
[16] Parnas, D.L., Clements, P.C., Weiss, D.M., “The Modular Structure of Complex Systems”,
IEEE Transactions on Software Engineering, Vol. SE-11 No. 3, pp. 259-266, 1985;
In Proceedings of 7th International Conference on Software Engineering, March 1984,
408-417;
Reprinted in Peterson, G.E. (ed.), IEEE Tutorial: “Object-Oriented Computing”, Vol. 2:
Implementations, IEEE Computer Society Press, IEEE Catalog Number EH0264-2,
ISBN 0-8186-4822-8, 1987, pp. 162-169;
Reprinted as Chapter 16 in item [7].
[17] Parker, R.A., Heninger, K.L., Parnas, D.L., Shore, J.E., “Abstract Interface Specifications for
the A-7E Device Interface Modules”, NRL Report 4385, November 1980.
[18] Parnas D.L., Wang, Y., “Simulating the Behaviour of Software Modules by Trace Rewriting
Systems”, IEEE Transactions of Software Engineering, Vol. 19, No. 10, pp. 750 - 759, 1994.
[19] Roubine, O., Robinson, L., “Special Reference Manual” Technical Report CSL-45, Computer
Science Laboratory, Stanford Research Institute, August 1976.
[20] Robinson, L., Levitt K.N., Neumann P.G., Saxena, A.R., “A Formal Methodology for the
Design of Operating System Software”, in Yeh, R. (ed.), Current Trends in Programming
Methodology I, Prentice-Hall, 1977, pp. 61-110.
[21] Robinson, L., Levitt K.N., “Proof Techniques for Hierarchically Structured Programs”,
Communications of the ACM, Vol. 20, No. 4, pp. 271-283, 1977.
[22] Robinson, L., Levitt K.N., Silverberg, B.A.,“The (HDM) Handbook”, Computer Science
Laboratory, SRI International, June 1979.
