En modell som syftar till en ändringsvänlig arkitektur tar hänsyn till dels struktur (vilka begrepp är centrala i domänen och hur de är relaterade), dels beteende (vad ska systemet/systemen göra). Det innebär väl avvägda delar ”domain driven” och ”behavior driven”
Tendensen att hålla fast vid gammalt beprövat ”såhär har vi
alltid gjort” följer gärna nivån i hierarkin. Ju högre upp i en organisation
man modellerar, ju äldre modelleringstekniker används. De må vara helt up to date
på programnivån, men uppe i EA/EITA kan man få en och annan nostalgitrip till
70-talet, på gott och ont.
Det goda med ER-diagram, datamodeller, och så småningom CA ERwin
var insikten att redundans kostar och ska förebyggas - ett angreppssätt som
spreds på 70-talet av Codd & Date (relationsalgebra med normalformer, och
så småningom SQL-standarden).
Det mindre goda var att insikten stannade vid strukturering
av data. Företagen städade successivt upp just där, men inte på
programbiblioteken och inte heller i affärsprocesserna. Där fick dubblering
florera vidare - och därmed även dubbelarbetet, särskilt i samband med förändringar.
ER- och Datamodellernas naturliga begränsning är just deras
fokus på data (förutom på vissa typer av regler, men inte alla). De
passar inte för att modellera beteende/förlopp som t ex tjänster/operationer,
livscykler, scenarion, affärsprocesser, eller människa-dator interaktion.
Ibland har man kompletterat dem med användningsfall (en bra interaktionsbeskrivning)
men i övrigt ändå nöjt sig med underförstått CRUD-beteende dvs ”dum”
dataskyffling där systemet inte ”ser” riktiga affärshändelser utan bara
mekaniskt ”Create – Retrieve - Update – Delete” så att den egentliga
verksamhetslogiken förblev utspridd i lathundar och hjärnor. Det fick
återverkningar uppåt på affärsprocesserna, där man senare med BPM på 1990- och
2000-talen upptäckte åtskilliga inkonsekvenser, dubbelarbete, överlapp, och halvmanuell
improvisation.
Domän- och Objektmodeller i UML ligger alltså bra till som
länk för att få med beteende hela vägen i modellerna, från BPM:s affärsprocess
(ett förlopp ”från ax till limpa”) via senioranvändarens användningsfall
(systems beteenden mot omgivningen) till arkitektens EITA som väger ihop data och
beteende (verksamhetsanpassade tjänster/”semantiska operationer”, tvärtemot
CRUD).
Det är dessutom enklare att härleda eller generera en
Datamodell ur ett Klassdiagram i UML än tvärtom, trots att det innebär mer än
bara en menyrad i en UML-ritare (om man gått in för enbart Datamodellering så finns
f ö inte heller någon beteendemodell att klicka på).
Växelverkan mellan struktur och beteende påverkar både
modelleringsstilen och arkitekturen. Det som lutar åt en entitet i
ER-modellering behöver inte bli en klass i en UML-modell. Ett exempel på tjänst/operation
(dvs beteende) i affärslogikskiktet som förenklar strukturen är en webbutik där
varje klick på ”Betala” bara skickar iväg ett anrop på en fristående förmedlare
av säkra betalningar. I UML-modellen kan ”Betala” bli en operation i stället, givet
naturligtvis transaktionslogg och bekräftelse från betalningsförmedlaren till köparen
och butiken (förresten, varken Datainspektionen eller kunderna skulle bli
gladare av att data om bankkort hamnade i en massa webbutikers datamodeller och
databaser). Ett omvänt exempel, där dataskiktet märkbart förenklar
beteendemodellen, är färdig nästlad SQL eller OLAP-hjälpmedel i databaser. Klarar
de komplexa svar (views) på vanliga anrop så kan många Sekvensdiagram i UML
visa dem som bara 1 komponent - i stället för kanske 10 tabeller och interna
loopar som är inkapslade i dem (under ”huven”, av SQL-motorn eller OLAP-paketet).
Fler tillfällen att vrida och vända på sambandet mellan
struktur och beteende får man under övningar på modelleringskurserna hos
Informator. Välkommen.
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:
och även Informators fullsatta Frukostseminarium om användningsfall.
/Milan Kratochvil
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.