Metodologias1 121105164855 Phpapp01.Desbloqueado

Trabajo Terico de Programacin Avanzada.
Metodologas Orientadas a Objeto
3 I. T. INFORMTICA DE GESTIN
PROGRAMACIN AVANZADA
IGNACIO CRUZADO NUO

JORGE GARCA DEL EGIDO
JAVIER PORTUGAL ALONSO
Pg. 1.
RESUMEN ................................................................................................................................................. 4
PALABRAS CLAVE ................................................................................................................................... 4
METODOLOGAS ORIENTADAS A OBJETOS. ................................................................................ 5
INTRODUCCIN ........................................................................................................................................ 5
Concepto de metodologa................................................................................................................... 5
Generalidades .................................................................................................................................... 6
Clasificaciones ................................................................................................................................... 6
EL MTODO DE BOOCH .......................................................................................................................... 8
Introduccin. ...................................................................................................................................... 8
La complejidad................................................................................................................................... 8
El modelo del objeto........................................................................................................................... 9
Elementos del modelo de objetos ...................................................................................................................9
Clases y objetos................................................................................................................................ 11
La naturaleza de un objeto ............................................................................................................................11
Relaciones entre los objetos..........................................................................................................................12
La naturaleza de una clase ............................................................................................................................13
Relaciones entre las clases............................................................................................................................13
La interaccin de Clases y objetos................................................................................................................14
Construccin de Clases y Objetos de Calidad...............................................................................................14
Clasificacin .................................................................................................................................... 15
Aproximacin a las clasificaciones...............................................................................................................15
Procedimientos para encontrar clases y objetos............................................................................................15
El mtodo ......................................................................................................................................... 16
Diagramas de clases......................................................................................................................................17
Diagramas de objetos....................................................................................................................................21
Otros diagramas............................................................................................................................................23
Los procesos del desarrollo orientado al objeto ............................................................................................26
Conclusin........................................................................................................................................ 26
Un ejemplo concreto ........................................................................................................................ 26
OMT (OBJECT MODELING TECNIQUE) JAMES RAMBAUGH ................................................................... 28
Visin general .................................................................................................................................. 28
Fases (4)........................................................................................................................................... 28
Pasos especficos a dar en cada fase ............................................................................................... 29
Fase De Anlisis ...........................................................................................................................................29
Fase De Diseo Del Sistema.........................................................................................................................30
Fase de Diseo De Objetos...........................................................................................................................30
Implementacin ............................................................................................................................................31
Conclusin........................................................................................................................................ 31
Notacin ........................................................................................................................................... 31
MTODO DE FUSION. COLEMAN ............................................................................................................ 33
Introduccin ..................................................................................................................................... 33
Anlisis............................................................................................................................................. 33
Modelo de objetos ........................................................................................................................................34
Modelo de Objetos del sistema .....................................................................................................................36
Modelo de la Interface ..................................................................................................................................36
Modelo del Funcionamiento .........................................................................................................................36
Modelo del Ciclo de Vida.............................................................................................................................37
Proceso de Anlisis .......................................................................................................................... 38

Diccionario de datos .....................................................................................................................................38
Desarrollo del Modelo de Objetos ................................................................................................................39
Determinacin de la Interface del Sistema....................................................................................................39
Desarrollo del Modelo de la Interface...........................................................................................................41
Verificando los Modelos del Anlisis...........................................................................................................41
Diseo .............................................................................................................................................. 42
Grfico de Interaccin de Objetos ................................................................................................................43
Grficos de visibilidad..................................................................................................................................47
Descripciones de clase..................................................................................................................................50
Grficos de herencia .....................................................................................................................................52
Implementacin ................................................................................................................................ 55
Pg. 2.
Gestin de un Desarrollo Fusion ..................................................................................................... 55

SMM (SHLAER & MELLOR METHOD) ................................................................................................... 56
Caractersticas ................................................................................................................................. 56
Proceso............................................................................................................................................. 56
Principales assets generados ........................................................................................................... 57
EROOS: (ESPECIFICACIONES ORIENTADAS A OBJETO E-R) ................................................................. 58
Introduccin ..................................................................................................................................... 58
Caractersticas ................................................................................................................................. 58
Ciclo de Vida.................................................................................................................................... 58
Filosofa y Conceptos Contemplados............................................................................................... 59
Notacin ........................................................................................................................................... 60
METODOLOGA MOSES ........................................................................................................................ 64
Introduccin ..................................................................................................................................... 64
Modelo Fuente ................................................................................................................................. 64
Ciclo de vida del producto ............................................................................................................... 66
Assets generados .............................................................................................................................. 66
Proceso de Ciclo de Vida (las 20 actividades) ............................................................................ 67
BON ...................................................................................................................................................... 71
Principios fundamentales................................................................................................................. 71
Proceso de Anlisis .......................................................................................................................... 72
Proceso de diseo............................................................................................................................. 72
LA UNIFICACIN DE MTODOS .............................................................................................................. 76
UML (Unified Modelating Languaje) .............................................................................................. 76
OPEN. .............................................................................................................................................. 76
CONCLUSIN ......................................................................................................................................... 79
BIBLIOGRAFA ....................................................................................................................................... 81
Pg. 3.
Resumen
En el mundo de desarrollo de software, se tiende cada vez ms hacia la programacin
orientada a objeto, un nuevo paradigma de programacin que aporta grandes ventajas al
software generado, como son el acercamiento entre el concepto del usuario y el
resultado programado o la disponibilidad a la reutilizacin del cdigo generado.
Pero todo ello no es posible sin seguir una metodologa que, por medio del
establecimiento de pasos, normas y conceptos a aplicar, lleve el desarrollo a buen
puerto, y con un resultado ptimo.
En este documento se pretende acercar al lector a las metodologas orientadas a objeto
que existen en la actualidad y dar una visin global de las mismas. As pues se hace
especial hincapi en OMT (la ms difundida actualmente), BOOCH (como punto de
partida de los conceptos que conlleva la orientacin a objeto) y FUSION (como una
metodologa ms desarrollada).
No pasa inadvertido que el futuro de las metodologas se basa en su unificacin, y por
ello este documento explica brevemente UML (como notacin unificadora) y OPEN
(como metodologa). En cualquier caso habr que esperar a la publicacin de
OBJETORY, que se perfila como la metodologa unificadora y de ms futuro.
Palabras Clave
Metodologa, orientacin a objeto, ciclo de vida, notacin, proceso, Booch, OMT,
Fusion, UML, OPEN, MOSES, EROOS, OOSE, BON, unificacin, clase, objeto,
anlisis, diseo.
Pg. 4.
Metodologas orientadas a objetos.

Introduccin
Con este trabajo se pretende acercar un poco ms al lector al mundo de las metodologas
orientadas a objeto. Es un mundo en contnua expansin.
Se tratar de ofrecer una idea global de las metodologas orintadas a objeto y
profundizar algo ms en las ms conocidas:
Booch, como punto de partida de los conceptos de la orientacin a objetos.
OMT, como la metodologa ms difundida en los desarrollos realizados

actualmente.
Fusion, como ejemplo de metodologa proveniente de otros mtodos (2

generacin).
Hoy en da se est trabajando en buscar una unificacin de mtodos. En esta lnea se ha

llegado a una unificacin en la notacin (UML). No se explicar muy detalladamente
pues merecera un artculo aparte.
Concepto de metodologa
No existe un consenso entre los diversos autores sobre el concepto de metodologa.
Genricamente se puede decir que una metodologa es un conjunto de pasos que
deben seguirse para el desarrollo de software.
Conjunto de filosofas, fases, procedimientos, reglas, tcnicas, herramientas,
documentacin y aspectos de formacin para los desarrolladores de sistemas de
informacin. Segn esto, una metodologa es un conjunto de componentes que
especifican:
Cmo dividir un proyecto en etapas.
Qu tareas se llevarn a cabo en cada etapa
Qu salidas se producen y cundo deben producirse.
Qu restricciones se aplican.
Qu herramientas van a ser utilizadas.
Cmo se gestiona y controla el proyecto.
R.N. Maddison
De un modo ms general una metodologa podra definirse como un conjunto de
conceptos para poder abstraer el dominio del problema, una notacin para representar
esos conceptos, una serie de pasos y procedimientos a seguir, y un conjunto de assets
generados.
Pg. 5.
Generalidades
Todas las metodologas distinguen estas tres fases:
Anlisis
Diseo
Implementacin
Segn Piattini [Piattini et al., 1996], se puede observar un cambio filosfico entre las
metodologas clsicas de anlisis y diseo estructurado y las de orientacin al objeto. En
las primeras se examinan los sistemas desde el punto de vista de las funciones o tareas
que deben realizar, tareas que se van descomponiendo sucesivamente en otras tareas
ms pequeas y que forman los bloques o mdulos de las aplicaciones. En la
orientacin al objeto, por su parte, cobra mucha ms importancia el aspecto de
modelado del sistema, examinando el dominio del problema como un conjunto de
objetos que interactan entre s.
En las metodologas tradicionales se produce una dicotoma entre los dos elementos
constituyentes de un sistema: funciones que llevan a cabo los programas y datos que se
almacenan en ficheros o bases de datos. Sin embargo, la orientacin al objeto propugna
un enfoque unificador de ambos aspectos, que se encapsulan en los objetos.
Clasificaciones
Se pueden identificar dos enfoques en las metodologas orientadas al objeto, [Fichman y
Kemerer, 1992]:
Revolucionarias o puras, que extienden la orientacin al objeto como un cambio

profundo que convierte a las metodologas estructuradas en obsoletas. En este
apartado podran incluirse metodologas como OOD de [Booch, 1991] o CRC/RDD
de [Wirfs-Brock et al., 1990].
Sintetistas o evolutivas, que piensan que el anlisis y diseo estructurados

constituyen la base para el desarrollo orientado al objeto, pudindose combinar
elementos del anlisis y diseo estructurados con los de la orientacin al objeto.
Ejemplos de este tipo podran ser OMT [Rumbaugh et al., 1991], SYNTHESIS
[Bailin, 1989] o [Martin y Odell, 1992].
ltimamente estn apareciendo nuevas metodologas de desarrollo orientado al objeto,

catalogadas como de segunda generacin, basadas en las citadas anteriormente; de las
que formaran parte [Singer, 1993], FUSION propuesta por [Coleman et al., 1994],
OOA/D de [Booch, 1994], MOSES de [Henderson-Sellers y Edwards, 1994],
SYNTROPY de [Cook y Daniels, 1994], MTODO UNIFICADO [Booch y
Rumbaugh, 1995] o MEDEA [Piattini, 1994]. En esta segunda generacin se
aprovechan las tcnicas y los procedimientos de las primeras metodologas,
especialmente las tarjetas de clase (CRCs), el proceso y notacin de diseo de [Booch,
1991], el modelo de clases de OMT y los escenarios de Jacobson, con el fin de construir
metodologas ms completas y sistemticas en las que juegan tambin un papel
relevante las mtricas y los lenguajes formales, as como modelos para la mejora del
software, como los del SEI (CMM) o ISO (SPICE).
Pg. 6.
Otra posible clasificacin, en funcin de en qu se centran, es:
Metodologas dirigidas por los datos (data-driven)

-
OMT (Rumbaugh et al. 1991)
FUSION (Coleman et al. 1994)
Metodologas dirigidas por las responsabilidades (responsability-driven)

-
RDD (Wirfs-Brock et al. 1990)
OBA (Rubin y Goldberg 1992)
Metodologas dirigidas por los casos de uso (use case-driven)

-
OOSE (Jacobson et al. 1992)

Metodologas dirigidas por estados (state-driven)
Metodologa de Shlaer y Mellor 1992)
Pg. 7.
El mtodo de BOOCH
Introduccin.
El mtodo de Grady Booch es uno de los ms conocidos en la orientacin al objeto.
En su versin de 1.993 este mtodo cubre las fases de anlisis y diseo dentro de un
desarrollo orientado al objeto.
Se definirn una gran cantidad de smbolos para representar las distintas decisiones de
diseo.
Este mtodo ofrece una gran libertad en la produccin del software, como ya veremos
ms adelante.
En un primer momento se explicarn una serie de conceptos bsicos, los cuales han de
quedar claros para poder comprender a fondo la metodologa de Booch.
Dichos conceptos se pueden estructurar estructurarlos de la siguiente manera:
Complejidad.
El modelo del objeto.
Clases y objetos.
Clasificacin.
La complejidad
El software, por lo general, va a ser un sistema complejo, sobre todo cuando se trate
de un software grande. Esto es debido a 4 elementos:
La complejidad del dominio del problema. (Definicin de los requisitos,
modificaciones que pueden ir sufriendo stos...)
La dificultad de gestionar el proceso de desarrollo. (Sobre todo en proyectos
muy grandes.)
La flexibilidad que posibilita el software.
Los problemas del comportamiento de sistemas discretos.
Para tratar un sistema complejo se pueden utilizar las siguientes tcnicas:
Descomposicin: consiste en dividir el sistema en partes ms y ms pequeas cada vez,
pudiendo ser stas refinadas independientemente.
Abstraccin: la abstraccin denota las caractersticas esenciales de un objeto que lo
distinguen de todos los dems tipos de objetos y proporciona as fronteras conceptuales
ntidamente definidas respecto a la perspectiva del observador.
Jerarqua: para Booch la jerarqua es una clasificacin u ordenacin de abstracciones.
Existen dos clases de jerarqua:
Pg. 8.

jerarqua parte de (part of) o tiene un (has a): corresponde a la estructura del
objeto.
jerarqua es un (is a): corresponde a la estructura de la clase.
El modelo del objeto

La programacin orientada a objetos es un mtodo en el que los programas se organizan
como una coleccin de objetos, representando cada uno una instancia de alguna clase,
estando relacionadas todas las clases mediante una jerarqua.
Un programa que no tenga bien claros estos 3 elementos (que se tengan objetos en lugar
de algoritmos, que cada objeto sea instancia de alguna clase, y que entre las clases
exista una relacin de herencia que de lugar a una jerarqua) no puede considerarse
orientado a objetos. Booch lo llama programacin con tipos de datos abstractos.
Se estudiarn las fases de anlisis y diseo en la orientacin al objeto. El anlisis se
realizar a partir del dominio inicial del problema. A continuacin vendr el diseo.
Elementos del modelo de objetos
Hay 4 elementos bsicos que constituyen dicho modelo:
Abstraccin.
Encapsulamiento.
Modularidad.
Jerarqua.
Hay otros elementos (no principales) que son los siguientes:
Tipos.
Concurrencia.
Persistencia.
La abstraccin.
La abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de
todos los dems tipos de objetos y proporciona as fronteras conceptuales ntidamente
definidas respecto a la perspectiva del observador.
Existen varios tipos de abstraccin:
Abstraccin de entidad: un objeto que representa un modelo til del problema de
dominio de la entidad.
Abstraccin de accin: un objeto proporciona un conjunto generalizado de operaciones
para una determinada funcin.
Abstraccin de la mquina virtual: un objeto que agrupa funcionamientos que son
utilizados por niveles superiores de control, y por conjuntos de operaciones de niveles
inferiores.
Abstraccin coincidental: un objeto que agrupa un conjunto de operaciones que no estn
relacionadas con ninguna otra.
El encapsulamiento.
Pg. 9.
Es el proceso de almacenar en un mismo compartimento los elementos de una

abstraccin que constituyen su estructura y su comportamiento; sirve para separar la
interfaz contractual de una abstraccin y su implantacin. (El encapsulamiento oculta
los detalles de la implementacin de un objeto).
La modularidad.
Cuando se habla de modularidad hay que imaginarse la fragmentacin de un programa
en componentes individuales para reducir la complejidad. Booch define modularidad
como la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de
mdulos cohesivos y dbilmente acoplados.
Existen varias tcnicas para poder obtener una modularidad correcta o inteligente en
nuestras clases y objetos:
La reduccin de los costes del software viene apoyada por la descomposicin en
mdulos, ya que stos pueden disearse y revisarse independientemente.
La estructura de cada modulo debe ser lo suficientemente simple como para que
pueda entenderse completamente.
Debe ser posible modificar la implementacin de un mdulo sin tener conocimiento
de la implementacin de otros mdulos, y sin que se afecte al comportamiento de
otros mdulos.
La facilidad de realizar un cambio en el diseo debera estar relacionada con la
necesidad de ese cambio.
La identificacin de clases y objetos se corresponde con el diseo lgico del sistema. La
identificacin de mdulos es parte del diseo fsico del sistema. No se pueden tomar
todas las decisiones fsicas antes que las lgicas o viceversa. Ms bien, se suelen ir
tomando a la vez.
La jerarqua.
Para Booch la jerarqua es una clasificacin u ordenacin de abstracciones. Las 2
jerarquas ms importantes en un sistema complejo son la estructura de la clase (es un) y
la estructura del objeto (parte de) o (tiene un).
La herencia es el ejemplo ms importante de jerarqua (es un), ya que va a definir las
relaciones entre clases, tanto en el caso de herencia simple como en el caso de herencia
mltiple.
Cuando se habla de jerarqua (es un) normalmente se refiriere a generalizacin /
especializacin. Sin embargo (parte de) es ms bien un caso de agregacin. La
combinacin de la herencia y la agregacin puede ser muy potente: la agregacin
permite el agrupamiento fsico de las estructuras lgicas, y la jerarqua permite a estos
grupos su funcionamiento en diferentes niveles de abstraccin.
Los tipos.
Son la puesta en vigor de la clase de los objetos, de modo que los objetos de tipos
distintos no pueden intercambiarse o, como mucho, pueden intercambiarse slo de
formas muy restringidas.
Existen varias comprobaciones de tipos:
Pg. 10.
Comprobacin estricta: un objeto slo pude realizar aquellas operaciones que se

