3.1.5. Моделі взаємодії і варіабельності пс для організації обчислень

Під взаємодією розуміють сумісність двох і більше об'єктів (програм і середовищ між собою), яка пов’язана з обміном інформацією і використанням її для організації обчислень у сучасних операційних середовищах. Для завдання взаємодії програм у мовах програмування (МП) використовується апарат зв’язку типу CALL, а для розподілених програм – RPC, RMI, ORB (stub, skeleton), IContract тощо. Взаємодія здійснюється інтерфейсом, який специфікується мовою IDL (Interface Definition Language) допомогою якої на загальному рівні передаються дані компонентам, що знаходяться в різних гетерогенних середовищах [5]. Для опису взаємодії різнорідних компонентів нами розроблено модель взаємодії. Головне її призначення – забезпечувати взаємодію різнорідних компонентів, що побудовані в інтегрованому середовищі ІТК з Eclipse, MS.Net, CORBA, Protégé тощо. Цю модель можна адаптувати до середовища Grid для обчислення різнорідних програм глобального масштабу в області e–science та Cloud Computing [1, 2].

Модель взаємодії М_inter

Ця модель має такий загальний вигляд:

М_inter = {М_pro, М_sys, М_env},

де М_pro = {Com, Int, Pro} – модель програми, Com – компонент, Int– інтерфейс, Pro –програма;

М_sys = {PS, Int, Prot } – модель програмної системи PS, Int – інтерфейс, Prot – протокол зв’язку для передачі даних ;через мережу;

М_env = {Envir, Int, Pro} – модель середовища, в якому Int, Pro відображають сукупність зовнішніх інтерфейсів, викликів та протоколів, що забезпечують передачу даних між програмами або системи через мережу відповідно.

Фактично Мinter по відношенню до стандартної семірівневої моделі відкритих систем OSI , є моделлю верхнього рівня.

Програмні компоненти і системи й інтерфейси специфікуються відповідною МП, інтерфейсом IDL, протоколами з XDL, RDF, що зберігаються в бібліотеках і репозиторіях ІТК Новим способом взаємодії між програмами типу клієнт і сервер є інтерфейс типу Icontract системи WCF [ ], який призначений для опису атрибутів та операцій для передачі даних від сервісного об’єкту (Service consumer) до клієнтського (Service provider) за контрактами Icontracts.

Базисом інструментального середовища ІТК є Eclipse, як засоб керування репозиторієм КПВ і використання КПВ для зборки в складну структуру. В процесі взаємодії програм і систем через інтерфейс при обчисленнях в тому чи іншому середовищі застосовуються різні механізми перебудови типів даних з різних форматів даних їх опису і формою трансформації типів даних в системах програмування з МП та використання бібліотек функцій і процедур з примітивами перетворення різних даних [ ].

Практичним рішенням задач взаємодії в ІТК є моделі розподілених систем:

– Visual Studio.Ne Eclipse реалізує взаємодію програм в мові С# на основі опису специфікації інтерфейсу, перенесення готового продукту в репозиторій системи Eclipse, що відображає зв'язок з даним середовищем програм через плагини і конфігураційний файл з параметрами і операціями оброблення даних в даному середовищі;

– CorbaJavaMS.Net забезпечує встановлення зв’язків між цими програмними середовищами шляхом розміщення програм в МП у репозиторії ІТК та надання доступу до них інших програм;

– IBM Eclipse орієнтована на нові програми в МП з використання інтерфейсу, що допускаються у цьому середовищі та у віртуальному варіанті VSphere.

Тобто при переході в середовище Eclipse використовуються вихідні файли програми, dll–бібліотки VS та файли ресурсів (.resx). Коли необхідно знов перейти із цього середовище в Visual Studio, вся проектна програма імпортується туди і зворотньо. Обчислення програми та її змінювання можна виконувати як у середовищі Eclipse, так і у Visual Studio. Модель IBM Eclipse буде продовжено надалі у випадку використання сервісів для взаємодії програм, як обчислень у розширеному середовищі ІТК.

Модель варіабельності ПС і СПС

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

СПС із ПС має спільну множину характеристик, відповідних потребам певних функціональних варіантів ПрО, розрізняються способами втілення цих характеристик в окремі ПС і розробляються з використанням готових ресурсів. ПС створюються не «з нуля», а породжуються за моделлю СПС або обираються для неї готові КПВ з репозиторіїв, після чого адаптуються і збираються у нову структуру ПС [ ].

Модель СПС пов’язана з об’єктною і її компонентною моделлю ПрО і доповнена точками варіантності, створив розширену модель сімейства варіантної системи (СВС) за таким формальним виглядом:

М _СВС = (Мпс, Int, C), C = CC  BC; Bc = ib, rb, BC  ! o₃^**L₃ | ib = met(o₃^**),

dat(o₃^**), {rb}= im(ib);

CC = ic, rcCC  !o₃^*O₃\L₃ | ic =  met(o₃^*), dat(o₃^*) , BC={met(o_3u), dat(o_3u),

Part_of(o₃^*,o_3u)}, {rc}= im(ic),

