Metodologa de Desarrollo de Software Basada en Componentes

Ingeniera de Software Basada en Componentes

Metodologa de Sistemas I
Viernes 30 de Abril de 2010 Concordia, Entre Ros

Integrantes:
Fontn, Emmanuel

Metodologa de Desarrollo de Software Basada en Componentes

Contenido:

Introduccin....................................................................................................................................... 3 Por qu surge est metodologa?................................................................................................. 4 Conceptos Bsicos:......................................................................................................................... 4 Un acercamiento al concepto de Componente.................................................................................. 5 Diferencia entre componentes y clases de objetos: ....................................................................... 6 Componentes COTS (Commercial-Off-The-Shelf)........................................................................... 6 Ingeniera de Software Basada en Componentes (ISBC).................................................................... 7 Fase de Construccin y adaptacin de la Ingeniera....................................................................... 8 Programacin Orientada a Componentes.......................................................................................... 9 Conceptos bsicos de la POC.......................................................................................................... 9 Problemas tpicos de la POC......................................................................................................... 10 Tecnologas de Implementacin....................................................................................................... 12 CORBA.......................................................................................................................................... 12 Middleware (capa de software intermedia)................................................................................. 12 Frameworks.................................................................................................................................. 13 JavaBeans..................................................................................................................................... 13 Conclusiones y Trabajo Futuro......................................................................................................... 15 Referencias....................................................................................................................................... 16

2010

2|Pgina

Metodologa de Desarrollo de Software Basada en Componentes

Introduccin
El presente trabajo trata de explicar los lineamientos generales y los conceptos bsicos que presenta el Desarrollo de Software Basado en Componentes (DSBC) reutilizables y distribuidos, y los procesos de ingeniera que sugiere este modelo. Est metodologa es una disciplina muy reciente, que surge como una extensin del paradigma de desarrollo Orientado a Objetos1 para arquitecturas de desarrollo donde los sistemas de aplicaciones son distribuidos y abiertos, y que presentan una complejidad inherente al sistema relativamente alta, donde este ltimo modelo se ve seriamente limitado , como por ejemplo los sistemas de informacin distribuidos bajo Web o las Telecomunicaciones. As tambin, se basa y extiende el modelo de objetos, y mantiene muchas de sus caractersticas principales, agregando la filosofa del ensamblaje de componentes de software independientes y previamente construidos y testeados, y extendiendo ms an el concepto de reutilizacin del software dentro de las aplicaciones. Como es una disciplina joven y aunque ha tenido un gran impulso en lo que es la vanguardia del desarrollo de software de hoy en da, an se encuentra en continuo desarrollo y evolucin; sin embargo, podemos destacar algunos de los conceptos que son pilares fundamentales y sientan las bases de esta metodologa. El objetivo del presente trabajo es justamente tratar de describir de manera breve dichos conceptos sobre los que se apoya el desarrollo de aplicaciones software basado en componentes reutilizables. En particular, nos centraremos en el proceso de Ingeniera de Desarrollo Basado en Componentes y en un vistazo a las plataformas presentes hoy en da para implementar aplicaciones creadas con dicha ingeniera, sin profundizar demasiado en conceptos tales como reutilizacin de software o aspectos de calidad y marketing de componentes comerciales (COTS), que creemos daran pie para otro trabajo mucho ms extenso. En primer lugar, se ofrece una introduccin a los conceptos bsicos necesarios para comprender las definiciones ms avanzadas que se muestran a lo largo del trabajo. Despus se presenta un acercamiento al concepto de componente de software, y al de Ingeniera de Desarrollo Basada en Componentes, y a los procesos que propone para construir aplicaciones en estos nuevos ambientes. Luego, se explicar la Programacin Orientada a Componentes (POC), un paradigma que ofrece herramientas prcticas de programacin para la construccin y utilizacin de componentes reusables, con el objetivo de lograr un mercado global de software. Finalmente, haremos un acercamiento a las tecnologas y plataformas actuales de desarrollo y de ejecucin de componentes que permite aislar la mayor parte de las dificultades conceptuales y tcnicas que conlleva la construccin de aplicaciones de este tipo.

Y como consecuencia directa del mismo. 3|Pgina

2010

Metodologa de Desarrollo de Software Basada en Componentes

