Ingeniera del software

Desarrollo Orientado a Objetos

TEMA 3 FASES DEL CICLO DE VIDA DE UN SISTEMA Introduccin Enfoque clsico Enfoque estructurado Enfoque Orientado a objeto. Metodologa Yourdon

ENFOQUE ORIENTADO A OBJETO 1.Introduccin

A medida que se acercaban los 80, el paradigma orientado a objetos comienza a madurar como un enfoque de desarrollo software. Se empezaron a hacer diseos de aplicaciones usando la orientacin a objetos, pero se qued atrs el anlisis de requisitos para esas aplicaciones. Actualmente el anlisis orientado a objetos (AOO) se va imponiendo como mtodo de anlisis, pero no existe unanimidad en cuanto a la metodologa a usar. El primer problema que la programacin supone resuelto, es la definicin de objetos y clases. Es labor del AOO y del Diseo Orientado a Objeto (DOO) llevar a cabo esta definicin, para obtener aplicaciones de calidad. As, se puede decir que modelos orientados a objetos para el anlisis permiten al ingeniero de software obtener el modelo de un problema representando clases, objetos, atributos y operaciones como elementos de ese modelo. El desarrollo orientado a objetos no es un mtodo simple. No se basa en la descomposicin funcional, es decir,estudiar el problema de un modo clsico (entradaproceso-salida o por estudio de las estructuras de los datos). Las aplicaciones basadas en los mtodos orientados a objeto se analizan, disean, implementan y prueban en funcin de los objetos que las componen. . 2.Justificacin de Orientacin a Objetos

Como ya hemos comentado, el desarrollo de software utilizando las metodologas tradicionales es caro y hay algunos problemas cuya resolucin es de gran complejidad. El anlisis estructurado se basa en la descomposicin funcional, e introdujo un mtodo prctico para llevar a cabo el anlisis de sistemas. Sin embargo, el AOO es un mtodo que realiza la definicin de las caractersticas y el comportamiento dentro de un sistema de objetos. El proceso de anlisis estructurado consiste en considerar el sistema como un conjunto de reas funcionales que se divide en procesos, stos a su vez se descomponen en procedimientos comprensibles para las personas involucradas en el diseo del

Ingeniera del software

Desarrollo Orientado a Objetos

sistema. El diseo estructurado es directo, en cuanto a la preparacin de la programacin, pero obliga a los programadores a centrarse en las operaciones, prestando poca atencin a la estructura de los datos. Los diseos suelen traducirse en ms cdigo y menos datos porque la organizacin de los datos se deriva de los procesos y sus necesidades de interaccin. Un sistema orientado a objetos no pone el nfasis en las transformaciones de entradas en salidas, sino en el contenido de las entidades, en los objetos. El criterio para agrupar funciones no es el proceso, sino que se trata de agrupar mtodos cuando stos funcionan sobre una misma abstraccin de datos. El paso de mensajes entre objetos es lo que determina secuencia de funcionamiento. De este modo, el desarrollo de sistemas orientados a objeto es fundamentalmente distinto de los mtodos tradicionales, para los cuales el primer criterio de descomposicin del sistema es que cada mdulo en el sistema representa un paso en el conjunto del proyecto. Con las tcnicas orientadas a objetos el criterio es diferente: Cada mdulo en el sistema denota un objeto o clase de objetos del espacio del problema. Abstraccin e informacin escondidas son el fundamento del desarrollo orientado a objeto. Tambin podemos justificar el uso del desarrollo orientado a objetos apoyndonos en que las aplicaciones de hoy, debido a su tamao y complejidad, requieren la utilizacin de nuevos paradigmas. El desarrollo del software utilizando el paradigma O.O. tiene ventajas que otros paradigmas no pueden ofrecer. Por ejemplo, si un proyecto se desarrolla a partir de una biblioteca de objetos (clases de objetos ya diseadas y probadas), saldr ms barato, ya que los costos de desarrollo y mantenimiento son menores. El precursor del anlisis y diseo O.O. es el modelado de informacin (de datos) popularizado por Chen en los aos 80. El modelo inicial (DER) se completa aadiendo a la lista de entidades y atributos, jerarquas de subtipos y objetos asociativos. Aunque este mtodo est relacionado con el AOO, no existe encapsulacin de datos, es decir los requisitos de procesamiento de cada objeto y de sus atributos no se tratan como una entidad. Tampoco permite la herencia ni el paso de mensajes. Actualmente el mtodo de desarrollo orientado a objetos que se est imponiendo como estandar de facto es seguir el llamado proceso unificado que se es un tipo de desarrollo iterativo por incrementos. Los elementos grficos en los que se apoya son los que proporciona UML (Unified Modeling Language). UML tambin se puede utilizar como lenguaje de modelado si se siguen otras metodologas. Cualquier metodologa de desarrollo O.O. pone el nfasis en la reutilizacin, modularidad, y encapsulacin, as como la fuerte relacin entre diseo y cdigo, que forman parte integral de los sistemas orientado a objetos. Independientemente de la estrecha relacin entre diseo y programacin, sigue teniendo importancia la bondad del anlisis y el diseo que se traducir en mejores sistemas. Adems, con una aproximacin orientada a objetos generalmente es posible limitar el alcance de los cambios a aquellos mdulos en el espacio de la solucin que son objetos en el espacio del problema.

