CAPÍTULO 20

El propósito del Análisis Orientado a objetos (AOO) es definir todas las clases (y las relaciones y
comportamiento asociadas con ellas) que son relevantes al problema que se va a resolver. Para
cumplirlo se deben ejecutar las siguientes tareas:
1. Los requisitos básicos del usuario deben comunicarse entre el cliente y el ingeniero del soft.
2. Identificar las clases (es decir, definir atributos y metodos).
3. Se debe especificar una jerarquia de clases.
4. Representan las relaciones objeto a objeto (conexiones de objetos).
5. Modelar el comportamiento del objeto.
6. Repetir iterativamente las tareas de la 1 a la 5 hasta completar el modelo.

20.1. ANALISIS ORIENTADO A OBJETOS

El objetivo del AOO es desarrollar una serie de modelos que describan el soft de computadora al
trabajar para satisfacer un conjunto de requisitos definidos por el cliente.

20.1.1. Enfoques convencionales y enfoques OO

Se sugieren “dimensiones de modelado que pueden ser usadas para comparar diferentes metodos de
analisis convencional y orientados a objetos:
1. Identificacion/clasificación de entidades.
2. Relaciones de entidad general a específica y del todo a partes.
3. Otras relaciones de entidad.
4. Descripción de atributos de entidades.
5. Partición de modelos a gran escala.
6. Estados y transiciones entre estados.
7. Especificación detallada de funciones.
8. Descomposición descendente (top-down).
9. Secuencias de procesamiento de fin-a-fin.
10. Identificación de servicios exclusivos.
11. Comunicación entre entidades (a través de mensajes o eventos).
Las dimensiones 8 y 9 siempre están presentes en el Análisis estructurado y raramente aparecen
cuando se usa el AOO.

20.1.2. El panorama del AOO

Los métodos de AOO introducen un proceso para el análisis de un producto o sistema, un conjunto de
modelos que evoluciona fuera del proceso, y una notación que posibilita al ingeniero del software crear
cada modelo de una manera consistente.

El método de Booch. Abarca un “micro proceso de desarrollo” y un “macro proceso de desarrollo”. El

nivel micro define un conjunto de tareas de análisis que se reaplican en cada etapa en el macro
proceso.(enfoque evolutivo)

El método de Coad y Yourdon. Uno de los metodos del AOO más sencillos de aprender.
Descripción del proceso:
 Identificar objetos usando el criterio de “qué buscar”.

1
 Definir una estructura de generalización-especificación.
 Definir una estructura de todo-parte.
 Identificar temas (representaciones de componentes de subsistemas).
 Definir atributos.
 Definir servicios.

El método de Jacobson. También llamado ISOO (ingeniería del software orientada a objetos) es una
versión simplificada de Objectory. Este método se diferencia de los otros por la importancia que da al
caso de uso – una descripción o escenario que describe cómo el usuario interactúa con el producto o
sistema.

El método de Rumbaugh. Técnica de Modelado de Objetos(OMT). La actividad de análisis crea tres

modelos:
- El modelo de objeto (una representación de objetos, clases, jerarquías y relaciones)
- El modelo dinámico (una representación del comportamiento del sistema y los objetos)
- El modelo funcional (una representación a alto nivel del flujo de información a través del
sistema similar al DFD)

El método de Wirfs-Brock. No hace una distinción clara entre las tareas de análisis y diseño. Se
propone un proceso continuo que comienza con la valoración de una especificación del cliente y
termina con el diseño.

Aunque la terminología y etapas del proceso de c/u de los métodos difieren se consideran las
siguientes etapas genéricas:
 Obtener los requisitos del cliente para el sistema OO.
 Identificar escenarios o casos de uso
 Construir un modelo de requisitos
 Seleccionar clases y objetos usando los requisitos básicos como guías
 Identificar atributos y operaciones para cada objeto del sistema
 Definir estructuras y jerarquías que organicen las clases
 Construir un modelo objeto-relación
 Construir un modelo objeto-comportamiento
 Revisar el modelo de análisis OO en relación a los casos de uso/escenarios

20.2. ANÁLISIS DEL DOMINIO

