Intro to Modeling
CS 622/722Reflective and Adaptive Systems
November 4, 2008
MDE and DSM slide help from Jean Bezivin and MetaEdit+…MIC slide help taken from various ISIS talks…
Agenda Today
Quiz 7 Intro to MDE/MDA Intro to MIC slides HW 2 Due Nov 18
Next Tuesday Quiz 8 Hands-on-lab: GME
November 18 SoftCom research in this area
November 25 Not sure?
December 2 Exam 2
From OO to MDE (Model-Driven Engineering) Object technology realized some promises but failed to
achieve others Stopping the search for generality by unification "everything
is an object" may be one of the causes for this Model engineering is making many promises today
Will it be able to deliver correspondingly? Sticking with the principle that "everything is a model"
seems a good way to make progress
Objects
Models
1980 2000 2020
Promises Delivery
Evaluation Promises
Delivery Evaluation
Separating the platform dependent and independent parts of systems
We don't want to pay such a high price anymore for simply moving our information system to a new middleware platform (COM, CORBA, Java, HTML, XML, DotNet, etc.) when our business system stays stable.We are prepared to pay a last price for building the abstract models of our business and services that will guarantee us against technological obsolescence.From there, any platform provider will also have to provide the mapping solutions from standard business models before we buy.
The origins of M
DA
November 2000
Model Driven Architecture (MDA)
PIM to PSM
CORBA
Java/EJB
C#/DotNet
Web/XML/SOAP
PIM
etc.
Platform-IndependentModelMulti-target
code generation
+ SVG, GML, Delphi, ASP, MySQL, PHP, etc.
data grid computingpervasive computingcluster computing
SMIL/Flash
Question
But what is a model?
(Naïve introduction)
Next Few slides adapted from Jean Bezivin….
A very popular model: geographical maps (thanks to Jean Bezivin for this idea)
Models
repOfSystem
2000 Census Map
Aerial Map
Model Road Map
The System
1819 City Plan
Every map has a legend
legend = metamodel
Model
conformsTo (c2)
Metamodel
Another Notation (DSL)
Model
Metamodel
c2
Music notation
Sheet music
Executable Model
Power Tab Editor
Two Views:
Traditional notes
Guitar tab
Assisted Drawing Tools (e.g. MS/Visio)
conformsTo(c2)Metamodel Model
(thanks to Jean Bezivin for this slide)
The Rational/Booch Template
Concrete syntax
Schema definitions: Going “Meta”
Domain-SpecificModeling
ProgrammingLanguage Definition
Database SchemaDefinition
Schema definitionMetamodel for aspecific domain(e.g., Petri Net)
Grammar for a specificlanguage (e.g., Java)
Table, constraint, and storedprocedure definitions for a
specific domain (e.g., payroll database)
Schema instance
Domain model (e.g., Petri Net model of a teller
machine)
A program written in aspecific language
Intension of a database at aspecific instance in time
(e.g., the June 2006 payrollinstance)
Schema execution Model InterpreterLanguage
compiler/interpreter
Transactions and behavior ofstored procedures
in an executing application
Characteristics of Modeling Languages Each model conforms to its
metamodel A model is a representation
of a system satisfying substitutability For each question that can be
asked of the system, the model produces the same answer Not true for me and road maps!
(from Jean Bezivin)
Observation• “One size fits all” approach is appearing to be
inadequate for many end-user needs• Too complex and contains “kitchen sink” approach
providing things most users do not need (UML)• Current trend is to provide “domain-specific”
modeling languages that are customized to a specific domain • Notations and abstractions are exactly what the
users expects; focused on problem space, not technology solution space
• But, how to create such modeling languages and environments?• Expensive to create from scratch for each domain
Typical Situations (only some)Visio Stencil
Visio Drawing
c2
Form definition
Form content
c2
XML Schema
XML Document
c2
Legend
Map
c2
File Structure
File content
c2
UML MM
UML Model
c2
Music Theory
Partition
c2
Grammar
Program
c2
DB Schema
DB Content
c2
Agenda
We Need Precise and Consensual Definitions
Next Few slides adapted from Jean Bezivin….
Each model conforms to its reference model
Structural definition of a model Definition 1. A directed multigraph G = (NG, EG, G)
consists of a set of distinct nodes NG, a set of edges EG and a mapping function
G: : EG NG x NG
Definition 2. A model M = (G, , ) is a triple where: G = (NG, EG, G) is a directed multigraph is itself a model, called the reference model of M,
associated to a graph G = (N, E, ) : NG EG N is a function associating elements (nodes
and edges) of G to nodes of G (metaElements)
There are usually several kinds of models
Definitions
Definition 3. A metametamodel is a model that is its own reference model (i.e., it conforms to itself).
Definition 4. A metamodel is a model such that its reference model is a metametamodel.
Definition 5. A terminal model is a model such that its reference model is a metamodel.
The global picture
repOf
representation ofsystem S terminal
model M
metamodelMM
c2
metametamodelMMM c2
c2
the UML MetaModel
Class Attribute*
1
a UML Model
Client
Name : String
Illustration with OMG standards
M2
M1
the MOF
Class Association
source
destination
M3
c2
c2
c2
metamodel
model
"the real world"
meta-metamodel
The MOF
The UML metamodel
Some UML Models
Various usagesof these modelsM0
M1
M2
M3
Utilization definition
The objective here is to define the possible usages of a model.
Definition 6. A system S is a delimited part of the world considered as a set of elements in interaction.
Definition 7. A model M is a representation of a given system S, satisfying the substitutability principle (see below).
Definition 8. (Principle of Substitutability). A model M is said to be a representation of a system S for a given set of questions Q if, for each question of this set Q, the model M will provide exactly the same answer that the system S would have provided in answering the same question.
repOfrepresentation ofsystem S model
M
Principle of limited substitutability according to Minsky"If a creature can answer a question about a hypothetical experiment without actually performing it, then it has demonstrated some knowledge about the world. … We use the term "model" in the following sense: To an observer B, an object A* is a model of an object A to the extent that B can use A* to answer questions that interest him about A. …
It is understood that B's use of a model entails the use of encodings for input and output, both for A and A*.If A is the world, questions for A are experiments. ...A* is a good model of A, in B's view, to the extent that A*'s answers agree with those of A's, on the whole, with respect to the questions important to B. …"
Marvin L. MinskyMatter, Mind and Models Semantic Information Processing, MIT Press, 1968
The Modeling Tool World
Vanderbilt/ISIS work on MIC and the GME Eclipse GMT project (CIS 693/793) MetaCase MetaEdit+ Microsoft Software Factory Concept
Model Integrated Computing
Computer-Based Systems• CBS characteristics
• Hardware and software tightly coupled• Dynamic operating environment• Critical to the enterprise• Long lifespan• Multi-disciplinary development
• Examples• Embedded systems• Process monitoring, analysis• Manufacturing execution systems
CBS design is highly non-trivial
IEEE International Symposium on the Engineering of Computer-Based Systems (ECBS),
“Small changes in requirements entail large changes in the structure and configuration.”
•Digital Fire Control/NAV
•PT-PT Wiring
•Mechanically Controlled Sensors/FLT Controls/ Displays
•Crew-Dominated Operation
•Functionally Integrated Data Processing
-NAV/WD/Air Data Sensors
-Flight Control
•Beam Steering Sensors
•Fly By Wire
•Dedicated Digital Processing
•Crew-Assisted Operations
- Weapon Delivery
- Automated TF/TA
- EW Response
•Aircraft-Wide Information Integration
- Sensors/Stores/ Vehicle/
Propulsion
•Modular Electronics
•Massive Data Bases
- Terrain, Threat
•Digital Sensor Processing
- Sensor Fusion
- Hyperspectral Imaging
•Integrated Diagnostics/
System Fault Tolerance
•System Data Security
•Limited UAV Autonomy
•Platform Exploitation of Global Information
- Information Mining
- At-A-Distance
Reconfiguration
•Autonomous Vehicle Emphasis
- Air & Space
•Air Crew/ Ground Crew Monitoring & Management
•Automated Functions
- ATR (Multi-Sensor)
- Failure Prognostics
- Route/ Sensor/ Weapon/
Vehicle Coordination
- Bistatic Sensing
(Air/ Space)
- Threat Evasion
DEDICATED SUBSYSTEMS
FEDERATED SUBSYSTEMS
INTEGRATED SYSTEMS
SYSTEM of SYSTEMS
1958 1950’s - 60’s 1990’s - 00’s 2000 1970’s - 80’s
Embedded Software: Increasing Integration Role
64 KB
1 MB
1 GB
100 MB
Radar
Comm
EW
Integrated Avionics
Mission
Radar
Comm
NAV
Mission
Federated Avionics
Radar
Comm
NAV
Independent Avionics
Advanced Avionics
Source: AFRL
Evolution of Avionics Systems:
Components as Imagined (McIlroy)…
But: Responsibility for design integrity is in the hands of each system integrator
(Semantics problem) “Side effects” of component interactions turn up in the system integration
labs (or in the field) (Compositionality Problem)
Component Library
ApplicationsApplications
$ $ $
Notice the $ signs!
Composability Problem
Subsystem D Subsystem E Subsystem F
Subsystem A Subsystem B Subsystem C
Composability: Ability to link subsystems so that properties established at subsystem levels hold at the system level
But physical requirements crosscut functional component boundaries, which
weaken or destroy composability
Current technology focuses on functional composition...
EmbeddedSoftware
mCDMA
ROM
FPGA DSP
Process
Process
Pro
cess
EmbeddedSoftware
Computing as system integrator: computing is tightly integrated with physical environment
Due to its integration role, system-wide constraints and assumptions accumulate in software:• design assumptions • internal/external integrity constraints • usage assumptions ..scattered all over the software…undocumented
Possible solution:• constraints and assumptions need to be explicitly modeled • consistency needs to be checked and maintained during composition (even runtime)
Semantics Problem
Model-Integrated Computing
Technology for using
– domain-specific modeling and– model-based generators
to compose systems on various platforms
Arguments and Proposals
MIC proposes a two-level approach:1. Domain-specific modeling tools for creating domain-specific
models2. Modeling tools represented by, and built from, metamodels
• No one modeling language satisfies the requirements of all CBS’s
• UML often not helpful in some domains, despite efforts
• No single engineering discipline exists for CBS design
• Common language should be that of the domain, not computer engineering
• Integration of models and tools is necessary for CBS analysis and synthesis
• Modeling tool evolution must be easy, predictable, and safe
• Different categories of users; domain experts who may not be programmers
Domain-Specific Modeling (not UML)
Categories of End-Users
AdminAssistants
Businessman
Auto Factory Worker
Scientist
Spreadsheet
BusinessQuery Systems
Modeling Language
DSL forPhysics
Model Integrated Computing
MIC is a technology for Modeling computer-based systems Synthesizing applications from the models Integrating new and legacy applications Evolving computer-based systems
Logical separation of design, implementation True end-user programmability
Effective integration solutions are possible due to the integrated nature of the models
Implementing MIC• Domain-specific, graphical
design tools• Automated model translation
creates• Data streams for existing
simulation, analysis tools• Configuration info for system
components• Executable software
applications• User-controlled system
evolution• Domain experts update
models, regenerate system
12/15/97
Components
Domain Modeling
Mapping/Synthesis
Integration Platform
Metamodeling and Modeling
ModelMetamodel
OCL Constraints1. Abstract & Concrete Syntax
2. Static Semantics
3. Visualization
Specification of Domain Specific Modeling Languages (DSML)
ConcreteSyntax
C
AbstractSyntax
A
SemanticDomain
SSemantics
parses to parses to parses to
Concepts
Relations
Well formed-nessrules
Mathematical abstraction for specifying the meaning of models
Notation forrepresenting models
L = < C, A, S, MS, MC>
MC
MS
Modeling Language Definition
Notation forrepresenting models:E.g.: Block Diagram
Concrete
Syntax
C
Abstract
Syntax
A
Semantic
DomainS
Semantics
parses to parses to parses to
MC
MS
Mathematical abstraction
for specifying the meaning of models
But What About S?
Signal Flow Language (SF)Concepts, Relations
Well formed-ness rules:
Self.InputPorts()forAll(ipip.src()forAll(x1,x2x1=x2))
UML-CD/OCL
Semantics via Meta-Modeling
Concrete
Syntax
Abstract
Syntax
Semantic
DomainSemantics
parses to parses to parses to
Meta-modeling language withwell-defined semantics
Concrete
Syntax
Abstract
Syntax
Semantic
DomainSemantics
parses to parses to parses to
Represented by
Meta-modelSemantics
DSML
Meta-modelStructural
SemanticsDSML:StateFlow
DOMAIN-MODEL
META-MODEL
Meta-Model of StateFlow using uml/OCLas meta modeling language.
Semantics via Translation
Concrete
Syntax
Abstract
Syntax
Semantic
DomainSemantics
parses to parses to parses to
Concrete
Syntax
Abstract
SyntaxSemantics
parses to parses to parses to
Semantic
Domain
translator
DSML
Semantics
Modeling language with
well-defined semanticsSynchronous Dataflow (SDF)
translatorBehavioral
Semantics
ASF
Hierarchical Signal Flow (HSF)
Lee, Sangiovanni-Vincentelli
Model-Based Generators
Models: stored as directed, attributed graphs
Generators:traverse/transform
Targets:
executable models
analyzable model
Synchronous Dataflow
Petri Net
Domain-Specific Modeling at ISIS:Model Integrated Computing• The Generic Modeling Environment (GME) is a domain-
specific modeling tool• It can be utilized in many different domains by providing
a meta-level paradigm description• Paradigm describes all of the entities of the domain,
as well as valid relationships• An end-user first loads the domain paradigm and then
constructs new models in that domain
See November 2001 issue of IEEE Computer
ModelInterpretation
Model Interpreters
Models
Modeling Environment
ApplicationDomain
App1
App2
App3
Application Evolution
Environment Evolution
MetamodelingInterface
Metamodel Definition
Meta-LevelTranslation
Model Builder
Model Integrated Computing (MIC) with GMEM
etamodel
Model
Interpreter
void CComponent::InvokeEx(CBuilder &builder,CBuilderObject *focus, CBuilderObjectList &selected, long param) {CString DMSRoot = "";DMSRoot = SelectFolder("Please Select DMSRoot Folder:");if (DMSRoot != "") {DMSRulePath = DMSRoot + RULESPATH + "Rules\\";MSRuleApplierPath = DMSRoot + RULESPATH + "RuleApplier\\";AfxMessageBox("DMSRulePath = " + DMSRulePath , MB_OK);CString OEPRoot = "";OEPRoot = SelectFolder("Please Selec
DEFINE
INTERPRET
The Generic Modeling Environment (GME) adopts the MIC approach and provides a plug-in mechanism for extension.
GME Architecture
GME
Persistent Storage Model database
Storage Interface
Editor Core
Graphical User Interface
Constraint Checker
Meta models
Model data
Domain model
[download site: http://www.isis.vanderbilt.edu/Projects/gme]
Internal Structure Use
MICApplications
Saturn Site Production Flow
Saturn Site Production FlowProduction Flow
• Flow of raw materials, parts, sub-assembly through the operations
• A complex network of operations and buffers
• Production flow very critical to throughput
Saturn Site Production FlowData Collection and Storage
• Real-time collection• Nearly 80,000 points• Large-scale, distributed system• Storage of historical data• Hundreds of distributed clients
• LAN and WAN• Real-time and historical data
Saturn Site Production FlowAnalysis and Visualization
• Flexible access to real-time/historical data• Visualization• Bottleneck identification• What-If analysis• Data trending• Interoperation with COTS• Reports/charts generation
Real-Time Viewer
Saturn Site Production FlowSoftware Engineering Issues
• Large-scale, complex, heterogeneous and continually changing environment
• Distributed, real-time application• Changing requirements• Integration with the plant• Integration of diverse software sub-systems
• Custom and COTS• Maintenance• Evolution
New Capabilities, Benefits
• 10-100 X decrease in system integration cost
• Enables evolution and adaptation of complex software
• Provides “true” end-user programmability
Domain-Specific Modeling with MetaEdit+
What we need to define for DSM?• Metamodel
• Modeling concepts, their properties, rules and correctness constraints
• Symbols• Notation & representation of diagram, matrix or table
• User interface of a modeling tool• Dialogs, toolbars etc
• Generators• Code, checkings, build, metrics, documentation etc.
• Connectivity with other tools• Help and tutorials• Share the DSM to its users• Reflect to models already made
Proper tool creates many of these automatically
Concepts Symbols
GeneratorsRules1 2 3 4
Steps for implementing DSM
1. Design domain concepts (1)• Map modeling concepts accurately to domain
concepts• What information is stored with each concept
• In MetaEdit+ metamodels are defined in forms or in graphical models• below a sample of metamodeling in a form (left)
• Metamodels can be immediately tested in modeling
1. Design domain concepts (2) Metamodel can be also described graphically
e.g. metamodel of class diagram (partial below)
2. Define domain rules Language semantics and rules
defined as they exist in the domain
In MetaEdit+ rules are expressed as data
Examples of rule types: Links between concepts Layering abstractions Occurrency, uniqueness
3. Draw symbols (notation)• Define symbols illustrating as well as possible the
corresponding domain concept’s natural “visualization” • In MetaEdit+ symbols can be drawn with Symbol Editor
or exported as bitmaps and svg (vector graphcis)
4. Implement generators• Generator translates the models into a required output• In MetaEdit+ generators are defined using Generator Editor • Generators can be defined also externally with any
programming language accessing models via API or XML• Generator Editor (below) is linked to the metamodel and
provides generator debugger and traces from generated code to models
MetaEdit+ delivers automatically modeling tools for the metamodel• Editors (diagram, matrix, table), browsers, generators, multi-
user, multi-project, multi-platform environment• Method easy and safe to maintain and share
• Shared new language versions, updates models already made
Case Study : Enterprise apps in smartphones• Symbian/Series 60 for enterprise application
development• Platform provides basic services• Modeling language to define application logic
using basic widgets and services• Code generator produces 100% of
implementation• Complete chain from model to running app
• Symbian/Series 60 application development• Platform provides basic services• Modeling language to define application logic using basic
widgets and services• Code generator produces 100% of implementation• Complete chain from model to running app • Libraries possible to integrate
Case Study : Enterprise apps in smartphones
Generator definition
Function calls – Series 60/Python
def Note3_2227(): appuifw.note(u"Registration made", 'conf') return Stop3_983
def Note3_6109(): appuifw.note(u“Registration cancelled", ‘info') return Stop3_983
def Note3_2543(): appuifw.note(u“Conference registration: Welcome", ‘info') return Popup_menu3_2520
def Stop3_983():# This applications stops here return appuifw.app.set_exit
...
Generator output
Report '_Note'/* Produces Note code */'def '; type;oid; '():'; ‘ appuifw.note(u"';:Text or code; '", '''; :Note type; ''')'; subreport; '_next element'; run;endreport
Report '_next element'/* reports next flow element*/do ~From>Flow { do :Function used {' '; :Function name;} '('; :Code; ')'; do ~To.() {‘ return '; subreport; '_Internal name'; run;}}endreport
Generator definition
Summary• Productivity can be improved by raising the
abstraction beyond coding• 5-10x faster than manual approaches
• Automation can be applied effectively if bothmetamodel and generators can be customized
• MetaEdit+ provides a cost-effective way to create automation
• Building DSM is great fun for experts• MetaEdit+ is tried and proven technology
• Hundreds of DSM implementations
Top Related