• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

ЖЦ проектування ПС із типових компонентів та КПВ

На початкових етапах життєвого циклу застосовуються об’єктно–орієнтовані методи концептуального моделювання, аналізу та проектування. На абстрактному рівні компонентна модель будується на основі компонентних інтерфейсів, які за своєю сутністю аналогічні інтерфейсам в ООП. На етапах ЖЦ, пов’язаних з реалізацією компонентних систем, застосовуються власні, тобто, компонентні підходи [11]. На цих етапах сутності об’єктів та компонентів істотно відрізняються і тому є необхідність у використанні суто компонентних моделей та методів.

В цілому ЖЦ компонентних систем складається з наступних етапів:

 розробка вимог до програмної системи;

 аналіз об’єктної моделі та поведінки для програмної системи;

 специфікація інтерфейсів та взаємодії компонентів;

 інтеграція компонентів у єдине середовище для програмної системи на основі нових компонентів та компонентів повторного застосування;

 розгортання програмної системи у користувача;

 підтримка та супровід програмної системи.

Далі розглядається формальний опис кожного етапу ЖЦ і результатів проектування та реалізації розподілених програмних систем (РПС) на компонентній основі.

Розробка вимог до ПС – це формування та опис функціональних, технологічних, організаційних та ін. властивостей програмної системи, які необхідні чи бажані з точки зору кінцевого користувача.

Суть етапу розробки вимог полягає у визначенні бізнес–процесів, виконання яких РПС повинна забезпечити. Бізнес–процеси – це процеси, що пов’язані з професійною діяльністю кінцевого користувача та виконання яких підтримується функціонуванням системи.

Згідно з ООП на цьому етапі виконуються наступні процеси: визначення бізнес–процесів; формування прецедентів; специфікація вимог до бізнес–процесів, умов та особливостей їх виконання. Розглянемо семантику цих процесів.

Визначення бізнес–процесів. Це – найменш формалізований процес на етапі розробки вимог. Початковий опис робиться замовником РПС з використанням звичайної мови відповідно до його уявлень та понять щодо бізнес–процесів та ПрО взагалі. На практиці існують кілька ітерацій у формуванні цього опису, щоб замовник та розробник дійшли згоди та зрозуміли один одного.

Формування прецедентів. Прецедент – це типовий сценарій взаємодії користувача та системи, який поданий та описаний як документ, схема чи інший матеріал у формі для сприйняття його замовником та розробником, що описує послідовність подій у звичайній професійній діяльності користувача, де застосовується РПС. Тобто, прецеденти описують варіанти застосування системи.

Сукупність усіх прецедентів визначають загальну картину застосування програмної системи для вирішення задач певної предметної області. Враховуючи, що вони формуються різними категоріями користувачів, можуть існувати певні суперечності у їх описах.

Специфікація вимог та особливостей бізнес–процесів. При формуванні опису бізнес–процесів та прецедентів результати формалізуються, структуруються та подаються у вигляді документу, який визначає сукупність вимог до майбутньої програмної системи. У більшості випадків специфікація на етапі розробки вимог не закінчується, а продовжує виконуватись на стадії об’єктного аналізу та аналізу поведінки.

Важливим та доцільним завданням цього етапу є перехід від розробки загальних системних вимог до вимог щодо окремих компонентів. Наперед не відомо – будуть існувати усі необхідні дані для інтеграції компонентів чи ні. Деякі програмні компоненти спеціально розробляються, основою специфікації яких є деталізація системних вимог до рівня компонентів.

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

Головна мета об’єктного аналізу – подати предметну область як множину об’єктів з властивостями та характеристиками, які достатні для визначення та ідентифікації окремих об’єктів, а також опису їх поведінки у рамках вибраної системи понять та абстракцій

Етап об’єктного аналізу та аналізу поведінки включає такі процеси:

 моделювання ПрО;

 побудова об’єктної системи;

 адаптація об’єктної системи.

