Komponentbaserad arkitektur

Ett system som är under utveckling måste enligt Kruchten (2000) ses från en rad olika perspektiv. Exempel på dessa är beställare, slutanvändare, programmerare, analytiker osv.

30 Alla som är involverade i utvecklingsarbetet har en annorlunda syn på hur systemet ser ut under de olika stadier som systemutvecklingen går igenom. För att ta hand om dessa problem på ett effektivt sätt anser Kruchten (2000) att systemets arkitektur är en viktig del.

Enligt Kruchten (2000) är det viktigt att använda en arkitektur under systemutveckling. Detta möjliggör återanvändning av komponenter och kan i sin tur ge ekonomiska vinster. Vidare beskrivs det att det blir lättare att upptäcka beroenden mellan mjukvara och hårdvara och att det förenklar uppdelningen av arbetsmoment mellan olika systemutvecklare. Detta leder till att befintliga komponenter återanvändas med nyutvecklade och på så sätt utnyttjas resurserna effektivare. Genom att kombinera en arkitektur med en iterativ process utvecklas dess komponenter vid varje iteration som i sin tur kan evalueras och testas mot de insamlade kraven (Kruchten, 2000).

För att säkerställa de insamlade kraven menar Avison & Fitzgerald (2002) att utvecklarna bör använda sig av analys och design. Vidare menar Avison & Fitzgerald (2002) att analysdelen är ett logiskt synsätt på systemet till skillnad från designdelen som använder resultatet av analysen och anpassar den till arkitekturens gränser och de icke-funktionella kraven.

3.3.1 Visuell modellering 

Systemutveckling är inte bara kodning utan kräver planering och insamling av krav. Vid systemutveckling är det, enligt Jacobsen, Booch & Rumbaugh (1999) nödvändigt att utvecklarna använder ett modelleringsspråk. Detta görs för att en kontakt ska upprätthållas för att få kontroll på vad som sker mellan olika utvecklingsgrupper och för att förvalta beställarens krav och önskemål. För att förverkliga detta kan notationsspråket UML användas.

Det finns ett flertal olika områden där UML kan användas. Enligt Arlow & Neustadt (2005) förknippas UML först och främst med objektorienterad systemutveckling. UML har som funktion att visualisera hur ett program ska se ut och fungera med hjälp av olika diagram. I UML 2.0 existerar fjorton diagram som är strukturella diagram eller beteendediagram. Strukturella diagram har som syfte att visa hur ett system kommer att se ut i förhållande till ett beteendediagram som visar olika arbetsflöden.

För att förstå hur ett system ska utvecklas måste det göras mer abstrakt med hjälp av olika modeller. Modellering hjälper systemutvecklarna och underlättar visualisering, specificering,

31 konstruktion och dokumentering av systemets struktur och beteende (Kruchten, 2000). UML är en ritning över systemets processer och funktioner som låter utvecklarna visualisera resultatet för andra involverade parter i utvecklingsgruppen. Visualiseringen sker med hjälp av UML:s olika ikoner och diagram där delar av systemet, användare och informationsflöden demonstreras (Jacobsen, 1999).

UML är ett vanligt förekommande språk när olika semantiska notationer över ett system ska skapas. Modelleringen visar hur ett system ska se ut och vad det ska göra men inte hur funktionerna ska lösas (Jacobsen, 1999). För att lösa detta är RUP enligt Kruchten (2000), en bra metod som fungerar som en guide över hur de olika diagrammen ska användas.

Use Case används för att identifiera, klargöra och organisera systemkrav samt beskriva systemet utifrån användarens perspektiv. Symbolerna beskriver hur olika aktörer kommunicerar med systemet. Symbolerna som visar hur interaktionerna sker består bland annat av ovaler, systemgränser, aktörer och relationspilar. Aktörerna står utanför systemgränsen för att påvisa relationen mellan aktör och systemgräns, andra former av aktörer kan vara olika hårdvaror. I Use Caset nedan beskrivs funktioner som är av värde för användaren (Arlow & Neustadt, 2005).

32 Vid konstruktion av ett klassdiagram finns det flertalet element som ska beaktas. Enligt Arlow & Neustadt (2005) konstrueras en klass som en rektangel och delas in i tre olika kolumner. Namnet på klassen placeras alltid överst. Attribut och egenskaper beskrivs längst ned och visar tillhörande metoder. Relationer skapas genom att de kopplas samman (se figur 3:4).

Figur 3:4 UML klassdiagram 

Vid utveckling av ett aktivitetsdiagram utgår diagrammet från en startposition som symboliseras med en fylld cirkel. Pilarna ska representera olika övergångar mellan de olika tillstånden. Aktivitetsdiagrammet avslutas med en cirkel som är delvis fylld och detta för att indikera att aktiviteten är avslutad (Arlow & Neustadt, 2005) (se figur 3:5).

33

Figur 3:5 UML aktivitetsdiagram 

3.3.2 Verifiering av kvaliteten 

Inom RUP har alla som är involverade i utvecklingen av ett nytt system ansvar för kvaliteten på systemet. Enligt Kruchten (2000) ska fokus ligga på två områden, produktkvalitet och processkvalitet. Produktkvaliteten säkerställer kvaliteten på själva produkten som utvecklas samt dess element. Dessa element kan exempelvis vara komponenter, subsystem, arkitekturer etc. Processkvaliteten kan mätas med hur själva implementeringen av produkten har genomförts, dokumentationens kvalitet, diagrammen och de olika Use Casen. Eriksson (2007) anser att meningen med Use Case är att hitta och beskriva systemets olika aktörer. För att hitta alla aktörer och funktioner som kommer att användas kan detta göras genom arbete i workshops och användandet av Use Cases vilket har som syfte att samla in olika krav. I Workshops bör det finnas aktörer som är representativa intressenter. Systemets beställare bör finnas med från början och kan inta rollen att iaktta och kommentera de krav som har utvecklats. Det finns både för och nackdelar med Use Cases, en fördel är att kraven identifieras på systemet. Men det är också bra på ett visuellt plan för att överbrygga problem och kommunikation mellan beställare och leverantör. Nackdelarna med Use Cases anses av Genilloud & Wegmann (2000) vara möjligheten att påvisa multiplicitet. Detta hindrar utvecklarna att visa hur många aktörer som interagerar med systemet. Utifrån de krav som identifierats utvecklas ett Use Case. Meningen är att visa hur olika operationer ska fungera och hur de är kopplade till olika aktörer i systemet. En aktör är någon som använder systemet, men som inte är en del av det.