Analisis Orientado a Objetos

Un libro abierto es un cerebro que habla; cerrado un amigo que espera; olvidado, un alma que perdona; destruido, un corazón que llora. Proverbio hindú

miércoles, mayo 10, 2006

RESUMEN ANLAISIS ORIENTADO A OBJETOS

NATALY PEREZ
-------------

En un programa orientado a objetos tendremos a un conjunto de objetos colaborando entre ellos.

La orientación a objetos es paradigma de que está de moda para el desarrollo de software.
Un objeto es una abstracción conceptual del mundo real que se puede traducir a un lenguaje de programación orientado a objetos.
Un objeto del mundo real tiene características y comportamientos, y de la misma manera, un objeto del mundo del software tiene variables y métodos.
Una Clase es una plantilla que define las variables y métodos a ser incluidas en un tipo de objeto específico.
Los objetos también son llamados instancias de la Clase. Los objetos sólo almacenan su estado. De dice que un objeto tiene estado cuando tiene valores en sus variables.
Los objetos se comunican entre ellos usando los mensajes. Un mensaje es la invocación de un método del objeto.
La orientación a objetos requiere de una metodología que integre el proceso de desarrollo y un lenguaje de modelamiento con herramientas y técnicas adecuadas.


ventajas de un lenguaje orientado a objetos

Fomenta la reutilización y extensión del código.
Permite crear sistemas más complejos.
Relacionar el sistema al mundo real.
Facilita la creación de programas visuales.
Construcción de prototipos
Agiliza el desarrollo de software
Facilita el trabajo en equipo
Facilita el mantenimiento del software
Lo interesante de la POO es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible.

jueves, mayo 04, 2006

Analisis Orientado a Objetos

Analisis Orientado a Objetos

ANALISIS Y DISEÑO ORIENTADO A OBJETOS
Durante los últimos años ha ido creciendo en forma considerable el análisis y diseño orientado a objetos. Se han publicado numerosos libros y muchas organizaciones están listas para implementar la práctica de esta nueva tecnología.
De un tiempo para acá ha venido presentándose un interés creciente en el campo del análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO). Este interés es debido a que la programación orientada a objetos (POO) se ha impuesto debido a sus enormes ventajas, pero las metodologías de análisis y diseño tradicional no son aplicables. Con la publicación de numerosos libros, los métodos se han estabilizado y ahora las organizaciones pueden moverse con tranquilidad a esta nueva tecnología.
Hay que tener en claro la idea de que un buen análisis puede acortar considerablemente la fase de desarrollo de programas, por ello, no se debe escatimar horas en organizar y estructurar la aplicación en cuestión. Este mensaje no sólo va dirigido para el analista - programador, sino también para algunos jefes de proyecto o gerente de empresas de desarrollo que se ponen literalmente nerviosos cuando ven que sus programadores están sentados mirando el techo, "sin hacer nada", y por consiguiente, no produciendo. Este es un gran error, sin duda. Que el programador tenga en claro que lo que va hacer es básico para que la aplicación sea realmente atractiva y competitiva, sobre todo para el usuario, que es el objetivo principal.
Vamos a ver en los párrafos siguientes en qué medida cambia el análisis y diseño a objetos, respecto del tradicional. Primeramente, desglosemos las diferentes partes en que se divide cada uno de ellos:


ANALISIS ORIENTADO A OBJETOS(AOO)
Como su propio nombre indica, lo que nos importa en este análisis es distinguir cuáles serán los objetos que van a ser parte de la aplicación. Tal vez ésta es la tarea más complicada del analista. En un primer momento, no debemos intentar enfocar con rigurosidad los objetos que nos puedan hacer falta en nuestra aplicación. Lo que haremos, un Brain Storming (tormenta de ideas que depuremos con posterioridad).
El primer paso que debemos hacer en un AOO será explicar con mayor claridad los puntos funcionales anteriormente definidos. Utilizamos para ello los escenarios.

ANALISIS MEDIANTE ESCENARIOS
Esta determinación viene a analizar la realidad como si de una película se tratase, viendo qué escenario se producen. Normalmente derivarán de los puntos funcionales.
El dependiente toma el producto del almacén y lo entrega al cliente
El dependiente comprueba el precio del producto, se lo dice al cliente y éste lo paga.
El dependiente rellena un recibo con los datos del producto y lo entrega al cliente.

