PDF de programación - Introducción al Análisis y Diseño Orientado a Objetos

Introducción al Análisis y Diseño Orientado a Objetos

Licenciado en Informática. Profesor del Área de Lenguajes y Sistemas Informáticos de

Francisco José García Peñalvo

la Universidad de Burgos.

[email protected]

Licenciado en Informática. Profesor del Área de Lenguajes y Sistemas Informáticos de



Carlos Pardo Aguilar

la Universidad de Burgos

[email protected]



La construcción de un sistema software, con independencia de su tamaño, de sus

características funcionales y de la tecnología elegida, consta de una serie de fases que
abarcan desde su concepción hasta su retirada, definiendo un espacio temporal que
recibe el nombre de ciclo de vida del software. Existen diferentes modelos de ciclo de
vida, cada uno con sus propias peculiaridades, adaptándose unos mejor que otros a los
distintos paradigmas o estilos de programación. Pero, lo que sí se puede afirmar es que

en ninguno de estos modelos de desarrollo se comienza un proyecto software por la

fase de implementación.


Comenzar un proyecto software por la fase de implementación, esto decir, colocarse
inmediatamente delante del ordenador y comenzar a generar código fuente, es
desgraciadamente una forma de trabajo bastante extendida, que toma sus tintes más
preocupantes cuando sale del entorno del programador ocasional o aficionado, para
convertirse en la forma de trabajo de la inmensa mayoría de las empresas de
construcción de software dentro y fuera de nuestras fronteras.
Por tanto, puede parecer utópico y dar la sensación de predicar en el desierto, el dedicar
un artículo al análisis y el diseño en la orientación a objeto, cuando prácticamente nadie
se molesta en seguir unos principios metodológicos básicos en sus desarrollos y,
además, la orientación a objeto en nuestro país no acaba de convertirse en una
alternativa completamente aceptada. No obstante, desde nuestra modesta posición
vamos a intentar aportar nuestro granito de arena en favor de lo que sería una forma más
correcta de realizar la construcción de una aplicación software desde el prisma de la
orientación a objetos.

Fases de un desarrollo orientado a objetos
Nada más lejos de la intención de este artículo que realizar la descripción de ningún
modelo de ciclo de vida del software, ya que para este fin el lector puede recurrir a
cualquiera de los textos clásicos sobre ingeniería del software, por ejemplo [1] y [2],
donde encontrará una información más amplia y precisa. Pero, dado que se ha
comenzado el artículo criticando la construcción de las aplicaciones que empiezan
directamente por la codificación, se va a dar un marco muy general de lo que sería un
desarrollo software, marco que en su generalidad es perfectamente válido para cualquier
tipo de desarrollo, independientemente que sea orientado a objeto o no.
El marco de desarrollo de una aplicación software estaría formado por las tres fases
tradicionales: análisis, diseño e implementación.

El análisis es la fase cuyo objetivo es estudiar y comprender el dominio del problema,
es decir, el análisis se centra en responder al interrogante ¿QUÉ HACER?
El diseño, por su parte, dirige sus esfuerzos en desarrollar la solución a los requisitos
planteados en el análisis, esto es, el diseño se haya centrado en el espacio de la solución,
intentando dar respuesta a la cuestión ¿CÓMO HACERLO?
Por último, la fase de implementación sería la encarga de la traducción del diseño de la
aplicación al lenguaje de programación elegido, adaptando por tanto la solución a un
entorno concreto.

Que este marco de desarrollo sea válido tanto para los desarrollos tradicionales
(desarrollos estructurados) como para los desarrollos orientados a objeto, no significa
que la realización de las actividades propias de cada fase se lleve a cabo de la misma
manera. De hecho, en los desarrollos estructurados hay mucha distancia entre las fases
de análisis de diseño, e incluso entre los diferentes modelos generados en una misma
fase. Esta separación se conoce con el nombre de gap semántico, y es la barrera que la
orientación a objeto intenta eliminar difuminando la frontera entre las diferentes fases.
Los métodos orientados a objeto acortan la distancia existente entre el espacio de
conceptos (lo que los expertos o usuarios conocen) y el espacio de diseño (lo que
conocen los desarrolladores) e
implementación, ya que
los
objetos del mundo real tienen
una correspondencia bastante
clara con
los objetos del
sistema informático, evitando
así
abismos
existentes entre el análisis y el
diseño
enfoque
estructurado, esto es la falta de
continuidad
la
representación de los conceptos
en una y otra fase, por ejemplo
los DFDs y los diagramas de
estructura, como muestra la Figura 1.
Por su parte, en los desarrollos orientados al objeto se tiene una mayor continuidad entre
las diferentes fases, con unas fronteras entre fases muy poco marcadas que dan lugar a
desarrollos más iterativos e incrementales. Todo esto es posible gracias a una
característica de vital importancia, el modelo subyacente a todas las fases es el mismo,
el modelo objeto, que tiene como elemento central al objeto, que es la entidad que
encapsula elementos estructurales y de comportamiento. De esta forma, los objetos
semánticos identificados en la fase de análisis se refinarán durante la fase de diseño e
implementación, a la vez que se añaden objetos de interfaz y de utilidad para constituir
la aplicación final, como se puede apreciar en la Figura 2.

