BON: la notación de objeto empresarial

Hay muchos enfoques para el modelado OO y la mayoría tiene sus puntos

fuertes. Sin embargo, el método que parece proporcionar el mayor beneficio
para la menor complejidad es la notación de objetos comerciales de
Waldén y Nerson ; echemos un vistazo más de cerca para obtener una idea de
lo que requiere un enfoque integral para el análisis OO. Esta breve
presentación solo delineará las principales características del método,
limitándose a su contribución al análisis; para más detalles, y para explorar
aspectos de diseño e implementación, vea el libro de Waldén-Nerson
citado aquí .

La notación de objetos comerciales comenzó como un formalismo gráfico

para representar las estructuras del sistema. El nombre original se mantuvo, a
pesar de que BON ha pasado de solo una notación a un método de desarrollo
completo. BON se ha utilizado en muchas áreas de aplicación diferentes para
el análisis y desarrollo de sistemas, algunos muy complejos.

BON se basa en tres principios: fluidez, reversibilidad y contracción.

 La sin costura es el uso de un proceso continuo a lo largo del

ciclo de vida del software.
 La reversibilidad es el soporte para la ingeniería tanto hacia
adelante como hacia atrás: desde el análisis hasta el diseño y la
implementación, y viceversa.
 La contratación (recuerde Design by Contract) es la definición
precisa, para cada elemento de software, de las propiedades
semánticas asociadas;

BON es casi el único entre los métodos de análisis populares que utiliza un
mecanismo de aseveración completo, que permite a los analistas especificar
no solo la estructura de un sistema sino también su semántica (restricciones,
invariantes, propiedades de los resultados esperados). Varias otras
propiedades hacen que BON se destaque entre los métodos OO:

 Está destinado a "escalar" , en el sentido explicado al comienzo

de este capítulo. Varias instalaciones y convenciones le permiten
elegir el nivel de abstracción de una descripción de sistema o
subsistema, para ampliar un componente, para ocultar partes de
una descripción. Esta ocultación selectiva es preferible, en mi
opinión, al uso de modelos múltiples ilustrados por algunos de
los métodos anteriores: aquí, para la fluidez y la reversibilidad,
se mantiene un único modelo; pero puede decidir en cualquier
momento qué aspectos son relevantes para sus necesidades del
momento y ocultar el resto.
  BON , creado en la década de 1990, se diseñó bajo el supuesto
de que sus usuarios tendrían acceso a recursos informáticos, no
solo papel y pizarras. Esto hace posible el uso de herramientas
potentes para mostrar información compleja, libre de la tiranía de
áreas de tamaño fijo como páginas de papel. Tal herramienta está
esbozada en el último capítulo de este libro. Para pequeños
ejemplos, el método puede, por supuesto, ser utilizado con lápiz
y papel.
 A pesar de su ambición, especialmente su capacidad para cubrir
sistemas grandes y complejos, el método es notable por su
simplicidad. Solo implica una pequeña cantidad de conceptos
básicos. Nótese en particular que el formalismo se puede
describir en dos páginas; los elementos más importantes
aparecen a continuación y en la página siguiente.

El soporte de BON para sistemas grandes se basa en parte en la noción de

clúster, que denota un grupo de clases lógicamente relacionadas. Los clústeres
pueden incluir subgrupos, de modo que el resultado es una estructura anidada
que permite a los analistas trabajar en varios niveles en diferentes
momentos. Algunos de los clusters pueden ser, por supuesto, bibliotecas; el
método pone un fuerte énfasis en la reutilización.
[Para un análisis más detallado de los clusters, ver CLUSTERS , sección
28.1, página 923 de OOSC ]

La parte estática del modelo se centra en clases y clusters; la parte dinámica

describe objetos, interacciones de objetos y posibles escenarios para la
secuencia de mensajes. BON reconoce la necesidad de varios formalismos
complementarios, explicados anteriormente en este capítulo. (La supuesta
disponibilidad de herramientas de software es esencial aquí: con un proceso
manual, las vistas múltiples plantearían la cuestión de cómo mantener la
consistencia del modelo, las herramientas pueden garantizarlo
automáticamente). Los formalismos incluyen una notación textual, una forma
tabular y diagramas gráficos

