Дәріс.

Практикалық жұмыс №7

Зертханалық жұмыс№7

Дәрiс

Диаграммалар

UML-дағы диаграмма – бұл элементтер жиынтығының графикалық көрінісі, төбелермен(болмыстармен) және қабырғалармен (қатынастармен) граф түрінде жиі бейнеленеді.

Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма – в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы. Таким образом, в UML выделяют девять типов диаграмм:

Диаграммалар әр түрлі көру нүктелерінен жүйе визуализациясы үшін сурет салады. Диаграмма – кейбір мағынадағы бір жүйе проекциялары. Ереже сияқты, тривиалды оқиәалардан тыс, диаграммалар элементтердің оралған түсінігін береді, қайсылардан жүйе құрастырылған. Диаграмма теориялық тұрғыда болмыстар мен қатынастардың кез-келген комбинациясын құрай алады. Тәжірибеде, бірақ, типтік комбинацияның аз саны салыстырмалы қолданылады, ол бес ең тұтынушылық түрлерге сәйкес келеді, лдар бағдарламалық жүйенің архитектурасын құрастырады. Сайып келгенде, UML –да диаграммалардың тоғыз үлгісін белгілейді :

ü класстар диаграммасы;

ü диаграммы объектов;

ü диаграммы прецедентов;

ü диаграммы последовательностей;

ü диаграммы кооперации;

ü диаграммы состояний;

ü диаграммы действий;

ü диаграммы компонентов;

ü диаграммы развертывания.

UML тілінде қатынастың төрт типі анықталған:

· тәуелділік;

· ассоциация;

· жалпылау;

· жүзеге асыру.

Тәуелділік (Dependency) – екі болмыс арасындағы семаникалық қатынас, осыдан олардың біреуінің өзгерісі тәуелсіздің, тәәуелдіге әсер етуі мүмкін. Графикалық белгілеуі: түзу пунктир сызық түрінде, жиі белгісі бар болатын тілшемен.

Ассоциация (Association) – құрылысты қатынас, байланыстардың жиынтығын суреттеуші; байланыс - бұл объектілер арасындағы бірігу. Асоцияцияның түрлігі агрегирлеу болып табылады (Aggregation)- қўрылысты дәл осылай жиі оның бүтін және жеке бөлімдер арасындағы қатынасты атайды. Графикалық белгілеуі: түзу сызық түрінде (кейде аяқталатын тілмен немесе таңба ұстаушы), қайсының жанында қосымша белгілеулері қатыса алады, мысалы еселілік және рольдердің аттары

Жалпылау (Generalization) – бұл «мамандандыру|жалпылау» қатынасы, қайсыда мамандандырылған элемент объектісі (ұрпақ) жалпыланған элемент объектісінің орнына қойылуы мүмкін (ата-анасының немесе атасының). Осылайша ұрпақ (Child) өзінің ата анасы (Parent) тәртібін мұра етеді. Графикалық белгілеу: боялмаған тілмен пен сызық түрінде, ата-анасына белгілейтін.

Жүзеге асыру (Realization) – бұл топтастырғыштар арасындағы семантикалық қатынас, қайсыда бір топтастырғыш «келісімді» анықтайды, ал басқасы оның орындалуына кепіл болады. Орындау қатынастары екі жағдайда кездеседі: біріншіден, интерфейстер және оларды іске асырушы класпен немесе компоненттер арасындағы, ал - екіншіден, прецеденттер және олардың іске асырушы кооперация арасында. Графикалық белгілеуі: пунктир сызық түрінде боялмаған тілмен, қандай да бір жалпылау және тәуелділік қатынасының ортасы сияқты.

Төрт суреттелген элементтер UML үлгісіне қосуға болатын қатынастардың негізгі типтері болып табылады. Олардың сонымен қатар вариациясы (Refinement) да, трассировка (Trace), қосу және кеңейту де (тәуелділіктерге арналған) бар болады.

Диаграммалар

UML-дағы диаграмма – бұл элементтер жиынтығының графикалық көрінісі, төбелермен(болмыстармен) және қабырғалармен (қатынастармен) граф түрінде жиі бейнеленеді.

Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма – в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы. Таким образом, в UML выделяют девять типов диаграмм:

