ПроектнийПрактикум / ПрофесійнаПрактика / Разное / lavrishcheva-6

Якщо друга СКБД реляційного типа, то дані в транзитних файлах перетворяться до табличного вигляду. Якщо перша СКБД не реляційна, то дані повинні бути приведені до табличного вигляду і першої нормальної форми.

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

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

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

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

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

Як уніфікований формат транзитних файлів використовують формат DBFфайлів, оскільки багато СКБД, такі, як DB2, FохРго і деякі інші, зберігають дані в таких файлах, тим самим немає потріби у початковому перенесенні даних із старої СКБД до транзитних файлів. Більшість СКБД, формат зберігання даних яких відрізняється від формату DBF-файлів, забезпечується утилітами або драйверами, що дозволяють перенести дані в такий формат.

7.4. Методи еволюційного змінювання компонентів і систем

Готові ПС активно використовують при створенні і супроводі нових систем. При цьому виникають різного роду помилки, які вимагають внесення змін у систему після того, як помилка виявлена або виникла необхідність у зміні або покращенні певних характеристик системи [17–24] .

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

Типові причини внесення змін це:

–виявлення дефектів в системі під час експлуатації, які не були виявлені на процесі тестування;

–з'ясування невідповідності або невиконання деяких вимог замовника, через що система не виконує окремі функції;

–зміна умов замовником, які пов'язані з коригуванням раніше поставлених їм

вимог.

Як стверджують експерти, процес внесення змін в експлуатовану систему досить дорогий, його вартість досягає від 60 до 80 % загальної вартості розробки системи.

До видів супроводу належать:

–коригування – внесення змін в діючу ПС для усунення помилок, які були виявлені після передачі системи до експлуатації;

–адаптація продукту до змінених умов (апаратури, ОС) використання системи після її передачі в експлуатацію;

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

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

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

В цілому процес зміни (еволюції) ПС проводиться шляхом:

–аналізу початкового коду для внесення в нього змін;

–настроювання компонентів і системи на нові платформи;

–кодування і декодування даних при переході з однієї платформи на іншу;

–зміни функцій системи або додавання нових;

–розширення можливостей (сервісу, мобільності та ін.) компонентів;

–перетворення структури системи або окремих її компонентів.

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

Наприклад, широкого кола фахівців торкнулася проблема зміни формату дати в 2000 році. Для систематичного перероблення функціонуючих програм з новими можливостями ОС, мов і платформ сучасних комп'ютерів і т.п. використовується сучасний офсорсинг програмування (Індія, Росія, Україна та ін.).

Внесення змін до ПС можна розглядати як еволюційний шлях його розвитку. Еволюція ПО здійснюється такими зовнішніми методами обробки компонентів в розподіленому середовищі і внутрішніми методами, як зміна компонентів (Сом), інтерфейсів (Int) і/або систем. До внутрішніх методів еволюції належать методи реінженерії, рефакторинга і реверсної інженерії (рис. 7.10).

Рис. 7.10. Схема методів еволюційної зміни компонентів ПС

Ці методи забезпечують різнопланову зміну програм або систем.

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

Суть цих методів полягає в такому:

–реінженерія забезпечує перепрограмування окремих компонентів на нові МП, платформи і середовища, а також розширення можливостей ПС;

–рефакторинг забезпечує внесення змін в компоненти або інтерфейси (додавання, розширення і т.д.), додавання екземплярів компонентів, нових функцій або системних сервісів;

–реверсна інженерія означає повну переробку компонентів, а іноді і перепрограмування всієї системи.

7.4.1. Реінженерія програмних систем

Реінженерія (reengineering) – це еволюція програми (системи) шляхом її зміни з метою підвищення зручності її експлуатації, супроводу або зміни її функцій. Вона містить у собі процеси реорганізації і реструктуризації системи, переведення окремих компонентів системи в іншу, сучаснішу МП, а також процеси модифікації або модернізації структури і системи даних. При цьому архітектура системи може залишатися незмінною [18].

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

З технічної точки зору реінженерія – це вирішення проблеми еволюції системи шляхом зміни її компонентів, архітектури в середовищі, в якому компоненти розміщуються на різних комп'ютерах. Причиною еволюції може бути зміна МП системи, наприклад, Fortran, Сobol і ін. з переходом на сучасні об'єктноорієнтовані мови, такі, як Java або C++.

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

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

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

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

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

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

До основних процесів процесу реінженерії належать:

– переклад початкового коду в старій МП на сучасну версію цієї мови або в іншій МП;

–аналіз програм згідно з документованою структурою і функціональними можливостями системи;

–модифікація структури програм для нарощування нових властивостей і можливостей;

– розбиття системи на модулі для їхнього групування і усунення надмірності;

– зміна даних, з якими працює програма.

Причинами, що вимагають перетворення початкового коду програм в іншу мову, можуть бути:

– оновлення платформи апаратних засобів, на якій може не виконуватися компілятор МП;

– недолік кваліфікованого персоналу для програм, написаних в МП, що вже не застосовують;

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

