SlideShare a Scribd company logo
1 of 38
Download to read offline
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
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
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]
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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
Reference
Architecture
Reference
Requirements
Solution
Space
DSSA Components(cont.)
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
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]
MODULE 1:
DOMAIN MODEL
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
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]
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]
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]
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]
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]
Entity/Relationship (ER) Diagram
Represents the aggregation and generalization
relationships between entities.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
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]
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]
State-Transition Diagram
It describes the events and states that take
place in the domain.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
MODULE 2:
REFERENCE REQUIREMENTS
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
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]
Components of Reference Requirements
 Functional Requirements
 Non-functional Requirements
 Design Requirements
 Implementation Requirements
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
Functional Requirements
Describes the functions to be performed as per the domain .
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
Non-Functional Requirements
Example: Security, Performance, Reliability.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
Design Requirements
Example: Architecture style, User interface style.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
Implementation Requirements
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
MODULE 3:
REFERENCE ARCHITECTURE
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
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]
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]
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]
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]
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]
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]
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]
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.
GNDU, Amritsar [M.Tech. Software Systems 2012-2014 batch]
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]
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]
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]

More Related Content

What's hot

NIST Cloud Computing Reference Architecture
NIST Cloud Computing Reference ArchitectureNIST Cloud Computing Reference Architecture
NIST Cloud Computing Reference ArchitectureThanakrit Lersmethasakul
 
Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factorsNancyBeaulah_R
 
Software Configuration Management
Software Configuration ManagementSoftware Configuration Management
Software Configuration ManagementChandan Chaurasia
 
Unified process model
Unified process modelUnified process model
Unified process modelRyndaMaala
 
Importance & Principles of Modeling from UML Designing
Importance & Principles of Modeling from UML DesigningImportance & Principles of Modeling from UML Designing
Importance & Principles of Modeling from UML DesigningABHISHEK KUMAR
 
Design Concept software engineering
Design Concept software engineeringDesign Concept software engineering
Design Concept software engineeringDarshit Metaliya
 
Language and Processors for Requirements Specification
Language and Processors for Requirements SpecificationLanguage and Processors for Requirements Specification
Language and Processors for Requirements Specificationkirupasuchi1996
 
Software configuration management
Software configuration managementSoftware configuration management
Software configuration managementfizamustanser
 
Quality Management in Software Engineering SE24
Quality Management in Software Engineering SE24Quality Management in Software Engineering SE24
Quality Management in Software Engineering SE24koolkampus
 
Architecture design in software engineering
Architecture design in software engineeringArchitecture design in software engineering
Architecture design in software engineeringPreeti Mishra
 
Software Designing - Software Engineering
Software Designing - Software EngineeringSoftware Designing - Software Engineering
Software Designing - Software EngineeringPurvik Rana
 
Architectural Design in Software Engineering SE10
Architectural Design in Software Engineering SE10Architectural Design in Software Engineering SE10
Architectural Design in Software Engineering SE10koolkampus
 
Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9koolkampus
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)IIUI
 
Chapter 15 software product metrics
Chapter 15 software product metricsChapter 15 software product metrics
Chapter 15 software product metricsSHREEHARI WADAWADAGI
 
Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design pptfarazimlak
 

What's hot (20)

NIST Cloud Computing Reference Architecture
NIST Cloud Computing Reference ArchitectureNIST Cloud Computing Reference Architecture
NIST Cloud Computing Reference Architecture
 
Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factors
 
Chapter 2 software process models
Chapter 2   software process modelsChapter 2   software process models
Chapter 2 software process models
 
Software Configuration Management
Software Configuration ManagementSoftware Configuration Management
Software Configuration Management
 
Unified process model
Unified process modelUnified process model
Unified process model
 
Importance & Principles of Modeling from UML Designing
Importance & Principles of Modeling from UML DesigningImportance & Principles of Modeling from UML Designing
Importance & Principles of Modeling from UML Designing
 
Design Concept software engineering
Design Concept software engineeringDesign Concept software engineering
Design Concept software engineering
 
Language and Processors for Requirements Specification
Language and Processors for Requirements SpecificationLanguage and Processors for Requirements Specification
Language and Processors for Requirements Specification
 
Software configuration management
Software configuration managementSoftware configuration management
Software configuration management
 
Quality Management in Software Engineering SE24
Quality Management in Software Engineering SE24Quality Management in Software Engineering SE24
Quality Management in Software Engineering SE24
 
Architecture design in software engineering
Architecture design in software engineeringArchitecture design in software engineering
Architecture design in software engineering
 