El AOO tiene diferentes niveles de abstracción:

 Al nivel de negocios o empresas pueden acoplarse con un enfoque de ingeniería de información en
un esfuerzo por definir clases, objetos, relaciones y comportamientos que modelen el negocio por
completo.
 Al nivel de áreas de negocios, puede definirse un modelo de objeto que describa el trabajo de un
área específica de negocios.
 Al nivel de las aplicaciones, el modelo de objetos se centra en los requisitos específicos del cliente
pues estos afectan a la aplicación que se va a construir.

2
El análisis que se realiza a un nivel medio de abstracción se llama análisis del dominio. Tiene lugar
cuando una organización desea crear una biblioteca de clases reutilizables (componentes) ampliamente
aplicables a una categoría completa de aplicaciones.
20.2.1. Análisis de reusabilidad y del dominio

Las tecnologías de objetos están influenciadas por la reusabilidad (reutilización)

20.2.2. El proceso de análisis de dominio

El objetivo del análisis de dominio es crear aquellas clases ampliamente aplicadas, de tal manera que
sean reusables (reutilizables)
El análisis de dominio es una actividad en curso de ingeniería del software no ligada a ningún proyecto
de software (ej: maestro tornero que diseña y construye herramientas que pueden usarse por varias
personas que trabajan en aplicaciones similares pero no idénticas)
El proceso de análisis de dominio puede identificarse por una serie de actividades:

Definir el dominio a investigar. El analista debe primero aislar el área de negocio, luego se deben
extraer los elementos OO (especificaciones, diseños y código para clases de aplicaciones ya
existentes, clases de soporte, bibliotecas y casos de prueba) y no OO (políticas, procedimientos,
planes, estándares y guías, métricas)

Clasificar los elementos extraídos del dominio. Los elementos se organizan en categorías y se
establecen las características generales que definen la categoría.

Recolectar una muestra representativa de aplicaciones en el dominio. El analista debe asegurar que
la aplicación en cuestión tiene elementos que caen dentro de las categorías ya definidas. El analista
debe “identificar los objetos conceptuales (opuestos a los físicos) en cada aplicación no OO.

Analizar cada aplicación dentro de la muestra. Una vez que se han definido los objetos, el analista
debe estimar qué porcentaje de una aplicación típica pudiera construirse usando los objetos reusables.

Desarrollar un modelo de análisis para los objetos. El modelo de análisis servirá como base para el
diseño y construcción de los objetos del dominio.

Adicionalmente a estas etapas, el analista del dominio también debe crear un conjunto de líneas
maestras para la reusabilidad, y desarrollar un ejemplo que ilustre cómo los objetos del dominio
pudieran usarse para crear una aplicación nueva.

20.3. COMPONENTES GENÉRICOS DEL MODELO DE ANÁLISIS OO

Se define un conjunto de componentes de representación genéricos que aparecen en todos los modelos
de análisis OO. Los componentes estáticos son estructurales por naturaleza, e indican características
que se mantienen durante toda la vida operacional de una aplicación. Los componentes dinámicos se
centran en el control, son sensibles al tiempo y al tratamiento de eventos y definen cómo interactúa un
objeto con otros a lo largo del tiempo. Los siguientes componentes pueden identificarse:
Vista estática de clases semánticas. Se imponen los requisitos y se extraen (y representan)
clases como parte del modelo de análisis. Estas clases persisten a través de todo el período de
vida de la aplicación y se derivan en base a la semántica de los requisitos del cliente.

3
 Vista estática de los atributos. Los atributos asociados con la clase aportan una descripción de
la clase, así como una indicación inicial de las operaciones relevantes a esta clase.
Vista estática de las relaciones. Debe representar las relaciones de manera tal que puedan
identificarse las operaciones (que afecten estas conexiones) y que pueda desarrollarse un buen
diseño de intercambio de mensajes.
Vista estática de los comportamientos. Las relaciones anteriores definen un conjunto de
comportamiento que se adaptan al escenario utilizado (casos de uso). Estos comportamientos se
implementan a través de la definición de una secuencia de operaciones que los ejecutan.
Vista dinámica de la comunicación. Los objetos deben comunicarse unos con otros y hacerlo
basándose en una serie de mensajes que provoquen transiciones de un estado a otro del sistema.
Vista dinámica del control y manejo del tiempo. Debe describirse la naturaleza y tiempo de
duración de los eventos que provocan transiciones de estados.

