SlideShare una empresa de Scribd logo
1 de 5
Descargar para leer sin conexión
1
Arquitectura basada en Componentes
Definición
La arquitectura basada en componentes consiste en una rama de la Ingeniería de software
en la cual se trata con énfasis la descomposición del software en componentes funcionales. Esta
descomposición permite convertir componentes pre-existentes en piezas más grandes de
software.
Este proceso de construcción de una pieza de software con componentes ya existentes,
da origen al principio de reutilización del software, mediante el cual se promueve que los
componentes sean implementados de una forma que permita su utilización funcional sobre
diferentes sistemas en el futuro.
Se debe entonces, para terminar de definir la arquitectura basada en componente, saber
que es un componente de software. Un componente de software se define típicamente como algo
que puede ser utilizado como una caja negra, en donde se tiene de manera externa una
especificación general, la cual es independiente de la especificación interna1
• Interior del componente: es una pieza de software que cumple con un conjunto de
propiedades y que se encuentra conformada como un artefacto del cual se espera que sea
reutilizable.
.
De esta definición se presentan tres conceptos ligados con la definición de un componente:
• Exterior del componente: es una interface que cumple con un conjunto de propiedades y
provee un servicio a los agentes humanos u otros artefactos de software.
• Relación interior-exterior: es la que define el proceso de relación entre el interior y
exterior el componente, a través de conceptos como especificación, implementación y
encapsulación.
Elementos y estructura de la arquitectura basada en componentes
De forma evidente se puede determinar que, el principal elemento de software dentro de
un Arquitectura basada en componentes son precisamente los componentes de software.
Existen 5 principios definidos por Clemens Szyperski and David Messerschmitt2
1
Component-Based Development
http://www.users.globalnet.co.uk/~rxv/CBDmain/cbdfaq.htm#Component-Based%20Development
2
Component-based software engineering. http://en.wikipedia.org/wiki/Software_componentry
, que
definen a un componente de software como elemento de la arquitectura:
2
• Múltiple uso: se refiere al hecho de que un componente es escrito dentro de un
contexto que permita que su funcionalidad sea útil en la creación de distintas
piezas de software.
• Contexto no específico: en relación con la orientación conceptual de la
especificación de un componente, debe estar planteada de una forma general que
permita su adaptación en distintos sistemas, sin que el contexto tenga prioridad.
• Encapsulación: se refiere a la especificación interna oculta o no investigable a
través de la interface. Así se protege que el resto de componentes y piezas de
software dentro de un sistema, no se vean afectados por cambios en el diseño de
uno de los componentes.
• Una unidad independiente de desarrollo con su propio control de versiones:
este principio muy relacionado con la encapsulación, permite que un componente
pueda ser desarrollado de manera independiente, cambiando el diseño o
agregando nuevas funcionalidades, sin afectar significativamente el resto del
sistema.
La estructura de la arquitectura basada en componentes contempla 3 partes:
1. El nombre de los componentes: el nombre de un componente debe ser la identificación
de la funcionalidad y uso que tiene como software. Generalmente, los desarrolladores
usan algún tipo de convención que facilite la identificación de componentes,
especialmente, cuando se trabaja en proyectos de gran envergadura
2. La interface de los componentes: es el área de intercambio (input-output) entre el interior
y el exterior de un componente de software. La interface es quien permite acceder a los
datos y funcionalidades que estén especificadas en el interior del componente (acceder
funcionalmente, no a su especificación).
Adicional a la interface se encuentra la documentación que muestra la información sobre
cómo utilizar un componente.
3. Cuerpo y código de implementación: es la parte del componente que provee la forma
(implementación) sobre la cual un fragmento del componente realiza sus servicios y
funcionalidades. Este es el área que debe cumplir con el principio de encapsulación.
Dentro de la estructura de una arquitectura basada en software existen dos procesos
fundamentales para el desarrollo:
El ensamblaje de sistemas a partir de componentes de software
Este proceso está compuesto por cuatro actividades:
1) Calificación de los componentes: comprende el estudio y análisis de que tan adecuado es un
componente para la construcción del sistema final. Esta evaluación se realiza sobre un
conjunto de métricas que deben establecer los analistas y diseñadores de la arquitectura.
3
Además de esto, de acuerdo con Felix Bachman3
I. El establecimiento de hechos sobre el componente para verificar que las propiedades que
el componente posee son acordes con su especificación pública (documentada).
, durante esta actividad existen dos procesos
relacionados con la certificación de los componentes:
II. La validación de que los hechos establecidos sobre el componente son ciertos.
La razón por la cual se realiza este proceso de certificación es que existe un vínculo entre las
propiedades certificadas de un componente y las del sistema final, es decir, la certificación es una
herramienta para garantizar que las propiedades de la pieza de software final sean válidas.
2) Adaptación de los componentes: dado que un componente es desarrollado para cumplir con
requerimientos específicos, es posible que esté orientado en cierta medida hacia el contexto
en el que fue desarrollado. Por esta razón, se realiza un proceso de adaptación con el objetivo
de minimizar la cantidad de conflictos.
Un componente puede ser adaptado entonces de tres maneras:
I. White-Box: cuando el componente debe ser reescrito para operar en conjunto con el resto
de componentes del sistema.
II. Grey-Box: cuando el componente incorpora su propio API (Application Programming
Interface).
III. Black-Box: cuando el componente no posee un API. Una interfaz completamente
independiente es construida para acceder a los servicios del componente.
3) Ensamblaje de los componentes: es el proceso de integración de los componentes a través de
la estructura mediante la cual fueron definidos. Esto incluye el modelo de software por
componentes sobre el cual son escritos, por ejemplo: COM (Component Object Model), CORBA
(Common Object Request Broker Architectur), Enterprise JavaBeans y .NET.
4) Mantenimiento y evolución del sistema: consiste en el proceso de actualización de
componentes, ya sea por requerimiento o por cambios de especificación. Estos cambios
pueden ser la reescritura o sustitución de un componente. Por tal razón un componente
trabaja como una unidad (conectable y desconectable) dentro de un sistema.
Reusabilidad
Esta es una de las características más importantes en el desarrollo de sistemas bajo una
arquitectura basada en componentes. Un componente de software debe ser diseñado de tal
madera que pueda ser reutilizado en otros sistemas.
3
Technical Concepts of Component-Based Software Engineering, T.R. CMU/SEI-2000.
4
Este principio de reutilización del componente, requiere un esfuerzo extra por el equipo de
desarrollo que se basa en:
• Una documentación completa de cada atributo y funcionalidad del componente.
• Una etapa de pruebas organizada y certera que certifique el correcto funcionamiento del
componente.
• Una definición de comprobaciones precisa para el chequeo de cada parámetro de entrada
(input) del componente.
• Un manejo de notificaciones de errores preciso, que advierta de la existencia de estos de
una forma apropiada.
• Desarrollar teniendo en cuenta que el componente puede ser requerido para trabajar en
muchos contextos muy diferentes unos de otros (tomar en cuenta la eficiencia, uso de
memoria y recursos).
5
Referencias Bibliográficas
 http://cbs.colognet.org/overview.php
 http://active.cput.ac.za/myconference/Gregory%20Booth%20-