Software design
Software designSoftware design
Software design
 
Software Designing - Software Engineering
Software Designing - Software EngineeringSoftware Designing - Software Engineering
Software Designing - Software Engineering
 
Component level design
Component   level designComponent   level design
Component level design
 
Architectural Design in Software Engineering SE10
Architectural Design in Software Engineering SE10Architectural Design in Software Engineering SE10
Architectural Design in Software Engineering SE10
 
Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)
 
Software process
Software processSoftware process
Software process
 
Chapter 15 software product metrics
Chapter 15 software product metricsChapter 15 software product metrics
Chapter 15 software product metrics
 
Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design ppt
 

Viewers also liked

1. Overview of Distributed Systems
1. Overview of Distributed Systems1. Overview of Distributed Systems
1. Overview of Distributed SystemsDaminda Herath
 
Software Architecture Lab
Software Architecture LabSoftware Architecture Lab
Software Architecture LabHenry Muccini
 
Group Decision Making to improve Software Resilience
Group Decision Making to improve Software ResilienceGroup Decision Making to improve Software Resilience
Group Decision Making to improve Software ResilienceHenry Muccini
 
20 examples on Domain-Specific Modeling Languages
20 examples on Domain-Specific Modeling Languages20 examples on Domain-Specific Modeling Languages
20 examples on Domain-Specific Modeling LanguagesJuha-Pekka Tolvanen
 
A summary of software architecture guide
A summary of software architecture guideA summary of software architecture guide
A summary of software architecture guideTriet Ho
 
Software Architecture Recovery: The 5 Questions You Always Asked Yourself Abo...
Software Architecture Recovery: The 5 Questions You Always Asked Yourself Abo...Software Architecture Recovery: The 5 Questions You Always Asked Yourself Abo...
Software Architecture Recovery: The 5 Questions You Always Asked Yourself Abo...mircea.lungu
 
Software Engineering - Ch11
Software Engineering - Ch11Software Engineering - Ch11
Software Engineering - Ch11Siddharth Ayer
 
Types of Network Architecture
Types of Network ArchitectureTypes of Network Architecture
Types of Network Architecturesabari Giri
 
Architectural styles and patterns
Architectural styles and patternsArchitectural styles and patterns
Architectural styles and patternsHimanshu
 
Software Architecture: Styles
Software Architecture: StylesSoftware Architecture: Styles
Software Architecture: StylesHenry Muccini
 
Distributed & parallel system
Distributed & parallel systemDistributed & parallel system
Distributed & parallel systemManish Singh
 
5.state diagrams
5.state diagrams5.state diagrams
5.state diagramsAPU
 
Information system
Information systemInformation system
Information systemhiddensoul
 
Three Software Architecture Styles
Three Software Architecture StylesThree Software Architecture Styles
Three Software Architecture StylesJorgen Thelin
 
Distributed Systems
Distributed SystemsDistributed Systems
Distributed SystemsRupsee
 
Hacking & its types
Hacking & its typesHacking & its types
Hacking & its typesSai Sakoji
 

Viewers also liked (20)

1. Overview of Distributed Systems
1. Overview of Distributed Systems1. Overview of Distributed Systems
1. Overview of Distributed Systems
 
Software Architecture Lab
Software Architecture LabSoftware Architecture Lab
Software Architecture Lab
 
Group Decision Making to improve Software Resilience
Group Decision Making to improve Software ResilienceGroup Decision Making to improve Software Resilience
Group Decision Making to improve Software Resilience
 
20 examples on Domain-Specific Modeling Languages
20 examples on Domain-Specific Modeling Languages20 examples on Domain-Specific Modeling Languages
20 examples on Domain-Specific Modeling Languages
 
A summary of software architecture guide
A summary of software architecture guideA summary of software architecture guide
A summary of software architecture guide
 
Domain Driven Design 101
Domain Driven Design 101Domain Driven Design 101
Domain Driven Design 101
 
Software Architecture Recovery: The 5 Questions You Always Asked Yourself Abo...
Software Architecture Recovery: The 5 Questions You Always Asked Yourself Abo...Software Architecture Recovery: The 5 Questions You Always Asked Yourself Abo...
Software Architecture Recovery: The 5 Questions You Always Asked Yourself Abo...
 
Software Engineering - Ch11
Software Engineering - Ch11Software Engineering - Ch11
Software Engineering - Ch11
 
Types of Network Architecture
Types of Network ArchitectureTypes of Network Architecture
Types of Network Architecture
 
