Software Reutilizable

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 1

Objetivos 





 

Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir las diferentes formas de implementar el software reutilizable Para explicar cómo los conceptos reutilizables pueden ser representados como patrones o incrustados en generadores de programas Para hablar sobre la reutilización de COTS (cuna) Para describir el desarrollo de líneas de producto de software ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 2

Los temas Cubiertos     

El campo de la reutilización Los patrones de diseño Reutilización basado en generador Los marcos de aplicación Sistema de reutilización de aplicaciones

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 3

La Reutilización del Software 



En la mayoría de las disciplinas de ingeniería, los sistemas han sido diseñados por la composición de componentes existentes que han sido utilizados en otros sistemas. La ingeniería del software ha estado más centrada en el desarrollo original, pero actualmente se reconoce que para lograr un software mejor, más rápidamente y a menor costo, tenemos que adoptar un proceso de diseño que se basa en la reutilización del software sistemático.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 4

Reutilización Basada en Ingeniería de Software Sistema de reutilización de aplicaciones



•

El conjunto de un sistema de aplicación puede ser reutilizado, ya sea por su incorporación sin cambios en otros sistemas (reutilización de COTS) o mediante el desarrollo de las familias de aplicación.

La reutilización de componentes



•

Componentes de una solicitud de sub-sistemas a los objetos solo se pueden reutilizar. Cubierto en el Capítulo 19.

La reutilización de objetos y la función



•

Los componentes de software que implementan un objeto único y bien definido o función pueden ser reutilizados.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 5

Beneficios de la Reutilización 1 





Mayor fiabilidad: Software reutilizados, que han sido probados en sistemas de trabajo, deben ser mas confiables que el nuevo software. El uso inicial del software revela cualquier avería del diseño y de la puesta en práctica. Éstos entonces están fijados, así reduciendo el número de faltas cuando se reutiliza el software. Proceso de reducción de riesgos: Si existe el software, hay menos incertidumbre en los costes de la reutilización que el software que en los costes de desarrollo. Este es un factor importante para la gestión de proyectos, ya que reduce el margen de error en la estimación de costes del proyecto. Esto es particularmente cierto cuando se vuelven a utilizar los componentes de software relativamente grandes, tales como sub-sistemas. El uso eficaz de los especialistas: En lugar de especialistas en aplicaciones haciendo el mismo trabajo en diferentes proyectos, estos especialistas pueden desarrollar software reutilizables que encapsulan sus conocimientos. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 6

Beneficios de la Reutilización 2 • Cumplimiento de las normas: Algunas normas, como las normas de interfaz de usuario, puede ser implementadas como un conjunto de componentes estándar reutilizables. Por ejemplo, si los menús en un interfaz de usuario se implementan utilizando componentes reutilizables, todas las aplicaciones presentes en el mismo menú se ajustan en formatos para los usuarios. El uso de interfaces de usuario estándar mejora fiabilidad, los usuarios son menos propensos a cometer errores cuando se presenta una interfaz familiar. •El desarrollo acelerado: Llevar un sistema de mercado tan pronto como sea posible es muchas veces más importante que el coste global de desarrollo. La reutilización de software puede acelerar la producción de sistema, porque el desarrollo y la validación en tiempo debe reducirse.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 7

Problemas de Reutilización 1 Aumento de costes de mantenimiento: Si el código fuente de un sistema de software reutilizable o componente no está disponible, los costos de mantenimiento podrán incrementarse, los elementos reutilizados del sistema puede llegar a ser cada vez más incompatibles con los cambios del sistema. La falta de herramienta de apoyo: Conjuntos de herramientas CASE no puede apoyar el desarrollo con reutilización. Puede ser difícil o imposible integrar estas herramientas con un sistema de biblioteca de componentes. El proceso de software asumido por estas herramientas no puede tomar en cuenta la reutilización. Síndrome No inventado: Algunos ingenieros de software a veces prefieren volver a escribir componentes, ya que creen que pueden mejorar los componentes reutilizables. Esto es en parte tiene que ver con la confianza y con el hecho de que el software original de la escritura es vista como más difícil que la reutilización de software de otras personas.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 8

