2.1.6 Desarrollo Basado en Componentes

6
2.1.6 Desarrollo Basado En Componentes La ingeniería de software basada en componentes (desarrollo basado en componentes (CBD)) es una rama de la ingeniería de software que enfatiza la separación de asuntos. Es un acercamiento basado en la reutilización para definir, implementar, y componer, componentes débilmente acoplados en sistemas. Es la reutilización la que permite a los desarrolladores construir aplicaciones sin partir desde cero, sino acercándose más al modelo de construcción de otras ingenierías, donde los productos se construyen en base al ensamblaje y adaptación de distintos componentes desarrollados por terceros (como lo es la industria del hardware para computadoras). Por ello requiere un conjunto de estándares, guías, procesos y prácticas, para que se la considere como una ingeniería tal, y como una sub-disciplina de la Ingeniería de Software. Los ingenieros de software consideran los componentes como parte de la plataforma inicial para la orientación a servicios. Los componentes juegan este rol, por ejemplo, en servicios de web, y más recientemente, en las arquitecturas orientadas a servicios (SOA), por el que un componente es convertido por el servicio web en un servicio y subsecuentemente hereda otras características más allá de las de un componente ordinario. Un componente de software individual es un paquete de software, un servicio web, o un módulo que encapsula un conjunto de funciones relacionadas (o de datos). Con respecto a la coordinación a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, éste adopta una interface proporcionada que especifica los servicios que otros componentes pueden utilizar, y cómo pueden hacerlo. Esta interface puede ser

description

2.1.6 Desarrollo Basado en Componentes

Transcript of 2.1.6 Desarrollo Basado en Componentes

2.1.6 Desarrollo Basado En Componentes

Laingeniera de software basada en componentes(desarrollo basado en componentes(CBD)) es una rama de laingeniera de softwareque enfatiza laseparacin de asuntos. Es un acercamiento basado en la reutilizacin para definir, implementar, y componer,componentesdbilmente acopladosen sistemas.

Es la reutilizacin la que permite a los desarrolladores construir aplicaciones sin partir desde cero, sino acercndose ms al modelo de construccin de otras ingenieras, donde los productos se construyen en base al ensamblaje y adaptacin de distintos componentes desarrollados por terceros (como lo es la industria del hardware para computadoras). Por ello requiere un conjunto de estndares, guas, procesos y prcticas, para que se la considere como una ingeniera tal, y como una sub-disciplina de la Ingeniera de Software.

Losingenieros de softwareconsideran los componentes como parte de la plataforma inicial para laorientacin a servicios. Los componentes juegan este rol, por ejemplo, enservicios de web, y ms recientemente, en lasarquitecturas orientadas a servicios(SOA), por el que un componente es convertido por el servicio web en un servicio y subsecuentemente hereda otras caractersticas ms all de las de un componente ordinario.

Uncomponente de softwareindividual es un paquete de software, un servicio web, o unmduloqueencapsulaun conjunto de funciones relacionadas (o de datos).Con respecto a la coordinacin a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, ste adopta una interface proporcionada que especifica los servicios que otros componentes pueden utilizar, y cmo pueden hacerlo. Esta interface puede ser vista como una firma del componente - el cliente no necesita saber sobre los funcionamientos internos del componente (su implementacin) para hacer uso de ella. Este principio resulta en componentes referidos comoencapsulados. Las ilustracionesUMLde este artculo representan a las interfaces proporcionadas, con un smbolo lollipop unido al borde externo del componente.

Fases de Ingeniera y Construccin y Accin de ste modelo por una sola fase de Construccin y adaptacin de la Ingeniera: Comunicacin con el cliente- Las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente.

Planificacin: Las tareas requeridas para definir recursos, el tiempo y otra informacin relacionadas con el proyecto. Anlisis de riesgos: Las tareas requeridas para evaluar riesgos tcnicos y de gestin.

Construccin y adaptacin de la Ingeniera

Evaluacin del cliente:Las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin.

Ventajas Rapidez Vlido para aplicaciones modularizables

InconvenientesExige conocer bien los requisitos y delimitar el mbito del proyecto Nmero de personasClientes y desarrolladores comprometidos Gestin riesgos tcnicos altosUso de nueva tecnologa Alto grado de interoperabilidad con sistemas existentes

Ejemplo:FrameworksLos Frameworks son artefactos de software especficamente diseados para promover la reutilizacin. Ms de sus propuestas generales e innovadoras han aparecido recientemente en la literatura, se centra en el uso de Frameworks para el desarrollo de sistemas de software.

