{"id":25249,"date":"2013-10-21T00:00:00","date_gmt":"2024-09-13T08:48:29","guid":{"rendered":"https:\/\/wordpress-583806-4798031.cloudwaysapps.com\/agil-arkitekturmodellering-med-uml-principlosningar-gar-fore-detaljer\/"},"modified":"2024-11-15T16:22:51","modified_gmt":"2024-11-15T15:22:51","slug":"agil-arkitekturmodellering-med-uml-principlosningar-gar-fore-detaljer","status":"publish","type":"post","link":"https:\/\/informator.se\/en\/agil-arkitekturmodellering-med-uml-principlosningar-gar-fore-detaljer\/","title":{"rendered":"Agil arkitekturmodellering med UML: principl\u00f6sningar g\u00e5r f\u00f6re detaljer."},"content":{"rendered":"

<\/p>\n

Mitt arkitekturinl\u00e4gg<\/a><\/span> i mars p\u00e5pekade att dataskiktet ofta f\u00f6renklar beteendemodellen, och att f\u00e4rdig bepr\u00f6vad SQL (eller OLAP) i databaser, som kan servera svar (cursors\/views) p\u00e5 komplexa men vanliga anrop, kan krympa m\u00e5nga Sekvensdiagram i UML. D\u00e4r en l\u00e5ng kedja av interaktioner kommer av l\u00e5nga komplexa s\u00f6kningar (ofta navigering mellan m\u00e5nga tabeller) kan ett antal tabeller kapslas in i 1 komponent (t ex som en SQL procedur).    <\/div>\n
<\/o_p><\/div>\n
<\/div>\n
Jag n\u00e4mnde \u00e4ven att datamodellers fokus p\u00e5 data \u00e4r en begr\u00e4nsning: de l\u00e4mpar sig inte f\u00f6r att modellera beteenden som t ex tj\u00e4nster\/operationer, livscykler, scenarion, aff\u00e4rsprocesser, eller MMI. <\/o_p><\/div>\n
<\/div>\n
Men \u00e5 andra sidan r\u00e4cker de l\u00e5ngt f\u00f6r komplexa l\u00e4sningar\/s\u00f6kningar (\u201dQ:et\u201d i CQRS<\/span><\/a>). Med tonvikt p\u00e5 inkapsling snarare \u00e4n notation kan ett minimalistiskt Sekvensdiagram i arkitektvyn se ut s\u00e5 h\u00e4r, uttryckt i UML men bortsett fr\u00e5n aktiveringar (activation bars) och eventuella s\u00e4kerhetsskikt:<\/div>\n

<\/p>\n

<\/a><\/div>\n
<\/div>\n
Dvs f\u00e4rdig och testad funktionalitet krymper SQL-s\u00f6kningen 1 komponent (och i Sekvensdiagram 1 lifeline), i st\u00e4llet f\u00f6r att visa ett antal tabeller i interna loopar (\u201dunder huven\u201d av SQL-motorn eller OLAP-paketet). Enkelt, deklarativt (t\u00e4nk SQL, OCL, Linq, Hibernate, eller ErLang, snarare \u00e4n procedurellt\/imperativt), oberoende av olika accesshj\u00e4lpmedel (SQL index, Peter Coad\u2019s extra associationer f\u00f6r Status Collections som t ex alla fullbokade avg\u00e5ngar kontra de med platser kvar, osv), bortser f\u00f6r tillf\u00e4llet b\u00e5de fr\u00e5n NIH-syndromet (Not Invented Here) och \u00f6nskelistan \u201dB\u00e4ttre testhj\u00e4lpmedel f\u00f6r deklarativa spr\u00e5k\u201d, men visar \u00e4nd\u00e5 s\u00e5dant som intresserar arkitekten.<\/o_p><\/div>\n
<\/div>\n
Trots att exemplet \u00e4r f\u00f6renklat (en resa \u00e4r bara 1 flightsegment, andra bolag i samma allians utel\u00e4mnas, osv) s\u00e5 beh\u00f6vs allts\u00e5 ingen UML-expertis f\u00f6r att inse att minimalistalternativet med inkapsling enligt ovan har sina f\u00f6rdelar j\u00e4mf\u00f6rt med det utf\u00f6rliga \u201dprocedurella\u201d alternativet nedan:<\/o_p><\/div>\n

<\/p>\n

<\/div>\n
<\/a><\/div>\n

<\/p>\n

<\/div>\n
F\u00f6rutom att mer detaljer inte automatiskt medf\u00f6r mer f\u00f6rst\u00e5else och samsyn, s\u00e5 st\u00e4mmer den h\u00e4r sortens explicita s\u00f6kkedjor s\u00e4llan med verkligheten i deklarativa milj\u00f6er, i synnerhet SQL, av fr\u00e4mst tv\u00e5 sk\u00e4l:<\/o_p><\/div>\n
– I st\u00f6rre datam\u00e4ngder anv\u00e4nder SQL motorn ofta accessoptimering, som medf\u00f6r att f\u00f6rst l\u00e4ses de tabeller som effektivt krymper den \u00e5terst\u00e5ende accessv\u00e4gen\/s\u00f6krymden, detta \u00e4ven n\u00e4r accesskedjan kommer att k\u00e4nnas \u201dologisk\u201d f\u00f6r kravanalytiker.<\/o_p><\/div>\n
– Vilka tabeller som l\u00e4ses f\u00f6rst kan variera \u00f6ver tiden beroende p\u00e5 nya index, aktuellt antal rader, och aktuell access-statistik.<\/o_p><\/div>\n
<\/div>\n
\u00c4ven i plattformsoberoende UML-diagram brukar det l\u00f6na sig att b\u00f6rja med \u201dinkapslingsniv\u00e5n\u201d (subsystem, eller komponenter som PriserP\u00e5Tillg\u00e4ngliga i den \u00f6vre bilden), och d\u00e4rifr\u00e5n ta sig ner till detaljniv\u00e5n (med UML 2 Lifeline decomposition), eftersom niv\u00e5erna brukar g\u00e5 hem hos helt olika roller.  <\/o_p><\/div>\n
<\/div>\n
I all agil modellering \u00e4r det viktigt att f\u00f6rst fr\u00e5ga sig vilka roller och situationer modellen \u00e4r till f\u00f6r och vad de f\u00e5r ut av att l\u00e4sa den, detta innan man drar p\u00e5 med detaljerad notation. T ex tittar arkitekten och applikationsutvecklaren s\u00e4llan genom samma glas\u00f6gon. Men ist\u00e4llet f\u00f6r det d\u00e4r med valuta f\u00f6r modelleringspengarna s\u00e5 avslutar jag med en quiz-fr\u00e5ga p\u00e5 temat \u201dbok kontra kurs”, och en k\u00e4nga till de f\u00f6rlag som f\u00f6redragit annat framf\u00f6r praktisk substans medan kurser prioriterat substans:<\/o_p><\/div>\n
<\/div>\n
Gissa vilket av f\u00f6ljande tv\u00e5 citat kommer ur en i \u00f6vrigt mycket bra arkitekturbok, och vilket ur en arkitekturkurs p\u00e5 Informator. B\u00e5da g\u00e5r ut p\u00e5 att f\u00f6rklara A:et i CAP<\/i> inom distribuerat data (CAP = Consistency, Availability, Partition tolerance). <\/o_p><\/div>\n
<\/div>\n
Citat 1.  Availability: The data will be available.<\/o_p><\/span><\/div>\n
Citat 2.  Availability: Node failures do not prevent survivors from continuing to operate and being visible. <\/span><\/o_p><\/div>\n
<\/div>\n
Att rangordna de tv\u00e5 efter praktisk anv\u00e4ndbarhet (eller kanske efter graden av \u201dt\u00e5rta-p\u00e5-t\u00e5rta tautologi\u201d…) \u00f6verl\u00e5ter vi till l\u00e4sarna.<\/o_p><\/div>\n
<\/div>\n
<\/div>\n
Milan Kratochvil<\/b><\/span><\/a><\/o_p><\/span><\/div>\n
konsult, Kiseldalen.com<\/span><\/a><\/span><\/o_p><\/div>\n
UML 2 Professional, OCUP<\/span><\/a> Advanced Level (certifikatniv\u00e5 3 av 3)<\/o_p><\/div>\n
Huvudf\u00f6rfattare UML Xtra Light<\/span>:<\/span> How to Specify Your SW Requirements<\/span> <\/span><\/o_p><\/span><\/a><\/span><\/div>\n
samt Growing Modular:Mass Customization of Complex Products, Services and Software<\/span><\/a><\/o_p><\/span><\/div>\n
<\/div>\n

<\/p>\n

Milan samarbetar med Informator sedan v\u00e5ren 1996 inom modellering, UML, krav, analys och design. H\u00e5ller f.n. kurser i Arkitektur<\/span><\/a>, i modellering (T2715<\/span><\/a>, T2716<\/span><\/a>), och i februari 2013 h\u00f6ll han ocks\u00e5 Informators fullsatta Frukostseminarium<\/span><\/a> om anv\u00e4ndningsfall.<\/o_p><\/div>\n

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

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

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

Mitt arkitekturinl\u00e4gg i mars p\u00e5pekade att dataskiktet ofta f\u00f6renklar beteendemodellen, och att f\u00e4rdig bepr\u00f6vad SQL (eller OLAP) i databaser, som kan servera svar (cursors\/views) p\u00e5 komplexa men vanliga anrop, kan krympa m\u00e5nga Sekvensdiagram i UML. D\u00e4r en l\u00e5ng kedja av interaktioner kommer av l\u00e5nga komplexa s\u00f6kningar (ofta navigering mellan m\u00e5nga tabeller) kan ett antal tabeller kapslas in […]<\/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,1],"tags":[],"class_list":["post-25249","post","type-post","status-publish","format-standard","hentry","category-blogg","category-blogi","category-okategoriserad"],"aioseo_notices":[],"aioseo_head":"\n\t\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\n\t\t