kvalitet attributter i programmel arkitektur

billede 1. Monument Valley spil

lad os fortsætte med at undersøge programmel arkitektur. Vi overvejede, hvem der er Programmelarkitekt, hvilke typer Programmelarkitekter der findes, og hvad arkitekten skal gøre i starten af et projekt. Når interessenter identificeres, og krav indsamles, opstår spørgsmålet, hvad de skal gøre næste gang. Når funktionelle krav er formuleret – eller svaret på spørgsmålet “hvad systemet skal gøre” findes, begynder programarkitekten at søge efter svaret på spørgsmålet “hvordan systemet skal fungere.”Ikke-funktionelle krav hjælper i så fald.

  1. vejen til at blive Programmelarkitekt
  2. interessenter i Programmelarkitektur
  3. typer af Programmelarkitekter
  4. kvalitetsattributter i Programmelarkitektur
  5. dokumentation i Programmelarkitektur
  6. certifikater i Programmelarkitektur
  7. bøger i Programmelarkitektur
  8. system design cheat sheet

Hvad er de ikke-funktionelle krav?

ikke-funktionelle krav (NFRs) definerer de kriterier, der bruges til at evaluere hele systemet, men ikke for en bestemt adfærd, og kaldes også kvalitetsattributter og beskrives detaljeret i arkitektoniske SPECIFIKATIONER.

alle NFRs kan opdeles i to hovedkategorier:

  • NFRs, der påvirker systemets adfærd, design og brugergrænseflade under arbejdet.
  • NFRs, der påvirker udviklingen og understøttelsen af systemet.

en situation, hvor systemet har den ønskede kombination af kvalitetsattributter, f.eks. Når du designer for at imødekomme eventuelle krav, er det vigtigt at overveje indvirkningen på andre attributter og finde kompromiser mellem krav. Sammen med dette adskiller værdien eller prioriteten for hver attribut sig fra system til system. Denne artikel dækker ikke alle eksisterende attributter, men de dækkede kan være en god start til at designe dit system.

kvalitetsattributtyper (ISO/IEC FCD 25010 diagram)

for at overveje typerne af kvalitetsattributter kan vi bruge et diagram fra ISO 25010:

billede 2. ISO/IEC FCD 25010 diagram

denne standard beskriver kvalitetsattributterne for et programprodukt. Dernæst vil vi se på, hvad præcis hver attribut betyder individuelt.

ydeevne viser systemets reaktion på at udføre visse handlinger i en vis periode.

der er to måder at måle ydeevne på:

  • Latency: tid brugt på at reagere på en begivenhed
  • kanal kapacitet. Antallet af begivenheder, der opstår på et bestemt tidspunkt.

i praksis omfatter de mulige præstationsindikatorer for eksempel:

  • gennemsnitligt / maksimalt antal systembrugere pr.
  • gennemsnitlig sideindlæsningstid.
  • gennemsnitlig metode udførelsestid.

her kan du finde interessante latenstal, som enhver udvikler skal kende.

ydelsesproblemer vokser meget ofte til problemer, der kan påvirke alt, fra serverens kapacitet eller hvordan du udvikler din front-end til effektiviteten af databaseforespørgsler eller kapaciteten i kommunikationskanaler.

ydeevne er næsten altid inkluderet på listen over kritiske kvalitetsattributter, der skal overvejes af arkitekten, da det påvirker hele systemet og kan påvirke mange dele af den arkitektoniske løsning. Derfor kan du på internettet finde et stort antal eksempler på, hvordan du håndterer ydelsesproblemer.

interoperabilitet er en egenskab af systemet eller en del af systemet, der er ansvarlig for dets drift og transmission af data og dets udveksling med andre eksterne systemer. Et veldesignet system letter integration med tredjepartssystemer. For at forbedre interoperabiliteten kan du bruge veldesignede eksterne grænseflader, standardiseringssystemer mv.

