Domain-Specific Software Engineering (DSSE). Software Engineering Concerns There are many of them “Classical” software architecture research has focused.

Domain-Specific Software Engineering (DSSE)

Software Engineering Concerns

There are many of them

“Classical” software architecture research has focused on one– Technology is king

A SA can be expressed using architecture description language (ADL)

What’s Out There?

Software

Archite

cture

What’s Out There?

Technology

Software

Archite

cture

What’s Out There?

Technology

Software

Archite

cture

Domain

What’s Out There?

Technology

Software

Archite

cture

Domain Business

The Three Lampposts (“3L”)

Excessive or exclusive focus on technology is a critical failing of early architecture research

3L provides the needed answer– Illuminates the space of architectural concerns

appropriately – Provides the necessary broad perspective on

architectures and their role in product development– Explains architectures’ successes and failures– Provides guidance for developers

Different lamps can still “shine” at different intensities

Technology

Domain Business

TechnologyTechnology

Domain Business

Concerned with – Recurring technical challenges of engineering systems– Means for representing and reasoning about

architectures– Examples: tools, applications, reusable components,

infrastructure, methods

Results in– Type on analysis on various models (data flow, potential

deadlock, system composition)– Linguistic means for describing architectures

• Interoperability among different ADLs– And some important ones

• How do we transform architectures into implementations

A Technology-DrivenArchitectural Model

Technology

Domain Business

DomainTechnology

Domain Business

Concerned with – Exploiting domain characteristics to aid system

development– Means for representing and reasoning about problems

in a given domain

Results in– Successful architectural approaches

• MetaH (Avionics ADL), C2 (components and message-based)

– Specialized, deeper solutions – Reusable assets

• Including the architecture!

– Engineers speaking the language of the target system’s users

How Domains Help

Technology

Domain Business

Traditional software development

How Domains Help

Technology

Domain Business

Architecture-based software development

SE Problem SpaceTechnology

Domain Business

How Domains Really Help

Technology

Domain Business

Domain-specific architecture-based software development

Business

Technology

Domain Business

Concerned with – Capturing and exploiting knowledge of the business

context– Costs

• Includes financial concerns

Results in– Product strategy (differentiate a product in target

market)– Processes (create, manage, and evolve product)– Means for capturing multiple stakeholder perspectives– Characterization of desired product qualities– What specifically, in an architecture?

• Product relationships to each other in product lines• Cost data per component

Putting It All Together

Domain scopes theproblem space

Business goals and

motivations

TechnologyGeneric solutions

and tools

CoreCompetencies

Solutions and toolsSpecialized for

a domain

GeneralInfrastructure

Domain-Specific Engineering

Product-LineArchitectures

What Is DSSA?

Assemblage of software components

– Specialized for particular type of task (domain)

– Composed in standardized structure (topology) effective for building successful applications

– E.g., IBM Deep Blue chess-playing game (elements designed to win a game), genetic-based SA (elements to mutate, select, crossover)

Components of DSSA

Domain model

Reference requirements

Reference architecture– Standardized architecture describing all systems in domain– Focuses on fundamental domain abstractions– Expressed in ADL

Supporting infrastructure/environment

Process/methodology to instantiate, refine, & evaluate it

» Will Tracz, 1995

Why Domain-specific Architecture?

Development can be optimized

– Domain-specific software patterns

– Domain-specific models & methods to analyse

Reuse potential is maximized

– Domain-specific requirements

– Domain-specific components

– Domain-specific software patterns

What Is A Domain Model?

“All models are wrong; some are useful.”» Unknown, SEI

Represents domain (problem space)

– Functions being performed

– Entities

– Information

Fundamental objective:

– Standardize problem domain’s terminology & semantics

• Terminology + semantics = ontology

– Provides basis for standard descriptions of problems to be solved

Domain Analysis

Identify, describe, & organizing objects, operations and patterns– Described using standardized vocabulary– Abstracted to suit

