Diseño Orientado A Objetos (DOO)
Jhon92Val3 de Junio de 2013
2.527 Palabras (11 Páginas)352 Visitas
Diseño orientado a los objetos
1
Diseño orientado a los objetos
El Diseño Orientado a los Objetos (DOO) crea una representación del problema
del mundo real y la hace corresponder con el ámbito de la solución, que es el
software.
A diferencia con otros métodos de diseño, el DOO produce un diseño que
interconecta objetos de datos y operaciones de procesamiento para esos
objetos, de forma que se modulariza la información y el procesamiento, en
lugar de aislar el procesamiento.
Todos los métodos de diseño intentan desarrollar software basándose en:
• Abstracción
• Ocultamiento de información
• Modularidad
El DOO proporciona un mecanismo que permite al diseñador consigue estas
tres características sin dificultad.
El Análisis Orientado a Objetos, el Diseño Orientado a Objetos y la
Programación Orientada a Objetos comprenden un conjunto de actividades de
la Ingeniería del Software para la construcción de un sistema basado en
objetos.
1. CONCEPTOS DEL DISEÑO ORIENTADO A OBJETOS
Al igual que todos los métodos de diseño utilizan su propia notación y
metodología, el DOO introduce un conjunto nuevo de términos, notaciones y
procedimientos para la derivación del diseño del software.
A continuación resumimos la terminología orientada a objetos e introducimos
algunos conceptos propios de esta forma de diseño-
1.1 Objetos, operaciones y mensajes
El funcionamiento del software se consigue al actuar uno o más procesos sobre
una estructura de datos de acuerdo con un procedimiento de invocación.
Para conseguir un DOO, tenemos que establecer un mecanismo para:
• Representar la estructura de datos
• Especificar el proceso
• Realizar el procedimiento de invocación
Objeto: Componente del mundo real que se hace corresponder con el
software. En un Sistema de Información basado en Computador, un objeto es
un producto o consumidor de información, o un elemento de información.
Cuando se hace corresponder un objeto con su realización software,
implementamos una estructura de datos y usa serie de procesos que pueden
transformar la estructura de datos.
Diseño orientado a los objetos
2
Operaciones, métodos o servicios: Procesos a los que se le permite
transformar estructuras de datos.
Mensajes: Peticiones que se realizan a los objetos para que realicen alguna de
sus operaciones. Las operaciones contienen construcciones procedimentales y
de control, que se invocan mediante un mensaje.
Al definir un objeto con parte privada y proporcionar mensajes para invocar al
procedimiento adecuado conseguimos el ocultamiento de información. De
esta forma dejamos ocultos al resto de los elementos de programa los detalles
de implementación del objeto.
Los objetos con sus operaciones proporcionan una modularidad inherente, es
decir los elementos del software (datos y procesos) están agrupados con un
mecanismo de interfaz bien definido, que son los mensajes.
1.2. Aspectos de diseño
Meyer sugiere cinco criterios para evaluar la calidad de un método de diseño a
partir de la modularidad.
Descomponibilidad: Facilidad con la que un método de diseño ayuda al
diseñador a descomponer un problema en subproblemas más sencillos.
Componibilidad: Grado en el que un método de diseño permite la
reutilizabilidad de módulos.
Compresibilidad: Facilidad para comprender un componente del programa sin
tener que hacer referencia a otros módulos.
Continuidad: Capacidad de realizar cambios en un programa y que esos
cambios afecten a un número mínimo de módulos.
Protección: Característica arquitectónica que reduce la propagación de
errores.
A partir de estos criterios, Meyer sugiere la derivación de cinco principios de
diseño para arquitecturas modulares:
Diseño orientado a los objetos
3
• Unidades modulares
• Pocas interfaces
• Interfaces pequeñas (acoplamiento débil)
• Interfaces explícitas
• Ocultamiento de información
Para conseguir un acoplamiento débil, se debe minimizar el número de
interfaces entre módulos y minimizar la cantidad de información que se mueve
a través de una interfaz.
Siempre que los módulos tengan que comunicarse tiene que hacerlo de forma
clara, mediante interfaces explícitas, y no mediante una zona global de datos,
ya que la comunicación entre módulos no sería fácilmente comprensible para
un observador externo.
El principio de ocultamiento de información se consigue cuando toda la
información del módulo está oculta para el acceso desde el exterior, a menos
que la información se defina explícitamente de forma pública.
Si bien estos principios son aplicables a cualquier tipo de diseño, el método de
Diseño Orientado a Objetos consigue alcanzar estos principios de forma más
eficiente que el resto de los enfoques, consiguiendo arquitecturas más
modulares.
1.3. Clases, instancias y herencia
Muchos objetos del mundo real tienen características prácticamente iguales y
realizan operaciones prácticamente similares.
Por ejemplo, si observamos un conjunto de vehículos, vemos que existen
motos, automóviles y camiones. Aunque todos estos objetos son diferentes,
todos pertenecen a una clase superior, llamada vehículo.
Todos los objetos de la clase vehículo tienen atributos comunes (marca,
modelo, ...) y realizan una serie operaciones comunes (acelerar, frenar, ...)
Las implementaciones en software de objetos del mundo real se hacen de
forma muy similar. Todos los objetos son miembros de una clase mayor y
heredan la estructura de datos privada y las operaciones que se hayan
definido para esa clase.
Es decir una clase es un conjunto de objetos que tienen las mismas
características. Así, un objeto es una instancia de una clase mayor.
Pero, ¿qué ocurre cuando una instancia de una clase mayor contiene una serie
de atributos y/o operaciones que son propias de la instancia?
La solución a este problema es la creación de subclases, que heredaría los
atributos y las operaciones de la clase superior, y permite modificarlos para
ajustarlos a sus necesidades.
Diseño orientado a los objetos
4
El uso de clases, subclases y herencia tiene mucha importancia en la
Ingeniería del Software moderna. La reutilización de componentes del software
(que nos permite conseguir la componibilidad) se lleva a cabo creando objetos
(instancias) que se forman sobre los atributos y las operaciones de una clase o
una subclase. Sólo hay que especificar cuáles son las diferencias entre el
objeto nuevo y la clase, en vez de tener que volver a definir todas las
características del objeto.
1.4. Descripciones de los objetos
La descripción del diseño de un objeto (una instancia de una clase o de una
subclase) está compuesta de dos partes:
Descripción de la interfaz: Establece la interfaz del objeto, definiendo los
mensajes que puede recibir el objeto y las operaciones que puede realizar
cuando el objeto recibe el mensaje.
Descripción de la implementación: Muestra los detalles de cada una de las
operaciones implicadas como consecuencia de la recepción de un mensaje.
Los detalles de implementación incluyen información sobre la parte privada del
objeto, es decir, los detalles de las estructuras de datos y los detalles
procedimentales que describen las operaciones.
La descripción de la interfaz son un conjunto de mensajes con sus comentarios
correspondientes
La descripción de la implementación debe contener la información suficiente
para que se puedan manejar de forma adecuada todos los mensajes recibidos
en la descripción de la interfaz.
A la diferencia entre la forma de especificar qué es lo que se desea y cómo se
proporciona ese servicio es lo que se conoce como encapsulación.
Por tanto, el paradigma orientado a objetos persigue la encapsulación, es decir,
mostrar sólo las operaciones visibles, y ocultar los detalles de implementación,
creando una sensación de cajas negras a las que se envían mensajes, pero no
se conocen los detalles de implementación de la gestión de esos mensajes.
Diseño orientado a los objetos
5
2. METODOS DE DISEÑO ORIENTADOS A OBJETOS
Antes de continuar debemos comprender la diferencia entre el Análisis
Orientado a Objetos, que es una actividad de clasificación, y el Diseño
Orientado a Objetos, que define los objetos que se derivan de cada clase, se
tiene que indicar las relaciones que existen entre ellos mediante una notación.
El DOO tiene que comenzar con una descripción en lenguaje natural de la
estrategia de solución, y a partir de esta descripción, el diseñador identifica los
objetos y operaciones.
2.1. Pasos del Diseño Orientado a Objetos
1) Definición del problema
2) Desarrollo informal
...