kvalitetsattributter i Programvarearkitektur

Bilde 1. Monument Valley game

La oss fortsette å undersøke Programvarearkitektur. Vi vurderte hvem Som Er Programvarearkitekt, hvilke Typer Programvarearkitekter som finnes, og hva arkitekten skal gjøre i begynnelsen av et prosjekt. Når interessenter identifiseres, og krav samles inn, oppstår spørsmålet hva de skal gjøre neste gang. Etter at funksjonelle krav er formulert – eller svaret på spørsmålet «HVA systemet skal gjøre» er funnet, begynner programvarearkitekten å søke etter svaret på spørsmålet » HVORDAN systemet skal fungere.»Ikke-funksjonelle krav hjelper i så fall .

  1. Veien til Å Bli Programvarearkitekt
  2. Interessenter I Programvarearkitektur
  3. Typer Programvarearkitekter
  4. kvalitetsattributter I Programvarearkitektur
  5. Dokumentasjon I Programvarearkitektur
  6. Sertifikater I Programvarearkitektur
  7. Bøker I Programvarearkitektur
  8. system design cheat sheet

Hva Er De Ikke-Funksjonelle Kravene?

Ikke-funksjonelle krav (NFRs) definerer kriteriene som brukes til å evaluere hele systemet, men ikke for en bestemt oppførsel, og kalles også kvalitetsattributter og beskrevet i detalj i arkitektoniske spesifikasjoner.

Alle NFRs kan deles inn i to hovedkategorier:

  • NFRs som påvirker systemadferd, design og brukergrensesnitt under arbeid.
  • NFRs som påvirker utviklingen og støtten til systemet.

en situasjon der systemet har den ønskede kombinasjonen av kvalitetsattributter, for eksempel brukervennlighet og ytelse eller pålitelighet, viser suksessen til arkitekturen og kvaliteten på programvaren. Når du designer for å møte eventuelle krav, er det viktig å vurdere virkningen på andre attributter og finne kompromisser mellom krav. Sammen med dette varierer verdien eller prioriteten til hvert attributt fra system til system. Denne artikkelen dekker ikke alle eksisterende attributter, men de dekket kan være en god start for å designe systemet.

kvalitet attributter typer (ISO/IEC FCD 25010 diagram)

for å vurdere hvilke typer kvalitet attributter, kan vi bruke et diagram FRA ISO 25010:

Bilde 2. ISO / IEC FCD 25010 diagram

denne standarden beskriver kvalitetsattributtene til et programvareprodukt. Deretter ser vi på hva hvert attributt betyr individuelt.

Ytelse viser systemets respons til å utføre bestemte handlinger i en viss periode.

det er to måter å måle ytelse på:

  • Ventetid: tid brukt på å svare på en hendelse
  • Kanalkapasitet. Antall hendelser som oppstår på et bestemt tidspunkt.

i praksis inkluderer de mulige resultatindikatorene for eksempel:

  • Gjennomsnittlig / maksimalt antall systembrukere per tidsenhet.
  • Gjennomsnittlig lastetid på siden.
  • Gjennomsnittlig kjøretid for metoden.

her finner du interessante latensnumre som alle utviklere burde vite.

Ytelsesproblemer utvikler seg ofte til problemer som kan påvirke alt, fra serverens kapasitet eller hvordan du utvikler frontenden til effektiviteten av databasespørringer eller kapasiteten til kommunikasjonskanaler.

Ytelse er nesten alltid inkludert i listen over kritiske kvalitetsattributter som må vurderes av arkitekten, siden det påvirker hele systemet og kan påvirke mange deler av den arkitektoniske løsningen. Derfor, på internett, kan du finne et stort antall eksempler på hvordan du skal håndtere ytelsesproblemer.

Interoperabilitet er et attributt til systemet eller en del av systemet som er ansvarlig for driften og overføringen av data og utvekslingen med andre eksterne systemer. Et godt designet system muliggjør integrasjon med tredjepartssystemer. For å forbedre interoperabiliteten kan du bruke godt utformede eksterne grensesnitt, standardiseringssystemer etc.

