COMPONENTES REUTILIZABLES EN UN PROYECTO DE SOFTWARE

El objetivo de la ISBC (Ingeniera de Software Basada en Componentes) es aumentar la productividad de otros software que ya estn elaborados, esto se hace reutilizando componentes estndares, pero primero que nada un componente es una parte modular que encapsula su contenido y es por eso que reutilizarlo es fcil ya que no es necesario reprogramarlo completamente, el componente est compuesto de su interfaz y su implementacin por separado por lo que solo se cambiara en su implementacin l como hace las cosas no el servicio que provee ya originalmente y tampoco cambiara la resto de la aplicacin. Cuando vamos a reutilizar un componente hay dos clasificaciones una que divide en subcategorias las categoras de cada componente y el de facetas que nos describe de manera profunda cada componente, por otra parte los elementos de los componentes nos dicen el estado de stos como su servicio y tambin nos dice que el componente puede soportar varias implementaciones, cuando tenemos los componentes a utilizar ahora buscamos programas donde ejecutarlos como puede ser Microsoft COM+, Sun Java Beans, Enterprise Java Beans etc. Ahora los paquetes son componentes agrupados que dan un servicio, para esto tambin debemos tener en cuenta que los componentes estn formados por objetos que tiene acceso a su implementacin pero no debemos dejar accesible la implementacin de nuestro componente a objetos de afuera de est, para utilizar los componentes podemos usar CORBA que es actualmente la arquitectura estndar para objetos y compatible con varias plataformas. Por otro lado Java Beans es una arquitectura neutral, tambin opera en cualquier sistema operativo y permite la reutilizacin de componentes los cuales soportan contenedores de diferentes

exploradores, se basa en los APIs cual objetivo es poder definir un modelo de componentes pequeos o medianos que permitan una mejor accesibilidad, que sean portables con gran calidad y lo ms simple posibles, adems de que los componentes pueden soportar la introspeccin, ser modificados, la comunicacin mediante eventos. Ahora Java 2 Platform Enterprise Edition (J2EE) facilita y simplifica el desarrollo de programacin en mltiples capas adems incluye polticas y APIs como Java Servlets y Java Message Service (JMS), tambin es compatible con las plataformas estndares. Por otra pare se encuentra Microsoft.NET que conecta personas, sistemas y dispositivos, permite construir aplicaciones web, inteligentes, servicios web XML, los desarrolladores de componentes puede utilizar herramientas como Microsoft Visual Studio.NET el cual provee un ambiente integrado y rpido para programar, tambin puede utilizar servidores como Microsoft Windows, SQL Server, BizTalk Server que integran corren y manejan aplicaciones y servicios web. En conjunto permite al desarrollador construir y correr aplicaciones basadas en web, reduciendo el tiempo de codificacin ya que partes de la programacin las realiza automticamente, tambin permite el desarrollo, bsqueda y manipulacin de datos XML. Ahora hablaremos de las interfaces son la parte visible de los componentes y no afectan la implementacin de los mismos. Las interfaces definidas tienen dos propiedades funcionales unas que son la firma que describen las operaciones del componente y las y el comportamiento que describe el comportamiento del componente. Se pueden describir dos tipos de interfaces las exportadas o las importadas las interfaces exportadas describen los servicios que ofrece un componente en un ambiente mientras que las interfaces importadas especifican los servicios requeridos por un componente en el ambiente. El nico problema de las interfaces es que no se actualicen y haya incompatibilidad de versiones, por lo que

