SlideShare uma empresa Scribd logo
1 de 14
Para el software personalizado, la ingeniería de software basada en componentes es
una forma efectiva orientada a la reutilización para desarrollar nuevos sistemas
empresariales.
La CBSE surgió a finales de la década de 1990 como un enfoque al desarrollo de
sistemas de software basado en la reutilización de componentes de software. Su
creación fue motivada por la frustración de los diseñadores al percatarse de que
el desarrollo orientado a objetos no conducía a una reutilización extensa como
se había sugerido originalmente.
La CBSE es el proceso de definir, implementar e integrar o componer los
componentes independientes e imprecisos en los sistemas.
Los fundamentos de la ingeniería de software basada en componentes son:
1. Componentes independientes que se especifican por completo mediante sus
interfaces.
2. Estándares de componentes que facilitan la integración de estos.
3. Middleware que brinda soporte de software para integración de componentes.
4. Un proceso de desarrollo que se engrana con la ingeniería de software basada
en componentes.
En la base de CBSE existen firmes principios de diseño que apoyan la
construcción de software comprensible y mantenible:
 Los componentes so n independientes, de manera que sus ejecuciones no
interfieren entre si. Se ocultan los detalles de la implementación.
 Los componentes se comunican a través de interfaces bien definidas.
 Las infraestructuras de componentes ofrecen varios servicios estándar que
pueden usarse en sistemas de aplicación.
La motivación inicial para la CBSE fue la necesidad de brindar apoyo tanto a la
ingeniería de software de reutilización como a la distribuida.
En la comunidad CBSE existen un acuerdo general de que un componentes es una
unidad de software independiente que puede organizarse con otros
componentes para ser un sistema de software. Los componentes son
independientes, y los consideran la unidad fundamental de composición en un
sistema.
Características del componente:
 Estandarizado: estandarización de componentes significan que un
componente utilizado durante un proceso CBSE debe ajustarse a un
modelo de componentes estándar.
 Independiente: debe ser factible componerlo e implementarlo sin usar
otros componentes específicos.
 Componible: todas las interacciones externas deben tener lugar
mediante interfaces definidas públicamente.
 Implementarle: un componente debe estar auto contenido.
 Documentado: los componentes deben implementarse por completo,
para que los usuarios potenciales puedan decidir si los componentes
cumplen o no sus necesidades.
Visualizar un componente como un proveedor de servicios pone de relieve
dos características criticas de un componente de reutilización:
1) El componente es una entidad ejecutable independiente definida
mediante sus interfaces.
2) Los servicios ofrecidos por un componentes se ponen a disposición
mediante una interfaz, y todas las interacciones por dicha interfaz.
Los componentes tienen dos interfaces relacionadas. Dichas interfaces reflejan los
servicios que proveen los componentes y los servicios que el componente
requiere para ejecutarse correctamente:
 La interfaz “proporciona” define los servicios que ofrece el componente.
 La interfaz “requiere” especifica que servicio deben ofrecer otros
componentes en el sistema para que un componente opere correctamente.
Un modelo de componentes es una definición de estándares para implementación,
documentación, y despliegue de componentes. Los modelos de componentes
mas importantes son el modelo WebServices, el modelo Enterprise Java Beans
(EJB) de Sun, y el modelo .NET de Microsoft.
Los elementos de un modelo de componentes definen los interfaces de
componentes, que los elementos de un modelo de componentes definen las
interfaces de componentes, la información que necesita usar el componentes
en un programa como deben implementarse un componentes:
 Interfaces: los componentes se definen al especificar sus interfaces.
 Uso: para que los componentes se distribuyan y se acceda a ellos de manera
remota deben tener un nombre único asociado.
 Implementación: el modelo de componentes incluye una especificación de cómo
deben empacarse los componentes para su implementación como entidades
ejecutables independientes.
Los servicios brindados por una implementación de modelo de componentes se
dividen en dos categorías:
1. Servicios de plataformas: los cuales permiten a los componentes comunicarse e
inter operar en un entorno distribuido.
2. Servicios de apoyo: que son servicio comunes que probablemente requieren
muchos componentes diversos.
El Middleware implementa los servicios de componentes y ofrece interfaces a dichos
servicios.
Los procesos CBSE son procesos de software que brindan soporte a la ingeniería
de software basada en componentes. Toman en cuenta los posibilidades de
reutilización y las diferentes actividades de proceso implicadas en el desarrollo
y uso de componentes reutilizables.
Al nivel mas alto, existen dos tipos de proceso CBSE:
Desarrollo para reutilización: este proceso se ocupa del desarrollo de
componentes o servicios que se reutilizaran en otras aplicaciones.
Desarrollo con reutilización: este es el proceso para desarrollar nuevas
aplicaciones usando los componentes y servicios existentes.
En el proceso de desarrollo para reutilización, el objetivo es producir uno o mas
componentes reutilizables. En el desarrollo con reutilización, no sabe cuales
componentes están disponibles, así que necesitan descubrir dichos
componentes y diseñar un sistema para utilizarlos de la manera mas efectiva.
Los procesos básicos de CBSE con y para reutilización tienen procesos de soporte
que se ocupan de la adquisición, gestión y certificación de componentes:
 Adquisición de componentes es el proceso de adquirir componentes para
reutilización o desarrollo en un componente reutilizable.
 La gestión de componentes se ocupa de la gestión de los componentes de
