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

..

...

Problem Space

General Solution Space

Problem Spaceby Domains

Solution Space by Domains

..

..

? searching for solution - - - a big frustration

mapping specific domain problems to domain specific reference architecture

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

Technology

BusinessDomain

DSSE;Product LineswhereDomain∩Business∩Technology

defines differentindustry domainconcerns

defines differentbusiness goalssuch as efficiency ormoney

defines various tools,methodologies & processes

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

ReferenceArchitecture Dev.

DomainAnalysis

Framework &Component Dev.

Product lineDevelopment

ApplicationDevelopment

DomainModel

Domain Specific App.

Product Arch.Model

Framework &Comp. Library

Ref. Arch.Model

DSSE

done

over

time

additional reqs.

Parts ofDSSA

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

DomainDictionary

InformationModel

Feature Model

Operational Mode

Context infodiagram

Class (object)diagram

SemanticNetwork

Entity-Relationdiagram

State Transitiondiagram

Control-flowdiagram

Data-flowdiagram

Representationdiagram

Use Casediagram

Feature Relationdiagram

How applicationcontrol flows

DictionaryOf terms

Capabilities (reqs.) of application

Interdependenceof entities

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 orComp/connectors

Office Suite: Product-LineBasic Complete Advanced

word processor

spread sheet

presentations

layout support

spell check

grammar check

file import/export

auto save

task management

multi-lingual

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

You can pickor “select” yourown a)Combinations - single product b) add more features - re-do - paginationc) add more functions - statistical calc.

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 designSome specific application domain– Technologies– Standards that has to be kept Business economics Domain

Technology

Business

Example: Payroll “Product-Line” Technology Based Re-Architecting

OracleDB

AS/400DB

MS SQL

UNIX based Payroll

MS Window based Payroll

IBM AS/400 based Payroll

UNIX

OracleDB

AS/400

MS/Window

Payroll

Payroll

Payroll

webcloud

Common UI

Common DB

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!

Example of Product “Family” ---- and Versioning

General Requirements

French( version 1 )

Brazilian( version 1 )

Japanese( version 1 )

General Requirements

(Version 2)

French( version 2 )

General Requirements

(Version 3)

French( version 3 )

Japanese( version 2 )

Japanese( version 3 )

Brazilian( version 3)

Brazilian( version 2 )

French(version 2.1)

If Fench Version 2.1 came after Version 3,we may need to build

a French V3.1

US (common) codev1

US (common) codev2

US (common) codev3