PLA and the SC 2002-04-15

PLA and the SC 2002-04-15.doc Updated: 15 April 2002 Page 1
Product Line Architecture and the Separation of Concerns
Dr. Jay van Zyl
Rubico Products (Pty) Ltd, Johannesburg, South Africa
Summary: Software product lines present many benefits over the traditional methods of building
systems. With the diverse implementation of product lines, organizations are faced with complex design
constraints. Layered architectures assist with breaking down complexity through separating
architectural elements based on their use and applicability. It is difficult to achieve high levels of re-
use and productivity by focusing on one architectural style. This paper discusses two primary concepts,
namely, the product line architecture and the separation continuum. It starts by presenting a product
line architectural view that shows how various concepts are separated based on abstraction. In order to
provide context, the Software Engineering Institute and Carnegie Mellon University’s product line
practices are discussed briefly. The separation continuum shows how vertical and horizontal layering
can assist with separating user interface from business logic and data at an implementation level, and
the separation of customer facing processes from infrastructure facing processes at a business or
abstract level. Software product developers know that these relationships are not easily related –
customer facing business processes have different requirements to infrastructure facing processes. In
order to tie the concepts together, vertical layering is needed whereby the more abstract elements are
separated from the implementation of those elements. An application assembly approach is discussed
whereby a product line architecture is tied to the separation continuum showing how high levels of
productivity can be achieved when realizing product lines. The approach presented in this paper is still
under development with implementation on a limited number of product lines only. It is intended that
the content will provoke and stimulate the thinking and experimentation needed to deal with application
assembly by means of having a product line architecture overlaid onto a separation continuum.
Keywords: product line, architecture, separation of concerns, separation continuum, patterns,
software assembly
1. Introduction
Re-usability is a topic that is constantly under
discussion. The reality is that there are no “silver
bullets”, no easy process, no easy software solution
and no bullet-proof architecture to assist with building
and using re-usable software assets. In this era of
objects, components and service based architectures,
how do architects and software practitioners
implement large-scale usable, re-usable software
products that are fit for purpose? How are the benefits
of product lines fully realized once implemented?
These kinds of questions are answered in this paper.
This paper ties together three essential concepts,
namely, the separation continuum, product line
practices, and a product line architecture. The three
concepts “morph” into one, yielding benefits that all
revolve around the ability to: “assemble” software
systems safely, quickly and easily into product lines.
The complex nature of large-scale software systems
requires a clear separation of the concerns that is
represented by a separation continuum. Product line
practices are a frequently adopted and well understood
means of facilitating the processes needed in the
production, maintenance and management of product
lines. A product line architecture is needed in order
to realize the various concerns in a software product
by using product line practices.
Emerging approaches, such as the Model Driven
Architecture (MDA) [MDA] and the Reusable Asset
Specification (RAS) [Rational], show that the need to
have a common method for understanding how
requirements are realized, independently of the
implementation, is receiving a fair deal of attention.
The MDA framework is based on modelling different
levels and abstractions of systems, and exploiting the
relationships amongst these models. The RAS
provides guidelines for description, development and
application of different kinds of reusable software
assets. Neither of these initiatives focuses on
producing product lines.
In order to have a clearly separated technology and
platform architecture [Doerr] suggests that certain
elements of flow control must be removed from the
underlying architectures. Components might be
independently defined and built, but the flow of
processes and data presents many platform specific
challenges. The core software assets must include
tools to perform these tasks without having a specific
platform feature implemented.
This paper contributes to the research already
underway in the field of assembling systems from
previously constructed software assets.
Section 2 provides an overview of the software product
line practices as promoted by the Software
Engineering Institute.

Section 3 introduces the separation continuum and the
way in which the various dimensions are identified.
Section 4 discusses the abstract layering of the
separation continuum model.
Section 5 discusses the platform implementation
layering of the separation continuum model. It also
shows that the separation of concerns must be taken
into account in product line architectures.
Section 6 introduces the concept of assembling new
product lines from pre-defined software assets. It also
shows how product lines are realized.
Section 7 closes with some specific comments on the
implementation of the principles described in this
paper.
2. Overview of Software Product Line
Practices
Software product lines have emerged as a very
important paradigm in delivering systems. Major
benefits are derived from the practice of using
common assets to build systems. Remarkable
increases in time-to-market, product quality, and
customer satisfaction are realised through this
framework. With the “component” paradigm
maturing and the emergence of “Web services”,
companies can construct systems from commonly
available software assets. The technological aspects
are not without their problems, but the process of
product line practices presents more benefits than
existed previously.
2.1 Software Product Lines
The Product Line Management v2.0 [SEI PLP: pg 3]
presents the following definition:
“A software product line is a set of software-intensive
systems sharing a common, managed set of features
that satisfy the specific needs of a particular market
segment or mission”.
Common software assets are invented, designed and
built in such a way that they can be used in a
multitude of product lines. The ability to build and
evolve these separately has major benefits as
architectural, resource and other dependencies can be
balanced. “Independent synchronised product
delivery”, where assets are constructed in parallel, is
now possible as products are assembled depending on
the customer’s needs.
2.2 Product Line Activities
The practice of product line development can be
broken into two major areas of activities: The
development or acquisition of core assets, and the
development of the product itself make up the essence
of product development or acquisition.
Figure 1: SEI’s product line activities
[SEI PLP:pg 10]
These activities happen throughout the product’s life
cycle and are iterative in nature. Management activity
is responsible for the coordination and delivery of the
process as a whole. Sections 2.3 and 2.4 will discuss
Core Asset Development and Product Development.
The Management process will not be dealt with here.
2.3 Core Asset Development and Acquisition
The purpose of this activity is to produce or acquire
product production capability. A product space is
described and used to direct the content of the product
line. Core software assets are used to assemble the
product line. The assets are based on an underlying
architecture that will be included in the final product.
Figure 2: Core asset development and acquisition
[SEI PLP: pg 13]
A production plan is needed to describe the way in
which these products will be produced. It is based on
the practices that best suit the product line