reutilización de una compañía, asegurándose de que están adecuadamente
catalogados, almacenados y dispuestos para reutilizarse.
 Certificación de componentes es el proceso de comprobar un componente y
asegurase de que cumple su especificación.
La CBSE para reutilización es el proceso de desarrollar componentes reutilizables
y ponerlos a disposición para reutilizarlos a través de un sistema de gestión de
componentes.
Para elaborar componentes de reutilización, deben adaptarse y extenderse
componentes específicos de aplicación para crear versiones mas genéricas y,
por lo tanto, mas reutilizables.
Los cambios que se pueden hacer a un componentes para volverlo mas reutilizable
incluyen:
 Eliminar métodos específicos de aplicación.
 Cambiar los nombres para hacerlos mas generales.
 Agregar métodos para brindar cobertura funcional mas completa.
 Hacer manejadores de excepción consistentes para todos los métodos.
 Adicionar una interfaz de “configuración” para permitir la adaptación de los
componentes a diferentes situaciones de uso.
 Integrar los componentes requeridos para aumentar la independencia.
El problema del manejo de excepción es particularmente difícil. Los componentes
no deben manejar las excepciones por si mismos, porque cada aplicación
tendrá sus propios requerimientos para manejo de excepción.
Sin embargo, en la practica, existen dos problemas con esto:
1. Publicar todas las excepciones conduce a interfaces infladas que son difíciles
de entender.
2. La ejecución del componente puede depender del manejo de excepciones
locales, y cambiar estos tal vez tengan serias implicaciones para las
funcionalidad del componente
Si un componente es susceptible de reutilización, o no, depende de su dominio
de aplicación y su funcionalidad. Para hacer reutilizable un componente,
usted deberá proporcionar un conjunto de interfaces genéricas con
operaciones que incluyan todas las formas que el componente podría usar.
La certificación significa que alguien aparte del desarrollador, verifica la calidad
del componente. Se prueba el componente y se certifica que alcanza un
estándar de calidad aceptable, antes de ponerlo a disposición para su
reutilización.
La reutilización exitosa de componentes requiere un proceso de desarrollo
ajustado a CBSE. La CBSE con un proceso de reutilización debe incluir
actividades que encuentren e integren componentes reutilizables. Algunas
de las actividades dentro de este proceso, como el descubrimiento inicial de
los requerimientos de usuario , se realizan en la misma forma que en otros
procesos de software. Sin embargo, las diferencias esenciales entre CBSE
con reutilización y procesos de software para desarrollo de software
original son:
 Los requerimientos del usuario inicialmente se desarrollan en bosquejos y
no en detalles , y se alienta a las partes interesadas a ser tan flexibles como
sea posible para definir su requerimientos.
 Los requerimientos se afinan y modifican oportunamente durante el proceso,
dependiendo de los componentes disponibles.
 Después de diseñar la arquitectura del sistema, hay una actividad adicional de
búsqueda de componentes y clarificación del diseño.
 El desarrollo es un proceso de composición en que se integran los
componentes descubiertos.
La etapa de diseño arquitectónico es particularmente importante. Definir una
arquitectura robusta es crucial para tener éxito en reutilización.
Una actividad que es única para el proceso CBSE es identificar los componentes o
servicios candidatos para reutilización. Esto implica algunas actividades
especificas.
Inicialmente, el enfoque debe estar en la búsqueda y selección. En la ultima etapa
después de diseñada la arquitectura del sistema, debe de dedicarse a la
validación de componentes.
El primer paso en la identificación de los componentes es buscar aquellos que
estén disponibles localmente o con proveedores confiables.
Una vez que el proceso de búsqueda permite identificarlos posibles componentes,
se deben seleccionar componentes candidatos para su valoración.
Una vez seleccionados los componentes para su posible inclusión en un sistema
se deben validar para comprobar que se comportan como se espera.
La validación de componentes implica desarrollar un conjunto de casos de
pruebas para un componente (o, posiblemente, extender los casos de prueba
suministrado con dichos componentes) y desarrollar un conjunto de pruebas
para ejecutar pruebas de componentes.
Además de probar que un componente para reutilización logra lo que se requiere,
es posible que se tenga que verificar también que el componente no incluya
algunos códigos o una funcionalidad maliciosos e innecesarios.
El problema con la funcionalidad innecesaria es que puedan activarse por el
componente en si.
La composición de componentes es el proceso de integrar componente uno con
otro y con “código pegamento” especialmente escrito para crear un sistema u
otro componente.
El se describen las siguientes composiciones:
1. La composición secuencial: usted crea aun nuevo componente a partir de dos
componentes existente al llamare en secuencia a los componentes existentes.
2. La composición jerárquica: esto tipo de composición ocurre cuando un
componente llama directamente a los servicios que ofrece otro componentes.
3. La composición aditiva: esto ocurre cuando dos o mas componentes se juntan
(se suman) para crear un nuevo componente, lo que cambia su funcionalidad.
Cuando escriba nuevos componentes especialmente para composición, deberia
diseñar las interfaces de dichos componentes de manera que sean compatibles
con otro componente en el sistema.
Es posible que ocurran tres tipos de incompatibilidades:
 Incompatibilidad de parámetro: las operaciones de cada lado de la interfaz
tienen el mismo nombre pero sus tipos de parámetro o el numero de
parámetros son diferentes.
 Incompatibilidad: los nombres de las operaciones de la interfaces
