UML use cases, sequence diagrams: easily converted into executable code

Engineering and IT Insight: UML (Unified Modeling Language) is the language of software engineering, and State Models in UML are used to define internal logic. When state diagrams, use case diagrams, and sequence diagrams are combined with UML class diagrams they define a system, can be easily understood by non-programmers, and can be rapidly converted into executable code.

02/20/2012


UML (Unified Modeling Language) is the language of software engineering, and the ever increasing software content of automation means that it is a language that automation engineers must understand. There are three basic parts to any software; structure (data and or messages), system behavior and interactions, and internal logic. UML defines a standard language for each of these elements. Last month’s column described two parts of UML that deal with structural information; class models and object models. The structural models can be used to generate databases, function block libraries, messages, IEC 61131-3 structured text STRUCT definitions, C# classes or C++ classes. System behavior is defined through Use Case Diagrams and Sequence Diagrams. State Models in UML are used to define internal logic.

UML state models are an extended version of finite state models, which are diagrams containing states and events. State models define the internal behavior of objects that can be implemented in procedures, function blocks, or any other type of code. UML state models are extended to include nested states, variable values associated with states, and guard conditions. Nested states support complex state models, where one event may cause a transition from multiple states. Nested states are commonly used in specifications to reduce state model complexity and make them easier to understand. Variable values support looping of state/event values, allowing different actions depending on the loop value. Guard conditions define Boolean checks that prevent an event from causing a state change, and are also used to simplify state model designs. Each event in a state model defines the actions that are to occur when the event happens. In control systems, there can also be logic that is repetitively executed while in a state.

The following diagram illustrates a simple nested state model for a device. It starts in the IDLE state and when it receives a START event it will go to the RUNNING state. The device may be paused and when performing pausing logic, or waiting for the physical device to respond, it is in the PAUSING state. When pausing is complete the device enters the PAUSED state. On a RESUME event the device goes back to RUNNING. If a STOP event is received, then it goes to the IDLE state independent of the current state. If the run time in the RUNNING state is exceeded, then the device also goes to the IDLE state.

UML state models are an extended version of finite state models, which are diagrams containing states and events. This shows a simple nested state model for a device. Courtesy: Control Engineering

Use case diagrams (UCDs) define system behavior through the interactions of actors and processes. They essentially define the needed interfaces to processes or objects. UCDs contain one or more use cases and illustrate how external systems interact with each use case. External systems may be a person, organization or other system and are called “actors’ in UML terminology. An actor performs one or more “roles” in an interaction diagram, such as a person performing the role of an Operator or a Supervisor or a PLC performing the role of a safety system. Use cases are represented as ellipses, and, in one of the unfortunate accidents of collaborative standards (such as UML), actors are drawn as stick figures, making UCDs look like badly drawn cartoons. Each use case represents one scenario. A scenario represents either a normal situation with no errors or an abnormal situation where one or more errors can occur. Use cases may be nested so that one use case represents a complete UCD, which contains more detailed smaller use cases.

An association is defined whenever an actor is involved with a use case and is represented as a solid line. Many interactions are two way, with multiple related transactions. If the interaction is only a one way interaction, then it is documented with an arrowhead on the line. Each use case in a UCD is defined through a sequence of actions that provide some basic function of the system that has importance or value to the actor. A typical UCD may involve 3 to 10 use cases and from 1 to 10 actors. UCDs provide an overview of major external interactions, defining either normal or abnormal situations, and provide a structure for Sequence diagrams.

The following diagram illustrates a typical UCD. It shows two actors (an operator and a data historian), two systems (a control system and a safety system), and three use cases. Each use case has an associated sequence of actions (shown in a sequence diagram) that describe the sequence of interactions with the actor.

This illustrates a typical UML use case diagram (UCD). It shows two actors (an operator and a data historian), two systems (a control system and a safety system), and three use cases. Courtesy: Control Engineering

Use cases in a UCD may be grouped together into systems when the system substructure in know. Use cases may also be related through “Uses” or “Extends” relationships. For example, an Equipment Startup use case may extend a Machine Power-up use case and a Machine Self-Check use case, where the Machine Power-up use case and Machine Self-Check use case are defined in different UCDs.

UCDs should not be used to represent a sequence of steps. Sequence Diagrams should be used to represent the time sequence communication among two or more processes or objects. A sequence diagram is a type of message sequence chart, even though the communication may not be messages but may be procedure calls, object method invocations, web service calls, or any other method of inter-process communication. A sequence diagram is used to describe the expected, or desired, flow of information for one specific use case. For example, one use case may be a no-error use case which describes normal communication, while another use case may describe the sequence of communications when an error occurs.

As in message sequence charts, sequence diagrams are represented as a set of vertical lines, one line for each process or actor that participates in the sequence. Each communication event between participants is represented as a horizontal arrow, and the communication event contains the content of the event (such as the parameters used if the event is a procedure call). The communication events are ordered by time, with the first message at the top and time increasing as you move down the vertical lines.

The following example shows a message sequence between an operator, a process, and a data historian. It shows the messages for the normal equipment operation. There are many other options available in Sequence Diagrams, including the ability to show object creation and deletion, loops of message transactions, alternate paths, and guard statements (which define a condition that must be met before the message is sent).

This UML diagram shows a message sequence between an operator, a process, and a data historian. It shows the messages for the normal equipment operation. Courtesy: Control Engineering

Sequence diagrams are used to define the interfaces to processes or objects. Each communication defines a possible interface, which can be implemented as a function block interface, an IEC 61131-3 structured text function definition, a network message definition, or object method definition. The diagrams are also used to define the process that should occur when a communication is received.

The combination of state models, UCDs and sequence diagrams define the internal logic and behavior of the system, defining how the system will respond to normal and abnormal conditions. When state diagrams, UCDs, and sequence diagrams are combined with UML class diagrams they provide a complete definition of a system which can be easily understood by non-programmers, and can also be rapidly converted into executable code. UML is the software engineering language that all control engineers should understand and start to use in their specification and designs.

- Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Edited by Mark T. Hoske, Control Engineering, www.controleng.com.

See diagrams and additional explanation above. Also read: Part 1: Understanding UML is an important part of your toolkit. Link follows.

http://www.controleng.com/single-article/understanding-uml-is-an-important-part-of-your-toolkit/7ad8c16929.html 

Read more Engineering and IT Insight columns by using the following link.

http://www.controleng.com/cgi-bin/ce.cgi?cmd=Search!&fmt=long&form=extended&GroupBySite=no&m=all&ps=10&q=%22dennis+brandl%22&sp=1&sy=1&type=&ul=&wf=2221&wm=wrd&s=DRP



No comments
The Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Leaders Under 40 program features outstanding young people who are making a difference in manufacturing. View the 2013 Leaders here.
The new control room: It's got all the bells and whistles - and alarms, too; Remote maintenance; Specifying VFDs
2014 forecast issue: To serve and to manufacture - Veterans will bring skill and discipline to the plant floor if we can find a way to get them there.
2013 Top Plant: Lincoln Electric Company, Cleveland, Ohio
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.

Bring focus to PLC programming: 5 things to avoid in putting your system together; Managing the DCS upgrade; PLM upgrade: a step-by-step approach
Balancing the bagging triangle; PID tuning improves process efficiency; Standardizing control room HMIs
Commissioning electrical systems in mission critical facilities; Anticipating the Smart Grid; Mitigating arc flash hazards in medium-voltage switchgear; Comparing generator sizing software

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.