Domain-Specific Software EngineeringAlex Adamec

Overview• Domain-Specific Software Engineering (DSSE) – An approach

to software engineering that is characterized by extensively leveraging existing domain knowledge.• Guided by the observation that certain problems belong to

specific, well-defined problem classes, or domains

Advantages of DSSE• The requirements for a system can be divided into those

common across the application domain and those unique to the system.

• The common requirements can be tied to the existing canonical solutions, allowing developers to focus on the remaining subset.

• The system implementation, testing, and maintenance are simplified because of the already-existing reusable software “assets”.• Engineering knowledge, design models, implemented

subsystems, test suites, deployment scripts, etc.• Development activities are simplified through software tools

and environments that are specialized for the domain.

Advantages of DSSE• Any concerns are more easily communicated among the

system’s stakeholders because of the shared understanding, experience, and even terminology, which may have been developed incrementally and may be specific to the application domain.

Similar Problems, Similar Solutions

• The principal task of the software engineer is to find a way of taking the problem description, which exists in the problem space, and mapping it to a software system, which exists in the solution space.• Is difficult in general because the two spaces are usually

characterized by different concepts, with different terminologies and different properties

• Also difficult because, in general, there are often many possibilities for addressing a given software requirement

Traditional Software EngineeringAny given software development problem can be solved in a large number of ways.

Architecture-Based Software EngineeringAny given software development problem can be solved by a finite number of software

architectures.

Domain-Specific Software EngineeringSome software development problems belong to specific classes of problems for which known (partial) architectural and

implementation solutions exist. Those partial architectures are then tailored to the specific problem at hand and implemented using well-understood techniques.

Similar Problems, Similar Solutions

• Within each domain, effective (partial) architectural solutions can be identified and documented.• Known as reference architectures

• Instead of developing new architectures for each new problem in the domain, solutions can be derived by tailoring the reference architecture.

• Commonalities across the different problems in the same domain allow engineers to develop solid intuitions about a system before it is built, evaluate their solutions, and leverage a large number of powerful tools for generating and evaluating system implementations.

Three Principal Concerns of DSSE

• Domain – scopes the discourse, the problem space, and the solution space.

• Business Goals – motivate the work and help engineers decide why they are doing what they are doing.

• Technology – used to facilitate development and reuse of domain- and business-specific assets.

Domain

Scopes the Problem Space

Core Competencies

DSSEProduct Lines

Solutions andTools Specialized

for a Domain

General Infrastructure

Business

Goals and Motivation

Technology

General Solutions and Tools

Domain• Establishes a problem

space• Has defined

characteristics, a vocabulary, a motivation (why this domain exists), and so on• Must have a domain to

constrain the problem space and focus development

Business• Largely concerned with

human goals: improving people’s quality of life through the creation of new products, attaining money, power, notoriety, and so on• These goals motivate

people to solve problems

Technology• Comprises tools,

applications, reusable components, infrastructure, and methods that can be applied generally.• “Solutions without

problems”• Must have a variety of

technological solutions to bring to bear on a domain

Domain + Business• Expertise and core

competencies• Business organizations

specialize their skills to optimize them for particular domains.• E.g. building airplanes

Business + Technology• Business organizations will

acquire and develop technologies that are relevant to its overall goals but that can be applied to many domains.• E.g. A software development

company will have an infrastructure containing compilers, operating systems, networks, office applications, etc. that do not apply specifically to any domain

Domain + Technology• Contains tools, methods,

and architectures that are specifically applicable to a particular domain, but are independent of any particular business goal.• E.g. A programming

language and compiler that are specifically developed for building aircraft software would fall into this category.

Domain + Business + Technology

• Core of domain-specific software engineering: business goals motivating the identification and creation of a solution in the problem space of a domain, facilitated by the use of technology

Key Architecturally Relevant Areas of DSSE

• Domain-Specific Software Architecture• Product Lines

Domain-Specific Software Architecture

• A domain-specific software architecture (DSSA) comprises:• A reference architecture, which describes a general