Ingeniera del software

Desarrollo Orientado a Objetos

La abstraccin es la labor continua del desarrollador Orientado a Objetos. Los elementos iniciales de un desarrollo orientado a objetos son los propios objetos. Posteriormente, stos se van guardando en clases (en un primer nivel de abstraccin), que a su vez sern sublclases de clases ms abstractas. Un diseo orientado a objetos comienza con un conjunto de definiciones de clases. Cada una tiene un conjunto de mtodos que define, y una lista de objetos a los que sus mtodos pasan mensajes. El diseo queda completo cuando se define cada clase, mtodo y mensaje. El resultado de un diseo orientado a objetos es una jerarqua de clases. Cada clase es un mdulo separado, con sus propias estructuras de control y datos. El nivel de abstraccin ms alto es el que se llama marco estructural o framework que es un conjunto de clases que expresa un diseo para una familia de aplicaciones relacionadas entre s. El proceso de desarrollo de sistemas O.O. suele ser incremental y los ingenieros de software rara vez empiezan partiendo de la nada. Suelen partir y reutilizar bibliotecas de clases preexistentes, adaptando clases especficas a las necesidades del sistema. Una metodologa O.O. debe proporcionar reglas para identificar, definir y organizar las clases, y los mtodos y mensajes que las acompaan. Tambin han de proporcionar estrategias para organizar libreras de clases y directrices para construir aplicaciones para los marcos estructurales (frameworks) o bibliotecas de clases existentes. Adems podemos decir que el Desarrollo O.O. es cclico. Los diseadores empiezan con un conjunto de clases, las amplan, las modifican y las encajan formando un prototipo de una aplicacin. La interaccin con los usuarios finales hace que el prototipo se revise y a continuacin el equipo de desarrollo revisa el trabajo: se reorganizan y redefinen las clases. Si se observa que una clase es lo suficientemente genrica para ser reutilizada en aplicaciones futuras, se aade a la biblioteca de clases estndar. Posteriormente los diseadores de marcos estructurales identifican similitudes entre aplicaciones y desarrollan marcos estructurales de clases que son tiles como soluciones de programacin para problemas futuros similares. De la utilizacin del Desarrollo O.O. se deducen varias ventajas especficas: - Utilizacin de todas las posibilidades de los lenguajes orientado a objetos. - El mtodo produce diseos flexibles al cambio. - Produce diseos ms intuitivos para desarrolladores y usuarios. - La orientacin a objetos mejora el proceso de diseo. 3.Caractersticas generales de las metodologas O.O.