Conceptos Bsicos
POR QU SURGE EST METODOLOGA ? La metodologa de software basada en Componentes surgi a finales de los 90's como una aproximacin basada en la reutilizacin al desarrollo de sistemas de software. Est metodologa fue motivada por la frustracin de los desarrolladores de que el modelo orientados a objetos no aplicaba una reutilizacin extensiva, tal como sta sugera originalmente, debido a que la utilizacin de clases implica el conocimiento detallado de ellas, lo cual significa que se deba tener acceso al cdigo fuente lo que imposibilitaba el marketing de clases para su reutilizacin. CONCEPTOS BSICOS: Segn [Vallecillo, Troya, & Fuentes, 2001], en este contexto entenderemos por sistema de aplicacin a un conjunto de herramientas que permiten la creacin e interconexin de componentes software, junto con una coleccin de servicios para facilitar las labores de los componentes que residen y se ejecutan en l. Un sistema se denomina independientemente extensible si puede ser dinmicamente extendido, y en donde pueden combinarse extensiones independientemente desarrolladas por distintas partes o entidades, sin conocimiento unas de otras. Diremos que un sistema es abierto si es concurrente, independientemente extensible, y permite a componentes heterogneos ingresar o abandonar el sistema de forma dinmica. Estas condiciones implican que los sistemas abiertos son inherentemente evolutivos, y que la vida de sus componentes es ms larga corta que la del propio sistema. As, la Programacin Orientada a Objetos (POO) ha sido el sustento de la ingeniera del software para los sistemas cerrados. Sin embargo, se ha mostrado insuficiente al tratar de aplicar sus tcnicas para el desarrollo de aplicaciones en entornos abiertos. Sin embargo, disponer de componentes no es suficiente tampoco, a menos que seamos capaces de reutilizarlos. Y reutilizar un componente no significa usarlo ms de una vez, sino que implica la capacidad del componente de ser utilizado en contextos distintos a aquellos para los que fue diseado. En este sentido, la reutilizacin es un concepto ms abarcativo que solo limitarse a la reutilizacin de cdigo fuente: ella involucra el uso de otros elementos de software, tales como arquitecturas de software y soluciones diseos estructurales que han probado su utilidad en situaciones similares ( patrones de diseo), e incluso partes enteras de programas se pueden reutilizar adaptndolas al proyecto especifico que estamos desarrollando.

2010

4|Pgina

Metodologa de Desarrollo de Software Basada en Componentes

Un acercamiento al concepto de Componente

Un componente es una unidad de software independiente que puede estar compuesta por otros componentes y que se utiliza para crear un sistema de software. Existen componentes con estado y sin estado. Que un componente no tenga estado externamente observable significa que las copias de componentes son indistinguibles, estos son ms sencillos de implementar. De cualquier modo se considera que la ingeniera de software basado en componentes (CBSE) debera adaptarse tanto a los componentes sin estado como los componentes con estado. Estas definiciones resultan abstractas, para una mejor comprensin se puede considerar a un componente como un proveedor de servicios independiente. Cuando un sistema necesita un servicio llama al componente que le proporcione dicho servicio sin tener en cuenta donde se esta ejecutando el componente o que lenguaje se a utilizado para desarrollar el componente. Ej. Un componente que convierta un formato grafico a otro (Ej.: png a jpg) proporciona un servicio de conversin de datos [Somerville, 2005]. Al ver a los componentes como proveedores de servicios aparecen dos caractersticas criticas de un componente reutilizable:
1- Un componente es una entidad ejecutable independiente. El cdigo fuente no

esta disponible, por lo que el componente no tiene que ser compilado antes de que sea usado por otros componentes del sistema. 2- Los servicios ofrecidos por componentes estn disponibles a travs de una interfaz, y todas las interacciones son a travs de esa interfaz. La interfaz del componente se expresa en trminos de operaciones parametrizadas y su estado interno nunca se muestra. Interfaces: Los componentes se definen por sus interfaces y puede considerarse que tienen dos interfaces relacionadas. 1- Interfaz que proporciona: Define los servicios que proporciona el componente, lo que se conoce como el API del componente. Define los mtodos que pueden ser llamados por el usuario del componente. 2- Interfaz que requiere: Especifica que servicios son necesarios para que el componente funcione, estos son requeridos de otros componentes del sistema. Esto no altera la independencia del componente, debido a que los servicios que se requieren no son solicitados a un componente especifico.

