Tendencias del anlisis de sistemas orientado a objetos

Jos Lus Barros Justo

*



Actualmente existen dos corrientes dentro de la orientacin a objetos, una que apunta a las
caractersticas -y a la que muchos autores denominan tradicional- y otra que atiende principalmente
el comportamiento de los objetos. Las diferencias que subsisten entre quienes sostienen estos dos
enfoques no son tan infranqueables como las que enfrentaban a los integrantes de las corrientes
tradicionales de anlisis no orientado a objetos.
A estas dos posturas se suma el problema de la cantidad de mtodos conocidos. Pero
parece que poco a poco se va despejando el panorama, y comienzan a delinearse los aspectos que
poseern los mtodos de anlisis orientado a objetos con que nos encontraremos en un futuro
bastante cercano.
Uno de los principales motivos de esta suerte de "seleccin natural", proviene del veredicto
que dieron quienes emplearon los mtodos en base a los resultados obtenidos. Otro motivo es el
establecimiento paulatino de estndares, que van fijando las pautas a las que deben responder los
mtodos.
No obstante, se siguen manteniendo estas dos corrientes en los mtodos que hoy se
encuentran en desarrollo, aunque de maneras diversas. En este artculo comentar tres mtodos
que, a mi criterio, sern los ms utilizados una vez que se establezcan definitivamente -aunque, en
rigor, ya estn siendo empleados-. Ellos son OOA96 de Shlaer y Mellor, UML de Booch, Rumbaugh y
Jacobson, y OBA de ParcPlace-Digitalk.


A - OOA96 de Shaler y Mellor

Este mtodo es desarrollado en la empresa Project Technology, Inc., fundada en 1984, y de
la que Sally Shlaer y Steve Mellor son co-fundadores. La denominacin OOA96 responde al nombre
del mtodo seguido por el ao del establecimiento de su nueva versin.
El contenido de este comentario fue extrado principalmente de la versin 1.0 de OOA96 [1],
ms otras publicaciones de diversos medios referidos al tema.
Bsicamente el mtodo es el mismo que OOA91, al que se le incorporan algunas
novedades, pero las suficientes como para justificar una nueva versin.
El objetivo principal de OOA96 consiste en establecer las reglas del mtodo de Shlaer y
Mellor, que sientan las bases de la publicacin de su prximo libro de Diseo Recursivo. Los autores
intentan establecer un mtodo autoconsistente, manteniendo el perfil de OOA91 e incorporando
mayor rigor, tanto en las caractersticas del mtodo como en el establecimiento de los lmites del
dominio del problema. OOA96 se compone de un formalismo de rigor matemtico, de una notacin,
que permiten sea modificada de acuerdo con las necesidades particulares de uso, los productos de
la modelacin y las tcnicas de empleo.
En el OOA96 Report version 1.0 se exponen tan solo los nuevos aspectos del mtodo, de
manera que seguir la misma estructura del documento para presentar su contenido, cuyos puntos
son los siguientes:

1 - Dependencia entre atributos
2 - Bucles de relaciones
3 - Relaciones reflexivas
4 - Eventos
5 - El mecanismo FSM
6 - Asignadores
7 - Creacin y eliminacin de instancias
8 - Modelo de procesos

*
Universidad de Vigo
Departamento de Lenguajes y Sistemas Informticos
Email: jbarros@uvigo.es
2

A continuacin har un resumen de cada uno de ellos.

1 - Dependencia entre atributos

Ya se hablaba de dependencia entre los atributos en la primera versin de OOA -Modeling
the World in Data- y en OOA91, al hacer referencia a la normalizacin o reglas de atribucin. Ahora
los autores definen con mayor precisin este tema al establecer tres tipos de dependencia entre los
atributos: funcional, estocstica y matemtica.
Existe dependencia funcional cuando se cumple la cuarta forma normal (4FN), a lo que los
autores denominan atribucin apropiada (proper attribution).
Cuando es posible inferir los valores ms probables de un atributo a partir del valor de otro -u
otros-, y no son parte del identificador, estamos en presencia de una dependencia estocstica.
La dependencia matemtica consiste en que el valor de un atributo puede obtenerse de los
valores de otros atributos mediante la aplicacin de una frmula o algoritmo -en tanto y en cuanto
estos atributos se encuentren en objetos separados, no se viola la cuarta forma normal-. OOA96
propone un indicador para este tipo de dependencia -se debe colocar (M) al lado del atributo-.

2 - Bucles de relaciones

En este punto se propone el anlisis de los bucles formados por las relaciones, que
eventualmente pueden encontrarse en los Diagramas de Estructura de la Informacin. Normalmente,
el modelador estudia estos bucles a fin de determinar si existe alguna relacin redundante.


Clase 1
Clase 2 Clase 3
R1 R2
R3



Figura VI.1: Bucle de relaciones.


En el caso de que as fuera, sera posible eliminar la redundancia, pero existen situaciones -
relaciones independientes- en las que con esta conducta se perdera informacin. En otras palabras,
mientras que en algunos casos sera posible determinar las instancias vinculadas entre s -por
ejemplo, las relacionadas por R1 en la figura VI.1- al observar el resto de las relaciones de un bucle,
en otros esto no sera factible.
Las relaciones independientes se formalizan de la manera habitual en el mtodo, por medio
de atributos referenciales, mientras que las relaciones dependientes deben marcarse con una "c" -
por constraint (restriccin)- al lado del atributo referencial cuyo valor depende del resto de las
relaciones, y se debe documentar esta restriccin.
Los autores consideran otras formas de relaciones dependientes, estableciendo la restriccin
mediante datos, a las denominan referenciales colapsados (collapsed referentials) y relaciones
compuestas (composed relations). Estas ltimas, que ya haban sido contempladas en OOA91, no se
formalizan por medio de atributos, debido a que ya existen los referenciales provenientes del resto de
las relaciones involucradas en el bucle.

3
3 - Relaciones reflexivas

Las relaciones reflexivas son aquellas que vinculan instancias de un mismo objeto. Al
enfrentarse a ellas, el analista debe determinar, a su vez, si son simtricas o asimtricas de manera
de modelar la realidad tal cual es.
Una relacin es simtrica cuando es posible intercambiar los objetos en los extremos de una
relacin y sta se sigue cumpliendo. El caso contrario corresponde a una relacin asimtrica.
En la primera versin de OOA consideraban las relaciones en las que su nombre en un
sentido es el mismo que en el inverso, y tambin las relaciones de un slo objeto. En OOA91 no se
hace referencia explcita al tema.
Las relaciones reflexivas simtricas se modelan incluyendo la multiplicidad, condicionalidad y
nombre de la relacin en un slo extremo de la lnea, mientras que las relaciones reflexivas
asimtricas se deben modelar por medio de la herencia.

