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.
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.
(CQRS ingår i kursen Software Architecture, T20112)
Övriga kurser på Informator inom CQRS:
Övriga kurser på Informator inom CQRS:
Modern Business Applications with DDD on CQRS
Skicka en kommentar
Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.