Clase 20. Estrategia de diseño La presente clase reúne varias de las ideas ya vistas en clases anteriores: modelos de objeto de problemas y código, diagramas de dependencia de módulos y patrones de diseño. El objetivo que en ella se persigue es ofrecer algunos consejos de carácter general sobre cómo enfrentarse al proceso de diseño de software.

20.1 Descripción general del proceso y pruebas Los principales pasos del proceso de desarrollo son los siguientes: • Análisis del problema: da como resultado un modelo de objeto y una lista de operaciones. • Diseño: da como resultado un modelo de objeto de código, un diagrama de dependencia de módulos y especificaciones de módulos. • Implementación: da como resultado un código ejecutable. Lo ideal sería 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 conclusión de que el coste de corregir un error puede llegar a multiplicarse hasta por 1.000 cuando se detecta tardíamente. Hemos empleado el término "pruebas" exclusivamente para describir la evaluación de códigos, pero se pueden aplicar técnicas parecidas a descripciones de problemas y diseños cuando se han registrado en una notación que tenga asociada una semántica. (En mi grupo de trabajo hemos desarrollado una técnica de análisis 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 diseños 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 programación extrema (XP), una metodología de desarrollo muy extendida en la actualidad, aboga por escribir las pruebas antes incluso de haber escrito el código 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 selección de pruebas quede expuesta a sufrir los mismos errores conceptuales que esas pruebas tratan precisamente de detectar. Además, estimula al usuario a pensar en las especificaciones por adelantado. Es un enfoque ambicioso, aunque no siempre factible. En vez de probar el código de una manera ad hoc, es más conveniente crear una base sistemática de pruebas que no requieran la interacción del usuario para su ejecución y validación. Este sistema reporta numerosos beneficios: por ejemplo, permite, cuando se introducen cambios en un código, detectar rápidamente los nuevos errores que se han producido al volver a ejecutar estas "pruebas de regresión". Es aconsejable hacer un uso liberal de las certificaciones en tiempo de ejecución y comprobar las constantes de representación.

20.2 Análisis del problema El resultado principal del análisis 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 término "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 fácil olvidar más tarde el significado de algún término. Además, muchas veces una descripción que nos parecía clara resulta no serlo tanto cuando la vemos por escrito. Por ejemplo, en mi grupo de trabajo estamos diseñando un nuevo componente de control de tráfico aéreo, y hemos descubierto que en nuestro modelo de objeto el término Flight resulta bastante confuso y que es importante describirlo con claridad. También 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, añadir acciones a carteras, actualizar el precio de un valor, etc. 20.3 Propiedades del diseño La fase de diseño produce como resultado principal un modelo de objeto de código que muestra la forma en la que se implementa el estado del sistema, y un diagrama de dependencia de módulos que representa la división del sistema en módulos y el modo en que éstos se relacionan entre sí. En el caso de módulos que presenten complicaciones, resulta también conveniente disponer de un esquema con las especificaciones del módulo antes de comenzar la codificación. ¿En qué se basa un buen diseño? Obviamente, no hay un modo sencillo y objetivo de decidir si un diseño es mejor o peor que otro, pero sí que hay ciertas propiedades clave que permiten evaluar su calidad. Lo ideal sería un diseño que funcionara bien en todos los aspectos, pero en la práctica normalmente es necesario sacrificar algún aspecto a cambio de otro. Estas propiedades clave son: • Extensibilidad. El diseño debe ser capaz de soportar nuevas funciones. Aunque sea perfecto en todos los demás aspectos, un sistema que no muestre disposición a integrar el más ligero cambio o perfeccionamiento resulta inservible. Quizás no haya necesidad de añadir 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 además 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 especificación confusa; debe satisfacer una que el usuario comprenda fácilmente, de forma que

éste pueda predecir su comportamiento). La disponibilidad es una característica importante si el sistema es distribuido, mientras que en los sistemas en tiempo real tiene más importancia el tiempo: no tanto que el sistema sea rápido, sino que complete las tareas en el tiempo previsto. La forma de contemplar la fiabilidad varía mucho de un sistema a otro. Así, la falta de precisión a la hora de presentar imágenes es menos grave en un navegador que en un programa de edición electrónica. Los conmutadores telefónicos, por su parte, deben cumplir estándares de disponibilidad extraordinariamente altos, si bien ello ocasiona de vez en cuando errores de desvío de llamadas. Los pequeños retrasos quizás no importen mucho cuando se trata de un cliente de correo electrónico, 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 más depende del contexto. Una aplicación que se ejecuta en un teléfono móvil no puede asumir la misma disponibilidad de memoria que la que se ejecuta en un ordenador de consola. Los recursos más específicos 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 idéntica importancia, al igual que otro recurso que no se debe pasar por alto: el dinero. Un diseño que se implemente de modo económico puede ser preferible a otro que funcione mejor conforme a otros parámetros pero que resulte más caro.

