INSTITUTO COMERCIAL SUPERIOR DE LA NACION INCOS - EL ALTO CARRERA: MATERIA: DOCENTE: ANALISIS DE SISTEMAS INFORMATICOS INGENIERIA DE SOFTWARE LIC.

MARISOL MENDEZ C.

TALLER DE LECTURA #3
CAPITULO 3 INGENIERIA DEL SOFTWARE ORIENTADA A OBJETOS CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS CONTENIDO: 3.1 Paradigma Orientado a Objetos 3.2 Conceptos de Orientacin a Objetos 3.2.1 Clases y Objetos 3.2.2 Atributos 3.2.3 Operaciones, Mtodos y Servicios 3.2.4 Mensajes 3.2.5 Encapsulamiento, Herencia y Polimorfismo 3.3 Identificacin de los elementos de un Modelo de Objetos 3.3.1 Identificacin de Clases y Objetos 3.3.2 Especificacin de Atributos 3.3.3 Definicin de Operaciones 3.3.4 Fin de la Definicin del Objeto 3.4 Gestin de proyectos de Software Orientado a Objetos 3.4.1 Marco de proceso comn para OO 3.4.2 Mtricas y Estimacin en Proyectos Orientados a Objetos 3.4.3 Un enfoque OO para estimaciones y planificaciones 3.4.4 Seguimiento del Progreso OO Introduccin Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas por el hombre, en los negocios y en los productos que usamos. Pueden ser clasificados, descritos, organizados, combinados, manipulados y creados. Por esto no es sorprendente que se proponga una visin orientada a objetos para la creacin de software de computadora, una abstraccin que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los aos sesenta. Sin embargo, las tecnologas de objetos han necesitado casi veinte aos para llegar a ser ampliamente usadas. Durante los aos 90, la ingeniera del software orientada a objetos se convirti en el paradigma de eleccin para muchos productores de software y para un creciente nmero de sistemas de informacin y profesionales de la ingeniera. A medida que pasa el tiempo, las tecnologas de objetos estn sustituyendo a los enfoques clsicos de desarrollo de software. Una pregunta importante es: Por qu? La respuesta (como muchas otras respuestas a interrogantes sobre ingeniera del software) no es sencilla. Algunas personas argumentaran que los profesionales del software sencillamente aoraban un nuevo enfoque, pero esta visin es muy simplista. Las tecnologas de objeto llevan un nmero de beneficios inherentes que proporcionan ventajas a los niveles de direccin y tcnico.