encuentran definidas en la clase o en la superclase del objeto. Se comprueba en tiempo
de compilacin.
Comprobacin dbil: un cliente puede mandar un mensaje a cualquier clase. No se
detectar hasta el momento de la ejecucin.
La comprobacin estricta de tipos toma especial relevancia en las decisiones de diseo
cuando la complejidad de nuestro sistema aumenta considerablemente.
Estos conceptos se hallan relacionados con los de ligadura esttica y ligadura
dinmica; sta ltima constituye la base del polimorfismo.
La concurrencia.
Se produce cuando se tienen varios procesos que se ejecutan a la vez en un sistema. En
la programacin orientada a objetos la concurrencia permitir a diferentes objetos actuar
simultneamente. Booch define concurrencia como: la propiedad que distingue un
objeto activo de uno que no est activo.
La persistencia.
Es la propiedad de un objeto por la que su existencia transciende el tiempo (es decir, el
objeto contina existiendo despus de que su creador deja de existir) y /o el espacio (es
decir, la posicin del objeto vara con respecto al espacio de direcciones en el que fue
creado). Dicho de otra manera, la persistencia conserva el estado de un objeto en el
tiempo y en el espacio.
El espectro de persistencia abarcar lo siguiente:
Resultados transitorios en la evaluacin de expresiones.
Variables locales en la activacin de procedimientos.
Variables globales y elementos del heap cuya duracin difiere de su mbito.
Datos que existen entre ejecuciones de un programa.
Datos que existen entre varias versiones de un programa.
Datos que sobrevienen al programa.
Clases y objetos
La naturaleza de un objeto
Un objeto tiene estado, comportamiento e identidad; la estructura y el comportamiento
de objetos similares estn definidos en su clase comn; los trminos instancia y objeto
son intercambiables.
Se explican a continuacin cada una de las partes de esta definicin:
Un objeto tiene estado: el estado de un objeto abarca todas las propiedades

(normalmente estticas) del mismo ms los valores actuales (normalmente
dinmicos) de cada una de esas propiedades.
Pg. 11.
Un objeto tiene comportamiento: el comportamiento de un objeto es cmo acta

y se relaciona, en funcin de sus cambios de estado y paso de mensajes. El
estado del objeto representar los resultados acumulados de su comportamiento.
Por ejemplo, un cliente puede realizar una serie de operaciones sobre un
objeto: modificar (alterar el estado del objeto), seleccionar (acceder al
estado de un objeto sin alterarlo), iterar (acceder a todas las partes de un
objeto en algn orden establecido), construir (crear un objeto e iniciar su
estado) y destruir (liberar el estado del objeto y destruir el objeto).
Un objeto tiene identidad: la identidad ser aquella propiedad que lo distingue

de todos los dems objetos. No es conveniente que la identificacin la llevan a
cabo los nombre de las entidades, ya que: una entidad puede no tener un nombre
nico y sin embargo ser identificable, puede tener ms de un nombre nico,
puede cambiar de nombre a lo largo del tiempo...
Las responsabilidades de un objeto son todos los servicios que proporciona a quien se
relacione con l.
Pero hay que constatar que un objeto puede tener diferentes roles o papeles, que han de
definirse en la fase de diseo.
Igualdad de objetos: cuando hablamos de igualdad puede significar que dos nombres
designan el mismo objeto, o que dos nombres designan objetos distintos cuyos estados
son iguales.
Se puede considerar que en un ciclo de vida habr un primer momento de
declaracin del objeto y luego vendr la asignacin o instanciacin del mismo.
Relaciones entre los objetos
Los objetos se relacionan unos con otros para colaborar entre s y con el sistema.
Existen 2 tipos de relaciones: enlaces y agregaciones.
Enlaces.
Un enlace es una conexin fsica o conceptual entre objetos. A travs del enlace un
objeto cliente puede solicitar servicios a un objeto proveedor, bien directamente o bien a
travs de enlaces con otros objetos.
Un objeto puede desempear cualquiera de estos 3 papeles:
Actor: cuando puede operar sobre otros objetos pero ningn objeto opera sobre l.
Servidor: otros objetos actan sobre l mientras que l no hace peticiones al resto.
Agente: puede operar sobre otros y tambin otros objetos pueden operar sobre l.
Agregaciones.
Si los enlaces denotan una relacin cliente - servidor, la agregacin denotar una
jerarqua de partes de un todo. Esas partes pueden ser fsicas (Ej. partes de un avin) o
no fsicas (Ej. acciones de un accionista).
La agregacin a veces es mejor, porque encapsula partes como secretos de un todo. Los
enlaces son ptimos en algunas ocasiones ya que permiten un acoplamiento ms dbil
entre los objetos.
Pg. 12.
La naturaleza de una clase

Booch define clase como un juego de objetos que comparten una estructura comn y
un comportamiento comn. La clase es un medio necesario pero no suficiente para la
descomposicin.
La interfaz de una clase suministra su vista externa y recalca la abstraccin, mientras
que oculta su estructura y los secretos de su comportamiento.
Dicha interfaz puede estar dividida en 3 partes:
Pblica: una declaracin que es accesible a todos los clientes.
Protegida: una declaracin que es accesible a la clase, a las subclases y a las clases
amigas.
Privada: una declaracin que a la que slo acceden la propia clase y las clases
amigas.
Relaciones entre las clases
Hay 3 tipos bsicos de relaciones:
Generalizacin / especializacin.
Todo / partes.
Asociacin.
Dichas relaciones pueden obtenerse como combinacin de algunas de estas otras:
asociacin, herencia, agregacin, uso, instanciacin, metaclases...
La asociacin.
Una asociacin describe un grupo de enlaces con una estructura y una semntica en
comn.
La herencia.
La herencia, para Booch, es una relacin entre clases, en la que una clase comparte la
estructura o comportamiento definido en otra (herencia simple) u otras (herencia
mltiple) clases.
La herencia define una relacin de tipo entre clases en la que una subclase hereda de
una o ms superclases generalizadas; una subclase suele especializar a sus superclases
aumentando o redefiniendo la estructura y comportamiento existentes.
El polimorfismo.
Booch lo define como concepto de la teora de tipos, de acuerdo con el cual un nombre
(como una declaracin de una variable) puede denotar objetos de muchas clases
diferentes que se relacionan mediante alguna superclase comn; as todo objeto
denotado por este nombre es capaz de responder a algn conjunto comn de
operaciones de diferentes modos.
El polimorfismo es muy til cuando hay muchas clases con los mismos protocolos.
Cada objeto conoce su propio tipo.
La agregacin.
Pg. 13.
El concepto de agregacin entre clases es equivalente al explicado para la relacin entre

objetos.
El uso.
Una relacin de uso es posiblemente una abstraccin en la cual aseguramos quin es el
cliente y quin es el proveedor de un cierto servicio.
La instanciacin.
La instanciacin se refiere al hecho de ir creando las instancias de las clases.
Aqu hay que destacar tambin el concepto de clase parametrizada, como plantilla de
otras clases.
Las metaclases.
Una metaclase es una clase cuyas instancias son a su vez clases.
La interaccin de Clases y objetos
Durante la fase de anlisis hay dos tareas principales:
Identificar las clases y objetos que forman el vocabulario del dominio del
problema. (Esas clases y objetos se llaman key abstractions).
Inventar estructuras en las que los objetos trabajen juntos para proporcionar un
modelo de comportamiento que satisfaga los requisitos del problema.
Durante estas fases del proceso, no hay que centrarse en esas abstracciones importantes
y mecanismos. Esta vista representa el armazn lgico del sistema, y por consiguiente
abarca la estructura de la clase y estructura del objeto del sistema.
En fases posteriores, y pasando entonces a la implementacin, el enfoque est en la vista
interior de estas abstracciones importantes y mecanismos. Estas decisiones de diseo se
explican como parte de la arquitectura del mdulo del sistema y arquitectura del
proceso.
Construccin de Clases y Objetos de Calidad
Para medir la calidad de una abstraccin se tiene lo siguiente:
El acoplamiento: es la medida de la fuerza de una asociacin establecida por una
conexin entre clases.
La cohesin: mide el grado de conectividad entre los elementos de una clase o
de un objeto.
Suficiencia: significa que la clase capture bastantes caractersticas de la
abstraccin para permitir interaccin significante y eficaz.
Completeness: una interfaz completa es aquella que cubre todos los aspectos
de la abstraccin.
Primitiveness: desde que muchas operaciones de alto nivel estn compuestas
por operaciones de bajo nivel, se sugiere que esas clases sean primitivas.
Es muy frecuente que sobre el primer anlisis efectuado sobre las clases se haga
necesario modificar y refinar las interfaces, e incluso a veces se llega a la creacin de
Pg. 14.
nuevas clases o a una reorganizacin de las relaciones existentes entre las que ya
existen.
Es importante conocer el concepto de Visibilidad ya que la metdologa de Fusion se
va a apoyar en l. Durante la fase de diseo conviene especificar cmo un objeto es
visible por otro objeto. Hay 4 formas diferentes de que esto se produzca.
El objeto servidor es global para el cliente.
El objeto servidor es un parmetro de alguna operacin del cliente.
El objeto servidor es una parte del cliente.
El objeto servidor est localmente declarado en el alcance del diagrama de
objetos.
Clasificacin
La clasificacin va a ser fundamentalmente una cuestin de igualdad que ayudar a
identificar las jerarquas de generalizacin, especializacin y agregacin entre clases.
Tambin ayuda a la toma de decisiones sobre la modularizacin.
Es difcil llevar a cabo una buena clasificacin ya que no existe una clasificacin
perfecta. Cualquier clasificacin es relativa al punto de vista de su autor. Por otra
parte, una buena clasificacin requiere una gran creatividad e ingenio.
Aproximacin a las clasificaciones
Se hacen tres divisiones:
Categorizacin clsica: todas las entidades que tienen una propiedad o un conjunto
de propiedades en comn forman una categora. Esas propiedades han de ser
necesarias y suficientes para constituir dicha categora. Ej. Una persona est casada
o no casada.
Concptual clustering: las clases se generan a partir de unas descripciones
conceptuales previas acerca de las mismas; posteriormente se clasifican las
entidades de acuerdo con la descripcin.
Teora del prototipo: Una clase de objetos es representada por un objeto prototipo, y
un objeto ser considerado miembro de la clase si y slo si se parece al prototipo de
manera significativa.
En el primer caso hay que centrarse en las estructuras, en el segundo en la colaboracin
de objetos, mientras que en el tercero se considera que el objeto est definido de
acuerdo con una serie de caractersticas del objeto prototipo.
Procedimientos para encontrar clases y objetos
Booch define las fases de anlisis y diseo como sigue:
Anlisis: se va a modelar descubriendo las clases y objetos que forman el
vocabulario de dominio del problema.
Diseo: se inventarn las abstracciones y los mecanismos necesarios para conseguir
el comportamiento que exige el modelo establecido en la fase de anlisis.
Pg. 15.
Existen unos cuantos mtodos para el anlisis de sistemas en orientacin al objeto:

Acercamientos clsicos: las clases y los objetos se derivan de los requisitos del
problema.
Anlisis de comportamiento: se basa en el comportamiento dinmico existente entre
clases y objetos. Se constituirn clases basadas en grupos de objetos que exhiban un
comportamiento similar. Se formarn jerarquas de clases y subclases de acuerdo con
unas responsabilidades que poseen todos los elementos de un mismo grupo.
Anlisis de dominio: se define como un intento de identificar los objetos, las
operaciones y las relaciones, que los expertos del dominio consideran importante acerca
del dominio.
Casos de uso: un caso de uso es una forma o patrn o ejemplo concreto de utilizacin,
un escenario que comienza con algn usuario del sistema que inicia alguna transaccin
o secuencia de eventos interrelacionados. Pueden utilizarse en el anlisis de requisitos
de la siguiente manera:
Se enumeran los escenarios principales del sistema.
Se realiza un estudio de cada escenario.
A medida que se pasa por cada escenario se van identificando los objetos que
participan en l, las responsabilidades de cada objeto, y la forma en que los
objetos colaboran.
Tarjetas de clase: consiste en elaborar por cada clase una tarjeta en la que se anotan: el
nombre de la clase, sus superclases y subclases, sus responsabilidades y sus
colaboraciones.
El mtodo
En la metodooga de Booch se explica qu hay que hacer para definir el sistema, pero
no se da ninguna prescripcin para mejorar las fases de anlisis y diseo del sistema.
Eso puede ser visto como una ventaja por parte de aquellos que prefieren disponer de
una mayor libertad a la hora de producir software, y como una debilidad para aquellos
que no dispongan de mucha experiencia y expertos en la orientacin al objeto.
Booch propone varias formas de describir un sistema en orientacin al objeto. El
modelo lgico, por ejemplo, se representa bajo la estructura de clases y objetos.
Mientras que el diagrama de clases es ms bien esttico, el diagrama de objetos muestra
el comportamiento dinmico del sistema
Pg. 16.
Figura 1. Esquema del mtodo de Booch.
Diagramas de clases
Un diagrama de clases muestra las relaciones entre las abstracciones de un sistema
(vista lgica).
En el diagrama se pueden representar todas o parte de las estructuras de clases de un
sistema, esto es:
Clase: es la unidad modular de la descomposicin software orientada al objeto. Una
clase representa un conjunto de elementos u objetos que comparten la misma estructura
y un comportamiento comn. El comportamiento dinmico de una clase puede
describirse gracias a su diagrama de transicin de estados.
Pg. 17.
Figura 2. Notacin de clase" en Booch.

Clase Utilidad: constituida por una coleccin de subprogramas libres y declarada como
parte de una clase que no tiene estado. (Aunque se puede decir que todos los mtodos
son operaciones, no todas las operaciones son mtodos).
Figura 3. Notacin de clase utilidad en Booch.

Clase Parametrizada: clase que sirve como plantilla para otras clases. Dicha plantilla
puede contener parmetros de otras clases, objetos y/o operaciones. Normalmente las
clases parametrizadas se utilizan como clases contenedoras. Los trminos clase
genrica y clase parametrizada suelen ser intercambiables.
Figura 4. Notacin de clase parametrizada en Booch.
Pg. 18.
Categoras de clase: coleccin lgica de clases, algunas de las cuales son visibles a otras
categoras de clase mientras que otras estn ocultas. La mayora de los lenguajes de
programacin en la orientacin al objeto no soportan las categoras de clase.
Figura 5. Notacin de categoras de clase en Booch.

Atributos: un atributo de la clase describe una informacin singular guardada en cada
caso. Puede ser muy til exponer algunos de los atributos relacionados con una clase.
Mtodos: los mtodos especifican que un determinado algoritmo ser aplicado a alguna
instancia de la clase. Pueden dividirse en funciones y procedimientos, dependiendo de si
devuelven un resultado o no.
Adornos y propiedades: son piezas secundarias de informacin sobre alguna entidad en
el modelo del sistema. Se representan mediante una letra dentro de un tringulo. Las
relaciones tambin pueden poseerlos; en C++ hay 3 propiedades:
1.esttica: la designacin de un miembro de la clase: objeto o funcin.
2.virtual: la designacin de una clase compartida en una estructura de herencia.
3.amiga: la designacin del acceso concedido a las partes no pblicas de una clase.
Figura 6. Notacin de adornos y propiedades en Booch.

Control de exportacin (para atributos, operaciones y relaciones): los miembros pueden
ser pblicos (accesibles para todos los clientes), protegidos (accesibles slo a subclases,
amigos o a la propia clase), o privado (accesible a l y sus amigos).
Pg. 19.
Figura 7. Notacin del control de la exportacin en Booch.
Relaciones entre clases.

Las clases colaboran entre s de diversas formas. Las conexiones esenciales entre clases
son:
Asociacin: que tendr en cuenta una serie de aspectos: valor clave, restricciones,
cardinalidad, papel que desempea, etiqueta...
Figura 8. Notacin de asociacin entre clases en Booch.

Herencia: define una relacin entre clases donde una clase comparte la estructura o el
comportamiento definido en otra u otras clases. La herencia representa una jerarqua de
abstracciones donde una subclase hereda de una o ms superclases.
La notacin consiste en una flecha que apunta de la subclase a la superclase.
Figura 9. Notacin de Herencia en Booch.
Agregacin: o relacin todo/parte; aparece como una asociacin con un crculo relleno
que indica la agregacin.
Se puede encontrar agregacin por valor:
Figura 10. Notacin de Agregacin por valor en Booch.

