Domain Specific Software Engineering (DSSE)
• Software Engineering, just as other engineering
disciplines, needs to take into account of the
different domain in which it is working.
• Consider the “electrical engineering” of Electric
Coffee Machine (household appliance) versus the
“electric engineering” of Airplane (avionics):
a) We may design the electric Coffee Maker in such a manner
that it is focused on properties such as speed of heating,
electric safety, and looks; but we know if it breaks the user
will just go buy a new one --- do NOT worry about
maintenance (reusable parts & replacement) too much.
b) We may design commercial Airplanes for super reliability
and safety first. Thus we want to design for frequent
maintenance (reusable parts and replacement). Then we
are concerned with speed and comfort. We are not
concerned with the “looks” of the airplane.
Our design concerns differ based on the different problem domain.
DSSE (cont.)
• Each Different Domain require potentially different:
–
–
–
–
Principles
Techniques
Processes
Tools
• Domain Specific Software Engineering is an approach to
developing software by leveraging the existing domain knowledge
(usually the “common” part) extensively:
1. Dividing requirements between those common across application domain and
those that are unique to the system
2. Common requirements can be tied to existing solutions, allowing design focus
on domain specific areas
3. Many of the software development activities are simplified through reuse of the
common material and focusing only on the domain specific areas separately
4. Separation of the tools and environments for common and domain specific
needs will make the development and support activities a lot clearer
5. Separation of the common from the domain specific will allow communications
to the various stakeholders easier, especially that the domain specific areas
may have their own “parochial” vocabulary.
General vs Domain Specific Software Engineering
.
.
.
.
?
.
searching for solution
- - - a big frustration
Problem Space
General Solution Space
.
.
..
Problem Space
by Domains
Solution Space by Domains
mapping specific domain problems to domain specific reference architecture
DSSE in terms of 3 Areas:
Domain, Business & Technology
Business
Domain
defines different
business goals
such as efficiency or
money
defines different
industry domain
concerns
Technology
defines various tools,
DSSE;
methodologies & processes
Product Lines
Interest lies where
(Domain∩Business∩Technology)
Domain Specific Software Architecture
• Domain Specific Software Architecture is a
set of principal design decisions composed
of:
1) A reference architecture which describes a
general computational framework for a significant
domain of applications
2) A component library of reusable chunks of
domain expertise
3) An application configuration method for selecting
and configuring components within the
architecture to meet particular application
requirements
DSSA is not free and is built over time upon deep experiences with the domain
Note: Only for
“Large”
Organizations?
DSSE
done
A “Process” View of DSSE and DSSA
Domain
Analysis
Domain
Model
Reference
Architecture Dev.
Ref. Arch.
Model
Parts of
DSSA
over
time
additional
reqs.
Framework &
Component Dev.
Framework &
Comp. Library
Product line
Development
Product Arch.
Model
Application
Development
Domain
Specific App.
Domain Model
• Domain model characterizes the problem space:
– Standardizes the domain terminologies and semantics
forming a domain ontology or domain system
– Provides the basis for standardized descriptions of problems
to be solved in that domain
• Consider the term, “lot” . What does this mean? A) It means a “parcel of
land” in the real estate industry. B) It means a “set of same type of items”
in manufacturing . C) It means “role in life” in sociology and psychology.
• Domain model is created as a result of:
1. Context analysis of those items within the domain context
and relating to those items outside of the domain context
2. Domain analysis via identifying, capturing, and organizing
those entities, functionalities, properties, and data which
recur across multiple applications within the specific
domain.
Domain Model (cont.)
• A domain model is made of 4 main components:
1) Domain dictionary composed of domain specific terms
2) Information model which is a collection of models built
from context analysis and information analysis
(domain analysis- describes the domain)
3) Feature model which describes the user/customers
expectations of the capabilities of the application in the
given domain
4) Operational model identifies how the applications
within the domain works:
Elements of Domain Model
Domain
Dictionary
Information
Model
Feature
Model
Operational
Mode
Context info
Diagram *
Feature
Relation
Diagram *
Data-flow
diagram
Use Case
diagram
Control-flow
diagram
Representation
Diagram *
State Transition
diagram
Entity-Relation
diagram
Semantic
Network *
Class (object)
diagram
Dictionary
Of “domain”
terms
“Interdependence” Capabilities (reqs.)
of entities in the
of the domain
domain
application
How application
Control and Data
“flow”
A Few Possibly-Unfamiliar Diagrams
• The domain model may use part or all of the different
diagrams to depict the models. Most are familiar to
software engineers but a few may not be:
– Context-information diagram - captures high level
information flow among entities within and outside of the
domain system (reminds one of “use case diagram”)
– Semantic network – a network diagram to represent relations
among concepts (entities) in the domain
– Feature-relation diagram – describes overall-all mission of
the domain application
– Representation diagram – describes how information is made
available to users (e.g. UI looks and flow )and other
applications
Domain Specific Software Architecture (DSSA)
& Reference (canonical) Requirements
• DSSA is focused on the “standard” or canonical parts of a
specific domain to create the reference architecture. It still
depends on the requirements specified. Such “standard’ or
canonical requirements for the domain is called the
“Reference Requirements”
• Reference Requirements are derived from customers in the same
application domain and contains:
–
–
–
–
Functional requirements
Non-functional requirements
Design requirements
Implementation requirements
• Reference requirements contains 3 parts:
– Mandatory features : applicable to all systems in the domain
– Optional features: applicable to only subsets of systems in the domain
– Variable features: known to differ in nature by “specific application” in the
domain
Note that reference requirements are similar to what is shown in feature model
Reference Architecture
• From the reference requirements & the domain model
(which speaks to business, technology, and a specific
domain), we can develop the Reference Architecture
which was defined earlier as:
Def: Reference Architecture is the set of principal
design decisions that are (1) simultaneously
applicable to multiple-related-systems, typically
within an application domain, (2) with explicitly
defined points of variation.
• A reference architecture may be “defined” via:
1. An architecture derived completely from a complete, single product in the domain
that serves as guidance for the future (not ideal –too narrow)
2. Incomplete variant architecture containing a specified common part among
products in the doamin and an unspecified part, which may vary. (drift & erosion?)
3. Domain-specific invariant architecture with explicitly “defined” points of variation
As you study “sample” retail apps ---- which way are you going to
approach your assignment ?
Developing Reference Architecture
• There is no “simple” path to when and how to
develop a reference architecture.
– Timing must be just right: not too early when not enough is
know or too late when everything is already developed. This
is a tall order ---- the best way may be do this incrementally
as enough information and knowledge are acquired.
– The form of the reference architecture can not be based on
a single product (too restrictive), nor just incomplete
invariant (may lack too much detail, especially on the
incomplete variable parts) ---- the best is the invariant
architecture with explicit points of variation.
Caution : too many points of variation can be combinatory nightmare!
e.g. 6 potential points of variation can give you 26 = 64 combinations of variations!
Product-Line Architecture
• The software industry has been building products in the form of
product-line. (e.g. Oracle database, Oracle HRM, MS Office Suite,
SAP ERP, etc.)
• Product-line architecture is similar to reference architecture in
DSSA, except in scope and completeness:
– product-line architecture captures the complete set of design
decisions of well-defined, multiple related products in the productline
– while DSSA reference architecture may have incomplete and
undefined parts
• Product-line architecture - design decisions which simultaneously
capture all the related products in the product-line. Some of these
decisions will be 1) common among all products, 2) some will be
common among a subset of the products and 3) some will be
unique to individual product in the product-line.
Tabular Method to specify Product-Line
(requirements and/or architecture)
Features or
Comp/connectors
Basic
Office Suite: Product-Line
Complete
Advanced
word processor
X
X
X
spread sheet
X
X
X
presentations
X
X
X
X
X
layout support
spell check
X
X
X
grammar check
X
X
X
X
file import/export
X
auto save
task management
multi-lingual
X
X
X
You can pick
or “select” your
own
a) Combinations
- single product
b) add more features
such as:
- re-do
- pagination
c) add more functions
- statistical calc.
Advantages of Product-line
• Biggest Rationale for Product-line is to gain “re-use”.
– Less cost (spread the cost across multiple products in the
family and lower the individual cost
→ lower pricing)
– Shorter schedule for subsequent products that share common
features and functionalities
– Better quality for subsequent products that share already
tested and proven features and functionalities
• Re-used common parts also reduces individual
product maintenance cost
– Share fix to common parts
– Share cost on improvements to the common parts
Domain Specific Architect
• Can you be a domain specific
architect. Yes, if you know:
– Software design
 Some specific application domain