Naturligvis er det Mange problemer for samhandling:

  • Utdaterte eksterne systemer.
  • Ulike formater av data i lignende eksterne systemer.
  • Ulike versjoner AV API i eksterne systemer.
  • Bakoverkompatibilitet AV API for integrasjon.
  • Dårlig kvalitet og mangel på standarder for eksterne systemer.

Interoperabilitet kan ikke ignoreres. I beste fall må du opprette flere lag for interaksjons-API. I verste fall vil det være nødvendig å gjenoppbygge hele systemet.

Brukervennlighet er en av de viktigste egenskapene, fordi, i motsetning til i tilfeller med andre attributter, kan brukerne se direkte hvor godt denne egenskapen til systemet er utarbeidet. Et av de kritiske problemene med brukervennlighet er for mye samhandling eller for mange handlinger som er nødvendige for å utføre en oppgave. Feil sekvenser av trinn i flertrinns grensesnitt er også et problem med brukervennlighet. Dataelementer og kontroller kan utformes ikke i henhold til de aksepterte mønstrene for brukeropplevelsen, noe som også kompliserer samspillet. Hvis du for eksempel utvikler et iOS-program, er det viktig å bruke retningslinjene Fra Apple, eller retningslinjene Fra Microsoft-for windows-skrivebordsprogrammer.

Eksempler på viktige indikatorer for dette attributtet er:

  • Liste over støttede enheter, OS-versjoner, skjermoppløsninger og nettlesere og deres versjoner.
  • Elementer som akselererer brukerinteraksjon, for eksempel «hurtigtaster»,» lister over forslag » og så videre.
  • gjennomsnittlig tid en bruker trenger for å utføre individuelle handlinger.
  • Støtte for tilgjengelighet for funksjonshemmede.

Pålitelighet Er et attributt til systemet som er ansvarlig for evnen til å fortsette å operere under forhåndsdefinerte forhold. Ofte mislykkes systemet på grunn av utilgjengelighet av eksterne elementer, for eksempel databaser, systemer og nettverkstilkoblinger.

Tilgjengelighet er en del av pålitelighet og uttrykkes som forholdet mellom tilgjengelig systemtid og total arbeidstid. Viktige indikatorer for dette attributtet er:

  • Tilgjengelighet.
  • Planlagt nedetid.
  • tiden som trengs for å oppdatere programvaren, og så videre.

Tilgjengelighet uttrykkes ofte i antall nines etter komma, det vil si nines av tilgjengelighet (timer / minutter / sekunder):

  • 2 9 s (99%) = opptil 87.6 h / 5256.0 m / 315360.0 sekunder nedetid per år.
  • 3 9 ‘ s ( 99.9%) = opptil 8.76 h / 525.6 m / 31536.0 sekunder nedetid per år.
  • 4 9 ‘ er ( 99,99%) = opptil 0,876 h / 52,559999999999995 m / 3153,6 sekunder nedetid per år.
  • 5 9 ‘ s ( 99.999%) = opptil 0.0876 h / 5.256 m / 315.36 sekunder nedetid per år.
  • 6 9 ‘ s ( 99.9999%) = opp til 0.00876 h / 0.5256000000000001 m / 31.536 sekunder nedetid per år.
  • 7 9 (99,99999%) = opptil 8,76 E-4h / 0,05256 m / 3,1536 sekunder nedetid per år.

tilgjengelighet er for eksempel et av hovedkriteriene for nivårangeringen av datasentre i USA.

Sikkerhet er ansvarlig for systemets evne til å redusere sannsynligheten for ondsinnede eller utilsiktede handlinger, samt muligheten for tyveri eller tap av informasjon. Flere tiltak brukes til å beskytte systemer: autentisering, kryptering, revisjon og andre.

Eksempler på dette attributtet i systemets arbeid er:

  • systemets evne til å oppdage DDoS-angrep og svare på dem.
  • Begrensninger av brukertilgang ved godkjenning / autorisasjon.
  • Forebygging AV SQL-injeksjon.
  • Kryptering av passord og innhold.
  • Sikker tilkobling.

