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

Типізація і класифікація програмних компонентів

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

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

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

Побудована нова класифікації програмних компонентів, щодо Веб–застосувань.

Типізація програмних компонентів.Згідно з теорією типів будь-який тип розглядається, як множина елементів, для кожного з яких одна чи сукупність предикатних функцій приймають значення істини. Тобто, якщо певне d Î D (D – домен) і Y = {Y₁, Y₂, … Y_n} – сукупність предикатних функцій, то тип T визначається виразом

T = {d: D | Y}.

Відповідно до цього для поняття типу існує наступне визначення.

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

Формально кожен тип даних подається як абстрактна система, що складається з множини значень (домену даних для цього типу) та сукупності операцій над цією множиною (сигнатури типу) [1, 13]. Тобто тип даних розглядається, як алгебраїчна система, алгебра чи розширення алгебри. В подальшому замість виразу (1) буде застосовуватись вираз

T = ( X, W ),

де X – множина елементів типу даних; W – сукупність операцій над елементами множини.

Типи даних поділяються на базові або примітивні (наприклад, integer, real) та складні або похідні (наприклад, array, struct), які складаються з впорядкованої сукупності даних з меншим рівнем структурованості. Щоб забезпечити цілісність обробки типізованих змінних, до складу операцій для складних типів входять операції як безпосередньо над самою змінною так і над окремими складовими. Це забезпечує побудову і застосування ієрархічної системи типів даних у рамках єдиної теорії типів.

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

Узагальненням поняття типу даних є клас в термінології об’єктно–орієнтованого програмування. Для класу існує наступне визначення [2].

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

 операції над цілим екземпляром (створення, знищення, стерилізація та ін.);

 методи класу та методи екземплярів класу;

 операції над змінними класу та змінними екземпляру класу.

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

Якщо порівняти визначення типу та класу, то сутність цих термінів принципово не відрізняються на абстрактному рівні. Тому у сучасних мовах програмування ці поняття часто застосовуються як синоніми.

Розглянемо поняття типізації для компонентів. У компонентному програмуванні, яке є подальшим розвитком об’єктно–орієнтованого програмування [22], однією з основних властивостей компонентів є їх інкапсуляція. Згідно з цією властивістю будь-яка взаємодія з екземплярами компонентів відбувається за допомогою його інтерфейсів, які складаються з методів та атрибутів. Атрибут є логічним поданням схеми взаємодії з зовнішніми змінними екземпляру. Для цих змінних існують спеціальні методи, які не виконують операції обробки даних, а лише забезпечують доступ до цих змінних. Для кожної зовнішньої змінної існує пара методів – вибірки значення змінної (get–метод) та присвоєння їй нового значення (set–метод).

Тобто, з узагальнюючої точки зору, інтерфейс екземпляру компонента складається з сукупності методів. Кожен компонент може мати кілька таких інтерфейсів, які визначають його функціональні властивості. Крім цього, компонент має спеціальний інтерфейс, методи якого працюють з цілими екземплярами (наприклад у компонентної моделі EJB мови програмування Java такий інтерфейс називається “домашній ” інтерфейс або Home–інтерфейс) [11]. До складу цих методів, зокрема, входять методи пошуку екземплярів компонента, їх створення, знищення, тощо. Для кожного компоненту можуть існувати кілька методів пошуку, створення і т.д. в залежності від алгоритму виконання цієї операції та відповідної сигнатури. Наприклад, пошук екземпляру компонента може відбуватись за його унікальним ідентифікатором або значенням певної змінної.

Кожен компонент характеризується:

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

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

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

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

Якщо існують два типи T¹ = ( X¹, W¹ ) і T² = ( X², W² ), то T¹ тип зводиться до T² за наступної умови T¹ –> T², якщо F(X¹)² ,

де F – функція перетворення множин, W² Î W¹.

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

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

З наведеного вище необхідно зробити висновок, що операції приведення для типів і класів семантично еквівалентні. Розглянемо операцію приведення для компонентів. З визначення програмного компоненту можливо зробити наступні висновки:

 компонент може мати кілька інтерфейсів;

 реалізації одного і того ж компонента можуть мати різну структуру та поведінку;

 статичний аспект перевірки типів для компонентів принципово не можливий.

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

 будь-який екземпляр обов’язково є екземпляром певного класу і має усі методи, які визначені у цьому класі;

 екземпляр класу може бути приведений у відповідності з одним із суперкласів або у відповідності до інтерфейсу, який реалізується в цьому класі.

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

