mbooch

8/2/2019 MBooch

1/14

62

Instituto Tecnolgicode la Laguna

Anlisis y Diseo Orientadoa Objetos

Paola Romero Guilln

3.3 EL MTODO DE BOOCH.

3.3.1 Introduccin.

El mtodo cuenta con una notacin expresiva y bien definida que le permite al diseadorcomunicar 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.

El hecho de que esta notacin sea detallada no significa que se deben utilizar todos susaspectos en la totalidad de las ocasiones, de hecho, un subconjunto de ella es suficiente paraexpresar la semntica de un gran porcentaje de problemas de anlisis y diseo. La notacinutilizada 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 loque se deben evitar para la implementacin.

3.3.2 Modelos y vistas.

Son necesarias dos dimensiones para especificar la estructura y comportamiento de unsistema 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 losmodelos 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 ylos mecanismos que forman el espacio del problema o para definir la arquitectura delsistema.

Modelo fsico: Describe la composicin concreta en cuanto a hardware y software delcontexto o implantacin del sistema.

Estructura de clases

Estructura de Objetos

Arquitectura de mdulos

Arquitectura de procesos

Figura # 44 Modelos del desarrollo Orientado a Objetos..

Modelo Dinmico

Modelo Esttico

Modelo Lgico

Modelo Fsico

8/2/2019 MBooch

2/14

63



Paola Romero Guilln

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 lavisin lgica de un sistema, utilizados en la etapa de anlisis.

Diagramas de objetos: Muestran la existencia de objetos y sus relaciones enla 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 procesadoresen el diseo fsico de un sistema.

Modelos dinmicos: La semntica dinmica de un problema se expresa mediantelos siguientes diagramas:

Diagrama de transicin de estados: Muestra el comportamiento de cadainstancia de una clase, los eventos que provocan una transicin de un estado aotro y las acciones que resultan de este cambio de estado, por lo que, cadaclase puede contar con este tipo de diagrama.

Diagramas de interaccin: Muestra el orden temporal en que se suceden losmensajes en un conjunto de objetos que representan un escenario. Estn en elmismo 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 visinlgica de un sistema. Los dos elementos esenciales de un diagrama de clases son: las clases ysus relaciones bsicas.

Clases: La figura # 45 muestra el icono que se utiliza para representar una clase en un diagrama declases. En ciertos diagramas de clases, es til exponer algunos de los atributos y operacionesasociados con una clase:

Atributos: denotan una parte de un objeto agregado, durante el diseo expresan una propiedadsingular de la clase.

! A Nombre del atributo solamente.! :C Clase del atributo solamente.! A:C Nombre y clase del atributo.

a) Icono de una clase

Nombre

AtributosOperaciones( )

Figura # 45

8/2/2019 MBooch

3/14

64



Paola Romero Guilln

Operaciones: denotan algn servicio proporcionado por la clase, se distinguen de los atributosaadiendo 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. Lasconexiones esenciales entre clases incluyen las siguientes relaciones:

Asociacin: conecta dos clases y denota una conexin semntica, se etiquetan conexpresiones sustantivas, denotando la naturaleza de la relacin.

Herencia: denota una relacin de generalizacin / especializacin (una relacin ), yaparece como una asociacin con una cabeza de flecha. La flecha apunta a la superclase, y elextremo opuesto de la asociacin designa la subclase. La subclase hereda la estructura ycomportamiento de su superclase. Las relaciones de herencia no pueden llevar indicaciones decardinalidad.

Posesin: denota una relacin todo / parte (relacin o agregacin), aparececomo una asociacin con un crculo relleno en el extremo que seala al agregado, la clase queesta en el otro extremo denota la parte cuyas instancias estn contenidas por el objetoagregado.

Utilizacin: denota una relacin cliente / servidor y aparece como una asociacin con unacircunferencia 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.

La multiplicidad o cardinalidad: se aplica el adorno de la cardinalidad al extremo de destinode una asociacin y denota el nmero de enlaces entre cada instancia de la clase origen y lasinstancias de la clase destino.

1 Exactamente uno.

N Nmero ilimitado.

1

Fruta1

50

Pildora

1Pacman

1

1Come

50

1

Come

Figura # 47 Diagrama de clases

Asociacin

HerenciaPosesin

Uso

Figura # 46 Iconos de relaciones

8/2/2019 MBooch

4/14

65



Paola Romero Guilln

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: es aquella clase la cual no puede tener instancias. Para representarla se seala el iconode clase con la letra (A), situada en el interior de un triangulo, en cualquier punto del interior delicono 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 derombo(V).Amiga: la designacin de una clase que concede a otra derechos de acceso a sus partes nopublicas (F).

1

1

A

Pildora

n

1

Pildora_m

1

4

Laberinto

nS

1

Fantasma n

1

n

11

4

PacmanPosicin : entero

1

1

1

4Come

1