4 - Eventos

En la primera version de OOA existen muy pocas referencias a los eventos. Tan slo se
puede observar una muy rudimentaria forma de denominarlos -con una "E" seguida de un nombre
mnemotcnico- y de documentarlos -con una tabla en la que se incluye el significado del evento y los
atributos asociados-. Esto cambia rotundamente en OOA91, en donde la mayor parte del libro se
dedica al tema.
En OOA96 se aumenta el formalismo al incorporar nuevas reglas, al modificar algunas de las
existentes, y al ajustar la notacin de los eventos.
Se incluye una nueva regla de notacin para la etiqueta de un evento no polimrfico -un
evento polimrfico es aquel que se dirige a una instancia de una superclase-, la que deber
comenzar con la letra clave del objeto destino; nuevas formas de sintaxis para describir los datos que
transporta un evento; un nuevo formato para la lista de eventos en base a la nueva sintaxis de los
eventos; se redefine la regla de los mismos datos (same data rule) a causa de esa misma sintaxis; se
establece que los eventos generados por una accin en un dominio deben ser recibidos nicamente
por instancias de ese mismo dominio; se incluye la regla para los eventos autodirigidos, los que
debern ser aceptados por la misma instancia antes que cualquier otro; se incorporan los eventos
polimrficos -los que, siendo dirigidos a una instancia de una superclase, sern recibidos por las
instancias de las subclases- detallando su definicin, notacin, reglas y forma de inclusin en el resto
de los modelos en los que intervienen.
Por otra parte, los autores previenen -aunque tericamente est permitido- contra la
modelacin de instancias con ms de un modelo de estados, por razones prcticas.

5 - El mecanismo FSM

La incorporacin de las modificaciones en los eventos recin descripta -sintaxis de los datos
de un evento, eventos polimrficos y mltiples instancias de un asignador-, provoca ciertos cambios
en el establecimiento del mecanismo de las FSM o Mquinas de Estados Finitos (Finite State
Machine). El resto contina como en OOA91.
En esta nueva versin de OOA, el mecanismo FSM debe llevar el control del estado en que
se encuentran las instancias que poseen modelos de estados, y los autores proveen los algoritmos
del mecanismo para el procesamiento de los eventos.

6 - Asignadores

Un concepto que no fue explicitado en OOA91, el de relaciones competitivas (competitive
relationships) lo es ahora en OOA96. Este caso se da cuando muchas instancias de un objeto eligen
simultneamente la misma instancia de otro. Estas relaciones se formalizan como condicionales en
ambos extremos.
El asignador (assigner) es un modelo de estados que se emplea para representar la creacin
de instancias de un objeto asociativo. En OOA91 se indicaba perteneciente al objeto asociativo,
mientras que ahora pertenece a la relacin competitiva vinculada al objeto asociativo.
La formalizacin de una relacin se realiza por medio de un atributo que indica la
disponibilidad (availability status) de la instancia para asociarse a otra y el envo de un mensaje al
asignador para informarlo acerca de este estado, quien realizar los pasos necesarios para
4
establecer la relacin. Uno de estos pasos ser "marcar" el estado de disponibilidad de cada
instancia asignada, que constituye la mejora en el protocolo del asignador con respecto a OOA91.
OOA96 incluye el concepto de asignadores mltiples (multiple asigners), o asignadores de
mltiples instancias, para modelar las relaciones competitivas que, a su vez, conforman un bucle de
relaciones dependientes.

7 - Creacin y eliminacin de instancias

En Modeling the World in Data, se defini muy bsicamente el significado del ciclo de vida de
una instancia, mientras que en la siguiente publicacin de los mismos autores, Object Lifecycles, fue
el tema central de la obra, como lo indica su ttulo. Obviamente fue considerada all la creacin y
eliminacin de instancias.
En OOA96 se incluyen nuevos axiomas y definiciones para regir la manera en la que las
instancias de un objeto nacen y mueren en el sistema.
El rigor se enfatiza en la definicin del inicio y de la duracin de la vida de las instancias; en
los estados y eventos que crean instancias; y en las instancias creadas o eliminadas en su propio
ciclo de vida o en otro diferente.

8 - Modelo de procesos

En este punto se establecen ciertas pautas a fin de dejar en claro algunos aspectos que no
fueron suficientemente explicitados en OOA91 para el Modelo de Procesos, en lo que respecta a los
datos transitorios (transient data); a los flujos de datos como parmetros actuales (actual parameters)
de un ADFD; a los ADFDs acclicos (directed acyclic graphs); a la limitacin en el acceso al atributo
de estado (state attribute) de una instancia; a la posibilidad de presentacin de los valores de los
atributos junto al nombre del atributo en los ADFDs; a una nueva notacin para los tems de datos
mltiples (multiple data items); a la definicin de los procesos base (base processes) para
representar invocaciones nicas y su parametrizacin; al ordenamiento de los conjuntos de datos
(ordered datasets) que ingresan a los procesos; al manejo de iteraciones y de procesos derivados; al
orden de llegada de los datos a los procesos; y a la notacin para la transferencia de control
interdominios y el procesamiento de una rama comn luego de la salida de un proceso condicional.
En esta actualizacin del mtodo se establecen cuatro tipos de procesos: para acceso
(accesors); generacin de eventos (event generators); transformaciones (transformations); y pruebas
(tests), junto a sus conceptos y notaciones.
Por ltimo se explicitan las dos formas de conexin de dominios: por medio de procesos
puente (bridging process) que existen en un dominio y se invocan desde un ADFD en otro dominio; y
eventos que cruzan dominios (domain-crossing events).

Estos cambios no tienen otro objetivo que el de consolidar el rigor del mtodo y mejorar su
caracterstica principal, la de ser traducible. En este punto radica uno de los aspectos ms
sobresalientes de OOA96, o por lo menos uno de los cuales est siendo objeto de discusin en la
actualidad, y se impone como un argumento importante a su favor.
OOA96 es un mtodo que tiene bases muy slidas y objetivos claros. Se mantiene dentro de
la lnea de los mtodos orientados a las caractersticas de los objetos, prestando una buena atencin
al comportamiento, aunque por la inclusin de la teora relacional -que justamente es el fundamento
de la rigurosidad matemtica del mtodo- puede ser desatendido por muchos dentro de la
comunidad de la orientacin a objetos.
Sin embargo, a fuerza de resultados y por su amplia gama de aplicabilidad, seguramente
seguir mantenindose entre los mtodos de anlisis ms utilizados.


B - El Lenguaje de Modelacin Unificado de Booch, Rumbaugh y Jacobson

