Clase 20.

Estrategia de diseo
La presente clase rene varias de las ideas ya vistas en clases anteriores: modelos de objeto de problemas y cdigo, diagramas de dependencia de mdulos y patrones de diseo. El objetivo que en ella se persigue es ofrecer algunos consejos de carcter general sobre cmo enfrentarse al proceso de diseo de software.

20.1 Descripcin general del proceso y pruebas

Los principales pasos del proceso de desarrollo son los siguientes: Anlisis del problema: da como resultado un modelo de objeto y una lista de operaciones. Diseo: da como resultado un modelo de objeto de cdigo, un diagrama de dependencia de mdulos y especificaciones de mdulos. Implementacin: da como resultado un cdigo ejecutable. Lo ideal sera que las pruebas se llevaran a cabo a medida que se realiza el proceso de desarrollo, de modo que los errores aparezcan lo antes posible. En un conocido estudio sobre proyectos desarrollados por TRW e IBM, Barry Boehm lleg a la conclusin de que el coste de corregir un error puede llegar a multiplicarse hasta por 1.000 cuando se detecta tardamente. Hemos empleado el trmino "pruebas" exclusivamente para describir la evaluacin de cdigos, pero se pueden aplicar tcnicas parecidas a descripciones de problemas y diseos cuando se han registrado en una notacin que tenga asociada una semntica. (En mi grupo de trabajo hemos desarrollado una tcnica de anlisis para modelos de objetos). En este curso, el estudiante deber basar su trabajo en la meticulosidad de las revisiones y en el uso de escenarios manuales para evaluar las descripciones y los diseos del problema. Por lo que a probar las implementaciones se refiere, el estudiante debe marcarse como objetivo que las pruebas se realicen tan pronto como sea posible. La programacin extrema (XP), una metodologa de desarrollo muy extendida en la actualidad, aboga por escribir las pruebas antes incluso de haber escrito el cdigo al que se van a aplicar stas. Se trata de una idea muy interesante, en primer lugar porque significa que es menos probable que una seleccin de pruebas quede expuesta a sufrir los mismos errores conceptuales que esas pruebas tratan precisamente de detectar. Adems, estimula al usuario a pensar en las especificaciones por adelantado. Es un enfoque ambicioso, aunque no siempre factible. En vez de probar el cdigo de una manera ad hoc, es ms conveniente crear una base sistemtica de pruebas que no requieran la interaccin del usuario para su ejecucin y validacin. Este sistema reporta numerosos beneficios: por ejemplo, permite, cuando se introducen cambios en un cdigo, detectar rpidamente los nuevos errores que se han producido al volver a ejecutar estas "pruebas de regresin". Es aconsejable hacer un uso liberal de las certificaciones en tiempo de ejecucin y comprobar las constantes de representacin.

20.2 Anlisis del problema