4 F

Come

Pildora_N

n

1

n

1

F

A

S

Figura # 49 Ejemplo de Propiedades

A F

S V

Abstracta Amiga

Esttica Virtual

Figura # 48

8/2/2019 MBooch

5/14

66



Paola Romero Guilln

Diagramas de Objetos.

Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones enel 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 deobjetos. Al igual que en el diagrama de clases, tambin se pueden especificar algunos atributos delobjeto.

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 igualque un objeto es una instancia de una clase.

Mensaje: la existencia de una asociacin entre dos clases denota por tanto una va decomunicacin entre instancias de clases, por la que un objeto puede enviar mensajes a otro. Unobjeto tambin puede enviarse un mensaje a s mismo. Cualquier objeto que invoque la operacinse conoce como cliente, cualquier objeto que suministre la operacin se conoce como proveedor oservidor. Un enlace se puede adornar mediante una serie de mensajes. Cada mensaje consta detres 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 laoperacin.

Figura # 50 Icono de objeto.

Nombre

Atributo

Mensa e armetros

Objeto/valor

Rol

[Llave]

Restriccin

Figura # 51 Relaciones entre objeto.

8/2/2019 MBooch

6/14

67



Paola Romero Guilln

Papeles, claves y restricciones: denotan el propsito o carcter de la relacin que asocia unaclase con otra. Es til declarar este papel en el enlace correspondiente entre dos objetos, ya queayuda 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 deun 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 elmensaje.

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

Fuera de tiempo: Es igual al anterior, solo que en este casose espera una cierta cantidad de tiempo

Sincronizacin: El servidor pone en la cola el mensaje y elcliente 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 operacindel cliente.

Campo: El objeto servidor es una parte del cliente.

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

G

P

F

L

Figura # 53 Visibilidad

8/2/2019 MBooch

7/14

68



Paola Romero Guilln

Diagramas de transicin de estados.

Un diagrama de transicin de estados se utiliza para mostrar el espacio de estados de unaclase determinada, los eventos que provocan una transicin de un estado a otro y las acciones queresultan de ese cambio de estado.

Puede representar una vista del modelo dinmico de una sola clase o de un sistemacompleto. Debido a que durante el anlisis se utilizan para indicar el comportamiento dinmico delsistema.

Estados: el estado de un objeto representa los resultados acumulados de su comportamiento. Todoestado debe de tener un nombre y este debe ser nico dentro de la clase que lo contiene. Estambin til exponer las acciones asociadas a un estado.

Transiciones entre estados: se le conoce como cambio de estado, un evento es algn suceso quepuede causar un cambio en el estado de un objeto. Cada transicin de estados conecta a dosestados, 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 oparada 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 disparadaautomticamente solo en el caso de que la expresin se evalu como cierta. El orden de evaluacinen transicin de estado condicionales es importante. En todo diagrama de transicin de estadosdebe haber exactamente un estado de partida por defecto, que se designa escribiendo unatransicin sin etiqueta al estado desde un icono especial, que aparece como un circulo relleno. Esmenos frecuente describir un estado de parada.

Figura # 54 Diagrama de objetos.

1

Fruta

Posicion : entero = 100Valor : entero = 15

50

Posicion : entero = 150

Pildora

Valor : entero = 5

Numero : entero = 50

Pacman

Posicion : entero = 12Puntos : entero = 200

Vida : entero = 3Velocidad : entero = 20

1Come

50

Come

1

1

8/2/2019 MBooch

8/14

69



Paola Romero Guilln

El diagrama de estados inicia cuando el Pacman camina, entra en un estado activo quetiene dos estados opcionales a donde puede irse. Si se topa en un borde entra en estado de esperay la otra opcin es de comer Pldora-M en este estado puede comer fantasma e incrementarvelocidad. 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 suselementos esenciales de los diagramas de objeto. Con este tipo de diagramas es ms fcil leer el

paso de mensajes en orden relativo.

Figura # 56 Diagrama de transicin de estados.

inicio

entry: Camina

Activo

do: Come Pildora, Camina

En Borde

do: Espera

Come Pildora_M

do: Come Fantasma, incrementa velocidad

[ Fantasma come pacman ] / Pacman termina

a) icono de estado b) icono de transicin de estado.

nombre

acciones

Figura # 55

evento / accin

8/2/2019 MBooch

9/14

70



Paola Romero Guilln

El diagrama de interaccin esta compuesto de 3 bloques y un actor que es el jugador. Iniciacon el mensaje moverque va del actor hacia la clase Pacman. Despus la clase Pacman se envaun 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, esdecir 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 mdulosen el diseo fsico de un sistema. Un solo diagrama de mdulos representa una vista de laestructura de mdulos de un sistema. Los dos elementos esenciales de un diagrama de mdulosson los mdulos y sus dependencias.

Programa principal:Denota un archivo que contiene la raz del programa.

