صفحه 1:
Domain-Specific
Software Architecture
and Product Lines
Software Architecture
Lecture 24
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reser
صفحه 2:
مت
Objectives
® Concepts
What is domain-specific software
engineering (DSSE)
* The “Three Lampposts” of DSSE: Domain,
Business, and Technology
* Domain Specific Software Architectures
© Product Lines
® Relationship between DSSAs, Product Lines,
and Architectural Styles
° Examples of DSSE at work
صفحه 3:
مت
Objectives
© Product Lines
® Relationship between DSSAs, Product Lines,
and Architectural Styles
e
صفحه 4:
مت
Product Lines
° Aset of related products that have substantial
commonality
* In general, the commonality exists at the
architecture level
© One potential ‘silver bullet’ of software engineering
* Power through reuse of
° Engineering knowledge
° Existing product architectures, styles, patterns
° Pre-existing software components and connectors
صفحه 5:
مت
Domains vs. Product Lines
Oowuies are ic the problew spuce, product bees ure it
the svluiog space
© Domain © Product Line
* Consumer » Sony WEGA TVs
electronics Boeing 747 Family
* Avionics GNU compiler
+ Compilers suite
Suite of games
built on same
engine
* Video games
صفحه 6:
مت
Business vs. Engineering Product
Lines
® Business Product Line
» A set of products marketed under a common banner
to increase sales and market penetration through
bundling and integration
° Engineering Product Line
A set of products that have substantial commonality
from a technical/engineering perspective
® Generally, business product lines are engineering
product lines and vice-versa, but not always
Applications bundled after a company acquisition
» Chrysler Crossfire & Mercedes SLK V6
صفحه 7:
1 مت
Business Motivation for Product
Lines
Expense to create product.
1 Income from seling the product
digs GoPtiware
م ب هزر
سد كد فس تیه یه صل 6066 160 > /#ماهدة. :88 5212 هادا ,عاب وها نعة! العم .«ماتره1” 0 سما زمه موه :م7 رد۳6 مد
صفحه 8:
مت
Business Motivation for Product Lines
Expense to create product
| Income from selling the product
سه
ناه وله
Coxiceeriog
ae Product 1 Product 1 Product 2-—_~Product 2
Expense Income Expense Income
! ! ! |
‘money
لل دور
۳ رمد لع مم7 04م ,مم11 رممد ichare-W: Tayler, Menai Masini سس isn i i hd
صفحه 9:
۳ مت
[Business Motivation for Product Lines
@roduct-ice-based
Product 1 Product 1
Expense — Income — product 2 Product 2
| ۱ Expense Income
money
time —————+
سوه دنه 0۵0۵۸۳ 16۲ هه 1 ۳96 رما بقع Tarery: ond Poocetee) ‘tchard-W: Taya; رممد متمدو نموه ویس eine:
صفحه 10:
مت
Capturing Product Line
Architectures
A A A
Common Common —)
© Common: features common to all products
° A: features specific to product A
© B: features specific to product B
© Product A= Common + A
© Product B = Common + B
صفحه 11:
مت
A Product-Line Architecture
© Definition: A product-line architecture captures
the architectures of many related products
simultaneously
© Generally employs explicit variation points in the
architecture indicating where design decisions
may diverge from product to product
صفحه 12:
ee RN ماص
A Lunar Lander Product Line
صفحه 13:
مت
Product Component Table
© Helps us
decide 5
whether 1
creating a 3
۱ 3 2 ۵ او و اوه product line
is viable or Bll d) >
feasible 3 3 1 5 5 5
Lite [X |x [x |x 1
Demo | x | x |X | x x
ظ | ۶ | ۶ | 1 | x
صفحه 14:
مت
Group Components into Features
© Not a mechanical
process
° Attempt to
identify (mostly) i :
orthogonal él. 8
features, or gig 5 1
features that alae 2
would be 1 9 5
beneficial in که[ ]| م 8
Alements:
different productsxcur
صفحه 15:
مت
Reconstitute Products from
Features
© Use technical and business 5 8
knowledge to identify which 3 8
combinations form feasible ع | 5 | لد | 3
or marketable products g 8 5 2
that will be constructed ۵ ۲ 9 ۲
Lunar Lander Lite 2 |
LunarLanderDemo | X xX |X
Lunar Lander Pro xX x
صفحه 16:
مت
Modeling Product Line
Architectures
Architectural models need to be diversified with و
information about variation points and features
» Not all ADLs have good support for this
Exceptions include
* Koala
® xADL 2.0
* These ADLs have explicit support for capturing
variation points
صفحه 17:
aw sore 9 ۱
fi ل
[cu cect ="
Satine
Loner |
{ope [ote
Cea crm ی
5: [cu سحت
اس
17
7 ۳ Acai; Wi THT) MARAE HGRLMRIAA ALS any ICY ies ci مسجو ظ
صفحه 18:
مت
Selection
© Product-line selection is the process of extracting
a single product architecture (or smaller product
line) from an architectural model that contains
explicit points of variation
® ADLs such as Koala and xADL 2.0 can do selection
automatically with tools
سد كد یه یه له ۵۳۵۵۸۵ 3۵۵۸۵۸۷۸۰۱۳۲ 16 ۳۳96 مومس Tarery: ond Poocetees Richard: W: Tayler; ‘Nenad رمک مان نموم تعد sine
صفحه 19:
ee RN ماص
Product Lines for Evolution
le Products in a product line don’t have to exclusively capture
alternatives
* They can also capture variation over time
1
سد كد لماي ده یه Sit 6069 6 :و هه 1 ۳46 مومس لاعفا .+مابرم1 3 سک رم او که رتم73 ومد مان نموم ویس eine:
صفحه 20:
ee RN ماص
Product Lines for Evolution
صفحه 21:
Product Lines for ‘What-If’
Analysis
© In addition to alternative products and different
versions of the same product, product lines can
capture different potentia/ products
Selection can be used to quickly generate
product architectures for potential products
* These can be checked for certain properties or
subjected to more rigorous analysis for
feasibility or quality
Can also be used to generate new product
ideas
صفحه 22:
مت
Implementation Issues
© Important to partition implementations along
variation-point boundaries
سوه دنه 0۵0۵۸۳ 16۲ هه 1 ۳96 رما بقع Tarery: ond Poocetee) ‘tchard-W: Taya; رممد متمدو نموه ویس eine:
صفحه 23:
0 ee eek ea cen ee nee [ced |
Implementation Issues (cont’d)
© Keeping evolving architectures and version-
controlled source repositories (e.g., RCS, CVS,
Subvers'*7* #= ~~ ميان
(as versoned ina sofware
configuration management system)
Text-Based UI
‘Component
Graphical UI
‘Component
سوه دنه 0۵0۵۸۳ 16۲ هه 1 ۳96 رما بقع Tarery: ond Poocetee) ‘tchard-W: Taya; رممد متمدو نموه ویس eine:
صفحه 24:
مت
Unifying Products with Different
Heritage
© Often, the idea to create a product line emerges after several
products have been implemented and commonality is noticed
© Strategies include
No product line
© It may be more expensive to create a product line or there
may not be enough commonality
One master product
© One product architecture becomes the basis for the
product line
Hybrid
© A new product line architecture emerges out of many
products
® Seems ideal but can be hard in practice
صفحه 25:
مت
Architectural Styles, DSSAs,
Product Lines
© Architectural Styles
» Can be general or domain-specific
* Provides general guidelines for diverse kinds of
applications; focus on -ility development
° DSSAs
* Domain specific; includes elaborate domain
model and specific reference architecture
© Product lines
» Explicit set of related products with common
aspects با سس ج | وه
EE
صفحه 26:
eR ae eRe ed
Families of Styles
‘Components
have one
input, one
‘output
Data moves
incharacter
streams
Data moves
in chunks
Linear
ordering of
‘components
Data moves
inone
direction
‘Components
‘execute in
parallel
‘Components
execute one
ata time
Nid WaiikesaeRLE 6: كوهة (6) رام امدة iO ده tink
> و رم موی نرتسو وهی sine:
صفحه 27:
0 ee eek ea cen ee nee [ced |
Objectives
© Examples of DSSE at work
صفحه 28:
مت
Koala
°® An ADL and tool-set for developing product lines
of consumer electronics
» A successor to Darwin in terms of structural
modeling
© One of the first ADLs to capture points of
variation explicitly
® Has tight bindings to implementations such that
architecture descriptions can be “compiled” into
application skeletons
صفحه 29:
مت
Lunar Lander in Koala
» No product line features yet
© Note similarities to Darwin,
XxADL 2.0
* xADL 2.0 Archipelago Game
visualization is derived و
from Koala ١
interface IDataStore{
void setAltitude(int altitudeInMeters) ; Poste إن
int getaltitude() ;
void setBurnRate(int newBurnRate) ;
int getBurnRate(); Dames
ata Store
31
7 سس
صفحه 30:
مت
Lunar Lander PL
Us
» Switch construct oe
routes calls to one
of two potential eee
data stores 0 =
© ‘Diversity interface’ 3
lets game logic |
4 M ١4
component select Tatestore
callee from
external config
component roatastore “مي
© Same |DataStore eMac Relational
interface ensures Data Store Data Store
call compatibility
صفحه 31:
مت
Software Defined Radios
Software-Defined 1
Radio Board General-Purpose
Processor(s)
5
i Aalog'o ti
z ۳ evetom
ممجم. ما سم سوه Components
Sianal
Processing |e“
نما AA
وم
عون ۹
Analog Converter nae
Components bt (input Davies)
® Variation points in radio configuration, board
configuration, software configuration
ja BLE Wi sah )6( و6 iO i A tink
۳ Procetees tcuard-m: Tayler, Nenad Masini
صفحه 32:
و ا2عوه:
83 ۳9
© Two-node “SCARI” SDR with just device drivers
loaded 22
Foundations; Thesry:; ond Procttee} Achiard:W: Taylor, “Nese Me ۳ سوه ی ی
صفحه 33:
© Same radio with one waveform deployed
سوه دنه 0۵0۵۸۳ 16۲ هه 1 ۳96 رما بقع Tarery: ond Poocetee) ‘tchard-W: Taya; رممد متمدو نموه ویس eine:
صفحه 34:
SDRs in xADL 2.0
© By applying product line techniques to SDRs
* Can manage different configurations of the radio
* Deploying components on alternative hosts
* Deployments with
* No waveforms
* One waveform
۶ Different combinations of waveforms
Can show radio in different states as radio starts
up or transitions from one waveform to another
Domain-Specific
Software Architecture
and Product Lines
Software Architecture
Lecture 24
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserv
Software Architecture: Foundations, Theory, and Practice
Objectives
Concepts
What is domain-specific software
engineering (DSSE)
The “Three Lampposts” of DSSE: Domain,
Business, and Technology
Domain Specific Software Architectures
Product Lines
Relationship between DSSAs, Product Lines,
and Architectural Styles
Examples of DSSE at work
2
Software Architecture: Foundations, Theory, and Practice
Objectives
Concepts
What is domain-specific software
engineering (DSSE)
The “Three Lampposts” of DSSE: Domain,
Business, and Technology
Domain Specific Software Architectures
Product Lines
Relationship between DSSAs, Product Lines,
and Architectural Styles
Examples of DSSE at work
3
Software Architecture: Foundations, Theory, and Practice
Product Lines
A set of related products that have substantial
commonality
In general, the commonality exists at the
architecture level
One potential ‘silver bullet’ of software engineering
Power through reuse of
Engineering knowledge
Existing product architectures, styles, patterns
Pre-existing software components and connectors
4
Software Architecture: Foundations, Theory, and Practice
Domains vs. Product Lines
Domains are in the problem space, product lines are in
the solution space
Domain
Consumer
electronics
Avionics
Compilers
Video games
Product Line
Sony WEGA TVs
Boeing 747 Family
GNU compiler
suite
Suite of games
built on same
engine
5
Software Architecture: Foundations, Theory, and Practice
Business vs. Engineering Product
Lines
Business Product Line
A set of products marketed under a common banner
to increase sales and market penetration through
bundling and integration
Engineering Product Line
A set of products that have substantial commonality
from a technical/engineering perspective
Generally, business product lines are engineering
product lines and vice-versa, but not always
Applications bundled after a company acquisition
Chrysler Crossfire & Mercedes SLK V6
6
Software Architecture: Foundations, Theory, and Practice
Business Motivation for Product
Lines
Traditional Software
Engineering
7
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Business Motivation for Product Lines
Traditional Software
Engineering
8
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Business Motivation for Product Lines
Product-line-based
engineering
9
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Capturing Product Line
Architectures
Common: features common to all products
A: features specific to product A
B: features specific to product B
Product A = Common + A
Product B = Common + B
10
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
A Product-Line Architecture
Definition: A product-line architecture captures
the architectures of many related products
simultaneously
Generally employs explicit variation points in the
architecture indicating where design decisions
may diverge from product to product
11
Software Architecture: Foundations, Theory, and Practice
A Lunar Lander Product Line
“Lite”
“Demo”
“Pro”
12
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Product Component Table
Data Store Connector
Game Logic
Game Logic Connector
Text-based UI
UI Plug-ins Connector
Graphical UI
System Clock
System Clock Connector
Demo Reminder
Helps us
decide
whether
creating a
product line
is viable or
feasible
Data Store
Lite
X
X
X
X
X
X
Demo
X
X
X
X
X
X
X
X
X
X
Pro
X
X
X
X
X
X
13
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
System Clock Connector
Demo Reminder
X
Graphical UI
X
UI Plug-ins Connector
X
Text-based UI
Game Logic Connector
X
System Clock
Graphical UI
Time
Limited
Game Logic
Not a mechanical
process
Attempt to
identify (mostly)
orthogonal
features, or
features that
would be
Core
beneficial in
Elements
different products
Text UI
Data Store Connector
Data Store
Group Components into Features
X
X
X
X
X
X
14
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Text UI
Graphical UI
Time Limited
Core Elements
Reconstitute Products from
Features
Lunar Lander Lite
X
X
Lunar Lander Demo
X
X
X
Lunar Lander Pro
X
X
Use technical and business
knowledge to identify which
combinations form feasible
or marketable products
that will be constructed
15
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Modeling Product Line
Architectures
Architectural models need to be diversified with
information about variation points and features
Not all ADLs have good support for this
Exceptions include
Koala
xADL 2.0
These ADLs have explicit support for capturing
variation points
16
Software Architecture: Foundations, Theory, and Practice
17
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Selection
Product-line selection is the process of extracting
a single product architecture (or smaller product
line) from an architectural model that contains
explicit points of variation
ADLs such as Koala and xADL 2.0 can do selection
automatically with tools
18
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Product Lines for Evolution
Products in a product line don’t have to exclusively capture
alternatives
They can also capture variation over time
19
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Product Lines for Evolution
20
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Product Lines for ‘What-If’
Analysis
In addition to alternative products and different
versions of the same product, product lines can
capture different potential products
Selection can be used to quickly generate
product architectures for potential products
These can be checked for certain properties or
subjected to more rigorous analysis for
feasibility or quality
Can also be used to generate new product
ideas
21
Software Architecture: Foundations, Theory, and Practice
Implementation Issues
Important to partition implementations along
variation-point boundaries
Bad
Good
22
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Implementation Issues (cont’d)
Keeping evolving architectures and versioncontrolled source repositories (e.g., RCS, CVS,
Subversion) in sync
23
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Unifying Products with Different
Heritage
Often, the idea to create a product line emerges after several
products have been implemented and commonality is noticed
Strategies include
No product line
It may be more expensive to create a product line or there
may not be enough commonality
One master product
One product architecture becomes the basis for the
product line
Hybrid
A new product line architecture emerges out of many
products
Seems ideal but can be hard in practice
24
Software Architecture: Foundations, Theory, and Practice
Architectural Styles, DSSAs,
Product Lines
Architectural Styles
Can be general or domain-specific
Provides general guidelines for diverse kinds of
applications; focus on –ility development
DSSAs
Domain specific; includes elaborate domain
model and specific reference architecture
Product lines
Explicit set of related products with common
aspects
Style
DSSA / Ref Arch
Product Line
25
Software Architecture: Foundations, Theory, and Practice
Families of Styles
26
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Objectives
Concepts
What is domain-specific software engineering
(DSSE)
The “Three Lampposts” of DSSE: Domain,
Business, and Technology
Domain Specific Software Architectures
Product Lines
Relationship between DSSAs, Product Lines, and
Architectural Styles
Examples of DSSE at work
27
Software Architecture: Foundations, Theory, and Practice
Koala
An ADL and tool-set for developing product lines
of consumer electronics
A successor to Darwin in terms of structural
modeling
One of the first ADLs to capture points of
variation explicitly
Has tight bindings to implementations such that
architecture descriptions can be “compiled” into
application skeletons
28
Software Architecture: Foundations, Theory, and Practice
Lunar Lander in Koala
No product line features yet
Note similarities to Darwin,
xADL 2.0
xADL 2.0 Archipelago
visualization is derived
from Koala
interface IDataStore{
void setAltitude(int altitudeInMeters);
int getAltitude();
void setBurnRate(int newBurnRate);
int getBurnRate();
...
}
29
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Lunar Lander PL in Koala
Switch construct
routes calls to one
of two potential
data stores
‘Diversity interface’
lets game logic
component select
callee from
external config
component
Same IDataStore
interface ensures
call compatibility
30
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
Software Defined Radios
Variation points in radio configuration, board
configuration, software configuration
31
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
SDR in xADL 2.0
Two-node “SCARI” SDR with just device drivers
loaded
32
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
SDR in xADL 2.0
Same radio with one waveform deployed
33
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Software Architecture: Foundations, Theory, and Practice
SDRs in xADL 2.0
By applying product line techniques to SDRs
Can manage different configurations of the radio
Deploying components on alternative hosts
Deployments with
No waveforms
One waveform
Different combinations of waveforms
Can show radio in different states as radio starts
up or transitions from one waveform to another
34