2010

5|Pgina

Metodologa de Desarrollo de Software Basada en Componentes Interfaz requiere Interfaz proporciona

Define los servicios que utiliza de los componentes del entorno ponentes del entorno

Componente

Define los servicios proporcionados por el componente a los com-

DIFERENCIA ENTRE COMPONENTES Y CLASES DE OBJETOS: Los componentes se desarrollan normalmente de forma similar a los objetos pero difieren en varios aspectos:
1- Los componentes son entidades desplegables: No son compilados, se instalan

23-

4-

5-

directamente en una plataforma de ejecucin. Los mtodos y atributos definidos en sus interfaces pueden ser accedidos por otros componentes. Los componentes no definen tipos: Las clases definen un tipo de dato abstracto y los objetos son instancias de ese tipo. Un componente ya es una instancia. Las implementaciones de los componentes son opacas: La implementacin de componentes esta oculta para los usuarios. Los componentes se suelen entregar como unidades binarias de este modo el que lo adquiere no tiene acceso a la implementacin. Los componentes son independientes del lenguaje: Las clases de objetos tienen que seguir las reglas de los lenguajes orientados a objetos, y generalmente solo pueden con otras clases escritas en el mismo lenguaje. Los componentes suelen implementarse en lenguajes orientados a objetos pero tambin pueden implementarse en lenguajes no orientados a objetos. Los componentes estn estandarizados: Esto significa que los componentes deben ajustarse a un modelo que restringe su implementacin, a diferencia de las clases de objetos que pueden implementarse de cualquier forma.

COMPONENTES COTS (COMMERCIAL -OFF-THE-SHELF) La mayora de de las metodologas de reutilizacin actuales no contemplan el uso de componentes comerciales ya existentes para el desarrollo de aplicaciones software. A estos tipos de software se los conoce con el nombre de comerciales fuera de la plataforma o componente COTS. El termino COTS hace referencia al software comercial desarrollado previamente por terceras partes, fuera de las estrategias de desarrollo y aplicadas durante todo el ciclo de vida del producto a desarrollar en base a productos comerciales. Esta clase de componente software generalmente es adquirido en formato binario, sin posibilidad de tener acceso al cdigo fuente y sin informacin adicional que ayude a los integradores en la seleccin correcta de los mismos. Esto impide pensar en tareas para la automatizacin de procesos [Iribarne & Vallecillo].

2010

6|Pgina

Metodologa de Desarrollo de Software Basada en Componentes

Ingeniera de Software Basada en Componentes (ISBC)

Tradicionalmente los ingenieros del software han seguido un enfoque de desarrollo descendente (top-down) basado en el ciclo de vida en cascada (anlisis-diseoimplementacin) para la construccin de sus sistemas, donde se establecen los requisitos y la arquitectura de la aplicacin y luego se va desarrollando, diseando e implementando cada parte software hasta obtener la aplicacin completa implementada [Iribarne, 2003]. La ISBC parte de la idea de la integracin de componentes software ya existentes (desarrollo ascendente o bottom-up). Las tecnologas de objetos proporcionan el marco de trabajo tcnico, para la ingeniera de software, para un modelo de proceso basado en componentes . El paradigma orientado a objetos enfatiza la creacin de clases que encapsulan tanto los datos como los algoritmos para manejar esos datos. Si se disean y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por diferentes aplicaciones. Es la reutilizacin la que permite a los desarrolladores construir aplicaciones sin partir desde cero, sino acercndose ms al modelo de construccin de otras ingenieras, donde los productos se construyen en base al ensamblaje y adaptacin de distintos componentes desarrollados por terceros (como lo es la industria del hardware para computadoras). Por ello requiere un conjunto de estndares, guas, procesos y prcticas, para que se la considere como una ingeniera tal, y como una subdisciplina de la Ingeniera de Software [Iribarne, 2003]. Segn Pressman, La metodologa que propone entonces la Ingeniera de Software Basada en Componentes (ISBC) (Figura 1) incorpora muchas de las caractersticas del Modelo en Espiral. Es evolutivo2 por naturaleza, y por ello exige tambin un enfoque iterativo para la creacin del software. Pero reemplaza las fases de Ingeniera y Construccin y Accin de ste modelo por una sola fase de Construccin y adaptacin de la Ingeniera:

comunicacin con el cliente- las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente. planificacin- las tareas requeridas para definir recursos, el tiempo y otra informacin relacionadas con el proyecto. anlisis de riesgos- las tareas requeridas para evaluar riesgos tcnicos y de gestin. construccin y adaptacin de la Ingeniera evaluacin del cliente- las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin.

Evoluciona con el tiempo, se crean versiones cada vez ms completas del producto . 7|Pgina

2010

Metodologa de Desarrollo de Software Basada en Componentes

Figura 1 Ingeniera basada en componentes [Pressman, 2002]

FASE DE CONSTRUCCIN Y ADAPTACIN DE LA INGENIERA La actividad comienza con la identificacin de clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la aplicacin y el algoritmo que se va a aplicar para conseguir el tratamiento. Los datos y los algoritmos correspondientes se empaquetan en una clase. Las clases creadas en los proyectos de ingeniera de software anteriores, se almacenan en una biblioteca de clases o diccionario de datos (repositorio). Una vez identificadas las clases candidatas, la biblioteca de clases se examina 3 para determinar si estas clases ya existen. En caso de que as fuera, se extraen de la biblioteca y se vuelven a utilizar. Si una clase candidata no reside en la biblioteca, se aplican los mtodos orientados a objetos para desarrollarla y se la agrega a la biblioteca para tenerla disponible en futuras iteraciones o futuras aplicaciones. Se crea una o ms representaciones (entregables) de la aplicacin, mediante las clases extradas de la biblioteca y las clases nuevas construidas para cumplir las necesidades nicas del proyecto, y se pasa a la fase de evaluacin del cliente. Se compone as la primera iteracin de la aplicacin , y el flujo del proceso vuelve a la espiral, para continuar iterando el proyecto para perfeccionarlo. El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software. Reduce en gran medida el tiempo del ciclo de desarrollo y el coste del proyecto, y aumenta la productividad 4. [Pressman, 2002]

3 4

Esto se conoce comnmente como trading Estos resultados estn en funcin directa de la robustez de la biblioteca de componentes. 8|Pgina

2010

Metodologa de Desarrollo de Software Basada en Componentes

Programacin Orientada a Componentes