DETERMINACION DE OBJETOS
La programación orientada a objetos se basa en la definición de clases. Una clase no es más que una abstracción de un objeto, o lo que es lo mismo, las características comunes de un grupo de objetos. Elegir qué conjunto de objetos son susceptibles de crear una abstracción, o sea, una clase, será la labor del analista. Por tanto buscaremos las clases que componen la aplicación, que luego se convertirá en objetos.
Una forma fácil de localizar objetos es encontrar en la aplicación:
 Cosas
 Lugares
 Personas o funciones
 Eventos
 Conceptos
 Organizaciones

Según esto, en nuestro ejemplo podemos conseguir los siguiente objetos:
Cosas Recibí (ticket)
Conceptos Productos
Lugares Almacén
Personas Dependiente, Clientes

Podríamos, por lo tanto, a partir de aquí, crear unas clases candidatas, es decir que posiblemente serán las clases utilizadas en la aplicación. Cuando definimos las clases tenemos que indicar cuáles van a ser los métodos y sus propiedades, así como los términos específicos de la programación orientada a objetos. Para aquellos que no están acostumbrados a esta terminología lo podemos comparar con estos procedimientos y variables que deben contener un módulo, donde podemos tomarnos la licencia de igualar clase con módulo, procedimiento con método y variable con propiedad.


El análisis orientado a objetos esta basado en un modelo de cinco capas:
1. Capa clase/objeto.
2. Capa de estructura.
3. Capa de atributos.
4. Capa de servicios
5. Capa de tema.

La figura ilustra como se entrelazan estas cinco capas.
1. Capa Clase/Objeto. Esta capa indica las clase y objetos.
2. Capa de Estructura. Esta capa captura diversas estructuras de clase y objetos, tales como las relaciones uno a muchos y la herencia.
3. Capa de Atributos. Esta capa detalla los atributos de las clases.
4. Capa de Servicios. Esta capa indica los mensajes y comportamientos del objeto (servicios y métodos).
5. Capa de Tema. Esta capa divide el diseño en unidades de implementación o asignaciones de equipos.

Análisis y clases de objetos.
Objeto: es una abstracción de algo en un dominio de un problema que refleja las capacidades de un sistema para llevar información acerca de ello, interactuar con ello a ambas cosas.
Es una representación en computadora de alguna cosa o evento del mundo real. Pueden tener tanto atributos y comportamientos.
Clase. Es una categoría de objetos similares. Los objetos se agrupan en clases. Una clase define el conjunto de atributos y comportamientos compartidos que se encuentran a cada objeto de la clase.
Clase y objeto. Un término que se refiere tanto a clase como a los objetos que ocurren en la clase.
Hay cinco tipos generales de objetos que pueden descubrirse durante el análisis. Los objetos a veces representan cosas tangibles como vehículos, dispositivos y libros. Algunas veces los objetos representan papeles actuados por personas u organizaciones. Los objetos también pueden ser derivados de incidentes o eventos. Otros objetos pueden indicar interacciones tales como una venta o un matrimonio. Las interacciones tienen una cualidad de transacción o contrato. Los objetos también pueden detallar especificaciones. Las especificaciones tienen estándares o una cualidad de definición y, por lo general, implican que otros objetos representaran ocurrencias de cosas tangibles.

Las clases son representadas por cuadros rectangulares redondeados (bubtángulos) divididos en tres partes. El nombre de la clase se muestra en la división superior del cuadro. Las otras dos divisiones se usan para las capas de atributo y servicio. Cuando una clase aparece sin objetos, puede ser solamente una clase base, debido a que la única razón para tal clase "sin objetos" es que sea un medio para agrupar atributos y servicios que serán heredados por varias otras clases.
Los objetos que tienen ocurrencia de una clase son representados por un cuadro sombreados rodeado por la clase. Debido a que los objetos tiene ocurrencias de una clase.
Criterios que podemos usar para que nos ayuden a determinar si se justifica una nueva clase de objetos:
1. Hay una necesidad de recordar el objeto. Esto es, el objeto puede ser descrito en un sentido definido y sus atributos son relevantes para el problema.
2. Hay una necesidad de determinados comportamientos del objeto. Esto es, aunque un objeto no tenga atributos, hay servicios que debe proporcionar o estados de objeto que deben ser llamados.
3. Usualmente un objeto tendrá varios atributos. Los objetos que tienen solamente uno o dos atributos sugieren diseños sobreanalizados.
4. Usualmente una clase tendrá mas de una instancia de objeto, a menos de que sea una clase base.
5. Usualmente los atributos tendrán siempre un valor significativo para cada objeto de la clase. Los objetos que producen valor NULO para un atributo, o para los que no es aplicable un atributo, por lo general implican una estructura generalización-especificación.
6. Usualmente los servicios siempre se comportarán en la misma forma para todos los objetos de la clase. Los servicios que varían dramáticamente para algunos objetos de una clase o que regresan sin realizar acción para algunos objetos también sugieren una estructura generalización-especificación.
7. Los objetos deben implementar requerimientos que son derivados del problema y no de la tecnología de solución. La parte de análisis del proyecto orientado a objetos no debe llegar a ser dependiente de una tecnología de implementación particular, tal como un sistema de computadora especifico o un lenguaje de programación especifico. Los objetos que atienden tales detalles técnicos no deben aparecer sino hasta muy tarde en la etapa de diseño. Los objetos dependientes de la tecnología sugieren que el proceso de análisis tiene fallas.
8. Los objetos no deben duplicar atributos o servicios que pueden ser derivados de otros objetos del sistema. Por ejemplo, un objeto que guarda la edad de un empleado es superfluo cuando existe un objeto de empleado separado que conserva el atributo fecha de nacimiento. El objeto edad puede ser eliminado por un servicio edad que es componente del objeto empleado.

