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

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

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2009
Автори:	Алексеєв, В.А., Терещенко, В.С.
Формат:	Стаття
Мова:	Українська
Опубліковано:	Інститут програмних систем НАН України 2009
Теми:	Методи програмної інженерії
Онлайн доступ:	https://nasplib.isofts.kiev.ua/handle/123456789/6578
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації / В.А. Алексеєв, В.С. Терещенко // Пробл. програмув. — 2009. — № 4. — С. 33-48. — Бібліогр.: 19 назв. — укр.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

_version_	1860178803859390464
author	Алексеєв, В.А. Терещенко, В.С.
author_facet	Алексеєв, В.А. Терещенко, В.С.
citation_txt	Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації / В.А. Алексеєв, В.С. Терещенко // Пробл. програмув. — 2009. — № 4. — С. 33-48. — Бібліогр.: 19 назв. — укр.
collection	DSpace DC
description	Розглядаються різні варіанти нотацій представлення алгоритмів прикладних задач у інформаційних системах, що дає змогу до їх програмної реалізації провести верифікацію прийнятих рішень щодо їх побудови, використовуючи для цього різноманітні засоби, притаманні кожній з цих нотацій. Рассматриваются различные варианты нотаций представления алгоритмов прикладных задач в информационных системах, что даёт возможность до их программной реализации провести верификацию принятых решений по их построению, используя для этого разнообразные средства, присущие каждой из этих нотаций. The various variants of the notations of representation of algorithms of the application tasks in information systems are considered, that enables before their program implementation to lead(carry out) verification of the accepted solutions on their construction, using for this purpose various tools, inherent by each of these notations.
first_indexed	2025-12-07T18:01:32Z
format	Article
fulltext	Методи програмної інженерії 33 УДК 681.3 В.А. Алексеєв, В.С. Терещенко БАГАТОВАРІАНТНІСТЬ НОТАЦІЙ ПРЕДСТАВЛЕННЯ АЛГОРИТМІВ ФУНКЦІОНУВАННЯ ПРОГРАМНИХ ЗАСОБІВ ЯК ШЛЯХ ДО ЇХ ВЕРИФІКАЦІЇ Розглядаються різні варіанти нотацій представлення алгоритмів прикладних задач у інформаційних системах, що дає змогу до їх програмної реалізації провести верифікацію прийнятих рішень щодо їх побудови, використовуючи для цього різноманітні засоби, притаманні кожній з цих нотацій. Вступ Суспільство, структури, технічна база та людський потенціал якого пристосовані до оптимального перетворен- ня знань у інформаційний ресурс та перероблення його з метою перекладання з пасивних форм (книги, статті, патенти тощо) у активні (моделі, алгоритми, про- грами, проекти), є інформаційним суспіль- ством [1]. Саме на створення такого сус- пільства в нашій країні направлено дію Закону України "Про Національну прог- раму інформатизації", тобто на створення сукупності взаємопов'язаних організацій- них, правових, політичних, соціально-еко- номічних, науково-технічних, виробничих процесів, що спрямовані на створення умов для задоволення інформаційних потреб громадян та суспільства на основі ство- рення, розвитку і використання інформа- ційних систем, мереж, ресурсів та інфор- маційних технологій, які побудовані на основі застосування сучасної обчислюваль- ної та комунікаційної техніки [2]. Інфор- матизація приходить в усі сфери життя суспільства. Важко собі уявити установу чи підприємство будь-якої галузі, де б не використовувалась обчислювальна техніка та інформаційні або інформаційно-теле- комунікаційні системи. Їх проектування та створення, то справа відповідних фахівців: системних проектувальників та програміс- тів з залученням необхідного інструмента- рію та методів проектування. Але розвиток таких вже існуючих систем, нарощування їх функціональних можливостей за раху- нок створення додаткових підсистем та програмно-технічних комплексів для вирі- шення нових прикладних задач не може обійтись без їхніх користувачів, що мають повноваження здійснювати обробку функ- ціональної інформації цих систем для здій- снення своїх функціональних обов'язків. Тільки такі спеціалісти, можуть визначити круг прикладних задач, які необхідно вирі- шувати в межах інформаційної системи для успішного функціонування їх установ або підприємств, визначити вимоги до їх функціонування та експлуатації. Аналізу таких вимог розробниками підсистеми буває недостатньо для визна- чення шляхів реалізації (програмування) запропонованої прикладної задачі. Для створення програмного продукту для такої задачі необхідний чіткий алгоритм її реалізації. Тут і постає питання з опису алгоритмів – упорядкованих скінчених наборів чітко визначених правил для розв’язання задач за скінчену кількість кроків [3]. Користувачі майбутніх підсис- тем, хоча і не можуть створити досконалий алгоритм та описати його у вигляді блок- схеми, але вони мають достатній досвід для формулювання, постановки та вербаль- ного опису визначеної прикладної задачі в межах тактичного завдання. У сучасних інформаційних техноло- гіях фаза життєвого циклу, на якій фіксуються вимоги на розробку програм- ного забезпечення, є визначальною для його якості, термінів та вартості робіт. Саме на цій фазі має бути зафіксовано реальні потреби користувачів, що стосу- ються функціональних, операційних та сервісних можливостей, які має реалізу- вати розробник. Ціна помилок та нечітких неоднозначних формулювань користувача на цій фазі дуже висока, бо час і засоби витрачаються на непотрібний користува- © В.А. Алексеєв, В.С. Терещенко, 2009 ISSN 1727-4907. Проблеми програмування. 2009. № 4 Методи програмної інженерії 34 чеві (замовникові) програмний продукт, оскільки він мав на увазі зовсім інше, але не зумів сформулювати свої потреби. Внесення необхідних коректив при цьому може вимагати значних переробок, а інколи і повного перепроектування і, відповідно, перепрограмування [4]. Для уникнення такої негативної перспективи необхідно будь-який вербаль- ний опис прикладної задачі, виконаний користувачем, поступово, за допомогою обумовлених дій розробника та користу- вача перетворити у завершену блок-схему алгоритму з повним набором коментарів, яка б повністю задовольнила потреби програміста і дозволила йому створити необхідний програмний продукт. Одним із шляхів для досягнення такої мети пропо- нується між згаданими етапами, які можна вважати описами алгоритму, використати проміжні описи, які з вже згаданими утворять упорядкований (направлений) ряд описів алгоритмів, можливості яких, з точки зору їх формалізації та жорсткості правил і вимог до їх побудови, послідовно збільшуються та поступово наближуються до блок-схемного опису. Таким чином, кожний з наступних у цьому ряді описів не зможе бути повністю створений, доки, з точки зору правил, прийнятих в такому описі, не будуть усунуті помилки та нечіткі формулювання у попередньому описі цього ряду. Така поступова поетапна верифікація описів дасть змогу послідовно вилучити вади з кожного з них. Такий підхід повністю відповідає концепції каскадної моделі, наведеної у [5, с. 67], життєвого циклу програмного продукту. На даний час серед різноманітних описів або нотацій представлення алгори- тмів функціонування програмних засобів підсистем в інформаційних системах, що застосовуються під час їх створення, можна виділити шість найбільш поши- рених способів описів, які утворюють вищезгаданий ряд: - вербальний спосіб опису алго- ритму; - табличний спосіб опису алго- ритму; - граф-схемний спосіб опису алго- ритму; - формальний або математичний спосіб опису алгоритму; - блок-схемний спосіб опису алго- ритму; - програмний спосіб опису алго- ритму, тобто створення його програми. Кожний з цих підходів має свої переваги та недоліки, свою ступінь складності та формалізації, свої можли- вості щодо повноти опису та деталізації процесів, процедур, операцій, дій, команд, що застосовано в них. Але всі вони, кожний окремо, не вільні від можливих помилок і нечітких формулювань розроб- ників, та послідовна розробка описів цього ряду й узгодження кожного з них з попереднім описом, з обов'язковим залу- ченням їх авторів-розробників, дозволяє максимально знизити кількість таких по- милок. При цьому при розробці наступного опису часто можуть виникнути утруднен- ня, які спонукатимуть потребу у внесенні змін до попереднього опису, і таким чином, поступово, використовуючи ітера- тивний підхід, здійснювати його поетапну верифікацію – перевірку системи, що здійснюється за допомогою формальних засобів для визначення відповідності системи установленим вимогам [6]. При проектуванні та розробленні програмних засобів верифікація полягає у процесі перевірки результатів певної діяльності для визначення відповідності вимогам, встановленим щодо цієї діяльності [7]. Саме цим проблемам – верифікації описів алгоритму на етапі проектування програмних засобів, тобто, на ранніх стадіях їх життєвого циклу [8, c. 46] на відміну від визначеної у літера- турних джерелах верифікації вимог до розробки та планів створення системи [4, 9] та верифікації програм вже створених програмних засобів [9, 10, 11], і присвя- чена дана робота. 1. Формальний опис структури узагальненого алгоритму Яким би не був опис алгоритму, незалежно від способу його представлення, чи то у вигляді текстів, чи то у вигляді геометричної інтерпретації множин із зв'язками, що носять характер відображень, Методи програмної інженерії 35 він має бути ретельно структурованим. Таке структурування перш за все залежить від структури самого алгоритму – будь- якої скінченої системи правил перетво- рення інформації (даних) над будь-яким скінченим алфавітом [12, с. 38]. Зважаючи на те, що алгоритмами ще називають конструктивно завдані відповідності між словами в абстрактних алфавітах [13], вважатимемо, що наш узагальнений алгоритм А обробки інфор- маційних ресурсів реалізовано у двох абстрактних алфавітах: скінченому наборі ( AS ) його складових функціональних ком- понентів (ФК), призначених для обробки інформаційних ресурсів, та скінченому наборі ( AT ) запам'ятовуючих компонентів сховища даних (КСД), призначених для зберігання результатів обробки як в корот- костроковому (технологічному), так і в довгостроковому режимі. Припустимо, що між словами пер- шого з абстрактних алфавітів ( AS ) уза- гальненого алгоритму A конструктивно завдані відповідності щодо ієрархічності ФК – послідовної вкладеності процесів { }AA SB ∈ , процедур { }AA BC ∈ , операцій { }AA CD ∈ та команд { }AA DE ∈ так, що: UUUUUUUUUU I i J j K k L l A ijkl I i J j K k A ijk I i J j A ij I i A i A EDCBS 1 1 1 11 1 11 11 = = = == = == == ==== Треба зауважити, що опис ФК містить не тільки перелік дій у межах цих ФК (процеси, процедури, операції) та інформаційних ресурсів для їх забез- печення, але і умови, при яких вони можуть мати місце та відбуватися, а команди – ФК, що характерний тільки для програмного способу опису алгоритму. Припустимо також, що між словами другого з абстрактних алфавітів ( AT ) узагальненого алгоритму (A) конструктив- но завдані відповідності щодо отримання результатів функціонування згаданих про- цесів, процедур, операцій, команд та збе- рігання їх у ієрархічних КСД – послідовно вкладених базах даних (БД) { }AA TV ∈ , таблицях БД (ТБД) { } { }AAA TVW ∈∈ та їх записах { } { } { }AAAA TVWX ∈∈∈ , реквізи- тах ТБД { } { } { }AAAA TVWY ∈∈∈ та їх за- писах { } { } { } { }AAAAA TVWYZ ∈∈∈∈ так, що: UUUUUU M m N n O o A mno M m N n A mn M m A m A XWVT 1 1 11 11 = = == == === , а також : ==== = = == == UUUUUU M m N n P p A mnp M m N n A mn M m A m A YWVT 1 1 11 11 UUUU M m N n P p R r A mnprZ 1 1 1 1= = = = = , де A mnP A mnO A mnpR YXZ ⋅= – максимально можлива кількість записів реквізитів визначеної ТБД. Тоді будь-який опис такого алго- ритму, незалежно від способу його представлення, має включати слова As алфавіту { }AAAAA EDCBS ,,,= , слова At алфавіту { }AAAAAA ZYXWVT ,,,,= та алфавітні оператори AAA ts =Γ , тобто функції що задають відповідність між словами вхідного ( AS ) та вихідного ( AT ) алфавітів цих операторів, інакше кажучи, встановлюють зв'язки між ними або відображують вхідне слово у вихідне на заданому рівні абстракції. Таким чином, опис алгоритму А у формалізованому вигляді можна предста- вити як: U F f AAA f A ts 1= =Γ=ℑ (1) при { }AA Ss ∈ та { }AA Tt ∈ . Це формальне представлення опису алгоритму в дуже загальному вигляді, але його структура накладає свій відбиток на будь-який спосіб опису (нотацію) конкрет- ного алгоритму. Через такий загальний вигляд не враховувались особливості нотацій вищеперелічених способів пред- ставлення алгоритмів, інструментарію цих нотацій, норм та правил його застосування, але ці особливості будуть висвітлені у подальших розділах. Методи програмної інженерії 36 2. Короткий опис нотацій представлення алгоритму Як вже згадувалось, існують різні способи опису алгоритму – структурної нотації його представлення, тобто, струк- турного, блок-схемного або текстового подання аспектів проектування структури програмних засобів з об'єктів, компонентів, їх інтерфейсів і взаємозв'язків [8, с. 30]. Серед них у даній роботі розглянемо: вербальний A 1ℑ , табличний A 2ℑ , граф- схемний A 3ℑ , формальний A 4ℑ , блок- схемний A 5ℑ та програмний A 6ℑ описи алгоритму А та їх порівняльний аналіз. Вербальний спосіб опису алго- ритму ( A 1ℑ ) за функціональним наван- таженням загалом тотожний експертній або концептуальній моделі, де наводиться формулювання і вербальна постановка (визначення) задачі, та дескриптивній моделі, де наводиться семантичний опис задачі, а визначення задачі, як відомо з державного стандарту [6], є її форму- лювання, що може містити опис даних, а також метод, процедури і алгоритм її розв’язання. До переваг вербального способу опису алгоритму належить застосування мови опису, яка дуже наближена до звичної людської мови, і, в залежності від вибраної нотації, крім застосування необ- хідної термінології визначеної предметної області, може включати деякі формалізми, наприклад, у позначенні різних видів інформаційних ресурсів: баз даних, їх таблиць та, можливо, їх реквізитів. Це дозволяє користувачеві, незнайомому з програмістським мистецтвом, зрозуміло викласти своє бачення щодо вирішення прикладних задач інформаційної системи у вигляді опису алгоритму звичною йому нотацією. У даному разі нотації визна- чатимуть міру узагальненості або, навпаки, – міру деталізації прийнятого способу опису. До недоліків вербального способу опису слід віднести велику складність для програмістів визначити та обумовити склад обчислювальних процедур та операцій для досягнення результату та не завжди чітке визначення переліку і місць знаходження вхідних та вихідних даних у таких процедурах. Недоліком такого способу опису алгоритму є також нечітке визначення послідовності здійснення опе- рацій у кожному з процесів та процедур, не завжди чітке визначення умовних пере- ходів, наприклад: "якщо <умова>, то <перехід 1>" забуваючи при цьому, що обов'язково має бути "інакше <перехід 2>" тощо. Це може змусити під час опра- цювання наступних описів повернутися до цього опису для його верифікації та висвітлення зазначених питань. З енциклопедичного видання відо- мо, що таблиця це перелік відомостей, числових даних, приведених у певну систему та рознесених по графах [14]. Основним положенням такої системи для запропонованої нотації табличного спосо- бу опису алгоритму ( A 2ℑ ) є використання двобічної таблиці опису алгоритму (ТОА), лівий бік якої призначено для вхідного алфавіту AS , а правий – для вихідного алфавіту AT . Зрозуміло, що відповідність слів цих алфавітів у ТОА має забез- печувати алфавітний оператор tsA =Γ . З лівого боку такої ТОА мають бути передбачені графи для опису ФК в залежності від ступеня її деталізації і умов функціонування ФК, включаючи вхідні дані та місця їх зберігання у КСД. З правого боку такої ТОА мають бути передбачені графи для зазначення місць зберігання у КСД результатів функ- ціонування ФК. Такі ТОА, завдячуючи своїй структурі, навіть на початковому етапі проектування підсистеми, спону- кають визначити не тільки ФК та умови і результати їх функціонування, але і необхідну структуру КСД (БД, ТБД, реквізити) для зберігання вхідних даних та результатів функціонування ФК. Практика показала, що навіть невеликий, з точки зору сучасних інфор- маційних систем, алгоритм потребує для свого опису значної ТОА, яка надто незручна для огляду та аналізу. До того ж велика кількість чарунок (місць перетину граф та рядків) її правого боку часто Методи програмної інженерії 37 залишаються незаповненими, що свідчить про невдалу структуру такої таблиці. Тому таку ТОА слід модифікувати: згрупувати її рядки по окремих модифікованих таблицях опису алгоритму (МТОА) в залежності від ФК, тобто для кожного процесу, процедури або, навіть, операції має бути створена окрема МТОА, як це показано у табл. 1 для процедури A ijC (j-ої процедури i-го процесу). Другий етап модифікації ТОА стосується її правого боку, де мають бути згруповані та рознесені по окремих МТОА графи, присвячені окремим КСД – БД або, навіть, ТБД в залежності від кількості реквізитів у цих ТБД, що задіяні для зберігання результатів функціонування визначеного ФК цієї МТОА, як це показано у табл. 1 для ТБД mnW (n-ої ТБД m-ої БД) та її записів і реквізитів 'mnpY , ''mnpY , '''mnpY та ''''mnpY при Pp ≤≤1 , Pp ≤≤ '1 , Pp ≤≤ ''1 , Pp ≤≤ '''1 , Pp ≤≤ ''''1 та '''''''''' ppppp ≠≠≠≠ . Якщо результати операцій проце- дури A ijC можуть зберігатись і в інших ТБД, то для них необхідно створювати такі ж за структурою, але окремі МТОА саме для цих ТБД. До переваг табличного способу опису алгоритму, крім їхньої властивості до спонукання визначення структури КСД, можна віднести також застосування звичної людської мови, хоча таблична структура обумовлює досить жорсткі вимоги до викладення положень у такому описі цією мовою, що відбивається на підвищенні рівня гарантій щодо безпо- милковості створення такого опису. Тут прозоріше виглядають каузальні зв'язки, які спонукають наводити у визначених графах лівого боку МТОА тільки зміст процедур, їх операцій, вхідних даних та умов, при яких вони мають відбуватись у відповідності до вхідного алфавіту AS . У графах правого боку МТОА безперечно мають бути тільки результати цих операції та КСД, де вони зберігаються, у відпо- відності до вихідного алфавіту AT . Таким чином, саме на цьому етапі, при цьому способі опису алгоритму проходить межа взаємних узгоджень між користувачем та системним проектувальником на будь- якому етапі верифікації. Недоліком табличного способу опи- су алгоритму є відсутність конструктивно в ньому закладених жорстких вимог до визначення послідовності проведення операцій у кожному з процесів та проце- дур. Тому це більшістю залежить від кваліфікації, прискіпливості та досвід- ченості проектувальника, що не дає без- перечних гарантій на всебічну безпо- милковість такого опису. При граф-схемному способі опису алгоритму ( A 3ℑ ), для зображення його структури використовується граф-схема, що представляє собою скінчену множину з'єднаних між собою вершин у вигляді геометричних фігур, що звуться вузлами граф-схеми [13]. На визначеному рівні деталізації опису (для процесів, процедур, операцій) у якості вузлів застосовуються спеціалізовані двографові таблички – табели (ікони), в яких крім назви ТБД зазначеного КСД у лівій графі колонкою наведено перелік реквізитів для поточного (старого) запису ТБД, а у правій – нового запису. Таким чином, сама структура такого способу опису обумовлює чітке визначення як вхідних даних для проведення операцій (старі записи) та КСД для їх зберігання, так і їх результатів (нові записи) та відповідних КСД. Це є перевагою такого способу опису алго- ритму. Як ребра такої граф-схеми засто- совуються операції, що зображуються колами чи овалами, зв'язаними стрілками з реквізитами у табелах, пронумеровані (у відповідності до послідовності їх здій- снення) та позначені (відповідними абре- віатурами, прийнятими у вербальному та табличному описах) або тільки стрілками, якщо операцією є тільки присвоєння значення даним або їх пересилання. Якщо до цих граф-схем застосувати розвинутий математичний апарат теорії графів, скажімо, для їх еквівалентного пере- творення з одночасною мінімізацією кількості вузлів, то виникає перспектива до оптимізації структури КСД. Методи програмної інженерії 38 Таблиця 1. Структура МТОА для ФК- A ijC визначеного процесу A iB та ТБД- mnW Вхідний алфавіт AS алгоритму А Вихідний алфавіт AT алгоритму А ФК процесу A iB Результати операції над записами та реквізитами ТБД mnW Процедура та її умови Операції процедури та їх умови Записи ТБД mnW Реквізит 'mnpY ТБД mnW Реквізит ''mnpY ТБД mnW Реквізит '''mnpY ТБД mnW Реквізит ''''mnpY ТБД mnW A ijD 1 ( )mn A ij A WDf ,11 ( )'11 , mnp A ij A YDf ( )''11 , mnp A ij A YDf ( )'''11 , mnp A ij A YDf ( )''''11 , mnp A ij A YDf A ijD 2 ( )mn A ij A WDf ,22 ( )'22 , mnp A ij A YDf ( )''22 , mnp A ij A YDf ( )'''22 , mnp A ij A YDf ( )''''22 , mnp A ij A YDf ... ... ... ... ... ... A ijkD ( )mn A ijk A k WDf , ( )', mnp A ijk A k YDf ( )'', mnp A ijk A k YDf ( )''', mnp A ijk A k YDf ( )'''', mnp A ijk A k YDf ... ... ... ... ... ... A ijC A ijKD ( )mn A ijK A K WDf , ( )', mnp A ijK A K YDf ( )'', mnp A ijK A K YDf ( )''', mnp A ijK A K YDf ( )'''', mnp A ijK A K YDf Недоліком такого способу є слаб- кість конструктивно закладеної вимоги до визначення послідовності операцій у кож- ному з процесів. У відповідності до неї, хоча і застосовується нумерація операцій, але вона не настільки жорстка, щоб забез- печити впевненість у безпомилкових діях розробника. І все таки, на відміну від табличного способу, можливість визначен- ня послідовності операцій при граф- схемному способі більше виражена. Формальний спосіб опису алго- ритму ( A 4ℑ ) за функціональним наванта- женням тотожний математичній моделі – системі математичних виразів, що опи- сують характеристики об'єкта моделю- вання та взаємозв'язки між ними. При його створенні використовується опис матема- тичними методами окремих операцій для встановлення кількісних та логічних залежностей між різними елементами ФК у межах цих операцій. Перевагами такого способу опису є закладена в ньому конструктивно вимога до визначення послідовності проведення операцій у кожному з процесів та процедур (жорстка нумерація операцій). Недоліком такого способу є дуже жорстка лаконічність у представленні та описі операцій. Тому його доцільно використовувати разом з іншими описами. При блок-схемному способі опису алгоритму ( A 5ℑ ), найбільш поширеному в програмістській практиці, для зображення його структури використовується блок- схема – графічне подання алгоритму чи задачі за допомогою спеціальних символів для проведення їхнього аналізу або розв’язку [15]. У такій блок-схемі на виз- наченому рівні деталізації (для процесів, процедур, операцій, команд) застосовують- ся блоки у вигляді геометричних фігур, кожна з яких несе відповідне функціональ- не навантаження [16], блокам присвою- ються номери, і вони споряджаються пояснювальним текстом. Напрям процесу обробки у блок-схемі позначається відпо- відними стрілками. Якщо один блок пере- дає керування іншим блокам у залежності від виконання певних умов, то на стрілках позначається умова, при якій процес розга- лужується. Перевагами такого способу опису алгоритму є те, що він дає найбільш повне представлення програмісту про структуру алгоритму, необхідні дії, пов'язані з безпосередньою розробкою програми для його реалізації. Це пояснюється тим, що вже складено найбільш наближений до програми формальний опис процесу вирі- шення прикладної задачі з дуже чітким визначенням послідовності проведення операцій (D), а, можливо, і команд (Е) у кожному з процесів (В) та процедур (С). Перевагами такого способу є також те, що він полегшує читання та розуміння вже створених програм для їх валідації та Методи програмної інженерії 39 верифікації, що зменшує кількість помилок при програмуванні [13]. Недоліком такого способу опису алгоритму є неодмінна необхідність у зу- силлях системного проектувальника, який міг би переосмислити будь-який поперед- ній опис у таку блок-схему, а також: - слабка залежність відчуття завершеності опису від визначення місць зберігання у КСД проміжних та кінцевих результатів функціонування ФК (це, як правило, має зазначатися у коментарях, які далеко не завжди присутні на блок-схемі), що робить дуже критичним опис від кваліфікації та досвіду розробника, тобто можливе неповне визначення вихідного алфавіту оператора алгоритму; - відсутність можливості встанов- лення певного ступеня деталізації, яка у подальшому необхідна при розробці програми, що призводить до опису одних блоків з надлишковими подробицями, а інших – у загальних рисах, через пряму залежність чіткості та повноти опису від кваліфікації та досвіду розробників. Треба зазначити, що останній недо- лік притаманний всім попереднім способам опису алгоритму. Але на відміну від попередніх способів, він дає змогу встановити нечіткість у формулюванні пояснювального тексту у ФК попередніх описів, а особливо при визначенні розга- луження процесу обробки інформації в залежності від встановлених умов. Вищеперелічені способи: табличний A 2ℑ , граф-схемний A 3ℑ , формальний A 4ℑ та блок-схемний A 5ℑ опису алгоритму за функціональним навантаженням тотожні різним аспектам логіко-інформаційної моделі, де наводиться опис алгоритму та бази даних [10, 17] і математичної (формальної) моделі. В описі A 2ℑ приді- ляється більше уваги переліку ФК та їх описів, необхідних для визначення їх суті для отримання певних результатів; у описі A 3ℑ – переліку місць зберігання вхідних даних для ФК та місць зберігання результатів їх функціонування у КСД; у описі A 4ℑ – суті математичних дій у ході операцій; у описі A 5ℑ – послідовності операцій та суті функціонування ФК . Саме ці розбіжності у наголосах цих описів і дозволяють здійснити всебічну верифі- кацію завершеного на цій стадії проекту перед переходом до програмування. За великим рахунком ці описи лише доповнюють вербальний опис, ретельно висвітлюючи його вузькі місця. Таким чином, можна сказати, що саме сукупність цих описів дає змогу створити довершений проект функціональної підсистеми – програмний опис її алгоритму. Програмний спосіб опису алго- ритму ( A 6ℑ ) за функціональним наван- таженням тотожний командній моделі, де наводиться опис програми у нотації алгоритмічної мови або у нотації інстру- ментальної системи розробки програмних засобів, наприклад: пакету S-Designer for Power Builder для проектування та генерації розподілених баз даних в архітектурі “клієнт-сервер” і створення функціональних модулів [18]. Машинні програми, створені за допомогою різно- манітних трансляторів, описом алгоритму не вважатимемо, бо це вже є завершений програмний продукт, який в такому вигляді на змінних носіях розповсюд- жується серед користувачів, на відміну від алгоритмів, що є всього лише точно визначеним правилом дій, для якого задана вказівка, як і в якій послідовності це правило необхідно застосовувати до початкових даних задачі, щоб отримати її вирішення [19], тобто проектним доку- ментом. До переваг програмного способу опису алгоритму необхідно віднести той факт, що такий завершений опис алгоритму за суттю є програмою – мовною конструкцією, що є впорядкованою послі- довністю описів і команд, призначеною для оброблення даних [3], програмним засобом, який потребує тільки перевірки та налагоджування (валідація та верифікація програм). Перевагами такого способу є також дуже чітке визначення послідовності проведення команд (Е), операцій (D) та процедур (С) у кожному з процесів (В), що і дозволяє функціонувати створеному програмному засобу. Методи програмної інженерії 40 Недоліком такого опису є те, що це найбільш складний спосіб опису алго- ритму, що підвласний тільки безпо- середньо програмісту, який, як правило, не є спеціалістом у предметній області, для автоматизації якої і призначена система. Навіть системний проектувальник тут безсилий, не кажучи вже про користувача. Подальша трансляція програмного опису у машинну програму призводить до створення завершеного програмного про- дукту, після інсталяції якого на програмно- апаратних засобах утворюється фізична модель підсистеми. 3. Порівняльний аналіз описів (нотацій представлення) алгоритму Зрозуміло що для того, щоб фізична модель функціонувала у відповідності до настанов, закладених у експертну, концеп- туальну, дескриптивну, логіко-інформа- ційну та формальну (математичну) моделі, вони мають бути еквівалентними у тому сенсі, що кінцеві результати їх реалізації мають відповідати повному набору наста- нов, закладених ще у початкову експертну модель, першим розробником якої у нашому випадку був користувач. Відповідно до цього, для заданого алгоритму А описи A 1ℑ , A 2ℑ , A 3ℑ , A 4ℑ , A 5ℑ та A 6ℑ теж мають бути еквівалентними. Описи (алгоритми) будемо вважати еквівалентними, якщо у них збігається функціональне навантаження (алфавітні оператори), але можуть не збігатися способи їх завдання. Фактично еквіва- лентність описів незалежно від їх вмісту (нотації) може бути підтверджена одна- ковим функціонуванням ( Ψ ) реалізованих за допомогою цих описів програмних за- собів ( ( )Aℑℜ ). Тобто, умовою еквівалент- ності описів є: ( ) ( ) ( )[ ⇔ℑℜΨ⇔ℑℜΨ⇔ℑℜΨ AAA 332211 ( ) ( ) ( ) ]⇒ℑℜΨ⇔ℑℜΨ⇔ℑℜΨ⇔ AAA 665544 [ ]AAAAAA 654321 ℑ⇔ℑ⇔ℑ⇔ℑ⇔ℑ⇔ℑ⇒ . (2) Інакше кажучи, функціональне навантаження незалежно від способу представлення цих еквівалентних описів має бути однаковим. Але на практиці не тільки способи представлення, але і функціональне їх навантаження дещо відрізняється через наявність у них нечітких формулювань та висловлень на початковій стадії створення цих описів – Ao 1ℑ , Ao 2ℑ , Ao 3ℑ та Ao 4ℑ : U oooo F f A r A r A rf A r ts 1= =Γ=ℑ (3) при { }AA r Ss ∈o та { }AA r Tt ∈o для { }4,3,2,1∈r , де r – індекс способу опису алгоритму; { }Ff ...,,2,1∈ – індекс ФК, що розглядаються у даному описі. Так, вербальний опис ( Ao 1ℑ ) не дозволяє бути впевненим у його функ- ціональній повноті, і може статися, що не всі необхідні для обробки інформації параметри завдані, не всі умови, які можуть бути у процесі її обробки, враховані та шляхи отримання результату передбачені, що неодмінно ускладнить розробку блок-схемного опису ( 5ℑ ), якщо взагалі дозволить це зробити. Тут стануть у пригоді наступні способи: табличний ( Ao 2ℑ ), граф-схемний ( Ao 3ℑ ), який у якійсь мірі перегукується з широко відомим нині методом мови UML, та формальний ( Ao 4ℑ ). Зрештою, описи Ao 2ℑ , Ao 3ℑ та Ao 4ℑ і призначені саме для визначення недо- опрацьованих питань, їхнього вирішення та удосконалення опису Ao 1ℑ , а разом з ним і всіх інших описів для створення безпомилкового опису A 5ℑ . Такі способи дозволять певною мірою поступово у декілька заходів (циклічно) цілеспрямо- вано верифікувати не тільки вербальний опис алгоритму, а і табличний, граф- схемний та формальний і довести їх до потрібного стану, тобто до їх еквіва- лентності (функціональної тотожності 1ℑ , A 2ℑ , A 3ℑ та A 4ℑ ), що дозволить впевнено перейти до еквівалентного з ними блок- схемного опису алгоритму ( 5ℑ ), і, на ґрунті зазначених описів, створити екві- валентний ним програмний опис ( 6ℑ ), який після трансляції стане працеспро- можним програмним продуктом. Саме Методи програмної інженерії 41 еквівалентність наведених описів алгорит- му дозволяє бути впевненим в успішному функціонуванні створеного за допомогою таких описів програмного продукту. Таким чином, еквівалентність опи- сів досягається у процесі їх верифікації внесенням відповідних, можливо, багато- разових поправок у початкові описи для їх коригування: ( )U oooo F f A r A r A rfrf A r A r ts 1= =ΓΠℑ=ℑ . (4) 4. Поетапна ітеративна верифікація описів алгоритму різних нотацій Наведені тут способи опису алго- ритму застосовують як елементи парадиг- ми імперативного програмування, де чітко визначається алгоритм та способи вирі- шення прикладної задачі (наприклад, способи опису A 1ℑ , A 4ℑ та A 5ℑ ), так і парадигми декларативного програмування, де чітко визначаються структури даних та властивість рішення задачі (наприклад, способи опису A 2ℑ та A 3ℑ ) [9]. Такий різнобічний підхід створює умови до щонайбільшого використання можливо- стей як одної, так і іншої парадигми. Зокрема, для проведення всебічної верифікації проекту алгоритму для перевірки, чи правильно він розробляється, шляхом дослідження вхідних робочих продуктів (описів попереднього способу в задекларованому ряді способів опису алгоритму) у вихідні робочі продукти (наступні описи). Під час створення опису алгоритму вербальним способом ( Ao 1ℑ ) одночасно користувачем здійснюється початкова його валідація у відповідності до загальних вимог реалізації цього алгоритму – специфікацій його проекту, які були обговорені та домовлені між замовником та розробником програмних засобів для вирішення прикладної задачі. Таку валі- дацію при створенні вербального опису не будемо розглядати серед етапів вери- фікації, які будуть викладені далі. При створенні опису алгоритму таб- личним способом ( Ao 2ℑ ) у системного про- ектувальника можуть виникнути питання щодо переліку та взаємодії ФК, переліку, напрямків та зв'язків інформаційних пото- ків з КСД запропонованої користувачем у вербальному описі алгоритму підсистеми на заданому ступені деталізації. Такий користувач разом з системним проекту- вальником має цілеспрямовано валідувати вербальний опис Ao 1ℑ та зняти ці питання шляхом внесення до нього змін та доповнень і отримати скоригований опис A' 1ℑ (4). Згодом, ці спеціалісти мають проаналізувати та верифікувати табличний опис алгоритму Ao 2ℑ та шляхом внесення до нього необхідних змін і доповнень отримати скоригований опис A' 2ℑ (4), узгоджуючи між собою ці два скориго- ваних описи. У ході такої валідації та верифікацій описів перевіряються відпо- відності потребам, несуперечності, повно- ти і можливості реалізації алгоритму, а також узгодженості зі стандартами прог- рамної інженерії [8, с. 29]. Це 1-й етап верифікації описів, у ході якого відбува- ється перше коригування вербального ( A r o 1=ℑ ) та табличного ( A r o 2=ℑ ) описів: ( )U o 2 1 ' 1 1 = Π ℑ→ℑ⇔ℜ r A r A r r . (5) Якщо при створенні опису алгорит- му граф-схемним ( Ao 3ℑ ) та формальним ( Ao 4ℑ ) способами виникають питання щодо реалізації операцій ФК та визначення КСД, де зберігаються результати цих операцій, то це спонукатиме до повернення до попе- редніх: вербального ( A r ' 1=ℑ ) та табличного ( A r ' 2=ℑ ) описів алгоритму та їх цілеспрямо- ваної верифікації щодо вказаних питань. Це 2-й етап верифікації описів та кори- гування вербального та табличного з них: ( )U 2 1 ''' 2 2 = Π ℑ→ℑ⇔ℜ r A r A r r . (6) Якщо при створенні опису алго- ритму блок-схемним способом ( Ao 5ℑ ) вини- кають питання щодо послідовності прове- дення операцій ФК, їхньої суті та визначення місць зберігання результатів цих операцій у КСД, то це спонукатиме до повернення до попередніх описів алго- Методи програмної інженерії 42 ритму ( A r '' 1=ℑ , A r '' 2=ℑ , A r o 3=ℑ і A r o 4=ℑ ) та, у ході 3- го етапу верифікації описів, їх кори- гування: ( ) ( )UU o 4 3 ' 2 1 ''''' 3 13 = Π = Π ℑ→ℑℑ→ℑ⇔ℜ r A r A r r A r A r rr . (7) Якщо виникають питання (сумніви) щодо правильності отриманих результатів під час функціонування програмного засобу, створеного за програмним описом Ao 6ℑ , то це спонукатиме до повернення до цього опису для його коригування у відповідності до Ao 5ℑ або, може, і до всіх попередніх описів ( A r ''' 1=ℑ , A r ''' 2=ℑ , A r ' 3=ℑ , A r ' 4=ℑ та Ao 5ℑ ) алгоритму та, у ході 4-го етапу верифікації описів, їх коригування. ( ) ( )UUU 4 3 ''' 2 1 ''''''' 4 24 = Π = Π ℑ→ℑℑ→ℑ⇔ℜ r A r A r r A r A r rr ( ) ( )UU oo AAAA ' 66 ' 55 1 6 1 5 ℑ→ℑℑ→ℑ ΠΠ . (8) Таким чином, процес верифікації ℜ всього ряду описів для всіх етапів ρ можна представити як: ⇔ℜ⇔ℜ = U 4 1ρ ρ                     ℑ⇔ℑ→ℑ ℑ⇔ℑ→ℑ ℑ⇔ℑ→ℑ→ℑ ℑ⇔ℑ→ℑ→ℑ ℑ⇔ℑ→ℑ→ℑ→ℑ→ℑ ℑ⇔ℑ→ℑ→ℑ→ℑ→ℑ ⇔ Π Π ΠΠ ΠΠ ΠΠΠΠ ΠΠΠΠ AAA AAA AAAA AAAA AAAAAA AAAAAA 6 ' 66 5 ' 55 4 '' 4 ' 44 3 '' 3 ' 33 2 '''' 2 ''' 2 '' 2 ' 22 1 '''' 1 ''' 1 '' 1 ' 11 1 6 1 5 2 4 1 4 2 3 1 3 4 2 3 2 2 2 1 2 4 1 3 1 2 1 1 1 o o o o o o . (9) Блок-схема здійснення такої поетап- ної верифікації показана на рис. 1. 5. Екземпліфікація верифікації описів алгоритму Екземпліфікація здійснюється на прикладі описів фрагменту реального алго- ритму діючої підсистеми, представлених різними способами. Приклад опису фрагменту алго- ритму вербальним способом. ...«Якщо у ТБД БД К-1 "Параметри контролю реєстра- ції документів" значення реквізиту "Допу- стимий сумарний термін реєстрації доку- ментів у межах інтервалу контролю" менше сумарного терміну реєстрації доку- ментів то: а) у поточному записі ТБД БД 6.1-4 "Терміни реєстрації документів" реквізиту "Порушення" надається зна-чення "2"; б) створюється "новий" запис таблиці ТБД БД 6.1-4 "Терміни реєстрації доку- ментів" (до "нового" запису з поточного здійснюється копіювання спільних даних) та для нього: - підраховується і заноситься у новий запис ТБД БД 6.1-4 "Терміни реєстрації документів" реквізиту "Дата наступного контролю терміну реєстрації документів" сума значень цього реквізиту з старого за- пису та відповідного значення реквізиту "Термін перебування на обліку" ТБД БД К-1 "Параметри контролю реєстрації доку- ментів" (у даному разі значення підра- хованого реквізиту становить дату зняття з обліку); - у "новому" записі ТБД БД 6.1-4 "Терміни реєстрації документів" реквізиту "Порушення" надається значення "2"; в) записам ТБД БД 6.1-2 "Установчі дані", які мають єдине значення реквізиту "Вид документу" (визначається за значен- ням реквізитів "Ідентифікатор запису БД 6.1-2" та "Ідентифікатор "первинного" за- пису" з ТБД БД 6.1-1): - реквізиту "Порушення" надається значення "2"; - реквізиту "Облік" надається зна- чення "1" (тобто, потрібно взяти на облік); - реквізиту "Дата встановлення на облік в БД 1.11" надається значення рек- візиту "Дата наступного контролю терміну реєстрації документів" "старого" запису ТБД БД 6.1-4 "Терміни реєстрації доку- ментів" плюс 3 доби; - реквізиту "Дата зняття з обліку" на- дається значення реквізиту "Дата наступ- ного контролю терміну реєстрації докумен тів" "нового" запису ТБД БД 6.1-4 "Тер- міни реєстрації паспортних документів"; г) формується запис ТБД БД 1.11-1 "Відомості про осіб, які перевищили термін реєстрації документів" за відповідними даними ТБД БД 6.1-2 "Установчі дані" (формування запису у ТБД БД 1.11-1 реєструється за реквізитом "Дата, час уведення інформації до БД" цієї ТБД)». Методи програмної інженерії 43 Рис. 1. Блок-схема здійснення поетапної верифікації описів алгоритмів Приклад опису фрагмента алгоритму табличним способом приводиться в табл. 2 та 3 Таблиця 2. Приклад МТОА для процедури "А" Процедури та умови, при яких вони відбуваються Результат процедури (наслідки для таблиць БД, їх записів та реквізитів) ТБД БД 6.1-4 "Терміни реєстрації документів" запис ТБД "Порушення" Процедури та загальні умови Операції та умови їх здійснення поточний (старий) новий "Дата наступного контролю терміну реєстрації документів" старий запис новий запис Процедура А Обробка записів ТБД БД 6.1-4 "Терміни реє- страції документів" для контролю сумарного терміну реєстрації Операція А.1 визначення дати на- ступного контролю терміну реєстрації документів Е4 Умова А.1 DST < ST Не зміню- ється Створюється шляхом копі- ювання спіль- них даних зі старого запи-су Значення цього реквізиту старого запису ТБД БД 6.1-4 + значення реквізиту "Термін перебування на обліку" ТБД КПД-1 "Параметри контролю реєстрації документів" 2 2 Початок Чи є питання до створення наступного опису? 2 Чи є питання до створення попереднього опису? 4 Чи є питання до створення наступного опису? 5 Чи є питання до створення попередніх описів? 7 Чи є питання до створення наступного опису? 8 5 Чи є питання до створення попереднього опису? 10 Чи є питання до створення наступного опису? 11 Чи є питання до створення попереднього опису? 13 Чи є питання до створення машинної програми? 14 Кінець 1 1 2 2 Створення граф-схемного та формального описів Ao 3ℑ ... A'' 3ℑ , Ao 4ℑ ... A'' 4ℑ 6 Створення табличних описів алгоритму Ao 2ℑ , A' 2ℑ , A'' 2ℑ , A''' 2ℑ , A'''' 2ℑ 3 Створення вербальних описів алгоритму Ao 1ℑ , A' 1ℑ , A'' 1ℑ , A''' 1ℑ , A'''' 1ℑ 1 Створення табличних описів алгоритму Ao 5ℑ , A' 5ℑ 9 Створення програмних описів алгоритму Ao 6ℑ , A' 6ℑ 12 Так Так Так Так Так Так Так Так Так Ні Ні Ні Ні Ні Ні Ні Ні Ні Методи програмної інженерії 44 Таблиця 3. Приклад МТОА для процедури "Б" Процедури та умови, при яких вони відбуваються Результат процедури (наслідки для таблиць БД, їх записів та реквізитів) ТБД БД 6.1-2 "Установчі дані" ТБД БД 1.11-1 "Відомості про осіб, які перевищили термін реєстрації документів" Процедури та загальні умови Операції та умови їх здійснення "По- руше- ння" "Об- лік" "Дата взяття на облік в БД 1. 11" "Дата зняття з обліку" Запис таблиці "Дата, час уведення інформації до БД" Процедура Б Обробка записів ТБД БД 6.1-2 "Установчі дані" та БД 1.11-1 "Відомості про осіб, які перевищили термін реєстрації документів" для контролю сумарного терміну реєстрації Операція Б.1 Тотожна проце- дурі Б Умова Б.1 DST < ST " 2" " 1" Значення реквізиту "Дата наступного контролю тер- міну реєстрації документів" старого запису ТБД БД 6.1-4 + 3 доби Значення реквізиту "Дата наступного контролю тер- міну реєстрації документів" нового запису ТБД БД 6.1-4 Формується запис за від- повідними да- ними ТБД БД 6.1-2 "Уста- новчі дані" Реєстрація Примітки: DST – значення реквізиту "Допустимий сумарний термін реєстрації документів у межах інтервалу контролю" ТБД БД К-1 "Параметри контролю реєстрації документів"; ST – значення реквізиту "Сумарний термін реєстрації документів одного виду" ТБД БД 6.1-4. Приклад опису фрагмента алгоритму граф-схемним способом показано на рис. 2 та 3. Рис. 2. Опис процедури "А" у відповідності до табл. 2 БД 6.1-2 Ст. з. Нов.з 2 as 2 bs 2 cs 2 ds 2 at 2 bt 2 ct 2 dt КПД-1 запис K as K bs K cs K ds Опер. А1 Умови А1 1 DST Опер. A1.1 4 БД 6.1-4 Ст. з. Нов.з 4 as 4 bs 4 cs 4 ds 4 at 4 bt 4 ct 4 dt 3 2 5 2 2 БД 1.11-1 Ст. з. Нов.з H as H bs H cs H ds H es H at H bt H ct H dt H et Методи програмної інженерії 45 Рис. 3. Опис процедури "Б" у відповідності до табл. 3 Позначення, що прийняті на рис. 2 та 3, наведені у табл. 4 і 5. Таблиця 4. Найменування реквізитів ТБД Новий та старий запис реквізиту ТБД Код Найменування 2 as , 2 at Порушення 2 bs , 2 bt Облік 2 cs , 2 ct Дата встановлення на облік в БД БД 6.1-2 "Установчі дані" 2 ds , 2 dt Дата зняття з обліку 4 as , 4 at Сумарний термін реєстрації документів одного виду 4 bs , 4 bt Дата наступного контролю терміну реєстрації документів 4 cs , 4 ct Контроль БД 6.1-4 "Терміни реєстрації документів" 4 ds , 4 dt Порушення K as Дата започаткування контролю K bs Термін перебування на обліку K cs Інтервал контролю БД К-1 "Параметри контролю реєстрації документів" K ds Допустимий сумарний термін реєстрації документів у межах інтервалу контролю H as , H at Порушення H bs , H bt Облік H cs , H ct Дата встановлення на облік в БД H ds , H dt Дата зняття з обліку БД 1.11-1 "Відомості про осіб, які перевищили термін реєстрації документів" H es , H et Дата та час уведення інформації до БД Таблиця 5. Найменування операцій Операція Процедура Номер Найменування 1.1 Перевірка умов А1 процедури А1 1.2 Надання значення "2" у старий запис реквізиту "Порушення" 1.3 Створення нового запису шляхом ко- піювання спільних даних зі старого 1.4 Розрахунок та занесення у новий за- пис "Дата наступного контролю тер- міну реєстрації документів" суму значень з старого запису та відповід- ного значення реквізиту "Термін перебування на обліку" БД К-1 Процедура "А" (див. табл. 2) 1.5 Надання значення "2" у новий запис реквізиту "Порушення" 2.1 Перевірка умов Б1 процедури Б1 2.2 Надання значення "2" у новий запис реквізиту "Порушення" 2.3 Надання значення "1" у новий запис реквізиту "Облік" 2.4 Надання значення "Дата наступного контролю терміну реєстрації доку- ментів" старого запису БД 6.1-4 + 3 доби у новий запис "Дата взяття на облік в БД 1.11" БД 6.1-2 2.5 Надання значення "Дата наступного контролю терміну реєстрації доку- ментів" нового запису БД 6.1-4 у но- вий "Дата зняття з обліку" БД 6.1-2 2.6 Формування запису для БД 1.11-1 за відповідними даними БД 6.1-2 Процедура "Б" (див. табл. 3) 2.7 Здійснення реєстрації у р. "Дата, час уведення інформації до БД" Опер. Б1 Умови Б1 1 2 1 4 5 3 2 7 Реєстрація Формуван- ня запису 6 операція 4 БД 6.1-2 Ст. з. Нов.з 2 as 2 bs 2 cs 2 ds 2 at 2 bt 2 ct 2 dt БД 6.1-4 Ст. з. Нов.з 4 as 4 bs 4 cs 4 ds 4 at 4 bt 4 ct 4 dt 3 КПД-1 запис K as K bs K cs K ds БД 1.11-1 Ст. з. Нов.з H as H bs H cs H ds H es H at H bt H ct H dt H et 7 Методи програмної інженерії 46 Приклад опису фрагмента алго- ритму формальним способом у вигляді математичних описів окремих операцій за процедурами наведено у табл. 6 та 7. Скорочення та визначення змінних наведені у табл. 4 та 5. Таблиця 6. Формальний опис процедури "А" Таблиця 7. Формальний опис процедури "Б" Математична операція Номер Код 2.1 ( )Θ≠∃⇒< )1(1)( 4 БfБss a K d 2.2 22 =at 2.3 12 =bt 2.4 344 += bc st 2.5 42 bd tt = 2.6 { } { }2222 ,,,,,, dcba H d H c H b H a tttttttt = 2.7 Θ≠H et Приклад опису фрагмента алгоритму блок-схемним способом показано на рис. 4. Рис. 4. Опис фрагмента алгоритму блок-схемним способом Математична операція Номер Код 1.1 ( )Θ≠∃⇒< )1(1)( 4 AfAss a K d , де Θ – пуста множина 1.2 24 =ds 1.3 44 aa st = , 44 bb st = , 44 cc st = , 44 dd st = 1.4 K bbb sst += 44 1.5 24 =at Початок 4 a K d ss < 1 Так Ні 24 =ds 1.2 44 aa st = , 44 aa st = , 44 aa st = , 44 aa st = . 1.3 K bbb sst += 44 1.4 24 =at 1.5 12 =bt 344 += bc st 2.4 42 bd tt = 2.5 24 aa tt = , 24 bb tt = , 24 cc tt = , 24 dd tt = . 2.6 Реєстрація у H et 2.7 22 =at 2.2 До іншого фрагмента алгоритму 1 1 Кінець Процедура "А" Процедура "Б" 2.3 Методи програмної інженерії 47 Висновки У роботі запропоновано підхід до верифікації вербального опису алгоритму вирішення прикладної задачі у складі інформаційної системи. Такий опис ство- рюється на початковій стадії проектування, під час визначення та збору вимог до функціонування такої задачі з боку користувача інформаційної системи та системного проектувальника. Практика показала, що якість такого опису далека від бажаної. Помилки через нечіткі або неоднозначні формулювання вимог можуть призвести до того, що виготовлений програмний продукт не буде задовольняти замовника – того самого користувача. Тому на етапах розробки проекту вимоги, а з ними і вербальний опис задачі, мають постійно уточнюватись як користувачем, так і системним проектувальником: корис- тувачем – для уточнення самої задачі, а проектувальником – для коректного і якіс- ного викладення її у вигляді відповідного опису. Для досягнення цього пропонується верифікувати початковий вербальний опис алгоритму за допомогою інших описів алгоритму, створених у табличний, граф- схемний, формальний та блок-схемний спосіб. Це дозволяє заздалегідь, до стадії програмування, поетапно виявити та ви- правити помилки та неточності як у вербальному, так і у інших описах, і створити досконалу блок-схему алгоритму для використання програмістами під час розробки програмного продукту. Треба зазначити, що хоча наведені тут способи опису алгоритму вже давно відомі, але їх застосування у такому контексті запропоновано уперше. І ще, такий підхід можна розглядати як відгалу- ження методики проектування великих систем так званим методом формалізо- ваних технічних завдань [12, с. 151], де замість проблемно-орієнтованих алгорит- мічних мов використовується визначений ряд способів опису алгоритму. Як перспективу подальшої роботи у цьому напрямку можна запропонувати застосування математичного апарату теорії графів для еквівалентного перетворення граф-схем з мінімізацією кількості вузлів, що може призвести до оптимізації структури КСД при реалізації заданого алгоритму. 1. Каныгин Ю.М., Калитич Г.И. "Основы теоретической информатики". – Киев: Наук. думка, 1990. – 232 с. 2. Закон України "Про Національну програму інформатизації" від 4.02.1998, № 74/98-ВР (із змінами, внесеними згідно із Законом від 13.09.2001, № 2684-III). 3. ДСТУ 2938-94. Системи оброблення інформації. Основні поняття. Терміни та визначення. Держстандарт України. 4. Бабенко Л.П., Лавріщева К.М. Основи програмної інженерії: Навч. посіб. – К.: Т- во "Знання", КОО, 2001. – 209 с. 5. Software Engineering: a European Respective. IEEE Computer Society Press, Los Almitos, California. – Washington, Brussels, Tokyo, 1993. – 682 р. 6. ДСТУ 2941-94. Системи оброблення інформації. Розроблення систем. Терміни та визначення. Держстандарт України. 7. ДСТУ 3918-99 (ISO/IEC 12207:1995) Інформаційні технології. Процеси життє- вого циклу програмного забезпечення. Держстандарт України. 8. Лавріщева К.М. Програмна інженерія. – К., 2008. – 319 с. 9. Андон Ф.И., Лаврищева Е.М., Суслов В.Ю. и др. Основы инженерии качества програм- мных систем. – 2-е изд., перераб. и доп. – Киев: Академпериодика, 2007. – 672 с. 10. Вендров А.М. Проектирование програм- много обеспечения экономических инфор- мационных систем: Учебник. – М.: Финан- сы и статистика, 2000. – 352 с. 11. Колдовский В. Разработка ПО: оценка ре- ультата. http://itc.ua/node/25631. 12. Глушков В.М. Основы безбумажной инфор- атики. – М.: Наука. Гл. ред. Физ.-мат. лит., 1987. – 552 с. 13. Алфёрова З.В. Теория алгоритмов. – М.: Издательство "Статистика", 1973. – 164 с. 14. Советский энциклопедический словарь. – М.: Советская энциклопедия,1989. – 1632 с. Методи програмної інженерії 48 15. ДСТУ 2226-93. Автоматизовані системи. Терміни та визначення. Держстандарт України. 16. ГОСТ 19.701-90 Единая система програм- ной документации. Схемы алгоритмов и программ. 17. Башлыков А.А. Проектирование систем принятия решений в энергетике. – М.: Энергоатомиздат, 1986. – 120 с. 18. Калянов Г.Н. CASE. Структурный систем- ный анализ (автоматизация и применение). – М.: Лори, 1996. – 327 с. 19. Энциклопедия кибернетики / В 2-х томах. – Киев: Главная редакция Украинской советской энциклопедии АН УССР, 1974. – 1232 с. О Отримано 20.07.2009 Про авторів: Алексеєв Віктор Анатолійович, кандидат технічних наук, завідуючий відділом, Терещенко Валерій Савелійович, кандидат технічних наук, старший науковий співробітник. Місце роботи авторів: Інститут програмних систем НАН України, 03187, Київ-187, Проспект Академіка Глушкова, 40. Тел.: (044) 526 4228; (044) 526 6191; факс.: (044) 526 4228. e-mail: alekseev@isofts.kiev.ua, terek@isofts.kiev.ua
id	nasplib_isofts_kiev_ua-123456789-6578
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
issn	1727-4907
language	Ukrainian
last_indexed	2025-12-07T18:01:32Z
publishDate	2009
publisher	Інститут програмних систем НАН України
record_format	dspace
spelling	Алексеєв, В.А. Терещенко, В.С. 2010-03-09T12:24:45Z 2010-03-09T12:24:45Z 2009 Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації / В.А. Алексеєв, В.С. Терещенко // Пробл. програмув. — 2009. — № 4. — С. 33-48. — Бібліогр.: 19 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/6578 681.3 Розглядаються різні варіанти нотацій представлення алгоритмів прикладних задач у інформаційних системах, що дає змогу до їх програмної реалізації провести верифікацію прийнятих рішень щодо їх побудови, використовуючи для цього різноманітні засоби, притаманні кожній з цих нотацій. Рассматриваются различные варианты нотаций представления алгоритмов прикладных задач в информационных системах, что даёт возможность до их программной реализации провести верификацию принятых решений по их построению, используя для этого разнообразные средства, присущие каждой из этих нотаций. The various variants of the notations of representation of algorithms of the application tasks in information systems are considered, that enables before their program implementation to lead(carry out) verification of the accepted solutions on their construction, using for this purpose various tools, inherent by each of these notations. uk Інститут програмних систем НАН України Методи програмної інженерії Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації Многовариантность нотаций представ-ления алгоритмов функционирования программных средств как путь к их верификации Multivariance of the notations of represen-tation of algorithms of operation of software as path to their verification Article published earlier
spellingShingle	Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації Алексеєв, В.А. Терещенко, В.С. Методи програмної інженерії
title	Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації
title_alt	Многовариантность нотаций представ-ления алгоритмов функционирования программных средств как путь к их верификации Multivariance of the notations of represen-tation of algorithms of operation of software as path to their verification
title_full	Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації
title_fullStr	Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації
title_full_unstemmed	Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації
title_short	Багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації
title_sort	багатоваріантність нотацій представлення алгоритмів функціонування програмних засобів як шлях до їх верифікації
topic	Методи програмної інженерії
topic_facet	Методи програмної інженерії
url	https://nasplib.isofts.kiev.ua/handle/123456789/6578
work_keys_str_mv	AT alekseêvva bagatovaríantnístʹnotacíipredstavlennâalgoritmívfunkcíonuvannâprogramnihzasobívâkšlâhdoíhverifíkacíí AT tereŝenkovs bagatovaríantnístʹnotacíipredstavlennâalgoritmívfunkcíonuvannâprogramnihzasobívâkšlâhdoíhverifíkacíí AT alekseêvva mnogovariantnostʹnotaciipredstavleniâalgoritmovfunkcionirovaniâprogrammnyhsredstvkakputʹkihverifikacii AT tereŝenkovs mnogovariantnostʹnotaciipredstavleniâalgoritmovfunkcionirovaniâprogrammnyhsredstvkakputʹkihverifikacii AT alekseêvva multivarianceofthenotationsofrepresentationofalgorithmsofoperationofsoftwareaspathtotheirverification AT tereŝenkovs multivarianceofthenotationsofrepresentationofalgorithmsofoperationofsoftwareaspathtotheirverification

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

Репозитарії

Схожі ресурси