* Su concepcin es de ms alto nivel que la de las metodologas tradicionales. Luego es ms fcil su enfoque, aunque aqu debe hacerse la siguiente salvedad: Si el analista fue educado con los mtodos tradicionales le costar cambiar su forma de pensar, siendo ste uno de los principales inconvenientes para ellos. * Los sistemas suelen empezar a construirse a partir de objetos ya creados. Con lo cual la reutilizacin se pone de manifiesto. Esto conlleva una experiencia del objeto y la garanta de un buen funcionamiento.

Ingeniera del software

Desarrollo Orientado a Objetos

* La complejidad de los objetos que podemos utilizar puede aumentar hasta lmites increbles, ya que unos se construyen a partir de otros. * Metodologa ideal para el desarrollo de herramientas CASE. * La creacin de sistemas con un funcionamiento correcto es ms fcil con las metodologas O.O., ya que cada sistema creado se puede construir, depurar y modificar con relativa facilidad. * Un buen diseo puede asegurar que se logran las mximas ventajas de un lenguaje de programacin orientado a objetos (sobretodo si no se tiene bibliotecas preexistentes). * Un Desarrollo O.O. en general produce menos cdigo y ms reutilizable que el obtenido por descomposicin funcional. * Los sistemas suelen ser ms flexibles a los cambios, ya que fija su atencin en los elementos del sistema que son ms estables (los objetos). * La modularidad del mtodo orientado a objetos beneficia tambin al equipo de desarrollo, ya que, como los datos y los procesos estn localizados en los objetos, es fcil tener varios equipos trabajando independientemente en diferentes partes del diseo. * Es ms intuitivo, no slo para el analista, sino tambin para el usuario final, ya que su enfoque de organizacin y comprensin del problema resulta natural al estar basado en la forma de pensar de los seres humanos. Definiciones y conceptos. Al igual que ocurre en otras reas de la ingeniera del software, el Desarrollo Orientado a Objeto tiene su propio vocabulario y conjunto de conceptos fundamentales. El ingeniero de software debe dominar ambos si se quiere desarrollar un trabajo correctamente. Los conceptos bsicos sobre los que se apoya la metodologa son Objetos, Mensajes y Clases. Objeto: (Firesmith): Abstraccin de software que modela todos los aspectos relevantes de una entidad -tangible o conceptual - o cosa del dominio de aplicacin o espacio de solucin. Los objetos pueden considerarse como paquetes que contienen datos y funciones para trabajar con esos datos. Un objeto es una entidad, que tiene un valor y se caracteriza por las acciones que puede recibir. Estos datos y funciones se denominan atributos y mtodos. La nica manera de acceder a los datos es a travs de los mtodos, encargndose stos de protegerlos de posibles inconsistencias del exterior. Adems de los atributos y mtodos, los objetos a su vez pueden contener otros objetos (objetos compuestos). Clases: Si la metodologa O.O. estuviera compuesta exclusivamente por objetos y mensajes sera una metodologa potente. Sin embargo, tenemos la posibilidad de aumentar esta potencia si aadimos un nuevo concepto, la clase: Plantilla para

Ingeniera del software

Desarrollo Orientado a Objetos

un tipo particular de objetos. Si tenemos muchos objetos del mismo tipo (tienen caractersticas comunes), stos se pueden agrupar en clases. Cuando tenemos una clase de objetos podemos compartir los mtodos y variables comunes a todos ellos, con lo cual aumenta la potencia de la metodologa. Adems, el concepto de clase ayuda comprender mejor el concepto de objeto: Modelo o instancia de una clase. Podemos establecer la jerarqua de clases: Superclases que son clases de las cuales van a especializarse otras clases y subclases (clases que derivan de una superclase). Una de las caractersticas ms importantes de establecer una jerarqua de clases es que podemos emplear en ellas un concepto nuevo, el de herencia: facultad que tienen los objetos y las clases para compartir mtodos y variables de otros objetos y clases. La herencia puede ser simple o mltiple, dependiendo de si la clase u objeto hereda de un/a o varios/as objetos/clases. Mensajes: Los objetos no son entidades independientes, se comunican entre ellos mediante los mensajes. As, un mensaje puede definirse como: Llamada a un objeto (o clase) para que responda a un servicio especfico (Firesmith). Los mensajes confieren proteccin a los objetos, ya que slo a travs de ellos (mensajes) podremos comunicarlos (objetos) accediendo nicamente en la forma en que est emitido el mensaje. Otra ventaja que tienen es que, utilizando los mensajes, no es necesario conocer la estructura interna de los objetos, podemos abstraernos de ella. Podemos definir polimorfismo como: Distintas respuestas que dan los objetos ante un mismo mensaje. Esto tiene la ventaja de no tener que usar un mensaje para cada objeto. 4.Una Aproximacin a las Metodologas O.O.

