1. Domain-Specific Software Engineering (DSSE)

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

3. What’s Out There? Software Architecture

4. What’s Out There? Technology Software Architecture

5. What’s Out There? Technology Software Architecture Domain

6. What’s Out There? Technology Software Architecture Domain Business

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

8. Technology DomainBusiness  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

9. A Technology-Driven Architectural Model Technology DomainBusiness

10. Domain Technology DomainBusiness  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

11. How Domains Help Technology DomainBusiness  Traditional software development

12. How Domains Help Technology DomainBusiness  Architecture-based software development

13. SE Problem Space Technology DomainBusiness

14. How Domains Really Help Technology DomainBusiness  Domain-specific architecture-based software development

15. Business Technology DomainBusiness  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

16. Putting It All Together Domain scopes the problem space Business goals and motivations Technology Generic solutions and tools Core Competencies Solutions and tools Specialized for a domain General Infrastructure Domain-Specific Engineering Product-Line Architectures

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

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

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

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

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

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

23. 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 models  State transition models  Object model –First phase of component interface design

24. 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)

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

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

27. DSSA Process With Principal Supporting Tool Types

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

29. Three Layers of DSSA Environments

30. 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 components realm  { x : component | (  i,j) (x i.interface = x j.interface) }

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

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