FAQ

OOP and UML

Does object-oriented programming (OOP) and UML always have to be used together?

• The combined use of OOP and UML offers many benefits (see next question), although it is not compulsory. Object-oriented programming of applications is also possible without using UML. Likewise, UML can be used in PLC projects, which are not based on object-oriented programming.

What are the benefits of using OOP and UML together?

• In order to make the most of OOP, the structure of an object-oriented software should be designed and created before the implementation (e.g. What classes are available, what is their relationship, what functionalities do they offer, etc.). Before, during and after programming, documentation helps to understand, analyze and maintain the software.
• As an analysis, design and documentation tool for software, UML offers options for planning, creating and documenting the application. UML is particularly suitable for object-oriented implementations, since modular software is particularly suitable for representation with the aid of a graphical language.
• For example, the class diagram is used for analyzing and creating the program structure. The more modular the software structure, the easier and more efficient the class diagram can be used (e.g. Graphical representation of separate function blocks with individual methods for providing the functionalities etc.).
• The state diagram can be used to specify the sequence of a system with discrete events. The more consistent the object- and event-orientation of the software structure, the more transparent and effective the state machines can be designed (e.g. The behavior of modules/systems is based on a state model with states (such as startup, production, pause); within the states corresponding functionalities are called, which are encapsulated in methods (such as startup, execute, pause) etc.).

UML state diagram methods with deactivated "UseVarInst" option

The following three queries refer to methods with the implementation language UML state diagram, which in addition meet one of the following conditions:

• The state diagram method belongs to a program.
• The state diagram method belongs to a function block, and the option UseVarInst of the method is disabled.

State diagram methods that meet these conditions are referred to as "the methods mentioned" in the questions below.

Further information on the option UseVarInst can be found under UML state diagram > Object properties.

Why can these methods only contain cycle-internal states, and why is there no online view?

• As a general rule, all data of a method are temporary and only valid while the method is executed (stack variables). If, however, a method variable is declared as instance variable with VAR_INST, it is not stored on the methods stack, but on the stack for the function block instance. It therefore behaves like other variables of the function block instance and is not reinitialized with each call of the method.
• Since the data of the state diagram method mentioned are not declared as instance variables, they are cycle-internal state machines. The states contained in the diagrams are therefore switched cycle-internally, not by the task cycle, since the method execution "restarts" with each task cycle, due to the temporary nature of the data management. Online view is therefore not available for these state diagram methods, since the variables of the state machine are temporary, and the active state can change repeatedly within a cycle.
• This is in contrast to state diagrams without temporary data management (e.g. programs or function blocks as state diagram, function block method as state diagram with UseVarInst option enabled), in which the states are switched by the task cycle as standard and can optionally be configured as "cycle-internal".

Why does the tool list for the methods mentioned not contain composite states, forks and joins?

• Since the data of these methods are temporary and only valid while the method is executed, the UML state diagram methods can only have cycle-internal states (see previous question).
• A composite state would therefore have to be completed within a cycle. This means the element would always be processed sequentially, even if execution of a region is not completed.
• This behavior would therefore be fundamentally different than for "normal" composite states, which can remember their internal state.
• So as not to offer different behaviors for a composite state, depending on the POU type with which the element is used, the composite states are not allowed in the methods mentioned.
• Since forks and joins are only permitted in conjunction with composite states, these elements are not available in den state diagram methods mentioned.

What should be considered when programming the methods mentioned? What could be the reason for high system load when these methods are executed?

• As explained under the previous questions, the UML state diagram methods are cycle-internal state machines. Therefore, they are operated cycle-internally, not based on the task cycle.
• This means that completion of the actions of an internal state is followed immediately by the transition. The transition condition is checked immediately, and the transition action is executed when the condition is met. Also, the system immediately switches to the target state when the transition condition is met.
• If the transition condition is not met, the system does not switch to the target state, and the current state remains active. Due to the cycle-internal states, the DO action for the current state is called again in the same cycle, if the maximum number of DO-cycle calls was not yet reached.
• Max. DO-cycle calls: The maximum number of DO-cycle calls for a state can be configured, whereby a value between 1 and 32767 can be set. This number indicates the maximum number of DO-action calls.
• Note the following: If the transition condition is not met during the whole task cycle, the DO-action of the current active state is executed in this cycle until the maximum number of DO-cycle calls in this state is reached.

Sample: If a value of 32767 is set for "max. DO-cycle calls" and the transition condition is not met during the task cycle, the DO-action of the corresponding state is executed 32767 times in a cycle! Since this could lead to high system load, depending on the scope of the DO-action, the state machine and in particular the transition condition and the maximum number of DO-cycle calls should be verified for compliance with the required application behavior.