Un sistema, que implementa un modelo de la realidad puede verse como un conjunto de objetos que interactuan entre ellos. Para disear un sistema orientado a objetos se deben seguir los siguientes pasos (para cualquier metodologa): 1.- Definir el problema y describir la solucin. 2.- Identificar los posibles objetos y clases de objetos. 3.- Identificar los atributos de los mismos. 4.- Identificar los mtodos (operaciones). 5.- Establecer la visibilidad de cada objeto(o clase) con respecto a los otros. 6.- Establecer la interfaz entre objetos. 7.- Implementarlos es el ltimo paso del proceso. (** Desarrollo propuesto por Abbott y que se ajusta tambin a la metodologa de Booch).

Ingeniera del software

Desarrollo Orientado a Objetos

1.- Definir el problema y describir la solucin. En el espacio del problema hay un conjunto de objetos del mundo real, cada uno tiene a su vez un conjunto de operaciones y algunos algoritmos que operan sobre esos objetos y proporcionan como resultado objetos transformados. Adems, el mundo real no es secuencial, sino que las cosas ocurren concurrentemente. Por otra parte si examinamos el lenguaje humano, encontramos que hay dos componentes primarios: frases nominales y frases verbales. Una estructura parecida existe en los lenguajes de programacin que permiten implementar objetos (frases nominales), y operaciones (frases verbales). Sin embargo los lenguajes anteriores eran imperativos, es decir, en general permitan implementar operaciones, pero fallaban cuando se intentaba abstraer a objetos del mundo real. 2.- Identificar objetos y clases de objetos. Si miramos alrededor de una habitacin, veremos varios objetos fcilmente identificables, clasificables y definibles en trminos de atributos y operaciones. Sin embargo, cuando lo que se tiene es la definicin de un problema de desarrollo software es ms complicado identificar los objetos. Podemos decir que los objetos modelizan casi cualquier aspecto identificable dentro del mbito del problema: El desarrollo de un sistema orientado a objetos comienza con la identificacin de los objetos. Esto implica reconocer la mayora de los elementos existentes (actores, agentes, y servidores) en el espacio del problema, as como su papel en el modelo de la realidad. Los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se unen para formar una clase. Toda clase describe un conjunto, de objetos individuales. Se dice que cada objeto es una instancia de su clase, a travs de los valores de los atributos de cada objeto. As pues, la abstraccin de objetos da una clase. Las operaciones son comunes a todos ellos. Se han utilizado varios mtodos para identificar objetos: A) Booch (1983) dio origen al mtodo semntico, que consiste en llevar a cabo el anlisis gramatical de la descripcin del problema y sugiere que el diseador debe empezar por el estudio de la descripcin textual del sistema deseado. Se identifican los objetos (o clases de objetos) posibles seleccionando (subrayando) los nombres. Tambin es interesante recordar que un objeto encapsula datos y procesos. Hay que tener en cuenta que no todos los nombres que aparecen en la descripcin inicial del sistema, se convertirn en objetos. Por otra parte, los verbos identifican los mtodos. La lista resultante de objetos o clases de objetos y mtodos se utilizar para empezar el proceso de diseo. Los objetos pueden ser: Entidades externas - Producen o consumen informacin. Cosas - Forman parte del dominio de informacin del problema (informes, cartas, seales).

Ingeniera del software

Desarrollo Orientado a Objetos