де bcBC і CC – унікальні імена КПВ, названих базовими та складними;

ib, rb – вхідний інтерфейс і реалізація базового КПВ, яка підтримує інтерфейс базового КПВ:  (bc₁, bc₂) BC im(bc₁)  im(bc₂);

ic, rc – вхідний s вихідні інтерфейси та реалізація складного КПВ;

im() – функція, що надає множину реалізацій інтерфейсу;

cr_ij = (c_i, c_j) Int – відношення Part_of: (c_i, c_j)NC  Part_of(o_3i, o_3j), що пов’язує КПВ, прототипи яких o_3i, o_3j в об’єктній моделі.

Компонентна модель програмного КПВ входить в модель CВС. Для забезпечення властивостей варіантності і змінності ПС з СПС проведено узагальнення наведених моделей для послаблення відношення Part_of.

Нехай C_t: O_t {0;1} і D_t: {vp_tO_t |C(vp_t)=1}  2^Ot  {0;1}, t= 1,...,4 – деякі предикати, які для об’єкту o_tjO_t (С_t, D_t) декомпозує варіантнт об’єкту o_tiO_t (VP(C_t,D_t; o_ti,o_tj)), якщо реалізація в певній ПС об’єкту тягне за собою реалізацію нового об’єкту тоді й тільки тоді, коли

C_t(o_ti)=1,  SO_ti  O_t {o_ti} | o_tjSO_ti, D_t(o_ti, SO_ti)=1, t = 1,..., 4.

Об’єкти o_ti і o_tj уданому виразі будемо звати об’єктною точкою варіантності та варіантом підпорядкованого об’єкта для o_ti, а предикати C_t і D_t – обмеженням на точки варіантності і залежністю між варіантами.

Процесі розроблення СПС як програмного продукту є керованим за такими підпроцесами:

– планування реалізації варіантів в артефактах СПС [9]) (F1);

– системного моніторингу забезпечення варіантності СПС;

– актуалізації СПС шляхом конфігурування підібраних нових КПВ чи артефактів з метою отримання нового варіанта ПС.

При реалізації варіабельністі використовуються такі принципи:

– узгодженість способу створення й реалізації рішень на всіх рівнях абстракції та на процесах ЖЦ розроблення СПС з готових КПВ;

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

– обов’язкове завдання інтерфейсів КПВ з точками варіантності змуних компонентів;

– можливість відстеження зв’язків між проявами варіантів на всіх рівнях абстракції та процесах розроблення СПС тощо..

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

Необхідним елементом ІТК у майбутньому має бути інтегрована модель варіабельності СПС (VР), яка дозволить створити прогнозовану структуру СПС, визначати оцінку можливості побудови варіантів ПС із КПВ.

Про варіанти взаємодії користувача з ПС

Мделювання взаємодії користувача з ПС базується на сценаріях UML, а саме, Варіантах використання, до яких актор звертається до системи. У відповідь система виконує певну роботу у результаті одного запуску відповідної роботи системи, або, якщо якісь події її перервали, вважається невиконаною. Будь–яка робота складається з чотирьох частин, а саме:

1. Актор посилає до системи запит та дані до нього.

2. Система підтверджує отримання запиту та даних.

3. Система реагує на підтверджений запит зміною свого стану.

4. Система видає актору результат.

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

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

Життєвий цикл варіанта використання такий:

• Особа–в–ролi, або екземпляр актора, вводить підходящий стимул, стартує екземпляр потрібного йому варіанта використання і виконується доти, доки екземпляр варіанту використання знову чекає на вхідний стимул від екземпляру актора.

• Екземпляр варіанта використання існує, поки він виконується.

У даній моделі визначені такі правила:

– кожен варіант використання може запускатися тільки одним актором;

– кожен актор може запускати декілька варіантів використання;

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

– актор не визначає варіант використання, він тільки ініціює ланцюжок подій, який викличе варіант використання;

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

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

Для специфікації властивостей варіантів використання пропонується каркас (framework), подається послідовністю наступних елементів:

– назва, яка однозначно ідентифікує варіант використання на діаграмах моделі сценарію i є засобом посилання на варіант використання;

– анотація (короткий зміст у неформальному поданні);

– актори, що можуть запускати варіант використання за зверненнями до послуги системи;

– визначення усіх аспектів взаємодії системи з акторами: можливих дій акторів та їх можливих наслідків;

– передумови визначення початкового стану, необхідного для успішного виконання;

– функції, які здійснюються при виконанні варіанта використання ;

– опис нестандартні ситуації, яка може з'явитися при виконанні варіанта використання та завдання дії, яка є реакцією на таку ситуацію ;

– умови завершення варіанта використання;

– постумови, що визначає кінцевий стан варіанта використання при його нормальному, тобто успішному завершенні.;

– опис інтерфейсів, який також подається неформально; .

– нефункціональні вимоги до варіанта використання.

Включення – перелік назв сценаріїв, які він використовує у сенсі UML

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