Figura 1. Desarrollos estructurados.

RELACIONAL

los

grandes

en

el

Diseño
Diseño

Implementación
Implementación

Análisis
Análisis

DFD

S
O
S
E
C
O
R
P

S
O
T
A
D

DE

PROGRAMA

en

DER

TABLAS

Análisis
Análisis

Diseño
Diseño

Implementación
Implementación










S
O
T
E
J
B
O

Figura 2. Desarrollos orientados a objeto.

Como referencia de modelos objeto concretos puede hacerse mención al modelo de
objeto de OMT, definido por James Rumbaugh en [3], o al modelo objeto de UML [4],
entre muchos otros.

Análisis y diseño orientados a objetos (ADOO)
Como se ha comentado en el apartado anterior, la transición entre las fases de análisis y
diseño en la orientación al objeto es mucho más suave que en las metodologías
estructuradas, no habiendo tanta diferencia entre las etapas. Esto implica que es difícil
determinar donde acaba el Análisis Orientado a Objeto (AOO) y donde comienza el
Diseño Orientado a Objeto (DOO), siendo la frontera entre ambas fases totalmente
inconsistente, de forma que lo que algunos autores incluyen en el AOO otros lo hacen
en el DOO. Esto conduce a que sea frecuente el uso de las siglas ADOO para hacer
referencia a ambas fases de forma conjunta.
El objetivo del AOO es modelar la semántica del problema en términos de objetos
distintos pero relacionados. Por su parte, el DOO conlleva reexaminar las clases del
dominio del problema, refinándolas, extendiéndolas y reorganizándolas, para mejorar su
reutilización y tomar ventaja de la herencia. El análisis casa con el dominio del
problema y el diseño con el dominio de la solución; por lo tanto el AOO enfoca el
problema en los objetos del dominio del problema y el DOO en los objetos del dominio
de la solución.
Los objetos del dominio del problema representan cosas o conceptos utilizados para
describir el problema, recibiendo el nombre de objetos semánticos porque ellos
representan las abstracciones que encierran el significado del dominio del problema.
El análisis se centra en la representación del problema, es decir, en la identificación de
las abstracciones que representen el significado de las especificaciones y de los
requisitos del sistema.
El énfasis del diseño se centra en la definición de la solución. Los objetos semánticos
serán refinados durante la fase de análisis y de diseño, siendo completados con los
objetos propios del dominio de la solución.
Los objetos del dominio de la solución incluyen: objetos de interfaz, objetos de
aplicación y objetos base o de utilidad. Éstos no forman parte directamente de los
objetos del dominio problema, pero representan la vista del usuario de los objetos
semánticos.
Una vez realizada esta introducción al AOO y al DOO se puede proceder a dar una
definición más concreta de ambos procesos.

Se puede definir AOO como el proceso que modela el dominio del problema
identificando y especificando un conjunto de objetos semánticos que interaccionan y se
comportan de acuerdo a los requisitos del sistema.
Se puede definir DOO como el proceso que modela el dominio de la solución, lo que
incluye a las clases semánticas con posibles añadidos, y las clases de interfaz,
aplicación y utilidad identificadas durante el diseño.
No debiera darse por terminado este apartado sin enunciar cuales son las actividades
propias del AOO y del DOO. Este es un asunto comprometido por la diversidad
existente en el mundo de las metodologías orientadas a objeto, como se puso de
manifiesto en [5], pero de forma general podría afirmarse que:
• En el AOO deben llevarse a cabo las siguientes actividades:
• La identificación de clases semánticas, atributos y servicios
•

Identificación de las relaciones entre clases (generalizaciones, agregaciones y
asociaciones).

• El emplazamiento de las clases, atributos y servicios.
• La especificación del comportamiento dinámico mediante paso de mensajes.