Monografias.com > Sin categoría
Descargar Imprimir Comentar Ver trabajos relacionados

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




Enviado por araceli_lecuanda



Partes: 1, 2, 3

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

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

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

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

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

3. CONCEPTOS BASICOS DE ORIENTACION A
OBJETOS

Qué es Orientado a Objetos?

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

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

Objeto.

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

Características de los Objetos.

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

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

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

Clase Bicicleta:

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

Operaciones: mover, reparar, cambiar
velocidad

Objetos: Triangulo, Cuadrado, Octagono

Clase Poligonos:

Atributos: vertices, color del borde,
color del interior

Operaciones: dibujar, borrar, mover

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

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

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

4.
QUE ES UNA METODOLOGIA

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

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

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

5.
EL ENFOQUE DE ESTA INVESTIGACION

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

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

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

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

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

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

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

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

6.
RESULTADO ESPERADO

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

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

7. CONCEPTOS

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

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

Berard 1992.

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

Booch 1991.

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

Coad y Yourdon 1990.

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

Embley y Kurtz 1990.

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

Martin y Odell 1992.

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

Rumbaugh 1991.

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

Shlaer y Mellor 1992.

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

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

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

Wrifs-Brock 1990.

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

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

ANALISIS

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

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

Metodología

Mención de
abstracción

Unicidad o
identidad

Comportamiento o
acciones

Estado

Berard

X

X

Booch

X

X

X

Coad y Yourdon

X

X

Embley

X

Martin y Odell

X

Rumbaugh

X

Shlaer y Mellor

X

Wirfs-Brock

X

X

X

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

Berard 1992.

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

Booch 1991.

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

Coad y Yourdon 1990.

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

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

Embley y Kurtz 1990.

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

Martin y Odell 1992.

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

Rumbaugh 1991.

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

Shlaer y Mellor 1992.

No provee una definición explicita de
"clase"

Wrifs-Brock 1990.

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

ANALISIS

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

Metodología

Mención de
abstracción

Mención de
Estructura

Mención de
Comportamiento

Estado

Relaciones

Berard

X

X

X

Booch

X

X

Coad y Yourdon

X

X

Embley

X

X

Martin y Odell

X

X

Rumbaugh

X

X

X

X

Shlaer y Mellor

Wirfs-Brock

X

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

Berard 1992.

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

Booch 1991.

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

Coad y Yourdon 1990.

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

Embley y Kurtz 1990.

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

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

Martin y Odell 1992.

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

Rumbaugh 1991.

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

Shlaer y Mellor 1992.

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

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

Wrifs-Brock 1990.

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

ANALISIS

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

Metodología

Operación =
Método

Externo

Interno

Estado

Berard

X

X

Booch

X

X

Coad y Yourdon

X

Embley

X

Martin y Odell

X

Rumbaugh

X

X

Shlaer y Mellor

X

X

X

Wirfs-Brock

X

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

Berard 1992.

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

Booch 1991.

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

Coad y Yourdon 1990.

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

Partes: 1, 2, 3
 Página anterior Volver al principio del trabajoPágina siguiente 

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.

Categorias
Newsletter