Hay muchas formas de enfocar un problema utilizando una solucin basada en el software. Un enfoque muy utilizado es la visin orientada a objetos. El dominio del problema se caracteriza mediante un conjunto de objetos con atributos y comportamientos especficos. Los objetos con manipulados mediante una coleccin de funciones (llamadas mtodos, operaciones o servicios) y se comunican entre ellos mediante un protocolo de mensajes. Los objetos se clasifican mediante clases y subclases. La definicin de objetos implica la descripcin de atributos, comportamientos, operaciones y mensajes. Esta actividad la realiza un ingeniero del software. Un objeto encapsula tanto datos como los procesos que se aplican a esos datos. Esta importante caracterstica permite construir clases de objetos e inherentemente construir bibliotecas de objetos y clases reutilizables. El paradigma de orientacin a objetos es atractivo para tantas organizaciones de desarrollo de software debido a que la reutilizacin es un atributo importantsimo en la ingeniera del software. Adems, los componentes de software derivados mediante el paradigma de objetos muestran caractersticas (como la independencia funcional, la ocultacin de informacin, etc.) asociadas con el software de alta calidad. La ingeniera del software orientado a objetos sigue los mismos pasos que el convencional. El anlisis identifica las clases y objetos relevantes en el dominio del problema, el diseo proporciona detalles sobre la arquitectura, las interfaces y los componentes, la implementacin (utilizando un lenguaje orientado a objetos) transforma el diseo en cdigo, y las pruebas chequean tanto la arquitectura como las interfaces y los componentes. Se produce un conjunto de modelos orientados a objetos. Estos modelos describen los requisitos, el diseo, el cdigo y los procesos de pruebas para un sistema o producto. En cada etapa se revisa la claridad de los productos de trabajo orientados a objetos, su correccin, complexin y consistencia con los requisitos del cliente Las tecnologas de objetos llevan a reutilizar, y la reutilizacin (de componente de software) lleva a un desarrollo de software ms rpido y a programas de mejor calidad. El software orientado a objetos es ms fcil de mantener debido a que su estructura es inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios y provoca menos frustracin en el ingeniero del software y en el cliente. Adems, los sistemas orientados a objetos son ms fciles de adaptar y ms fcilmente escalables (por ejemplo: pueden crearse grandes sistemas ensamblando subsistemas reutilizables). 3.1 Paradigma Orientado a Objetos Durante muchos aos el trmino orientado a objetos (OO) se us para referirse a un enfoque de desarrollo de software que usaba uno de los lenguajes orientados a objetos (Ada 95, C++, Eiffel, Smalltalk, etc.). Hoy en da el paradigma OO encierra una completa visin de la ingeniera del software. Edward Berard hace notar esto cuando declara: Los beneficios de la tecnologa orientada a objetos se fortalecen si se usa antes y durante el proceso de ingeniera del software. Esta tecnologa orientada a objetos considerada debe hacer sentir su impacto en todo el proceso de ingeniera del software. Un simple uso de programacin orientada a objetos (POO) no brindar los mejores resultados. Los ingenieros del software y sus directores deben considerar tales elementos: el anlisis de requisitos orientado a objetos (AROO), el diseo orientado a objetos (DOO), el anlisis del dominio orientado a objetos (ADOO), sistemas de gestin de bases de datos orientadas a objetos (SGBDOO) y la ingeniera del software orientada a objetos asistida por computadora (ISOOAC) El lector familiarizado con el enfoque convencional de ingeniera del software puede reaccionar ante esta declaracin con esta pregunta: Cul es la gran ventaja? Usamos el anlisis, diseo, la programacin, las pruebas y otras tecnologas relacionadas cuando realizamos ingeniera del software segn mtodos clsicos.
2

Por qu debe ser la OO diferente? Ciertamente, por qu debe ser la OO diferente? En pocas palabras, no debiera! En el enfoque convencional, se examina un nmero de modelos de procesos diferentes para la ingeniera del software. Aunque ninguno de estos modelos pudo ser adaptado para su uso con OO, la mejor seleccin reconocera que los sistemas OO tienden a evolucionar con el tiempo. Por esto, un modelo evolutivo de proceso acoplado con un enfoque que fomenta el ensamblaje (reutilizacin) de componentes es el mejor paradigma para ingeniera del software OO. En la Figura el modelo de proceso de ensamblaje de componentes en el enfoque convencional ha sido adaptado a la ingeniera del software OO. Fig: El Modelo de Proceso OO OO El proceso OO se mueve a travs de una espiral evolutiva que comienza con la comunicacin con el usuario. Es aqu donde se define el dominio del problema y se identifican las clases bsicas del problema. La planificacin y el anlisis de riesgos establecen una base para el plan del proyecto OO. El trabajo tcnico asociado con la ingeniera del software OO sigue el camino iterativo mostrado en la caja sombreada. La ingeniera del software OO hace hincapi en la reutilizacin. Por lo tanto, las clases se buscan en una biblioteca (de clases OO existentes) antes de construirse. Cuando una clase no puede encontrarse en la biblioteca, el desarrollador de software aplica anlisis orientado a objetos (AOO), diseo orientado a objetos (DOO), programacin orientada a objetos (POO) y pruebas orientadas a objetos (PROO) para crear la clase y los objetos derivados de la clase. La nueva clase se pone en la biblioteca de tal manera que pueda ser reutilizada en el futuro. La visin orientada a objetos demanda un enfoque evolutivo de la ingeniera del software. A veces es extremadamente difcil definir las clases necesarias para un gran sistema o producto en una sola iteracin. A medida que el anlisis OO y los modelos de diseo evolucionan, se hace patente la necesidad de clases adicionales. Es por esta razn por lo que el paradigma arriba descrito funciona mejor para la OO.