– іменування змінних компонентів і їхня ідентифікація;

– розширення функцій існуючої реалізації компонентів;

– переклад мови компонента в нову сучасну МП;

– реструктуризація компонента;

– модифікація опису компонента і його даних.

7.4.2. Рефакторінг компонентів

Рефакторінг розвивається в об'єктно-орієнтованому програмуванні у зв'язку з широким застосуванням інтерфейсів, шаблонів проектування і методів покращання коду [5, 17]. Розроблено бібліотеки типових трансформацій пошукових об'єктів (класів), які покращують ті або інші характеристики ПС.

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

Процес рефакторингу орієнтується на отримання нових компонентів, які містять у собі такі операції з організації проведення змін:

–додавання нової реалізації для існуючого і нового інтерфейсу;

–заміна існуючої реалізації нової з еквівалентною функціональністю;

–додавання нового інтерфейсу (за наявності відповідної реалізації);

–розширення існуючого інтерфейсу для нових системних сервісів у компонентному середовищі.

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

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

Операції над компонентами задовольняють умови:

–об'єкт, одержаний внаслідок рефакторингу, – це компонент з відповідними властивостями, характеристиками і типовою структурою;

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

–перебудова компонентів, а іноді і перепрограмування проводиться в процесі реверсної інженерії [15, 18].

7.4.3. Реверсна інженерія

Методи реверсної інженерії, які розроблено в середовищі об'єктноорієнтованого програмування, ґрунтуються на виконанні базових операцій візуалізації (visual) і вимірювання метрик (metric) ПС в рамках моделі, яка пропонує такі цілі:

–забезпечення високої якості системи і перезасвідчення її розміру, складності і структури;

–пошук ієрархії класів і атрибутів програмних об'єктів з метою успадковання їх в ядрі системи;

–ідентифікація класів об'єктів з визначенням розміру і/або складності всіх класів системи;

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

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

тестів для перевірки кодів, а також проведення метричного аналізу системи для отримання фактичних значень внутрішніх і зовнішніх характеристик системи [21].

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

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

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

Висновки. Розглянуто базові поняття інтерфейсу, підходи до забезпечення інтерфейсу, мов програмування і взаємодії різномовних програм і даних. Визначено загальні проблеми неоднорідності МП, платформ комп'ютерів і середовищ, що впливають на виконання зв'язків між різномовними програмами, сформульовано шляхи їхнього вирішення. Викладено стандартні рішення ISO/IEC 11404–1996 з забезпечення незалежних від МП типів даних, стандарти з перетворення форматів даних і еволюційного змінювання програмних систем.

Контрольні питання і завдання

1.Визначте цілі і завдання інтерфейсу в програмній інженерії.

2.Назвіть системи, які ґрунтуються на інтерфейсах і забезпечують перетворення даних.

3.Охарактеризуйте стисло сучасні розподілені системи (наприклад, CORBA).

4.Назвіть методи виклику компонентів в розподілених середовищах.

5.Визначте формальну схему взаємодії програм.

6.Визначте основні завдання інтерфейсу МП.

7.Назвіть сучасні підходи до взаємодії різномовних програм.

8.Визначте проблеми перетворення форматів даних.

9.Які методи перетворення даних БД існують?

10.Визначте цілі і завдання зміни ПС при супроводі

11.Охарактеризуйте проблеми, що виникають при супроводі системи.

12.Визначте основні завдання реінженерії ПС.

13.Чим відрізняється рефакторинг компонентів від реінженерії?

14.Визначте основні операції реверсної інженерії ПС.

Список літератури до глави 7

1.Англо-український тлумачний словник з обчислювальної техніки, Інтернету, програмування. – К.: СофтПрес, 2006. – 823 с.

2.Лаврищева Е.М. Интерфейс в программировании // Проблеми програму-

вання. – 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 с.

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. Домен визначається набором понять, які однаково розуміються усіма системами сімейства та користувачами. Предметні області можна поділити на:

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

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

–універсальні, що відображають загальні функції, необхідні для використання у спеціалізованих і загальних ПрО (наприклад, системи БД, захисту, ліцензування, редагування тощо).

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

Іншими исловами, кожний домен (область) має систему знань, знайому відповідним професіоналам, з притаманними йому характерними властивостями

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

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

Четвертий напрям – це засоби і інструменти автоматизації виробництва програмних продуктів, які подаються для застосування сучасними закордонними фірмами (Microsoft, IBM, Rational Rose тощо).

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

8.1. Інженерія компонентів повторного використання

Інженерія КПВ – це систематична і цілеспрямована діяльність з підбору реалізованих і представлених у вигляді КПВ програмних артефактів, аналізу їхніх функцій для додавання їх у проектовану систему як готових компонентів та інтеграції з іншими компонентами. Згідно з стандартом ISO/IEC-12207 ця діяльність класифікується як організаційна і планована інженерна діяльність, що полягає у виявленні загальних і специфічних рис компонентів для прийняття рішень про їх використання при розробці нових ПС [1–4, 7, 8].

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