Domain Specific Software Engineering (DSSE)

Software Engineering, just as other engineering disciplines, needs to take into account of the different domain in which it is working. Consider the engineering of Electric Coffee Machine (household appliance) versus the engineering of Airplane (avionics):
We may design the electric coffee maker in such a manner that it is focused on properties such as speed of heating, electric safety, and looks; but we know if it breaks the user will just go buy a new one --- do not worry about maintenance (reusable parts & replacement) too much. We may design commercial airplanes for super reliability and safety first. Thus we want to design for frequent maintenance (reusable parts and replacement). Then we are concerned with speed and comfort. We are not concerned with the looks of the airplane.
Our design concerns differ based on the different problem domain.

DSSE (cont.)
Different domains require potentially different:
Principles Techniques Processes Tools

Domain Specific Software Engineering is an approach to developing software by leveraging the existing domain knowledge extensively:
Dividing requirements between those common across application domain and those that are unique to the system Common requirements can be tied to existing solutions, allowing design focus on domain specific areas Many of the software development activities are simplified through reuse of the common material and focusing only on the domain specific areas separately Separation of the tools and environments for common and domain specific needs will make the development and support activities a lot clearer Separation of the common from the domain specific will allow communications to the various stakeholders easier, especially that the domain specific areas may have their own parochial vocabulary.

Domain Specific Software Engineering

. . . ?
searching for solution - - - a big frustration

Problem Space

General Solution Space

. .

.
Solution Space by Domains

Problem Space by Domains

mapping specific domain problems to domain specific reference architecture

DSSE in terms of 3 Areas: Domain, Business & Technology

Domain
defines different industry domain concerns

Business
defines different business goals such as efficiency or money

Technology DSSE; methodologies & processes Product Lines where DomainBusinessTechnology

defines various tools,

Domain Specific Software Architecture

Domain Specific Software Architecture is a set of principal design decisions composed of:
1) A reference architecture which describes a general computational framework for a significant domain of applications 2) A component library of reusable chunks of domain expertise 3) An application configuration method for selecting and configuring components within the architecture to meet particular application requirements
DSSA is not free and is built over time upon deep experiences with the domain

A Process View of DSSE and DSSA

Domain Analysis

Domain Model

DSSE done over time

Reference Architecture Dev.

Ref. Arch. Model

Parts of DSSA
Framework & Component Dev.
Framework & Comp. Library

Product line Development

Product Arch. Model

additional reqs.

Application Development

Domain Specific App.

Domain Model
Domain model characterizes the problem space:
Standardizes the domain terminologies and semantics forming a domain ontology or domain system Provides the basis for standardized descriptions of problems to be solved in that domain
Consider the term, lot . What does this mean? A) It means a parcel of land in the real estate industry. B) It means a set of same type of items in manufacturing . C) It means role in life in sociology and psychology.

Domain model is created as a result of:

Context analysis of those items within the domain context and relating to those items outside of the domain context Domain analysis via identifying, capturing, and organizing those entities, functionalities, properties, and data which recur across mulitple applications within the specific domain.

Domain Model (cont.) A domain model is composed of 4 main components:

1) Domain dictionary composed of domain specific terms 2) Information model which is a collection of models built from context analysis and information analysis (domain analysis) 3) Feature model which describes the user/customers expectations of the capabilities of the application in the given domain 4) Operational model identifies how the applications within the domain works:

Elements of Domain Model

Information Model Feature Model Operational Mode

Context info diagram

Feature Relation diagram

Data-flow diagram

Domain Dictionary

Entity-Relation diagram

Use Case diagram

Control-flow diagram

Semantic Network Representation diagram Class (object) diagram State Transition diagram

Dictionary Of terms

Interdependence of entities

Capabilities (reqs.) of application

How application control flows

A Few Possibly-Unfamiliar Diagrams

The domain model may use part or all of the different diagrams to depict the models. Most are familiar to software engineers but a few may not be:
Context-information diagram - captures high level information flow among entities within and outside of the system Semantic network a network diagram to represent relations among concepts (entities) Feature-relation diagram describes overall-all mission of the application Representation diagram describes how information is made available to users (e.g. UI)and other applications

Domain Specific Software Architecture (DSSA) & Reference (canonical) Requirements

DSSA is focused on the standard or canonical parts of a specific domain to create the reference architecture. It still depends on the requirements specified. Such standard or canonical requirements for the domain is called the

