Managing Variability in Software Architectures

1
Managing Variability in Software Architectures

• Area Software Reuse
• Source Symposium on Software Reusability
  Proceedings of the 2001 symposium on Software
  reusability putting software reuse in context
  Toronto, Ontario, Canada Pages 126 - 132   Year
  of Publication 2001 ISSN0163-5948
• Authors Felix Bachmann, Len Bass
• Presented by Nivritha Gopathi

2
Software Reuse

• Important software attribute permitting
  individual software components from one system to
  be incorporated into other systems to perform a
  reusable function.
• One of the simplest and oldest programming
  concepts.
• Saves time, money as well as create an inventory
  of valuable and reusable software assets.
• Effective in achieving higher productivity
  improvement.

3
Software Reuse

• In 1960s, reuse of well-defined algorithms to
  develop reusable scientific subroutine libraries.
  Had limited domain of application.
• Now, view of reuse extended to encompass
  algorithms and data structures i.e. encapsulates
  data and processing in a single package (often
  called a class or object).
• Enables creation of new applications from
  reusable parts.

4
Managing Variability in Software Architectures

• Variability - Ability to change or customize a
  software system.
• Goals of identifying and preparing software for
  change -
• To delay design decisions (promoting
  reuse).
• To minimize efforts required for
  maintenance.

5

• In architectures used for different product
  versions, it is important to understand where
  change has to be planned and options possible to
  handle it.
• An architect will try to predict likely changes
  and encapsulate the change in a single component.
  
• (strong cohesion and loose coupling used for
  other components)

6
Trends

• Where to handle variability
• - Traditional at/before requirement
  specification.
• - Current architecture/implementation
  level.
• - Future at run-time.

7
Causes of variability

• Representing different possibilities within an
  architecture required
• During design (to defer design decisions).
• For dealing with variation among products
  (capturing alternatives and the rationale for
  each, gives a list of solutions to choose from)
• Alternatives are best captured in context to the
  rest of the architecture and so, the architecture
  representation, itself, should support
  variability.

8
Causes of variability

• Variation in function - A function may exist in
  some products and not in others.
• Example A car radio/navigation system
  within an automobile.
• Variation in data A particular data structure
  may vary from one product to another.
• Example Information exchange between two
  components in a call center.
• Variation in data is a consequence of
  variation in function.

9
Causes of variability

• Variation in control flow A particular pattern
  of interaction may vary from one product to
  another.
• Example Notification mechanisms between
  components.
• Variation in technology The OS or the hardware
  may vary from product to product.
• A piece of middleware may be required in one
  product and not in another.
• Example A sensor may be connected directly
  to the controller of the software being designed
  or connected over a connection line.

10
Causes of variability

• Variation in quality goals The particular
  quality goals important for a product may vary.
• Example Choice of importance of
  performance and modifiability.
• Variation in environment The fashion in which a
  product interacts with its environment may vary.
• Example The invocation mechanism varies from
  one product to another (A particular piece of
  middleware invoked from C or Java).

11
Types of variation

• Optional
• An instance out of several alternatives
• A set of instances out of several alternatives.

12
Putting Variation in Context

• Variation in architecture
• Two products with modules related by
  depends on relationship.

Module A
Module B
Module A
Module D
Product 1
Product 2
Module C
Module C
13

• To support the variation in the two products, the
  two diagrams are collapsed into one.

Variant A
Module A
Variant A
realize
Module B
Module D
Module C
Alternatives for variant A
14

• Variation of relation

Module A
Module B
Module A
Module B
Display Station name
Display frequency
Module C
Module C
Product 2
Product 1
15

• Variation of relation as variation of components

Module A
Variant A 1
Variant B 1
16

• Constraints between alternatives for variants

Module D
Variant A
Display
Module B
Module C
Display
Variant B
Module E
17

• Decomposition of Variant A

Module A1
Variant A1
with
Variant A1 1
realize
Module A3
Module A4
Module A2
18
Different types of variants
Variant C 1..
Set of Alternatives
Variant A 0
Optional
Variant D 0..1
Optional Alternatives
Variant B 1
Alternative
Variant E 0..
Optional set of alternatives
19

• Basic problem statement

Module A
Variant A 1
Variant B 1
20
Relations from and to Variants

• Relations between variants and modules important
  if the architecture is designed to support
  change.
• Changing the variants influences the relations
  among those variants and modules.
• Relations from variant to module are easy to
  handle.

21
Relations from and to Variants

• Difficulties arise with relations that point to a
  variant.
• Simplest case Alternative variant.
• All implementations of the variant must
  comply with the interface required by the
  relation.
• Optional variant All relations to this variant
  must be optional.

22
Relations from and to Variants

• One method - two different implementations of
  the module that uses the optional variant. But,
  results in ripple effect.
• Another solution Adaptation during development
  time using techniques like generators or compiler
  switches. Hide adaptation on architecture level.

23
Relations from and to Variants

• Set of alternatives Modules using this set have
  to deal with a varying set of implementations.
  Requires some sort of a distribution mechanism.
• The distributor can be
• -a part of the module requesting service
• -separate module between the module and the
  set
• -a wrapper around the set.

24
Connection to requirements

• Representation of variations in the
  documentation.
• Done by introducing variation points.
• Variation points build connection between
  customers requirements (where variation can
  occur) and places in the architecture designed to
  support these variations.

25
Connection to requirements

• Variation points contain information needed to
  build the required architecture for a product.

Module B
Display Frequency
Module C
Display Station
Module D
Display Station Name
Module E
26
Connection to requirements

• Documentation of variation points is a part of
  architecture documentation.
• Build the link between the requirements document
  and architecture description.
• Variation points can be a part of the
  requirements document, architecture document, or
  could be a separate document.

27
Implementations of Variations

• Two basic implementation techniques
• Module replacement
• Data Controlled variation
• Module replacement
• Having multiple code-based versions of a
  module and choosing the correct one.
• The interfaces to all the versions of the
  module are compatible.
• The choice can be made at execution time or
  at an earlier time.

28
Data Controlled Variation

• Maintain a variation information in a data
  structure.
• Module that understands the data structure
  determines the correct actions.
• Module remains unchanged from variant to variant
  but the data on which it operates will control
  the variant.

29
Realization mechanisms

• Generators
• Configuration Management System
• Compilation
• Adaptation during start-up
• Adaptation during normal execution

30
Conclusion

• Potential for variation realized by an explicit
  link between the requirement analysis and the
  architecture development.
• Explicit design of variants and definition of
  variation points enables developers to full
  employ designed variations.
• Requires tool support in an industrial
  environment.
• Not sufficient to support the described variation
  points.

31
References

• Jan Bosch, Design Use of Software
  Architectures,
• Addison Wesley, 2000.
• Paul Clements and Linda Northrop, A Framework for
  Software Product Line Practice Version 3.0.
• http//www.sei.cmu.edu/plp/framework.html.
• Michael Coriat, Jean Jourdan, Fabien Boisbourdin,
  The
• SPLIT Method, Software Product Lines, Kluwer
  Academic
• Publishers, August 2000 147-166.
• Software Engineering Roger S. Pressman.
• http//www.eesi.tue.nl/colloquia/ppt/271,18,Variab
  ility