computational framework for a significant domain of applications• A component library, which contains reusable chunks of domain

expertise• An application configuration method for selecting and configuring

components within the architecture to meet particular application requirements

Domain Model• A representation of what happens in an application domain• Includes the functions being performed, the objects (entities) performing

the functions and those on which the functions are performed, and the data and information flowing among the entities and/or functions

• The objective of a domain model is to• Standardize the given problem domain’s ontology (its terminology and

semantics)• Provide the basis for standardized descriptions of problems to be solved

in the domain• Comprised of several pieces of information that together present

a useful picture of the domain assets and their interrelationships• Domain dictionary• Information model• Feature model• Operational model

Domain Model• Defines

vocabulary for the domain

• Describes the entities and data in the domain

• Defines how entities and data combine to provide features

• Defines how data and control flow through entities

Domain DictionaryRepresents the identification and definitions of terms used in the domain model

Information Model• A result of context analysis and information analysis• Ensures that the DSSA employs appropriate data abstractions

and decompositions• A collection of multiple models that may be used in different

organizations and different DSSA’s• Context Information Diagram• Entity/Relationship (ER) Diagram• Object Diagram

Context Information DiagramDefines high-level entities

Defines what is considered inside and outside the domain (or subdomains)Defines relationships and high-level flows

Entity Relationship DiagramDefines entities and cardinal relationships between them

Object DiagramDefines attributes and operations on entities

Feature Model• Results from feature analysis• Considered to be the chief means of communication between

the customers and the developers of new applications• Explicitly delineates the commonalities and differences among

systems in the domain• A collection of several models• Feature Relationship Diagram• Use-Case Diagram• Representational Model

Feature-Relationship DiagramDescribes overall mission operations of a system

Describes major features and decomposition

Use-Case DiagramDefines use cases within the domain

Representational ModelDefines how information is presented to human users

Operational Model• A result of operational analysis• Foundation upon which the software designer begins the process of

understanding• How to provide the features for a particular system in the domain• How to make use of the entities identified in the resulting domain

model• Identifies the key operations (functions) that occur within the

domain, the data exchanged among those operations, and the commonly occurring sequences of those operations• How applications within a domain work

• Three representative types of diagrams used within the operational model are• Data-Flow Diagram• Control-Flow Diagram• State-Transition Diagram

Data-Flow DiagramFocuses on data flow between entities with no notion of control

Control Flow DiagramFocuses on control flow between entities separate from data flow

State-Transition DiagramFocuses on states of systems and transitions between them

Canonical (Reference) Requirements• Requirements that apply across the entire domain captured by a DSSA• Will be incomplete because they must be general enough to capture the

variations that occur across individual systems and because individual systems also will introduce their own requirements

• Directly facilitate the mapping of the requirements for each system within a given domain to the canonical domain-specific solution

• Derived from the customer needs statement• Contain• Functional requirements – defining characteristics of the problem space• Non-functional requirements – limiting characteristics (constraints) in the

solution space• Design requirements

• E.g. Architectural style, user interface style• Implementation requirements

• E.g. Hardware platform, programming language

Canonical (Reference) Requirements• Must distinguish among three types of requirements• Mandatory requirements – applicable to all systems in the

domain• Operational requirements – applicable to a certain set of systems

within the domain• Variable requirements – application-specific and may be unknown

at the time the DSSA is formulated

Reference Architecture• The set of principal design decisions that are simultaneously

applicable to multiple related systems, typically within an application domain, with explicitly defined points of variation

• Three classes of reference architectures• Complete single-product architecture

• Relatively weak because they do not provide much engineering guidance as to how to use the reference architecture to create new systems and they do not explicitly call out variation points

• Incomplete invariant architecture• Partial architecture that is complete and unchanging among all products• Parts of the architecture that vary from product to product are left

unspecified, although some design guidance might be provided• Invariant architecture with explicit variation

• Can be used to simultaneously capture both the invariants and the variants in products in the domain

• For each variation point, permitted alternatives are specified in detail

Reference Architecture