diseño orientado a objeto

Ingeniera del Software

Diseo Orientado a Objeto. Una metodologa.

Diseo Orientado a Objetos1.- Yendo hacia el Diseo Orientado a Objeto. Para los analistas, el paso del AOO al Diseo Orientado a Objeto (DOO) se hace de un modo progresivo. Las distintas actividades de la metodologa lo van guiando en el modelado del dominio del problema y el conocimiento de las responsabilidades y requerimiento del Sistema. Durante el diseo, la expansin de las actividades definidas durante el anlisis va a modelar la implementacin. La expansin se hace con componentes aadidos: interaccin humana, tratamiento de tareas y tratamiento de datos. Esta expansin de actividades se contrapone al trabajo que se realiza en las metodologas estructuradas en las que se produce un cambio radical en el paso del Anlisis al Diseo (desde DFD a Mapas de estructura). Los diseadores, toman el modelo del Anlisis y salen al mundo real para hacer el diseo. 2.- Anlisis frente al Diseo. AOO identifica y define clases y objetos que reflejan el dominio del problema y sus requerimientos del Sistema. El DOO identifica y define clases y objetos adicionales, reflejando la implementacin de los requerimientos. El AOO y DOO se deben aplicar de modo secuencial. Adems de ser el modo natural de trabajo, este orden ayuda sobretodo en sistemas grandes en los que puede haber distintos equipos de trabajo, y en dominios de Sistemas grandes en los que el anlisis se puede hacer a un nivel de abstraccin ms alto. Es posible que despus de realizar el AOO y el DOO convenga hacer una segunda revisin de los mismos, sobretodo cuando se est en entornos de prototipacin. Incluso es posible que no est bien definida la lnea que separa ambas fases. El DOO, como el AOO consta de 5 niveles: El nivel de rea, de clase y objeto, de estructura, de atributo y de proceso que se apoyen en las 5 actividades del AOO. 3.- Una continuidad de representacin. Del AOO al DOO al IOO al TOO. La Orientacin a objeto usa las construcciones definidas a partir del dominio del problema para proporcionar una continuidad de representacin desde el AOO hacia el DOO, de aqu a la Implementacin O.O. (IOO) y de sta al Testeo (prueba) O.O. (TOO). El AOO est dirigida sobre el dominio del problema, sus responsabilidades y requerimientos y es independiente del lenguaje de programacin. El DOO preliminar tambin es independiente del lenguaje. Sin embargo, el DOO detallado s es dependiente del lenguaje y se puede aplicar a lenguajes de programacin procedurales, a los orientados a paquetes y a los orientados a objeto. El desarrollador, cuando se enfrenta al desarrollo de un sistema mediante la orientacin a objeto, debe:

1