Aunque el nombre The Unified Modeling Language se supona tentativo, su uso y difusin fue
la causa de su establecimiento definitivo. Al principio se denomin El Mtodo Unificado (The Unified
Method), a modo de nombre inicial para el proyecto.
Los primeros pasos hacia la unificacin los dio Grady Booch, a quien se uni Jim Rumbaugh
en octubre de 1994. Ellos ya haban incorporado las ideas de ambos en sus respectivos mtodos, lo
que se puede observar en la segunda edicin del libro de anlisis y diseo de Booch y en la segunda
5
versin de OMT -conocido como OMT 2- de Rumbaugh. Tambin los dos autores haban comenzado
a incluir los casos de uso de Ivar Jacobson.
Ms tarde, el mismo Jacobson se uni a Booch y a Rumbaugh, durante 1995, con lo que la
versin final del mtodo, inicialmente estimada para mediados de 1996, se postergar por unos
meses -se espera una versin completa del metamodelo a comienzos de 1997-, aunque est
previsto contar, para fines de 1996, con el trabajo que se presentar al Object Management Group
[2] a fin de lograr su estandarizacin.
El presente trabajo se basa, principalmente, en la versin 0.8 del mtodo, en ese entonces
Mtodo Unificado, que est compuesto por una serie de documentos propiedad de Rational Software
Corporation y elaborada por Booch y Rumbaugh, cuando todava no se contaba con la incorporacin
oficial de Ivar Jacobson [3]. El mtodo se elabor para OOPSLA '95 a partir del anuncio que ambos
autores realizaran en la misma conferencia del ao anterior. Otra fuente es la documentacin de la
versin 0.9, addendum de la versin 0.8 citada, elaborada por Booch, Rumbaugh y Jacobson, y
hecha pblica a principios de julio de 1996 [4].
Los objetivos principales, que se establecen en el inicio del documento, consisten en
elaborar "un mtodo para especificar, visualizar, y documentar los artefactos de un sistema orientado
a objetos en desarrollo" [5]. Si bien est previsto proponer un mtodo, la principal finalidad consiste
en elaborar un lenguaje comn -aunque grfico, lenguaje al fin- que permita describir todos los
mtodos, incluso para sistemas de tiempo real, distribuidos, y otros. Esta fue una de las causas del
cambio en la denominacin del UML.
Un objetivo subyacente es el de establecer un mtodo "abierto", es decir, que no sea
propiedad exclusiva de Rational, puesto que la tendencia mundial marcha en el sentido opuesto a
todo aquello que sea "propietario". De hecho, en la versin 0.9 dejan expresado claramente que "el
UML es un estndar abierto; no es un lenguaje propietario de Rational" [6].
El UML est basado en la unificacin del mtodo de Booch, de OMT y de OOSE, y en los
conceptos extrados de otros autores, entre los que se encuentran Peter Coad, David Embley, Eric
Gamma, David Harel, Shlaer y Mellor, Bertrand Meyer, Kenneth Rubin, Rebecca Wirfs-Brock,
Edward Yourdon y James Odell, y a los que se les pueden sumar muchos ms an a partir de la
invitacin para el aporte de ideas que los autores del mtodo hacen al resto de los metodologistas, a
la comunidad usuaria y a todos aquellos que deseen contribuir para la construccin de un mtodo
estndar, realmente "unificado".
Los mismo autores consideran al UML como el sucesor inmediato y natural de los mtodos
de Booch, Objectory y OMT -incluso Rumbaugh lo considera la versin 3 de OMT y del mtodo de
Booch-, y por tal motivo, es necesario slo un muy pequeo esfuerzo para realizar la transicin de
uno de estos mtodos al UML. Este "pequeo esfuerzo" no consiste en incorporar ms complejidad
en los conceptos o herramientas, sino todo lo contrario, puesto que el UML es ms claro, coherente y
simple.
Adems de herramientas automatizadas -que actualmente existen varias en desarrollo-,
manual de referencia, ejemplos de uso, etc., muchos de estos elementos an incompletos, el UML
consta de tres partes principales: un metamodelo formal, la notacin del mtodo y un conjunto de
idiomas de uso.

a - El Metamodelo Unificado

El Metamodelo se desarroll para poder realizar una exposicin clara, sin ambigedades, de
los conceptos e ideas, de la sintaxis y de la semntica del UML. Se estableci para definir al UML, no
para ensearlo, tarea que corresponder al manual de referencia y a otros documentos. Por otra
parte, es una versin completa, aunque no definitiva.
Fue necesario que se establecieran algunas pautas que guiaran e inspiraran una idea rectora
para la elaboracin del metamodelo. Principalmente porque el objetivo consiste en poder definir por
medio de l a todos los mtodos de anlisis y diseo, lo que requerir tener en cuenta muchos
aspectos que permitan abarcar a todos, pero que a la vez podra aumentar la complejidad del
metamodelo. Es as que se tom como gua la idea de que "si usted debe elegir entre submodelacin
y sobremodelacin, elija submodelar y adicionar un comentario textual" [7].
Una de las caractersticas que se determinaron para este modelo -un metamodelo es, en
definitiva, un modelo, pues, aunque parezca un trabalenguas, se emplea para modelar modelos y
ms an, el metamodelo se puede emplear para definir... al metamodelo mismo- fue la de incorporar
ciertas notaciones y conceptos de los principales lenguajes de programacin. Los casos particulares
que se pudieran presentar slo en algunos lenguajes, como por ejemplo, el nivel de ocultamiento de
la informacin protected de C++, podran ser dejados de lado si no fueran necesarios. Los aspectos
6
ms dependientes de los lenguajes se manejan como strings y el metamodelo permite manipularlos,
pero sin interpretarlos, considerndolos justamente como uninterpreted.
No debe entenderse que con el uso de la sintaxis de un lenguaje de programacin se pierda
cierto grado de abstraccin en el anlisis, puesto que es indistinto el empleo de una u otra forma, por
ejemplo, para documentar la descripcin de un atributo. Si bien es necesario contar con una
perspectiva general, tambin es importante tener en cuenta la posibilidad de desarrollar sistemas con
tecnologas en particular tales como CORBA, por ejemplo.
El metamodelo incluye la descripcin textual y grfica de todos los elementos que utiliza para
la modelacin y un diccionario en el que incluye la definicin de todos los trminos que se emplean
en l.


DeclDeClase
Atributo
Operacin
Atributo:tipo
propiedades de diseo
.......
propiedades del lenguaje
.......
lista de param: ......
resultado: ......
*
*
1 1
AtributoDeClase Operacin DeClase
atributos {ordenado}
Operaciones
{ordenadas}
0..1
*
Anidada
Atributo:tipo
propiedades de diseo
.......
propiedades del lenguaje
.......
Miembro
nombre: ......
mbito: {......}
propiedades de diseo
.......
propiedades del lenguaje
.......



