DSSA, or Domain-Specific Software Architecture, focuses on specific domains to clarify the problem space and support targeted development through structured software elements and their relationships. It encompasses domain modeling, reference requirements, and reference architecture, facilitating efficient application development and minimizing overall costs by reusing components. Key components include functional and non-functional requirements, along with design principles that guide the architectural framework for related systems.

2. 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]

3. 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
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

4. Problem Space & Solution Space
.
.
..
.
Problem Space
General Solution Space
Problem Space
divided as per the domain
.
.
.
.
?
General Solution Space
divided as per the domain
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

5. 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)
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

6. DSSA Components(cont.)
Domain
Model
Problem
Space
The problem space is simplified through the
creation of a domain model.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

7. Reference
Architecture
Reference
Requirements
Solution
Space
DSSA Components(cont.)
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

8. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

9. MODULE 1:
DOMAIN MODEL
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

10. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

11. 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
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

12. Scenario
Scenarios are a list of events which are helpful in
eliciting the requirements from the customer in an
informal manner.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

13. Domain Dictionary
It consists of the explanation of the terms used in
the scenarios and the customer needs statement.
Example:
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

14. Context Information Diagram
It describes the high-level data flow between
the major components in the system.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

15. Entity/Relationship (ER) Diagram
Represents the aggregation and generalization
relationships between entities.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

16. Object diagram
An object-oriented approach is followed to identify
the objects which are mentioned along with their
attributes and operations.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

17. Data-Flow Diagram
It focuses on the data exchanged within the
system, with no notion of control.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

18. State-Transition Diagram
It describes the events and states that take
place in the domain.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

19. MODULE 2:
REFERENCE REQUIREMENTS
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

20. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

21. Components of Reference Requirements
 Functional Requirements
 Non-functional Requirements
 Design Requirements
 Implementation Requirements
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

22. Functional Requirements
Describes the functions to be performed as per the domain .
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

23. Non-Functional Requirements
Example: Security, Performance, Reliability.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

24. Design Requirements
Example: Architecture style, User interface style.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

25. Implementation Requirements
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

26. MODULE 3:
REFERENCE ARCHITECTURE
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

27. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

28. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

29. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

30. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

31. Components of Reference Architecture
 Reference Architecture Model
 Configuration Decision Tree
 Architecture Schema
 Dependency Diagram
 Component Interface Description
 Constraints
 Rationale
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

32. Reference Architecture Model
All designs start out with some simple
abstraction based on the architecture style.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

33. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

34. 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]

35. Dependency Diagram
The reference architecture dependency diagram reveals
component connections at a level of granularity reflecting
the architectural style chosen by the system architect.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

36. 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
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

37. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]

38. 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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]