Problemas de Reutilización 2 •Crear y mantener una biblioteca de componentes: Llenar una biblioteca de componentes reutilizables y garantizar a desarrolladores de software el uso esta biblioteca puede ser costoso. Nuestras técnicas actuales para la clasificación, catalogación y recuperación de componentes de software son inmaduros. •Encontrar, la comprensión y la adaptación de componentes reutilizables: Los componentes de software tienen que ser descubiertos en una biblioteca, ser entendidos y, ser adaptados a veces al trabajo en un nuevo entorno. Los ingenieros deben estar razonablemente seguros de encontrar un componente en la biblioteca antes de que hagan rutinariamente una búsqueda para incluir un componente como parte de su proceso normal del desarrollo.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 9

El Campo de la Reutilización 





Aunque la reutilización es a menudo simplemente considerada como la reutilización de los componentes de un sistema, hay muchos enfoques diferentes para la reutilización que pueden ser utilizados. La reutilización es posible en un rango de niveles de funciones simples para completar los sistemas de aplicación. El campo de la reutilización cubre la gama de técnicas de reutilización posible. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 10

El Campo de la Reutilización

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 11

Enfoques de Reutilización 1 • Los patrones de diseño: Abstracciones genéricas que se producen en todas las aplicaciones son representados como patrones de diseño que muestran los objetos abstractos y concretos y de las interacciones. • Desarrollo basado en componentes: Los sistemas se desarrollan mediante la integración de componentes (colecciones de objetos) que se ajusten a las normas de componentes del modelo. Esto se trata en el capítulo 19. • Los marcos de aplicación: Colecciones de clases abstractas y concretas que pueden ser adaptadas y ampliadas para crear sistemas de aplicación. • Envoltura de sistemas heredados: Los sistemas heredados (véase el capítulo 2) que pueden ser "envueltos por la definición de un conjunto de interfaces y el acceso a estos sistemas de legado a través de estas interfaces. • Servicio de sistemas orientados: Los sistemas se desarrollan mediante la vinculación de los servicios compartidos que pueden ser proporcionados externamente.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 12

Enfoques de Reutilización 2 • Líneas de aplicación de productos: Un tipo de aplicación es generalizada en torno a una arquitectura común para que pueda adaptarse en diferentes formas para diferentes clientes. • Integración de COTS: Los sistemas se desarrollan mediante la integración de los sistemas de aplicación existentes. • Aplicaciones verticales configurables: Un sistema genérico está diseñado de manera que se puede configurar para las necesidades de clientes específicos del sistema. • Generadores de programas: Un sistema de generador encaja el conocimiento del los tipos particulares de aplicaciones y puede generar sistemas o fragmentos del sistema en ese dominio • Aspecto de desarrollo de software orientado: Los componentes compartidos se entretejen en una aplicación en diferentes lugares cuando se compila el programa. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 13

Los Factores de Planificación en la Reutilización   



 

El calendario de desarrollo del software. La expectativa del tiempo de vida del software. Los antecedentes, aptitudes y experiencia del equipo de desarrollo. La criticidad del software y sus requisitos no funcionales. El dominio de la aplicación. La plataforma de ejecución para el software.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 14

Concepto de Reutilización Cuando vuelves a utilizar un programa o diseño de componentes, tienes que seguir las decisiones de diseño realizados por el desarrollador original del componente. Esto puede limitar las posibilidades de reutilización. Sin embargo, una forma más abstracta de reutilización es la reutilización de concepto cuando se describe un enfoque particular en una implementación de manera independiente y la implementación es, a continuación, desarrollada. Los dos enfoques principales para el concepto de reutilización son:



 



• •

Los patrones de diseño; Programación Generativa.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 15

Los Patrones de Diseño 