%20Component%20Software%20Development.pdf

Más contenido relacionado

La actualidad más candente

25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de SoftwareCamila Arbelaez
 
Entrevista y encuesta para analisis y diseño de sistemas
Entrevista y encuesta para analisis y diseño de sistemasEntrevista y encuesta para analisis y diseño de sistemas
Entrevista y encuesta para analisis y diseño de sistemasmodayestilo
 
Arquitecturas de software - Parte 2
Arquitecturas de software - Parte 2Arquitecturas de software - Parte 2
Arquitecturas de software - Parte 2Marta Silvia Tabares
 
Métricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareMétricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareLorena Quiñónez
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosCesar Prado
 
Diagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaDiagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaRobert Rodriguez
 
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
 
LINEAS DE PRODUCTOS DE SOFTWARE Y MÉTODO WATCH
LINEAS DE PRODUCTOS DE SOFTWARE Y MÉTODO WATCHLINEAS DE PRODUCTOS DE SOFTWARE Y MÉTODO WATCH
LINEAS DE PRODUCTOS DE SOFTWARE Y MÉTODO WATCHPerozoAlejandro
 
Importancia del Análisis de Requerimientos
Importancia del Análisis de RequerimientosImportancia del Análisis de Requerimientos
Importancia del Análisis de Requerimientospedro tovar
 
Doc. lista de requerimientos ver. 1.0
Doc. lista de requerimientos ver. 1.0Doc. lista de requerimientos ver. 1.0
Doc. lista de requerimientos ver. 1.0luimiguelandrade
 
Estandares y modelos de calidad del software
Estandares y modelos de calidad del softwareEstandares y modelos de calidad del software
Estandares y modelos de calidad del softwareaagalvisg
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicoslandeta_p
 

La actualidad más candente (20)