El resultado principal del anlisis de un problema es un modelo de objeto que describe las entidades fundamentales del mismo y sus relaciones con otro problema. (El libro de texto del curso utiliza el trmino "modelo de datos" para referirse a esto). Conviene escribir descripciones breves para cada uno de los conjuntos y cada una de las relaciones del modelo de objeto, explicando lo que significan. Aunque nos parezcan evidentes en el momento de escribirlas, es fcil olvidar ms tarde el significado de algn trmino. Adems, muchas veces una descripcin que nos pareca clara resulta no serlo tanto cuando la vemos por escrito. Por ejemplo, en mi grupo de trabajo estamos diseando un nuevo componente de control de trfico areo, y hemos descubierto que en nuestro modelo de objeto el trmino Flight resulta bastante confuso y que es importante describirlo con claridad. Tambin resulta til escribir una lista de las operaciones primarias que el sistema proporciona. Con ello se aprende a controlar la funcionalidad global y se puede comprobar que el modelo de objeto es capaz de soportar las operaciones. Por ejemplo, un programa pensado para llevar un seguimiento de precios de valores en Bolsa puede incluir operaciones para crear y suprimir carteras, aadir acciones a carteras, actualizar el precio de un valor, etc. 20.3 Propiedades del diseo La fase de diseo produce como resultado principal un modelo de objeto de cdigo que muestra la forma en la que se implementa el estado del sistema, y un diagrama de dependencia de mdulos que representa la divisin del sistema en mdulos y el modo en que stos se relacionan entre s. En el caso de mdulos que presenten complicaciones, resulta tambin conveniente disponer de un esquema con las especificaciones del mdulo antes de comenzar la codificacin. En qu se basa un buen diseo? Obviamente, no hay un modo sencillo y objetivo de decidir si un diseo es mejor o peor que otro, pero s que hay ciertas propiedades clave que permiten evaluar su calidad. Lo ideal sera un diseo que funcionara bien en todos los aspectos, pero en la prctica normalmente es necesario sacrificar algn aspecto a cambio de otro. Estas propiedades clave son: Extensibilidad. El diseo debe ser capaz de soportar nuevas funciones. Aunque sea perfecto en todos los dems aspectos, un sistema que no muestre disposicin a integrar el ms ligero cambio o perfeccionamiento resulta inservible. Quizs no haya necesidad de aadir nuevas funciones, pero siempre es posible que se produzcan alteraciones en el dominio del problema que exijan introducir cambios en el programa. Fiabilidad. El sistema debe tener un comportamiento fiable, lo que no significa solamente que no se bloquee ni corrompa los datos; debe adems realizar todas sus funciones correctamente y de la forma prevista por el usuario. (Lo que, por cierto, quiere decir que tampoco basta con que el sistema satisfaga una especificacin confusa; debe satisfacer una que el usuario comprenda fcilmente, de forma que

ste pueda predecir su comportamiento). La disponibilidad es una caracterstica importante si el sistema es distribuido, mientras que en los sistemas en tiempo real tiene ms importancia el tiempo: no tanto que el sistema sea rpido, sino que complete las tareas en el tiempo previsto. La forma de contemplar la fiabilidad vara mucho de un sistema a otro. As, la falta de precisin a la hora de presentar imgenes es menos grave en un navegador que en un programa de edicin electrnica. Los conmutadores telefnicos, por su parte, deben cumplir estndares de disponibilidad extraordinariamente altos, si bien ello ocasiona de vez en cuando errores de desvo de llamadas. Los pequeos retrasos quizs no importen mucho cuando se trata de un cliente de correo electrnico, pero son inaceptables en el caso del controlador de un reactor nuclear. Eficiencia. El consumo de recursos por parte del sistema debe ser racional, lo que una vez ms depende del contexto. Una aplicacin que se ejecuta en un telfono mvil no puede asumir la misma disponibilidad de memoria que la que se ejecuta en un ordenador de consola. Los recursos ms especficos son el tiempo y el espacio que consume el programa que se ejecuta. Pero no hay que olvidar que, como ha demostrado Microsoft, el tiempo empleado en el desarrollo del programa puede tener idntica importancia, al igual que otro recurso que no se debe pasar por alto: el dinero. Un diseo que se implemente de modo econmico puede ser preferible a otro que funcione mejor conforme a otros parmetros pero que resulte ms caro.

20.4 Estrategia: visin general

Cmo se obtienen estas propiedades?

20.4.1 Extensibilidad Suficiencia del modelo de objeto. El modelo de objeto del problema debe ser capaz de describir ste de un modo suficientemente fiel. Uno de los obstculos habituales a la hora de extender un sistema es la falta de espacio para aadir una nueva funcin, debido a que sus nociones no se hallan expresadas en el cdigo. Microsoft Word nos muestra un ejemplo de este tipo de problemas. Word se dise asumiendo que los prrafos eran la nocin clave de la estructura de los documentos, sin que se incluyera la nocin de flujos de texto (los espacios fsicos del documento a travs de los que se hilvana el texto) ni ningn tipo de estructura jerrquica. A consecuencia de ello, Word no admite fcilmente la divisin en secciones y no es capaz de ubicar figuras. Es importante tener mucho cuidado de no optimizar el modelo de objeto del problema y eliminar subestructuras que no parezcan necesarias a primera vista. No se debe introducir una abstraccin para sustituir nociones ms concretas a menos que se est totalmente seguro de que se halla bien fundada. Como se suele decir, toda generalizaciones suele conllevar errores. Localizacin y desacoplamiento. Aunque el cdigo consiga reunir suficientes nociones que permitan la adicin de nuevas funcionalidades, puede resultar complicado realizar el cambio que se desea introducir sin alterar el cdigo en todo el sistema. Para evitar esto, el diseo debe proporcionar localizacin: cuestiones distintas deben estar separadas, en la medida de lo posible, en distintas regiones