•

20.4 Estrategia: visión general ¿Cómo 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 obstáculos habituales a la hora de extender un sistema es la falta de espacio para añadir una nueva función, debido a que sus nociones no se hallan expresadas en el código. Microsoft Word nos muestra un ejemplo de este tipo de problemas. Word se diseñó asumiendo que los párrafos eran la noción clave de la estructura de los documentos, sin que se incluyera la noción de flujos de texto (los espacios físicos del documento a través de los que se hilvana el texto) ni ningún tipo de estructura jerárquica. A consecuencia de ello, Word no admite fácilmente la división 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 abstracción para sustituir nociones más concretas a menos que se esté totalmente seguro de que se halla bien fundada. Como se suele decir, toda generalizaciones suele conllevar errores. Localización y desacoplamiento. Aunque el código consiga reunir suficientes nociones que permitan la adición de nuevas funcionalidades, puede resultar complicado realizar el cambio que se desea introducir sin alterar el código en todo el sistema. Para evitar esto, el diseño debe proporcionar localización: cuestiones distintas deben estar separadas, en la medida de lo posible, en distintas regiones

del código. Asimismo, los módulos 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, más recientemente, en las clases sobre patrones de diseño (por ejemplo, al hablar de Observer). Estas propiedades se ven con mayor claridad en el diagrama de dependencia de módulos, razón por la que construimos éste. Las especificaciones del módulo son también importantes para obtener localización; en este sentido, una especificación debe ser coherente, con una colección de comportamientos claramente definida (sin características ad hoc especiales) y una división terminante entre los métodos, de modo que éstos sean ampliamente independientes unos de otros. 20.4.2 Fiabilidad •

•

Esmero en el modelado. No es fácil 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 más graves en sistemas críticos no provienen de errores de código, sino de fallos en el análisis 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 mecánico del Airbus en el aeropuerto de Varsovia. Revisión, análisis y prueba. Por mucho cuidado que se ponga, es inevitable cometer errores. Por ello, en todo proceso de desarrollo es preciso decidir por adelantado cómo se van a solucionar éstos. En la práctica, uno de los métodos más eficaces desde el punto de vista del coste a la hora de detectar errores de software, sea cual sea el modelo, la especificación o el código utilizados, es el de la revisión por pares. Hasta ahora, usted solamente habrá podido explorar este método 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 compañeros. De esta forma, tanto usted como ellos ahorrarán tiempo a largo plazo.