La notación textual es similar a la notación de este libro; pero como no tiene

que ser directamente compilable, puede usar algunas extensiones en el área de
aserciones, incluida delta a para especificar que una característica puede
cambiar un atributo a, forall y existe para expresar fórmulas lógicas de cálculo
de predicados de primer orden y establecer operadores como member_of.

La forma tabular es conveniente para resumir las propiedades de una clase de

forma compacta. Aquí está la forma general de un gráfico de clase tabular:
La notación gráfica es extremadamente simple, para que sea fácil de aprender
y recordar. Las principales convenciones, tanto estáticas como dinámicas,
aparecen a continuación.

Figuras: Tipos de diagramas principales de la notación de objetos

comerciales (BON)
(Después de [ Arquitectura de software orientada a objetos sin
fisuras , Waldén y Nerson 1995], utilizado con permiso).
El método define un proceso preciso para el análisis y desarrollo, que consta
de siete tareas. El orden de las tareas corresponde a un proceso ideal, pero el
método reconoce que en la práctica está sujeto a variación e iteración, tal
como lo implica el concepto de reversibilidad. Las tareas estándar son:

 B1 - Delinear el límite del sistema : identificar lo que el sistema

incluirá y no incluirá; definir los subsistemas principales, las
metáforas del usuario, la funcionalidad, las bibliotecas
reutilizadas.
 B2: enumera las clases candidatas : genera la primera lista de
clases según el dominio del problema.
 B3 - Seleccione clases y agrupe en grupos : organice las clases
en grupos lógicos, decida qué clases serán diferidas, persistentes,
interconectadas externamente, etc.
 B4 - Definir clases : expanda la definición inicial de clases para
especificar cada una de ellas en términos de consultas, comandos
y restricciones.
 B5 - Comportamiento del sistema de bocetos : defina gráficos
para creación de objetos, eventos y escenarios.
 B6 - Definir características públicas : finalizar las interfaces de
clase.
 B7 - Refina el sistema .

A lo largo del proceso, el método prescribe mantener un glosario de términos

del dominio técnico. La experiencia muestra que esta es una herramienta
esencial para cualquier proyecto de aplicación grande, tanto para brindar a los
no expertos un lugar donde ir cuando no entienden la jerga de los expertos de
dominio, como para asegurarse de que los expertos realmente estén de
acuerdo con los términos ( ¡es sorprendente ver con qué frecuencia el proceso
revela que no lo hacen!).

De manera más general, el método que se especifica para cada paso es una
lista precisa de sus entregables: documentos que el gerente tiene derecho a
esperar como resultado del trabajo del paso. Esta precisión en la definición de
las responsabilidades de la organización hace que BON no solo sea un método
de análisis y diseño, sino también una herramienta estratégica para la gestión
de proyectos.
BON: el método de análisis y diseño para confiabilidad,
reusabilidad y reversibilidad

BON, Business Business Notation, es un método y una notación gráfica para análisis y diseño
orientado a objetos de alto nivel.

Visión de conjunto

BON se basa en conceptos similares a los de Eiffel, pero se pueden usar independientemente
de Eiffel, por ejemplo, por personas que utilizan otro idioma de OO para la implementación.

Muchas personas que se sienten atraídas por el poder y la practicidad de los conceptos
comienzan con BON como su primer paso hacia la construcción de software de OO moderna
y sistemática, incluso si a corto plazo deben usar otro lenguaje de implementación.

¿De dónde vino BON?

El diseñador original de BON fue Jean-Marc Nerson de SOL (París); el diseño se completó con
la colaboración de Kim Waldén de Enea Data (Estocolmo). El Dr. Waldén y el Dr. Nerson son
los coautores del libro definitivo sobre BON: "Arquitectura de software orientada a objetos
sin problemas" (Prentice Hall).