del cdigo. Asimismo, los mdulos deben hallarse desacoplados todo lo posible unos de otros, de modo que un cambio no provoque alteraciones en cascada. Ya hemos visto ejemplos de desacoplamiento en la clase sobre espacios de nombres y, ms recientemente, en las clases sobre patrones de diseo (por ejemplo, al hablar de Observer). Estas propiedades se ven con mayor claridad en el diagrama de dependencia de mdulos, razn por la que construimos ste. Las especificaciones del mdulo son tambin importantes para obtener localizacin; en este sentido, una especificacin debe ser coherente, con una coleccin de comportamientos claramente definida (sin caractersticas ad hoc especiales) y una divisin terminante entre los mtodos, de modo que stos sean ampliamente independientes unos de otros. 20.4.2 Fiabilidad Esmero en el modelado. No es fcil dotar de fiabilidad a un sistema ya existente. La clave para lograr que un software sea fiable radica en desarrollarlo con el mayor cuidado, manteniendo ese esmero durante todo el proceso de modelado. Los problemas ms graves en sistemas crticos no provienen de errores de cdigo, sino de fallos en el anlisis del problema; normalmente porque el analista no ha tenido en cuenta alguna propiedad del entorno en el que el sistema se halla insertado. Un ejemplo de ello es el fallo mecnico del Airbus en el aeropuerto de Varsovia. Revisin, anlisis y prueba. Por mucho cuidado que se ponga, es inevitable cometer errores. Por ello, en todo proceso de desarrollo es preciso decidir por adelantado cmo se van a solucionar stos. En la prctica, uno de los mtodos ms eficaces desde el punto de vista del coste a la hora de detectar errores de software, sea cual sea el modelo, la especificacin o el cdigo utilizados, es el de la revisin por pares. Hasta ahora, usted solamente habr podido explorar este mtodo con el profesor auxiliar y en las clases de laboratorio; en el proyecto de final de curso le conviene aprovechar la oportunidad de trabajar en equipo para analizar el trabajo de sus compaeros. De esta forma, tanto usted como ellos ahorrarn tiempo a largo plazo.

Anlisis y pruebas ms especficos permiten hallar aquellos errores que hayan pasado inadvertidos en el anlisis de pares. Un anlisis til y fcil de realizar consiste simplemente en comprobar la coherencia de los modelos. Soporta el modelo de objeto del cdigo todos los estados del modelo de objeto del problema? Se combinan adecuadamente las multiplicidades y mutabilidades? Tiene en cuenta el diagrama de dependencia de mdulos todas las restricciones del modelo de objeto? Otra posibilidad es comprobar el cdigo con los modelos. La herramienta Womble, que se puede descargar desde el sitio http://sdg.lcs.mit.edu, construye automticamente modelos de objetos a partir de Codi-bait (Byte-code). Hemos descubierto numerosos errores en nuestro cdigo examinando modelos extrados y comparndolos con los modelos planeados. Es conveniente, por tanto, que usted compruebe las propiedades esenciales de su modelo de objeto preguntndose si est seguro de que mantiene las propiedades. Suponga, por ejemplo, que su modelo dice que un vector nunca es compartido por dos objetos de cuenta bancaria. En tal caso, usted debera ser capaz de explicar por qu el cdigo garantiza esta afirmacin. Siempre que su modelo de objeto contenga una restriccin que no se haya podido expresar grficamente es especialmente aconsejable verificarla, ya que

