Metodologia de BOOCH

La Metodología de Booch es una técnica usada en ingeniería de software. Es un lenguaje de modelado de objetos y una metodología ampliamente usada en el diseño de software orientado a objetos. Fue desarrollada por Grady Booch mientras trabajaba para Rational Software (hoy parte de IBM). Los aspectos notables de la metodología de Booch han sido superados por el Lenguaje Unificado de Modelado, que combina elementos gráficos de la metodología de Booch junto a elementos de la técnica de modelado de objetos y la Ingeniería de software orientada a objetos.

Los aspectos metodológicos de la metodología de Booch fueron incorporados en varias metodologías y procesos, siendo la principal de ellas el Proceso Racional Unificado (RUP).

La metodología de Booch se enfoca en el análisis y el diseño y no en la implementación o la prueba del resultado de estos.
Define seis tipos de diagramas: clase, objeto, estado de transición, interacción, modulo y proceso.

Booch en esencia plantea que para trabajar con su método es conveniente trabajar en dos partes fundamentales: un microproceso y un macroproceso. Ambas partes incluyen varios pasos como son la identificación de clases y objetos a un nivel de abstracción dado, la identificación de la semántica de esas clases y objetos, la identificación de las relaciones entre esas clases y objetos, la selección de la estructura de datos y algoritmos para la implantación de estas clases y objetos, la conceptualización del sistema, etc. El microproceso de desarrollo del AOO de Booch incluye:

• 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.
• Implantación de clases y objetos.

Metodologia OMT

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.

OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software.

Las fases que conforman a la metodología OMT son:

• Análisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades más importantes. El modelo de análisis es una abstracción resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se hará. Los elementos del modelo deben ser conceptos del dominio de aplicación y no conceptos informáticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informáticos.
• Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema.
• Diseño de objetos. El diseñador de objetos construye un modelo de diseño basándose en el modelo de análisis, pero incorporando detalles de implementación. El diseño de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseño puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.).
• Implementación. Las clases de objetos y relaciones desarrolladas durante el análisis de objetos se traducen finalmente a una implementación concreta. Durante la fase de implementación es importante tener en cuenta los principios de la ingeniería del software de forma que la correspondencia con el diseño sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilización de código y la correspondencia entre el dominio del problema y el sistema informático, si luego perdemos todas estas ventajas con una implementación de mala calidad.

La metodología OMT emplea tres clases de modelos para describir el sistema:

• Modelo de objetos. Describe la estructura estática de los objetos del sistema (identidad, relaciones con otros objetos, atributos y operaciones). El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo dinámico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que sean importantes para la aplicación. Se representa mediante diagramas de objetos.
• Modelo dinámico. Describe los aspectos de un sistema que tratan de la temporización y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos) y la organización de sucesos y estados. Captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que están implementadas. Se representa gráficamente mediante diagramas de estado.
• Modelo funcional. Describe las transformaciones de valores de datos (funciones, correspondencias, restricciones y dependencias funcionales) que ocurren dentro del sistema. Captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se haga. Se representa mediante diagramas de flujo de datos

Metodologia RUP

El Proceso Racional Unificado (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

Principales características

• Desarrollo iterativo
• Administración de requisitos
• Uso de arquitectura basadas en componentes
• Control de cambios
• Modelado visual del software
• Verificación de la calidad del software
• Pretende implementar las mejores prácticas en Ingeniería de Software, de forma que se adapte a cualquier proyecto

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).