BON y EiffelCase

Una atracción particular de BON es la disponibilidad de la herramienta de soporte: EiffelCase

( ahora integrado en ISE EiffelStudio ), quizás el banco de trabajo de análisis y diseño más
sofisticado del mercado. Conectada directamente con las otras herramientas del entorno ISE,
EiffelCase admite la generación de nuevas arquitecturas de sistemas, así como la ingeniería
inversa de los sistemas existentes, por grandes y complejos que sean.

Los tres conceptos clave

Los tres conceptos principales del método BON son la fluidez, la reversibilidad y la
contratación de software:

 La sin costura es el principio de usar un conjunto consistente de conceptos y

notaciones a lo largo del ciclo de vida, evitando los desajustes de impedancia de los
enfoques tradicionales.
 La reversibilidad garantiza que los cambios realizados en cualquier etapa del proceso,
incluso tan tarde como la implementación o el mantenimiento detallados, pueden
reflejarse en los pasos anteriores, incluido el análisis, a fin de garantizar la
coherencia de la línea base completa del proyecto.
 La contratación de software, una idea también fundamental en el lenguaje de Eiffel ,
ve la construcción de un sistema de software como una sucesión de contratos
precisos entre sus módulos, para garantizar la fiabilidad y la coherencia.
Cómo aprender más

Puede encontrar una introducción a una versión temprana de BON en "Aplicación de análisis
y diseño orientado a objetos" por Jean-Marc Nerson, Comunicaciones de la ACM , vol. 35,
no. 9, septiembre de 1992, páginas 63-74. Pero para el caso real, debe obtener una copia
del libro mencionado anteriormente.

© 1985-2012 Software de Eiffel. Todos los derechos reservados. - Política de privacidad

En la selección de los métodos de ISD utilizamos varios criterios. Primero, elegimos métodos
que son bien conocidos o ampliamente utilizados. Este criterio garantiza que las
construcciones de metamodelado sean necesarias para modelar la mayoría de los métodos
utilizados en la actualidad. En segundo lugar, debido a que nos enfocamos en representar el
conocimiento del método en las herramientas de modelado, solo se seleccionaron aquellos
métodos que podrían ser respaldados por herramientas de modelado asistido por
computadora [16] . De hecho, los métodos seleccionados ya son compatibles con otro
entorno asistido por computadora, ya sea en una herramienta CASE dependiente del método o
en un entorno metaCASE. La disponibilidad del soporte de herramientas también muestra que
los métodos seleccionados son conocidos y que tienen usuarios. De lo contrario, difícilmente
habría tales herramientas disponibles.

En tercer lugar, el criterio principal para la selección de métodos fue encontrar un conjunto de
métodos de ISD que representen diversos enfoques y exploten diferentes tipos de estructuras
conceptuales. Este criterio de selección asegura que las construcciones de metamodelado
identificadas son válidas para una amplia variedad de métodos, no solo, por ejemplo, para
modelar métodos orientados a objetos. Por lo tanto, los métodos elegidos incluyen técnicas de
modelado de datos, técnicas de planificación de SI, métodos de diseño y análisis estructurados,
métodos orientados a objetos y métodos de modelado de negocios. El número relativamente
grande de métodos orientados a objetos incluidos se puede explicar por el hecho de que
incluyen más técnicas y tienen estructuras conceptuales más ricas que otros métodos (Rossi y
Brinkkemper, 1996). Como consecuencia, se espera que el modelado de métodos orientados a
objetos requiera el uso de lenguajes de metamodelado más potentes. La Tabla 4-1
proporciona un resumen de los métodos seleccionados junto con sus técnicas de modelado
individuales (es decir, cada método consiste en una o más técnicas).

TABLA 4-1 Métodos seleccionados para el metamodelado.

Métodos analizados Técnicas individuales

Modelo de actividad Modelo de actividad

(Goldkuhl 1992, 1989) Lista de objetivos