Pg. 20.
Y agregacin por referencia:
Figura 11. Notacin de Agregacin por referencia en Booch.
Uso: el proveedor proporciona ciertos servicios (ver el apartado diagramas de objetos

para averiguar cmo se ven los objetos entre ellos).
Figura 12. Notacin de Uso en Booch.
Instanciaciones:
Figura 13. Notacin de instanciaciones en Booch.
Metaclases:
Figura 14. Notacin de metaclases en Booch.
Diagramas de objetos
Los diagramas de objetos son parte de la notacin del diseo orientado a objetos.
Muestran todos o algunos objetos junto a sus relaciones en el modelo lgico del sistema.
Pueden usarse para ver su ejecucin en diferentes escenarios.
En un diagrama de objetos se puede tener:
Pg. 21.
Objetos: un objeto es algo que puede hacer cosas; tiene estado, comportamiento e
identidad. La estructura y el comportamiento de los objetos similares se definen en su
clase comn. Un objeto es una instancia de una clase.
Figura 15. Notacin de Objeto en Booch.

Enlace de objetos: este trmino deriva de Rumbaugh, quien lo define como conexin
fsica o conceptual entre objetos. Muestra la asociacin entre un objeto Cliente que
solicita una serie de servicios de un objeto Servidor, y la direccin seguida por los
mensajes intercambiados entre los objetos.
Un objeto que participe de un enlace puede desempear uno de estos papeles:
Actor: opera en otros objetos, pero nadie opera sobre l.
Servidor: no opera en otros objetos, sino que operan otros en l.
Agente: opera sobre l mismo, y tambin otros pueden hacerlo sobre l.
Figura 16. Notacin de Enlace de objetos en Booch.
Sincronizacin de enlaces (para objetos actores): ante mltiples tcnicas de control un

objeto requiere ms que eso para tratar los problemas de exclusiones mutuas y
conflictos que puedan presentarse. Los objetos actores tienen sus propios mtodos de
control, pero con servidores se ha de escoger entre una de las siguientes
aproximaciones:
Secuencial: un objeto activo en un instante.
Guarded: los clientes activos deben colaborar para conseguir la exclusin mutua.
Synchronous: el servidor garantiza la exclusin mutua.
Los mensajes se adornan utilizando la siguiente notacin:
Pg. 22.
Figura 17. Notacin de sincronizacin de enlaces en Booch.

Visibilidad de enlaces: los diagramas de clases muestran las dependencias existentes
entre las clases de varios objetos. Pero no dictaminan cmo se ven esas instancias, entre
ellas. Pro ello es posible adornar enlaces que representen la visibilidad del servidor
desde el punto de vista del cliente.
Figura 18. Notacin de visibilidad de enlaces en Booch.
Otros diagramas
Diagrama de transicin de estados:
Se utiliza para mostrar el espacio de estados de una determinada clase, los eventos
(mensajes) que disparan una transicin de un estado a otro y las acciones que resultan
del cambio de estado.
La notacin empleada es la siguiente: un nico nombre para cada estado (que puede
incluir acciones asociadas), flechas dirigidas para conectar los diferentes estados...
Figura 19. Notacin de estado en Booch.
Pg. 23.
Una transicin conecta dos estados y tiene que haber un estado inicial en el diagrama.
Figura 20. Diagrama de transicin de estados en Booch.
Diagrama de Mdulos:
Se utiliza para mostrar la colocacin de las clases y objetos en los mdulos en el diseo
fsico de un sistema. Indica la divisin de la arquitectura del sistema.
Los dos elementos esenciales del diagrama son: los mdulos y sus dependencias.
Un subsistema puede tener dependencias en otros subsistemas o mdulos, y un mdulo
puede tener dependencias en un subsistema. La misma anotacin se usa para las
dependencias de los subsistemas.
Figura 21. Diagrama de mdulos en Booch.
Diagrama de procesos:
Se usan para mostrar la asignacin de procesos a los procesadores en un diseo fsico
del sistema. A travs de los diagramas se indica la coleccin de procesadores y
dispositivos que sirven como plataforma para ejecutar el sistema.
Pg. 24.
Hay 3 elementos esenciales: procesadores, dispositivos y sus conexiones.
Figura 22. Diagrama de procesos en Booch.
Diagrama de interaccin:
Traza la ejecucin de un escenario en el mismo contexto que un diagrama de objetos.
Permite leer el paso de mensajes de unos objetos a otros en perfecto orden.
Los objetos se colocan horizontalmente en la parte superior y se trazan unas lneas
verticales. Los mensajes se representan horizontalmente con flechas que van desde el
cliente al servidor. La caja vertical representa el tiempo en el que el control est sobre
dicho objeto.
Figura 23. Diagrama de interaccin en Booch.
Pg. 25.
Los procesos del desarrollo orientado al objeto

Booch soporta el desarrollo iterativo e incremental.
Define dos tipos de procesos para describir los niveles en un desarrollo orientado al
objeto.
Macro procesos.
Establecimiento de los requisitos principales (conceptualizacin).
Desarrollo de un modelo de comportamiento deseado (anlisis).
Creacin de una arquitectura (diseo).
Evolucin de la implementacin (evolucin).
Mantenimiento.
Micro procesos.
Identificacin de las clases y de los objetos en un nivel de abstraccin dado.
Identificacin de la semntica de dichas clases y objetos.
Identificacin de las relaciones entre estas clases y objetos.
Especificar las interfaces y despus la implementacin de estas clases.
Conclusin
La metodologa de Booch es muy poco rgida y ofrece gran libertad al usuario de la
misma, lo cual, como ya se ha dicho, trae consigo una serie de ventajas e
inconvenientes.
A partir de todos los conceptos que conforman el modelo de objetos para Booch y de la
notacin que ofrece, el usuario ser el nico responsable de identificar las fases de
anlisis y diseo del sistema. Siempre que se respete esa notacin y que los resultados
obtenidos sean coherentes con los conceptos anteriormente explicados podr
considerarse que el anlisis y el diseo se han llevado a cabo correctamente.
Un ejemplo concreto
Segn Booch, una posible forma (que no tiene por qu ser la mejor) de desarrollar las
fases de anlisis y diseo de un sistema informtico de Adquisicin de datos: estacin
de monitorizacion del clima, podra ser:
Fase de anlisis:
Definicin de los lmites del problema. (Servicios que proporcionar el sistema).
Especificacin detallada de las necesidades del soporte hardware.
Realizacin del diagrama de procesos del sistema.
Ciclo de vida de algn objeto.
Pg. 26.

Jerarqua de clases. (Clase sensor).

Diagramas de interaccin. (Temporizador).
Escenarios.
Diagrama de transicin de estados. (GestorEntrada).
Fase de diseo:
Escoger el marco de referencia arquitectnica.
Creacin de nuevas clases cuya creacin se ha visto necesaria.
Se empiezan a definir internamente las clases.
Pg. 27.
OMT (Object Modeling Tecnique) James Rambaugh

Visin general
Es una metodologa orientada a objeto muy difundida, de hecho es la que actualmente
ms se est utilizando por encima incluso de la de Booch. Se desarroll en el Research
and Development Center de General Electric a finales de los 80. Se hace cargo de todo
el ciclo de vida del software, y durante ese tiempo mantiene la misma notacin. Se
divide en cuatro fases consecutivas. Tiene una parte de diseo no muy compleja. Se
centra mucho en un buen anlisis. Es de las denominadas dirigidas por los datos.
Fases (4)
1. Anlisis de objetos:
Se describe el problema: Se obtienen unos requisitos que no den lugar a dudas
(rendimiento, funcionalidad, contexto,...). En toda la fase de anlisis se describe el
comportamiento del sistema como una caja negra.
Se hacen los diagramas de objetos con su diccionario de datos. As obtengo el modelo
de objetos. En l se define su la estructura de los objetos y clases as como las
relaciones que les unen. Comprende tanto un Diagrama de Clases como un Diccionario
de Datos que las explique. Este modelo debe ser refinado por medio de la iteracin.
Creacin de un modelo dinmico para describir los aspectos de control y evolucin del
sistema. Incluye un Diagrama de Eventos del sistema y un Diagrama de Estado por cada
clase que tenga un comportamiento dinmico.
Creacin de un modelo funcional que describa las funciones, los valores de entrada y
salida, e imponga las restricciones pertinentes. Se suelen utilizar Diagramas de Flujo de
Datos (DFDs).
Se verifican todos los modelos creados.
Se itera para conseguir un refinamiento de los 3 modelos.
2. Diseo del sistema: Comprende la arquitectura bsica. En esta fase se tomarn las
decisiones estratgicas (a alto nivel) de diseo (estructura global del sistema).
3. Diseo de objetos: Es el ltimo paso antes de implementar, y sirve para definir
completamente todas las caractersticas de los objetos. Se detallan los 3 modelos ya
descritos en el anlisis de objetos de cara a poder implementarlo, y optimizar el
programa (acceso a datos, iteraciones, control, recursos,...). Todo esto ha de hacerse
con independencia del lenguaje o entorno en que finalmente codifiquemos y
ejecutemos la aplicacin.
4. Implementacin: Se codifica lo ya diseado.
Pg. 28.
Pasos especficos a dar en cada fase

Fase De Anlisis
1.Obtener y escribir una descripcin inicial del problema.
2.Construir un modelo de objetos:
- Identificar las clases (y objetos).
- Comenzar a crear un diccionario de datos que contenga descripciones de las
clases, sus atributos y sus asociaciones.
- Aadir las asociaciones (y agregaciones) entre las clases.
- Aadir los atributos de los objetos y sus uniones.
- Organizar y simplificar las clases usando herencias.
- Probar que los accesos son correctos, usando escenarios e iterando los pasos
siguientes como sea necesario.
- Agrupar las clases en mdulos, basndose en su proximidad y funcin.
3.Construir un modelo dinmico:
- Preparar los escenarios para las secuencias de interaccin tpicas entre los
usuarios y el sistema.
- Identificar los eventos que se dan entre objetos y preparar una traza de
eventos para cada escenario.
- Preparar un DTE para el sistema, y una traza de eventos para cada escenario.
- Construir un diagrama de estado para cada clase que tenga un marcado
comportamiento dinmico.
- Chequear la consistencia (y que estn todos) de los eventos que aparecen en
los diagramas.
4.Contruir un modelo funcional: (*)
- Identificar los valores de entrada y de salida.
- Usar DFDs cuando sea necesario para mostrar las dependencias funcionales.
- Describir qu hace cada funcin.
- Identificar las restricciones.
- Especificar criterios de optimizacin.
(*) Este modelo ha sido bastante criticado, por no seguir los principios del AOO.
Desde 1995 se recomienda que este modelo consista en una descripcin
detallada de las operaciones del sistema, y solo usa DFDOO cuando estas
operaciones impliquen a varios objetos. Conviene, para cada operacin
especificar las siguientes cosas: Nombre, Responsabilidades, Entradas, Salidas,
Objetos modificados, Precondiciones y Postcondiciones.
5.Verificar, iterar y refinar los tres modelos:
- Aadir las operaciones claves que fueron descubiertas durante la preparacin
del modelo funcional al modelo de objetos. No mostrar todas las operaciones
durante el anlisis, slo mostrar las ms importantes.
Pg. 29.
Verificar que las clases, asociaciones, atributos y operaciones son

consistentes y completas al nivel elegido de abstraccin. Compara los tres
modelos con la definicin del problema y probar los modelos mediante el
uso de escenarios.
Desarrollar escenarios ms detallados (incluyendo condiciones que den
errores) como variaciones de los escenarios bsicos. Usar estos escenarios
y si... para verificar en el futuro los tres modelos.
Iterar los pasos anteriores cuanto sea necesario para completar el anlisis.
Fase De Diseo Del Sistema

1. Organizar el sistema en subsistemas (conjunto de capas horizontales).
2. Identificar la concurrencia inherente al problema.
3. Colocar los susbsistemas a sus procesos y tareas. Aqu han de asignarse recursos de la
mquina a los distintos subsitemas (memoria, procesador, ficheros...).
4. Elegir la estrategia bsica para almacenar los datos; tipos abstractos de datos,
estructuras, ficheros y bases de datos.
5. Identificar los recursos globales y determinar mecanismos de control de acceso a
ellos.
6. Elegir un mtodo de implementacin del control de software. Existen 3 tipos de
control destacados: Por programa (sistemas dirigidos por procedimientos; C++), Por
planificador del entorno (sistemas dirigidos por eventos; X-Windows) o Concurrente
(sistemas concurrentes; Ada). Esto se puede implementar de las siguientes maneras:
- Usar el programa como un estado fijo, o
- Directamente implementar un autmata de estados, o
- Usar tareas de concurrencia.
7. Considerar las condiciones lmite.
8. Establecer las prioridades.
Fase de Diseo De Objetos
1. Obtener operaciones para el modelo de objetos a partir de los otros modelos:
- Encontrar una operacin para cada proceso del modelo funcional.
- Definir una operacin por cada evento del modelo dinmico, dependiendo de
la implementacin del control.
2. Disear algoritmos para implementar operaciones:
- Elegir algoritmos que minimicen el coste de implementar las operaciones.
- Elegir estructuras de datos apropiadas a los algoritmos.
- Definir nuevas clases internas y operaciones como sea necesario.
- Asignar responsabilidades para operaciones que no han sido claramente
asociadas a una sola clase.
3. Optimizar los accesos a datos:
Pg. 30.
Aadir asociaciones redundantes para minimizar el coste de acceso y

maximizar la conveniencias.
Reajustar los procesos computacionales para lograr una mayor efectividad.
Almacenar los valores derivados para evitar los clculos repetidos.
4. Implementar el control software mediante el sistema elegido durante el diseo del

sistema.
5. Ajustar las estructuras de las clases para aumentar la herencia.
- Reajuste de clases y sus operaciones para aumentar la herencia.
- Extraer el comportamiento abstracto comn de grupos de clases.
- Delegar para poder compartir comportamientos cuando la herencia sea
semnticamente invlida.
6. Diseo de la implementacin de las asociaciones:
- Analizar las asociaciones transversales.
- Implementar cada asociacin como si fuera un objeto distinto o aadiendo el
valor de los objetos como atributos de una o ambas clases de la asociacin.
7. Determinar la representacin exacta de los atributos de los objetos.
8. Compactar las clases y asociaciones en mdulos, ocultando en la parte privada toda la
informacin que deba estar oculta.
Implementacin
No se detiene en ella (al igual que la fase de pruebas), con lo que se queda a la eleccin
del programador.
Conclusin
Una de las grandes virtudes de OMT es su modelo de objetos, que contiene una enorme
riqueza semntica, por lo que ha sido adaptado por casi todas las metodologas de
segunda generacin, y es una de las bases metodolgicas de la metodologa Objetory
que en breve aparecer (de la mano de los 3 amigos: Rambaugh, Booch y Jacobson)
para completar a UML.
OMT es una metodologa bastante slida (si exceptuamos su modelo funcional, bastante
criticado), que completado con otras tcnicas de representacin (CRCs, Casos de Uso...)
la hacen la metodologa ms difundida (tanto a nivel universitario como empresarial)
del momento.
Notacin
Todas las relaciones y diagramas han de respetar la siguiente notacin:
Pg. 31.
Figura 24. Notacin de OMT para el Modelo de Objetos
Pg. 32.
Mtodo de Fusion. Coleman

Introduccin
Fusion proporciona un mtodo de desarrollo de software orientado al objeto, que abarca
desde la definicin de requisitos a la implementacin en un lenguaje de programacin.
Es considerada como una metodologa de segunda generacin, porque proviene de:
OMT: modelo de objetos,
CRC: interaccin de objetos,
BOOCH: visibilidad,
Los mtodos Formales: pre- y postcondiciones.
Proporciona un proceso de desarrollo, que se divide en:

Anlisis, Diseo e Implementacin.1
Ofrece notaciones para los modelos, que describen varios aspectos del software.
Actualmente ha abandonado su notacin.
Proporciona herramientas de gestin.
Anlisis
El anlisis se basa ms en describir lo que hace un sistema en lugar de cmo lo hace.
Para esto, hay que ver el sistema desde la perspectiva del usuario en lugar de desde la de
la mquina. El anlisis casa con el dominio del problema y se preocupa por el
comportamiento visible externamente.
La meta de la fase de anlisis es capturar tantos requisitos del sistema como sea posible.
Se producen los siguientes modelos del sistema:
Modelo de objetos
Modelo de la interface
Modelo del funcionamiento,
Modelo del ciclo de vida.
Estos modelos describen:
Clases de objetos que existen en el sistema.2
Relaciones entre esas clases.
Operaciones que pueden realizarse en el sistema.
Secuencias permitidas de estas operaciones.
La entrada para la fase de anlisis es un documento de definicin de requisitos en
lenguaje natural.
Especifica el orden en el que deben hacerse las cosas dentro de cada fase. Tambin proporciona
criterios de cundo pasar a la siguiente fase.
2
En la fase del anlisis de Fusion, slo los atributos de una clase son considerados. Los mtodos son
considerados en la fase de diseo. Por consiguiente, en la fase del anlisis, los objetos son similares a las
entidades en el tradicional modelo entidad relacin.
Pg. 33.
Modelo de objetos
La finalidad del modelo de objetos en Fusion es:
capturar los conceptos que existen en el dominio del problema y las relaciones entre
ellos,
mostrar clases y sus relaciones, (no mostrar objetos)
El modelo de objetos representa:
la estructura esttica de la informacin en el sistema,
las clases y relaciones entre ellas,
atributos de clases,
agregacin,
especializacin/generalizacin.
Definiciones:
Un objeto es cualquier cosa que puede ser identificada. Puede tener una serie de
valores nombrados, llamados atributos.
Los objetos se agrupan en conjuntos, llamados clases.
Las relaciones se usan para modelar la idea de asociacin o correspondencia entre