Figura # 57 Diagrama de interaccin.

: Jugador: Pacman : Fruta : Pildora

Camina_

Camina_Fruta(Posicion)

Come_

Decrementa(n

Come_

Mover

c) Programa Principal

Figura # 58

8/2/2019 MBooch

10/14

71



Paola Romero Guilln

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

Subsistema: Los subsistemas sirven para modularizar el modelo fsico de un sistema. Unsubsistema 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.

Figura # 61 Diagrama de mdulos

Definicin de Pacman Definicin de Pildora Definicin de Fruta

Definicin de Campo

Campo

Sistema del Pacman

Sistema del Pacman

a) Especificacin en "C" archivo .h b) Cuerpo en "C" archivo .cpp

Figura # 59

nombre

d Subsistema.

Figura # 60

8/2/2019 MBooch

11/14

72



Paola Romero Guilln

Dependencias: la nica relacin que puede darse entre dos mdulos es una dependencia decompilacin, representada por una lnea dirigida que apunta al modulo respecto al cual existe ladependencia.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 enel diseo fsico de un sistema. Un solo diagrama de procesos presenta una vista de la estructura deprocesos 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.

3.3.4 El proceso.

El proceso de diseo orientado a objetos no puede describirse mediante reglas, aunqueesta bastante bien definido como para brindar un proceso predecible y repetible para unaorganizacin de software madura.

Un proyecto de software bien hecho es aquel en el que el software entregado satisface yposiblemente excede las expectativas del cliente. Se ha desarrollado de forma econmica,

nombre

nombre

a) icono de proceso b) icono de dispositivo c) icono de conexin

Figura # 62 Diagrama de Procesos.

Estacin de Juegodel Usuario

JoyStick

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

8/2/2019 MBooch

12/14

73



Paola Romero Guilln

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

! La existencia de una fuerte visin arquitectnica. Un sistema con una buena arquitectura esaquel 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 losrequerimientos 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 macro-proceso 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 eldominio del mismo. A raz de realizar esta etapa se crea un diccionario de datos donde sedocumentan 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 unrefinamiento 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 selleva a cabo mediante la descripcin de las responsabilidades de cada abstraccin. En estaetapa se especifican las asociaciones y mediante la separacin de responsabilidades se lleva acabo un refinamiento de las mismas, adems esta etapa tiene como consecuencia otrorefinamiento 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 queuna abstraccin responde al llamado de otra, lo cual lleva a definir mtodos y mensajestransmitidos entre las abstracciones.

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

8/2/2019 MBooch

13/14

74



Paola Romero Guilln

.

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 deactividades cuantificables que permiten al equipo de desarrollo tasar el riego de forma significativa yrealizar correcciones iniciales al micro-proceso de forma de centrar mejor las actividades de anlisisy diseo del equipo. El macro-proceso realiza las siguientes actividades:

! Conceptualizacin: En esta etapa se establecen los requisitos esenciales para elsistema.

! Anlisis: Se lleva a cabo un anlisis en el dominio del problema para poder llegar adescribir 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.

Diccionario de datos(responsabilidades yaccesibilidad entre ellos)

Identificar clasesy objetos.

Identificarsemntica de

clases y objetos.

Especificar interfaces eimplementacin declases y objetos.

Identificarrelaciones entreclases y objetos.

Diccionario de datos(clases y objetos)

Diccionario de datos(clases y objetosresponsabilidades)

Refinamiento deldiccionario

Figura # 64 Microproceso de desarrollo.

8/2/2019 MBooch

14/14

75



Paola Romero Guilln

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

Booch propone este proceso de desarrollo pensando en que el macro-proceso es aquelproceso donde las etapas de desarrollo abarcan un perodo grande, donde un equipo dedesarrolladores se vera implicado, mientras que define al micro-proceso como una actividad diariaque 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 micro-proceso donde se describen que clases y objetos intervendrn, y mientras se avanza en el macro-proceso cuando se tengan establecidos los escenarios en el micro-proceso se podr llevar acabouna 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 sepueden tener varias iteraciones del micro-proceso, lo cual tendr el propsito de refinar el sistemaagregando o eliminando abstracciones que se presenten en el sistema.

No importa lo sofisticado que sea el mtodo de desarrollo, y lo bien fundamentado queestn sus bases tericas, no es posible ignorar los aspectos prcticos de diseo de sistemas para elmundo real. Esto implica que es necesario considerar buenas prcticas de gestin por lo que serefiere a temas como; administracin de personal, gestin de versiones y control de calidad.

Establecer

requisitos bsicos(conceptualizacin)

Desarrollar un

modelo delcomportamientodeseado anlisis

Crear unaarquitectura

(diseo)

Gestionar laevolucin despus de

la entrega(mantenimiento)

Transformar laimplementacin

(evolucin)

Figura # 65 Macro-proceso de desarrollo.

mbooch

Documents