Lcap18 - Reutilizacion de Software

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
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
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.
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.
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.
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.
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.

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.
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.

El Campo de la Reutilización
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.

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.
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.

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.
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.

Elementos del Patrón
 Nombre
• Un identificador de modelo significativo.
 Descripción del problema.
 Descripción de la solución.
• 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.
Múltiples Pantallas
50
D
A
25
C
A B C D
B 0
Tema
Observador 1 A: 40 Observador 2
B: 25
C: 15
D: 20

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.
El Patrón Observador

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.
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.
Reutilización a Través del Generador
de Programa
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.

Desarrollo de Aspecto-Orientado
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.

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.
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.

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).
Modelo-Vista-Controlador

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.
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.

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
Sistema de E-Adquisiciones

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.
Problemas de Integración
del sistema COTS
 La falta de control sobre la funcionalidad y el rendimiento
• Sistemas COTS pueden ser menos eficaces de lo que
parecen
 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
• 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
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.
Especialización de Productos COTS

 Especialización de la Plataforma
• Diferentes versiones de la aplicación se han desarrollado para
diferentes plataformas.
 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 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.
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.
La Organización del Sistema de ERP

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.
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.

Línea de Productos de Arquitecturas
 Las arquitecturas deben estar estructuradas

de tal manera de separar los diferentes sub-
sistemas 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.
Un Sistema de Gestión de los Recursos

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.
Un Sistema de Despacho

Desarrollo del Caso del Producto
Desarrollo del Caso del Producto

 Obtenga necesidades de los interesados
• Utilice a un miembro existente de la familia como prototipo
 Elige al miembro mas cercano de la familia
• Encuentre el miembro de la familia que mejor se adapte a los
requisitos
 Re-negociar los requisitos
• Adaptar los requisitos que sean necesarios para las capacidades
del software
 Adaptar el sistema existente
• 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
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.
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.

Lcap18 - Reutilizacion de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Lcap18 - Reutilizacion de Software

Cargado por

Copyright:

Formatos disponibles

Software Reutilizable

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

 Para explicar los beneficios del software

©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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 5

•El desarrollo acelerado: Llevar un sistema de mercado tan pronto

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 7

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 8

•Encontrar, la comprensión y la adaptación de componentes

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 9

 Aunque la reutilización es a menudo simplemente

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 10

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 11

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 12

Los Factores de Planificación

 El calendario de desarrollo del software.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 14

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 15

Los Patrones de Diseño

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 16

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 17

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 18

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 19

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 20

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 23

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 24

©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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 26

 Los marcos de la infraestructura del sistema

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 27

Ampliación de los Marcos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 28

 Marco de la infraestructura del sistema para el

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 29

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 30

 Consiste en la reutilización de los sistemas de

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 31

Reutilización de los Productos COTS

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 32

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 34

 En el cliente, se utilizan los programas estándares

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 35

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 37

Especialización de Productos COTS

 Configuración del tiempo de despliegue

©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

 Un sistema de planificación de recursos

Configuración del Tiempo del Diseño

 Líneas de productos de software que se

 Los productos genéricos suelen surgir

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 42

 Las arquitecturas deben estar estructuradas

 La arquitectura debe también separar

©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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 46

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 47