-- Como analista seguir los criterios del AOO: a) Principios bsicos de: abstraccin (de datos y procedural), encapsulacin, heredabilidad, asociacin, comunicacin por mensajes, organizacin por los mtodos de objetos y atributos, generalizacin- Especializacin y todo parte. b) Las estrategias del modelo para establecer los niveles de rea, de clase y objeto, de estructura, de atributo y de proceso. Todo esto le permite hacer un modelo del sistema, sin presuponer nada acerca de cmo ser el diseo o la implementacin. --Como diseador: Si recibe las especificaciones del modelo en un modo no orientado a objeto, debe desarrollar un modelo AOO a travs de los requerimientos del problema y las especificaciones de los procesos. A continuacin aplicara el DOO preliminar y luego el DOO detallado estableciendo el lenguaje de programacin que se va a usar. -- Como implementador: Aplicar el diseo detallado, centrndose en las clases definidas durante el desarrollo del proyecto y estudiando la posible reusabilidad de otras ya existentes. La eleccin del lenguaje afecta a la estrategia y el enfoque del DOO. Si la implementacin se va a hacer en un lenguaje procedural u orientado a paquetes(Ada) no afecta al AOO o al DOO. Mientras que el Analista de sistemas est muy relacionado con el mundo del usuario, el problema (dominio de la aplicacin) y las responsabilidades y requerimientos del sistema, el diseador est relacionado con trabajo relativo al resultado del anlisis (esto es la especificacin) para una implementacin y un hardware particular. 4.- Modelo Multi-nivel, multi-componente. Metod. De Coad-Yourdon El AOO se divide en 5 actividades principales (bsqueda de clases y objetos, identificar estructuras, identificar reas, definir atributos, y definir procesos) que si bien normalmente se realizarn de modo secuencial, frecuentemente los analistas no las realizan en este orden. Esto es as especialmente cuando se trata de sistemas grandes en los que conviene que el analista no tenga una visin completa del sistema sino de una parte de l. En estos casos, antes de comenzar la bsqueda de clases y objetos conviene realizarla divisin del dominio del problema en subproblemas y definir primero las reas. Segn esto, podemos hablar del desarrollo del AOO en 5 niveles: Nivel de rea, nivel de clase y objeto, nivel de estructura, nivel de atributo y nivel de proceso. El modelo multi-nivel, multi-componente consta de los cinco niveles extendindolos a 4 componentes: Componente de interaccin humana, del dominio del problema, de gestin de tareas y de gestin de datos.

2



Nivel rea N. Cl. y O. N. estructura N. atributo N. proceso

Componente interaccin humana

Componente Dominio del problema

Componente Gestin de tareas

Componente Gestin de datos