es probable que comprenda relaciones que sobrepasen los lmites del objeto 20.4.3 Eficiencia Modelo de objeto. La eleccin del modelo de objeto del cdigo es esencial, ya que una vez elegido resulta muy difcil de cambiar. Por ello es conveniente considerar los objetivos de rendimiento crtico al comenzar el diseo. Ms adelante veremos algunos ejemplos de transformaciones que se pueden aplicar al modelo de objeto para mejorar su eficiencia. Evitar el sesgo. Al desarrollar el modelo de objeto del problema deben dejarse de lado las cuestiones relativas a la implementacin. Cuando un modelo de problema contiene detalles sobre su implementacin se dice que est sesgado, ya que favorece un tipo de implementacin en perjuicio de otro. Ello supone reducir prematuramente el espacio a posibles implementaciones, entre las que podra hallarse la ms eficiente. Optimizacin. La palabra "optimizacin" es engaosa: invariablemente significa una mejora del rendimiento, pero en detrimento de otras cualidades (como la nitidez de la estructura). Y si no se tiene cuidado con la optimizacin se corre el riesgo de que el sistema acabe siendo peor en todos los aspectos. Antes de introducir un cambio para mejorar el rendimiento, asegrese de que tiene suficientes pruebas de que las alteraciones tendrn probablemente un efecto muy positivo. En general es aconsejable resistir la tentacin de optimizar y concentrarse en lograr que el diseo sea sencillo y claro. En cualquier caso, los diseos que cumplen estas premisas suelen ser los que muestran mayor eficiencia y, en caso de que no la muestren, siempre son los ms fciles de modificar. Eleccin de representaciones. En vez de perder el tiempo en lograr pequeas mejoras del rendimiento, es mejor centrarse en las clases de mejora positiva que se pueden obtener eligiendo una representacin diferente para un tipo abstracto, por ejemplo, capaz de cambiar una operacin de tiempo lineal a tiempo constante. Muchos de ustedes lo habrn podido comprobar en su proyecto de MapQuick: cuando se elige una representacin para grafos que requiere un tiempo proporcional al tamao de todo el grafo para obtener vecinos de un nodo, la bsqueda resulta totalmente impracticable. Asimismo, no se debe olvidar que compartir objetos puede tener efectos positivos, por lo que hay que considerar la posibilidad de utilizar tipos invariables y hacer que los objetos compartan una estructura. Por ejemplo, en MapQuick, Route es un tipo invariable; si se implementa compartiendo estructura, cada extensin de la ruta por un nodo durante la bsqueda exige solamente situar un nico nodo en vez de una copia entera de la ruta.

Ante todo, recuerde que lo ms importante es la sencillez. Piense en lo fcil que resulta terminar embrollado en una masa de complejidades, incapaz de alcanzar ninguna de estas propiedades. Lo ms sensato es disear y construir primero un sistema mnimo, lo ms sencillo posible, y slo entonces comenzar a aadir recursos. 20.5 Transformaciones del modelo de objeto En modelos de objetos de cdigos y problemas, hemos visto dos usos distintos de la misma

notacin. Cmo puede un modelo de objeto describir un problema a la vez que describe una implementacin? Para responder a esta pregunta resulta til pensar en la interpretacin de un modelo de objeto como un proceso en dos fases. En la primera, se interpreta el modelo en funcin de conjuntos y relaciones abstractas. En la segunda fase, se asocian estos conjuntos y relaciones, bien a las entidades y relaciones del problema, o bien a los objetos y campos de la implementacin. Supongamos, por ejemplo, que tenemos un modelo de objeto con una relacin employs (contrata) que asocia Company (empresa) a Employee (empleado).

Matemticamente, vemos esto como una expresin de dos conjuntos y de una relacin entre ambos. La restriccin de multiplicidad nos dice que cada employee se asocia, conforme a la relacin employs, a una company como mximo. A la hora de interpretarlo como un modelo de objeto de problema, contemplaremos el conjunto Company como un conjunto de empresas del mundo real (real world), y Employee como un conjunto de personas que son contratadas por las empresas. La relacin employs relaciona c con e cuando la compaa c contrata a la persona e. Si lo interpretamos como un modelo de objeto de cdigo, en cambio, contemplaremos el conjunto Company como un conjunto de objetos situados en una pila (heap) de la clase Company, y Employee como un conjunto de objetos situados en una pila de la clase Employee. Aqu, la relacin employs pasa a ser un campo de especificacin que asocia c y e cuando el objeto c mantiene una referencia a una coleccin (oculto en la representacin de Company) que contenga la referencia e. Nuestra estrategia consiste en partir de un modelo de objeto de problema y transformarlo en uno de cdigo. Por lo general, uno y otro sern considerablemente distintos, dado que un modelo que proporciona una descripcin clara del problema no suele ofrecer una buena implementacin.