25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Entrevista y encuesta para analisis y diseño de sistemas
Entrevista y encuesta para analisis y diseño de sistemasEntrevista y encuesta para analisis y diseño de sistemas
Entrevista y encuesta para analisis y diseño de sistemas
 
Arquitecturas de software - Parte 2
Arquitecturas de software - Parte 2Arquitecturas de software - Parte 2
Arquitecturas de software - Parte 2
 
Métricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareMétricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de software
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Diagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaDiagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, Asistencia
 
Plan de desarrollo software
Plan de desarrollo softwarePlan de desarrollo software
Plan de desarrollo software
 
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
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
LINEAS DE PRODUCTOS DE SOFTWARE Y MÉTODO WATCH
LINEAS DE PRODUCTOS DE SOFTWARE Y MÉTODO WATCHLINEAS DE PRODUCTOS DE SOFTWARE Y MÉTODO WATCH
LINEAS DE PRODUCTOS DE SOFTWARE Y MÉTODO WATCH
 
Auditoría de redes
Auditoría de redesAuditoría de redes
Auditoría de redes
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
 
Importancia del Análisis de Requerimientos
Importancia del Análisis de RequerimientosImportancia del Análisis de Requerimientos
Importancia del Análisis de Requerimientos
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
Doc. lista de requerimientos ver. 1.0
Doc. lista de requerimientos ver. 1.0Doc. lista de requerimientos ver. 1.0
Doc. lista de requerimientos ver. 1.0
 
5. Métodos de Prueba de Software
5. Métodos de Prueba de Software5. Métodos de Prueba de Software
5. Métodos de Prueba de Software
 
Estandares y modelos de calidad del software
Estandares y modelos de calidad del softwareEstandares y modelos de calidad del software
Estandares y modelos de calidad del software
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Paralelismo a nivel de Instrucciones
Paralelismo a nivel de InstruccionesParalelismo a nivel de Instrucciones
Paralelismo a nivel de Instrucciones
 

Similar a 14704374 arquitectura-basada-en-componentes

Ingenieria de software basada en componentes -jeiner gonzalez blanco
Ingenieria de software basada en componentes  -jeiner gonzalez blancoIngenieria de software basada en componentes  -jeiner gonzalez blanco
Ingenieria de software basada en componentes -jeiner gonzalez blancoJeiner Gonzalez Blanco
 
FUNDAMENTO DEL DISEÑO DE SOFTWARE
FUNDAMENTO DEL DISEÑO DE SOFTWAREFUNDAMENTO DEL DISEÑO DE SOFTWARE
FUNDAMENTO DEL DISEÑO DE SOFTWAREEstebanOrtegon
 
Gestión del Cambio
Gestión del Cambio Gestión del Cambio
Gestión del Cambio jose_macias
 
diseno Componente3.ppt
diseno Componente3.pptdiseno Componente3.ppt
diseno Componente3.pptrafael405074
 
Fundamentos del diseño de software
Fundamentos del diseño de software Fundamentos del diseño de software
Fundamentos del diseño de software AlessandreMndez
 
Introducción A La Orientación A Aspectos - Programador PHP
Introducción A La Orientación A Aspectos - Programador PHPIntroducción A La Orientación A Aspectos - Programador PHP
Introducción A La Orientación A Aspectos - Programador PHPJuan Belón Pérez
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicionEvelin Oña
 
Modelo componentes
Modelo componentesModelo componentes
Modelo componentesmartin
 
Desarrollo de software basado en componentes
Desarrollo de software basado en componentesDesarrollo de software basado en componentes
Desarrollo de software basado en componentesUlises Cruz
 
Reutilizacion de componentes en sistemas
Reutilizacion de componentes en sistemas Reutilizacion de componentes en sistemas
Reutilizacion de componentes en sistemas Gabriela Oyervides
 
Metodología basada en componentes
Metodología basada en componentes Metodología basada en componentes
Metodología basada en componentes Anibal Ulibarri
 
Ingenieria de software basada en componentes
Ingenieria de software basada en componentesIngenieria de software basada en componentes
Ingenieria de software basada en componentesTensor
 

Similar a 14704374 arquitectura-basada-en-componentes (20)

Componentes
ComponentesComponentes
Componentes
 
Ingenieria de software basada en componentes -jeiner gonzalez blanco
Ingenieria de software basada en componentes  -jeiner gonzalez blancoIngenieria de software basada en componentes  -jeiner gonzalez blanco
Ingenieria de software basada en componentes -jeiner gonzalez blanco
 