• Class of similar systems

• Particular problem domain

– To be reused when creating new systems

Produces domain model“Domain analysis is like several blind men

describing an elephant”

Elements Of Domain Model (1)

Customer needs statement– Identifies functional requirements– Informal– High-level – Ambiguous– Incomplete

Scenarios– Functional requirements– Data flow– Control flow– Elicited from the customer

Domain dictionary– Definitions of terms used– Updated over time

Elements Of Domain Model (2)

Context (block) diagram– High-level connection between major components of

system

Entity-relationship/Class models– Aggregation (“a-part-of”) & generalization (“is-a”)

relations

Data-/Message-flow modelsState transition modelsObject model

– First phase of component interface design

What Are Reference Requirements?Requirements that apply to entire domain

Contain– Defining characteristics of problem space

• Functional requirements• Non-functional (Qualities) requirements

– Limiting characteristics (constraints) on solution space

• Non-functional requirements (e.g., security, performance)

• Design requirements (e.g., architectural style, UI style)• Implementation requirements (e.g., platform, language)

What Is Reference Architecture?Standardized, generic architecture describing

“all” systems in domain

– Focuses on fundamental abstractions • Expose a hierarchical, compositional nature• Syntax & semantics of constituent high-level

components are specified

– Satisfies reference requirements• May need set of reference architectures to satisfy all

reference requirements

– Reusable, extendable, & configurable

Instantiated to create design architecture for specific system

Elements Of Reference Architecture

Reference architecture model– Topology based on architectural style– Component dependency diagram– Component interface descriptions– Constraints

• Parameter value ranges & relationships

Architecture schema or design record– Information about components & design alternatives– Domain- & implementation-specific

Rationale

Configuration decision tree– Used to instantiate system from reference architecture

DSSA Process With Principal Supporting Tool Types

ApplicationRequirements

Analysis

ApplicationDesign &

Development

ApplicationRequirements

DomainModel:

Context+

ReferenceRequirements

ReferenceArchitecture

Test &ValidationSystem

ApplicationSystem:

Architecture+

Components+

Platform Specs

RequirementsManagement ToolsModeling

Tools ArchitectureSpecification

Tools

ArchitectureRefinement

&Evolution

Tools

DSSA Support Tool Types

Domain modeling tools

Requirements management tools– Describe new application objects, attributes, & relationships– Detect inconsistency, incompleteness, ambiguity

Architecture specification tools– Refine reference architectures– Describe & constrain components & connectors

Architecture refinement & evolution tools– Configure reference architecture to meet application-specific

requirements– Specify & instantiate components– Compose configurations into executable form

Three Layers of DSSA EnvironmentsDomain

Architect

ApplicationEngineer

Operator

ReferenceArchitecture

Components

DevelopmentTools

Application ExecutionEnvironment

Domain-Specific ApplicationDevelopment Environment

Domain DevelopmentEnvironment

Instantiated Architecture

Avionics DSSA

Avionics Domain Application Generation Environment (ADAGE)

Layered reference architecture– Subsystems decomposed into primitive

components with standardized interfaces– Over 40 different realms with over 350 distinct

componentsrealm { x : component | (i,j) (xi.interface = xj.interface) }

ADAGE Reference Architecture Model Defined by

– Component realms – Domain-specific

composition constraints

Even simple avionics systems often require over 50 distinct components stacked 15 layers deep

Controls and Display

Flight Director

Guidance

Navigation Radio-Nav

Data Source Objects(sensors)

Summary Domain-Specific Software Architecture (DSSA) is

– Generalized solution for particular type of problem (domain)• Domain model• Reference requirements• Reference (parameterized) architecture• Supporting infrastructure/environment• Process/methodology to instantiate, refine, & evaluate it

– Configurable for specific problem

Benefits– Efficient development

• Don’t need to start from scratch– Requirements– Design– Implementation

– Reuse• Requirements• Components• Architectures/patterns