La programacin orientada a componentes (POC) surge como una variante natural ante las limitaciones de la programacin orientada a objetos (POO) en los sistemas abiertos, por problemas como la falta de una unidad concreta de composicin independiente e las aplicaciones, y la definicin de interfaces a demasiado bajo nivel, dificultando la reutilizacin comercial de objetos. El objetivo de la POC es construir un mercado global de componentes software, en donde los usuarios son los desarrolladores de las aplicaciones que necesitan reutilizar componentes ya hechos y testeados para construir sus aplicaciones de forma ms rpida y robusta. Las entidades bsicas de la POC son los componentes, estos pueden interpretarse como cajas negras que encapsulan cierta funcionalidad y que son diseadas sin saber quien los utilizar, ni como, ni cuando. Los servicios de los componentes son conocidos mediante sus interfaces y requisitos. La POC es un paradigma de programacin que se centra en el diseo e implementacin de componentes, y en particular en los conceptos de encapsulacin, polimorfismo, composicin tarda y seguridad. CONCEPTOS BSICOS DE LA POC Aparte del propio concepto de componente software, existe otro conjunto de conceptos bsicos que intervienen en la POC, y que permiten diferenciarla del resto de los paradigmas de programacin. Entre ellos se encuentran los siguientes: Composicin tarda: Composicin que se realiza en un tiempo posterior al de la compilacin del componente, como puede ser durante su enlazado, carga o ejecucin, y por alguien ajeno a su desarrollo, es decir, que slo conoce al componente por su interfaz o contrato, sin necesidad de conocer detalles de implementacin, ni la forma en que fue creado. Eventos: Mecanismo de comunicacin por el que se pueden propagar las situaciones que ocurren en un sistema de forma asncrona. Emitidos para avisar a los componentes de su entorno de cambios en su estado. Reutilizacin: Habilidad de un componente software de ser utilizado en contextos distintos a aquellos para los que fue diseado (reutilizar no significa usar ms de una vez). Contratos: Especificacin que se aade a la interfaz de un componente y que establece las condiciones de uso e implementacin que ligan a los clientes y proveedores del componente. Los contratos cubren aspectos tanto funcionales (semntica de las operaciones
2010 9|Pgina

Metodologa de Desarrollo de Software Basada en Componentes

de la interfaz) como no funcionales (calidad de servicio, prestaciones, fiabilidad o seguridad). Polimorfismo: Habilidad de un mismo componente de mostrarse de diferentes formas, dependiendo del contexto; o bien la capacidad de distintos componentes de mostrar un mismo comportamiento en un contexto dado. En POC muestra tres nuevas posibilidades: La reemplazabilidad (Inclusin), o capacidad de un componente de reemplazar a otro en una aplicacin, sin romper los contratos con sus clientes. El polimorfismo paramtrico, o implementacin genrica de un componente. Este no se resuelve en tiempo de compilacin (generando la tpica explosin de cdigo) sino en tiempo de ejecucin. Por ltimo, el polimorfismo acotado, para indicar restricciones sobre los tipos sobre los que se puede parametrizar un componente. Seguridad: Garanta que debe ofrecer un componente de respetar sus interfaces y contratos. -Seguridad a nivel de tipos: Asegura que las invocaciones usen los parmetros adecuados (o supertipos) y que los valores que devuelven son del tipo adecuado (o subtipos). -Seguridad a nivel de mdulo: Asegura que solo se utilizan los servicios ajenos al componente que se han declarado. Reflexin: Habilidad para conocer y modificar el estado de un componente. PROBLEMAS TPICOS DE LA POC POC es una disciplina muy joven y por tanto en la que los resultados obtenidos hasta ahora se centran ms en la identificacin de los problemas que en la resolucin de los mismos. Algunos de retos y problemas con los que se enfrenta actualmente son: 1. Clarividencia. Se refiere a la dificultad con la que se encuentra el diseador de un componente al realizar su diseo, pues no conoce ni quin lo utilizar, ni cmo, ni en qu entorno, ni para qu aplicacin. Este problema est muy ligado a la composicin tarda y reusabilidad de los componentes. 2. Evolucin de los componentes. La gestin de la evolucin es un problema serio, pues en los sistemas grandes han de poder coexistir varias versiones de un mismo componente. 3. Percepcin del entorno. Habilidad de un componente de descubrir tanto el tipo de entorno en donde se est ejecutando (de diseo o de ejecucin), como los servicios y recursos disponibles en el.

2010

10 | P g i n a

Metodologa de Desarrollo de Software Basada en Componentes

4. Particularizacin. Cmo particularizar los servicios que ofrece un componente para adaptarlo a las necesidades y requisitos concretos de nuestra aplicacin, sin poder manipular su implementacin. 5. Falta de soporte formal. La POC tambin se encuentra con otro reto aadido, como es la dificultad que encuentran los mtodos formales para trabajar con sus peculiaridades, como puede ser la composicin tarda, el polimorfismo o la evolucin de los componentes. 6. El problema de la clase base frgil (FBCP). Este problema ocurre cuando la superclase de una clase sufre modificaciones. El FBCP existe a dos niveles, sintctico y semntico. A nivel sintctico ocurre cuando las modificaciones de la superclase son puramente a este nivel. A nivel semntico ocurre cuando lo que se altera es la implementacin de los mtodos de la superclase. 7. Asincrona y carreras de eventos. Problema que se presenta por los tiempos de comunicacin en los sistemas abiertos (no se pueden despreciar retrasos). Es muy difcil garantizar el orden relativo en el que se distribuyen los eventos. El proceso de difusin de eventos es complicado cuando los emisores y receptores pueden cambiar con el tiempo. 8. Interoperabilidad. Actualmente, los contratos de los componentes se reducen a la definicin de sus interfaces a nivel sintctico, y la interoperabilidad se reduce a la comprobacin de los nombres y perfiles de los mtodos. Sin embargo, es necesario ser capaces de referirnos y buscar los servicios que necesitamos por algo ms que sus nombres, y poder utilizar los mtodos ofrecidos en una interfaz en el orden adecuado.

