Arkitekturblogg del 3: Faktorer som avgör hur mjukvaruarkitekturen bör se ut

08 November 2016 // Patrik Gustavsson

Att ta fram en mjukvaruarkitektur handlar främst om att identifiera vilka mjukvaruelement som behövs i en lösning samt vilka relationer dessa element ska ha till varandra. Det påståendet följer helt logiskt från definitionen av mjukvaruarkitektur som gavs i föregående blogginlägg.

Men vilka faktorer är det då som styr hur arkitekturen bör utformas?

Boken ”Software Architecture In Practice” tar upp tre sorters krav på sidan 64.

• Funktionella krav (Functional requirements)
• Begränsningar (Constraints)
• Krav på kvalitetsegenskaper (Quality attribute requirements)

Det är främst kraven på kvalitetsegenskaper och på förhand givna förutsättningar (begränsningar) som driver mjukvaruarkitekturen, inte kraven på vad systemet faktiskt ska kunna utföra. Det uttrycks på ett ganska drastiskt sätt på sid 65 i samma bok.

”In fact, if functionality were the only thing that mattered, you wouldn’t have to divide the system into pieces at all; a single monolithic blob with no internal structure would do just fine”.

Begränsningar (constraints)

Det skulle ganska snabbt bli kaotiskt om varje mjukvaruarkitekt införde tekniker, programmeringsspråk och plattformar som just den arkitekten är van att arbeta med och tycker är spännande. Därför bör det finnas en målarkitektur och olika referensarkitekturer som mjukvaruarkitekten behöver förhålla sig till. Dessa innehåller ofta begränsningar som vilka programmeringsspråk som får användas, vilka typer av databaser som får användas, om man ska prioritera OpenSource före kommersiella produkter, köpa i första hand och bygga i andra hand osv.

Den här saken handlar mycket om att se helheten på hela företaget eller organisationen. För man in ny teknik så får det påverkan på fler ställen än vad många kanske tänker på. Men tänker man på driftsorganisation, behov av utbildning och kompetens, behov av licenser, behov av support, samarbetsförmåga med mjukvara som redan finns på företaget osv så inser man ganska snabbt att det är viktigt att sätta upp vissa ramar även för mjukvaruarkitekturen.

Begränsningar (constraints) formar alltså mjukvaruarkitekturen på ett väldigt direkt sätt utan behov av att mjukvaruarkitekten i sitt specifika projekt väger för- och nack-delar, gör sunda avvägningar eller drar logiska slutsatser. Skulle det däremot vara så att en mjukvaruarkitekt i ett sammanhang ser en stor fördel med att använda en annan teknik så bör det stämmas av med arkitekturrådet eller motsvarande funktion på företaget eller organisationen. Men då handlar det om en sorts dispensansökan för att få göra ett undantag i ett enskilt projekt.

Krav på kvalitetsegenskaper

Det är värt att notera att en av världens mest ansedda böcker om mjukvaruarkitektur (Software Architecure In Practice) använder sidan 61 – sidan 269 för att beskriva hur en mjukvaruarkitekt utgående från krav på kvalitet med hjälp av ”taktiker” och ”mönster” kan forma en mjukvaruarkitektur. I princip halva boken ägnas åt detta.

Följande kvalitetsegenskaper belyses:

• Tillgänglighet (availability)
• Samarbetsförmåga (interoperability)
• Modifierbarhet (modifiability)
• Prestanda (performance)
• Säkerhet (security)
• Testbarhet (testability)
• Användbarhet (usability)

Väl värt att notera är att inte alla kvalitetsegenskaper handlar om hur mjukvaran beter sig under körning. Modifierbarhet till exempel handlar om hur lätt eller svårt det är att göra en förändring i mjukvaran. Kraven på kvalitetsegenskaper driver inte arkitekturen på samma enkla och direkta sätt som begränsningar gör. För att forma mjukvaruarkitekturen utgående från krav på kvalitetsegenskaper krävs det både sunda avvägningar, erfarenhet och logiska resonemang. Begränsningen ”JBoss ska användas som applikationsserver” lämnar inte mycket kvar för arkitekten att fundera över. Men krav på kvalitetsegenskaper som testbarhet, säkerhet eller modifierbarhet ger stort utrymme för arkitekten att ta fram olika lösningar. Det finns beprövade sätt att lösa kraven på kvalitetsegenskaper och de kallas för ”taktiker”. Dessa taktiker kommer att beskrivas i senare blogginlägg. Då blir det även tydligt hur krav på kvalitet som hanteras med en taktik påverkar vilka mjukvaruelement som behövs och relationer mellan dem, dvs hur de formar en mjukvaruarkitektur. Ännu längre fram i bloggserien ska vi se hur arkitekturmönster in sin tur är uppbyggda av taktiker.

Andra kvalitetsegenskaper

Software Architecture In Practice har även ett kapitel som handlar om andra kvalitetsegenskaper som inte lika ofta används i projekt men som kan vara värda att känna till. Förutom de kvalitetsegenskaper jag nämnt från boken så finns det olika sammanställningar av kvalitetsegenskaper. FURPS (Functionality, Usability, Reliability, Performance och Supportability) är exempel på en sådan. Allt utom F i FURPS är kvalitetsegenskaper. Wikipedia har en lång lista på kvalitetsegenskaper och Software Architecture In Practice uppmanar till att man i olika projekt tänker efter själv vilka kvalitetsegenskaper man vill arbeta med och kallar det för ”X-ability”.

