Nyanser i UML: intressant för fler än analytikern

Avancerade objektmodeller innehåller en del nyanser som ett ovant öga kan missa. Ett enkelt exempel (på gränsen till avancerat) är ”graderingen” av koppling mellan två klasser (association, aggregat, composition). Är man inte mycket för att åskådliggöra men desto mer för affärsregler och referensinteritetsregler, så skulle association plus olika regler kunna räcka för alla tre graderna. Vad är det då för regler UML visualiserar med graderingen?

Anta att du gjort modelleringsseminarier på tre olika avdelningar hos en kund som sysslar med tåg. På alla tre gick det snabbt att enas om att deras tåg har vagnar, men du vet av erfarenhet att tågdjävulen sitter i detaljerna (det gick ju bra med Stockholm-Riksgränsen t/r på 1 biljett medan Stockholm-Uppsala t/r med SL-tåg behövdes 4 biljetter per pers, osv...)

Därför ritar du ett tåg som aggregat (”har”, ”består av”, mittersta bilden) av vagnar, till at börja med. När du kommer till punkten Kluriga Frågor får du lite olika svar på olika avdelningar...

På den ena visar sig aggregatet stämma ganska bra: livscyklerna (hos Tåg resp Vagn) överlappar under en lång tid, fast reglerna verkar tänjbara, det är inte helt säkert om en vagn kan t ex. kopplas loss under en kortare tid (och inte tillhöra något tåg just då). För analytikerrollen betyder aggregat (mittersta bilden) ”består av” utan särskilt tydliga regler. För utvecklaren ger den en vink att en referens (Tåg – Vagn) kan passa bättre (än en nästlad klass i Tågklassen).

På den andra, som sysslar med höghastighetståg, visar sig däremot composition stämma bättre: deras nya säkerhetspolicy att anskaffning/avyttring och översyn/reparation alltid gäller hela tågsätt får livscyklerna (Tåg resp Vagn) att överlappa på livstid. Reglerna är tydliga, det är säkert att när t ex ett Tåg tas bort i systemet så medför det att dess vagnar tas bort samtidigt. En vagn måste alltid tillhöra något tåg. För analytikerrollen betyder composition (högra bilden) aggregat plus strikta regler. För utvecklaren ger den en vink att en nästlad klass (inuti Tåg-klassen) passar. För DBA-rollen betyder den en striktare referensintegritetsregel (on Delete Cascade).

På den tredje, som sysslar med godsvagnsreskontra, passar association: deras vagnar far kors och tvärs genom Europa, kopplas om mellan tåg på vägen, ibland står de på något stickspår i Sydosteuropa i veckor (dvs tillhör inget tåg alls under tiden) osv. Livscyklerna (Tåg resp Vagn) överlappar inte alls, reglerna (eller snarare praxis) är tydliga, när Tåg tas bort i systemet så medför det att dess vagnar finns kvar (och behöver inte tillhöra något tåg). För analytikerrollen betyder association (vänstra bilden) en ganska lös koppling utan tydlig hierarki. För utvecklaren ger den en vink att referens fungerar (inte nästlad klass) och att tomma referenser förekommer. För DBA-rollen betyder den oftast referensintegritetsregeln ”on Delete Set Null”.

Ytterligare nyansexempel (Generalisering) kommer under senvåren.

Milan Kratochvil

konsult, Kiseldalen.com

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

Huvudförfattare UMLXtra Light: How to Specify Your SW Requirements

samt GrowingModular: Mass Customization of Complex Products, Services and Software

Milan 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 i februari 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.