– Technologies
– Standards that has to be kept
 Business economics
Domain
Business
Technology
Example: Payroll “Product-Line” Technology Based
Re-Architecting
Payroll
UNIX based Payroll
UNIX
Oracle
DB
IBM AS/400 based Payroll
web
cloud
Payroll
AS/400
Oracle
DB
AS/400
DB
Common DB
MS Window based Payroll
MS
SQL
Common UI
Payroll
MS/
Window
Now Consider the Domain & Business
• Domain Specific Considerations:
– Universal Part: inputting employee payroll information,
modifying employee payroll info, computing pay check,
printing pay check, performing direct deposit of pay check, ------ etc.
– Variable Parts: benefits management; retirement pension
management; amount of reports and history maintained ----etc.
• Business Specific Considerations:
– There will be 3 products in the product line: 1) Core, 2)
Complete, 3) Deluxe for customer “pricing” purposes
– International Versions based off US version and includes:
Spanish, French, Chinese, Japanese, Arabic versions for
international marketing purpose
– There will be two “maintenance” updates per year, which
includes: bug fixes, annual tax law change, minor updates
for customer satisfaction purpose
You can imagine the version control and configuration management nightmare for this!
General
Requirements
(Version 2)
General
Requirements
General
Requirements
(Version 3)
US (common) code
v3
US (common) code
v2
US (common) code
v1
French
( version 1 )
French
( version 3 )
French
( version 2 )
French
(version 2.1)
Japanese
( version 3 )
If Fench Version 2.1
came after Version 3,
we may need to build
a French V3.1
Japanese
( version 2 )
Japanese
( version 1 )
Brazilian
( version 3)
Brazilian
( version 2 )
Brazilian
( version 1 )
Example of Product “Family” ---- and Versioning