Ocurrencias o sucesos que ocurren en el contexto de operacin del sistema (transferencia de una propiedad). Papeles que utilizan las personas que interactan con el sistema. Unidades organizativas relevantes para la aplicacin (divisin, grupo, equipo). Lugares que establecen el contexto del problema y del funcionamiento general del sistema (sala de facturacin). Estructuras que definen clases de objetos, o clases de objetos relacionadas (sensores, ordenadores, vehculos). Tambin es importante darse cuenta de lo que no son objetos. En general un objeto no debe tener nunca un nombre procedimental imperativo es decir elementos obtenidos a partir de la aplicacin de una operacin a un objeto ( Imagen Invertida no es un objeto, sino el resultado de aplicar al objeto imagen la operacin de invertir). Cuando se ha recorrido el texto correspondiente al enunciado tendremos una lista de objetos potenciales. Para obtener la lista definitiva, debemos repasarla cuidadosamente, estudiando los posibles sinnimos, as como eliminando los que no tengan entidad suficiente. B) Coad y Yourdon sugieren seis caractersticas selectivas que debe usar el ingeniero de software para considerar la inclusin o no de cada objeto potencial en el modelo de anlisis (aunque no especifica cmo llegar a la definicin de los objetos): - Informacin retenida: El objeto potencial ser til durante el anlisis slo si la informacin sobre el mismo tiene que recordarse para que el sistema pueda funcionar. - Servicios necesarios: El objeto potencial debe tener un conjunto de operaciones identificables que puedan cambiar de alguna forma el valor de sus atributos. - Mltiples atributos: En la fase de anlisis, en general, los objeto tiles tiene ms de un atributo (un objeto con uno slo puede ser interesante en la fase de diseo). - Atributos comunes: Se pueden definir conjuntos de atributos para los objetos potenciales y aplicarlos a todas las ocurrencias del objeto. - Operaciones comunes: Se pueden definir conjuntos de operaciones para los objetos potenciales y aplicarlas a todas las ocurrencias del objeto. - Requisitos esenciales: En el anlisis/especificacin casi siempre se definen como objetos las entidades externas asociadas al problema, y que son origen o destino de informacin, necesaria para el funcionamiento del sistema. Para que un objeto potencial pase a ser un objeto definitivo, ha de satisfacer todas (o casi todas) las caractersticas anteriores. La decisin de incluir o no un objeto potencial en la lista definitiva puede ser algo subjetiva; una revisin posterior puede descartar o incluir un determinado objeto. C) Abbott dice que en la descripcin del problema se pueden encontrar varios tipos de frases nominales: - Los nombres comunes definen una clase de entidad. - Los nombres de masas y unidades de medida definen cualidades, actividades, substancias (agua, gasolina).

Ingeniera del software

Desarrollo Orientado a Objetos

- Los nombres propios y nombres de referencia directa describen una instancia especfica (sensor de calor, mi mesa..). D) Actualmente existen algunas herramientas que soportan el desarrollo de sistemas OO. De cualquier modo, el primer paso del AOO debe ser la definicin de los objetos y clases de objetos, debindose tomar las decisiones necesarias (aunque sean subjetivas) sobre la inclusin de los mismos en la lista. Igualmente, hay que tener en cuenta que: 1. La lista anterior no incluye todo. Puede que haya que aadir ms objetos para completar la definicin del modelo. 2. Algunos de los objetos rechazados se pueden convertir en atributos de los objetos aceptados. 3. Diferentes descripciones del problema pueden dar lugar a listas de objetos diferentes. 3.- Especificacin de atributos. Los atributos describen y definen un objeto del modelo de anlisis/especificacin. Para identificar un conjunto de atributos para un objeto, el analista debe estudiar nuevamente la descripcin del problema y seleccionar aquello que pertenezca de forma razonable al objeto. Adems, para cada objeto se debe responder a la siguiente pregunta: Qu elementos de datos (elementales y/o compuestos) definen completamente ese objeto en el contexto del problema?. Shlaer y Mellor (SyM) dan varias reglas ayudan en la identificacin de los atributos de objeto: - Cada objeto debe tener un (solo) valor para cada atributo - Cada atributo debe representar una caracterstica del objeto completo. Estas reglas aseguran que un objeto se pueda expresar (ms adelante) como una sola fila en una tabla, ocupando cada atributo una celda. Para S y M el concepto de objeto viene a ser como un registro de una base de datos. Aunque proporciona al diseador una base de partida, la metodologa no contempla muchos de los conceptos orientado a objetos. Toma notaciones de DFD, DER y diagramas de transicin de estados extrados del anlisis estructurado. (Sin embargo, no hay forma de expresar conceptos como mensaje o mtodo. Esta metodologa tampoco est automatizada y se apoya en la programacin sobre papel). 4.- Identificar las operaciones. Definicin. Las operaciones de procesamiento son parte del objeto y se inician cuando a ese objeto se le pasa un mensaje. Una operacin sobre un objeto, lo modifica de algn modo, cambia valores de uno o ms atributos del mismo. Por tanto, una operacin debe

