Model Driven Development

1
Model Driven Development
2
DoDAF/ModAF/ SysML and AP233

• Architecture
• DODAF
• MODAF
• Modelling
• UML
• SysML
• Interchange
• AP 233
• XMI

3
DoDAF

• Architecture
• The structure of components, their relationships
  and the principles and guidelines governing their
  design and evolution over time. DoD
• Public Documents
• Volume 1 Architectural Framework
• Volume 2 Product Description
• Deskbook

4
3 views
5
(No Transcript)
6
(No Transcript)
7
UML 1.4

• Version of Unified Modelling language in most
  widespread use
• Wide set of support tools
• IBM/Rational Rose, Telelogic Tau, System
  Architect, QSEE..
• Arises from Object-Oriented Software development
• Previously data and code were kept separate,
  objects combine the two
• Software objects mimic real world things
• Objects have a type or class
• Viewpoints
• Structure
• Class object component deployment
• Behaviour
• Use case state-chart sequence collaboration
  activity

8
UML 2.0

• UML 2.0 includes features which are helpful in
  Systems Engineering1
• Allows for more flexible System, Subsystem and
  Component representations
• Structural decomposition
• e.g. Classes, Components, Subsystems
• System and component interconnections
• via Parts, Ports, Connectors
• Behavior decomposition
• e.g., Sequences, Activities, State Machines
• Enhancements to Activity diagrams
• e.g. data and control flow constructs, activity
  partitions/swim lanes

1Kobryn and Friedenthal, Systems Modeling
Language Overview, 2003
9
UML 2.0

• UML 2.0 includes features which are helpful in
  Systems Engineering (contd.)
• Enhancements to Interaction diagrams
• e.g., alternative sequences, reference sequences,
  interaction overview, timing diagrams
• Support for information flows between components
• Improved Profile and extension mechanisms
• Support for complete model interchange, including
  diagrams
• Compliance points and levels for standardizing
  tool compliance
• Does not preclude continuous time varying
  properties
• especially important for SE applications

10
SysML origins

• Systems Engineering requirements
• Hierarchic levelling of detail
• Functional decomposition Function block diagrams
• Physical interaction and continuous connections
• Requirements system relationship
• Mathematical models
• Main authors
• Cris Kobryn and Sandy Friedenthal (SysMl
  partners (www.SysML.org)
• Support from
• Object Management Group
• Tool vendors
• Artisan, Telelogic, IBM/Rational, I-Logix
• INCOSE
• Industry
• BAE SYSTEMS, Deere Company, Lockheed Martin,
  Motorola, Northrop Grumman, Raytheon, Thales
• Now at Draft 0.9

11
SysML Diagrams

• Viewpoints
• Structure
• Class object component deployment assembly
• Behaviour
• Use case state-chart sequence collaboration
  activity state-machine timing
• Others
• Parametric requirements

12
SysML Example

• Vehicle system
• The problem is derived from a marketing analysis
  which indicated the need to increase the
  acceleration of the vehicle form its current
  capability.
• Appendix B of the Draft standard

13
Concept Diagram
stereotype
14
Class diagram
composition??
generalisation
15
Requirement Diagram
containment
16
Use case diagram
Use case
actor
Sub use case
Optional extension
17
Activity Diagram
initial
fork
merge
Sub-activity
decision
join
final
18
Activity Diagram
object
Swimlane (actor)
action
signal
19
Class Diagram
association with flow
Data property
Physical property
operation
association
20
State Machine Diagram
state
state
Initial
transition
final
guard
event
21
Class Diagram
Meta data
Exclusive sub-assembly
22
Assembly Diagram
connector
Connector type
port
23
Assembly Diagram
swimlane
connection stereotype
24
Parametric Diagram
Parametric constraint
parameter
25
Timing Diagram
26
Sequence Diagram
object
Class of object
Lifeline (time downwards)
Message (Async)
27
Sequence Diagram
Sub sequence
28
Issues
manager
1
Employee

• Diagrams are not enough
• Limited expressive power
• Limited scope for verification
• Formal languages e.g.
• OCL (Object Constraint Language)
• Alloy from MIT
• Comprehension
• Construction
• Patterns and Problem Frames
• Knowledge representation and reuse
• Problem Frames (Jackson)

0..
29
Workshop

• 1 Comprehension
• What do these diagrams mean in English?
• 2 Construction
• Look at the collection of simple diagrams taken
  form various texts and papers
• Identify which kind of diagram most closely
  matches each diagram
• Take on diagram and re-write as a SysML diagram

30
(No Transcript)
31
(No Transcript)
32
State machines in SysML

• 15 July 2004 I-Logix announce that BAe systems
  are standardising on Statemate for development of
  Eurofigher Typhoon
• - using MDD Model-driven Development
• Dec 14 2004 Statemate chosen for use by MBDA in
  the development of METEOR

33
Modeldriven Development

• Design behaviour using diagrammatic notations
• Demonstrate and evaluate the behaviour early in
  the development process
• Generate the delivered code/part directly from
  the model, perhaps guided by the designer with
  additional decisions.

34
Statemate

• A state machine design tool based on David
  Harels state charts (incorporated into UML)
• Allows
• Simulation what would happen if the following
  sequence of events occurred.
• Analysis prove that the system can never lock
  up
• Code generation to C for loading into embedded
  processors

35
Basic State Machine

• The basic concepts in this notation are
• state
• A mode of the object/component/sub-system
• transition
• A change of state caused by an event or input,
  perhaps back to the same state
• event
• the input which causes a transition to occur
• action
• An action which occurs when a transition is made

36
example
C
clang
s1
event
A
-------
B
action
A
boing
clack
hiss
B
bang
S2
S3
A
ping
C
pong
37
Exercise

• 1.1. What sequence of noises does it make when
  the sequence ABACAC is in put?
• 1.2 What about BABAAC?
• 1.3 What kind of error in the machine does the
  sequence ACCBA reveal?
• 1.4 What kind error in the machine does the
  input BABC reveal?
• 1.5 What kind of error does the sequence
  ABAXAC reveal?
• 1.6 Give other examples of good and bad input.