20.4. EL PROCESO DE AOO

El proceso de AOO comienza con una comprensión de la manera en la que se usará el sistema. Una
vez que se ha definido el escenario, comienza el modelado del software.

20.4.1. Casos de uso o de utilización (use cases)

La recopilación de requisitos es siempre el primer paso en cualquier actividad de análisis del software.
Basado en estos requisitos, el ingeniero del software (analista) puede crear un conjunto de escenarios
de manera tal que cada uno identifique una parte del uso que se le dará al sistema a construir (casos de
uso).
Para crear un caso de uso se deben identificar los diferentes tipos de personas (o dispositivos) que usan
el sistema o producto. Estos actores actualmente representan papeles ejecutados por personas cuando
el sistema está en operación. Un actor y un usuario no son la misma cosa. Un usuario típico puede
desempeñar un cierto número de papeles (roles) cuando usa el sistema, mientras que el actor representa
una clase de entidades externas (no siempre personas) que sólo desempeñan un único papel.
No se identifican todos los actores en la primer iteración. Es posible identificar:
Actores primarios. Se identifican en la primer iteración e interactúan para lograr el
funcionamiento requerido del sistema y obtener de él, el beneficio propuesto.
Actores secundarios. Se identifican al aprender más sobre el sistema. Existen para dar soporte
al sistema de manera tal que los primarios puedan realizar su trabajo.
Una vez que los actores primarios han sido identificados, pueden desarrollarse casos de uso. El caso de
uso describe la forma en la cual un actor interactúa con el sistema. En general, un caso de uso es
simplemente una narración escrita que describe el papel de un actor al ocurrir la interacción con el
sistema.

20.4.2. Modelado de clases-responsabilidades-colaboraciones

Una vez que se han desarrollado los escenarios de uso básicos para el sistema, es tiempo de identificar
las clases candidatas, e indicar sus responsabilidades y colaboraciones (CRC).
El modelo CRC puede hacer uso de tarjetas índices virtuales o actuales. El intento es desarrollar una
representación organizada de las clases.
Las responsabilidades son los atributos y operaciones relevantes para la clase.
Los colaboradores son aquellas clases necesarias para proveer a una clase con la información
necesaria para completar una responsabilidad (solicitud de información o una solicitud de alguna
acción).

4
Clases
Los objetos se manifiestan en una variedad de formas: entidades externas, cosas, ocurrencias o
eventos, roles, unidades organizacionales, lugares, o estructuras.
Tipos de clases:
Clases dispositivo. Modelan entidades externas tales como sensores, motores y teclados.
Clases propiedad. Representan alguna propiedad importante del entorno del problema
(establecimiento de créditos dentro del contexto de una aplicación de préstamos)
Clases interacción. Modelan interacciones que ocurren entre otros objetos (una adquisición).

Características de los objetos y clases:

Tangibilidad. ¿Representa la clase algo tangible o palpable o representa información más

abstracta?
Inclusividad. ¿Es la clase atómica (no incluye otras clases) o es agregada (incluye al menos un
objeto anidado)?
Secuenciabilidad. ¿Es la clase concurrente (es decir posee su propio hilo de control) o
secuencial (es controlada por recursos externos)?
Persistencia. ¿Es la clase transitoria (creada y eliminada durante la ejecución del programa),
temporal (creada durante la ejecución del programa y eliminada una vez que éste termina), o
permanente (es almacenada en una base de datos)?
Integridad. ¿Es la clase corrompible (no protege sus recursos de influencias externas) o es
segura (la clase refuerza los controles de acceso a sus recursos)?

Las tarjetas índices creadas como parte del modelo CRC pueden extenderse para incluir el tipo de la
clase y sus características.

