Metodologias[1]

Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto

3º I. T. INFORMÁTICA DE GESTIÓN
PROGRAMACIÓN AVANZADA

IGNACIO CRUZADO NUÑO
JORGE GARCÍA DEL EGIDO
JAVIER PORTUGAL ALONSO

Pág. 1.


RESUMEN ................................................................................................................................................. 4
PALABRAS CLAVE ................................................................................................................................... 4
METODOLOGÍAS ORIENTADAS A OBJETOS. ................................................................................ 5
INTRODUCCIÓN ........................................................................................................................................ 5
Concepto de metodología................................................................................................................... 5
Generalidades .................................................................................................................................... 6
Clasificaciones ................................................................................................................................... 6
EL MÉTODO DE BOOCH .......................................................................................................................... 8
Introducción. ...................................................................................................................................... 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 interacción de Clases y objetos................................................................................................................14
Construcción de Clases y Objetos de Calidad...............................................................................................14
Clasificación .................................................................................................................................... 15
Aproximación a las clasificaciones...............................................................................................................15
Procedimientos para encontrar clases y objetos............................................................................................15
El método ......................................................................................................................................... 16
Diagramas de clases......................................................................................................................................17
Diagramas de objetos....................................................................................................................................21
Otros diagramas............................................................................................................................................23
Los procesos del desarrollo orientado al objeto ............................................................................................26
Conclusión........................................................................................................................................ 26
Un ejemplo concreto ........................................................................................................................ 26
OMT (OBJECT MODELING TECNIQUE) JAMES RAMBAUGH ................................................................... 28
Visión general .................................................................................................................................. 28
Fases (4)........................................................................................................................................... 28
Pasos específicos a dar en cada fase ............................................................................................... 29
Fase De Análisis ...........................................................................................................................................29
Fase De Diseño Del Sistema.........................................................................................................................30
Fase de Diseño De Objetos...........................................................................................................................30
Implementación ............................................................................................................................................31
Conclusión........................................................................................................................................ 31
Notación ........................................................................................................................................... 31
MÉTODO DE FUSION. COLEMAN ............................................................................................................ 33
Introducción ..................................................................................................................................... 33
Análisis............................................................................................................................................. 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 Análisis .......................................................................................................................... 38
Diccionario de datos .....................................................................................................................................38
Desarrollo del Modelo de Objetos ................................................................................................................39
Determinación de la Interface del Sistema....................................................................................................39
Desarrollo del Modelo de la Interface...........................................................................................................41
Verificando los Modelos del Análisis...........................................................................................................41
Diseño .............................................................................................................................................. 42
Gráfico de Interacción de Objetos ................................................................................................................43
Gráficos de visibilidad..................................................................................................................................47
Descripciones de clase..................................................................................................................................50
Gráficos de herencia .....................................................................................................................................52
Implementación ................................................................................................................................ 55

Pág. 2.


Gestión de un Desarrollo Fusion ..................................................................................................... 55
SMM (SHLAER & MELLOR METHOD) ................................................................................................... 56
Características ................................................................................................................................. 56
Proceso............................................................................................................................................. 56
Principales assets generados ........................................................................................................... 57
EROOS: (ESPECIFICACIONES ORIENTADAS A OBJETO E-R) ................................................................. 58
Introducción ..................................................................................................................................... 58
Características ................................................................................................................................. 58
Ciclo de Vida.................................................................................................................................... 58
Filosofía y Conceptos Contemplados............................................................................................... 59
Notación ........................................................................................................................................... 60
METODOLOGÍA MOSES ........................................................................................................................ 64
Introducción ..................................................................................................................................... 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 Análisis .......................................................................................................................... 72
Proceso de diseño............................................................................................................................. 72
LA UNIFICACIÓN DE MÉTODOS .............................................................................................................. 76
UML (Unified Modelating Languaje) .............................................................................................. 76
OPEN. .............................................................................................................................................. 76
CONCLUSIÓN ......................................................................................................................................... 79
BIBLIOGRAFÍA ....................................................................................................................................... 81

Pág. 3.


Resumen
En el mundo de desarrollo de software, se tiende cada vez más hacia la programación
orientada a objeto, un nuevo paradigma de programación 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 reutilización del código generado.
Pero todo ello no es posible sin seguir una metodología 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 metodologías orientadas a objeto
que existen en la actualidad y dar una visión global de las mismas. Así pues se hace
especial hincapié en OMT (la más difundida actualmente), BOOCH (como punto de
partida de los conceptos que conlleva la orientación a objeto) y FUSION (como una
metodología más desarrollada).
No pasa inadvertido que el futuro de las metodologías se basa en su unificación, y por
ello este documento explica brevemente UML (como notación unificadora) y OPEN
(como metodología). En cualquier caso habrá que esperar a la publicación de
OBJETORY, que se perfila como la metodología unificadora y de más futuro.

Palabras Clave
Metodología, orientación a objeto, ciclo de vida, notación, proceso, Booch, OMT,
Fusion, UML, OPEN, MOSES, EROOS, OOSE, BON, unificación, clase, objeto,
análisis, diseño.

Pág. 4.


Metodologías orientadas a objetos.

Introducción
Con este trabajo se pretende acercar un poco más al lector al mundo de las metodologías
orientadas a objeto. Es un mundo en contínua expansión.
Se tratará de ofrecer una idea global de las metodologías orintadas a objeto y
profundizar algo más en las más conocidas:
• Booch, como punto de partida de los conceptos de la orientación a objetos.
• OMT, como la metodología más difundida en los desarrollos realizados
actualmente.
• Fusion, como ejemplo de metodología proveniente de otros métodos (2ª
generación).
Hoy en día se está trabajando en buscar una unificación de métodos. En esta línea se ha
llegado a una unificación en la notación (UML). No se explicará muy detalladamente
pues merecería un artículo aparte.

Concepto de metodología
No existe un consenso entre los diversos autores sobre el concepto de metodología.
Genéricamente se puede decir que una metodología es un conjunto de pasos que
deben seguirse para el desarrollo de software.
Conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas,
documentación y aspectos de formación para los desarrolladores de sistemas de
información. Según esto, una metodología es un conjunto de componentes que
especifican:
Cómo dividir un proyecto en etapas.
Qué tareas se llevarán a cabo en cada etapa
Qué salidas se producen y cuándo deben producirse.
Qué restricciones se aplican.
Qué herramientas van a ser utilizadas.
Cómo se gestiona y controla el proyecto.
R.N. Maddison

De un modo más general una metodología podría definirse como “un conjunto de
conceptos para poder abstraer el dominio del problema, una notación para representar
esos conceptos, una serie de pasos y procedimientos a seguir, y un conjunto de assets
generados”.

Pág. 5.


