Beneficios del modelo de objetos
Como se ha mostrado, el modelo de objetos es fundamentalmente diferente de los modelos adoptados por los métodos más tradicionales de análisis estructurado, diseño estructurado y programación estructurada. Esto no significa que el modelo de objetos abandone todos los sanos principios y experiencias de métodos más viejos. En lugar de eso, introduce varios elementos novedosos que se basan en estos modelos anteriores. Así, el modelo de objetos proporciona una serie de beneficios significativos que otros modelos simplemente no ofre- cen. Aún más importante, el uso del modelo de objetos conduce a la construcción de siste- mas que incluyen los cinco atributos de los sistemas complejos bien estructurados. Según nuestra experiencia, existen otros cinco beneficios prácticos que se derivan de la aplicación del modelo de objetos.
En primer lugar, el uso del modelo de objetos ayuda a explotar la potencia expresiva de los lenguajes de programación basados en objetos y orientados a objetos. Como apunta Stroustrup, “No siempre está claro cómo aprovechar mejor un lenguaje como C++. Se han logrado mejoras significativas de forma consistente en la productividad y la calidad del código utilizando C++ como un ‘C mejorado’ con una pizca de abstracción de datos añadida donde era claramente útil. Sin embargo, se han obtenido mejoras distintas y apreciablemente mayores aprovechando las je- rarquías de clases en el proceso de diseño. Esto se llama muchas veces diseño orientado a objetos, y aquí es donde se han encontrado los mayores beneficios del uso de C++” [81]. Nuestra expe- riencia indica que, sin la aplicación de los elementos del modelo de objetos, las características más potentes de lenguajes como Smalltalk, Object Pascal, C++, CLOS y Ada, o bien se ignoran o bien se utilizan desastrosamente.
Por otra parte, el uso del modelo de objetos promueve la reutilización no solo de software, sino de diseños enteros, conduciendo a la creación de marcos de desarrollo de aplicaciones reu- tilizables [82]. Se ha encontrado que los sistemas orientados a objetos son frecuentemente más pequeños que sus implantaciones equivalentes no orientadas a objetos. Esto no solo significa es- cribir y mantener menos código, sino que la mayor reutilización del software también se traduce en beneficios de costo y planificación.
Tercero, el uso del modelo de objetos produce sistemas que se construyen sobre formas interme- dias estables, que son más flexibles al cambio. Esto también significa que se puede admitir que tales sistemas evolucionen en el tiempo, en lugar de ser abandonados o completamente rediseña- dos en cuanto se produzca el primer cambio importante en los requerimientos.
El modelo de objetos reduce los riesgos inherentes al desarrollo de sistemas complejos, más que nada porque la integración se distribuye a lo largo del ciclo vital en vez de suceder como un evento principal. La guía que proporciona el modelo de objetos, al diseñar una separación inteligente de intereses también reduce los riesgos del desarrollo e incrementa la confianza en la corrección del diseño.
Orient a ción a O bje tO s. t eO ría y pr á c tic a
Finalmente, el modelo de objetos resulta atractivo para el funcionamiento de la cognición hu- mana, porque, como sugiere Robson, “muchas personas que no tienen ni idea de cómo funciona un computador encuentran bastante natural la idea de los sistemas orientados a objetos” [83].
Aplicaciones del modelo de objetos
El modelo de objetos ha demostrado ser aplicable a una amplia variedad de dominios de proble- ma. La figura 2.6 enumera muchos de los dominios para los que existen sistemas que perfecta- mente pueden denominarse orientados a objetos. La bibliografía proporciona una lista extensa de referencias a estas y otras aplicaciones.
Puede que el diseño orientado a objetos sea el único método entre los disponibles hoy en día que puede emplearse para atacar la complejidad innata a muchos sistemas grandes. Siendo justos, sin embargo, el uso de diseño orientado a objetos puede no ser aconsejable en algunos dominios, no por razones técnicas, sino por razones no técnicas, como la falta de personal con entrenamiento adecuado o buenos entornos de desarrollo.
Figura 2.6. Aplicaciones del modelo de objetos. aeronáutica
análisis matemático animación
automatización de oficinas bases de datos
componentes de software reutilizables composición de música
control de procesos químicos control de tráfico aéreo Diseño asistido por computador Diseño de interfaces de usuario Diseño VLsi
electrónica médica
enseñanza asistida por ordenador entornos de desarrollo de software estrategias de inversión
Fabricación integrada por computador Hipermedia
ingeniería petroquímica preparación de documentos preparación de películas y escenarios proceso de datos de negocios reconocimiento de imágenes robótica
simulación de cohetes y aviones sistemas de dirección y control sistemas de telemetría sistemas expertos sistemas operativos software de banca y seguros software de estaciones espaciales telecomunicaciones
Problemas planteados
Para aplicar con efectividad los elementos del modelo de objetos, es necesario resolver varios problemas:
❚
❚ ¿Qué son exactamente las clases y los objetos? ❚
❚ ¿Cómo se identifica correctamente las clases y objetos relevantes de una aplicación concreta? ❚
❚ ¿Cómo sería una notación adecuada para expresar el diseño de un sistema orientado a objetos? ❚
❚ ¿Qué proceso puede conducir a un sistema orientado a objetos bien estructurado? ❚
❚ ¿Cuáles son las implicaciones en cuanto a gestión que se derivan del uso de diseño orien- tado a objetos?
Resumen
❚
❚ La madurez de la ingeniería del software ha conducido al desarrollo de métodos de aná- lisis, diseño y programación orientados a objetos, todos los cuales tienen la misión de resolver los problemas de la programación a gran escala.
❚
❚ Existen varios paradigmas de programación distintos: orientados a procedimientos, orien- tados a objetos, orientados a lógica, orientados a reglas y orientados a restricciones. ❚
❚ Una abstracción denota las características esenciales de un objeto que lo distinguen de todos los demás tipos de objeto y proporciona así fronteras conceptuales definidas con nitidez desde la perspectiva del observador.
❚
❚ El encapsulamiento es el proceso de compartimentar los elementos de una abstracción que constituyen su estructura y comportamiento. Sirve para separar la interfaz “ contractual” de una abstracción y su implantación.
❚
❚ La modularidad es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y débilmente acoplados.
❚
❚ La jerarquía es una graduación u ordenación de abstracciones. ❚
❚ Los tipos son el resultado de imponer la clase de los objetos, de forma que los objetos de tipos diferentes no pueden intercambiarse o, como mucho, pueden hacerlo de formas muy restringidas.
❚
❚ La concurrencia es la propiedad que distingue un objeto activo de uno que no está activo. ❚
❚ La persistencia es la propiedad de un objeto mediante la cual su existencia perdura en el tiempo y/o el espacio.
Lecturas recomendadas
El concepto del modelo de objetos fue introducido en primer lugar por Jones [F 1979] y Williams [F 1986]. La Tesis Doctoral de Kay [F 1969] estableció la dirección para gran parte del trabajo subsiguiente en programación orientada a objetos.
Orient a ción a O bje tO s. t eO ría y pr á c tic
a Shaw [J 1984] ofrece un excelente resumen acerca de los mecanismos de abstracción en
lenguajes de programación de alto nivel. El fundamento teórico de la abstracción puede encon- trarse en el trabajo de Liskov y Guttag [H 1986], Guttag [J 1980] y Hilfinger [J 1982]. Parnas [F 1979] es el trabajo seminal sobre la ocultación de información. El significado e importancia de la jerarquía se discute en el trabajo editado por Pattee [J 1973].
Existe gran cantidad de literatura sobre programación orientada a objetos. Cardelli y Wegner [J 1985] y Wegner [J 1987] ofrecen un excelente estudio de los lenguajes de programación ba- sados en objetos y orientados a objetos. Los artículos tutoriales de Stefik y Bobrow [G 1986], Stroustrup [G 1988], Nygaard [G 1986] y Grogono [G 1991] son buenos puntos de partida sobre los problemas importantes de la programación orientada a objetos. Los libros de Cox [G 1986], Meyer [F 1988], Schmucker [G 1986] y Kim y Lochovsky [F 1989] ofrecen un extenso tratamiento de estos temas.
Los métodos de diseño orientados a objetos fueron introducidos por Booch [F 1981, 1982, 1986, 1987, 1989]. Los métodos de análisis orientado a objetos fueron introducidos por Shlaer y Mellor [B 1988] y Bailin [B 1988]. Desde entonces, se han propuesto varios métodos de aná- lisis y diseño orientados a objetos, destacando Rumbaugh [F 1991], Coad y Yourdon [B 1991], Constantine [F 1989], Shlaer y Mellor [B 1992], Martin y Odell [B 1992], Wasserman [B 1991], Jacobson [F 1992], Rubin y Goldberg [B 1992], Embly [B 1992], Wirfs-Brock [F 1990], Goldstein y Alger [C 1992]. Henderson-Sellers [F 1992], Firesmith [F 1992] y Fusion [F 1992].
Pueden encontrarse casos de estudio de aplicaciones orientadas a objetos en Taylor [H 1990, C 1992], Berard [H 1993], Love [C 1993] y Pinson y Weiner [C 1990].
Puede encontrarse una excelente colección de artículos que tratan todos los aspectos de la tecnología orientada a objetos en Peterson [G 1987], Schriver y Wegner [G 1987] y Khoshafian y Abnous [G 1990]. Las actas de varias conferencias anuales sobre tecnología orientada a obje- tos son también excelentes fuentes de material. Algunos de los foros más importantes incluyen OOPSLA, ECOOP, TOOLS, Object World y Object Expo.
Entre las organizaciones responsables de establecer estándares para la tecnología orientada a objetos se incluyen Object Management Group y el comité ANSI X3J7.
La referencia principal para C++ es Ellis y Stroustrup [G 1990]. Otras referencias útiles in- cluyen a Stroustrup [G 1991], Lippman [G 1991] y Coplien [G 1992].
Notas bibliográficas
[1] Rentsch, T. September 1982. Object-Oriented Programming. SIGPLAN Notices vol. 17(12), p. 51. [2] Wegner, P. June 1981. The Ada Programming Language and Environment. Unpublished draft. [3] Abbott, R. August 1987. Knowledge Abstraction. Communications of the ACM vol. 30(8), p. 664. [4] Ibid., p. 664.
[5] Shankar, K. 1984. Data design: Types, Structures, and Abstractions. Handbook of Software
[6] Macintosh MacApp 1.1.1 Programmer’s Reference. 1986. Cupertino, CA: Apple Computer, p. 2. [7] Bhaskar, K. October 1983. How Object-Oriented Is Your System? SIGPLAN Notices vol. 18(10), p. 8. [8] Stefik, M. and Bobrow, D. Winter 1986. Object-Oriented Programming: Themes and
Variations, AI Magazine vol. 6(4), p. 41.
[9] Jones, A. 1979. The Object Model: A Conceptual Tool for Structuring Software. Operating
Systems. New York, NY: Springer-Verlag, p. 8.
[10] Yonezawa, A. and Tokoro, M. 1987. Object-Oriented Concurrent Programming: An Introduction, in Object-Oriented Concurrent Programming. Cambridge, MA: The MIT Press, p. 2.
[11] Levy, H. 1984. Capability-Based Computer Systems. Bedford, MA: Digital Press, p. 13.
[12] Ramamoorthy, C. and Sheu, P. Fall 1988. Object-Oriented Systems. IEEE Expert vol. 3(3), p. 14. [13] Myers, G. 1982. Advances in Computer Architecture. Second Edition. New York, NY: John Wiley
and Sons, p. 58.
[14] Levy. Capability-Based Computer.
[15] Kavi, K. and Chen, D. 1987. Architectural Support for Object-Oriented Languages. Proceedings
of the Thirty-second IEEE Computer Society International Conference. IEEE.
[16] iAPX 432 Object Primer. 1981. Santa Clara, CA: Intel Corporation.
[17] Dally, W. J. and Kajiya, J. T. March 1985. An Object-Oriented Architecture. SIGARCH
Newsletter vol. 13(3).
[18] Dahlby, S., Henry, G., Reynolds, D., and Taylor, P. 1982. The IBM System/38: A High Level Machine, in Computer Structures: Principles and Examples. New York, NY: McGraw-Hill. [19] Dijkstra, E. May 1968. The Structure of the “THE“ Multiprogramming System.
Communications of the ACM vol. 11(5).
[20] Parnas, D. 1979. On the Criteria to Be Used in Decomposing Systems into Modules, in Classics
in Software Engineering. New York, NY: Yourdon Press.
[21] Liskov, B. and Zilles, S. 1977. An Introduction to Formal Specifications of Data Abstractions.
Current Trends in Programming Methodology: Software Specification and Design vol. 1. Englewood
Cliffs, NH: Prentice-Hall.
[22] Guttag, J. 1980. Abstract Data Types and the Development of Data Structures, in Programming
Language Design, New York, NY: Computer Society Press.
[23] Shaw. Abstraction Techniques.
[24] Nygaard, K. and Dahl, O-J. 1981. The Development of the Simula Languages, in History of
Programming Languages. New York, NY: Academic Press, p. 460.
[25] Atkinson, M. and Buneman, P. June 1987. Types and Persistence in Database Programming Languages. ACM Computing Surveys vol. 19(2), p. 105.
[26] Rumbaugh, J. April 1988. Relational Database Design Using an Object-Oriented Methodology.
Communications of the ACM vol. 31(4), p. 415.
[27] Chen. P. March 1976. The Entity-Relationship Model-Toward a Unified View of Data. ACM
Transactions on Database Systems vol. 1(1).
[28] Barr, A. and Feigenbaum, E. 1981. The Handbook of Artificial Intelligence. Vol. 1. Los Altos, CA: William Kaufmann, p. 216.
Orient a ción a O bje tO s. t eO ría y pr á c tic
a [29] Stillings, N., Feinstein, M., Garfield, J. Rissland, E., Rosenbaum, D., Weisler, S., Baker-Ward, L. 1987. Cognitive Science: An Introduction. Cambridge, MA: The MIT Press, p. 305.
[30] Rand, Ayn. 1979. Introduction to Objectivist Epistemology. New York, NY: New American Library. [31] Minsky, M. 1986. The Society of Mind. New York, NY: Simon and Schuster.
[32] Stroustrup, B. May 1988. What Is Object-Oriented programming? IEEE Software vol. 5(3), p. 10. [33] Cardelli, L. and Wegner, P. On Understanding Types, Data Abstraction, and Polymorphism.
December 1985. ACM Computing Surveys vol. 17(4), p. 481.
[34] DeMarco, T. 1979. Structured Analysis and System Specification. Englewood Cliffs, NJ: Prentice-Hall.
[35] Yourdon, E. 1989. Modern Structured Analysis. Englewood Cliffs, NJ: Prentice-Hall. [36] Gane, C. and Sarson, T. 1979. Structured Systems Analysis. Englewood Cliffs, NJ:
Prentice-Hall.
[37] Ward. P. and Mellor, S. 1985. Structured Development for Real-Time Systems. Englewood Cliffs, NJ: Yourdon Press.
[38] Hatley, D. and Pirbhai, I. 1988. Strategies for Real-Time System Specification. New York, NY: Dorset House.
[39] Jenkins, M. and Glasgow, J. January 1986. Programming Styles in Nial. IEEE Software vol. 3(1), p. 48.
[40] Bobrow, D. and Stefik, M. February 1986. Perspectives on Artificial Intelligence Programming.
Science vol. 231, p. 951.
[41] Dahl, O., Dijkstra, E., and Hoare, C. A. R. 1972. Structured Programming. London, England: Academic Press, p. 83.
[42] Shaw. M. October 1984. Abstraction Techniques in Modern Programming Languages. IEEE
Software vol. 1(4), p. 10.
[43] Berzins, V., Gray, M., and Naumann, D. May 1986. Abstraction-Based Software Development.
Communications of the ACM vol. 29(5), p. 403.
[44] Abelson, H. and Sussman, G. 1985. Structure and Interpretation of Computer Programs. Cambridge, MA: The MIT Press, p. 126.
[45] Ibid., p. 132.
[46] Seidewitz, E. and Stark, M. 1986. Towards a General Object-Oriented Software Development Methodology. Proceedings of the First International Conference on Ada Programming Language
Applications for the NASA Space Station. NASA Lyndon B. Johnson Space Center, TX: NASA,
p. D.4.6.4.
[47] Meyer, B. 1988. Object-Oriented Software Construction. New York, NY: Prentice Hall. [48] Wirfs-Brock, R. and Wilkerson, B. October 1989. Object-Oriented Design: A Responsability-
Driven Approach. SIGPLAN Notices vol. 24(10).
[49] Ingalls, D. The Smalltalk-76 Programming System Design and Implementation. Proceedings of
the Fifth Annual ACM Symposium on Principles of Programming Languages. ACM, p. 9.
[50] Gannon, J., Hamlet, R., and Mills, H. July 1987. Theory of Modules. IEEE Transactions on
[51] Date, C. 1986. Relational Database: Selected Writings. Reading, MA: Addison-Wesley, p. 180. [52] Liskov, B. May 1988. Data Abstraction and Hierarchy. SIGPLAN Notices vol. 23(5), p. 19. [53] Britton, K. and Parnas, D. December 8, 1981. A-7E Software Module Guide. Washington, D.C.
Naval Research Laboratory, Report 4702, p. 24. [54] Gabriel, R. 1990. Private communication. [55] Stroustrup, B. 1988. Private communication.
[56] Myers, G. 1978. Composite/Structured Design. New York, NY: Van Nostrand Reinhold, p. 21. [57] Liskov, B. 1980. A Design Methodology for Reliable Software Systems, in Tutorial on Software
Design Techniques. Third Edition. New York, NY: IEEE Computer society, p. 66.
[58] Zelkowitz, M. June 1978. Perspectives on Software Engineering. ACM Computing Surveys vol. 10(2), p. 20.
[59] Parnas, D., Clements, P., and Weiss, D. March 1985. The Modular Structure of Complex Systems. IEEE Transactions on Software Engineering vol. SE-11(3), p. 260.
[60] Britton and Parnas. A-7E Software, p. 2.
[61] Parnas, D., Clements, P., and Weiss, D. 1983. Enhancing Reusability with Information Hiding.
Proceedings of the Workshop on Reusability in Programming, Stratford, CT: ITT Programming, p.
241.
[62] Meyer, Object-Oriented Software Construction, p. 47. [63] Cox, B. 1986. Object-Oriented Software Construction, p. 47.
[64] Danforth, S. and Tomlinson, C. March 1988. Type Theories and Object-Oriented Programming. ACM Computing Surveys vol. 20(1), p. 34.
[65] Liskov. 1988, p. 23.
[66] As quoted in Liskov. 1980, p. 67.
[67] Zilles, S. 1984. Types, Algebras, and Modeling, in On Conceptual Modeling: Perspectives from Artificial
Intelligence, Databases, and Programming Languages. New York, NY: Springer-Verlag, p. 442.
[68] Wegner, P. October 1987. Dimensions of Object-Based Language Design. SIGPLAN Notices vol. 22(12), p. 171.
[69] Borning, A. and Ingalls, D. 1982. A Type Declaration and Inference System for Smalltalk. Palo Alto, CA: Xerox Palo Alto Research Center, p. 134.
[70] Stroustrup, B. 1992. Private communication.
[71] Tesler, L. August 1981. The Smalltalk Environment. Byte vol. 6(8), p. 142. [72] Borning and Ingalls. Type Declaration, p. 133.
[73] Thomas, D. March 1989. What’s in an Object? Byte vol. 14(3), p. 232.
[74] Lim, J. and Johnson, R. April 1989. The Heart of Object-Oriented Concurrent Programming.
SIGPLAN Notices vol. 24(4), p. 165.
[75] Ibid., p. 165.
[76] Black, A., Hutchinson, N., Jul, E., Levy, H., and Carter, L. July 1986. Distribution and Abstract
Types in Emerald. Report 86-02-04. Seattle, WA: University of Washington, p. 3.
[77] Proceedings of the ACM SIGPLAN Workshop on Object-Based Concurrent Programming. April 1989. SIGPLAN Notices vol. 24(4), p. 1.
Orient a ción a O bje tO s. t eO ría y pr á c tic
a [78] Atkinson, M., Bailey, P., Chisholm, K., Cockshott, P., and Morrison, R. 1983. An Approach to Persistent Programming. The Computer Journal vol. 26(4), p. 360.
[79] Khoshafian, S. and Copeland, G. November 1986. Object Identity. SIGPLAN Notices vol. 21(11), p. 409.
[80] Vbase Technical Overview. September 1987. Billerica, MA: Ontologic, p. 4.
[81] Stroustrup, B. November 1987. Possible Directions for C++. Proceedings of the USENIX C++
Workshop. Santa Fe, NM, p. 14.
[82] Meyer. Object-Oriented Software Construction, p. 30-31.