naturligvis er der mange problemer for interaktion:

  • forældede eksterne systemer.
  • forskellige formater af data i lignende eksterne systemer.
  • forskellige versioner af API i eksterne systemer.
  • bagudkompatibilitet af API til integration.
  • dårlig kvalitet og mangel på standarder for eksterne systemer.

interoperabilitet kan ikke ignoreres. I bedste fald skal du oprette yderligere lag til interaction API. I værste fald vil det være nødvendigt at genopbygge hele systemet.

Usability er en af de mest væsentlige attributter, fordi brugerne i modsætning til i tilfælde med andre attributter kan se direkte, hvor godt denne attribut af systemet er udarbejdet. Et af de kritiske problemer med brugervenlighed er for meget interaktion eller for mange handlinger, der er nødvendige for at udføre en opgave. Forkerte sekvenser af trin i flertrinsgrænseflader er også et problem med brugervenlighed. Dataelementer og kontroller kan designes ikke i henhold til de accepterede mønstre for brugeroplevelse, hvilket også komplicerer interaktionen. For eksempel, hvis du udvikler en iOS — applikation, er det vigtigt at bruge retningslinjerne fra Apple eller retningslinjerne fra Microsoft-til vinduer desktop applikationer.

eksempler på vigtige indikatorer for denne attribut er:

  • liste over understøttede enheder, OS-versioner, skærmopløsninger og deres versioner.
  • elementer, der fremskynder brugerinteraktion, såsom “genvejstaster”, “lister over forslag” og så videre.
  • den gennemsnitlige tid en bruger skal udføre individuelle handlinger.
  • støtte til tilgængelighed for handicappede.

pålidelighed er en egenskab af systemet, der er ansvarlig for evnen til at fortsætte med at fungere under foruddefinerede forhold. Systemet fejler oftest på grund af utilgængeligheden af eksterne elementer, såsom databaser, systemer og netværksforbindelser.

tilgængelighed er en del af pålideligheden og udtrykkes som forholdet mellem den tilgængelige systemtid og den samlede arbejdstid. Vigtige indikatorer for denne attribut er:

  • tilgængelighed.
  • planlagt nedetid.
  • den nødvendige tid til at opdatere programmet, og så videre.

tilgængelighed udtrykkes ofte i antallet af ni efter kommaet, det er ni af tilgængelighed (Timer / Minutter / Sekunder):

  • 2 9 s (99%) = op til 87,6 h / 5256,0 m / 315360,0 sekunders nedetid om året.
  • 3 9 ‘ er (99,9%) = op til 8,76 h / 525,6 m / 31536,0 sekunders nedetid om året.
  • 4 9 ‘ er (99.99%) = op til 0.876 h / 52.5599999999999995 m / 3153.6 sekunders nedetid om året.
  • 5 9 ‘ er (99.999%) = op til 0.0876 h / 5.256 m / 315.36 sekunders nedetid om året.
  • 6 9 ‘ er (99, 9999%) = op til 0, 00876 h / 0, 5256000000000001 m / 31.536 sekunders nedetid om året.
  • 7 9 ‘ er (99.99999%) = op til 8.76 E-4h / 0.05256 m / 3.1536 sekunders nedetid om året.

for eksempel er Tilgængelighed et af hovedkriterierne for tier-ranking af datacentre i USA.

sikkerhed er ansvarlig for systemets evne til at reducere sandsynligheden for ondsindede eller utilsigtede handlinger samt muligheden for tyveri eller tab af information. Flere foranstaltninger bruges til at beskytte systemer: godkendelse, kryptering, revision og andre.

eksempler på denne attribut i systemets arbejde er:

  • systemets evne til at opdage DDoS-angreb og reagere på dem.
  • begrænsninger af brugeradgang ved godkendelse/autorisation.
  • forebyggelse af injektion.
  • kryptering af adgangskoder og indhold.
  • sikker forbindelse.