Lista de problemas

Demeter (Lieberherr y otros, 1994) Demeter

BON, notación de objetos comerciales Gráfico del sistema

(Walden y Nerson, 1995) Cuadro de conglomerados

Tabla de eventos

Tabla de escenarios
 Diagrama de creación

Modelo estático

Modelo dinámico

BSP, planificación de sistemas empresariales Tabla de problemas

(IBM 1984) Matriz de proceso / entidad

Matriz de proceso / organización

Matriz de proceso / sistema

Matriz de sistema / entidad

Matriz de sistema / organización

EXPRESS (ISO 1991) EXPRESS-G

Fusión Modelo de objeto

(Coleman y otros, 1994) Modelo de operación

Gráfico de interacción de objetos

Gráfico de visibilidad

Gráfico de herencia

IDEF, definición de integración IDEF0

(Ross y Schoman 1977, FIPS 1993a, 1993b) IDEF1

IDEF3

ISAC, trabajo de sistemas de información y Un gráfico

análisis de cambios
I-graph
(Lundeberg y otros 1981, Lundeberg 1982)
Tabla de problemas

Tabla de grupos de problemas

Tabla de necesidades de cambios

Tabla de grupos de interés

C-graph

D-graph

JSD, el desarrollo del sistema de Jackson Diagrama de estructura de datos

(Jackson 1976, Cameron 1989) Diagrama de estructura del programa

OMT, técnica de modelado de objetos Diagrama de clase

(Rumbaugh y otros, 1991) Diagrama de flujo de datos

Diagrama de transición de estado

Modelo de caso de uso

OOA / OOD, Análisis y Diseño Orientado a Diagrama de objeto

Objetos
Diagrama de transición de estado
(Coad y Yourdon 1991a, 1991b)
Cuadro de servicio

Moisés Modelo de O / C

(Henderson-Sellers y Edwards 1994) Modelo de evento

Modelo de herencia

OODA, diseño orientado a objetos Diagrama de clase

(Booch 1994) Diagrama de transición del estado

Diagrama de objeto

Diagrama del módulo

Diagrama de proceso

OODLE, lenguaje de diseño orientado a Modelo de información

objetos
Modelo de estado
(Shlaer y Mellor 1992)
Diagrama de flujo de datos de acción

Modelo de acceso a objetos

Tabla de proceso

OSA, Análisis de Sistemas Orientado a Modelo de relación de objeto

Objetos
Modelo de comportamiento de objetos
(Embley y otros, 1992)
Diagrama de interacción de objetos

SA / SD, análisis estructurado y diseño Diagrama de flujo de datos

(Gane y Sarson 1979, Yourdon 1989a, Ward y Diagrama de flujo de datos RT

Mellor 1985)
Relación diagrama de entidad

Diagrama de estructura

Diagrama de transición de estado

UML, lenguaje de modelado unificado Diagrama de clase

Use el diagrama del caso

(Booch y Rumbaugh 1995, Booch y otros Tabla de funcionamiento
1996, Booch et al. 1997)
Diagrama de colaboración

Diagrama de estado

Diagrama compuesto

Diagrama de componentes

Diagrama de despliegue

4.2.2 Proceso de metamodelado

La estructura del proceso de metamodelado se resume en la Figura 4-1. El universo del

discurso es el de los métodos seleccionados, en contraste con el modelado del "mundo
real". Cada método fue examinado y modelado utilizando un lenguaje metamodelado en una
herramienta metaCASE. El resultado del esfuerzo de metamodelado, es decir, el metamodelo
producido, se adaptó a un entorno de herramientas y se validó probando el método en el
modelado de sistemas.

FIGURA 4-1 Estructura del modelado de métodos.

