Las primeras computadoras salieron en la década de los 40s, se llamó la primera generación, las computadoras estaban construidas por medio de tubos de vacío y eran programadas en lenguaje de máquina.

En la década de los 50s se empezó con los Sistemas de Procesamiento de Transacciones, el objetivo de muchos de esos primeros sistemas era reducir costos, el cual era posible mediante la automatización de numersos sistemas administrativos rutinarios y de trabajo intensivo. Las computadoras son de la segunda generación; estaban construídas con circuitos de transistores. Eran programadas con tarjetas perforadas, con lenguajes llamados de alto nivel. No contaban con disco duro. Tampoco existían los discos flexibles. Aparecen los procesadores de plabras como Word Star, hoja de cálculo como Visicalc. Los sistemas de información que sobresalieron son: Cuentas por Cobrar y Nómina.

Los Sistemas de Información administrativos, empezaron a desarrollarse en la decada de los 60s y se caracterizaron por utilizarlos para producir informes administrativos que en la mayoría de los casos eran elaborados de manera periódica. La programación Orientada a Objetos fue discutida primeramente a finales de los 60s por la comunidad de SIMULA. Surge la tercera generación de las computadoras. Su fabricación electrónica estaba basada en circuitos integrados. Se manejaban por medio de lenguajes de control de los sistemas operativos. Aparecen las minicomputadoras. Los sistemas de información que sobresalieron son: Flujo de Efectivo, Presupuestos, Manejo de Personal y de Manufactura.

En los 70s aparecen las computadoras de cuarta generación. Aparecen los microprocesadores, las computadoras se hacen más pequeñas y baratas por lo que se extiende su uso al mercado industrial. Surgen mas aplicaciones, paquetes gráficos. A principios de los 70s, fue una importante parte de el lenguanje Smalltalk desarrollado por Xerox PARK. Mientras, el resto del mundo salía adelante con lenguajes como COBOL o FORTRAN y usaban métodos de descomposición funcional para manejar los problemas de diseño e implementación en los SI. Había pocas si no es que ninguna, discusiones enfocadas en diseño de orientación a objetos, y virtualmente ninguna sobre análisis basado en orientación a objetos. El procesador principal de esta década es el 404. Los sistemas de información que sobresalieron son de Planeación y Pronóstico.

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.

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.

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.

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.

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

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

• 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.

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?"

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.

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.

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.

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)

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.

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."

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.

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.

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.

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.

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.

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.

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."

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.

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.

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.

No provee una definición explicita de "clase"

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.

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."

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.

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.

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

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."

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.

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.

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

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

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.

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

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

No se hace ninguna mención explícita de metaclase.

No se hace ninguna mención explícita de metaclase.

No se hace ninguna mención explícita de metaclase.

Las clases se pueden también considerar como objetos, pero son meta-objetos y objetos no del mundo real. El objeto del descriptor de la clase tiene características, y alternadamente tienen sus propias clases, que se llaman metaclases. Tratar todo como objeto proporciona una puesta en práctica más uniforme y una mayor funcionalidad para solucionar problemas complejos. Metaclase: una clase que describe otras clases.

No se hace ninguna mención explícita de metaclase.

No se hace ninguna mención explícita de metaclase.

El dominio del análisis orientado a objetos intenta identificar los artículos reutilizables localizados alrededor de los objetos, ejem clases, de instancias, sistemas de objetos interactuando, y kits.

Kit: una colección de objetos (ejem, clases, metaclasses, instancias de no-clase, otros kits, y los sistemas de objetos interactuando) que apoyan a un solo concepto, grande, coherente, orientado al objeto, ejem, ventanas, interruptores, y pólizas de seguro. Puede de hecho haber una cierta conexión física entre algunos miembros de un kit dado. Sin embargo, los kits son "granulares," es decir, mientras que todos los componentes de un kit son lógicamente relacionados, allí son muy pocas conexiones físicas las que los unen.

Sistema de objetos interactuando: una colección de objetos (ejem, clases, metaclasses, instancias de no-clase, kits, y otros los sistemas de objetos interactuando) todos aquellos que apoyan un concepto solo, grande, coherente, orientado al objeto, y en cuales allí deben ser una conexión física directa o indirecta entre cualquier dos objetos arbitrarios dentro de la colección. Además, los sistemas de objetos interactuando tienen por lo menos uno interno, independientemente del control ejecutado

