Agregar a favoritos      Ayuda      Português      Ingles     

Metodologías modernas de desarrollo de Sistemas de Información

Enviado por araceli_lecuanda



  1. Historia
  2. Conceptos básicos de orientación a objetos
  3. Que es una metodología
  4. El enfoque de esta investigación
  5. Resultado esperado
  6. Conceptos
  7. Notaciones
  8. Procesos
  9. Aspectos pragmáticos
  10. Aplicación de las metodologías
  11. Conclusión
  12. Bibliografía
  1. INTRODUCCION

El propósito de este trabajo es complementar mi examen profesional con el tema: Sistemas de Información, para la Licenciatura de Sistemas Computacionales. En esta investigación se comparan varias Metdologías Modernas para el Desarrollo de Sistemas de Información. Estas utilizan el paradigma de Orientación a Objetos. Este es el enfoque actual de los Desarrollos de Sistemas; primero se tuvo un enfoque en Desarrollo Convencional, despues Estructurado y actualmente Orientado a Objetos.

En esta comparación lo que se busca es en primer lugar saber cuales son los nombres de tantas metodologías existentes y en segundo lugar, conocer el enfoque de cada una, la manera en que definen los conceptos básicos de Orientación a Objetos, cómo son sus notaciones, sus procesos, qué parte del ciclo de vida abarcan o si abarcan todo el ciclo de vida. Qué recursos disponibles hay para utilizar una de estas metodologías, existen libros disponibles, qué tipo de conocimientos necesitamos tener para poder utilizarlas, en qué lenguajes de programación se apoyan.

Y teneniendo esta base de conocimientos, ahora sí poder elegir una de ellas para utilizarla en el desarrollo de los sistemas en los que sea participe tanto yo, como cualquier persona que lea este documento.

2. HISTORIA

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.

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.

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

Embley y Kurtz 1990.

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

Martin y Odell 1992.

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

Rumbaugh 1991.

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.

Shlaer y Mellor 1992.

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

Wrifs-Brock 1990.

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

E. SIMBOLOGIA UTILIZADA PARA REPRESENTAR LOS CONCEPTOS POR BOOCH, COAD & YOURDON, Y RUMBAUGH

OBJETOS

 

 

 

 

 

 

 

CLASES

 

 

 

 

 

 

 

 

 

ASOCIACION

 

 

 

 

 

 

 

 

HERENCIA

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

AGREGACION

 

 

 

 

 

 

 

 

 

 

 

F. COMO LIDIA EL METODO CON CONCEPTOS QUE SON MAS GRANDES Y QUE PUEDEN SER REPRESENTADOS RAZONABLEMENTE POR UNA CLASE

Berard 1992.

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

Booch 1991.

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.

Coad y Yourdon 1990.

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.

Embley y Kurtz 1990.

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

Martin y Odell 1992.

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

Rumbaugh 1991.

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.

Shlaer y Mellor 1992.

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.

Wrifs-Brock 1990.

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.

G. ENFOQUE A LA ORIENTACION DE OBJETOS

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.

8. NOTACIONES

A. COMPONENTES DE LA NOTACIÓN DE LAS MÉTODOLOGIAS

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

Berard 1992.

  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

Booch 1991.

  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

Coad y Yourdon 1990.

  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

Embley y Kurtz 1990.

  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

Martin y Odell 1992.

  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

Rumbaugh 1991.

  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

Shlaer y Mellor 1992.

  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

Wirfs-Brock 1990.

  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.

B. REPRESENTACIONES GRAFICAS DE ALGUNOS DIAGRAMAS UTILIZADOS POR BOOCH, COAD & YOURDON, Y RUMBAUGH

BOOCH

Para ver el gráfico seleccione la opción "Descargar" 

COAD & YOURDON

 Para ver el gráfico seleccione la opción "Descargar" 

RUMBAUGH

 Para ver el gráfico seleccione la opción "Descargar" 

C. CONCEPTOS ESTÁTICOS QUE LA NOTACIÓN ES CAPAZ DE EXPRESAR

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?

Metodología

Agregación

Especialización

Comunicación

Módulo de Interfaz

Calificaciones para la reutilización

Berard

Red de Semantica

Red de Semantica

Diagrama Objeto Mensaje

Grafica de la unidad del Programa

Red de Semantica

Booch

Diagrama de Clases

Diagrama de Clases