architecture. Inputs into the process are used to
produce the final core assets, product space or assist
with production planning.
The product constraints (for example, performance
characteristics) are used to direct the way in which the
products are built and assembled. Styles, patterns and
frameworks are the principles used to construct the
assets to be developed. Production constraints and the
production strategy are used to direct the ways in
which the assets are built and deployed into product
lines. Existing pre-built software assets are used
throughout the management and building phases to
ensure optimal re-use of existing assets.
2.4 Product Development and Acquisition
The ability to turn out products with a high level of
productivity is the ultimate goal of a product line in
the context of a commercial software organization
[vanZyla]. To be able to do this, three inputs are
required, as described in the asset development and
acquisition activity, namely, the product space, core
assets, and the production plan. Requirements are
essentially the product features.
The products produced and organised into product
lines essentially represent a group of products.
Ultimately the products are produced independently by
groups of product developers and are synchronised and
integrated into a coherent product line. Product
managers manage the vision and goals of the product
line that needs to be commercialized [van Zyla].
Figure 3: Product development and acquisition
[SEI PLP: pg 18]
Different relationships are built between the customers
that use the products and customers that sell the
products. When partners, which are essentially
customers, sell products to their target market issues
are raised that need to be fed back into the product
provider. Commercial viability is analysed and used
as a business case to, in extreme cases, create new
product lines.
Section 3 will discuss the principles of the “separation
continuum”. It is only later in the paper that product
line practices are overlaid onto the continuum.
3. Separation Continuum
The principle of “the separation of concerns” has been
used by various architectural styles. Essentially, it is
used to deal with the complexities that exist in the
definition and use of software systems. Principally, if
the inherently static rules that require high speeds of
execution are placed in an environment where they are
best suited, and are separated from the dynamics of
user interface metaphors, the risk of having an
imbalance between performance and dynamic
capability is reduced radically.
The continuum described here attempts to extend the
thinking already prevalent in layered architectures.
Architectures always describe a system that is made up
of smaller parts [Bachman]. Complexity is managed
by understanding the continuums that exist when
describing, defining and assembling product lines
using these parts.
3.1 Separation of Concerns
The Separation Continuum can be defined as: “a
systemic view of a system to understand its parts and
their relationship, through understanding vertical and
horizontal continuums needed where abstraction and
implementation are on the vertical continuum, and
human and machine facing aspects to have attributes
of adaptability, context and relevance are on the
horizontal continuum.”
Model Driven Architecture [Dsouza] has a vision that
overlaps with the separation continuum: “An
integrated enterprise is one whose business areas,
strategies, architectures, organizational units,
processes, machines, technology platforms, data and
information – and the organization’s understanding of
these – form a consistent, cohesive, and adaptive
whole”.
It is reasoned that the separation continuum will assist
in the implementation of product line practices. The
ability to understand interrelated layers of a system
and the levels of re-usability required in producing
software intensive product lines, have many benefits
that include:
? Agility – the ability of the business to respond to
market demand by having highly adaptive
software systems.

? Time-to-market – the ability to assemble new
software products by using software assets in a
highly productive and easy to use manner.
? Operational optimization – the ability to have
focused teams produce relevant assets based on
functional and non-functional requirements.
? Innovation ability – new products can be produced
as prototypes by using different combinations of
assets.
When architectures are designed for new product
lines, there needs to be one main objective [Pronk],
namely, “avoiding a monolithic design by extreme de-
coupling of components and localization of
functionality so that every component can be replaced
or upgraded in isolation”. The separation continuum
takes this concept one step further in that other
dimensions in systems delivery need to be considered.
“Horizontal separation” is concerned with the
separation of how the user interface is independent of
the connectivity and, in turn, separate from the
business logic and data access. “Vertical separation”
is the layering needed to implement platform elements
separately from the higher levels of abstraction needed
at application levels typically represented in business
requirements.
Architectures from many platform vendors are
available that specialise in different kinds of
separation. Both J2EE and Microsoft .NET platforms
are focused strongly on the notion of separating out
the various dimensions of a system on both the vertical
and horizontal axis. The continuum assists with the
thinking required to bring vertical and horizontal
layering into one construct.
3.2 Horizontal Continuum
The horizontal continuum can be seen as having two
areas, namely, “customer facing aspects” and
“infrastructure facing aspects”. The horizontal
continuum at a platform implementation continuum
level is typically made up of the following elements:
? User interface: the interface that is used by the
user of the system that might include a multitude
of devices including web browsers, personal
devices, etc.
? User interface controller: this controller is needed
to manage the behaviour of the interfaces (for
example, Web pages) that connect to the business
logic layer.
? Connection or middleware layer: the ability of the
user interface to connect to a server that directs
the way in which the interface is used.
? Services and business logic layer: the ability to
have a cluster of business and/or technical
services exposed to the user interface.
? Data provision layer: the ability to store in a
reliable fashion that may be used by the services
layer to deal with transactional, system and meta-
data data definitions.
Architectural patterns can assist in determining the
optimal groupings of architectural elements on the
horizontal continuum. [Buschmann] describes in
“Pattern-Oriented Software Architecture” many
architectural constructs that can be used.
The layering abstract continuum relates to the
platform implementation in the following way.
Customer facing processes in organizations can be
implemented by using various technologies. Human-
only processes do not require any physical
implementation but still need to be defined and
understood in order to provide the optimal human-
technology interaction. An example could be that a
system can be accessed via the web to perform certain
transactions. When something out of the ordinary
happens, the user can telephone a call centre, where a
human can assist with queries. In this example there
is an overlap between what the technology needs to
provide and what humans need to provide.
By taking an internal customer facing perspective, the
separation continuum can be implemented in its
entirety as the realization of an infrastructure process.
The call centre example above is seen by the external
customer as an infrastructure facing process. The call
centre operator, using visual tools, sees a customer
facing view of the system used to deal with the
enquiry.
3.3 Vertical Continuum
The separation of dimensions, based on context and
relevance, are fundamentally important when defining
a product line architecture [Doerr]. Aspect-Oriented
Frameworks [Constantinides] can assist with the
challenge that is faced by so many designers and
architects. “Aspects” refer to the properties of the
system that do not align directly with a system’s
functional requirements, but cut across functional
components increasing their interdependencies. The
“vertical continuum” essentially deals with the aspects
needed to produce product lines. In order to
understand this continuum, two concepts need to be
defined briefly, namely, models and architecture.
“Models” can be defined as a simplified description of
a complex problem that is represented by designs of a
projected implementation. The separation continuum
uses models to analyse and communicate abstract
business related requirements.

