SE or C for ES?
Download
1 / 10

SE or C for ES? Discussion Group - PowerPoint PPT Presentation


  • 100 Views
  • Uploaded on

SE or C for ES? Discussion Group. Olaf Spinczyk / Bernd Fischer Embedded System Software Group Computer Science 12 TU Dortmund [email protected] http://ess.cs.tu-dortmund.de/~os/. Why C?. Fear of performance issues Lack of tool support Matlab/Simulink ok

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' SE or C for ES? Discussion Group' - katima


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

SE or C for ES?

Discussion Group

Olaf Spinczyk / Bernd Fischer

Embedded System Software Group

Computer Science 12

TU Dortmund

[email protected]

http://ess.cs.tu-dortmund.de/~os/


Why c
Why C?

  • Fear of performance issues

  • Lack of tool support

    • Matlab/Simulink ok

  • Certification is very difficult with dynamic dispatch, etc.

    • predictability is critical

    • Safety critical applications are common in ES


Tailoring embedded dbms today
Tailoring Embedded DBMS Today?

  • Not at all? Not really.

    • Berkeley DB a little (11 features, #ifdefs, runtime checks)‏

    • Ctree (C, multiple variants)‏

    • 2 -3 commercial embedded databases

    • Flash DB

  • Models? Models for variability?

    • No. At least we don't know better.


Se techniques of interest
SE Techniques of Interest

  • Various techniques that support Product Line Enginering

    • CPP++

    • OO

    • AOP

    • FOP

    • SOA

    • MDSD


How to do better
How to do better?

  • With CPP++

  • Benefits

    • same level of configurability

    • better views, navigation, documentation (statistics)‏

    • checking consistency

    • maintenance costs are reduced

    • could be coupled with variant management tools

  • Open Issues

    • how to use it?

      • what is the right feature granularity?

    • depending on the feature granularity #ifdef hell could be replacedby a color hell


  • How to do better1
    How to do better?

    • With OO (and Components)‏

  • Benefits

    • modularization, ...

  • Open Issues

    • crosscutting concerns

    • granularity vs overhead

    • dynamic binding vs. resource constraints


  • How to do better2
    How to do better?

    • With AOP or FOP

  • Benefits

    • Better modularity

      • -ilities

      • feature tracability (mapping of features to modules better)‏

    • Generating variants is easier

    • Pluggability of modules

    • Development easier

  • Open Issues

    • unexpected results with aspects (wrong pointcuts)‏

    • with FOP combining layer in mind is difficult

    • tools support for visualization and reasoning etc. crucial

      • aspect interaction...

      • no commercial support, yet


  • How to do better3
    How to do better?

    • With MDSD

  • Benefits

    • ultimate generative power

    • arbitrary domain-specific abstraction

      • e.g. a language for locking mechanism

  • Open Issues

    • abstraction gap between feature model and MDSD model low or even not existing

    • how many DB-specific abstraction do exist?


  • How to do better?

    • With SOA

  • Benefits

    • easy to integrate and flexible architecture

    • loosely coupled components

    • distributed components

    • high autonomy

    • reduced complexity

  • Open Issues

    • communication overhead

    • SOA and embedded devices don’t really match

      • SOA is designed for large enterprises

      • are small scale applications

    • can’t be fast and reliable at the same time


  • So what can we do
    So what can we do?

    • Can we take just the benefits?

    • Is there a migration path from the current state of the art to more advance SE techniques?

      • start thinking in product lines

      • use CPP++: very close to #ifdef, but visualization etc.

      • use simple objects or components: clearly defined interfaces; higher level of abstraction; be aware of costs!

      • use AOP and/or FOP: better modularization of feature implementations in the solution space (homogeneously crosscutting/inhomogeneously crosscutting concerns)‏

      • use MDSD: more “generative power” and arbitrary domain-specific models

      • use SOA: decoupling and distribution of components

    • Tool support for each migration step would be needed


    ad