Speeding up UML control flow system specification with "Rapid" Use Case Development (RUCD) - Embedded.com

Speeding up UML control flow system specification with “Rapid” Use Case Development (RUCD)

In today's fast paced world of engineering and rapidprototyping,sometimes system requirements can be victims of tough schedulingdemands.

Conversely, in large scale systems, engineers can be facedwith an overwhelming number of requirements which are spread acrossnumerous volumes of documents, which in either case; results into alaborious task that nobody wants to perform.

In today's modern world new approaches and modeling tools, engineernow move toward using more advanced and mature techniques, such as,applying UML (Unified Model Language) approaches.The modern UML savvyengineer usually creates use cases which describe a particular aspectof a systems behavior. These use cases typically have a basicstructure, in which it contains pre and post conditions followed by aflow of procedural steps invoked by an external source yielding someobservable results.

In developing these requirements, each author has their own uniquewriting style, which usually is inconsistent with co-authors. Authorswill vary with their use of terms, syntax and amount of detail. Lastly,many engineers just shy away from the task due to lack of interest inwriting another dull term paper.

Short-hand for rapid use casedevelopment
Don't fear, hope has arrived during my efforts in writing systemrequirements, I thought it would be helpful or maybe just enjoyable, tocreate a common UML syntax that all engineers could follow. This syntaxwould apply constructs, terms and special links that would make sensein the requirement world that somewhat mimics the style of softwaredevelopment.

Then, I believe that engineers would embrace and possibly lookforward to developing. This new short-hand syntax could be a more”rapid” approach which outlines the control flow of requirementsavoiding being tied down to the details, which could be later added ina more formalize document.

This “rapid” use case outline could be a way to formalize theterminology and lexicon used by all authors, thus creating a moreconsistent set of requirements.

To take this a step further, the result of this “rapid” use caseoutline could be use to automate the creation of the formalrequirements applying some ingenious tools to convert this new syntaxin technical jargon or at the very least be translated by professionaltechnical writers whose job it is to produce the final commerciallyacceptable requirement documentation.

This “rapid” use case outline syntax differs from the ObjectConstraint Language (OCL) approach, but a new style toallow quickprototyping and developing requirements in a more consistent approach.

<>Specifying anĀ  EKG with UML
To aid my explanations of this new syntax approach, I will walkthrough a notional example of creation requirements for some type ofmedical instrumentation. In our example, we need to develop functionalrequirements for a heart monitor medical instrument such as an EKGmachine. The EKG machine will need to have an input and output devicethat allows the user to interface with the machine for viewing andprint out results.

If you are unfamiliar with UML and how it applies to use cases, hereare some brief explanations. Applying the UML approach, the engineerwill deploy numerous use cases to handle the various operationalfunctional behaviors during their discovery phase of their functionalrequirements.

These system functional requirements describe all the possiblescenarios which some user (actor) interacts with the system. A use casediagram is created to depict the use cases, external actors and otherexternal systems. Within each use case, documentation describes thedialog between the user and the system, and describing what the systemis doing that the user may not be able to perceive externally.

Use cases can have generalization and dependency relationshipsbetween one another. A generalization relationship is one in which achild use case inherits behavior and meaning from the parent use case.This is typically not used between use cases, however is sometimesapplied between actors. For the dependency relationships, there are twokinds which are used to decompose complicated use cases, “included ” and“extended “.

The “included ” dependency isapplied when a flow of events can beapplied to more than a single use case. This avoids describing the sameflow of events, resulting in the requirement being “pulled” into a usecase. The “extended ” use caseallows you to insert new steps into anexisting use case, resulting in new specialized behavior being “pushed”into a use case. Extended use case is a good approach when handlingasynchronous behavior or new features without affecting the originaluse case.

Applying these concepts to our medical instrument in the discoveryphase, the engineer will need to determine the actors, its goals,summary goals and its main success scenarios. This is an iterativephase, resulting in the refinement of conditions and extensions toscenarios. For our example, the resulting use case diagram is shown in Figure 1 below .

Figure1: Use Case Diagram for Medical Instrument Requirements

As shown in the use case diagram, we have 1 primary actor “operato r “and 4 secondary actors “printer “, “display “, “medical analyzer “and”database manager “.These secondary actors don't need to be physicaldevices and could actually be other software entities such as softwarecomponents. The behaviors for the system requirements are found in 1 ofthe 5 use cases.

When writing use cases, the goal of the text is in a readable formatthat could be written at different levels of formality. Writing toomuch detail can cause the use case to become some what too brittle.During the analysis phase of writing a use case, you should askyourself at what level should I write the use case?

A goal would be to decide whether this use case needs to providevalue to the user. By organizing the user goals into a hierarchy,resulting in the details unfolding as you progress through the usecase.

A use case structure consists of a several parts: description of itsgoal, a contractual statement of its assumptions and expectations in apre-conditions and post-conditions, respectively. A main successscenario that describes the sequence of events that result in the actorobtaining its successful goal. The final step is to define extensionsto the main scenario that describe alternate behavior or failurescenarios.

