1.5.

Papel de clases y objetos en el análisis y el diseño

Durante el análisis y las primeras etapas del diseño, el desarrollador tiene dos tareas principales:
* Identificar las clases y objetos que forman el vocabulario del dominio del problema.
* Idear las estructuras por las que conjuntos de objetos trabajan juntos para lograr los
comportamientos que satisfacen los requerimientos del problema.

En conjunto, se llama a esas clases y objetos las abstracciones clave del problema, y se denomina
a esas estructuras cooperativas los mecanismos de la implantación. Durante estas fases del
desarrollo, el interés principal del desarrollo debe estar en la vista externa de estas abstracciones
clave y mecanismos.

Esta vista representa el marco de referencia lógico del sistema y, por tanto, abarca la estructura
de clases y la estructura de objetos del mismo. En las etapas finales del diseño y entrando ya en
la implantación, la tarea del desarrollador cambia: el centro de atención está en la vista interna
de estas abstracciones clave y mecanismos, involucrando a su representación física. Pueden
expresarse estas decisiones de diseño como parte de la arquitectura de módulos y la arquitectura
de procesos del sistema.

La experiencia de algunos analistas nos lleva a aplicar en primer lugar el criterio orientado a
objetos porque esta aproximación es mejor a la hora de servir de ayuda para organizar la
complejidad innata de los sistemas de software, al igual que ha servido de ayuda para describir
la complejidad organizada de sistemas complejos tan diversos como los computadores, plantas,
galaxias o grandes instituciones sociales.

Los sistemas orientados a objetos son también más resistentes al cambio y por lo tanto están
mejor preparados para evolucionar en el tiempo, porque su diseño está basado en formas
intermedias estables.

El modelo de objetos ha influido incluso en las fases iniciales del ciclo de vida del desarrollo del
software. El análisis orientado a objetos (AOO) enfatiza la construcción de modelos del mundo
real utilizando una visión del mundo orientado a objetos:
El análisis orientado a objetos es un método de análisis que examina los requisitos desde la
perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema.
Básicamente los productos del análisis orientado a objetos sirven como modelos de los que se
puede partir para un diseño orientado a objetos; los productos del diseño orientado a objetos
pueden utilizarse entonces como anteproyectos para la implementación completa de unos
sistemas utilizando métodos de programación orientado a objetos, de esta forma se relacionan
AOO, DOO y POO.

Se insiste que se ha encontrado un gran valor en la construcción de modelos que se centran en

las “cosas” que se encuentran en el espacio del problema formando lo que se ha llamado una
descomposición orientada a objetos.

El diseño orientado a objetos es el método que lleva a una descomposición orientado a objetos.
Ofrece un rico conjunto de modelos que reflejan la importancia de plasmar explícitamente las
jerarquías de clases y de objetos de los sistemas que diseña.

El análisis orientado a objetos (AOO) se basa en conceptos sencillos, conocidos desde la infancia
y que aplicamos continuamente: objetos y atributos, él todo y las partes, clases y miembros.
Puede parecer llamativo que se haya tardado tanto tiempo en aplicar estos conceptos al
desarrollo de software. Posiblemente, una de las razones es el éxito de los métodos de análisis
estructurados, basados en los conceptos de flujo de información, que monopolizaron el análisis
de sistemas de software durante los últimos veinte años.

El AOO ofrece un enfoque nuevo para el análisis de requisitos de sistemas software. En lugar de
considerar el software desde una perspectiva clásica de entrada - proceso - salida, como los
métodos estructurados clásicos se basan en modelar el sistema mediante los objetos que forman
parte de el y las relaciones estáticas o dinámicas entre estos objetos.

Este enfoque pretende conseguir modelos que se ajusten mejor al problema real a partir del
conocimiento del llamado dominio del problema.

