• Author / Uploaded
• Chava Martinez

• Categories
• Arquitectura orientada a Servicios
• Marco de software
• Software
• Ingeniería de software
• Informática

Citation preview

2.1.6 Desarrollo Componentes

Basado

En

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 subdisciplina 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 vista como una firma del componente - el cliente no necesita saber sobre los funcionamientos internos del componente (su implementación) para hacer uso de ella. Este principio resulta en componentes referidos como encapsulados. Las ilustraciones UML de este artículo representan a las interfaces proporcionadas, con un símbolo lollipop unido al borde externo del componente. Fases de Ingeniería y Construcción y Acción de éste modelo por una sola fase de Construcción y adaptación de la Ingeniería:

-

Comunicación con el cliente-

Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. -

Planificación:

Las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto. -

Análisis de riesgos:

Las tareas requeridas para evaluar riesgos técnicos y de gestión. -

Construcción y adaptación de la Ingeniería

-

Evaluación del cliente:

Las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación. Ventajas •Rapidez • Válido para modularizables

aplicaciones

Inconvenientes •Exige conocer bien los requisitos y delimitar el ámbito del proyecto • Número de personas •Clientes y desarrolladores comprometidos • Gestión riesgos técnicos altos •Uso de nueva tecnología • Alto grado de interoperabilidad con sistemas existentes

Ejemplo: Frameworks Los Frameworks son artefactos de software específicamente diseñados para promover la reutilización. Más 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 método para la especialización de los Frameworks OO utilizando patrones de diseño, que proporciona un fragmento de diseño para el sistema como un todo. Un fragmento de diseño es una solución probada a la forma en que el programa debe interactuar con el marco con el fin de realizar una función. La idea es que cada marco para tener su propio catálogo de fragmentos de diseño, ofreciendo soluciones convencionales a los problemas conocidos. La propuesta se valida con una herramienta basada en Eclipse que contiene más de cincuenta modelos. Antkiewicz et al ir un paso más allá al ofrecer un marco conceptual y metodológico para la definición y el uso de las lenguas-marco específico de modelado (FSMLs). Un FSML es una representación explícita de las características específicas de un dominio que ofrece el marco asociado. Por lo tanto, FSMLs se pueden utilizar para expresar modelos de aplicaciones-marco específico. Estos modelos se describen los casos de las características proporcionadas por el marco que se implementan en última instancia en el código de la aplicación. Algunos autores como Cervantes et defienden que los Frameworks deben ser considerados como conceptos de diseño de primera clase durante el diseño arquitectónico. Describen una aproximación al diseño de la arquitectura donde los Frameworks aparecen directamente en los pasos del diseño atributo impulsada método (ADD) utilizaron para llevar a cabo el diseño de aplicaciones. Es decir, que afirman que los Frameworks no deben ser relegados a las últimas fases del proceso de desarrollo, sino más 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]. Además, los Frameworks basados en componentes mejoran la escalabilidad y extensibilidad, proporcionando mecanismos para facilitar la reconfiguración dinámica de los componentes, incluso en tiempo de ejecución. Por lo tanto, los Frameworks basados en componentes facilitan la integración e interoperabilidad si se construyen de tal manera de dejar espacio suficiente para futuras ampliaciones de la adición de nuevos componentes.

a)

b)

c)

d)

Como resumen de esta sección, la investigación presentada en este documento contribuye al estado actual de la técnica proporcionando una novedosa combinación sinérgica de modelos, componentes, y los Frameworks en los que tenemos lo siguiente. El modelado de las aplicaciones es estrictamente CBSE. El modelador no necesita saber todos los detalles de la implementación del modelo de componentes, ya que estos detalles serán parte del marco seleccionado que eventualmente apoyar la plataforma. La propuesta es apoyada por la tecnología MDSD. El uso de modelos, así como el aumento del nivel de abstracción, hace posible la integración de otros modelos para llevar a cabo la validación temprana y actividades de verificación y de posponer la elección de las características de la plataforma, dadas las posibilidades de generación automática de código. La aplicación es apoyada por la reutilización de los Frameworks. El desarrollador percibe cada marco de un punto de vista puramente conceptual a través del conjunto de características que lo definen. Estas características pueden ser instanciadas como parte del proceso de especialización marco. Por lo tanto, la elección del marco dependerá del conjunto de características que ofrece (por ejemplo, componentes distribuidos en oposición a un esquema centralizado, diseños de comunicación, etc.). La selección de la plataforma de destino se pospone hasta lo más tarde posible. 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 aplicación. 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-componentes http://itpn.mx/recursosisc/6semestre/ingenieriadesoftware/Unidad%20II.pdf http://www.hindawi.com/journals/tswj/2014/687346/