Some RUCD ground rules
Now this “rapid” use case syntax differs from the traditionalapproach to focus more on the events and less on its readability. Toapply this technique to the use cases, we need to have some groundrules (see Syntax Rules below )thatallowfor consistency across use cases and the authors.

“Rapid” UseCase Syntax Rules:

* Use Case names appear at thetop of the UseCase.

* If the Use Case is either anincluded orextended use case, the “<>” or<>”title should follow the Use Case name in a smaller font than the UseCase name .

* Use Case titles should be inblack and have alarger font than Alternate Flow titles and flows

* Use Case descriptions areoptional and they arein black italics.

* The Use Case should try toonly occupy a singlepage.

* In the body of the Use Caseabbreviations areacceptable and encourage.

* Pre-conditions andPost-conditions are optionaland they are in black normal font with allowed have a “>>” forpre-conditions and “<<" for post-conditions.

* The first step of the Use Casebasic flow itshould contain the trigger for this Use Case.

* All statements appear in bluenormal font,unless otherwise specified.

* Verbs that state the action tobe performedshould be in black bold font.

* External component namesshould be in greenbold .

* Messages being sent or receiveshould have boththe “sent” or “receive” word in green bold font and the message beingsent orreceive should be in blue underline font.

* All conditional statementsshould be capitalizedin black bold .

* Comments should be in “()”and have a greenitalic font.

* Included statements should bereduced to justthe included Use Case name with “<< >>” surrounding it ingoldbold font

* Any constants, such as “TRUE”or “FALSE”, “YES”or “NO”, etc. should be capitalized in dark yellow italic bold font

* Literals such as status ormessage should beplace in black italic bold font.

* Any Objects that is used inthe Use Case shouldbe in black normal font

* Alternate Flows names havelinks in the basicflow that should be in “[]” and should be in black bold font

* Alternate Flow titles shouldbe numbered and bein a larger font than flows but not larger than the Use Case title

Now this “rapid” use case syntax differs from the traditionalapproach to focus more on the events and less on its readability. Toapply this technique to the use cases, we need to have some groundrules (see Syntax Rules above )thatallowfor consistency across use cases and its authors.

These syntax rules could vary based upon your own unique projectenvironment constraints or circumstance. The rules listed above areones in which I found to be helpful in providing a consistent approach.

Applying the “rapid” use case syntax rules to the use casedescription found in Listing 1 above would now result in a new”rapid” use case outline description found in Listing 2 below.

As shown in the examples below, the new “rapid” use case descriptionin Listing 2 is very clearand has a code syntax style, which Ibelieves increases to the easiness and quickness of create or modifyingyour requirements.

Putting RUCD through its paces
As you examine the “rapid” use case approach shown above , the importantinteractions between the actors and other included/extended use casesare emphasized. For example, in Step 1 of the Main Success Scenario,this use case “Process User Reques t “,receives the start order message from the operator actor.

This is direct and to the point. The“< >” indicatesan included use casefor performing the system start and could be thought as a link to theStart System use case. The next sequence of steps choreographs thevarious messages to be sent to other actors at the appropriate highlevel allowing others to examine the interplay at ease without outgetting too bogged down in the details of the interchange.

In Step 6 of the main success scenario, the “[Re-run the exam] “inform us that at the conclusion of this step, the flow jumps to analternate behavior found in alternate flow “Re-run exam”. At the end ofthis alternate flow, in Step 2, the use case flow return to the mainsuccess scenario Step 5, indicated by the “< Rerun Exam>,where the use case continues the main flow.

Also note that whenever the use case wants to communicate to anactor, 3 elements must exist, the command (either “send” or “receive”)the message and the recipient of the message. For example in Step 6, ifthe print request is “YES” and the printer is in the “active” state,and then send a medical data message to printer actor.

As you gain experience with these rules or your own set of rulesthat fit your environment, you will appreciate how easy and quickly youcan follow the flow of a use case and how it interacts with other usecases.

I found that this “rapid” use case outline approach works well ininitial requirement development and helps detail the high levelinterfaces and interplay between actors and other use cases of asystem. Also, maintaining this “rapid” use case outline in concert withthe standard use cases, allows a quick way to lookup systemsrequirements in very large and/or complex systems.

I used Microsoft PowerPoint application to create my “rapid” usecase outline; however any advanced editor tool could be used. Theplacing these “rapid” use case outlines in PowerPoint allows me toeasily integrate them into other PowerPoint presentations.

I hope this technique allows you to create your own unique “rapid”use case outline that best fits your environment allowing to easily,rapidly and with clarity updating your system requirements beforedenoting many hours to implement what you and your customers want in asystem.

Matthew R. Curreri, P.E., is a leadsystem software engineer and has worked in the software industry forthe past 18 years having developed systems and software used in bothcommercial and military environments. He is a previous author for theEmbedded Systems Design Magazine. Matthew holds an MS in electricalengineering from Drexel University. He may be reached atmatthew.curreri@softcreators.com.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.