Figura VI.2: Vista parcial del metamodelo para un
Diagrama de Clases [8].



b - La notacin unificada

La notacin se podra haber descripto a travs del metamodelo, en lugar de incluirla en un
documento aparte, pero como los mismos autores expresan, aqul se hubiera tornado redundante y
hara dependientes de l a las herramientas grficas que lo quisieran implementar. Esto ira en
contra de lo que los autores pretenden, ya que para ellos, el UML debera poder ser soportado por
diversas herramientas, y consideran que no habra inconvenientes en que la notacin se pudiera
representar de diferentes formas. El documento consta de la descripcin, aunque no detallada, de los
grficos que se emplean en el UML.
En la documentacin del Mtodo Unificado versin 0.8 se describen los siguientes
diagramas:

1 - Diagrama de Casos de Uso (Use-case Diagram)
2 - Diagrama de Clases (Class Diagram)
3 - Diagrama de Traza de Mensajes (Message Trace Diagram)
4 - Diagrama de Mensajes de Objetos (Object Message Diagram)
5 - Diagrama de Estados (State Diagram)
6 - Diagrama de Mdulos (Module Diagram)
7 - Diagrama de Plataforma (Platform Diagram)

7
Algunos de los nombres de estas herramientas fueron cambiados. Actualmente, la versin
0.9 del mtodo incluye los siguientes diagramas, que se corresponden con los anteriores siguiendo
la misma numeracin:

1 - Diagrama de Casos de Uso
2 - Diagrama de Clases
3 - Diagrama de Secuencias (Sequence Diagram)
4 - Diagrama de Colaboracin (Collaboration Diagram)
5 - Diagrama de Mquina de Estados (State-machine Diagram)
6 - Diagrama de Componentes (Component Diagram)
7 - Diagrama de Despliegue (Deployment Diagram)

Los requerimientos del usuario se establecen por medio del Diagrama de Casos de Uso; la
visin esttica del sistema se representa a travs del Diagrama de Clases; el enfoque dinmico,
empleando el Diagrama de Mquina de Estados; el modelo operacional por medio del Diagrama de
Secuencias y del Diagrama de Colaboraciones; y la arquitectura del sistema utilizando el resto.
El Diagrama de Casos de Uso es el mismo que se encuentra en Objectory y se representa
casi de la misma forma en la que se expone a travs de OOSE, aunque reemplazando los conos de
personas, con los que Jacobson simboliza los actores, por hexgonos, que corresponde a la
notacin que en el UML se utiliza para los objetos. Esta herramienta est orientada a que se emplee
en el comienzo del proceso de desarrollo. A partir de los casos de uso, se obtendrn los objetos que
permitirn componer las diferentes vistas del modelo con las herramientas del UML.


Actor 1
Actor 3
Actor 5
Actor 4
Actor 2
Caso de
uso 1
Caso de
uso 2
Caso de
uso 3
Caso de
uso 4
Sistema



Figura VI.3: Diagrama de casos de uso.


El Diagrama de Clases, como sucede en OMT y los mtodos tradicionales, presenta un
enfoque esttico del sistema. La notacin, que es la misma que se utiliza en OMT, fue enriquecida
con los aportes del diagrama de clases del mtodo de Booch, en lo que respecta a la inclusin de
nuevos tipos de relaciones. Con estos diagramas se representan las clases y los objetos,
pudindose mezclar ambos en un mismo grfico, aunque tambin contemplan el uso de Diagramas
de Objetos (Object diagrams) para modelar slo a estos ltimos.
Adems de algunas pequeas variaciones en la notacin -que se puede observar en la figura
VI.2-, los Diagramas de Clases incorporan nuevos conceptos, en relacin con los que presenta OMT,
tales como plantillas (templates), que son clases parametrizadas; utilitarios (utilities), que son grupos
de atributos y operaciones globales del sistema; grupos de objetos (multiobject), que se simbolizan
por medio de un conjunto de hexgonos superpuestos; asociaciones "o" (Or-associations), que
permiten establecer que cada objeto puede participar de slo una de todas las relaciones, unidas por
8
esta notacin, en las que intervenga la clase a la que pertenece; distingue las clases de una
asociacin (association class), que pueden contener atributos, comportamiento y nuevas
asociaciones, de los atributos de una asociacin (association attribute), que son slo atributos;
contemplan diferentes tipos de agregacin y de herencia; permite establecer el sentido de
navegacin de las relaciones (navegability), que indica la forma en la que stas se deben atravesar,
y as orientan su diseo; consideran tambin atributos o relaciones redundantes; incorporan las
categoras (Categories), equivalentes al concepto de subsistema -aunque, si bien las categoras
generalmente corresponden a los subsistemas, esto no sucede siempre-, que representan las partes
en que se subdivide un sistema -aunque tambin una categora puede representar al sistema
completo- para administrar su complejidad y organizar su estudio, y establece distintas formas de
representacin grfica, incluyendo los Diagramas de Interfaz de Categoras (category interface
diagram), en los que se representa cada categora con sus clases y relaciones pblicas, aunque
tambin utilizan el concepto de subsistema como equivalente al de categora lgica, pero en el
mbito de la implementacin fsica del sistema; e incorporan los compuestos (composites), concepto
extrado de OSA (Embley), que representan agregados de objetos y sus relaciones, y que se ponen
de manifiesto una vez que la clase es instanciada.
El Diagrama de Secuencias, antes denominado Diagrama de Traza de Mensajes, es una
herramienta que se puede encontrar en los mtodos de cada uno de los autores (figura VI.4).
Corresponde al Diagrama de Traza de Eventos de OMT, al Diagrama de Interaccin de OOSE, y al
tambin denominado Diagrama de Interaccin del mtodo de Booch, quien considera que su
herramienta es una generalizacin de las otras dos. El cambio en la denominacin responde al
deseo de establecer un nombre ms genrico, puesto que con ella se pretende modelar no slo
eventos.


Objeto 1
Objeto 2 Objeto 3
(1)
(2)
(3)


(1) Inicio de un mtodo; (2) Recursin; (3) Destruccin de un objeto


Figura VI.4: Diagrama de Secuencias.