Reference Requirements
Reference Requirements are derived from customers in the same application domain and contains:
Functional requirements Non-functional requirements Design requirements Implementation requirements

Reference requirements may be of:

Mandatory features : applicable to all systems in the domain Optional features: applicable to only subsets of systems in the domain Variable features: known to differ in nature by specific application in the domain

Note that reference requirements are similar to what is shown in feature model

Reference Architecture
From the reference architecture & the domain model (which speaks to business, technology, and a specific domain), we can develop the Reference Architecture which was defined earlier as:
Def: Reference Architecture is the set of principal design decisions that are (1) simultaneously applicable to multiple systems, typically within an application domain, (2) with explicitly defined points of variation. A reference architecture may be:
1. An architecture derived completely from a single product in the domain 2. Incomplete variant architecture containing a common part and an unspecified part, which may vary. 3. Domain specific invariant architecture with explicitly defined points of variation

Developing Reference Architecture

There is no simple path to when and how to develop a reference architecture.
Timing must be just right: not too early when not enough is know or too late when everything is already developed. This is a tall order ---- the best way may be do this incrementally as enough information and knowledge are acquired. The form of the reference architecture can not be based on a single product (too restrictive), nor just incomplete invariant (may lack too much detail, especially on the incomplete variable parts) ---- the best is the invariant architecture with explicit points of variation.

Product-Line Architecture
The software industry has been building products in the form of product-line. (e.g. Oracle database, Oracle HRM, MS Office Suite, SAP ERP, etc.) Product-line architecture is similar to reference architecture in DSSA, except in scope and completeness:
product-line architecture captures the complete set of design decisions of well-defined, multiple related products in the product-line while DSSA reference architecture may have incomplete and undefined parts

Product-line architecture is composed of design decisions which simultaneously capture all the related products in the product-line. Some of these decisions will
be 1) common among all products, 2) some will be common among a subset of the products and 3) some will be unique to individual product.

Tabular Method to specify Product-Line (requirements and/or architecture)

Features or Comp/connectors word processor spread sheet presentations layout support spell check grammar check file import/export auto save task management multi-lingual X X X

Basic
X X X

Office Suite: Product-Line Complete Advanced

X
X X

X
X X You can pick or select your own a) Combinations - single product b) add more features - re-do - pagination c) add more functions - statistical calc.

X
X X

X
X X

X
X X

Advantages of Product-line
Biggest Rationale for Product-line is to gain re-use.
Less cost (spread the cost across multiple products in the

family and lower the individual cost

lower pricing)

Shorter schedule for subsequent products that share common features and functionalities Better quality for subsequent products that share already tested and proven features and functionalities

Re-used common parts also reduces individual product maintenance cost

Share fix to common parts Share cost on improvements to the common parts

Domain Specific Architect Can you be a domain specific architect. Yes, if you know:
Software design Some specific application domain Technologies Standards that has to be kept Business economics Domain

Business

Technology

Example: Payroll Product-Line Technology Based Re-Architecting

Payroll
UNIX based Payroll Oracle DB
UNIX

IBM AS/400 based Payroll

web cloud

Payroll
AS/400

AS/400 DB

Oracle DB Common DB

MS Window based Payroll

MS SQL

Common UI

Payroll
MS/ Window

Now Consider the Domain & Business Domain Specific Considerations:

Universal Part: inputting employee payroll information, modifying employee payroll info, computing pay check, printing pay check, performing direct deposit of pay check, ------ etc. Variable Parts: benefits management; retirement pension management; amount of reports and history maintained ----etc.

Business Specific Considerations:

There will be 3 products in the product line: 1) Core, 2) Complete, 3) Deluxe International Versions based off US version and includes: Spanish, French, Chinese, Japanese, Arabic versions There will be two maintenance updates per year, which includes: bug fixes, annual tax law change, minor updates

You can imagine the version control and configuration management nightmare for this!

General Requirements (Version 2) General Requirements US (common) code v2

General Requirements (Version 3) US (common) code v3 French ( version 3 ) If Fench Version 2.1 came after Version 3, we may need to build a French V3.1

US (common) code v1

French ( version 2 ) French (version 2.1) Japanese ( version 2 ) Japanese ( version 3 )

French ( version 1 )

Japanese ( version 1 ) Brazilian ( version 2 ) Brazilian ( version 1 )

Brazilian ( version 3)

Example of Product Family ---- and Versioning