Диаграммалар әр түрлі көру нүктелерінен жүйе визуализациясы үшін сурет салады. Диаграмма – кейбір мағынадағы бір жүйе проекциялары. Ереже сияқты, тривиалды оқиәалардан тыс, диаграммалар элементтердің оралған түсінігін береді, қайсылардан жүйе құрастырылған. Диаграмма теориялық тұрғыда болмыстар мен қатынастардың кез-келген комбинациясын құрай алады. Тәжірибеде, бірақ, типтік комбинацияның аз саны салыстырмалы қолданылады, ол бес ең тұтынушылық түрлерге сәйкес келеді, лдар бағдарламалық жүйенің архитектурасын құрастырады. Сайып келгенде, UML –да диаграммалардың тоғыз үлгісін белгілейді :

· класстар диаграммасы;

· диаграммы объектов;

· диаграммы прецедентов;

· диаграммы последовательностей;

· диаграммы кооперации;

· диаграммы состояний;

· диаграммы действий;

· диаграммы компонентов;

· диаграммы развертывания.

UML тілінің жалпы механизмдері

UML тілімен жұмысы жалпы механизмдардың жүйелі қолдануы кезінде маңызды жеңілденеді:

· спецификацияны (Specifications);

· қосымшаны (Adornments);

· қабылданған бөлудің (Common divisions);

· кеңейту механизмдері (Extensibility mechanisms).

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

UML өсиетінің әрбір элементі оған арналған соған арнап түрлі спецификалық толықтырулар қосуға болатын базалық символ құрайды.

Қабылданған бөлулер. Объектті-бағытталған жүйелерді модельдеу кезінде шынайылық ең құрығанда екі ыңғайды есепке алумен бөлінеді: «класстар/объекттер» және «интерфейс/жүзеге асыру». Практикалық барлық құрылыс блоктары UML «класс/объект» дихотомиясымен сипатталады. Осылай, прецендент экземпляры мен компоненттер және компонент экземплярв, түйіндер және түйіндер экземпляры бар болады. Графикалық көріністе объект үшін оның класындағы символды қолдану қабылданған, ал атауды белгілеу қажет. Осылайша UML-дың құрылыс блоктары «интерфейс/жүзеге асыру» дихотомиясымен сипатталады. Мысалы, прецеденттер кооперациямен жүзеге асырылады, ал операциялар – әдістермен.

Кеңейту механизмдері, UML – бағдарламалық қаматамасыз етудің «сызбаларын» өңдеуге арналған стандартты тіл, бірақ тұйық тілдің ешқайсысы барлық мүмкін модельдердің нюанстарын түрлі пәндік облыста қамти алмайды. Сондықтан UML ашық тіл болып табылады, яғни бақыланатын кеңейтілулерді өткізеді. UML кеңейту механизмдері қосады:

· стереотиптер;

· белгіленген мәндер;

· шектеулер.

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

Белгіленген мәндер (Tagged value) элементтің жаңа ақапарты мен спецификаын қоса UML құрылыс блоктарының қаситін кеңейтеді. Мысалы, қандай да бір маңызды абстракцияның нұсқасы мен авторын қандай да бір блокқа, мысалы класс ретінде белгіленген мәндерді белгілей отырып қосуға болады.

Шектеулер (Constraints) жаңа немесе қолданыстағы ережелерді анықтауға мүмкіндік беретін UML құрылыс блоктарының семантикасын кеңейтеді.

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

Бақылау сұрақтары:

1. Кәсіпорын кассасының жұмысы үшін класстар диаграммасын құрастырыңыз: бухгалтериядан кассаға жалақының берілуі жайында тізім түседі, бұл тізім негізінде қызметкерлерге жалақы беріледі және тізімге арнайы белгі қойылады, біткеннен кейін тізім бухгалтерияға қайтарылады;

2. Тұрмыстық-коммуналдық қызметтерді есептеу жұмыстарына арналған класстар дтаграммасын құрастырыңыз. ТКҚ бухгалтериясы алдымен тұрғын үйдін, жылу мен су есепақысын жібереді, кейін пәтер жалдаушылардікін жібереді. Пәтер жалдаушы ақысын төлеген уақытта ғана төленді деп белгіленеді. Ай сайын пәтер жалдаушыға айтылған ұйымның ұсынысын жіберіп отырады;

