domain-specific software engineering (dsse). software engineering concerns there are many of them ...
Post on 20-Dec-2015
216 views
TRANSCRIPT
Domain-Specific Software Engineering (DSSE)
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)
What’s Out There?
Software
Archite
cture
What’s Out There?
Technology
Software
Archite
cture
What’s Out There?
Technology
Software
Archite
cture
Domain
What’s Out There?
Technology
Software
Archite
cture
Domain Business
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
Domain Business
TechnologyTechnology
Domain Business
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
A Technology-DrivenArchitectural Model
Technology
Domain Business
DomainTechnology
Domain Business
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
How Domains Help
Technology
Domain Business
Traditional software development
How Domains Help
Technology
Domain Business
Architecture-based software development
SE Problem SpaceTechnology
Domain Business
How Domains Really Help
Technology
Domain Business
Domain-specific architecture-based software development
Business
Technology
Domain Business
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
Putting It All Together
Domain scopes theproblem space
Business goals and
motivations
TechnologyGeneric solutions
and tools
CoreCompetencies
Solutions and toolsSpecialized for
a domain
GeneralInfrastructure
Domain-Specific Engineering
Product-LineArchitectures
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)
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
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
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
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”
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
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 modelsState transition modelsObject model
– First phase of component interface design
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)
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
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
DSSA Process With Principal Supporting Tool Types
ApplicationRequirements
Analysis
ApplicationDesign &
Development
ApplicationRequirements
DomainModel:
Context+
ReferenceRequirements
ReferenceArchitecture
Test &ValidationSystem
ApplicationSystem:
Architecture+
Components+
Platform Specs
RequirementsManagement ToolsModeling
Tools ArchitectureSpecification
Tools
ArchitectureRefinement
&Evolution
Tools
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
Three Layers of DSSA EnvironmentsDomain
Architect
ApplicationEngineer
Operator
ReferenceArchitecture
Components
DevelopmentTools
Application ExecutionEnvironment
Domain-Specific ApplicationDevelopment Environment
Domain DevelopmentEnvironment
Instantiated Architecture
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
componentsrealm { x : component | (i,j) (xi.interface = xj.interface) }
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
Controls and Display
Flight Director
Guidance
Navigation Radio-Nav
Data Source Objects(sensors)
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