El Diagrama de Colaboracin, cuyo nombre antes fuera Diagrama de Mensajes de Objetos,
corresponde al Diagrama de Objetos de Booch, slo que ahora se emplea la notacin de los objetos
del UML en lugar de las nubes [9] de aquel mtodo, y la convencin que propone el mtodo Fusion
9
[10] para la numeracin de los mensajes (figura VI.5). Es una forma distinta de representar lo que
muestra un Diagrama de Secuencias. La diferencia entre ambos es que con los Diagramas de
Secuencias se puede apreciar a simple vista la ocurrencia temporal de los eventos, ya que son
graficados en el orden en que se producen, mientras que con los Diagramas de Colaboracin se
intenta poner de manifiesto, principalmente, las relaciones existentes. Est prevista, tambin, la
representacin de la concurrencia de los objetos mediante los Diagramas de Mensajes de Objetos
Concurrentes (concurrent object message diagram), seguramente ahora denominados Diagramas de
Colaboracin Concurrentes a partir de la version 0.9 del UML.


Objeto 1 Objeto 2
1:f(x)



Figura VI.5: Diagrama de Colaboracin.


Los Diagramas de Secuencia y los de Colaboracin se denominan, conjuntamente,
diagramas de interaccin (interaction diagrams), por tener la misin de representar justamente este
aspecto del modelo.
Como notacin para los Diagramas de Estados, fue adoptada la propuesta por David Harel -
que se puede observar en OMT-, a la que se incorporan pequeas modificaciones, entre otras, del
enfoque de Shlaer y Mellor -aunque en el UML se siguen manteniendo las operaciones a la entrada y
a la salida de los estados como propone OMT, mientras que en Shlaer y Mellor slo existe una
operacin por estado y slo en los estados- y del SSADM (Structured Systems Analysis and Design
Method).
El origen de los Diagramas de Componentes, que fueran propuestos bajo el nombre de
Diagramas de Mdulo en la version 0.8 del UML, salta inmediatamente a la vista, pues en ellos se
emplean los conos correspondientes a los gradygramas o diagramas de Booch (figura VI.6). Esta
herramienta, que ya no pertenece al mbito de representacin lgica de los elementos del sistema,
como sucede con las anteriores, se emplea para especificar la asignacin fsica de las clases a los
diferentes ficheros, como as tambin sus dependencias, indicando la secuencia de compilacin. De
esta manera es posible, entonces, representar la arquitectura del sistema.


Mdulo 1
Mdulo 2
dependencia de
compilacin



Figura VI.6: Diagrama de Componentes.
10


Otra de las herramientas que contiene la notacin grfica extrada del mtodo de Booch -
especficamente, del Diagrama de Procesos en el mtodo original-, y que tambin se emplea para
especificar una visin fsica del sistema, en este caso la topologa, es el Diagrama de Despliegue,
nueva denominacin para la herramienta anteriormente conocida como Diagrama de Plataformas
(figura VI.7).


PC
1
PC
*
Servidor
1
Impresora
*



Figura VI.7: Diagrama de Despliegue.


Los autores dejan librado a la eleccin de quienes empleen el mtodo, la posibilidad de
incorporar nuevas herramientas, que complementen, aumenten o expliquen lo que este conjunto
propuesto es capaz de modelar. Tambin consideran la posibilidad de que los usuarios del mtodo
incluyan otros aspectos grficos que resalten la conceptos especificados por la notacin del UML.
Por ltimo, en la documentacin de la versin 0.8 incluyen una plantilla para la especificacin
de los procesos representados en los diagramas, y una comparacin de las notaciones del UML,
OMT y del mtodo de Booch, a fin de establecer las equivalencias entre ambas, y el esquema
tentativo de la estructura que poseern la gua del usuario y el manual de referencia del mtodo.
Como se puede observar, todava no est definido el proceso de modelacin, sino tan slo
sus elementos constituyentes. Pero esto es as ex profeso, ya que los esfuerzos estn orientados,
principalmente, a la elaboracin de un estndar que permita representar la realidad desde diferentes
puntos de vista y pueda ser aplicable en distintos mbitos. De esta manera, en funcin de las
necesidades de modelacin para un caso en particular, sera posible adoptar las herramientas que
mejor se adapten a esa situacin y ellas estaran perfectamente definidas, principalmente, por medio
del metamodelo, ms all de que se provea la notacin grfica separadamente.
En la versin 0.9, el UML incorpora el concepto de estereotipo (stereotype), trmino
propuesto por Rebecca Wirfs-Brock y concepto que Jacobson incluyera en Objectory en 1987, al
incluir los tres diferentes tipos de objetos a su mtodo (objetos de interfaz, de entidad y de control),
aunque ahora se presenta mucho ms generalizado. Los estereotipos poseen propiedades definidas,
entre las que se encuentran la multiplicidad, concurrencia y persistencia de una clase, e incluso para
generacin de cdigo, entre otras.
Este concepto permiti mejorar la exposicin del UML, dndole un grado ms amplio de
generalizacin, posibilitando la incorporacin futura de nuevas ideas que an no hubieran sido
tomadas en cuenta y que podran aparecer posteriormente, y hacindolo ms consistente y simple.
Por otra parte, tambin sirvi para acoplar los conceptos de Jacobson a la estructura ya existente de
la versin 0.8 del UML.
Los autores establecen dos clases de estereotipos: aquellos que incluyen semntica
(estereotipos de evento, excepcin, interfaz, metaclase, utilidad, proceso e hilo -thread-) y son
conceptos clave del UML; y los que no incorporan nueva semntica (estereotipos de paquete, nodo y
tipos de objeto).
Un aspecto interesantsimo que se puede observar en la versin 0.9 es el del establecimiento
de la interfaz (interface) de una clase. De acuerdo a la terminologa propuesta, cada clase puede
11
conformar (conforms) una interfaz de acuerdo al rol (role) de cliente (client) o de proveedor (supplier)
de un servicio. Adems incluyen los conceptos de distribucin y concurrencia, conjuntamente con su
notacin, y semnticas de tiempo real.
Existen algunas modificaciones sintcticas con respecto a lo que se propone en la versin
0.8, entre las que se encuentran la nueva notacin para los estereotipos; la notacin para la herencia
simple y mltiple; la notacin de las clases abstractas; la representacin del sentido de navegacin
de las relaciones en los diagramas de clases; la inclusin de condicionalidad en los diagramas de
colaboracin y de secuencias para permitir su empleo para la representacin de patrones.
Entre las modificaciones conceptuales se observa el reemplazo de las categoras y
subsistemas por los paquetes (packages). En lugar de utilizar dos trminos diferentes para
representar un mismo concepto en los planos lgico y fsico, emplean uno slo y con una nueva
notacin grfica. Otro nuevo concepto es el de nodo (node), que reemplaza a los de procesadores
(processors) y dispositivos (devices) -que en la versin 0.8 representaban a unidades con capacidad
de procesamiento y sin esta capacidad respectivamente, a la manera del mtodo de Booch-, y que
emplea un nico smbolo grfico para su representacin.
Hay ciertas consideraciones que dejan libradas a un estudio ms profundo. Tal es el caso de
la notacin para los elementos a diferente nivel de abstraccin -establecieron la notacin de clase y
su correspondencia a nivel fsico, el objeto, pero no hicieron lo mismo con todos los elementos del
UML-; la traza (traceability) de un elemento en un modelo a su equivalente -o equivalentes- en los
dems; y el empleo de patrones de modelacin.
Tambin, y en base a los logros probados del mtodo de Wirfs-Brock, consideran el empleo
de las responsabilidades como un aspecto prioritario del mtodo, o como les gusta expresar
grficamente al considerarlas ciudadanos de primera clase (first-class citizens) del UML.
Por ltimo, hacen mencin los pasos que quedan pendientes: dejar en claro los puntos que
an son tentativos, incursionar un poco ms en cuanto a las tareas y operaciones y otros puntos,
publicar el resto de los documentos que compondrn al UML, y su propuesta cmo estndar ante el
OMG.
Sin lugar a dudas, el principal objetivo del UML se cumplir rotundamente: convertirse en un
estndar. Y esto se debe a dos hechos fundamentales: la unin de los tres autores y las
caractersticas intrnsecas del UML.
Con la unin entre Booch, Rumbaugh y Jacobson no slo se logra acaparar la atencin de
todos aquellos que los seguan en forma individual, sino tambin de quienes se podran encontrar un
tanto confusos con respecto a la decisin de optar por un enfoque orientado a las caractersticas de
los objetos o hacia aqul que enfatiza el comportamiento; y una vez dentro de alguna de estas
corrientes, con el problema de elegir un mtodo entre todos los existentes. Ahora, al unificar los
criterios y mtodos de ambos enfoques, solucionan en gran medida esta situacin.
Por otra parte, no puede negarse que nos encontramos frente a tres de los metodologistas
ms importantes de los ltimos tiempos, y las expectativas por los resultados de la unificacin de sus
criterios seguramente sern satisfechas al mximo.
En cuanto al UML, podemos notar que se trata de un material completamente distinto a todo
lo que cualquier autor haya presentado hasta el momento en materia de anlisis orientado a objetos -
an cuando se note un cierto "sabor" al mtodo de Booch-. Y quien, como yo, tenga en sus manos el
conjunto de documentos que lo componen, no puede menos que entusiasmarse con la propuesta.
Pero debe quedar en claro que mi principal satisfaccin est centrada en el hecho de contar
con una excelente exposicin de lo que significa el anlisis de sistemas: poseer un enfoque de la
realidad que permita entenderla tal cual es, producto de la orientacin a objetos; un conjunto de
herramientas que posibiliten representarla fielmente; y la conviccin de que el mtodo debe ser
propuesto por la realidad misma.