Diagrama de Clases

Modulo

Diagrama de Objetos

Coad y Yourdon

Entero-Parte

Estrcutura Generalizacion-Especializacion

Mensaje

Embley

Modelo Relacion Objeto

Modelo Relacion Objeto

Modelo Relacion Objeto

Martin y Odell

Diagrama de composicion de objetos

Diagrama de la Jerarqia Objeto Generalizacion

Diagramas de flujo del objeto

Rumbaugh

Modelo del Objeto

Modelo del Objeto

Escenario

Shlaer y Mellor

Herencia

Modelo Comunicacion de Objetos

Diagrama de clases

Wirfs-Brock

Tarjeta de Clases

Jerarquias

Colaboradores

D. CONCEPTOS DINÁMICOS QUE LA NOTACIÓN ES CAPAZ DE EXPRESAR

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.

Metodologia

Cambios de Estado

Tiempos

Berard

Diagrama Transicion Estado / Grafica Petri Net

Diagrama de Tiempos

Booch

Diagrama Transicion Estado

Diagrama de Tiempos

Coad y Yourdon

Diagrama Estado

Embley

Red de Estado

Red de Estado

Martin y Odell

Cambios de Estado

Rumbaugh

Diagrama de Estado

Estado Extendido

Shlaer y Mellor

Modelo de Estado

Wirfs-Brock

E. REGLAS EXPLÍCITAS PARA DEFINIR LOS SÍMBOLOS DE LAS NOTACIONES

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.

Berard

La notación no es formalmente definida. Se proporcionan numerosos ejemplos

Booch

La notación se documenta en parte de su libro. Se proporcionan numerosos ejemplos

Coad y Yourdon

Proporciona las reglas específicas para la simbología de la notación el apéndice A, del análisis orientado a objetos y proporciona numerosos ejemplos.

Embley

La notación es formalmente definida en el Apendice A, y proporciona numerosos ejemplos

Martin y Odell

Se define la notacion en uno de sus capitulos y tambien Diagramas Estandares son recomendados

Rumbaugh

La notación si se define en su libro.

Shlaer y Mellor

La notacion es formalmente definida a traves de sus libro.

Wirfs-Brock

La notación no se define formalmente, pero se presentan numerosos 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.

Metodologia

Sintaxis Definida

Semántica Definida

Provisión de Ejemplos

Heurísticas Presentadas

Berard

X

X

Booch

X

X

X

X

Coad y Yourdon

X

X

X

X

Embley

X

X

X

X

Martin y Odell

X

X

X

Rumbaugh

X

X

X

X

Shlaer y Mellor

X

X

X

X

Wirfs-Brock

X

X

X

X

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.

E. MECANISMO DE PARTICION DENTRO DE LA NOTACION

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:

Metodología

Mecanismo de Partición

Berard

Kits, sistemas de Interaccion de Objetos

Booch

Subsistemas, Procesadores

Coad y Yourdon

Temas

Embley

Vistas de Alto Nivel

Martin y Odell

*

Rumbaugh

Subsistemas

Shlaer y Mellor

Subsistemas

Wirfs-Brock

Subsistemas y Frameworks

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

9. PROCESOS

A. PASOS DEL PROCESO DE DESARROLLO DE CADA METODOLOGÍA

Berard 1992.

  • 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

Booch 1991.

  • 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

Coad y Yourdon 1990.

  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ñar el componente del dominio del problema

  • 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

Diseñar el Componente Humano de la Interacción

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

Diseño del componente del Manejo de tareas

  • 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

Diseño del Componente del Manejo de Datos

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

Embley y Kurtz 1990.

  • Analisis de los Sistemas Orientado a Objetos
  1. Construcción de Modelos Objeto-Relación
  2. Costruccion de Modelos Objeto-Comportamiento
  3. Construcción de Modelos Objeto Interacción
  4. Integrar los Modelos

Martin y Odell 1992.

  • 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

Rumbaugh 1991.

  1. Analisis

2Escribir u obtener una descripción inicial del problema (declaración del problema)

3Construir in modelo del Objeto

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

4Desarrollar un Modelo Dinámico

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

5Construir un Modelo Funcional

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

6Verificar, iterar, y refinar los tres modelos

  • 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

7Diseño del Sistema

  • 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

8Diseño del Objeto

  • 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