vedligeholdelighed er systemets evne til at understøtte ændringer. Ændringer kan relateres til nye forretningskrav eller korrektion af gamle fejl og påvirke systemkomponenter eller separate metoder. Vedligeholdelighed påvirker også den tid, der er nødvendig for at gendanne systemet efter en fejl. Overdreven afhængighed mellem komponenter har en meget negativ indvirkning på vedligeholdelsen. I programmeringen er der en forestilling om anti-mønster spaghetti kode, hvilket betyder overdreven sammenhæng i koden. I arkitektur er der ikke sådan noget, men arkitektur er meget tæt på programmering i denne forstand. Det er på grund af vedligeholdelsesattributten, at sådanne begreber som adskillelse af ansvar, mikroservicearkitekturer og modularitet har vist sig. Samtidig påvirker denne attribut ikke kun udviklingsprocesser, men også ledelsesprocesser (for eksempel opdeling af hold i produktrelaterede dele).

Modificerbarhed bestemmer, hvor mange almindelige ændringer der skal foretages i systemet for at foretage ændringer i hvert element. Idealet er tilfældet, hvor hver ændring kun påvirker et element.

testbarhed viser, hvor godt systemet tillader udførelse af test i henhold til foruddefinerede kriterier. Ud over testydelsen gør testbarheden det muligt at opdele systemet effektivt i delsystemer.

hovedindikatorerne for denne attribut er:

  • procentdel af dækning med modul -, Integrations-eller enhedstest.
  • den endelige liste over krævede testmiljøer samt den endelige liste over anvendte tilgange til test (manuel/automatisk, regression, integration osv.).

andre grundlæggende kvalitetsattributter er ikke omfattet af standarden, men kan ikke ignoreres i denne artikel.

skalerbarhed er systemets evne til at håndtere belastningsstigninger uden at mindske ydeevnen eller muligheden for hurtigt at øge belastningen.

der er to måder at forbedre skalerbarheden på:

  • lodret: for at øge tilføjer vi flere ressourcer, såsom hukommelse, diske eller processorer til et system.
  • vandret: vi øger antallet af computerenheder og deler belastningen.

nøgleindikatorerne til måling af denne attribut er:

  • hvis systemet tillader vandret skalering.
  • den nødvendige tid til at øge skaleringen i sekunder.
  • Skaleringsbegrænsninger: antallet af servere eller netværkskapaciteten.
  • mulighed for at skalere: stigningen i antallet af transaktioner eller mængden af indhold.

og dette er kun en lille del af de indikatorer, som du skal følge, når du designer. Skalerbarhed er en af de mest væsentlige egenskaber, uanset hvad der er projektets fase.

genanvendelighed er en chance for at bruge en komponent eller et system i andre komponenter/systemer med lille eller ingen ændring. Adskillelse af ansvarsområder, modularisering, faldende kopi-pasta handler om genanvendelighed. Kopiering af kode, eller værre, ved hjælp af forskellige komponenter til det samme resultat i forskellige moduler, er et af de største problemer med genanvendelighed.

Supportability er systemets evne til at give nyttige oplysninger til at identificere og løse problemer. De vigtigste problemer med at sikre supportbarhed kan løses med følgende midler:

  • ingen diagnose: hvordan systemets aktivitet og ydeevne styres. Det omfatter forskellige typer logning.
  • ingen værktøjer til Fejlfinding: Dette inkluderer sikkerhedskopier, forskellige systemer til oprettelse af snapshots af systemet og værktøjer til revision af systemet. Når systemet fejler, er det altid mere behageligt at vente på en automatisk genstart end at løse problemet manuelt.
  • ingen sundhedskontrol: dette inkluderer en række systemer til måling af kompileringstid, implementeringstid, databasestørrelse eller mobilapplikationsstørrelse.

oftest betragtes disse ikke i start-ups eller små projekter oprindeligt. Omkostningerne ved at opretholde understøttelsesattributten er høje, og resultatet er kun synligt i stor skala. Men med væksten af holdet og produktet bliver denne egenskab en af de vigtige.

denne artikel er opdelt i to dele. I anden del skal vi overveje tilgange til, hvordan man prioriterer kvalitetsattributter og besvarer spørgsmålet om, hvorfor det er så vigtigt at vælge de rigtige prioriteter.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.