“Software Architecture” as defined by [Bass] is the
structure (or structures) of a system which comprises
software components, the externally visible properties
of those components, and the relationships between
them. “Architecture” in the context of the separation
continuum, as adapted from [Bass], is defined as the
high level design that can be realized by the overall
structure of the system that includes all the
interrelationships of elements in whatever style was
used.
Figure 4: The separation continuum
Vertical separation of contexts in the organization or
system considers the following levels, moving from
abstract layering to platform implementation:
? Business Model – This layer represents the basic
concept of “doing business”.
? Systems Model – The systems model deals with
the portfolio of systems required to satisfy a
specific business model.
? Applications Portfolio – Systems are required to
automate required systems by means of producing
software assets, product lines and product
families.
? Services Architecture – This architecture is
concerned with the breadth of functionality
needed to implement the business systems via the
applications portfolio. A generic term that could
be used here is “web service” or “service based
architecture”.
? Component Architecture - The component
architecture view presents a complete view of the
business components that can be exposed as
services. Components are typically coarse-
grained software elements that satisfy a particular
requirement.
? Object Architecture – Components are created
from object or other technologies and exposed as
business components. Objects are the finest
granularity of functionality in a typical system.
This continuum also assists with application context
realization [Atkinson] and refers to this as “Zoom-in”
and “Zoom-out”. These “zooming” concepts can be
used in order to move up or down the vertical
continuum, for example, a particular business model is
realized by a number of systems models. It also means
that there is traceability between the various layers.
This ability allows for the direct mapping onto the
Model Driven Architecture through platform
independent and platform dependent models [MDA].
The next two sections will explore the vertical
continuum. Firstly the layering abstract is discussed
where it is shown how business requirements are used
to derive an applications portfolio that is used to
assemble a product line. Secondly, the platform
implementation is discussed and it is shown how
software architectures are used to realize software
assets. These assets are used to realize the product
line through an assembly process.
4. Layering Abstract
This continuum is concerned with the relationships
that are required to ensure that the platform
implementation is relevant to the layering abstract it
will implement. The layers defined in the layering
abstract can overlap, and probably will, with existing
business design and modeling methods. Most
organizations today have business plans, strategies,
processes and other artefacts that describe the way in
which the business operates that can be used to
determine the required models.
Benefits of continuity and common understanding can
be realized when an organization, or a unit in an
organization, understands business requirements in
terms of the horizontal continuum. The systems
model layer and below can form a critical map for the
chief information officer or technology executive in
that, once continuity is achieved, all dependencies are
understood and new development and packaged
product purchases can be seen in the context of the
overall organization.
4.1 Business Model
This layer represents the basic concept of “doing
business”. An example could be the way in which an
organization deals with its customers in relation to the
kinds of products provided. The business concept of
“personal banking” is one way to deal with high nett
worth individuals on a one-to-one basis, whereas
“electronic banking”has no human contact.
Elements of the business model cannot be
implemented directly into systems (such as key

performance areas and business scenarios), but can
form a critical influence and success factor. Other
concepts (for example, balanced score card and
business scenarios) can be used to determine the
completeness and correctness of the business and
systems models.
4.2 Systems Model
The “systems model” deals with the portfolio of
systems required to satisfy a specific business model.
Looking at the example above, “personal banking”
requires systems where individuals need to get to the
client in order to perform the relevant process.
“Electronic banking” provides a completely different
kind of experience whereby the only human function
might be to ensure that extraneous loan applications
are processed.
The systems models must create sufficient know-how
of the systems by understanding the automated and
manual processes required to produce the required
outcomes. Systemic thinking can be applied to
systems to optimally design customer-facing processes
to reduce the time it takes when customers deal with
agents, or when using electronic banking for example.
Classical requirement management and domain
engineering techniques can be applied in specifying
models at this level. Systems models provide the
essential ingredients when determining the
applications portfolio.
4.3 Applications Portfolio
Well thought out business systems are required in
order to automate these systems. The software
required to undertake customer management, for
example, might be the same for both business models
and their related systems. Differences will be
prevalent when the various audiences use the software
interfaces, for example, the “electronic banking” user
will have a specific means to maintain information,
whereas the “personal banking” agent might have
access to more confidential information relating to the
client, such as internal banking ratings.
A typical applications portfolio might involve software
applications that might be classified as legacy. This
means that this portfolio is the implementation view of
the systems model without the manual operations. It
does, however, show the relationship between human
and machine, resulting in flow-of-activity definitions
that are specific to the way in which a certain role
would utilize the software product.
The applications portfolio lives on the abstract
continuum and forms the bridge between the layering
abstract and platform implementation continuums.
Application engineering [Atkinson], as a concept of
producing applications, uses all the concepts as
articulated at the various levels in the continuum.
Even though the applications portfolio might seem
more “Platform Implementation” specific, it is not.
Overlaps into the “Layering Abstract” become more
apparent when systems can be constructed quickly,
and the stakeholders decide to accept changes in this
level rather than the technology [van Zylb]. This
means that deployable software will include the
definitions of the application portfolio in some
platform independent fashion such as an Extensible
Markup Language (XML) definition.
This was a high level introduction into the layering
abstract. It is provided in order to see the platform
implementation for what it is: a realization of business
requirements.
5. Platform Implementation
Product lines that cover a wide spectrum of
functionality can only be produced if the underlying
architecture is independent of the business
functionality required by the ultimate user. A number
of architectures cover the ability of software developed
objects and components to be transformed from one
type of implementation to another. This still proves
problematic as the skills shortage and level of
understanding of the architecture are critical elements
in transforming strategic features into products.
This part of the continuum is affected by the
implementation and usage of international standards.
Standards help in the ability to integrate diverse
software assets, and settle the mind of the purchaser
that lock-in is minimised. But, “there are
standards … and there are standards”. The selection
process of implementing standards is as important as
selecting an entire architecture in some cases, as these
are closely interrelated. Standards also assist with
basic requirements that need to be included to make
architectures more competitive.
The three layers in the platform implementation can
be grouped into two main areas, namely, services and
components. Typical component implementations will
not expose the objects used as these are typically part
of the underlying frameworks used.
5.1 Services Architecture
This architecture is concerned with the breadth of
functionality needed to implement the business
systems via the applications portfolio. A generic term
that could be used here is “Web service” or “service
based architecture”. It means that the application
portfolio is constructed from independently usable
software components that are exposed as services. A
typical service might be “CustomerManagement” that
entails all the basic elements of maintaining
information about a customer. Another related service
could be “CustomerPortfolio”, that is, the portfolio of

