Talvez isto possa ajudar de alguma forma. Em portugu�s nada tenho. -----Mensagem original----- De: Cosmo <[EMAIL PROTECTED]> Para: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Data: Quinta-feira, 25 de Novembro de 1999 05:47 Assunto: OOP > Caro All > > Por acaso alguem sabe onde posso encontrar textos, de preferencia em >portugues, explicando os conceitosa, encapsulamento, heranca, polimorfismo e >classes, de Programacao Orientado a Objeto ?!?!!? > > >[]'s > >Cosmo >[EMAIL PROTECTED] >www.hackhour.com.br >Hack Hour Inc. > >* Para n�o receber mais e-mails desta lista envie um e-mail para [[EMAIL PROTECTED]] >e no corpo do email escreva [unsubscribe <seu-email>] >Veja as mensagens antigas em http://www.mail-archive.com/javabr%40cits.br/ >Title: Gestion de Proyectos Orientados-a-Objetos: Una Incursion Cruenta
Evoloop.docGESTION DE PROYECTOS
ORIENTADOS-A-OBJETOS:
UNA INCURSION CRUENTA.
por
INTRODUCCION
En este artículo se pretende mostrar, aun muy sucintamente, el estado actual de la tecnología de objetos respecto de su aplicación en proyectos reales de desarollo software. Es imposible, naturalmente, resumir y condensar en tan pocas páginas la nebulosa de la Tecnología de Objetos (OT), pero al menos se expondrán algunas consideraciones prácticas extraídas de la aplicación por el autor de lenguajes, técnicas y métodos orientados-a-objetos en proyectos reales desde 1.987.
EL SINDROME DE ESTOCOLMO
Es opinión antigua, firme y consensuada que "no existe una bala-de-plata" en relación con la OT (o sea, que la panacea software universal sigue estando en el terreno de la alquimia), pero también se acepta de forma unánime que la OT proporciona ventajas evidentes en el desarrollo genérico de software. Naturalmente lo más fácil es pensar que los "nuevos" métodos que la OT propugna no van a facilitar el trabajo diario "real" en empresas y departamentos de desarrollo de software, pero ocurre que los que accidental o incidentalmente caen en ellos pronto incuban lo que los no-convertidos denominan un OOSS (Object-Oriented Stockholm Syndrome) y que resulta en una persistente y malsana atracción por las nuevas técnicas. Los atractivos de los "objetos" aparecen innegables y, de acuerdo con Lorenz, las siguientes etapas personales se cubren de forma inexorable:
- Novicio (3-6 meses): se mixtifica el código eminentemente funcional modificándolo y añadiéndole porciones significadas en objetos.
- Aprendiz (3-6 meses): aquí se produce el "despertar" del que hablan los textos de Zen, se ve el verdadero significado de la orientación-a-objetos y se empiezan a bosquejar diseños pertinentes.
- Postulante (6-18 meses): los conceptos ya se aplican con soltura en el desarrollo, pero todavía se dan algunos problemas con la modelización.
- Experto (guru): todo son objetos, y el sujeto se pregunta: ¿cómo pude pensar antes de otra manera? Este estadio no siempre se alcanza, naturalmente (afortunadamente, según algunos).
Bien: todo esto, unido a la gran profusión de noticias sobre objetos en la prensa especializada, resulta muy emocionante y atractivo, pero en las empresas necesitan de métodos fiables, estables, bien documentados y a los que dé soporte un buen conjunto de soluciones software desarrolladas con ellos. Hay, pues, que examinar el estado de la OT para decidir. Pero aquí empiezan -o siguen- los problemas.
ANALISIS Y DISENO ORIENTADOS-A-OBJETOS
Si echamos una ojeada al actual panorama de análisis y diseño orientados-a-objetos nos encontraremos con pocas metodologías y muchos métodos, buena parte de los cuales observan un carácter básicamente "propietario", siendo muy pocos los que cubren el ciclo completo de vida del software. Aparecerá claro, a la vez, que existe un escaso interés, ajeno a las cuitas comerciales, en estandarizar los métodos: es más: cuando el OMG (Object Management Group), en un intento normalizador, requirió la colaboración de los autores de métodos de OOA/OOD, un nutrido e importante grupo de éstos replicó con una carta pública en la que afirmaban que tal estandarización no era en absoluto deseable. Parece que es ridículo pensar que existe un método orientado-a-objetos bueno-para-todo, como es risible afirmar que no existe ningún hombre absolutamente estúpido. Se aprecia, también, la difuminación del hasta ahora habitual gap semántico entre análisis y diseño: pero aun esto resulta turbador, pues la planificación práctica usualmente necesita de fases claras que permitan la evaluación de resultados y los pertinentes controles de integridad y estabilidad. Las grafías, por último, resultan sospechosamente parecidas entre sí, y oscilan entre la simplicidad sospechosa y la prolijidad culpable.
Tras todo lo anterior no dejen que el tono les intimide: la orientación-a-objetos -de la que el autor es firme defensor- realmente "funciona", y ya existe un importante acervo práctico de soluciones software basadas en análisis y diseños orientados-a-objetos. Pero también existe un nada despreciable anecdotario de fracasos y despropósitos. La realidad es que el camino de la productividad, como el del infierno, está fatalmente empedrado de ilusiones e intentos aventurados. Necesitamos alguna luz. Intentemos una revisión de los métodos comerciales.
METODOS COMERCIALES DE OOA/OOD
Es opinión extendida que en la arena de los métodos OOA/OOD existen dos corrientes principales, dividiendo a estos en:
- estáticos (enfocados-a-datos), en los que lo importante es la estructura de datos anexa a los objetos y las operaciones que sobre ella operan.
- dinámicos (enfocados-a-comportamientos o enfocados-a-responsabilidades): un objeto tiene sentido en estos métodos cuando exhibe un comportamiento diferencial respecto del resto de los objetos. Tal comportamiento puede referirse bien al objeto en sí (los cambios que pueden operarse en su representación interna) bien a sus relaciones con otros objetos.
Pero la verdad es que ésta es una diferencia puramente académica. Lo cierto es que la mayoría de los métodos viene desplazándose, afianzados en el borboteo comercial de las Bases de Objetos (OODBMSs), hacia esquemas puramente dinámicos. Y es que divisiones como la anterior pueden encontrarse con demasiada frecuencia en la literatura, cada vez más extensa, sobre el tema, fundamentalmente debido a la gran profusión de métodos con bases teóricas un tanto difusas. Y si no échenle un vistazo a algunos (imposible disponer de una lista actualizada de todos ellos) de los actuales métodos de OOA/OOD (intencionadamente desordenados, para no generar falsas esperanzas):
METODOS SIGLAS AUTORES ----------------------------------- ------ ---------------------------------- Object Oriented Design OOD Grady Booch Object Behaviour Analysis OBA Rubin & Goldberg Methodology for Object Oriented Software Engineering of Systems MOSES Henderson-Sellers & Edwards General Object Oriented Design GOOD Seidewitz & Stark Object Oriented Software Engineering OOSE Ivar Jacobson Visual Modeling Technique VMT IBM Texel Texel Object Modeling Technique OMT Rumbaugh y otros Better Object Notation BOM Nerson Object Oriented System Analysis OOSA Shlaer & Mellor Object Oriented Structured Design OOSD Wasserman et al. Systems Engineering OO SEOO LBMS Syntropy Cook y otros Object Oriented Jackson Structured Design OOJSD Jackson Hierarchical Object Oriented Design HOOD ESA Object Oriented Analysis OOA Coad & Yourdon Object Oriented Design OOD Coad & Yourdon Object Oriented System Analysis OSA Embley y otros Colbert E. Colbert Frame Object Analysis FOA Andleigh/Gretzingr Semantic Object Modelling Approach SOMA Ian Graham Berard Berard ADM3 Donald Firesmith Ptech OOA&D Martin & Odell Object Oriented Rôle Analysis, Synthesis and Structuring OORASS Reenskaug et al. Fusion Coleman y otros Desfray Softeam Responsability Driven Design CRC Wirfs-Brock et al.
Como el lector avisado fácilmente comprobará, en la anterior tabla se mezclan métodos de análisis y de diseño porque, pese a lo que anuncien sus autores o aun su mismo nombre, la distinción entre análisis y diseño se difumina, como antes comentábamos, de forma turbadora (aunque claramente deseable respecto de la modelización de la realidad).
SOBRE LISTAS Y COMPARACIONES
Naturalmente sería deseable disponer de una suerte de catálogo bien documentado en el que se explicitaran, compararan y evaluaran las claves exactas, bondades y flaquezas de cada método de OOA/OOD. Así los interesados simplemente sólo tendrían que dilucidar, tras una somera revisión del documento, el método que mejor se ajustase a las características del proyecto a desarrollar. Podría pensarse, también, que tales comparaciones ya existen (y de hecho así es: libros, artículos, juegos y productos software presumen de haber completado tal tarea). La realidad es, sin embargo, que mal pueden evaluarse y compararse métodos cuando no existen métricas orientadas-a-objetos, ni tan siquiera criterios claros e indiscutibles, para tal fin. Los mismos autores no se atreven a afirmar que sus métodos son "universales", aunque desafortunadamente tampoco establecen sus límites de aplicación. De esta manera resulta que la mayoría de papeles sobre el tema se suelen limitar a un resumen textual de ideas, donde se comparan las subjetivas quintaesencias de cada método. Resulta así, por fin, que tales revisiones son válidas sobre todo para aquellos lectores que conocen suficientemente los métodos estudiados. Pero ejemplifiquemos estas flaquezas:
Wirfs-Brock favorece las responsabilidades frente a los atributos, mientras que Rumbaugh (OMT) enfatiza la importancia de las asociaciones entre clases; Jacobson (Objectory) es el autor de los casos-de-uso (use-cases) y afirma que su metodología soporta el ciclo total de vida del software orientado-a-objetos; Booch, por otro lado, introduce la noción práctica de visibilidad en su método de OOD. Shlaer/Mellor (OOSA) modifican los DFDs en Action-DFDs y soportan una gradual descomposición de las acciones en el modelo-de-estados en procesos en el modelo-de-procesos. Embley, Kurtz y Woodfield (OSA) amplían y matizan OMT añadiendo el modelo-de-interacción-de-objetos (OIM). Coad/Yourdon aportan en su método unario (OOA/OOD) las plantillas de objetos y de descripción de métodos. Etc., etc., ... ad nauseam.
Como el lector fácilmente podrá apreciar, la legibilidad no es lo que aquí más importa: las anteriores frases tienen sentido sobre todo para el que ya tiene una opinión formada sobre los distintos métodos. La comprensibilidad sí se echa en falta: es fatalmente difícil asimilar opiniones como las anteriores sin conocer en suficiente detalle cada uno de los métodos tratados, y tanto más en cuanto que tales no representan unidades de comprensibilidad autónoma, pues cada uno refleja una particular visión, usualmente basada en la experiencia de sus autores en proyectos reales, del ciclo de desarrollo de software. ¿Y entonces? Pues que, aun a riesgo de parecer estúpidamente trivial, debo sostener que para aplicar un método de OOA/OOD (o un refrito de algunos de ellos) hay que conocerlos casi todos. Pero examinemos con más detenimiento esta -aparentemente- sorprendente conclusión.
CESAR O NADA
A poco que el lector bucee en los textos y artículos de análisis y diseño orientados-a-objetos se encontrará con afirmaciones tales como que los métodos de OOA/OOD se dividen en unarios y ternarios, o que los métodos de segunda generación pueden usar de uniones de métodos de primera generación, o simplemente que si un análisis contiene un solo DFD es que hay que rehacerlo (Coleman?!). Y es que no hay final donde no existen claros principios: si aun se discute la esencia ortodoxa de la orientación-a-objetos (si la persistencia es una característica, si la herencia es simplemente un mecanismo, bla-bla-bla), ¿cómo abundar en tantas clasificaciones y divisiones? Pero se mueve, como diría Galileo, pues lo cierto es que los sistemas orientados-a-objetos comercial y realmente funcionan. Debe ser posible, pues, extraer técnicas prácticas de los mismos, pues tales normalmente se basan directamente en las experiencias prácticas (que sí suelen funcionar) de sus autores. Pero ¿existe algo bueno en cada método que se pueda aislar y usar en un entorno separado? Absolutamente no, aunque quizás sí con cierta matización. Resulta que los objetos no están ahí para cogerlos (object-picking), sino que más bien el analista (OODA: Object-Oriented Domain Analyst) los crea en cada análisis, y de aquí que la pertinencia de que cada método o técnica deban ser específicamente evaluados en cada proyecto. Y precisamente para esto hay que conocer muchos de ellos, pues si no limitaríamos de forma peligrosa la arquitectura, y aun el resultado final, de nuestros proyectos. Pero tal no es exclamar, en un remedo barojiano, o "César o nada": se trata más bien de ponderar si la base metodológica del equipo de análisis y diseño es suficiente para abordar proyectos no-triviales, y dado que no existen todavía criterios inamovibles de evaluación metodológica en OOA/OOD, parece que habrá que dejar, en buena medida, la concrección de elementos básicos arquitectónicos en la construcción de software al buen criterio de tal equipo. Pero aquí surgen lógicas inquietudes: ¿es posible dedicarse al estudio de las corrientes OOA/OOD sin perder el rumbo del trabajo diario? ¿cómo se ajusta el anunciado eclecticismo, de connotaciones subjetivas, con la deseable normalización de la gestión de proyectos en las empresas de desarrollo? ¿cómo determinar la bondad práctica de los métodos basándose solamente en consideraciones teóricas? ¿no existe, al fin, un cierto rango de soluciones suficientemente probadas en análisis y diseño? Bien: vayamos a las respuestas.
LA SOLUCION ECLECTICA
La experiencia y la revisión real de la gestión de proyectos orientados-a-objetos en distintas empresas muestra que el exito siempre ha ido acompañado de una visión particularizada de OOA/OOD/OOP acorde con la política de la empresa, las pecularidades del equipo de desarrollo, la experiencia en determinados lenguajes de programación y la naturaleza concreta de cada proyecto, dentro de unos márgenes más o menos estables de actuación. Resulta así que, mayormente, es una cuestión de "afinidades electivas", como diría Goethe. La gran cuestión es, por supuesto, ¿quién elige? Y aquí sólo una respuesta: un experto, naturalmente.
Es moneda común que la resolución de proyectos exitosos, en tanto la empresa no adquiere una sólida cultura de objetos, se debe al consejo y mentorización -externa o interna- de expertos o "gurúes" (la barbarización de OGs: Object Gurus) que, merced a su experiencia en distintas empresas, pueden elegir con fundamento el enfoque idóneo para cada cometido software. Es labor de tales expertos asesorar sobre el equipo de desarrollo, arquitecturas, metodologías, generación de documentación, lenguajes de programación, gestión del proyecto mismo, herramientas de desarrollo, técnicas y herramientas de validación, etc.
Con todo, y para que el lector no se quede con una amarga sensación, sí puede explicitarse un cierto núcleo metódico: Las fichas CRC y el enfoque a responsabilidades facilitan mucho la labor en las primeras etapas del OOA/OOD (que básicamente trabajan sobre unas especificaciones obtenidas en la etapa del OORA, Object-Oriented Requeriment Analysis, pero esto es otra batalla); después una modelización tipo OMT ú OSA ayuda bastante, junto con aspectos de la metodología de Booch y la aplicación de casos-de-uso (use-cases) de Jacobson, e incluso diagramas de transición de estados y redes de Petri. Al final se obtienen fichas tanto de objetos como de sus relaciones, pero tales son, como casi todo, susceptibles de ser mecanizadas. Naturalmente si todo lo anterior se envuelve en un entorno visual (lisez VMT, de IBM), las cosas mejoran bastante. Si a este entorno añadimos capacidades de prototipación rápida y de documentación del diseño, entonces parece que tendríamos la herramienta adecuada, con lo que entramos en el resbaladizo terreno del CASE (OOCASE ahora).
HERRAMIENTAS OOCASE
Como una requeteconocida multinacional oficiosamente afirma: "Prescinde de herramientas OOCASE, pero si has de operar con una procura que sea la más barata". Lo cierto es que el mercado de tales herramientas está un tanto desquiciado: cuando parecía que estaban en franco decaimiento, la orientación-a-objetos les proporciona un soporte nuevo sobre el que extender su funcionalidad. La realidad, empero, es que tales herramientas son aun bastante primitivas: el soporte de los distintos métodos es cuestionable, la reingeniería no funciona (los problemas son incontables si se toca el código), y muchas de ellas se limitan a la parte gráfica (son al menos sinceras y resultan simpáticas las que comercialmente afirman que sólo sirven para eso: para los gráficos). El otrora espinoso asunto de los repositorios parece solucionado mediante Bases de Objetos, pero existe un gap insondable entre los resultados de tales herramientas y el código de producción que se supone (como el valor a los soldados) generan. Los mejores resultados aparecen, no obstante, en herramientas íntimamente ligadas a entornos de programación, como smalltalk, pero lo que aquí se consigue es, en esencia, extender tales entornos de una forma que pronto asumen los propietarios de los mismos (Parts de Digitalk, VisualAge de IBM, etc.). ¿Hasta qué punto un entorno orientado-a-objetos con capacidades visuales/textuales de documentación, modelización y prototipación necesita de una IOOCASE? Naturalmente la cuestión pasa primero por la revisión de tales entornos, y más tarde por la adecuación de los posibles métodos de OOA/OOD elegidos a las herramientas OOCASE disponibles para su uso. Cuestión de expertos, sin duda. Pero la experiencia muestra que la herramienta que mejor satisface los requerimientos de un proyecto orientado-a-objetos es la que no existe: esto es, usualmente se utilizan esquemas textuales "caseros", mientras que el uso de herramientas comerciales se basa en razones "corporativas" de normalización documentaria (así es frecuente encontrar severos desajustes entre la documentación generada por la herramienta y el proyecto real, tan lejos uno de del otro como lo está un político de Utopia). Lo más prudente es determinar, con la ayuda de un experto, el direccionamiento hacia estas herramientas.
GESTION DE PROYECTOS ORIENTADOS-A-OBJETOS
Si los anteriores capítulos parecen borrosos, echémosle una ojeada ahora al OOPM (Object-Oriented Project Management): ¿Qué documentos deben generarse y utilizarse en el desarrollo de un proyecto software orientado-a-objetos? ¿Y en qué momentos? ¿Cuáles son los puntos críticos y cuáles los de control del proyecto? ¿Cómo pueden, por otro lado, evaluarse los rendimientos del equipo de desarrollo? ¿Existen métricas formales? Bueno, son muchas preguntas. Y las respuestas aparecen en los manuales. Sí, en los escasos manuales de OOPM existentes y que se deben, en su práctica totalidad, a grandes firmas consultoras. Otra cosa es su practicidad: hay que soportar grupos de "kernels" de cuatro dígitos y "mapeos" de componentes a documentaciones y responsabilidades. Lo que es incuestionable es que algunos roles cambian, otros aparecen como nuevos, mientras que otros desparecen por completo (como, verbigracia, el del mero programador). Con la documentación (o los "deliverables") ocurre otro tanto: dado que el ciclo de vida del software es diferente ("Analiza un poco, diseña un poco, implementa un poco y evalúa un poco", según Berard), no existen fases estancas y, por tanto, una fase no puede basarse en resultados completos de una supuesta fase anterior, de lo que resulta que la documentación ha de generarse, también, de forma involutiva. Parece claro, no obstante, que han de documentarse clases, métodos y relaciones. Pero lo que definirá la estrategia de documentación normalmente se define en la etapa de OORA (la gran desconocida, en manida frase): especificaciones estáticas y dinámicas, de interfaces y comportamientos, de modelización y control, etc. Trabajo de expertos, de nuevo. El lector podrá encontrar, empero, descripciones de particulares gestiones de proyectos, con diferentes niveles de abstracción, en Lorenz, Berard, Firesmith, etc., pero difícilmente podrán ser aplicadas a un proyecto concreto con limitaciones humanas, temporales y dinerarias, cual suele ser el más común caso. ¿Desesperanza, entonces? No: simplemente una cuestión de monitorización: suele acertar quien se ha equivocado antes, directa o indirectamente; y usualmente la gestión de proyectos necesita de una experiencia interdisciplinar en campos dispersos.
SISIFO REDIVIVO
Quedáronse muchas cosas en el tintero: Bases de Objetos, Lenguajes de Programación, OORA, etc., etc. Pero se trataba aquí de generar en el lector un cierto grado de insatisfacción, complemento del caramelo comercial "orientado-a-objetos" que nos invade de forma inmisericorde. Y recuerden a Chesterton: sólo se permite dudar el que sinceramente cree, alejado de todo fanatismo. Cada uno tiene un método de OOA/OOD, como cada matemático tiene un álgebra. Quizá la mejor descripción del proceso de desarrollo de software orientado-a-objetos sea esa que explica que se trata con plastilina en lugar de con bloques de metal, y que la cuestión no es generar componentes inamovibles, sino más bien refinarlos gradualmente desde borradores más o menos acertados. Se trata, al fin, de un proceso reiterativo que asimila al analista a Sísifo, subiendo incesante una piedra que vuelve a caer a la ladera para volver a ser subida. Y aquí, como en el ensayo de Camus, podemos sentir la sonrisa de Sísifo cuando baja la pendiente para volvolver a empujar la piedra.
Copyright 1996 Ricardo Devis. All Rights Reserved
... return
to The Object Oriented
Page.