Architectural styles and patterns
Architectural styles and patternsArchitectural styles and patterns
Architectural styles and patterns
 
Software Architecture: Styles
Software Architecture: StylesSoftware Architecture: Styles
Software Architecture: Styles
 
Distributed & parallel system
Distributed & parallel systemDistributed & parallel system
Distributed & parallel system
 
5.state diagrams
5.state diagrams5.state diagrams
5.state diagrams
 
ARCHITECTURAL STYLES
ARCHITECTURAL STYLESARCHITECTURAL STYLES
ARCHITECTURAL STYLES
 
software architecture
software architecturesoftware architecture
software architecture
 
Information system
Information systemInformation system
Information system
 
Three Software Architecture Styles
Three Software Architecture StylesThree Software Architecture Styles
Three Software Architecture Styles
 
Layered Software Architecture
Layered Software ArchitectureLayered Software Architecture
Layered Software Architecture
 
Distributed Systems
Distributed SystemsDistributed Systems
Distributed Systems
 
Hacking & its types
Hacking & its typesHacking & its types
Hacking & its types
 

Similar to Domain specific Software Architecture

Mdsd capable target architecture
Mdsd capable target architectureMdsd capable target architecture
Mdsd capable target architecturerida mariam
 
Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxKarthigaiSelviS3
 
Unit_4_Software_Design.pptx
Unit_4_Software_Design.pptxUnit_4_Software_Design.pptx
Unit_4_Software_Design.pptxtaxegap762
 
[2015/2016] Introduction to software architecture
[2015/2016] Introduction to software architecture[2015/2016] Introduction to software architecture
[2015/2016] Introduction to software architectureIvano Malavolta
 
Evolution of Modelling Techniques for Service Oriented Architecture
Evolution of Modelling Techniques for Service Oriented ArchitectureEvolution of Modelling Techniques for Service Oriented Architecture
Evolution of Modelling Techniques for Service Oriented ArchitectureIJERA Editor
 
Technical Architecture
Technical ArchitectureTechnical Architecture
Technical Architecturescmiyer
 
Interface management incose2014_lisi
Interface management incose2014_lisiInterface management incose2014_lisi
Interface management incose2014_lisiMarco Lisi
 
Software enginnering
Software enginneringSoftware enginnering
Software enginneringIshucs
 
Lecture # 8 software design and architecture (SDA).ppt
Lecture # 8 software design and architecture (SDA).pptLecture # 8 software design and architecture (SDA).ppt
Lecture # 8 software design and architecture (SDA).pptesrabilgic2
 
J2EEPlatformsandMicrosoft007
J2EEPlatformsandMicrosoft007J2EEPlatformsandMicrosoft007
J2EEPlatformsandMicrosoft007Jay van Zyl
 
Introduction to SOFTWARE ARCHITECTURE
Introduction to SOFTWARE ARCHITECTUREIntroduction to SOFTWARE ARCHITECTURE
Introduction to SOFTWARE ARCHITECTUREIvano Malavolta
 
Adopting the open group cloud eco system reference model
Adopting the open group cloud eco system reference modelAdopting the open group cloud eco system reference model
Adopting the open group cloud eco system reference modelKrishna-Kumar
 
A pattern based approach to the development of updm architectures
A pattern based approach to the development of updm architecturesA pattern based approach to the development of updm architectures
A pattern based approach to the development of updm architecturesGraham Bleakley
 
5.2.2013 2013 2013 - Software, System, & IT Architecture - Good Design is G...
5.2.2013 2013   2013 - Software, System, & IT Architecture - Good Design is G...5.2.2013 2013   2013 - Software, System, & IT Architecture - Good Design is G...
5.2.2013 2013 2013 - Software, System, & IT Architecture - Good Design is G...IBM Rational
 

Similar to Domain specific Software Architecture (20)

Mdsd capable target architecture
Mdsd capable target architectureMdsd capable target architecture
Mdsd capable target architecture
 
DESIGN CONCEPTS
DESIGN CONCEPTSDESIGN CONCEPTS
DESIGN CONCEPTS
 
Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptx
 
Chapter1
Chapter1Chapter1
Chapter1
 
Unit_4_Software_Design.pptx
Unit_4_Software_Design.pptxUnit_4_Software_Design.pptx
Unit_4_Software_Design.pptx
 
SA_UNIT_1.pptx
SA_UNIT_1.pptxSA_UNIT_1.pptx
SA_UNIT_1.pptx
 
[2015/2016] Introduction to software architecture
[2015/2016] Introduction to software architecture[2015/2016] Introduction to software architecture
[2015/2016] Introduction to software architecture
 
