Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Покомпонентна розробка




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

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

Погляд на компонент як постачальника сервісів визначається двома основними характеристиками, що допускають повторне використання:

1) Компонент – це програмний об’єкт, що виконується незалежно. Його вихідний код може бути недоступним, тому такий компонент не компілюється з іншими компонентам системи;

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

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

Рис. 1. Компонент служби друку

Компоненти можуть існувати на різних рівнях абстракції – від простої бібліотечної підпрограми до цілих додатків:

1) Функціональна абстракція (компонент реалізує певну функцію, яка й є його інтерфейсом);

2) Безсистемне групування (компонент – набір слабко зв’язаних між собою програмних об’єктів і підпрограм, інтерфейс складається з назв усіх об’єктів у групуванні);

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

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

5) Системні абстракції (компонент – повністю автономна система, інтерфейс - API, що надає доступ до системних команд і методів).

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

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

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

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

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




Поделиться с друзьями:


Дата добавления: 2014-01-11; Просмотров: 949; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.009 сек.