К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Висновки. Розглянуто базові поняття інтерфейсу, підходи до забезпечення інтерфейсу, мов програмування і взаємодії різномовних програм і даних. Визначено загальні проблеми неоднорідності МП, платформ комп'ютерів і середовищ, що впливають на виконання зв'язків між різномовними програмами, сформульовано шляхи їхнього вирішення. Викладено стандартні рішення ISO/IEC 11404–1996 з забезпечення незалежних від МП типів даних, стандарти з перетворення форматів даних і еволюційного змінювання програмних систем. Контрольні питання і завдання 1. Визначте цілі і завдання інтерфейсу в програмній інженерії. 2. Назвіть системи, які ґрунтуються на інтерфейсах і забезпечують перетворення даних. 3. Охарактеризуйте стисло сучасні розподілені системи (наприклад, CORBA). 4. Назвіть методи виклику компонентів в розподілених середовищах. 5. Визначте формальну схему взаємодії програм. 6. Визначте основні завдання інтерфейсу МП. 7. Назвіть сучасні підходи до взаємодії різномовних програм. 8. Визначте проблеми перетворення форматів даних. 9. Які методи перетворення даних БД існують? 10. Визначте цілі і завдання зміни ПС при супроводі 11. Охарактеризуйте проблеми, що виникають при супроводі системи. 12. Визначте основні завдання реінженерії ПС. 13. Чим відрізняється рефакторинг компонентів від реінженерії? 14. Визначте основні операції реверсної інженерії ПС. Список літератури до глави 7 1. Англо-український тлумачний словник з обчислювальної техніки, Інтернету, програмування. – К.: СофтПрес, 2006. – 823 с. 2. Лаврищева Е.М. Интерфейс в программировании // Проблеми програму- Розділ 7 207 вання. – 2007. – № 2. – С. 126 – 139. 3. Wegner P. Interaction Foundation of Object–oriented Programming ECOOP – 97 th Europian Conference on OOP Finland, June 9–12, 1997.–С.123–139. 4. Летичевский А.А, Маринченко В.Г. Объекты в системе алгебраического программирования // Кибернетика и системный анализ. – 1997 .– № 2. – С. 160–180. 5. Open Software Foundation. Introduce to Open Software Foundation. Distributed Computed Environments. – Englewood Cliffs: Prentice Hall, 1993. – 437 p. 6. Corbin J. The art of Distributed Application. Programming Techn. For Remote Procedure Calls. – Berlin: Springer Verlag, 1992. – 305 p. 7. Роджерсон Д. Основы СОМ. Руск.пер .– Microsoft Press, 1996. – 361 c. 8. CORBA. The Common Object Request Broker: Architecture and Specification. Revision 2.0. Copyright 1991, 1992, 1995 by Sun Microsystems, Inc. – 1995. – 621 p. 9. Монсон–Хейфел Р. Enterprise JavaBeans. – СПб: Символ–Плюс, 2002. – 672 с. 10. Барлет Н., Лесли А., Симкин С. Программирование на JAVA. Путеводитель. – Киев, 1996. – 736 с. 11. Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft COM и Java RMI. – М.: Мир, 2002. – 510 с. 12. Иванников В.П., Дышлевый К.В., Мажелей С.Г., Содовская Д.Б., Шебуняев А.Б. Распределенные объектно-ориентированные среды. // М.: РАН. ИСП. Труды ИСП, 2000. – С. 84–100. 13. Лаврищева Е.М., Грищенко В.М. Сборочное программирование. – Киев: – Наук.думка, 1991. –213 с. 14. Лаврищева Е.М. Методы программирования. Теория, инженерия, практика. Киев: Наук. думка, 2006.–451с. 15. Бей И. Взаимодействие разноязыковых программ. Руководство программиста. – М.: Издательский дом «Вильямс», М.– СПб .– Киев, 2005. – 880 с. 16. ИСО/МЭК 11404:1996. Информационные технологии. Языки программирования, их среда и системный интерфейс. Независимые от языков типы данных / Межгосударственный стандарт. – Межгосударственный совет по стандартизации, метрологии и сертификации, 2000. – 112 с. 17. Фаулер М. Рефакторинг: улучшение соответствующего кода. – СПб.: Символ–Плюс, 2003 .– 432 с. 18. Пантелеймонов А.А. Аспекты реинженерии приложений с графическим интерфейсом пользователя // Проблемы программирования. – 2001. – № 1– 2. – С. 53–62. 19. Бабенко Л.П., Лаврищева Е.М. Основы программной инженерии.–Киев: Знание. – 2001. – 269 с. 20. Джордан Д. Обработка объектных бах данных в С++. Программирование по стандарту ODMG: Пер.с англ. – М.: Издательский дом «Вильямс», 2001. – 384 с. 208 Розділ 7 21. Дунаев С.Б. Доступ к базам данных и техника работы в сети. – М.: Диалог–Мифи, 1999. – 416 с. 22. Lanza M., Ducasse S. Polimetric Views – A lightweight Visual Approach to Reverse Engineering // IEEE Transaction on Software Engineering. – 2003 .– Sept., № 3 (ISSN 0098–5589). – P. 782–796. 23. Соммервилл И. Инженерия программного обеспечения. – М.: Изд. Дом «Вильямс». 24. Гласс Г., Нуазо Р. Сопровождение программного обеспечения. Пер. с англ. // Под ред. Ю.А.Чернышова. – М.: Мир .– 1983. – 256 с. 209 Розділ 8. ІНЖЕНЕРІЯ ВИРОБНИЦТВА ПРОГРАМНИХ ПРОДУКТІВ Одна з характерних рис інженерної діяльності в промисловості – використання готових рішень і деталей. У програмуванні промислове використання готових рішень і програмних продуктів ще не ввішло у повсякденну практику, але сформувалися ознаки цієї інженерної діяльності. Головна ідея компонентів, КПВ, що повторно використовуються, полягає у накопиченні досвіду програмування, отриманого під час розробок різних ПС, і подання його у вигляді, придатному для використання при побудові майбутніх систем за конвеєрною технологією. Зараз накопичено велику кількість КПВ; це привело до формування таких напрямів їхнього практичного застосування у інженерній діяльності виробництва програмних продуктів [1–4]: 1) інженерія КПВ – систематична і цілеспрямована діяльність з визначення можливостей готового компонента або повторно застосовуваного в ПС, або об’єднуваного у цільову їхню сукупність для виконання більш загальних напрямів роботи; 2) інженерія застосувань (application engineering), або прикладних систем — процес виробництва конкретних нових систем, застосувань із КПВ (модулів, програм, підпрограм та ін.), раніше створених як самостійні програмні продукти або як окремі елементи багаторазового використання в інженерії іншої предметної області; 3) інженерія ПрО або інженерія домену (domain engineering) містить у собі методи розробки, пошуку, класифікації, адаптації, збирання КПВ, а також одиночних програмних застосувань і створення з них або з готових частин прикладних систем сімейств систем. Системи сімейства зберігають напрацьований досвід з реалізації однієї прикладної проблеми предметної області для застосування його в даному або іншому, більшому сімействі. Необхідна умова цієї інженерії – системні інструментальні засоби підтримки методів накопичення КПВ і впровадження їх у системи нового сімейства. 4) інженерія виробництва ПС технологічними засобами та інструментами середовищ сучасних систем автоматизації. У програмній інженерії під доменом розуміють предметну (проблемну) область, яка трактується як сімейство систем, призначених для розв’язання різних задач (проблем) цього домену відповідними користувачами. Це визначення з’явилися у мовно-орієнтованому і генерувальному програмуванні [3, 4, 5]. Воно є новим щодо класичного визначення ПрО, яке сформоване раніше під впливом розвитку об’єктного підходу і наведене у розділі 4. Домен визначається набором понять, які однаково розуміються усіма системами сімейства та користувачами. Предметні області можна поділити на: – спеціалізовані, що відбивають специфічні і виробничі інтереси груп фахівців у рамках деякої людської спільноти (наприклад, на підприємстві відображення інтересів бухгалтерів, плановиків, керівника кадрами тощо), певної галузі науки, фірми тощо; 210 Розділ 8 – загальні, що відбивають процеси ЖЦ (визначення вимог, проектування, тестування, оцінювання показників якості тощо) або виробництво програмних систем за типом конвеєрпій технології; – універсальні, що відображають загальні функції, необхідні для використання у спеціалізованих і загальних ПрО (наприклад, системи БД, захисту, ліцензування, редагування тощо). У межах деякої ПрО розв’язуються задачі, які відображають спільні і варіантні аспекти її проблем, а також правила маніпулювання ними. Задачі представляються у моделі ПрО шляхом моделювання проблем області у просторі понять цієї предметної області або на перехресті декількох областей і входять до складу спільної мови між розробниками, користувачами і замовником системи. Іншими исловами, кожний домен (область) має систему знань, знайому відповідним професіоналам, з притаманними йому характерними властивостями (атрибутами), відношеннями та правилами поведінки. Посередником між професіоналами і розробниками різних систем, що містяться у домені (наприклад, бухгалтерська, кадрова системи тощо) є специфікована модель ПрО, яка повинна забезпечувати точність та однозначність трактування встановлених понять цієї області як фахівцям ПрО, так і різними категоріями її користувачів. Ця модель застосовується при комунікації між людьми і системами, анотуванні окремих її елементів щодо КПВ, а також при її трансформації у вихідну систему. Перший і другій напрями інженерії фактично характеризують створення унікальних, одиночних ПС з різного роду КПВ, а третій ставить завдання створення програмних систем і їхніх сукупностей з виділенням окремих частин ПС, що мають загальні властивості і характеристики, які можна багаторазово використовувати в інших системах сімейства. В основному вказані проблеми інженерії ПрО, висвітлені у параграфі 5.6 при описі генерувального програмування. Четвертий напрям – це засоби і інструменти автоматизації виробництва програмних продуктів, які подаються для застосування сучасними закордонними фірмами (Microsoft, IBM, Rational Rose тощо). Далі розглядаються названі напрями інженерії побудови програмних продуктів детальніше. 8.1. Інженерія компонентів повторного використання Інженерія КПВ – це систематична і цілеспрямована діяльність з підбору реалізованих і представлених у вигляді КПВ програмних артефактів, аналізу їхніх функцій для додавання їх у проектовану систему як готових компонентів та інтеграції з іншими компонентами. Згідно з стандартом ISO/IEC-12207 ця діяльність класифікується як організаційна і планована інженерна діяльність, що полягає у виявленні загальних і специфічних рис компонентів для прийняття рішень про їх використання при розробці нових ПС [1–4, 7, 8]. При цьому передбачається, що є каталог сховища, за допомогою якого можна зрозуміти, які КПВ є готовими «деталями» і як їх можна по'єднати в більш складну програмну конструкцію. Саме ця сторона характеризує повторне використання як систематичну і цілеспрямовану діяльність із створення і використання каталогу КПВ зі сховища або репозитарію. Розділ 8 211 Систематичне повторне використання – це капіталомісткий підхід, який передбачає наявність двох процесів ЖЦ при розробці ПС. Перший процес – це побудова КПВ шляхом: – вивчення спектра розв’язуваних задач ПрО, виявлення серед них загальних властивостей і функцій; – опис компонентів, реалізуючих виявлені функції у вигляді звичайних компонентів або КПВ; – зберігання виготовлених компонентів у каталозі і організація пошуку необхідних компонентів з запитів користувачів. Для успішної реалізації такого процесу необхідно мати певний досвід з розв’язку декількох подібних між собою задач, що дозволить визначити загальні риси і відмінності для знаходження розв’язку зїхньої реалізації, а також розробити прийоми настроювання на характерні для кожного завдання особливості. Другий процес – конструювання нових систем з готових компонентів шляхом: – визначення цілей майбутній системи і вимог, що висуваються до неї; – пошуку в каталозі готових компонентів, які можуть відповідати вимогам до нової системи; – зіставлення окремих цілій нової розробки з можливостями знайдених КПВ і прийняття рішень про доцільність і місце їхнього застосування в системі; – інтеграція КПВ у нову розробку із забезпеченням інтерфейсу з підсистемами та іншими компонентами. Перший процес вимагає вкладення капіталу, другий – дає прибуток за рахунок заощадження трудовитрат від застосування готових КПВ. Інвестиції в повторне використання вимагають оцінки ефективності вкладення капіталу, прогнозування термінів і обсягів повернення цього вкладення, оцінки ризиків та ін. Бізнес повторного використання, як будь-який бізнес, вимагає спеціальних умов щодо менеджменту всієї інженерної діяльності в межах інженерії систем із КПВ. Критерії успіху такого бізнесу визначаються такими передумовами: 1) повторне використання готових компонентів вимагає менших трудовитрат, ніж їхня нова розробка; 2) пошук придатних для використання компонентів вимагає менших зусиль, ніж реалізація необхідних функцій у проектованій системі; 3) розгортання компонентів в нових умовах середовища, потребує менших трудовитрат, ніж знов виконаної розробки. Основна парадигма КПВ – «писати один раз, виконувати багато разів, де завгодно». Архітектура, в яку вбудовується готовий КПВ, підтримує стандартні механізми для роботи з компонентами як із будівельними блоками. Щоб забезпечити високу ефективність повторного використання, вони повинні мати такі властивості, як функціональність, зручність використання і якість реалізації. Різновиди КПВ. За КПВ можуть використовуватися формалізовані артефакти діяльності розробників ПС, які відображають певну функціональність для застосування в нових розробках. Під артефактом розуміється реальна порція інформації, яка може створюватися, змінюватися і використовуватися при виконанні діяльності, пов'язаної з розробкою ПС різного призначення. Артефактами можуть бути: – моделі ПрО в термінах понять і лексики деякої предметної області; – готові компоненти ПС, КВП або окремі частини системи; 212 Розділ 8 – проміжні продукти процесу розроблення ПС (вимоги, постановки завдань, архітектура та ін.); – описи процесу проектування ПС (специфікація, модель, каркас і т.п.) – діаграми, патерни і т.п. До компонентів КПВ висуваються такі вимоги, як незалежність від конкретної платформи, наявність стандартного інтерфейсу і параметрів настроювання на нове середовище, можливість їхньої взаємодії з іншими компонентами системи без внесення в них змін. Розробці ПС за допомогою КПВ відповідає модель ЖЦ з такими загальними процесами: – аналіз об'єктів і зв’язків у ПрО, яка реалізується, для виявлення КПВ, що мають загальні властивості, притаманні групам об'єктів цієї області; – адаптація наявних в базі репозитарію КПВ, розроблення нових функціональних компонентів, не представлених у цій базі, і доведення їх до рівня повторного використання; – розроблення інтерфейсів компонентів і розміщення їх в репозитарії інтерфейсів системи; – інтеграція КПВ з їхніми інтерфейсами та іншими елементами створюваної системи і формування конфігурації цієї системи. КПВ можуть бути прикладними і загальносистемними. Прикладні компоненти виконують окремі задачі і функції прикладної області (домени бізнесу, комерції, економіки і т.п.), які можуть використовуватися надалі як прикладні системи в інших доменах з аналогічними функціями. До загальносистемних компонентів належать компоненти загального і універсального призначення, а також загальносистемні сервісні засоби, які забезпечують системне обслуговування і надають різні види сервісу для багатьох створюваних програмних систем різного призначення. До компонентів загального призначення належать: транслятори, редактори текстів, системи генерації, інтеграції, завантажувачі та ін. Вони використовуються всіма прикладними системами в процесі проектування і виконання. Універсальні системні компоненти забезпечують функціонування будь-яких (у тому числі і прикладних) компонентів, обмін даними і передачу повідомлень між усіма видами систем і компонентів, розміщених в різних операційних середовищах. До них належать ОС, СКБД, мережне забезпечення, електронна пошта та ін. Зв'язок між прикладними і загальносистемними засобами здійснюється через стандартні інтерфейси, що забезпечують взаємодію різних типів компонентів через механізми передачі даних і повідомлень. На сучасному ринку програмних продуктів циркулюють такі види готових компонентів: – процедури і функції на МП високого рівня; – алгоритми, програми; – класи об'єктів і абстрактні класи; – структури даних і часто використовувана інформація (наприклад, інформаційні ресурси Інтернету); – API, IDL-модулі в бібліотеках (наприклад, GUI, графіка і ін.); – веб-ресурси і сервіси; Розділ 8 213 – засоби розгортки систем і компонентів в операційному середовищі (наприклад, CORBA, COM, .NET) [17-19]; – готові розв’язки у вигляді абстракцій – патерни, фрейми та ін. Уся різноманітність видів і типів готових компонентів вимагає від розробників нових систем пошуку і вивчення їх для використання в цих системах. Процес розробки нових ПС за допомогою різних видів КПВ є капіталомісткий, у ньому як капітал виступають готові КПВ, на застосування яких витрачається менше зусиль та ресурсів, ніж на їхню повторну розробку. 8.1.1. Специфікація КПВ Як КПВ можуть бути класи, створені в рамках об'єктно-орієнтованого програмування (наприклад, величезна бібліотека класів в С++) разом із реалізацією їхніх методів. У компонентному програмуванні успадковується реалізація компонента і його інтерфейси. Компонент може змінюватися і поповнюватися новими функціональними можливостями і інтерфейсами. Один компонент може вміщати реалізацію декількох різних інтерфейсів, а один інтерфейс, у свою чергу, може бути реалізований в різних компонентах. Заміна одного компонента іншим не призводить до перекомпіляції ПС або перенастроювання зв'язків у ній. Приклад КПВ – контейнерні класи, які зберігають структури даних з правилами їхнього запам'ятовування або видачі чергового елемента, що входить в контейнер. Механізм контейнерів реалізовано в С++ у вигляді так званих шаблонів (templates) і їхніх бібліотек. Кожний компонент має такі властивості: – зв'язок через інтерфейси із зовнішними компонентами в процесі розроблення системи; – інкапсуляція компонента як «чорна скринька» без можливості втручання у вихідний код; – успадкування інтерфейсів, їхня зміна і настроювання на застосування; – повторне використання вихідного коду. Із загальної точки зору компонент визначається по-різному залежно від середовища і функцій. Наведемо деякі визначення [1, 2, 7]. |