Metodologías modernas de desarrollo de Sistemas de Información (página 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.
- 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.
- Implementar el software de control
- 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.
- 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.
- eterminar la exacta representación de los
atributos de los objetos. - 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
- Identificar candidatos para la abstracción de
superclases por agrupamiento de clases que comparten atributos
comunes. - Uso de categorias para buscar clases que puedan ser
olvidadas. - Escribir una declaración cortadel
propósito de las clases. - 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.
- Asignar responsibilidades a las clases utilizando las
siguientes guías: Distribuir uniformemente la inteligencia del sistema
Definir responsabilidades lo mas posible
Matnener el comportamiento con la informacion
relacionadaMantener la información de cada cosa en un
lugarCompartir 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.- Encontrar responsabilidades adicionales observando
las relaciones entre las clases. - Encontrar y enlistar colaboradores examinando las
relaciones asociadas con las clases. - Identificar colaboradores adicionales.
- Desechar las clases que no colaboran con ellas, y las
que colaboran con otras clases. - Construir graficas de herencias para ilustrar las
relaciones de herencias entre las clases. - Identificar cuales clases son abstractas y cuales son
concretas. - Dibujar Diagramas Venn representando las
responsabilidades compartidas entre las clases. - Construir herencias de las clases.
- Construir los contratos
definidos para cada clases. - Dibujar y completar graficas de colaboradore del
sistema. - Identificar posibles subsistemas con el
diseño. - Simplifique los colaboradores entre los
subsistemas - Construir los protocolos
para cada clase. Refinar las responsibilidades entre los sets y
firmas que maximizan la utilización de las
clases. - Escribir y diseñar las especificaciones para
cada clase. - Escribir y diseñar las especificaciones para
cada subsistema. - 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 | Requerimientos en el | 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 | 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 | Identificación de | Colocación de | Identifincación de | Identifincación de | 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 |
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 |
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 |
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 | Plataforma en la que | Descripcion y Metodologias que |
Ptech | Unix (DECStation, RS6000, Silicon | Martin y Odell |
Teamwork | VAX/VMS, Unix, OS/2, | set de herramientas CASE con capacidades de |
OMTool | Unix | Analisis y diseño orientados a objetos |
Iconix Power Tools | Macintosh | Multiusuario, set de herramientas de desarrollo OO |
OMW | WIndows and Unix | Martin and Odell |
ObjectMaker | MS-Windows, | Analisis y diseño orientado a objetos |
OOATool | Unix, Macintosh, MS-Windows | Analisis Orientado a Objetos |
Object System/Designer | MS-Windows | Diseño Orientado a Objetos |
System Architect | MS-Windows, OS/2 | Diseño Orientado a Objetos |
Rose | Unix, AIX | Analisis y Diseño Orientado a Objetos |
ATRIOM | MS-Windows | Analisis y Diseño Orientado a Objetos |
TurboCase | Macintosh | Analisis Orientado a Objetos, Diseño |
OOTher | Windows | Herramienta de documentacion OO |
Metodologia | Numero de Herramientas |
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
- . COMPARACION DE METODOLOGIA TRADICIONAL CON
- 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.
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.
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.
Página anterior | Volver al principio del trabajo | Página siguiente |