Рівні абстракції компонентів.

Компоненти можуть існувати на різних рівнях абстракції - від простої бібліотечної підпрограми до цілих додатків , таких як Microsoft Excel. У роботі [Meyer B. On to components // lEEE Computer. - 1999. - 32(1). - P. 139-179. ] визначено п'ять рівнів абстракцпі компонентів.

1. Функціональна абстракція. Компонент реалізує окрему функцію, наприклад математичну. По суті , інтерфейсом постачальника сервісів тут є сама функція.

2. Безсистемне угрупування. У даному випадку компонент – це набір слабо зв'язаних між собою програмних об'єктів і підпрограм, наприклад оголошень даних, функцій і т.п. Інтерфейс постачальника сервісів складається з назв усіх об'єктів в угрупуванні.

3. Абстракції даних. Компонент є абстракцією даних або класом, описаним об'єктно-орієнтованою мовою. Інтерфейс постачальника сервісів складається з методів (операцій), що забезпечують створення, зміну та отримання доступу до абстракції даних.

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

5. Системні абстракції. Компонент є повністю автономною системою. Повторне використання абстракцій системного рівня іноді називають повторним використанням комерційних продуктів. Інтерфейсом постачальника сервісів па цьому рівні є так званий програмний інтерфейс додатків (Application Программинг lnterface – API ), який надає доступ до системних команд і методів.

Вимоги до компонентів.

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

Програмний компонент, що призначений для повторного використання, має ряд особливостей.

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

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

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

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

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

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