objetos que pertenecen a clases.
Para describir una relacin, se consideran los puntos siguientes:

Restricciones de Cardinalidad. Cardinalidad es el nmero de clases que pueden
asociarse entre s en una relacin.
Invariantes. Restricciones de que alguna propiedad se debe cumplir.
Roles. Las clases que participan en una relacin tienen roles. Los nombres para los
roles o papeles en una relacin deben ser nicos.
Atributos de la relacin. Las relaciones, como los objetos, pueden tener atributos.3
Relaciones ternarias y ms altas. Las relaciones ternarias relacionan tres objetos
separados. Las que involucran ms de tres objetos se llaman relaciones n-arias.
La agregacin es un mecanismo para estructurar el modelo de objetos. Permite la

construccin de una clase agregada a partir de las otras clases componentes. La
agregacin modela las relaciones todo/parte.
La generalizacin permite a una clase, llamada supertipo, ser formada sacando las
propiedades comunes de varias clases, llamadas subtipos. La especializacin es el
caso inverso en el que un nuevo subtipo se define como una versin ms
especializada de un supertipo.4
La especializacin mltiple permite definir un nuevo subtipo como una

especializacin de ms de un supertipo inmediato. La subclase hereda los atributos y
relaciones de todas sus superclases.5
Un diagrama de modelado de objetos puede ser dividido en subdiagramas.

3
Esto corresponde al Atributo de Unin (Link Attribute) en el la notacin de Rumbaugh.

En el la anotacin de Rumbaugh, el supertipo se llama superclase, y el subtipo se llama subclase. Las
notaciones del tringulo en Fusion son completamente opuestas a las de Rumbaugh.
5
En el la notacin de Rumbaugh, la especializacin mltiple se llama herencia mltiple. La notacin es
exactamente la misma para los dos mtodos.
4
Pg. 34.
Figura 25. Notacin del diagrama de objetos de

Fusion.
Pg. 35.
Modelo de Objetos del sistema

El modelo de objetos del sistema es un subconjunto del modelo de objetos que describe
el sistema a ser construido. Se forma excluyendo todas las clases y relaciones que
pertenecen al entorno.
Usa la informacin sobre la interface del sistema para indicar qu clases y qu
relaciones pertenecen al estado del sistema, y no a su entorno.
Las clases que quedan fuera del modelo de objetos del sistema no participan en las
relaciones dentro del modelo de objetos del sistema. El modelo de objetos del sistema es
la base en la que se hace el resto del desarrollo.
Modelo de la Interface
El modelo de la interface describe el comportamiento de un sistema, por ejemplo, define
la comunicacin de entrada y salida del sistema. La descripcin est en trminos de
eventos y el cambio de estado que ellos causan.6
Un sistema se modela como una entidad activa que interacta con otras entidades
activas llamadas agentes. Los agentes modelan a los usuarios humanos, u otros sistemas
hardware o software. Las caractersticas importantes de un agente son que es activo y se
que comunica con el sistema.
Un modelo de la interface utiliza dos modelos para diferentes aspectos del
comportamiento:
Modelo del funcionamiento
Modelo de ciclo de vida
Modelo del Funcionamiento
El modelo del funcionamiento (modelo funcional) especifica el comportamiento de las
operaciones del sistema utilizando un Esquema de Modelado de Funcionamiento.
Define efectos del funcionamiento en trminos de :
cambios de estado,
eventos que son salidas.
Una operacin del sistema es un evento de entrada y su efecto en un sistema. Las
operaciones del sistema son invocadas por agentes en el entorno. Una operacin del
sistema puede
Crear una nueva instancia de una clase.
Cambiar el valor de un atributo de un objeto existente.
Agregar o anular alguna tupla de objetos de una relacin.
Enviar un evento a un agente.
Un evento es una unidad instantnea y atmica de comunicacin entre el sistema y su ambiente. Un

evento de entrada es enviado por un agente al sistema. Un evento de salida es enviado por el sistema a
un agente. Un evento de entrada y el efecto que puede tener se llama una operacin del sistema.
Pg. 36.
Figura 26. Esquema del modelo de funcionamiento.
El modelo del funcionamiento se expresa como una serie de esquemas llamados

"Esquemas del Modelo del Funcionamiento." Debe haber un esquema por lo menos
para cada operacin del sistema.
Semntica de cada entrada en la sintaxis del esquema.
Operacin: Nombre de la operacin.
Descripcin: Descripcin concisa de la operacin.
Lee:
Todos los valores a los que la operacin puede acceder sin modificacin.
Cambia: Todos los valores a los que la operacin puede acceder y modificar.
Enva:
Lista de agentes y eventos que la operacin puede enviar.
Asume:
Pre-condicin, por ejemplo, lo que debe ser verdad antes de la operacin.
Resultados: Post-condicin, por ejemplo, qu cambios han ocurrido por la operacin.
Modelo del Ciclo de Vida
El modelo de ciclo de vida describe cmo el sistema se comunica con su entorno desde
su creacin hasta su muerte. Consiste en expresiones del ciclo de vida. Una expresin
del ciclo de vida define las secuencias aceptables de interacciones en las que un sistema
puede participar en su tiempo de vida. Es algo parecido al modo en que una gramtica
describe las secuencias aceptables de smbolos que son aceptadas por un compilador. 7
Este modelo puede ser reemplazado por guiones en la versin ligera de Fusion.
Pg. 37.
Proceso de Anlisis
El anlisis no es un proceso anrquico: hay una sucesin definida de pasos que pueden
aplicarse iterativamente para producir una especificacin completa y consistente que
capture los requisitos.
El anlisis es una actividad incremental e iterativa que formaliza los requisitos. Puede
llevarse a cabo de una manera sistemtica.
En Fusion, el proceso de anlisis se define como sigue:
1. Desarrolle un modelo de objetos para el dominio del problema.
2. Determine la interface del sistema.
Identifique los agentes, operaciones del sistema, y eventos.
Produzca el modelo de objetos del sistema agregando el lmite al modelo de
objetos.
3. Desarrolle un modelo de interface.
Desarrolle un modelo de ciclo de vida.
Desarrolle un modelo de funcionamiento.
4. Verifique el modelo de anlisis.
Para todos, hasta para el ms trivial, de los problemas el proceso debe de ir acompaado
por la construccin y uso de un diccionario del datos.
Diccionario de datos
El diccionario de datos sirve para coleccionar informacin no disponible en los
diagramas de Fusion. El diccionario de los datos es un almacn (repositorio) central de
definiciones de trminos y conceptos.
Ejemplo de la estructura del diccionario de datos.
Figura 27. Ejemplo de la estructura del diccionario de datos.
Pg. 38.
Sin embargo, esto no es obligatorio, y el formato real del diccionario de los datos es
insignificante.
Desarrollo del Modelo de Objetos
Cmo empezar a construir el Modelo de Objetos?
Empezar el anlisis puede ser a menudo la parte ms difcil. El anlisis debe empezarse
con un alto nivel de abstraccin. Es mejor utilizar los requisitos para una tormenta de
ideas de posibles clases y relaciones. Slo despus de que su estructura global sea
satisfactoria deben aadirse los detalles. Hay que recordar que el modelo de objetos
utiliza clases, mientras que un documento de requisitos es expresado principalmente en
trminos de objetos especficos.
Cmo encontrar clase candidatas?
Casi cualquier nombre puede dar lugar a una clase. Sin embargo, para serlo, el nombre
debe pertenecer a un concepto que sea importante para la comprensin del dominio.
Posibles fuentes de clases candidatas son:
Objetos fsicos,
Personas y organizaciones,
Abstracciones.
Cmo encontrar relaciones?
Modelan correspondencias entre objetos. Comunicaciones, asociaciones fsicas,
contenciones, y acciones son todas las posibles fuentes para relaciones candidatas. Una
vez que las listas de candidatas se ha hecho, deben racionalizarse. En ese punto, pueden
usarse las clases y relaciones para empezar el diccionario de datos.
Qu debe ser considerado en las relaciones?

Generalizacin
Agregacin
Atributos8
Cardinalidades
Invariantes
Qu puntos deben remarcarse para construir el modelo de objetos?

Modelar objetos no es una ciencia precisa. No hay ninguna respuesta perfecta, as
que el resultado de anlisis siempre depende en parte de la experiencia, y incluso de la
esttica del analista.
Es importante recordar que los objetos no tienen que modelar cosas: tambin pueden
modelar abstracciones.
No hay que mal interpretar clases y relaciones como diagramas de flujo de datos.
Determinacin de la Interface del Sistema
Por qu determinar la interface del sistema?
stos se ignoran durante la fase de la tormenta de ideas inicial. Cualquier clase candidata que no tenga
ningn atributo y que se relacione con slo otra clase, puede convertirse en atributos.
Pg. 39.
Durante el anlisis, un sistema es modelado como una entidad activa que coopera con
otras entidades activas, llamadas agentes. El sistema y los agentes se comunican
enviando y recibiendo eventos. Cuando los eventos son recibidos por el sistema, pueden
causar un cambio de estado y eventos de salida. Un evento de la entrada y su efecto
asociado son conocidos como una operacin del sistema.
La interface de un sistema es el conjunto de operaciones del sistema a las que puede
responder y los eventos que puede enviar.
Una operacin del sistema siempre es invocada por un agente, no por un objeto; la fase
del anlisis no se preocupa por mensajes internos entre los objetos.
La informacin obtenida en la determinacin de la interface del sistema es el punto de
partida para desarrollar el modelo de la interface.
Qu es la notacin de la interface del sistema?
El escenario es una tcnica til para definir la interface del sistema.
Un escenario es una sucesin de eventos que fluyen entre agentes y el sistema para
algn propsito.
Un escenario se representa como un diagrama de secuencia, que muestra las rdenes
temporales del sistema y los eventos que fluyen a los agentes. Los diagramas de
secuencia no pueden mostrar caminos alternativos de comunicacin. Por consiguiente,
en general pueden necesitarse diagramas mltiples para un slo escenario.
Los diagramas de secuencia de escenario aportan una herramienta para intuir las
consecuencias del diseo de la interface y visualizar cmo se comporta el sistema. Son
tiles al validar decisiones de la interface con clientes porque son simples e intuitivos de
entender.
Figura 28. Diagrama de secuencia.
Pg. 40.
Desarrollo del Modelo de la Interface

Cul es el orden para desarrollar el modelo de la interface?
El modelo de la interface comprende un modelo del ciclo de vida y un modelo del
funcionamiento. El orden de desarrollo no es fijo. Sin embargo, es mejor empezar con el
modelo del ciclo de vida porque el ciclo de vida puede ser una ayuda al desarrollo del
esquema del modelo de funcionamiento.
Cmo desarrollar el modelo del ciclo de vida?
El modelo del ciclo de vida es una expresin generalizada de los escenarios que se
expresan en diagramas de secuencia. Las expresiones del ciclo de vida son ms
expresivas que el diagrama de secuencia, porque pueden expresar repeticin,
alternacin, y optionalidad, as como el encadenamiento.
Una expresin del ciclo de vida puede definir un conjunto de escenarios, mientras que
un diagrama de secuencia puede mostrar slo un solo escenario.
El proceso para formar el modelo del ciclo de vida es:
1. Generalice los escenarios para formar expresiones del ciclo de vida nombradas.
2. Combine las expresiones del ciclo de vida para formar el modelo del ciclo de vida.
Cmo desarrollar el modelo del funcionamiento?
El modelo del funcionamiento define la semntica de cada operacin del sistema en la
interface del sistema usando un esquema de modelo del funcionamiento.
El proceso para desarrollar un esquema puede resumirse como sigue:
1. Desarrolle la clusulas Asume y Resultados.
2. Extraiga la clusulas Enva, Lee, y Cambia de Asume y Resultados.
Verificando los Modelos del Anlisis
Cundo detener la fase del anlisis?
El dilema que enfrenta al analista es saber cundo los modelos del anlisis son
suficientemente buenos para ser usados en el diseo. La perfeccin es inasequible y
normalmente no se requiere. Sin embargo, una especificacin con errores graves no
sirve.
Verificar los modelos del anlisis es una manera de evitar errores graves. Si los
chequeos no revelan ningn problema, entonces se puede pensar que la fase del anlisis
est completa.
Qu aspectos sern verificados?
Hay dos aspectos para ser verificado: completitud (integridad) y consistencia.
La integridad puede medirse contra los requisitos. Los modelos del anlisis deben
probarse contra los requisitos, y tambin el conocimiento y expectativas de los clientes
y expertos del dominio.
1) Chequeo de la Integridad contra los Requisitos
Hay que verificar que:
- Todos los posibles escenarios son cubiertos por el ciclo de vida.
- Todos las operaciones del sistema son definidas por un esquema.
Pg. 41.
- Toda la informacin esttica es capturada por el modelo de objetos del sistema.

- Cualquier otra informacin (ej., definiciones tcnicas e invariantes), est en el
diccionario de datos.
Un conjunto de modelos es consistente cuando los modelos no se contradicen entre
ellos, explcitamente o implcitamente. En un modelo debe verificarse su consistencia
interna y tambin para esas reas donde se solapa con otros modelos.
2) Chequeos de la Consistencia Simple
Estos chequeos tratan las reas de solape entre los modelos del anlisis. Verifique que
- Todas las clases, relaciones, y atributos mencionados en el modelo del
funcionamiento aparece en el modelo de objetos del sistema. Todos los otros conceptos
(ej., predicados), deben aparecer por el modelo del ciclo de vida.
- Todos las operaciones del sistema en el modelo del ciclo de vida tienen un
esquema.
- Todos los identificadores en todos los modelos tienen entradas en el diccionario de
datos.
3) Chequeos de la Consistencia Semntica
Estos chequeos intentan asegurar que las implicaciones de los modelos son consistentes.
Verifique que
- La salida de eventos en el modelo del ciclo de vida y el modelo de funcionamiento
deben ser consistentes. El esquema para una operacin del sistema debe generar los
eventos de salida que lo siguen en los escenarios del modelo de ciclo de vida.
- El modelo de funcionamiento debe conservar invariantes del modelo de objetos del
sistema. Si hay alguna invariante acerca de una relacin o clase, entonces cualquier
operacin que puede cambiarlo debe respetar el invariante en su esquema.
- Chequear los escenarios usando el esquema. Escoja ejemplos de escenarios , y
defina el cambio de estado que cada uno debe causar. Entonces "ejecute" los escenarios,
usando el esquema para definir el comportamiento de cada operacin del sistema.
Chequee que los resultados son lo que se espera.
Diseo
El diseo consiste en desarrollar un modelo abstracto de cmo un sistema lleva a cabo
el comportamiento especificado en el anlisis.
El diseador escoge cmo se va a construir el sistema. Durante este proceso, los
mtodos se unen a las clases. El diseador tambin escoge cmo los objetos se
relacionan entre ellos y qu relaciones de herencia entre clases son apropiadas.
La fase de diseo de Fusion se basa en las CRC y los mtodos de Booch.
La salida del diseo es una estructura de software orientado a objeto que contiene la
misma informacin y mantiene las relaciones definidas en el modelo de objetos del
sistema.
Durante esta fase se desarrollan los cuatro modelos siguientes:
Grficos de Interaccin de Objetos. Describen cmo los objetos interactan en

tiempo de ejecucin para conseguir la funcionalidad especificada en el modelo de
funcionamiento en la fase del anlisis.
Pg. 42.
Grficos de visibilidad. Describen las rutas de comunicacin entre objetos.

Descripciones de clases. Proporcionan una especificacin de la interface de la
clase, atributos de datos, atributos de referencia a objetos, y signaturas de los
mtodos para todas las clases en el sistema.
Grficos de herencia. Describen las estructuras de herencia clases/subclases.
Adems, el diccionario de los datos documenta los trminos, conceptos, y restricciones

que aparezcan durante esta fase.
La entrada de la fase de diseo son los tres modelos desarrollados en la fase del
anlisis: Modelo de objetos, modelo de funcionamiento y modelo del ciclo de vida.
Grfico de Interaccin de Objetos
La primera consideracin en diseo orientado a objetos es la implementacin de cada
operacin del sistema. El modelo de funcionamiento especifica la conducta de estas
operaciones definiendo el efecto de cada operacin en trminos de cambios de estado
del sistema y de eventos de salida. El propsito de esta fase en diseo es construir las
estructuras de mensajes entre objetos definidas en el modelo de funcionamiento.
El grfico de interaccin de objetos se construye para cada operacin del sistema.
Un grfico de interaccin de objetos es una coleccin de cajas unidas por flechas. Las
cajas representan al objeto, y las flechas representan el paso del mensaje. Hay dos tipos
de cajas:
Director
Le llega una flecha que no viene de ninguna otra caja del grfico;
esta flecha se etiqueta con el nombre de la operacin del sistema que implementa ese
grfico de iteraccin de objetos.
Colaboradores El resto de las cajas se llaman colaboradores. El resto de las
flechas, salvo la de la operacin del sistema, van de una caja a otra dentro del grfico.
Las sucesiones de mensajes entre los objetos determinan el comportamiento de los
objetos declarado en el grfico de interaccin de objetos. Esto define la implementacin
a alto nivel de la funcionalidad a travs de los objetos para una operacin del sistema.
Cada grfico de interaccin de objetos tambin lleva asociado un texto descriptivo en el
diccionario de los datos, en lenguaje natural, pseudocdigo, o especificacin formal,
para dar significando a la operacin del sistema y los mensajes definidos.
Notacin del grfico de interaccin de objetos
Pg. 43.
Figura 29. Notacin del grfico de iteraccin de objetos.