Sin embargo, la estructura de la clase de un sistema grande puede contener varios cientos o algunos miles de clases. El intentar poner todas estas clases en un diagrama de la clase llega a ser poco manejable. Para ocuparse de este problema, necesitamos algunos medios de organización de clases en pedazos significativos, que nos conduce a la idea de una categoría de clase.

... el dominio del análisis intenta identificar las clases y los objetos que son comunes a todos los usos dentro de un dominio dado, tal como un software de la contabilidad.

... subsistema una colección de módulos, algunos de los cuales son visibles a otros subsistemas y otros de las cuales se ocultan.

Tema. Un tema es un mecanismo para dirigir a un lector (analista, experto del dominio del problema, encargado, cliente) a través de un modelo grande, complejo. Los temas son también provechosos para los paquetes del trabajo de la organización en proyectos más grandes, basado sobre investigaciones iniciales de OOA.

Una clase de alto nivel de objetos agrupa las clases de los objetos, sistemas de relaciones, y notas en una sola clase objeto.

No se hace ninguna mención explícita de esto.

Subsistema un componente importante de un sistema organizado alrededor de un cierto tema coherente. Un sistema se puede dividir en subsistemas usando particiones o capas. Sistema: colección organizada de componentes que interactúan. Partición: un subsistema que povee un tipo de servicio; una partición puede por si misma construir subsistemas de nivel mas bajo. Capas: un subsistema que provee múltiples servicios, todos los cuales estan en el mismo nivel de abstracción, construye en sistemas de nivel bajo de abstracción.

Mientras que un dominio pequeño (consistiendo en cincuenta o pocos objetos) se puede analizar generalmente como unidad, los dominios grandes se deben particionar para hacer que el análisis sea una tarea manejable. Para hacer tal particionamiento, nos aprovechamos del hecho de que los objetos en un modelo de información tienden a formar racimos: grupos de objetos que son interconectados el uno con el otro por muchas relaciones. Por el contrario, relativamente pocas relaciones conectan objetos en diversos racimos. Al particionar un dominio, dividimos el modelo de la información de modo que permanezcan los racimos intactos... Cada sección del modelo de información entonces se convierte en un subsistema separado. Observe que cuando el modelo de información se particiona en subsistemas, cada objeto está asignado a exactamente un subsistema.

Hemos estado hablando de clases como si fueran las únicas entidades conceptuales que componían una aplicación. Pero dependiendo de la complejidad de su diseño, los varios niveles de la encapsulación se pueden jerarquizar, una dentro del otro... Un subsistema es un sistema de clases (y posiblemente de otros subsistemas) que colaboran para satisfacer un sistema de responsabilidades. Aunque no existen los subsistemas mientras que el software se ejecuta, son entidades conceptuales útiles.

Los aplicaciones son programas completos. Una simulación completamente desarrollada, un sistema del procesamiento de textos, una hoja de cálculo, una calculadora, o un sistema del pago de la nómina son ejemplos de aplicaciones.

Solamente Booch y Berard tienen una cantidad significativa de texto en describir el dominio del análisis orientado a objetos.

Shlaer y Mellor sugieren que los objetos se puedan localizar usando las fuentes siguientes:

• Cosas tangibles (avión, una pipa, una computadora)
• Roles realizados por personas u organizaciones (doctor, paciente, corredor)
• Incidentes (vuelo, accidente, funcionamiento)
• Interacciones (compra, boda, una red eléctrica)
• Especificaciones (tipos de pólizas de seguro)

Coad y Yourdon recomiendan la busqueda de objetos con las siguientes fuentes:

• Estructuras
• Otros Sistemas
• Dispositivos
• Cosas o acontecimientos recordados
• Los roles jugados
• Procedimientos operacionales
• Sitios
• Unidades de la organización

Estas dos aproximaciones, aunque son útiles, son limitados.

Booch, Berard, y Wirfs-Brock parecen ser los más orientados al objeto, con su énfasis terminante en objetos, y el bajo enfoque en asociaciones y relaciones.

Coad y Yourdon parecen ser los siguientes, con las carácterísticas de los datos (las cualidades y las variables de la isntancia).

