Metodología de desarrollo de software basada en componentes

Metodología de
Desarrollo de
Software Basada en
Componentes
Ingeniería de Software Basada en
Componentes
Metodología de Sistemas I
Universidad Nacional de Entre Ríos
Viernes 30 de Abril de 2010
Fontán, Emmanuel

Metodología de Desarrollo de Software Basada en Componentes
Contenido:
Introducción........................................................................................................3
¿Por qué surge está metodología?...................................................................4
Conceptos Básicos:..........................................................................................4
Un acercamiento al concepto de Componente....................................................5
Diferencia entre componentes y clases de objetos:.........................................6
Componentes COTS (Commercial-Off-The-Shelf).............................................6
Ingeniería de Software Basada en Componentes (ISBC).....................................7
Fase de Construcción y adaptación de la Ingeniería........................................8
Programación Orientada a Componentes............................................................9
Conceptos básicos de la POC...........................................................................9
Problemas típicos de la POC...........................................................................10
Tecnologías de Implementación........................................................................12
CORBA...........................................................................................................12
Middleware (capa de software intermedia)....................................................12
Frameworks....................................................................................................13
JavaBeans......................................................................................................13
Conclusiones y Trabajo Futuro...........................................................................15
Referencias.......................................................................................................16
2010 2 | P á g i n a

Introducción
El presente trabajo trata de explicar los lineamientos generales y los conceptos
básicos que presenta el Desarrollo de Software Basado en Componentes
(DSBC) reutilizables y distribuidos, y los procesos de ingeniería que sugiere este
modelo. Está metodología es una disciplina muy reciente, que surge como una
extensión 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
información distribuidos bajo Web o las Telecomunicaciones. Así también, se basa
y extiende el modelo de objetos, y mantiene muchas de sus características
principales, agregando la filosofía del “ensamblaje” de componentes de software
independientes y previamente construidos y testeados, y extendiendo más aún el
concepto de “reutilización” 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 día, aún se encuentra en continuo
desarrollo y evolución; sin embargo, podemos destacar algunos de los conceptos
que son pilares fundamentales y sientan las bases de esta metodología.
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 Ingeniería de Desarrollo Basado en Componentes y en un vistazo a las
plataformas presentes hoy en día para implementar aplicaciones creadas con
dicha ingeniería, sin profundizar demasiado en conceptos tales como reutilización
de software o aspectos de calidad y marketing de componentes comerciales
(COTS), que creemos darían pie para otro trabajo mucho más extenso.
En primer lugar, se ofrece una introducción a los conceptos básicos necesarios
para comprender las definiciones más avanzadas que se muestran a lo largo del
trabajo. Después se presenta un acercamiento al concepto de “componente de
software”, y al de Ingeniería de Desarrollo Basada en Componentes, y a los
procesos que propone para construir aplicaciones en estos nuevos ambientes.
Luego, se explicará la Programación Orientada a Componentes (POC), un
paradigma que ofrece herramientas prácticas de programación para la
construcción y utilización de componentes reusables, con el objetivo de lograr un
“mercado global de software”. Finalmente, haremos un acercamiento a las
tecnologías y plataformas actuales de desarrollo y de ejecución de componentes
1
Y como consecuencia directa del mismo.
2010 3 | P á g i n a

que permite aislar la mayor parte de las dificultades conceptuales y técnicas que
conlleva la construcción de aplicaciones de este tipo.
2010 4 | P á g i n a