account that the customer has with a particular
institution.
Services need to be defined in such a way that they can
be used in a loosely coupled way. This means that an
assembly process is applied to tie together the different
functionality areas at the run-time of the software
system’s execution. People performing the role of
assemblers, need not have the technical skill of a
component builder or developer. Safety is a major
factor when non-technical people assemble systems. A
concept such as design-by-contract can be used to
ensure that services have the correct inputs, produce
the appropriate outputs, and are controlled by means
of pre- and post conditional checks.
5.2 Component Architecture
The component architecture presents a complete view
of the business components that can be exposed as
services. Components are typically coarse-grained
software elements that satisfy a particular requirement
and are constructed using an object oriented or other
technology. The customer management service
requires a number of components in order to realize
functionality (for example, there might be different
components to read customer information and create
new customers). More generic components might be
grouped together in order to realize more business-
related functionality (for example, when a generic
storage management or security component is used).
More generic components might have associated
configuration environments to direct the behavioural
and data usage principles applied.
Components that live in the same technical component
architecture can be tightly coupled to ensure good
performance. “Tightly coupled” means that there is
specific work involved in getting components wired
together, where they share and have optimal ways to
execute using high performance implementation
techniques. “Loosely coupled” differs from tightly
coupled by the dynamic ability to wire components
together. Loosely coupled components are typically
done via services, as described in the previous section.
5.3 Object Architecture
Components are created from object or other
technologies and exposed as business components.
Objects are the finest granularity of functionality in a
typical system. The term is used in this context more
generically than in object orientation. Data objects for
example might be realized in a particular database
technology, where connectivity might be realized
using a particular transport mechanism. Functionality
provided by objects is grouped and used as
components.
Object usage would normally involve the use of an
underlying technical architecture. It involves a
programming model that has specific semantics,
characteristics, and usage criteria. When used in
programming, objects are applied in a tightly coupled
fashion, meaning that programming would be required
to change the way in which an execution sequence is
implemented, for example.
The platform implementation continuum is realized
using one or more technical architectures. Specific
styles can be applied depending on the characteristics
of how the final systems need to function.
5.4 Software Architecture
The software architecture can be implemented by
using object, component, and service-based
architectures. The software architecture needs to be
designed in such a way that applications can be
created dynamically. There will be trade-offs when
applying the various architectural styles during the
design process. Architectural styles are described by
five canonical structures:
? Functional structure is concerned with the
decomposition of the functionality that is required
by a system.
? Code structure is concerned with the key
abstractions that are used to build a system.
? Concurrency structure is concerned with the units
of concurrency that are refined into processes and
threads.
? Physical structure is concerned with the physical
implementation of the architecture and includes
the hardware and networking requirements.
? Developmental structure is concerned with the
administrative control of the system.
Each of these structures represents a number of
challenges when realizing features, each with its “pros
and cons” – but they are not within the scope of this
paper. Methods are needed whereby the anomalies
can be removed from the software component and the
business component builder’s process of assembling a
system.
A number of basic architectural patterns has stayed the
same over the history of computer systems. These
basics are applied repeatedly in the design and
development of systems. To be “design centric”
means to be focused on the timeless concepts needed
to construct systems. Patterns have been used to fill
this gap to a certain extent. Programming languages
have come and gone, but the basic design of language,
semantics and usage has remained the same or similar
in nature.