Después Rumbaugh, Embley y Kurtz, y Shlaer y Mellor, con un énfasis fuerte en asociaciones y relaciones casi en un nivel que hace a estos pares de los artículos de objetos.

Martin y Odell son los menos orientados a objetos, aparentemente presentando extensiones leves a la ingeniería de información con una orientación del comportamiento muy pesada.

Cada metodología es caracterizada por un sistema específico de modelos (componentes de la notación)

1. Diagrama Objeto-Mensaje
2. Diagrama Semántica de Red
3. Diagrrama Transición de Estados
4. Gráfica Petri-net
5. Diagrama de Tiempos
6. Kit
7. Sistema de Interacción de Objetos
8. Gráfica de la Unidad del Programa

1. Diagrama de Clases
2. Diagrama de Objetos
3. Diagrama de Transiciones de Estados
4. Diagrama de Tiempos
5. Diagrama de Módulos
6. Diagrama de Procesos

1. El símbolo de clase de OOA, representando una clase, sus cualidades, y sus servicios.
2. El símbolo de OOA Clase-y-Objeto
3. Notación de la estructura Generalización-Especialización
4. Notación de la estructura Entero-Parte
5. Notación del temas
6. Notación de atributos
7. Notación de la conexión de la instancia (Instance Connection notation)
8. Notación de servicio
9. Notación Diagrama Objeto Estado
10. Notación de Grafica de Servicio

1. Modelo Objeto-Relación (ORM)
2. Alto-Nivel ORM
3. Estado Red
4. Alto Nivel del Estado Red
5. Diagrama de Interacción
6. Alto-Nivel del Diagrama de Interacción

1. Diagrama de Estructura de Datos
2. Diagrama de la Jerarquía Objeto-Generalización
3. Diagrama Objeto-Relación
4. Diagrama de composición de Objetos
5. Diagramas de acción
6. Gráficas de Estructura (no muestra ejemplos)
7. Tablas declarativas. (no muestra ejemplos)
8. Diagramas Estado-Cambio o Diagramas Transición Estado
9. Diagramas de Evento o Esquema de Eventos
10. Diagramas de Flujo de Objetos
11. Herramientas para el diseño gráfico de la interfaz del usuario

1. Modelo Objeto utilizado para describir clases, objetos, atributos, operaciones, especializaciones, generalizaciones y herencias
2. Modelos dinámicos los cuales consisten en: Ecenarios, Traceabilidad de eventos, Diagramas de estado, Jerarquia de eventos, Diagramas concurrentes de estado, Diagramas extendidos de estado por sincronización y ocurrencia de actividades
3. Modelos funcionales consistentes en: Diagrama de flujo de datos, Diagramas de flujo de control
4. Arquitectura del sistema

1. Diagrama de Estructura de Información
2. Diagrama de repaso de la Estructura de Información
3. Grafica de Dominio
4. Matriz del Proyecto
5. Modelo de Relación del Subsistema
6. Modelo de Comunicación del Subsistema
7. Modelo de Acceso al Subsistema
8. Modelo de Información
9. Descripción de Objetos y Atributos
10. Descripción de Relaciones
11. Modelo de Comunicación de Objetos
12. Lista de Eventos
13. Modelo de Acceso a Objetos
14. Tabla de Estados del Proceso
15. Modelo de Estado
16. Diagrama de Flujo de la Acción de Datos
17. Descripcion de Procesos
18. Diagrama de Herencias
19. Diagrama de Dependencias
20. Diagrama de Clases
21. Gráfica de Estructura de Clases

1. Tarjeta de Clases
2. Tarjeta de Clases con Responsabilidades
3. Tarjeta de Clases con Colaboradores
4. Una Tarjeta de Clase con una Delegación de Subsistema
5. Jerarquías
6. Modelo de Interfaz del Usuario
7. Grafica de Colaboraciones
8. Tarjeta de Subsistemas con Delegaciones.

Se consideraron los siguientes conceptos:

• Agregación: ¿De qué objetos componentes se construye un objeto compuesto?
• Especialización: ¿Cómo es un objeto representado siendo una generalización, o la especialización de otro objeto?
• Comunicación: ¿Cómo los objetos mostrados se comunican unos con otros? (enviandose mensajes)
• Módulo de Interfaz: ¿Cómo son las implementaciones físicas de los objetos representados?
• Calificaciones para la reutilización: ¿Cómo un caso específico de un objeto se representa para ser utilizado por otra clase?

