Instituto Tecnolgico

de la Laguna

Anlisis y Diseo Orientado

a Objetos

3.3 EL MTODO DE BOOCH.

3.3.1 Introduccin.
El mtodo cuenta con una notacin expresiva y bien definida que le permite al diseador
comunicar sus ideas y concentrarse en problemas ms serios.
Para la captura de todos los detalles de un sistema de software complejo es necesario
vistas mltiples. La Figura # 44 muestra los diferentes modelos que se han considerado relevantes,
en el desarrollo de un proyecto orientado a objetos.
Modelo Dinmico
Modelo Esttico

Estructura de clases
Modelo Lgico

Estructura de Objetos
Modelo Fsico

Arquitectura de mdulos
Arquitectura de procesos

Figura # 44 Modelos del desarrollo Orientado a Objetos..

El hecho de que esta notacin sea detallada no significa que se deben utilizar todos sus
aspectos en la totalidad de las ocasiones, de hecho, un subconjunto de ella es suficiente para
expresar la semntica de un gran porcentaje de problemas de anlisis y diseo. La notacin
utilizada es independiente del lenguaje seleccionado, es necesario tener en cuenta que algunos
elementos de la notacin no tienen equivalencia en determinados lenguajes de programacin, por lo
que se deben evitar para la implementacin.
3.3.2 Modelos y vistas.
Son necesarias dos dimensiones para especificar la estructura y comportamiento de un
sistema orientado a objetos:
Dimensin uno: Fsica / Lgica.
Dimensin dos: Esttica / Dinmica.
Para cada dimensin se definen una serie de diagramas que denotan una vista de los
modelos del sistema, stos reflejan "toda la verdad" sobre sus clases, relaciones y otras entidades,
y cada diagrama representa una proyeccin de estos modelos. En el estado estable, todos estos
diagramas deben ser consistentes con el modelo y tambin consistentes entre ellos mismos.
Modelos lgicos contra modelos fsicos.
Modelo lgico: Describe la existencia y significado de las abstracciones principales y
los mecanismos que forman el espacio del problema o para definir la arquitectura del
sistema.
Modelo fsico: Describe la composicin concreta en cuanto a hardware y software del
contexto o implantacin del sistema.
Paola Romero Guilln

62

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Modelos estticos contra modelos dinmicos.

Modelos estticos: Estn formados por los diagramas de:

Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la
visin lgica de un sistema, utilizados en la etapa de anlisis.
Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en
la etapa de diseo lgico de un sistema.
Diagramas de mdulos: Muestran la asignacin de clases y objetos a
mdulos en el diseo fsico de un sistema.
Diagramas de procesos: Muestran la asignacin de procesos a procesadores
en el diseo fsico de un sistema.

Modelos dinmicos: La semntica dinmica de un problema se expresa mediante

los siguientes diagramas:
Diagrama de transicin de estados: Muestra el comportamiento de cada
instancia de una clase, los eventos que provocan una transicin de un estado a
otro y las acciones que resultan de este cambio de estado, por lo que, cada
clase puede contar con este tipo de diagrama.
Diagramas de interaccin: Muestra el orden temporal en que se suceden los
mensajes en un conjunto de objetos que representan un escenario. Estn en el
mismo contexto que los diagramas de objetos.

3.3.3 Representacin grfica.

Diagramas de Clases
Un diagrama de clases es utilizado para mostrar la existencia de clases y sus relaciones en la visin
lgica de un sistema. Los dos elementos esenciales de un diagrama de clases son: las clases y
sus relaciones bsicas.
Clases: La figura # 45 muestra el icono que se utiliza para representar una clase en un diagrama de
clases. En ciertos diagramas de clases, es til exponer algunos de los atributos y operaciones
asociados con una clase:
Nombre
Atributos
Operaciones( )

a) Icono de una clase

Figura # 45
Atributos: denotan una parte de un objeto agregado, durante el diseo expresan una propiedad
singular de la clase.
! A
Nombre del atributo solamente.
! :C
Clase del atributo solamente.
! A:C Nombre y clase del atributo.

Paola Romero Guilln

63

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Operaciones: denotan algn servicio proporcionado por la clase, se distinguen de los atributos
aadiendo parntesis.
! N() Nombre de la operacin solamente.
! R N(Argumento) Clase de retorno de la operacin, nombre y parmetros formales (si los
hay).
Relaciones de clase: representan una colaboracin con otras clases de diversas maneras. Las
conexiones esenciales entre clases incluyen las siguientes relaciones:
Asociacin
Herencia
Posesin
Uso
Figura # 46 Iconos de relaciones