9Diseño de algoritmos para implementar las operaciones:

  • 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.
  1. 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.
  1. Implementar el software de control
  2. 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.
  1. 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.
  1. eterminar la exacta representación de los atributos de los objetos.
  2. Empaquetar clases y asociaciones en modulos.

Shlaer y Mellor 1992.

  • Para los renglones de modelos de información

Busqueda

Desarrollo y Refinación de los Modelos

Integrar con Otros Modelos

Revisar

  • Para los renglones de Modelo de Estado

Construir el Modelo Estado

Verificar las interacciones entre los modelos estados y los modelos de comunicación de objetos

Construir o modificar, los modelos de comunicación de subsistemas

Revisar que esten correctos y su consistencia

  • Para el renglón de los Modelos de Proceso

Construcción de Diagramas de Flujo de Datos Activos

Integrar con las Tablas de Proceso de Estado y producir los modelos de acceso de datos para los subsistemas y modificar los modelos de acceso a subsistemas

Revisar

Wirfs-Brock 1990.

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

Modelo de objetos físicos

Modelo conceptual de entidades

Uso de un termino solo para cada concepto

Ser cuidadoso en el uso de adjectivos

Modelo de categorias de objetos

Modelo de interfaces externas

Modelo los valores de los abributos de los objetos

  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:

Recuerde el propósito de cada clase, según lo implicado por su nombre y especificado en la declaración del propósito

Extraiga responsabilidades de la especificación buscando acciones e información

Identifique responsabilidades implicadas por las relaciones entre clases.

  1. Asignar responsibilidades a las clases utilizando las siguientes guías:
  2. 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.

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

B. VISION GRAFICA DEL PROCESO DE DESARROLLO DE BOOCH, COAD & YOURDON, Y RUMBAUGH

BOOCH

 Para ver el gráfico seleccione la opción "Descargar"

COAD & YOURDON

 Para ver el gráfico seleccione la opción "Descargar" 

RUMBAUGH

  Para ver el gráfico seleccione la opción "Descargar"

C. ENTREGAS QUÉ GENERA EL PROCESO DEL DESARROLLO

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.

Metodología

Requerimientos

Diseño

Pruebas

Objetos/Clases

Subsistemas

Total

Berard

2

5

5

5

2

19

Booch

1

2

0

1

1

5

Coad y Yourdon

2

2

0

5

0

9

Embley

5

1

0

1

1

8

Martin y Odell

0

0

0

0

0

0

Rumbaugh

2

2

0

5

0

9

Shlaer y Mellor

5

5

0

5

4

19

Wirfs-Brock

1

5

0

5

5

16

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.

D. ASPECTOS DEL CICLO DE VIDA QUE SON CUBIERTOS POR LA APROXIMACION

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.

Metodología

Dominio de Análisis

Requerimientos en el Análisis

Diseño

Implementación

Pruebas

Total

Berard

4

4

5

5

5

23

Booch

4

2

5

4

0

15

Coad y Yourdon

1

5

5

3

3

17

Embley

0

5

1

0

0

6

Martin y Odell

0

3

5

0

0

8

Rumbaugh

0

5

5

3

2

15

Shlaer y Mellor

0

5

5

1

0

11

Wirfs-Brock

0

3

5

4

3

15

E. DEFINICION DE LOS PASOS DEL PROCESO

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.

Metodología

Definición de Pasos

Entradas

Salidas

Rol

QA

Total

Berard

X

X

X

X

X

5

Booch

X

X

X

X

4

Coad and Yourdon

X

X

X

X

4

Embley and Kurtz

X

X

2

Martin and Odell

X

X

2

Rumbaugh

X

X

X

X

4

Shlaer and Mellor

X

X

2

Wirfs-Brock

X

X

X

3

F. HEURÍSTICA DISPONIBLE PARA LOS PASOS DE PROCESO

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.

Metodología

Identificación de Clases

Identificación de Operaciones

Colocación de Operaciones

Identifincación de Subsistemas

Identifincación de Estados

Total

Berard

1

1

1

3

1

7

Booch

3

3

3

3

3

15

Coad and Yourdon

3

3

0

0

1

7

Embley and Kurtz

3

3

1

1

3

11

Martin and Odell

3

3

1

-

3

10

Rumbaugh

3

3

1

2

3

12

Shlaer and Mellor

3

1

1

3

3

11

Wirfs-Brock

3

1