Evolution of Modelling Techniques for Service Oriented Architecture
Evolution of Modelling Techniques for Service Oriented ArchitectureEvolution of Modelling Techniques for Service Oriented Architecture
Evolution of Modelling Techniques for Service Oriented Architecture
 
Technical Architecture
Technical ArchitectureTechnical Architecture
Technical Architecture
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Interface management incose2014_lisi
Interface management incose2014_lisiInterface management incose2014_lisi
Interface management incose2014_lisi
 
SOA Course - Next Generation
SOA Course - Next GenerationSOA Course - Next Generation
SOA Course - Next Generation
 
Software enginnering
Software enginneringSoftware enginnering
Software enginnering
 
Lecture # 8 software design and architecture (SDA).ppt
Lecture # 8 software design and architecture (SDA).pptLecture # 8 software design and architecture (SDA).ppt
Lecture # 8 software design and architecture (SDA).ppt
 
J2EEPlatformsandMicrosoft007
J2EEPlatformsandMicrosoft007J2EEPlatformsandMicrosoft007
J2EEPlatformsandMicrosoft007
 
Introduction to SOFTWARE ARCHITECTURE
Introduction to SOFTWARE ARCHITECTUREIntroduction to SOFTWARE ARCHITECTURE
Introduction to SOFTWARE ARCHITECTURE
 
Adopting the open group cloud eco system reference model
Adopting the open group cloud eco system reference modelAdopting the open group cloud eco system reference model
Adopting the open group cloud eco system reference model
 
A pattern based approach to the development of updm architectures
A pattern based approach to the development of updm architecturesA pattern based approach to the development of updm architectures
A pattern based approach to the development of updm architectures
 
5.2.2013 2013 2013 - Software, System, & IT Architecture - Good Design is G...
5.2.2013 2013   2013 - Software, System, & IT Architecture - Good Design is G...5.2.2013 2013   2013 - Software, System, & IT Architecture - Good Design is G...
5.2.2013 2013 2013 - Software, System, & IT Architecture - Good Design is G...
 

Recently uploaded

S1S2 B.Arch MGU - HOA1&2 Module 3 -Temple Architecture of Kerala.pptx
S1S2 B.Arch MGU - HOA1&2 Module 3 -Temple Architecture of Kerala.pptxS1S2 B.Arch MGU - HOA1&2 Module 3 -Temple Architecture of Kerala.pptx
S1S2 B.Arch MGU - HOA1&2 Module 3 -Temple Architecture of Kerala.pptxSCMS School of Architecture
 
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...soginsider
 
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...Call Girls Mumbai
 
Standard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power PlayStandard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power PlayEpec Engineered Technologies
 
Thermal Engineering -unit - III & IV.ppt
Thermal Engineering -unit - III & IV.pptThermal Engineering -unit - III & IV.ppt
Thermal Engineering -unit - III & IV.pptDineshKumar4165
 
Learn the concepts of Thermodynamics on Magic Marks
Learn the concepts of Thermodynamics on Magic MarksLearn the concepts of Thermodynamics on Magic Marks
Learn the concepts of Thermodynamics on Magic MarksMagic Marks
 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXssuser89054b
 
HOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptx
HOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptxHOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptx
HOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptxSCMS School of Architecture
 
Employee leave management system project.
Employee leave management system project.Employee leave management system project.
Employee leave management system project.Kamal Acharya
 
Online food ordering system project report.pdf
Online food ordering system project report.pdfOnline food ordering system project report.pdf
Online food ordering system project report.pdfKamal Acharya
 
Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086anil_gaur
 
Computer Networks Basics of Network Devices
Computer Networks  Basics of Network DevicesComputer Networks  Basics of Network Devices
Computer Networks Basics of Network DevicesChandrakantDivate1
 
Bridge Jacking Design Sample Calculation.pptx
Bridge Jacking Design Sample Calculation.pptxBridge Jacking Design Sample Calculation.pptx
Bridge Jacking Design Sample Calculation.pptxnuruddin69
 
HAND TOOLS USED AT ELECTRONICS WORK PRESENTED BY KOUSTAV SARKAR
HAND TOOLS USED AT ELECTRONICS WORK PRESENTED BY KOUSTAV SARKARHAND TOOLS USED AT ELECTRONICS WORK PRESENTED BY KOUSTAV SARKAR
HAND TOOLS USED AT ELECTRONICS WORK PRESENTED BY KOUSTAV SARKARKOUSTAV SARKAR
 
