Modern microcontrollers have more power in a chip than the first personal computers. This makes the use of modern programming languages such as C ++ possible. This can significantly improve the software quality and the speed of development. Object-oriented programming languages have long established themselves in PC systems. This is also increasingly evident in microcontrollers.

For many, object orientation as a paradigm of software development is elusive. Even if one can already use an object-oriented programming language such as C ++, JAVA or C #, it does not necessarily mean that actively object-oriented concepts are systematically applied.

To start with, the most important concept of object orientation should be described. In the literature this is called abstraction. That sounds more complicated than it is. We can translate this concept into simple words: “We give things names.”

This means that we as humans communicate about things and also think about things by assigning a term to them. This is essential for our ability to use a language. It's not difficult for us at all. We do this around the clock.

In the UML models that we are going to create, the “naming” is expressed in that we represent the elements that we want to program as follows.

The things we talk about and think about are interrelated. Taking this into account is also one of the object-oriented concepts. In language we find the relationships between things as verbs (subject-predicate-object). The LED is connected to the controller. We can then also represent this in the UML.

A very important type of relationship that we consider in object orientation is that something can belong to a certain group. The controller that we will program in this course belongs to the STM32 family. With the UML we learn to model this fact abstractly.

Summary:

• Object orientation means first giving things meaningful names (abstraction, class)
• Things are related to other things
  • Things know / use each other (association, dependency)
  • Things are made up of other things (aggregation, composition)
• Things belong to groups (abstraction, generalization, specialization, realization, reuse)

• detailed discussion of the object-oriented basic concepts

The UML has developed into an established representation technique that is particularly suitable for modeling object-oriented software. With the international standard ISO 19505, the UML is regulated in a globally binding manner. A few diagrams and a manageable set of symbols are sufficient to start using the UML.

As can be seen from the illustration, the UML comprises a number of different diagram types that are strictly classified according to whether structures or behavior are visualized. There is no representation technique in UML that encompasses structure and behavior at the same time.

The use case diagram shows the system to be developed from the perspective of the user. UML and SysML offer this form of representation to clarify WHO does WHAT with WHAT. It is particularly suitable during development for the visualization of the main requirements or in the documentation for the representation of the main functions of a system.

* the WHO is the user, this is shown as a stick figure

• If the user of the system is another external system then this is shown as a cube
• the WHAT is the described system itself
• To show what belongs to the system and what is outside the system, the system boundary should be shown as a frame
• the application is the WHAT , it is a service that the system provides for a user or another system
• The user is related to the application he is using, these relationships represent an interaction of the user with the system and should therefore be drawn without a specific direction
• Use cases can call each other, these calls are shown with dashed lines.

In this course we use the use case diagram to visualize the main requirements for solutions to be developed. The representations become more complex step by step.

• the use case diagram in detail

Activity diagrams are based very much on the long-known and widespread flowcharts. They can even be found in some user guides. They are self-explanatory and easy to understand. The activity diagram shown on the right is the refinement of the use case: “User calls someone with the smartphone”. The use case represents the main requirement for the smartphone to be able to make calls with it. The activity diagram describes in more detail how this works.

• Use case = main requirement
• Activity diagram = functional requirements

The textual test instructions for the system can be generated automatically as so-called test cases or test scenarios from this activity diagram.

Scenario: user make calls - path 1

1. / Start
2. user / switches on the smartphone
3. smartphone / booting
4. smartphone / asks for the PIN
5. user / enters the PIN
6. / PIN
7. smartphone / checks the pin
8. smartphone [PIN is wrong] / shows an error message
9. user / enters the PIN
10. / PIN
11. smartphone / checks the pin
12. smartphone [PIN OK] / shows the start screen
13. user / click the phone icon
14. smartphone / shows the numeric keypad
15. user / dials the phone number
16. smartphone / establishes the connection
17. user / speaks to the called party
18. user / hangs up
19. smartphone / closes the connection
20. / End

The activity diagram shown consists of the following display elements:

• elementary actions = rectangles with rounded corners
• Beginning of the process = black point
• End of the process = black point in the circle
• Decision = diamond with two exits
• Partition (responsible for actions) = frame around the actions
• Control flow = links with arrow for direction
• Data element / data flow = rectangle

• more detailed information on the activity diagram

Class diagrams are the most important UML diagrams. These are the actual blueprints of the software. Use case diagrams and activity diagrams are only there so that the software developer has sufficient information to design and implement the software. We use the class diagram not only for construction but also for implementation. You can not only display the structure of the software with it, but also generate the source code from this diagram.

The most important element in the class diagram is the class. We can translate class with a system component. All things that make up an embedded system are potential classes. These can be sensors, actuators, buttons, LEDs, displays, other controllers, but also internal components such as timers. Each module is represented by a class (rectangle) in the construction drawing. Each block can have properties (attributes) and behavior (operations). These are displayed in the UML class diagram as lists within the class symbol. Classes are types by nature. The programmer must create instances of the classes (see variables) in order to use them. Since the hardware used is often only required once as an instance in embedded systems, the distinction between class and object or type and instance plays a subordinate role in the perspective of the class design. This only becomes important when C ++ code has to be written to implement the desired logic.