“proporcionan” y “requiere” son diferentes.
 Operación incompleta: la interfaz “proporciona “de un componentes es un
subconjunto de la interfaz “requiere” de otro componente o viceversa.
En todos los caso el problema de la incompatibilidad se resuelve al escribir un
adaptador que reconcilie las interfaces de los dos componentes a reutilizar.

Mais conteúdo relacionado

Mais procurados

Cuadro comparativo Modelos de Software.
Cuadro comparativo Modelos de Software.Cuadro comparativo Modelos de Software.
Cuadro comparativo Modelos de Software.templarioo
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosFranklin Parrales Bravo
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de SoftwareCamila Arbelaez
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwaresergio
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareJennifer Andrea Cano Guevara
 
IEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de softwareIEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de softwareJesús Navarro
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareEvelinBermeo
 
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de softwareTm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de softwareJulio Pari
 
Indagación de los requerimientos
Indagación de los requerimientosIndagación de los requerimientos
Indagación de los requerimientosUCATEBA
 
Proceso del software
Proceso del softwareProceso del software
Proceso del softwareTensor
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de controlJuan Pablo Bustos Thames
 
Enfoque estructurado y Enfoque OO - Ingenieria de software
Enfoque estructurado y Enfoque OO  - Ingenieria de softwareEnfoque estructurado y Enfoque OO  - Ingenieria de software
Enfoque estructurado y Enfoque OO - Ingenieria de softwareKola Real
 
Atributos de calidad en el desarrollo de software
Atributos de calidad en el desarrollo de software Atributos de calidad en el desarrollo de software
Atributos de calidad en el desarrollo de software Joan Manuel Zabala
 

Mais procurados (20)

Cuadro comparativo Modelos de Software.
Cuadro comparativo Modelos de Software.Cuadro comparativo Modelos de Software.
Cuadro comparativo Modelos de Software.
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitos
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Diagrama de contexto
Diagrama de contextoDiagrama de contexto
Diagrama de contexto
 
cmmi-dev
cmmi-devcmmi-dev
cmmi-dev
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de software
 
Proceso de diseño
Proceso de diseñoProceso de diseño
Proceso de diseño
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
IEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de softwareIEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de software
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de Software
 
3. Análisis de Requerimientos
3. Análisis de Requerimientos3. Análisis de Requerimientos
3. Análisis de Requerimientos
 
Iso 25000
Iso 25000Iso 25000
Iso 25000
 
Modelo TSP
Modelo TSPModelo TSP
Modelo TSP
 
Tm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de softwareTm01 el modelado en el desarrollo de software
Tm01 el modelado en el desarrollo de software
 
Indagación de los requerimientos
Indagación de los requerimientosIndagación de los requerimientos
Indagación de los requerimientos
 
Proceso del software
Proceso del softwareProceso del software
Proceso del software
 
Diseño de sistemas
Diseño de sistemasDiseño de sistemas
Diseño de sistemas
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de control
 
Enfoque estructurado y Enfoque OO - Ingenieria de software
Enfoque estructurado y Enfoque OO  - Ingenieria de softwareEnfoque estructurado y Enfoque OO  - Ingenieria de software
Enfoque estructurado y Enfoque OO - Ingenieria de software
 
Atributos de calidad en el desarrollo de software
Atributos de calidad en el desarrollo de software Atributos de calidad en el desarrollo de software
Atributos de calidad en el desarrollo de software
 

Semelhante a Ingenieria de software basada en componentes -jeiner gonzalez blanco

Semelhante a Ingenieria de software basada en componentes -jeiner gonzalez blanco (20)

Componentes
ComponentesComponentes
Componentes
 
14704374 arquitectura-basada-en-componentes
14704374 arquitectura-basada-en-componentes14704374 arquitectura-basada-en-componentes
14704374 arquitectura-basada-en-componentes
 
Metodo watch
Metodo watchMetodo watch
Metodo watch
 
Proyecto
ProyectoProyecto
Proyecto
 
Proyecto
ProyectoProyecto
Proyecto
 
Proceso software
Proceso softwareProceso software
Proceso software
 
Metodología basada en componentes
Metodología basada en componentes Metodología basada en componentes
Metodología basada en componentes
 
Desarrollo de aplicaciones web en el entorno servidor
Desarrollo de aplicaciones web en el entorno servidorDesarrollo de aplicaciones web en el entorno servidor
Desarrollo de aplicaciones web en el entorno servidor
 
ing del software
 ing del software  ing del software
ing del software
 
Software basado en Componentes
Software basado en ComponentesSoftware basado en Componentes
Software basado en Componentes
 
Software basado en Componentes
Software basado en ComponentesSoftware basado en Componentes
Software basado en Componentes
 
Proceso del Software
Proceso del Software Proceso del Software
Proceso del Software
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicion
 
Modelos de procesos de software(completo)
Modelos de procesos de software(completo)Modelos de procesos de software(completo)
Modelos de procesos de software(completo)
 
Desarrollo de componentes
Desarrollo de componentesDesarrollo de componentes
Desarrollo de componentes
 
Desarrollo de componentes
Desarrollo de componentesDesarrollo de componentes
Desarrollo de componentes
 
Metodología de desarrollo de software basada en componentes
Metodología de desarrollo de software basada en componentesMetodología de desarrollo de software basada en componentes
Metodología de desarrollo de software basada en componentes
 
