Domain specific Software Architecture

INTRODUCTION TO DSSA
 DSSA is basically ‘Software Architecture focused on a
particular domain.’
 Why is it focused to a particular domain?
a) To constraint the problem space
b) Facilitate focused development
 DSSA is a collection of structures of the system which
comprise of:
a) Software elements
b) Externally visible properties of those elements
c) Relationship among those components
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

Applications of DSSA
The process of
developing and
implementing
a DSSA is
called domain
engineering.
The process of
developing an
application
based on a
DSSA is called
application
engineering.
D
S
S
A

Problem Space & Solution Space
.
.
..
.
Problem Space
General Solution Space
Problem Space
divided as per the domain
.
.
.
.
?
General Solution Space
divided as per the domain

DSSA Components
(Classification of requirements)
Domain Model
• Defines the behaviour of applications in the system.
• Standardizes the domain terminologies & provides the system data flow.
• Provides standardized descriptions of problems to be solved in the domain.
Reference
Requirements
• Supports the design of the reference architecture.
• Divides the customers requirement into functional and non-functional
components.
• The requirements may be mandatory, optional or variable.
Reference
Architecture
• Describes a general computational framework.
• Represents a set of principal design decisions simultaneously applicable to
multiple related systems.
• Includes explicitly defined points of variation.
(Collect info. about the domain)
(Develop a generalized framework)

DSSA Components(cont.)
Domain
Model
Problem
Space
The problem space is simplified through the
creation of a domain model.

Reference
Architecture
Reference
Requirements
Solution
Space
DSSA Components(cont.)

Main Advantages of DSSA
• The overall cost is minimized as the
assets can be reused.
• The market share of the
organization can be increased by
developing related applications for
different users.

MODULE 1:
DOMAIN MODEL

Domain Model
Before the requirements can be determined, it is
necessary to understand the characteristics of the
system.
Domain model:
 Defines the behaviour of applications in the
system
 Standardizes the domain terminologies &
provides the system data flow.
 Provides standardized descriptions of problems
to be solved in the domain.
 Provides the vocabulary to formulate the
reference requirements.

Components of the Domain Model
 Scenarios
 Domain Dictionary
 Context/Block Diagram
 Entity-Relationship Diagram
 Object Model
 Data Flow Model
 State Transition Models
Information
model
Operational
model
Feature model

Scenario
Scenarios are a list of events which are helpful in
eliciting the requirements from the customer in an
informal manner.

Domain Dictionary
It consists of the explanation of the terms used in
the scenarios and the customer needs statement.
Example:

Context Information Diagram
It describes the high-level data flow between
the major components in the system.

Entity/Relationship (ER) Diagram
Represents the aggregation and generalization
relationships between entities.

Object diagram
An object-oriented approach is followed to identify
the objects which are mentioned along with their
attributes and operations.

Data-Flow Diagram
It focuses on the data exchanged within the
system, with no notion of control.

State-Transition Diagram
It describes the events and states that take
place in the domain.

MODULE 2:
REFERENCE REQUIREMENTS

Reference Requirements
Reference requirements are responsible for identifying
the portion of solution space that the domain model
(problem space) will map into.
Reference Requirements:
 Support the design of the reference architecture.
 Divides the customers requirement into functional
and non-functional components.
 The requirements may be mandatory, optional or
variable.
 Constrains the architecture and the implementation.

Components of Reference Requirements
 Functional Requirements
 Non-functional Requirements
 Design Requirements
 Implementation Requirements

Functional Requirements
Describes the functions to be performed as per the domain .

Non-Functional Requirements
Example: Security, Performance, Reliability.

Design Requirements
Example: Architecture style, User interface style.

Implementation Requirements

MODULE 3:
REFERENCE ARCHITECTURE

Reference Architecture Perquisites
There are no predefined standards for designing the
reference architecture
• This is one of the reasons, that it is supported by an extensive
documentation.
Architecture does not define implementation
• The architecture establishes constraints on downstream activities,
and those activities must produce finer-grained designs and code
that are compliant with the architecture.
Architecture is design but not all design is architecture
• There are many design decisions that are left unbound by the
architecture, and are happily left to the discretion and good
judgment of downstream designers and implementers.

Reference Architecture Perquisites
‘Design’ is a general term, don’t confuse it
with ‘System Design’ , which refers to the in-
depth view of the structure of the system.
An ‘architecture’ is a reusable design and a
‘reference architecture’ is a reusable design
for a family of systems in a particular domain.
Reference Architecture Model can also be
called as the architectural style of the system
which may be layered, pipe and filter etc.

Reference Architecture
It is a generic architecture focused on
fundamental abstractions of the domain.
• Describes a general computational
framework based on the chosen
architectural style.
• Represents a set of principal design
decisions simultaneously applicable to
multiple related systems.
• Includes explicitly defined points of
variation.

Architecture Hierarchy
Reference
Architecture
• First, a
generalized
architecture
is selected.
Application
Specific
Architecture
• Using the reference architecture,
an application specific
architecture is created.
Implementation
• The
implementation
of the
architecture is
carried out.

Components of Reference Architecture
 Reference Architecture Model
 Configuration Decision Tree
 Architecture Schema
 Dependency Diagram
 Component Interface Description
 Constraints
 Rationale

Reference Architecture Model
All designs start out with some simple
abstraction based on the architecture style.

Configuration Decision Tree
A subset of reference requirements is chosen and
a configuration decision tree is made accordingly.
Configuration is done at reference architecture
instantiation time.

Architecture Schema
Name/Type
Description
Reference
requirements satisfied
Data flow and control
flow diagrams
Design rationale
Interface and architecture
specifications and
dependencies
It is a collection point for knowledge about the components that
make up a DSSA.
All such details
are to be listed
for every
component
involved.GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

Dependency Diagram
The reference architecture dependency diagram reveals
component connections at a level of granularity reflecting
the architectural style chosen by the system architect.

Component Interface Description
The focus is on, how elements interact with their environments, not on how
elements are implemented. An Interface Description Language(IDL) is used
to describe the interface as per the syntax of the language chosen.
Ex: LILENNA

Constraints
Constraints are the ranges of parameter
values, relationships between parameter
values or components etc. which have to be
considered throughout the development of
a system.

Rationale
Rationales capture the motivation behind various
decisions, such as the partitioning of the system
into discrete elements and the formation of the
architecture in terms of connecting elements.
Rationales are inferences that can be structured as
an argument with the design decision being the
conclusion.

Domain specific Software Architecture

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Domain specific Software Architecture (20)

Recently uploaded (20)

Domain specific Software Architecture