Vedlikehold Er systemets evne til å støtte endringer. Endringer kan relateres til nye forretningskrav eller korrigering av gamle feil og påvirke systemkomponenter eller separate metoder. Vedlikehold påvirker også tiden som trengs for å gjenopprette systemet etter en feil. Overdreven avhengighet mellom komponenter har en svært negativ effekt på vedlikehold. I programmering er det et begrep om anti-mønster spaghetti kode, noe som betyr overdreven sammenheng i koden. I arkitektur er det ikke noe slikt, men arkitektur er svært nær programmering i denne forstand. Det er på grunn av vedlikeholdsattributtet at slike begreper som ansvarsfordeling, mikroservicearkitekturer og modularitet har dukket opp. Samtidig påvirker dette attributtet ikke bare utviklingsprosesser, men også styringsprosesser (for eksempel splitting av lag i produktrelaterte deler).

Modifiserbarhet bestemmer hvor mange vanlige endringer som må gjøres i systemet for å gjøre endringer i hvert element. Idealet er tilfellet der hver endring bare påvirker ett element.

Testbarhet viser hvor godt systemet tillater å utføre tester, i henhold til forhåndsdefinerte kriterier. I tillegg til testytelse gjør testbarhet det mulig å effektivt dele systemet i delsystemer.

hovedindikatorene for dette attributtet er:

  • Prosentandel av dekning med modulære, integrasjon eller enhetstester.
  • den endelige listen over nødvendige testmiljøer samt den endelige listen over brukte tilnærminger til testing(manuell / automatisk, regresjon, integrasjon, etc.).

Andre grunnleggende kvalitetsattributter dekkes ikke av standarden, men kan ikke ignoreres i denne artikkelen.

Skalerbarhet er systemets evne til å håndtere lastøkninger uten å redusere ytelsen, eller muligheten til raskt å øke belastningen.

det er to måter å forbedre skalerbarheten på:

  • Vertikal: For å øke, legger vi til flere ressurser, for eksempel minne, disker eller prosessorer i ett system.
  • Horisontal: vi øker antall databehandlingsenheter og deler belastningen.

nøkkelindikatorene for måling av dette attributtet er:

  • hvis systemet tillater horisontal skalering.
  • tiden det tar å øke skaleringen, i løpet av sekunder.
  • Skaleringsbegrensninger: antall servere eller nettverkskapasitet.
  • mulighet for å skalere: økningen i antall transaksjoner eller mengden innhold.

Og Dette er Bare en liten del av indikatorene som du må følge når du designer. Skalerbarhet er en av de viktigste egenskapene, uansett hva som er prosjektets stadium.

Gjenbrukbarhet Er en mulighet for å bruke en komponent eller et system i andre komponenter / systemer med liten eller ingen endring. Segregering av ansvar, modularisering, reduksjon av kopi-lim handler om gjenbruk. Kopiering av kode, eller verre, ved hjelp av forskjellige komponenter for samme resultat i forskjellige moduler, er et av de største problemene med gjenbrukbarhet.

Supportability Er systemets evne til å gi nyttig informasjon for å identifisere og løse problemer. Hovedproblemene for å sikre støttbarhet kan løses med følgende midler:

  • ingen diagnose: hvordan aktiviteten og ytelsen til systemet styres. Den inneholder ulike typer logging.
  • Ingen verktøy for feilsøking: dette inkluderer sikkerhetskopier, ulike systemer for å lage øyeblikksbilder av systemet, og verktøy for revisjon av systemet. Når systemet mislykkes, er det alltid mer behagelig å vente på en automatisk omstart enn å løse problemet manuelt.
  • ingen helsekontroll: dette inkluderer en rekke systemer for måling av kompileringstid, distribusjonstid, databasestørrelse eller mobilapplikasjonsstørrelse.

oftest er disse ikke vurdert i oppstart eller små prosjekter i utgangspunktet. Kostnaden for å opprettholde supportability-attributtet er høy, og resultatet er kun synlig i stor skala. Men med veksten av teamet og produktet blir dette attributtet en av de viktigste.

denne artikkelen er delt inn i to deler. I den andre delen, la oss vurdere tilnærmingene til hvordan man prioriterer kvalitetsattributter og svarer på spørsmålet om hvorfor det er så viktig å velge de riktige prioritetene.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.