C - OBA de ParcPlace-Digitalk

Los primeros pasos de OBA, Object Behavior Analysis, fueron dados inicialmente por
Elizabeth Gibson en los comienzos de la dcada de los '90, cuando perteneca a la empresa
ParcPlace Systems, Inc. Posteriores desarrollos se deben principalmente a Kenneth Rubin y a Adele
Goldberg, que a partir de 1992 lo presentaron en varias oportunidades como OBA/D. Luego Rubin
deja el proyecto, y en su lugar se incorpora Rebecca Wirfs-Brock, en la nueva etapa de la empresa,
ahora denominada ParcPlace-Digitalk por la fusin entre ParcPlace Systems, Inc. y Digitalk, Inc. en
agosto de 1995.
12
Esta parte del trabajo la desarroll en base a la exposicin de OBA/D que hiciera Kenny
Rubin en Buenos Aires, en noviembre de 1994, con el material que, a su vez, presentara en
OOPSLA de ese mismo ao, y a partir de la gua del usuario [11] y del manual de referencia [12] de
la herramienta de ParcPlace que soporta el mtodo.
En OBA existe un proceso de desarrollo perfectamente definido y con herramientas que lo
automatizan, pero su alcance llega a la etapa de anlisis. MethodWorks es una herramienta que
contempla la fase de anlisis de OBA, aunque el mtodo fue presentado, en varias oportunidades y
en diversos congresos, incluyendo diseo, esto es, bajo la denominacin OBA/D.
Como su nombre lo indica, OBA es un mtodo que realiza una modelacin orientada al
comportamiento de la realidad y hace "especial hincapi en la cooperacin entre objetos, ms que en
extraer los objetos de la terminologa del dominio" [13]. Se inicia a partir del establecimiento de los
requerimientos -ya que no parte de la necesidad de contar con una especificacin de requerimientos
completa- desde la perspectiva del uso del sistema que har el usuario, al estilo de OOSE. Es ms,
directamente emplea casos de uso como herramienta inicial, por lo que los conceptos principales de
esta etapa son equivalentes a actor y caso de uso de OOSE, pero que en OBA se denominan rol y
responsabilidad (en OOSE una persona se puede instanciar en varios actores, esto es, puede
ejecutar varios roles, mientras que en OBA un actor -equivalente al concepto persona de OOSE-
puede ejecutar varios roles diferentes). Por lo tanto, a partir de ahora emplear la denominacin
propuesta por OBA, en lugar de utilizar los ya tradicionales trminos "actor" y "caso de uso".
OBA emplea el concepto de escenario de uso (use scenario). Existe una diferencia sutil entre
un caso de uso, al estilo OOSE, y un escenario, la que lleva a que no los considere estrictamente
equivalentes. Un escenario describe, de forma narrativa, cmo se usa un sistema, en el que pueden
encontrarse diversos roles (o actores) desencadenando acciones. El escenario luego se subdivide, a
fin de separar el comportamiento en funcin de cada uno de los roles que se observan en el
escenario, especificando, de esta manera, las responsabilidades que corresponden a cada rol. Por
otra parte el caso de uso describe el comportamiento desde la perspectiva particular del actor
responsable de iniciarlo, es decir, el comportamiento observado en la realidad ya se encuentra
subdividido, por lo que cada caso de uso de OOSE equivale, entonces, a una responsabilidad de
OBA ms que a un escenario.
Ya coment que la realidad descripta por los casos o escenarios de uso debe estructurarse
con otras herramientas que la modelen desde una perspectiva de objetos. Para ello, los autores
definen dos tipos de roles, iniciador (initiator) y participante (participant) y dos tipos de
responsabilidades, accin (action responsibility) y servicio (service responsibility).
El iniciador es el rol de quien desarrolla una accin a la que se deber responder por medio
de otra. El participante es el rol de quien da respuesta a la accin del iniciador, por medio de un
servicio. Podemos observar que al estructurar el comportamiento de esta manera, adems de
asignarse las responsabilidades, tambin se describen las colaboraciones entre objetos, en este
caso, entre quienes llevan a cabo los roles de iniciador y participante.
Cada colaboracin se denomina contrato (contract). Los autores prevn tres formas tpicas
de contrato, las que se observan cuando un iniciador provee informacin y el participante la acepta;
cuando un iniciador solicita informacin al participante y ste la otorga; y cuando el iniciador solicita
un servicio y el participante lo provee.
Esta forma estructurada de descripcin del comportamiento, establecida en funcin de las
cuatro partes descriptas, se denomina guin (script), aunque por su difusin, mantendr el trmino
en ingls.
Existen dos tipos de scripts: los que responden a eventos externos (event scripts) y, los ms
comunes, aquellos que representan el desempeo de una tarea (responsibility scripts). Ellos pueden
ser expresados con diferente grado de detalle -en un nivel ms general (superscripts) o ms
detallado (subscripts)- y ser vinculados por medio de una referencia (script reference). A su vez, a los
scripts de eventos se les deben definir los precontextos (precontexts) y los postcontextos
(postcontexts), que corresponden a los estados iniciales y finales, antes y despus de que se ejecute
el script, respectivamente.
Otro de los aspectos que se debe identificar, y que es parte de los principales conceptos de
OBA, corresponde a la definicin de las reglas (rules). Su estructura es la de las condiciones
"if/then/else", en la que las alternativas son comportamientos. Es preciso identificar la condicin y
establecer la accin que se debe llevar a cabo si su resultado es el valor booleano "verdadero".
Luego es necesario especificar el comportamiento a desarrollarse en caso de un resultado de valor
"falso" en la condicin. Tanto la condicin, como los comportamientos alternativos, se representan
por medio de scripts.
13
Los flujos de control (control flows) determinan la secuencia en la que debe llevarse a cabo el
comportamiento del sistema. OBA considera seis tipos de flujos de control: secuencialidad
(sequentiality), que implica que el comportamiento se debe llevar a cabo uno tras otro; iteracin
(iteration), que corresponde a una repeticin del comportamiento; seleccin (selection), que
determina la ejecucin de slo una parte del comportamiento; paralelismo (paralelism), que
corresponde a comportamientos concurrentes; y opcionalidad (optionality), que establece la
posibilidad de que cierto comportamiento no se lleve a cabo.
Otro de los principales conceptos del mtodo es el de evento (event), equivalente al de
estmulo de OOSE, y que da origen a los scripts de eventos. Cada evento cruza los lmites del
sistema (este ltimo es otro de los conceptos que OBA define como primordiales) en un sentido u
otro.
El proceso de anlisis est constituido por nueve pasos o etapas principales, las que, a su
vez, pueden dividirse en subetapas. El esquema del mtodo de anlisis propuesto, junto a los
productos del proceso, es el que se muestra en la figura siguiente.

