Metodologías modernas de desarrollo de Sistemas de Información (página 2)

Partes: 1, 2, 3

En la década de los 80s, los grandes avances tecnológicos permitieron el desarrollo de SI de menor costo y mayor potencia que los anteriores. Empleados de todos los niveles comenzaron a utilizar computadoras personales para realizar las mas diversas tareas; ya no dependían solo del departamento de sistemas de información para resolver todas sus necesidades informativas. La gente se dio cuenta entonces de que era posible utilizar los sistemas de computación en apoyo a actividades adicionales de toma de decisiones. Y se generaron os Sistemas de Apoyo para la toma de Decisiones. Las computadoras entonces cambiaron a ser de quinta generación. En las que se cuentan los procesadores 8080, 8086, 80286. Los sistemas de información que sobresalieron son: Sistemas de Soporte a Decisiones, Pago a Usuarios Finales y Planeación Estratégica. Surge la Administración de Recursos de Información y los Centros de Información

A partir de los 90s surgen los procesadores 80386, 80486, y Microprocesadores Pentium. En esta se han conseguido importantes avances tanto en la IA como en los SE. El valor excepcional de los sistemas expertos radica en el hecho de que permiten a los organizadores proveerse de y utilizar el saber de expertos y especialistas. Por lo tanto, años de experiencia y habilidades especificas no se pierden del todo cuando un experto muere, se retira o cambia de trabajo. Son aplicables a casi cualquier campo o disciplina. Los temas principales en los sistemas de información son: Servicios de Información, Estaciones de Trabajo y Administración de datos centralizados.

Cuatro cambios ocurrieron a través de las décadas pasadas y ahora son factores claves para los 90s:

El concepto en la aproximación orientada a objetos en el campo de software ha ido madurando durante dos decadas, y la atención ha ido gradualmente cambiando hacia los asuntos de codificación y a los asuntos de diseño y analisis.
La tecnología para construir sistemas ha ido haciendose mas poderosa. Ideas acerca de diseño han influido por ideas preconcebidas acerca de como uno podria escribir codigo; e ideas acerca de codificacion son fuertemente influenciadas por el lenguaje de programación que esta disponible. Era difícil pensar acerca de programación estructurada cuando los lenguajes a elegir eran ensambladores y FORTRAN; las cosas se volvieron mas fáciles con Pascal, PL-1, y ALGOL. Similarmente, fue difícil pensar en programar en la moda de Orientación a Objetos cuando el leguaje a elegir era COBOL o el plano C; se hizo mas fácil con C++ y Samlltalk.
Los sistemas construidos hoy en día son diferentes de como eran hace diez o veinte años atras: son largos, muy complejos y muy volátiles. Una aproximación orientada a objetos para el análisis y el diseño es probable conducirlo a un sistema mas estable. También ahora sistemas interactivos requieren mas atención a la interface de usuarios en comparación al proceso de sistemas de texto desarrollados en los 70s. Una aproximación orientado a objetos para tales sistemas –desde análisis hasta diseño y codificación- es un método mas natural para lidiar con tales sistemas orientados a usuarios.
Los sistemas construidos hoy en día son mas "dominio-orientado" que los sistemas construidos en los 70s y 80s. La complejidad funcional es menos preocupante de como lo era antes; el modelado de datos se ha convertido en una prioridad moderada; a tomado una prioridad alta el modelar la comprensión del dominio del problema y las responsabilidades del sistema.

En el 2000 la información ha ejercido un profundo impacto en la sociedad, al grado de que hay quienes llaman a esta época la Era de la Información. La sociedad industrial ha dado paso a una nueva sociedad, en donde la mayoría de las personas trabajan con información en lugar de producir bienes. Los procesadores principales son los Pentium. Y el tema principal en Sistemas de Información es el Internet, y los Sistemas de Información de la Linea del Frente.

3. CONCEPTOS BASICOS DE ORIENTACION A OBJETOS

Qué es Orientado a Objetos?

Significa que el sistema se organiza como una colección de objetos que interactúan entre sí y que contienen tanto estructuras de datos como un comportamiento.

Esto se opone a la programación convencional, en la cual las estructuras de datos y el comportamiento solamente estan relacionadas de forma débil, ya que estos se enfocan principalmente a las funciones.

Objeto.

Los objetos son las cosas físicas y conceptuales que encontramos en el universo alrededor de nosotros. Hadware, software, documentos, seres humanos, los conceptos son todos los ejemplos de los objetos.

