6.2 OMT (Object Modeling Technique).

Es una metodología orientada a objeto muy difundida, de hecho es la que actualmente más se está
utilizando por encima incluso de la de Booch. Se desarrolló por un equipo liderado por el Dr.
James Rumbaugh en el ‘Research and Development Center de General Electric’ a finales de los
’80.
Fases
1. Análisis de objetos:
Se describe el problema: Se obtienen unos requisitos que no den lugar a dudas (rendimiento,
funcionalidad, contexto,...). En toda la fase de análisis se describe el comportamiento del sistema
como una “caja negra”.
Se hacen los diagramas de objetos con su diccionario de datos. Así obtengo el modelo de
objetos. En él se define su la estructura de los objetos y clases así como las relaciones que les
unen. Comprende tanto un Diagrama de Clases como un Diccionario de Datos que las explique.
Este modelo debe ser refinado por medio de la iteración.
Creación de un modelo dinámico para describir los aspectos de control y evolución del sistema.
Incluye un Diagrama de Eventos del sistema y un Diagrama de Estado por cada clase que tenga
un comportamiento dinámico.
Creación de un modelo funcional que describa las funciones, los valores de entrada y salida, e
imponga las restricciones pertinentes. Se suelen utilizar Diagramas de Flujo de Datos (DFDs).
Se verifican todos los modelos creados.
Se itera para conseguir un refinamiento de los 3 modelos.
2. Diseño del sistema: Comprende la arquitectura básica. En esta fase se tomarán las
decisiones estratégicas (a alto nivel) de diseño (estructura global del sistema).
3. Diseño de objetos: Es el último paso antes de implementar, y sirve para definir
completamente todas las características de los objetos. Se detallan los 3 modelos ya descritos
en el análisis de objetos de cara a poder implementarlo, y optimizar el programa (acceso a
datos, iteraciones, control, recursos,...). Todo esto ha de hacerse con independencia del
lenguaje o entorno en que finalmente codifiquemos y ejecutemos la aplicación.
4. Implementación: Se codifica lo ya diseñado.

Fase de diseño de objetos
1. Obtener operaciones para el modelo de objetos a partir de los otros modelos:
· Encontrar una operación para cada proceso del modelo funcional.
· Definir una operación por cada evento del modelo dinámico, dependiendo de la
implementación del control.
2. Diseñar algoritmo para implementar operaciones:
· Elegir algoritmos que minimicen el coste de implementar las operaciones.
· Elegir estructuras de datos apropiadas a los algoritmos.
· Definir nuevas clases internas y operaciones como sea necesario.
· Asignar responsabilidades para operaciones que no han sido claramente asociadas a
una sola clase.
3. Optimizar los accesos a datos:
· Añadir asociaciones redundantes para minimizar el coste de acceso y maximizar las
conveniencias.
· Reajustar los procesos computacionales para lograr una mayor efectividad.
· Almacenar los valores derivados para evitar los cálculos repetidos.
4. Implementar el control software mediante el sistema elegido durante el diseño del sistema.
5. Ajustar las estructuras de las clases para aumentar la herencia.
· Reajuste de clases y sus operaciones para aumentar la herencia.
· Extraer el comportamiento abstracto común de grupos de clases.
· Delegar para poder compartir comportamientos cuando la herencia sea
semánticamente inválida.
6. Diseño de la implementación de las asociaciones:
· Analizar las asociaciones transversales.
· Implementar cada asociación como si fuera un objeto distinto o añadiendo el valor de
los objetos como atributos de una o ambas clases de la asociación.
7. Determinar la representación exacta de los atributos de los objetos.
8. Compactar las clases y asociaciones en módulos, ocultando en la parte privada toda la
información que deba estar oculta.
3.3.4 Implementación
No se detiene en ella (al igual que la fase de pruebas), con lo que se queda a la elección del
programador.

6.3 Fusión.

Método de Fusión
4.1 Introducción
Fusion proporciona un método de desarrollo de software orientado al objeto, que abarca desde la
definición de requisitos a la implementación en un lenguaje de programación.

6.4 EROOS (Entity Relationship Object Oriented Specification).