El componente de interaccin humana incluye las salidas y las entradas al sistema que constituyen el Interface de Usuario. Un ejemplo de clases de este componente son la clase ventana, panel, botn, etc. Los resultados del AOO corresponden al componente del dominio del problema. En l es en donde estn las clases y objetos, las estructuras, los atributos y los procesos, y es posible que sea necesario combinar o dividir estos elementos durante el diseo. El componente gestin de tareas incluye la definicin, comunicacin y coordinacin de tareas en tiempo real. El componente de gestin de datos incluye el acceso y tratamiento de datos persistentes. Esto asla lo relativo a la gestin de datos- fichero bases de datos relacionales, o bases de datos Orientadas a Objeto. 4.1.- Diseo del componente del dominio del problema. Los resultados del AOO son una parte fundamental del modelo multicomponente del DOO. Estos resultados pueden cambiarse, aumentarse y detallarse ms. Los aadidos que se hagan suponen los cambios que son necesarios para resolver consideraciones del diseo. Esto puede requerir una combinacin o divisin software clases y objetos, estructuras, atributos o procesos, pero slo se harn si se basan en criterios objetivos. Durante el DOO y la POO interesa mantener los elementos definidos en el AOO para mantener la estabilidad del desarrollo, que por otra parte es esencial en la reusabilidad del Anlisis, el Diseo y la Programacin, para el conjunto de Sistemas de una familia con un dominio del problema similar. Cualquier modificacin de los resultados del Anlisis en el Dominio del Problema, si son necesarios, deben estar justificados. Pasos en el Diseo del Componente del Dominio del Problema. 1.- Aplicar el AOO. 2.- Usar los resultados de AOO, mejorndolos en el DOO 3.- Usar los resultados del AOO y aadirlos durante el DOO. 1.- Aplicar el AOO. Tanto AOO como DOO utilizan la misma notacin. AOO aplicado a 5 actividades, y el DOO aplicado a 4 componentes. Para hacer un desarrollo Orientado a Objeto, se puede aplicar cualquiera de los mtodos conocidos: En cascada (con poca retroalimentacin entre las fases), en espiral (en la que se define un prototipo que se va mejorando en sucesivas revisiones, o con el procedimiento incremental (en el que se va progresando en el desarrollo poco a poco en AOO, DOO y POO a medida que se lleva a cabo el estudio del problema). 2.- Usar los resultados de AOO, mejorndolos en el DOO.3



Se llevan los resultados del AOO al DOO directamente. A veces se dan modificaciones a las especificaciones de requerimientos definidas durante el Anlisis, porque cambian los requerimientos por causas ajenas, o bien porque ha habido algn problema de comprensin de los requerimientos por parte del Analista. 3.- Usar los resultados del AOO y aadirlos durante el DOO. Para ello: - Reutilizar clases ya diseadas y programadas con anterioridad. . Aadir las clases propias del componente del dominio del problema. . Identificar atributos y procesos de las clases reutilizadas que no sean necesarias para el problema en estudio. . Aadir una jerarqua de Gen-Espec de la clase encontrada a las clases del dominio del problema. - Aadir una clase raz para mantener juntas en una biblioteca de clases, las clases especificas del dominio del problema. - Establecer un protocolo aadiendo una clase generalizacin. - Adecuar el nivel de herencia soportado por el lenguaje de programacin que se vaya a utilizar. Es deseable utilizar lenguajes de programacin que soporten herencia ya que proporcionan una sintaxis para capturar la semntica de GenEspec y proporcionan la sintaxis para la reusabilidad mediante la especializacin y la extensin. Si se utilizan LP que no soporten herencia, habr que hacer las modificaciones necesarias en la definicin inicial de la jerarqua de clases. - El componente de dominio del problema debe soportar tambin el componente de gestin de datos, ya que cada objeto necesita conocer cmo almacenarse. Para ello, cada objeto se almacena a s mismo, o cada objeto se enva a s mismo al componente de control de datos quien lo almacena. - Revisar las modificaciones realizadas a los resultados del AOO. 4.2.- Diseo del componente de interaccin Humana. La interaccin humana necesita un estudio detallado durante el anlisis y diseo: - En Anlisis se hace cuando se especifican los atributos y el contenido de los procesos. El prototipado se usa para ayudar la especificacin de los requerimientos. - En diseo el componente de interaccin humana aade detalles de la interaccin. El prototipo se usa para ayudar en el desarrollo y la seleccin de los mecanismos de interaccin. A veces ayuda, e incluso es esencial hacer una parte del desarrollo de este componente en paralelo con el AOO. El uso del modelo multi-nivel, multi-componente ayuda a separar el componente de interaccin humana en su parte dependiente de la implementacin del AOO. En este apartado es fundamental aplicar la estrategia sistemtica del prototipado. El componente de interaccin humana considera cmo el hombre va a manejar el sistema y como ste presentar la informacin al usuario. Las decisiones de diseo afectan a la gente que puede verse afectada por ellos. Durante el Anlisis se deben tener en cuenta las caractersticas de los usuarios finales, y durante el diseo continuar con este estudio. La estrategia para disear este componente consiste en lo siguiente:4



1. 2. 3. 4. 5. 6. 7.

- Clasificar a las personas. - Describir a las personas y sus respectivas tareas. - Disear una jerarqua de comandos. - Disear la interaccin de modo detallado. - Continuar con el prototipo. - Disear las clases para el componente. - Disear el interface de Usuario (interface grfico).

La secuencia de estas actividades refleja un conjunto de prioridades en el diseo de la interccin humana: el hombre, las tareas, las herramientas. Los factores humanos es una disciplina en s misma, necesitndose un estudio cuidadoso. 1.- Clasificar a las personas: Se estudiarn las personas a las que va dirigido el sistema. Sus caractersticas personales, su predisposicin, las tareas que realizan. De este modo se clasifican en diferentes categoras: Si se define en este componente una estructura de Gen-Espec Persona, se usa el modelo Gen-Espec como punto de partida, y se van considerando subconjuntos de personas que interactuarn con el Sistema. Se pueden tener distintas clasificaciones jerrquicas atendiendo a distintos conceptos: Clasificacin por nivel de antigedad, por nivel de pertenencia a la organizacin, por nivel de pertenencia a diferentes grupos, ... 2.- Describir a las personas y sus respectivas tareas: Para cada una de las categoras definidas en el paso anterior, considerar y tabular lo siguiente: Quien es, Caractersticas (edad, nivel educativo, limitaciones...), factores crticos (necesidades, deseos, gustos), categora, tareas. 3.- Disear una jerarqua de comandos. En este apartado se disea la jerarqua de comandos, incluyendo: .- Estudio de las caractersticas del sistema de interaccin humana existente actualmente. .- Establecimiento de una jerarqua inicial de comandos. Mediante una barra de men, mens de pantalla, iconos.... .- Redefinicin de la jerarqua. Ordenarla del modo que ms fcil de usar por parte del usuario: las tareas ms frecuente, se ponen antes; las secuenciales se ponen en orden; no se deben poner demasiados tems asociados, ni muchos mens anidados. 4- Disear la interaccin humana de modo detallado. Se debe realizar atendiendo a los siguientes criterios: - Consistencia : en los nombres utilizados, en los pasos a dar, en las acciones a realizar. - Pocos Pasos: Reducir el nmero de teclas, o pulsaciones a dar para realizar una operacin (teclas de acceso rpido)... - No debe haber tiempos muertos, es decir que el usuario debe saber lo que est haciendo el sistema, no sentirse abandonado por l. - Debe haber operaciones de deshacer para dar la oportunidad al usuario a corregir los errores que pueda cometer. - No se debe obligar al usuario a recordar gran cantidad de cosas sobre la aplicacin o sobre el contenido de una pantalla en particular.

5



- El tiempo y esfuerzo de aprender de debe ser pequeo. Adems debe proporcionarse documentacin sobre el uso del sistema y ayudas on-line. - El entorno debe ser amigable. 5.- Continuar con el prototipo. El prototipado empieza en el Anlisis y continua durante el Diseo. Definir un prototipo de la interaccin hombre mquina es esencial para el diseo del componente de interaccin humana. Incluso, con herramientas de prototipado automtico se pueden generar varias interfaces, y hacer que el usuario trabaje con ellas para elegir la ms adecuada, o de modo iterativo ir mejorndola hasta que llegue a ser lo ms efectiva posible. 6- Disear las clases para el componente de interaccin humana. Las clases a definir variarn segn el tipo de interface (grfico) que se vaya a utilizar. El diseo empieza mediante la organizacin de la interaccin humana en ventanas y componentes. Por ejemplo: Clase Ventana de la que forman parte las clases men, campo, grfico, botn, selector, ... 7- Disear el interface de Usuario (interface grfico). Aplicar las caractersticas del interface desarrollado en los puntos anteriores al GUI que se considere ms adecuado a la aplicacin en estudio, considerando las caractersticas generales de stos (tipos de caracteres, eventos -directos o encolados-, caractersticas de presentacin,...). 4.3.- Diseando el componente de control de tareas. Una tarea se define como un proceso o una actividad. La ejecucin concurrente de varias tareas se conoce como Multitarea. Hay sistemas que requieren la ejecucin de mltiples tareas. Por ejemplo: - Sistemas de adquisicin de datos y de control de varios recursos. - Ciertos interfaces humanos como, por ejemplo para mltiples ventanas. - Sistemas multiusuario en los que se pueden necesitar varias copias de la tarea de un usuario. - Para arquitecturas software multisistema, las tareas se pueden usar para coordinar y comunicar los distintos elementos. - Para mltiples tareas en un nico procesador, las tareas pueden ser necesarias para coordinar y comunicar con otras tareas durante su ejecucin. En este caso la ejecucin de todas ellas se hace por divisin del tiempo de ejecucin en rodajas de tiempo por parte de SO. - En arquitecturas hardware multiprocesador, cada procesador necesita distintas tareas, ms las tareas necesarias para soportar la comunicacin entre procesadores. - Para comunicacin con otros sistemas. Las tareas aaden complejidad al diseo y la codificacin. As cada una debe ser cuidadosamente seleccionada. Tareas distintas separan comportamientos que deben ser concurrentes. La concurrencia se debe implementar en procesadores separados o ser simulados en un nico procesador usado en conjuncin con un SO multitarea.

6



Una posibilidad es considerar un programa secuencial de ejecucin cclica que ejecuta una parte pequea y rpida de programa; despus de cada parte chequea para ver qu ha ocurrido mientras estaba ocupado, y entonces responde adecuadamente... Estrategias de seleccin de tareas en el componente de control de tareas. Son: 1.- Identificar tareas dirigidas por eventos. 2.- Identificar tareas dirigidas por reloj 3.- Identificar tareas prioritarias y crticas 4.- Identificar un coordinador 5.- Definir cada tarea. El objetivo de esta estrategia es identificar y disear las tareas ms los procesos incluidos en cada una. 1.- Identificar tareas dirigidas por eventos. Algunas tareas estn dirigidas por eventos. En este caso se pueden disear para que salten a partir de un evento, como puede ser la llegada de algunos datos. El modo de trabajar una tarea de este tipo es que la tarea est durmiendo (no consume tiempo de proceso), esperando por una interrupcin desde una lnea de datos. Cuando recibe la interrupcin, la tarea despierta, toma los datos, los pone en un buffer, notifica esto a quien necesite conocer los datos y vuelve al estado de dormida. 2.- Identificar tareas dirigidas por reloj. Estas tareas saltan para hacer algn proceso en un intervalo de tiempo determinado. El modo de trabajar este tipo de tareas es: la tarea pone un despertador y se queda durmiendo (no consume tiempo de procesador) esperando por una interrupcin del sistema. Cuando la recibe, se despierta, hace su trabajo, lo notifica a quien necesite saberlo y vuelve a dormir. 3.- Identificar tareas prioritarias y crticas. Las tareas prioritarias estn definidas en niveles de prioridad. Una tarea crtica (de alta prioridad) se usa para aislar procesos especialmente crticos para el sistema. 4.- Identificar un coordinador. Cuando se tiene 3 o ms tareas, hay que considerar otra tarea ms que acte como coordinador. 5.- Definir cada tarea. El nmero de tareas definidas debe ser el mnimo posible. Para definirlas: - Especificar el nombre, y hacer breve descripcin de ella. - Aadir el nuevo nombre a cada proceso de los componentes del diseo. - En cuanto a la coordinacin de tareas, hay que distinguir entre las dirigidas por eventos y las dirigidas por reloj. Para las dirigidas por eventos, describir los eventos que la hacen saltar. Para las dirigidas por reloj, describir el intervalo de tiempo que ha de pasar antes de que la tarea salte.- Por otra parte hay que definir cmo comunicar las tareas, por ejemplo de donde obtiene los valores de los datos de entrada - una lnea de entrada un semforo, un buffer o un rendezvous- y a donde los enviar.

7



Tarea Coordinador

Coordinador

Tarea Nombre Descripcin Prioridad Procesos Incluidos Coordinado por Comunicacin va. Inicializar Empezar En espera T i d

4.4.- Diseo del componente del control de datos. Este componente proporciona la infraestructura necesaria para el almacenamiento y recuperacin de objetos desde un sistema de gestin de datos. Asla el impacto del esquema de gestin de datos, tanto si son ficheros como bases de datos relacionales u Orientadas a Objeto. El diseo del componente de control de datos necesita incluir el diseo del plan de datos y el diseo de los procesos correspondientes. El diseo del plan de datos depende del tipo de estructura de datos del sistema. - Si son ficheros, definir cada uno como una tabla en 1 forma normal. - Si se trata de una base de datos relacional, definir las tablas en 3 FN. - Si son BDOO: para SQL relacionales, aplicar lo anterior. para LPOO habr que dar un tratamiento ms complejo. El diseo de los procesos asociados: - Aadir un atributo y un proceso a cada clase y objeto con objetos que se vayan a almacenar. - Definir adecuadamente cada uno de estos atributos y procesos. De este modo se consigue que cada objeto conozca como se almacena. Estos atributos y procesos son un puente entre el componente de dominio del problema y el componente del controlador de datos.

5.- Aplicando DOO a LPOO. La programacin orientada a objeto es el mejor soporte para las construcciones de AOO y DOO. Siendo los mejores los que tienen asociado un poderoso entorno de desarrollo y bibliotecas de clases.

8



Hay lenguajes no Orientado a Objeto que se pueden utilizar efectivamente para la implementacin de los resultados del AOO y DOO. Desde una perspectiva del LPOO, la sintaxis de estos lenguajes es muy significativa tanto en cuanto: - Deben mantener una uniformidad de representacin con relacin a la del AOO y el DOO. - La reusabilidad implica grandes ventajas, no slo a nivel de programacin, sino tambin a la hora de reusar resultados ya obtenidos en Anlisis y Diseos previos. - La mantenibilidad se asegura teniendo adecuadamente documentados los programas (herramientas de generacin automtica de documentacin). 6.- Criterios que mejoran el diseo. ACOPLAMIENTO: En DOO describe la interconexin entre las componentes de DOO. En DOO buscamos conexiones entre objetos y entre Clases. En un caso ideal, el estudio y comprensin de un componente - clase, objeto- debera tener una probabilidad mnima de necesitar el estudio de otro componentes. El grado de acoplamiento entre dos componentes es la medida de la cantidad y complejidad de la informacin transmitida entre esos componentes. En DOO hay dos situaciones anlogas: El acoplamiento entre objetos expresada por una conexin de mensaje, y el acoplamiento entre clases de generalizacin y especializacin. - Acoplamiento de interaccin. Es el ms deseable. Se consigue cuando la complejidad de una conexin de mensaje se hace lo ms baja posible. No debe envolver ms de tres parmetros. Tambin se debera de minimizar el nmero de mensajes que se enven y reciban. - Acoplamiento en la herencia. Es deseable un alto acoplamiento en la herencia. La herencia es una forma de acoplamiento clases de generalizacin y especializacin: Una clase se acopla con su generalizacin en trminos de atributos y procesos heredados. Para conseguir un alto acoplamiento en la herencia, cada clase especializacin debera ser una especializacin de su clase generalizacin. Es decir una clase especializacin debera heredar y utilizar muchos atributos y procesos de su clase generalizacin. COHESION. Describe el grado de interrelaciones entre un grupo de elementos del DOO. Es decir el grado en el que los elementos de una parte del diseo contribuye a llevar a cabo un nico y bien definido propsito. - Cohesin de procesos. Se da si un proceso lleva a cabo una y solo una funcin. - Cohesin de clases. Atributos y procesos deben ser cohesivos (que no sobren). - Cohesin de Gen-Espec. Se refiere a la definicin e interrelacin de las estructuras de Gen-Espec. Estas deben ser correctas y las necesarias para el diseo del sistema. REUSABILIDAD. Es otra de las caractersticas que debe cumplir el DOO ya que:9



- Aumenta la productividad al aumentar la reutilizacin de desarrollos anteriores. - Aumenta la calidad ya que los componentes reutilizados han sido probados con anterioridad. Niveles: - Reusabilidad del cdigo. Es el nivel ms bajo. Puede implicar slo reusar cdigo, o cdigo + herencia, o invocaciones en tiempo de ejecucin. - Reusabilidad de los resultados del diseo. - Reusabilidad de los resultados del anlisis. Es el nivel ms alto. Se reutilizan las especificaciones

10

diseño orientado a objeto

Documents