Conceptos Básicos
¿POR QUÉ SURGE ESTÁ METODOLOGÍA?
La metodología de software basada en Componentes surgió a finales de los
90's como una aproximación basada en la reutilización al desarrollo de sistemas
de software. Está metodología fue motivada por la frustración de los
desarrolladores de que el modelo orientados a objetos no aplicaba una
reutilización extensiva, tal como ésta sugería originalmente, debido a que la
utilización de clases implica el conocimiento detallado de ellas, lo cual significa
que se debía tener acceso al código fuente lo que imposibilitaba el marketing de
clases para su reutilización.
CONCEPTOS BÁSICOS:
Según [Vallecillo, Troya, & Fuentes, 2001], en este contexto entenderemos por
sistema de aplicación a un conjunto de herramientas que permiten la creación e
interconexión de componentes software, junto con una colección 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
dinámicamente 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 heterogéneos ingresar o abandonar el
sistema de forma dinámica. Estas condiciones implican que los sistemas abiertos
son inherentemente evolutivos, y que la vida de sus componentes es más corta
que la del propio sistema.
Así, la Programación Orientada a Objetos (POO) ha sido el sustento de la
ingeniería del software para los sistemas cerrados. Sin embargo, se ha mostrado
insuficiente al tratar de aplicar sus técnicas 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
más de una vez, sino que implica la capacidad del componente de ser utilizado
en contextos distintos a aquellos para los que fue diseñado. En este sentido,
la reutilización es un concepto más abarcativo que solo limitarse a la reutilización
de código fuente: ella involucra el uso de otros elementos de software, tales como
arquitecturas de software y soluciones diseños estructurales que han probado su
utilidad en situaciones similares (“patrones de diseño”), e incluso partes enteras de
programas se pueden reutilizar adaptándolas al proyecto especifico que estamos
desarrollando.
2010 5 | P á g i n a

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 más sencillos de implementar. De cualquier modo se
considera que la ingeniería de software basado en componentes (CBSE) debería
adaptarse tanto a los componentes sin estado como los componentes con estado.
Estas definiciones resultan abstractas, para una mejor comprensión 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 gráfico a otro (Ej.: png a jpg) proporciona un servicio de
conversión de datos [Somerville, 2005].
Al ver a los componentes como proveedores de servicios aparecen dos
características criticas de un componente reutilizable:
1- Un componente es una entidad ejecutable independiente. El código
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 están disponibles a través de
una interfaz, y todas las interacciones son a través de esa interfaz. La
interfaz del componente se expresa en términos 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 métodos
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 | P á g i n a

Interfaz requiere Interfaz proporciona
Define los servicios Define los servicios
que utiliza de los com- proporcionados por
el
ponentes del entorno componente a los
com-
ponentes del entorno
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 ejecución. Los métodos 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
implementación 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 implementación.
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 también pueden implementarse en lenguajes
no orientados a objetos.
5- Los componentes están estandarizados: Esto significa que los
componentes deben ajustarse a un modelo que restringe su
implementación, a diferencia de las clases de objetos que pueden
implementarse de cualquier forma.
COMPONENTES COTS (COMMERCIAL-OFF-THE-SHELF)
La mayoría de de las metodologías de reutilización 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 | P á g i n a
Component
e

desarrollar en base a productos comerciales. Esta clase de componente software
generalmente es adquirido en formato binario, sin posibilidad de tener acceso al
código fuente y sin información adicional que ayude a los integradores en la
selección correcta de los mismos. Esto impide pensar en tareas para la
automatización de procesos [Iribarne & Vallecillo].
2010 8 | P á g i n a

Ingeniería 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
(análisis-diseño-implementación) para la construcción de sus sistemas, donde se
establecen los requisitos y la arquitectura de la aplicación y luego se va
desarrollando, diseñando e implementando cada parte software hasta obtener la
aplicación completa implementada [Iribarne, 2003]. La ISBC parte de la idea de la
integración de componentes software ya existentes (desarrollo ascendente o
bottom-up).
Las tecnologías de objetos proporcionan el marco de trabajo técnico, para la
ingeniería de software, para un modelo de proceso basado en componentes. El
paradigma orientado a objetos enfatiza la creación de clases que encapsulan tanto
los datos como los algoritmos para manejar esos datos. Si se diseñan y se
implementan adecuadamente, las clases orientadas a objetos son reutilizables por
diferentes aplicaciones. Es la reutilización la que permite a los desarrolladores
construir aplicaciones sin partir desde cero, sino acercándose más al modelo de
construcción de otras ingenierías, donde los productos se construyen en base al
ensamblaje y adaptación de distintos componentes desarrollados por terceros
(como lo es la industria del hardware para computadoras). Por ello requiere un
conjunto de estándares, guías, procesos y prácticas, para que se la considere
como una ingeniería tal, y como una subdisciplina de la Ingeniería de Software
[Iribarne, 2003].
Según Pressman, La metodología que propone entonces la “Ingeniería de
Software Basada en Componentes” (ISBC) (Figura 1) incorpora muchas de las
características del Modelo en Espiral. Es evolutivo2
por naturaleza, y por ello
exige también un enfoque iterativo para la creación del software.
Pero reemplaza las fases de Ingeniería y Construcción y Acción de éste
modelo por una sola fase de Construcción y adaptación de la Ingeniería:
 comunicación con el cliente- las tareas requeridas para establecer