Asociacin: conecta dos clases y denota una conexin semntica, se etiquetan con
expresiones sustantivas, denotando la naturaleza de la relacin.
Herencia: denota una relacin de generalizacin / especializacin (una relacin <<es un>>), y
aparece como una asociacin con una cabeza de flecha. La flecha apunta a la superclase, y el
extremo opuesto de la asociacin designa la subclase. La subclase hereda la estructura y
comportamiento de su superclase. Las relaciones de herencia no pueden llevar indicaciones de
cardinalidad.
Posesin: denota una relacin todo / parte (relacin <<tiene un>> o agregacin), aparece
como una asociacin con un crculo relleno en el extremo que seala al agregado, la clase que
esta en el otro extremo denota la parte cuyas instancias estn contenidas por el objeto
agregado.
Utilizacin: denota una relacin cliente / servidor y aparece como una asociacin con una
circunferencia en el extremo que denota al cliente. En esta relacin de alguna forma el cliente
depende del servidor para que ste le proporcione determinados servicios.
Pildora
Come

50

Pacman
1

Fruta

1Come
1

Figura # 47 Diagrama de clases

La multiplicidad o cardinalidad: se aplica el adorno de la cardinalidad al extremo de destino
de una asociacin y denota el nmero de enlaces entre cada instancia de la clase origen y las
instancias de la clase destino.
1 Exactamente uno.
N Nmero ilimitado.
Paola Romero Guilln

64

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

0..N Cero o ms.

1..N Uno o ms.
0..1 Cero o uno.
3..7 Rango especfico.
1..3, 7 Rango especfico o nmero exacto.

Tipos de clases:

Abstracta

Amiga

Esttica

Virtual

Figura # 48

Abstracta: es aquella clase la cual no puede tener instancias. Para representarla se seala el icono
de clase con la letra (A), situada en el interior de un triangulo, en cualquier punto del interior del
icono de clase.
Esttica: la designacin de un objeto o funcin miembro de una clase (S).
Virtual: la designacin de una clase base compartida en una trama de herencias con forma de
rombo(V).
Amiga: la designacin de una clase que concede a otra derechos de acceso a sus partes no
publicas (F).
Pacman

Laberinto

Posicin : entero
1

1 Come

S n
S

4 F

Come
4

Fantasma

Pildora

n
Pildora_m

A
A

Pildora_N
n

Figura # 49 Ejemplo de Propiedades

Paola Romero Guilln

65

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Diagramas de Objetos.
Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones en
el diseo lgico de un sistema. Los dos elementos esenciales de un diagrama de objetos son los
objetos y sus relaciones.
Objetos: La Figura # 50 muestra el icono que se usa para representar un objeto en un diagrama de
objetos. Al igual que en el diagrama de clases, tambin se pueden especificar algunos atributos del
objeto.
Nombre
Atributo

Figura # 50 Icono de objeto.

Relaciones entre objetos: los objetos interaccionan a travs de sus enlaces con otros objetos,
representados por el icono de la Figura # 51, un enlace es una instancia de una asociacin, al igual
que un objeto es una instancia de una clase.
Mensaje(parmetros)
Objeto/valor
Rol
[Llave]
Restriccin
Figura # 51 Relaciones entre objeto.

Mensaje: la existencia de una asociacin entre dos clases denota por tanto una va de
comunicacin entre instancias de clases, por la que un objeto puede enviar mensajes a otro. Un
objeto tambin puede enviarse un mensaje a s mismo. Cualquier objeto que invoque la operacin
se conoce como cliente, cualquier objeto que suministre la operacin se conoce como proveedor o
servidor. Un enlace se puede adornar mediante una serie de mensajes. Cada mensaje consta de
tres elementos.
D Un smbolo de sincronizacin que denota la direccin de la invocacin.
M Una invocacin de operacin o despacho de evento.
S Opcionalmente, un nmero de secuencia.
La direccin del mensaje se indica mediante una lnea dirigida que apunta al objeto servidor.
La invocacin de una operacin es el tipo de mensaje ms comn. La sintaxis es la siguiente:
N() Solamente el nombre de la operacin.
R N(argumentos) Objeto de retorno, nombre y argumentos actuales de la
operacin.
Paola Romero Guilln