Generative AI or GenAI technology based PPT
Generative AI or GenAI technology based PPTGenerative AI or GenAI technology based PPT
Generative AI or GenAI technology based PPTbhaskargani46
 
Block diagram reduction techniques in control systems.ppt
Block diagram reduction techniques in control systems.pptBlock diagram reduction techniques in control systems.ppt
Block diagram reduction techniques in control systems.pptNANDHAKUMARA10
 
AIRCANVAS[1].pdf mini project for btech students
AIRCANVAS[1].pdf mini project for btech studentsAIRCANVAS[1].pdf mini project for btech students
AIRCANVAS[1].pdf mini project for btech studentsvanyagupta248
 
Thermal Engineering-R & A / C - unit - V
Thermal Engineering-R & A / C - unit - VThermal Engineering-R & A / C - unit - V
Thermal Engineering-R & A / C - unit - VDineshKumar4165
 

Recently uploaded (20)

S1S2 B.Arch MGU - HOA1&2 Module 3 -Temple Architecture of Kerala.pptx
S1S2 B.Arch MGU - HOA1&2 Module 3 -Temple Architecture of Kerala.pptxS1S2 B.Arch MGU - HOA1&2 Module 3 -Temple Architecture of Kerala.pptx
S1S2 B.Arch MGU - HOA1&2 Module 3 -Temple Architecture of Kerala.pptx
 
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
 
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
 
Standard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power PlayStandard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power Play
 
Thermal Engineering -unit - III & IV.ppt
Thermal Engineering -unit - III & IV.pptThermal Engineering -unit - III & IV.ppt
Thermal Engineering -unit - III & IV.ppt
 
Learn the concepts of Thermodynamics on Magic Marks
Learn the concepts of Thermodynamics on Magic MarksLearn the concepts of Thermodynamics on Magic Marks
Learn the concepts of Thermodynamics on Magic Marks
 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 
HOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptx
HOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptxHOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptx
HOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptx
 
Employee leave management system project.
Employee leave management system project.Employee leave management system project.
Employee leave management system project.
 
Online food ordering system project report.pdf
Online food ordering system project report.pdfOnline food ordering system project report.pdf
Online food ordering system project report.pdf
 
Integrated Test Rig For HTFE-25 - Neometrix
Integrated Test Rig For HTFE-25 - NeometrixIntegrated Test Rig For HTFE-25 - Neometrix
Integrated Test Rig For HTFE-25 - Neometrix
 
Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086
 
Computer Networks Basics of Network Devices
Computer Networks  Basics of Network DevicesComputer Networks  Basics of Network Devices
Computer Networks Basics of Network Devices
 
Bridge Jacking Design Sample Calculation.pptx
Bridge Jacking Design Sample Calculation.pptxBridge Jacking Design Sample Calculation.pptx
Bridge Jacking Design Sample Calculation.pptx
 
HAND TOOLS USED AT ELECTRONICS WORK PRESENTED BY KOUSTAV SARKAR
HAND TOOLS USED AT ELECTRONICS WORK PRESENTED BY KOUSTAV SARKARHAND TOOLS USED AT ELECTRONICS WORK PRESENTED BY KOUSTAV SARKAR
HAND TOOLS USED AT ELECTRONICS WORK PRESENTED BY KOUSTAV SARKAR
 
Generative AI or GenAI technology based PPT
Generative AI or GenAI technology based PPTGenerative AI or GenAI technology based PPT
Generative AI or GenAI technology based PPT
 
Block diagram reduction techniques in control systems.ppt
Block diagram reduction techniques in control systems.pptBlock diagram reduction techniques in control systems.ppt
Block diagram reduction techniques in control systems.ppt
 
AIRCANVAS[1].pdf mini project for btech students
AIRCANVAS[1].pdf mini project for btech studentsAIRCANVAS[1].pdf mini project for btech students
AIRCANVAS[1].pdf mini project for btech students
 
Thermal Engineering-R & A / C - unit - V
Thermal Engineering-R & A / C - unit - VThermal Engineering-R & A / C - unit - V
Thermal Engineering-R & A / C - unit - V
 
Call Girls in South Ex (delhi) call me [🔝9953056974🔝] escort service 24X7
Call Girls in South Ex (delhi) call me [🔝9953056974🔝] escort service 24X7Call Girls in South Ex (delhi) call me [🔝9953056974🔝] escort service 24X7
Call Girls in South Ex (delhi) call me [🔝9953056974🔝] escort service 24X7
 

Domain specific Software Architecture

  • 1.
  • 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]
  • 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]