La representación de los cambios de estado, la sincronización, y en cierta forma las interacciones del objeto son elementos esenciales para modelar el comportamiento de los sistemas.

Cada método fue repasado para determinar si los símbolos del método fueron definidos explícitamente, y si así es, donde se definieron; y si existen ejemplos.

Además, de la definición de la semántica de las notaciones, se buscaron también ejemplos y heurística para la construcción de modelos.

En general, cada notación (excepto Berard) provee una definición explícita de la semántica de su notación, ejemplos y heurística. En muchos casos los ejemplos son bastante completos, estos son, de los modelos requeridos para un problema específico, o de una variedad de problemas.

Mientras que el tamaño de un sistema aumenta, se requiere un cierto mecanismo para limitar la visibilidad de la información solamente a esos objetos de interés en un momento particular. Estos son los mecanismos que proporciona cada metodología:

* Martin y Odell mencionan "reinos" y "especificaciones del reino" en su glosario, pero no proporcionan ninguna referencia de cómo ésta se relaciona con la partición del sistema.

• Analisis Orientada a Objetos

1. Identificacion de fuentes y requerimientos de informacion
2. Caracterizaer las fuentes y requerimientos deinformación
3. Identificar objetos candidatos
4. Construir los modelos orientados a objetos de ambos problemas, y de la solucion potencial
5. Re-localizar la informacion alrededor de los apropiados candidates de objectos
6. Seleccionar, crear, y verificar objetos candidatos
7. Asignar los objetos candidatos a las apropiadas secciones de los requerimientos especificados de la orientacion a objetos (OORS)
8. Desarrollar y refinar la precisa y concisa descripcion del sistema

• Diseño Orientado a Objetos

1. Identificacion de los Objetos Candidatos
2. Desarrollo de un modelo de solucion de orientacion a objetos
3. Identificar objetos de interes del modelo
4. Asociar atributos con las operaciones de interes
5. Identificar operaciones afectadas por, y requeridas por, los objetos candidatos
6. Identificacion de operaciones de interes
7. Asociacion de atributos con las operaciones de interes
8. Manejo de Operaciones compuestas
9. Descomposición a operaciones primitivas
10. Desemparejamiento de objetos
11. Seleccionar, crear, y verificar objetos para diseño
12. Unir objetos y operaciones
13. Examinar objetos para ser completados
14. Decidir sobre el lenguaje de programacion de objetos
15. Identificacion de Objetos durante el analisis
16. Idetificacion de Objetos durinte el diseño
17. Crear modelos graficos de orientacion a objetos
18. Establecer la interface para cada articulo orientado a objetos
19. Implementar cada articulo orientado a objetos

• Refinar la interface de objetos
• Refinar los otros objetos
• Aplicar recursividad al proceso de desarrollo orientado a objetos

• Diseño de Orientacion a Objetos

1. Identificación de Clases y Objetos
2. Identificar las Semanticas de Clases y Objetos
3. Identificar las relaciones entre Clases y Objetos
4. Implementación de Clases y Objetos

1. Analisis orientado a Objetos

• Identificar Objetos
• Identificar Estructuras
• Especialización-Generalización de Estructuras
• Estructuras de Entero-Parte
• Estructuras Múltiples

1. Definición de Temas
2. Definición de Estructuras

• Identificación de los Atributos
• Posicionar los Atributos
• Identificación de las instancias de Conección
• Checar los Casos Especiales
• Especificar los Atributos

1. Definición de Servicios

• Identificación del Estado del Objeto
• Identificación de los Servicios Requeridos
• Identificación de los Mensajes de Conección
• Especificar los Servicios
• Poner el conjunto de documentos OOA juntos
• Diseño de Orientación a Objetos

• Diseño de la reutilización y Clases de Programación
• Agrupacionde Clases Problema-Dominio-Especificación
• Establezcer un protocolo agregando una clase de la generalización
• Acomodar el nivel apoyado de la herencia
• Mejora del Funcionamiento
• Apoyo del Componente de la Administración de Datos
• Agregar los Componentes de Nivel Inferior
• Revisar y desafíar las adiciones a los resultados de OOA