Responsabilidades
Pautas para especificar responsabilidades para las clases:
1. La inteligencia del sistema debe distribuirse de manera igualitaria. El grado de inteligencia
es lo que sabe el sistema y que puede hacer. Esta inteligencia puede distribuirse entre las
“clases tontas” (aquellas con pocas responsabilidades) que actúen como sirvientes de unas
pocas “clases listas” (aquellas con muchas responsabilidades). Este enfoque posee algunas
desventajas: concentra la inteligencia haciendo los cambios más difíciles; tiende a necesitar
más clases y por lo tanto el esfuerzo de desarrollo aumenta.
2. Cada responsabilidad debe establecerse lo más general posible. Deben residir en la parte
alta de la jerarquía de clases (puesto que son genéricas se aplicarán a todas las subclases),
debe usarse el polimorfismo.
3. La información y el comportamiento asociado a ella, debe encontrarse dentro de la misma
clase. Implementa el principio OO de encapsulamiento.
4. La información sobre un elemento debe estar localizada dentro de una clase, no
distribuida a través de varias clases. Una clase simple debe asumir la responsabilidad de
almacenamiento y manipulación de un tipo específico de información. No debe
compartirse.
5. Compartir responsabilidades entre clases relacionadas cuando sea apropiado. Existen
muchos casos en los cuales una gran variedad de objetos exhibe el mismo comportamiento
al mismo tiempo.

Colaboradores

5
Las colaboraciones identifican relaciones entre clases. Cuando todo un conjunto de clases colabora
para satisfacer algún requisito, es posible organizarlas en un subsistema (un elemento del diseño).
Las colaboraciones se identifican determinando si una clase puede satisfacer cada responsabilidad. Si
no puede, entonces necesita interactuar con otra clase.
Para ayudar en la identificación de colaboradores, el analista puede examinar tres relaciones genéricas
diferentes entre clases:
(1) La relación es-parte-de
(2) La relación tiene-conocimiento-sobre
(3) La relación depende-de
Todas las clases que forman parte de una clase agregada, están conectadas a ésta a través de una
relación es-parte-de (la clase cuerpo-del-jugador es-parte-de jugador)
Cuando una clase debe obtener información sobre otra, se establece la relación tiene-conocimiento-
sobre.
La relación depende-de implica que dos clases poseen una dependencia no realizable a través de tiene-
conocimiento-sobre o es-parte-de (la cabeza-de-jugador depende-de cuerpo-del-jugador)
El modelo CRC es una primera representación del modelo de análisis para un sistema OO. Puede ser
“probado” realizando una revisión dirigida por casos de uso derivados del sistema.

20.4.3. Definición de estructuras y jerarquías

Una vez que se han identificado las clases y objetos usando el modelo CRC, el analista comienza a
centrarse en la estructura del modelo de clases y las jerarquías resultantes que surgen al emerger
clases y subclases. Coad y Yourdon sugieren que debe derivarse una estructura de generalización-
especialización (gen-espec) para las clases identificadas.(Ej: sensor, sensor de entrada, sensor de
movimiento)
En otros casos, un objeto representado según el modelo inicial puede estar compuesto realmente de un
número de partes las cuales pueden definirse a su vez como objetos. Estos objetos agregados pueden
representarse como una estructura todo-partes.

20.4.4. Definición de temas y subsistemas

Los subconjuntos de clases que colaboran entre sí para llevar a cabo un conjunto de responsabilidades
cohesionadas se les llama normalmente temas o subsistemas.
Un subsistema implementa uno o más contratos con sus colaboradores externos. Un contrato es una
lista específica de solicitudes que los colaboradores pueden hacer a un subsistema.
Los temas son idénticos a los subsistemas en intención y contenido, pero se representan graficamente.
Las referencias de temas se crean generalmente para cualquier estructura que posea más de cinco o seis
objetos.

20.5. EL MODELO OBJETO-RELACIÓN

El siguiente paso es definir aquellas clases colaboradoras que ayudan en la realización de cada
responsabilidad. Esto establece la “conexión” entre las clases.
Una relación existe entre dos clases cualesquiera que estén conectadas. Debido a esto los
colaboradores siempre están relacionados de alguna manera. El tipo de relación más comun es la
binaria que en un sistema OO posee una dirección específica que se define a partir de que clase
desempeña el papel de cliente y cuál actúa como servidor.
Las relaciones pueden derivarse a partir del examen de los verbos o frases verbales en el
establecimiento del alcance o casos de uso para el sistema. El analista aisla los verbos que indican

