Fun with Frames and the User Experience Model
by
Bob Maksimchuk, Principal Consultant
Project Pragmatics, LLC www.ProjectPragmatics.com
Rmaksimchuk@ProjectPragmatics.com
Development teams don’t necessarily receive “requirements” from their stakeholders as use cases, textual requirements, user stories, or even “drive-by requirements” (where the stakeholder throws a yellow sticky note - that contains their latest requirement - over your cubicle wall as they walk down the hallway). And sometimes the end users (an important stakeholder) are so focused around the user interface of the system, that suggesting changes to their user interface is the only way they know how to express their needs. Not an optimal situation, but we must deal with it.
The advice you commonly hear regarding using the UML© for user interface modeling ranges from “don’t do it” to (at best) “create a User Experience (UX) model” (i.e. a set of class and sequence diagrams to show structure, navigation, and behavior of the user interface). The UX model as traditionally described is good for simple situations, but with the advent of more modern, complex UI presentation options, the traditional UX model’s utility begins to reach its limit quickly.
A recent client of mine was facing this situation. Screen structure and screen-to-screen navigation of their application was not that much of an issue (although their screens were so complex that the models of them were quite impressive and contained deep detail). Behavior (i.e. the processing flow that the users direct via the interface) was the issue. Run-of-the-mill sequence diagramming became quite complicated and did not provide a satisfying outcome, due to the plethora of possible scenarios a stakeholder might take. Also, the limitations of some modeling tools, particularly regarding sequence diagrams, caused much rework when changing requirements drove changes to the existing UX models.
Being a very pragmatic consultant, I was hesitant to delve into the more obscure and little used areas of the UML (been there before…it’s rarely a pleasing experience), because many of my client’s staff were still just being introduced to UML modeling. I was pleased to find an elegant answer available in an area that does not get delved into deeply very often—interaction operators.
There are many different interaction operators used on sequence diagrams. You probably have seen and used some of the more prevalent ones such as “loop” and “alt” – labeling a group of messages enclosed by a rectangular “frame” – specifying that the messages are to be looped through or selected from, respectively. If these are new to you, here is a basic example of using the alt operator.
Choosing Alternative Flows – “Alt” Operator
When a scenario indicates there could be more than one path that may be chosen, an alt operator should be used. An alt frame can have one or more compartments. Each compartment contains a specific fragment of the interaction. Which one of the fragments is executed depends on the guard condition (shown in square brackets) on the compartment (see Figure 1).
Figure 1 – Alt Interaction Operator
Here you see four guard conditions A, B, C, and Else. The flow of the sequence diagram begins with message 1.0 from object Object1 to Object2. Then the guard conditions are evaluated. For whichever one is true, the messages in that compartment are executed. For example, if [C] is true, messages 1.4, 1.5, and 1.6 within the C compartment are executed. Once these messages are executed, the flow continues immediately following the alt frame with message 1.8. If none of the guard conditions are true, the [Else] compartment messages are sent and similarly the flow continues immediately following the alt frame with message 1.8.
Optional Flows – “Opt” Operator
One of the interaction operators that is seen infrequently is the opt operator. When there are possible interactions that may or may not happen, an opt operator can be used. The use of this operator indicates that a behavior either occurs or nothing occurs.
In Figure 2, messages 1.0 and 1.1 execute. Then if the opt frame guard condition is true (i.e., a log of a transaction is requested) then the Log Transaction message (1.2) is executed. Otherwise, the flow just continues from message 1.1 to message 1.3.
Figure 2 – Opt Interaction Operator
Interrupting Flows – “Break” Operator
Another infrequently seen interaction operator is break. Sometimes, when a flow is executing an interruption happens (e.g., the user pushes a Reset button to clear a form). This is where the break operator is used. Break indicates an “interrupting” scenario that is executed instead of the remainder of the original scenario in the enclosing frame. By convention an interaction fragment with a break operator should extend across all the lifelines in the diagram.
In Figure 3, if the guard condition [Reset Pressed] is true at any time during the interaction flow, the flow immediately “jumps” into the break frame. The messages in the break frame (1.5 and 1.6) are executed. Then the flow leaves the break frame and jumps out of the frame that encloses the break frame (skipping any subsequent message flows in the enclosing frame, in this case, message 1.7). In Figure 3, there is an implied enclosing frame surrounding the entire diagram; so, the entire interaction terminates.
Figure 3 – Break Interaction Operator
Nesting Frames
Realize that frames can be put inside other frames. Imagine an alt frame containing loop frames, with opt frames and break frames scattered throughout. This can create quite complex flows. Take care to clearly understand the way the flows change and where they resume based on the type of interaction operator(s) you are using.
The combination of just these few interaction operators, gave my client and I an elegant way to depict the complex flows of the system we were working on. Consider, with multiple levels of nesting and by exploring some of the other seldom used interaction operators, how much fun you can have with frames.
__________________________________________________________________________________
Thanks to Michael W. Engle, Certified Enterprise Architect, for his technical review of this article.
WANT TO USE THIS ARTICLE IN YOUR E-ZINE, BLOG OR WEB SITE?
You can, as long as you include the following complete text with it: “Bob Maksimchuk is a Software Development Team Coach, Author, and Speaker at Project Pragmatics, LLC., specializing in helping software development teams GET WORK DONE by introducing: PRACTICAL techniques, STREAMLINED process, and FOCUSED training and mentoring, all specific to your team's needs. Visit now at http://www.ProjectPragmatics.com. All rights reserved © 2010 Project Pragmatics, LLC.”