Características de los Objetos.

Identidad. Los datos estan cuantificados en entidades discretas y distinguibles denominadas objetos. Ejem una televisión, una bicicleta, un árbol. Los objetos pueden ser concretos, como un archivo en un sistema de archivos, o bien conceptuales como la política de planificación en un sistema operativo con multiprocesos. Cada objeto posee su propia identidad inherente. En otras palabras: dos objetos seran distintos aun cuando los valores de todos sus atributos (tales como el nombre y el tamaño) sean idénticos.

Clasificación. Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se reunen para formar una clase. La selección de clases es arbitraria y depende de la aplicación.

Objetos: Bicicleta de montaña, Bicicleta de carreras, Bicicleta de niños

Clase Bicicleta:

Atributos: Tamaño del cuadro, tamaño de rueda, material, marca, velocidad

Operaciones: mover, reparar, cambiar velocidad

Objetos: Triangulo, Cuadrado, Octagono

Clase Poligonos:

Atributos: vertices, color del borde, color del interior

Operaciones: dibujar, borrar, mover

Polimorfismo. Significa que una misma operación puede comportarse de modos distintos en distintas clases. La operación mover por ejem, se puede comportar de modo distinto en las clases Ventana y Pieza de ajedrez. Una operación es una acción o una transformación que se lleva a cabo o que se aplica a un objeto. Justificar a la derecha, visualizar y mover son ejemplos de operaciones. Una implementación específica de una operación por parte de una cierta clase es lo que se denomina método. Dado que los operadores orientados a objetos son polimórficos es posible que haya más de un método que lo implemente.

En el mundo real una operación es simplemente, una abstracción de comportamiento análogo entre distintas clases de objetos. Cada objeto "sabe" llevar a cabo sus propias operaciones. Sin embargo, en un lenguaje orientado a objetos es este el que selecciona automaticamente el método correcto para implementar una operación basandose en el nombre de la operación y en la clase del objeto que esta siendo afectado. El usuario de una operación no necesita ser consciente del número de métodos que existen para implementar una cierta operación polimórfica. Se pueden añadir nuevas clases sin modificar el código existente, siempre y cuando se proporcionen métodos para todas las operaciones aplicables a las nuevas clases.

Herencia. Es compartir atributos y operaciones entre clases tomando como base una relación jerárquica. En términos generales se puede definir una clase que después se irá refinando sucesivamente para producir subclases. Todas las subclases poseen o heredan, todas y cada una de las popiedades de su superclase y añaden, además, sus propiedades exclusivas. No es necesario repetir las propiedades de las superclases en cada subclase. Por ejem Ventanadedesplazamiento y ventanafija son subclases de ventana. Ambas subclases heredan las propiedades de ventana tales como una región visible de la pantalla. La ventanadedesplazamiento añade una barra de desplazamiento y un ascensor. La capacidad de sacar factor común a las propiedades de varias clases en una superclase común y de heredar las propiedades de la superclase puede reducir muchísimo la repteción en el diseño y en los programas siendo una de las ventajas pricipales de un sistema orientado a objetos.

4. QUE ES UNA METODOLOGIA

Metodología. Conjunto de métodos empleados para el desarrollo de sistemas automatizados.

Una metodología completa es algo más que una notación, un proceso, y herramientas. Además de una "notación, de un proceso, y de herramientas," estas "metodologías completas" proporcionan:

Guías para estimar costos,
Manejo del proyecto en las tareas y entregas,
Medidas y métricas,
Formas definidas y dirección en las entregas de la construcción,
Políticas y procedimientos para garantizar la calidad del software,
Descripciones de los roles y programas de entrenamiento detallados,
Ejemplos totalmente trabajados,
Ejercicios de entrenamiento,
Técnicas para adaptar el método, y
Técnicas definidas

5. EL ENFOQUE DE ESTA INVESTIGACION

Este trabajo consiste en una comparación de modernas metodologías de desarrollo de sistemas orientados a objetos en las que se identificará y cuantificará la ayuda de estas para el proceso de desarrollo.

Debido a que a la fecha ninguna de las metodologías que se van a comprar cumplen completamente con las características mencionadas anteriormente, ya que falta mucho trabajo por hacer para que sean unas metodologías completas. La comparación se hace con ese conocimiento y entonces "metodología" se considera tambien como un método.

Las metodologías a comparar, ordenadas alfabéticamente son:

Berard 1992,
Booch 1991,
Coad y Yourdon 1990,
Embley y Kurtz 1990,
Martin y Odell 1992,
Rumbaugh 1991,
Shlaer y Mellor 1992, y
Wirfs-Brock 1990

En esta comparación se consideran cuatro áreas específicamente:

Conceptos
- Esta sección cita de la ayuda particular del método y de los contrastes para los términos dentro de cada método. Los términos tales como objeto, clase, metaclases, y operación se comparan.
Notaciones
- Muchos métodos requieren crear descripciones abstractas, o modelos gráficos, del sistema en el análisis y/o diseño. Se construyen estos modelos usando una cierta forma de notación. La semántica de la notación proporciona el significado a los modelos. Las notaciones, para ser eficaces en el desarrollo de grandes sistemas, requieren un mecanismo para dividir los componentes en "pedazos más manejables".
Procesos
- Cuanto del ciclo de vida del desarrollo de los sistemas es cubierto por el método, y qué adaptación o heurística está disponible para el proceso del método. Es evaluada la cobertura al ciclo de vida. Comprobar que elementos del desarrollo del software se manejan dentro del método. Cada metodología puede tener elementos que sean útiles a una parte del ciclo de vida del desarrollo. Las fases del ciclo de vida se definen de la siguiente manera:
- - El Análisis es esa parte de ciclo de vida que describe las características exterior observables del sistema, ejem, funcionalidad, funcionamiento, capacidad. Esta descripción incluye normalmente los modelos que representan la construcción lógica de los sistemas, y su colocación dentro de un ambiente de sistema.
  - El Diseño es la parte del ciclo de vida que prepara definiciones en cuanto a cómo el sistema logrará sus requerimientos. Los modelos preparados en análisis se refinan, o se transforman, en los modelos del diseño que representan la naturaleza física del producto de software.
  - La implementación es la parte del ciclo de vida que convierte los modelos desarrollados del diseño en el software ejecutable dentro del ambiente del sistema. Este implica la codificación de las unidades del programa, de la generación automatizada del código, o del montaje de los componentes reutilizables ya construidos y probados del código de una biblioteca interna de la reusabilidad.
  - La prueba se centra en asegurarse de que cada una de las entregas a partir de cada fase cumple con las necesidades indentificadas por el/los usuarios.
  - El domininio del análisis direcciona la busqueda y aplicación del dominio y la identificación, documentación, construcción y prueba y demostración de los componentes reutilizables utiles en el dominio. Aunque esto no es una actividad del ciclo de vida del proyecto, es una parte importante de considerar en la ayuda brindada por la metodología.
- Se evalúan después las características o las cualidades del proceso del método. Las características de un proceso sirven para medir la capacidad de repetición del método y flexibilidad. Las características define la secuencia de pasos, de entradas requeridas y de salidas, papeles implicados, así como la interacción con otros pasos. Los pasos opcionales deben ser identificados claramente. La heurística y los mecanismos disponibles para la traceabilidad, la verificación, y la validación del proceso son también cualidades deseables de un proceso bien definido.
Pragmática

La pragmática de una metodología consiste en:

Recursos: ¿Qué recursos disponibles hay dentro de la ayuda del método? ¿Existen un libros disponibles? ¿Establecen a los grupos de usuarios? ¿El entrenamiento y la consulta es ofrecida por el vendedor y/o los terceros? ¿Además, están las herramientas automatizadas (herramientas CASE) disponibles en la ayuda del método?
Conocimientos Requeridos: ¿Cuál es el background requerido de los que aprenden el método? Una característica que distingue de muchos métodos es el nivel de la sofisticación matemática requerido para explotar completamente el método. ¿El método asume conocimiento en una cierta disciplina?
Utilización del lenguaje: ¿El método guía a un lenguaje en particular? Algunos métodos son específicos a COBOL o al Ada, mientras que otros métodos tienen aplicabilidad más general.

6. RESULTADO ESPERADO

La expectativa de cualquier comparación de la metodología es que proporcionará una base para desechar las metodologías que no parecen dar valor dependiendo de la situación. Esta comparación maneja esta expectativa. Planteando preguntas de las metodologías presentadas y usando los resultados documentados para contestar a las necesidades particulares. Estas preguntas sirven como punto que partida para una investigación posterior. Una muestra de las preguntas incluye:

"Deseo aprender sobre el desarrollo orientado al objeto en un sentido general. El proceso del desarrollo orientado al objeto del software y de la disponibilidad de herramientas no es realmente muy importante para mí en este tiempo. Apenas quiero informacion sobre objetos."
"Tengo que iniciar un gran proyecto que implique veinte personas, fuera de consultores, y es crítico para el éxito de nuestra compañía. Qué métodos son apropiados para mí?"
"Mi proyecto requiere el uso del lenguaje Smalltalk. Qué métodos son apropiados considerando que el lenguaje de programación se ha seleccionado ya para mi proyecto?"

7. CONCEPTOS

En esta sección se cita a cada metodología para comprarar la opinión de cada autor de un número de conceptos orientados al objeto.

A. DEFINICIÓN DEL "OBJETO" EN CADA METODOLOGIA

Berard 1992.

Un objeto que se utiliza para crear las instancias, es decir, una plantilla, descripción, patrón, o "modelo" un una categoría o colección de artículos muy similares. Entre otras cosas, una clase describe el interfaz que los estos artículos presentarán al mundo exterior, los métodos, las constantes, y las excepciones es decir, disponibles y apropiados. Una clase representa una abstracción de los artículos. Una clase es realmente una familia de clases muy de cerca relacionadas. La clase es un concepto recurrente. Específicamente, podemos definir clases como un compuesto de otras clases (es decir, las clases compuestas heterogéneas y clases compuestas homogéneas), en términos de sí mismo (una clase recurrentemente definida), como herencia de características de unas o más otras clases (es decir, los superclasses de la clase), y como abastecimiento de características a otras clases (es decir, las subclases de la clase). En algunos lugares, se definen las clases como "el sistema de todos las instancias de un tipo," y del término "tipo" se da la definición antedicha para la clase.

Booch 1991.

Algo a lo que se le pueden hacer cosas. Un objeto tiene estado, comportamiento, e identidad; la estructura y el comportamiento de objetos similares se definen en su clase común. Los términos instancia y objeto son intercambiables.

Coad y Yourdon 1990.

Una abstracción de algo en un dominio del problema, reflejando las capacidades de un sistema a mantener la información de este, interactúa recíprocamente con esta información, o ambas (interactuar y mantener); una encapsulación de los valores atributos y sus usos exclusivos (sinónimo: una instancia)

Embley y Kurtz 1990.

Un objeto es una persona, un lugar, o una cosa. Un objeto puede ser físico o conceptual… La idea es que un objeto es una sola entidad o noción. Cada objeto es un individuo único. Un objeto se puede relacionar con o componer de otros objetos, pero cada objeto es único.

Martin y Odell 1992.

Cualquier cosa a la cual un concepto, o tipo de objeto, se aplica – una instancia de un concepto o tipo de objeto. En OOPLs, es cualquier instancia de una clase."

Rumbaugh 1991.

Definimos un objeto como un concepto, una abstracción, o cosa con límites para el problema actual. Los objetos responden a dos propósitos: Promueven la comprensión del mundo verdadero y proporcionan una base práctica para la puesta en práctica de la computadora. La descomposición de un problema en objetos depende del juicio y de la naturaleza del problema. No hay una representación correcta.

Shlaer y Mellor 1992.

Un objeto es una abstracción de un sistema de cosas del mundo real, tales como:

todas las cosas en el sistema – las instancias – tenga las mismas características, y
todas las instancias están conforme y se conforman con el mismo sistema de reglas y políticas…

Un objeto en OOA representa un solo caso típico pero sin especificar algo en el mundo verdadero – cualquier avión, no importa cual, mientras sea representativo. El analista orientado al objeto distingue este concepto de un caso específico: Avión número 8945, una fuerza aérea, o un avión de Aeromexico, por ejemplo.

Wrifs-Brock 1990.

Los objetos saben ciertos datos sobre sí mismos (como por ejemplo, una persona sabe los colores de su pelo y ojos), y los objetos saben como hacer ciertas funciones (asi como una persona sabe comprar en el mercado o hacer su trabajo).

En un sentido, un objeto se puede ver como una declaración, que cierto conocimiento y ciertas operaciones están relacionados conceptualmente con otro, de modo que tenga sentido el unirlos.

ANALISIS

En las definciones del término "Objeto", se concluye lo siguiente:

Indica que ciertos métodos integran la mención de abstracción a sus definiciones del objeto, y otros consideran unicidad e identidad como crítica (solamente Rumbaugh menciona ambos). Además, la mención el comportamiento y estado se percibe limitada a esos métodos el centrarse en unicidad.