Un patrón de diseño es una forma de reutilizar el conocimiento abstracto acerca de un problema y su solución. Un patrón es una descripción del problema y la esencia de su solución. Debe ser lo suficientemente abstracto para ser reutilizado en diferentes entornos. Los patrones a menudo se basan en las características de objetos como la herencia y polimorfismo. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 16

Elementos del Patrón 

Nombre •

 

Descripción del problema. Descripción de la solución. •



Un identificador de modelo significativo.

No un diseño concreto sino una plantilla para una solución del diseño que puede ser instanciado de diversas maneras.

Consecuencias •

Los resultados, las ventajas y desventajas de aplicar el modelo.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 17

Múltiples Pantallas 50 D A

25

C

A

B

B

C

D

0

Tema Observador 1

©Ian Sommerville 2004

A: 40 B: 25 C: 15 D: 20

Observador 2

Software Engineering, 7th edition. Chapter 18

Slide 18

El Patrón Observador 

Nombre •









Observador

Descripción • Separa la pantalla de estado del objeto, del objeto en sí. Descripción del problema • Se utiliza cuando se necesitan múltiples pantallas de estado. Descripción de la solución • Véase la descripción de diapositivas con UML. Consecuencias • Optimizaciones para mejorar el rendimiento de visualización no son prácticos.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 19

El Patrón Observador

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 20

Reutilización Basada en Generador 







Los generadores de programa implican la reutilización de patrones y de algoritmos estándares. Éstos se encajan en el generador y son parámetrizados por comandos del usuario. Un programa entonces se genera automáticamente. La reutilización basada en generador es posible cuando las abstracciones del dominio y su asignación al código ejecutable puede ser identificado. Una lenguaje específico del dominio se utiliza para componer y controlar estas abstracciones.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 21

Tipos de Generadores de Programa 

Tipos de generadores de programa • • •





Generadores de aplicaciones para procesamiento de datos de negocios; Analizador y generadores de analizadores léxicos para el procesamiento de lenguaje; Generadores de código en las herramientas CASE..

Un Generador basado en la reutilización es muy rentable, pero su aplicabilidad se limita a un número relativamente pequeño de dominios de aplicación. Es más fácil que los usuarios finales desarrollen programas usando los generadores en comparación con el otro componente de los enfoques basados en la reutilización. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 22

Reutilización a Través del Generador de Programa

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 23

Desarrollo de Aspecto-Orientado 





El desarrollo Aspecto-orientado trata un problema importante de la tecnología de dotación lógica - la separación de preocupaciones. Las preocupaciones no se asocian a menudo simplemente funcionalidad de la aplicación, pero son transversales - por ejemplo, todos los componentes pueden controlar su propio funcionamiento, todos los componentes pueden tener para mantener la seguridad, etc. Cuestiones intersectoriales se implementan como los aspectos y se tejen dinámicamente en un programa. El código de preocupación es la reutilización y el nuevo sistema es generado por el tejedor del aspecto. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 24

Desarrollo de Aspecto-Orientado

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 25

Los Marcos de Aplicación 





Los marcos son un sub-diseño del sistema compuesto por una colección de clases abstractas y concretas, y las interfaces entre ellas. El sub-sistema es implementado por la adición de componentes para rellenar las partes del diseño y de instancias de las clases abstractas en el marco. Los marcos son moderadamente grandes entidades que pueden ser reutilizados.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 26

Clases de Marco Los marcos de la infraestructura del sistema



•

Apoyar el desarrollo del sistema de infraestructuras tales como las comunicaciones, interfaces de usuario y compiladores.

Los marcos de integración de middleware



•

Estándares y clases que apoyan la comunicación de componentes y el intercambio de información.

Marcos de aplicaciones de empresa



•

Apoyar el desarrollo de determinados tipos de aplicaciones como las telecomunicaciones o sistemas financieros.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 27

Ampliación de los Marcos 