FUNDAMENTO DEL DISEÑO DE SOFTWARE
FUNDAMENTO DEL DISEÑO DE SOFTWAREFUNDAMENTO DEL DISEÑO DE SOFTWARE
FUNDAMENTO DEL DISEÑO DE SOFTWARE
 
Gestión del Cambio
Gestión del Cambio Gestión del Cambio
Gestión del Cambio
 
Metodo watch
Metodo watchMetodo watch
Metodo watch
 
diseno Componente3.ppt
diseno Componente3.pptdiseno Componente3.ppt
diseno Componente3.ppt
 
Proyecto
ProyectoProyecto
Proyecto
 
Proyecto
ProyectoProyecto
Proyecto
 
Fundamentos del diseño de software
Fundamentos del diseño de software Fundamentos del diseño de software
Fundamentos del diseño de software
 
ing del software
 ing del software  ing del software
ing del software
 
Proceso software
Proceso softwareProceso software
Proceso software
 
Introducción A La Orientación A Aspectos - Programador PHP
Introducción A La Orientación A Aspectos - Programador PHPIntroducción A La Orientación A Aspectos - Programador PHP
Introducción A La Orientación A Aspectos - Programador PHP
 
Capitulo 11 parte1 (2)
Capitulo 11 parte1 (2)Capitulo 11 parte1 (2)
Capitulo 11 parte1 (2)
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicion
 
Modelo componentes
Modelo componentesModelo componentes
Modelo componentes
 
Desarrollo de software basado en componentes
Desarrollo de software basado en componentesDesarrollo de software basado en componentes
Desarrollo de software basado en componentes
 
Proceso del Software
Proceso del Software Proceso del Software
Proceso del Software
 
Reutilizacion de componentes en sistemas
Reutilizacion de componentes en sistemas Reutilizacion de componentes en sistemas
Reutilizacion de componentes en sistemas
 
Metodología basada en componentes
Metodología basada en componentes Metodología basada en componentes
Metodología basada en componentes
 
Ingenieria de software basada en componentes
Ingenieria de software basada en componentesIngenieria de software basada en componentes
Ingenieria de software basada en componentes
 

Más de Gary Araujo Viscarra

Arquitecturacomponentes 141027205348-conversion-gate01
Arquitecturacomponentes 141027205348-conversion-gate01Arquitecturacomponentes 141027205348-conversion-gate01
Arquitecturacomponentes 141027205348-conversion-gate01Gary Araujo Viscarra
 
Tema1 desarrollo de software basado en componentes
Tema1 desarrollo de software basado en componentesTema1 desarrollo de software basado en componentes
Tema1 desarrollo de software basado en componentesGary Araujo Viscarra
 
2.1.4.7 lab establishing a console session with tera term
2.1.4.7 lab   establishing a console session with tera term2.1.4.7 lab   establishing a console session with tera term
2.1.4.7 lab establishing a console session with tera termGary Araujo Viscarra
 

Más de Gary Araujo Viscarra (7)

Arquitecturacomponentes 141027205348-conversion-gate01
Arquitecturacomponentes 141027205348-conversion-gate01Arquitecturacomponentes 141027205348-conversion-gate01
Arquitecturacomponentes 141027205348-conversion-gate01
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 
Tesis luis iribarne
Tesis luis iribarneTesis luis iribarne
Tesis luis iribarne
 
Tema1 desarrollo de software basado en componentes
Tema1 desarrollo de software basado en componentesTema1 desarrollo de software basado en componentes
Tema1 desarrollo de software basado en componentes
 
Estructura practico investigacion
Estructura practico investigacionEstructura practico investigacion
Estructura practico investigacion
 
Educacion especial i
Educacion especial iEducacion especial i
Educacion especial i
 
2.1.4.7 lab establishing a console session with tera term
2.1.4.7 lab   establishing a console session with tera term2.1.4.7 lab   establishing a console session with tera term
2.1.4.7 lab establishing a console session with tera term
 

Último

Trabajo en altura de acuerdo a la normativa peruana
Trabajo en altura de acuerdo a la normativa peruanaTrabajo en altura de acuerdo a la normativa peruana
Trabajo en altura de acuerdo a la normativa peruana5extraviado
 
Revista estudiantil, trabajo final Materia ingeniería de Proyectos
Revista estudiantil, trabajo final Materia ingeniería de ProyectosRevista estudiantil, trabajo final Materia ingeniería de Proyectos
Revista estudiantil, trabajo final Materia ingeniería de ProyectosJeanCarlosLorenzo1
 