Pg. 44.
Objeto del diseo. Tiene atributos y la interface de los mtodos. En la fase del
anlisis un objeto no tena ningn atributo ni mtodo. Para distinguirlo de este, se utiliza
la palabra objeto del diseo. La notacin es una caja slida.
Colecciones de Objetos. Colecciones de objetos de la misma clase. Las
implementaciones tpicas de estas colecciones sern listas o arrays. La notacin es una
caja con lneas discontinuas.
Paso de mensajes. El paso de mensajes es una comunicacin punto a punto, y se
realiza como una llamada a una funcin o a un mtodo. La notacin es una flecha
directa con etiquetas. La direccin de la flecha es del remitente al receptor. Tambin se
llaman cliente y servidor.
Paso de mensajes a Colecciones. Un mensaje puede pasarse a colecciones de
objetos. La notacin es una flecha directa a una caja con lneas discontinuas.
Secuencia de Mensajes . Si una secuencia de pasos de mensajes es importante, se
puede mostrar el orden de la secuencia introduciendo etiquetas de la secuencia entre
parntesis sobre el nombre del mensaje. La notacin son etiquetas de la secuencia entre
parntesis.
Creacin dinmica de Objetos . La palabra clave new indica que un objeto se crea
como parte de la ejecucin de un grfico de interaccin de objetos. El mensaje especial
create tambin debe ser enviado a cada nuevo objeto, con los parmetros de invocacin
apropiados, para inicializarlo. La notacin es una flecha directa con el mensaje create().
Cmo desarrollar un grfico de interaccin de objetos?
Para cada operacin del sistema se realiza un grfico de interaccin de objetos. Esto
significa que se desarrolla un grfico de interaccin de objetos para cada esquema en el
modelo de funcionamiento.
Esto supone los siguientes pasos:
1. Identifique los objetos pertinentes involucrados en la implementacin de la
operacin del sistema.
El esquema del modelo de funcionamiento se usa como el punto de partida para
identificar los objetos involucrados.
La clusula Lee del esquema proporciona una lista de los objetos a los que la
operacin del sistema accede pero no modifica.
La clusula Cambia lista los objetos cambiados por dicha operacin.
Adems de los objetos listados explcitamente en el esquema, puede haber otros
objetos involucrados. Por ejemplo, pueden introducirse nuevos objetos para representar
abstracciones de mecanismos computacionales no identificadas en los modelos del
anlisis.
La clusula Enva del esquema, por ejemplo, lista los eventos de salida a agentes
del sistema.
2. Establezca el rol de cada objeto.
Identifique al director (es decir, el objeto que recibe la demanda para invocar la
operacin del sistema, y es responsable de dicha operacin).
Identifique a los colaboradores involucrados.
3. Decida los mensajes entre los objetos.
Pg. 45.
Cada objeto proporcionar pedazos diferentes de funcionalidad. Estos pedazos de

funcionalidad estn compuestos por el paso de mensajes entre los objetos.
4. Registre cmo los objetos identificados interactan en un grfico de interaccin de
objetos.
Cada objeto proporciona una parte de la definicin funcional de la operacin, y
esta informacin puede extraerse para definir la interface del mtodo del objeto. Una
descripcin textual de cada mtodo es incluida en el diccionario de los datos. Esto
explica el significado de los mtodos.
Cmo refinar un grfico de interaccin de objetos?
El proceso de diseo lleva a cabo un desarrollo iterativo y una descomposicin
jerrquica. Los grficos de Interaccin de objetos proporcionan una representacin
visual de la estructura de los algoritmos. Permiten llevar a cabo experimentos con
diseos alternativos y ayudar a la descomposicin jerrquica.
Diseo alternativo
Los diseos alternativos son explorados desarrollando grficos de interaccin de
objetos para el mismo funcionamiento, pero escogiendo diferentes objetos para
directores y colaboradores, y con mensajes diferentes que pasan entre ellos. Pueden
demostrarse las consecuencias de estas alternativas claramente, mostrando los mensajes
en tiempo real que ocurren para una determinada operacin del sistema.
Descomposicin del mtodo jerrquica
Un diseador puede reducir la complejidad de un grfico de interaccin de objetos
posponiendo la descomposicin de un mtodo. Esto puede hacerse con el uso de un
esquema de modelo de funcionamiento para especificar el mtodo. Despus en el
diseo, el esquema del mtodo puede usarse para producir unos grficos de interaccin
de objetos de la manera normal.
Cmo verificar un grfico de interaccin de objetos?
Hay dos chequeos bsicos que necesitan ser llevados a cabo una vez que el diseador
est satisfecho con los diseos iniciales.
1. Consistencia con la especificacin del sistema.
Verifique que cada una de las clases en el modelo de objetos del sistema se
representa en por lo menos un grfico de interaccin de objetos.
2. Comprobacin de efecto funcional.
Chequee que el efecto funcional de cada grfico de interaccin de objetos satisface la
especificacin de su operacin del sistema dada en el modelo del funcionamiento.
Chequee que se satisfacen todas las clusulas Resultado del esquema.
Principios de buen diseo
Hay que tratar de:
Minimizar las interacciones entre objetos.
Separar ordenadamente la funcionalidad.
Desarrollar sistemas modulares.
Pg. 46.
Grficos de visibilidad
Durante el desarrollo de los grficos de interaccin de objetos, se supona que todos los
objetos son visibles entre s y se pueden enviar mensajes. El propsito del grfico de
visibilidad es definir la estructura de la referencia de clases en el sistema. La tarea es
identificar para cada clase,
objetos que las instancias de la clase necesitan referenciar,
los tipos apropiados de referencia a esos objetos.
Notacin del grfico de visibilidad
Hay tres componentes en el grfico de visibilidad:
1.caja del cliente
Esto representa la clase que requiere el acceso. Una caja del cliente es un rectngulo
que contiene el nombre de una clase.
2.caja del servidor
Esto representa el objeto al que se accede. Una caja del servidor es un rectngulo que
contiene una etiqueta del servidor que nombra la instancia en la caja, la clase de la
instancia, si el servidor es creado por el cliente, y si la referencia al servidor es o no
constante.
3.flecha de visibilidad
Esto representa que el cliente tiene acceso a la instancia del servidor va una ruta de
acceso.
Pg. 47.
Figura 30. Notacin del grfico de visibilidad.

Pg. 48.
Semntica del grfico de visibilidad

Hay cuatro decisiones de diseo cuando se considera la estructura de la referencia de
clases.
Vida de la referencia
Referencia dinmica.- Cuando un cliente slo necesita mandar un mensaje al
servidor en el contexto de una sola invocacin del mtodo, puede darse el acceso a
travs de un parmetro o por una variable local del mtodo. En esta situacin se
especifica una referencia dinmica. Se denota por una flecha discontinua.
Referencia permanente.- Cuando un objeto necesita la misma referencia en
muchos contextos, se usan referencias permanentes. Se denota por una flecha slida.
Visibilidad del servidor
Servidor no-compartido.- Un objeto servidor que recibe un mensaje de un cliente
exclusivamente. La caja de objeto de servidor tiene un borde doble. Esto garantiza que
en el momento de cualquier invocacin al mtodo, slo un cliente tendr una referencia
al servidor. Sin embargo, puede haber clientes diferentes en momentos diferentes, pero
en cualquier invocacin hay slo un cliente. El contorno discontinuo se usa para
servidores que son una coleccin de objetos servidores.
Servidor compartido.- Un objeto servidor que recibe un mensaje de mltiples
clientes. La caja de objeto de servidor tiene un borde simple.
Ligadura del servidor
Servidor ligado.- Si un objeto servidor debe ser eliminado cuando su cliente se
elimina, se dice que el tiempo de vida del servidor es limitado. En este caso, la caja del
servidor se pone dentro de la caja del cliente.
Servidor no ligado.- Cuando el tiempo de vida de un objeto servidor no se liga al
de un cliente, la caja del servidor se muestra fuera de la caja de clase de cliente.
Mutabilidad de la referencia
Mutabilidad constante.- Si una referencia no es asignable despus de inicializarse,
se dice que tiene mutabilidad constante. Esto significa que la referencia es fija cuando
se inicializa. La palabra clave constante se pone delante del nombre del servidor.
Mutabilidad inconstante.- Si una referencia es reasignable, la mutabilidad es
inconstante. La palabra clave variable se pone delante del nombre del servidor.
Cmo desarrollar los grficos de visibilidad?
Los grficos de visibilidad se desarrollan de los grficos de interaccin de objetos de la
manera siguiente:
1. Se inspeccionan todos los grficos de interaccin de objetos. Para cada flecha que
va de un objeto a otro, la clase del remitente requiere una referencia de visibilidad al
objeto receptor.
2. Anote la flecha con informacin de visibilidad detallndolo donde sea apropiado.
Vida de la referencia
Visibilidad del servidor
Ligadura del servidor
Mutabilidad de la referencia
Pg. 49.
3. Para cada clase, considere todas las flechas anotadas de las instancias de la clase.
Construya un grfico de visibilidad con la clase en la caja cliente y con flechas de
visibilidad conectadas a las cajas servidor.
La etiqueta en las flechas de los grficos de interaccin de objetos puede copiarse a
travs de los grficos de visibilidad donde sea necesario.
Cmo verificar el grfico de visibilidad?
Hay que hacer tres chequeos importantes:
1.Consistencia con los modelos del anlisis.
Las relaciones identificadas durante el anlisis definen invariantes que deben
mantenerse entre las clases. Se debe chequear que las estructuras orientadas a objeto
definidas en los grficos de visibilidad mantengan las relaciones. Para cada relacin en
el modelo de objetos de sistema, esperamos que haya un camino de visibilidad entre las
clases correspondientes en el diseo.
2.Consistencia mutua
Verifique que los objetos servidor exclusivos no son referenciados por ms de un
cliente.
3.Integridad
Verifique para ver que todos los pasos de mensajes definidos en los grficos de
interaccin de objetos estn comprendidos en los grficos de visibilidad.

Minimizar datos y las dependencias funcionales.
Descripciones de clase
Despus de desarrollar los grficos de visibilidad para todas la clases, el siguiente paso
es intercalar informacin del modelo de objetos del sistema, de los grficos de
interaccin de objetos y de los grficos de visibilidad en descripciones de clase, una
para cada clase.
En esta fase, los mtodos, algunos atributos de datos, y los atributos de valor de los
objetos se establecen para cada clase.
Cuando estas descripciones iniciales se han producido, se disean las estructuras de
herencia requeridas en el sistema.
Notacin de las descripciones de la clase
La notacin es como sigue:
clase <Nombre_de_la_Clase> [ isa <Nombre_de_la_SuperClase>]
// para cada atributo
[attribute][Mutability] <Nombre_del_Atributo>: [Sharing][Binding] <Tipo>
:
:
// para cada mtodo
[method] <Nombre_del_mtodo> <Lista_de_argumentos> [: <Tipo>]
:
:
endclass
Cmo desarrollar las descripciones de la clase?

Pg. 50.
El proceso para construir descripciones de clases es como sigue:

Mtodos y sus parmetros
Se derivan mtodos de los grficos de interaccin de objetos.
Atributos de datos
La fuente para los atributos de datos es el modelo de objetos de sistema y el
diccionario de los datos.
Atributos de objeto
Se extraen atributos de objetos del grfico de visibilidad para la clase.
Dependencias de herencia
Las dependencias de herencia se documentan despus de definir los grficos de
herencia.
Cmo verificar las descripciones de la clase?
La informacin en las descripciones de clase se deriva, es decir, no se genera de nuevo.
Con tal de que las transcripciones sean exactas, las descripciones sern consistentes con
las descripciones producidas antes en anlisis y diseo.
Sin embargo, se deben hacer los siguientes chequeos:
1. Atributos de datos. Verifique que se recogen todos los atributos de datos del
modelo de objetos del sistema.
2. Atributos del objeto. Verifique que estn todas las referencias de visibilidad.
3.Mtodos y parmetros. Verifique que se recogen todos los mtodos de los grficos
de interaccin de objetos.
4.Herencia. Verifique se recogen que todas las superclases.
Restringir reusos basados en herencia.
Reusar a travs de herencia no siempre es la opcin mejor.
Decidir cuando construir nuevas clases a travs de herencia y cundo construir
usando composicin es un aspecto del diseo de OO.
La herencia debe usarse cuando la interface completa de la clase vieja se aplica a
la clase nueva, sin embargo, no debe usarse cuando una alta proporcin de cdigo
necesita volverse a escribir o cuando algunos de los mtodos de la clase vieja son no
pertinentes.
Desarrollar grficos de herencia poco profundos.
Deben organizarse clases en un sistema como un bosque de grficos de herencia,
cada uno cubriendo una categora particular de clases relacionadas.
Deben organizarse clases en jerarquas poco profundas de aproximadamente
cuatro a cinco niveles.
Hacer una raz en una clase abstracta.

Cada grfico de herencia debe arraigarse en una clase abstracta que slo sirve como
una definicin de una interface. Debe definir un conjunto de atributos mnimo
(preferentemente vaco) para que no se restrinjan subclases potenciales en su
representacin.
Pg. 51.
Figura 31. Proceso de construccin de una descripcin de clase.
Grficos de herencia
Una consideracin importante en diseo orientado a objeto es la herencia, un
mecanismo por cul una clase puede definirse como una especializacin de otra. Los
grficos de herencia reflejan las relaciones de herencia entre las clases.
Pg. 52.
Notacin de los grficos de herencia

La notacin usada para herencia es igual que la notacin del modelo de objetos usada
para la generalizacin y la especializacin. Una caja representa una clase, con el nombre
de la clase indicado en la seccin superior de la caja. Se nombran los atributos en la caja
debajo de la lnea.
Tringulo hueco.- No se hacen ninguna suposicin de que las subclases sean
disjuntas o que particionen a la superclase. Esto significa eso puede haber otras
subclases que hereden de la superclase.
Tringulo slido.- Esto indica que las subclases son disjuntas y que su unin forma
la superclase. Esto significa que no hay ms subclases que hereden de la superclase.9
Figura 32. Notacin de los grficos de herencia.

Cmo desarrollar los grficos de herencia?
Las entradas para desarrollar grficos de herencia son 1) el modelo de objetos del
sistema, 2) los grficos de interaccin de objetos , 3) los grficos de visibilidad, y 4) las
descripciones de clase. Lo siguiente son pasos para desarrollar grficos de herencia de
estos modelos.
Modelo de objetos del sistema - generalizaciones
Las estructuras de generalizacin y especializacin del modelo de objetos del
sistema proporcionan el punto de partida obvio.
Una clase del anlisis especializada es una subclase, y una clase del anlisis
generalizada es un superclase.
9
La definicin anterior de tringulo del hueco/slido es completamente opuesta a la de Rumbaugh
Pg. 53.
Grficos de interaccin de objetos y descripciones de clase - funcionalidad comn

Cada descripcin de clase es chequeada para descubrir la funcionalidad comn.
Esta funcionalidad puede extraerse para construir una nueva clase abstracta.
Grficos de visibilidad - estructura comn
Cada grfico de visibilidad se verifica contra otros para extraer la estructura
comn. Si dos clases tienen una referencia comn en la estructura entonces puede ser
posible definir una clase abstracta que define las referencias comunes.
Cmo verificar los grficos de herencia?
Los grficos de herencia tienen que ser verificados con los modelos siguientes:
Modelo de objetos del sistema
Chequee que las relaciones de subtipos se conservan. Recuerde que el propsito
de las relaciones de generalizacin y especializacin en el anlisis es declarar la
propiedad de subtipos entre dos clases.
Grficos de interaccin de objetos
Verifique que todas las clases se representan en un grfico de herencia.
Grficos de visibilidad
Verifique que todas las clases se representan en un grfico de herencia. Pueden
definirse clases abstractas para la estructura comn entre las clases en los grficos de
visibilidad.
Descripciones de clase
Chequee que las nuevas descripciones de clase capturan todos los mtodos
comunes de los anteriores y respetan los grficos de herencia.

Una Clase; Una Abstraccin
Una clase debe tener un tipo de funcionalidad.
Una manera de medir la cohesin de clases es considerar pares de mtodos en la
interface de la clase y los atributos de datos involucrados en su definicin.
Dos mtodos sin atributos de datos comunes sirven funciones separadas y puede
indicar que la clase no es cohesiva.
Representacin del Encapsulamiento
Un buen principio de encapsulacin es esconder la implementacin y reducir la
dependencia de la interface en la implementacin.
Los mtodos deben ser ortogonales, es decir, no debe haber ningn solape de
funcionalidad entre los mtodos.
Pg. 54.
Implementacin
Gestin de un Desarrollo Fusion
Cmo introducir Fusion en un proyecto?
Se sugiere un acercamiento de tres pasos:

1. Valoracin de necesidades
Repase el proceso de desarrollo de software del proyecto y sus necesidades de
negocio. Chequee si Fusion es apropiada.
2. Entrenando
Organice "un curso de entrenamiento" y "un grupo de trabajo" para una nueva
tecnologa. Despus de estos entrenamientos, confirme su decisin de utilizar Fusion.
3. Plan de transicin
Las pautas para la transicin son:
Identifique aquellos componentes de software que sean ms amenos al uso de
Fusion. Escoja un o dos componentes de bajo riesgo para aplicar el mtodo.
No planee hacer todo el anlisis, seguido por todo el diseo, seguido por toda la
implementacin. Tome confianza convirtiendo una pequea parte en cdigo lo antes
posible.
No es necesario que la totalidad del equipo de proyecto est involucrada
directamente usando el mtodo. Aqullos que no estn analizando ni diseando pueden
participar revisando.
Un experto en el mtodo puede llegar a ser muy eficaz actuando como mentor y
consultor extraoficial del resto del equipo.
Adaptacin de Fusion. Qu es la versin ligera de Fusion (Fusion Lightweigt)?
Un proyecto no siempre puede poder adoptar la versin de Fusion completa. Entonces

se pueden introducir una versin ms ligera.
Estas simplificaciones significan que se requiere menos esfuerzo en aprender el mtodo.
Ejemplos de estas simplificaciones son:
-
En el modelo de funcionamiento omitir las clusulas Asume y Resultados.

Reemplazar el modelo del ciclo de vida por guiones
En las descripciones de clase omitir la informacin sobre la visibilidad, el tiempo

de vida y la mutabilidad de los atributos de los objetos.
El costo de utilizar esta versin ligera es que habr menos documentacin para la
implementacin y un menor soporte para el mantenimiento.
Pg. 55.
SMM (Shlaer & Mellor Method)

Caractersticas
Es una metodologa bastante rgida. Sus assets resultan fciles de verificar. Es vlido
para proyectos de muy diversos tamaos. Incluye la planificacin dentro de sus fases
mediante el uso de una tcnica denominada matriz de proyecto.
Su forma de trabajar consiste en la separacin del problema a solventar en problemas
independientes, denominados dominios, y la divisin de los mismos en subsistemas
para poder analizarlos en profundidad.
Proceso
Una vez diferenciados los dominios, se procede al anlisis de cada uno de ellos
consiguiendo un modelo de cada dominio:
1. Divisin del problema en dominios: Hay 4 tipos de dominios: de Aplicacin
(usuario), de Servicio (interfaz), de Arquitectura (datos y su control.) y de
Implementacin (sistema operativo).
2. Anlisis del Dominio de Aplicacin: Se crean varios modelos, para cubrir las
especificaciones del cliente:
Un Modelo de Informacin de los objetos en el que se reflejar el anlisis
conceptual.
Luego un Modelo de Estados que refleje el comportamiento del sistema.
Por ltimo una descripcin de acciones especficas, usando A-DFDs.
Para toda esta fase se pueden usar herramientas CASE. La metodologa tambin define
una serie de modelos de subsistemas adicionales.
3. Confirmacin del anlisis: Validar que cumple los requisitos y tiene la forma
adecuada. Se hace una simulacin mediante secuencias del tipo Estado_inicialComportamiento-Accin para comprobar si realmente la aplicacin va a funcionar
como deseamos.
4. Extraccin de requisitos para los Dominios de Servicio. Se representan los dominios
como elipses. Ahora, a todos los requisitos implcitos no descritos por el cliente
(aquellos que tratan sobre la interrelacin entre los dominios) se representan por una
flecha entre los dominios afectados, denominada puente. Deben quedar reflejados
darse todos estos requisitos, tanto los cualitativos como los cuantitativos.
5. Anlisis de los Dominios de Servicio: Una vez que ya tenemos los requisitos de los
dominios del cliente, pasamos a analizar este segundo tipo de dominios en los que
subdividimos nuestro problema.
6. Especificacin del Dominio de Arquitectura: En este dominio se especifican facetas
de diseo (estructuras de datos a usar, autmatas de control, threads, algoritmos,...). Se
usarn los siguientes diagramas: de pertenencia/dependencia -> de clases(estructura
Pg. 56.
externa) -> de estructura de clase(estructura interna). Cada diagrama puede contener o +

de los otros tipos, para explicar sus contenidos.
7. Construccin del Dominio de Arquitectura: Tiene dos tipos de componentes:
Mecanismos: Procesos que lleva a cabo el sistema.
Estructuras: Colecciones de datos organizadas y arquetipos.
8. Codificacin de los modelos: Para la codificacin nos dan unas pautas generales,
aunque ya nos avisa que no tienen por que ser totalmente seguidas debido a la diferencia
existente entre un LPOO y otro.
9. Beneficios: Los desarrollos apoyados en esta metodologa son fciles de verificar.
Usa un refinamiento sucesivo, y un acercamiento integral al problema. Los programas
son mucho ms reutilizables. Existen herramientas CASE que automatizan tosa la
metodologa.
Principales assets generados

Fase de anlisis
Fase de diseo
System Level:
System Level:
Domain Chart
Task Communication Diagram
Project matrix
Domain Level:
Task Level:
Subsystem Relationship Model
Inheritance Diagram
Subsystem Communication Model
Dependency Diagram
Subsystem Access Model
Task Archetypes
Subsystem Level:
Class Level:
Object Information Model
Class Diagram
Object Communication Model
Class Structure Chart
Object Access Model
Class Archetypes
Object Level:
Fase de impementacin
Object State Model
Populated Task Archetypes
State Action Specification
Populated Module Archetypes
Pg. 57.
EROOS: (Especificaciones Orientadas a Objeto E-R)

Introduccin
Es una metodologa desarrollada por Software Development Methodology Research
Group. Tiene tanto una notacin como una serie de estrategias para el desarrollo de
software (desde el anlisis hasta la implementacin). Todas las especificaciones que se
hacen son declarativas, permitiendo posponer as decisiones de diseo e
implementacin para justo antes de la codificacin, pero habiendo ya realizado un buen
anlisis.
Intenta acabar con el mtodo de trabajo tradicional al considerarlo informal, ambiguo e
incompleto.
Caractersticas
La potencia de EROOS queda resumida en 3 puntos:
1. Combina el modelado del comportamiento con el modelado de las estructuras a
representar. Una integracin total de estos dos modelados proporcionara al mtodo de
especificacin unas propiedades de composicin y descomposicin mucho ms
potentes. Esto llevara a un software mejor estructurado, mantenible y reutilizable.
2. Descripcin del software declarativa (no operacional). La primera descripcin de lo
que el sistema ha de hacer, en lugar de cmo le permite ir transformndose sin perder
de vista el problema a solventar. Esto da un nivel de abstraccin adecuado a cada fase
del desarrollo.
3. Separacin del dominio del problema de su solucin. Esto crea un sistema flexible y
cambiable, pero con un ncleo slido. La funcionalidad del sistema se reflejar en ese
ncleo, permitiendo que el sistema se adapte a las peticiones del usuario, en lugar de
comenzar desde el principio cada vez que surja una nueva demanda.
Una de las virtudes de EROOS es que al dar una notacin y reglas a seguir, solo puede
darse una solucin a un problema (estando en un determinado nivel de abstraccin). As
se minimizan los malentendidos por malas interpretaciones y se facilita el trabajo en
grupo.
Existen herramientas generadoras de cdigo C++ y herramientas CASE basadas en esta
metodologa que ayudan a llevarla a la prctica.
Ciclo de Vida
Comienza por la solicitud de los requisitos (no despus).
1. Anlisis:
Anlisis del contexto del problema: Uso de tcnicas de modelado de negocio.
Pg. 58.
Especificacin del problema: Mentalidad de gerente. Especificar los requisitos de la

solucin.
Especificacin de las soluciones: Reingeniera de procesos de negocio e idear

nuevas soluciones.
2. Diseo: Ha de hacerse antes de dar la solucin (informacin necesaria, decisiones

persistentes, interfaces con el mundo real). A partir de ah anlisis y diseo del software
(descomposicin y restricciones):
Diseo de la solucin: Optimizacin del tamao, determinacin de la informacin

necesaria, toma de decisiones persistentes y definir las interfaces del sistema con el
mundo exterior.
Anlisis del software: Diseo y descomposicin del sistema en subpartes para poder
reutilizarlas o compartirlas. Toma de decisiones en cuanto a la distribucin de la
informacin y la concurrencia se refieren.
Diseo del software: Conseguir separar el lenguaje de la plataforma en que se

ejecutar el programa, realizacin de las restricciones impuestas al sistema y de
nuevo la toma de decisiones en cuanto a la distribucin de la informacin y la
concurrencia se refieren.
3. Diseo de la solucin:
Diseo del cdigo: Seleccin del lenguaje adecuado para nuestro cdigo y fusin
entre el lenguaje y la plataforma. Toma de decisiones en cuanto a la distribucin de
la informacin y la concurrencia se refieren.
Codificacin: Generacin del cdigo.
Filosofa y Conceptos Contemplados

Los siguientes conceptos son contemplados en la metodologa (vese su representacin
en el apartado Notaciones, que viene a continuacin):
Objetos y clases: Los objetos son clasificados en clases, distinguiendo entre objetos
presentes y pasados. Esto se consigue porque aunque la relacin entre el objeto y su
clase madre es esttica, ste puede mantenerse an despus de la muerte de la clase
como archivado, pudiendo accederse a sus valores, pero nunca ms modificarlos.
Siempre son creados y destruidos (poseen un ciclo de vida).
Relaciones: Refinan a las clases y especifican las relaciones que las unen. En
realidad son objetos, con una existencia dependiente de los objetos implicados en la
relacin. Solo se permiten relaciones unarias y binarias.
Atributos, Dominios y Valores: Los valores son clasificados en dominios. Esos

mismos valores decoran a las clases, y especifican sus propiedades. Una de sus
diferencias con los objetos es que ni se crean ni son destruidos. En EROOS solo se
puede acceder a los atributos mediante las funciones (servicios) que tiene cada clase,
y no de otra forma que violara el encapsulamiento.
Restricciones: Limitan las posibles relaciones o valores de los atributos. En EROOs

las restricciones pueden ser de 3 tipos: Implcitas (Ej un objeto refinado tiene una
Pg. 59.
dependencia existencial de quienes proviene), Integradas (Ej: las de conectividad) y

Explcitas (adems de los dos tipos anteriores se pueden definir mediante lgica de
primer orden). Han de definir las clasulas que el sistema ha de cumplir en todo
momentos, sin importarles cmo son preservadas.Se pueden definir triggers para
que reaccionen a posibles violaciones de las restricciones.
Funcionalidades: Divididas en:

Consultas dinmicas: Solo acceden a informacin del sistema y de los objetos,

pero no la modifican. Con una flecha hacia arriba devuelve todos los objetos
refinados en que una clase participa. Con una flecha hacia abajo devuelve el
objeto al que la aplicamos. Con una flecha hacia la derecha devuelve los valores
del objeto al que apunta.
Eventos: Cambian el estado del sistema. Pueden estar localizados en:

-
Kernel: Constructores, destructores y mutadores. Los eventos del kernel se

especifican mediante post-condiciones con clasulas de efecto que se
redactan mediante lgica de primer orden.
Shell: Son ms complejos y se especifican mediante combinaciones de

funciones del kernel, consultas y otras del shell.
Generalizacin/especificacin: Comprende las relaciones Is-a (es un). La herencia

es una relacin ISA a fin de cuentas. Este tipo de relaciones lo que hacen es
fortalecer las capacidades de una clase, lugo una clase refinada as debe tener una
definicin ms slida que su clase preferente. Adems se le pueden aadir nuevas
funcionalidades.
Herencia: En esta metodologa la estructura del sistema se define en forma de

herencias. Esto permite tener varios niveles de abstraccin incluso dentro de un
mismo modelo. Esto a su vez permite extender clases ya definidas, incluso reusarlas.
Notacin
OBJETOS Y CLASES:
Figura 33. Notacin de objetos y clases en EROOS
Pg. 60.
RELACIONES:
Figura 34. Notacin para las relaciones entre clases en

EROOS (1)
Figura 35. Notacin para las relaciones entre clases

en EROOS (2)
ATRIBUTOS:
Figura 36. Notacin para los atributos en

EROOS
Pg. 61.
RESTRICCIONES:
Figura
37.
Notacin
restricciones en EROOS
para
las
CONSULTAS:
Figura 38. Notacin para las consultas en

EROOS
KERNEL:
Figura
39.
Notacin
para
las
funcionalidades del Kernel en EROOS
SHELL:
Figura
40.
Notacin
para
funcionalidades del Shell en EROOS
las
Pg. 62.
GENERALIZACIN/ESPECIALICACIN:
Figura 41. Notacin para las relaciones Is_A en

EROOS
Pg. 63.
Metodologa MOSES
Introduccin
La metodologa MOSES (Methodology for Object-Oriented Software Engineering of
Systems) es una metodologa que cubre todo el ciclo de vida del desarrollo de software
orientado a objeto, no slo anlisis y diseo, sino la gestin de proyectos, planificacin
de negocio, mantenimiento de la aplicacin y futuras mejoras. Incluye una notacin
completa que adems es soportada por algunas de las herramientas CASE que existen
en el mercado, as como unas tcnicas de gestin avanzadas que no estn disponibles en
ninguna otra metodologa.
Muchas industrias estn adoptando MOSES como metodologa de desarrollo de
software de calidad. Uno de los sitios donde se est realizando (buque insignia de esta
metodologa) es en Dow Jones, para su sistema de Telerate (Sistema de informacin
que distribuye del valor de las acciones de la bolsa de Dow Jones, Nueva York).
MOSES es un compendio de:
1. Un ciclo de vida de desarrollo de software basado en el modelo de ciclo de vida
fuente orientado a objeto.
2. Un ciclo de vida del producto con 3 etapas orientadas al negocio.
3. Un ciclo de vida de procesos con 5 fases solapadas orientadas a la parte tcnica.
4. Un conjunto de 20 actividades que componen una detallada gua de pasos a seguir.
Ventajas que ofrece MOSES:
Incorpora diagramas de modelizacin de negocio.
Consigue unos procesos mejores.
Da soporte a la reutilizacin.
Las extensiones y modificaciones son ms fciles de gestionar.
Est enfocada a la calidad.
Crea una arquitectura flexible.
Consigue una gestin adecuada de proyectos complejos.
Da soporte a herramientas CASE.
Modelo Fuente
El modelo fuente nos da un ciclo de vida de desarrollo software (SDLC) muy iterativo y
recursivo, que es especialmente adecuado para la construccin de software orientado a
objeto. Las ventajas de la reutilizacin y el anlisis y diseo de dominios estn
incorporadas, y as se consigue un modelo semnticamente muy rico, aunque flexible.
En este modelo (que viene a reemplazar al modelo cascada usado en anlisis
estructurado) aunque las fases son consecutivas, encontramos un considerable
solapamiento.
Pg. 64.
La creacin de sistemas orientados a objeto es ms propicia a enfocarla en secciones,

denominadas clusters o subsistemas (conjuntos de clases que van a trabajar conjunta y
estrechamente). Bien, pues esta metodologa da soporte a esta forma de trabajo,
proponiendo un nuevo modelo fuente interno para cada uno de estos subsistemas.
Como en el desarrollo de aplicaciones orientadas a objeto se busca un alto nivel de
granuralidad, el solapamiento entre fases es significativamente menor, aunque la
iteracin sigue siendo una importante componente del proceso del ciclo de vida. La
generalizacin y reutilizacin son tratadas especficamente.
Figura 42. Modelo fuente del ciclo de

vida de MOSES
Pg. 65.
Ciclo de vida del producto

Existen 3 etapas orientadas al negocio que son: Planificacin, construccin y entrega
(que se repiten recursivamente en cada versin generada del producto software). Tanto
la primera como la ltima han de involucrar al usuario, y comprenden las decisiones
generales, mientras que la parte de construccin sera ms tcnica.
La parte de construccin es en la que se generan ms assets, y suele tener las siguientes
fases internas: Planificacin, investigacin (estas 2 comprenden el periodo de
crecimiento), especificacin, implementacin y revisin.
Assets generados
1. En la etapa de planificacin de negocio:
El estudio de planificacin de negocio. Es un asset textual, es decir es una descripcin
realizada en algn procesador de textos en lenguaje natural.
2. En la etapa de construccin:
- 8 textuales: El plan de iteracin, la especificacin de requisitos del usuario, el glosario
de escenarios y actores, la especificacin de clases, la especificacin de
responsabilidades de los subsistemas, el cdigo fuente, resultados de las pruebas y
resultados de la revisin.
De estos 8 destacan 2:
*) La especificacin de clases (descripcin de cada clase que aparecer en el
modelo de objetos y clases) que puede hacerse en una sintaxis formal basada en la
usada en Eiffel o usando una sintaxis ms informal.
*) La especificacin de responsabilidades de los subsistemas, que es usada para
documentar los nombres de los distintos subsistemas, sus servicios, sus
responsabilidades y colaboraciones. Tambin se le conoce como SRS. Se usa un
mecanismo similar a las tarjetas de clase (CRC).
- 5 grficos: El modelo de clases y objetos, el modelo de eventos, los diagramas de
objetos, el modelo de herencia y el modelo de estructuras de servicios:
1. El modelo de clases y objetos (O/C Model) es el principal asset de MOSES.
Representa la estructura esttica del sistema (las clases, sus servicios y relaciones
con otras clases). (Figura 1: parte superior izquierda).
2. El modelo de herencia (inheritance model) se usa para mostrar la herencia que se
produzca entre las diferentes clases, y aunque se puede integrar en el modelo
anterior, se suele hacer en este otro. (Figura 1: parte superior derecha)
3. El diagrama de objetos (objectchart) muestra las clases que presentan
comportamiento dinmico. Muestra los diagramas de transicin de estados aplicados
a clases. (Figura 1: parte inferior izquierda).
4. El modelo de eventos (event model) muestra las clases que presentan
comportamiento dinmico. Muestra las secuencias de paso de mensajes entre un
conjunto de objetos que colaboren. Se suelen usar para formalizar escenarios o casos
de uso. (Figura 1: parte inferior derecha)
Pg. 66.
5. El modelo de estructuras de servicio (SMM model) se suele usar significativamente