Ingeniera del software

Desarrollo Orientado a Objetos

tener conocimiento de los atributos del objeto, y deben implementarse de modo que puedan manipular las estructuras de datos a las que dieran lugar los atributos. Existen muchos tipos de operaciones, pero, de modo general, se pueden dividir en operaciones que: 1. Manipulan los datos de alguna forma: aadir, eliminar, seleccionar. 2. Realizan algn clculo. 3. Monitorizan un objeto frente a la ocurrencia de algn suceso de control. Para identificar el conjunto de operaciones (mtodos) que afectan a cada objeto del modelo de anlisis, se vuelve a leer el enunciado del problema, y se seleccionan aquellas operaciones que correspondan razonablemente a cada objeto. Para ello, se vuelve a hacer un anlisis gramatical del texto, y se seleccionan (subrayan) los verbos. Algunos de ellos sern operaciones, y se podrn relacionar con un cierto objeto (mtodo de Booch). Estudios posteriores ms detallados pueden hacer que modifiquemos la lista, aadiendo, quitando, o descomponiendo los verbos de la relacin. Identificar operaciones sirve para caracterizar la conducta de cada objeto o clase de objeto. Aqu se establece la semntica de los objetos determinando las operaciones que pueden ser ejecutadas sobre el objeto o por el objeto. En este momento tambin se establece el comportamiento dinmico de cada objeto identificando las restricciones en tiempo y en espacio que se deben observar. Comunicacin entre objetos. La definicin de los objetos en el contexto del modelo de anlisis puede ser suficiente para establecer una base para el diseo, pero se debe aadir algo ms (durante el anlisis o el diseo) para que se pueda construir un sistema: Se debe establecer un mecanismo de comunicacin entre los objetos: el mensaje. En la figura 1 se muestran 4 objetos A, B, C, y D. Cada uno de ellos tiene definidos unos atributos, as como unas ciertas operaciones. La comunicacin entre ellos, se representa mediante una flecha entre los objetos que se relacionen. Estas conexiones pueden ser del tipo 1:1, conexin simple; o 1:M, conexin compleja. El objeto B requiere un procesamiento asociado con una operacin del objeto D, para lo cual le enva un mensaje. El envo de mensajes es importante para la implementacin de un sistema orientado a objeto, pero no es necesario considerarla de modo detallado durante el anlisis. De hecho, slo interesa usar el concepto como ayuda para determinar la operaciones candidatas para un objeto concreto. 5.- Establecer la visibilidad. Cuando se establece la visibilidad de un objeto con respecto a otro, estamos identificando las dependencias estticas entre objetos y clases de objetos - en otras palabras qu objetos ven y son vistos por otros. El propsito de este paso es capturar la topologa de los objetos desde nuestro modelo de la realidad y determinar la relacin entre ellos.

Ingeniera del software

Desarrollo Orientado a Objetos

B
B_atr-1 B_atr-2

A
A_atr-1 A_atr-2 A_atr-3

B_op1 B_op2

A_op1 A_op2 C
C_atr-1 C_atr-2 C_atr-3

D
D_atr-1 D_atr-2

C_op1

D_op1 D_op2

