dsbc
TRANSCRIPT
-
7/22/2019 DSBC
1/12
Componentes de Software 1
INTRODUCCIN Y PRINCIPIOS BSICOS DEL DESARROLLO DESOFTWARE BASADO EN COMPONENTESMaribel Ariza Rojas, Juan Carlos Molina Garca
[email protected], [email protected]
Septiembre 30 de 2004
Abstract:
Component Based Software Development
(CBSD) has become important in the last
few years; its appearing as a solution for
complex developments and a new
methodology to join the best technologies
in one project. This article presents a
glimpse of CBSD, and its main
characteristics, followed by their
description. Classifying components is a
recent subject in CBSD, which considers
the process of analysis and design, that
has to be taken seriously in an appropriate
CBSD. Finally, it describes the most
relevant types of components
complemented by current technologies in
the field of CBSD.
Palabras Clave: Componentes de
Software, Desarrollo de Software basado
en componentes (DSBC), Framework,
Bussines Component
1. INTRODUCCIN
El desarrollo de software basado en
componentes (DSBC), es una tecnologaque ha empezado a demostrar que ofrece
ventajas en tiempo de desarrollo y
reduccin de costos en el proceso[1] dedesarrollo de software. La definicin de
Componente de Software, sus
caractersticas principales, la bsqueda deposibles mtodos para clasificar
componentes y la exposicin de las
herramientas estandarizadas que se
encuentran en el mercado representan losobjetivos que persigue este documento.
Este es entonces, una breve introduccin
acerca de lo que el lector encontrar en
este documento : La definicin deComponente de software, exponiendo sus
principales caractersticas y un modelo
que facilita su comprensin dentro delproceso de desarrollo de software. Luego
se expone una posible metodologa para la
clasificacin de componentes a travs de
atributos cuantificables y medibles.Finalmente exponemos dos de los
principales Componentes de software y las
tecnologas estandarizadas que hanayudado en gran medida a que el DSBC se
convierta en una buena y diferente opcin
para los desarrolladores de software.
2. COMPONENTES YCARACTERSTICAS DEDESCRIPCIN
2.1. ContextoEl concepto de componentes para eldesarrollo de software no es un concepto
nuevo; para muchos autores simplemente
es la evolucin del la metodologaorientada a objetos[2]. De hecho, muchas
de las caractersticas de los componentes
para el desarrollo parten de la idea deldiseo orientado a objetos. Pero la historia
del desarrollo de software basado en
componentes proviene an desde ms
-
7/22/2019 DSBC
2/12
Componentes de Software 2
atrs. Uno de los logros de la revolucin
industrial fue el desarrollo por
componentes, surgiendo a partir de lanecesidad de estandarizar los elementos de
los productos realizados en lnea, como los
automviles. [3]Los desarrollos tradicionales de
aplicaciones incurren en altos costos y en
una inversin de tiempo extensa. El iniciarun desarrollo de software desde cero es un
reto muy grande, incluso para una empresaque pueda soportar este proceso. Esto
sesgara el desarrollo de software a las
grandes empresas, y no le dara cabida alas pequeas y medianas empresas que
desean adquirir tecnologas o construir sus
propias soluciones. Las empresaspequeas han estado siempre al margen
del desarrollo de software; solo hasta la
dcada pasada se les permiti la
introduccin a este campo. Estaintroduccin se origin ante la demanda de
estas por buscar sus propios productos
para dejar de depender de aquellos que lasgrandes empresas ponan en el mercado.
Por otra parte, las empresas buscaban la
reduccin de costos en la tecnologa(Hardware, Software e Infraestructura de
Comunicacin).
El DSBC busca, dentro de otros objetivos,
reducir el tiempo de trabajo, el esfuerzoque requiere implementar una aplicacin y
los costos del proyecto, y, de esta forma,
incrementar el nivel de productividad delos grupos desarrolladores y minimizar los
riesgos globales sin incurrir en gastos
exorbitantes. De esta manera, las pequeasempresas pueden tener una mayor
confiabilidad a la hora de realizar una
inversin tecnolgica. Otra ventaja espoder integrar lo mejor de las tecnologas
para desarrollar una aplicacin de manera
personalizada, a la medida de las
necesidades de los clientes. Esto permite a
los desarrolladores y a la empresa adquirirlas tecnologas que ms se adapten a sus
necesidades, y no incurrir en gastos de
licenciamiento o soporte y actualizacin
de las grandes soluciones, ya que muchasde estas tecnologas son gratis y existen
bajo la premisa de Freeware y GNU
(General Public License)1, lo cual aade
otra gran ventaja.
Otro punto a tomar en cuenta es que elDSBC, pertenece al paradigma de
programacin de sistemas abiertos, los
cuales son extensibles y tienen unainteraccin con componentes
heterogneos que ingresan o abandonan el
sistema de forma dinmica, es decir quelos componentes pueden ser remplazados,
por otros independientemente de su
arquitectura y desarrollo [4]. De esta
manera se puede hacer un paralelo entre elmundo percibido por el hombre y el
DSBC desde un punto de vista menos
formal y con una perspectiva del mundocotidiano donde se tienen sistemas
abiertos y cerrados. Por ejemplo, el ser
humano es un sistema abierto y realizainteracciones con el medio (otro sistema),
la mayora de los sistemas en el mundo
percibido por el hombre son abiertos y
necesitan una interaccin con el mediopara poder sobrevivir como en el caso del
hombre (alimentos, aire, relaciones, etc).
Esta interaccin es la que permite quecrezca el sistema (extensin), dndole la
posibilidad de mejorar con el tiempo y
lograr una estabilidad (evolucin para elcaso del hombre).
1www.osmosislatina.com/diversos/open_source.ht
ml
-
7/22/2019 DSBC
3/12
-
7/22/2019 DSBC
4/12
Bien Documentado: Un componentedebe estar correctamente documentado
para facilitar su bsqueda si se quiereactualizar, integrar con otros,
adaptarlo, etc.
Es genrico: Sus servicios debe servirpara varias aplicaciones. Reutilizado dinmicamente: Puede
ser cargado en tiempo de ejecucin enuna aplicacin.
Independiente de la plataforma:Hardware, Software, S.O.[9]
Existen ya varios modelos que permitenentender los componentes de software,
para poder encontrar los componentes que
determinada aplicacin necesita. Uno deestos modelos desarrollado por Anneliese
Andrews y Sudipto Ghosh , en Colorado
State University [10] planta la posibilidad
de entender un componente por medio detres perspectivas, estas son:
El Dominio : Representa en trminosgenerales todos los aspectos del
problema del usuario relacionado deforma directa con la funcionalidad que
apoya el componente.
Programa :Este enfoque es el que msvaria de componente a componente, yaque muestra en forma ms detallada la
informacin tcnica del componente
como la estructura de los archivos deinformacin, definiciones de las bases
de datos, la definicin de la Interface
de datos, los tipos de parmetros,
informacin acerca de la invocacin delos mtodos del componente, etc.
Situacin: En este punto Elconocimiento del diseo ycomportamiento de las entidadesnecesita ser especificado[10], la
informacin que se determina en este
punto es til para igualar los
requerimientos con las capacidadesfuncionales y no funcionales del
componente; aqu se deben determinar
aspectos como: Estructura de la
arquitectura fsica y conceptual,flujos de Informacin que el
componente transfiere, usa y
transforma y tipos de algoritmos.
Ya fueron presentados los trminos: ladefinicin de componente, sus
caractersticas y las variables por la cuales
puede ser comprendido un componente.Ahora bien, Cmo se integran los
componentes dentro del ciclo de vida de
desarrollo de software basado encomponentes?. La siguiente figura ilustra
el ciclo de vida del software basado en
componentes desde una perspectiva
global[11] :
Grfico 1 :Modelo del Ciclo de vida de DSBC
Componentes de Software 4
-
7/22/2019 DSBC
5/12
Componentes de Software 5
A continuacin mostramos una breve
descripcin de cada una de las actividades
que involucra el modelo del ciclo de vidapara DSBC :
Anlisis de Requerimientos: En estaetapa del ciclo de vida los procesos ylas necesidades del negocio se
descubren y se expresan en los casos
de uso.
Seleccin, construccin, anlisis yevaluacin de la Arquitectura deSoftware : La arquitectura delsoftware define un sistema en trminosde componentes computacionales y la
interaccin entre ellos[11]. Estas
tareas podrn ser realizadas con xitosi se exponen las propiedades externas
de los componentes que harn parte de
la aplicacin y las relaciones entreellos.
Identificacin y arreglo pararequisitos particulares delComponente : En esta actividad, loscomponentes deben ser seleccionados
por los requerimientos funcionales y
de calidad que satisfaga cada
componente. Luego de haber sidoidentificados los componentes que
sern integrados al sistema, se debe
evaluar si el componente necesita sersujeto a alguna modificacin.
Integracin del Sistema : En estaactividad se debe examinar, evaluar y
determinar como va a ser lacomunicacin y la coordinacin entre
los componentes que harn parte del
sistema. Luego debe ensamblarse el
sistema y proseguir con una serie depruebas que determinarn si los
componentes seleccionados son losadecuados.
Pruebas : Posterior a la integracinde los componentes se debe proceder
con las pruebas, esto implica evaluar elfuncionamiento de los componentes
que fueron integrados en el sistema, si
algn componente demuestra no estarfuncionando de forma correcta se debe
pensar en la posibilidad de
reemplazarlo o modificarlo para luego
proceder con la re integracin.
Mantenimiento : En el perodo delmantenimiento, se lleva a cabo un
proceso similar al desarrollado en la
POO, esto es vigilar el correctofuncionamiento del sistema, corregir
fallas en el comportamiento, etc.
3. CLASIFICACIN DECOMPONENTES
3.1. CMO CLASIFICARCOMPONENTES? :
La clasificacin de componentes es un
proceso extenso, ya que un componente
involucra en s mismo varios atributos
relevantes. En este segmento se expone
una serie de variables que podranconsiderarse criterios de clasificacin de
componentes:
3.2. Tamao
El tamao de los componentes puede ser
medido por medio de las mtricas
utilizadas en diseo orientado a objetos.
Esto significa que la medicin del tamaode un componente puede ser medido a
travs de:
Lneas de Cdigo (LDC)
Orientadas a Funcin
-
7/22/2019 DSBC
6/12
Componentes de Software 6
Si un componente resulta ser demasiado
grande en tamao, el proceso de
aseguramiento de calidad del mismo serms complicado y exigente para el
desarrollador.[11]
3.2.1. Complejidad :
En algunas ocasiones, son utilizadasmtricas de tamao para evaluar la
complejidad, pero es recomendable haceruso de otro tipo de mtricas. Si un
componente es demasiado trivial no podr
sacrsele mayor provecho en sureutilizacin, y si el componente es
demasiado complejo ser difcil asegurar
su calidad[11].
3.2.1.1. Mtricas de Complejidad
Las mtricas ms utilizadas para medir lacomplejidad de los componentes, combina
uno de los mtodos ms reconocidos para
medir la complejidad de mtodos oalgoritmos desarrollado por Tomas
McCabe, Complejidad Ciclomtica,
este mtodo mide el nmero de decisioneslgicas en un segmento de cdigo. A
continuacin nombramos cuatro diferentes
tcnicas para medir la complejidad de un
componente:
CPC (Component Plain Complexity):Mide la complejidad del componente
por medio de la suma de clases, clasesabstractas e interfaces, la complejidad
de clases y mtodos.
CSC (Component Static Complexity):
Se centra en la estructura interna del
componente por medio de una visinesttica del mismo, utilizando
variables como la relacin entre las
clases y el peso e cada relacin.
CDC (Component Dynamic
Complexity): Se centra en el nmerode mensajes que pasan dentro del
componente por medio de una visin
dinmica, evaluando variables como lafrecuencia en el intercambio de
mensajes entre clases y la complejidad
de los mensajes.
CCC (Component CyclomaticComplexity): Esta medida de
complejidad es utilizada cuando el
componente ya ha sido finalizado.
Utiliza como variables el cdigodesarrollado, la suma de las clases,
interfaces, mtodos definidos en cada
una de las interfaces.
A diferencia del mtodo CCC, los
mtodos anteriores CPC, CSC, CDCutilizan para sus clculos los diagramas de
clase, la interaccin de los diagramas y el
diagrama de componentes.
3.2.1.2. Mantenibilidad
La mantenibilidad de un sistema es la
facilidad con la cual puede ser modificadofrente a cambios en
el ambiente, requerimientos funcionales oespecificaciones funcionales[12]. Para
los componentes de software esta es una
caracterstica de vital importancia, ya quesu propia naturaleza los obliga a tener la
capacidad de adaptarse a diferentes
entornos.
Generalmente, las mtricas que se utilizanpara medir la mantenibilidad utilizan
variables que miden los atributos, el
comportamiento y el flujo de trabajo,entre otros.
3.2.1.3. Reusabilidad
-
7/22/2019 DSBC
7/12
Componentes de Software 7
La reusabilidad de un componente se
puede medir a partir de dos diferentesperspectivas, estas son [13]:
Cmo puede un componente serreutilizado: Este tipo de medida tiene
en cuenta las siguientes variables: El
nmero de cada mtodo de interface
que puede proveer funciones en comnentre varias aplicaciones en un
dominio, el nmero de mtodos
declarados en la interface quepertenecen al componente.
Cmo es re - usado un componente enuna aplicacin particular: Las variables
que se miden para este objetivo enparticular son: Las lneas de cdigo re
- utilizadas por el componente en una
aplicacin, el total de lneas entregadosen la aplicacin. La combinacin de
estas dos variables resulta el
porcentaje de funcionalidad que aportael componente dentro de toda la
aplicacin
3.2.2. Frecuencia de re uso
El nmero de veces que ha sido utilizado
un componente dentro de distintasaplicaciones, es sin lugar a dudas el mejor
indicador de frecuencia de re uso. Cabe
anotar que este atributo puede ser solomedido en componentes que ya han sido
expuestos al mercado.
3.2.3. Confiabilidad
Es la probabilidad de fall en el
funcionamiento del componente dentro decierto escenario operacional.
3.2.4. CMO EVALUAR LACALIDAD DE UN COMPONENTE?
La calidad dentro de la Ingeniera de
Sistemas se define como la totalidad de
aspectos y caractersticas de un producto oservicio que tiene que ver con su habilidad
de satisfacer las necesidades declaradas o
implcitas[14]. La calidad de loscomponentes de software puede ser el
factor decisivo para la seleccin de loscomponentes que entrarn a ser parte de
un nuevo sistema, es decir, si dos
componentes son candidatos para hacerparte de una aplicacin y muestran la
misma funcionalidad, el nivel de calidad
que implemente cada uno de ellos ser elelemento sobre el cul se base la decisin
final. Algunos de los elementos que
pueden dar al usuario una idea del nivel de
calidad de un componente son [11]:
Funcionalidad
Interface
Usabilidad
Pruebas
Seguridad
3.3. TIPOS DE COMPONENTES
3.3.1. Framework:
Los frameworks de componentes
proporcionan servicios que soportan unmodelo de componentes [15]. Estos
modelos de componentes son patrones que
permiten interactuar entres si de acuerdo al
problema que resuelven y permiten laextensibilidad del framework y su
funcionalidad, estos son aplicados adominios especficos, lo cual hace que elframework tambin lo sea, se dice que un
framework es una aplicacin incompleta y
-
7/22/2019 DSBC
8/12
Componentes de Software 8
genrica, sobre la cual las aplicaciones que
se implementan (las que soporta) son las
que le dan el estado final definiendo unafuncionalidad especifica y propia.
Las principales ventajas que ofrecen los
frameworks son la reduccin del costo enel proceso de desarrollo de aplicaciones
software para dominios especficos, y la
mejora de la calidad del producto final.[4]. Existen tres tipos de Frameworks, los
Frameworks de caja blanca exigen alusuario un conocimiento muy profundo de
su estructura interna y pueden llevar
aparejados los problemas que acarrea laherencia, como pueden ser las anomalas
de la herencia[16]. Por otro lado, los
Frameworks de caja negra enfrentanproblemas de la programacin orientada a
componentes, como son la composicin
tarda [1] o la clarividencia (previsin de
los posibles usos futuros del Framework).Esto significa que cualquiera de los dos
necesita de un entendimiento tcnico del
framework sobre el cual se quiere trabajary una previa evaluacin de sus
caractersticas principales y su
descripcin. La eleccin de un frameworkes un proceso de ingeniera de software y
de este depende el producto final que se
quiera desarrollar. La mala eleccin de
ste conllevar a un desarrollo complejo yfuera del domino. Es necesario integrar los
conceptos de DSBC y la ingeniera de
dominio para llegar a un desarrollosatisfactorio [17].
Utilizar un Framework no es una tarea que
se debe tomar a la ligera, es necesario lautilizacin y condensacin de
conocimientos para que este pueda ser
utilizado como un componente. No esnecesario conocer todos los tipos de
Frameworks existentes, pero s es
necesario saber como stos ofrecen sus
servicios. La arquitectura de los
Frameworks se basa en el uso de patronesde software, los cuales simplifican su
construccin y permiten su extensin [18],
los patrones no solo se convierten en los
constructores del framework sino queconstituyen la manera de interactuar con
este. La manera ms comn de desarrollar
una aplicacin sobre un framework es atravs de los patrones, los cuales por
medio de sus interfaces nos permiteninteractuar con el y adaptarlo a la
aplicacin.
3.3.2. Bussines ComponentLos componentes de negocio, son aquellos
componentes especializados en prestaralguna clase de servicio, enfocado a un
dominio en particular [19]. Los
componentes de negocio son aquellos
componentes que generan el valoragregado y se enfocan a las necesidades de
los clientes. Un componente de negocio es
aquel que realiza o provee al cliente de lafuncionalidad necesaria en su aplicacin
para resolver sus necesidades y cumplir
con sus requerimientos.Este tipo de componentes se sitan por lo
general en el ltimo escalafn dentro del
desarrollo basado en componentes, ya que
estos son los que darn la funcionalidadpropia del negocio a la aplicacin, estos
componentes estn soportados por lo
general bajo un framework en particular,el cual permite que el componente de
negocio se desempee y cumpla con su
objetivo, lo cual implica que adems de lascaractersticas propias de un componente
de software, tenga tambin las
caractersticas adicionales del frameworksobre el cual est soportado. Un
componente de negocio no le da
particularidad a una aplicacin, ni realiza
-
7/22/2019 DSBC
9/12
Componentes de Software 9
por s solo la funcionalidad de una
aplicacin; es la integracin entre el
framework y por lo general varioscomponentes de negocio, los que le dan la
particularidad de todo un desarrollo. Los
componentes de negocio permiteninteractuar con otros a travs de protocolos
ya estandarizados inherentes al framework
sobre el cual estn soportados, como porejemplo J2EE [18].
Los componentes de negocio necesitan deun nivel de especificacin mas all de el
establecido por el framework o los
patrones. Los niveles de especificacin delos componentes de negocio resulta til,
ya que cada nivel se enfoca a un aspecto
de la especificacin del negocio ydirecciona diferentes roles en el desarrollo
como desarrollador de componentes,
documetador, jefe de proyecto, etc. Esto
ayuda en la bsqueda del componentenecesario que se adapte al dominio y
prevea la funcionalidad que se busca,
desde diferentes niveles de conocimientos.Existen siete distintos niveles, cada uno
con un aspecto en especfico direccionado
al negocio:
Nivel de Marketing: Caractersticas de laorganizacin y el negocio, condiciones
tcnicas.Nivel de tarea: Ayuda a las tareas delnegocio que corresponden al dominio de la
aplicacin. Propsito de la aplicacin.Nivel de terminologa: Definicin deconceptos del dominio de la aplicacin.Nivel de Calidad: Criterios de calidad,procedimientos y categoras de medidas,
niveles de servicio.
Nivel de interaccin: Secuencias dedependencias a travs de servicios del
mismo componente de negocio y de
diferentes componentes de negocio.
Nivel de Comportamiento: Pre yposcondicin, invariantes.Nivel de Interfaces: Servicios,parmetros, tipos de datos y excepciones.
[19]
Por medio de estos niveles la bsqueda de
un componente de negocio resulta ms
rpida y fcil, acelerando el proceso deDSBC.
3.4.TECNOLOGAS DECOMPONENTESESTANDARIZADAS :
Los componentes son unidades bien
definidas, que adquirieron suscaractersticas principales de sus orgenes
en el desarrollo de software de la POO y el
UML. Aunque la infraestructura
tecnolgica del DSBC se ha desarrollado,son pocas las tecnologas y productores de
software que se han estandarizado [20].
Estas tecnologas han enriquecido elDSBC y, de hecho, hacen posible que
nazca el concepto. Aunque la
investigacin en el rea del DSBC esrelativamente nueva, existen da a da
investigaciones que tratan de unificar
criterios y estandarizar las tecnologas, que
permitan unificar criterios y madurar elDSBC. Una de las principales
organizaciones y pionera desde hace
mucho tiempo en el tema de componenteses la ORGANIZACIN OMG,(ObjectManagement Group) esta es una
organizacin que agrupa a ms de 400empresas entre vendedoras de software y
compaas relacionadas con la tecnologa
de objetos. Su bandera es la especificacinmultiplataforma MDA, y basada en
modelos de especificacin como MOF
,UML , XML y CWM, esta cuenta con su
-
7/22/2019 DSBC
10/12
Componentes de Software 10
propia plataforma middleware CORBA.
[21]. Su importancia radica en ser una
organizacin sin nimo de lucro que buscala unificacin de criterios que ayuden al
DSBC. Esta se constituye como un
organismo centralizado que ayuda alarbitramiento de ideas en este tema.
3.4.1. CORBAEs un estndar abierto para la aplicacin
de la interoperabilidad y est respaldadapor la OMG. CORBA maneja al detalle la
interoperabilidad entre componentes y
permite la comunicacin entreaplicaciones independientemente de su
ubicacin y diseo. CORBA es bien
utilizada en el desarrollo de aplicacionesdistribuidas y en el DSBC, ya que ofrece
una programacin consistentemente
distribuida y un ambiente en tiempo de
ejecucin para muchos lenguajes deprogramacin, sistemas operativos y redes
distribuidas [11]. CORBA es aceptado casi
como un estndar por los vendedores detecnologa y no como una plataforma
independiente.
3.4.2. DCOMDistributed COM es la extensin para
ambientes distribuidos de COM
(Component Object Model) , el cualprovee de un protocolo de comunicacin
con el cual componentes distribuidos
pueden interactuar y comunicarseindependientemente de su ubicacin[11].
El aporte de DCOM a las tecnologas
Microsoft se ve en su ms recienteproducto MS.NET.
3.4.3. Enterprise Java Beans
Modelo de componentes basado en
arquitectura cliente servidor. Esta
plataforma ofrece una solucin
multiplataforma, de fcil reutilizacin,integracin universal con otros
componentes adems de la maquina
virtual de java, seguridad transaccional,
entre otras. Estas caractersticas la hanhecho reconocida en el mundo de los
programadores y del DSBC[11]. La
tecnologa java a estado a la vanguardiadel DSBC y constituye una referencia
clave en este tema.
3.4.4. The Microsoft .NET Framework:
Esta es una nueva plataforma para
construir e integrar, servicios orientados a
la aplicacin. Este framework es lasolucin para aplicaciones que operan bajo
un ambiente Windows simplificando el
lenguaje de desarrollo y accediendo en
tiempo de ejecucin a las funcionalidadesdel framework. [22]. La infraestructura
Microsoft es una de las mas reconocidas
en el mundo y MS.NET constituye unaoportunidad de nuevas soluciones a partir
de DSBC.
4. RESULTADOS
El DSBC es, sin lugar a dudas, una
excelente opcin para quienes deseanminimizar los riesgos y maximizar los
beneficios en el proceso de desarrollo de
software. Pero para poder hacer realidad laimplementacin a gran escala de este tipo
de desarrollo es importante empezar a
definir de forma clara y concreta todos losconceptos que hacen parte del DSBC. Este
es uno de los resultados que logra este
documento, el definir de forma clara yprecisa qu es y qu define a un
componente de software, por otro lado
involucramos el componente de forma real
-
7/22/2019 DSBC
11/12
Componentes de Software 11
en el modelo de ciclo de vida del software
y se puede evidenciar que no difiere en
gran medida del modelo que implementala POO, por el contrario, muchas de las
actividades incluidas en este ltimo se
incluyen con una funcionalidad similar enel modelo del DSBC.
Otro importante resultado, es larealizacin de una primera aproximacin a
una metodologa de clasificacin decomponentes de software , donde se
involucrarn los diferentes tipos de
componentes que desarrollan lastecnologas estandarizadas mencionadas
tambin en el documento.
5. CONCLUSIONES:
El DSBC es una metodologa que no
se puede tomar mas como una
metodologa de desarrollo nueva, porel contrario se trata de una idea que
esta evolucionando de sus inicios para
tomar mas fuerza en el mundo de laingeniera de software, existen ya
grandes ideas, conceptos y un mundo
de analistas, diseadores que desean
hacerla realidad y lo estn haciendo.
El DSBC es una metodologa que no
se puede tomar mas como unametodologa de desarrollo nueva, por
el contrario se trata de una idea que
esta evolucionando de sus inicios paratomar mas fuerza en el mundo de la
ingeniera de software, existen ya
grandes ideas, conceptos y un mundode analistas, diseadores que desean
hacerla realidad y lo estn haciendo.
Los proveedores de tecnologas que
utilizan y proporcionan soporte alDSBC son pocas, sin embargo ya
existe un mundo de desarrollo a partir
de estas, ya que es definitivo que la
evolucin de la POO es el DSBC, yson estos mismos proveedores aquellos
que definitivamente ya maduraron el
paradigma de POO. Su siguiente etapaen la evolucin del desarrollo de
software es DSBC y sus tecnologasproveen de todos los servicios y
funcionalidades para que esto ocurra.
Con base en todo lo expuesto surge la
necesidad no slo de encontrar un lenguaje
comn referente al tema de DSBC entredesarrolladores y los usuario finales, sino
tambin la necesidad de buscar mtodos
que permitan el acercamiento y faciliten la
utilizacin de los Componentes deSoftware a cualquier tipo de usuario que
desee integrarlos a los desarrollos de
software.
6. REFERENCIAS :[1] Clemens Szyperski. ComponentSoftware Beyond Object Oriented
Programming. P 15 -20. 1998.
[2]Lidia Fuentes, Jos M. Troya, AntonioVallecillo. Desarrollo de SoftwareBasado en Componentes, p 2-3. 2003.
[3] Rafael Gonzlez . Ontologa desoftware para PyMEs, p 3 2004.[4]Lidia Fuentes, Jos M. Troya, AntonioVallecillo Desarrollo de Software Basado
en Componentes, p 3-4. 2003.[5]Philippe Krutchen. Rational Software[6]Gartner Group.[7]Clemens Szyperski, ComponentSoftware Component Software Beyond
Object Oriented Programming. P 20 -
22. 1998.
-
7/22/2019 DSBC
12/12
Componentes de Software 12
[8] Wojtek Kozaczynski, SSA, Alan W.Brown, Kurt C. Wallnau The Current
State of CBSE.1998.[9] Jons A. Montilva C., Nelson Arap yJuan Andrs Colmenares. Desarrollo
Basado en Componentes, p 3.2003[10]Anneliese Andrews, SudiptoGhosh, A model for Understandig
Software Componets, p.5. 2002[11]Cai Xia, Lyu Michael R., Wong Kam Fai, Component bases softwareEngineering: Technologies, Development
Frameworks ans quality assurance
schemes. p. 374-375[12]PerOlof Bengtsson, Nico Lassing, JanBosch and Hans van Vliet, Analyzing
Software Architectures for Modifiability
[13]Kim Min Sun, Kim Soo Dong. Component metrics to measure component
quality. P.421-422.[14]Bertoa Manuel F. , Troya Jose M. ,Vallecillo Antonio. Aspectos de Calidad
en el Desarrollo de Software Basado en
Componentes. p 5[15]Jons A. Montilva C., Nelson Arap yJuan Andrs Colmenares. Desarrollo
Basado en Componentes, p 4.2003.[16]Matsuoka y Yonezawa. Analysis ofInheritance Anomaly in Object-Oriented
Concurrent Programming Languages, p
107-150.1993.[17] Roger Presuman. Ingeniera deSoftware un enfoque practico, p 474-481.
1997.[18] Desmond Francis DSouza, AlanCameron Wills. Objects components and
Frmaworks The Catalysis Aproach p38.-386.1998.
[19] Peter Ferrke y Peter Loos.Specification of Business Components .
Objects,Components, Architectures,Services and Aplications for a Networked
World. , p 2-8. 2002.
[20] Alan W. Brown, Kurt C. WallnauThe Current State of CBSE.1998 .[21] OMG About the ObjectManagement Group.2004.
[22] Jeffrey Richter. Microsoft .NET
Framework Delivers the Platform for anIntegrated,Service 2002.
7. AUTORES
Maribel Ariza Rojas y Juan Carlos MolinaGarca son estudiantes de pregrado de la
facultad de Ingeniera de Sistemas en la
Pontificia Universidad Javeriana. En estemomento se encuentran desarrollando un
proyecto de Investigacin que lleva como
ttulo : Jerarqua y Granularidad deComponentes de Software para PyMEs en
Bogot dirigida por Ing. Rafael Gonzles
Rivera.