Metodología	Mención de abstracción	Unicidad o identidad	Comportamiento o acciones	Estado
Berard		X	X
Booch		X	X	X
Coad y Yourdon	X		X
Embley		X
Martin y Odell	X
Rumbaugh	X
Shlaer y Mellor	X
Wirfs-Brock		X	X	X

B. DEFINICIÓN DE "CLASE" EN CADA METODOLOGIA

Berard 1992.

Un objeto el cual es utilizado para crear instancias, es decir, una plantilla, descripción, patrón, o "modelo" de una categoría o de una colección de artículos muy similares. Entre otras cosas, una clase describe la interfaz que los artículos presentarán al mundo exterior, ejem. los métodos apropiados y disponibles, las constantes, y las excepciones. Una clase representa una abstracción de los artículos. Una clase puede a si misma darse parámetros (ejem, representa realmente una familia de clases muy estrechamente relacionadas), a esto le llamamos dar parametos a la clase. Clase es un concepto recursivo. Específicamente, podemos definir clases como un compuesto de otras clases (es decir, clases compuestas heterogéneamente y clases compuestas homogéneamente), en términos de sí mismo (una clase definida recursivamente), como características de herencia de una o más clases (es decir, los superclasses de la clase), y como abastecimiento de características a otras clases (es decir, las subclases de la clase). En algunos lugares, las clases se definen como "el conjunto de todas los instancias de un tipo," y del término "tipo" se da la definición para clase.

Booch 1991.

Un conjunto de objetos que comparten una estructura común y un comportamiento común. Los términos clase y tipo son generalmente (pero no siempre) intercambiables; y una clase es un concepto levemente distinto a tipo, en el hecho que acentúa la importancia de jerarquías de clases.

Coad y Yourdon 1990.

Una descripción de uno o más objetos con un conjunto uniforme de cualidades y de servicios, incluyendo una descripción de cómo crear nuevos objetos en la clase.

Clase-Objeto. Un significado del término "una clase y los objetos en esa clase."

Embley y Kurtz 1990.

Identificación de conjunto de objetos que pertenecen juntos por una cierta razón lógica llamada clasificación. En OSA, un sistema de objetos que pertenecen juntos por una cierta razón lógica se le llama clase del objeto. El modelo de la Objeto-Relacion insita a los analistas a que organicen objetos en clases del objeto. Cada clase del objeto tiene un nombre genérico y denota a cualquier miembro de la clase del objeto. Así, en un ORM, una clase del objeto con nombre X señala una clasificación de los objetos cada uno de los cuales se considera ser un X. Como cada objeto en clase del objeto X es un X, los objetos en la clase son semejantes, por lo menos en un cierto sentido.

Martin y Odell 1992.

Una implementación de un concepto o de un tipo de objeto. En lenguajes de programación OO, los tipos de datos abstractos se llaman clases. En matemáticas, el significado de la clase es similar a el de sistema. El significado de la definición de OOPL de la clase se presentó de la definición matemática.

Rumbaugh 1991.

Una clase del objeto describe un grupo de objetos con las características similares (cualidades), el comportamiento común (operaciones), relaciones comunes a otros objetos, y la semántica común. La persona, la compañía, el animal, el proceso, y la ventana son todas las clases del objeto.

Shlaer y Mellor 1992.

No provee una definición explicita de "clase"

Wrifs-Brock 1990.

Los objetos que comparten el mismo comportamiento se dice que pertenecen a la misma clase. Una clase es una especificación genérica para un número arbitrario de objetos similares. Se puede pensar en una clase como plantilla para una clase específica de objeto.

ANALISIS

Mientras que el método de Shlaer y de Mellor utiliza diagramas de la clase y hace la mención significativa del término "clase" en su aproximación, no proveen ninguna definición explícita de la clase. Otra nota es que, Rumbaugh menciona que una clase debe identificar sus relaciones con otras clases, mientras que Embley menciona que el modelo de la Objeto-Relacion es útil en identificar clases. Estos dos métodos difieren de los otros métodos en su enfoque en relaciones como fundamental para el uso del término "clase."

Metodología	Mención de abstracción	Mención de Estructura	Mención de Comportamiento	Estado	Relaciones
Berard	X	X	X
Booch		X	X
Coad y Yourdon		X	X
Embley	X				X
Martin y Odell	X	X
Rumbaugh	X	X	X		X
Shlaer y Mellor
Wirfs-Brock			X