5.1 MATERIAL COMPLEMENTARIO Sesión 02.pptx
5.1 MATERIAL COMPLEMENTARIO Sesión 02.pptx5.1 MATERIAL COMPLEMENTARIO Sesión 02.pptx
5.1 MATERIAL COMPLEMENTARIO Sesión 02.pptxNayeliZarzosa1
 
CLASE 2 MUROS CARAVISTA EN CONCRETO Y UNIDAD DE ALBAÑILERIA
CLASE 2 MUROS CARAVISTA EN CONCRETO  Y UNIDAD DE ALBAÑILERIACLASE 2 MUROS CARAVISTA EN CONCRETO  Y UNIDAD DE ALBAÑILERIA
CLASE 2 MUROS CARAVISTA EN CONCRETO Y UNIDAD DE ALBAÑILERIAMayraOchoa35
 
NOM-002-STPS-2010, combate contra incendio.pptx
NOM-002-STPS-2010, combate contra incendio.pptxNOM-002-STPS-2010, combate contra incendio.pptx
NOM-002-STPS-2010, combate contra incendio.pptxJairReyna1
 
Biología molecular ADN recombinante.pptx
Biología molecular ADN recombinante.pptxBiología molecular ADN recombinante.pptx
Biología molecular ADN recombinante.pptxluisvalero46
 
Espontaneidad de las reacciones y procesos espontáneos
Espontaneidad de las reacciones y procesos espontáneosEspontaneidad de las reacciones y procesos espontáneos
Espontaneidad de las reacciones y procesos espontáneosOscarGonzalez231938
 
Centro Integral del Transporte de Metro de Madrid (CIT). Premio COAM 2023
Centro Integral del Transporte de Metro de Madrid (CIT). Premio COAM 2023Centro Integral del Transporte de Metro de Madrid (CIT). Premio COAM 2023
Centro Integral del Transporte de Metro de Madrid (CIT). Premio COAM 2023ANDECE
 
Tarea de UTP matematices y soluciones ingenieria
Tarea de UTP matematices y soluciones ingenieriaTarea de UTP matematices y soluciones ingenieria
Tarea de UTP matematices y soluciones ingenieriaSebastianQP1
 
Sistema de gestión de turnos para negocios
Sistema de gestión de turnos para negociosSistema de gestión de turnos para negocios
Sistema de gestión de turnos para negociosfranchescamassielmor
 
VIRUS FITOPATÓGENOS (GENERALIDADES EN PLANTAS)
VIRUS FITOPATÓGENOS (GENERALIDADES EN PLANTAS)VIRUS FITOPATÓGENOS (GENERALIDADES EN PLANTAS)
VIRUS FITOPATÓGENOS (GENERALIDADES EN PLANTAS)ssuser6958b11
 
Clase 1 Análisis Estructura. Para Arquitectura pptx
Clase 1 Análisis Estructura. Para Arquitectura pptxClase 1 Análisis Estructura. Para Arquitectura pptx
Clase 1 Análisis Estructura. Para Arquitectura pptxPaolaVillalba13
 
Flujo potencial, conceptos básicos y ejemplos resueltos.
Flujo potencial, conceptos básicos y ejemplos resueltos.Flujo potencial, conceptos básicos y ejemplos resueltos.
Flujo potencial, conceptos básicos y ejemplos resueltos.ALEJANDROLEONGALICIA
 
Electromagnetismo Fisica FisicaFisica.pdf
Electromagnetismo Fisica FisicaFisica.pdfElectromagnetismo Fisica FisicaFisica.pdf
Electromagnetismo Fisica FisicaFisica.pdfAnonymous0pBRsQXfnx
 
SOLIDOS DE REVOLUCION, aplicaciones de integrales definidas
SOLIDOS DE REVOLUCION, aplicaciones de integrales definidasSOLIDOS DE REVOLUCION, aplicaciones de integrales definidas
SOLIDOS DE REVOLUCION, aplicaciones de integrales definidasLeonardoMendozaDvila
 
Diagrama de flujo metalurgia del cobre..pptx
Diagrama de flujo metalurgia del cobre..pptxDiagrama de flujo metalurgia del cobre..pptx
Diagrama de flujo metalurgia del cobre..pptxHarryArmandoLazaroBa
 
SEGURIDAD EN CONSTRUCCION PPT PARA EL CIP
SEGURIDAD EN CONSTRUCCION PPT PARA EL CIPSEGURIDAD EN CONSTRUCCION PPT PARA EL CIP
SEGURIDAD EN CONSTRUCCION PPT PARA EL CIPJosLuisFrancoCaldern
 