Design needs to take into account both functional and
non-functional requirements when designing
architectures. Design processes, such as those by
[Bosch], can be applied to all architectures on the
platform implementation continuum.
5.5 Using Software as Assets
The implementation of architecture has not really been
discussed up to now. Various mechanisms can be used
to facilitate implementation where this paper proposes
software assets, product line architecture and pattern
usage.
The Software Engineering Institute’s (SEI) report
called “An Activity Framework for COTS-Based
Systems” explains why Commercial off-the-shelf
(COTS)-based systems are different to other systems:
With COTS-based systems, continual, rapid changes
driven by new mission needs, product upgrades, and
technology advances, are facts of life. An architecture
that can retain its structure and cohesiveness, yet
allows the system to respond easily to these changes -
an evolve-able system architecture - becomes an
important strategic asset to an organization.
Any artefact needed to either create or alter a software
product can be seen as an asset. All layers on the
implementation continuum contain software and other
assets. These assets can be brought together to form a
product line as discussed in the next section.
The componentization of software systems has brought
about a new era of using software in a manner similar
to the electronics of motor vehicle components. The
drive towards common standards still seems to be the
major obstacle as the industry moves forward with
objects, components, services and agents. Each of
these principles can be encapsulated, once available
for use, as an asset owned by an organization.
Assets can be fixed or dynamic. Fixed software assets
are the ones developed with a programming language
that encapsulates the more volatile business
definitions. Dynamic software assets are the ones
where the behaviour and data requirements are loosely
coupled, and fully configurable once deployed.
Principles of altering behaviour and information
requirements of more dynamic assets can be applied in
assembly processes. In “Software Product Lines”,
Clements and Northrop [Clements] state that: “In a
product line, the generic form of the component is
evolved and maintained in the asset base. In
component-based development, if any variation is
involved, it is usually accomplished by writing code,
and the variations are most likely maintained
separately”. The next section will describe one such
implementation, where executable patterns can be seen
as software assets, and the variations on the patterns as
asset parameters.
6. Assembly Using a Product Line
Approach
The previous three sections discussed the separation
continuum. There was an emphasis on the platform
implementation continuum because this section will
describe how a product line architecture can be used to
implement the continuum.
6.1 Introduction
Product lines are defined in order to realize a specific
customer requirement, market need or market niche.
Product line features, or requirements, are determined
from the systems models that require software
applications to function. “Assembly” is the process of
exploring and re-using existing software assets. In the
case where a requirement cannot be satisfied, a
development life cycle will be initiated to construct the
relevant asset.
During system assembly the focus should be on the
tying together of a predefined set of assets that comes
in the form of web services or services, components or
objects. It must be considered that these assets could
have been acquired from different sources.
Assembly using software as assets, is needed to realize
the benefits of agility, time-to-market, operational
optimization and increased innovation ability.
Figure 5: Separation continuum and product line
realization
Component and object architectures form the nucleus
of software execution. Product lines are realized
where the abstract layers join the implementation
layers. The diagram above shows that there are two
ways to realize product lines:
? Top-down: The business model drives strategic
initiatives from the top down to the
implementation. All the interpretations of how
the business systems must function are realized in
the application portfolio specification. The

platform implementation continuum needs to be
flexible enough to respond to changes with quick
turn-around times. Business consultants or
systems analysts typically function in this domain.
? Bottom-up: The architectures already
implemented either present enablers or inhibitors
to the business model. Web services is a good
example of how business is affected and how a
new means of realizing functionality quickly can
facilitate new business products to be taken to
market. Developer, architect and assembler are
roles typically seen in this domain.
6.2 Product Line Architecture
The separation continuum is realized by having a high
level product line architecture mapped onto it. The
product line architecture needs to separate out the
essential elements needed to produce product lines
productively – software assets can be used in many
different product families and product lines.
Figure 6 shows three distinct groupings of concepts
used to realize a software system using the separation
continuum. Technology and platform architectures
form the basis on which software assets are built –
these can include platforms provided by, for example,
IBM, BEA or Microsoft. This paper is focused on
commercially related software - hence the use of
widely used commercial platforms.
Figure 6: Assembly and Product Line Architecture
and the separation continuum
Core software assets are the different elements that
make up a complete software product. All assets need
to be stored in a repository for ease of search and use
characteristics. Software components, designs and
documentation are built using patterns and
frameworks, and are all included as assets. Product
families are made up of product lines that are, in turn,
assembled from core software assets.
Product lines are produced from software assets to
satisfy a specific product space. This production
exercise should be executed with rigour, based on
processes that reflect mature capabilities. Scoping of
product lines has posed challenges to the production of
product lines [Schmid]. Producing the product, by
using the “independent synchronised product delivery”
[van Zylc] concept, poses risks to the team if the scope
of the asset and overall product line is not clearly
defined and communicated.
Part of the message here is that the separation
continuum is used to layer elements of a software
system – layering abstract into platform
implementation, and that assembly by means of using
software assets, forms the basis of productivity and
time-to-market gains.
6.3 Separation Continuum Implementation
The approach described next relies on the
understanding that systems have elements that are
stable and others that are volatile in the context of on-
going systemic evolution. Basically, one needs to
understand “the things that will stay the same” versus
“the things that might or will change” over a
particular time period. “The things that stay the
same” are developed in the underlying software
technology platform and represent stability. “The
things that change” are used to tell the software how
to behave and represent volatility. This is done by
means of using patterns when assembling systems.
Figure 7: Software asset creation using a pattern-
technology-assembly method
Patterns are used as a means to facilitate re-use of
requirements, software assets, designs, and other
artefacts needed to construct a system. Each pattern
describes the solution to a known problem. It also
describes the structural and behavioural solutions.
Patterns are classified as per the separation
continuum. It means that business model patterns
have certain system model patterns linked to it.
Certain system model patterns have application
portfolio elements linked to it, and so on.