Cmo se obtiene esta implementacin? Un mtodo de trabajo bastante apropiado consiste en realizar una sesin de brainstorming y, a partir de ella, jugar con diferentes fragmentos de modelos de cdigo hasta que encajen. Es necesario comprobar que el modelo de objeto de cdigo se corresponde fielmente al modelo de objeto del problema. Debe ser capaz de representar al menos toda la informacin sobre los estados del modelo de problema, de forma que sea posible, por ejemplo, aadir una relacin, pero que no sea posible eliminarla. Otra forma de llevar a cabo la transformacin es mediante la aplicacin sistemtica de una serie de pequeas transformaciones. Cada una de ellas se elige de entre un repertorio de transformaciones que preservan el contenido de los datos del modelo. De esta forma, como cada paso mantiene el modelo intacto, toda la serie se mantendr tambin invariable. Hasta el momento, nadie ha propuesto un repertorio completo de tales transformaciones (lo que representa un problema de investigacin), pero s que hay varias que se pueden identificar como las ms tiles. Antes de seguir adelante, veamos un ejemplo. 20.6 Ejemplo de Folio Tracker Supongamos que queremos disear un programa para realizar el seguimiento de una cartera de valores. El modelo de objeto nos da la descripcin de los elementos del problema. Folio es el conjunto de carteras, cada una de ellas con un Name (nombre), que contiene un conjunto de posiciones Pos. Cada posicin corresponde a un Stock (valor) concreto, del que se mantiene algn nmero. Un stock puede tener un valor (cuando se haya obtenido recientemente una cotizacin), y tiene asignado un smbolo de registro de cotizacin que permanece invariable. Estos smbolos identifican nicamente a los valores. Se puede situar un observador (Watch) en una cartera, lo que hace que el sistema muestre la informacin relativa a la cartera cuando se produzcan determinados cambios en sta.

20.7 Catalogo de transformaciones

20.7.1 Introduccin de una generalizacin Si A y B son conjuntos con relaciones p y q, de la misma multiplicidad y mutabilidad, al conjunto C, podemos introducir una generalizacin AB y sustituir p y q por una nica relacin pq de AB a C. La relacin pq puede no tener la misma multiplicidad fuente que p y q.

20.7.2 Insercin de una coleccin Si una relacin r de A a B tiene una multiplicidad objetivo que permite ms de un elemento, podemos interponer una coleccin, como un vector o un conjunto, entre A y B, y sustituir r por una relacin a dos relaciones, una desde A a la coleccin y otra desde la coleccin a B.

En nuestro ejemplo de Folio Tracker, podramos sustituir/interponer un vector en la relacin posns entre Folio y Pos. Obsrvense las marcas de mutabilidad; la coleccin es generalmente construida y reorganizada con su contenedor.

20.7.3 Inversin de una relacin Dado que la direccin de una relacin no implica su capacidad para recorrerla en esa direccin, siempre cabe la posibilidad de invertirla. Al final, naturalmente, interpretaremos las relaciones como campos, por lo que es habitual invertir relaciones para orientarlas en la direccin en que se espera que sean recorridas. En nuestro ejemplo, podramos invertir la relacin name, ya que posiblemente querremos recorrerla desde nombres (names) a carteras (folios), obteniendo una relacin folio, por ejemplo. 20.7.4 Traslado de una relacin A veces es posible trasladar el objetivo o la fuente de una relacin sin que ello suponga prdida de datos. Por ejemplo, una relacin de A a C se puede sustituir por una relacin de B a C si A y B se hallan en una correspondencia de uno a uno.

En nuestro ejemplo, podemos sustituir la relacin val entre Stock y Dollar por una relacin entre Ticker y Dollar. Resulta conveniente utilizar un mismo nombre para la nueva relacin, aunque tcnicamente se trate de una relacin diferente.

20.7.5 Relacin a una tabla Una relacin de A a B que tenga una multiplicidad objetivo igual a exactamente uno o cero-o-uno, puede sustituirse por una tabla. Dado que solamente se necesita una tabla, puede utilizarse el patrn de instancia nica (singleton), de manera que la tabla se pueda referenciar por un nombre global. Si la multiplicidad objetivo de la relacin es cero o uno, la tabla debe ser capaz de admitir correlaciones a valores nulos.

En FolioTracker, por ejemplo, podramos convertir la relacin folio a una tabla que permitiera hallar carteras mediante una operacin de verificacin constante. As, tendramos:

Sera interesante convertir tambin en una tabla la relacin val que vincula Ticker a Dollar, ya que ello hara posible que la bsqueda de valores para smbolos de registro de cotizacin se encapsulara en un objeto distinto de la cartera de valores. En este caso, debido a la multiplicidad cero-o-uno, necesitaremos una tabla capaz de almacenar valores nulos.