algunas veces en cuanto sale una interfaz se congela su implementacin y no se vuelven a modificar. Los contratos listan las restricciones globales que mantendr un componente, lista las restricciones que el cliente necesita conocer (la precondicin) y las que el componente promete establecer (la pos condicin) que en conjunto forman la especificacin del componente, tambin especifica las interacciones entre componentes en trminos de el conjunto de componentes que participan, el papel que desempea cada componente as como sus requerimientos, la especificacin de los mtodos que instancia el contrato. Todo componente requiere de los servicios de otros componentes, y en conjunto trabajan para proveer un objetivo especfico. Los patrones capturan soluciones no obvias y describen relaciones entre las estructuras ms profundas de un sistema y los mecanismos y no solo entre mdulos independientes. Ahora un patrn de diseo puede ser empleado en el diseo y documentacin de un componente describe los detalles de la implementacin, pueden ser clasificados en 3 categoras dependiendo de su nivel de abstraccin: los patrones de arquitectura capturan toda la estructura y organizacin de un sistema, describen los subsistemas participantes y especifica los papeles y relaciones que hay entre ellos, otros son los patrones de diseo stos refinan la estructura y el comportamiento de los subsistemas y la comunicacin entre ellos. Pero en conclusin los patrones sirven para identificar y describir los componentes que se van a reutilizar. Los frameworks son marcos de trabajo donde se juntan todas las piezas o componentes reutilizables su diseo puede servir para varias situaciones y en ellos se especifican los requerimientos que deben tener los componentes que estarn en l, la diferencia que hay entre estos y los contratos es que los frameworks se enfocan en las propiedades globales de los componentes y los contratos especifican el comportamiento y requerimientos de los mismos y referente a

los frameworks y patrones podemos decir que los patrones de diseo son una estructura lgica en el software mientras que los frameworks es una estructura fsica que se basa en el diseo de los patrones las diferencias entre ambos es que los frameworks son implementados en un lenguaje de programacin y es ejecutado y los patrones necesitan ser implementados cada que se utilizan, otra diferencia es que los patrones son elementos ms pequeos que los frameworks y estos a su vez contiene varios patrones mientras que un patrn no puede contener varios frameworks, otra cosa los patrones pueden utilizarse en cualquier aplicacin y los frameworks son ms especializados y se aplican particularmente. Ahora sobre el anlisis y diseo orientado al objeto para la reutilizacin, para esto podemos decir que el termino reutilizacin fue postulado por M.D Mclloroy en la conferencia de la NATO en 1968 sobre Ingeniera de Software, el propsito de la reutilizacin es mejorar la eficiencia y productividad del desarrollo de software utilizando elementos de software existentes, para reutilizar un componente est debe cumplir ciertos requerimientos para terminar como un componente genrico y especializado, las tcnicas para utilizarlos consisten en la seleccin y recuperacin, la comprensin y evaluacin, la adaptacin y la integracin de los componentes, en la reutilizacin se utiliza la programacin orientada a objetos la cual proporciona mecanismos como encapsulacin, abstraccin y ocultacin de la informacin y las clases proporcionan dos niveles de reutilizacin como representacin de una abstraccin que se puede especializar y como fabrica de objetos que comparten estructura y comportamiento, para esto se usa la herencia que permite que una clase utilice objetos de ella en otra clase pero no es tan eficiente a la hora de una aplicacin amplia al tener muchas dependencias internas en el recurso de rapidez, por otro lado los frameworks son un conjunto de clases asociadas por herencia donde las clases abstractas son las principales y le siguen las clases concretas las cuales trabajan como un todo y debe de ocultar las partes

