15.2.2 Canonical Requirements
Canonical Requirements = Reference Requirements
A set of requirements that applies across the entire domain that is captured by a Domain
Specific Software Architecture (DSSA).
Starting point for these requirements is often the customer’s statement of needs, taking into
account requirements of the individual legacy systems within the domain.
Contains functional requirements, non-functional requirements (security, performance,
reliability), design requirements (architectural style, UI style) and implementation requirements.
Also distinguishes between 3 types of requirements: Mandatory, Optional, Variable (Application
Specific)
15.2.3 Canonical Solution Strategies – Reference Architectures
Reference Architecture is the set of principal design decisions that are simultaneously applicable
to multiple related systems, typically within an application domain with explicitly defined points of
variations.
Many different kinds, differ in expressing commonalties and the points of variation in a
population or product line.
Book defines 3 classes:
Complete Single-Product Architecture
Incomplete invariant architecture
Invariant architecture with explicit variation
When to Develop a Reference Architecture?
Too early, large cost involved in changes
Too late, difficult to integrate into many diverse existing products
Should use an incremental approach with an eye towards the entire family of products
Choosing the Form of a Reference Architecture
Depends on domain, stakeholders, underlying business needs of organization(s)
involved
Complete Single-Product Architecture offers the least guidance in creating a family of
products
Incomplete invariant architecture tells architects directly what must be present in a
family member’s architecture, but lacks details about how to actually complete the elaboration process.
Invariant architectures with explicit variation points provides the most direction to
architects; not only do they say exactly what must be present in every family member’s architecture, but
they also effectively define all the members of the family.
15.2.4 Product Lines and Architecture
Many differences between designing a single-product architecture and a reference architecture;
chiefly that a reference architecture must serve as the basis for many different products simultaneously.
Tools and techniques exist for developing product line architectures, diversifying an ordinary
product architecture into an artifact suitable for describing many similar\related prodcuts.
Seen as a potential “silver bullet” of software architecture, potentially significantly reducing
costs and increasing software qualities. Product lines derives its power from reuse, particularly of
engineering knowledge, existing product architectures, styles and patterns, and preexisting software
components and connectors.
15.2.5 Product-Line Concepts
Various notions of product lines
Business Product Lines – set of products tied together to achieve business\monetary purposes.
Products in family do not necessary have similarity from an engineering standpoint.
Engineering Product Lines – set of products tied together by similarities in how they are
designed or constructed. Book uses example of Ford building a number of cars on the same engineering
platform, but marketing them under different brand names such as Lincoln, Mercury and Mazda.
15.2.6 Specifying the Architecture of a Product Line
The architectures of product lines differ from reference architectures by capturing the complete
architectures of multiple related products simultaneously. Reference architectures can be incomplete.
Two major differences: one of scope and one of completeness.
Product line architectures focus on a specific, explicit set of related products opposed to all of
those possible in a domain.
Product lines architectures also generally capture multiple complete product architectures
rather than leaving parts undefined.
Design decisions in a product line architecture may be common all of the products, some will be
common among a subset and others will be unique to individual products.
Extending an ordinary software architecture into a product line architecture can be
accomplished through the addition of variation points to create variant architectures. Each variant
architecture represents a different product – a member of the product line. A variation point is a set of
design decision that may or may not be included in the architecture of a given product.
The book uses 3 examples focusing around the Lunar Lander architecture: Lunar Lander Lite,
Lunar Lander Demo, and Lunar Lander Pro. These versions include several common systems such as a
Data Store and Game Logic but the UI and a System clock are variation points establishing these
different products. Products are created from combinations of the various variation points, although for
business reasons, not all combinations will be made into products.
Reducing a product line into a smaller product line or a single product is known as selection.
Approaches can be used that support the explicit specification of variation points and product lines
through architecture specific tools like Koala or xADL.
15.2.7 Capturing Variations Over Time
The products in a product line are often alternatives to one another, intended for simultaneous
development and release. However, product-line architectures also can be used to capture different
version of the same product over time. Various products capture the evolution of the original software
design unless something drastic occurs such as a complete rewrite.