Generalidades
Todas las metodologías distinguen estas tres fases:
Análisis
Diseño
Implementación
Según Piattini [Piattini et al., 1996], se puede observar un cambio “filosófico” entre las
metodologías clásicas de análisis y diseño estructurado y las de orientación 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
más pequeñas y que forman los bloques o módulos de las aplicaciones. En la
orientación al objeto, por su parte, cobra mucha más importancia el aspecto de
“modelado” del sistema, examinando el dominio del problema como un conjunto de
objetos que interactúan entre sí.
En las metodologías tradicionales se produce una dicotomía 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 orientación al objeto propugna
un enfoque unificador de ambos aspectos, que se encapsulan en los objetos.

Clasificaciones
Se pueden identificar dos enfoques en las metodologías orientadas al objeto, [Fichman y
Kemerer, 1992]:
• “Revolucionarias” o “puras”, que extienden la orientación al objeto como un cambio
profundo que convierte a las metodologías estructuradas en obsoletas. En este
apartado podrían incluirse metodologías como OOD de [Booch, 1991] o CRC/RDD
de [Wirfs-Brock et al., 1990].
• “Sintetistas” o “evolutivas”, que piensan que el análisis y diseño estructurados
constituyen la base para el desarrollo orientado al objeto, pudiéndose combinar
elementos del análisis y diseño estructurados con los de la orientación al objeto.
Ejemplos de este tipo podrían ser OMT [Rumbaugh et al., 1991], SYNTHESIS
[Bailin, 1989] o [Martin y Odell, 1992].
Últimamente están apareciendo nuevas metodologías de desarrollo orientado al objeto,
catalogadas como de “segunda generación”, basadas en las citadas anteriormente; de las
que formarían 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], MÉTODO UNIFICADO [Booch y
Rumbaugh, 1995] o MEDEA [Piattini, 1994]. En esta segunda generación se
aprovechan las técnicas y los procedimientos de las primeras metodologías,
especialmente las tarjetas de clase (CRCs), el proceso y notación de diseño de [Booch,
1991], el modelo de clases de OMT y los escenarios de Jacobson, con el fin de construir
metodologías más completas y sistemáticas en las que juegan también un papel
relevante las métricas y los lenguajes formales, así como modelos para la mejora del
software, como los del SEI (CMM) o ISO (SPICE).

Pág. 6.


Otra posible clasificación, en función de en qué se centran, es:
• Metodologías dirigidas por los datos (data-driven)
- OMT (Rumbaugh et al. 1991)
- FUSION (Coleman et al. 1994)
• Metodologías dirigidas por las responsabilidades (responsability-driven)
- RDD (Wirfs-Brock et al. 1990)
- OBA (Rubin y Goldberg 1992)
• Metodologías dirigidas por los casos de uso (use case-driven)
- OOSE (Jacobson et al. 1992)
• Metodologías dirigidas por estados (state-driven)
- Metodología de Shlaer y Mellor 1992)

Pág. 7.


El método de BOOCH

Introducción.
El método de Grady Booch es uno de los más conocidos en la orientación al objeto.
En su versión de 1.993 este método cubre las fases de análisis y diseño dentro de un
desarrollo orientado al objeto.
Se definirán una gran cantidad de símbolos para representar las distintas decisiones de
diseño.
Este método ofrece una gran libertad en la producción del software, como ya veremos
más adelante.
En un primer momento se explicarán una serie de conceptos básicos, los cuales han de
quedar claros para poder comprender a fondo la metodología de Booch.
Dichos conceptos se pueden estructurar estructurarlos de la siguiente manera:
Complejidad.
El modelo del objeto.
Clases y objetos.
Clasificación.

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. (Definición 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 técnicas:
Descomposición: consiste en dividir el sistema en partes más y más pequeñas cada vez,
pudiendo ser éstas refinadas independientemente.
Abstracción: la abstracción denota las características esenciales de un objeto que lo
distinguen de todos los demás tipos de objetos y proporciona así fronteras conceptuales
nítidamente definidas respecto a la perspectiva del observador.
Jerarquía: para Booch la jerarquía es “una clasificación u ordenación de abstracciones”.
Existen dos clases de jerarquía:

Pág. 8.


jerarquía “parte de” (part of) o “tiene un” (has a): corresponde a la estructura del
objeto.
jerarquía “es un” (is a): corresponde a la estructura de la clase.

El modelo del objeto
La programación orientada a objetos es un método en el que los programas se organizan
como una colección de objetos, representando cada uno una instancia de alguna clase,
estando relacionadas todas las clases mediante una jerarquía.
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 relación de herencia que de lugar a una jerarquía) no puede considerarse
“orientado a objetos”. Booch lo llama “programación con tipos de datos abstractos”.
Se estudiarán las fases de “análisis” y “diseño” en la orientación al objeto. El análisis se
realizará a partir del dominio inicial del problema. A continuación vendrá el diseño.

Elementos del modelo de objetos
Hay 4 elementos básicos que constituyen dicho modelo:
Abstracción.
Encapsulamiento.
Modularidad.
Jerarquía.
Hay otros elementos (no principales) que son los siguientes:
Tipos.
Concurrencia.
Persistencia.
La abstracción.
“La abstracción denota las características esenciales de un objeto que lo distinguen de
todos los demás tipos de objetos y proporciona así fronteras conceptuales nítidamente
definidas respecto a la perspectiva del observador.”
Existen varios tipos de abstracción:
Abstracción de entidad: un objeto que representa un modelo útil del problema de
dominio de la entidad.
Abstracción de acción: un objeto proporciona un conjunto generalizado de operaciones
para una determinada función.
Abstracción de la máquina virtual: un objeto que agrupa funcionamientos que son
utilizados por niveles superiores de control, y por conjuntos de operaciones de niveles
inferiores.
Abstracción coincidental: un objeto que agrupa un conjunto de operaciones que no están
relacionadas con ninguna otra.
El encapsulamiento.

Pág. 9.