Al igual que cualquier tarea de modelado, el metamodelado está impulsado por una serie de
objetivos. En nuestro caso, el metamodelado se basó en un análisis de contenido de la
literatura del método publicado. Tratamos de seguir lo más cerca posible las descripciones de
los métodos que figuran en los libros de referencia (véase la Tabla 4-1) en lugar de desviarnos
ligeramente para adaptarnos mejor a una situación de uso previsto. El análisis de contenido se
puede definir como un proceso de identificación, codificación y categorización de patrones
primarios en datos (Patton 1990). En nuestro estudio de metamodelado, los datos relevantes
sobre los métodos se recopilaron e identificaron por primera vez a través de la literatura del
método. La literatura sobre métodos describe básicamente los conceptos, los idiomas, las
notaciones y los posibles requisitos en el soporte de herramientas de construcción para un
método. En segundo lugar, los datos se clasificaron en distintos tipos, lo que nos permite
simplificar y sistematizar la estructura conceptual de los métodos. En nuestro caso, la
clasificación se basó en los lenguajes metamodelados. Naturalmente, un lenguaje
metamodelado con un esquema de clasificación dado restringe nuestra visión de los
métodos. En tercer lugar, los métodos se documentaron de la manera más completa posible a
través de los metamodelos.

Otro objetivo para la tarea de metamodelado fue el compañerismo de herramienta de

método: la tarea de metamodelado se realizó al examinar cómo una herramienta podría
apoyar los métodos seleccionados. Por lo tanto, los metamodelos fueron "ejecutables" e
implementados en una herramienta de modelado (ver Sección 4.2.3).

El modelado del método real se realizó en dos fases. En la primera fase, invierno 1992-1993,
analizamos un conjunto de métodos y desarrollamos un conjunto de metamodelos tentativos
(informados en Tolvanen y Rossi 1996). La segunda fase tuvo lugar en 1995-1996, cuando
analizamos y modelamos los mismos métodos con más detalle. Modelamos así los métodos
dos veces. Durante la primera ronda, limitamos nuestro enfoque al modelado de las técnicas
individuales y sus estructuras conceptuales, mientras que en la segunda fase nos enfocamos
en la integración del método, es decir, cómo diferentes técnicas podrían combinarse para
formar un método "completo". Debido a nuestro interés en los métodos soportados por
herramientas aplicamos dos lenguajes de metamodelado que son compatibles con las
herramientas metaCASE, OPRR (Welke 1988, Smolander 1992) y GOPRR (Marttiin et al., 1995,
Kelly et al., 1996) respectivamente [17] .Estos lenguajes de metamodelado se aplicaron
debido al soporte de herramientas disponible para metamodelar y probar los metamodelos
(véase la Sección 4.2.3), porque tuvieron un éxito relativamente bueno en el ejercicio de
metamodelado (véase la Sección 3.3) y porque nuestra propia experiencia de metamodelado
fue principalmente con estos idiomas

Durante el modelado de métodos distinguimos el siguiente conjunto de tareas que debe seguir
OPRR (Tolvanen y Lyytinen 1993) y metamodelado relacionado con GOPRR. Estas tareas,
aplicadas en varios esfuerzos exitosos de metamodelado (véase Tolvanen y Lyytinen 1993,
Rossi y Brinkkemper 1996, Hillegersberg et al., 1998), proporcionaron una visión más detallada
del proceso de clasificación del análisis de contenido adaptado al metamodelado. Estas tareas
son:

1) Identificación de las técnicas en el método. Debido a que cada método puede consistir en
una o más técnicas, primero debemos identificarlos (como se detalla en la Tabla 4-1). La
mayoría de las veces, un método ISD propone una serie de técnicas separadas con diferentes
conceptos y notaciones de apoyo, pero una técnica también puede incluir conceptos que se
comparten con otras técnicas. Por ejemplo, en Embley et al. (1992) un modelo de
comportamiento de objeto (utilizado para describir un ciclo de vida de un solo objeto a través
de transiciones de estado) puede incluir relaciones de interacción que también se aplican en
modelos de interacción de objetos. Algunas técnicas también pueden ser subconjuntos de
otras técnicas más ricas y complejas en el mismo método. Por ejemplo, en Fusion (Coleman et
al., 1994) y en MOSES (Henderson-Sellers y Edwards, 1994), un gráfico de herencia incluye solo
un subconjunto de los conceptos utilizados en un modelo de objetos.

