Grady Booch

Grady Booch (27 de febrero de 1955) es un diseñador de software, un metodologista

de software y entusiasta de diseño de patrones. Es director científico de Rational Software
(ahora parte de IBM) y editor de una serie de Benjamin/Cummings. En 1995 se recibió como
miembro de la Asociación de Maquinaria Computacional (ACM). Fue nombrado socio de IBM en
2003.
Es más conocido por el desarrollo del Lenguaje Unificado de Modelado (UML), junto con Ivar
Jacobson y James Rumbaugh. También desarrolló el método Booch de desarrollo de software,
el que presenta en su libro Análisis y diseño orientado a objetos. Él aconseja la adición de más
clases para simplificar códigos complejos.
Obtuvo su licenciatura en 1977 en la Academia de la Fuerza Aérea de los Estados Unidos y un
máster en ingeniería eléctrica en 1979 de la Universidad de California, Santa Barbara.

Ivar Jacobson
Ivar Hjalmar Jacobson (2 de septiembre 1939, Ystad - ), es un ingeniero sueco en Ciencias de la
computación.
Inventó el diagrama de secuencia y desarrolló los diagramas de colaboración. También impuso
el uso de diagramas de estado de transición para describir los flujos de mensajes entre los
componentes. Fue uno de los desarrolladores originales del SDL (lenguaje de especificación),
que se convirtió en estándar en 1967.
Carrera profesional[editar]
Obtuvo su maestría en Ingeniería Eléctrica en la Universidad Tecnológica Chalmers (Chalmers
tekniska högskola) de Gotemburgo en 1962, y un doctoradoen la Universidad Tecnológica Real
(Kungliga Tekniska högskolan) de Estocolmo en 1985, con una tesis sobre lenguaje constructor
para grandes sistemas en tiempo real.
En 1967 propuso la utilización de componentes de software en el desarrollo de la nueva
generación de conmutadores telefónicos controlados, que Ericssonestaba desarrollando. Para
ello inventó diagramas de secuencia y desarrolló diagramas de colaboración. También aplicó
diagramas de transición de estado para describir el flujo de mensajes entre los componentes.
Pensó que era necesario hacer planes de desarrollo de software y fue uno de los desarrolladores
originales de SDL (lenguaje de descripción y especificación). En 1967, SDL se convirtió en un
estándar en la industria de las telecomunicaciones.
También inventó casos de uso como una forma de especificar los requisitos funcionales de
software.
En abril de 1987, dejó Ericsson y fundó la empresa Objective Systems. Una mayoría de las
acciones de la compañía fue adquirida por Ericsson en 1991, y la compañía fue
renombrada Objectory AB.
Ivar Jacobson desarrolló el proceso de software OOSE en Objectory AB alrededor de 1992.
En octubre de 1995 Ericsson vendió Objectory AB a la firma Rational Software, y Jacobson
comenzó a trabajar con Grady Booch y James Rumbaugh, primero para crear el Lenguaje
Unificado de Modelado (UML) y posteriormente para desarrollar el Proceso Unificado Racional
(RUP). En 2003 Rational Software fue adquirida por IBM e Ivar decidió renunciar, pero se quedó
en la empresa hasta mayo de 2004, como técnico consultor ejecutivo.
A mediados de 2003 formó Ivar Jacobson International (IJI), que es un paraguas de la
empresa Ivar Jacobson Consulting (IJC), que opera en 4 continentes y cuenta con oficinas en el
Reino Unido, EE.UU., Escandinavia, China, Corea, Singapur y Australia.
En noviembre de 2005, Jacobson anunció la Essential Unified Process (EssUP), una nueva
"práctica" centrada en el proceso de desarrollo de software. Se trata de un nuevo comienzo a la
integración de prácticas eficaces de entre los tres principales campos de proceso: el proceso
unificado, los métodos ágiles y el proceso de madurez. Cada uno de ellos contribuye diferentes
capacidades: estructura, la agilidad y la mejora de procesos.
Jacobson ha descrito a EssUP como un "súper ligeros y ágiles". RUP y la IJC han integrado
EssUP en Microsoft Visual Studio Team System, y Eclipse.

