Software DesignMarco A. DorantesCon respecto al diseño de software, que es el aspecto más fascinante para mí de lo que hacemos como programadores profesionales, permíteme comentarte mis impresiones y conclusiones actuales acerca de la esencia de esta actividad, por supuesto estas conclusiones están sesgadas por mi enturbiado entendimiento, pero el practicar y estudiar la experiencia de algunas luminarias en nuestro campo hace que dichas conclusiones tengan sentido para mi. I. El resultado de la actividad 'diseño' El resultado material de la actividad de diseño debe ser algo ejecutable, cualquier cosa menos que eso, es pura estimulación mental. II. Arquitectura de software Todos los aspectos, de alto y bajo nivel de nuestro diseño están expresados, implícita ó explícitamente, en la arquitectura del software. Aunque todavía es un término difuso, pero la exposición más adecuada de arquitectura de software es la de Phillip Kruchten "The 4+1 View Model of Architecture" The 4+1 View Model of Architecture http://www.computer.org/software/so1995/s6042abs.htm IEEE Software November 1995 (Vol. 12, No. 6) http://www.rational.com/media/whitepapers/Pbk4p1.pdf En resumen, la arquitectura de software considera 5 vistas, agrupadas por su naturaleza en:
III. El código fuente es el diseño detallado del software El diseño de alto nivel puede consistir de diagramas que expresen aspectos de las diferentes vistas de Kruchten, pero el diseño detallado es el código fuente, punto. En software, nuestros planos detallados es un documento técnico llamado comúnmente código fuente, dichos planos de nuestro producto son entregamos al constructor del producto: el compilador o traductor a código ejecutable. Phillip Kruchten, Jack W. Reeves y otros tienen algunas ideas al respecto: What is Software Design? by Jack W. Reeves http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm The Nature of Software: What's so Special About Software Engineering? by Philippe Kruchten http://www.therationaledge.com/content/oct_01/toc.html From Craft to Science: Searching for First Principles of Software Development by Koni Buhrer http://www.therationaledge.com/content/dec_00/f_craftscience.html IV. Decidir es diseñar Diseñar requiere decidir constantemente, diseñar es decidir. Decidir sobre los aspectos del diseño detallado, decidir sobre los aspectos de diseño de alto nivel, e incluso decidir que no vamos a decidir nada todavía sobre alguna propiedad particular del software, es decir, vamos a diferir dicha decisión. Martin Fowler habla acerca del diseño en: Is Design Dead? http://martinfowler.com/articles/designDead.html What's a Model For? http://martinfowler.com/articles/purpose.pdf V. Diseño estable y emergente Diseñar requiere atender a los principios que gobiernan y sustentan la arquitectura de software, como dice Bertrand Meyer, los aspectos a gran escala de la arquitectura de software, se encomiendan o están sustentados en los aspectos de bajo nivel o escala detallada (código fuente). Si estos aspectos no obedecen a principios coherentes y de estilo, difícilmente se logran los aspectos a gran escala. Existe un cuerpo de conocimiento importante acerca de diseño orientado a objetos, con reglas que representan esos principios coherentes y de estilo: Principles Of Object Oriented Design http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign Las recomendaciones del maestro Stroustrup agregan perspectivas importantes: Bjarne Stroustrup's C++ Style and Technique FAQ http://www.research.att.com/~bs/bs_faq2.html Las prácticas básicas son esenciales, Steve McConnell, ex-programador de MS tiene buen material al respecto: Code Complete: A Practical Handbook of Software Construction http://www.stevemcconnell.com/cc.htm Rapid Development: Taming Wild Software Schedules http://www.stevemcconnell.com/rd.htm La técnica de factorización representa una excelente forma para mantener un diseño estable y flexible: Refactoring VI. Control empírico del proceso de diseño Un método de diseño es intrínsecamente iterativo e incremental, se adhiere a un proceso 'gestalt', es decir, no puedes terminar de diseñar software si primero no lo programas, y al mismo tiempo no puedes programar software si primero no lo diseñas. Existen métodos sistemáticos de diseño y programación, Martin Fowler habla acerca de algunos métodos actuales: The New Methodology http://martinfowler.com/articles/newMethodology.html Continuous Integration (no daily build) http://martinfowler.com/articles/continuousIntegration.html VII. Método sistemático de diseño Un método sistemático de programación consiste de al menos tres partes:
En general, el material en este sitio provee buen material para el diseño y desarrollo de software: http://www.objectmentor.com/resources/articles Los mejores métodos sistemáticos de diseño y programación actuales se derivan del trabajo de las siguientes luminarias: Profesor Edsger Wybe Dijkstra http://www.cs.utexas.edu/users/EWD/ Kristen Nygaard http://www.ifi.uio.no/~kristen/ Ole-Johan Dahl http://www.ifi.uio.no/%7Eolejohan/ Alan Turing http://www.turing.org.uk/turing/ Niklaus Wirth http://www.cs.inf.ethz.ch/~wirth/ Donald E. Knuth http://www-cs-faculty.stanford.edu/~knuth/ Bjarne Stroustrup http://www.research.att.com/~bs/homepage.html Barbara Liskov http://www.objectmentor.com/resources/articles/lsp.pdf David Lorge Parnas http://www.crl.mcmaster.ca/SERG/parnas.homepg Tom DeMarco http://www.atlsysguild.com/GuildSite/TDM/Tom_DeMarco.html Gerald M. Weinberg http://www.geraldmweinberg.com/books.html Larry Constantine Edward Yourdon http://www.yourdon.com/index.htm Meilir Page-Jones http://www.technologytransfer.it/it/speakers/meilir_page_jones.asp Grady Booch, James Rumbaugh, Ivar Jacobson Bertrand Meyer VIII. Dimensiones en desarrollo de software Los factores para la calidad del diseño y desarrollo de software se pueden agrupar en cuatro dimensiones:
IX. Pensamiento sistémico Patrones y la teoría general de sistemas para el futuro (que ya paso) - existe material importante y un cuerpo de conocimiento fundamental que, sin importar lo que digan los de mercadotecnia, es indispensable dominar para ser relevante en desarrollo de software ahora y siempre, se trata de los patrones o mecanismos análogos de la teoría general de sistemas. Comúnmente se escucha de patrones de diseño, sin embargo, esos pertenecen a una categoría, pero los hay por todos lados, patrones de proceso, patrones organizacionales, patrones arquitectónicos, patrones de implementación (idioms), patrones de análisis; esto equivale a lo que la teoría general de sistemas estudia como situaciones análogas en relación a los procesos de pensamiento en los seres humanos. Las herramientas de pensamiento para diseño moderno de software están disponibles y serán las bases para el software que estaremos usando en el cual se utilizan múltiples paradigmas para su diseño. Algunas referencias al respecto:
"Este no es el final, ni siquiera es el comienzo del final; tal vez, tan solo es el final del comienzo" -Winston Churchill |