comunicación entre el desarrollador y el cliente.
 planificación- las tareas requeridas para definir recursos, el tiempo y otra
información relacionadas con el proyecto.
 análisis de riesgos- las tareas requeridas para evaluar riesgos técnicos y
de gestión.
2
Evoluciona con el tiempo, se crean versiones cada vez más completas del producto.
2010 9 | P á g i n a

 construcción y adaptación de la Ingeniería
 evaluación del cliente- las tareas requeridas para obtener la reacción del
cliente según la evaluación de las representaciones del software creadas
durante la etapa de ingeniería e implementada durante la etapa de
instalación.
Figura 1 – Ingeniería basada en componentes [Pressman, 2002]
FASE DE CONSTRUCCIÓN Y ADAPTACIÓN DE LA INGENIERÍA
La actividad comienza con la identificación de clases candidatas. Esto se lleva a
cabo examinando los datos que se van a manejar por parte de la aplicación 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 ingeniería 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 examina3
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 métodos 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 más representaciones (entregables) de la aplicación, mediante las
clases extraídas de la biblioteca y las clases nuevas construidas para cumplir las
necesidades únicas del proyecto, y se pasa a la fase de evaluación del cliente.
Se compone así la primera iteración de la aplicación, 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 reutilización del
software, y la reutilización proporciona beneficios a los ingenieros de software.
3
Esto se conoce comúnmente 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 productividad4
. [Pressman, 2002]
4
Estos resultados están en función directa de la robustez de la biblioteca de componentes.
2010 11 | P á g i n a

Programación Orientada a Componentes
La programación orientada a componentes (POC) surge como una variante natural
ante las limitaciones de la programación orientada a objetos (POO) en los
sistemas abiertos, por problemas como la falta de una unidad concreta de
composición independiente e las aplicaciones, y la definición de interfaces a
demasiado bajo nivel, dificultando la reutilización 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 más rápida y robusta.
Las entidades básicas de la POC son los componentes, estos pueden
interpretarse como cajas negras que encapsulan cierta funcionalidad y que son
diseñadas sin saber quien los utilizará, ni cómo, ni cuándo. Los servicios de los
componentes son conocidos mediante sus interfaces y requisitos.
La POC es un paradigma de programación que se centra en el diseño e
implementación de componentes, y en particular en los conceptos de
encapsulamiento, polimorfismo, composición tardía y seguridad.
CONCEPTOS BÁSICOS DE LA POC
Aparte del propio concepto de componente software, existe otro conjunto de
conceptos básicos que intervienen en la POC, y que permiten diferenciarla del
resto de los paradigmas de programación. Entre ellos se encuentran los
siguientes:
Composición tardía: Composición que se realiza en un tiempo posterior al de la
compilación del componente, como puede ser durante su enlazado, carga o
ejecución, y por alguien ajeno a su desarrollo, es decir, que sólo conoce al
componente por su interfaz o contrato, sin necesidad de conocer detalles de
implementación, ni la forma en que fue creado.
Eventos: Mecanismo de comunicación por el que se pueden propagar las
situaciones que ocurren en un sistema de forma asíncrona. Emitidos para avisar a
los componentes de su entorno de cambios en su estado.
Reutilización: Habilidad de un componente software de ser utilizado en contextos
distintos a aquellos para los que fue diseñado (reutilizar no significa usar más de
una vez).
2010 12 | P á g i n a

