Dr. Dobb's Journal February, 2005
We develop complex scientific applications and integration between different instrument, inventory, and financial systems. To get a better handle on scope and requirements, we began using UML. However, the more we used Activity Diagrams to model the end-user tasks and user interaction at the screen, the more we recognized a gap in UML—there is no way to actually model user interaction that illustrates the steps and required actions users perform to complete their tasks.
Upon examination, we identified a pattern of what users needed to do on screen—enter this, read that, select next, and submit all. We then saw a direct correlation between user function and the type of GUI elements we were using to perform that function. Consequently, we devised what we call "Extended Activity Semantics" (XAS) to model the business tasks and required user interactions to complete those tasks. From this mapping, we can automatically generate GUI elements and simultaneously develop more accurate requirements.
In this article, we present XAS notation and show how you can use it to design user activity. We then describe how the notation can be directly mapped to GUI components to simultaneously construct user interfaces. By applying a simple heuristic between the notation and UI components, we generate a construct for the forward and reverse engineering of user interfaces and activity diagrams. To illustrate how XAS notation can be used, we present Guibot, a CASE tool we developed.
UML provides a good foundation for forward and reverse engineering of class diagrams, and there are numerous tools that produce lots of software based on UML class diagrams. However, for user activity and accompanying user interfaces, class diagrams leave a flat, incomplete view of the user activity. Sequence diagrams and collaboration diagrams produce a dynamic view coupling user activity to the GUI functions and middleware, but they don't translate well to end users during elucidation of use cases and functional requirements.
In short, GUI designers find UML cumbersome and complain that it produces unnecessary work rather than eliminating it. Compounding this problem are the user stories that analysts typically produce as verbose written narratives. Furthermore, user storyboards implemented through written narratives leave too much interpretation and inference by code developers because a narrative offers no inherent mechanism for verifying its own completeness. This deficiency is underscored by industry practices, which are still plagued by problems of bridging the communication gap between those who consume software and the technologists who create it.
Often, prototype user interfaces are used to elicit end-user requirements, but they suffer from only providing a static view of user activity (a "snapshot" view), and fail to express a dynamic model of the end-user's workflow. By modeling the task-based steps necessary for the end user to achieve the goal/purpose of a use case, UML activity diagrams overcome many of these problems. They succeed in illustrating the scenarios of the tasks performed by end users to achieve their goals, yet to stakeholders unfamiliar with activity diagrams, they are insufficient to provide a clear picture of the software system "to be."
From our experience of elaborating software requirements for complex systems, domain experts and stakeholders are hungry for such visualization early in the specification of a new software project. Using existing tools, we have found that the best way to provide such vision to stakeholders is via an approach employing both static UI prototypes and activity diagrams to complement one another. This method yields greater end-user involvement in the design and specification of user activity, provides better user satisfaction, and results in a more accurate and detailed definition of end-user requirements early in the project lifecycle.
Subsequently, through such a process of drafting user prototypes in parallel with activity diagrams, we have determined that user interaction at the interface could be directly represented by a notational supplement to activity diagrams, which in turn can be mapped back to GUI components, which we employ in our Guibot tools.
Users perform defined sets of irreducible actions with respect to user interfaces—input, review, select, and command. We represent these actions as inputters, outputters, selectors, and action invokers. User actions such as drag-and-drop are composite actions of these irreducible actions, where drag-and-drop would be select-and-input. In addition, there is a multiplicity—formatting of the information in to and out of the system and conditions surrounding the information.
The Multiplicity denotes whether the action is required or optional, or whether it requires multiple actions, such as one or many selections to be made. Formatting describes the presentation of the information, such as the format of a date input or output. The Conditions for an action define what is allowed or needed, such as a "date entry must be earlier than today," or a "password must be longer than some number of characters."
In the use of activity diagrams, prose in the business language of the end user is generally written to describe these actions and constraints. Although the UML specification does state that pseudocode and programming language code can be used in developing activity diagrams, in the context of eliciting requirements from end users, we have found their own business language is the most effective. As an extension to activity diagrams, we added the following XAS notation to translate such "business actions" into user interactions:
The complete grammar for inputters, outputters, and selectors, therefore, is respectively expressed as:
>>,<<, V m..n label :
datatype | mask [conditions]
while for action invokers it is:
! command [conditions]
Figure 1, a typical activity diagram presented in the UML 1.5 specification, illustrates customer ordering services from the sales department and a stockroom filling the order. While this example is a satisfactory description of the general workflow, these action states require more detail to describe the process for both end users and software developers when it comes to human/computer interface issues.
By adding XAS to each action state that requires user interaction in Figure 1, we can detail the interactions required and any requirements surrounding these user interactions that are necessary to complete the task. Figure 2(a) is a more detailed activity diagram employing XAS and more comprehensively describing user activity.
In Figure 2(a), the customer selects 1 to n services, then to pay for those services, the system outputs the order amount, formatted as $*.##, although the grammar for the format can be of the analyst's choosing. Here we specify any dollar amount with the condition that the order amount must equal the sum of the amounts of each individual service. When the order is collected, the order is received by the customer, expressed with the condition that the collection date is less than or equal to the delivery due date.
In Figure 2(b), the sales department selects the order, reviews the payment submitted, and processes the payment. When the order is filled by the stockroom, the sales department delivers the order to the customer with the specified condition that the delivery date is less than or equal to the delivery due date.
In Figure 2(c), the stockroom selects an order with the condition it has not been filled, and then processes the order in order to fill it.
To automatically generate GUI prototypes, we have developed a mapping between the activity diagram elements and the notation elements of Extended Activity Semantics; see Table 1. Swimlanes represent the view for the actor and are represented by a GUI form. The action state groups the user interaction and is represented by GUI groupboxes or panels. Inputters typically are text boxes, text areas, and grids. Outputters typically are labels, grids, image boxes, and read-only text areas. Single selectors typically are comboboxes, single selection list boxes, radio buttons, or treeviews. Multiselectors are typically multiselection list boxes, grids, checkboxes, and list views. Action invokers are typically command buttons, hyperlinks, menu items, and image buttons.
Guibot, for example, directly maps the activity diagram elements and the XAS to GUI components. Figure 2 automatically produces the GUI prototypes for the customer, sales, and stockroom swimlanes in Figures 3(a), 3(b), and 3(c). The resulting prototype allows immediate understanding between users and analysts, and defines the expectations for the coder.
If you add an input box to the Pay panel in the Customer user interface in Figure 3(a) for security code (csc) entry for credit cards, the action state is updated with the new inputter information via the mapping between notational elements and the GUI components; see Figure 4.
The XAS extensions let us maximize the benefits that activity diagrams offer. Rapid prototyping gathers faster buy-in from the customer and faster elaboration of their business needs. Less ambiguous software requirements are generated earlier, obviating the need for onerous or extended iterations. The extended activity diagrams are implementation agnostic, allowing technologists to determine the best implementation path. For small projects or short discussions, we even whiteboard the notation to expedite communication.
DDJ