Trabajo de sistemas 2
Trabajo de sistemas 2Trabajo de sistemas 2
Trabajo de sistemas 2
 
Trabajo de sistemas 2
Trabajo de sistemas 2Trabajo de sistemas 2
Trabajo de sistemas 2
 
Reutilizacion de componentes en sistemas
Reutilizacion de componentes en sistemas Reutilizacion de componentes en sistemas
Reutilizacion de componentes en sistemas
 

Mais de Jeiner Gonzalez Blanco (20)

Mule investigation (jeiner gonzalez.b)
Mule investigation (jeiner gonzalez.b)Mule investigation (jeiner gonzalez.b)
Mule investigation (jeiner gonzalez.b)
 
Atm soft
Atm softAtm soft
Atm soft
 
Gestion mule
Gestion muleGestion mule
Gestion mule
 
Mule investigation (jeiner gonzalez.b)
Mule investigation (jeiner gonzalez.b)Mule investigation (jeiner gonzalez.b)
Mule investigation (jeiner gonzalez.b)
 
Mulesoft arboles
Mulesoft arbolesMulesoft arboles
Mulesoft arboles
 
Mule db
Mule dbMule db
Mule db
 
Trabajo de excel
Trabajo de excelTrabajo de excel
Trabajo de excel
 
NICOLÁS COPÉRNICO
NICOLÁS COPÉRNICONICOLÁS COPÉRNICO
NICOLÁS COPÉRNICO
 
Factores de riesgo
Factores de riesgoFactores de riesgo
Factores de riesgo
 
Extraclass work of english convesacional
Extraclass work of english convesacionalExtraclass work of english convesacional
Extraclass work of english convesacional
 
manejo de desechos solidos
manejo de desechos solidosmanejo de desechos solidos
manejo de desechos solidos
 
Virus y antivirus2
Virus y antivirus2Virus y antivirus2
Virus y antivirus2
 
LA REVOLUCION CIENTIFICA-TENCOLOGICO
LA REVOLUCION CIENTIFICA-TENCOLOGICOLA REVOLUCION CIENTIFICA-TENCOLOGICO
LA REVOLUCION CIENTIFICA-TENCOLOGICO
 
Concepto de identidad y sus manifestaciones en la cultura costarricense
Concepto de identidad y sus manifestaciones en la cultura costarricenseConcepto de identidad y sus manifestaciones en la cultura costarricense
Concepto de identidad y sus manifestaciones en la cultura costarricense
 
Riesgos fisicos powerpoint
Riesgos fisicos powerpointRiesgos fisicos powerpoint
Riesgos fisicos powerpoint
 
Riesgos de atrapamientos
Riesgos de atrapamientosRiesgos de atrapamientos
Riesgos de atrapamientos
 
Exposicion de fisica
Exposicion de fisicaExposicion de fisica
Exposicion de fisica
 
Arboles 2014 final
Arboles 2014 finalArboles 2014 final
Arboles 2014 final
 
Arboles binarios
Arboles binariosArboles binarios
Arboles binarios
 
Tda y heaps
Tda y heapsTda y heaps
Tda y heaps
 

Último

libro de ingeniería de petróleos y operaciones
libro de ingeniería de petróleos y operacioneslibro de ingeniería de petróleos y operaciones
libro de ingeniería de petróleos y operacionesRamon Bartolozzi
 
27311861-Cuencas-sedimentarias-en-Colombia.ppt
27311861-Cuencas-sedimentarias-en-Colombia.ppt27311861-Cuencas-sedimentarias-en-Colombia.ppt
27311861-Cuencas-sedimentarias-en-Colombia.pptjacnuevarisaralda22
 
NTC 3883 análisis sensorial. metodología. prueba duo-trio.pdf
NTC 3883 análisis sensorial. metodología. prueba duo-trio.pdfNTC 3883 análisis sensorial. metodología. prueba duo-trio.pdf
NTC 3883 análisis sensorial. metodología. prueba duo-trio.pdfELIZABETHCRUZVALENCI
 
PostgreSQL on Kubernetes Using GitOps and ArgoCD
PostgreSQL on Kubernetes Using GitOps and ArgoCDPostgreSQL on Kubernetes Using GitOps and ArgoCD
PostgreSQL on Kubernetes Using GitOps and ArgoCDEdith Puclla
 
Determinación de espacios en la instalación
Determinación de espacios en la instalaciónDeterminación de espacios en la instalación
Determinación de espacios en la instalaciónQualityAdviceService
 
semana-08-clase-transformadores-y-norma-eep.ppt
semana-08-clase-transformadores-y-norma-eep.pptsemana-08-clase-transformadores-y-norma-eep.ppt
semana-08-clase-transformadores-y-norma-eep.pptKelinnRiveraa
 
[1LLF] UNIDADES, MAGNITUDES FÍSICAS Y VECTORES.pdf
[1LLF] UNIDADES, MAGNITUDES FÍSICAS Y VECTORES.pdf[1LLF] UNIDADES, MAGNITUDES FÍSICAS Y VECTORES.pdf
[1LLF] UNIDADES, MAGNITUDES FÍSICAS Y VECTORES.pdfsmendozap1
 