Моделювання ПрО. Зміст цього процесу визначається ступенем формалізації та рівнем деталізації в поданні знань щодо ПрО. Головні завдання цього процесу є типовими, як і при застосуванні інших методологій, і полягають у визначенні базових понять та термінів для ПрО, реальних об’єктів, що їм відповідають, а також визначення відношень та зв’язків між цими поняттями відповідно до відношень та зв’язків між реальними компонентами, побудова різних моделей, які відображають різні аспекти ПрО (структурні, поведінкові та ін.).

Побудова об’єктної системи. Результати попереднього процесу об’єднуються у рамках побудови об’єктної системи. Система визначає структурні властивості для сукупності об’єктів, асоціації між ними, їх атрибути та відповідні значення.

Об’єктна система подається як модель, яка описується об’єктним графом у вигляді

OSyst = (OClass, G),

де OClass = {OClassⁱ} – множина класів; G – об’єктний граф, який відображає зв’язки та відношення між класами та екземплярами.

Для цієї моделі існує еквівалентна модель

ISyst = (IFunc, IG) ,

де IFunc = {IFuncⁱ} – множина інтерфейсів; IG – інтерфейсний граф, який ідентичне графу G.

Кожному IFuncⁱ відповідає OClassⁱ, який поданий через його зовнішнє сприйняття, тобто об’єктний інтерфейс, який інкапсулює внутрішню структуру класу. Цей інтерфейс складається із зовнішніх методів та атрибутів. Виконання ідентичних операцій над кожною з моделлю забезпечує у будь-який період перехід від об’єктного подання до інтерфейсного, який є абстрактним рівнем для формування компонентного подання.

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

Адаптація ПС. Цей процес є нетиповим для традиційних об’єктних методологій і необхідність його продиктована особливостями компонентного підходу. Сутність процесу полягає в оптимизіції компонентної системи у відповідності до можливостей покриття загальної функціональності за рахунок функціональносте й існуючих програмних компонентів. Тобто, система трансформується таким чином, щоб об’єкти, що залишаться у ній, за своїми сервісними можливостями максимально були наближені до функціональних можливостей існуючих компонентів.

Для забезпечення умов виконання процесу адаптації найбільш доцільно застосовувати модель контрактів, сутність якої полягає у наступному. Якщо для функціонування певного компонента необхідна функціональність, яка реалізується в іншому компоненті, то перший укладає контракт з другим для виконання відповідних послуг. Зв’язок забезпечується на основі інтерфейсів. Як правило, модель контрактів застосовується для проектування об’єктно–орієнтованих програм. Але методи проектування компонентних програм за своєю сутністю співпадає з проектуванням об’єктно–орієнтованих програм і тому цей метод доцільно застосувати на даному етапі.

Одна з головних задач проектування компонентної програми полягає у поданні її функціональності та інших вимог як сукупності контрактів між компонентами, з яких буде складатись програма.

Специфікація інтерфейсів для взаємодії компонентів.Головний зміст цього етапу полягає у наступному. Нехай A_i – множина контрактів, що визначає функціональність програми отриману на попередньому етапі. Кожному A_i співставляється інтерфейс I_i, який визначає контракт як клієнт–серверну взаємодію. Відповідно до цього кожному інтерфейсу співставляється In_i та Out_i, які називаються відповідно реалізуючи поданням для I_i та визначаючим поданням для I_i. Інколи вони називаються вхідним та вихідним інтерфейсами, та ці терміни є не зовсім коректними. Out_i визначає умови та ціль контракту з боку клієнта, а In_i визначає реалізацію контракту з боку сервера.

Після того, як усі In_i та Out_i визначені, вони групуються у певних сукупностях. Розглянемо довільну множину M_v ={In_iÈOut_j}. Назвемо кожну M_v шаблоном компонента. Фактично кожний шаблон складається з множини, елементами якої є реалізуючи та визначаючі подання для інтерфейсів. За цими шаблонами у подальшому виконується співставлення з описами інтерфейсів для компонентів повторного застосування.

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