“Es el proceso de almacenar en un mismo compartimento los elementos de una
abstracción que constituyen su estructura y su comportamiento; sirve para separar la
interfaz contractual de una abstracción y su implantación”. (El encapsulamiento oculta
los detalles de la implementación de un objeto).
La modularidad.
Cuando se habla de modularidad hay que imaginarse la fragmentación 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
módulos cohesivos y débilmente acoplados”.
Existen varias técnicas para poder obtener una modularidad correcta o inteligente en
nuestras clases y objetos:
La reducción de los costes del software viene apoyada por la descomposición en
módulos, ya que éstos pueden diseñarse y revisarse independientemente.
La estructura de cada modulo debe ser lo suficientemente simple como para que
pueda entenderse completamente.
Debe ser posible modificar la implementación de un módulo sin tener conocimiento
de la implementación de otros módulos, y sin que se afecte al comportamiento de
otros módulos.
La facilidad de realizar un cambio en el diseño debería estar relacionada con la
necesidad de ese cambio.
La identificación de clases y objetos se corresponde con el diseño lógico del sistema. La
identificación de módulos es parte del diseño físico del sistema. No se pueden tomar
todas las decisiones “físicas” antes que las “lógicas” o viceversa. Más bien, se suelen ir
tomando a la vez.
La jerarquía.
Para Booch la jerarquía es “una clasificación u ordenación de abstracciones”. Las 2
jerarquías más 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 más importante de jerarquía (es un), ya que va a definir las
relaciones entre clases, tanto en el caso de herencia simple como en el caso de herencia
múltiple.
Cuando se habla de jerarquía (es un) normalmente se refiriere a generalización /
especialización. Sin embargo (parte de) es más bien un caso de agregación. La
combinación de la herencia y la agregación puede ser muy potente: la agregación
permite el agrupamiento físico de las estructuras lógicas, y la jerarquía permite a estos
grupos su funcionamiento en diferentes niveles de abstracción.
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 sólo de
formas muy restringidas.
Existen varias comprobaciones de tipos:

Pág. 10.


