GRADY BOOCH
La
metodología de Booch usa los siguientes tipos de diagramas para describir las
decisiones de análisis y diseño, tácticas y estratégicas, que deben ser
hechas en la creación de un sistema orientado por objetos.
Diagrama
de Clases. Consisten en un conjunto de clases y relaciones entre ellas.
Puede contener clases, clases paramétricas, utilidades y metaclases. Los
tipos de relaciones son asociaciones, contenencia, herencia, uso,
instanciación y metaclase.
Especificación
de Clases. Es usado para capturar toda la información importante acerca de
una clase en formato texto.
Diagrama
de Categorias. Muestra clases agrupadas lógicamente bajo varias categorías
Diagramas
de transición de estados.
Diagramas
de Objetos. Muestra objetos en el sistema y su relación lógica. Pueden ser
diagramas de escenario, donde se muestra cómo colaboran los objetos en
cierta operación; o diagramas de instancia, que muestra la existencia de
los objetos y las relaciones estructurales entre ellos.
Diagramas
de Tiempo. Aumenta un diagrama de objetos con información acerca de eventos
externos y tiempo de llegada de los mensajes.
Diagramas
de módulos. Muestra la localización de objetos y clases en módulos del
diseño físico de un sistema.Un diagrama de módulos representa parte o la
totalidad de la arquitectura de módulos del sistema.
Subsistemas.
Un subsistema es una agrupación de módulos, útil en modelos de gran
escala.
Diagramas
de procesos. Muestra la localización de los procesos en los distintos
procesadores de un ambiente distribuido.
Funciones
primarias del sistema: Principales entradas y salidas del sistema,
referencias a políticas, sistemas existentes o procedimientos, etc.
Conjunto
de mecanismos claves que el sistema debe proveer: estado de entrada, estado
de salida y estados esperados.
Diagrama
de clases con las abstracciones clave, identificando las clases del dominio
claves y sus relaciones
Especificación
de las clases
Vistas
de herencia. Diagramas de clases con este tipo de relaciones
Diagramas
de escenarios de objetos
Especificación
de objetos, que relacionan objetos y sus clases.
Descripción
de arquitectura, que describe las decisiones más importantes de diseño
como son el conjunto de procesos, manejadores de bases de datos, sistemas
operativos, lenguajes, etc.
Descripciones
de prototipo, que describen las metas y contenido de las implementaciones
sucesivas de prototipos, su proceso de desarrollo y la forma de probar
requerimientos.
Diagramas
de Categorías
Diagramas
de clases en diseño, detallan las abstracciones de análisis con características
de implementación.
Diagramas
de objetos en diseño, muestran las operaciones necesarias para desarrollar
una operación
Nuevas
especificaciones
Especificaciones
de clases corregidas, muestra la especificación completa de los métodos
con algoritmos complicados, la implementación de relaciones y el tipo de
atributos.
En
esta etapa se define qué quiere el usuario del sistema. Es una etapa de alto
nivel que identifica las funciones principales del sistema, el alcance del
modelamiento del mundo y documenta los procesos principales y las políticas que
el sistema va a soportar. No se definen pasos formales, ya que éstos dependen
de qué tan nuevo es el proyecto, la disponibilidad de expertos y usuarios y la
disponibilidad de documentos adicionales
Es
el proceso de definir de una manera concisa, precisa y OO la parte del modelo
del mundo del sistema. Las siguientes actividades son parte de esta etapa:
Es
el proceso de determinar una implementación efectiva y eficiente que realice
las funciones y tenga la información del análisis de dominio. Las siguientes
actividades se plantean en esta etapa
El
desarrollo de el UML empezó en octubre de 1994 cuando Booch y Jim Rumbaugh de
Rational Software Corporation iniciaron su trabajo para unificar los métodos de
Booch y OMT. Debido a que los métodos Booch y OMT ya habían madurado
independientemente y eran reconocidos como métodos líderes en el desarrollo
orientado a objetos, Booch y Rumbaugh unieron fuerzas para forjar una unificación
completa de los dos métodos. Una versión preliminar 0.8 de el “método
unificado” fue dad a conocer en octubre de 1995. Poco después, Ivar Jacobson
y su compañía “Objectory” se unieron a Rational y a su trabajo de
unificación, uniendo el método OOSE (Object Oriented software engineering). El
Nombre de Objectory es ahora dado mayormente para describir a el Proceso que
acompaña al UML el “Rational unified process”
Los
objetivos de la unificación fueron: el mantenerlo simple, el quitar elementos
de los lenguajes de Booch, OMT y OOSE que no funcionaran en la práctica, el añadir
elementos de otros métodos que fueran mas efectivos y el inventar nuevas
construcciones solamente cuando la solución existente no estuviera disponible.
Varios
nuevos conceptos existen en UML, incluyendo:
· Mecanismos
de extensión (estereotipos, valores
marcados y restricciones),
·
Procesos y ramas de procesamiento
·
Distribución y concurrencia
·
Patrones y colaboración
·
Diagramas de actividad
·
Refinamiento (para manejar las relaciones
entre los niveles de abstracción)
·
Interfaces y componentes y
·
Un lenguaje para restricciones
De
las tres metodologías de partida, las de Booch y Rumbaugh pueden ser descritas
como centradas en objetos, ya que sus aproximaciones se enfocan hacia el
modelado de los objetos que componen el sistema, su relación y colaboración.
Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que
todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando
y aceptando como estándar desde la formación de OMG, que es también el origen
de CORBA, el estándar líder en la industria para la programación de objetos
distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la
notación estándar de facto para el análisis y el diseño orientado a objetos.