3. Жинақ банкінің бөлімшесінде жаңа есептеу шотын ашуға арналған класстар диаграммасын құрастырыңыз: клиент жаңа есептеу шотын ашуға арналған құжаттарды толтырып кассирға береді, кассир дұрыстығына тексеріп жаңа есептеу шотын ашады. Сосын клиенттің берген ақшасын сол есептеу шотына салады;

4. Телефон есептеулері бойынша бөлiмнiң жұмысына арналған класстар диаграммасын құрастырыңыз. АТЖ абонент бөлімшесі телефонға абонплатаны есептеп шығарады, қала аралық келiссөздер сомасын артып, содан соң абонентке есеп жазады. Абонент ақысын төлеген уақытта ғана төленді деп белгіленеді. Ай сайын абонентке ұйымның ұсынысын жіберіп отырады және қарыздар адамдардың тізімін шығарады, телефонның сөндірілуі туралы хабарланады;

5. Пәтер айырбастаумен айналысатын ұйымға арналған класстар диаграммасын құрастырыңыз. Менеджер клиеттен пәтер айырбастауы жайында мәлімдеме қабылдайды, оны деректер қорына тіркейді. Мәлімдемедегі талаптарға негізделіп, сәйкесінше айырбас пәтерлер қарастырылады. Қарастырылған пәтерлер тізімі клиентке көрсетіледі.

Қолданылған әдебиеттер тiзiмi

1. Леоненков А.В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2012;

2. Слайд Мухаметжанова Б.О. Жасанды зерде жүйелеріне кіріспе – ҚарМТУ- Қ.Р. Тұнғыш Президенті атындағы ЭОТ ғЗИ – Сертификат № 3895 2011ж.;

3. Мухаметжанова Б.О., Когай Г.Д. Деректерді өңдеу құрылымдары мен әдістері: Оқу құралы- Қарағанды ҚарМТУ баспасы 2011-110б;;

4. Мухаметжанова Б.О.Автоматтандырылған жүйелердің теориялық негіздері– ҚарМТУ- ң.Р. Тұнғыш Президенті атындағы ЭОТ ғЗИ – Сертификат № 2711 2010ж.;

5. Боггс У., Боггс М. UML и Rational Rose - М.: "ЛОРИ", 2012. - 582 с.

Практикалық жұмыс №7

Жұмыс мақсаты:

Windows хаттарын өңдеудің, көпағынды және ақпарат алмасу бағдарламаларын жасаудың тәжірибелік дағдысын алу.

СӨЖ үшін тапсырма:

1. Барлық модификацияларды есепке енгізу;

2. Есептеу нәтижесінің мазмұны;

3. Міндетті белгілеу;

4. Талаптар ерекшелігі;

5. Мәліметтер құрылымы;

6. Бағдарламалық қамтамасыз етудің архитектурасы;

7. Қолданушы интерфейсі;

8. Түсініктемесі бар код.

Сабаққа дайындалуға арналған әдістемелік нұсқаулар

Әдебиеттер:

1 Покушалова, Л.В. Метод case - study как современная технология профессионально-ориентированного обучения студентов [Текст] / Л.В. Покушалова // Молодой ученый. —2011. —No5. Т.2. —С. 155-157.

2 Романов П.В. Стратегия кейс-стади в исследовании социальныхслужб//Социс,2005, No4, с 101-109.6.

3 Фливберг, Б. Кейс-стади в контексте качественно-количественнойпроблематики: Ст. из Дании] / Б. Фливберг // Социологические исследования. -2004. -No 9. -С. 15 –

4 Гагарина, Л.Г. Разработка и эксплуатация автоматизированных систем: учеб. пособие/ Л.Г. Гагарина, Д.В. Киселев, Е.Л. Федотова; ред. Л.Г. Гагарина. - М.: Форум: ИНФРА-М, 2011. - 384с. 2. Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: учеб. пособие для вузов/ В.Ю. Пирогов. - СПб. : БХВ-Петербург, 2009. - 528 с. 3.

5 Фуфаев, Д.Э. Разработка и эксплуатация автоматизированных информационных систем : учеб. Для студ. сред. проф. образования/ Д.Э. Фуфаев, Э.В. Фуфаев. - М.: Академия, 2010. - 304 с.б)