66

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Papeles, claves y restricciones: denotan el propsito o carcter de la relacin que asocia una
clase con otra. Es til declarar este papel en el enlace correspondiente entre dos objetos, ya que
ayuda a explicar porque un objeto opera sobre otro.
Flujo de datos: los datos pueden fluir en la misma direccin que un mensaje o en direccin
contraria. El mostrar explcitamente la direccin del flujo de datos ayuda a explicar la semntica de
un escenario particular.
Sincronizacin (para objetos activos).
Objetos activos: son aquellos que incorporan su propio hilo de control.
Simple: simple paso de mensajes secuencial.

Sincronizacin: Espera hasta que el servidor acepta el

mensaje.
Contratiempo: Abandona el mensaje si el servidor no puede
proporcionar el servicio de manera inmediata.

Fuera de tiempo: Es igual al anterior, solo que en este caso

se espera una cierta cantidad de tiempo

Sincronizacin: El servidor pone en la cola el mensaje y el

cliente continua sin esperar respuesta.
Figura # 52 Sincronizacin.
Visibilidad. (valor / referencia negro/blanco)

Global: El objeto proveedor es global al cliente.

Parmetro: El objeto proveedor es parametro de alguna operacin

del cliente.

Campo: El objeto servidor es una parte del cliente.

Local: Objeto declarado de forma local en el mbito del diagrama.

Figura # 53 Visibilidad

Paola Romero Guilln

67

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Pildora
Posicion : entero = 150
Valor : entero = 5
Numero : entero = 50

50

Come

Pacman
Posicion : entero = 12
Puntos : entero = 200
Vida : entero = 3
Velocidad : entero = 20

1
1

Come

Fruta
1

Posicion : entero = 100

Valor : entero = 15

Figura # 54 Diagrama de objetos.

Diagramas de transicin de estados.
Un diagrama de transicin de estados se utiliza para mostrar el espacio de estados de una
clase determinada, los eventos que provocan una transicin de un estado a otro y las acciones que
resultan de ese cambio de estado.
Puede representar una vista del modelo dinmico de una sola clase o de un sistema
completo. Debido a que durante el anlisis se utilizan para indicar el comportamiento dinmico del
sistema.
Estados: el estado de un objeto representa los resultados acumulados de su comportamiento. Todo
estado debe de tener un nombre y este debe ser nico dentro de la clase que lo contiene. Es
tambin til exponer las acciones asociadas a un estado.
Transiciones entre estados: se le conoce como cambio de estado, un evento es algn suceso que
puede causar un cambio en el estado de un objeto. Cada transicin de estados conecta a dos
estados, un estado puede tener una transicin hacia si mismo.
Accin: denota tpicamente la invocacin de un mtodo, el disparo de otro evento, o el inicio o
parada de una actividad.
Evento: puede ser un nombre simblico, una clase o el nombre de alguna operacin. Un evento
puede proporcionar operaciones que pueden recibir tales nombres y efectuar la accin adecuada.
Transiciones de estado condicionales: en esta tipo de transicin, esta ser disparada
automticamente solo en el caso de que la expresin se evalu como cierta. El orden de evaluacin
en transicin de estado condicionales es importante. En todo diagrama de transicin de estados
debe haber exactamente un estado de partida por defecto, que se designa escribiendo una
transicin sin etiqueta al estado desde un icono especial, que aparece como un circulo relleno. Es
menos frecuente describir un estado de parada.
Paola Romero Guilln

68

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

nombre
evento / accin

acciones

a) icono de estado

b) icono de transicin de estado.

Figura # 55

[ Fantasma come pacman ] / Pacman termina

inicio

Activo

entry: Camina

do: Come Pildora, Camina

Come Pildora_M
En Borde

do: Come Fantasma, incrementa velocidad

do: Espera

Figura # 56 Diagrama de transicin de estados.

El diagrama de estados inicia cuando el Pacman camina, entra en un estado activo que
tiene dos estados opcionales a donde puede irse. Si se topa en un borde entra en estado de espera
y la otra opcin es de comer Pldora-M en este estado puede comer fantasma e incrementar
velocidad. El estado activo termina cuando un fantasma se come al Pacman.

Diagramas de interaccin.
Es otra manera de representar el diagrama de objetos, tomando la mayora de sus
elementos esenciales de los diagramas de objeto. Con este tipo de diagramas es ms fcil leer el
paso de mensajes en orden relativo.

Paola Romero Guilln

69

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

: Pacman

: Jugador

: Fruta

: Pildora

Mover

Camina_