Es una metodología desarrollada por “Software Development Methodology Research Group”.
Tiene tanto una notación como una serie de estrategias para el desarrollo de software (desde el
análisis hasta la implementación). Todas las especificaciones que se hacen son declarativas,
permitiendo posponer así decisiones de diseño e implementación para justo antes de la
codificación, pero habiendo ya realizado un buen análisis.
Intenta acabar con el método de trabajo tradicional al considerarlo ‘informal, ambiguo e
incompleto’.

Características
La potencia de EROOS queda resumida en 3 puntos:
1. Combina el modelado del comportamiento con el modelado de las estructuras a representar.
Una integración total de estos dos modelados proporcionaría al método de especificación unas
propiedades de composición y descomposición mucho más potentes. Esto llevaría a un software
mejor estructurado, mantenible y reutilizable.
2. Descripción del software declarativa (no operacional). La primera descripción de ‘lo que el
sistema ha de hacer’, en lugar de ‘cómo’ le permite ir transformándose sin perder de vista el
problema a solventar. Esto da un nivel de abstracción adecuado a cada fase del desarrollo.
3. Separación del dominio del problema de su solución. Esto crea un sistema flexible y
cambiable, pero con un núcleo sólido. La funcionalidad del sistema se reflejará en ese núcleo,
permitiendo que el sistema se adapte a las peticiones del usuario, en lugar de comenzar desde el
principio cada vez que surja una nueva demanda.
Una de las virtudes de EROOS es que al dar una notación y reglas a seguir, solo puede darse una
solución a un problema (estando en un determinado nivel de abstracción). Así se minimizan los
malentendidos por malas interpretaciones y se facilita el trabajo en grupo.
Existen herramientas generadoras de código C++ y herramientas CASE basadas en esta
metodología que ayudan a llevarla a la práctica.
6.5 MOSES (Methodology for Object Oriented Software Engineering of Systems).

La metodología MOSES (Methodology for Object-Oriented Software Engineering of Systems) es
una metodología que cubre todo el ciclo de vida del desarrollo de software orientado a objeto, no
sólo análisis y diseño, sino la gestión de proyectos, planificación de negocio, mantenimiento de la
aplicación y futuras mejoras. Incluye una notación completa que además es soportada por algunas
de las herramientas CASE que existen en el mercado, así como unas técnicas de gestión
avanzadas que no están disponibles en ninguna otra metodología.

MOSES es un compendio de:
1. Un ciclo de vida de desarrollo de software basado en el modelo de ciclo de vida ‘fuente’
orientado a objeto.
2. Un ciclo de vida del producto con 3 etapas orientadas al negocio.
3. Un ciclo de vida de procesos con 5 fases solapadas orientadas a la parte técnica.
4. Un conjunto de 20 actividades que componen una detallada guía de pasos a seguir.
Ventajas que ofrece MOSES:
� Incorpora diagramas de modelado de negocio.
� Consigue unos procesos mejores.
� Da soporte a la reutilización.
� Las extensiones y modificaciones son más fáciles de gestionar.
� Está enfocada a la calidad.
� Crea una arquitectura flexible.
� Consigue una gestión adecuada de proyectos complejos.
� Da soporte a herramientas CASE.

6.6 Proceso Unificado

UML (Unified Modeling Language)
Proviene sobre todo de: Booch´93, OMT´93 y OOSE.
La idea de unificación pretende en un principio estabilizar el caos existente en las metodologías
orientadas a objeto, así como la aparición de un modelo más rico, producto del intercambio de
experiencias en las tres metodologías génesis de UML.
UML no es una metodología OO, sino una notación universal. El utilizar un lenguaje de
modelado estándar le da un valor añadido.
Es un lenguaje para representar los modelos que se obtienen a partir de la aplicación de cualquier
metodología OO.
UML no fuerza a utilizar ninguna metodología concreta, porque presupone que distintos
dominios de problemas conducen a diferentes métodos de análisis y diseño.

7. Análisis
7.1 Fases.
1.Obtener y escribir una descripción inicial del problema.
2.Construir un modelo de objetos:
· Identificar las clases (y objetos).
· Comenzar a crear un diccionario de datos que contenga descripciones de las clases,
sus atributos y sus asociaciones.