Análisis y pruebas más específicos permiten hallar aquellos errores que hayan pasado inadvertidos en el análisis de pares. Un análisis útil y fácil de realizar consiste simplemente en comprobar la coherencia de los modelos. ¿Soporta el modelo de objeto del código todos los estados del modelo de objeto del problema? ¿Se combinan adecuadamente las multiplicidades y mutabilidades? ¿Tiene en cuenta el diagrama de dependencia de módulos todas las restricciones del modelo de objeto? Otra posibilidad es comprobar el código con los modelos. La herramienta Womble, que se puede descargar desde el sitio http://sdg.lcs.mit.edu, construye automáticamente modelos de objetos a partir de Codi-bait (Byte-code). Hemos descubierto numerosos errores en nuestro código examinando modelos extraídos y comparándolos con los modelos planeados. Es conveniente, por tanto, que usted compruebe las propiedades esenciales de su modelo de objeto preguntándose 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 debería ser capaz de explicar por qué el código garantiza esta afirmación. Siempre que su modelo de objeto contenga una restricción que no se haya podido expresar gráficamente es especialmente aconsejable verificarla, ya que

es probable que comprenda relaciones que sobrepasen los límites del objeto 20.4.3 Eficiencia •

•

•

•

Modelo de objeto. La elección del modelo de objeto del código es esencial, ya que una vez elegido resulta muy difícil de cambiar. Por ello es conveniente considerar los objetivos de rendimiento crítico al comenzar el diseño. Más 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 implementación. Cuando un modelo de problema contiene detalles sobre su implementación se dice que está sesgado, ya que favorece un tipo de implementación en perjuicio de otro. Ello supone reducir prematuramente el espacio a posibles implementaciones, entre las que podría hallarse la más eficiente. Optimización. La palabra "optimización" es engañosa: 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 optimización se corre el riesgo de que el sistema acabe siendo peor en todos los aspectos. Antes de introducir un cambio para mejorar el rendimiento, asegúrese de que tiene suficientes pruebas de que las alteraciones tendrán probablemente un efecto muy positivo. En general es aconsejable resistir la tentación de optimizar y concentrarse en lograr que el diseño sea sencillo y claro. En cualquier caso, los diseños que cumplen estas premisas suelen ser los que muestran mayor eficiencia y, en caso de que no la muestren, siempre son los más fáciles de modificar. Elección de representaciones. En vez de perder el tiempo en lograr pequeñas mejoras del rendimiento, es mejor centrarse en las clases de mejora positiva que se pueden obtener eligiendo una representación diferente para un tipo abstracto, por ejemplo, capaz de cambiar una operación de tiempo lineal a tiempo constante. Muchos de ustedes lo habrán podido comprobar en su proyecto de MapQuick: cuando se elige una representación para grafos que requiere un tiempo proporcional al tamaño de todo el grafo para obtener vecinos de un nodo, la búsqueda 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 extensión de la ruta por un nodo durante la búsqueda exige solamente situar un único nodo en vez de una copia entera de la ruta.

Ante todo, recuerde que lo más importante es la sencillez. Piense en lo fácil que resulta terminar embrollado en una masa de complejidades, incapaz de alcanzar ninguna de estas propiedades. Lo más sensato es diseñar y construir primero un sistema mínimo, lo más sencillo posible, y sólo entonces comenzar a añadir recursos. 20.5 Transformaciones del modelo de objeto En modelos de objetos de códigos y problemas, hemos visto dos usos distintos de la misma

notación. ¿Cómo puede un modelo de objeto describir un problema a la vez que describe una implementación? Para responder a esta pregunta resulta útil pensar en la interpretación de un modelo de objeto como un proceso en dos fases. En la primera, se interpreta el modelo en función 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 implementación. Supongamos, por ejemplo, que tenemos un modelo de objeto con una relación employs (contrata) que asocia Company (empresa) a Employee (empleado).

Matemáticamente, vemos esto como una expresión de dos conjuntos y de una relación entre ambos. La restricción de multiplicidad nos dice que cada employee se asocia, conforme a la relación employs, a una company como máximo. 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 relación employs relaciona c con e cuando la compañía c contrata a la persona e. Si lo interpretamos como un modelo de objeto de código, 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 relación employs pasa a ser un campo de especificación que asocia c y e cuando el objeto c mantiene una referencia a una colección (oculto en la representación de Company) que contenga la referencia e. Nuestra estrategia consiste en partir de un modelo de objeto de problema y transformarlo en uno de código. Por lo general, uno y otro serán considerablemente distintos, dado que un modelo que proporciona una descripción clara del problema no suele ofrecer una buena implementación.

