6.1 Booch
El método Booch
2.1 Introducción
El método de Grady Booch es uno de los más conocidos en la orientación al objeto.
En su versión de 1.993 este método cubre las fases de análisis y diseño dentro de un desarrollo
orientado al objeto.
Se definirán una gran cantidad de símbolos para representar las distintas decisiones de diseño.
Este método ofrece una gran libertad en la producción del software, como ya veremos más
adelante.
En un primer momento se explicarán una serie de conceptos básicos, los cuales han de quedar
claros para poder comprender a fondo la metodología de Booch.
Dichos conceptos se pueden estructurar estructurarlos de la siguiente manera:
Complejidad.
El modelo del objeto.
Clases y objetos.
Clasificación.
El método
En la metodoogía de Booch se explica qué hay que hacer para definir el sistema, pero no se da
ninguna prescripción para mejorar las fases de análisis y diseño del sistema. Eso puede ser visto
como una ventaja por parte de aquellos que prefieren disponer de una mayor libertad a la hora de
producir software, y como una debilidad para aquellos que no dispongan de mucha experiencia y
expertos en la orientación al objeto.
Booch propone varias formas de describir un sistema en orientación al objeto. El modelo lógico,
por ejemplo, se representa bajo la estructura de clases y objetos. Mientras que el diagrama de
clases es más bien estático, el diagrama de objetos muestra el comportamiento dinámico del
sistema.
6.2 OMT (Object Modeling Technique)
OMT (Object Modeling Tecnique)
3.1 Introducción
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. Se hace cargo de todo el ciclo de vida del software, y durante ese tiempo mantiene la misma
notación. Se divide en cuatro fases consecutivas. Tiene una parte de diseño no muy compleja. Se
centra mucho en un buen análisis. Es de las denominadas “dirigidas por los datos”.
3.2 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.
3.3 Pasos específicos a dar en cada fase
3.3.1 Fase de análisis
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.
3.3.2 Fase de diseño del sistema
1. Organizar el sistema en subsistemas (“conjunto de capas horizontales”).
2. Identificar la concurrencia inherente al problema.
3. Colocar los susbsistemas a sus procesos y tareas. Aquí han de asignarse recursos de la máquina
a los distintos subsitemas (memoria, procesador, ficheros...).
4. Elegir la estrategia básica para almacenar los datos; tipos abstractos de datos, estructuras,
ficheros y bases de datos.
5. Identificar los recursos globales y determinar mecanismos de control de acceso a ellos.
6. Elegir un método de implementación del control de software. Existen tres tipos de control
destacados: Por programa (sistemas dirigidos por procedimientos; C++), Por planificador del
entorno (sistemas dirigidos por eventos; X-Window) o Concurrente (sistemas concurrentes; Ada).
Esto se puede implementar de las siguientes maneras:
- Usar el programa como un estado fijo, o
- Directamente implementar un autómata de estados, o
- Usar tareas de concurrencia.
7. Considerar las condiciones límite.
8. Establecer las prioridades.
3.3.3 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.
Figura 24. Notación de OMT para el Modelo de Objetos
Es considerada como una metodología de segunda generación, porque proviene de:
OMT: modelo de objetos,
CRC: interacción de objetos,
BOOCH: visibilidad,
Los métodos Formales: pre- y post- condiciones.
· Proporciona un proceso de desarrollo, que se divide en:
· Análisis, Diseño e Implementación.1
· Ofrece notaciones para los modelos, que describen varios aspectos del software.
Actualmente ha abandonado su notación.
· Proporciona herramientas de gestión.
6.4 EROOS (Entity Relationship Object Oriented
Specification).
EROOS: (Especificaciones Orientadas a Objeto E-R)
7.1 Introducción
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’.
7.2 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.
7.3 Ciclo de vida
Comienza por la solicitud de los requisitos (no después).
1. Análisis:
· Análisis del contexto del problema: Uso de técnicas de modelado de negocio.
· Especificación del problema: Mentalidad de gerente. Especificar los requisitos de la solución.
· Especificación de las soluciones: Reingeniería de procesos de negocio e idear nuevas soluciones.
2. Diseño: Ha de hacerse antes de dar la solución (información necesaria, decisiones persistentes,
interfaces con el mundo real). A partir de ahí análisis y diseño del software (descomposición y
restricciones):
· Diseño de la solución: Optimización del tamaño, determinación de la información necesaria,
toma de decisiones persistentes y definir las interfaces del sistema con el mundo exterior.
· Análisis del software: Diseño y descomposición del sistema en subpartes para poder
reutilizarlas o compartirlas. Toma de decisiones en cuanto a la distribución de la información
y la concurrencia se refieren.
· Diseño del software: Conseguir separar el lenguaje de la plataforma en que se ejecutará el
programa, realización de las restricciones impuestas al sistema y de nuevo la toma de
decisiones en cuanto a la distribución de la información y la concurrencia se refieren.
3. Diseño de la solución:
· Diseño del código: Selección del lenguaje adecuado para nuestro código y fusión entre el
lenguaje y la plataforma. Toma de decisiones en cuanto a la distribución de la información y
la concurrencia se refieren.
· Codificación: Generación del código.
7.4 Filosofía y Conceptos Contemplados
Los siguientes conceptos son contemplados en la metodología (véase su representación en el
apartado “Notaciones”, que viene a continuación):
· Objetos y clases: Los objetos son clasificados en clases, distinguiendo entre objetos presentes
y pasados. Esto se consigue porque aunque la relación entre el objeto y su clase madre es
estática, éste puede mantenerse aún después de la muerte de la clase como ‘archivado’,
pudiendo accederse a sus valores, pero nunca más modificarlos. Siempre son creados y
destruidos (poseen un ciclo de vida).
· Relaciones: Refinan a las clases y especifican las relaciones que las unen. En realidad son
objetos, con una existencia dependiente de los objetos implicados en la relación. Solo se
permiten relaciones unarias y binarias.
· Atributos, Dominios y Valores: Los valores son clasificados en dominios. Esos mismos
valores decoran a las clases, y especifican sus propiedades. Una de sus diferencias con los
objetos es que ni se crean ni son destruidos. En EROOS solo se puede acceder a los atributos
mediante las funciones (servicios) que tiene cada clase, y no de otra forma que violaría el
encapsulamiento.
· Restricciones: Limitan las posibles relaciones o valores de los atributos. En EROOs las
restricciones pueden ser de 3 tipos: Implícitas (Ej un objeto refinado tiene una dependencia
existencial de quienes proviene), Integradas (Ej: las de conectividad) y Explícitas (además de
los dos tipos anteriores se pueden definir mediante lógica de primer orden). Han de definir las
cláusulas que el sistema ha de cumplir en todo momento, sin importarles cómo son
preservadas. Se pueden definir triggers para que reaccionen a posibles violaciones de las
restricciones.
· Funcionalidades: Divididas en:
Consultas dinámicas: Solo acceden a información del sistema y de los objetos, pero no la
modifican. Con una flecha hacia arriba devuelve todos los objetos refinados en que una clase
participa. Con una flecha hacia abajo devuelve el objeto al que la aplicamos. Con una flecha
hacia la derecha devuelve los valores del objeto al que apunta.
Eventos: Cambian el estado del sistema. Pueden estar localizados en:
- Kernel: Constructores, destructores y mutadores. Los eventos del kernel se
especifican mediante post-condiciones con ‘claúsulas de efecto’ que se redactan
mediante lógica de primer orden.
- Shell: Son más complejos y se especifican mediante combinaciones de funciones del
kernel, consultas y otras del shell.
· Generalización/especificación: Comprende las relaciones Is-a (“es un”). La herencia es una
relación ISA a fin de cuentas. Este tipo de relaciones lo que hacen es ‘fortalecer’ las
capacidades de una clase, luego una clase refinada así debe tener una definición más sólida
que su clase preferente. Además se le pueden añadir nuevas funcionalidades.
· Herencia: En esta metodología la estructura del sistema se define en forma de herencias. Esto
permite tener varios niveles de abstracción incluso dentro de un mismo modelo. Esto a su vez
permite extender clases ya definidas, incluso reutilizarlas.
7.5 Notación
OBJETOS Y CLASES:
Figura 34. Notación de objetos y clases en EROOS
RELACIONES:
Figura 35. Notación para las relaciones entre clases
en EROOS (1)
Figura 36. Notación para las relaciones entre clases en EROOS (2)
ATRIBUTOS:
Figura 37. Notación para los atributos en EROOS
RESTRICCIONES:
Figura 38. Notación para las restricciones en EROOS
CONSULTAS:
Figura 39. Notación para las consultas en EROOS
KERNEL:
Figura 40. Notación para las funcionalidades del Kernel en EROOS
SHELL:
Figura 41. Notación para las funcionalidades del Shell en EROOS
GENERALIZACIÓN/ESPECIALICACIÓN:
Figura 42. Notación para las relaciones Is_A en EROOS
6.5 MOSES (Methodology for Object Oriented Software Engineering of Systems).
Metodología MOSES
8.1 Introducción
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.
Muchas industrias están adoptando MOSES como metodología de desarrollo de software de
calidad. Uno de los sitios donde se está realizando (buque insignia de esta metodología) es en
Dow Jones, para su sistema de ‘Telerate’ (Sistema de información que distribuye del valor de las
acciones de la bolsa de Dow Jones, Nueva York).
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.
10.2 OPEN
OPEN fue creada en un principio a partir de una mezcla de algunas metodologías de segunda
generación (MOSES, SOMA y “The Firesmith Method”).
Es esencialmente un armazón para la tercera generación de métodos de desarrollo software en la
orientación al objeto, suministrando un gran soporte para el proceso de modelado mediante el uso
de modelos de ciclo de vida, mediante una captura de requisitos, y ofreciendo la habilidad de
modelar o construir agentes inteligentes.
OPEN también toma conceptos de BON, Martin/Odell, OBA, RDD, ROOM, UML y otros.
Ofrece un conjunto de principios para el modelado de todos los aspectos del desarrollo software:
ciclo de vida, tareas, técnicas y modelado del lenguaje.
OPEN extiende el concepto de metodología, no sólo incluyendo un modelo de procesos, sino
también suministrando líneas para construir versiones del método que se ajusten a las necesidades
del dominio industrial, organizaciones individuales...
Los elementos principales de esta metodología son:
Ciclo de vida o metamodelo.
Técnicas.
Representación.
Se ha conseguido una metodología que comprenda, al menos, un conjunto de técnicas, más un
modelo de ciclo de vida y una representación.
Figura 47. Elementos principales de OPEN.
Las actividades de OPEN tienen tareas que se ejecutan y se completan gracias a las técnicas.
Figura 48. Descomposición de procesos en OPEN.
OPEN representa la cúspide de los logros obtenidos en los métodos de orientación al objeto por
decenas de metodologías y un posible camino a seguir en un futuro todavía incierto. Es de
dominio público.
