2 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”.

2.1 El Método BoochEl 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.

2.2 Modelos del Método Booch

2.2.1 Modelo de LógicaEstá representado en la estructura clase-objeto.

a) Diagramas de ClaseEn 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.

b) 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).

2.2.2 Modelo Físico El que se construye la arquitectura que se definirá para el sistema.

a) Diagramas de módulosEl 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.

Imagen 1.- Diagrama de una clase

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

b) 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.

TransporteSe cambia de lugar o se mueve.

InspeccionSe verifica calidad o cantidad.

RetrasoSe interfiere o retrasa el paso siguiente

AlmacenajeSe guarda o protege.

2.2.3 Dinámica de Clases Consta de:

a) 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.

2.2.4 Dinámica de Instanciasa) 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.

2.3 Macro ProcesoEngloba 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.

2.3.1 Pasos del Macro procesoConsta de 5 pasos:

a) ConceptualizaciónSe establecen las necesidades básicas

b) AnálisisModelar un comportamiento deseado

c) DiseñoSe crea una arquitectura

d) EvoluciónEvolución de la aplicación(a través de refinamientos sucesivos.

e) MantenimientoGestionar la entrega luego de la evolución

2.4 Micro ProcesoEn 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.

Imagen 2.- Pasos Micro proceso

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.

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.