Головне завдання етапу специфікації інтерфейсів та взаємодії компонентів складається з наступних процесів: розподіл ролей компонентів; проектування та специфікація окремих інтерфейсів; опис взаємодій компонентів.

Розподіл ролей компонентів. Інтерфейси специфікуються виходячи з ролей, які компоненти, що є фізичними реалізаціями відповідних об’єктів системи, відіграють у обробці даних в процесі своєї взаємодії. Фактично визначаються I_i, за відповідними A_i. У подальшому на такому розподілу ролей буде відбуватись пошук і вибір компонентів, які мають відповідні сервісні можливості і необхідну функціональність.

Проектування та специфікація інтерфейсів. Проектування інтерфейсів відбувається відповідно до ролей компонентів. При цьому потрібно дотримуватися концепції оптимальності у проектуванні, суть якої міститься в тому, що інтерфейсів для компонента не повинно бути багато, але в той же час не потрібно проектувати дуже великі (за обсягом операцій) інтерфейси. Кожен з типів інтерфейсів – клієнтський чи сервісний – проектується окремо. Проектування інтерфейсів полягає в їх ідентифікації та в визначенні складу операцій, які вони підтримують. На цьому процесі формуються остаточні описи для In_i та Out_i.

Опис взаємодії компонентів. Цей опис подається у контексті послідовності дій для підтримки певних бізнес–процесів. Якщо результат проектування інтерфейсів визначає пари компонентів, що взаємодіють, то результатом цього процесу є сукупність послідовностей операцій всіх компонентів для досягнення цілей виконання бізнес–процесів. Головна мета – підібрати найбільш оптимальну конфігурацію CP.

Збирання компонентів. Головними завданнями цього етапу є визначення, пошук та вибір всіх необхідних компонентів, їх адаптація до потреб інтеграції, забезпечення умов для необхідного перетворення типів даних взаємодіючих компонентів, визначення плану компонентної конфігурації, створення та тестування інтегрованого середовища для РПС.

Всі роботи розподіляються відповідно виконанню послідовності наступних процесів: пошук компонентів згідно з описом інтерфейсів; вибір сукупності компонентів, які забезпечують необхідну функціональність; адаптація існуючих компонентів для вимог побудови інтегрованого середовища; створення нових компонентів, для яких результати пошуку, вибору та адаптації дали негативні результати; інсталяція компонентів для потреб композиції; визначення повної сукупності правил та умов композиції компонентів; безпосередня побудова РПС; тестування інтегрованого середовища.

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

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

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

Створення компонентів. Цей процес виконується, коли попередні процесу пошуку, вибору, адаптації для певних компонентів дають негативні результати. У цьому разі необхідно створювати нові компоненти з наперед визначеними інтерфейсами та функціональністю. Розробка таких компонентів провадиться сучасними мовами і засобами. Важливо, щоб усі вимоги до компонентів, їх властивості та типова структура відповідали вимогам компонентної моделі, що застосовується для композиції.

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

Побудова РПС.Головна мета процесу побудови РПС – виконати всі дії щодо підготовки інтегрованого середовища до функціонування та створення плану конфігурації компонентів РПС. З цією метою послідовно виконуються наступні кроки.

1). Компілюються описи інтерфейсів та генеруються допоміжні програмні компоненти, які пристосовані для потреб певної моделі, а також згенеровані з врахуванням мови програмування, на якій написані самі компоненти.

2). Компілюються додаткові зв’язкові програмні компоненти (посередники), що зв’язуються з відповідними програмними компонентами. За аналогією можна сказати, що ці додаткові об’єкти відіграють роль роз’ємів, за допомогою яких компоненти від’єднуються до інтегрованого середовища.

