Дәріс. Архитектуралы жобалау

Қ азіргі кезде IT-индустрияда программалық архитектуралар мен оларды жобалау дисциплина қ арқ ынды дамуда. Енді біз барлық профессионалды ө ң деушілерге тү сінікті болатын, жоғ арғ ы дең гейлі жә не тө менгі дең гейлі архитектура терминдері жайында айта аламыз.

Кез келген қ осымша аппараттық жә не программалық компоненттерден тұ рады. Жү йелік ө ң деу – қ осымшаларды аппараттық пен программалық компоненттерге бө летін жобалау жә не талдау ү рдісі. Бұ л декомпозицияның кейбір аспектілері тапсырыс берушінің талаптарымен басқ арылады, ө згелерін ө ң деушілер анық тайды.

Жү йелік ө ң деу ү рдісі жалпы жү йелік талаптарды анық таудан басталады. Содан аппараттық жә не программалық қ амтама арасындағ ы тиімді қ атынас таң далынады. Содан кейін программалық бө ліміне ө ң деу технологиясы талаптарды талдаудан бастап, тағ ы басқ аларына пайдаланылады.

Программаның архитектурасын қ ұ ру деген – ең жоғ арғ ы джең гейде жобалау. Жобалау ү рдісінің қ алғ ан бө лігін бө лшекті жобалау деп атайды.

Программалық қ амтама жү йесінің принциптік проблемасы – бұ л оның кү рделілігі. Кү рделілікке кү ресудің тиімді ә дісі – модуляризация немесе есептің ішкі есептерге декомпозициясы болып табылады. Декомпозицияның орындалуының критериіне - байланыстылық пен (сцепление) сияқ ты сипаттамалары жатады. Модуль ішіндегі байланыстылық деген ол – модуль элементтерінің арасындағ ы ө зара байланыс кү ші. Сцепление – модульдер арасындағ ы ө зара ә рекеттестік дә режесін сипаттайды. Тиімді модульдік - байланыстылық тың максимизациясы мен сцепление минимизациясы кезінде анық талады.

Сцепление аз мө лшері мен байланыстылық тың кө п мө лшерінің жиынтығ ы қ осымшаларды жобалаудың жиі ө згерістер енгізу кезінде маң ызды болып табылады. Тө мен сцепление жә не жоғ ары байанысты архитектуралар модификацияғ а бейімделген, ө йткені мұ ндай архиткетураларда ө згерістер локальді (жергілікті) тиімділікті береді. Алайда мұ ндай архитектураларды қ ұ ру ө те кү рделіболып табылады.

Мысал ретінде жеке қ аржылық қ осымша декомпозициясын қ арастырайық.

- Есептер (тексеру, сақ тау жә не т.б.);

- Есептер тө лемі (электронды, чектер жә не т.б.);

- Глобальді есептер (жалпы активтер, қ арыз жә не т.б.);

- Займ (қ арыз) (автомобиль, білім, ү й жә не т.б.);

- Инвестициялар (акциялар, қ арыз міндеттері жә не т.б.);

Бұ л декомпозиция пайдаланушы кө з қ арасына қ ызығ ушылық тудырғ анымен, онда архитектуралы декомпозиция сияқ ты ірі кемшілкітері бар. Мысалы, Есептерде ә лісіз байланыс болғ андық тан, байланыстылық ө те аз. Ал мұ нда модульдердің байланыстылығ ы ө те жоғ ары. Мысалы, қ арыз тө лемінде Есептер, Есептер тө лемі, Займ, Отчет модульдері қ атысқ ан.

Бұ л декомпозицияның келесі бір балама тү рі бар:

- Интерфейс (пайдаланушы жә не коммуникациялы интерфейс, есеп берушілік отчетность жә не т.с.с.);

- Жабдық таушылар (поставщики) (жалғ а беруші, пайызсыз қ арыз, коммуналдық қ ызметтер жә не т.б.);

- Активтер (есептерді тексеру, акциялар, қ арыз міндеттері жә не т.б.);

 

 

Жобалаудың модельдері, каркастар жә не ү лгілері

Модульдер компоненттеріне жоба декомпозициялары - маң ызды қ адам болады. Ал архитектураны қ ұ ру ө те ү лкен жұ мыс болып табылады. Бірінші, декомпозицияны пайдалану нұ сқ алары, класстар жә не кү йлерге ауысу модельдерімен байланыстыру керек.

Ә детте кез келген қ осымша бірнеше кө з қ арастармен, яғ ни бірнеше проекциялармен сипатталады. Программалау ә лемінде проекция - модельдер деп аталады. Олар:

Пайдалану нұ сқ асының моделі – қ осымшаның не істеу керек екенін тү сіндіретін нұ сқ алардың коллекциясы.

Класстар моделі – қ осымшалар қ ұ ратын блоктардың қ ұ растырылуын тү сіндіреді. Класстар моделінің (объектті моделінің) ішінде ә дістері мен атрибуттарын кө рсетуге болады.

Компоненттер моделі – мә ліметтер тасымалдау терминдерінде қ осымшаның қ алай жұ мыс істейтіндігін тү сіндіретін ағ ындық мә ліметтер диаграммасының коллекциясы.

Кү йлерге ауысу моделі – қ осымшаның жұ мысына кететін уақ ыт моментін анық тайтын кү йлерге ауысу диаграммасының коллекциясы.

Қ осымша архитектурасы модельдердің бір терминінде жиі айтылып, ө зге модельдерімен қ олдалады. Ә р архитектурада оны жү зеге асыра алатын кем дегенде бір класстар моделі бар.

Каркастар – бұ л бірнеше ә ртү рлі қ осымшаларда пайдаланылатын класстар коллекциясы. Каркастың ішіндегі класстар ө зара байланысты болып келеді. Олар абстракті бола алады, жә не олар мұ рагарлікпен қ олданыла алады.

Осылайша, қ осымша класстарының моделі талаптарды талдаудан, пә ндік область (ортадан) пайда болады. Каркас класстары біз жобалап жатқ анғ а ұ қ сас қ осымшаларғ а архитектураларды ө ң деу арқ ылы жү зеге асады. Осылайша, каркас класстары бұ рын болғ ан пакеттің бө лігі немесе архитектура талдау ү рдісінде ө ң делгені болып келеді. Жобалау класстары – жобалауды аяқ тауғ а қ осылғ ан, қ алғ ан класстар.

Жобалау ү лгісі – тә жірибелі жолмен табылғ ан, анық талғ ан, жобаланғ ан жалпы есептерді шешетін компоненттер комбинациясы, ә детте класстар немесе объекттер комбинациясы.Барлық жобалау ү лгілері – қ ұ рылымдық, креакциялық, тә ртіптік категорияларғ а бө лінеді. Қ ұ рылымдық ү лгілер объектілерді кө рсету ә дістерімен байланысты креакциялық........24бет

Компоненттер – программалық қ амтама жайында білімді қ ажет етпейтін қ айталанылатын объектілер. Мысалы, COM жә не Java Beans. Бір компоненттерді басқ а компоненттер агрегациялау арқ ылы пайдаланады жә не олар негізінде оқ иғ алармен ө зара қ атынасады.