• Clasificación de Humanos
• Descripción de los Humanos y los escenarios de las Tareas
• Diseño de la Jerarquía del Comando
• Diseño de la Interacción Detallada
• Continuación del Prototipo
• Diseño de las Clases de los Compnentes de la Interacción Humanas
• Diseño, Contabilidad para el GUI ( cuando es applicable )

• Cuando las tareas sean requeridas
• Identificar las Tareas Manejo-Evento
• Identificar las Tareas Reloj-Conducidas
• Identificar las tareas de Prioridad y las Tareas Críticas
• Identificar un Coordinador
• Desafiar cada Tarea
• Definir cada Tarea

• Aproximación selecta de la administración de datos
• Determinar las herramientas del manejo de datos
• Diseñar el componente del Administrador de Datos

• Analisis de los Sistemas Orientado a Objetos

0. Construcción de Modelos Objeto-Relación
1. Costruccion de Modelos Objeto-Comportamiento
2. Construcción de Modelos Objeto Interacción
3. Integrar los Modelos

• Analisis del Comportamiento Orientado a Objetos

1. Definir las Metas del Analisis
2. Clarificar el Tipo de Evento
3. Generalizar el Tipo de Evento
4. Definir las Condiciones de Operación
5. Identificar las Causas de Operación
6. Refinar los Resultados del Ciclo

1. Analisis

• Identificar Clases de los Objetos
• Comenzar un diccionario de datos que contenga descripción de Clases, Atributos y Asociaciones
• Agregar asocioaciones entre Clases
• Agregar los atributos para los Objetos y sus ligas
• Organizar y simplificar las clases del objeto usando herencia.
• Probar los caminos de acceso usando panoramas e iterando los pasos antedichos como necesarios
• Agrupar las clases en los módulos, basados en el acoplador cercano y función relacionada.

• Prepar los escenarios de las secuencias típicas de la interacción.
• Identificar Eventos entre Objetos y preparar una traciabilidad de Eventos para cada Escenario
• Preparar un organigrama del Evento para el sistema.
• Desarrollar un diagrama de estado para cada clase que tenga comportamiento dinámico importante
• Comprobar para saber si hay consistencia y lo completo de los Eventos compartidos entre los diagramas de estado.

• Identificar los valores de la entrada y de la salida.
• Usar diagramas de flujo como sean necesarios para mostrar la dependencia funcional
• Describir lo que hace cada función
• Identificación de los contrastes
• Especificar los criterios de la optimización.

• Agregar operaciones claves de lo Funcional al Objeto Modelo
• Verificar la consistencia y lo completo de las Clases, Atributos, de Asociaciones, y de Operaciones
• Desarrollar modelos más detallados para explorar y para verificar los tres modelos
• Iterar los pasos antes mencionados tanto como sean necesarios para acompletar el analisis

• Organizar el Sistema en Subsistemas
• Identificar la concurrencia inherente en el problema.
• Asigne los subsistemas a los procesadores y a las tareas.
• Elegir la estrategia basica para implementar almacenes de datos en términos de estructuras de datos, archivos y bases de datos
• Identificar los recursos globales y determinar los mecanismos para controlar el acceso a ellos
• Elegir una aproximación para implementar el control del software
• Utilice la localización dentro del programa para llevar a cabo el estado, o
• Directamente implemente un estado de máquina, o
• Utilice las tareas concurrentes
• Considerar las condiciones de Límite
• Establecer las prioridades de compensación

• Obtener las operaciones para el modelo del objeto de los otros modelos:
• Encontrar una operación para cada proceso en el modelo funcional
• Definir una operación para cada evento en el modelo dinámico, dependiendo del control de la implementación

• Elegir algoritmos que minimicen el costo de implementación de la operación
• Seleccionar las estructuras de datos apropiadas para los algoritmos.
• Definir nuevas clases internas y operaciones
• Asignar responsabilidades para las operaciones que son claramiente asociadas con las clases solas.

10. ptimizar las rutas de acceso a los datos:

• Agregar asocaciones redundante para minimizar el costo del acceso y maximizar la conveniencia
• Reorganizar la computación para mayor eficiencia
• Grabar valores derivados de evitar las expresiones complicadas.

10. Implementar el software de control
11. Ajustar la estructura de clases para incrementar la herencia:

• Reorganizar y ajustar las clases y operaciones para incrementar la herencia.
• Abstraccion del comportamiento comun de los grupos y clases.
• Utilizar delegacion para compartir el comportamiento donde la herencia es semanticamente invalida.

10. iseñar la implementación de asociaciones:

• Analizar el traversal de asociaciones
• Implementar cada asociación como a distintos objetos o por adicion del atributo valor-objeto a una o ambas clases en la asociación.

10. eterminar la exacta representación de los atributos de los objetos.
11. Empaquetar clases y asociaciones en modulos.

• Para los renglones de modelos de información

• Para los renglones de Modelo de Estado

• Para el renglón de los Modelos de Proceso

• Leer y Entender las Especificaciones
• Probar varios escenarios para explorar diferentes posibilidades. Grabar los resultados en tarjetas de diseño.
• Extraer frases de sustantivos de las especificaciones y construir una lista.
• Escoger los sustantivos que pueden ser escondidos (ejem, el uso de la voz pasiva) y agregarlos a la lista
• Identificar clases candidates para las frases de los sustantivos para aplicarlas en las siguientes guías:

1. Identificar candidatos para la abstracción de superclases por agrupamiento de clases que comparten atributos comunes.
2. Uso de categorias para buscar clases que puedan ser olvidadas.
3. Escribir una declaración cortadel propósito de las clases.
4. Encontrar las responsabilidades utilizando las siguientes guías:

1. Asignar responsibilidades a las clases utilizando las siguientes guías:

Distribuir uniformemente la inteligencia del sistema

Definir responsabilidades lo mas posible

Matnener el comportamiento con la informacion relacionada

Mantener la información de cada cosa en un lugar

Compartir responsibilidades a través de las clases relacionadas.

2. Encontrar responsabilidades adicionales observando las relaciones entre las clases.

Utilizar relaciones "es-tipo-de" para encontrar herencias en las relaciones.

Utilizar relaciones "es-analogo-para" para encongrar superclases perdidas.

Utilizar relaciones "es-parte-de" para encontrar otras clases perdidas.

3. Encontrar y enlistar colaboradores examinando las relaciones asociadas con las clases.
4. Identificar colaboradores adicionales.
5. Desechar las clases que no colaboran con ellas, y las que colaboran con otras clases.
6. Construir graficas de herencias para ilustrar las relaciones de herencias entre las clases.
7. Identificar cuales clases son abstractas y cuales son concretas.
8. Dibujar Diagramas Venn representando las responsabilidades compartidas entre las clases.
9. Construir herencias de las clases.
10. Construir los contratos definidos para cada clases.
11. Dibujar y completar graficas de colaboradore del sistema.
12. Identificar posibles subsistemas con el diseño.
13. Simplifique los colaboradores entre los subsistemas
14. Construir los protocolos para cada clase. Refinar las responsibilidades entre los sets y firmas que maximizan la utilización de las clases.
15. Escribir y diseñar las especificaciones para cada clase.
16. Escribir y diseñar las especificaciones para cada subsistema.
17. Escribir y diseñar las especificaciones para cada contrato.

Una cualidad de cualquier proceso del desarrollo es el número y los tipos de entregas que el proceso genera. La documentación del ciclo de vida incluye generalmente especificaciones de requerimientos, especificaciones de diseño, especificación del sistema y subsistemas, así como casos de prueba. Las entregas para cada método se evalúan usando los criterios siguientes:

• 0 indica que no se hace ninguna mención.
• 1 indica que la mención está hecha, pero no se proporciona ninguno detalle
• 2 indica que la mención está hecha y se proporciona una definición
• 3 indica que la mención está hecha, una definición, y por lo menos se presenta un ejemplo
• 4 indica que la mención está hecha, una definición, y por lo menos se presenta un ejemplo, y se define un proceso
• 5 indica que la mención está hecha, una definición, por lo menos se presenta un ejemplo, se define un proceso, y se proporciona la heurística.

La carencia de especificaciones claras, bien-construidas es una debilidad significativa en muchos de los métodos. Sin tales especificaciones, no puede haber reutilización a excepción del código desarrollado (ningún esfuerzo del análisis o del diseño puede ser reutilizado, puesto que no esta documentado). Además, la prueba se afecta seriamente puesto que las pruebas no se pueden hacer sin tales especificaciones. Algunos métodos consideran las especificaciones como solamente necesarias cuando la "programación es grande." Rumbaugh, por ejemplo, comenta que la documentación de clases y métodos es importante al escribir grandes y complejos programas, que implican equipos de programadores; asumiendo que aparentemente es menos importante para los programas pequeños.