1

3

-

8

G. VERIFICACION DEL PROCESO

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.

Metodología

Reglas de Verificación

Berard

Si provee

Booch

Coad and Yourdon

Si provee

Embley and Kurtz

Si provee

Martin and Odell

Rumbaugh

Si provee

Shlaer and Mellor

Si provee

Wirfs-Brock

Si provee

H. VALIDACION DEL PROCESO

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.

Metodología

Reglas de Validación

Berard

Prototipo

Booch

Prototipo

Coad and Yourdon

Prototipo

Embley and Kurtz

Martin and Odell

Prototipo

Rumbaugh

Flujo de Eventos

Shlaer and Mellor

Wirfs-Brock

Prototipo

10. ASPECTOS PRAGMATICOS

A. RECURSOS DE AYUDA DISPONIBLE

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.

Metodogías

Entrenamiento

Recursos

Video

Textos

Librerías

Berard

Ambas

2

3

1

Booch

Ambas

Por lo menos 2

Si

1

1

Coad and Yourdon

Ambas

1

Si

2

Embley and Kurtz

1

Martin and Odell

Ambas

1

Si

1

Rumbaugh

Ambas

1

Si

1

Shlaer and Mellor

Ambas

1

2

Wirfs-Brock

Ambas

Por lo menos 2

1

B. ENTRENAMIENTO REQUERIDO PARA LA UTILIZACION DE LA METODOLOGIA (Independiente del entrenamiento del Lenguaje de programación)

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.

Metodología

Complejidad

Berard

Medio

Booch

Medio

Coad and Yourdon

Bajo

Embley and Kurtz

Alto

Martin and Odell

Alto

Rumbaugh

Medio

Shlaer and Mellor

Alto

Wirfs-Brock

Medio

C. LENGUAJES QUE UTILIZAN LAS METODOLOGIAS

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.

Metodogias

Ada

Eiffel

Smalltalk

C++

CLOS

Total

Berard

X

X

X

X

X

5

Booch

X

X

X

X

X

5

Coad and Yourdon

X

X

X

3

Embley and Kurtz

0

Martin and Odell

0

Rumbaugh

X

X

X

X

4

Shlaer and Mellor

X

X

2

Wirfs-Brock

X

1

D. HERRAMIENTAS AUTOMATIZADAS DISPONIBLES PARA CADA METODOLOGIA

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

Nombre de la herramienta

Plataforma en la que trabaja

Descripcion y Metodologias que Suporta

Ptech

Unix (DECStation, RS6000, Silicon Graphics)

Martin y Odell

Teamwork

VAX/VMS, Unix, OS/2, PC-DOS

set de herramientas CASE con capacidades de orientacion a objetos Shlaer/Mellor, HOOD

OMTool

Unix

Analisis y diseño orientados a objetos Rumbaugh

Iconix Power Tools

Macintosh

Multiusuario, set de herramientas de desarrollo OO Rumbaugh, Coad/Yourdon, y Booch

OMW

WIndows and Unix

Martin and Odell

ObjectMaker

MS-Windows, Unix, Macintosh

Analisis y diseño orientado a objetos Berard, Booch, Coad/Yourdon, Rumbaugh,

OOATool

Unix, Macintosh, MS-Windows

Analisis Orientado a Objetos Coad/Yourdon

Object System/Designer

MS-Windows

Diseño Orientado a Objetos Booch

System Architect

MS-Windows, OS/2

Diseño Orientado a Objetos Booch

Rose

Unix, AIX

Analisis y Diseño Orientado a Objetos Booch

ATRIOM

MS-Windows

Analisis y Diseño Orientado a Objetos Booch, Coad/Yourdon, Rumbaugh Shlaer/Mellor

TurboCase

Macintosh

Analisis Orientado a Objetos, Diseño estructurado Wirfs-Brock

OOTher

Windows

Herramienta de documentacion OO Coad/Yourdon

Metodologia

Numero de Herramientas Disponibles

Berard

2

Booch

7

Coad and Yourdon

7

Embley and Kurtz

-

Martin and Odell

2

Rumbaugh

4

Shlaer and Mellor

3

Wirfs-Brock