UN PUNTO DE VISTA:
Desde el punto de vista de los análisis antes mencionados hablamos del AOO y el AEO, podemos
decir que el AOO concibe una abstracción mayor que el AEO, que modela los sistemas desde un
punto de vista más próximo a su implementaron en un ordenador (entrada/proceso/salida).
La ventaja del AOO es que se basa en la utilización de objetos como abstracciones del mundo
real. Esto nos permite centrarnos en los aspectos significativos del domino del problema (en las
características de los objetos y las relaciones que se establecen entre ellos) y este conocimiento
se convierte en la parte fundamental del análisis del sistema software que será utilizado luego
en el diseño y la implementación.
En el AOO los objetos encapsulan tanto atributos como procedimientos (operaciones que se
realizan sobre los objetos), e incorpora, además, conceptos como los polimorfismos o la herencia
que facilitan la reutilización de código.

Podemos concluir entonces que el AOO puede facilitar mucho la creación de prototipos, y las
técnicas de desarrollo evolutivo de software. Los objetos don inherentemente reutilizables, y se
puede crear un catálogo de objetos que podemos usar en sucesivas aplicaciones. De esta forma,
podemos obtener rápidamente un prototipo del sistema, que pueda ser evaluado por el cliente,
a partir de los objetos analizados, diseñados e implementados en aplicaciones anteriores. Y lo
que es más importante, dada la facilidad de reutilización de estos objetos, el prototipo puede ir
evolucionando hacia convertirse en el sistema final, según vamos refinando los objetos de
acuerdo a un proceso de especificación incremental.

VENTAJAS DEL AOO:

Dominio del problema

El paradigma OO es más que una forma de programar. Es una forma de pensar acerca de un
problema desde el punto de vista del mundo real en vez de desde el punto de vista del ordenador.
El AOO permite analizar mejor el dominio del problema, sin pensar en términos de implementar
el sistema de un ordenador, permite, además, pasar directamente el dominio del problema al
modelo del sistema.

Comunicación
El concepto OO es más simple y esta menos relacionado con la informática que el concepto de
flujo de datos. Esto permite una mejor comunicación entre el analista y el experto en el dominio
del problema.

Consistencia
Los objetos encapsulan tanto atributos como operaciones. Debido a esto, el AOO reduce la
distancia entre el punto de vista de los datos y el punto de vista del proceso, dejando menos lugar
a inconsistencias disparidades entre ambos modelos.

Expresión de características comunes

El paradigma lo utiliza la herencia para expresar explícitamente las características comunes de
una serie de objetos estas característica comunes quedan escondidas en otros enfoques y llevan
a duplicar entidades en el análisis y código en los programas. Sin embargo, el paradigma OO pone
especial énfasis en la reutilización y proporciona mecanismos efectivos que permiten reutilizar
aquello que es común sin impedir por ello describir las diferencias.

Resistencia al cambio
Los cambios en los requisitos afectan notablemente a la funcionalidad de un sistema por lo que
afectan mucho al software desarrollando con métodos estructurados. Sin embargo, los cambios
afectan en mucha menos medida a los objetos que componen o maneja el sistema, que son
mucho más estables. Las modificaciones necesarias para adaptar una aplicación basada en
objetos a un cambio de requisitos suelen estar mucho más localizadas.

Reutilización
Aparte de la reutilización interna, basada en la expresión explícita de características comunes, el
paradigma 00 desarrolla modelos mucho más próximos al mundo real, con lo que aumentan las
posibilidades de reutilización. Es probable que en futuras aplicaciones nos encontremos con
objetos iguales o similares a los de la actual.

ELEMENTOS FUNDAMENTALES DEL ANALISIS ORIENTADO A OBJETOS

EL MODELO DE OBJETOS

El modelo de objetos describe la estructura de los objetos de un sistema: su identidad, sus

relaciones con otros objetos, sus atributos y sus operaciones. Los cambios y las transformaciones
no tienen sentido a menos que haya algo que cambiar o transformar.

El modelo de objetos se representa gráficamente con diagramas de objetos y diagramas de

instancias, que contienen clases de objetos e instancias respectivamente. Las clases se disponen
en jerarquías que compartan una estructura de datos y un comportamiento común, y se
relacionan con otras clases. Cada clase define los atributos que contiene cada uno de los objetos
o instancias y las operaciones que realizan o sufren.

La tecnología orientada a objetos se apoya en sólidos fundamentos de la ingeniería, cuyos

