Agil modellering, kravkommunikation, Påskbord, smörgåsbord... Vad är lagom?

Min gästblogg i september, om UML-standardens femtonårsdag och om att förenkla för att maximera nyttan med modellering, nämnde bl a väldefinierad syntax. Entydighet är knappast något större hinder när man använder UML-diagram som mindmap i kravkommunikation med icke-tekniker. Snarare än precision kan ”notation bloat” bli ett.

I min UML-bok (länk nedan) jämför vi det med att överäta från ett smörgåsbord: nyttan per extra tugga är nära noll, det tar dessutom extra tid, och kan straffa sig i längden. Att OMG dukat fram 14 diagramtyper i modelleringsstandarden UML (bild) betyder inte att alla projekt ska svälja allt med hår och hull. Agil modellering väljer med eftertanke bland de 14, och prioriterar tydlig kommunikation utan missförstånd. Det viktiga är att ha projektets uppdrag i fokus, att snabbt ta fram få men ”rätt” diagram (informativa, kompakta, korrekta, ändamålsenliga).

Vilka av de 14 bör alltid ingå?
Det finns lika många svar som roller, produktfamiljer, eller applikationsområden. Michael A. Jackson (min forne arbetsgivare) kategoriserade applikationsområden i ett antal Problem Frames, som t ex operatörs- och övervakningsstöd, editorer (för text, bild, presentationer), styrsystem och automation, informationssystem, fil- och dataomvandling, osv.
När det klarnat vilket/vilka ”frames” som kommer att dominera projektet är det lätt att välja bland både diagram och metoder/processer/arbetssätt. I agil modellering är det syftet som avgör. I den vanliga jämförelsen med hus (där olika ritningar visar grund, byggnad, VVS, el, tele, bredband osv) fungerar Problem Frames även som arkitekturgrund. I en blivande ishall eller gym behöver man lyfta fram andra saker än i en villa, och på samma sätt blir arkitekturen för ett processtyrningssystem olik en editor.

Lika viktig är anpassning till mottagaren och situationen. Ett litet axplock från tidigare kunder där helt olika saker hamnat i fokus: arkitektur för ärendehandläggning (med event sourcing, pga strikta myndighetskrav på diarieföring), modellering av mjukvara för bilar, och ett grafiskt UML-baserat utbildningshjälpmedel för inskolning av nyanställda tjänstemän hos en storkoncern over there (visualiserar hur olika typer av ärenden passerar genom koncernens komplexa systemportfölj – för att förankra arkitekturen i organisationen). Alla tre applikationerna var ju IT och UML, men naturligtvis blev modellerna helt olika och började med var sin (olika) diagramtyp som grund.  

”Lagom” i modellering är lätt att orda om men sådär lagom lätt att pricka in för projektet. I det ena träsket lurar skakig arkitektur och luddiga krav med stort utrymme för dyra feltolkningar. I det andra lurar TAGRI (They Aren't Gonna Read It) och en marginalkostnad som överstiger marginalnyttan. Scott Ambler (Ambysoft, tidigare IBM Canada) använder fem kriterier för lagom bra modeller: (1) verkningsfulla/anpassade till mottagaren, (2) ändamålsenliga i en given situation, (3) av tillräcklig kvalitet, (4) ändras och uppdateras när det behövs, (5) färdiga tidigare än man trott.

Oftast landar jag på 3 till 6 diagramtyper, aldrig på 14 (”you can still build significantly complex systems using only three diagrams” - som RT-UML gurun Bruce Powel Douglass uttryckt det).

Nästa gallringsomgång gäller innehållet – dels att delar som inte tas med i modellen verkligen är irrelevanta, dels att rätt saker hamnar i rätt diagram, och dels att var sak modelleras (enbart) på sin plats i modellen (”separation of concerns”). Detta för att slippa splittra fokus med ”too much to see” och för att undvika dubbelarbete – i nuet, i kommande iterationer, i nya versioner osv. Även den här gallringen kräver eftertanke. Det finns många exempel på överlapp, redundans (”var sak på sin uppsjö av platser”) och onödigt dubbelarbete som hämmar användningen av modeller.

Summan av detta leder in på strukturen för en agil modelleringskurs. Den bör använda ett smalt urval av diagram, visa var sak på sin plats, visa hur UML-diagrammen hänger ihop och kompletterar varandra i en modell, och lära ut notation (”alfabet” och ”ordförråd”) invävd i modellering (”skrivstilar”) - med andra ord, välkommen på kurs hos Informator (som tänkt på ”valuta för modelleringspengarna”, så kurserna utgår från praktisk användning och innehåller en hel del övningar).

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, krav, analys och design. Håller f.n. kurser i Arkitektur, i modellering (T2715, T2716), och (februari 2013) även Informators fullsatta Frukostseminarium om användningsfall.

Läs mer

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).

Läs mer

Användningsfall under CQRS, del 2: Parametrisering ger flexibla användningsfall (gör inte idag vad du kan skjuta upp till i morgon)

Mitt förra inlägg här konstaterade att parametrisering är (i likhet med ordspråksparentesen ovan) en konsekvens av flexibilitetstrenden i affärsprocesserna: late binding i vid bemärkelse, configuration agility, Q2O / C2O.

I Growing Modular (Springer, 2005) hårddrog jag skillnaden i ett verklighetsbaserat exempel med användargränssnitt, där ett statiskt alternativ efter ”skolboken” landade på 2550 klasser efter någon enstaka uppgradering, medan parameteralternativet låg kvar på 1 klass (plus två ytterligare parametrar).