6 Федорова, Г.Н. Информационные системы : учебник/ Г.Н. Федорова. - 2-еизд., испр. - М.: Академия, 2011. - 208 с.

Қосымша:

7 Ларман К. Применение UML и шаблонов проектирования. 2-е издание.: Пер. с англ. – М.: Издательский дом “Вильямс”, 2002. – 624 с.: ил.

8 Калянов Г.Н. CASE-технологии: Консалтинг в автоматизации бизнес-процессов. 2-е изд. перераб. и доп. - М.-Горячая линия – Телеком, 2000.-320 с.

9 Вендров А.М. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: Финансы и статистика, 2000.

10 Александров, Д.В. Инструментальные средства информационного менеджмента. CASE-технологии и распределенные информационные системы : учебное пособие / .В.Александров. -М. : Финансы и статистика, 2011. -225 с. -ISBN 978-5-279-03475-8;

11 http://www.bookwebmaster.narod.ru/uml.html

12 http://wm-help.net/books-online/book/57663/57663-53.html

Зертханалық жұмыс№7

Компоненттер диаграммасы

Жұмыстың мақсаты:

1. Жүзеге асыру диаграммаларын салып үйрену.

Өз бетінше дайындалуға арналған тапсырма:

1. Әзірленетін жүйе сәулетін анықтау;

2. Бағдарламалық компоненттер арасында тәуелділікті орнату;

3. Компоненттер диаграммасын әзірлеу;

4. Компоненттер диаграммасын салу және кеңсе тауарларына тапсырыс бойынша қолданба жобасын жасау мысалында Орналастыру технологиясын зерделеу ( ппо (кп).doc файлды қараңыз);

5. Компоненттер диаграммасын әзірлеу және UML тілінде Орналастыру технологиясын зерделеу;

6. Компоненттер диаграммасын салу және Ratoinal Rose бағдарламасында Орналастыру процесін зерделеу;

7. Жобаланатын бағдарламалық жүйеге «Эскиздік жоба» құжатын дайындау (оның толық көлемінің 100%).

## Жұмыстың мазмұны:

1. ДК №7 жаттығуды орындау;

2. ДК №8 жаттығуды орындау;

3. ДК №9 немесе №10 жаттығуды орындау;

4. Нұсқа бойынша жобаланатын бағдарламалық жүйе үшін Компоненттер және Орналастыру диаграммасын жасау.

##

## Есеп беру мазмұны:

1. Әзірленген Компоненттер мен Орналастыру диаграммаларын келтіру;

2. Берілген диаграммалардың әрбір элементін сипаттау.

##

## Әдістемелік нұсқаулар

Компоненттер диаграммасы

Бұрын қарастырылған барлық диаграммалар жүйе моделін салудың концептуалды аспектілерін бейнеледі және түсіндірудің логикалық деңгейіне жатты. Логикалық түсіндіру ерекшелігі, оның өз бетіндік материалдық іске асырылуы болмайтын ұғымдармен операция жасайды. Басқаша айтқанда, кластар, ассоциациялар, күй, хабарлама сияқты логикалық түсіндірудің түрлі элементтері материалдық немесе физикалық түрде болмайды. Олар тек физикалық жүйе құрылымын немесе оның тәртіп аспектілерін біздің түсінуімізді бейнелейді.

Логикалық түсініктің негізгі түсінігі жүйе моделінің элементтері арасында құрылымдық және функционалдық қатынастарды талдаудан тұрады. Алайда нақты физикалық жүйені құру үшін логикалық түсініктің барлық элементтерін нақты матреиалдық маңыздарға біршама түрде жүзеге асырудан тұрады. Осындай нақты маңыздарды сипаттау үшін модельдік түсініктің басқа аспектісі, атап айтқанда, модельді физикалық түсіндіру тағайындалған.