Contratos: Especificación que se añade a la interfaz de un componente y que
establece las condiciones de uso e implementación que ligan a los clientes y
proveedores del componente. Los contratos cubren aspectos tanto funcionales
(semántica 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 (Inclusión), o capacidad de un componente de reemplazar a
otro en una aplicación, sin romper los contratos con sus clientes.
El polimorfismo paramétrico, o implementación genérica de un componente. Este
no se resuelve en tiempo de compilación (generando la típica explosión de código)
sino en tiempo de ejecución.
Por último, el polimorfismo acotado, para indicar restricciones sobre los tipos
sobre los que se puede parametrizar un componente.
Seguridad: Garantía que debe ofrecer un componente de respetar sus interfaces
y contratos.
-Seguridad a nivel de tipos: Asegura que las invocaciones usen los parámetros
adecuados (o supertipos) y que los valores que devuelven son del tipo adecuado
(o subtipos).
-Seguridad a nivel de módulo: Asegura que solo se utilizan los servicios ajenos al
componente que se han declarado.
Reflexión: Habilidad para conocer y modificar el estado de un componente.
PROBLEMAS TÍPICOS DE LA POC
POC es una disciplina muy joven y por tanto en la que los resultados obtenidos
hasta ahora se centran más en la identificación de los problemas que en la
resolución 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 diseñador de
un componente al realizar su diseño, pues no conoce ni quién lo utilizará, ni cómo,
ni en qué entorno, ni para qué aplicación. Este problema está muy ligado a la
composición tardía y reusabilidad de los componentes.
2010 13 | P á g i n a

2. Evolución de los componentes. La gestión de la evolución es un problema
serio, pues en los sistemas grandes han de poder coexistir varias versiones de un
mismo componente.
3. Percepción del entorno. Habilidad de un componente de descubrir tanto el tipo
de entorno en donde se está ejecutando (de diseño o de ejecución), como los
servicios y recursos disponibles en el.
4. Particularización. Cómo particularizar los servicios que ofrece un componente
para adaptarlo a las necesidades y requisitos concretos de nuestra aplicación, sin
poder manipular su implementación.
5. Falta de soporte formal. La POC también se encuentra con otro reto añadido,
como es la dificultad que encuentran los métodos formales para trabajar con sus
peculiaridades, como puede ser la composición tardía, el polimorfismo o la
evolución de los componentes.
6. El problema de la clase base frágil (FBCP). Este problema ocurre cuando la
superclase de una clase sufre modificaciones. El FBCP existe a dos niveles,
sintáctico y semántico. A nivel sintáctico ocurre cuando las modificaciones de la
superclase son puramente a este nivel. A nivel semántico ocurre cuando lo que se
altera es la implementación de los métodos de la superclase.
7. Asincronía y carreras de eventos. Problema que se presenta por los tiempos
de comunicación en los sistemas abiertos (no se pueden despreciar retrasos).
Es muy difícil garantizar el orden relativo en el que se distribuyen los eventos. El
proceso de difusión 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 definición de sus interfaces a nivel sintáctico, y la interoperabilidad se reduce a
la comprobación de los nombres y perfiles de los métodos. Sin embargo, es
necesario ser capaces de referirnos y buscar los servicios que necesitamos por
algo más que sus nombres, y poder utilizar los métodos ofrecidos en una interfaz
en el orden adecuado.
Quizá sea POC la disciplina de la programación con mayor proyección a corto y
medio plazo por el planteamiento tan apropiado que realiza de la construcción de
aplicaciones para sistemas abiertos, a partir de esto se busca cubrir las
necesidades de la industria. Actualmente es uno de los campos de investigación
más activos de la comunidad software.
2010 14 | P á g i n a

Tecnologías de Implementación
CORBA5
CORBA es un estándar que establece una plataforma de desarrollo de sistemas
distribuidos facilitando la invocación de métodos remotos (componentes) bajo un
paradigma orientado a objetos.
Este estándar 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 computación distribuida.
Este estándar consta en encerrar el código escrito en otro lenguaje, en un
paquete que contiene además alguna información sobre el código que encierra y
sobre cómo llamar y utilizar sus métodos (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 estándar utiliza un lenguaje de definición de interfaces (IDL) para especificar
la forma en que deben ser llamados los métodos que contiene un objeto CORBA
(liberando al programador de conocer la implementación de estos métodos).
Se puede especificar a partir de este IDL, la interfaz para utilizar el objeto CORBA
en cualquier lenguaje. Implementaciones estándar existen para Ada, C, C++,
Smalltalk, Java, Python, Perl y Tcl.
Cuando se compila una interfaz en IDL se genera código para el cliente y el
servidor (el implementador del objeto). El código del cliente sirve para poder
realizar las llamadas a métodos remotos, e incluye un proxy (representante) del
objeto remoto en el lado del cliente. El código generado para el servidor consiste
en un esqueleto (o una estructura) y el desarrollador tiene que codificar para
implementar los métodos del objeto.
El estándar, más que ser una especificación multiplataforma, también 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
computación distribuida), en la cual los recursos pueden ser heterogéneos, es
decir, poseer diferentes arquitecturas, supercomputadores, clústeres, etcétera, 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 más clásica es
Internet).
Este software una ver funcionando automatiza todas las interacciones “máquina a
máquina” (llamada también M2M) y crea una única grid computacional.
Funcionamiento:
El middleware negocia de manera automática el intercambio de recursos. La
negociación consiste en cómo se va a realizar la transacción 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 (Máquina a Máquina),
requeridas para la autenticación y la autorización 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 tecnológica compuesta por módulos
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,
permitiéndoles a los diseñadores y programadores pasar más tiempo
estableciendo correctamente los requerimientos de un software y pasar menos
tiempo en los detalles de implementación para proveer un sistema funcional. Sin
embargo, en los últimos tiempos surgieron muchas quejas sobre los framework ya
que según dicen añade código innecesario y por la falta de un framework de
calidad y simplicidad, el tiempo que antes había que pasar programando ahora
hay que pasarlo aprendiendo a usar un framework.
2010 16 | P á g i n a