C. DEFINICIÓN DE "OPERACION" EN CADA METODOLOGIA

Berard 1992.

Una acción que es afectada por, o requerida por un objeto. Las operaciones pueden ser selectoras, constructivas, o iterativas. Una operación es contenida en la interfaz del objeto y tiene sus detalles descritos en un método correspondiente. Las operaciones pueden ser compuestas, es decir, integrada por otras operaciones. Sin embargo no es alentada, la encapsulación de operaciones compuestas dentro de la interfaz a un objeto.

Booch 1991.

Una cierta acción que un objeto realiza sobre otro para sacar una reacción. Todas las operaciones sobre un objeto específico se pueden encontrar en subprogramas libres y funciones o métodos. Los términos mensaje, método, y operación son generalmente intercambiables.

Coad y Yourdon 1990.

Un servicio es un comportamiento específico que un objeto es responsable de exhibir.

Embley y Kurtz 1990.

Además de estados y de transiciones entre estados, también deseamos modelar las acciones que un objeto realiza. Una acción puede causar acontecimientos, crear o destruir objetos y relaciones, observar objetos y relaciones, y enviar o recibir mensajes.

"Ponemos acciones en dos categorías en OSA: acciones no-interrumpibles y acciones interrumpibles. Las acciones no-interrumptibles son las acciones que el analista espera correr al terminar a menos que ocurran las excepciones o los fallos del sistema. Las acciones interrumpibles pueden ser suspendidas antes de que acaben de ejecutarse y puedan reasumir la ejecución despues. En OSA, pensamos en las acciones asociadas a transiciones como no-interrumptible, mientras que las acciones asociadas a los estados son interrumpibles."

Martin y Odell 1992.

Un proceso que se puede solicitar como unidad. Un solo paso que se realiza en una serie de pasos. Las operaciones pueden o pueden no cambiar el estado de un objeto. Las funciones son las operaciones que no cambian el estado. Sin embargo, en un esquema del acontecimiento, las operaciones que dan lugar a acontecimientos cambian estados (y se podrían más correctamente llamar las operaciones-cambia-estados).. Sin embargo cada operación estado-cambia puede estar como transacción. Una transacción es un proceso o una serie de procesos que actúan como unidad para cambiar el estado de un objeto. Los casos de operaciones se llaman operaciones invocadas. La especificación de cómo una operación debe ser realizada se llama método.

Rumbaugh 1991.

Una operación es una función o una transformación a la cual puede ser aplicada para o por los objetos en una clase. Contratar, despedir, y pagar utilidades son operaciones en la clase Compañía. Abiertas, cerradas, escondidas, y desplegadas son las operaciones de la clase ventana. Todos los objetos en una clase comparten las mismas operaciones.

Shlaer y Mellor 1992.

Tomadores de acontecimientos. Define una operación publicada que corresponde a cada acontecimiento generado por el objeto bajo consideración. Tales operaciones publicadas se conocen como tomadores de acontecimientos. Hay dos casos a considerar:

si el acontecimiento generado por el generador de acontecimientos no causa un nuevo caso del objeto a ser creado, define a tomador correspondiente del acontecimiento como operación del caso. Lo nombra: "Acontecimiento Tomado"
si el acontecimiento generado por el generador de acontecimientos hace un nuevo caso del objeto a ser creado, define a tomador correspondiente del acontecimiento como operación de la clase y lo nombra: Toma y Crea

Wrifs-Brock 1990.

Cuando un objeto recibe un mensaje, realiza la operación solicitada ejecutando un método.

ANALISIS

En el repaso de cada definición de la "Operación", solamente Booch indica que el método y la operación son equivalentes. Algunos métodos visualizan los métodos de un objeto de una perspectiva externa, mientras que otros se centran en los métodos de un objeto de una perspectiva interna. El método solamente de Martin y de Odell no hace caso de la aplicación métodos externos o internos.

Metodología	Operación = Método	Externo	Interno	Estado
Berard		X	X
Booch	X		X
Coad y Yourdon		X
Embley		X
Martin y Odell				X
Rumbaugh		X	X
Shlaer y Mellor		X	X	X
Wirfs-Brock		X

D. DEFINICIÓN DE "METACLASE" EN CADA METODOLOGIA

Berard 1992.

Metaclase: una clase que sus isntancias son asi mismos clases.

Booch 1991.

Metaclase: la clase de una clase; una clase que sus instancias son asi mismos clases

Coad y Yourdon 1990.