Business needs, once analysed, can be mapped onto
business patterns relevant to a particular domain. If
new patterns are identified, a process is initiated
whereby a new pattern is created. These patterns form
the basis on which the final software system will be
constructed. The availability of patterns that show
how specific problems have been solved presents many
opportunities for business analysts to apply defined
knowledge. When used in productivity tools, patterns
realized previously give the development teams
comfort as re-use is implemented by means of pattern
recognition and application.
Figure 8: One user interface example of a completed
product line
Looking at the separation continuum it was seen that
the abstract layers describe only the patterns and
requirements needed by a business audience. The
platform implementation revealed software assets that
are used to construct the various product lines using
services and components. Once services are put to
use, the resultant product line reveals a “look and feel”
that are specific to the intended user. The user
interface and other user-facing aspects are typically
part of the “things that change” between two product
line implementations.
The example above shows a “tree-view” on the left
most panel that is constructed based on the user logon
credentials, role definition and process definition. The
panels in the work areas are also created by using a
role-based definition to ensure that attribute usage on
forms is appropriate for the intended application.
Many other non-visual software assets make up the
completed product line. The non-visual software
assets, for example, Web services used to obtain the
data that are filled in on the form, can be used by a
number of different visual devices.
The next section will explore how assets are built and
acquired through using the pattern-technology-
assembly method.
6.4 The Product Space
The previous section provided an introduction into the
concepts separating volatility from stability when
looking at software product lines. This section will
show how a final product is constructed using the
pattern library, assembly and technology platform
areas.
6.4.1 Pattern library
The pattern library provides descriptions of the
potential solutions that a client might require in a
specific domain. The separation continuum is used to
ensure the structure of the library is such that new
patterns can be added over time. The horizontal
continuum ensures the completeness and effective
separation of the various architectural elements, that
is, by having the following catered for: correct user
interface, user interface controller, connectivity,
business logic, and data.
The pattern library is the central location and method
where process and technology knowledge are captured.
All aspects of a solution can be “patternized”, even if
there is one pattern to match a particular software
component, COTS based component, or even a Web
service. For the sake of focus, this discussion will
focus only on patterns for the platform implementation
continuum.
Application patterns focus on coarse-grained software
systems that implement specific business systems.
These patterns need to cover all the aspects of an
application that make up the deployable product line.
They typically cover the specifics of how services and
components will be used in a final application.
Example application patterns are: electronic banking
and self-service banking terminal. Each of these will
have specific characteristics when used that might
include the way a user identifies himself/herself, how
the user interface is represented and used, and how a
legacy system is accessed.
Services patterns can be classified in the areas of user
interface, user interface controller, connectivity,
business logic and data. These classifications apply to
all the layers on the platform implementation
continuum. This is the layer where these patterns are
realized through physical software – a point where a
one-on-one relationship exists between a pattern and
its implementation by referencing a software asset.
Services can be constructed by using components or
might be used from an external source (for example,
Web services). Example services patterns are
ManageCustomer, TransferFunds, etc. There is a
mapping between services patterns and application
patterns.
Component patterns are classified the same way as the
services patterns. Since most software development
will take place at this layer and the object layer, a vast

number of patterns are available. Some specific ones
are: ManageHierarchy, StoreTransaction,
RetrieveTransaction, etc. There could also have been
components called ManageCustomer and
TransferFunds – the services layer becomes the
“externalization”of these components.
Each pattern should have behavioural and structural
definitions. Pattern behaviour is the common set of
stimuli, actions and responses that the pattern
implements. The pattern structure is the more static
definitions that the pattern needs, for example, data.
Each of these definitions can be made up of other
related behavioural and structural definitions.
Figure 9: An example of patterns in the Rubico
Assembler Tool
The tool shows available patterns, documentation of
the patterns and possible properties of a pattern. The
two primary areas in the tool are used as follows:
? The tree view on the left indicates the patterns as
classified in the library that is being browsed.
? The documentation for the selected pattern is
shown in the window on the right. Each pattern
has abstract, behaviour and abstract definitions as
per the Y-Model [van Zyld].
The population of the pattern library should be done
only once a clear understanding is formed of how a
product can be realized in the context of an
application. Analysis techniques need to be applied in
order to have the appropriate levels of abstraction
adhered to. The population and usage of patterns
involve various roles throughout the life cycle.
6.4.2 Assembly
Assembly of software assets takes place in the context
of available patterns. Patterns are “instantiated” by
being given values to a set of properties – making its
execution ready for a technology platform. Specific
roles throughout the process of constructing software
assets need to apply pattern usage characteristics to
ensure secure implementations.
The process of assembling systems starts with a
product definition or business need and follows
through to the final deployment of the executable
software. Roles in the assembly process might change
depending on the organizational requirements. Roles
like business analysts, component builder and
assembler need productive tools that assist with re-
using pre-built assets. The business analyst defines
the requirement; the component builder develops
components, and the assembler ties the various
components together.
When using patterns at the application layer, the
assembler role focuses on producing a product line
that can be deployed with all its related assets. The
application will contain all the services, components
and objects in order to execute on a selected
technology platform. The result is a definition of an
application package that can be deployed.
Constructing or using services can be done via using
the patterns at the services layer. Either new services
are constructed or existing ones used, when a product
line is realized. The assembly process facilitates this
process of creating new, using existing, and deploying
services for a product line.
Components are used or constructed in the assembly
process depending on application and service
requirements. Typically there are two paths to follow:
firstly – using existing components, either built
previously by using an Assembler tool or acquired
from an external party, or secondly – creating new
components by using an Assembler tool or industry
standard development environment.
Components can be realized using base generic
components through means of re-use techniques like
inheritance and service provision. The bulk of a
system’s functionality, as specified by a requirement,
lives in a component called the “business component”
and not in the underlying, and more generic,
components. Base generic components, business
components or services are implemented using the
horizontal continuum as a guide. Each component
will fit into user-interface, user-interface-controller,
connectivity, business-logic, or data, classifications.