Maquinaria Agricola utilizada en la produccion de Piña.pdf
Maquinaria Agricola utilizada en la produccion de Piña.pdfMaquinaria Agricola utilizada en la produccion de Piña.pdf
Maquinaria Agricola utilizada en la produccion de Piña.pdfdanielJAlejosC
 
APORTES A LA ARQUITECTURA DE WALTER GROPIUS Y FRANK LLOYD WRIGHT
APORTES A LA ARQUITECTURA DE WALTER GROPIUS Y FRANK LLOYD WRIGHTAPORTES A LA ARQUITECTURA DE WALTER GROPIUS Y FRANK LLOYD WRIGHT
APORTES A LA ARQUITECTURA DE WALTER GROPIUS Y FRANK LLOYD WRIGHTElisaLen4
 
EFICIENCIA ENERGETICA-ISO50001_INTEC_2.pptx
EFICIENCIA ENERGETICA-ISO50001_INTEC_2.pptxEFICIENCIA ENERGETICA-ISO50001_INTEC_2.pptx
EFICIENCIA ENERGETICA-ISO50001_INTEC_2.pptxfranklingerardoloma
 
Trazos paileros para realizar trazos, cortes y calculos.pptx
Trazos paileros para realizar trazos, cortes y calculos.pptxTrazos paileros para realizar trazos, cortes y calculos.pptx
Trazos paileros para realizar trazos, cortes y calculos.pptxmiguelmateos18
 
Minería convencional: datos importantes y conceptos
Minería convencional: datos importantes y conceptosMinería convencional: datos importantes y conceptos
Minería convencional: datos importantes y conceptosisauVillalva
 
Desigualdades e inecuaciones-convertido.pdf
Desigualdades e inecuaciones-convertido.pdfDesigualdades e inecuaciones-convertido.pdf
Desigualdades e inecuaciones-convertido.pdfRonaldLozano11
 
Introduction to Satellite Communication_esp_FINAL.ppt
Introduction to Satellite Communication_esp_FINAL.pptIntroduction to Satellite Communication_esp_FINAL.ppt
Introduction to Satellite Communication_esp_FINAL.pptReYMaStERHD
 
FUNCION DE ESTADO EN LA TERMODINAMICA.pdf
FUNCION DE ESTADO EN LA TERMODINAMICA.pdfFUNCION DE ESTADO EN LA TERMODINAMICA.pdf
FUNCION DE ESTADO EN LA TERMODINAMICA.pdfalfredoivan1
 
TIPOS DE SOPORTES - CLASIFICACION IG.pdf
TIPOS DE SOPORTES - CLASIFICACION IG.pdfTIPOS DE SOPORTES - CLASIFICACION IG.pdf
TIPOS DE SOPORTES - CLASIFICACION IG.pdfssuser202b79
 
Tippens fisica 7eDIAPOSITIVAS TIPENS Tippens_fisica_7e_diapositivas_33.ppt
Tippens fisica 7eDIAPOSITIVAS TIPENS Tippens_fisica_7e_diapositivas_33.pptTippens fisica 7eDIAPOSITIVAS TIPENS Tippens_fisica_7e_diapositivas_33.ppt
Tippens fisica 7eDIAPOSITIVAS TIPENS Tippens_fisica_7e_diapositivas_33.pptNombre Apellidos
 
Análisis_y_Diseño_de_Estructuras_con_SAP_2000,_5ta_Edición_ICG.pdf
Análisis_y_Diseño_de_Estructuras_con_SAP_2000,_5ta_Edición_ICG.pdfAnálisis_y_Diseño_de_Estructuras_con_SAP_2000,_5ta_Edición_ICG.pdf
Análisis_y_Diseño_de_Estructuras_con_SAP_2000,_5ta_Edición_ICG.pdfGabrielCayampiGutier
 
ingenieria grafica para la carrera de ingeniera .pptx
ingenieria grafica para la carrera de ingeniera .pptxingenieria grafica para la carrera de ingeniera .pptx
ingenieria grafica para la carrera de ingeniera .pptxjhorbycoralsanchez
 
CONEXIONES SERIE, PERALELO EN MÓDULOS FOTOVOLTAICOS.pdf
CONEXIONES SERIE, PERALELO EN MÓDULOS FOTOVOLTAICOS.pdfCONEXIONES SERIE, PERALELO EN MÓDULOS FOTOVOLTAICOS.pdf
CONEXIONES SERIE, PERALELO EN MÓDULOS FOTOVOLTAICOS.pdfwduranteg
 

Último (20)

libro de ingeniería de petróleos y operaciones
libro de ingeniería de petróleos y operacioneslibro de ingeniería de petróleos y operaciones
libro de ingeniería de petróleos y operaciones
 
27311861-Cuencas-sedimentarias-en-Colombia.ppt
27311861-Cuencas-sedimentarias-en-Colombia.ppt27311861-Cuencas-sedimentarias-en-Colombia.ppt
27311861-Cuencas-sedimentarias-en-Colombia.ppt
 
NTC 3883 análisis sensorial. metodología. prueba duo-trio.pdf
NTC 3883 análisis sensorial. metodología. prueba duo-trio.pdfNTC 3883 análisis sensorial. metodología. prueba duo-trio.pdf
NTC 3883 análisis sensorial. metodología. prueba duo-trio.pdf
 
PostgreSQL on Kubernetes Using GitOps and ArgoCD
PostgreSQL on Kubernetes Using GitOps and ArgoCDPostgreSQL on Kubernetes Using GitOps and ArgoCD
PostgreSQL on Kubernetes Using GitOps and ArgoCD
 
