UMLEmb
UML
for
Embedded
Systems

Exams

The exam focuses on the understanding of the course, and on both practical and theoretical aspects of UML for embedded systems.

Various information

  • Date: To be defined.
  • Duration&kind: Eurecom: 3-hour lab, Polytech'Nice: 2-hour exam.
  • Grading: 70% for the exam, 30% for labs.
  • Authorized documents: limited to course's slides, labs or homework documents. Nothing else.
  • Language (Eurecom): The exam is provided in English only, but you may answer either in English or in French (but do not mix both!). You will have to use TTool to make your models.

Past exams



Advices and common mistakes

All diagrams

  • Keep your diagrams readable.
  • Ensure the coherency between your diagrams. For example, if there is a requirement on the "Battery" of the system, it is very likely that this battery will be used in other diagrams. Also, if an element is an actor in the Use Case Diagram, then it should also be an actor in the Sequence Diagram, and not be part of the blocks modeling the system in the design diagrams (but it could be part of the blocks modeling the environment).
  • In all diagrams, you have to be clear on what is be part of the system, and what is not part of the system.
  • "DeriveRqt", "Refine" are very often drawn in the wrong direction.

Assumptions

  • I usually ask for separating environment assumptions from system assumptions. So, you should make two separate lists.

Use Case Diagram

  • The name of the system must be very precise e.g. "Software of the Intel Smart Connect system".
  • "include" and "extend" links are commonly drawn in the wrong direction. Beware!

Activity diagrams

  • Be clear about which activities can be executed in parallel, and which are only sequential.

Sequence diagrams

  • Never use messages between actors.
  • A lifeline without an actor models a subsystem of the system. If a lifeline represents an actor, do put the actor sign on top of it.

Design diagrams

  • Using non deterministic choices generates combinatory explosion. For example, after(1,1000) or random(0,1000) should be used only if really necessary. If you want to model only two possible behaviors, put two transitions starting from the same state: avoid using large random intervals for two possible behaviors.
  • Use simulation as soon as possible even if your model is not (yet) complete.