3). Фіксується план компонентної конфігурації. План описує перелік компонентів, зв’язки та залежності між ними відповідно до послідовностей взаємодій компонентів та умов функціонування.

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

Розгортання РПС.У випадку, коли РПС створюється для конкретного замовника, який є і користувачем, то деякі завдання розгортання виконуються на попередніх етапах. До них, зокрема, відносяться:

 проектування та композиція ПС з орієнтацією на конкретні комп’ютерні засоби замовника, їх потужність, розташування, наявність комп’ютерних мереж та інших засобів комунікації, найбільш ефективну топологію з’єднань та ін.;

 інсталяція окремих компонентів на визначених комп’ютерах для цілей композиції (дуже часто ця конфігурація компонентів залишається в подальшому для робочого функціонування системи);

 створення компонентної конфігурації на етапі композиції з орієнтацією на її подальше застосування на етапі супроводу.

У випадку, коли РПС є комерційним продуктом, її розробник для цілей композиції та тестування розгортає усі компоненти на власній комп’ютерній базі, яка є певною моделлю, що відповідає найбільш типовій ситуації. Користувач такої системи проходіть всі процеси етапу розгортання на власній комп’ютерній базі і відповідно до своєї конфігурації технічних та загальносистемних засобів.

Друга ситуація. Всі процеси розгортання виконуються як окремий етап, до складу яких входять: оптимізація плану компонентної конфігурації у відповідності до наявної комп’ютерної бази користувача, її властивостей та топології; розгортання окремих програмних компонентів; створення цільової компонентної конфігурації.

Оптимізації плану компонентної конфігурації. План компонентної конфігурації є одним з результатів процесу композиції. Він визначає абстрактну модель подання інтегрованого середовища РПС. Всі взаємозв’язки та взаємодії компонентів подані на логічному рівні, тобто, описуються самі факти зв’язків та взаємодій без врахування фактичного розташування компонентів.

Головне завдання цього процесу – визначення реальної конфігурації компонентів. Це є оптимізаційна задача, у якій початковими даними будуть: наявні комп’ютерні потужності з засобами комунікації у користувача; вимоги до ресурсів з боку окремих компонентів; план конфігурації.

У якості граничних умов виступає необхідність виконання функціональних, технологічних та інших вимог до РПС.

Розгортання програмних компонентів. Процес інсталяції для кожного окремого компонента може мати свої власні відмінності, які залежать від методу та засобів інсталяції. Вимоги компонентно–орієнтованої методології охоплюють лише питання, що пов’язані з про інстальованим компонентом, тобто, після його розгортання. Результат інсталяції повинен задовольняти всім вимогам з боку відповідних компонентних моделей та інтегрованого середовища для програмної системи.

Створення цільової компонентної конфігурації. Результати попередніх процесів є основою для створення цільової конфігурації. До неї, зокрема, входять:

 розташування окремих компонентів;

 характеристики компонентів;

 опис взаємозв’язків чи інтерфейсів компонентів.

Цей процес завершує створення цільової конфігурації. Уся наведена вище інформація описує цільову конфігурацію і застосовується для підтримки функціонування РПС на етапі супроводу.

Читайте також:

1. Active-HDL як сучасна система автоматизованого проектування ВІС.
2. V. Робоче проектування та авторський нагляд.
3. VII. Етап проектування
4. VII. Етап проектування
5. Автоматизація проектування напівзамовлених ВІС.
6. Аналітичний розрахунок сумарного завантаження типових перетинань
7. Б. Англо-український глосарій типових конструкцій з військового перекладу 1 страница
8. Б. Англо-український глосарій типових конструкцій з військового перекладу 2 страница
9. Б. Англо-український глосарій типових конструкцій з військового перекладу 3 страница
10. Будова типових кондуктометричних чарунок
11. Варіантне проектування будівельного виробництва.
12. Варіантне проектування технології зведення будівель та споруд.

Переглядів: 1256