Аналогічно існує суттєва різниця на рівні класів і компонентів. З точки зору типізації клас є цілком визначеним статичним поняттям. Напроти, вираз “тип компоненту ” є невизначеним поняттям у статичному аспекті. Під час функціонування компонентної програми для компонента може існувати кілька екземплярів різної структури та поведінки. Тому операція приведення компонента у відповідності з одним з його інтерфейсів у динамічному аспекті також не визначена і вона може виконуватись тільки для його окремих екземплярів.

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

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

Нехай C – множина елементів tⁱ₁, tⁱ₂, … tⁱ_r є сукупністю ознак таких, що для кожного cÎ C існує тільки одна ознака, яка властива даному елементу. Введемо сукупність Tⁱ = {tⁱ₁, tⁱ₂, … tⁱ_r}. Тоді на множині C існує еквівалентність відносно Tⁱ. Для елементів кожного з класів еквівалентності C ⁱ_j властива ознака tⁱ_j і об’єднання C ⁱ_j складають множину C, тобто C = C ⁱ₁ Î C ⁱ₂ ,Î … ,Î C ⁱ_r.

Назвемо Tⁱ класифікаційною характеристикою Tⁱ, а кожне з tⁱ_j – класифікаційною ознакою характеристики Tⁱ. Нехай T = {T¹, T², …, Tⁿ}, де кожне Tⁱ є класифікаційною характеристикою. Тоді T визначає класифікаційну систему для множини C. Введемо наступні визначення.

Множина C є класифікованою множиною, якщо для неї існує класифікаційна система T.

Метод класифікації для множини C – це спосіб побудови класифікаційної системи T за умови виконання вимог відношення еквівалентності на цій множині.

Класифікаційна характеристика Tⁱ є повною для множини C, якщо для кожного елементу c Î C обов’язково існує класифікаційна ознака з Tⁱ.

Класифікаційна характеристика Tⁱ є частковою для множини C, якщо існує C₁ Î C і для кожного елементу c Î C₁ не існує класифікаційної ознаки з Tⁱ. Такий випадок існує, коли класифікаційні характеристики залежні одна від одної. Наприклад, характеристика T¹ є повною для множини C і визначає класи еквівалентності C¹₁ C¹₂ … C¹_r , а характеристика T² є повною лише для одного або кількох C¹_j .

Класифікаційні характеристики T¹ і T² ієрархічно впорядковані, якщо:

 T¹ є повною характеристикою для певної підмножини C₁Î C (або самої C);

 T² є частковою характеристикою для C₁;

 T² є повною класифікаційною характеристикою для одного з класів еквівалентності C¹_j Î C₁.

З наведеного вище існує кілька наслідків.

По–перше, для однієї і тієї ж множини може існувати багато систем класифікації.

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

По–третє, кожен метод класифікації визначається:

 способом групування первинних ознак у класифікаційні характеристики;

 типом класифікаційних характеристик (повні чи часткові);

 ієрархічними відношеннями між характеристиками.

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

По–перше, розподілити елементи множини серед підмножин згідно з певними знаннями про саму множину та окремі елементи, їх взаємозв’язки, семантичні ознаки, тощо. Рішення цієї задачі дає можливість за належністю конкретного елемента множини до певного класу еквівалентності визначити апріорі сукупність властивостей даного елементу. Якщо певний елемент c Î Cⁱ_j , то c має ознаку tⁱ_j з класифікаційної характеристики Tⁱ.

По–друге, забезпечити можливість швидкого пошуку елементів множини відповідно до умов, які пов’язані з класифікаційними ознаками. Тобто, результатом пошуку є клас еквівалентності, який відповідає заданим властивостям. Пошук відбувається відповідно до заданих класифікаційних характеристик T¹, …,T^s і конкретних ознак з цих класифікаційних характеристик.

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

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

Єдиної системи класифікації на цей час не існує. Побудова будь-якої класифікаційної системи для компонентів засновується на загальних знаннях про компоненти та їх застосування. Ці знання розподіляються серед наступних груп загальних властивостей компонентів [3]:

 структурні ознаки;

 функціональні можливості;

 характеристики поведінки.

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

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

Якщо є компонент, який відповідно до наведеної класифікації побудований для конкретної моделі, то з ним пов’язана певна сукупність знань про нього, зокрема:

 операційні системи, на яких компонент може функціонувати;

 особливості його побудови;

 методи розгортання;

 особливості взаємодії з іншими компонентами та ін.

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