Comprobación estricta: un objeto sólo pude realizar aquellas operaciones que se
encuentran definidas en la clase o en la superclase del objeto. Se comprueba en tiempo
de compilación.
Comprobación débil: un cliente puede mandar un mensaje a cualquier clase. No se
detectará hasta el momento de la ejecución.
La comprobación estricta de tipos toma especial relevancia en las decisiones de diseño
cuando la complejidad de nuestro sistema aumenta considerablemente.
Estos conceptos se hallan relacionados con los de “ligadura estática” y “ligadura
dinámica”; é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 programación orientada a objetos la concurrencia permitirá a diferentes objetos actuar
simultáneamente. 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 continúa existiendo después de que su creador deja de existir) y /o el espacio (es
decir, la posición del objeto varía 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 evaluación de expresiones.
Variables locales en la activación de procedimientos.
Variables globales y elementos del heap cuya duración 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 están definidos en su clase común; los términos instancia y objeto
son intercambiables”.
Se explican a continuación cada una de las partes de esta definición:
Un objeto tiene estado: el estado de un objeto abarca todas las propiedades
(normalmente estáticas) del mismo más los valores actuales (normalmente
dinámicos) de cada una de esas propiedades.

Pág. 11.


Un objeto tiene comportamiento: el comportamiento de un objeto es cómo actúa
y se relaciona, en función 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 algún 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 demás objetos”. No es conveniente que la identificación 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 más 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 diseño.
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
“declaración” del objeto y luego vendrá la “asignación” o instanciación 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 conexión física o conceptual entre objetos. A través del enlace un
objeto cliente puede solicitar servicios a un objeto proveedor, bien directamente o bien a
través de enlaces con otros objetos.
Un objeto puede desempeñar cualquiera de estos 3 papeles:
Actor: cuando puede operar sobre otros objetos pero ningún objeto opera sobre él.
Servidor: otros objetos actúan sobre él mientras que él no hace peticiones al resto.
Agente: puede operar sobre otros y también otros objetos pueden operar sobre él.
Agregaciones.
Si los enlaces denotan una relación cliente - servidor, la agregación denotará una
jerarquía de partes de un todo. Esas partes pueden ser físicas (Ej. partes de un avión) o
no físicas (Ej. acciones de un accionista).
La agregación a veces es mejor, porque encapsula partes como secretos de un todo. Los
enlaces son óptimos en algunas ocasiones ya que permiten un acoplamiento más débil
entre los objetos.

Pág. 12.


La naturaleza de una clase
Booch define clase como “un juego de objetos que comparten una estructura común y
un comportamiento común”. La clase es un medio necesario pero no suficiente para la
descomposición.
La interfaz de una clase suministra su vista externa y recalca la abstracción, mientras
que oculta su estructura y los secretos de su comportamiento.
Dicha interfaz puede estar dividida en 3 partes:
Pública: una declaración que es accesible a todos los clientes.
Protegida: una declaración que es accesible a la clase, a las subclases y a las clases
amigas.
Privada: una declaración que a la que sólo acceden la propia clase y las clases
amigas.

Relaciones entre las clases
Hay 3 tipos básicos de relaciones:
Generalización / especialización.
Todo / partes.
Asociación.
Dichas relaciones pueden obtenerse como combinación de algunas de estas otras:
asociación, herencia, agregación, uso, instanciación, metaclases...
La asociación.
Una asociación describe un grupo de enlaces con una estructura y una semántica en
común.
La herencia.
La herencia, para Booch, es una “relación entre clases, en la que una clase comparte la
estructura o comportamiento definido en otra (herencia simple) u otras (herencia
múltiple) clases.
La herencia define una relación “de tipo” entre clases en la que una subclase hereda de
una o más 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 teoría de tipos, de acuerdo con el cual un nombre
(como una declaración de una variable) puede denotar objetos de muchas clases
diferentes que se relacionan mediante alguna superclase común; así todo objeto
denotado por este nombre es capaz de responder a algún conjunto común 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 agregación.

Pág. 13.


El concepto de agregación entre clases es equivalente al explicado para la relación entre
objetos.
El uso.
Una relación de uso es posiblemente una abstracción en la cual aseguramos quién es el
cliente y quién es el proveedor de un cierto servicio.
La instanciación.
La instanciación se refiere al hecho de “ir creando las instancias de las clases”.
Aquí hay que destacar también 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 interacción de Clases y objetos
Durante la fase de análisis 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 armazón lógico 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 implementación, el enfoque está en la vista
interior de estas abstracciones importantes y mecanismos. Estas decisiones de diseño se
explican como parte de la arquitectura del módulo del sistema y arquitectura del
proceso.

Construcción de Clases y Objetos de Calidad
Para medir la calidad de una abstracción se tiene lo siguiente:
El acoplamiento: es la medida de la fuerza de una asociación establecida por una
conexión entre clases.
La cohesión: mide el grado de conectividad entre los elementos de una clase o
de un objeto.
Suficiencia: significa que la clase capture bastantes características de la
abstracción para permitir interacción significante y eficaz.
”Completeness”: una interfaz completa es aquella que cubre todos los aspectos
de la abstracción.
“Primitiveness”: desde que muchas operaciones de alto nivel están compuestas
por operaciones de bajo nivel, se sugiere que esas clases sean primitivas.
Es muy frecuente que sobre el primer análisis efectuado sobre las clases se haga
necesario modificar y refinar las interfaces, e incluso a veces se llega a la creación de

Pág. 14.


nuevas clases o a una reorganización de las relaciones existentes entre las que ya
existen.
Es importante conocer el concepto de “Visibilidad” ya que la metdología de Fusion se
va a apoyar en él. Durante la fase de diseño conviene especificar cómo 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 parámetro de alguna operación del cliente.
El objeto servidor es una parte del cliente.
El objeto servidor está localmente declarado en el alcance del diagrama de
objetos.

Clasificación
La clasificación va a ser fundamentalmente una cuestión de igualdad que ayudará a
identificar las jerarquías de generalización, especialización y agregación entre clases.
También ayuda a la toma de decisiones sobre la “modularización”.
Es difícil llevar a cabo una buena clasificación ya que no existe una clasificación
“perfecta”. Cualquier clasificación es relativa al punto de vista de su autor. Por otra
parte, una buena clasificación requiere una gran creatividad e ingenio.

Aproximación a las clasificaciones
Se hacen tres divisiones:
Categorización clásica: todas las entidades que tienen una propiedad o un conjunto
de propiedades en común forman una categoría. Esas propiedades han de ser
necesarias y suficientes para constituir dicha categoría. 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 descripción.
Teoría del prototipo: Una clase de objetos es representada por un objeto prototipo, y
un objeto será considerado miembro de la clase si y sólo si se parece al prototipo de
manera significativa.
En el primer caso hay que centrarse en las estructuras, en el segundo en la colaboración
de objetos, mientras que en el tercero se considera que el objeto esté definido de
acuerdo con una serie de características del objeto prototipo.

Procedimientos para encontrar clases y objetos
Booch define las fases de análisis y diseño como sigue:
Análisis: se va a modelar descubriendo las clases y objetos que forman el
vocabulario de dominio del problema.
Diseño: se inventarán las abstracciones y los mecanismos necesarios para conseguir
el comportamiento que exige el modelo establecido en la fase de análisis.

Pág. 15.


Existen unos cuantos métodos para el análisis de sistemas en orientación al objeto:
Acercamientos clásicos: las clases y los objetos se derivan de los requisitos del
problema.
Análisis de comportamiento: se basa en el comportamiento dinámico existente entre
clases y objetos. Se constituirán clases basadas en grupos de objetos que exhiban un
comportamiento similar. Se formarán jerarquías de clases y subclases de acuerdo con
unas responsabilidades que poseen todos los elementos de un mismo grupo.
Análisis 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 patrón o ejemplo concreto de utilización,
un escenario que comienza con algún usuario del sistema que inicia alguna transacción
o secuencia de eventos interrelacionados. Pueden utilizarse en el análisis 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 método
En la metodoogía de Booch se explica qué hay que hacer para definir el sistema, pero
no se da ninguna prescripción para mejorar las fases de análisis y diseño 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 orientación al objeto.
Booch propone varias formas de describir un sistema en orientación al objeto. El
modelo lógico, por ejemplo, se representa bajo la estructura de clases y objetos.
Mientras que el diagrama de clases es más bien estático, el diagrama de objetos muestra
el comportamiento dinámico del sistema

Pág. 16.


Figura 1. Esquema del método de Booch.

Diagramas de clases
Un diagrama de clases muestra las relaciones entre las abstracciones de un sistema
(vista lógica).
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 descomposición software orientada al objeto. Una
clase representa un conjunto de elementos u objetos que comparten la misma estructura
y un comportamiento común. El comportamiento dinámico de una clase puede
describirse gracias a su diagrama de transición de estados.

Pág. 17.


Figura 2. Notación de “clase" en Booch.

Clase Utilidad: constituida por una colección de subprogramas libres y declarada como
parte de una clase que no tiene estado. (Aunque se puede decir que todos los métodos
son operaciones, no todas las operaciones son métodos).

Figura 3. Notación de “clase utilidad” en Booch.

Clase Parametrizada: clase que sirve como plantilla para otras clases. Dicha plantilla
puede contener parámetros de otras clases, objetos y/o operaciones. Normalmente las
clases parametrizadas se utilizan como clases contenedoras. Los términos clase
“genérica” y clase “parametrizada” suelen ser intercambiables.

Figura 4. Notación de “clase parametrizada” en Booch.

Pág. 18.


Categorías de clase: colección lógica de clases, algunas de las cuales son visibles a otras
categorías de clase mientras que otras están ocultas. La mayoría de los lenguajes de
programación en la orientación al objeto no soportan las categorías de clase.

Figura 5. Notación de “categorías de clase” en Booch.

Atributos: un atributo de la clase describe una información singular guardada en cada
caso. Puede ser muy útil exponer algunos de los atributos relacionados con una clase.
Métodos: los métodos 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 información sobre alguna entidad en
el modelo del sistema. Se representan mediante una letra dentro de un triángulo. Las
“relaciones” también pueden poseerlos; en C++ hay 3 propiedades:
1.estática: la designación de un miembro de la clase: objeto o función.
2.virtual: la designación de una clase compartida en una estructura de herencia.
3.amiga: la designación del acceso concedido a las partes no públicas de una clase.

Figura 6. Notación de “adornos y propiedades” en Booch.

Control de exportación (para atributos, operaciones y relaciones): los miembros pueden
ser públicos (accesibles para todos los clientes), protegidos (accesibles sólo a subclases,
amigos o a la propia clase), o privado (accesible a él y sus amigos).

Pág. 19.


Figura 7. Notación del “control de la exportación” en Booch.

Relaciones entre clases.
Las clases colaboran entre sí de diversas formas. Las conexiones esenciales entre clases
son:
Asociación: que tendrá en cuenta una serie de aspectos: valor clave, restricciones,
cardinalidad, papel que desempeña, etiqueta...

Figura 8. Notación de “asociación” entre clases en Booch.

Herencia: define una relación entre clases donde una clase comparte la estructura o el
comportamiento definido en otra u otras clases. La herencia representa una jerarquía de
abstracciones donde una subclase hereda de una o más superclases.
La notación consiste en una flecha que apunta de la subclase a la superclase.

Figura 9. Notación de “Herencia” en Booch.

Agregación: o relación todo/parte; aparece como una asociación con un círculo relleno
que indica la “agregación”.
Se puede encontrar agregación por valor:

Figura 10. Notación de “Agregación por valor” en Booch.

Pág. 20.


Y agregación por referencia:

Figura 11. Notación de “Agregación por referencia” en Booch.

Uso: el proveedor proporciona ciertos servicios (ver el apartado “diagramas de objetos”
para averiguar cómo se ven los objetos entre ellos).

Figura 12. Notación de “Uso” en Booch.

Instanciaciones:

Figura 13. Notación de “instanciaciones” en Booch.

Metaclases:

Figura 14. Notación de “metaclases” en Booch.

Diagramas de objetos
Los diagramas de objetos son parte de la notación del diseño orientado a objetos.
Muestran todos o algunos objetos junto a sus relaciones en el modelo lógico del sistema.
Pueden usarse para ver su ejecución en diferentes escenarios.
En un diagrama de objetos se puede tener:

Pág. 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 común. Un objeto es una instancia de una clase.

Figura 15. Notación de “Objeto” en Booch.

Enlace de objetos: este término deriva de Rumbaugh, quien lo define como “conexión
física o conceptual entre objetos”. Muestra la asociación entre un objeto Cliente que
solicita una serie de servicios de un objeto Servidor, y la dirección seguida por los
mensajes intercambiados entre los objetos.
Un objeto que participe de un enlace puede desempeñar 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 también otros pueden hacerlo sobre él.

Figura 16. Notación de “Enlace de objetos” en Booch.

Sincronización de enlaces (para objetos actores): ante múltiples técnicas de control un
objeto requiere más que eso para tratar los problemas de exclusiones mutuas y
conflictos que puedan presentarse. Los objetos actores tienen sus propios métodos 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 exclusión mutua.
Synchronous: el servidor garantiza la exclusión mutua.
Los mensajes se adornan utilizando la siguiente notación:

Pág. 22.


Figura 17. Notación de “sincronización de enlaces” en Booch.

Visibilidad de enlaces: los diagramas de clases muestran las dependencias existentes
entre las clases de varios objetos. Pero no dictaminan cómo 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. Notación de “visibilidad de enlaces” en Booch.

Otros diagramas
Diagrama de transición de estados:
Se utiliza para mostrar el espacio de estados de una determinada clase, los eventos
(mensajes) que disparan una transición de un estado a otro y las acciones que resultan
del cambio de estado.
La notación empleada es la siguiente: un único nombre para cada estado (que puede
incluir acciones asociadas), flechas dirigidas para conectar los diferentes estados...

Figura 19. Notación de “estado” en Booch.

Pág. 23.


Una transición conecta dos estados y tiene que haber un estado inicial en el diagrama.

Figura 20. Diagrama de transición de estados en Booch.

Diagrama de Módulos:
Se utiliza para mostrar la colocación de las clases y objetos en los módulos en el diseño
físico de un sistema. Indica la división de la arquitectura del sistema.
Los dos elementos esenciales del diagrama son: los módulos y sus dependencias.
Un subsistema puede tener dependencias en otros subsistemas o módulos, y un módulo
puede tener dependencias en un subsistema. La misma anotación se usa para las
dependencias de los subsistemas.

Figura 21. Diagrama de módulos en Booch.

Diagrama de procesos:
Se usan para mostrar la asignación de procesos a los procesadores en un diseño físico
del sistema. A través de los diagramas se indica la colección de procesadores y
dispositivos que sirven como plataforma para ejecutar el sistema.

Pág. 24.


Hay 3 elementos esenciales: procesadores, dispositivos y sus conexiones.

Figura 22. Diagrama de procesos en Booch.

Diagrama de interacción:
Traza la ejecución 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 líneas
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 interacción en Booch.

Pág. 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 (conceptualización).
Desarrollo de un modelo de comportamiento deseado (análisis).
Creación de una arquitectura (diseño).
Evolución de la implementación (evolución).
Mantenimiento.
“Micro procesos”.
Identificación de las clases y de los objetos en un nivel de abstracción dado.
Identificación de la semántica de dichas clases y objetos.
Identificación de las relaciones entre estas clases y objetos.
Especificar las interfaces y después la implementación de estas clases.

Conclusión
La metodología de Booch es muy poco rígida 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
notación que ofrece, el usuario será el único responsable de identificar las fases de
análisis y diseño del sistema. Siempre que se respete esa notación y que los resultados
obtenidos sean coherentes con los conceptos anteriormente explicados podrá
considerarse que el análisis y el diseño se han llevado a cabo correctamente.

Un ejemplo concreto
Según Booch, una posible forma (que no tiene por qué ser la mejor) de desarrollar las
fases de análisis y diseño de un sistema informático de “Adquisición de datos: estación
de monitorizacion del clima”, podría ser:
Fase de análisis:
Definición de los límites del problema. (Servicios que proporcionará el sistema).
Especificación detallada de las necesidades del soporte hardware.
Realización del diagrama de procesos del sistema.
Ciclo de vida de algún objeto.

Pág. 26.


Jerarquía de clases. (Clase sensor).
Diagramas de interacción. (Temporizador).
Escenarios.
Diagrama de transición de estados. (GestorEntrada).

Fase de diseño:
• Escoger el marco de referencia arquitectónica.
• Creación de nuevas clases cuya creación se ha visto necesaria.
• Se empiezan a definir internamente las clases.

Pág. 27.


OMT (Object Modeling Tecnique) James Rambaugh

Visión general
Es una metodología orientada a objeto muy difundida, de hecho es la que actualmente
más 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 notación. Se
divide en cuatro fases consecutivas. Tiene una parte de diseño no muy compleja. Se
centra mucho en un buen análisis. Es de las denominadas “dirigidas por los datos”.

Fases (4)
1. Análisis de objetos:
Se describe el problema: Se obtienen unos requisitos que no den lugar a dudas
(rendimiento, funcionalidad, contexto,...). En toda la fase de análisis 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 iteración.
Creación de un modelo dinámico para describir los aspectos de control y evolución del
sistema. Incluye un Diagrama de Eventos del sistema y un Diagrama de Estado por cada
clase que tenga un comportamiento dinámico.
Creación 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. Diseño del sistema: Comprende la arquitectura básica. En esta fase se tomarán las
decisiones estratégicas (a alto nivel) de diseño (estructura global del sistema).
3. Diseño de objetos: Es el último paso antes de implementar, y sirve para definir
completamente todas las características de los objetos. Se detallan los 3 modelos ya
descritos en el análisis 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 aplicación.
4. Implementación: Se codifica lo ya diseñado.

Pág. 28.


Pasos específicos a dar en cada fase

Fase De Análisis
1.Obtener y escribir una descripción 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.
- Añadir las asociaciones (y agregaciones) entre las clases.
- Añadir 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 módulos, basándose en su proximidad y función.
3.Construir un modelo dinámico:
- Preparar los escenarios para las secuencias de interacción típicas 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 dinámico.
- Chequear la consistencia (y que están 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 función.
- Identificar las restricciones.
- Especificar criterios de optimización.
(*) Este modelo ha sido bastante criticado, por no seguir los principios del AOO.
Desde 1995 se recomienda que este modelo consista en una descripción
detallada de las operaciones del sistema, y solo usa DFDOO cuando estas
operaciones impliquen a varios objetos. Conviene, para cada operación
especificar las siguientes cosas: Nombre, Responsabilidades, Entradas, Salidas,
Objetos modificados, Precondiciones y Postcondiciones.
5.Verificar, iterar y refinar los tres modelos:
- Añadir las operaciones claves que fueron descubiertas durante la preparación
del modelo funcional al modelo de objetos. No mostrar todas las operaciones
durante el análisis, sólo mostrar las más importantes.

Pág. 29.


- Verificar que las clases, asociaciones, atributos y operaciones son
consistentes y completas al nivel elegido de abstracción. Compara los tres
modelos con la definición del problema y probar los modelos mediante el
uso de escenarios.
- Desarrollar escenarios más detallados (incluyendo condiciones que den
errores) como variaciones de los escenarios básicos. Usar estos escenarios
“y si...” para verificar en el futuro los tres modelos.
- Iterar los pasos anteriores cuanto sea necesario para completar el análisis.

Fase De Diseño 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
máquina a los distintos subsitemas (memoria, procesador, ficheros...).
4. Elegir la estrategia básica 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 método de implementación 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 autómata de estados, o
- Usar tareas de concurrencia.
7. Considerar las condiciones límite.
8. Establecer las prioridades.

Fase de Diseño De Objetos
1. Obtener operaciones para el modelo de objetos a partir de los otros modelos:
- Encontrar una operación para cada proceso del modelo funcional.
- Definir una operación por cada evento del modelo dinámico, dependiendo de
la implementación del control.
2. Diseñar 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:

Pág. 30.


- Añadir 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 cálculos repetidos.
4. Implementar el control software mediante el sistema elegido durante el diseño 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 común de grupos de clases.
- Delegar para poder compartir comportamientos cuando la herencia sea
semánticamente inválida.
6. Diseño de la implementación de las asociaciones:
- Analizar las asociaciones transversales.
- Implementar cada asociación como si fuera un objeto distinto o añadiendo el
valor de los objetos como atributos de una o ambas clases de la asociación.
7. Determinar la representación exacta de los atributos de los objetos.
8. Compactar las clases y asociaciones en módulos, ocultando en la parte privada toda la
información que deba estar oculta.

Implementación
No se detiene en ella (al igual que la fase de pruebas), con lo que se queda a la elección
del programador.

Conclusión
Una de las grandes virtudes de OMT es su modelo de objetos, que contiene una enorme
riqueza semántica, por lo que ha sido adaptado por casi todas las metodologías de
segunda generación, y es una de las bases metodológicas de la metodología ‘Objetory’
que en breve aparecerá (de la mano de los ‘3 amigos’: Rambaugh, Booch y Jacobson)
para completar a UML.
OMT es una metodología bastante sólida (si exceptuamos su modelo funcional, bastante
criticado), que completado con otras técnicas de representación (CRCs, Casos de Uso...)
la hacen la metodología más difundida (tanto a nivel universitario como empresarial)
del momento.

Notación
Todas las relaciones y diagramas han de respetar la siguiente notación:

Pág. 31.


Figura 24. Notación de OMT para el Modelo de Objetos

Pág. 32.


Método de Fusion. Coleman

Introducción
Fusion proporciona un método de desarrollo de software orientado al objeto, que abarca
desde la definición de requisitos a la implementación en un lenguaje de programación.
Es considerada como una metodología de segunda generación, porque proviene de:
OMT: modelo de objetos,
CRC: interacción de objetos,
BOOCH: visibilidad,
Los métodos Formales: pre- y postcondiciones.
• Proporciona un proceso de desarrollo, que se divide en:
Análisis, Diseño e Implementación.1
• Ofrece notaciones para los modelos, que describen varios aspectos del software.
Actualmente ha abandonado su notación.
• Proporciona herramientas de gestión.

Análisis
El análisis se basa más en describir lo que hace un sistema en lugar de cómo lo hace.
Para esto, hay que ver el sistema desde la perspectiva del usuario en lugar de desde la de
la máquina. El análisis casa con el dominio del problema y se preocupa por el
comportamiento visible externamente.
La meta de la fase de análisis 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 análisis es un documento de definición de requisitos en
lenguaje natural.

1
Especifica el orden en el que deben hacerse las cosas dentro de cada fase. También proporciona
criterios de cuándo pasar a la siguiente fase.
2
En la fase del análisis de Fusion, sólo los atributos de una clase son considerados. Los métodos son
considerados en la fase de diseño. Por consiguiente, en la fase del análisis, los objetos son similares a las
entidades en el tradicional modelo entidad relación.

Pág. 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 estática de la información en el sistema,
las clases y relaciones entre ellas,
atributos de clases,
agregación,
especialización/generalización.
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 asociación o correspondencia entre
objetos que pertenecen a clases.
Para describir una relación, se consideran los puntos siguientes:
Restricciones de Cardinalidad. Cardinalidad es el número de clases que pueden
asociarse entre sí en una relación.
Invariantes. Restricciones de que alguna propiedad se debe cumplir.
Roles. Las clases que participan en una relación tienen roles. Los nombres para los
roles o papeles en una relación deben ser únicos.
Atributos de la relación. Las relaciones, como los objetos, pueden tener atributos.3
Relaciones ternarias y más altas. Las relaciones ternarias relacionan tres objetos
separados. Las que involucran más de tres objetos se llaman relaciones n-arias.
• La agregación es un mecanismo para estructurar el modelo de objetos. Permite la
construcción de una clase agregada a partir de las otras clases componentes. La
agregación modela las relaciones todo/parte.
• La generalización permite a una clase, llamada supertipo, ser formada sacando las
propiedades comunes de varias clases, llamadas subtipos. La especialización es el
caso inverso en el que un nuevo subtipo se define como una versión más
especializada de un supertipo.4
• La especialización múltiple permite definir un nuevo subtipo como una
especialización de más 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 Unión (Link Attribute) en el la notación de Rumbaugh.
4
En el la anotación de Rumbaugh, el supertipo se llama superclase, y el subtipo se llama subclase. Las
notaciones del triángulo en Fusion son completamente opuestas a las de Rumbaugh.
5
En el la notación de Rumbaugh, la especialización múltiple se llama herencia múltiple. La notación es
exactamente la misma para los dos métodos.

Pág. 34.


Figura 25. Notación del diagrama de objetos de
Pág. 35.
Fusion.


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 información 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 comunicación de entrada y salida del sistema. La descripción está en términos de
eventos y el cambio de estado que ellos causan.6
Un sistema se modela como una entidad activa que interactúa con otras entidades
activas llamadas agentes. Los agentes modelan a los usuarios humanos, u otros sistemas
hardware o software. Las características 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 términos de :
cambios de estado,
eventos que son salidas.
Una operación 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 operación 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 relación.
Enviar un evento a un agente.

6
Un evento es una unidad instantánea y atómica de comunicación 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 operación del sistema.

Pág. 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 operación del sistema.
Semántica de cada entrada en la sintaxis del esquema.
Operación: Nombre de la operación.
Descripción: Descripción concisa de la operación.
Lee: Todos los valores a los que la operación puede acceder sin modificación.
Cambia: Todos los valores a los que la operación puede acceder y modificar.
Envía: Lista de agentes y eventos que la operación puede enviar.
Asume: Pre-condición, por ejemplo, lo que debe ser verdad antes de la operación.
Resultados: Post-condición, por ejemplo, qué cambios han ocurrido por la operación.

Modelo del Ciclo de Vida
El modelo de ciclo de vida describe cómo el sistema se comunica con su entorno desde
su creación hasta su muerte. Consiste en expresiones del ciclo de vida. Una expresión
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 gramática
describe las secuencias aceptables de símbolos que son aceptadas por un compilador. 7

7
Este modelo puede ser reemplazado por guiones en la versión ligera de Fusion.

Pág. 37.


Proceso de Análisis
El análisis no es un proceso anárquico: hay una sucesión definida de pasos que pueden
aplicarse iterativamente para producir una especificación completa y consistente que
capture los requisitos.
El análisis es una actividad incremental e iterativa que formaliza los requisitos. Puede
llevarse a cabo de una manera sistemática.
En Fusion, el proceso de análisis 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 límite 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 análisis.
Para todos, hasta para el más trivial, de los problemas el proceso debe de ir acompañado
por la construcción y uso de un diccionario del datos.

Diccionario de datos
El diccionario de datos sirve para coleccionar información no disponible en los
diagramas de Fusion. El diccionario de los datos es un almacén (repositorio) central de
definiciones de términos y conceptos.
Ejemplo de la estructura del diccionario de datos.

Figura 27. Ejemplo de la estructura del diccionario de datos.

Pág. 38.


Sin embargo, esto no es obligatorio, y el formato real del diccionario de los datos es
insignificante.

Desarrollo del Modelo de Objetos
• ¿Cómo empezar a construir el Modelo de Objetos?
Empezar el análisis puede ser a menudo la parte más difícil. El análisis debe empezarse
con un alto nivel de abstracción. Es mejor utilizar los requisitos para una tormenta de
ideas de posibles clases y relaciones. Sólo después de que su estructura global sea
satisfactoria deben añadirse los detalles. Hay que recordar que el modelo de objetos
utiliza clases, mientras que un documento de requisitos es expresado principalmente en
términos de objetos específicos.
• ¿Cómo 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 comprensión del dominio.
Posibles fuentes de clases candidatas son:
Objetos físicos,
Personas y organizaciones,
Abstracciones.
• ¿Cómo encontrar relaciones?
Modelan correspondencias entre objetos. Comunicaciones, asociaciones físicas,
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?
Generalización
Agregación
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 análisis siempre depende en parte de la experiencia, y incluso de la
estética del analista.
Es importante recordar que los objetos no tienen que modelar cosas: también pueden
modelar abstracciones.
No hay que mal interpretar clases y relaciones como diagramas de flujo de datos.

Determinación de la Interface del Sistema
• ¿Por qué determinar la interface del sistema?

8
Éstos se ignoran durante la fase de la tormenta de ideas inicial. Cualquier clase candidata que no tenga
ningún atributo y que se relacione con sólo otra clase, puede convertirse en atributos.

Pág. 39.


Durante el análisis, 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 operación 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 operación del sistema siempre es invocada por un agente, no por un objeto; la fase
del análisis no se preocupa por mensajes internos entre los objetos.
La información obtenida en la determinación de la interface del sistema es el punto de
partida para desarrollar el modelo de la interface.
• ¿Qué es la notación de la interface del sistema?
El escenario es una técnica útil para definir la interface del sistema.
Un escenario es una sucesión de eventos que fluyen entre agentes y el sistema para
algún propósito.
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 comunicación. Por consiguiente,
en general pueden necesitarse diagramas múltiples para un sólo escenario.
Los diagramas de secuencia de escenario aportan una herramienta para intuir las
consecuencias del diseño de la interface y visualizar cómo 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.

Pág. 40.


Desarrollo del Modelo de la Interface
• ¿Cuál 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.
• ¿Cómo desarrollar el modelo del ciclo de vida?
El modelo del ciclo de vida es una expresión generalizada de los escenarios que se
expresan en diagramas de secuencia. Las expresiones del ciclo de vida son más
expresivas que el diagrama de secuencia, porque pueden expresar repetición,
alternación, y optionalidad, así como el encadenamiento.
Una expresión del ciclo de vida puede definir un conjunto de escenarios, mientras que
un diagrama de secuencia puede mostrar sólo 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.
• ¿Cómo desarrollar el modelo del funcionamiento?
El modelo del funcionamiento define la semántica de cada operación 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 cláusulas Asume y Resultados.
2. Extraiga la cláusulas Envía, Lee, y Cambia de Asume y Resultados.

Verificando los Modelos del Análisis
• ¿Cuándo detener la fase del análisis?
El dilema que enfrenta al analista es saber cuándo los modelos del análisis son
suficientemente buenos para ser usados en el diseño. La perfección es inasequible y
normalmente no se requiere. Sin embargo, una especificación con errores graves no
sirve.
Verificar los modelos del análisis es una manera de evitar errores graves. Si los
chequeos no revelan ningún problema, entonces se puede pensar que la fase del análisis
está completa.
• ¿Qué aspectos serán verificados?
Hay dos aspectos para ser verificado: completitud (integridad) y consistencia.
La integridad puede medirse contra los requisitos. Los modelos del análisis deben
probarse contra los requisitos, y también 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.

Pág. 41.


- Toda la información estática es capturada por el modelo de objetos del sistema.
- Cualquier otra información (ej., definiciones técnicas e invariantes), está en el
diccionario de datos.
Un conjunto de modelos es consistente cuando los modelos no se contradicen entre
ellos, explícitamente o implícitamente. En un modelo debe verificarse su consistencia
interna y también 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 análisis. 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 Semántica
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 operación 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 relación o clase, entonces cualquier
operación 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 operación del sistema.
Chequee que los resultados son lo que se espera.

Diseño
El diseño consiste en desarrollar un modelo abstracto de cómo un sistema lleva a cabo
el comportamiento especificado en el análisis.
El diseñador escoge cómo se va a construir el sistema. Durante este proceso, los
métodos se unen a las clases. El diseñador también escoge cómo los objetos se
relacionan entre ellos y qué relaciones de herencia entre clases son apropiadas.
La fase de diseño de Fusion se basa en las CRC y los métodos de Booch.
La salida del diseño es una estructura de software orientado a objeto que contiene la
misma información y mantiene las relaciones definidas en el modelo de objetos del
sistema.
Durante esta fase se desarrollan los cuatro modelos siguientes:
• Gráficos de Interacción de Objetos. Describen cómo los objetos interactúan en
tiempo de ejecución para conseguir la funcionalidad especificada en el modelo de
funcionamiento en la fase del análisis.

Pág. 42.


• Gráficos de visibilidad. Describen las rutas de comunicación entre objetos.
• Descripciones de clases. Proporcionan una especificación de la interface de la
clase, atributos de datos, atributos de referencia a objetos, y signaturas de los
métodos para todas las clases en el sistema.
• Gráficos de herencia. Describen las estructuras de herencia clases/subclases.
Además, el diccionario de los datos documenta los términos, conceptos, y restricciones
que aparezcan durante esta fase.
La entrada de la fase de diseño son los tres modelos desarrollados en la fase del
análisis: Modelo de objetos, modelo de funcionamiento y modelo del ciclo de vida.

Gráfico de Interacción de Objetos
La primera consideración en diseño orientado a objetos es la implementación de cada
operación del sistema. El modelo de funcionamiento especifica la conducta de estas
operaciones definiendo el efecto de cada operación en términos de cambios de estado
del sistema y de eventos de salida. El propósito de esta fase en diseño es construir las
estructuras de mensajes entre objetos definidas en el modelo de funcionamiento.
El gráfico de interacción de objetos se construye para cada operación del sistema.
Un gráfico de interacción de objetos es una colección 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 gráfico;
esta flecha se etiqueta con el nombre de la operación del sistema que implementa ese
gráfico de iteracción de objetos.
Colaboradores El resto de las cajas se llaman colaboradores. El resto de las
flechas, salvo la de la operación del sistema, van de una caja a otra dentro del gráfico.
Las sucesiones de mensajes entre los objetos determinan el comportamiento de los
objetos declarado en el gráfico de interacción de objetos. Esto define la implementación
a alto nivel de la funcionalidad a través de los objetos para una operación del sistema.
Cada gráfico de interacción de objetos también lleva asociado un texto descriptivo en el
diccionario de los datos, en lenguaje natural, pseudocódigo, o especificación formal,
para dar significando a la operación del sistema y los mensajes definidos.
Notación del gráfico de interacción de objetos

Pág. 43.


Figura 29. Notación del gráfico de iteracción de objetos.

Pág. 44.


Objeto del diseño. Tiene atributos y la interface de los métodos. En la fase del
análisis un objeto no tenía ningún atributo ni método. Para distinguirlo de este, se utiliza
la palabra objeto del diseño. La notación es una caja sólida.
Colecciones de Objetos. Colecciones de objetos de la misma clase. Las
implementaciones típicas de estas colecciones serán listas o arrays. La notación es una
caja con líneas discontinuas.
Paso de mensajes. El paso de mensajes es una comunicación punto a punto, y se
realiza como una llamada a una función o a un método. La notación es una flecha
directa con etiquetas. La dirección de la flecha es del remitente al receptor. También se
llaman cliente y servidor.
Paso de mensajes a Colecciones. Un mensaje puede pasarse a colecciones de
objetos. La notación es una flecha directa a una caja con líneas 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
paréntesis sobre el nombre del mensaje. La notación son etiquetas de la secuencia entre
paréntesis.
Creación dinámica de Objetos . La palabra clave new indica que un objeto se crea
como parte de la ejecución de un gráfico de interacción de objetos. El mensaje especial
create también debe ser enviado a cada nuevo objeto, con los parámetros de invocación
apropiados, para inicializarlo. La notación es una flecha directa con el mensaje create().
• ¿Cómo desarrollar un gráfico de interacción de objetos?
Para cada operación del sistema se realiza un gráfico de interacción de objetos. Esto
significa que se desarrolla un gráfico de interacción de objetos para cada esquema en el
modelo de funcionamiento.
Esto supone los siguientes pasos:
1. Identifique los objetos pertinentes involucrados en la implementación de la
operación del sistema.
El esquema del modelo de funcionamiento se usa como el punto de partida para
identificar los objetos involucrados.
La cláusula Lee del esquema proporciona una lista de los objetos a los que la
operación del sistema accede pero no modifica.
La cláusula Cambia lista los objetos cambiados por dicha operación.
Además de los objetos listados explícitamente 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
análisis.
La cláusula Envía 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
operación del sistema, y es responsable de dicha operación).
Identifique a los colaboradores involucrados.
3. Decida los mensajes entre los objetos.

Pág. 45.


Cada objeto proporcionará pedazos diferentes de funcionalidad. Estos pedazos de
funcionalidad están compuestos por el paso de mensajes entre los objetos.
4. Registre cómo los objetos identificados interactúan en un gráfico de interacción de
objetos.
Cada objeto proporciona una parte de la definición funcional de la operación, y
esta información puede extraerse para definir la interface del método del objeto. Una
descripción textual de cada método es incluida en el diccionario de los datos. Esto
explica el significado de los métodos.
• ¿Cómo refinar un gráfico de interacción de objetos?
El proceso de diseño lleva a cabo un desarrollo iterativo y una descomposición
jerárquica. Los gráficos de Interacción de objetos proporcionan una representación
visual de la estructura de los algoritmos. Permiten llevar a cabo experimentos con
diseños alternativos y ayudar a la descomposición jerárquica.
Diseño alternativo
Los diseños alternativos son explorados desarrollando gráficos de interacción 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 operación del sistema.
Descomposición del método jerárquica
Un diseñador puede reducir la complejidad de un gráfico de interacción de objetos
posponiendo la descomposición de un método. Esto puede hacerse con el uso de un
esquema de modelo de funcionamiento para especificar el método. Después en el
diseño, el esquema del método puede usarse para producir unos gráficos de interacción
de objetos de la manera normal.
• ¿Cómo verificar un gráfico de interacción de objetos?
Hay dos chequeos básicos que necesitan ser llevados a cabo una vez que el diseñador
está satisfecho con los diseños iniciales.
1. Consistencia con la especificación del sistema.
Verifique que cada una de las clases en el modelo de objetos del sistema se
representa en por lo menos un gráfico de interacción de objetos.
2. Comprobación de efecto funcional.
Chequee que el efecto funcional de cada gráfico de interacción de objetos satisface la
especificación de su operación del sistema dada en el modelo del funcionamiento.
Chequee que se satisfacen todas las cláusulas Resultado del esquema.
• Principios de buen diseño
Hay que tratar de:
Minimizar las interacciones entre objetos.
Separar ordenadamente la funcionalidad.
Desarrollar sistemas modulares.

Pág. 46.


Gráficos de visibilidad
Durante el desarrollo de los gráficos de interacción de objetos, se suponía que todos los
objetos son visibles entre sí y se pueden enviar mensajes. El propósito del gráfico 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.
• Notación del gráfico de visibilidad
Hay tres componentes en el gráfico de visibilidad:
1.caja del cliente
Esto representa la clase que requiere el acceso. Una caja del cliente es un rectángulo
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 rectángulo 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 vía una ruta de
acceso.

Pág. 47.


Figura 30. Notación del gráfico de visibilidad.
Pág. 48.

Metodologias[1]

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Metodologias[1]

Similar a Metodologias[1] (20)

Metodologias[1]