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 website, including slides and labs. You can also come with an A4 paper, with your own notes on both sides. You can also use your previous models that you can open in TTool of necessary.
  
• 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

• Fall 2023. (Software of the mobile application of a bike reservation system) EURECOM (connected Pumpkin) Polytech'Nice.


• Fall 2022. (Digital augmented hand cart) EURECOM. (Smoked salmon packing system) Polytech'Nice.


• Fall 2021. (Space-based embedded system) EURECOM (Dynamic Positioning System for Ships) Polytech'Nice


• Fall 2020. (Platooning system): EURECOM and (FPGA scheduling) Polytech'Nice.


• Fall 2019. (Glucose Monitoring System): EURECOM and Polytech'Nice version.


• Fall 2018. (FortiSandBox): EURECOM and (BEWARE: it is a different from the Eurecom exam) Polytech'Nice version.


• Fall 2017 (Rover): EURECOM and (BEWARE: it is a different from the Eurecom exam) Polytech'Nice version.


• Fall 2016 (Lunch seeker mobile application): EURECOM and (3D printer) Polytech'Nice version.


• Fall 2015 (Webcam Foscam Fi9900p): EURECOM version and Polytech'Nice version.


• Fall 2014 (Intel Smart Connect Technology: Features and Requirements): EURECOM version and Polytech'Nice version.


• Fall 2013 EURECOM (Automotive system: messages lead to safety reaction): English version


• Fall 2013 Polytech'Nice (Réaction à un danger dans un système automobile): French version


• Fall 2012 (Drone navigation): English version


• Fall 2011 (Photo application): English version


• Fall 2010 (Base station): English version


• Fall 2009 (Smartphone application system): English version


• Fall 2008 (Hybrid vehicle): English version


• Fall 2006 (Drone system): English version, Solutions in English


• Fall 2005 (Railroad crossing system): English version, French version


• Fall 2004 (Coffee machine): English version, French version

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".
• The name of a use case must start with a verb because a use case captures a function of the system under design
• "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.
• Important timing information shall be captured

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.