6
localizaciones físicas o emplazamientos (cerca de, parte de, contenido en), comunicaciones (transmite
a, obtenido de), propiedad (incorporado por, se compone de) y cumplimiento de una condición
(dirige, coordina, controla). Estos aportan una indicación de la relación.
El modelo objeto-relación puede derivarse en tres pasos o etapas:
(1) Usando las tarjetas índice CRC, puede dibujarse una red de objetos colaboradores. Primero
se dibujan los objetos conectados por líneas sin etiquetas que indican la existencia de
alguna relación entre los objetos conectados.
(2) Revisando el modelo CRC de tarjetas índices, se evalúan responsabilidades y colaboradores
y cada línea de conexión sin etiquetar recibe un nombre y la dirección de la relación.
(3) Una vez que se han establecido y nombrado las relaciones, se evalúa cada extremo para
determinar la cardinalidad. Existen cuatro opciones: 0 a 1, 1 a 1, 0 a muchos, o 1 a muchos.
Los pasos anteriormente mostrados continúan hasta que se produzca el modelo completo.

20.6. EL MODELO OBJETO-COMPORTAMIENTO

El modelo CRC y el de objeto-relación representan elementos estáticos del modelo de AOO.

El modelo objeto-comportamiento indica cómo responderá un sistema OO a eventos externos o
estímulos (comportamiento dinámico)
Pasos para crear el modelo:
1. Evaluar todos los casos de uso para comprender totalmente la secuencia de interacción
dentro del sistema.
2. Identificar eventos que dirigen la secuencia de interacción y comprender cómo estos
eventos se relacionan con objetos específicos.
3. Crear una traza de eventos para cada caso de uso.
4. Construir un diagrama de transición de estados para el sistema.
5. Revisar el modelo objeto-comportamiento para verificar exactitud y consistencia.

20.6.1. Identificación de eventos con casos de uso

Un evento ocurre cada vez que un sistema OO y un actor intercambian información. Un evento es
booleano. Un evento no es la información que se intercambia; es el hecho que la información ha sido
intercambiada.
Un caso de uso se examina por puntos de intercambio de información.
Deberá identificarse un actor para cada evento; la información que se intercambia debe anotarsr, y
deberán indicarse otras condiciones o restricciones.
Una vez que todos los eventos han sido identificados, se asocian a los objetos incluidos. Los actores y
objetos pueden responsabilizarse de la generación de eventos o reconociendo eventos que han
ocurrido en otra partee.

20.6.2. Representaciones de estados

Deben considerarse dos caracterizaciones de estados:

 El estado de cada objeto cuando el sistema ejecuta su función.
 El estado del sistema observado desde el exterior cuando éste ejecuta su función.
El estado de un objeto adquiere en ambos casos características pasivas (estado actual de todos los
atributos de un objeto) y activas (indica el estado actual cuando el objeto entra en una transformación
continua o proceso). Para forzar la transición de un objeto de un estado activo a otro debe ocurrir un
evento (a veces llamado disparador). Un componente de un modelo objeto-comportamiento es una
representación simple de los estados activos de cada objeto y los eventos (disparadores) que producen
los cambios entre estos estados activos.

7
Un segundo tipo de representación de comportamiento para el AOO considera una representación de
estados para el producto general o sistema. Esta representación abarca un modelo simple de traza de
eventos que indica cómo los eventos causan las transiciones de objeto a objeto y un diagrama de
transición de estados que ilustra el comportamiento de cada objeto durante el procesamiento.
Una vez que los objetos para un caso de uso han sido identificados, el analista crea una representación
acerca de cómo los eventos provocan el flujo desde un objeto a otro (traza de eventos).
Una vez que se ha desarrollado una traza completa de los eventos, todos aquellos que provoquen
transiciones entre objetos del sistema pueden incluirse en un conjunto de eventos de entradas y eventos
de salidas (desde un objeto). Esto puede representarse a partir de un diagrama de eventos.