Físicas 1: Ecuaciones Dimensionales y Vectores
Físicas 1: Ecuaciones Dimensionales y VectoresFísicas 1: Ecuaciones Dimensionales y Vectores
Físicas 1: Ecuaciones Dimensionales y VectoresSegundo Silva Maguiña
 
SEMANA 6 MEDIDAS DE TENDENCIA CENTRAL.pdf
SEMANA  6 MEDIDAS DE TENDENCIA CENTRAL.pdfSEMANA  6 MEDIDAS DE TENDENCIA CENTRAL.pdf
SEMANA 6 MEDIDAS DE TENDENCIA CENTRAL.pdffredyflores58
 

Último (20)

Trabajo en altura de acuerdo a la normativa peruana
Trabajo en altura de acuerdo a la normativa peruanaTrabajo en altura de acuerdo a la normativa peruana
Trabajo en altura de acuerdo a la normativa peruana
 
Revista estudiantil, trabajo final Materia ingeniería de Proyectos
Revista estudiantil, trabajo final Materia ingeniería de ProyectosRevista estudiantil, trabajo final Materia ingeniería de Proyectos
Revista estudiantil, trabajo final Materia ingeniería de Proyectos
 
5.1 MATERIAL COMPLEMENTARIO Sesión 02.pptx
5.1 MATERIAL COMPLEMENTARIO Sesión 02.pptx5.1 MATERIAL COMPLEMENTARIO Sesión 02.pptx
5.1 MATERIAL COMPLEMENTARIO Sesión 02.pptx
 
CLASE 2 MUROS CARAVISTA EN CONCRETO Y UNIDAD DE ALBAÑILERIA
CLASE 2 MUROS CARAVISTA EN CONCRETO  Y UNIDAD DE ALBAÑILERIACLASE 2 MUROS CARAVISTA EN CONCRETO  Y UNIDAD DE ALBAÑILERIA
CLASE 2 MUROS CARAVISTA EN CONCRETO Y UNIDAD DE ALBAÑILERIA
 
NOM-002-STPS-2010, combate contra incendio.pptx
NOM-002-STPS-2010, combate contra incendio.pptxNOM-002-STPS-2010, combate contra incendio.pptx
NOM-002-STPS-2010, combate contra incendio.pptx
 
Biología molecular ADN recombinante.pptx
Biología molecular ADN recombinante.pptxBiología molecular ADN recombinante.pptx
Biología molecular ADN recombinante.pptx
 
Espontaneidad de las reacciones y procesos espontáneos
Espontaneidad de las reacciones y procesos espontáneosEspontaneidad de las reacciones y procesos espontáneos
Espontaneidad de las reacciones y procesos espontáneos
 
Centro Integral del Transporte de Metro de Madrid (CIT). Premio COAM 2023
Centro Integral del Transporte de Metro de Madrid (CIT). Premio COAM 2023Centro Integral del Transporte de Metro de Madrid (CIT). Premio COAM 2023
Centro Integral del Transporte de Metro de Madrid (CIT). Premio COAM 2023
 
Tarea de UTP matematices y soluciones ingenieria
Tarea de UTP matematices y soluciones ingenieriaTarea de UTP matematices y soluciones ingenieria
Tarea de UTP matematices y soluciones ingenieria
 
Sistema de gestión de turnos para negocios
Sistema de gestión de turnos para negociosSistema de gestión de turnos para negocios
Sistema de gestión de turnos para negocios
 
VIRUS FITOPATÓGENOS (GENERALIDADES EN PLANTAS)
VIRUS FITOPATÓGENOS (GENERALIDADES EN PLANTAS)VIRUS FITOPATÓGENOS (GENERALIDADES EN PLANTAS)
VIRUS FITOPATÓGENOS (GENERALIDADES EN PLANTAS)
 
MATPEL COMPLETO DESDE NIVEL I AL III.pdf
MATPEL COMPLETO DESDE NIVEL I AL III.pdfMATPEL COMPLETO DESDE NIVEL I AL III.pdf
MATPEL COMPLETO DESDE NIVEL I AL III.pdf
 
Clase 1 Análisis Estructura. Para Arquitectura pptx
Clase 1 Análisis Estructura. Para Arquitectura pptxClase 1 Análisis Estructura. Para Arquitectura pptx
Clase 1 Análisis Estructura. Para Arquitectura pptx
 