Los Marcos son genéricos y se extienden para crear un uso o un subsistema más específico. La ampliación del marcos consiste en: • •



Adición de clases concretas que heredan las operaciones de las clases abstractas en el marco; Agregando los métodos que se llaman en respuesta a los acontecimientos que son reconocidos por el marco.

Problema con los marcos es su complejidad lo que significa que se necesita mucho tiempo para utilizarlos con eficacia.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 28

Modelo-Vista-Controlador 





Marco de la infraestructura del sistema para el diseño GUI. Permite la presentación múltiple de un objeto y las interacciones por separado con estas presentaciones. Marco MVC implica la creación de instancias de una serie de patrones (como se explica anteriormente en concepto de reutilización).

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 29

Modelo-Vista-Controlador

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 30

Reutilización de Sistemas de Aplicación 



Consiste en la reutilización de los sistemas de aplicación completa, ya sea por la configuración de un sistema para un ambiente o por la integración de dos o más sistemas para crear una nueva aplicación. Dos enfoques cubiertos aquí: • Integración de productos COTS; • Desarrollo de la línea de productos.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 31

Reutilización de los Productos COTS  





COTS - Commercial Off-The-Shelf systems. Sistemas COTS suelen completar los sistemas de aplicación que ofrece un API (Application Programming Interface). La creación de sistemas mediante la integración de grandes sistemas COTS es ahora una estrategia de desarrollo viable para algunos tipos de sistema, tales como sistemas de comercio electrónico. El beneficio clave es el rápido desarrollo de aplicaciones y, por lo general, menores costos de desarrollo.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 32

Opciones de Diseño COTS 





Que productos COTS ofrecen la funcionalidad más adecuada? • Puede haber varios productos similares que pueden ser utilizados. ¿Cómo se intercambiarán los datos? • Los productos individuales utilizan sus propias estructuras y formatos de datos. ¿Qué características del producto serán utilizadas realmente? • La mayoría de los productos tienen más funcionalidad que la necesaria. Usted debe intentar negar el acceso a la funcionalidad inusitada ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 33

Sistema de E-Adquisiciones

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 34

Productos COTS Reutilizados 



En el cliente, se utilizan los programas estándares de correo electrónico y navegación web En el servidor, una plataforma de comercio electrónico tiene que ser integrado con un sistema de pedidos existentes. • •

Se trata de la escritura de un adaptador para que puedan intercambiar datos. Un sistema de correo electrónico está también integrado para generar e-mail para los clientes. Esto también requiere un adaptador para recibir datos desde el sistema de pedidos y facturación.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 35

Problemas de Integración del sistema COTS 

La falta de control sobre la funcionalidad y el rendimiento •



Problemas con el sistema de inter-operabilidad COTS •



Diversos sistemas de los COTS pueden hacer diversas asunciones que significa que la integración es difícil

Ningún control sobre la evolución del sistema •



Sistemas COTS pueden ser menos eficaces de lo que parecen

Proveedores de COTS no controlan la evolución de los usuarios del sistema

Soporte de los proveedores de COTS •

COTS vendedores no pueden ofrecer apoyo durante la vida útil del producto

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 36

Líneas de Productos de Software 



Las líneas de productos o familias de aplicaciones de software son aplicaciones con una funcionalidad genérica que puede ser adaptada y configurada para su uso en un contexto específico. La adaptación puede implicar: • Componentes y la configuración del sistema; • Adición de nuevos componentes para el sistema; • Selección de una biblioteca de componentes ya existentes; • Modificación de los componentes para satisfacer las nuevas necesidades.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 37

Especialización de Productos COTS 

Especialización de la Plataforma •



Especialización para el Entorno •



Diferentes versiones de la aplicación son creadas para gestionar entornos operativos diferentes, por ejemplo diferentes tipos de equipos de comunicación.

La especialización funcional •



Diferentes versiones de la aplicación se han desarrollado para diferentes plataformas.

Diferentes versiones de la aplicación se crean para clientes con diferentes necesidades.