Andra faktorer som formar en mjukvaruarkitektur

Allt kan inte fångas upp av teori och principer, ibland måste ren logik och sunt förnuft användas. Om du till exempel är i ett läge där du behöver information som finns hos en extern leverantör så påverkar det arkitekturen eftersom du då behöver en integration för att läsa data därifrån. Det har egentligen inget med krav på kvalitet eller begränsningar att göra. Det är bara ett faktum att informationen måste hämtas från den leverantören. Det kan vara en resebyrå som behöver tillgång till flygavgångar eller till information om hotell. Ett annat exempel är om du har ett funktionellt krav som innebär att du behöver skriva ut stora volymer. Då behöver du ha med skrivare i din arkitektur. Det är svårt att kategorisera in det som en begränsning eller som ett krav på en kvalitetsegenskap.

Lagkrav som PUL påverkar också arkitekturen. Men de kraven går att se som krav på kvalitetsegenskapen säkerhet och det är egentligen bara det att kravställaren inte är den egna organisationen utan Regeringen.

Förtydligande av relation mellan krav och arkitektur

En del krav går att lösa utan att förändra mjukvaruarkitekturen genom att skriva mer kod i befintliga mjukvaruelement. Andra krav behöver man lösa genom att införa nya mjukvaruelement och därmed formas även mjukvaruarkitekturen.

Om du tänker dig en enkel miniräknare som kan utföra addition, subtraktion, multiplikation och division. Om du får ett till krav på funktionalitet att miniräknaren även ska kunna ta kvadratroten eller räkna med exponenter så finns det ingen anledning att lägga in de funktionerna någon annanstans än där koden för de fyra räknesätten finns. Det är bara att fylla på med mer kod i befintliga mjukvaruelement.

Men för krav på kvalitetsegenskaper är det sällan bara att fylla på någonstans med mer kod. Tänk dig att du vill ha hög grad av tillgänglighet. Du kan inte uppnå det genom att skriva kod för att uppnå hög tillgänglighet där den andra koden redan ligger för går den ned så går även din metod för tillgänglighet ner. Det är mer lämpligt att bygga ett annat mjukvaruelement som övervakar att applikationen är uppe och kör och som kan larma när den inte är igång.

Ett annat exempel där det inte bara handlar om att fylla på med kod i befintliga mjukvaruelement är krav på säkerhet. Säg till exempel att applikationen ska skyddas av en brandvägg. Brandväggen är att betrakta som ett eget mjukvaruelement.

Du kan heller inte skriva kod som gör att övrig redan skriven kod i din applikation blir modifierbar.

Exempel som dessa kan göras hur många som helst och de visar på det faktum att det främst är kraven på kvalitet och på förhand givna begränsningar som formar mjukvaruarkitekturen.

Om funktionella krav och utformandet av en mjukvaruarkitektur

Även om krav på funktionalitet inte driver på arkitekturens utformning på samma sätt som kraven på kvalitetsegenskaper eller uppsatta begränsningar, så behöver arkitekten naturligtvis ta hänsyn till dem i sitt arbete. Om det inte var på det sättet så hade det varit tillräckligt med att ange krav på kvalitetsegenskaper och begränsningar och sedan trycka på en knapp i ett program för att få ut en hel beskrivning av mjukvaruarkitekturen.

Bästa sättet att uttrycka det på är att det är kraven på kvalitetsegenskaper och förutsatta begränsningar som driver arkitektens arbete, men under det arbetet ska även hänsyn tas till funktionella krav. Ett sätt att inse det är att om du i exemplet med en resebyrå har format arkitekturen på så sätt att du har en modul för bokningar, en annan för flygrutter, en tredje för kunder osv så har du gjort det för att öka modifieringsbarheten i resebyråapplikationen. Dvs målet för ditt arbete har varit att öka graden av kvalitetsegenskapen modifierbarhet. Men anledningen till att du kom fram till just de modulerna har att göra med vad applikationen faktiskt gör för något.

Dessutom är det så att krav på kvalitetsegenskaper ofta är knutna till olika funktioner. En funktion kan till exempel vara tillgänglig även om inte hela systemet är tillgängligt. På samma sätt kan en specifik funktion ha krav på svarstider som skiljer sig från andra funktioner i systemet.

Men det är viktigt också (för att hamna på rätt nivå i arkitekturen) att tänka på att definitionen av mjukvaruarkitektur talar om vilken nivå som behövs för att resonera om arkitekturen. Arkitekten för en resebyråapplikation behöver därför inte tänka på varje fält som matas in under till exempel en bokning av en resa. Att arkitekten har en allmän insikt i att det finns många krav kring bokningar (skapa bokning, sök bokning, ta bort bokning osv) är tillräckligt för att kunna inse att det är bra med en egen modul för bokningar. Mer detaljerad kunskap om funktionella kraven än så behöver inte arkitekten ha.

Nästa inlägg i bloggserien kommer att visa några exempel på hur krav på kvalitetsegenskaper kan hanteras med hjälp av olika taktiker.