6.1 Разлагане

Въпреки разнообразието от критерии, основната задача при разработването на големи системи е намаляването на сложността на системата . За да се намали сложността, все още не е измислено нищо друго освен разделяне на части.

Понякога, за простота, това се нарича принципът на "разделяй и владей", но от гледна точка на софтуерния архитект говорим за йерархична декомпозиция .

Една сложна система трябва да бъде изградена от малък брой по-прости подсистеми, всяка от които на свой ред е изградена от по-малки части и така нататък, докато най-малките части станат достатъчно прости, за да бъдат директно разбрани и създадени.

Разграждане

Страхотната новина е, че това решение е не само единственото известно, но и универсално. В допълнение към намаляването на сложността, той едновременно осигурява гъвкавост на системата , добра скалируемост и повишена устойчивост чрез дублиране на критични части.

Съответно, когато става въпрос за изграждане на архитектурата на програмата, създаване на нейната структура, това означава декомпозиране на програмата на подсистеми, услуги, слоеве, подпрограми и функционални модули и организиране на тяхното взаимодействие помежду си и с външния свят.

И най-ценното тук е следното: колкото по-независими са подсистемите, толкова по-безопасно е да се съсредоточите върху развитието на всяка от тях поотделно в определен момент и да не се тревожите за всички останали части.

6.2 Предимства на модулната архитектура

Използването на принципа на йерархичното разлагане ви позволява да се отървете от хаоса в хиляди класове на вашия code. Не забравяйте, че вашият code е разделен на пакети (package) и подпакети? Това е един от изразите за йерархична декомпозиция.

Вашата програма се превръща от куп класове в набор от библиотеки и модули, които взаимодействат помежду си според добре дефинирани и прости правила. Това от своя страна ви позволява да контролирате нейната сложност, а също така ви дава възможност да получите всички предимства, които обикновено се свързват с концепцията за добра архитектура.

Ето най-основните:

  • Мащабируемост - възможност за разширяване на системата и повишаване на нейната производителност чрез добавяне на нови модули.
  • Поддръжка - смяната на един модул не изисква смяна на други модули.
  • Сменяемост на модулите (Swappability) - модулът може лесно да бъде заменен с друг.
  • Тестване на модул – Един модул може да бъде отделен от всички останали и тестван/ремонтиран .
  • Повторна употреба - модулът може да се използва повторно в други програми и други среди.
  • Поддръжка - програма, която е разделена на модули, е по-лесна за разбиране и поддръжка.

Може да се каже, че разбиването на сложен проблем на прости фрагменти е целта на всички техники за проектиране . А терминът „архитектура“ в повечето случаи просто се отнася до резултата от такова разделение плюс „някои дизайнерски решения, които веднъж приети, са трудни за промяна“ (Мартин Фаулър „Архитектура на корпоративни софтуерни applications“).

Следователно повечето определения под една or друга форма се свеждат до следното:

" Архитектурата идентифицира основните компоненти на системата и How те си взаимодействат. Също така изборът на такива решения се тълкува като фундаментален и не подлежи на промяна в бъдеще ."

" Архитектурата е организацията на система, въплътена в нейните компоненти, тяхната връзка помежду си и с околната среда. Системата е набор от компоненти, комбинирани за изпълнение на специфична функция. "

По този начин добрата архитектура е преди всичко модулна/блокова архитектура . За да получите добра архитектура, трябва да знаете How правилно да разложите системата. Това означава, че е необходимо да се разбере кое разлагане се счита за „правилно“ и How е най-добре да се извърши.