1 - Determinar los comportamientos principales
2 - Organizar los comportamientos principales
3 - Normalizar los requerimientos
4 - Desarrollar el Modelo de Scripts
5 - Establecer un vocabulario comn
6 - Desarrollar el Modelo de Colaboracin de Roles (Role Collaboration Model)
7 - Desarrollar el Modelo de Relacin Semntica de Roles (Role-Semantic-
Relationship Model)
8 - Desarrollar el Modelo de Referencia de Scripts (Script Reference Model)
9 - Desarrollar el Modelo de Contexto de Script (Script Context Model)

Voy a referirme brevemente a cada uno de ellos a continuacin:

1 - Determinar los comportamientos principales

Como ya expres, OBA no pretende contar con la totalidad de los requerimientos
establecidos al inicio del proceso de anlisis. Por supuesto que es necesario partir de la propuesta
del usuario, ya sea expresada en forma verbal, escrita o por medio de documentacin grfica, pero
estos requerimientos iniciales sern slo una parte, ya que el resto se obtendr por medio del
empleo de las herramientas y tcnicas del mtodo.
Los elementos recopilados en esta etapa son los escenarios de uso, que describen la forma
de utilizacin del sistema, los eventos, que establecen los lmites del sistema, y las
responsabilidades ms importantes, provenientes de lo que debe llevar a cabo el sistema, de los
objetivos de la entidad en estudio, de las mejoras que desea incorporar el usuario, etc.

2 - Organizar los comportamientos principales

El paso siguiente consiste en subdividir el problema a fin de permitir una reduccin de su
complejidad, y as facilitar su interpretacin, y para organizar las tareas del equipo de anlisis.
Aunque esta subdivisin puede no ser definitiva, es necesaria en este momento del proceso de
anlisis por los motivos expuestos.

3 - Normalizar los requerimientos

Junto a la etapa anterior, es una de las principales para poder comenzar con la modelacin
de la realidad. Este es el momento de definir fuertemente los requerimientos dbilmente
establecidos, aclarar dudas, corregir, ampliar o eliminar los requerimientos, revisar si el relevamiento
est completo e incorporar los aspectos que puedan haber quedado olvidados, mantener el
adecuado nivel de abstraccin dejando de lado los puntos que dependen de una implementacin
fsica en particular, para atenderlos en la etapa de diseo, entre otras actividades.
Acto seguido se debe proceder a estructurar los requerimientos, de acuerdo con su tipo,
mediante las tcnicas de scripting para los escenarios de uso, eventos, condiciones -previa
estructuracin en la forma if/then/else- y responsabilidades, y dems tcnicas para reglas y datos.

4 - Desarrollar el Modelo de Scripts
14

Este paso consiste en escribir concretamente los scripts a partir de los requerimientos que
fueron estructurados en el paso anterior.
El conjunto de scripts del sistema, denominado Modelo de Scripts, especificar tambin el
flujo de control y los vnculos entre super y subscripts.


El cliente solicita un artculo el Vendedor provee el artculo
Iniciador Accin Participante Servicio



Figura VI.8: Script.



5 - Establecer un vocabulario comn

A fin de evitar inconvenientes en la interpretacin de los conceptos incluidos en el modelo, es
importante definirlos explcitamente. Para este propsito es que se elabora un glosario que incluye la
definicin de los elementos del modelo y los trminos que se emplean corrientemente en el dominio
del problema.
Esto posibilitar un acuerdo entre los usuarios y los analistas, ya que los primeros definirn
exactamente qu entienden por cada concepto, y evitar redundancias en el modelo.

6 - Desarrollar el Modelo de Colaboracin de Roles