DISEÑO ORIENTADO A OBJETOS
Diseño Orientado a Objetos
El diseño orientado a objetos (DOO) crea una representación del campo del problema del mundo real y la hace corresponder con el ámbito de la solución que es el Software, además produce un diseño que intercambia objeto de datos y operaciones de procesamiento en una forma que modulariza la información y el procesamiento en lugar de dejar aparte el procesamiento.
El DOO se caracteriza por mantener a la hora del diseño:
• La abstracción
• La modularidad
• El ocultamiento de la información
Todos los métodos de diseño tratan de mantener estas tres características presentes pero el DOO consigue las tres características sin complejidad.
Algunos especialista en la materia dicen acerca de la Metodología: "Ya no es necesario esforzarse en resolver un determinado problema mediante la aplicación de la estructura de datos usando las normas de los lenguajes de programación, deseando lograr mantener los principios de diseño, pues hacerlo mediante ese método nos dificultaría el trabajo, ya que en DOO muy fácil lograrlo sin tanta complejidad manteniendo las normas necesaria para el diseño".
El análisis, el diseño y la programación orientado a los objetos comprenden la INGENIERÍA DEL SOFTWARE para la construcción de un sistema orientado a los objetos.
Orígenes del diseño orientado a los objetos
En los primeros días de la informática, los lenguajes ensambladores permitían a los programadores utilizar instrucciones Máquina, para manipular elementos de datos, pero el nivel de abstracción era muy bajo.
Al parecer algunos lenguajes de programación de alto nivel (Fortran, cobol) lo lograron con la presencia de estructura de datos y de control logrando detallarlo mediante procedimiento, fue entonces cuando evolucionaron los conceptos de refinamiento de funciones y modularidad. Después en los años setenta aparecen los conceptos de abstracción y el ocultamiento de la información aunque los diseñaron se centraban todavía en los procesos y sus representaciones, pero al mismo tiempo los lenguajes se enriquecieron con sus estructuras y tipos de datos (PASCAL).
Entonces los lenguajes convencionales surgidos de la tradición fueron evolucionando (Fortran, Algol), los investigadores trabajaban en una nueva clase de lenguaje de simulación y de creación de prototipos (SIMULA, SMALLTALK) el énfasis estaba en la abstracción de datos y se representaba por un conjunto de objeto de datos y un conjunto correspondiente de operaciones los cuales se usaban distintamente a los lenguajes convencionales.
Los primeros trabajos de la abstracción en los últimos 20 años sentaron las bases al establecer la importancia de la abstracción, del ocultamiento de la información y de la modularidad para la calidad del software.
Seguidamente en los años ochenta la rápida evolución del Fortran, Ada, seguida de un crecimiento explosivo de los dialectos de C como C++, produjeron un interés inusitado en el DOO
Conceptos de diseño orientado a los objetos
El DOO introduce un conjunto de términos, notaciones y procedimientos para la derivación del diseño del software. Para conseguir un DOO debemos establecer un mecanismo para:
• Representar la estructura de datos
• Especificar el proceso
• Llevar a cabo el procedimiento de invocación
Objetos, operaciones y mensajes
Objetos: es un componente del mundo real que se ha hecho corresponder con el campo del software. En un sistema el objeto es considerado como un productor o consumidor de información
Ejemplo: monitores, interruptores, archivos.
Operaciones : consiste de una estructura de datos privada y en procesos, cuando se hace corresponde un objeto con su realización software, que pueden legítimamente transformar la estructura de datos, se conocen como métodos y servicios.
Mensaje: Las operaciones contiene unas instrucciones procedimentales y de control que pueden ser invocadas mediante un mensaje, en otras palabras, es una petición al objeto para que realice alguna de sus operaciones
El objeto tiene una parte compartida que es su interfaz, los mensajes llegan al objeto a través de su interfaz y especifica la operación que se desea que realizar sobre el objeto, aunque no como se ha de realizar.
Al definir un objeto como parte privada y proporcionar mensajes para invocar el procesamiento adecuado, conseguimos el ocultamiento de la información, es decir, dejar oculto para el resto de los elementos del programa los detalles de implementación del objeto.
Aspectos de diseño
Existen cinco criterios para juzgar la capacidad del método de diseño de conseguir la modularidad y los relaciona con el DOO:
Descomponibilidad : facilidad del método de diseño de conseguir un gran problema en sub-problemas más fáciles de resolver
Compatibilidad : grado en que se asegura que las componentes del programa una vez diseñada pueda ser rehusadas para crear programas.
Comprensibilidad : facilidad con que se comprende una componente de un programa sin necesidad de buscar información en otros módulos.
Continuidad : capacidad de realizar cambios en un programa y que se manifiesten por sí mismo con solo unos cambios correspondientes en unos pocos módulos
Protección : reduce la propagación de efectos colaterales cuando se produce un error en un modulo.
A partir de estos criterios se sugiere la derivación de cinco principios básicos de diseño para arquitectura modulares:
• Unidades lingüísticamente modulares: que corresponden a unidades sintácticas en el lenguaje utilizado, es decir el lenguaje de programación que se vaya a utilizar debe soportar la modularidad.
• Pocas interfaces: se debe minimizar el número de interfaces entre módulos.
• Interfaces pequeñas: minimizar la cantidad de información que se mueve a través de una interfaz.
• Interfaces explícitas: deben de comunicarse de forma obvia y directa cada vez que los módulos que se quiera modificar.
• Ocultamiento de la infamación: Esto ocurre cuando toda la información de un modulo esta oculta para un acceso desde el exterior.
Los criterios y los principios se aplican a cualquier método de diseño pero como veremos mas adelante el DOO los aplica mas eficientemente.
Clases instancias y herencia
Todos los objetos son miembros de una clase mayor y heredan la estructura de datos privadas y las operaciones que han sido definidas para esa clase. Dicho de otra forma, una clase es un conjunto de objetos que tiene las mismas características. Así, un objeto es una instancia de clase mayor.
El uso de clases, subclases y herencia es de crucial importancia en la ingeniería del software moderna. La reutilización de componentes de software de software (lo que nos permite conseguir la composición) se lleva a cabo creando objetos (instancias) que se forman sobre atributos y las operaciones existentes heredadas de una clase o de una subclase.
A diferencia de otros conceptos de diseño que son independientes del lenguaje de programación que se utilice, la implementación de las clases, de las subclases y de los objetos varía de acuerdo con el lenguaje de programación que se utilice. Por esta razón, el anterior tratamiento genérico requerirá ciertas modificaciones para el contexto de cada lenguaje de programación especifico. Por ejemplo, en Ada, los objetos se implementan como paquetes y las instancias se obtienen mediante el uso de abstracciones de datos y tipos.
Descripciones de los objetos
La descripción de diseño de un objeto puede tener dos formas distintas.
Una descripción del protocolo: que establece la interfaz del objeto, definiendo cada mensaje que puede recibir el objeto y las operaciones que realiza el objeto cuando recibe el mensaje.
Una descripción de la implementación: que demuestra los detalles de cada operación implicada en la recepción de un mensaje por el objeto. Los detalles de implementación incluyen la información sobre la parte privada del objeto, esto es, los detalles internos de la estructura de datos, y los detalles procedimentales que describen las operaciones.
Para grandes sistemas con muchos mensajes, a menudo se pueden crear categorías de mensajes. Por ejemplo, para el sistema hogar seguro las categorías de mensaje podría ser:
• Mensajes de configuración del sistema.
• Mensajes de monitorización.
• Mensajes de sucesos.
Una descripción de la implementación está compuesta por la siguiente información:
• una especificación del nombre del objeto y de la referencia a una clase.
• una especificación de la estructura de datos privada, con indicación de los elementos de datos y sus tipos.
• una descripción procedimental de cada operación o, alternativamente, referencia a esas descripciones procedimentales.
Las diferencias entre la información contenida en la descripción del protocolo y la contenida en la descripción de la implementación, en términos de los "usuarios" y de los "suministradores" de los servicios, es la siguiente.
Un usuario de un "servicio" proporcionado por un objeto debe familiarizarse con el protocolo de invocación de ese servicio, es decir, con la forma de especificar qué es lo que desea.
Al suministrador del servicio (el propio objeto), lo que le concierne es cómo proporcionar el servicio al usuario, es decir, los detalles de implementación.
Métodos de diseño orientados a los objetos
Esencialmente, el análisis orientado a los objetos (AOO) es una actividad de clasificación. Es decir, se analiza un problema con el fin de determinar clases de objetos que sean aplicables en el desarrollo de la solución. El diseño orientado a los objetos (DOO) permite al ingeniero de software indicar los objetos que se derivan de cada clase y las inter-relaciones entre ellos. Además el DOO debe proporcionar una notación que refleje las relaciones entre los objetos.
A inicios de los años ochenta, tanto Abbot como Booch establecen que el DOO debe comenzar con una descripción en lenguaje natural de la estrategia de solución, mediante una realización en software, de un problema del mundo real.
En su estado actual de evolución, los métodos de DOO combinan elementos de las tres categorías de diseño presentadas anteriormente: diseño de datos, diseño arquitectónico y diseño procedimental. Al identificar clases y objetos, se crean abstracciones de datos. Asociando operaciones a los datos, se especifican módulos y se establece una estructura para el software. Al desarrollar mecanismos para la utilización de los objetos se describen las interfaces.
Los métodos de DOO están caracterizados por los siguientes pasos:
1. Definir el problema.
2. Desarrollar una estrategia informal (narrativa de procesamiento) para la realización en software del campo del problema del mundo real.
3. Formalizar la estrategia mediante los siguientes sub-pasos:
• Identificar los objetos y sus atributos.
• Identificar las operaciones que se les puede aplicar a los objetos.
• Establecer interfaces que muestren las relaciones entre los objetos y las operaciones.
• Decidir aspectos del diseño detallado que proporcionen una descripción de la implementación de los objetos.
4. Volver a aplicar los pasos 2, 3 y 4 recursivamente.
5. Refinar el trabajo realizado en el AOO, buscando las subclases, las características de los mensajes y otros detalles de elaboración.
6. Representar la(s) estructura(s) de datos asociado(s) con los atributos del objeto.
7. Representar los detalles procedimentales asociados con cada operación.
Definición de clases y objetos
La aplicación de los principios y métodos de análisis de requisitos permite al analista y al diseñador llevar a cabo dos sub-pasos necesarios:
• Describir el problema.
• Analizar y clarificar las limitaciones conocidas.
Refinamiento de las operaciones
Una vez que se ha identificado los objetos del espacio de la solución, el diseñador selecciona el conjunto de operaciones que actúan sobre los objetos.
Las operaciones se identifican examinando todos los verbos de la estrategia informal (La narrativa de la estrategia informal).
Aunque existen muchos tipos distintos de operaciones generalmente se pueden dividir en tres grandes categorías:
• Operaciones que manipula los datos de alguna forma (Por eje: adiciones, eliminaciones, cambio de formato, selecciones etc.).
• Operaciones que realizan algún calculo.
• Operaciones que monitorizan un objeto frente a la ocurrencia de algún suceso de control.
Por ejemplo la narrativa de procesamiento de Hogar Seguro contiene los siguientes fragmento de frase:”Cada sensor tiene asignado un número y un tipo” y “se programa una contraseña maestra para activar y desactivar el sistema”.
Estas dos frases indican tres cosas:
• Que para el objeto sensor es relevante una operación de asignación.
• Que se aplicará una operación programar al objeto sistema.
• Que activar y desactivar son operaciones que se aplican al sistema; también que el estado del sistema tiene que ser definido(usando la notación diccionario de datos) como:
ESTADO DEL SISTEMA =[ACTIVADO | DESACTIVADO]
La operación programar queda asignada durante el AOO, pero es durante el DOO cuando se refina en varias operaciones más especificas. Que son requeridas durante para configurar el sistema. Por ejemplo, tras dialogar con el ingeniero del producto, con el analista y probablemente con el departamento de ventas, el diseñador puede reelaborar la narrativa de procesamiento original y escribir lo siguiente para programar:
Programar permite al usuario de Hogar Seguro configurar el sistema una vez que ha sido instalado. El usuario puede:
• Instalar números de teléfonos.
• Definir retardos para alarmas.
• Construir una tabla de sensores que contenga el ID, el tipo y la ubicación de cada sensor.
• Cargar una contraseña maestra.
Por tanto el diseñador ha definido la operación simple programar y la ha sustituido por las operaciones: instalar, definir, construir y cargar. Cada una de las nuevas operaciones entra a formar parte de objeto sistema. Conoce las estructuras internas de datos internas que implementan los atributos del objeto y se invocan mandando al objeto mensajes de la forma:
MENSAJE(sistema) -> instalar: RECIBE número de teléfono;
Que implica que, para proporcionar al sistema un número de teléfono de emergencia, se le debe enviar al objeto sistema el mensaje instalar.
Componentes de programas e interfaces
Un aspecto muy importante de la calidad del diseño de software la modularidad, esto es, la especificación de componentes de programas (módulo) que, combinados forman el programa completo. El enfoque orientados a los objetos define el objeto como componente de programa que se encuentra enlazado con otros componentes. (Por ejemplo: datos privados, operaciones). Pero la definición de objeto y operaciones no es suficiente. Durante el diseño también debemos identificar las interfaces que existen entre los objetos y la estructura general (en sentido arquitectónico) de objetos.
Aunque un componente de programa es una abstracción de diseño, se puede representar dentro del contexto del lenguaje de programación que se va ha utilizar para implementar el diseño. Para dar cabida al DOO, el lenguaje de programación que se use en la implementación debe permitir crear el siguiente componente de programa (modelizado a partir de ADA)
PACKGE nombre-de-componente-de-programa IS
TYPE especificación de los objetos de datos
.
.
.
PROC especificación de las operaciones asociadas...
PRIVATE
PROC operación.1 (descripción de la interfaz) IS
.
.
.
END
PROC operación.n (descripción de la interfaz) IS
.
.
.
END
END nombre-de-componente-de-programa
De acuerdo con el anterior LDP (lenguaje de diseño de programa) similar a ADA, un componente de programa queda especificado indicando tanto los objetos de datos como las operaciones. La parte de especificación de componente indica todos los objetos de datos (declaración de la sentencia TYPE) y todas las operaciones(PROC por “procedimiento”) que actúan sobre ellos. La parte privada (PRÍVATE) del componente proporciona los detalles ocultos de la estructura de datos y del procesamiento. En el contexto de la discusión anterior, el paquete (PACKAGE) es conceptualmente similar a los objetos tratados en este capitulo.
El primer componente de programa a identificar debe ser el módulo de mas alto nivel desde el que se origina todo el procesamiento y del que evolucionan todas las estructuras de datos.
Una notación para el DOO
Se han propuesto otras notaciones que a menudo se encuentran en el campo industrial. En esta sección repasaremos algunas de ellas. Booch propone una notación que combina cuatro diagramas distintos para la creación del DOO:
• Un diagrama de clases: Que refleja las clases y sus relaciones.
• Un diagrama de objetos: Representa objetos específicos(instancias de una clase) y los mensajes que pasan por ellos. Como parte del diseño físico, se asignan las clases y los objetos a componentes de software específicos.
• El diagrama de módulos: a veces denominado diagrama de BOOCH sirve para ilustrar esos componentes de programas.
• Diagrama de procesos: Que permite al diseñador reflejar como se asignan los procesos a procesadores concretos en un gran sistema, Debido a que muchos sistemas orientados a los objetos contienen varios programas que se pueden ejecutar en varios procesadores distribuidos.
Representación de relaciones entre clases y entre objetos
BOOCH sugiere diagramas que representan clases y objetos, así como las relaciones entre ellos.
El diagrama de clases indica la “arquitectura de clases de un sistema”
La herencia se representa con un símbolo de flecha.
Las conexiones de doble trazo indican que una clase utiliza información contenida en otra clase.
Los símbolos de los extremos de la notación (doble trazo) indican la cardinalidad. Además del propio diagrama de clases, se puede definir cada clase con una plantilla que incluya su nombre, sus atributos y sus operaciones. Así como la información sobre la herencia. Los parámetros y el comportamiento.
La clase se define como parte del diseño de un sistema y existen independientemente del comportamiento en ejecución del sistema. Sin embargo los objetos se crean y se eliminan dinámicamente a medida que se ejecuta el sistema.
Diagrama de objeto: Refleja cada instancia de una clase, las operaciones que se le aplican y los mensajes que se le pasan.
Las líneas que conectan a los objetos y terminan con un recuadro etiquetado indican el tipo de datos que contiene el mensaje.
La flecha paralela a la línea indica el tipo de sincronización entre los objetos (Síncrono, Asíncrono, Retardado).
Para cada objeto se crea una plantilla de objeto que define el objeto y los mensajes que se pasan.
Modularización del diseño
Ya hemos hablado de la importancia de la modularización en el diseño de software. Pero aquí surge una pregunta
¿Cómo se define el concepto de modulo cuando se aplica el DOO?
La respuesta a esta pregunta nos lleva a una notación de diseño que asigna clases y objetos a los componentes físicos de programan (módulos) y por tanto representa una visión de implementación de la arquitectura del programa.
El diagrama de módulos representa un componente de programa (objeto) como una caja dividida en una parte de especificación (visible al exterior) y una parte privada(parte del cuerpo) en esta etapa todavía no se especifican los detalles de implementación de la parte privada o cuerpo del paquete los objetos de datos se representan con un ovalo alargado mientras que las operaciones que actúan sobre ellos se representan mediante rectángulos, las flechas de conexión implican independencia, es decir el paquete o componente en el origen de la flecha depende del paquete o componente de programa en la punta de la flecha. El componente de programa de mayor nivel A, depende de los objetos y las operaciones contenidas en B, C, D necesarios para satisfacer su función.
El Software de un sistema basado en computadora es ejecutado por uno o más procesadores (computadora) que interactúan con otros dispositivos mediante una serie de conexiones definidas.
El uso del diseño y de la implementación orientados a los objetos no altera esa situación. Por ello se usa el diagrama de proceso, para indicar los procesadores (Caja sombreada) los dispositivos (Cajas en blanco) y las conexiones (líneas) que definen la arquitectura del hardware de un sistema.
En el diagrama también se indican los procesos software que se ejecutan en cada procesador.
Una estrategia alternativa de diseño orientado a los objetos
El método de diseño orientado a los objetos esta orientado al desarrollo del software con lenguaje de programación tipo Ada.
El método no se centra explícitamente sobre varios conceptos importantes de la orientación a los objetos esta sección describe un enfoque alternativo para el DOO que ha evolucionado del desarrollo del software con lenguajes de programación tipo Smalltalk a lenguajes que soportan directamente la abstracción, la herencia, los mensajes y todos los demás conceptos del DOO.
El enfoque de DOO es apropiado para el diseño preliminar el objetivo principal es definir y caracterizar las abstracciones de una forma que resulte en una definición de todos los objetos. LORENSE sugiere el siguiente enfoque:
1- Identificar las abstracciones de datos para cada sub-sistema
las abstracciones de datos son las clases del sistema a partir del documento de requisitos, se debe llevar acabo el proceso de abstracción de forma descendente. A menudo las clases corresponden a objetos físicos del sistema que se modeliza.
2- Identificar los atributos de cada abstracción
los atributos son variables de instancia de cada clase muchas veces, cuando las clases corresponden a objetos físicos las variables de instancia requeridas serán obvias.
3- Identificar las operaciones de cada abstracción.
las operaciones son los métodos o procedimientos de cada clase. en este momento no se especifican los detalles de implementación de los métodos, sino solo su funcionabilidad. Si una nueva abstracción hereda de otra clase, hay que inspeccionar los métodos de esa otra clase para ver si alguno es redefinido en la nueva clase.
4- Identificar la comunicación entre objetos
este paso define los mensajes que se envían unos objetos a otros. Aquí se define la correspondencia entre los métodos y los mensajes que invocan a los métodos.
5- Probar el diseño con guiones
los guiones, consistentes en conjuntos de mensajes a objetos prueban la habilidad del diseñador de satisfacer la especificación de requisitos del sistema.
6- Aplicar herencia donde sea apropiado
si el proceso de abstracción de datos del paso 1. se ha realizado de forma descendente, se puede especificar la herencia allí, sin embargo si las abstracciones se han creado de abajo hacia arriba también se aplica la herencia.
Integración del DOO con el análisis estructurado y el diseño estructurado
Actualmente, los investigadores nos se han puesto de acuerdo al respecto de sí es posible la integración de estas dos estrategias de análisis y diseño en un solo método único. Algunos piensan que las dos estrategias son muy diferentes, mientras que otros creen que se pueden utilizar elementos de ambos métodos para desarrollar un modelo completo del problema. Primero, se tratara el área donde ambos métodos tienen alguna similitud y convergencia conceptual, o sea situaciones en las que pueden coexistir pacíficamente ambas técnicas.
Los elementos claves de AE/DE son:
• El modelo de flujo.
• Diccionario de datos.
• La especificación del control.
• La especificación de procesos.
• Un diagrama de entidad-relación ( E- R ), para la modelización de datos.
Aunque el diagrama de flujos de datos pareciera que podría proporcionar una buena conexión entre el AE y el DOO no es así, ya que sus elementos de datos flujos (flechas) y almacenes (líneas dobles) y los procesos (“burbujas”) constituyen un modelo aproximado de los objetos y sus operaciones, respectivamente. Pero no es así.
Recordemos que la orientación a los objetos crea una representación del campo del problema del mundo real y la hace corresponder con el ámbito de la solución que es el software. Por esta razón, las representaciones de AE/DE que reflejan los elementos del mundo real relativos al problema proporcionarían un mejor puente con el AOO/DOO. Las entidades externas (cuadros) que representan a los productores y consumidores del flujo de datos será posible candidato a objetos. Los objetos de datos definidos como parte del diagrama E-R también son candidatos a objetos. Es cierto que los DFDs de menor nivel podrían proporcionar una indicación de los atributos de algunos objetos y que los procesos indicados a esos diagramas podrían ser operaciones aplicadas a los objetos. Pero un DFD no refleja un sistema desde el punto de vista orientado a los objetos.
La especificación de control (CSPEC) proporciona un modelo de comportamiento que puede ayudar al diseñador a comprender mejor el paso de mensajes en el sistema orientado a los objetos. Finalmente, el diagrama de entidad relación puede ayudar a aislar clases y subclases candidatas, así como las relaciones entre ellas.
Ward describe una correspondencia entre el AE/DE para sistema de tiempo real y el diseño orientado a los objetos. Se puede representar una abstracción de datos (una clase) como una transformación incorpórea con sus entradas y sus salidas; no es instanciada incorporándola al modelo de flujo; tal transformación podría construirse teniendo en cuenta la reusabilidad, incluyendo datos y transformaciones adecuadas para muchos ámbitos de aplicación (en los que aparezca la abstracción de datos). Esencialmente, lo que Ward sugiere es que se puede representar una clase o una subclase como una burbuja aparte. Los flujos hacia y desde esa burbuja siguen representando flujo de datos, pero implican operaciones asociadas a la clase. Para instanciar un objeto, se incluye la burbuja independiente en el contexto del modelo de flujo. Por ejemplo, una clase sensor puede estar modelizada como una abstracción de datos (utilizando un diagrama E-R) y representada por una burbuja aparte (incorpórea). Se podría instanciar un objeto de la clase sensor (por ejemplo, sensor de humo) en un modelo de flujo especifico, incluyendo una burbuja sensor de humo en el DFD.
Algunos investigadores piensan que no hay una oposición clara entre el AE/DE y el DOO, mientras que otros (los puristas) creen que los métodos orientados a los objetos y el enfoque de diseño estructurado se incluyen mutuamente (y que el DOO es con mucho superior). Solo el tiempo dirá si los dos valiosos métodos de diseño siguen caminos diferentes o si llegan a un matrimonio duradero.