· Añadir las asociaciones (y agregaciones) entre las clases.
· Añadir los atributos de los objetos y sus uniones.
· Organizar y simplificar las clases usando herencias.
· Probar que los accesos son correctos, usando escenarios e iterando los pasos
siguientes como sea necesario.
· Agrupar las clases en módulos, basándose en su proximidad y función.
3.Construir un modelo dinámico:
· Preparar los escenarios para las secuencias de interacción típicas entre los usuarios y
el sistema.
· Identificar los eventos que se dan entre objetos y preparar una traza de eventos para
cada escenario.
· Preparar un DTE para el sistema, y una traza de eventos para cada escenario.
· Construir un diagrama de estado para cada clase que tenga un marcado
comportamiento dinámico.
· Chequear la consistencia (y que están todos) de los eventos que aparecen en los
diagramas.
4.Contruir un modelo funcional: (*)
· Identificar los valores de entrada y de salida.
· Usar DFDs cuando sea necesario para mostrar las dependencias funcionales.
· Describir qué hace cada función.
· Identificar las restricciones.
· Especificar criterios de optimización.
(*) Este modelo ha sido bastante criticado, por no seguir los principios del AOO. Desde
1995 se recomienda que este modelo consista en una descripción detallada de las
operaciones del sistema, y solo usa DFDOO cuando estas operaciones impliquen a varios
objetos. Conviene, para cada operación especificar las siguientes cosas: Nombre,
Responsabilidades, Entradas, Salidas, Objetos modificados, Precondiciones y
Postcondiciones.
5.Verificar, iterar y refinar los tres modelos:
· Añadir las operaciones claves que fueron descubiertas durante la preparación del
modelo funcional al modelo de objetos. No mostrar todas las operaciones durante el
análisis, sólo mostrar las más importantes.
· Verificar que las clases, asociaciones, atributos y operaciones son consistentes y
completas al nivel elegido de abstracción. Compara los tres modelos con la definición
del problema y probar los modelos mediante el uso de escenarios.
· Desarrollar escenarios más detallados (incluyendo condiciones que den errores) como
variaciones de los escenarios básicos. Usar estos escenarios “y si...” para verificar en
el futuro los tres modelos.
· Iterar los pasos anteriores cuanto sea necesario para completar el análisis.

7.2 Herramientas de análisis.

HERRAMIENTAS DEL ANÁLISIS ESTRUCTURADO

El Diagrama de Flujo de Datos (DFD) es una técnica gráfica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.

Se puede usar el DFD para representar un sistema o un software a cualquier nivel de abstracción. Un DFD de nivel 0 o modelo fundamental del sistema o modelo del contexto, representa al elemento de software completo como una sóla burbuja con datos de entrada y salida. Al partir el DFD/0 para mostrar más detalles, aparecen representados procesos (burbujas) y caminos de flujo de información adicionales.

Debido a las características específicas del ciclo de vida y, sobre todo, debido a la gran cantidad de información que se debe generar en cada etapa, comienzan a introducirse herramientas y entornos automatizados de producción, organización, edición y gestión de dicha información, que facilitan, o en muchos casos posibilitan el uso de metodologías formales de forma cómoda y eficiente. Por tanto, la tecnología CASE sustituye el papel y el lápiz por el ordenador para hacer del desarrollo del software un proceso más productivo. El objetivo fundamental del CASE es proporcionar un conjunto de herramientas que automaticen los trabajos de desarrollo y mantenimiento del software. Algunas de las facilidades ofrecidas por este tipo de herramientas son:

Soporte a la gestión para aumentar el control y la coordinación por parte de la dirección.

Diseño de diagramas estructurados y creación de especificaciones gráficas.

Prototipado de las pantallas de usuario.

Centralización de la información del sistema en un diccionario en el que se pueden almacenar, obtener informes y consultar.

Verificación de la consistencia y la corrección de las especificaciones del sistema.

Mantenimiento: re-documentación, reestructuración y análisis del sistema diseñado.

Eliminar errores fácilmente.

 8.1 Fases

Las fases que se siguen para desarrollar un programa son:

•Estudio de los datos de salida. Trata de crear el archivo lógico de salida (ALS).

•Estudio de los datos de entrada. Trata de crear el archivo lógico de entrada (ALE).

•Hacer el cuadro de descomposición de secuencias.

•Dibujar el organigrama de secuencias de Warnier.

•Construir la lista de instrucciones y asignarlas en el organigrama de secuencias.

•Desarrollar el juego de datos de ensayo y analizar los resultados.
 

FASES DE LA METODOLOGÍA DE JACKSON