2) Identificación de tipos de objetos. El modelado de una técnica individual comienza con la

resolución del tipo de objeto (o entidad) que una técnica reconoce. Los tipos de objetos se
pueden definir como elementos básicos de una técnica que puede existir independientemente
de otros tipos en una técnica. Los ejemplos de tipos de objetos en un diagrama de flujo de
datos son 'proceso', 'almacenar' y 'externo'.

3) Determinación de propiedades para cada tipo de objeto. Cada tipo de objeto tiene de cero
a muchas propiedades que caracterizan instancias de tipo de objeto. Como los tipos de objetos
normalmente representan la mayoría de las propiedades de una técnica y las propiedades se
pueden compartir con otros tipos (Rossi y Brinkkemper 1996), esta tarea se distingue como
una tarea separada. La identificación de propiedades que pertenecen a tipos distintos de los
tipos de objeto se discute en la tarea 6. Ejemplos de tipos de propiedad son 'identificador' y
'nombre' para un tipo de objeto 'proceso'.

Se debe tener en cuenta que en GOPRR, un tipo de propiedad puede tener una estructura
interna, una restricción de identidad y un nombre local. Por ejemplo, el tipo de propiedad
'operations' es del tipo de datos de colección, y se refiere al tipo de objeto 'operation' que
contiene. Este tipo de objeto, a su vez, consta de otros tipos de propiedades, como un
"nombre de operación" y un "tipo de devolución" (consulte la Figura 3-11). Además de definir
un conjunto de tipos de propiedades, uno de ellos se puede definir como un tipo de propiedad
identificadora. En GOPRR, la propiedad de identificación define qué tipo de propiedad se
utiliza como el nombre del tipo no de propiedad. Por ejemplo, el nombre de una clase
proviene de su tipo de propiedad 'nombre de clase', en lugar de, por ejemplo, sus atributos (es
decir, el tipo de propiedad 'atributos'). Cuando se adjunta a no propiedades, un tipo de
propiedad puede volver a etiquetarse en el contexto de la propiedad no adjunta. Esto permite
definir el intercambio de propiedades entre tipos no de propiedad: las instancias de dos o más
tipos no de propiedad pueden referirse a los mismos valores de propiedad (véase Kelly 1997).

4) Determinación de las relaciones. Los tipos de objetos están conectados entre sí a través de
una serie de tipos de relaciones. Esta tarea se ocupa de la identificación de los tipos de
relación que conectan tipos de objetos. Los ejemplos de tipos de relación son 'flujo de datos'
en un diagrama de flujo de datos y 'herencia' en un diagrama de clases. Debe señalarse que
estos no se pueden definir como un tipo de objeto en GOPRR porque eso llevaría a
definiciones de métodos incorrectas: en el contexto de diagramas de flujo de datos, esto
permitiría flujos de datos que no están relacionados con los procesos.

5) Determinación de roles. Después de identificar los tipos de objetos y relaciones, es

necesario establecer las conexiones entre estos tipos. En los lenguajes de metamodelado que
aplicamos, estas conexiones se especifican mediante el uso de tipos de roles. Los ejemplos de
los tipos de rol son 'emisor' y 'receptor' conectados al tipo de relación 'flujo de datos', y
'subclase' y 'superclase' conectados al tipo de relación 'herencia'.

6) Asignación de propiedades a tipos de relaciones y tipos de roles. Al igual que con los tipos
de objeto, los tipos de relación y rol también pueden tener propiedades. Por lo general,
pueden asignarse a tipos de relación o rol una vez identificados todos los tipos.

7) La determinación de metamodelos para técnicas individuales trata de hacer todas las

conexiones posibles entre el objeto, la relación y los tipos de roles en una sola técnica. Las
conexiones se pueden especificar de acuerdo con la cardinalidad: un número mínimo y
máximo de instancias de un tipo de rol que puede tener una instancia de tipo de relación.