Determinación de espacios en la instalación
Determinación de espacios en la instalaciónDeterminación de espacios en la instalación
Determinación de espacios en la instalación
 
semana-08-clase-transformadores-y-norma-eep.ppt
semana-08-clase-transformadores-y-norma-eep.pptsemana-08-clase-transformadores-y-norma-eep.ppt
semana-08-clase-transformadores-y-norma-eep.ppt
 
[1LLF] UNIDADES, MAGNITUDES FÍSICAS Y VECTORES.pdf
[1LLF] UNIDADES, MAGNITUDES FÍSICAS Y VECTORES.pdf[1LLF] UNIDADES, MAGNITUDES FÍSICAS Y VECTORES.pdf
[1LLF] UNIDADES, MAGNITUDES FÍSICAS Y VECTORES.pdf
 
Maquinaria Agricola utilizada en la produccion de Piña.pdf
Maquinaria Agricola utilizada en la produccion de Piña.pdfMaquinaria Agricola utilizada en la produccion de Piña.pdf
Maquinaria Agricola utilizada en la produccion de Piña.pdf
 
APORTES A LA ARQUITECTURA DE WALTER GROPIUS Y FRANK LLOYD WRIGHT
APORTES A LA ARQUITECTURA DE WALTER GROPIUS Y FRANK LLOYD WRIGHTAPORTES A LA ARQUITECTURA DE WALTER GROPIUS Y FRANK LLOYD WRIGHT
APORTES A LA ARQUITECTURA DE WALTER GROPIUS Y FRANK LLOYD WRIGHT
 
EFICIENCIA ENERGETICA-ISO50001_INTEC_2.pptx
EFICIENCIA ENERGETICA-ISO50001_INTEC_2.pptxEFICIENCIA ENERGETICA-ISO50001_INTEC_2.pptx
EFICIENCIA ENERGETICA-ISO50001_INTEC_2.pptx
 
Trazos paileros para realizar trazos, cortes y calculos.pptx
Trazos paileros para realizar trazos, cortes y calculos.pptxTrazos paileros para realizar trazos, cortes y calculos.pptx
Trazos paileros para realizar trazos, cortes y calculos.pptx
 
Minería convencional: datos importantes y conceptos
Minería convencional: datos importantes y conceptosMinería convencional: datos importantes y conceptos
Minería convencional: datos importantes y conceptos
 
Desigualdades e inecuaciones-convertido.pdf
Desigualdades e inecuaciones-convertido.pdfDesigualdades e inecuaciones-convertido.pdf
Desigualdades e inecuaciones-convertido.pdf
 
Introduction to Satellite Communication_esp_FINAL.ppt
Introduction to Satellite Communication_esp_FINAL.pptIntroduction to Satellite Communication_esp_FINAL.ppt
Introduction to Satellite Communication_esp_FINAL.ppt
 
FUNCION DE ESTADO EN LA TERMODINAMICA.pdf
FUNCION DE ESTADO EN LA TERMODINAMICA.pdfFUNCION DE ESTADO EN LA TERMODINAMICA.pdf
FUNCION DE ESTADO EN LA TERMODINAMICA.pdf
 
TIPOS DE SOPORTES - CLASIFICACION IG.pdf
TIPOS DE SOPORTES - CLASIFICACION IG.pdfTIPOS DE SOPORTES - CLASIFICACION IG.pdf
TIPOS DE SOPORTES - CLASIFICACION IG.pdf
 
Tippens fisica 7eDIAPOSITIVAS TIPENS Tippens_fisica_7e_diapositivas_33.ppt
Tippens fisica 7eDIAPOSITIVAS TIPENS Tippens_fisica_7e_diapositivas_33.pptTippens fisica 7eDIAPOSITIVAS TIPENS Tippens_fisica_7e_diapositivas_33.ppt
Tippens fisica 7eDIAPOSITIVAS TIPENS Tippens_fisica_7e_diapositivas_33.ppt
 
Análisis_y_Diseño_de_Estructuras_con_SAP_2000,_5ta_Edición_ICG.pdf
Análisis_y_Diseño_de_Estructuras_con_SAP_2000,_5ta_Edición_ICG.pdfAnálisis_y_Diseño_de_Estructuras_con_SAP_2000,_5ta_Edición_ICG.pdf
Análisis_y_Diseño_de_Estructuras_con_SAP_2000,_5ta_Edición_ICG.pdf
 
ingenieria grafica para la carrera de ingeniera .pptx
ingenieria grafica para la carrera de ingeniera .pptxingenieria grafica para la carrera de ingeniera .pptx
ingenieria grafica para la carrera de ingeniera .pptx
 
CONEXIONES SERIE, PERALELO EN MÓDULOS FOTOVOLTAICOS.pdf
CONEXIONES SERIE, PERALELO EN MÓDULOS FOTOVOLTAICOS.pdfCONEXIONES SERIE, PERALELO EN MÓDULOS FOTOVOLTAICOS.pdf
CONEXIONES SERIE, PERALELO EN MÓDULOS FOTOVOLTAICOS.pdf
 