de diseo y dejar accesibles las que deben especializarse y para reutilizar un frameworks se debe definir las clases que se necesitan y configurar objetos ya que este se reutiliza completo. Ahora hablemos del anlisis y diseo orientado al objeto, donde el objetivo del anlisis es modelar el dominio del problema identificando los objetos semnticos que contiene el significado de las especificaciones y los requisitos mientras que el diseo se enfoca en los objetos semnticos relacionados a las soluciones examinando de nueva cuenta las clases para mejorar su reutilizacin y aventajar sobre la herencia, pero estos dos pasos deben llevarse a cabo juntos de manera concurrente. En concreto el AOO sirve para identificar los requerimientos de nuestro software para esto se realizan tres actividades las cuales son, identificar las clases, atributos y comportamientos y tener lo reemplazos de los anteriores y especificar el comportamiento dinmico mediante paso de mensajes, algunas consideraciones que se deben de tomar son: recoger informacin de la mayor cantidad de fuentes posibles para una mejor visin a futuro, capturar todos los requisitos que se puedan para tener un mejor producto reutilizable, que su implementacin sea lo ms sencillo posible para que lo entienda quien lo va a reutilizar, refinar y eliminar clases redundantes, utilizar la herencia para especializar nuestros componentes, tomar en cuenta todas las aplicaciones hechas con caractersticas comunes para buscar soluciones, generalizar nuestro software para que se permita reutilizar componentes sin necesidad de reestructurar la arquitectura mediante la herencia, establecer las variantes que hay entre varios sistemas para permitirles una larga vida, revisar la documentacin para verificar que no haya errores o requisitos incumplidos. Apara continuar hablemos sobre el DOO cuyo propsito es crear una arquitectura para el sistema todo esto se hace mediante el anlisis que se hizo anteriormente ejecutar las estrategias implementar las clases y atributos pero el problema aqu es que la complejidad se acrecienta rpidamente, y un buen

subsistema debe tener una fuerte cohesin es decir que si un subsistema es modificado no debe alterar a un subsistemas de nivel bajo, cada subsistema debe tener una alta cohesin y un bajo acoplamiento, se debe ocultar el comportamiento o funcionalidad entre los subsistemas, despus de esto llegamos al diseo detallado que consiste en la utilizacin de la herencia para que los componentes sean menores ms sencillos de entender y modificar, utilizar interfaces, mtodos pblicos, usar el polimorfismo y evitar clases demasiado grandes. Para la reutilizacin utilizamos mucho el termino dominio que puede definirse como un rea de conocimiento donde se observan conceptos relacionados por lo que el anlisis de dominio es un proceso de creacin y mantenimiento de estructuras los hay verticales que especifica una clase de sistemas y los horizontales que contiene partes generales de software, es muy importante que el dominio de nuestro software se defina de manera clara y juntar toda la informacin despus de esto se debe recolectar datos sobre los componentes que vamos a utilizar si sirven o no, deben clasificarse y analizarse los datos para determinar nuevos requerimientos, las caractersticas del dominio son el anlisis del contexto que consiste en definir el alcance, funciones y caractersticas del domino en diagramas de flujo de datos, el modelo del dominio su propsito es analizar las cosas en comn y diferencias del problema , analiza las caractersticas y capacidades y servicios de las aplicaciones, se define el conocimiento del dominio para implementarlo y el anlisis funcional representa el comportamiento de las aplicaciones. En conclusin se puede decir que la reutilizacin tiene beneficios en calidad, productividad, funcionamiento, confiabilidad, interoperabilidad, reduccin de esfuerzo y su facetas son 6: substancia define los componente a reutilizar), alcance (la forma y grado), modo (como se lleva a cabo), tcnica (lo que se utiliza para implementar), intencin (como se utilizaran), y producto (que es reutilizado). Los tipos de reutilizacin son: reutilizacin compositiva est basada en componentes

que aun no se han modificado y la reutilizacin generativa que se basa ms en reutilizar un proceso que un componente, tambin debemos saber que dentro de un software se puede reutilizar desde el cdigo fuente, la documentacin, los objetos, texto, y arquitectura, algoritmos ya que estos son la base del xito de un programa, las libreras de funcin, de clases, la arquitectura del software, por otra pare debemos tener en cuenta los aspectos legales que son los derechos de registro del software al momento de reutilizarlo, los aspectos econmicos como cuanto vamos a invertir y que vamos a obtener al terminar nuestro software, aspectos organizacionales dependiendo de los afectados por el software y los aspectos de mtricas para estudiar a fondo el proyecto antes de su realizacin.

ALICIA GABRIELA OYERVIDES ARJONA (10380692)