6.1 Dekomponering
Til tross for mangfoldet av kriterier, er hovedoppgaven i utviklingen av store systemer oppgaven med å redusere kompleksiteten til systemet . For å redusere kompleksiteten er det ennå ikke funnet opp noe annet enn oppdeling i deler.
Noen ganger, for enkelhets skyld, kalles dette prinsippet om "del og hersk", men fra programvarearkitektens synspunkt snakker vi om hierarkisk dekomponering .
Et komplekst system må bygges opp fra et lite antall enklere delsystemer, som hver i sin tur er bygget opp av mindre deler, og så videre til de minste delene er enkle nok til å bli direkte forstått og skapt.
Den gode nyheten er at denne løsningen ikke bare er den eneste kjente, men også universell. I tillegg til å redusere kompleksiteten, gir det samtidig systemfleksibilitet , god skalerbarhet og økt motstandskraft ved å duplisere kritiske deler.
Følgelig, når det gjelder å bygge programmets arkitektur, skape dets struktur, betyr dette å dekomponere programmet i delsystemer, tjenester, lag, subrutiner og funksjonelle moduler og organisere deres interaksjon med hverandre og omverdenen.
Og det mest verdifulle her er dette: jo mer uavhengige delsystemene er, desto tryggere er det å fokusere på utviklingen av hver av dem separat på et bestemt tidspunkt og ikke bekymre deg for alle de andre delene.
6.2 Fordeler med modulær arkitektur
Ved å bruke prinsippet om hierarkisk dekomponering kan du bli kvitt kaos i tusenvis av klasser av koden din. Husker du at koden din er delt inn i pakker (pakke) og underpakker? Dette er et av uttrykkene for hierarkisk dekomponering.
Programmet ditt blir fra en haug med klasser til et sett med biblioteker og moduler som samhandler med hverandre i henhold til veldefinerte og enkle regler. Dette lar deg igjen kontrollere kompleksiteten, og gir deg også muligheten til å få alle fordelene som vanligvis er forbundet med konseptet med en god arkitektur.
Her er de mest grunnleggende:
- Skalerbarhet - muligheten til å utvide systemet og øke ytelsen ved å legge til nye moduler.
- Vedlikehold - endring av en modul krever ikke endring av andre moduler.
- Utskiftbarhet av moduler (Swappability) - modulen kan enkelt byttes ut med en annen.
- Enhetstesting – En enhet kan løsnes fra alle andre og testes/repareres .
- Gjenbrukbarhet - modulen kan gjenbrukes i andre programmer og andre miljøer.
- Vedlikehold – et program som er delt inn i moduler er lettere å forstå og vedlikeholde.
Det kan sies at å bryte et komplekst problem i enkle fragmenter er målet for alle designteknikker . Og begrepet "arkitektur" refererer i de fleste tilfeller ganske enkelt til resultatet av en slik oppdeling pluss "noen designbeslutninger som, når de er vedtatt, er vanskelige å endre" (Martin Fowler "Architecture of Enterprise Software Applications").
Derfor koker de fleste definisjoner i en eller annen form ned til følgende:
" Arkitektur identifiserer hovedkomponentene i systemet og hvordan de samhandler. Det er også valget av slike beslutninger som tolkes som grunnleggende og ikke kan endres i fremtiden ."
" Arkitektur er organiseringen av et system, nedfelt i dets komponenter, deres forhold til hverandre og med miljøet. Et system er et sett med komponenter kombinert for å utføre en bestemt funksjon. "
En god arkitektur er derfor først og fremst en modulær / blokkarkitektur . For å få en god arkitektur, må du vite hvordan du skal dekomponere systemet på riktig måte. Dette betyr at det er nødvendig å forstå hvilken dekomponering som anses som "riktig" og hvordan det er best å gjennomføre det.