Resumen
El diseño orientado a los objetos crea un modelo del mundo real que puede ser realizado en software. Los objetos proporcionan un mecanismo para representar el ámbito de información, mientras que las operaciones describen el procesamiento asociado con el ámbito de información. Los mensajes (un mecanismo de interfaz) proporcionan el medio por el que se invocan las operaciones. La característica distintiva de AOO/DOO es que los objetos saben que operaciones se pueden aplicar sobre ellos. Este conocimiento se consigue combinando abstracciones de datos y de procedimientos en un solo componente de programa (denominado objeto o paquete).
AOO/DOO ha evolucionado como resultado de una nueva clase de lenguajes de programación orientados as los objetos, tales como Smalltalk, C++, Objetive-C, CLU, Ada, Modula y otros. Consecuentemente, las representaciones del diseño orientado a los objetos son mas adecuados que otras que dependen del lenguaje de programación.
La Métodología AOO/DOO consiste en tres pasos que requieren que el diseñador establezca el problema, defina una estrategia informal de resolución y formalice la estrategia, identificando los objetos y operaciones, especificando interfaces y proporcionando detalles de implementación para la abstracción de datos y de procedimientos. El papel del DOO es tomar las clases y los objetos básicos definidos en el AOO y refinarlos con los detalles adicionales de diseño.
Los diseños se representan mediante alguna de las notaciones gráficas existentes y el lenguaje de diseño de programas.
El diseño orientado a los objetos representa un enfoque único para los ingenieros de software.

BIBLIOGRAFÍA

Sommerville, Ian
"Ingeniería de Software" 6ª Edición
Addison-Wesley,2002

Bruegge B. y Dutoit A. H.
"Ingeniería de Software Orientado a Objetos"
Prentice Hall 2002

Craig Larman. UML y Patrones, Introducción al Análisis y Diseño Orientado a Objetos. Prentice Hall. Primera versión en Español, 1999
www.tic.udc.es
www.ub.es/stat/recerca/preprints