elementos reciben el nombre global de modelo de objetos. El modelo de objetos abarca
principios fundamentales que los detallaremos más adelante.

Quede claro que el diseño orientado a objetos es fundamentalmente diferente a los enfoques de
diseño estructurado tradicionales; requiere un modo distinto de pensar acerca de la
descomposición y produce arquitecturas software muy alejadas del dominio de la cultura del
diseño estructurado.
Además, conviene mencionar que se observa que la mayoría de los programadores trabajan en
un lenguaje y utilizan solo un estilo de programación. Programan bajo un paradigma apoyado por
el lenguaje que usan. Frecuentemente, no se les han mostrado vías alternativas para pensar
sobre un problema, y por lo tanto tiene dificultades para apreciar las ventajas de elegir un estilo,
más apropiado para el problema que tienen entre manos.

No hay un estilo de programación que sea el mejor para todo tipo de aplicaciones. Por ejemplo,
la programación orientada a reglas sería la mejor para el diseño de una base de conocimiento, y
la programación orientada a procedimientos seria la más indicada para el diseño de operaciones
de cálculo intensivo. Por experiencia de algunos estudiosos de la materia, el estilo orientado a
objetos es él más adecuado para él más amplio conjunto de aplicaciones; realmente, este
paradigma de programación sirve con frecuencia como el marco de referencia arquitectónico en
el que se emplean otros paradigmas.

Cada uno de estos estilos de programación se basa en su propio marco de referencia conceptual.
Cada uno requiere una actitud mental diferente, una forma distinta de pensar en el problema.
Para todas las cosas orientadas a objetos, el marco de referencia conceptual es el modelo de
objetos.

FUNDAMENTOS DEL MODELO DE OBJETOS:

En realidad, el modelo de objetos ha recibido la influencia de una serie de factores, no solo de la

programación orientada a objetos. El modelo de objetos a demostrado ser un concepto u
unificador de en la informática. La razón de este gran atractivo es simplemente que una
orientación a objetos ayuda a combatir la complejidad inherente a muchos tipos de sistemas
diferentes.
El diseño orientado a objetos representa así un desarrollo evolutivo, no revolucionario; no rompe
con los avances del pasado, sino que se basa en avances ya probados.

Los métodos de diseñó estructurado surgieron para guiar a los desarrolladores que intentaban
construir sistemas complejos utilizando los algoritmos como bloques fundamentales para su
construcción. Análogamente los métodos de diseño orientados a objetos han surgido para
ayudar a los desarrolladores a explotar la potencia expresiva de los lenguajes de
programación basados en objetos y orientados a objetos, utilizando las clases como bloques
básicos de construcción.
Desgraciadamente, hoy en día la mayoría de los programadores han sido educados formal e
informalmente solo en los principios del diseño estructurado.

En el modelo de objetos es necesario estudiar los principios fundamentales en los que se basa el
análisis orientado a objetos, es decir:
· Abstracción
· Encapsulación
· Modularidad
· Jerarquía
· Concurrencia
Ninguno de estos principios es nuevo por sí mismo. Lo importante del modelo de objetos es el
hecho de conjugar todos estos elementos en forma sinérgica.

Al decir fundamentales, quiere decir que un modelo que carezca de cualquiera de estos
elementos no estará orientado a objetos.

Otros elementos que podrían llamarse secundarios, que quiere decir, que cada uno de ellos es
una parte útil del modelo de objetos, pero no esenciales son:
· Tipos
· Persistencia
A partir de los elementos antes mencionados, trataremos de mostrar, mediante una definición
en primer lugar de cada uno de ellos, cual es la asociación con el sistema solar y el sistema celular,
esto quiere decir que asociaremos estos elementos bases de la llamada teoría de los objetos con
el macrocosmo y el microcosmo, dictando sus características fundamentales para el
entendimiento claro de este. A la vez, también definiremos las desigualdades u oposiciones de
estos elementos con los sistemas antes mencionados.

En otras palabras veremos cómo pasamos de un análisis estructurado a un análisis orientado a

objetos, y viceversa. Macrocosmo v/s Microcosmo, esto incorporado al sistema de la teoría de
los objetos.