{"id":25268,"date":"2013-03-20T00:00:00","date_gmt":"2024-09-13T08:48:30","guid":{"rendered":"https:\/\/wordpress-583806-4798031.cloudwaysapps.com\/modellering-i-enterprise-it-arkitektur-mer-an-datamodell-och-flode\/"},"modified":"2024-11-15T16:22:55","modified_gmt":"2024-11-15T15:22:55","slug":"modellering-i-enterprise-it-arkitektur-mer-an-datamodell-och-flode","status":"publish","type":"post","link":"https:\/\/informator.se\/en\/modellering-i-enterprise-it-arkitektur-mer-an-datamodell-och-flode\/","title":{"rendered":"Modellering i enterprise-IT arkitektur: mer \u00e4n datamodell och fl\u00f6de"},"content":{"rendered":"


En modell som syftar till en \u00e4ndringsv\u00e4nlig arkitektur tar h\u00e4nsyn till dels struktur (vilka begrepp \u00e4r centrala i dom\u00e4nen och hur de \u00e4r relaterade), dels beteende (vad ska systemet\/systemen g\u00f6ra). Det inneb\u00e4r v\u00e4l avv\u00e4gda delar \u201ddomain driven\u201d och \u201dbehavior driven\u201d <\/p>\n

<\/div>\n
Tendensen att h\u00e5lla fast vid gammalt bepr\u00f6vat \u201ds\u00e5h\u00e4r har vi alltid gjort\u201d f\u00f6ljer g\u00e4rna niv\u00e5n i hierarkin. Ju h\u00f6gre upp i en organisation man modellerar, ju \u00e4ldre modelleringstekniker anv\u00e4nds. De m\u00e5 vara helt up to date p\u00e5 programniv\u00e5n, men uppe i EA\/EITA kan man f\u00e5 en och annan nostalgitrip till 70-talet, p\u00e5 gott och ont.<\/div>\n
<\/div>\n
Det goda med ER-diagram, datamodeller, och s\u00e5 sm\u00e5ningom CA ERwin var insikten att redundans kostar och ska f\u00f6rebyggas – ett angreppss\u00e4tt som spreds p\u00e5 70-talet av Codd & Date (relationsalgebra med normalformer, och s\u00e5 sm\u00e5ningom SQL-standarden).<\/div>\n
<\/div>\n
Det mindre goda var att insikten stannade vid strukturering av data. F\u00f6retagen st\u00e4dade successivt upp just d\u00e4r, men inte p\u00e5 programbiblioteken och inte heller i aff\u00e4rsprocesserna. D\u00e4r fick dubblering florera vidare – och d\u00e4rmed \u00e4ven dubbelarbetet, s\u00e4rskilt i samband med f\u00f6r\u00e4ndringar.<\/div>\n
<\/div>\n
ER- och Datamodellernas naturliga begr\u00e4nsning \u00e4r just deras fokus p\u00e5 data (f\u00f6rutom p\u00e5 vissa<\/i> typer av regler, men inte alla). De passar inte f\u00f6r att modellera beteende\/f\u00f6rlopp som t ex tj\u00e4nster\/operationer, livscykler, scenarion, aff\u00e4rsprocesser, eller m\u00e4nniska-dator interaktion. <\/div>\n
<\/div>\n
Ibland har man kompletterat dem med anv\u00e4ndningsfall (en bra interaktionsbeskrivning) men i \u00f6vrigt \u00e4nd\u00e5 n\u00f6jt sig med underf\u00f6rst\u00e5tt CRUD-beteende dvs \u201ddum\u201d dataskyffling d\u00e4r systemet inte \u201dser\u201d riktiga aff\u00e4rsh\u00e4ndelser utan bara mekaniskt \u201dCreate \u2013 Retrieve – Update \u2013 Delete\u201d s\u00e5 att den egentliga verksamhetslogiken f\u00f6rblev utspridd i lathundar och hj\u00e4rnor. Det fick \u00e5terverkningar upp\u00e5t p\u00e5 aff\u00e4rsprocesserna, d\u00e4r man senare med BPM p\u00e5 1990- och 2000-talen uppt\u00e4ckte \u00e5tskilliga inkonsekvenser, dubbelarbete, \u00f6verlapp, och halvmanuell improvisation.<\/div>\n
<\/div>\n
Dom\u00e4n- och Objektmodeller i UML ligger allts\u00e5 bra till som l\u00e4nk f\u00f6r att f\u00e5 med beteende hela v\u00e4gen i modellerna, fr\u00e5n BPM:s aff\u00e4rsprocess (ett f\u00f6rlopp \u201dfr\u00e5n ax till limpa\u201d) via senioranv\u00e4ndarens anv\u00e4ndningsfall (systems beteenden mot omgivningen) till arkitektens EITA som v\u00e4ger ihop data och<\/i>beteende (verksamhetsanpassade tj\u00e4nster\/\u201dsemantiska operationer\u201d, tv\u00e4rtemot CRUD).<\/div>\n
<\/div>\n
Det \u00e4r dessutom enklare att h\u00e4rleda eller generera en Datamodell ur ett Klassdiagram i UML \u00e4n tv\u00e4rtom, trots att det inneb\u00e4r mer \u00e4n bara en menyrad i en UML-ritare (om man g\u00e5tt in f\u00f6r enbart Datamodellering s\u00e5 finns f \u00f6 inte heller n\u00e5gon beteendemodell att klicka p\u00e5).<\/div>\n
<\/div>\n
V\u00e4xelverkan mellan struktur och beteende p\u00e5verkar b\u00e5de modelleringsstilen och arkitekturen. Det som lutar \u00e5t en entitet i ER-modellering beh\u00f6ver inte bli en klass i en UML-modell. Ett exempel p\u00e5 tj\u00e4nst\/operation (dvs beteende) i aff\u00e4rslogikskiktet som f\u00f6renklar strukturen \u00e4r en webbutik d\u00e4r varje klick p\u00e5 \u201dBetala\u201d bara skickar iv\u00e4g ett anrop p\u00e5 en frist\u00e5ende f\u00f6rmedlare av s\u00e4kra betalningar. I UML-modellen kan \u201dBetala\u201d bli en operation i st\u00e4llet, givet naturligtvis transaktionslogg och bekr\u00e4ftelse fr\u00e5n betalningsf\u00f6rmedlaren till k\u00f6paren och butiken (f\u00f6rresten, varken Datainspektionen eller kunderna skulle bli gladare av att data om bankkort hamnade i en massa webbutikers datamodeller och databaser). Ett omv\u00e4nt exempel, d\u00e4r dataskiktet m\u00e4rkbart f\u00f6renklar beteendemodellen, \u00e4r f\u00e4rdig n\u00e4stlad SQL eller OLAP-hj\u00e4lpmedel i databaser. Klarar de komplexa svar (views) p\u00e5 vanliga anrop s\u00e5 kan m\u00e5nga Sekvensdiagram i UML visa dem som bara 1 komponent – i st\u00e4llet f\u00f6r kanske 10 tabeller och interna loopar som \u00e4r inkapslade i dem (under \u201dhuven\u201d, av SQL-motorn eller OLAP-paketet).   <\/span>   <\/span>   <\/span> <\/span><\/div>\n
<\/div>\n
Fler tillf\u00e4llen att vrida och v\u00e4nda p\u00e5 sambandet mellan struktur och beteende f\u00e5r man under \u00f6vningar p\u00e5 modelleringskurserna hos Informator. V\u00e4lkommen.<\/div>\n
<\/div>\n
Milan Kratochvil<\/span><\/span><\/a><\/div>\n
konsult, Kiseldalen.com<\/span><\/span><\/a><\/div>\n
UML 2 Professional, OCUP<\/span><\/span><\/a> Advanced Level (certifikatniv\u00e5 3 av 3)<\/div>\n
Huvudf\u00f6rfattare UML Xtra Light \u2013 How to Specify Your SW Requirements<\/span><\/span><\/span><\/a><\/span><\/div>\n
<\/div>\n
Samarbetar med Informator sedan v\u00e5ren 1996 inom modellering, UML, krav, analys och design. H\u00e5ller f.n. kurser i Arkitektur, i modellering:<\/div>\n
<\/div>\n
T2715,  <\/span><\/span><\/a><\/b>Agile Modellering med UML<\/span><\/a><\/div>\n

<\/p>\n

<\/span><\/span><\/a><\/b>T2716,  <\/span><\/span><\/a><\/b>Avancerad objektorientering med UML<\/a><\/div>\n
och \u00e4ven Informators fullsatta Frukostseminarium<\/span><\/span><\/a> om anv\u00e4ndningsfall.<\/div>\n
<\/div>\n
\/Milan Kratochvil <\/div>\n

<\/span><\/span><\/p>\n

\u00a0<\/span><\/span><\/h4>\n

<\/span><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

En modell som syftar till en \u00e4ndringsv\u00e4nlig arkitektur tar h\u00e4nsyn till dels struktur (vilka begrepp \u00e4r centrala i dom\u00e4nen och hur de \u00e4r relaterade), dels beteende (vad ska systemet\/systemen g\u00f6ra). Det inneb\u00e4r v\u00e4l avv\u00e4gda delar \u201ddomain driven\u201d och \u201dbehavior driven\u201d Tendensen att h\u00e5lla fast vid gammalt bepr\u00f6vat \u201ds\u00e5h\u00e4r har vi alltid gjort\u201d f\u00f6ljer g\u00e4rna niv\u00e5n […]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[570,922,572],"tags":[],"class_list":["post-25268","post","type-post","status-publish","format-standard","hentry","category-blogg","category-blogi","category-it-arkitektur"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t