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

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

Engineering

Domain specific Software Architecture