Quiz sea POC la disciplina de la programacin con mayor proyeccin a corto y medio plazo por el planteamiento tan apropiado que realiza de la construccin de aplicaciones para sistemas abiertos, a partir de esto se busca cubrir las necesidades de la industria. Actualmente es uno de los campos de investigacin ms activos de la comunidad software.

2010

11 | P g i n a

Metodologa de Desarrollo de Software Basada en Componentes

Tecnologas de Implementacin
CORBA 5 CORBA es un estndar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocacin de mtodos remotos (componentes) bajo un paradigma orientado a objetos. Este estndar define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la compatibilidad entre diferentes aplicaciones que se escriben en lenguajes distintos y se corren en distintas plataformas, por lo que se asemeja a la computacin distribuida. Este estndar consta en encerrar el cdigo escrito en otro lenguaje, en un paquete que contiene adems alguna informacin sobre el cdigo que encierra y sobre cmo llamar y utilizar sus mtodos (que son las interfaces). Los objetos que resultan de este empaquetamiento, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. El estndar utiliza un lenguaje de definicin de interfaces (IDL) para especificar la forma en que deben ser llamados los mtodos que contiene un objeto CORBA (liberando al programador de conocer la implementacin de estos mtodos). Se puede especificar a partir de este IDL, la interfaz para utilizar el objeto CORBA en cualquier lenguaje. Implementaciones estndar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl. Cuando se compila una interfaz en IDL se genera cdigo para el cliente y el servidor (el implementador del objeto). El cdigo del cliente sirve para poder realizar las llamadas a mtodos remotos, e incluye un proxy (representante) del objeto remoto en el lado del cliente. El cdigo generado para el servidor consiste en un esqueleto (o una estructura) y el desarrollador tiene que codificar para implementar los mtodos del objeto. El estndar, ms que ser una especificacin multiplataforma, tambin define servicios fundamentales de seguridad y de transacciones. MIDDLEWARE (CAPA DE SOFTWARE
INTERMEDIA )

Consiste en un software que proporciona interoperabilidad entre servicios de aplicaciones y organiza todos los recursos en una grid (nueva forma de computacin distribuida), en la cual los recursos pueden ser heterogneos, es decir, poseer diferentes arquitecturas, supercomputadores, clusters, etctera, y se encuentran conectados mediante redes de rea extensa, la ms clsica es Internet).
5

Wikipedia Enciclopedia Libre: http://es.wikipedia.org/wiki/CORBA

2010

12 | P g i n a

Metodologa de Desarrollo de Software Basada en Componentes

Este software una ver funcionando automatiza todas las interacciones mquina a mquina (llamada tambin M2M) y crea una nica grid computacional. Funcionamiento: El middleware negocia de manera automtica el intercambio de recursos. La negociacin consiste en cmo se va a realizar la transaccin de los recursos desde el proveedor de recursos de grid hacia el usuario de la grid. Existen dos tipos de middleware en estas negociaciones:
1. Los que presentan metadatos (datos acerca de los datos) que describen datos y

recursos.
2. Y los que se encargan de las negociaciones M2M (Mquina a Mquina), requeridas

para la autenticacin y la autorizacin que debe tener cada usuario para utilizar un recurso. Luego se constituyen acuerdos para acceder a los datos y recursos solicitados por el cliente. Pero no termina ah: una vez que se establece el acuerdo, el middleware supervisa la transferencia de los recursos y optimiza el enrutamientos de la red. FRAMEWORKS Un framework es una estructura conceptual y tecnolgica compuesta por mdulos de software concretos, que sirven de base para organizar y desarrollar nuevos proyectos de software. Los frameworks incluyen soporte para programas, bibliotecas y distintos programas para ayudar a desarrollar y unir los distintos componentes de un proyecto. Los frameworks fueron creados para facilitar la tarea de desarrollo de software, permitindoles a los diseadores y programadores pasar ms tiempo estableciendo correctamente los requerimientos de un software y pasar menos tiempo en los detalles de implementacin para proveer un sistema funcional. Sin embargo, en los ltimos tiempos surgieron muchas quejas sobre los framework ya que segn dicen aade cdigo innecesario y por la falta de un framework de calidad y simplicidad, el tiempo que antes haba que pasar programando ahora hay que pasarlo aprendiendo a usar un framework.

