INGENIERÍA DE SOFTWARE I
Metodología Booch (OOD)
“[El diseño orientado a objetos] es el
método que lleva a una descomposición Orientado a Objetos. Aplicando DOO, se
crea software resistente al cambio y escrito con economía de expresión. Se
logra un mayor nivel de confianza en la corrección del software a través de la
división inteligente de su espacio de estados. En última instancia, se reducen
los riesgos inherentes al desarrollo de sistemas” (Booch, 1994) .
El enfoque de Grady Booch para OOD es uno de los más
populares, y es apoyado por una variedad de herramientas de precio razonable
que van desde Visio a Rational Rose. Booch es el científico director en el
Rational Software, que produce a Rational Rose.
Abarca un
“microproceso de desarrollo” y un “macroproceso de desarrollo”.
El Método Booch
El método original de Booch comienza por un análisis de flujo de
datos, que se utiliza entonces como ayuda para identificar objetos, buscando
tanto objetos concretos como objetos abstractos en el espacio del problema, que
se encontraran a partir de las burbujas y almacenes de datos
en el diagrama de flujo de datos (DFD). (Romero Guillen, 2005)
Está orientado a analizar el modo, los documentos, y requisitos del
sistema en desarrollo. La Metodología de Booch ofrece un desarrollo orientado a
objetos en las fases de análisis y diseño. La fase de análisis se divide en los siguientes pasos:
·
Establecer los requerimientos
desde la perspectiva del cliente. Este paso genera una descripción de alto
nivel de las funciones y estructuras del sistema.
·
Análisis del dominio. El
análisis de dominio se logra mediante la definición de clases de objetos, sus
atributos, la herencia, y los métodos. Además los diagramas de estado de los objetos son
establecidos.
·
Finalmente la Validación.
La fase de análisis se repite entre el paso de los requerimientos
del cliente, el paso de análisis del dominio y la etapa de validación hasta
obtener la consistencia se alcanza.
Una vez que la fase de análisis se ha completado la metodología
Booch desarrolla la arquitectura en la fase de diseño. Esta fase es iterativa.
Un diseño lógico es establecido a un diseño físico, donde detalles de hilos de
ejecución, procesos, rendimiento, tipo de datos, ubicación, estructuras de
datos, visibilidad y distribución son establecidas. Un prototipo se crea y es
probado. El proceso se repite entre diseño lógico, diseño físico, prototipos y
pruebas.
Esta metodología es secuencial tomando en cuenta que primero se
realiza la fase de análisis y a continuación la fase de diseño. Y es cíclica
porque estas etapas constan de pasos iterativos. Además esta metodología se
centra en las fases de análisis y diseño y no toma muy en cuenta la aplicación
de la fase de pruebas. (LeRoi Burback, 1998) .
El cambio se prevé en todas las fases. Se trata de una reducción del
riesgo en el proceso impulsado.
Modelos del Método Booch
Modelo de Lógica
Está
representado en la estructura clase-objeto.
a)
Diagramas de Clase
En este tipo de diagramas se muestran las clases con sus
relaciones, o lo que es lo mismo, la estructura de clases.
El gráfico correspondiente
a una clase en la notación de Booch es una especie de nube (Ver Figura 1) a
trazos en cuyo interior se escribe el nombre de la misma, separado por una
línea de sus atributos (estado) y métodos (comportamiento). Cada clase lleva
asociado un nombre que en general debe ser único. No se especifican todos los
métodos y atributos siempre, sino solamente aquellos que son relevantes para la
parte del diseño que tratamos de describir.
a)
Diagramas de Objeto
Un diagrama
de objetos contiene un conjunto de instancias de los elementos encontrados en
un diagrama de clases. Por o tanto, un diagrama de objetos expresa la parte
estática de una interacción, consistiendo en los objetos que colaboran pero sin
ninguno de los mensajes enviados entre ellos (Alarcon, 2000) .
Modelo Físico
El que se construye la
arquitectura que se definirá para el sistema.
a)
Diagramas de módulos
El diagrama de módulos muestra la
asignación de clases y objetos o módulos en el diseño físico de un sistema. Un
solo diagrama de módulos representa una vista de la estructura de módulos de un
sistema. Los dos elementos esenciales de un diagrama de módulos son los módulos
y sus dependencias.
·
Programa Principal.- Identifica al archivo que contiene la raíz del
programa.
Representación:
·
Especificación y Cuerpo.- Identifican los archivos que contienen la
declaración y la definición de los objetos o bien procedimientos o funciones
necesarias para el correcto funcionamiento de la aplicación.
Representación:
· Subsistema.- Los subsistemas sirven para modularizar el modelo físico de un sistema.
Un subsistema es un agregado que contiene otros
módulos y otros subsistemas.
Representación:
- Dependencias.- la única relación que puede darse entre dos módulos es una dependencia de compilación, representada por una línea dirigida que apunta al modulo respecto al cual existe la dependencia. Las flechas indican dependencia o uso y debe salir del módulo dependiente
Diagramas de proceso
Es una representación gráfica de los
pasos que se siguen en toda una secuencia de actividades, dentro de un proceso
o un procedimiento, identificándolos mediante símbolos de acuerdo con su
naturaleza; incluye, además, toda la información que se considera necesaria
para el análisis, tal como distancias recorridas, cantidad considerada y tiempo
requerido.
Con fines analíticos y como ayuda para descubrir y eliminar ineficiencias,
es conveniente clasificar las acciones que tienen lugar durante un proceso dado
en cinco clasificaciones. Estas se conocen bajo los términos de operaciones,
transportes, inspecciones, retrasos o demoras y almacenajes.
Tabla 1.- Simbología usada en Diagramas de Procesos
Actividad
|
Simbolo
|
Resultado Predominante
|
Operación
|
|
Se
produce o efectúa algo.
|
Transporte
|
|
Se
cambia de lugar o se mueve.
|
Inspeccion
|
|
Se
verifica calidad o cantidad.
|
Retraso
|
|
Se
interfiere o retrasa el paso siguiente
|
Almacenaje
|
|
Se
guarda o protege.
|
Dinámica de Clases
Consta de:
Diagramas de Transición de
Estados
El Diagrama de Transición de Estado
(también conocido como DTE) enfatiza el comportamiento dependiente del tiempo
del sistema. Este tipo de modelo sólo importaba para una categoría de sistemas
conocido como sistemas de tiempo-real; como ejemplo de estos sistemas se tienen
el control de procesos, sistemas de conmutación telefónica, sistemas de captura
de datos de alta velocidad y sistemas de control y mando militares.
·
Elementos
ü Entidades.-
Las entidades pasan por varios estados. En cada uno de ellos pueden suceder
determinados eventos que provoquen efectos o acciones sobre la entidad.
ü Eventos.-
Algo que sucede en el mundo real y como consecuencia se ejecuta un proceso.
ü Acción.-
Descripción del estado de un
evento sobre una entidad.
·
Definición
de un DTE
Un
diagrama de transición de estados describe un conjunto de transiciones que
pueden suceder sobre una entidad. El estado en que se encuentra una entidad es
el resultado de todas las transiciones sucedidas durante su vida.
Dinámica de Instancias
a) Diagramas de Interacción
Muestran una interacción, que
consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes
que puedan ser realizados entre ellos. Son importantes para modelar los
aspectos dinámicos de un sistema y para construir sistemas ejecutables a través
de ingeniería hacia adelante e ingeniería inversa.
Comúnmente contienen: Objetos y
Enlaces, además de mensajes que pueden servir para visualizar, especificar,
construir y documentar los aspectos dinámicos de una sociedad particular de
objetos, o pueden ser usados para modelar un flujo particular de control de un
caso de uso.
Los diagramas de interacción están
conformados por los diagramas de secuencia y los diagramas de colaboración.
Macro Proceso
Engloba una
actividad de planificación arquitectónica, que agrupa capas de objetos por
nivel de abstracción. Además identifica situaciones relevantes.
Crea un
prototipo de diseño y valida el prototipo aplicándolo a situaciones de uso.
Es un proceso de
alto nivel.
Pasos del Macro proceso
Consta de 5
pasos:
a) Conceptualización
Se establecen las necesidades básicas
b) Análisis
Modelar un comportamiento deseado
c) Diseño
Se crea una arquitectura
d) Evolución
Evolución de la aplicación(a través de refinamientos sucesivos.
e) Mantenimiento
Gestionar la entrega luego de la evolución
Micro Proceso
En esta parte se
desarrolla lo siguiente (Guzman, Tojin, Sanchez, & Huriarte, 2007) :
·
Define un conjunto de “reglas”
que regulan el uso de operaciones y atributos, de reglas, y políticas.
·
Desarrolla situaciones que
describen la semántica de las reglas y política.
·
Crea un prototipo para cada
política.
·
Instrumenta y refina el
prototipo.
Es un proceso de
bajo nivel.
El micro proceso
de desarrollo del AOO de Booch incluye (Huchin Gamboa, 2009) :
·
Identificación de clases y
objetos.
·
Proposición de objetos
candidatos
·
Conducción del análisis de comportamiento.
·
Identificación de escenarios
relevantes.
·
Definición de atributos y
operaciones para cada clase.
·
Identificación de la semántica
de clases y objetos.
·
Selección y análisis de
escenarios.
·
Asignación de responsabilidades
para alcanzar el comportamiento deseado.
·
División de las
responsabilidades para equilibrar el comportamiento.
·
Selección de un objeto y
enumerar sus papeles y responsabilidades.
·
Definición de operaciones para
satisfacer las responsabilidades.
·
Búsqueda de colaboraciones
entre objetos.
·
Identificación de
interrelaciones entre clases y objetos.
·
Definición de las dependencias
que existen entre objetos.
·
Descripción del papel de cada
objeto participante.
·
Validación de escenarios por
revisión completa.
·
Realización de una serie de
refinamientos.
·
Producción de los diagramas
apropiados para el trabajo realizado en las partes anteriores.
·
Definición de jerarquías de
clases apropiadas
·
Creación de agrupamientos
basados en clases comunes.
·
Implementación de clases y
objetos.
Metodología
de James Martin
Esta metodología de
desarrollo de Software es mejor conocida como Metodología RAD (Rapid
Application Development) o Desarrollo rápido de Aplicaciones, y fue
creada por el gurú de computación James Martin en 1991. Está orientada a
disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas
de Información, el RAD cuenta con una participación intensa del usuario,
sesiones JAD, prototipaje, herramientas CSE integradas y generadores de código.
El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y
herramientas.
Fases
o Etapas de Metodología RAD de James Martin.
Esta metodología consta de 4 etapas a saber:
1) Etapa de
Planificación de Requisitos: Esta etapa requiere que los usuarios con un vasto
conocimiento de los procesos de la compañía determinen cuáles serán las
funciones del sistema. Debe darse una discusión estructurada sobre los
problemas de la compañía que necesitan solución.
2) Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la compañía en relación al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informática. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el análisis se crean los diagramas que definen las alteraciones entre los procesos y la data.
3) Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseño y la construcción del sistema. La construcción de la aplicación consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.
4) Implementación: Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.
Ventajas y Desventajas de la Metodología RAD
Ventajas | Desventajas
Ahorro dramático de tiempo durante el desarrollo del sistema. Mayor velocidad y menores costos pueden repercutir en la calidad del sistema (p.e., debido a falta de atención en controles internos).
Puede ahorrarse tiempo, dinero y esfuerzo humano. Peligrosa incoherencia entre el sistema desarrollado y el negocio, debido a la falta de información o a procesos del negocio sobreentendidos.
Estrecha correspondencia entre los requerimientos del usuario y las especificaciones del sistema.
Pueden producirse inconsistencias entre diseños internos y entre sistemas.
Trabaja muy bien cuando la velocidad de desarrollo es importante (cambios rápidos de las condiciones del negocio), o cuando lo sistemas pueden capitalizarse en oportunidades estratégicas. Posibles violaciones de estándares de programación relacionadas con nomenclaturas inconsistentes e insuficiente documentación.
Permite cambiar rápidamente el diseño de los sistemas cuando los usuarios lo demandan Dificultades con el reuso de módulos para futuros sistemas.
Los sistemas son optimizados por los usuarios involucrados en el proceso del RAD. Carencia de un diseño escalable dentro del sistema.
Se concentra en los elementos esenciales del sistema, desde el punto de vista del usuario. Falta de atención de la futura administración del sistema dentro de los sistemas existentes (p.e., falta de integración con el modelo de datos organizacional y facilidades de recuperación del sistema) . El usuario se compromete y se hace propietario del sistema. Altos costos de compromiso por parte del personal clave.
Metodología de Rumbaugh:
La metodología OMT
(Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en
1991, mientras
James dirigía un equipo de investigación de los laboratorios General
Electric. (Chávez y Olivares. 1999)Es una metodología de análisis y diseño,
orientada a objetos. Se utiliza para producir software de manera organizada. Se basa en etapas de desarrollo y una
colección de técnicas coordinadas y convenciones denotación predefinidas.
(Fachal, 2005)Las fases que conforman a la
metodología OMT son:
·
Análisis: se construye todo lo relevante al
problema, mostrando las propiedades más importantes. Se precisa en lo que el sistema debe hacer y no en la forma en la que se
hará. Los elementos del modelo deben ser todos conceptos
pertenecientes al ámbito de aplicación.
·
Diseño del sistema: Se diseña la arquitectura del sistema y
se organiza todo en subsistemas, basándose en la estructura del análisis. En
esta fase se selecciona la estrategia para la resolución del problema
planteado.
·
Diseño de objetos: Este
diseño se basa en el análisis y se centra en las estructuras de datos y algoritmos que son necesarios para la
implementación de cada clase.
·
Implementación: traducción concreta de las clases de
objetos y las relaciones desarrolladas durante el análisis de objetos. Es
importante que el sistema cuente los principios de la ingeniería de software,
tales como que el sistema implementado
sea flexible y extensible. La
metodología suele presentarse como una serie de pasos organizados en un ciclo
de vida que consta de varias fases de desarrollo. (Chávez y Olivares.
1999)La metodología OMT está basada en el desarrollo de un modelo del
sistema separado en tres aspectos:
·
un modelo de objetos
·
un modelo dinámico
·
un modelo funcional
a)
Modelo de Objetos
Describe la estructura estática de
los objetos del sistema, es decir, su identidad, atributos, operaciones,
así como también las relaciones con otros objetos. La definición clara de las
entidades que intervienen en el sistema es un paso fundamental para poder
definir que transformaciones ocurren en ellas y cuando se producen estas transformaciones. Este
modelo es representado gráficamente mediante diagramas de objetos. Los
diagramas de objetos permiten representar, de manera grafica, las clases,
objetos, y sus relaciones. Existen dos tipos de diagramas para este modelo: los
diagramas de clases y los diagramas de casos concretos. El primero ilustra y describe las clases que se encuentran en el
sistema y su relación estática. Los diagramas de casos concretos describen
la manera en que los objetos del sistema se relacionan. (Fachal, 2005)Para
entender mejor el concepto del modelo, definiremos los conceptos
básicos necesarios.
·
Objetos: se define como un
concepto o abstracción con propiedades definidas
·
Clase: describe un grupo de objetos con
propiedades similares y relaciones comunes con otros.
·
Atributos: Los objetos
que pertenecen a una clase poseen estas características. Otro
concepto fundamental en el modelado de objetos es el de las relaciones entre
las clases del sistema, las cuales determinan el comportamiento de este y
definen la forma en que los objetos se comunican entre sí. Las relaciones
tienen una serie de características:
•Se
identifican a través de enlaces, es decir, conexiones físicas entre objetos.
•Tienen
multiplicidad, término que indica el número de casos concretos de una clase que
puede relacionarse con otro caso.
•Los enlaces, así como los objetos,
pueden tener atributos los cuales nos indican las propiedades de la asociación.
•Agregación:
es de tipo “es parte de”, y se establece en los objetos compuestos (objetos que
contienen otros objetos). (Chávez y Olivares. 1999)En el modelo de
objetos, se trata con uno de los elementos más importantes de la orientación a
objetos, la herencia. La herencia está definida como la cualidad que permite
que los objetos hereden las características y las operaciones dentro de
una estructura jerárquica. Esto permite y facilita la reutilización de las clases
y del código implementado. (Fachal, 2005)Existen una serie de reglas
para implementar la herencia:
·
Las operaciones que no modifican los
valores de atributos (consulta), se heredan por todas las subclases.
·
Las operaciones que si modifican los valores
de atributos (actualización), se heredan por todas las subclases y se añaden las nuevas operaciones para las que añadan
atributos.
·
Las operaciones de actualización que se
realizan sobre atributos que tengan algún tipo de restricción o asociación, se bloquean para nuevas subclases.
·
Todos los métodos
concretos de una operación deben de tener el mismo protocolo. Todos los
elementos descritos se pueden agrupar para formar el modelo completo, así, las
clases, las asociaciones y las generalizaciones forman lo que se denomina
modulo, y varios módulos forman el modelo de objetos. (Chávez y Olivares. 1999) A continuación se presenta una serie de
pasos para la construcción de un modelo de objetos.
Identificar las clases de objetos
•
Listar las descripciones de las clases
tales como atributos y asociaciones.
•
Agregar las asociaciones entre
las clases.
•
Agregar atributos a los objetos.
•
Organizar las clases de objetos
mediante la herencia.
•
Probar los escenarios y las diferentes
rutas de acceso.
•
Agrupar las clases en módulos.
Diagrama 1: Ejemplo de Modelo de
Objetos
b)
Modelo Dinámico:
Describe la conducta y reacción
de los objetos del sistema frente a diferentes sucesos y las interacciones
entre ellos. También describe los aspectos
de un sistema que tratar de la temporización y secuencia de operaciones, secuencia
y la organización de sucesos y estados. Como ya se menciono, los conceptos más importantes
del modelado dinámico son los sucesos y los estados. Los sucesos representan estímulos
individuales provenientes de un objeto y que llega a otro objeto, y los
estados representan los valores de los objetos. Los valores de los atributos de
unos objetos son los que determinan su estado. A lo largo del tiempo, los
objetos del sistema interactúan con otros, dando lugar a una serie de cambios
en sus estados. Este modelo es representado gráficamente mediante una
variedad de diagramas de estado. (Fachal, 2005)
•
Suceso. Un suceso,
o evento, es algo que transcurre durante un período de tiempo. Un suceso puede preceder o seguir lógicamente a otro, o
bien los dos sucesos pueden no estar relacionados. Se dice quedos sucesos que no tienen relación causal son
concurrentes; no tienen efecto entre sí. Un suceso es una transmisión de
información de dirección única entre un objeto y otro. Todo suceso aporta
información de un objeto a otro. Los valores de datos aportados por un suceso
son sus atributos.
•
Escenarios y
seguimiento de sucesos. Un escenario es una secuencia de sucesos que se produce
durante
una ejecución concreta de un sistema. El ámbito de un escenario es variable;
puede incluir todos los sucesos del
sistema, o que sean generados por ellos. Todo suceso transmite información de
uno objeto a otro.
etodología de Rumbaugh:
La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y
Michael Blaha en 1991, mientras James dirigía un equipo de investigación de
los laboratorios General Electric. (Chávez y Olivares. 1999)Es una metodología de
análisis y diseño, orientada a objetos. Se utiliza para producir software de manera
organizada. Se basa en etapas de desarrollo y una colección de técnicas coordinadas y
convenciones denotación predefinidas. (Fachal, 2005)Las fases que conforman a la
metodología OMT son:
Análisis: se construye todo lo relevante al problema, mostrando las
propiedades más importantes. Se precisa en lo que el sistema debe hacer y no en
la forma en la que se hará. Los elementos del modelo deben ser todos conceptos
pertenecientes al ámbito de aplicación
Estados. Un estado es una abstracción de los valores de los atributos y de los enlaces de un objeto
13 conjuntos de valores se agrupan dentro del estado de acuerdo con
aquellas propiedades que afecten al comportamiento del objeto. Un
estado especifica la respuesta del objeto a los sucesos entrantes. La respuesta
a un suceso recibido por un objeto puede variar cuantitativamente,
dependiendo de los valores exactos de sus atributos, pero cualitativamente la
respuesta es la misma para todos los valores dentro del mismo estado, y puede
ser distinta para valores de distintos estados. La respuesta de un objeto a un suceso puede incluir una acción o un cambio de
estado por parte del objeto.
•
Escenarios y
seguimiento de sucesos. Un escenario es una secuencia de sucesos que se produce
durante
una ejecución concreta de un sistema. El ámbito de un escenario es variable;
puede incluir todos los sucesos del
sistema, o que sean generados por ellos.
Condiciones
Una
condición es una función Booleana lógica que tiene a objetos como valores. Las
condiciones se pueden utilizar como protecciones en las transiciones.
Una transición con protección se dispara cuando se produce su suceso, pero sólo
si la condición de protección es verdadera. (Chávez y Olivares. 1999)
Operaciones
Los diagramas de estados tendrían muy
poca utilidad si solamente describiesen tramas de sucesos. Una descripción de un objeto debe especificar lo que
hace el objeto como respuesta a los sucesos. Una actividad es una operación
cuya realización requiere un cierto tiempo. Toda actividad está asociada a un estado.
Entre las actividades se cuentan las operaciones continuas, tales como mostrar
una imagen en una pantalla, así como las operaciones secuenciales que terminan
por sí mismas después de un cierto intervalo de tiempo. Un estado puede controlar una actividad continua o una
actividad secuencial que va avanzando hasta que termina o hasta que se
produce un suceso que la hace finalizar prematuramente. La anotación
"hacer: X" indica que la
actividad secuencial X comienza al entrar en ese estado, y se detiene cuando ha
finalizado. Si un suceso da lugar a una transición que sale de ese estado antes
de que haya finalizado la actividad, entonces, la actividad finaliza de
forma prematura. (Chávez y Olivares. 1999)Una
acción es una operación instantánea que va asociada a un suceso. Una acción
representa a una operación cuya duración es insignificante en
comparación con la resolución del diagrama de estados. Realmente, no hay operaciones que sean instantáneas, pero se
modelan de esta manera aquellas operaciones de las que no nos importa su
estructura interna. (Chávez y Olivares. 1999)
•
Las acciones también pueden representar
operaciones internas de control, tales como dar valores a atributos o generar
otros sucesos. Estas acciones no tienen contrapartidas en el mundo real, sino
que son mecanismos para estructurar el control dentro de una implementación y
un único estado de todas las combinaciones
de valores de atributos y de enlaces que tienen una misma respuesta a los
sucesos. Por supuesto, todo atributo tiene algún efecto sobre el
comportamiento, o no tendría sentido, pero es frecuente que algunos atributos no afecten a la trama de control, y que se pueda
pensar en ellos como valores de parámetros dentro de un estado. Tanto los
sucesos como los estados dependen del nivel de abstracción utilizado.
Los estados se pueden caracterizar de diferentes maneras, pero normalmente
cada estado tiene un nombre y una descripción en la que se indica en la
situación en la que se encuentra el sistema.
CONCLUSIONES
METODOLOGÍA DE BOOCH
Conclusion
El método de Booch se basa en dividir un solo proceso en un micro proceso y macro proceso, desarrollando de forma iterativa un sistema, en el cual se mira el producto como una serie de arquitecturas que evolucionan hacia el sistema de desarrollo final. Además esta metodología juntó conceptos de otras metodologías.
GLOSARIO DE TÉRMINOS
INHERENTES:se emplea para designar a todo aquello o aquel que como consecuencia de la naturaleza que ostenta se halla inseparablemente unido a otro o a algo
CÍCLICA: Que ocurre o se repite regularmente cada cierto tiempo.
CUALITATIVO: es aquel que revela cuáles son las características o el valor de algo.
LINKOGRAFIA
http://myslide.es/documents/metodologia-booch.html
http://mundoinformatico321.blogspot.pe/2012/12/metodologia-de-james-martin-y-uml.html
http://myslide.es/documents/metodologia-de-rumbaugh.html
slide share : http://es.slideshare.net/cristianbenites01/metologia-55490089
slide share : http://es.slideshare.net/cristianbenites01/metologia-55490089
etodología de Rumbaugh:
La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y
Michael Blaha en 1991, mientras James dirigía un equipo de investigación de
los laboratorios General Electric. (Chávez y Olivares. 1999)Es una metodología de
análisis y diseño, orientada a objetos. Se utiliza para producir software de manera
organizada. Se basa en etapas de desarrollo y una colección de técnicas coordinadas y
convenciones denotación predefinidas. (Fachal, 2005)Las fases que conforman a la
metodología OMT son:
Análisis: se construye todo lo relevante al problema, mostrando las
propiedades más importantes. Se precisa en lo que el sistema debe hacer y no en
la forma en la que se hará. Los elementos del modelo deben ser todos conceptos
pertenecientes al ámbito de aplicación
El trabajo esta bien desarrollado. Se recomienda agregar VIDEOS sobre el tema. Saludos
ResponderBorrar