metodologadedesarrollodesoftwarebasadaencomponentes-140525022252-phpapp01

Metodologa de

Desarrollo de

Software Basada en

Componentes

Ingeniera de Software Basada en

Componentes

Metodologa de Sistemas I

Universidad Nacional de Entre Ros

Viernes 30 de Abril de 2010

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


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 Objetos 1 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

Y como consecuencia directa del mismo.

2010 3 | Pgina


que permite aislar la mayor parte de las dificultades conceptuales y tcnicas que

conlleva la construccin de aplicaciones de este tipo.

2010 4 | Pgina


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 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 5 | Pgina


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 est ejecutando el componente o que

lenguaje se a utilizado para desarrollar el componente. Ej. Un componente que

convierta un formato grfico 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 est 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 6 | Pgina


Interfaz requiere

Define los servicios Component que utiliza de los com- e el ponentes del entorno componentes del entorno

Interfaz proporciona

Define los servicios proporcionados por

componente a los

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 directamente en una plataforma de ejecucin. Los mtodos y

atributos definidos en sus interfaces pueden ser accedidos por otros

componentes.

2-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.

3-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.

4-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.

5-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

2010 7 | Pgina


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 8 | Pgina


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-diseo-implementacin) 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 evolutivo 2 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.

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

2010 9 | Pgina


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.

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.

Esto se conoce comnmente como trading

2010 10 | P g i n a


Reduce en gran medida el tiempo del ciclo de desarrollo y el coste del proyecto, y

aumenta la productividad 4 . [Pressman, 2002]

Estos resultados estn en funcin directa de la robustez de la biblioteca de componentes.

2010 11 | P g i n a


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 cmo, ni cundo. 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

encapsulamiento, 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).

2010 12 | P g i n a


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 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.

2010 13 | P g i n a


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.

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 14 | P g i n a


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, clsteres, etctera, y

5

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

2010 15 | P g i n a


se encuentran conectados mediante redes de rea extensa, la ms clsica es

Internet).

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.

2010 16 | P g i n a


JAVABEANS 6

Los JavaBeans son un modelo de componentes creado por Sun Microsystems

para la implementacin de componentes reutilizables en el lenguaje Java.

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).

6

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

2010 17 | P g i n a


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 JavaBeans 7 y COM 8 .

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.

7

8

Sun Microsystems

Microsoft Corporation

2010 18 | P g i n a


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 19 | P g i n a

metodologadedesarrollodesoftwarebasadaencomponentes-140525022252-phpapp01

Documents