Логикалық және физикалық түсініктердің айырмасын анықтау үшін, кейбір бағдарламалық жүйені әзірлеу процесін жалпы түрде қарастырамыз. Оның бастапқы логикалық түсінігі ретінде алгоритмдер мен рәсімдердің құрылымдық сұлбалары, интерфейстерді сипаттау және деректерсіз концептуалды сұлба қызмет ете алады. Алайда осы жүйені жүзеге асыру үшін кейбір бағдарламалау тілінде бағдарламаның бастапқы мәтінін әзірлеу қажет (C++, Pascal, Basic/VBA, Java). Осы кезде бағдарлама мәтінінде оны жеке модульдерге бөлуді болжайтын бағдарламалық кодты ұйымдастыру болжанады.

Дегенмен бағдарламаның бастапқы мәтіндері әлі жобаны түпкілікті жүзеге асыру юболып табылмайды және оны физикалық түсіндіру көрінісі ретніде қызмет етеді. Бағдарламалық жүйе, өзінің мақсаттық тағайыдалу функцияларын орыдауға қабілетті болған жағдайда жүзеге асырылған деп саналады. Ал бұл, тек егер жүйенің бағдарламалық коды орындалатын модульдер, кластар мен құрылмдар кластары, стандартты графиктік интерфейстер, деректер базалары файлдары түрінде жүзеге асырлған жағдайда мүмкін болады. нақ осы компоненттер жүйені физикалық түсіндірудің қажетті элементтері болып табылады.

Осылайша, бағдарламалық жүйенің толық жобасы логикалық және физикалық түсіндіру модельдерінің жиынтығы болып табылады, олар өзара келісілген болуы керек. UML тілінде жүйе модельдерін физикалық түсіндіру үшін жүзеге асыру диаграммалары (implementation diagrams) пайдаланылады, оларға екі жеке канондық диаграмма енеді: компоненттер диаграммасы және жаю диаграммасы. Олардың біріншсін салу ерекшеліктері осы тарауда қарастырылады, ал екіншісі – келесіде.

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

Компоненттер диаграммасы келесі мақсаттар үшін әзірленеді:

 Бағдарламалық жүйенің бастапқы кодының жалпы құрылымын көзбен шолу;

 Бағдарламалық жүйенің орындалатын нұсқасының спецификациясы;

 Бағдарламалық кодтың жеке көріністерін көп реттік пайдалануды қамтамасыз ету;

 Деректер базаларының концептуалды және физикалық сұлбаларын түсідіру.

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

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

Компоненттер

UML тілінде физикалық маңыздарды түсіндіру үшін арнайы термин — компонент (component) қолданылады. Компонент реализует некоторый набор интерфейстердің кейбір жинағын жүзеге асырады және модельді физикалық түсіндіру элементтерін жалпы белгілеу үшін қызмет етеді. Компонентті графиктік түрде түсіндіру үшін арнайы символ – сол жақта екі біршама ұсақ тік бұрыштары бар тьік бұрыш пайдаланылуы мүмкін (2.1-сурет). Қамтитын тік бұрыш ішінде компонент атауы жазылады және кейбір қосымша ақпарат болуы мүмкін. осы символды бейнелеу компонентпен ассоциацияланатын ақпарат сипатына байланысты болмашы өзгеруі мүмкін.

UML тілі метамоделінде компонентжіктегеші ұрпағы болып табылады. Ол физикалық пакет шеңберінде онымен ассоциацияланатын модель элементтерімен ұйымдастыру болып табылады. Жіктегіш ретінде компонентте атрибуттар мен операциялар сияқты өзінің жеке қасиеттері болуы мүмкін.

6.1-сурет - UML тілінде компонентті гарфиктік бейнелеу

Сонымен, бірінші жағдайда (5.56, а-сурет) даа деңгейі компонентімен тек оның атауы ғана байланысады, ал екіншісімен (5.56, б-сурет) – қосымша пакет атауы және белгілеген мән.

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

Компонент атауы. Компонент атауы модель элементтерін UML тілінде аатудың жалпы ережелеріне бағынады және әріптердің, цифрлардың кез келге санынан және кейбір тыныс белгілерінен тұруы мүмкін. Жеке компонент тип деңгейінде немесе дана деңгейінде түсіндірілуі мүмкін. Оның графиктік бейнесі екі жағдайда да бірдей болғанмен, компонент атауын жазу ережесі біршама ерекшелене алады. Егер компонент тип деңгейінде түсідірілетін болса, онда оның атауы ретінде тек тип атауы ғана бас әріппен жазылады.