Camina_Fruta(Posicion)
Come_
Decrementa(n

Come_

Figura # 57 Diagrama de interaccin.

El diagrama de interaccin esta compuesto de 3 bloques y un actor que es el jugador. Inicia
con el mensaje mover que va del actor hacia la clase Pacman. Despus la clase Pacman se enva
un mensaje a el mismo que es el de caminar. Seguido de la clase Fruta donde su auto-mensaje es
de camina_fruta. Despus tanto Pldora como Fruta le enva un mensaje a Pacman de come, es
decir estas pueden ser comibles por el Pacman.
Diagramas de mdulos.
Se utiliza un diagrama de mdulos para mostrar la asignacin de clases y objetos a mdulos
en el diseo fsico de un sistema. Un solo diagrama de mdulos representa una vista de la
estructura de mdulos de un sistema. Los dos elementos esenciales de un diagrama de mdulos
son los mdulos y sus dependencias.
Programa principal :Denota un archivo que contiene la raz del programa.

c) Programa Principal
Figura # 58
Paola Romero Guilln

70

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Especificacin y cuerpo: Denotan archivos que contienen la declaracin y la definicin de las

entidades.

a) Especificacin en "C" archivo .h

b) Cuerpo en "C" archivo .cpp

Figura # 59
Subsistema: Los subsistemas sirven para modularizar el modelo fsico de un sistema. Un
subsistema es un agregado que contiene otros mdulos y otros subsistemas.
Cada modulo engloba la declaracin o definicin de clases, objetos y otros detalles del lenguaje.
Sistema del Pacman

nombre

Definicin de Pacman

Definicin de Pildora

Definicin de Fruta

d) Subsistema.
Figura # 60

Definicin de Campo

Campo

Sistema del Pacman

Figura # 61 Diagrama de mdulos

Paola Romero Guilln

71

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Dependencias: la nica relacin que puede darse entre dos mdulos es una dependencia de
compilacin, representada por una lnea dirigida que apunta al modulo respecto al cual existe la
dependencia.
Las flechas denotan dependencias, la flecha sale del el icono dependiente.
Diagrama de procesos.
Se usa un diagrama de procesos para mostrar la asignacin de procesos a procesadores en
el diseo fsico de un sistema. Un solo diagrama de procesos presenta una vista de la estructura de
procesos de un sistema.
Elementos del diagrama

Procesadores. Elemento de hardware capaz de ejecutar programas.

Dispositivos. Elemento de hardware incapaz de ejecutar un programa.
Conexiones. Son lneas no dirigida para indicar conexiones entre procesadores y/o dispositivos.

nombre

nombre

a) icono de proceso

b) icono de dispositivo

c) icono de conexin

Figura # 62 Diagrama de Procesos.

Estacin de Juego
del Usuario

JoyStick

Figura # 63 Diagrama de procesos, Representa el sistema del Pacman

3.3.4 El proceso.
El proceso de diseo orientado a objetos no puede describirse mediante reglas, aunque
esta bastante bien definido como para brindar un proceso predecible y repetible para una
organizacin de software madura.
Un proyecto de software bien hecho es aquel en el que el software entregado satisface y
posiblemente excede las expectativas del cliente. Se ha desarrollado de forma econmica,
Paola Romero Guilln

72

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

entregado en tiempo, y es flexible al cambio y al crecimiento. En los proyectos que han tenido xito
se ha visto que existen los siguientes aspectos:
!
!
!
!
!
!
!

La existencia de una fuerte visin arquitectnica. Un sistema con una buena arquitectura es
aquel que cuenta con integridad conceptual, y las siguientes propiedades:
Esta construido en capas de abstraccin bien definida.
Existe una separacin entre la interfaz y la implementacin de cada capa.
La arquitectura es simple.
La aplicacin de un ciclo de vida bien dirigido, iterativo e incremental.
Es iterativo ya que conduce al refinamiento sucesivo de una arquitectura orientada a
objetos.
Es incremental ya que en cada pasada por el ciclo; anlisis / diseo / evolucin conduce a
un refinamiento gradual de las decisiones estratgicas y tcticas, convergiendo hacia los
requerimientos reales y habitualmente no expresados por el usuario final.

El micro-proceso de desarrollo.

Esta dirigido por la corriente de escenarios y productos arquitectnicos, resultantes del macroproceso y refinamientos sucesivos. El micro-proceso sigue las siguientes actividades:

Identifica clases y objetos a un nivel dado de abstraccin:

Se identifican clases y tipos de objetos para delimitar el problema y tener bien establecido el
dominio del mismo. A raz de realizar esta etapa se crea un diccionario de datos donde se
documentan dichos elementos, el cual servir para tener una visin global del sistema.
Identifica la semntica de estas clases y objetos:
Se identifica que van a hacer y que representa cada clase de datos, por lo cual surge un
refinamiento del diccionario de datos debido a que cada descripcin de clase contendr los
atributos y responsabilidades de dichas clases.
Identifica las relaciones entre estas clases y objetos:
Se identifican las colaboraciones de cada clase u objeto, para establecer las asociaciones y se
lleva a cabo mediante la descripcin de las responsabilidades de cada abstraccin. En esta
etapa se especifican las asociaciones y mediante la separacin de responsabilidades se lleva a
cabo un refinamiento de las mismas, adems esta etapa tiene como consecuencia otro
refinamiento al diccionario de datos.
Especifica la interfaz y luego la implementacin de estas clases y objetos:
En esta etapa se verifican las abstracciones existentes ya que se identifican la forma en que
una abstraccin responde al llamado de otra, lo cual lleva a definir mtodos y mensajes
transmitidos entre las abstracciones.

En la figura # 64 se muestra el micro-proceso de desarrollo.

Paola Romero Guilln

73

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Identificar clases
y objetos.

Refinamiento del
diccionario

Diccionario de datos
(clases y objetos)

.
Especificar interfaces e
implementacin de
clases y objetos.

Identificar
semntica de
clases y objetos.

Diccionario de datos
(responsabilidades y
accesibilidad entre ellos)

Identificar
relaciones entre
clases y objetos.

Diccionario de datos
(clases y objetos
responsabilidades)

Figura # 64 Microproceso de desarrollo.

El micro-proceso se ve como un proceso de refinamiento dentro de las etapas del macro-proceso
Para cada una de las etapas se desarrollan los siguientes puntos:

Propsito.
Productos.
Actividades.
Hitos y medidas.

El macro-proceso de desarrollo.
En el marco de referencia para el control del micro-proceso, se dicta una serie de
actividades cuantificables que permiten al equipo de desarrollo tasar el riego de forma significativa y
realizar correcciones iniciales al micro-proceso de forma de centrar mejor las actividades de anlisis
y diseo del equipo. El macro-proceso realiza las siguientes actividades:
!
!
!
!
!

Conceptualizacin: En esta etapa se establecen los requisitos esenciales para el

sistema.
Anlisis: Se lleva a cabo un anlisis en el dominio del problema para poder llegar a
describir el problema basndose en el comportamiento del sistema.
Diseo: Crear una arquitectura para la implementacin.
Evolucin: En esta etapa se puede llegar a aumentar y cambiar la implantacin
mediante refinamientos sucesivos.
Mantenimiento: Gestionar la evolucin post-venta o post-entrega.

Para cada una de las etapas se desarrollan los siguientes puntos:

Propsito.
Productos.
Actividades.
Hitos y medidas.

Paola Romero Guilln

74

Instituto Tecnolgico
de la Laguna

Anlisis y Diseo Orientado

a Objetos

Grficamente el macro-proceso se puede representar como en la figura # 65 .

Establecer
requisitos bsicos
(conceptualizacin)

Desarrollar un
modelo del
comportamiento
deseado (anlisis)

Crear una
arquitectura
(diseo)

Gestionar la
evolucin despus de
la entrega
(mantenimiento)

Transformar la
implementacin
(evolucin)

Figura # 65 Macro-proceso de desarrollo.

Booch propone este proceso de desarrollo pensando en que el macro-proceso es aquel

proceso donde las etapas de desarrollo abarcan un perodo grande, donde un equipo de
desarrolladores se vera implicado, mientras que define al micro-proceso como una actividad diaria
que se debe de realizar segn lo que se va descubriendo o desarrollando durante el macro-proceso.
Mediante esta conceptualizacin durante las primeras etapas del macro-proceso en especial
en el anlisis es donde se estudia el comportamiento del sistema, se entra en el proceso del microproceso donde se describen que clases y objetos intervendrn, y mientras se avanza en el macroproceso cuando se tengan establecidos los escenarios en el micro-proceso se podr llevar acabo
una narracin de sucesos que ayudar a identificar las responsabilidades de cada abstraccin.
Mediante el ejemplo anterior se percibe que durante una etapa dentro del macro-proceso se
pueden tener varias iteraciones del micro-proceso, lo cual tendr el propsito de refinar el sistema
agregando o eliminando abstracciones que se presenten en el sistema.
No importa lo sofisticado que sea el mtodo de desarrollo, y lo bien fundamentado que
estn sus bases tericas, no es posible ignorar los aspectos prcticos de diseo de sistemas para el
mundo real. Esto implica que es necesario considerar buenas prcticas de gestin por lo que se
refiere a temas como; administracin de personal, gestin de versiones y control de calidad.

Paola Romero Guilln

75