Product Line Architectures
Len Bass, Sholom Cohen, Linda Northrop
Software Engineering Institute
Pittsburgh, Pa USA
The Product Line Systems Program was created at the Software Engineering Institute (SEI) in Dec, 1995 in order to: select, refine, and establish practices of demonstrated effectiveness for creating software product lines in different domains and organizational contexts.
There are several different dimesnions of the technical work of the Product Line Systems Program. This paper focusses on the relationship between product lines and software architectures. We believe that the software architecture for a product line is fundamental in achieving overall system quality goals and our program strategy reflects that belief.
We begin this paper by presenting our strategy for product line architectures and continue by discussing the implications of that strategy on the achievement of specific quality goals.
STRATEGY
We are primarily interested in product lines of systems that exhibit similar structure as well as similar functionality (as opposed to just similar functionality). The foundation for common structures in such systems is a software architecture and reusable components that are developed within the framework of that architecture. In this way, both the architecture and the components can be reused when developing a new variant within the product line.
Developers of a product line must decide which software qualities they wish instances of that product line to exhibit. Flexibility in both functionality and platform are two that must be included since that, in essence, is our definition of what it means to be a product line. Other qualities, such as security, will depend on the goals of the product line. We are focussing on software qualities and how they relate to and are realized by software architectures.
There are four aspects of software architecture on which we focus in this work: identifying context and extent of variation among the instances; software architectural types used in an architecture and their interconnection mechanisms; division of operational functionality among software architectural types; and the coordination model used among the architectural types.
In the remainder of this paper we discuss how modifiability, portability and variability can be achieved and evaluated within a software architecture and we discuss a large case study that demonstrates the points we are making. In an expanded paper, we would also discuss the achievement and evaluation of other qualities.
MODIFIABILITY, PORTABILITY and VARIABILITY
It is important to understand the limitations of abstract qualities such as modifiability (a change in operational capability for a single system), portability (a change in platofrm for a single system), and variability (changes in platform and operational capabilities across multiple systems). Regardless of the architecture for a system, some modifications will be easy to perform and others will be difficult. A system is always modifiable with respect to the modifications that are easy. The difficult problem is to anticipate the type of modifications that might be made and then tailor the design to simplify these modifications. The SEI has developed several methods to determine these qualities from specific examples.
Variability
To determine variability, a domain analysis technique called Feature Oriented Domain Analysis (FODA) [2] is used. FODA is used to understand and anticipate the types of changes likely to occur. For example, we seek to classify operations as mandatory, optional or alternative. We may not design for all options or alternatives but recognizing their potential will affect architectural decisions. We also want to understand the rationale for variations (called context features in FODA). These features highlight variation among users and uses. For the flight simulators discussed in our case study, this might be engineering simulations versus flight crew trainers versus maintenance trainers. For other systems it might include levels of sophistication of the user or degrees of networking or system distribution.
Modifiability and Portability
To assess the modifiability and portability of an architecture, a technique named Software Architecture Analysis Method(SAAM) [1] is used. This technique depends on generating scenarios that represent likely modifications or platform changes. The scenarios should represent changes proposed by all stake-holders not just end users. The types of portabilities that are important are also considered. In our flight simulator case study, the types of platform changes anticipated were both hardware (processor, number of processors, type of shared memory) and software (operating system, window system).
CASE STUDY
We have evolved these techniques and ideas through participation and analysis of actual large systems. Our experience with flight simulators, for example, extends back almost a decade and covers multiple different systems as large as 1.5 million lines of code. It has resulted in an architecturally based development practice called Structural Modelling used by the US Air Force when
acquiring flight simulators [3].
The development practice is based on using a particular architectural style to constrain an object based decomposition strategy. We discuss first the architectural style and then the decomposition strategy as constrained by the architectural style.
Architectural Style for Flight Simulators
A large flight simulator has three major logical components: the simulation of the air vehicle that the crew uses for training, the instructor station that enables an instructor in control events that affect the air crew training and the environment that simulates other aircraft, environmental conditions such as turbulence and threat situations such as missile firings.
The air vehicle, typically, is simulated using periodic time based techniques, the instructor station operates on an event basis and the environment can be simulated either periodically or in an event based fashion depending on fidelity and number of different elements in the environment. We will discuss the air vehicle portion of the simulation.
The architectural style used in the air vehicle has two main portions: the executive controls the passage of time, the coordination of periodic
scheduling with the events that come and are sent to the other portions of the simulations, the mapping of software to hardware and the movement of data to and from the various instances of the application architectural types. The application controls the operational functionality of the air vehicle.
Portability considerations are very clearly isolated in the executive. Virtual
layers provide insulation against changes in either hardware or software
platforms. The rationale for placing data movement control in the executive,
for example, is that this allows either reflective memory or a different
memory sharing technique to be used. It also masks the number of processors
from the application.
At the application level, there are only two architectural types. This
restriction will become important both when we discuss decomposition strategy
and when we discuss the communication restrictions. The two architectural
types are: subsystem controllers and components. Components are subsidiary to
subsystem controllers. That is, each component is a component of a subsystem
controller. This yields a two deep hierarchy.
Subsystem controllers are allowed to communicate either with other subsystem
controllers or with their subsidiary components. They are not allowed to
communication directly with components subsidiary to another subsystem
controllers. Components are allowed to communicate only with their parent
subsystem controller.
Decomposition Strategy
The two deep hierarchy of architectural types limits the depth of
decomposition allowed. Within this limit, however, an object based strategy is
followed. That is, subsystems in the simulator are derived from subsystems in
the physical aircraft such as hydraulics, engines, etc. The components of a
subsystem are also derived from the physical aircraft within the constraint
that further decomposition is not possible. A hydraulic subsystem might have
two pump components, two valve components, etc.
Impact of Constraints
The constraints (two deep hierarchy and limited communication paths) enforce a
discipline intended to support both the quality of modifiability and also to
support template based development and the future development of a domain
specific language.
Modifications to the air vehicle are typically one of three types: either
movement to another platform, a modification that reflects a modification to
the aircraft being simulated, or a modification to add new operational
functionality or increase fidelity of a particular subsystem. Example of
adding new functionality include adding a new malfunction that the simulator
can accommodate to improve the training mission.
Of these types of modifications, movement to another platform is really a
portability consideration. A modification to the simulated aircraft is
accommodated by the physically based decomposition strategy and the limited
communication pattern. Since communication all goes through the subsystem and
since the subsystems mirror a physical system, modifications that reflect a
physical change are constrained in effect. Finally, malfunctions also mirror
physical situations such as a leak in a hydraulic system. Since the
decomposition, again, is physically based, such modifications are limited in
scope within the code for the air vehicle.
SUMMARY
The software architecture for flight simulators has been evolved and used
across several different large simulators. This reflects our strategy of
focussing on actual, large systems that have both common structure and common
functionality. We have emphasized our work on determining types of variation
in product lines and understanding the relationship between software
architecture and software qualities. In our future work, we intend to
investigate further the relationship between software architecture and
additional qualities and how software architectural based development
practices can be evolved to support product line efforts.
REFERENCES
1. Bass, L. and Howard, L. “Structural Modeling for Training Simulators”,
Proceedings 1993 Summer Computer Simulation Conference, Boston, Ma, July, 1993
pp876-881.
2. Kang, Kyo C.; Cohen, Sholom G.; Hess, James A.; Novak, William E.; Peter
son, A. Spencer. Feature-Oriented Domain Analysis (FODA) Feasibility Study
(CMU/SEI-90-TR-21). Pittsburgh, Pa: Software Engineering Institute, 1990.
3. Kazman, R., Abowd, G., Bass, L., and Clements, P. “Scenario-Based Analysis
of Software Architecture”, to appear IEEE Software, Nov, 1996.