Este modelo permite visualizar las responsabilidades que corresponden a cada rol, como as
tambin, las colaboraciones existentes entre ellos, como presentan los modelos de interaccin de los
otros mtodos.
Con esta herramienta se puede analizar si la asignacin de responsabilidades es la correcta,
si existe una desproporcin en el origen o destino de las colaboraciones, si las colaboraciones son
adecuadas, si es lgico que un rol sea iniciador, participante o ambos en el modelo, etc.
Aunque no define expresamente cul es el comportamiento que responde, en calidad de
servicio, a cada accin de un iniciador -pues esto est definido en el Modelo de Scripts-, se indica el
nmero de colaboraciones existentes entre los roles y su sentido.
Una representacin grfica del modelo [14] podra ser como se muestra a continuacin:


Rol 1
responsabilidades
Rol 4
responsabilidades
Rol 3
responsabilidades
Rol 2
responsabilidades
2
1 2
1



Figura VI.9: Representacin grfica del Modelo
de Colaboracin de Roles.



7 - Desarrollar el Modelo de Relacin Semntica de Roles

15
Ahora es el momento de realizar una reclasificacin de los roles, revisar si distintos roles
corresponden a un mismo concepto, y establecer las estructuras de herencia o de agregacin que
pudieran existir entre ellos. Hay que analizar revisar aquellos que comparten responsabilidades, de
manera de poder evaluar si existe herencia, y observar si los roles de los subscripts pueden ser parte
de los roles de los superscripts, de modo de detectar una posible relacin "todo-parte".
Este proceso aportar los beneficios de eliminacin de redundancias y aumento del
conocimiento de la realidad que brinda el modelo.

8 - Desarrollar el Modelo de Referencia de Scripts

Las referencias de scripts se detallan en este modelo -anteriormente era denominado Modelo
de Composicin de Scripts (Script-Composition Model)-, mediante la presentacin de una lista de
todos los scripts de primer nivel: eventos y superscripts. Abajo de cada uno de ellos se listan los
subscripts correspondientes, identificados por medio de sangra.
Este procedimiento permitir completar y corregir el modelo al visualizar los scripts
redundantes; los scripts que son susceptibles de generalizacin; los que requieren mayor detalle; los
que faltan; los que no poseen relacin con otros, a fin de determinar si es correcta su inclusin en el
modelo; los que inician una cadena de scripts y no son eventos; y otros.

9 - Desarrollar el Modelo de Contexto de Scripts

Tambin fue corregida la denominacin para este modelo, ya que anteriormente era
presentado como Modelo Dinmico del Sistema (System-Dynamic Model). Con su construccin
finaliza la etapa de anlisis de acuerdo con la propuesta del mtodo.
Los scripts de eventos no estn referenciados entre ellos hasta el momento, y hacerlo es la
tarea correspondiente para la construccin del modelo. Esta vinculacin se realiza por medio de los
contextos, previos o posteriores, que no son otra cosa que los estados de los que parte y a los que
arriba cada evento.
El resultado final ser el detalle de cada script de evento con sus respectivos pre y
postcontextos. Es posible utilizar un diagrama tradicional de transicin de estados a fin de
representar grficamente el modelo.
Con este paso culmina la modelacin propuesta en OBA.

La etapa de diseo an no est totalmente definida. En principio, los puntos que contempla
son:

1 - Adoptar una arquitectura que soporte al sistema.
2 - Pasar los roles del anlisis a roles del diseo.
3 - Extender los modelos del anlisis con consideraciones de diseo.
4 - Elegir una arquitectura para la implementacin.
5 - Crear un Modelo de Objetos (Object Model) con los modelos extendidos y la
arquitectura de implementacin.

Como se puede observar, el mtodo est basado en un conjunto de herramientas
estrictamente textuales, que se encuentran automatizadas a travs de MethodWorks de ParcPlace
Systems, Inc. Los pocos grficos que se incluyen provienen del material con el que Rubin realizara
su presentacin en OOPSLA '94, pero que no se observan en el producto mencionado.
Ms all del xito que, como esgrimen sus autores, proporciona este enfoque, creo que se
otorgan demasiadas ventajas por la no incorporacin de herramientas grficas -aunque esto pone de
manifiesto, de algn modo, la potencia del mtodo-. De todas formas, no sera muy difcil
incorporarlas a fin de permitir una visin complementaria, y que brindara excelentes beneficios, los
que, supongo, no es necesario detallar.

__________
[1] SHLAER, Sally y Lang, Neil. Shlaer-Mellor Method: The OOA96 Report Version 1.0. Berkeley,
Project Technology, Inc., 1996. Este documento est disponible en el sitio Web de Project
Technology, Inc., http://www.projtech.com o puede obtenerse dirigindose directamente a la
empresa.
16
[2] El Object Management Group, conocido por medio de la sigla OMG, es una asociacin
internacional, formada en 1989 y constituida a fin de establecer estndares para objetos distribuidos.
Est integrado por las principales empresas de hardware y software del mundo.
[3] BOOCH, Grady y Rumbaugh, James. Op.cit.
[4] BOOCH, Grady, Rumbaugh, James y Jacobson, Ivar. The Unified Modeling Language for
Object-Oriented Development. Documentation Set Version 0.9 Addendum. Santa Clara, Rational
Software Corporation, 1996. Este documento est disponible en el sitio Web de Rational Software
Corporation, http://www.rational.com o puede obtenerse dirigindose directamente a la empresa.
[5] BOOCH, Grady y Rumbaugh, James. Op.cit. Overview. p.1. La traduccin es ma.
[6] BOOCH, Grady, Rumbaugh, James y Jacobson, Ivar. Op.cit. p, 4. La traduccin es ma.
[7] BOOCH, Grady y Rumbaugh, James. Op.cit. Metamodel Guide. p.1.
[8] Ibidem. p.18.
[9] Ahora se deben interpretar como nubes estructuradas.
[10] FUSION es un mtodo de anlisis y diseo orientado a objetos desarrollado por Coleman y
Hayes, en 1991, en los laboratorios de Hewlett-Packard, entre el final de la dcada del '80 y el
comienzo de la siguiente. Propone el empleo de las fichas CRC e incorpora conceptos de los
mtodos de Booch y OMT, entre otros. Se basa en la elaboracin de un modelo de esttico que
representa la estructura de las clases (Object Diagram Model), un modelo dinmico para especificar
el comportamiento (Operation Model) y un modelo de interaccin (Object Interaction Graph) para
representar la comunicacin entre los objetos.
[11] ParcPlace. Op.cit.
[12] ParcPlace. MethodWorks Tool Reference Manual. Sunnyvale, ParcPlace Systems, Inc., 1995.
[13] GRAHAM, Ian. Op.cit. p.325.
[14] Cfr. RUBIN, Kenneth. Op.cit. p.44.