Fairbanks et al proponer un mtodo para la especializacin de los Frameworks OO utilizando patrones de diseo, que proporciona un fragmento de diseo para el sistema como un todo. Un fragmento de diseo es una solucin probada a la forma en que el programa debe interactuar con el marco con el fin de realizar una funcin. La idea es que cada marco para tener su propio catlogo de fragmentos de diseo, ofreciendo soluciones convencionales a los problemas conocidos. La propuesta se valida con una herramienta basada en Eclipse que contiene ms de cincuenta modelos.

Antkiewicz et al ir un paso ms all al ofrecer un marco conceptual y metodolgico para la definicin y el uso de las lenguas-marco especfico de modelado (FSMLs). Un FSML es una representacin explcita de las caractersticas especficas de un dominio que ofrece el marco asociado. Por lo tanto, FSMLs se pueden utilizar para expresar modelos de aplicaciones-marco especfico. Estos modelos se describen los casos de las caractersticas proporcionadas por el marco que se implementan en ltima instancia en el cdigo de la aplicacin.

Algunos autores como Cervantes et defienden que los Frameworks deben ser considerados como conceptos de diseo de primera clase durante el diseo arquitectnico. Describen una aproximacin al diseo de la arquitectura donde los Frameworks aparecen directamente en los pasos del diseo atributo impulsada mtodo (ADD) utilizaron para llevar a cabo el diseo de aplicaciones. Es decir, que afirman que los Frameworks no deben ser relegados a las ltimas fases del proceso de desarrollo, sino ms bien ser considerados desde el principio.

Estas obras ilustran muy claramente las tendencias en el desarrollo de marco y, por tanto, deben tenerse en cuenta en cualquier propuesta en ese sentido. En resumen, los Frameworks basados en plataformas y lenguajes OO han escalabilidad y extensibilidad limitada debido a las restricciones impuestas por el uso de objetos [40]. Adems, los Frameworks basados en componentes mejoran la escalabilidad y extensibilidad, proporcionando mecanismos para facilitar la reconfiguracin dinmica de los componentes, incluso en tiempo de ejecucin. Por lo tanto, los Frameworks basados en componentes facilitan la integracin e interoperabilidad si se construyen de tal manera de dejar espacio suficiente para futuras ampliaciones de la adicin de nuevos componentes.

Como resumen de esta seccin, la investigacin presentada en este documento contribuye al estado actual de la tcnica proporcionando una novedosa combinacin sinrgica de modelos, componentes, y los Frameworks en los que tenemos lo siguiente.a) El modelado de las aplicaciones es estrictamente CBSE. El modelador no necesita saber todos los detalles de la implementacin del modelo de componentes, ya que estos detalles sern parte del marco seleccionado que eventualmente apoyar la plataforma.b) La propuesta es apoyada por la tecnologa MDSD. El uso de modelos, as como el aumento del nivel de abstraccin, hace posible la integracin de otros modelos para llevar a cabo la validacin temprana y actividades de verificacin y de posponer la eleccin de las caractersticas de la plataforma, dadas las posibilidades de generacin automtica de cdigo.c) La aplicacin es apoyada por la reutilizacin de los Frameworks. El desarrollador percibe cada marco de un punto de vista puramente conceptual a travs del conjunto de caractersticas que lo definen. Estas caractersticas pueden ser instanciadas como parte del proceso de especializacin marco. Por lo tanto, la eleccin del marco depender del conjunto de caractersticas que ofrece (por ejemplo, componentes distribuidos en oposicin a un esquema centralizado, diseos de comunicacin, etc.). La seleccin de la plataforma de destino se pospone hasta lo ms tarde posible.d) La complejidad est oculta a los desarrolladores. El desarrollador de aplicaciones vistas cada marco como un conjunto de "puntos calientes" que se pueden rellenar desde el modelo de componentes de arquitectura de la aplicacin. Las transformaciones automatizadas de modelo a modelo de MDSD ocultan la complejidad del marco del desarrollador. Esta es una ventaja considerable ya que la curva de aprendizaje asociada con los Frameworks es generalmente larga.

Diagrama

Referencias:http://ith-gabriel.blogspot.mx/http://es.slideshare.net/martincito123/modelo-componenteshttp://itpn.mx/recursosisc/6semestre/ingenieriadesoftware/Unidad%20II.pdfhttp://www.hindawi.com/journals/tswj/2014/687346/