Professional Documents
Culture Documents
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:
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.
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
Los tres conceptos principales del método BON son la fluidez, la reversibilidad y la
contratación de software:
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.
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).
Lista de problemas
Tabla de eventos
Tabla de escenarios
Diagrama de creación
Modelo estático
Modelo dinámico
Gráfico de visibilidad
Gráfico de herencia
IDEF3
C-graph
D-graph
Moisés Modelo de O / C
Modelo de herencia
Diagrama de objeto
Diagrama de proceso
Tabla de proceso
Diagrama de estructura
Diagrama de estado
Diagrama compuesto
Diagrama de componentes
Diagrama de despliegue
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.
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.
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.
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.
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.
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.
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).