| |
Principles
RTDS supports several modeling levels from very informal to express an idea or a concept,
semi-formal to make a link from the idea to the implementation, and formal to allow full
verification before implementation. The more formal is the model, the more verification
can be made.
Informal models
Very early in the development process, ideas are not yet settled. Modeling at that moment
requires to quite open and leave a lot of details on the side. This is a time for
documentation, a time to express use cases with high level scenarios,
a time to focus on the "what" instead of focusing on the "how", a time
to build up a set of dependancies to ensure traceability of the requirements.
A Use case diagram
Actors are identified as well as how they interact with the system.
A Sequence diagram
Sequence Diagrams or Message Sequence Charts provide a detailed
description of a scenario.
Each object, semaphore or task is seen as a line on the diagram where time flows from top
to bottom. Key events in the system have a graphical representation such as :
- Internal states modification,
- Inputs and outputs,
- Timers manipulation,
- Semaphores manipulations (take and give),
- Task creation.
A Sequence Diagram can be used to specify a behaviour or to trace system execution.
|
|
Semi-formal models
Semi-formal models are used by those who have a target in mind. The basic idea is to mix
the code within a graphical model. That makes it easy to take in hand because it is traditionnal
code inside the model. And that guarantees the model and the code are always synchronized
since one is embedded in the other.
Full formal models
For those who need full validation of their model before going any further, formal modeling
is what you want. That is the situation in the case of certification, safety critical systems,
or when the system is given to develop to sub-contractors.
Top level architecture of the system can be drafted as well as their interfaces.
|
|
