Produktarkitektur: Användningsfall 2.0 - och varför glasögon är olika

 Use Case 2.0 ger i skrivande stund 174 miljoner träffar i Google. Use Case ger över 1 miljard (inberäknat de managementkonsulter, business analysts, eller verksamhetsarkitekter Over There som systematiskt förväxlar Use Case med ”praktikfall” eller ”exempel på tillämpning” och därmed får gratisklick)...

Användningsfall ingår sedan länge i både modellering och grundläggande arkitektur hos Informator, och många som gått båda kurserna har redan märkt att de handlar om två olika synvinklar/glasögon - i samma sorts UML-diagram resp tillhörande punktlistor.

Skillnaden följer av flexibilitet, då man lätt anpassar tekniken till sammanhanget för att underlätta kommunikation inom och kring projekten. Use Case 2.0 handlar inte om UML-versionen utan om en utvidgning av Användningsfall till flera områden och på anpassning till hur de vanligtvis har använts.

Aktörerna i Användningsfallsdiagrammet kan, sedan begynnelsen, vara människor (roller) eller andra system/subsystem. Därtill har Use Case 2.0 blivit tydligare med just infrastruktur- (eller ”arkitektur-”)Användningsfall, där synvinkeln går på tvärs mot ”applikationsglasögonens”: ju mer utvecklad och skiktad arkitektur desto fler icke-funktionella krav (NFR) hanteras av en färdig infrastruktur, samma för praktiskt taget alla applikationer (dvs. för dem ”vanliga” Användningsfallen).

Exempel på sådana krav är säkerhet, transaktionsintegritet, datalagring och objekt-RDB mappning (ORM). De leder inte till en ny applikation utan till en mer utbyggd plattform som fungerar som infrastruktur (”en smartare miljö”, lite förenklat) för alla applikationer.

Ett infrastrukturanvändningsfall kan t ex handla om hur en typisk transaktion hanteras, skikt för skikt, från GUI och hela vägen ner till databasen, och hur ev. avbrott, lås, eller logg hanteras – en gång för alla. Applikations-Användningsfall (och -utvecklare) slipper sedan upprepa allt detta, och ändringar eller vidareutveckling görs på bara ett ställe. Det är alltså helt i sin ordning med så pass olika ”glasögon” i Användningsfall 2.0.

Vad är det då som leder till tonvikt på Användningsfall, kontra på andra modelleringstekniker? I agil modellering är det, utöver systemets samspel med omvärlden (se min förra blogg), främst applikationsområde, modularitet/komponentifiering, och inte minst projektmedlemmarnas och intressenternas respektive bakgrund. Detta har jag skrivit om i en jämförelse mellan komponentanvändningsfall och sekvensdiagram, i den här tidigare artikeln på TechTarget.com (USA) - utifrån Informators agile-filosofi ”valuta för modelleringspengarna” (få men informativa dokument).

Trots att du tack vare Informatorbloggen nu får minst 174 000 001 J träffar i Google, så är också Användningsfall 2.0 en teknik av flera som går ut på smidigare kommunikation mellan olika roller i, kring, och inte minst efter projektet.

Milan Kratochvil

konsult, Kiseldalen.com

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Huvudförfattare UML Xtra Light – How to Specify Your SW Requirements

Samarbetar med Informator sedan våren 1996 inom modellering, UML, patterns, analys och design. Håller f.n. kurser i arkitektur, och i modellering där Användningsfall ingår (T2715, T2716).