Figura 1. Comunicacin entre objetos 6.- Establecer el interfaz. La interfaz de un objeto define los lmites entre lo que se ve desde fuera del objeto y lo que se ve desde dentro del mismo. 7.- Implementar cada objeto. El ltimo paso implica elegir una representacin para cada objeto o clase de objetos, e implementarlo. Por otra parte, un objeto puede estar formado por varios objetos subordinados. En este caso, un objeto se implementa sobre los objetos o clases de objetos de niveles ms bajos ya implementados. 7.1.- Definicin y organizacin de clases. Identificados y definidos los objetos, el siguiente paso es reunir las definiciones comunes de objetos en una abstraccin de clase. A continuacin se relacionan las clases entre s, y se forma (si es posible e interesa) una biblioteca de clases. Esta biblioteca de clases se puede perfeccionar en un marco estructural (framework) abstracto til para crear categoras de aplicacin. Por otra parte, es fcil cometer errores como la creacin de clases innecesarias y la declaracin de clases que no lo son. Cada clase slo debe corresponder a una abstraccin de datos significativa. Una clase debe ofrecer una serie de servicios u objetos de un tipo determinado. En fases sucesivas del desarrollo se determina si las clases son necesarias o no. Las bibliotecas de clases predefinidas simplifican mucho el proceso de diseo y ayudan a evitar muchas de las dificultades al determinar lo que se debe identificar como clases y como mtodos. Los diseadores siempre deben buscar primero clases preexistentes, -suministradas por los lenguajes, por los entornos de desarrollo o las

10

Ingeniera del software

Desarrollo Orientado a Objetos

creadas por el propio programador. Por eso siempre se debe dedicar un tiempo a generalizar y a robustecer las clases preexistentes. RESUMEN: Despus de todo lo dicho anteriormente podemos llegar a las siguientes conclusiones: Anlisis/Especificacin: Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se expresa en trminos de objetos y de relaciones. Los pasos que se pueden considerar incluidos en esta fase son: - Descripcin inicial del problema. - Construccin de un modelo de Objetos: . Identificacin de objetos y clases de objetos. . Se identifican los atributos de objetos y clases. . Primera definicin jerrquica de clases.- Herencia. - Construccin del modelo funcional . Identificacin de operaciones.- Mtodos. El modelo se completa mediante la iteracin y revisin de los diferentes pasos. Diseo: Se estudia la estructura de alto nivel del sistema - Estudio de la concurrencia en el sistema - Desarrollo de las operaciones -mtodos- y diseo de los algoritmos para preparar la implementacin. . Si es necesario, redefinicin de clases y operaciones. - Definicin de una estrategia global de implementacin. Al ir avanzando en la metodologa, se baja en niveles de abstraccin. La distincin entre Anlisis y Diseo a veces parece arbitraria y confusa. Las siguientes reglas pueden guiar las decisiones relativas al mbito del anlisis y del diseo: El modelo de Anlisis debera incluir aquella informacin que sea significativa desde el punto de vista del mundo real, y debe presentar el aspecto externo del sistema. El modelo de Anlisis debe ser comprensible al Usuario y debera proporcionar una base til para extraer los verdaderos requisitos del sistema. Estos son los que realmente se necesitan, son congruentes internamente y son realizables. El modelo de Diseo est dirigido a la implementacin. Por tanto debe ser razonablemente eficiente y prctico a la hora de codificar. En la prctica hay muchas partes del modelo de anlisis que son fciles de implementar sin modificaciones, por lo tanto podemos entender que puede haber un fuerte solapamiento entre los modelos de anlisis y diseo. El modelo de diseo debe tratar tambin detalles de bajo nivel que se obvian en el modelo de anlisis. Ambos modelos se combinan para proporcionar una valiosa

11

Ingeniera del software

Desarrollo Orientado a Objetos

documentacin del sistema desde dos puntos de vista distintos, pero complementarios. La implementacin del diseo se convierte en una tarea sencilla: Traducir el diseo a cdigo, puesto que la mayora de las decisiones difciles se han tomado en la fase anterior.

12