1

    • . COMPARACION DE METODOLOGIA TRADICIONAL CON METODOLOGIA ORIENTADA A OBJETOS
  • Las metodologías de análisis y diseño estructurado, se examinan los sistemas desde el punto de vista de las funciones o tareas que deben realizar, tareas que se van descomponiendo sucesivamente en otras tareas mas pequeñas y que forman los bloques o módulos de las aplicaciones. En la orientación a objeto, por su parte, cobra mucho más importancia el aspecto de "modelado" del sistema, examinando el dominio del problema como un conjunto de ojbetos que interactúan entres sí.

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:

METODOLOGIA TRADICIONAL

Representada por Diagrama de Flujo de Datos

 Para ver el gráfico seleccione la opción "Descargar" 

METODOLOGIA ORIENTADA A OBJETOS

Representada por Diagrama de Objetos de Rumbaugh

 Para ver el gráfico seleccione la opción "Descargar" 

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:

METODOLOGIA TRADICIONAL

Representada por Diagrama de Flujo

 Para ver el gráfico seleccione la opción "Descargar" 

METODOLOGIA ORIENTADA A OBJETOS

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

 Para ver el gráfico seleccione la opción "Descargar" 

12. APLICACIÓN DE LAS METODOLOGIAS

  • La organización desea explorar la orientación a objetos y está solamente interesada en una respuesta "qué es un objeto?"

Seleccione los mas altos candidatos de conceptos, como son: Booch, Berard, y Wirfs-Brock.

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

Seleccione a candidatos que tienen conceptos que no son tan altos en orientacion a objetos. Tales como Rumbaugh, Shlaer y Mellor, y Kurtz y Embley puesto que no están muy "orientados al objeto." Como cada uno de estas aproximaciones todavía hace el uso significativo en modelos de datos, y el impacto en las herramientas, la tecnología, y el entrenamiento sería mínimamente afectado.

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

Seleccione los metodos donde el proceso se ocupa de las ediciones grandes de aplicaciones, y de la pragmática basada en tamaño del proyecto y ayuda en tiempo real. Booch, Berard, Shlaer y Mellor, y posiblemente, Rumbaugh son los posibles a elegir.

  • El desarrollo requiere altas pruebas confiabilidad.

Berard provee una gran ayuda en esto, Booch, Shlaer/Mellor, y Rumbaugh le siguen.

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

Seleccione el modelo y la pragmática donde su desarrollo esta basado en la reutilización. Berard y Booch proporcionan la mayoría de esta ayuda.

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

Seleccione los metodos de Rumbaugh, Shlaer y Mellor, Wirfs-Brock, Berard, son procesos relativamente bien definidos.

13. CONCLUSION

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.

14. BIBLIOGRAFIA

Berard, Edward V. (1998). Basic Object-Oriented Concepts. Consultado a www.toa.com/pub/oobasics/oobasics.htm en fecha 26 de Nov. de 2002.

Booch, G. (1996). Análisis y Diseño Orientado a Objetos con aplicaciones. México: Pearson Educación.

Brinkkemper, S.; Hong, S.; Bulthuis, A.; Goor, G. (1994). Object-Oriented Analysis and Design Methods Contents. Consultado a http://panoramix.univ_paris1.fr/crinfo/ dmrg/oodoc/oodoc/oo-contents.html en fecha 29 de Nov. de 2002.

Coleman, D.; Arnold, P.; Bodoff, S.; Dollin, C.; Gilchrist, H.; Hayes, F.; Jeremaes, P. Object-Oriented Development The Fusion Method. Estados Unidos: Prentice Hall

Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.; Lorensen, W. (1999); Modelado y Diseño Orientados a Objetos; Metodología OMT. España: Prentice Hall.

Shneider, P. (S.F.). The Booch Method. Consultado a www.ifra.ing.tu-bs.de/docs/BoochReferenz/ en fecha 29 de Nov. de 2002.

The Object Agency, Inc. (1995). A Comparison of Object-Oriented Development Methodologies. Consultado a www.toa.com/smnn?mcr.html en fecha 26 de Nov. de 2002.

Yourdon, E. (1994). Object-Oriented Systems Design an Integrated Approach. Estados Unidos: Yourdon Press.

 

 

 

 

Autor:

Araceli Torres Lecuanda

 

 


Comentarios


Trabajos relacionados

Ver mas trabajos de General

 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.


Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Iniciar sesión

Ingrese el e-mail y contraseña con el que está registrado en Monografias.com

   
 

Regístrese gratis

¿Olvidó su contraseña?

Ayuda