• system element = classes with
  • Properties = attributes
  • Behavior = operations
• Object = instance of a class

With the basic concepts of object orientation, we have already learned that the relationships between the system components are of great importance for an object-oriented design of the software of an embedded system. What sounds complicated is easier than expected in practice. At the beginning you can limit the decision which of the different UML relationship types between classes should be used to only two. Translating this decision into simple words, when modeling a relationship between two classes, the developer simply has to ask:

1. class A is a class B or
2. class A has a class B?

Example 1:

1. the controller is an STM32 or
2. the controller has an STM32?

• The answer should be pretty clear for “is a”

Example 2:

1. the controller is an LED or
2. the controller has an LED?

• In this case the answer should clearly tend to “has”

With this we can limit the required relationship types to the following at the beginning:

• Generalization / Realization = “is a” thick, unpainted arrow with a solid or dashed line
• Aggregation = “has” = narrow arrow with diamond at the beginning

The following simple class design shows the application of what has been described:

Translated into simple words, the following can be read in this class model:

There are the system elements SMT32, controller, button and LED.
The controller is an STM32.
The controller has a button.
The controller has an LED.
The controller can be started (start).
The controller can run.
The controller can do something every 10 milliseconds (onTimer10ms).
The button can be pressed (isPressed).
The LED can be switched on.
The LED can be switched off.
The LED can be switched (toggle).

The code generator delivers the following code for the class declaration in C ++ for the LED class at the push of a button:

class LED
{
   public: LED();
   public: ~LED();
   public: void on();
   public: void off();
   public: void toggle();  
};

• More detailed information on classes and class diagrams

Sequence diagrams show just like activity diagrams HOW something is happening in the system. The most important difference besides the way of representation is that concrete messages are already modeled in the sequence diagram. Messages are ultimately calls to operations. This means that sequence diagrams are much more specific and close to implementation. Activity diagrams can clearly abstract from the concrete implementation in C ++ or another object-oriented programming language. Sequence diagrams are much closer to coding by their very nature. The following example shows the direct translation between C ++ source code and UML sequence diagram, in this case generated automatically by a generator.

Controller::onEvent100ms()
{
  if (led.getState())
  {
	led.off();
  }
  else
  {
	if (button.isPressed())
	{
		led.on();
	}
  }
}

In this course we use sequence diagrams to document selected code fragments. The diagrams are generated automatically by a generator and can be used in documentation instead of the source code.

• more detailed information on sequence diagrams

Neither the source code nor the sequence diagram shows at first glance what has been programmed. This means that you first have to figure out what happens every 100 milliseconds in your head. The logic is event-driven and based on the ON / OFF states. The following illustration shows exactly the same algorithm as the transition between the states ON and OFF.

This state diagram shows much more clearly that, driven by the 100 millisecond event, the LED changes between the states ON and OFF when the button is pressed, i.e. flashes. In this course we will also use the state diagram for programming. Source code can be generated from state diagrams in the same way as from class diagrams. Many tasks for embedded systems are event triggered and state-oriented. It is worthwhile to generate program logic from properly modeled state models.

• more detailed information on the state machine

In the introduction it was already shown that modern systems have to be understood in an interdisciplinary manner. But for a long time there was no interdisciplinary modeling language. Each specialist domain knows highly developed and standardized subject-specific modeling languages, but only specialists can really understand them. The domain-specific modeling languages ​​are not suitable for interdisciplinary communication. SysML is an offer to close this gap. As a general modeling language for systems, SysML abstracts from domain-specific symbols in electrical engineering, mechanics, hydraulics, pneumatics, electronics and software. The origin of the SysML can be found in the UML and many elements correspond to the UML, but the focus of the SysML is not on object orientation and software, but offers modeling options for any type of system. So-called block diagrams are a non-standardized means of interdisciplinary representation of system interrelationships. This was created and understood or not understood at will. This is where SysML comes in. The block as a basic element of modeling, regardless of whether it is a mechanical, electronic, hydraulic, pneumatic or a software block, is standardized, as is the representation of the relationships between such blocks. System module - block - class. Anyone who establishes this connection is already very close to the intentions of SysML. The overlaps in the conception of UML and SysML are clearly shown in the similar structure of SysML and UML. Compare the taxonomy of SysML with that of UML.

In this course, selected SysML representations are used to represent hardware configurations and to visualize hardware and software in a context. For this we use simple notation elements from block definition and internal block diagrams. Use case diagrams and activity diagrams are common representation techniques of UML and SysML.

Three important elements should be briefly introduced here.

• Block, the block is a clearly definable system component. It is irrelevant whether it is a mechanical, electrical, electronic or a software component.

• Flow, a flow indicates that something is being transmitted. These can be material flows, energy flows or information flows.

• Composition, this type of relationship between blocks is used to show that a block is composed of other blocks

• Interface, an interface shows that system blocks can be or are connected to one another in a defined way. The symbol is deliberately based on the plug-socket notation of electrical engineering, but in SysML these can be mechanical, electrical, hydraulic, pneumatic connections or software interfaces.

The basic structure of a smartphone is to be documented as an example of a simple block definition diagram.

• more detailed information on SysML

• next chapter
• Back to overview