bastante menos. Se aplica al diseo de la estructura interna de los mtodos.
Figura 43. Modelos grficos principales de MOSES

En la figura se observan : El modelo de clases y objetos( parte superior izquierda), El
modelo de herencia (parte superior derecha), El diagrama de objetos (parte inferior
izquierda) y El modelo de eventos (parte inferior derecha).
3. En la etapa de entrega:
Estudio de la etapa de entrega (incluye el manual del usuario). Es un asset textual.
Adems de todas estas tcnicas, para poder enfrentarse a proyectos complejos se
incluyen cuatro tcnicas (hojas, repositorio, visibilidad selectiva y subsistemas).
Proceso de Ciclo de Vida (las 20 actividades)

El proceso de ciclo de vida (process lifecycle) se ocupa de la etapa de construccin ya
mencionada. Es dividida en cinco fases (planificacin, investigacin, especificacin,
implementacin y revisin). Las fases cubren la parte de gestin, diseo y construccin
Pg. 67.
de los diferentes assets. Es un proceso altamente iterativo, reconstruyendo los assets en

cada una de las iteraciones.
Los assets (de la etapa de construccin) son generados desde cada actividad que
compone el proceso de ciclo de vida. Dependiendo de la profundidad a la que se llegue
en una interaccin se conseguir realizar menos iteraciones, pero, por el contrario, con
poca profundidad podra obtenerse rpidamente un prototipo de la aplicacin.
Se compone de 20 actividades, que se recomienda sean ampliadas (por ejemplo en el
diseo de bases de datos, concurrencia, procesos distribuidos y computacin en tiempo
real).
Las 20 actividades son las siguientes:
1. Contrato de especificacin: Es un documento que describe el servicio a prestar,sin
entrar en su implementacin. MOSES recomienda el uso de afirmaciones
(precondiciones, postcondiciones...) para formar un contrato que describir los
servicios que cumplir. Estos contratos son constantemente refinados y actualizados
durante el proceso de desarrollo.
2. Revisin de la documentacin: Debe ser llevada a cabo a unos intervalos regulares o
en unos puntos predeterminados para asegurar la existencia, precisin y consistencia
de los assets producidos hasta el momento.
3. Construccin del modelo de eventos: Sirve para descubrir la secuencia de mensajes
que se pasan entre los objetos como resultado de la solicitud de un servicio. Muestra
las colaboraciones de los objetos y clases para llevar a cabo un determinado
servicio. Para completar esta actividad debemos identificar las clases, servicios y
mensajes que estn involucrados en un escenario en particular.
4. Generalizacin para la reutilizacin: Permite mejorar la calidad de las clases del
proyecto, para una futura reutilizacin fuera del proyecto actual. Hay 3
subactividades para la generalizacin: Completar la abstraccin, Optimizacin de
algoritmos y Refinamiento de las jerarquas de clases.
5. Especificacin genrica: Para asegurarse que las clases y objetos genricos han sido
descubiertos y especificados en el sistema. Una vez definidos, estas clases y objetos
genricos pueden formar una librera de clases reutilizables en futuros proyectos.
6. Identificacin de la herencia: Identifica las jerarquas entre las clases. MOSES refina
el concepto de herencia en generalizacin y herencia de implementacin.
7. Especificacin de la interacin: Es usada para identificar y definir relaciones entre
clases desde los escenarios y la especificacin de requisitos del usuario, o desde el
modelo de eventos y diagrama de objetos. Existen subactivides para especificar
agregaciones, asociaciones e invariantes.
8. Plan de iteracin del desarrollo: Es usado primordialmente en la fase de
planificacin para desarrollar un plan de proyecto que detalle los recursos
necesarios, objetivos y plazos de la prxima iteracin.
9. Incorporacin a la librera de clases: Es para la identificacin y maximizacin de la
reutilizacin de las libreras de clase existentes. La librera ser investigada para
determinar si las clases existentes en libreras son adecuadas para usarlas en este
proyecto.
Pg. 68.
10. Construccin del diagrama de objetos: Se usa para construir una herramienta grfica
llamada diagrama de objetos, que es una extensin de los diagramas de estados y
representa los cambios de estados de las clases individuales. Adems puede ser
usado para especificar completamente el comportamiento de los objetos, de las
clases e identificar comportamientos errneos. Para construir un diagrama de
objetos, se debe identificar primero todos los estados aplicables a los objetos y todas
las transiciones entre estos estados.
11. Identificacin de clases y objetos: Es una actividad para modelizar las actividades,
identificar y especificar completamente todas las clases y objetos en el dominio del
sistema de la aplicacin. Esta actividad puede ser dividida en subactividades: refinar
la lista de clases iniciales e identificar las clases persistentes.
12. Optimizacin: Vale para optimizar en el diseo, con cambiar la estructura de las
clases y sus interfaces. Requiere el conocimiento profundo de los aspectos fsicos de
la plataforma hardware en que implementaremos el producto.
13. Evaluacin de la calidad (medidas): Asegura que la clase generalizada para su
reutilizabilidad posee la garanta suficiente. Las mtricas juegan un rol
insignificante.
14. Desarrollo de escenarios: Usa el lenguaje natural para implementar la secuencia de
interaccin (los casos de uso) con un sistema desde el cual las clases, los eventos y
las interacciones pueden ser identificados. Las acciones en el sistema son
primeramente identificados, y entonces los escenarios pueden ser asociados a cada
actor.
15. Identificacin de los servicios: Ayuda a comprender el comportamiento de los
objetos, mediante la especificacin de los servicios aplicables a una clase u objeto.
Los servicios pueden ser tanto operaciones como propiedades.
16. Coordinacin de los subsistemas: Es usado en la gestin de tareas de proyectos
grandes para descubrir redundancias potenciales y asociar la responsabilidad de una
clase a un grupo de trabajo.
17. Identificacin de subsistemas: Ayuda a manejar sistemas complejos.
18. Prueba: Da soporte a la verificacin y validacin del diseo y el cdigo generado.
19. Traduccin al Lenguaje de Programacin Orientado a Objeto (OOPL): Es
bsicamente la fase de implementacin de un proyecto. Los servicios y estructuras
han de codificarse en un determinado lenguajes y plataforma.
20. Revisin de los requisitos del usuario: Desarrolla y define una especificacin de
requisitos formal y estable.
Estas veinte actividades estn asociadas en la tabla siguiente con las fases (proceso del
ciclo de vida). Las actividades pueden suceder en ms de una fase:
Pg. 69.
Figura 44. Relacin entre las 20 actividades y las fases en que se realizan
en la metodologa MOSES
Pg. 70.
BON
BON es una metodologa de Ingeniera de Software que se inscribe en la categora de
metodologas puramente orientadas al objeto. Tiene su origen en la filosofa de diseo
y programacin por contrato, junto con algunas caractersticas del modelo de objetos
propuesto por el lenguaje Eiffel y diversas influencias del proyecto europeo ESPRIT II
(Research and Development Program).
Aunque BON (Business Object Notation) suele aparecer como una metodologa ligada
al lenguaje Eiffel, su concepcin es independiente de ste. Sin embargo muchas de sus
tcnicas encuentran un equivalente inmediato en Eiffel en el proceso de
implementacin, lo cual facilita la construccin de herramientas CASE que simulen la
metodologa orientadas a este lenguaje en particular.
BON es un mtodo y una notacin para un anlisis y diseo orientados a objeto de
sistemas de alto nivel. Algunas de sus caractersticas ms destacables son:
Hace nfasis en permitir un desarrollo sin transiciones.
Hace posible la reutilizacin del software a gran escala.
Refleja la confianza necesaria para hacer que los componentes reutilizables se

acepten y utilicen por la industria del software.
Sus principios fundamentales son:
Desarrollo sin costuras (Seamlessness).
Reversibilidad.
Software contractual.
Simplicidad.
Escalabilidad.
Principios fundamentales
Desarrollo sin costuras (Seamlessness).
El desarrollo sin costuras es el principio de utilizar un conjunto consistente de conceptos
y notaciones a travs del ciclo de vida del software, evitando lo que su falta genera en
los mtodos tradicionales.
Una ventaja muy importante del seamlessness es que facilita los procesos de traduccin
automtica.
Reversibilidad.
Este principio complementa el proceso sin costuras, garantizando que los cambios
realizados en cualquier paso del proceso, incluso en la implementacin o el
mantenimiento, puedan reflejarse hacia atrs en los primeros pasos, incluyendo el
anlisis.
Pg. 71.
Si esto no fuera posible los primeros niveles de modelado pasan a ser obsoletos dejando
solamente el cdigo fuente de la implementacin como especificacin del sistema, con
todos los inconvenientes que esto supone.
Software contractual.
Con este principio la especificacin de un gran sistema est distribuida entre todas sus
partes componentes. Las responsabilidades de cada abstraccin (clase) estn
especificadas por contratos expresados en funcin de otras abstracciones.
Simplicidad.
El principio de simplicidad indica que hay que minimizar el nmero de conceptos
utilizados.
Escalabilidad.
El principio de escalabilidad se manifiesta en trminos de la capacidad de soportar un
formalismo para representar grupos de clases progresivos y soportar la divisin del
problema, basada en capas de abstraccin como manejo de la complejidad estructural.
Proceso de Anlisis
El objetivo del anlisis es poner un cierto orden en nuestra concepcin del mundo real.
El propsito es simplificar, dominar la complejidad mediante la reformulacin del
problema. Hay que eliminar redundancias y ruidos, encontrar inconsistencias, posponer
decisiones de implementacin, dividir el espacio del problema...
BON considera que el anlisis se convierte en diseo cuando se toman decisiones de
implementacin, cuando se introducen grados de proteccin para la informacin o
cuando se introducen clases que no estn relacionadas con el espacio de objetos del
problema.
Proceso de diseo
El diseo es un proceso que toma por entrada una representacin del problema y la
transforma en una representacin de la solucin, regresando al anlisis si es necesario.
En el diseo, las clases obtenidas en el anlisis se extienden, generalizan y se transforma
su representacin en un esquema fcilmente traducible a un lenguaje de programacin
orientado al objeto.
Se aade la especificacin de nuevas clases que aparecen como interfaz con el exterior
del sistema, otras que son de utilidad bsica para la construccin del sistema (clases
contenedoras...) y aquellas que son consideradas como clases de aplicacin que tratan
con informacin dependiente de la mquina o del sistema, con persistencia de objetos,
manejo y recuperacin de errores.
En BON se modelan tanto el espacio del problema, como el espacio de la solucin,
como abstracciones de datos que encapsulan servicios. En el modelado, aunque lo
primero en que se piense sea en un servicio, debe buscarse la abstraccin (clase)
subyacente que representa a aquellos individuos que ofrecen tal servicio.
Pg. 72.
El primer principio es considerar las clases como una representacin de tipos de datos
abstractos que tienen un estado interno y ofrecen servicios, opuesto al criterio las cosas
que hacen que est ms cerca de las tcnicas procedurales.
Las clases no se ubican aisladamente sino que se agrupan en clusters. Durante el
anlisis, los clusters ayudan ya que agrupan clases de acuerdo con un criterio de
proximidad basado en funcionalidad de subsistema, en nivel de abstraccin o en el
punto de vista del usuario final. En el diseo, son utilizados frecuentemente como una
tcnica estructurada para visualizar selectivamente las conexiones entre las clases. Es
muy comn comenzar por un cluster general y luego ir determinando otros despus de
haber hecho ciertos agrupamientos de clases.
Es importante ubicar el lugar de una clase dentro de la estructura completa. Esto implica
que encontrar clases relacionadas es ms significativo que encontrar una clase aislada.
Cada etapa en BON (anlisis y diseo) refina el modelo general desde dos puntos de
vista distintos: arquitectura y comportamiento. El resultado es un modelo subdividido
en modelo esttico y modelo dinmico. Las actividades globales, que se describen en la
metodologa para ir creando dichos modelos se describen en la Tabla A mientras que en
la Tabla B y en la Figura 46 se describen los elementos grficos ms generales que se
utilizan en la descripcin del modelo.
Es de destacar, que se propone comenzar un proceso de generalizacin. En este proceso
debe analizarse si la arquitectura del sistema es suficientemente general para maximizar
futuras reutilizaciones. De esta manera, del conjunto de clases obtenidas se factorizan
recursos comunes en clases de alto nivel (por herencia o por genericidad) y las clases
existentes se convierten en versiones especializadas de estas ltimas.
Pg. 73.
TAREA
Encontrar clases
Clasificar
Encontrar clusters
Definir los recursos de las

clases
Seleccionar y describir
escenarios de objetos
Especificacin
de
las
condiciones contractuales.
Refinar el sistema.
Incrementar el potencial de
reusabilidad
Indexar y Documentar
Evolucionar la arquitectura
del sistema
DESCRIPCIN
ESQUEMA
Delinear la frontera del sistema. Encontrar subsistemas, Tabla de Sistema (System Chart),
metforas de los usuarios, casos de uso.
Tablas de Escenarios (scenario Charts)
Listar clases candidatas. Crear un glosario de trminos Tabla de Clusters (Clusters Chart)
tcnicos.
Tabla de Sistema (System Chart),
Seleccionar clases y agruparlas en clusters. Clasificar, Tabla de Clusters (Clusters Chart),
esbozar colaboraciones fundamentales entre clases
Arquitectura (Static Architecture),
Diccionario de clases (Class Dictionary)
Definir las clases. Determinar comandos (Qu servicios
pueden solicitar otras clases a esta?), consultas (Qu
informacin pueden preguntar otras clases a esta?) y Tablas de Clases (Class Charts)
restricciones (Qu conocimiento debe mantener la
clase?)
Esbozar el comportamiento del sistema. Identificar Tablas de Eventos (Event Charts),
eventos, creacin de objetos y escenarios relevantes Tablas de Escenarios (Scenario Charts),
derivados de la utilizacin del sistema
Tablas de Creacin (Creatio Charts),
Escenarios de Objetos (Object Scenarios)
Definir los recursos pblicos. Especificar tipos, Interfaz de clases (Class Interfaces),
signaturas y contratos formales.
Arquitectura (Static Architecture)
Interfaz de clases (Class Interfaces),
Encontrar nuevas clases de diseo, adicionar nuevos Arquitectura (Static Architecture),
recursos.
Diccionario de clases (Class Dictionary),
Tablas de Eventos (Event Charts),
Escenarios de Objetos (Object Scenarios)
Interfaz de clases (Class Interfaces),
Generalizar. Factorizar comportamiento comn.
Arquitectura (Static Architecture),
Diccionario de clases (Class Dictionary)
Documentar explcitamente la descripcin de una clase
mediante la clusula de indexado.
Completar la Interfaz de clases (Class Interfaces)
informacin de documentacin en el diccionario de Diccionario de clases (Class Dictionary)
clases.
Completar y revisar el sistema. Producir una arquitectura Modelos esttico y dinmico finales de
final con un comportamiento del sistema.
BON. Todos los esquemas completados.
Tabla A. Actividades globales de BON.