Егер де компонент дана деңгейінде түсіндірілетін болса, оның атауы ретінде <компонент атауы ':' тип атауыХ түрінде жазылады. Осы кезде атаудың барлық жолының асты сызылады

Объектілерді UML тілінде атау ережесі жеке даналардың атауларының астын сызуды талап еткенмен, әдебеитте компоненттерге қатысты олардың атауларының астын сызуды көбінесе босатады. Бұл жағдайда компонент атауын кіші әріппен жазу дана деңгейі компонентін сипаттайды.

Қарапайым атаулар ретінде орындалатын файлдардың атауларын (бөлгіш-нүктеден кейін ехе кеңеюді көрсету арқылы), динамикалық кітапханалар атаулары (dll кеңеюі), Web-беттердің атаулары (html кеңеюі), мәтіндік файлдардың (txt немесе doc кеңеюі) немесе анықтама файлдардың (hip) атаулары, деректер базасы файлдарының (DB) немесе бағдарламалардың бастапқы мәтіндері бар файлдардың атаулары (для языка C++ тілі үшін h, cpp кеңеюі, Java тілі үшін Java кеңеюі) атаулары, скрипттер (pi, asp) және т.б. пайдалану қабылданған.

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

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

Компоненттер түрі. Компонент физикалық жүзеге асыру элементі ретінде кодтың жеке модулі болып табылатындықтан, кейде оны жүзеге асыратын нақты ерекшеліктерді иллюстрациялайтын қосымша графиктік символдармен түсіндіреді. Қатаң айтқанда, осы қосымша мәндер ескертулер үшін UML тілінде спецификацияланбаған. Алайда оларды қолдану физикалық түсіндіру көрнектілігін айтарлықтай арттырып, компоненттер диаграммасын түсінуді жеңілдетеді. Осыдай жалпы қабылданған белгілердің кейбіреуі компоненттерді белгілеу үшін төменде бейнелеген (5.57-сурет).

UML тілінде компоненттердің үш түрін бөліп алады.

 Біріншіден, өрбіту компоненттері, олар жүйенің өз функциясын тікелей орыдауын қамтамасыз етеді. Осындай компоненттер dll кеңеюімен динамикалық қосылатын кітапханалар (5.57, а-сурет), html кеңеюімен гипермәтінді белгілеу тілінде Web-беттер (5.57, б-сурет) және Ыр кеңеюімен анықтама файлдары (6.2, в-сурет) болуы мүмкін;

 Екіншіден, компонент-жұмыс өнімдері. Ережеге сай — бұл бастапқы бағдарламалар мәтіндері бар файлдар, мысалы, C++ тілі үшін h немесе срр кеңеюімен (5.57, г-сурет);

 Үшіншіден, орындалатын модульдері болатын орындау компоненттері — ехе кеңеюі бар файлдар. Олар кәдімгі түрде белгіленеді.

6.2-сурет – Компоненттер диаграммасында компоненттерді графиктік бейнелеу нұсқалары

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

Компоненттердің әр түрлерін спецификациялаудың басқа тәсілдері —компонент стереотипін өзінің атауы алдында айқын көрсету. UML тілінде компоненттер үшін келесі стереотиптер анықталған:

 Кітапхана (library) — компоненттің бірінші алуан түрлілігін анықтайды, ол динамикалық немесе статикалық кітапхана түрінде беріледі;

 Кесте (table) — ол да компоненттің бірінші алуан түрлілігін анықтайды, ол деректер базасының кестесі түрінде беріледі;

 Файл (file) — компоненттің екінші алуан түрлілігін анықтайды, ол бағдарламалардың бастапқы мәтіндері бар файлдар түрінде түсідіріледі;

 Құжат (document) — компоненттің екінші алуан түрлілігін анықтайды, ол құжат түрінде беріледі;

 Орындалатын (executable) — компоненттің үшінші түрін анықтайды, ол түйіде орындалуы мүмкін.

Интерфейстер