Ingenieria de software basada en componentes -jeiner gonzalez blanco

  • 1.
  • 2. Para el software personalizado, la ingeniería de software basada en componentes es una forma efectiva orientada a la reutilización para desarrollar nuevos sistemas empresariales. La CBSE surgió a finales de la década de 1990 como un enfoque al desarrollo de sistemas de software basado en la reutilización de componentes de software. Su creación fue motivada por la frustración de los diseñadores al percatarse de que el desarrollo orientado a objetos no conducía a una reutilización extensa como se había sugerido originalmente. La CBSE es el proceso de definir, implementar e integrar o componer los componentes independientes e imprecisos en los sistemas. Los fundamentos de la ingeniería de software basada en componentes son: 1. Componentes independientes que se especifican por completo mediante sus interfaces. 2. Estándares de componentes que facilitan la integración de estos. 3. Middleware que brinda soporte de software para integración de componentes. 4. Un proceso de desarrollo que se engrana con la ingeniería de software basada en componentes.
  • 3. En la base de CBSE existen firmes principios de diseño que apoyan la construcción de software comprensible y mantenible:  Los componentes so n independientes, de manera que sus ejecuciones no interfieren entre si. Se ocultan los detalles de la implementación.  Los componentes se comunican a través de interfaces bien definidas.  Las infraestructuras de componentes ofrecen varios servicios estándar que pueden usarse en sistemas de aplicación. La motivación inicial para la CBSE fue la necesidad de brindar apoyo tanto a la ingeniería de software de reutilización como a la distribuida. En la comunidad CBSE existen un acuerdo general de que un componentes es una unidad de software independiente que puede organizarse con otros componentes para ser un sistema de software. Los componentes son independientes, y los consideran la unidad fundamental de composición en un sistema.
  • 4. Características del componente:  Estandarizado: estandarización de componentes significan que un componente utilizado durante un proceso CBSE debe ajustarse a un modelo de componentes estándar.  Independiente: debe ser factible componerlo e implementarlo sin usar otros componentes específicos.  Componible: todas las interacciones externas deben tener lugar mediante interfaces definidas públicamente.  Implementarle: un componente debe estar auto contenido.  Documentado: los componentes deben implementarse por completo, para que los usuarios potenciales puedan decidir si los componentes cumplen o no sus necesidades. Visualizar un componente como un proveedor de servicios pone de relieve dos características criticas de un componente de reutilización: 1) El componente es una entidad ejecutable independiente definida mediante sus interfaces. 2) Los servicios ofrecidos por un componentes se ponen a disposición mediante una interfaz, y todas las interacciones por dicha interfaz.
  • 5. Los componentes tienen dos interfaces relacionadas. Dichas interfaces reflejan los servicios que proveen los componentes y los servicios que el componente requiere para ejecutarse correctamente:  La interfaz “proporciona” define los servicios que ofrece el componente.  La interfaz “requiere” especifica que servicio deben ofrecer otros componentes en el sistema para que un componente opere correctamente. Un modelo de componentes es una definición de estándares para implementación, documentación, y despliegue de componentes. Los modelos de componentes mas importantes son el modelo WebServices, el modelo Enterprise Java Beans (EJB) de Sun, y el modelo .NET de Microsoft. Los elementos de un modelo de componentes definen los interfaces de componentes, que los elementos de un modelo de componentes definen las interfaces de componentes, la información que necesita usar el componentes en un programa como deben implementarse un componentes:  Interfaces: los componentes se definen al especificar sus interfaces.
  • 6.  Uso: para que los componentes se distribuyan y se acceda a ellos de manera remota deben tener un nombre único asociado.  Implementación: el modelo de componentes incluye una especificación de cómo deben empacarse los componentes para su implementación como entidades ejecutables independientes. Los servicios brindados por una implementación de modelo de componentes se dividen en dos categorías: 1. Servicios de plataformas: los cuales permiten a los componentes comunicarse e inter operar en un entorno distribuido. 2. Servicios de apoyo: que son servicio comunes que probablemente requieren muchos componentes diversos. El Middleware implementa los servicios de componentes y ofrece interfaces a dichos servicios.
  • 7. Los procesos CBSE son procesos de software que brindan soporte a la ingeniería de software basada en componentes. Toman en cuenta los posibilidades de reutilización y las diferentes actividades de proceso implicadas en el desarrollo y uso de componentes reutilizables. Al nivel mas alto, existen dos tipos de proceso CBSE: Desarrollo para reutilización: este proceso se ocupa del desarrollo de componentes o servicios que se reutilizaran en otras aplicaciones. Desarrollo con reutilización: este es el proceso para desarrollar nuevas aplicaciones usando los componentes y servicios existentes. En el proceso de desarrollo para reutilización, el objetivo es producir uno o mas componentes reutilizables. En el desarrollo con reutilización, no sabe cuales componentes están disponibles, así que necesitan descubrir dichos componentes y diseñar un sistema para utilizarlos de la manera mas efectiva.
  • 8. Los procesos básicos de CBSE con y para reutilización tienen procesos de soporte que se ocupan de la adquisición, gestión y certificación de componentes:  Adquisición de componentes es el proceso de adquirir componentes para reutilización o desarrollo en un componente reutilizable.  La gestión de componentes se ocupa de la gestión de los componentes de reutilización de una compañía, asegurándose de que están adecuadamente catalogados, almacenados y dispuestos para reutilizarse.  Certificación de componentes es el proceso de comprobar un componente y asegurase de que cumple su especificación. La CBSE para reutilización es el proceso de desarrollar componentes reutilizables y ponerlos a disposición para reutilizarlos a través de un sistema de gestión de componentes. Para elaborar componentes de reutilización, deben adaptarse y extenderse componentes específicos de aplicación para crear versiones mas genéricas y, por lo tanto, mas reutilizables.
  • 9. Los cambios que se pueden hacer a un componentes para volverlo mas reutilizable incluyen:  Eliminar métodos específicos de aplicación.  Cambiar los nombres para hacerlos mas generales.  Agregar métodos para brindar cobertura funcional mas completa.  Hacer manejadores de excepción consistentes para todos los métodos.  Adicionar una interfaz de “configuración” para permitir la adaptación de los componentes a diferentes situaciones de uso.  Integrar los componentes requeridos para aumentar la independencia. El problema del manejo de excepción es particularmente difícil. Los componentes no deben manejar las excepciones por si mismos, porque cada aplicación tendrá sus propios requerimientos para manejo de excepción. Sin embargo, en la practica, existen dos problemas con esto: 1. Publicar todas las excepciones conduce a interfaces infladas que son difíciles de entender. 2. La ejecución del componente puede depender del manejo de excepciones locales, y cambiar estos tal vez tengan serias implicaciones para las funcionalidad del componente
  • 10. Si un componente es susceptible de reutilización, o no, depende de su dominio de aplicación y su funcionalidad. Para hacer reutilizable un componente, usted deberá proporcionar un conjunto de interfaces genéricas con operaciones que incluyan todas las formas que el componente podría usar. La certificación significa que alguien aparte del desarrollador, verifica la calidad del componente. Se prueba el componente y se certifica que alcanza un estándar de calidad aceptable, antes de ponerlo a disposición para su reutilización. La reutilización exitosa de componentes requiere un proceso de desarrollo ajustado a CBSE. La CBSE con un proceso de reutilización debe incluir actividades que encuentren e integren componentes reutilizables. Algunas de las actividades dentro de este proceso, como el descubrimiento inicial de los requerimientos de usuario , se realizan en la misma forma que en otros procesos de software. Sin embargo, las diferencias esenciales entre CBSE con reutilización y procesos de software para desarrollo de software original son:  Los requerimientos del usuario inicialmente se desarrollan en bosquejos y no en detalles , y se alienta a las partes interesadas a ser tan flexibles como sea posible para definir su requerimientos.
  • 11.  Los requerimientos se afinan y modifican oportunamente durante el proceso, dependiendo de los componentes disponibles.  Después de diseñar la arquitectura del sistema, hay una actividad adicional de búsqueda de componentes y clarificación del diseño.  El desarrollo es un proceso de composición en que se integran los componentes descubiertos. La etapa de diseño arquitectónico es particularmente importante. Definir una arquitectura robusta es crucial para tener éxito en reutilización. Una actividad que es única para el proceso CBSE es identificar los componentes o servicios candidatos para reutilización. Esto implica algunas actividades especificas. Inicialmente, el enfoque debe estar en la búsqueda y selección. En la ultima etapa después de diseñada la arquitectura del sistema, debe de dedicarse a la validación de componentes. El primer paso en la identificación de los componentes es buscar aquellos que estén disponibles localmente o con proveedores confiables. Una vez que el proceso de búsqueda permite identificarlos posibles componentes, se deben seleccionar componentes candidatos para su valoración.
  • 12. Una vez seleccionados los componentes para su posible inclusión en un sistema se deben validar para comprobar que se comportan como se espera. La validación de componentes implica desarrollar un conjunto de casos de pruebas para un componente (o, posiblemente, extender los casos de prueba suministrado con dichos componentes) y desarrollar un conjunto de pruebas para ejecutar pruebas de componentes. Además de probar que un componente para reutilización logra lo que se requiere, es posible que se tenga que verificar también que el componente no incluya algunos códigos o una funcionalidad maliciosos e innecesarios. El problema con la funcionalidad innecesaria es que puedan activarse por el componente en si.
  • 13. La composición de componentes es el proceso de integrar componente uno con otro y con “código pegamento” especialmente escrito para crear un sistema u otro componente. El se describen las siguientes composiciones: 1. La composición secuencial: usted crea aun nuevo componente a partir de dos componentes existente al llamare en secuencia a los componentes existentes. 2. La composición jerárquica: esto tipo de composición ocurre cuando un componente llama directamente a los servicios que ofrece otro componentes. 3. La composición aditiva: esto ocurre cuando dos o mas componentes se juntan (se suman) para crear un nuevo componente, lo que cambia su funcionalidad. Cuando escriba nuevos componentes especialmente para composición, deberia diseñar las interfaces de dichos componentes de manera que sean compatibles con otro componente en el sistema.
  • 14. Es posible que ocurran tres tipos de incompatibilidades:  Incompatibilidad de parámetro: las operaciones de cada lado de la interfaz tienen el mismo nombre pero sus tipos de parámetro o el numero de parámetros son diferentes.  Incompatibilidad: los nombres de las operaciones de la interfaces “proporcionan” y “requiere” son diferentes.  Operación incompleta: la interfaz “proporciona “de un componentes es un subconjunto de la interfaz “requiere” de otro componente o viceversa. En todos los caso el problema de la incompatibilidad se resuelve al escribir un adaptador que reconcilie las interfaces de los dos componentes a reutilizar.