I ”Q-”användningsfall under CQRS brukar det förhållandet landa ”bara” någonstans mellan 5:1 och 50:1 i och med att de flesta ju redan försökt slå ihop flera frågedialoger till en gemensam, enda sedan Ivar Jacobsons användningsfall blev standard (i UML 1 för15 år sedan), så det är mer intressant att räknar ett par kravändringar framåt. En (1) flexibel ”variantkläckningsmaskin” (1 Fråga, som matas med parametrar, blir bara 1 ellips och 1 textdokument med punkter) ersätter även här ett otal i förväg ”cementerade” varianter, ungefär som en parametriserad klass gjort alltsedan UML 1 (1 Frågeformulär, med parametrar blev bara 1 klass)

Ett liknande exempel på flera varianter av ”Visa X” (genom gemensamt fönster/webbformulär och dialog) är resesidor på webben: välj vilka flygbolag, tidsperiod, destination osv du vill se, klicka, få upp svaret färdigfiltrerat och sorterat efter angivna önskemål.

Vad slags ”godis” som trillar ur maskinen kommer alltså att variera efter vad användaren ”kastat in” som parameterval i sitt frågefönter/webbformulär:

Informator betonar valuta för modelleringspengarna: arkitektur, agil modellering med få men informationsrika bilder, och hur man använder de allra viktigaste bland UMLs 14 olika diagram. Där har CQRS, parametrisering, och agilitet en given plats i flexibla företag, även om dessa tekniker ibland låter just ”tekniskt” för projektets intressenter.

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, analys och design.

Håller f.n. kurserna i modellering med UML, där Användningsfall ingår (T2715, T2716).

(CQRS ingår i kursen Software Architecture, T20112)

Övriga kurser på Informator inom CQRS:

Modern Business Applications with DDD on CQRS

Läs mer

Hur modern arkitektur gör jobbet enklare, del 1: CQRS och Användningsfall

Arkitektur ger smidigare och säkrare ändringar, vilket underlättar ett agilt iterativt arbetssätt. Drivkraften är samma som bakom Agile och Lean: att maximera flexibilitet och minimera upprepat/onödigt arbete. Omvänt, svag arkitektur ger svag modularitet, vilket leder till "promiseware" och ”överraskningar” under utvecklingsprojekten (ovanpå extratimmar i kravställandet). 

Ett exempel är Command-Query Responsibility Segregation (CQRS) som en beprövad princip i arkitektur, och användningsfall (Use Cases) som en beprövad teknik i kravfångst för applikationer.

  

CQRS delar upp domänmodellen i två olika, en skräddarsydd för uppdateringar och en för frågor. Att försöka få bägge två att samsas i en gemensam modell kostade oftast utvecklingstimmar, sämre prestanda och skalbarhet, mm. En påkostad flerskiktsarkitektur (n-tier) brukar lämpa sig för uppdateringar, och en enkel tvåskikts (2-tier) för frågor/sökningar.

Användningsfall beskriver hur systemet (som projektet kommer att bygga) ska interagera med olika aktörer i sin omgivning, inte minst hur dialogen med slutanvändare ska gå till i viktiga scenarion, steg för steg. UML:s Användningsfallsdiagram är en grafisk innehållsförteckning över textdokument (som i sin tur brukar struktureras i punktlistor).

Det handlar om interaktivitet, inte om en teknisk lösning. Användningsfall är beprövade inom IT-krav, men har även använts inom säkerhet i USA för att beskriva t ex olika hotbilder (hack, dataspionage, osv). På sistone har de också börjat uppmärksammas av FoU-avdelningar och av innovationsforskare kring bl a Harvard.

Påkostade användningsfall skräddarsydda per händelse (som lägg order, expediera order, betala order...) lämpar sig för värdeskapande affärshändelser (som i regel triggar uppdateringar inne i systemet), och ett förenklat gemensamt ”mall-användningsfall” lämpar sig för triviala händelser där dialogen är i stora drag samma överallt (som Fråga X, Sök Y, Hitta Z, eller Visa sorterad lista över XYZ som uppfyller villkoret...)

I UML Xtra Light – How to Specify Your SW Requirements beskrev jag parametriserade användningsfall lite innan standarden var klar. Cockburn hade då redan publicerat de vanligaste parametrarna för sina “Find” Use Cases: Sorting details, Searchable qualities, Display details (där europeiska företag bör lägga till en underavdelning ”Country details” såsom språk, valutatecken, datumformat, decimalavskiljare). UML 2 standarden fick syntaxbitarna att falla på plats. Parametrisering gäller numera för Operationer, Paket - och inte minst för Classifier som är ett brett samlingsbegrepp för bl a Klasser, Komponenter, Aktörer, och även Användningsfall.

De som använt parametriserade klasser i någon form (template i UML, C++ mm, generic i Java, C#, Ada mm), eller använt OLAP-uttryck med parametrar i stället för fasta attributnamn och konstanter (baserat på Microsofts MDX resp XMLA:s mdXML), inser lätt att under CQRS ger triviala händelser tillfälle till en liknande effektivisering redan i användningsfall...

Den som har sina rötter i mer verksamhet än i IT kan hellre relatera detta till flexibilitetstrenden i affärsprocesserna (late binding i vid bemärkelse, configuration agility, Quote2Order, osv.) där processen inte spikar något i förväg så länge ingen lag eller naturlag kräver det. Parametrisering är konsekvensen, från snabbt ställbara verktygsmaskiner och generisk CAD i fordonsindustrin till klasser och användningsfall i IT.

Mer om parametrisering i användningsfall följer.

/Milan Kratochvil

konsult, Kiseldalen.com

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

Samarbetar med Informator sedan våren 1996 inom modellering, UML, analys och design.

Håller f.n. kurserna i modellering med UML, där Användningsfall ingår (T2715, T2716).

(CQRS ingår i kursen Software Architecture, T20112)

Övriga kurser på Informator inom CQRS:

Modern Business Applications with DDD on CQRS

Läs mer