Documente Academic
Documente Profesional
Documente Cultură
www.elsevier.nl/locate/micpro
Abstract
Just as hardware integrated circuits, or components, can be used to inexpensively manufacture a product line of related hardware systems,
reusable software components can be used to create software systems. This is accomplished by developing a common framework for a
product line of related software systems that forms the component operating environment. A development architecture is presented based on
our work using Object Oriented Analysis and Design techniques to create reusable software components that combine with aircraft specific
customizations to form an avionics software system. q 1999 Published by Elsevier Science B.V.
Keywords: Avionics software; Product line software; Software architecture; Reusable software
0
AM
9L
PC
12
D
2
HU
K8
M
M
JD
M
AI
AI
M
Fly-out domains;
Airframe Radar Tgts FLIR Weapons Model
2. domain dependent—patterns applicable to a specific
Infrastructure Services
application domain.
Operating System
Board Support Package Buschmann et al. break patterns into the following divisions
Hardware (CPU, Memory, I/O) [5]:
View Controller
is responsible for taking all of the applicable software
elements and plugging them together into a functional
Model system.
Especially at the architectural level, the boundaries
Fig. 2. Model–View–Controller architecture. between software elements should foster change encapsula-
tion and separate independent concerns. This inspection
Jacobson et al. mention layered architectures as a central reveals the following benefits of the top-level architecture:
aspect of reusable software systems [9].
• The Infrastructure Services–Model boundary isolates
2.2. Model–View–Controller pattern hardware, run-time, and operating system issues from
the application.
The Model–View–Controller (MVC) pattern was devel- • The Model–Operator boundary isolates the core applica-
oped within the Smalltalk community as an architecture for tion from user interface volatility.
graphical user interface based systems. Its architecture is • The Operator–Configurator boundary isolates the soft-
shown in Fig. 2, and is itself a layered architecture. ware elements from their integration into a complete
One of the important characteristics of the MVC archi- system.
tectural pattern is the separation of the domain model from
the user interface utilized to present domain information to 2.4. Model architecture
users and allow them to manipulate it. This allows multiple
views (i.e. displays) of the same information. It also sepa- As stated earlier, the Layers pattern is applied recursively.
rates the relative stability of domain models from the rela- One example of this is within the top-level Model layer. Fig.
tive instability of user interfaces, resulting in better change 4 illustrates this second level layered architecture.
encapsulation. In this case, the Building Blocks layer represents general-
purpose objects like vectors and matrices. Avionics Inter-
2.3. Top-level architecture faces represents the mission-computing interface to other
avionics subsystems. The Real-World Model contains the
The top-level software architecture derives from applying software representation of the problem domain. Examples
the two aforementioned architectural patterns. In the case of of elements in the Real-World Model are weapons, stations,
the Layers pattern, it is applied recursively in hierarchical targets, the ownship airframe, waypoints, and routes.
fashion. In all cases, a relaxed version of the Layers archi- Applying the boundary inspection process as before at
tecture is applied where a higher level layer may bypass this level reveals the following benefits:
intermediary layers and access low layers directly where
necessary. • The Building Blocks–Avionics Interfaces boundary sepa-
Fig. 3 shows the top-level architecture. The Model layer rates more general-purpose domain-independent
represents the core domain application as defined in the elements from domain-specific elements.
MVC architecture. The Operator layer contains both the • The Avionics Interfaces–Real-World Model boundary
View and Controller portions of the MVC pattern, some- forms a key separation isolating product line elements
times referred to as a Document-View variant of the MVC from the specifics of a single avionics system on a parti-
architecture [10]. cular aircraft. This boundary is directly related to the
To these MVC based application layers, a foundational original goal of containing avionics system specifics.
Infrastructure layer is added to provide a CORBA based Summarizing, combining repeated application of these
run-time system and insulate the application from hardware architecture patterns with domain-specific considerations
configuration specifics. At the top, a Configurator layer is develops the overall system structure and leverages proven
added which represents a notional “software system circuit architecture experience within the product line software
board” and is responsible for instantiating all of the objects architecture.
and establishing their relationships. The Configurator layer
3.1.4. Structure
Fig. 5 shows the Component pattern structure using the
Unified Modeling Language (UML).
3.1.5. Participants
• ComponentConsumer—uses the component via the
ComponentSupplier1 ComponentSupplier2
facade.
• ComponentFacade—provides the public interface for the
Fig. 5. Component pattern structure. contained objects.
D.C. Sharp / Microprocessors and Microsystems 23 (1999) 425–433 429
User API
Config-
uration Horizontal
Sensors
... Vertical
Sensors
... Rotational
Sensors
...
API
Required Optional
Receptacle Receptacle
ComponentConfigurator
ConfigurableComponentFacade
ConfigurableObject1 StaticInternalObjectClass
1..*
ConfigurableObject2 ConfigurableObject3
SupplierComponent1 SupplierComponent2
should not contain algorithms or other functionality in API is used during component initialization. Fig. 6 offers
public member functions that objects internal to the a conceptual view of a configurable airframe component
component would want to invoke. This restriction can representing the navigational state of the aircraft.
be alleviated by the use of recursive locks, but they
require more throughput which is especially important 3.2.3. Applicability
in real-time embedded systems. Use the Configurable Component pattern when all of the
following hold true:
3.1.9. Related patterns • components in different applications or within a single
This pattern is a specialization of the Facade pattern [14]. application represent the same logical entity and can
Facade pattern issues apply here as well. share the same interface;
• flexible customization of the components enables or
3.2. Configurable component design pattern increases reuse, either within a single application for
The following sections define the Configurable Compo- different component objects or between different appli-
nent pattern. cations;
• interfaces to the differences can be defined;
3.2.1. Intent • the additional software or architecture reuse justifies the
Define components that are configurable to increase additional complexity.
reusability.
3.2.4. Structure
3.2.2. Motivation Fig. 7 shows the Configurable Component pattern struc-
There are many cases where multiple components can ture.
share interfaces but where all or part of the implementations
differ. Configurable components provide all of the shared
3.2.5. Participants
implementation and allow flexible incorporation of differ-
• ComponentConfigurator
ences.
This establishes a new kind of component interface for passes configuration parameters to the ComponentFa-
the purposes of plugging in customizations. The original cade via the Configuration API to customize compo-
notion of a component interface is referred to as the User nent behavior.
Application Programmer Interface (API). This interface
• ConfigurableComponentFacade
provides the services used during normal component opera-
tion. Configurable Components add the idea of a Configura- instantiates objects directly for those internal objects
tion API, which allows component creators (referred to as that are not configurable;
Configurators) to customize behavior. This Configuration provides the Configuration API which defines the
D.C. Sharp / Microprocessors and Microsystems 23 (1999) 425–433 431
complete set of allowed customizations for the Compo- advantageous in cases where simplified implementations
nentConfigurator to tailor operation as desired. can be plugged in for streamlined performance.
3. Abstract Factory. A clear and concise way to define the
• SupplierComponent1, SupplierComponent2
Configuration API is through use of the Abstract Factory
represent external components to which the Configur- pattern [15]. In this method, an abstract factory class is
able Component must be related during construction. created that has member functions for creating or other-
wise returning a reference to each configurable entity.
Users then inherit from the base class and fill in the
3.2.6. Collaborations
implementation with the specific desired configured
The collaborations listed here apply when the Abstract
items. The factory is passed into the facade constructor
Factory pattern [15] is applied for configuring the objects
for use during component construction. This method also
internal to the component, as described in Section 3.2.8
helps avoid lengthy constructor argument lists when
(Implementation).
there are many configurable items.
• The Configurator creates an Abstract Factory object, 4. Required or optional tailoring. The receptacles defined
passing in any references to supplier components as by the Configuration API may be either required or
constructor arguments. optional for component operation. Receptacles may be
• The Configurator creates the component by constructing designed as optional by providing a default plug internal
the facade and providing the factory as a constructor to the component or by virtue of the fact that the plug will
argument. simply not be used if not present. The later typically
• The facade invokes methods on the factory to create the occurs when there is a variable length list of plugs in
internal objects and receive references to both the created which case the component simply iterates over the
internal objects and possibly external suppliers. provided plugs.
• Consumers then receive references to the created compo- 5. Receptacles are relationships. The receptacles in the
nent via their configurators and invoke member functions Configuration API are actually special cases of relation-
in the User API to access operational capabilities of the ships. In this case, they are relationships to pluggable
component. customizations. Recognizing the different kinds of
component relationships aids understanding:
3.2.7. Consequences (a) Static relationships. These are set during construc-
The Configurable Component pattern has the following tion and remain unchanged during system operation.
benefits and drawbacks: The Configuration API is solely comprised of these
static relationships. There are two types of static rela-
1. Increases reusability. Allows components to be used in
tionships:
more situations by allowing customization.
2. Identifies potential tailorings. The Configuration API (i) To other components—these allow tailorable
defines the receptacles that provide customization component environments where surrounding compo-
hooks. The receptacles allow flexible configuration of nents are flexible, not tailorable component internals
functionality or performance customizations via aggre- themselves.
gation during component construction and initialization. (ii) To plugged in customizations—these are related to
actual component tailorings where objects internal to
the component are plugged in during construction.
3.2.8. Implementation
Consider the following issues when implementing the (b) Dynamic relationships. These are changed during
Configurable Component pattern: normal system operation. An example of this is select-
ing the target towards which a specific weapon is
1. What parts are configurable? One of the most basic
currently aimed. Since these relationships are an intrin-
issues is identifying the component internals that should
sic part of using the component, they are considered
be made customizable. Directly contained objects are
part of the User API.
inflexible and are typically only acceptable for those
parts that are extremely stable and would never require 6. Pushing or pulling plugs. Plugs may be provided either
customization in any reasonably expected usage. Any by a configurator passing the plugs in during construction
internal objects that might require customization should or by the component retrieving them itself. Pushing plugs
be pluggable to aid reusability. The hooks provided by makes the configurator smarter at the expense of the
Configurable Components clearly indicate which parts component. Conversely, pulling plugs makes the compo-
are customizable. nent smarter. Since configurators are focused on the
2. Tailoring functionality or performance. Customizations component level, and the component facade is more
may be desirable for any reason, not only to affect the concerned with issues internal to the component, the
component’s functional behavior. Tailoring may also be following recommendation is made:
432 D.C. Sharp / Microprocessors and Microsystems 23 (1999) 425–433
(a) Static relationships to other components are estab- provide reusable artifacts, which are exploited to reduce life
lished by passing the references into the component cycle avionics software cost.
facade constructor.
(b) Static relationships to plugged in objects and the
Acknowledgements
creation of the objects themselves are provided by the
configurator creating an Abstract Factory and passing
The concepts described herein were developed within the
its reference to the component facade for use during
stimulating confines of the project Software Core Architec-
component construction. This reduces configurator
ture Team. Their contributions, and especially the many
complexity, localizes the creation issues associated
insights provided by founding member Bryan Doerr, are
with a specific component, and clearly identifies to
gratefully acknowledged. Our work also reflects an extre-
users what items are tailorable within the component.
mely fruitful collaboration with Dr Douglas C. Schmidt and
his colleagues at Washington University in St. Louis,
3.2.9. Related patterns Missouri. Thanks also go to Tim Popp, who authored the
The Abstract Factory pattern is used as the means for original abstract for this paper.
flexibly creating objects internal to components.
References
4. Conclusion [1] D.C. Winter, Modular, reusable flight software for production aircraft,
15th AIAA/IEEE Digital Avionics Systems Conference Proceedings,
This paper focuses on two important characteristics of the October, 1996, pp. 401–406.
software architecture: [2] R. Johnson, How to develop frameworks, Conference on Object-
Oriented Programming, Systems, Languages, and Applications, Octo-
• layered architecture; ber, 1997.
• medium grained architecture. [3] Gamma, et al., Design Patterns: Elements of Reusable Object-
Oriented Software, Addison–Wesley, Reading, MA, 1995, p. 10.
It is important to note that both of these characteristics [4] D.C. Schmidt, A family of design patterns for application-level gate-
derive directly from the original goals of encapsulating ways, Theory and Practice of Object Systems, 2, Wiley, New York,
1996 No. 1, December.
change and maximizing reuse. The layering aspect espe- [5] Buschmann, et al., Pattern-Oriented Software Architecture: A System
cially relates to developing an application that is indepen- of Patterns, Wiley, New York, 1996, xiv.
dent of the hardware and avionics specifics of a single [6] Buschmann, et al., Pattern-Oriented Software Architecture: A System
aircraft. The medium granularity of the components of Patterns, Wiley, New York, 1996, pp. 31–52.
provides a system that can be deployed on varying numbers [7] Buschmann, et al., Pattern-Oriented Software Architecture: A System
of Patterns, Wiley, New York, 1996 pp. 125–144.
of processors in single processor or distributed hardware [8] K. Beck, R. Johnson, Patterns generate architectures, European
configurations. Both of these goals directly relate to the Conference on Object-Oriented programming (ECOOP) Proceedings,
original decision of developing a product line software 1994.
system. [9] Jacobson, et al., Software Reuse: Architecture Process and Organiza-
Patterns form a very powerful technique for reusing and tion for Business Success, Addison–Wesley, Reading, MA, 1997, pp.
170–212.
spreading expertise. The pattern driven architecture [10] Buschmann, et al., Pattern-Oriented Software Architecture: A System
described herein leverages previous industry experience to of Patterns, Wiley, New York, 1996, p. 140.
address the original goal of defining a software architecture [11] D. Roberts, R. Johnson, Evolving frameworks: a pattern language for
applicable to a fighter aircraft mission-processing product developing object-oriented frameworks, How to Develop Frame-
line. The Component pattern language defines the reusable works, Conference on Object-Oriented Programming, Systems,
Languages, and Applications, October 1997.
software elements and provides the complete development [12] T. Harrison, D. Levine, D.C. Schmidt, The design and performance of
community with understanding of the underlying rationale, a real-time CORBA event service, Conference on Object-Oriented
tradeoffs, and implementation concerns involved. The Programming, Systems, Languages, and Applications Proceedings,
resulting component library embodies reusable application October 1997, pp. 184–200.
elements available for specific aircraft products. All of these [13] Gamma, et al., Design Patterns: Elements of Reusable Object-
Oriented Software, Addison–Wesley, Reading, MA, 1995, pp. 6–8.
elements, including: [14] Gamma, et al., Design Patterns: Elements of Reusable Object-
• architecture; Oriented Software, Addison–Wesley, Reading, MA, 1995, pp. 185–
193.
• components; [15] Gamma, et al., Design Patterns: Elements of Reusable Object-
• patterns; and Oriented Software, Addison–Wesley, Reading, MA, 1995, pp. 87–
• developer expertise. 95.
D.C. Sharp / Microprocessors and Microsystems 23 (1999) 425–433 433