Компоненттер диаграммасының келесі элементі интерфейстер болып табылады. Соңғылары бұрын бірнеше рет қарастырылды, сондықтан мұнда олардың компоненттер диаграммасында түсіндіруге тән ерекшеліктері белгіленеді. Жалпы жағдайда интерфейс графиктік түрде шеңбермен бейнеленеді, ол компонентпен стрелкасыз сызық кесіндісі арқылы қосылатыны еске саламыз (3.1, а-сурет). Осы кезде міндетті түрде "I" бас әрпінен басталуы тиіс интерфейс атауы шеңбермен қатар жазылады. Семантикалық түрде сызық интерфейстің жүзеге асырылуын білдіреді, ал компонентте интерфейстердің болуы, берілген компонент интерфейстердің сәйкес жинағын жүзеге асыратыын білдіреді.

6.3-сурет - Компоненттер диаграммасында интерфейстерді графиктік белгілеу

Компоненттер диаграммасында интерфейсті түсіндірудің басқа тәсілі оны "интерфейс" стереотипі және атрибуттар мен операциялардың ықтимал секциялары бар кластың тік бұрышы түрінде бейнелеу болып табылады (5.58, б-сурет). Ережеге сай, осы белгілеу нұсқасы интерфейстің ішкі құрылымын түсіндіру үшін пайдаланылады, ол жүзеге асыру үшін маңызды болуы мүмкін. а

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

Интерфейстердің жеке компоненттермен пайдалану сипаты ерекшеленуі мүмкін. Сондықтан интерфейс пен компонент байлаысының екі тәсілін ажыратады. Егер компонент кейбір интерфейсті жүзеге асыратын болса, онда мұндай интерфейсті экспортталатын деп атайды, себебі осы компонент оны басқа компоненттерге сервис ретінде түсіндіреді. Егер де басқа компонент жүзеге асыратын кейбір интерфейсті пайдаланатын болса, онда осындай интерфейс бірінші компонент үшін импортталатын деп аталады. Импортталатын интерфейс ерекшелігі, компоненттер диаграммасында осы қатынас тәуелділік көмегімен бейнеленеді.

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

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

Бірінші жағдайда компонент-клиенттен импортталатын интерфейске қарай стрелка салады (6.4-сурет). Осындай стрелканың болуы, компонент сәйкес интерфейсті жүзеге асырмайтынын, оны өзінің орындалу процесінде пайдаланатынын білдіреді. Оның үстіне осы диаграммада осы интерфейсті жүзеге асыратын басқа компонент қатысуы мүмкін. Сонымен, мысалы төменде бейнеленген компоненттер диаграммасының көрінісі "main.exe" атауы бар компонент I Dialog импортталатын интерфейске тәуелді екендігі туралы ақпарат береді, оны өз кезегінде "image.java" атауы бюар компонент жүзеге асырады. Осы интрефейстің екінші компоненті үшін экспортталатын болып табылады.

6.4-сурет - .тәуелділік қатынасындағы компоненттер диаграммасының көрінісі

"image.java" атауымен екінші компонентті ескерту нұсқасы түрінде, осы компоненттің интерфейсті жүзеге асыратын фактісіне қарай бейнелеуге болмайтыны байқаймыз.

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

6.5-сурет – Компоненттер арасында тәуелділіктер қатынасын графиктік бейнелеу

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

6.6-сурет - Компоненттер мен кластар арасында тәуелділікті графиктік бейнелеу

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

6.7-сурет - Компоненттің өздері жүзеге асыратын кластар туралы қосымша ақпараты бар графиктік бейнесі

Компонент символының ішінде графиктік нотацияның, кластар (тип деңгейінің компоненті) немесе объектілер (дана деңгейінің компоненті) сияқты басқа элементтері бейнеленуі мүмкін. Сонымен, мысалы, төменде бейнеленген компонент (6.8-сурет) дана болып табылады және үш жеке объектіні жүзеге асырады.

6.8-сурет – Жеке объектілерді жүзеге асыратын дана деңгейі компонентінің графиктік бейнеленуі

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

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

## Rational Rose ортасында компоненттер диаграммасын әзірлеу

Компоненттер диаграммасы модельді физикалық түсіндіру бөлігі болып табылады және ООАП процесінде маңызды роль атқарады. Компоненттер диаграммасын белсендіру келесі тәсілдерінің бірімен орыдалуы мүмкін:

 Стандартты инструменттер панелінде компоненттер диаграммасын бейнелеу арқылы батырмада шерту;

 Браузерде (Component View) компоненттік түсіндіруді өрбіту және Main (Главная) пиктограммасында екі рет шерту;

 Browse-»Component Diagram (Браузер-» Компоненттер диаграммасы) меню пункті арқылы.