¿Cómo se obtiene esta implementación? Un método de trabajo bastante apropiado consiste en realizar una sesión de brainstorming y, a partir de ella, jugar con diferentes fragmentos de modelos de código hasta que encajen. Es necesario comprobar que el modelo de objeto de código se corresponde fielmente al modelo de objeto del problema. Debe ser capaz de representar al menos toda la información sobre los estados del modelo de problema, de forma que sea posible, por ejemplo, añadir una relación, pero que no sea posible eliminarla. Otra forma de llevar a cabo la transformación es mediante la aplicación sistemática de una serie de pequeñas 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á también invariable. Hasta el momento, nadie ha propuesto un repertorio completo de tales transformaciones (lo que representa un problema de investigación), pero sí que hay varias que se pueden identificar como las más útiles. Antes de seguir adelante, veamos un ejemplo. 20.6 Ejemplo de Folio Tracker Supongamos que queremos diseñar un programa para realizar el seguimiento de una cartera de valores. El modelo de objeto nos da la descripción 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 posición corresponde a un Stock (valor) concreto, del que se mantiene algún número. Un stock puede tener un valor (cuando se haya obtenido recientemente una cotización), y tiene asignado un símbolo de registro de cotización que permanece invariable. Estos símbolos identifican únicamente a los valores. Se puede situar un observador (Watch) en una cartera, lo que hace que el sistema muestre la información relativa a la cartera cuando se produzcan determinados cambios en ésta.

20.7 Catalogo de transformaciones 20.7.1 Introducción de una generalización Si A y B son conjuntos con relaciones p y q, de la misma multiplicidad y mutabilidad, al conjunto C, podemos introducir una generalización AB y sustituir p y q por una única relación pq de AB a C. La relación pq puede no tener la misma multiplicidad fuente que p y q.

20.7.2 Inserción de una colección Si una relación r de A a B tiene una multiplicidad objetivo que permite más de un elemento, podemos interponer una colección, como un vector o un conjunto, entre A y B, y sustituir r por una relación a dos relaciones, una desde A a la colección y otra desde la colección a B.

En nuestro ejemplo de Folio Tracker, podríamos sustituir/interponer un vector en la relación posns entre Folio y Pos. Obsérvense las marcas de mutabilidad; la colección es generalmente construida y reorganizada con su contenedor.

20.7.3 Inversión de una relación Dado que la dirección de una relación no implica su capacidad para recorrerla en esa dirección, 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 dirección en que se espera que sean recorridas. En nuestro ejemplo, podríamos invertir la relación name, ya que posiblemente querremos recorrerla desde nombres (names) a carteras (folios), obteniendo una relación folio, por ejemplo. 20.7.4 Traslado de una relación A veces es posible trasladar el objetivo o la fuente de una relación sin que ello suponga pérdida de datos. Por ejemplo, una relación de A a C se puede sustituir por una relación de B a C si A y B se hallan en una correspondencia de uno a uno.

En nuestro ejemplo, podemos sustituir la relación val entre Stock y Dollar por una relación entre Ticker y Dollar. Resulta conveniente utilizar un mismo nombre para la nueva relación, aunque técnicamente se trate de una relación diferente.

20.7.5 Relación a una tabla Una relación 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 patrón de instancia única (singleton), de manera que la tabla se pueda referenciar por un nombre global. Si la multiplicidad objetivo de la relación es cero o uno, la tabla debe ser capaz de admitir correlaciones a valores nulos.

En FolioTracker, por ejemplo, podríamos convertir la relación folio a una tabla que permitiera hallar carteras mediante una operación de verificación constante. Así, tendríamos:

Sería interesante convertir también en una tabla la relación val que vincula Ticker a Dollar, ya que ello haría posible que la búsqueda de valores para símbolos de registro de cotización 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 Adición de estados redundantes Suele ser útil añadir componentes de estado redundantes a un modelo de objeto. Dos casos comunes de ello son la adición del traslado de una relación y la adición de la composición de dos relaciones. Si p asocia A a B, podemos añadir el traslado q de B a A. Si p asocia A a B, y q asocia B a C, podemos añadir la composición pq de A a C. 20.7.7 Descomposición de relaciones mutables Supongamos que un conjunto A tiene relaciones de salida p, q y r, de las cuales p y q son estáticas. Si se implementa directamente, la presencia de r hará que A sea mutable. Por tanto, sería conveniente descomponer la relación r utilizando, por ejemplo, la transformación Relación a Tabla, e implementar a continuación A como un tipo de datos inmutable. Volviendo a nuestro ejemplo, la descomposición de la relación val encaja en este patrón, ya que hace inmutable a la relación Stock. La misma idea subyace en el patrón de diseño Flyweight. 20.7.8 Interpolación de una interfaz Esta transformación sustituye el objetivo de una relación R entre un conjunto A y un conjunto B por un superconjunto X de B. Por regla general, A y B pasarán a ser clases y X se convertirá en una clase o interfaz abstracta. Gracias a ello, la relación 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 especificación más simple que B; la dependencia de A en X es, por lo tanto, menos rígida que su dependencia anterior en B. Para compensar la pérdida de comunicación entre A y B, se puede añadir (mediante una nueva transformación) una relación adicional desde B de regreso a A.

El patrón de diseño Observer (observador)es un ejemplo del resultado de esta transformación. En nuestro ejemplo, podríamos convertir los objetos Watch en observadores de los objetos Folio:

20.7.9 Eliminación de conjuntos dinámicos No es posible implementar como subclase un subconjunto que no sea estático: los objetos no pueden migrar entre clases en tiempo de ejecución, por lo que es necesario transformarlos. Una clasificación en subconjuntos puede transformarse en una relación del subconjunto a un conjunto de valores de clasificación.

Cuando solamente hay uno o dos subconjuntos dinámicos, los valores de clasificación pueden ser valores booleanos primarios. La clasificación se puede también transformar en varios conjuntos únicos, uno para cada subconjunto.

20.8 Modelo de objeto final El siguiente gráfico 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 diseño. Tendremos que añadir módulos para la interfaz de usuario y para cualquier otro dispositivo que haya que utilizar para obtener las cotizaciones de las acciones. Asimismo, nos conviene añadir 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 implementación. Así, por ejemplo, si queremos que los usuarios puedan dar nombre a los archivos para almacenar carteras en ellos, es prácticamente seguro que necesitaremos un modelo de objeto del problema. Sin embargo, la construcción de un modelo no resultará posiblemente eficaz para resolver cuestiones relativas al modo de analizar una página Web para obtener cotizaciones de acciones.

20.9 Lenguaje unificado de modelado (UML) y métodos Existen varios métodos 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 método como estándar puede servir de ayuda a la hora de coordinar el trabajo de diversos equipos. Aunque en este curso no se enseña ningún método en concreto, las nociones que usted ha asimilado son la base de la mayoría de ellos, por lo que no debería tener problema en aprender cualquier método específico. Casi todos los métodos utilizan modelos de objeto, y algunos utilizan también diagramas de dependencia de módulos. Si desea conocer más sobre la materia, le recomiendo introducir en Google una búsqueda con los términos "Catalysis", "Fusion" y "Syntropy"; que le dirigirá a libros y materiales online. En los últimos años se han producido diversos intentos de estandarización de las notaciones. El Object Management Group (grupo de administración de objetos) ha adoptado como notación estándar el lenguaje unificado de modelado (UML), que es en realidad una amplia colección de notaciones diversas, en la que se incluye una notación de modelado de objetos similar a la nuestra (aunque mucho más compleja).