Figure 10: Wiring of services and components
When software assets are created in the assembler
from a pattern library, they can be referred to as “top-
down development”. If existing assets are explored
(for example, legacy system components, custom
developed components and COTS based systems) and
are registered in the assembly environment, they can
be referred to as “bottom-up development”. The
process of “wiring” components and services together
to form a product line is largely simplified due to the
ability of separating out the various continuums.
6.4.3 Technical
The technology platform is used to realize the pattern
and its associated assembly attributes. Together these
three areas make up the finally deployable component
and/or service as part of a software product. Patterns
implemented in particular technology platforms (for
example, Java versus C# based), might require specific
environmental implementation variations where
security, data access and component invocation might
be different.
There always needs to be a set of core software assets
in order to execute on a particular platform.
Components need to be abstracted [Doerr] in order to
allow for changes in COTS-based systems over time.
This requires a number of non-functional requirements
to take preference over others (for example,
interoperability becomes very important in cross-
technology deployment).
Certain patterns are used as software requirements to
develop software assets. It must be taken into account
that the assembly process will define the ways in
which the pattern, once turned into a software asset,
can be executed. Behavioural and structural
requirements are specified by the assembler and
should not be developed in the underlying software
code. This means that the developer of a core software
asset, using the pattern as the specification, needs to
design and develop code that is flexible enough to
execute within the constraints of the pattern’s
specification. The combination of pattern, assembly
properties and technical platform code form a
deployable component.
COTS-based components can be registered in the
technology platform and used in the assembly process.
It must be considered that certification of COTS-based
systems needs to be taken into account when
assembling product lines [Yacoub]. Functional
attributes include the functionality inherent in the
COTS component and quality of service criteria (like
reliability ratings and security criteria). Structural
attributes include understandability and adaptablility.
Operational attributes relate to the execution
environment and rate efficiency of implementation
and user interface characteristics.
Figure 11: An example of how a tool can be used to
query services that are exposed on a particular
application server
Once a product line is deployed onto a particular
platform, it must be possible to view the installed
software assets. The example in figure 13 shows a list
of software assets, as services, that are exposed on a
particular application server in the list view on the
left-most panel. These services represent
implementations of components from a multitude of
unrelated platforms. They also provide the entry point
into registry standards like Universal Description,
Discovery and Integration (UDDI) [UDDI]. The
interface specification, that is, the contract, does not
reveal the “real” implementation but is a façade to the
component that contains the functionality. The
window on the right is where the contract is shown –
the interface to the service and component. All the
inputs, outputs and related information, which make
up the contract, are revealed to the enquirer. Based on
this example, it can be seen that software assets
available on a particular platform, can be exposed by
means of using an [XML] contract. This XML can be
exposed as Web Services Description Language
(WSDL) [WSDL] in order to describe it as a Web
service.

6.5 Producing Product Lines
The separation continuum presented a means by which
many different techniques can produce product lines.
Domain analysis or domain engineering techniques
are used to extract features systematically from
existing stakeholders of a product line [Griss]. This
process is cumbersome and can take a long time.
[Griss] proposes that “aspect-oriented” methods can be
used to simplify the process of delivering product line
features. Each feature that is obtained must be
realized in a fragment or code or component
implementation. No effort should be made to try to
manage the components while they are being built, but
to manage only the features and aspects.
Product lines are produced by understanding the
continuums that exist in making up the final product.
It also needs an architecture to take this systemic view,
being the continuums, and implement a practically
implementable system.
7. Discussion
Using product line principles to construct systems will
become more evident over time as system assembly
benefits are realized. The thinking of software as
assets will have an influence over the adoption already
seen in the components world. Product lines are
constructed using various software assets: those that
are part of existing development effort and those that
are classified as legacy. These disparate systems need
to communicate based on business requirements and
process definitions as defined by the product line.
Enterprise application integration as a discipline will
be affected by the implementation of Web services as
systems can communicate more easily due the high
level of standardization. It is ideal to have the various
architectures that exist, separated. These loosely
coupled systems can integrate easily if standardized
protocols are used, for example using Simple Object
Access Protocol (SOAP), XML over (Hypertext
Transfer Protocol (HTTP).
One major challenge of this kind of implementation –
by assembling solutions – is that design architects try
to deal with as many eventualities as possible (even for
the unforeseen) when designing and building the
underlying software infrastructure. Projects like
“San Francisco” (now called IBM Business
Components), found similar issues [Carey] as
developers try to build “tanks”, that is, “bullet-proof”
software. It took a long time and was very expensive –
only to realise that the industry has moved on. The
separation continuum must be seen as a means by
which developers, architects, design specialists, and
business analysts can participate when creating large
and complex systems in harmony. The continuum
facilitates the use of architectural principles that need
to be applied when using Web services. It also assists
to provide a means to re-use code written by others,
elsewhere, using their own set of tools.
The separation of business and technology has never
been more relevant than now. Assembling systems
from software assets (including Web services) that
have been implemented in a variety of languages and
architectures is the vision for the provision of
application software provision. It opens an entirely
new thread of discussion as to what software is
available on an organization’s infrastructure versus
that of its software-as-service supplier.
The separation continuum and product line
architecture described in this paper formed the basis of
work performed between 2000 and 2002. Examples
included were taken from actual software products,
either available or currently under development.
Strategic product development [van Zyla] and product
line practices provided the process and product-line
thinking required in order to produce these products.
1994 1996 1997 1998 1999 2001 20022000
Time
1.1.7
1.3.2
1.4.0
2.0
3.0
4.0
Figure 12: Rubico Technology product family life-line
(version of product family over time)
The major releases of Rubico Technology products are
reflected in Figure 12 and were used in a paper
presented at the first Software Product Line
Conference (SPLC1) called “Strategic Product
Development” [vanZyla]. Even though no
quantitative results are presented here, the benefits
were realized over the time-frame while developing
versions 2 and 3 and the architectural definition of
version 4. Version 4 is currently under development
and is benefiting from the product line practices
implemented in the past.
8. References
[Atkinson] Atkinson C., Bayer J. and Muthig D.
(2000). Component-based product line development.
Software product lines: Experience and research
directions. Edited by Patrick Donohoe. Kluwer Press.
ISBN 0-7923-7940-3.
[Bachman] Bachman F., Bass L., Carriere J. and
Clements P. (2000). Software architecture
documentation in practice: Documenting architectural

layers. CMU/SEI Special Report CMU/SEI-2000-SR-
004.
[Bass] Bass L., Clements P. and Kazman R. (1998).
Software architecture in practice. Addison Wesley
Press. ISBN 0-201-19930-0.
[Bosch] Bosch J. (2000). Design and use of software
architectures: Adopting and evolving a product-line
approach. Addison Wesley Press.
ISBN 0-201-67494-7.
[Buschmann] Buschmann F., Meunier R., Rohnert H.,
Sommerlad P. and Stal M. (2000). Pattern-oriented
software architecture: A system of patterns. John
Wiley & Sons. ISBN 0-471-95869-7.
[Calantone] Calantone R. and Benedetto A. (2000).
Performance and time to market: Accelerating cycle
time with overlapping stages. IEEE transactions on
Engineering Management. May. Vol. 47, No. 2.
[Carey] Carey J.E. and Carlson B. A. (1998).
Deferring design decisions in an application
framework. IBM Corporation. ACM Computing
Surveys.
[Clark] Clark K.B. and Fujimoto T. (1991). Product
development performance: Strategy, organisation, and
management in the world of auto industry. Harvard
Business School Press.
[Clements] Clements P. and Northrop L. (2001).
Software product lines, practices and patterns.
Addison Wesley Press. ISBN 0-201-70332-7.
[Constantinides] Constantinides C.A., Bader A.,
Elrad T.H., Fayed M.E. and Netinand P. (2000).
Designing an aspect-oriented framework in an object
oriented environment. ACM Computing Surveys.
March.
[Doerr] Doerr B.S. and Sharp D.C. (2000). Freeing
product line architectures from execution
dependencies. Software product lines: Experience and
research directions. Edited by Patrick Donohoe.
Kluwer Press. ISBN 0-7923-7940-3.
[Dsouza] Dsouza D. (2001). Model-driven architecture
opportunities and challenges. Kinetium.
http://www.kinetium.com/. Website accessed:
15 April 2002
[Griss] Griss M.L. (2000). Implementing product-line
features by composing aspects. Software product lines:
experience and research directions. Edited by Patrick
Donohoe. Kluwer Press. ISBN 0-7923-7940-3.
[MDA] Architecture board MDA drafting team.
(2001). Model driven architecture: A technical
perspective. Document Number ab/2001-02-01.
[Pronk] Pronk B.J. (2000). An interface-based
platform approach. Software product lines:
Experience and research directions. Edited by Patrick
Donohoe. Kluwer Press. ISBN 0-7923-7940-3.
[Rational] Rational Corporation. (2001). Reusable
asset specification. http://www.rational.com/eda/ras/.
Website accessed: 15 April 2002
[Schmid] Schmid K. (2000). Scoping software product
lines.
[SEI COTS] SEI (2000). An activity framework for
COTS-based systems. CMU/SEI-2000-TR-010.
[SEI Diffusion] SEI (1999). Perceived control of
software developers and its impact on the successful
diffusion of information technology. SEI
CMU/SEI-98-SR-013.
[SEI PLP] Clements P. and Northrop L.M. (1999).
A framework for software product line practice.
Version 2.0, SEI.
[UDDI] http://www.uddi.org/. Website accessed:
15 April 2002
[van Zyla] van Zyl J.A. (1999). Strategic product
development. SPLC1. Denver, USA,
28-31 August 2000
[van Zylb] van Zyl J.A. (2001). Class of solution
dilemma. IEEE Engineering Management Conference
proceedings. IEEE Electronic Library.
[van Zylc] van Zyl J.A. (2001). Product line balancing.
IEEE Engineering Management Conference
proceedings. IEEE Electronic Library.
[van Zyld] van Zyl J.A. (2001). A model that deals
with system complexity. Unpublished PhD thesis,
University of the Witwatersrand, Johannesburg, South
Africa.
[WSDL] http://www.wsdl.org/. Website accessed:
15 April 2002
[XML] http://www.xml.org/. Website accessed:
15 April 2002
[Yacoub] Yacoub S., Kaveri C. and Dehlin M. (2000).
A hierarchy of COTS certification criteria. Software
product lines: Experience and research directions.
Edited by Patrick Donohoe. Kluwer Press.
ISBN 0-7923-7940-3.

9. Author Contact Details
Jay (http://www.jayvanzyl.com/) is a founding
member of Rubico (http://www.rubico.com/).
His responsibilities include: defining and articulating
product strategy, software products and architecture,
and related methodology products. He entered the
industry in 1984 and held a number of strategic
positions in products and services related companies.
Jay has been involved with, and ran many strategic
projects locally and abroad.
He is also responsible for Rubico Products’
internationalization and strategic projects. During his
time with Rubico previous responsibilities included:
established strategic product development competency,
established education centre, and managed technical
and strategic interfaces with investors and clients. He
brought three generations of product to market and is
currently working on Rubico’s 4th
generation
technology.
Jay holds a masters degree and a PhD from the
University of Witwatersrand in South Africa, in
software engineering. His research covers software and
business engineering focusing on product and process
innovation. His latest work called “The Process
Innovation Imperative” is currently being prepared to
be published. He is a member of the advisory board of
the Quality Assurance Institute
(http://www.qaiusa.com/) situated in the United
States of America. He is a leading architect and
methodology expert and he holds Certified Quality
Analyst and Certified Software Test Engineer
certifications. He is an active member of a number of
ISO workgroups and is a member of both IEEE and
ACM.
Jay is widely published in academic and general
journals. The “Process Innovation Imperative” and
Rubico concepts have been presented around the world
and received great acceptance.
Contact details: Rubico (Pty) Ltd, P O Box 2628,
Fourways, 2055, Johannesburg, South Africa. Phone:
+27-(0)11-808-1000, Mobile: +27-(0)82-555-0646,
Fax: +27-(0)11-808-1101, E-mail: jay@rubico.com,
http://www.jayvanzyl.com and
http://www.rubico.com/.
?

PLA and the SC 2002-04-15

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (18)

Similar to PLA and the SC 2002-04-15

Similar to PLA and the SC 2002-04-15 (20)

More from Jay van Zyl

More from Jay van Zyl (13)

PLA and the SC 2002-04-15