This contribution to the debate regards standard UML in Use Case modeling.

A Brief Summary in English:

Standards: alive & well !

There are many ways of getting it wrong in Use Case modeling (“misuse cases”). UCs are a good tool of requirement specification, provided we use them in an appropriate place and provided a wise tradeoff between the semi-formal, graphical, UC structure (containing nice distinctions, starting with UML ver. 1.3) and the detailed bullet lists of each use case. Neglecting the former may bring about doubled effort later, in dialog design, in doc and in maintenance whereas neglecting the latter provides a rather weak basis for system design (with the important functional requirements “not all there”). In other words, a thousand thanks for standard UML. As an illustration, do read M. A. Jackson’s Problem Frames (from 2001): several great hints and problem-scoping patterns for the analyst - which I feel I absorb despite of the notations (rather than because of); a reminder of the pre-UML years when a consultant was more or less supposed to swap brains from project to project, in a plenty of proprietary notations and terminologies.

No matter a heavyweight or lightweight process, it’s practical to distinguish between the business level (business-event centric) and the system level (system-boundary-event centric, i.e. more granular) of use case models. Providing the right level of detail to the right stakeholder saves time and misunderstanding. In finance, administration or business systems, it’s important to be aware of the strengths and limitations of each modeling technique, including those of use cases. In general, trying several ways (views of the business) is worthwhile, pushing through the most rewarding one – be it UCs or not (see UML Xtra Light, Cambridge University Press, www.wet-liquids.com ). If the system-to-be isn’t especially interactive then there is an obvious risk in building for instance, your project schedule on the UC model only. With some other systems, you might be well off with just a couple of parameterized UCs to avoid the "wallpaper problem" (not standard at the moment, but probably in UML ver 2.0 complete level).

Published in Swedish by the IDG in Computer Sweden, debate page, http://computersweden.idg.se/, February 26^th, 2003:

Standarderna Lever !

I CS den 15 januari skriver Peter Tallungs om fallgroparna i användningsfallsmodellering (Användningsfall - kravarbetarnas frälsning). I egenskap av praktiker lyfter han fram Agile-rörelsen (Cockburn m fl) mer än "tunga" processer. Det finns säkert tusen och ett sätt att skriva "oanvändningsfall" ("misuse cases") och Peter har rätt i att verkligheten oftast överträffar fantasin.

Som han skrivit i CS före Jullovet, har användningsfall räddat många kravspecar från att i stället ligga och samla damm. I hans senaste, kompakta, artikel kan läsaren få intrycket att de grafiska, halvformella delarna är mindre värda än punktlistorna som beskriver tågordningen inom varje användningsfall. Men det tror jag knappast Peter menar, man behöver snarare en väl fungerande balans mellan dem två. Slarvar man över den grafiska modellen och relationerna mellan användningsfall (som from. UML version 1.3 är mycket nyansrika) så riskerar man att oavsiktligt skapa en hel del dubbelarbete senare, i exempelvis dialogdesign, och att dessutom dra på sig en dubbelunderhållsbörda i dokumentationen. Slarvar man å andra sidan över punktlistorna så ger man designern klena underlag eftersom en del viktiga funktionella krav på systemet inte kommer med. Alltså tack och lov för standard UML; läs gärna, som illustration, min f.d. arbetsgivare Michael A. Jacksons senaste bok Problem Frames - Analyzing & Structuring SW Development Problems (2001) som innehåller ett antal utmärkta knep och mönster för analytikern - vilka man tar till sig trots notationen snarare än på grund av, som påminnelse om hur man före UML-tiden ständigt fick "byta hjärna" (i en uppsjö av olika notationer och terminologier).

Oavsett om man följer Rup eller en lättviktsmetod så är det klokt att för både utvecklarnas och beställarnas skull skilja på verksamhetsnivå och teknisk nivå ("dialognivå") i användningsfall. På verksamhetsnivån är det främst intressant ATT vissa externa affärshändelser (transaktioner, signaler osv) skall tas om hand av det blivande systemet och att det finns mål och mening (affärsvärde) med detta. På den tekniska nivån är det intressant HUR, dvs att steg för steg beskriva dialoger med användare eller externa system ("aktörer"). Man spar tid och missförstånd på att ge rätt detaljnivå till rätt målgrupp.

Något som sällan nämns i samband med användningsfall är vilka typer av tillämpningar de är lämpliga/olämpliga för, i synnerhet inom finans eller administrativa system. Enklaste analysrådet för praktikern är att prova flera vägar och att satsa mest modelleringstid där det "lossnar": e-vyn dvs användningsfall, processvyn eller kunskapsvyn/strukturvyn (mer om styrkor och begränsningar se i min bok UML Xtra Light, Cambridge University Press). I system som har för lite interaktion med omvärlden är det riskfyllt att exempelvis basera projektplanen på enbart användningsfall. I andra system där interaktionen är en mängd små variationer på samma tema är det praktiskt att bara arbeta med ett eller ett par parametriserade användningsfall (för att undvika de "tapetproblem" Peters artikel nuddar vid), det är inte standard idag men väl i den kommande UML versionen (2.0, på "kompletta" nivån av standarden - complete) - även standarder utvecklas.

Milan Kratochvil, konsult och UML-utbildare, Kiseldalens

Back, Kiseldalens Top Page