Моделі взаємодії компонентів у ПС

Виходячи з аналізу діючих фабрик програм [5, 12], дамо класифікацію моделей зв’язку в сучасних середовищах в залежності від сутності реалізованих в них принципів взаємодії компонентів як базових:

1) брокер запитів між програмами клієнта і сервера з отримання даних від stub клієнта, їх обробку під формати даних сервера складених через skeleton, що дає напрям обробки результатів обчислювань з доведенням їх до типу даних клієнта;

2) проміжний прошарок загальносистемних середовищ підтримки процесів виконання або взаємодії об’єднаних різнорідних програм;

3) пряма зборка странслюваних програм за різними МП і інтерфейсами у бібліотеці, наприклад, MS.Net.

Перша модель взаємодії практично реалізується брокером ORB для класу МП у середовищі CORBA. Зборка компонентів базується на класах: Client class з викликами інших, Stub class з конвертування даних, ORB class з передачі даних за викликами; Server class зі створення сервентів та посиланням даних ORB; Skeleton class з конвертування форматів даних та адаптеру для породження різних видів серверів.

Друга модель забезпечує взаємодію між компонентами, розміщеними на різних комп'ютерах, через проміжний прошарок (middleware), та неоднорідність їхніх форматів даних шляхом повідомлень (наприклад, Java Message Queue), віддаленого виклику процедур RPC в MS Windows, ONS IBM, CORBA та виклику методів RMI у Java. Модель ISO/OSI також забезпечує проміжну взаємодію на рівнях (фізичному, канальному, мережному і транспортному) через мережну ОС. Верхній рівень моделі (прикладний) забезпечує перетворення даних до транспортного рівня шляхом їх маршалінгу й демаршалінгу за інтерфейсним stub. Сеансовій рівень моделі передає дані через транспортний канал за механізми посилань іншим рівням.

Третя модель реалізована в MS.Net і базується на бібліотеках: CLR (Common Language Runtime), CTS (Common Type System) і CLS (Common Language Specification). CLR забезпечує виявлення і завантаження типів даних, керування ними у відповідності до завдань розробника програми. CTS визначає принципи взаємодії із іншими, відповідно представлених форм метаданих. Збірка різномовних програм виконується за правилами CLS бібліотеки. Усі компілятори з МП цього середовища створюють модуль DLL або EXE у проміжну мову MSIL (Microsoft Intermediate Language) для зборки отриманого коду, незалежно від платформи, на якій він буде виконуватися рішення. При запуску цей код конвертується в специфічний код CPU івиконується на різних архітектурах комп’ютерів.

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

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

Структура і зміст ліній виробництва програм. Технологічна лінія – ТЛ будується із процесів ЖЦ після аналізу ПрО|предметної| й виявлення її основних задач і |задачі| функцій. Для процесів підбираються готові ресурси, а також засоби й інструменти породження для функцій програм. Крім того додається планування, контроль й керування процесами ТЛ з | формуванням шаблонів і заготовок фіксації проектних рішень, зміни станів і оцінювання | с якості ПП [2, 4].

Набір процесів ТЛ будуються з урахуванням міжнародних стандартів ISO/IEC 12207– 2007 і ДСТУ 3918–99, що підкріплюються відібраними методами, засобами й інструментами для здійснення змін станів проміжних об'єктів. |язик||Цей підхід до побудови ТЛ| апробований в АИС "Юпітера" (1987–1991) на прикладі шості ТЛ обробки даних.

На новому вітку історії розвитку ліній індустрії програм виникли поняття продуктових ліній в SEI США[12], принципи побудови й виконання яких аналогічні ТЛ і відображають індустрію виробництва систем, сімейств систем комерційного типу.

Поняття product line (лінія продуктів) і product family (сімейство продуктів, надалі СПС) визначені у словнику ISO/IEC FDIS 24765:2009(E) – Systems and Software Engineering Vocabulary як «група продуктів або послуг, які мають спільну керовану множину властивостей, що задовольняють потреби певного сегменту ринку або виду діяльності» («product line – group of products or services sharing a common, managed set of features that satisfy specific needs of a selected market or mission. Synonym: product family»).

Тобто сім‘я продуктів або лінійка продуктів для деякої ПрО [22] – це множина програмних систем, розроблених з використанням набору готових ресурсів, які мають спільний набір властивостей і рис для деякої ПрО . Під ресурсами розуміються артефакти, КПВ, проектні рішення, коди, вимоги тощо.

Кожна лінія ініціює первинний процес або збирковий конвеєр з виробництва ПП із готових ресурсів з метою задовольняння потреб деякого ринка ПП.

Наведені типи ліній виробництва ПП не обмежені. Деяка фабрика може бути зорієнтована на спеціальні лінії функціонального типу, наприклад, на створення програм із класу задач статистичної обробки, чисельних методів, розробка яких було подано у роботах [2, 22, 23].

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

<== попередня сторінка	\|	наступна сторінка ==>
ЧАСТИНА 4.	\|	Методологічні аспекти виробництва СПС з готових ресурсів

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.015 сек.