Mjukvaruarkitektur

Prestandasyftar till att minska latency, dvs. tiden det tar från det att du trycker påen knapp till dess att processen utförts. Latency påverkas av många faktorer,bland annat processorns hastighet och nätverkets bandbredd.

För attreducera latency kan man reducera resurskraven genom att utforma mjukvara somkräver mindre processorkraft. Det säger sig självt, antingen gör manprogramvaran smartare/mindre resurskrävande eller så köper man helt enkeltbättre dator (med bättre processorkraft).

En annan metodför att reducera latency är genom så kallad Resource Management(resurshantering). Denna metod kontrollerar hur resurser hanteras och genomförprocesser på ett resurssnålt sätt genom att t.ex. hantera förfrågningarparallellt, tillhandahålla flera kopior av data/beräkning och öka antalettillgängliga resurser

Hög portabilitet innebär att ett system är anpassat för att fungera på flera plattformar. Det kanexempelvis innebära att ett internt IS-system skall fungera på laptops/smartphones/stationäradatorer osv. Detta gör man genom att antaganden om en viss plattform lokaliseras till ett begränsatantal komponenter, på så sätt behöver man endast förändra mjukvaran på komponentnivå för attden skall vara kompatibel med nya plattformar.

Typ och placering avsäkerhetskomponenter avgörs på arkitektonisk nivå.Säkerhet är förmågan hos ett system för att förhindraavsiktliga eller oavsiktliga handlingar utanför den avsedda användningen, ochför att förhindra utlämnande eller förlust av information. Ett säkert systemsyftar till att skydda tillgångar och förhindra obehörig ändring avinformation.

T.ex.Privat nätverk ← →Firewall ← → Internetf

Räcker det med lågkoppling och hög sammanhållning för att designa återanvändbara komponenter*Oftast måste komponenten vara mer anpassbar än det behövs för det system somutvecklas Vad mer ska vi ta hänsyn till för att återanvända befintlingakomponenter? *Anpassa systemet ( och därmed verskamheten ) till en befintlingkomponent *Anpassa den tekniska miljön för att kunna återanvända en befintligkomponent

Det enda vi kan göra viddesign av arkitekturen är att se till att funktionaliteten finns med ikomponenterna och att samordna komponenternas interaktion.

Fördelen för implementering är attom en mjukvarumodul har ett enda syfte, kommer det att vara enklare, och därförlättare och billigare, att utforma och genomföra.

Systemmed funktionellt utformade delar är lättare att ändra eftersom varje del görbara vad den påstår sig göra

Ett mått på hur lång tidsystemet fungerar utan fel och hur lång tid det tar att åtgärda felen. OBS! Detär inte alltid klart vad man menar med fel(failure) men oftast är det inte frågaom något funktionellt fel(error) utan systemets oförmåga att utgöra en viss funktion(ett avbrott). Tillgänglighet definieras den andel av tiden som systemetfungerar och arbetar. Det kan mätas som en procentandel av det totaladriftstoppet under en fördefinierad tidsperiod. Tillgängligheten påverkas avsystemfel, infrastrukturella problem, attacker, och belastningen på systemet.

Arkitektoniska åtgärder:

* Redundanta komponentersom tar över vid avbrott

* Ta hänsyn tillfelhantering vid design av komponentgränssnitt

* Time-out monitorer (en komponent )som slår larm om ingen respons efter en bestämd tid

* Komponenter med högsammanhållning och låg koppling förenklar testningen och modifieringen ochdärmed minskar sannolikheten av avbrott och snabbare reparation

Detta attribut är huvudsakligen en arkitekturfråga. Målet är att minimera effekten på övriga systemvid systemförändringar. Detta görs genom låg koppling och hög sammanhållning. Ett exempel pådetta är Mats välbeprövade bil-exempel; jag ska inte behöva byta olja bara för att jag behöver bytadäck på bilen.

Dvs en förändring ska inte påverka andra system.

Följande arkitektoniskafaktorer påverkar testbarheten:

* Hur klarakomponenternas ansvarsområden är (sammanhållning)

Detta innebär att man skall kunna koncentrera sin testning till en viss funktion, t.ex. om jag endastvill testa systemets sökförmåga så ska jag kunna testa just detta. Detta kan endast ske omkomponentera har tydliga ansvarsområden – i det här fallet genom att sökmotorskomponenten intehar flera uppgifter än att just söka.

* Grad av “informationhiding“

Genom att använda informationshiding är det enklare att kunna korrigera de delar som behövs ändras när testningen sker. Eftersom de delarna blir tillgängliga medans de delar som inte ska korrigeras är "gömda".

* Kvalitet på arkitektonisk dokumentation

Om dokumentationen inte håller hög kvalitet blir den svårare att använda sig av, den blir dvs opålitlig.

Testabilityär ett mått på hur lätt det är att skapa kriterier för systemet och desskomponenter, och till utföra dessa tester för att avgöra om kriteriernauppfylls. Bra testability gör det mer sannolikt att felen i systemet kanisoleras på ett snabbt och effektivt sätt.

Möjliggöra att ett program kan implementeras på mer än en plattform (genom att t.ex. skapa enmobilapp till programmet i framtiden). Låg koppling och hög sammanhållning ger en braåteranvändbarhet. (sparar tid och pengar)

Hur lätt det är förseparatutvecklade komponenter att fungera tillsammans

Detta attribut mäter ett mjukvarusystems möjlighet att integrera med andra system. Det kanexempelvis innebära att en CRM-modul hos Volvo även kan användas av Volvos underleverantörerför att skicka direktreklam till deras nuvarande kunder.

Detta avgörs av:

* Komponenternas externa(gränssnitt) komplexitet

* Klar ansvarsfördelning mellan komponenter (hög sammanhållning)

* Interaktionsmekanismenoch protokoll

* Fullständighet avgränssnittspecifikation Alla punkter ärarkitektoniska faktorer

Handlar om hur enkelt(billigt) det är att utveckla ett system

Blir dyrare om:

*Nödvändiga komponenten saknas i organisationen

*Bra verktyg inte är tillgängliga

Hur lätt är systemet att implementera? Hur mycket extra arbete kommer behövas för attimplementera det på andra organisatoriska enheter? Hur svårt är det att bygga upp systemet på enarbetsplats? Detta kvalitetskriterie innebär därmed att systemet måste vara väl anpassat för attkunna byggas ut på fler enheter.

Konceptuell integritet innebär att likartade problem skall ha likartade lösningar (standardisering).Mjukvarudesignen skall därför vara konsekvent, användning av samma ”patterns” är ett sätt attåstadkomma detta (genom t.ex. naming contentions osv).

“Conceptual integrityis the principle that anywhere you look in your system, you can tell that thedesign is part of the same overall design”