JAVABEANS6 Los JavaBeans son un modelo de componentes creado por Sun Microsystems para la implementacin de componentes reutilizables en el lenguaje Java.
6

Wikipedia Enciclopedia Libre: http://es.wikipedia.org/wiki/Javabeans

2010

13 | P g i n a

Metodologa de Desarrollo de Software Basada en Componentes

Se usan para encapsular varios objetos en un nico objeto, para hacer uso de un slo objeto en lugar de varios ms simples. La especificacin de JavaBeans de Sun Microsystems los define como componentes de software reutilizables que se puedan manipular visualmente en una herramienta de construccin. Para funcionar como una clase JavaBean, una clase debe obedecer ciertas convenciones sobre nomenclatura (nombre, tipo numero y orden de los parmetros de entrada) de los mtodos, construccin, y comportamiento. Estas convenciones permiten tener herramientas que puedan utilizar, reutilizar, sustituir, y conectar JavaBeans. Las convenciones requeridas son:

Debe tener un constructor sin argumentos (constructor ciego). Debe poderse instanciar: no se puede convertir una interfaz o una clase abstracta en un Bean. Sus propiedades deben ser accesibles mediante mtodos get() y set(), que siguen una convencin de nomenclatura estndar. Debe ser serializable: Debe implementar la interfaz Serializable o la interfaz Externalizable, que permiten que se copie como una serie de bytes en un flujo, para guardar su estado y restaurarlo posteriormente (persistencia).

2010

14 | P g i n a

Metodologa de Desarrollo de Software Basada en Componentes

Conclusiones y Trabajo Futuro

En esta leccin hemos tratado de ofrecer una visin sobre lo que constituye el desarrollo de aplicaciones software basado en la idea del ensamblaje de componentes reutilizables. Si bien el desarrollo del trabajo es abarcativo, muchos temas fueron dejados de lado porque mereceran un trabajo completo aparte. La reutilizacin es un rea que abarca aspectos mucho ms amplios de un proyecto, y no solo reutilizacin de cdigo de aplicaciones. La reutilizacin de Arquitecturas Software y Marcos de Trabajo completos, que intentan ofrecer soluciones de diseo desde el punto de vista estructural de las aplicaciones, y de las relaciones entre sus componentes, as como Patrones de Diseo comunes en dichas arquitecturas, son algunos de los temas que ms se est estudiando hoy en da a alto nivel en la Ingeniera Basada en Componentes, junto con los mencionados al principio como aspectos de calidad y marketing de componentes, y las diversas tecnologas de implementacin de modelos de componentes, como CORBA, Enterprise JavaBeans7 y COM8. Son temas que merecen futuras investigaciones aparte, y pensamos que, como es una disciplina muy joven, todava le queda mucho camino por recorrer para considerarse una Ingeniera como tal.

Sun Microsystems Microsoft Corporation

2010

15 | P g i n a

Metodologa de Desarrollo de Software Basada en Componentes

Referencias

[Pressman, 2002] Ingeniera del Software, Un enfoque prctico , Roger S. Pressman, 2002, 5ta Edicin McGRAW-HILL [Somerville, 2005] Ingeniera del Software, Ian Somerville, 2005, 7ma Edicin Pearson Educacin [Iribarne, 2003] Un Modelo de Mediacin para el Desarrollo de Software Basado en Componentes COTS, Luis F. Iribarne Martnez, Tesis Doctoral, Universidad de Almera, Espaa [Vallecillo, Troya, & Fuentes, 2001] Desarrollo de Software Basado en Componentes, Lidia Fuentes, Jos M. Troya y Antonio Vallecillo, 2001, Universidad de Mlaga [Iribarne & Vallecillo] Elaboracin de aplicaciones software a partir de Componentes COTS, Luis Iribarne y Antonio Vallecillo [Bertoa, Troya, & Vallecillo, 2002], Aspectos de Calidad en el Desarrollo de Software Basado en Componentes, Manuel F. Bertoa, Jos M. Troya y Antonio Vallecillo

2010

16 | P g i n a