JAVABEANS6
Los JavaBeans son un modelo de componentes creado por Sun Microsystems
para la implementación de componentes reutilizables en el lenguaje Java.
Se usan para encapsular varios objetos en un único objeto, para hacer uso de un
sólo objeto en lugar de varios más simples.
La especificación de JavaBeans de Sun Microsystems los define como
“componentes de software reutilizables que se puedan manipular visualmente en
una herramienta de construcción”.
Para funcionar como una clase JavaBean, una clase debe obedecer ciertas
convenciones sobre nomenclatura (nombre, tipo numero y orden de los
parámetros de entrada) de los métodos, construcción, 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 métodos get() y set(), que
siguen una convención de nomenclatura estándar.
 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 lección hemos tratado de ofrecer una visión 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 merecerían un trabajo completo aparte.
La reutilización es un área que abarca aspectos mucho más amplios de un
proyecto, y no solo reutilización de código de aplicaciones.
La reutilización de “Arquitecturas Software” y “Marcos de Trabajo” completos, que
intentan ofrecer soluciones de diseño desde el punto de vista estructural de las
aplicaciones, y de las relaciones entre sus componentes, así como “Patrones de
Diseño” comunes en dichas arquitecturas, son algunos de los temas que más se
está estudiando hoy en día a alto nivel en la Ingeniería Basada en Componentes,
junto con los mencionados al principio como aspectos de calidad y marketing de
componentes, y las diversas tecnologías de implementación 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, todavía le queda mucho camino por recorrer para
considerarse una Ingeniería como tal.
7
Sun Microsystems
8
Microsoft Corporation
2010 18 | P á g i n a

Referencias
 [Pressman, 2002] Ingeniería del Software, Un enfoque práctico, Roger S.
Pressman, 2002, 5ta Edición McGRAW-HILL
 [Somerville, 2005] Ingeniería del Software, Ian Somerville, 2005, 7ma
Edición Pearson Educación
 [Iribarne, 2003] Un Modelo de Mediación para el Desarrollo de Software
Basado en Componentes COTS, Luis F. Iribarne Martínez, Tesis Doctoral,
Universidad de Almería, España
 [Vallecillo, Troya, & Fuentes, 2001] Desarrollo de Software Basado en
Componentes, Lidia Fuentes, José M. Troya y Antonio Vallecillo, 2001,
Universidad de Málaga
 [Iribarne & Vallecillo] Elaboración 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

Metodología de desarrollo de software basada en componentes

Más contenido relacionado

La actualidad más candente

Similar a Metodología de desarrollo de software basada en componentes

Último

En este documento

Metodología de desarrollo de software basada en componentes