A New Look at Use Cases		Date	2019-07-01
		Tags

This is the sec­ond in a qua­si­-series of posts in which I moan about bits that I don’t like in SysM­L/UML. This time, I’m tak­ing a look at the use case di­a­gram and ar­gu­ing for a dif­fer­ent way of mod­el­ling the con­cept to the UML and SysML specs.

To be­gin our ex­plo­ration into how use cas­es, here are three de­f­i­n­i­tions of use case from around the in­ter­net:

A de­scrip­tion of the be­hav­ioral re­quire­ments of a sys­tem and its in­ter­ac­tion with a user. [1]

A de­scrip­tion of a po­ten­tial sce­nario in which a sys­tem re­ceives an ex­ter­nal re­quest (such as user in­put) and re­sponds to it. [2]

A list of ac­tions or event steps typ­i­cally defin­ing the in­ter­ac­tions be­tween a role (known in the Uni­fied Mod­el­ing Lan­guage (UML) as an ac­tor) and a sys­tem to achieve a goal [3]

Each of these de­f­i­n­i­tions de­scribe the use case as the sce­nario sur­round­ing the in­ter­a­tions be­tween ac­tors and the sys­tem we would like to de­sign. We could even in­ter­pret a use case as a con­tainer for an in­stance of the sys­tem un­der de­vel­op­ment and it’s ac­tors; a mi­cro­cosm of the uni­verse where the goal our de­sign will meet is the only thing that mat­ters.

Now look at the SysM­L/UML use case di­a­gram:

> An ex­am­ple of a UM­L/SysML use case di­a­gram.

The no­ta­tion of use cases sug­gests a rather dif­fer­ent in­ter­pre­ta­tion of the use case than the de­f­i­n­i­tions. The use cases are in­side the sys­tem bound­ary, sug­gest­ing that use cases are some­how con­tained in­side the sys­tem. Pos­si­bly as sys­tem be­hav­iours? To muddy the wa­ters fur­ther, the SysML spec­i­fi­ca­tion seems to agree with the other de­f­i­n­i­tions:

The use case di­a­gram de­scribes the us­age of a sys­tem (sub­ject) by its ac­tors (en­vi­ron­ment) to achieve a goal, that is re­al­ized by the sub­ject pro­vid­ing a set of ser­vices to se­lected ac­tors. The use case can also be viewed as func­tion­al­ity and/or ca­pa­bil­i­ties that are ac­com­plished through the in­ter­ac­tion be­tween the sub­ject and its ac­tors. [4]

An im­por­tant point to make about mod­el­ling lan­guages is that they are not just di­a­gram no­ta­tion. Each el­e­ment in a model ex­ists in an un­der­ly­ing on­tol­ogy with which di­a­grams (and other en­gi­neer­ing arte­facts) can be pro­duced. When we look at the un­der­ly­ing re­la­tion­ships be­tween the el­e­ments in this di­a­gram we don’t find much use­ful mean­ing. Ac­tors are re­lated to the use case with a sim­ple as­so­ci­a­tion. This de­notes that the ac­tors com­mu­ni­cate with the use case in some way. This does­n’t give us much to go on un­less we im­pose mean­ing that’s not in the spec­i­fi­ca­tion. The sys­tem bound­ary sim­ply has no re­la­tion to other el­e­ments in many mod­el­ling tools.

This can also man­i­fest as con­fu­sion when putting use cases in the mod­el­ling tool. Where do the use case el­e­ments live? In­side the block­/­class of the sys­tem un­der de­vel­op­ment? Gen­er­ally the use case analy­sis is done in a dif­fer­ent pack­age to the rest of the mod­el­ling. But this feels like a bit of a cop-out when we’re sup­posed to be mov­ing from a doc­u­men­t-based to a in­te­grated ar­chi­tec­ture-view based way of sytems en­gi­neer­ing.

So where did this di­a­gram come from? The clear­est an­swer that I can find is that the no­ta­tion and its mean­ings are relics from the birth of UML.

Use case analy­sis was de­vel­oped as one of the main ap­proaches to ob­jec­t-ori­ented soft­ware de­vel­op­ment in the 80s by Ivar Ja­cob­son. In fact, Ja­cob­son called his method Ob­jec­t-ori­ented soft­ware En­gi­neer­ing (OOSE). It was this method that in­tro­duced the stick men and bub­ble no­ta­tion. When Ja­cob­son was locked in a room at Ra­tio­nal soft­ware with Rum­baugh and Booch to make sure they came up with a uni­fied no­ta­tion for soft­ware, Ja­cob­son’s Ob­jec­tory no­ta­tion made it into the UML rel­a­tively un­scathed. Thank­ful­ly, Booch’s class no­ta­tion did­n’t make the fi­nal cut.