8) La determinación de vínculos entre técnicas separadas es necesaria para formar un método

completo. Por lo tanto, los pasos previos se llevan a cabo para cada técnica
individualmente. En general, estos vínculos definen las interacciones entre las técnicas en dos
direcciones: horizontal y vertical (Lyytinen et al., 1991). En la dirección horizontal se
especifican conexiones o restricciones entre tipos o instancias en diferentes técnicas. Por
ejemplo, los almacenes de datos en diagramas de flujo de datos se redefinen para la
verificación cruzada con modelos ER. La dirección vertical se refiere a vincular descripciones
semánticamente equivalentes en dos niveles consecutivos de abstracción, como conectar un
modelo ER con su representación en un esquema relacional, o transformar un diagrama de
flujo de datos en un diagrama de estructura (Yourdon 1989a).

9) Determinación de la parte representativa del método. El uso de métodos en herramientas

de modelado requiere la especificación de notaciones tales como símbolos gráficos. Las
representaciones son necesarias porque las descripciones derivadas usando el método son
creadas, comparadas y comunicadas por humanos (Harel 1988). En consecuencia, debemos
definir símbolos e información de ubicación para los elementos del método. Los ejemplos de
símbolos son burbujas para procesos (Yourdon 1989a) y una nube para clases (Booch
1991). Los ejemplos de ubicación incluyen colocar elementos en el eje horizontal de una
matriz y dibujar superclases encima de las subclases en un diagrama. Por lo general, se espera
que las representaciones correspondan uno a uno a los tipos especificados en un metamodelo
(Venable 1993). El aspecto de representación en una herramienta de modelado también
incluye diálogos, menús y barras de herramientas: para ser utilizados en una herramienta,
estos también se deben definir para el método.

10) Análisis y evaluación del metamodelo. Debido a que las especificaciones de los métodos
en la literatura a menudo son inconsistentes, ambiguas e informales, existen varias formas
alternativas de modelar un método. En este paso, se analizan y evalúan diferentes alternativas
de modelado, o incluso versiones de metamodelos, según las descripciones de métodos
disponibles y las herramientas de modelado desarrolladas, para garantizar que todo el
conocimiento de un método se capture en el metamodelo. Al mismo tiempo, también
discutimos las limitaciones del metamodelo y señalamos los constructos para modelar los
métodos ISD más completamente con un lenguaje metamodelado.

El metamodelado, sin embargo, no es un proceso tan sencillo como se describió

anteriormente. Más bien es un proceso iterativo en el que se prueban, se analizan y se
comparan formas alternativas de modelar el conocimiento del método sobre la base de sus
resultados (Tolvanen y Lyytinen 1993). Por ejemplo, cuando varias opciones para comprender
y modelar métodos estaban disponibles (por ejemplo, debido a descripciones de métodos
pobres o imprecisas), a menudo probamos varias alternativas. Esto naturalmente condujo a la
iteración entre las tareas de metamodelado y al desarrollo y prueba de muchas versiones de
metamodelos (se desarrollaron al menos dos versiones de cada técnica). Algunas de estas
alternativas de metamodelado se discuten en la Sección 4.3, en la que se representan los
metamodelos de tres métodos. También algunas piezas de los métodos ya modelados por
otros (como en Olle y otros 1991, Welke 1988, Brinkkemper 1990, Smolander 1992, ter
Hofstede 1993, Venable 1993, Hong et al 1993, Kinnunen y Leppänen 1994, Marttiin et al.
1993, Ebert y Süttenbach 1997, Süttenbach y Ebert 1997, Booch y Rumbaugh 1995) se
utilizaron para sugerir decisiones alternativas de metamodelado y ayudar a validar que se
capturaron todas las partes del conocimiento del método.

