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

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




Enviado por araceli_lecuanda



Partes: 1, 2, 3

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

 

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