Tabla de Sistema (System Chart): Definicin del sistema y lista de los clusters asociados. Solamente
una Tabla de sistema por proyecto. Los subsistemas se describen mediante su correspondiente Tabla de
Cluster.
Tablas de Clusters (Cluster Charts): Definicin de clusters y lista de las clases asociadas y subclusters,
si los hay. Un cluster representa un subsistema completo slo un grupo de clases.
Tablas de Clases (Class Charts): Definicin de las clases de anlisis en trminos de comandos, consultas
y restricciones, de forma que sea entendible para los expertos en el dominio y personal no tcnico.
Diccionario de Clases (Class Dictionary): Una lista alfabticamente ordenada de todas las clases del
sistema, mostrando el cluster al que pertenece cada clase y una breve descripcin. Debe poder ser
generada automticamente de las Tablas de Clase y de Interfaz.
Arquitectura (Static Architecture): Conjunto de diagramas que posiblemente representan clusters
anidados, encabezamientos de clases y sus relaciones. Una vista del sistema (con posibilidades de hacer
zoom)
Interfaz de Clases (Class Interfaces): Definiciones tipadas de las clases con la signatura de los recursos
y contratos formales con un lenguaje basado en el clculo de predicados. Vista detallada del sistema
Tablas de Creacin (Creation Charts): Lista de las clases que estn a cargo de crear instancias de otras
clases. Normalmente se hace una para el sistema pero si se desea se puede incluir una por subsistema.
Tablas de Eventos (Event Charts): Conjunto de eventos externos (estmulos) que disparan algn
comportamiento interesante del sistema y el conjunto de respuestas del sistema. Puede ser repetido para
cada subsistema.
Tablas de Escenarios (Scenario Charts): Lista de los escenarios de objetos utilizados para mostrar algn
comportamiento interesante y representativo del sistema. Los subsistemas pueden contener Tablas de
Escenario locales.
Escenarios de Objetos (Object Scenarios): Diagramas dinmicos que muestran comunicaciones
relevantes entre objetos para algunos o todos los escenarios que se describen en las Tablas de Escenarios.
Tabla B. Elementos ms caractersticos de BON.
Pg. 74.
Figura 45. Elementos grficos de BON
Pg. 75.
La Unificacin de Mtodos
Despus de explicar varias metodologas (orientadas a objeto), se puede observar que, a
pesar de algunas notables diferencias existentes entre unas y otras, todas persiguen un
mismo objetivo: la obtencin de un software de calidad dentro del paradigma de la
orientacin al objeto.
Por lo tanto se puede llegar fcilmente a la conclusin de que se intentar llegar a una
unificacin de los diferentes mtodos.
He aqu una serie de motivos que tambin contribuyen a esta tendencia:
El esfuerzo por la estandarizacin y la convergencia en la orientacin al objeto.
Los avances en herramientas CASE OO.
El inters por el modelado de negocios mediante objetos.
Comenzarn a surgir: UML, OPEN...
UML (Unified Modelating Languaje)

Proviene sobre todo de: Booch93, OMT93 y OOSE.
La idea de unificacin pretende en un principio estabilizar el caos existente en las
metodologas orientadas a objeto, as como la aparicin de un modelo ms rico,
producto del intercambio de experiencias en las tres metodologas gnesis de UML.
Es un lenguaje para especificar, construir, visualizar y documentar ingenios software,
cuyo alcance pretende cubrir los conceptos de Booch, OMT y OOSE resultando un
lenguaje simple, comn y ampliamente utilizable por usuarios de otras metodologas.
UML no es una metodologa OO, sino una notacin universal. El utilizar un lenguaje de
modelado estandar le da un valor aadido.
Es un lenguaje para representar los modelos que se obtienen a partir de la aplicacin de
cualquier metodologa OO.
UML no fuerza a utilizar ninguna metodologa concreta, porque presupone que distintos
dominios de problemas conducen a diferentes mtodos de anlisis y diseo.
En su versin 1.0 los principales elementos son: un metamodelo y una semntica, una
notacin grfica y un conjunto de recomendaciones.
OPEN.
OPEN fue creada en un principio a partir de una mezcla de algunas metodologas de
segunda generacin (MOSES, SOMA y The Firesmith Method).
Es esencialmente un armazn para la tercera generacin de mtodos de desarrollo
software en la orientacin al objeto, suministrando un gran soporte para el proceso de
modelado mediante el uso de modelos de ciclo de vida, mediante una captura de
requisitos, y ofreciendo la habilidad de modelar o construir agentes inteligentes.
Pg. 76.
OPEN tambin toma conceptos de BON, Martin/Odell, OBA, RDD, ROOM, UML y
otros.
Ofrece un conjunto de principios para el modelado de todos los aspectos del desarrollo
software: ciclo de vida, tareas, tcnicas y modelado del lenguaje.
OPEN extiende el concepto de metodologa, no slo incluyendo un modelo de procesos,
sino tambin suministrando lneas para construir versiones del mtodo que se ajusten a
las necesidades del dominio industrial, organizaciones individuales...
Los elementos principales de esta metodologa son:
Ciclo de vida o metamodelo.
Tcnicas.
Representacin.
Se ha conseguido una metodologa que comprenda, al menos, un conjunto de tcnicas,
ms un modelo de ciclo de vida y una representacin.
Figura 46. Elementos principales de OPEN.
Las actividades de OPEN tienen tareas que se ejecutan y se completan gracias a las
tcnicas.
Pg. 77.
Figura 47. Descomposicin de procesos en OPEN.
OPEN representa la cspide de los logros obtenidos en los mtodos de orientacin al

objeto por decenas de metodologas y un posible camino a seguir en un futuro todava
incierto. Es de dominio pblico.
Pg. 78.
Conclusin
Los mtodos orientados a objeto presentan una visin idealizada del desarrollo de
software. Describen una manera lgica, racional y sistemtica de desarrollar software
orientado a objeto. En la prctica, el desarrollo no se hace de una manera tan ordenada.
Presentar el proceso de desarrollo de una manera racional hace ms fcil ilustrar las
dependencias y relaciones entre las diferentes fases del desarrollo. El desarrollo del
software real no refleja semejante proceso racional pero la documentacin producida
refleja, y en algn sentido "imita", el proceso racional.
En el mundo empresarial la reutilizacin es uno de los valores aadidos que puede
presentar un elemento software, y en este sentido la orientacin a objetos presenta una
de sus mayores virtudes, pero esta cualidad perder potencia si no se desarrolla bajo los
parmetros que ofrece una metodologa.
Cualquiera de las metodologas explicadas es vlida para trabajar en la orientacin al
objeto. Sin embargo hoy en da se tiende a una unificacin de los mtodos, tal y como
se ha visto en el apartado correspondiente. En este sentido cabe destacar la metodologa
Objetory, que en breve ser publicada por Los 3 Amigos (Booch, Rumbaugh y
Jacobson), que se perfila como la metodologa con ms futuro y posiblemente la
unificadora de todas las publicadas actualmente. Una de las ventajas que ofrece esto es
el hecho de utilizar una misma notacin que todo el mundo comprenda y que no de
lugar a ambigedades.
Para poder llegar a esa unificacin se ha de estudiar cada una de las metodologas
existentes para poder tomar lo mejor de cada una de ellas.
En este documento se han visto metodologas de todo tipo. Desde la menos rigurosa
(que da una libertad de realizacin mayor al usuario) como puede ser Booch, hasta la
ms estricta como es el caso de SMM. En cada caso y circunstancias concretas una u
otra metodologa ser ms adecuada, llegando incluso al extremo de combinar varias
(Ej: usar el modelo de objetos de Booch y los 3 modelos de OMT).
En cada una de las metodologas estudiadas destacan uno o varios aspectos. As pues,
Booch se centra en el diseo, OOSE en los casos de uso, SMM en los dominios, OMT
en el anlisis...
La mayora de las metodologas son una evolucin de otra u otras metodologas. As por
ejemplo FUSION es una metodologa de segunda generacin que ha heredado bastantes
elementos de otras metodologas: el modelo de objetos de OMT, la interaccin de CRC,
la visibilidad de BOOCH, las precondiciones y postcondiciones de los mtodos
formales, etc.
Para esta evolucin sea posible tendr que haber elementos de gran calidad en alguna de
las metodologas para que sta pueda ofrecerlos a otras metodologas. As por ejemplo
OMT ofrece un modelo de objetos que contiene una enorme riqueza semntica, por lo
que ha sido adoptado por casi todas las metodologas de segunda generacin. La ya
mencionada unificacin de los mtodos tiene un fuerte compromiso en este sentido.
El hecho de que una metodologia presente algunas debilidades no quiere decir que no
sea vlida. Esto es algo que puede apreciarse muy bien en OMT, la cual posee un
Pg. 79.
modelo funcional bastante criticado y sin embargo es la ms difundida actualmente,

dada la solidez del resto de sus elementos.
Existen metodologas que cubren las fases tpicas de anlisis, diseo e imlpementacin
(aunque algunas se centran slo en el anlisis y el diseo) mientras que tambin hay
metodologas cuyo alcance se extiende a ms partes del desarrollo. En concreto MOSES
abarca, adems de lo anterior, la gestin de proyectos, la planificacin del negocio, el
mantenimiento de la aplicacin. Posee unas tcnicas de gestin avanzadas no existentes
en ninguna otra de las metodologas. Es por esto que se perfila como una de las
metodologas de mayor futuro a la hora del desarrollo de un software de calidad.
En principio las metodologas son independientes de cualquier lenguaje de
programacin. Sin embargo, en la prctica puede demostrarse que en algunos casos hay
una relacin entre lenguajes y metodologas. Por ejemplo la metodologa BON est muy
ligada al lenguaje Eiffel, sobre todo en la fase de implementacin.
Existen acutalmente en el mercado diversas herramientas CASE que ayudan a
desarrollar bajo la filosofa de muchas de las metodologas (especialmente las de
segunda generacin).
Algo comn a todas ellas es que tengan unas reglas o pasos marcados a seguir, y una
notacin que no de lugar a ambigedades (al menos entre los usuarios de una misma
metodologa). Para evitar las ambigedades entre todas las personas que trabajan en el
mundo de la orientacin al objeto ya estn surgiendo los mtodos unificados como
UML, OPEN, etc. )
Hoy en da no se puede concebir la orienacin al objeto (y el desarrollo de software en
general) sin que existan por debajo unos mtodos de trabajo que marquen unas pautas a
seguir.
Pg. 80.
Bibliografa
[Bailin, 1989] Bailin, S.C., An Object-Oriented Requirements Specification
Method. Communications of the ACM. Vol.32 n5, Mayo 1989.
[Beck, 1989] Beck, K. and Cunningham, W. A laboratory for teaching objectoriented thinking. OOPSLA '89, SIGPLAN Notices. 1989.
[Booch, 1991] Booch, G., Object-Oriented Design with Application. Redwood
city, Benajmin/Cummings Publising Company. 1991.
[Booch, 1994] Booch, G., Object-Oriented Design with Application. Redwood
city, Benajmin/Cummings Publising Company. 1994.
[BooRubin y Goldberg 1992] Rubin, K. y Goldberg A. Object Behaviour
Analysis. CACM Vol.25 n9. 1992.
[Carnigie-Mellon U. 1996] Carnegie-Mellon University. "Teaching Model-based
Software Engineering". OBJECT MAGAZINE. Enero 1996.
[Coleman et al. 1994] Dereck Coleman, Patrick Arnold, Stepahnie Bodoff,
Chris Dollin, Helena Gilchrist, Fiona Hayes, Paul Jeremes. Object-Oriented
Development: The Fusion Method. Prentice Hall 1994, ISBN 0-13-338823-9.
Prentice Hall International Edition 1994, ISBN 0-13-101040-9
[Cook y Daniels, 1994] Cook, S. y Daniels, J. Designing Object Systems:
Object-Oriented Modelling with Syntropy. Prentice Hall. 1994.
[Fichman y Kemerer, 1992] Fichman, R..G y Kemerer, C.F., Object-Oriented
and Conventional Analysis and Design Methologies. IEEE Computer. Octuber
1992.
[Garca, 1997] Francisco Jos Garca Pealvo. Apuntes de la Asignatura
Anlisis e Ingeniera del Software. Universidad de Burgos. 1997.
[Garca, 1998] Francisco Jos Garca Pealvo. Apuntes de la Asignatura
Programacin Avanzada. Universidad de Burgos. 1998.
[Graham et al. 1997] The Open Process Specification. Ian Graham, Brian
Henderson-Sellers, Houman Younessi. Editorial. Addison-Wesley. 1.997.
[Henderson-Sellers y Edwars 1994] Henderson-Sellers, B. y Edwars, J.M.
MOSES: A second generation object-oriented methodology. Object Magazine.
Junio 1994.
[Henderson-Sellers, 1992] Henderson-Sellers, B., Edwards, J.M. and
Constantine,
L.L.
The
O-O-O/EUON
Handbook,
Centre
for
InformationTechnology Research Report No. 58, University of New South Wales,
Sydney, Australia. 1992.
[Jacobson el al. 1992] Jacobson J. et al. Object-Oriented Software Engineeering.
A Use Case Driven Approach. ACM Press, Addison-Wesley. 1992
Pg. 81.
[Maddison, 1983] Maddison, R.N. Information System Methodologies. Wiley

Henden 1983.
[Martin y Odell, 1992] Martin, J. y Odell J. Object Oriented Analysis and
Design. Prentice-Hall. 1992.
[Martin, 1993] Martin J. Principles of Object-Oriented Analysis and Design,
Prentice-Hall. ISBN 0-13-720871-5.
[Meyer 1992] Meyer, B. Eiffel: The Language. Prentice Hall, New York.1992.
[Meyer, 1988] Meyer, B. Object-oriented Software Construction. Prentice Hall,
Hemel Hempstead. 1988.
[Meyer, 1989] Meyer, B. From structured programming to object-oriented design:
the road to Eiffel, Structured Programming, 1989.
[Page-Jones et al. 1990] Page-Jones, M. Constantine, L.L., and Weiss, S.
Modeling object-oriented systems: the Uniform Object Notation. Computer
Language. 1990.
[Piattini 1994] Piattini, M.G. Definicin de un ametodologa para el desarrollo
de bases de datos orientadas al objeto fundamentadas en extensiones del modelo
relacional. Tesis doctoral, Facultad de Informtica, Universidad Politcnica de
Madrid. 1994.
[Piattini et al. 1996] Mario G. Piattini Velthuis, Jos A. Calvo-Manzano,
Joaqun Cervera y Luis Fernndez. Anlisis y Diseo Detallado de Aplicaciones
Informticas de Gestin. Ra-ma. 1996.
[Renouf y Henderson, 1995] Renouf, D.W. y Henderson-Sellers, B. A
Incorporating roles into MOSES. Prentice Hall. 1995.
[Rumbaugh et al. 1991] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W.
Lornsen. Object-Oriented Modeling and Design. Prentice-Hall International
Editions. ISBN 0-13-630054-5
[Shlaer y Mellor, 1988] Sally Shlaer and Stephen J. Mellor. Object-Oriented
Systems Analysis: Modeling the World in Data. Prentice Hall. 1988.
[Shlaer y Mellor, 1990] Sally Shlaer and Stephen J. Mellor. Recursive Design,
in Computer Language. Miller Freeman, Inc. 1990.
[Shlaer y Mellor, 1992] Sally Shlaer and Stephen J. Mellor. Object Lifecycles:
Modeling the World in States. Prentice Hall. 1992.
[Singer, 1993] Singer, G. An electric approach to developing an Object-Oriented
methodology. Object Magazine. Noviembre/Diciembre 1993.
[Steegmans et al, 1995] Steegmans, E., Lewi, J., D'Haese, M., Dockx, J., Jehoul,
D., Swennen, B., Van Baelen, S., and Van Hirtum, P. EROOS Reference
Manual Version 1.0. Department of Computer Science, Katholieke Universiteit
Leuven. 1995.
[Wirfs-Brock et al., 1990] Wirfs-Brock, R.J., Wilkerson, B. and Wiener, L.
Designing Object-Oriented Software. Prentice Hall. 1990.
Pg. 82.

Metodologias1 121105164855 Phpapp01.Desbloqueado

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Metodologias1 121105164855 Phpapp01.Desbloqueado

Загружено:

Авторское право:

Доступные форматы

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

IGNACIO CRUZADO NUO

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Proceso de Anlisis .......................................................................................................................... 38

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Gestin de un Desarrollo Fusion ..................................................................................................... 55

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Metodologas orientadas a objetos.

Booch, como punto de partida de los conceptos de la orientacin a objetos.

OMT, como la metodologa ms difundida en los desarrollos realizados

Fusion, como ejemplo de metodologa proveniente de otros mtodos (2

Hoy en da se est trabajando en buscar una unificacin de mtodos. En esta lnea se ha

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Revolucionarias o puras, que extienden la orientacin al objeto como un cambio

Sintetistas o evolutivas, que piensan que el anlisis y diseo estructurados

ltimamente estn apareciendo nuevas metodologas de desarrollo orientado al objeto,

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Otra posible clasificacin, en funcin de en qu se centran, es:

Metodologas dirigidas por los datos (data-driven)

OMT (Rumbaugh et al. 1991)

FUSION (Coleman et al. 1994)

Metodologas dirigidas por las responsabilidades (responsability-driven)

RDD (Wirfs-Brock et al. 1990)

OBA (Rubin y Goldberg 1992)

Metodologas dirigidas por los casos de uso (use case-driven)

OOSE (Jacobson et al. 1992)

Metodologa de Shlaer y Mellor 1992)

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

El modelo del objeto

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Es el proceso de almacenar en un mismo compartimento los elementos de una

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Comprobacin estricta: un objeto slo pude realizar aquellas operaciones que se

Un objeto tiene estado: el estado de un objeto abarca todas las propiedades

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Un objeto tiene comportamiento: el comportamiento de un objeto es cmo acta

Un objeto tiene identidad: la identidad ser aquella propiedad que lo distingue

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

La naturaleza de una clase

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

El concepto de agregacin entre clases es equivalente al explicado para la relacin entre

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto

Existen unos cuantos mtodos para el anlisis de sistemas en orientacin al objeto:

Trabajo Terico de Programacin Avanzada.

Metodologas Orientadas a Objeto