Mi­cro­cos­mic Use Cases

To be no part of any body, is to be noth­ing. John Donne

So what hap­pens if we rec­on­cile the SysM­L/UML use case with the in­ter­pre­ta­tion gleaned from the in­ter­net de­f­i­n­i­tions? In this sec­tion we’ll take a look at what hap­pens to use cases when we try to model the use case as a mi­cro­cosm that is com­posed of the ac­tors and a ver­sion of the sys­tem.

It be­comes clear that the as­so­ci­a­tion be­tween a use case and an ac­tor is now a com­po­si­tion re­la­tion­ship; ac­tors ex­ist and in­ter­act with our sys­tem within the scope of our use case. An­other odd se­man­tic that comes from this is that use cases must be com­posed of the sys­tem un­der de­vel­op­ment too. This turns the orig­i­nal no­ta­tion of use cases be­ing within a sys­tem bound­ary on its head. Be­low is an ex­am­ple block de­f­i­n­i­tion di­a­gram of the re­la­tion­ships to il­lus­trate the ad­vo­cated re­la­tion­ships.

> An il­lus­tra­tion of my sug­gested use of use case el­e­ments.

The se­man­tic el­e­gance of this way of rep­re­sent­ing use cases re­ally comes into its own when you rep­re­sent the in­ter­ac­tions in a use case with ac­tiv­i­ties or se­quences. In­ter­nal block di­a­grams can then be used to rep­re­sent a con­text di­a­gram show­ing in­ter­faces be­tween the in­stances of the ac­tors and sys­tem un­der de­vel­op­ment. All of the el­e­ments are neatly with­ing scope. The scope also ap­plies to swim­lanes in ac­tiv­i­ties and life­lines in se­quences. A block de­f­i­n­i­tion di­a­gram can be used to il­lus­trate an overview of the use cases and the ac­tors at the top level if re­quired.

In my own head, I like to imag­ine the use cases as the “main func­tions” of a mod­el. Use cases form that top level en­try point to a model where the in­ter­preter can “run” the over­all be­hav­iour, drilling down through the com­po­si­tion re­la­tion­ships if they would like to un­der­stand the lower lev­els of ab­strac­tion.

I hope that this post and the last post in­spire the sys­tems en­gi­neer­ing com­mu­nity to cri­tique the UM­L/SysML lan­guages in­stead of tak­ing them for grant­ed. In many ways, UML and SysML are held in the 90’s “Java/C#/­Clas­si­cal OOP is the zenith of pro­gram­ming” mind­set. As the soft­ware world boldly steps into the new par­a­digm of func­tional pro­gram­ming with Haskell, Elm, Kotlin, Scala &c. I feel the time is right for sys­tems en­gi­neers to shed the trends of the 90s too¹. In a fu­ture post, I will show how pat­terns from func­tional pro­gram­ming can be used to de­sign for fail­ure in ac­tiv­ity di­a­grams.

Ref­er­ences

[1] ISO/IEC/IEEE. 2011. Sys­tems and soft­ware en­gi­neer­ing: De­vel­op­ing user doc­u­men­ta­tion in an ag­ile en­vi­ron­ment. Geneva, Switzer­land: In­ter­na­tional Or­ga­ni­za­tion for Stan­dard­iza­tion (ISO)/In­ter­na­tional Elec­trotech­ni­cal Com­mis­sion (IEC)/ In­sti­tute of Elec­tri­cal and Elec­tron­ics En­gi­neers (IEEE). ISO/IEC/IEEE 26515:2011.

[2] From Wik­tionary, Cre­ative Com­mons At­tri­bu­tion/Share-A­like Li­cense.

[3] http­s://en.wikipedi­a.org/wik­i/Use_­case

[4] OMG 2015 OMG Sys­tems Mod­el­ing Lan­guage (OMG SysM­L™) Ver­sion 1.4 http://www.omg.org/spec/SysM­L/1.4/

---

1. Af­ter all, did any­one re­ally en­joy trance with­out the chem­i­cal en­cour­age­ment?

Site proudly generated by Hakyll | Theme based on Oskar Wickström's Monospace Web.