La cobertura del ciclo de vida proporciona una idea de lo completo de la metodología. Una metodología que cubre todos los aspectos del ciclo de vida del desarrollo del sistema ofrece una solución atractiva a la organización ya que la metodología por sí misma asegura algo completo y consistente. Si una organización, por ejemplo, requiere o decide "mezclar y emparejar" una aproximación del análisis de una metodología con la aproximación del diseño de otra, la organización debe enfrentar la responsabilidad de la consistencia y de la completa transición a partir de una fase del ciclo de vida a otra. Tales estrategias de "mezcla y emparejamiento" introducen un elemento del riesgo en la aproximación.

• 0 indica que no se hace ninguna mención.
• 1 indica que la mención está hecha, pero no se proporciona ningun detalle.
• 2 indica que la mención está hecha y una definición está provista.
• 3 indica que la mención está hecha, una definición, y por lo menos se presenta un ejemplo
• 4 indica que la mención está hecha, una definición, y por lo menos se presenta un ejemplo, y se define un proceso.
• 5 indica que la mención está hecha, una definición, por lo menos se presenta un ejemplo, se define un proceso, y se provee la heurística.

Cada metodología debe describir un proceso que, si es seguido, debe brindar un sistema apropiado de productos (ejem, productos del análisis, productos del diseño, código, y casos de la prueba). La claridad de un proceso simplifica la ejecución y la introducción del proceso en una organización de desarrollo. Un proceso bien definido tiene las siguientes cualidades:

• Cada paso esta bien definido, con instrucciones claras, tips y técnicas apropiadas
• Las entradas de cada paso se definen, con posibles ejemplos.
• Las salidas, o los productos, de cada paso se definen, con posibles ejemplos.
• Se delinea el rol responsable en la ejecución de cada paso.
• Se proporciona software de aseguramiento de la calidad e instrucciones a seguir.

La heurística proporciona tips para asistir al analista y al diseñador en la ejecución de los pasos del proceso. En algunos casos esta heurística es simple y obvia, mientras que en otros son menos obvias. La disponibilidad de un sistema grande de heurística simplifica la ejecución del proceso. Estos puntos sirven como un indicador al grado de ayuda que el método proporciona para la heurística. Un "1" indica pocos si no es que ninguna heurística, mientras que "3" indica cinco o más heurística.

Un proceso definido debe contener reglas para verificar los productos desarrollados. Por ejemplo, los diversos modelos construidos pueden presentar la información que permite la verificación de otros modelos. O una especificación del objeto y de la clase puede ser comprobable contra los modelos usados en su construcción. Sin tales reglas, no son posibles, la verificación de las especificaciones y otros productos.

Cada metodología debe proporcionar una forma que permita la validación independiente de los productos del desarrollo con el cliente, independientemente de la notación de la misma. Modelos ejecutables, prototipos, y los flujos de escenarios son algunos ejemplos.

La tabla siguiente identifica los recursos disponibles para apoyar la metodología. Estos recursos incluyen en sitio o entrenamiento público, si el entrenamiento está disponible en fuentes solas o múltiples, la disponibilidad de las cintas video del entrenamiento, el número de los textos disponibles que se ocupan de la metodología, y los servicios de consulta disponibles. Además, las librerías de componentes reutilizables disponibles que se construyeron para usar la metodología.

Esta es una valoración subjetiva de la complejidad de cada método. Esta valoración se basa en el número de los modelos presentes en cada notación, la cantidad de maestría requerida para utilizar el método, el número de los pasos presentes en cada proceso, y la claridad de la aproximación. De acuerdo con estos factores, se hace una estimación del entrenamiento requerido necesitado para utilizar con eficacia el método. Los métodos altamente complejos requieren la mayoría del entrenamiento (mas de 6 semanas), los métodos medios de la complejidad requerirán aproximadamente 3-6 semanas de entrenamiento, y los métodos bajos de la complejidad requerirán menos de 3 semanas de entrenamiento. En todos los casos al período del tiempo será requerido (3-6 meses) antes de que el personal haga uso del método.