La metodología de Jackson desarrolla un programa en 5 fases que realizan consecutivamente. Estas fases son:

•Definir las estructuras de datos.

•Encontrar correspondencias entre las estructuras de datos.

•Formar la estructura del programa.

•Listar y asignar las operaciones y condiciones a realizar.

•Escribir la lógica esquematizada.

8.2 Herramientas de diseño

HERRAMIENTAS
Podemos definir las herramientas como el útil que se utiliza para desarrollar un análisis. Se usan para:
•- Concentrarse en las propiedades importantes del sistema,•- Discutir cambios y correcciones de los requerimientos del usuario, a bajo coste y con el riesgo mínimo.•- Verificar que el analista comprende correctamente el entorno del usuario.•Dan soporte automático o semiautomático a los métodos. Ejemplos de herramientas de modelado de sistemas importantes son:•- Diagramas Flujo de Datos. Ilustra las funciones que el sistema debe realizar.•- Diagrama Entidad-Relación. Hacen énfasis en las relaciones entre los datos.•- Diagrama de Transición de Estados. Se enfoca al comportamiento dependiente del tiempo del sistema.

8.3 Patrones.

Indican los pasos a seguir para desarrollar una aplicación (cómo desarrollar todas las tareas del desarrollo del software). Hay dos tendencias:

Americana (Yourdon, Martin, Gane & Sarson)

Europea: Inglesa - SSADM

Francesa - Merise

Las fases comunes a todos los patrones son:

- Estudio de viabilidad. Implica hacer estimaciones aproximadas del coste y tiempo necesarios para construir un sistema nuevo y los beneficios que se derivarán de ello.

- Análisis funcional. Se debe conseguir productos altamente mantenibles, siempre que sea posible se utilizarán gráficos, se deben tratar los problemas de gran tamaño mediante métodos de partición,...

- Diseño físico. Asignación de porciones de la especificación a procesadores adecuados, y a tareas apropiadas dentro de cada procesador. Creación de una jerarquía de módulos de programas e interfaces entre ellos.

- Puesta en marcha o implantación. Incluyendo la codificación y la integración de los módulos.

- Explotación y mantenimiento.

8.4 Diseño de un caso de estudio

9. Conceptos avanzados.

9.1 OODBMS (Object Oriented Database Management System) .
Desde el punto de vista del desarrollador las ventajas están dadas en ganancias de productividad, dado
su modelamiento más simple que facilita el desarrollo de aplicaciones. El modelamiento de aplicaciones
es mucho más sencillo gracias al concepto de objetos complejos y el modelo obtenido es fácilmente
comprensible para el usuario. Este modelo puede ser validado directamente por el cliente de la
aplicación. El enfoque Orientado al Objeto favorece la reutilización, porque gracias a la encapsulación y
la herencia, es fácil especializar un componente existente para responder a las necesidades particulares
de la aplicación.

Desde el punto de vista del usuario final de los OODBMS, el mayor aporte es la calidad en términos de
ergonomía, fiabilidad, evolución y desempeño. La mayor parte de los productos disponibles en el
mercado, son productos cerrados, difícilmente adaptables a las especificaciones de la empresa: la
ergonomía de la aplicación es fija, las reglas de cálculo son difícilmente modificables, etc. la tecnología
objeto, gracias en particular a la encapsulación y la herencia, da productos desarrollos con un OODBMS
más abierto y f ácilmente adaptables. El usuario puede obtener un costo menor de las modificaciones de
sus procedimientos, que van a integrar más fácilmente su medio ambiente (entorno).

9.2 CORBA (Common Object Request Broker Architecture).

LA NORMA CORBA
CORBA es una especificación normativa que resulta de un consenso entre los miembros de la
OMG, un consorcio que agrupa hoy por hoy a más de 700 empresas tanto de la industria
informática como consumidores de la misma. Esta norma cubre cinco grandes ámbitos que
constituyen los sistemas de objetos distribuidos:
• Un lenguaje de descripción de interfaces, llamado Lenguaje de Definición de Interfaces
IDL (Interface Definition Language), traducciones de este lenguaje de especificación
IDL a lenguajes de implementación (como pueden ser C++, Java, ADA, etc.) y una
infraestructura de distribución de objetos llamada ORB (Object Request Broker) que ha
dado su nombre a la propia norma: CORBA (Common Object Request Broker
Architecture).