Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Lab_work_DPPS.doc
Скачиваний:
10
Добавлен:
25.08.2019
Размер:
353.28 Кб
Скачать

Завдання

  1. Вибрати існуючий, або реалізувати новий архітектурний каркас.

  2. Продовжувати архітектуро-орієнтовану розробку вашого проекту зосереджуючись на реалізації скелетів проблемно-орієнтованих компонентів та основних механізмів взаємодії між компонентами. До захисту роботи необхідно побудувати робочий прототип застосування, який виконує усі основні взаємодії між компонентами.

  3. У ході роботи, обов’язково документуйте будь-які зміни архітектури застосування (набору основних проектних рішень про систему).

  4. До звіту необхідно включити таке:

  • Поточний статус вашого проекту та обґрунтування вибору архітектурного каркасу.

  • Опис стан справ з їх розробкою конкретних архітектурних елементів із посиланнями на них.

  • Один або два фрагменти коду (максимум 3-4 аркуші), показуючи як основні з’єднувачі реалізовані у вашому застосуванні. Для кожного шматка вказати, який з’єднувач показано, та забезпечте код коментарями, або поясненнями на один невеликий абзац.

  • Опис основних технічних викликів, ризиків та відкритих питань, з якими ви стикнулися.

Контрольні запитання

  1. У чому полягає суть завдання розробки системи на основі архітектури?

  2. Опишіть механізми відображення архітектурних елементів на елементи технологій реалізації.

  3. У чому суть одностороннього та двостороннього відображення архітектурних елементів на елементи технологій реалізації?

  4. Що таке архітектурний каркас, або каркас для реалізації архітектури?

  5. Наведіть приклади архітектурних каркасів.

  6. Що таке проміжне ПЗ?

  7. Наведіть приклади проміжного ПЗ, поясніть його роль у розробці та реалізації архітектури.

  8. Який зв'язок між архітектурним каркасом, архітектурним стилем та проміжним ПЗ?

  9. Які стратегії розв’язання конфліктів між архітектурним стилем та проміжним ПЗ, що нав’язує свої проектні рішення, вам відомі?

  10. Що таке прототип системи?

  11. Які типи прототипів вам відомі?

Лабораторна робота №2.2 Реалізація та розгортання програмного забезпечення

Мета: отримати практичні навички реалізації та розгортання ПЗ.

Теоретичні відомості

Найбільш простим та широко застосовуваним підходом до реалізації архітектури є відображення архітектурних елементів на елементи мов програмування вручну. Інший відхід до реалізації архітектури – це використання технологій для автоматичної генерації коду. За допомогою досить детальної архітектурної моделі можна згенерувати різні «робочі продукти реалізації». Реалізація усієї системи потребує дуже детальних моделей, які включають поведінкові специфікації та є більш конкретними щодо реального застосування.

Процес розгортання – це процес, під час якого елементи системи розміщується на її фізичних компонентах [2]. Зміна розміщення компонента під час роботи системи називається міграцією, або перерозподілом. Міграція чи перерозподіл це вид мобільності системи. Мобільність повинна передбачати усі можливі проблеми розгортання. До проблем розгортання та мобільності можна віднести наступне: широко розподілені процесори; цільові процесори вбудовані всередину гетерогенних пристроїв; різні компоненти системи можуть мати різні вимоги до апаратної частини системи; життєвий цикл застосування може розтягнутися на десятиліття; застосування постійно потребує доробки та інші. Система розгорнута на множині вузлів або сайтів. Кожен вузол надає ті ресурси, які потребують компоненти системи, наприклад апаратне забезпечення, мережа, перефирійні пристрої, системне ПЗ, інші програмні додатки, ресурси для зберігання даних. Ресурси можуть бути ексклюзивними або доступними для усіх компонентів. Архітектура розгортання це опис програмних компонентів для апаратних вузлів (рис. 2.1.).

Рис. 2.1. Архітектура розгортання

Під час розгортання виконують наступні пункти: планування, моделювання, аналіз та впровадження. Під час планування слід вирішити, як обрати оптимальну архітектуру розгортання, яка покращує якість сервісів системи. Користувачі системи мають різні вподобання щодо системних сервісів. Функції корисності допомагають визначити вподобання користувача щодо якості сервісів та провести оптимізацію розгортання відштовхуючись від певної скалярної величини.

Ефективне моделювання розгортання вимагає наявність наступних елементів: програмні елементи системи, їх конфігурація та параметри; апаратні елементи системи, їх конфігурація та параметри; будь-які обмеження на елементи системи та/чи їх параметри; формальні визначення якостей сервісів. Аналіз розгортання має давати питання на декілька питань. Чи усі розгортання дійсні? Яке з розгортань краще? Чи обране розгортання має потрібні властивості? Застосування розгортання потребує наступних дій з компонентами: реалізувати, встановити, активувати, деактивувати, оновити, адаптувати, переналаштувати, деінсталювати або видалити, де-реалізувати або завершити існування.

Переміщення ПЗ з одного апаратного комплексу на інший під час виконання системи означає мобільність коду, або логічну мобільність. Якщо програмний модуль, який мусить мігрувати знаходиться на виконанні, то міграція цього модуля отримує назву «міграції стану», але якщо мігрувати мусить тільки код, то у такому разі це буде міграцією без збереження стану.

Існує кілька парадигм мобільності: дистанційне обчислення, код-на-замовлення, мобільний агент. Для дистанційного обчислення потрібне повторне розгортання деяких модулів на віддалених вузлах, що мають ресурси, для обчислення. Код-на-вимогу є теж саме, що і віддалене обчислення, але при ньому ролі початкового та цільового вузлів змінені місцями. Парадигма «Мобільний агент» передбачає міграцію системного компоненту, що має поточний стан, але потребує деякі віддалені ресурси для завершення свого завдання.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]