DSML Semantics, Software Producibility, and Adaptability

1
DSML Semantics, Software Producibility, and
Adaptability

• Greg Sullivan gregory.sullivan_at_baesystems.com
• Basil Krikeles basil.krikeles_at_baesystems.com
• BAE Systems Advanced Information Technologies
  (AIT)
• 6 New England Executive Park
• Burlington, MA 01803

Presented at Precise Behavioral Semantics for
Domain Specific Modeling Languages September 25,
2007 Jacksonville, FL Sponsored by the OMG and
the Model Integrated Computing SIG
2
Overview, Caveats

• Focused on DMT/PAMS, but with anecdotes from
  other programs that require more pre-approval
  time.
• Mostly questions, not answers.

3
What is Software Producibility?

• From Rob Gold, OSD
• The ability to deliver needed capability in a
  timely, cost-effective, and predictable manner.
• Producibility in manufacturing
• Processes, tradeoffs, communication, risks.
• Get the product out the door.
• How does producibility apply to long-lived
  Software-intensive Systems?
• Requirements will evolve.
• Technologies will change.
• No well-defined Out the Door ? Producibility
  Over Time
• Our (working) definition
• The fitness of a software system to survive in
  todays ecosystems of interacting software
  components.

Example Punch-in or screw-in fasteners. Trade
off is future maintenance
SiSP Software-intensive Systems Producibility
4
Software Producibility, Costs over Time, and DSMLs

• Initial Development
• DSML-based Improvements (motherhood
  proposition) ?Automation, ?Abstraction ?
  ?Productivity (?time, ?quality) ?
  ?producibility
• Post Initial Deployment
• Requirements Change ? Models Change.
• What if new requirements not expressible in
  DSML?? Change the language (metamodels), ?
  Existing specifications (models) must be migrated
  / upgraded. How do we know that migration is
  correct?
• Need automated support (to maintain DSML
  productivity claims)
• Load-time context changes Adapt to different
  configurations of hardware and software. How to
  adapt?
• Need models of intended behavior (self) and
  required behavior (dependencies).
• Other components need to supply models
  (preferably more than type signatures).
• Run-time adaptation Self monitoring shows
  undesired behavior, or environment monitoring
  shows unanticipated context.
• Plan for transition to improved configuration.
  Self-adaptation.

5
DARPA Disruptive Manufacturing Technology
(DMT)Producible Adaptive Model-based Software
(PAMS)

• Funded by DARPA IPTO under the Software
  Producibility thrust of the DMT program.
• Goal is adaptation at three levels Design Time,
  Load Time, and Run Time.
• Support Domain Specific Modeling Languages using
  metamodels.
• Avoid tool disillusion and abandonment syndrome
  by evolving tools along with models.

6
DARPA DMT PAMS
Overview of Technical Approach How we will do it

• Design Time AdaptationCo-evolution of design
  abstractions captured in precisely defined domain
  specific modeling languages (DSML) and associated
  tools (for modeling, testing, verification, code
  generation)
• Load Time AdaptationUse load-time accessible
  models for platform specific composition/configura
  tion of software components based on the desired
  mission requirements and hardware/software
  resources available to that particular platform.

Objective Technology that allows the evolution
and design-time adaptation of domain-specific
languages, model-based tool chains, and legacy
models.

• Run Time AdaptationLeverage run-time accessible
  models to enable a system to reason about its own
  performance (reflection) and to adapt to changing
  and unanticipated circumstances (self-adaptation).

Objective Adapting generic components to
specific run-time platforms and applications, as
well as adapting system configurations to mission
requirements at load-time.
Objective Using symbolic reasoning and planning
techniques for the run-time reconfiguration of
systems to manage unforeseen changes and faults.
7
DMT/PAMS Design Time Adaptation is a simplified
version of MBSE/DSML tool interoperability
problem
PAMS
General Problem
Metamodelsv1
?s
(Implicit) metamodel
Induced IDE, v1
Induced IDE, v2
Semantics embedded in generators

• MBSE Tool 1
• Code Generation
• Analysis

• MBSE Tool 2
• Code Generation
• Analysis

Induced Model Migration
Models, v1
Models, v2
Conservativeextension?
aValve
anActuator
aMeter
Interoperate?
Executables
Executables
Induced Generator, v2
Induced Generator, v1
Conservativeextension?
Executables
Executables
8
How to address Conservative Extension? Question

• Conservative except where intended not to be
  (e.g. bug fix).
• Backwards compatibility testing.
• Is there an objective measure of correctness?
• Other than the generator defines the semantics.

• Answering Interoperate?
• Components need models of own behavior and
  required behavior of dependents.
• Semantic anchoring? Need to be able to query
  other models for compatibility / satisfaction.
• Roughly the same requirements as for Load Time
  Adaptation in DMT/PAMS.

9
Load Time Adaptation another instance of semantic
compatibility challenge
Load Time Context
Intended Behavior
Are these the same X?
Component X1
ComposedSystem
X
Component X1
Component X2
X
Load Time Adaptation
X
Component Y1
Component Y2
Y
Y
Is this configuration optimal?
Component Y2

Models supplied with components
Is this configuration correct?
Y

10
Run Time Adaptation Semantic Issues
Intended Behavior
ExecutingSystem
Run TimeMonitor
Component X1
X
event stream
satisfies?
Component Y2
no?
Reconfigure
Y

11
End of presentation
12

• If your dsml has well-defined semantics (in terms
  of e.g. semantic units), so what? There is still
  the possibility of misunderstanding.
• Furthermore, sufficiently complex semantics makes
  the problem of deciding whether two semantics are
  equivalent undecidable.
• Redundancy is good
• How do I know my system is behaving correctly?
• How do I know the component Im relying on is
  behaving (or promising to behave) correctly?

13
Jaguar Notes

• Had a metamodel, in UML, but not enforced
• Uses generic UML, with both restrictions (only
  a subset is meaningful to code generator) and
  extensions (via UML stereotypes, e.g.
  ltltgeneratedgtgt).

14
SIAP notes

• opaque semantics sometimes surprising
  buried deep in code generator.