Proceso de especialización •

Diferentes versiones de la aplicación se crean para apoyar los procesos de negocio diferentes.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 38

Configuración de COTS 

Configuración del tiempo de despliegue •



Un sistema genérico se configura mediante la inserción de conocimiento de las necesidades del cliente y procesos de negocio. El software en sí no cambia.

Configuración del tiempo del diseño •

Un código genérico común se adapta y cambia de acuerdo a las necesidades de los clientes en particular.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 39

La Organización del Sistema de ERP

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 40

Los Sistemas ERP 





Un sistema de planificación de recursos empresariales (ERP) es un sistema genérico que apoya los procesos de negocio comunes, tales como pedidos y facturación, fabricación, etc. Estos son muy utilizados en las grandes empresas - que representan probablemente la forma más común de la reutilización del software. El núcleo genérico se adapta mediante la inclusión de módulos y mediante la incorporación de conocimiento de los procesos de negocios y reglas. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 41

Configuración del Tiempo del Diseño 

Líneas de productos de software que se configuran en tiempo de diseño son instancias de aplicación de arquitecturas genéricas como se discutió en el capítulo 13.



Los productos genéricos suelen surgir después de la experiencia con productos específicos.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 42

Línea de Productos de Arquitecturas 

Las arquitecturas deben estar estructuradas de tal manera de separar los diferentes subsistemas para que puedan ser modificados.



La arquitectura debe también separar entidades y sus descripciones, y los niveles más altos en las entidades del sistema de acceso a través de las descripciones en lugar de hacerlo directamente.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 43

Un Sistema de Gestión de los Recursos

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 44

Despachando Vehículos 



Un sistema especializado de gestión de los recursos, donde el objetivo es asignar los recursos (vehículos) para manejar incidentes. Las adaptaciones incluyen: • •

•

•

A nivel de interfaz de usuario, hay componentes de visualización del operador y las comunicaciones; En la gestión de niveles de I/O, hay componentes que se encargan de la autenticación, la presentación de informes y planificación de ruta; A nivel de gestión de recursos, hay componentes de localización de vehículos y el envío, la gestión de estado del vehículo y el registro de incidentes; La base de datos incluye los equipos, vehículos y bases de datos de mapa.

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 45

Un Sistema de Despacho

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 46

Desarrollo del Caso del Producto

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 47

Desarrollo del Caso del Producto 

Obtenga necesidades de los interesados •



Elige al miembro mas cercano de la familia •



Adaptar los requisitos que sean necesarios para las capacidades del software

Adaptar el sistema existente •



Encuentre el miembro de la familia que mejor se adapte a los requisitos

Re-negociar los requisitos •



Utilice a un miembro existente de la familia como prototipo

Desarrolle los módulos nuevos y realice los cambios para el miembro de la familia

Entregue a nuevo miembro de la familia •

Características dominantes del documento para el desarrollo adicional del miembro

©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 48

Puntos Claves 







Ventajas de la reutilización son menores costos, desarrollar software de forma más rápida y reducir riesgos. Los patrones del diseño son las abstracciones de alto nivel que documentan soluciones acertadas del diseño. Generadores de programas también están preocupados con la reutilización del software - los conceptos reutilizables están integrados en un sistema generador. Los marcos de aplicación son colecciones de objetos concretos y abstractos que se han diseñado para su reutilización a través de la especialización. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 49

Puntos Claves 







Reutilización de productos COTS se refiere a la reutilización de los grandes, fuera de los sistemas comerciales. Problemas con la reutilización de COTS incluyen la falta de control sobre la funcionalidad, el rendimiento y la evolución y los problemas con la inter-operación. Los sistemas ERP son creados por la configuración de un sistema genérico, con información sobre el negocio de un cliente. Las líneas de productos de software están relacionados con las aplicaciones desarrolladas en torno a un núcleo común de funcionalidad compartida. ©Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 18

Slide 50