Domain-Specific Software Engineering

1. Domain-Specific Software Engineering Alex Adamec

2. 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

3. 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.

4. 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.

5. 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

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

7. Architecture-Based Software Engineering Any given software development problem can be solved by a finite number of software architectures.

8. Domain-Specific Software Engineering Some 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.

9. 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.

10. 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 Business Core Competencies Goals and Motivation Scopes the Problem Space DSSE Product Lines General Infrastructure Solutions and Tools Specialized for a Domain Technology General Solutions and Tools

11. 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

12. 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

13. 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

14. Domain + Business • Expertise and core competencies • Business organizations specialize their skills to optimize them for particular domains. • E.g. building airplanes

15. 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

16. 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.

17. 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

18. Key Architecturally Relevant Areas of DSSE • Domain-Specific Software Architecture • Product Lines

19. 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

20. 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

21. 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

22. Domain Dictionary Represents the identification and definitions of terms used in the domain model

23. 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

24. Context Information Diagram Defines high-level entities Defines what is considered inside and outside the domain (or subdomains) Defines relationships and high-level flows

25. Entity Relationship Diagram Defines entities and cardinal relationships between them

26. Object Diagram Defines attributes and operations on entities

27. 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

28. Feature-Relationship Diagram Describes overall mission operations of a system Describes major features and decomposition

29. Use-Case Diagram Defines use cases within the domain

30. Representational Model Defines how information is presented to human users

31. 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

32. Data-Flow Diagram Focuses on data flow between entities with no notion of control

33. Control Flow Diagram Focuses on control flow between entities separate from data flow

34. State-Transition Diagram Focuses on states of systems and transitions between them

35. 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

36. 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

37. 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

38. Reference Architecture