- повні сервери (самостійні, завершені застосування, що мають додаткові можливості, які дозволяють даному компоненту бути вбудованим у інші застосування, тобто вони можуть бути окремими складовими при побудові компонентів більшого рівня структурованості);

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

 міні–сервери (додаткові компоненти, які не мають ознак самостійного функціонування у компонентному середовищі і можуть застосовуватись лише у операційному контексті клієнтського компонента);

 компоненти Active X (різновид міні–серверів, які подаються як самостійні бібліотеки, що можуть бути передані у мережі, наприклад для функціонування у середовищі Інтернет–браузера);

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

Ця класифікація є розширенням класифікації в плані класифікаційних характеристик T¹ для вже визначених класів еквівалентності і для одного з класів з ознакою COM, вводиться нова класифікаційна характеристика T². Вона є частковою характеристикою для усієї множини компонентів Comp і повною для множини COM–компонентів. Класифікаційні характеристики T¹ і T² ієрархічно впорядковані.

Розглянемо класифікаційні ознаки для T². Аналіз наведеної вище послідовності класів класифікації показує, що існує кілька характеристик, за якими побудовані відповідні класи. Це, зокрема, характеристики для:

 рівня завершеності застосування;

 можливості вбудовування в компоненти більш вищого рівня структурованості;

 типу і виду середовища функціонування;

 наявність зв’язків з інтерфейсом кінцевого користувача.

У принципі можливо сформувати класифікаційну систему на основі усіх чотирьох класифікаційних характеристиках. Проте для такої системи багато класів еквівалентності не мають смислу або практично безкорисні. Наприклад, процес є самостійним фоновим завданням у операційній системі і тому недоцільно його розглядати з точки зору можливості бути вбудованим в компоненти більш вищого рівня структурованості. Враховуючи, що практично корисними є лише 5 класів компонентів, одним із рішень може бути безпосереднє формування одної характеристики, що має 5 ознак (кожна для відповідного класу). При такому підході існує ймовірність втрати інформації, проте кількість класів еквівалентності для класифікаційної системи значно зменшиться. У цьому випадку T² = {повний сервер, звичайний сервер автоматизації,

міні–сервер, компонент Active X, сервер процесу}. ( 5)

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

Як і для попереднього прикладу класифікації віднесення конкретного COM компонента до певного класу дозволяє мати знання про його структуру, подання, методи застосування та ін.

Основи класифікації компонентів за архітектурними ознаками

Загальна класифікація компонентів за ознаками архітектури корпоративних застосувань (КЗ) це . архітектурна модель, що складається з чотирьох рівній, наведених в табл. 2.1.

Таблиця 2.1. Схема розташування рівній архітектури КЗ

У відповідності до цієї схеми існують наступні рівні.

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

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

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

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

Характеристика T¹ буде відповідати рівню архітектури, тобто множину компонентів для побудови корпоративних систем поділяється на рівні архітектури: T¹ = {Подання, Логіка застосування, Джерела даних, Інформаційні ресурси}.

Характеристика T² буде відповідати рівню подання клієнта та Web–серверу:

T² = {Клієнт, Web–сервер, Сервер застосувань, Сервер даних}.

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

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

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

 системного середовища (операційної системи);

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

– стандартні компоненти, які реалізують типові шаблони проектування (наприклад, ORM–засоби, Table Module, DataSet) та ін.

Таблиця 2. Методи, моделі та засоби побудови КЗ

Сукупність наведених характеристик відповідає побудові класифікації компонентів Веб–застосувань

Типові рішення системи класифікації КП. Воно досягло значного рівня зрілості і можливо віднести такі елементи:

 структурау компонента;

 структура базового компонентного середовища – компонентного каркасу (framework);

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

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

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

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

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

1. II. Класифікація видатків та кредитування бюджету.
2. V. Класифікація і внесення поправок
3. V. Класифікація рахунків
4. А. Структурно-функціональна класифікація нирок залежно від ступеню злиття окремих нирочок у компактний орган.
5. Адміністративні провадження: поняття, класифікація, стадії
6. Аналітичні процедури внутрішнього аудиту та їх класифікація.
7. Баланс енергій у видобувній свердловині і класифікація видобувних свердловин за способом їх експлуатації
8. Банківська платіжна картка як засіб розрахунків. Класифікація платіжних карток
9. Банківський кредит та його класифікація.
10. Банківські ресурси, їх види та класифікація
11. Будівельна класифікація ґрунтів
12. Будівельні домкрати, їх призначення, класифікація та конструкція.

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