20.7.6 Adicin de estados redundantes Suele ser til aadir componentes de estado redundantes a un modelo de objeto. Dos casos comunes de ello son la adicin del traslado de una relacin y la adicin de la composicin de dos relaciones. Si p asocia A a B, podemos aadir el traslado q de B a A. Si p asocia A a B, y q asocia B a C, podemos aadir la composicin pq de A a C. 20.7.7 Descomposicin de relaciones mutables Supongamos que un conjunto A tiene relaciones de salida p, q y r, de las cuales p y q son estticas. Si se implementa directamente, la presencia de r har que A sea mutable. Por tanto, sera conveniente descomponer la relacin r utilizando, por ejemplo, la transformacin Relacin a Tabla, e implementar a continuacin A como un tipo de datos inmutable. Volviendo a nuestro ejemplo, la descomposicin de la relacin val encaja en este patrn, ya que hace inmutable a la relacin Stock. La misma idea subyace en el patrn de diseo Flyweight. 20.7.8 Interpolacin de una interfaz Esta transformacin sustituye el objetivo de una relacin R entre un conjunto A y un conjunto B por un superconjunto X de B. Por regla general, A y B pasarn a ser clases y X se convertir en una clase o interfaz abstracta. Gracias a ello, la relacin R se podr ampliar para asociar elementos de A a elementos de un nuevo conjunto C, implementando C como una subclase de X. Dado que X descompone las propiedades compartidas de sus subclases, tendr una especificacin ms simple que B; la dependencia de A en X es, por lo tanto, menos rgida que su dependencia anterior en B. Para compensar la prdida de comunicacin entre A y B, se puede aadir (mediante una nueva transformacin) una relacin adicional desde B de regreso a A.

El patrn de diseo Observer (observador)es un ejemplo del resultado de esta transformacin. En nuestro ejemplo, podramos convertir los objetos Watch en observadores de los objetos Folio:

20.7.9 Eliminacin de conjuntos dinmicos No es posible implementar como subclase un subconjunto que no sea esttico: los objetos no pueden migrar entre clases en tiempo de ejecucin, por lo que es necesario transformarlos. Una clasificacin en subconjuntos puede transformarse en una relacin del subconjunto a un conjunto de valores de clasificacin.

Cuando solamente hay uno o dos subconjuntos dinmicos, los valores de clasificacin pueden ser valores booleanos primarios. La clasificacin se puede tambin transformar en varios conjuntos nicos, uno para cada subconjunto.

20.8 Modelo de objeto final

El siguiente grfico muestra el resultado en el ejemplo de Folio Tracker de la secuencia de transformaciones que hemos comentado. Llegados a este punto, debemos comprobar que nuestro modelo es capaz de soportar las operaciones que el sistema debe realizar, y utilizar los escenarios de estas operaciones para construir un diagrama de dependencia del modelo que nos permita verificar la viabilidad del diseo. Tendremos que aadir mdulos para la interfaz de usuario y para cualquier otro dispositivo que haya que utilizar para obtener las cotizaciones de las acciones. Asimismo, nos conviene aadir un mecanismo para almacenar carteras en disco de modo permanente. Para algunas de estas tareas, necesitaremos volver sobre nuestros pasos y construir un modelo de objeto del problema, pero para otras partes habr que trabajar en el nivel de implementacin. As, por ejemplo, si queremos que los usuarios puedan dar nombre a los archivos para almacenar carteras en ellos, es prcticamente seguro que necesitaremos un modelo de objeto del problema. Sin embargo, la construccin de un modelo no resultar posiblemente eficaz para resolver cuestiones relativas al modo de analizar una pgina Web para obtener cotizaciones de acciones.

20.9 Lenguaje unificado de modelado (UML) y mtodos

Existen varios mtodos que describen detalladamente estrategias para el desarrollo orientado a objetos, indicando qu modelos hay que crear y en qu orden. En un escenario industrial, establecer un mtodo como estndar puede servir de ayuda a la hora de coordinar el trabajo de diversos equipos. Aunque en este curso no se ensea ningn mtodo en concreto, las nociones que usted ha asimilado son la base de la mayora de ellos, por lo que no debera tener problema en aprender cualquier mtodo especfico. Casi todos los mtodos utilizan modelos de objeto, y algunos utilizan tambin diagramas de dependencia de mdulos. Si desea conocer ms sobre la materia, le recomiendo introducir en Google una bsqueda con los trminos "Catalysis", "Fusion" y "Syntropy"; que le dirigir a libros y materiales online. En los ltimos aos se han producido diversos intentos de estandarizacin de las notaciones. El Object Management Group (grupo de administracin de objetos) ha adoptado como notacin estndar el lenguaje unificado de modelado (UML), que es en realidad una amplia coleccin de notaciones diversas, en la que se incluye una notacin de modelado de objetos similar a la nuestra (aunque mucho ms compleja).