ModelIntegrated Development of Embedded Software Karsai, Sztipanovits, Ledeczi, Bapty

1
Model-Integrated Development of Embedded
SoftwareKarsai, Sztipanovits, Ledeczi, Bapty

• Presented by DeWitt Latimer
• 09 Oct 2006
• USC CSCI 589

2
Overview

• Available resources/implementations
• Structure/Architecture
• Discussion of Assumptions
• Limitations / Benefits

3
Available Resources/Implementations

• GME Generic Modeling Environment
• Used in this class
• MATLAB/SIMULINK
• Partial solution, fairly well adopted
• Forthcoming
• UML 2 extensions

4
Structure/Architecture

• A metamodel of various DSMLs (Domain Specific
  Modeling Languages) is used to capture relevant
  information about the system to be developed to
  enable composition of models via various tools

5
Assumptions of the Problem Domain

• DSMLs relevant to the critical technical
  parameters exist
• Use of a meta-models will be in line with the
  selected architecture style and domain
• When a DSML doesn't exist, its development in the
  metalanguage is not a developmental burden

6
Limitations

• Reliance on DSMLs
• The cognitive activity of developing a DSML
  appears to be at least as hard as developing a
  product line architecture, which is already
  acknowledged as difficult
• Paper focuses on single style solution, but
  doesn't give guidelines as to when to use their
  (or alternative solutions)
• Enhancements aim toward major issues previously
  identified by Garlan and others

7
Limitations

• Reliance on generate or choose a new meta-model
  as needed
• Generating a new meta-model is VERY hard (e.g.
  UML, Z, Larch)
• Choosing a new meta-model has tremendous impact
  on the development organization (training, tools,
  etc.)
• Many modeling issues (composition and
  well-formedness) are pushed up to this meta-model
  level

8
Limitations

• Implementations details are not covered and are
  significant
• e.g. the metamodeling toolset needs to be
  extended with a validation tool, which checks the
  consistency of the well-formed rules - easy to
  verify, hard to validate!
• Indeed, noting that things can be composed in
  general is very different than the practicality
  of composition

9
Implications and Questions

• Is this just simply hard?
• In authors' conclusion on Aspect-Oriented
  Programming, it is noted that this solution is
  better suited for large, heterogeneous systems
  using larger components but AOP has better
  run-time performance
• Begs question if the chosen architecture activity
  is actually combinatorially more complex

10
Implications and Questions

• Are we at the point where ubiquitous, embedded
  architecture development will require extensive
  standards setting?
• How are we going to get all these meta models to
  be interoperable?
• Can small teams effectively architect an
  unprecedented system?
• Think of the relative size of the initial
  Internet protocol development team

11
Wrap-Up

• Available resources/implementations
• Structure/Architecture
• Discussion of Assumptions
• Limitations / Benefits

12
Discussion