Udostępnij za pośrednictwem

El mito del software orientado a objetos

  • Artykuł

La complejidad para el diseño de software a gran escala implica echar mano de la ayuda disponible y de técnicas modernas para administrar dicha complejidad. Una de dichas técnicas es el estilo de diseño orientado a objetos lo cual es el tema de múltiples enfoques sistemáticos para el desarrollo de software históricamente llamados métodos de análisis y diseño orientado a objetos, e.g., Booch, OPEN, SOMA, Shlaer & Mellor, OMT, OOSE/Objectory, Catalysis, Fusion, Syntropy, etc. Una característica importante de estos métodos es que su definición consiste en tres elementos sine qua non:

  • Notación

  • Proceso

  • Herramientas

El ejercicio de dichos métodos de diseño ha derivado hoy en día, entre otras cosas, en algunos de los fundamentos de la intención detrás del concepto y de la práctica de la arquitectura en software. La evolución de dichos métodos de diseño históricamente fue dejada en manos de casas comerciales y por lo tanto dicha evolución obedeció a intereses financieros, mismos que no necesariamente establecieron alta prioridad al avance y consolidación del desarrollo de software como una profesión basada en conocimiento confiable. Al mismo tiempo es natural concluir que una casa comercial no tiene porque tomar en sus manos dicha responsabilidad. Creo que un aspecto tan sensible como la educación está ultimadamente en las manos del individuo.

La utilización del software en una creciente cantidad de áreas de la sociedad moderna probablemente nos llevará a replantear el contenido y perfil de la educación de quienes diseñan dicho software. Por ahora, y tristemente, con frecuencia encuentro personal que le pagan por diseñar software cuya educación está casi en su totalidad basada en información de mercadotecnia y no basada en los fundamentos de la computación electrónica digital ni en el rigor matemático de una disciplina de ingeniería —en la cual supuestamente aspira convertirse esta actividad.

Un aspecto normal en la comunicación humana cabe notar en este punto ya que con lo arriba mencionado han estado de acuerdo un gran número de personas, sin embargo, al elaborar más detalladamente las implicaciones dichas personas se transforman en rotundos antagonistas. Una de las razones detrás del desacuerdo es —por un lado— el énfasis desproporcionado que unos hacen en la importancia del proceso o procesos dentro de una organización por encima del pensamiento individual y —por el otro lado— el énfasis que hacen otros en medir el progreso con base en una creciente capacidad funcional del software que sea demostrable periódicamente a clientes y usuarios. Los primeros favorecen una típica organización de comando y control estrictamente jerárquico mientras que los segundos favorecen la auto-administración y el control empírico de procesos.

Los clientes y usuarios de software hoy en día pueden estar en manos de proveedores quienes sólo quieren el contenido de su billetera o también puede ser el caso que estén en manos de quienes están interesados en ejercer una profesión honorable y servir a sus clientes y usuarios entregándoles software que puedan respaldar dando la cara cuando así sea necesario.

Un afamado autor y practicante de los métodos sistemáticos de análisis y diseño mencionados al inicio estaba recientemente en una plática de sobremesa y se le pregunto: “¿Cuál es el siguiente paso para la industria de diseño de software?” A lo cual respondió: “Pues todavía hace falta que la industria realmente entienda orientación a objetos en primer lugar, para luego pensar en qué sigue”.

Una situación que avala dicha respuesta es la recurrente frecuencia en la que se pueden encontrar diseños supuestamente orientados a objetos en los cuales se observa un uso inadecuado del concepto de identidad (¿Qué define a un objeto? Estado, conducta e identidad ¿Recuerdas?). Siendo la identidad un concepto clave para un buen diseño orientado a objetos pues se puede entender la respuesta del autor mencionado.

Una excelente explicación de identidad se puede encontrar en la siguiente publicación electrónica por Francisco Javier Baños: Guías, principios y técnicas para escribir aplicaciones escalables con Microsoft .NET

Comments