La independencia del lenguaje es una cualidad deseable de cualquier metodología esto provee una portabilidad de los productos del análisis y del diseño a través de los lenguajes.

Estas son algunas de las herramientas CASE orientadas a objetos disponibles para las metodologias presentadas en este documento.

En las metodologías tradicionales se produce una división entre los dos elementos de un sistema: funciones que llevan a cabo los programas y datos que se almacenan en archivos o bases de datos. Y por otro lado, la orientación al objeto de un enfoque unificador de ambos aspectos, que seunen en los objetos.

En las metodologías tradicionales las herramientas que utilizan para el análisis son: Diagramas de Flujos de Datos, Diccionarios de Datos, Diagramas Entidad-Relación, Diagramas de Trancisión de Estado, Especificaciones de procesos. En las metodologías orientadas a objetos se emplean distintos modelos depende de la metodología, entre los principales están Modelo de objetos, Modelo de Estado u Objeto-Estado, entre otros.

A continuación veremos un ejemplo de un sistema de Cuentas Bancarias, visto por los dos enfoques:

Representada por Diagrama de Flujo de Datos

Representada por Diagrama de Objetos de Rumbaugh

Ahora veamos un ejemplo de la representación de dinámica de un sistema de Clima (Aire acondicionado), modelado por los dos enfoques de metodologías:

Representada por Diagrama de Flujo

Representada por un Diagrama de Transición de Estado de Booch

• La organización esta provista pesadamente en herramientas, tecnología, y entrenamiento basado en datos o ingeniería de información, y desea cambios mínimos a esta base.

• La organización está construyendo una gran aplicacion, con enfoque en tiempo real.

• El desarrollo requiere altas pruebas confiabilidad.

• El esfuerzo está orientado a componentes reutilizables para la venta comercial.

• Interesado en un método donde la única preocupación es que el proceso del desarrollo esté bien definido.

En el transcurso del tiempo el ambiente computacional ha ido evolucionando en todos los aspectos, las computadoras cada día son mejores y más rapidas. Los usuarios se vuelven cada vez mas exigentes y buscan el servicio de los sistemas estando en cualquier parte del mundo, no solamente en sus oficinas. La tecnología de la información ha ejercido un profundo impacto en la sociedad por lo que ahora se le llama la Era de la Información. Los empleados administrativos rebasaron el número de los trabajadores de producció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 sistemas se han ido enfocando mas a la comodidad del usuario lo cual ha provocado dos cosas, que se realicen sistemas cada vez mas complejos y que se desarrollen muchas metodologías buscando la manera optima de desarrollarlos.

Las metodogías también han evolucionado. Inicialmente hubo un periodo de Desarrollo Convencional, después surge el Desarrollo Estructurado y en la actualidad aparece el paradigma de la Orientación a Objetos como un nuevo enfoque en la ingeniería de software.

A la fecha se han desarrollado muchísimas metodología enfocadas a la Orientación a Objetos, en esta investigación solo vimos 8 de ellas, siendo de las mas representativas de este paradigma.

Cuando inicié esta investigación yo contaba con ninguna o poquísimas bases de Orientación a Objetos. Poco a poco al ir leyendo y conociendo cada metodología entendí mejor este paradigma. Una de las metodologías que me ayudaron mucho a comprender la Orientación a Objetos fue la de Booch, ya que se apoya de muchos gráficos para definir los conceptos básicos de Orientación a Objetos, por lo que yo la recomiendo para principiantes.

Por otro lado Rumbaugh me pareció muy completa porque es una de las que más puntuación tiene con respecto a entregas de productos dentro de cada etapa del ciclo de vida, cuenta con bastantes tips para el analista y diseñadores para la identificación de clases, operaciones, estados y subsistemas; cuenta con reglas de verificación y de validación y existen suficientes recursos para aprenderla.

Debido a las comparaciones realizadas en este documento, podemos darnos cuenta que la debilidad que tiene en cierta area una metodología se compensa con alguna fuerza que tiene en otro punto, siendo asi todas útiles dependiendo del caso que tengamos para aplicarlas. Pero por lo que a mi respecta, y con lo anteriormente expuesto, las metodologías con las que yo propongo para desarrollar sistemas de calidad basados en Orientación a Objetos son Booch y Rumbaugh.