James Rumbaugh
James Rumbaugh (22 de agosto de 1947) es un científico de la computación y un
metodologista de objeto. Es más conocido por su trabajo en la creación de la Técnica de
Modelado de Objetos y el Lenguaje Unificado de Modelado (UML). Doctorado en ciencias de la
computación por el M.I.T.
Rumbaugh dirigió el desarrollo de la metodología OMT, en el Centro de Investigación y
Desarrollo de la General Electric, donde trabajó durante más de 25 años.
Se unió a Rational Software en 1994, y trabajó allí con Ivar Jacobson y Grady Booch ("los Tres
Amigos") para desarrollar UML. Más tarde fusionaron sus metodologías de desarrollo de
software, OMT, OOSE y Booch en el Proceso Unificado Racional (RUP). En el 2003 se trasladó
a IBM, después de su adquisición de Rational Software. Se retiró en 2006.
Ha escrito varios libros sobre UML y RUP, junto a Ivar Jacobson y Grady Booch.

Historia de UML
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la
compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología
del software).

El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el
OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma
época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas
tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la
colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones
condujeron a la definición de la primera versión de UML.

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar
artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y
controlar la información sobre los sistemas a construir.

UML capta la información sobre la estructura estática y el comportamiento dinámico de un

sistema. Un sistema se modela como una colección de objetos discretos que interactúan para
realizar un trabajo que finalmente beneficia a un usuario externo.

El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e

incorporar las mejores prácticas actuales en un acercamiento estándar.

UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de

código de UML para una gran variedad de lenguaje de programación, así como construir
modelos por ingeniería inversa a partir de programas existentes.
La notación UML se deriva y unifica las tres metodologías de análisis y diseños más extendidas.
Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling
Technique).
Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la
metodología de casos de uso (use case).

El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de
Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacob
son y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método
OOSE.
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
el 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.

UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la

notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un
meta-modelo auto-referencial (cualquier lenguaje de modelado de propósito general debería
ser capaz de modelarse a sí mismo).

Objetivos

Durante el desarrollo del UML sus autores tuvieron en cuenta:

Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad de
aspectos del modelado contemporáneo de una forma directa y económica.

Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar
en un futuro, como por ejemplo aspectos relacionados con la tecnología de componentes, el
cómputo distribuido, etc.

Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el

meta-modelo a un coste bajo.

Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras

podrían desarrollarse encima del UML.

Permitir el intercambio del modelo entre una gran variedad de herramientas.

Proporcionar semánticas suficientes para especificar las interfaces a bibliotecas para la

comparación y el almacenamiento de componentes del modelo.

Ser tan simple como sea posible, pero manteniendo la capacidad de modelar toda la gama de
sistemas que se necesita construir.

UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.

UML no pretende ser un método de desarrollo completo.

Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.

Imponer un estándar mundial.

Mediante el fomento del uso de UML OMG pretende alcanzar los siguientes objetivos:

Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el

desarrollo e intercambio de modelos significativos.

Proporcionar mecanismos de extensión y especialización.

Ser independiente del proceso de desarrollo y de los lenguajes de programación.

Proporcionar una base formal para entender el lenguaje de modelado.
Fomentar el crecimiento del mercado de las herramientas OO.

Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones, frameworks,
patterns, y componentes. Integrar las mejores prácticas utilizadas hasta el momento.

El UML debe entenderse como un estándar para modelado y no como un estándar de proceso
software. Aunque UML debe ser aplicado en el contexto de un proceso, la experiencia ha
mostrado que organizaciones diferentes y dominios del problema diferentes requieren
diferentes procesos. Por ello se han centrado los esfuerzos en un meta-modelo común (que
unifica las semánticas) y una notación común que proporcione una representación de esas
semánticas. De todas formas, los autores de UML fomentan un proceso guiado por casos de uso,
centrado en la arquitectura, iterativo e incremental. Bajo estas líneas genéricas proponen el
proceso software definido en una de las extensiones del UML (Objectory Extension for Software
Enginnering), pero en general el proceso software es fuertemente dependiente de la
organización y del dominio de aplicación.

Los conceptos y modelos de UML pueden agruparse en las siguientes áreas conceptuales:

Estructura estática:

Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave de la
aplicación, sus propiedades internas, y las relaciones entre cada una de ellas. Este conjunto de
construcciones es la estructura estática. Los conceptos de la aplicación son modelados como
clases, cada una de las cuales describe un conjunto de objetos que almacenan información y se
comunican para implementar un comportamiento. La información que almacena es modelada
como atributos; La estructura estática se expresa con diagramas de clases y puede usarse para
generar la mayoría de las declaraciones de estructuras de datos en un programa.

Comportamiento dinámico:

Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto y la

forma como interactúa con el resto del mundo y la otra es por los patrones de comunicación de
un conjunto de objetos conectados, es decir la forma en que interactúan entre sí. La visión de
un objeto aislado es una maquina de estados, muestra la forma en que el objeto responde a los
eventos en función de su estado actual. La visión de la interacción de los objetos se representa
con los enlaces entre objetos junto con el flujo de mensajes y los enlaces entre ellos. Este punto
de vista unifica la estructura de los datos, el control de flujo y el flujo de datos.
Construcciones de implementación:

Los modelos UML tienen significado para el análisis lógico y para la implementación física. Un
componente es una parte física reemplazable de un sistema y es capaz de responder a las
peticiones descritas por un conjunto de interfaces. Un nodo es un recurso computacional que
define una localización durante la ejecución de un sistema. Puede contener componentes y
objetos.

Mecanismos de extensión:

UML tiene una limitada capacidad de extensión pero que es suficiente para la mayoría de las
extensiones que requiere el día a día sin la necesidad de un cambio en el lenguaje básico. Un
estereotipo es una nueva clase de elemento de modelado con la misma estructura que un
elemento existente, pero con restricciones adicionales.

Organización del modelo:

La información del modelo debe ser dividida en piezas coherentes, para que los equipos puedan
trabajar en las diferentes partes de forma concurrente. El conocimiento humano requiere que
se organice el contenido del modelo en paquetes de tamaño modesto. Los paquetes son
unidades organizativas, jerárquicas y de propósito general de los modelos de UML. Pueden
usarse para almacenamiento, control de acceso, gestión de la configuración y construcción de
bibliotecas que contengan fragmentos de código reutilizable.

Elementos de anotación

Los elementos de anotación son las partes explicativas de los modelos UML. Son comentarios
que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento
de un modelo.

El tipo principal de anotación es la nota que simplemente es un símbolo para mostrar

restricciones y comentarios junto a un elemento o un conjunto de elementos

Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia,
asociación, generalización y realización, estas se describen a continuación

Dependencia
Es una relación semántica entre dos elementos en la cual un cambio a un elemento (el elemento
independiente) puede afectar a la semántica del otro elemento (elemento dependiente). Se
representa como una línea discontinua, posiblemente dirigida, que a veces incluye una etiqueta.

Asociación
Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre
objetos. La agregación es un tipo especial de asociación y representa una relación estructural
entre un todo y sus partes. La asociación se representa con una línea continua, posiblemente
dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos para indicar la
multiplicidad y roles de los objetos involucrados.
Generalización
Es una relación de especialización / generalización en la cual los objetos del elemento
especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta
forma, el hijo comparte la estructura y el comportamiento del padre. Gráficamente, la
generalización se representa con una línea con punta de flecha vacía.

Realización
Es una relación semántica entre clasificadores, donde un clasificador especifica un contrato que
otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos
sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las
colaboraciones que los realizan. La realización se representa como una mezcla entre la
generalización y la dependencia, esto es, una línea discontinua con una punta de flecha vacía .

Diagramas
Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que
un diagrama es una proyección del mismo. UML proporciona un amplio conjunto de diagramas
que normalmente se usan en pequeños subconjuntos para poder representar las cinco vistas
principales de la arquitectura de un sistema.

Diagramas de Clases

Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos
diagramas son los más comunes en el modelado de sistemas orientados a objetos y cubren la
vista de diseño estática o la vista de procesos estática (sí incluyen clases activas).

Diagramas de Objetos

Muestran un conjunto de objetos y sus relaciones, son como fotos instantáneas de los diagramas
de clases y cubren la vista de diseño estática o la vista de procesos estática desde la perspectiva
de casos reales o prototípicos.

Diagramas de Casos de Usos

Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren
la vista estática de los casos de uso y son especialmente importantes para el modelado y
organización del comportamiento.

Diagramas de Secuencia y de Colaboración

Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas
de interacción. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que
se pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas de
secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de
colaboración muestran la organización estructural de los objetos que envían y reciben mensajes.
Los diagramas de secuencia se pueden convertir en diagramas de colaboración sin pérdida de
información, lo mismo ocurren en sentido opuesto.
Diagramas de Estados

Muestran una máquina de estados compuesta por estados, transiciones, eventos y actividades.
Estos diagramas cubren la vista dinámica de un sistema y son muy importantes a la hora de
modelar el comportamiento de una interfaz, clase o colaboración.

Diagramas de Actividades

Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades
dentro de un sistema. Los diagramas de actividades cubren la parte dinámica de un sistema y se
utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre
objetos.

Diagramas de Componentes

Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista

de la implementación estática y se relacionan con los diagramas de clases ya que en un
componente suele tener una o más clases, interfaces o colaboraciones

Diagramas de Despliegue

Representan la configuración de los nodos de procesamiento en tiempo de ejecución y los

componentes que residen en ellos. Muestran la vista de despliegue estática de una arquitectura
y se relacionan con los componentes ya que, por lo común, los nodos contienen uno o más
componentes.