Flujo potencial, conceptos básicos y ejemplos resueltos.
Flujo potencial, conceptos básicos y ejemplos resueltos.Flujo potencial, conceptos básicos y ejemplos resueltos.
Flujo potencial, conceptos básicos y ejemplos resueltos.
 
Electromagnetismo Fisica FisicaFisica.pdf
Electromagnetismo Fisica FisicaFisica.pdfElectromagnetismo Fisica FisicaFisica.pdf
Electromagnetismo Fisica FisicaFisica.pdf
 
SOLIDOS DE REVOLUCION, aplicaciones de integrales definidas
SOLIDOS DE REVOLUCION, aplicaciones de integrales definidasSOLIDOS DE REVOLUCION, aplicaciones de integrales definidas
SOLIDOS DE REVOLUCION, aplicaciones de integrales definidas
 
Diagrama de flujo metalurgia del cobre..pptx
Diagrama de flujo metalurgia del cobre..pptxDiagrama de flujo metalurgia del cobre..pptx
Diagrama de flujo metalurgia del cobre..pptx
 
SEGURIDAD EN CONSTRUCCION PPT PARA EL CIP
SEGURIDAD EN CONSTRUCCION PPT PARA EL CIPSEGURIDAD EN CONSTRUCCION PPT PARA EL CIP
SEGURIDAD EN CONSTRUCCION PPT PARA EL CIP
 
Físicas 1: Ecuaciones Dimensionales y Vectores
Físicas 1: Ecuaciones Dimensionales y VectoresFísicas 1: Ecuaciones Dimensionales y Vectores
Físicas 1: Ecuaciones Dimensionales y Vectores
 
SEMANA 6 MEDIDAS DE TENDENCIA CENTRAL.pdf
SEMANA  6 MEDIDAS DE TENDENCIA CENTRAL.pdfSEMANA  6 MEDIDAS DE TENDENCIA CENTRAL.pdf
SEMANA 6 MEDIDAS DE TENDENCIA CENTRAL.pdf
 