Компоненттер диаграммасын белсендіргеннен кейін арнайы инструменттер панелі келесі түрге келеді (6.9-сурет).

6.9-сурет - Компоненттер диаграммасына арналған арнайы инструменттер панелінің сыртқы түрі.

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

Төменде компоненттер диаграммасы элементтерін графиктік бейнелеу мысалы келтіріледі (6.10-сурет).

Компоненттер диаграммасымен жұмыс кезінде пакеттер мен компоненттер жасауға, олардың спецификациясын және диаграмманың түрлі элементтері арасындағы тәуелділіктерді өзгертуге болады. Компонентте кластарды жүзеге асыруды бекіту кезінде браузерде класты бөліп алуға және оны диаграмманың керекті компонентіне тасымалдауға болады.

Rational Rose ортасында өрбіту диаграммасын әзірлеу.

Өрбіту диаграммасы модельді физикалық түсіндірудің екінші құрамды бөлігі болып табылады. Өрбіту диаграммасын белсендіру келесі тәсілдердің бірімен орындалуы мүмкін:

 Стандартты инструменттер панелінде өрбіту диаграммасын бейнелеу арқылы батырманы шерту;

 Браузерде (Deployment View) өрбітуді түсіндіруді екі рет шерту (Deployment View);

 Browse-»Deployment Diagram (Браузер-»Өрбіту диаграммасы) меню пункті арқылы.

6.10-сурет - Rational Rose ортасында компоненттер диаграммасын графиктік бейнелеу мысалы

Өрбіту диаграммасын белсендіргеннен кейін арнайы инструменттер панелі келесі түрге ие болады (6.11-сурет).

6.11-сурет - Өрбіту диаграммасы үшін арнайы инструменттер панелінің сыртқы түрі

Өрбіту диаграммасымен жұмыс процессорлар мен құрылғыларды, олардың спецификациясын жасаудан, олардың арасындағы байланыстарды орнатудан, сонымен қатар процестер қосу мен спецификациядан тұрады. Жеке процессорларға қатысты стереотиптерді пайдалануға болады.

Төменде өрбіту диаграммасын графиктік бейнелеу мысалы келтіріледі (6.12-сурет).

Rational Rose ортасының анағұрлым зор қасиеттерінің бірі модельді салғаннан кейін бағдарламалық кодты туындату мүмкіндігі болып табылады. Бұрын атап өтілгендей, бағдарлама мәтінін бағдарламалаудың сол немесе басқа тілінде туындату мүмкіндігі Rational Rose нұсқасын орнатуға байланысты.

6.12-сурет - Rational Rose ортасында өрбіту диаграммасын графиктік бейнелеу мысалы

Бұл үшін орындауға қажетті әрекеттердің жалпы реттілігі алты кезеңнен тұрады:

1. Тілді таңдауға тәуелсіз кодты туындату моделін тексеру;

2. Кластарды жүзеге асыру үшін компоненттер жасау;

3. Кластардың компоненттерге бейнеленуі;

4. Бағдарламалық код туындату қасиеттерін бекіту;

5. Класты, компонентті немесе пакетті таңдау;

6. Бағдарлама кодын туындату.

Кезеңдердің әрқайсысын орындау ерекшелігі тілді таңдауға байланысты өзгеруі мүмкін. Rational Rose ортасында жеке кластарды да, сондай-ақ тұтас жобаны сипаттайтын қасиеттердің жеткілікті түрде көп санын беру қарастырылды.

Компоненттер диаграммасын салу бойынша ұсыныстар

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

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

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

Жүйеі физикалық түсіндіруді жалпы құрылымдаудан кейін модельді интерфейстермен және деректер базасы сұлбаларымен толықтыру қажет. Интерфейстерді әзірлеу кезінде бағдарламалық жүйенің түрлі бөліктерін үйлестіруге (түйістіруге) азар аударған жөн. Модельге деректер базасының сұлбасын енгізу жеке кестелер спецификациясын және кестелер арасында ақпараттық байланыстарды орнатуды болжайды.

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

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

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

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