Aunque el enfoque de investigación inductiva seguido nos permite generalizar los requisitos
para metamodelar idiomas, también plantea algunos problemas. El primero trata del poder
expresivo de los lenguajes metamodelados elegidos (es decir, OPRR y GOPRR). Sus esquemas
de clasificación predefinidos influirán en nuestra visión de los métodos. En segundo lugar, los
lenguajes de metamodelado aplicados no podían describir todo el conocimiento del
método. Sin embargo, aquellas partes del conocimiento del método que no pudimos clasificar
de acuerdo con el lenguaje metamodelado, y por lo tanto no se describen en los metamodelos,
se registraron en un diario. Estas descripciones adicionales se adjuntaron a los metamodelos
como descripciones de forma libre y también se analizan en parte en la Sección 4.3 cuando
evaluamos los metamodelos. De hecho, la mayoría de los aspectos de los métodos que no se
pudieron modelar se generalizan como requisitos para los metamodelos de idiomas en la
Sección 4.4. Debido a que las herramientas fueron impulsadas por los metamodelos
desarrollados, estos aspectos no clasificados de los métodos no se tuvieron en cuenta durante
la implementación de la herramienta.

4.2.3 Implementación de herramienta

Como se mencionó anteriormente, el modelado de métodos incluyó un examen de cómo los

métodos seleccionados podrían ser modelados y soportados por una herramienta de
modelado. En consecuencia, los métodos se adaptaron en dos herramientas metaCASE,
llamadas MetaEdit (Smolander y col., 1990, MetaCase 1994) y MetaEdit + (Kelly y col., 1996,
MetaCase 1996a, 1996b). Por adaptación nos referimos a una representación de un método
dado en una herramienta de tal manera que la herramienta CASE pueda soportar tareas de
modelado según lo prescrito por el método (Tolvanen y Lyytinen 1993). En las herramientas
metaCASE seleccionadas, la adaptación es relativamente fácil y sencilla ya que los
metamodelos son casi directamente aplicables como especificaciones de método en la
herramienta.

Sin embargo, más importante que el soporte de herramientas era la posibilidad de validar los
metamodelos. En cada tarea de modelado, la falta de correspondencia entre el mundo real y
el modelo plantea una cuestión de validez. La correspondencia entre los métodos de ISD y los
metamodelos no es una excepción. En nuestro caso, el metamodelado relacionado con
herramientas ofreció mecanismos para asegurar una equivalencia entre los metamodelos en el
nivel de tipo (es decir, nivel de definición IRD) y los modelos del sistema a nivel de instancia (es
decir, nivel IRD) modelando con el método: cada elemento en un modelo debe tener un
elemento correspondiente en el metamodelo. En este sentido, los metamodelos incluyen solo
aquellos conceptos que son esenciales y que pueden ser respaldados por una herramienta de
modelado. Esto también confirma que los metamodelos son lo más completos posible. En
consecuencia, los ejemplos de métodos que se muestran en las siguientes secciones incluyen
tanto las definiciones de nivel de tipo (es decir, metamodelos) como algunas descripciones de
nivel de instancia (es decir, modelos). Del mismo modo, Wijers (1991) afirma que los
metamodelos completos son tan complejos que una verificación completa de ellos sin soporte
de herramientas es inmanejable. El soporte de herramientas nos permitió comprobar que los
metamodelos estaban completos en términos del lenguaje de metamodelado utilizado y
realizar consultas sobre los metamodelos (por ejemplo, qué tipo de relaciones son posibles
entre los objetos seleccionados, qué propiedades se comparten entre los elementos de una
técnica, etc.) . Las especificaciones del método descritas en la siguiente sección se produjeron
al consultar los metamodelos que se almacenaron en el repositorio.

[16] Los métodos excluidos suelen centrarse en las primeras fases de ISD, como la pizarra y los
métodos basados en lluvia de ideas. Del mismo modo, los métodos relacionados con la gestión
de proyectos, gestión de la configuración, etc. están excluidos de nuestro estudio.
[17] Estos idiomas se discuten en la Sección 3.3.3, en el apéndice, y en Tolvanen y Rossi
(1996).