14704374 arquitectura-basada-en-componentes

  • 1. 1 Arquitectura basada en Componentes Definición La arquitectura basada en componentes consiste en una rama de la Ingeniería de software en la cual se trata con énfasis la descomposición del software en componentes funcionales. Esta descomposición permite convertir componentes pre-existentes en piezas más grandes de software. Este proceso de construcción de una pieza de software con componentes ya existentes, da origen al principio de reutilización del software, mediante el cual se promueve que los componentes sean implementados de una forma que permita su utilización funcional sobre diferentes sistemas en el futuro. Se debe entonces, para terminar de definir la arquitectura basada en componente, saber que es un componente de software. Un componente de software se define típicamente como algo que puede ser utilizado como una caja negra, en donde se tiene de manera externa una especificación general, la cual es independiente de la especificación interna1 • Interior del componente: es una pieza de software que cumple con un conjunto de propiedades y que se encuentra conformada como un artefacto del cual se espera que sea reutilizable. . De esta definición se presentan tres conceptos ligados con la definición de un componente: • Exterior del componente: es una interface que cumple con un conjunto de propiedades y provee un servicio a los agentes humanos u otros artefactos de software. • Relación interior-exterior: es la que define el proceso de relación entre el interior y exterior el componente, a través de conceptos como especificación, implementación y encapsulación. Elementos y estructura de la arquitectura basada en componentes De forma evidente se puede determinar que, el principal elemento de software dentro de un Arquitectura basada en componentes son precisamente los componentes de software. Existen 5 principios definidos por Clemens Szyperski and David Messerschmitt2 1 Component-Based Development http://www.users.globalnet.co.uk/~rxv/CBDmain/cbdfaq.htm#Component-Based%20Development 2 Component-based software engineering. http://en.wikipedia.org/wiki/Software_componentry , que definen a un componente de software como elemento de la arquitectura:
  • 2. 2 • Múltiple uso: se refiere al hecho de que un componente es escrito dentro de un contexto que permita que su funcionalidad sea útil en la creación de distintas piezas de software. • Contexto no específico: en relación con la orientación conceptual de la especificación de un componente, debe estar planteada de una forma general que permita su adaptación en distintos sistemas, sin que el contexto tenga prioridad. • Encapsulación: se refiere a la especificación interna oculta o no investigable a través de la interface. Así se protege que el resto de componentes y piezas de software dentro de un sistema, no se vean afectados por cambios en el diseño de uno de los componentes. • Una unidad independiente de desarrollo con su propio control de versiones: este principio muy relacionado con la encapsulación, permite que un componente pueda ser desarrollado de manera independiente, cambiando el diseño o agregando nuevas funcionalidades, sin afectar significativamente el resto del sistema. La estructura de la arquitectura basada en componentes contempla 3 partes: 1. El nombre de los componentes: el nombre de un componente debe ser la identificación de la funcionalidad y uso que tiene como software. Generalmente, los desarrolladores usan algún tipo de convención que facilite la identificación de componentes, especialmente, cuando se trabaja en proyectos de gran envergadura 2. La interface de los componentes: es el área de intercambio (input-output) entre el interior y el exterior de un componente de software. La interface es quien permite acceder a los datos y funcionalidades que estén especificadas en el interior del componente (acceder funcionalmente, no a su especificación). Adicional a la interface se encuentra la documentación que muestra la información sobre cómo utilizar un componente. 3. Cuerpo y código de implementación: es la parte del componente que provee la forma (implementación) sobre la cual un fragmento del componente realiza sus servicios y funcionalidades. Este es el área que debe cumplir con el principio de encapsulación. Dentro de la estructura de una arquitectura basada en software existen dos procesos fundamentales para el desarrollo: El ensamblaje de sistemas a partir de componentes de software Este proceso está compuesto por cuatro actividades: 1) Calificación de los componentes: comprende el estudio y análisis de que tan adecuado es un componente para la construcción del sistema final. Esta evaluación se realiza sobre un conjunto de métricas que deben establecer los analistas y diseñadores de la arquitectura.
  • 3. 3 Además de esto, de acuerdo con Felix Bachman3 I. El establecimiento de hechos sobre el componente para verificar que las propiedades que el componente posee son acordes con su especificación pública (documentada). , durante esta actividad existen dos procesos relacionados con la certificación de los componentes: II. La validación de que los hechos establecidos sobre el componente son ciertos. La razón por la cual se realiza este proceso de certificación es que existe un vínculo entre las propiedades certificadas de un componente y las del sistema final, es decir, la certificación es una herramienta para garantizar que las propiedades de la pieza de software final sean válidas. 2) Adaptación de los componentes: dado que un componente es desarrollado para cumplir con requerimientos específicos, es posible que esté orientado en cierta medida hacia el contexto en el que fue desarrollado. Por esta razón, se realiza un proceso de adaptación con el objetivo de minimizar la cantidad de conflictos. Un componente puede ser adaptado entonces de tres maneras: I. White-Box: cuando el componente debe ser reescrito para operar en conjunto con el resto de componentes del sistema. II. Grey-Box: cuando el componente incorpora su propio API (Application Programming Interface). III. Black-Box: cuando el componente no posee un API. Una interfaz completamente independiente es construida para acceder a los servicios del componente. 3) Ensamblaje de los componentes: es el proceso de integración de los componentes a través de la estructura mediante la cual fueron definidos. Esto incluye el modelo de software por componentes sobre el cual son escritos, por ejemplo: COM (Component Object Model), CORBA (Common Object Request Broker Architectur), Enterprise JavaBeans y .NET. 4) Mantenimiento y evolución del sistema: consiste en el proceso de actualización de componentes, ya sea por requerimiento o por cambios de especificación. Estos cambios pueden ser la reescritura o sustitución de un componente. Por tal razón un componente trabaja como una unidad (conectable y desconectable) dentro de un sistema. Reusabilidad Esta es una de las características más importantes en el desarrollo de sistemas bajo una arquitectura basada en componentes. Un componente de software debe ser diseñado de tal madera que pueda ser reutilizado en otros sistemas. 3 Technical Concepts of Component-Based Software Engineering, T.R. CMU/SEI-2000.
  • 4. 4 Este principio de reutilización del componente, requiere un esfuerzo extra por el equipo de desarrollo que se basa en: • Una documentación completa de cada atributo y funcionalidad del componente. • Una etapa de pruebas organizada y certera que certifique el correcto funcionamiento del componente. • Una definición de comprobaciones precisa para el chequeo de cada parámetro de entrada (input) del componente. • Un manejo de notificaciones de errores preciso, que advierta de la existencia de estos de una forma apropiada. • Desarrollar teniendo en cuenta que el componente puede ser requerido para trabajar en muchos contextos muy diferentes unos de otros (tomar en cuenta la eficiencia, uso de memoria y recursos).
  • 5. 5 Referencias Bibliográficas  http://cbs.colognet.org/overview.php  http://active.cput.ac.za/myconference/Gregory%20Booth%20- %20Component%20Software%20Development.pdf