Міністерство освіти і науки України

Національний університет «Львівська політехніка»

кафедра САПР

Лабораторна робота №3
з дисципліни: «Розробка систем комп'ютерного проектування»
на тему: «Системний аналіз об'єкта проектування»

Виконав:
студент групи КНІТ-11
Храновський Микола
Прийняв:
Кривий Р.З.

Львів-2021
 Мета роботи: системний аналіз об’єкта проктування з визначенням мясце,
мета функціонування системи, побудова дерева цілей.

Хід роботи

У сучасній економіці значна частина активів існує в формі документованої

цифрової інформації, в тому числі відомостей про кількість активу. Тоді оборот
активу - не що інше, як зменшення кількості активу у одного суб'єкта відносин і
збільшення його - в іншого. При наявності волевиявлення суб'єктів і необхідних
організаційно-правових умов оборот активу можна розглядати як бізнес-процес
(БП) «Керувати правом володіння активом», А0. (Наприклад, передавати цифрові
грошові кошти).
Побудова IDEF0-моделі БП починається з контекстної діаграми, А0. описує
в загальному вигляді роботу системи в предметної області (рис. 1.).

Рис. 1. Контекстна діаграма БП «Керувати правом володіння активом», А0

Як вхід будемо розглядати «Дія власника активу» на передачу частини /
всього активу будь-якому покупцеві, який відповідає розглянутим нижче
вимогам. Виходом діаграми є Новий стан <кількість> активу у суб'єктів
економічного обороту. Управління сформулюємо в загальному вигляді: Правила
роботи БЧ системи. Механізм: технічним засобом підтримки БП А0, є БЧ-система
- автоматизована система, основні компоненти якої - обчислювальні
потужності(ОП), оператори ОП і P2P-мережа, реалізована в Інтернеті. Об'єднаймо
поняття ОП і його оператора терміном «вузол» і будемо розглядати, відповідно,
безліч вузлів. Деякі вузли (оператори ВС) є власниками / набувачами активу N =
{1, n} і використовують БЧ систему за призначенням. Решта - М-вузли -
забезпечують функціонування БЧ-системи (виконують технологічні функції).
Безлічі M і N перетинаються.
Внутрішня організація і функціонал БП А0, що використовує БЧ-систему,
мають оригінальні рішення. Коротко розглянемо їх. Будь-яка система підтримки
управління правом володіння активом повинна документувати це право, тобто
встановлювати зв'язок власника і активу. У БЧ-системі документування права
володіння здійснюється веденням реєстру хронології транзакцій, що фіксує всі
факти передачі права володіння. Кожна передача права володіння описується
даними транзакції: власник, який передається актив, набувач активу, кількість і
час передачі активу. У технічних термінах транзакція містить дані про облікові
записи, що передає та приймає право володіння конкретним активом. Дані
транзакцій зберігаються в порядку виконання в структурі даних БЧ. Включення
транзакцій в БЧ змінює дані власників активу, визначає поточного власника і
підтверджує дійсність транзакцій. Описана концепція організації БЧ-системи
дозволяє переформулювати Вихід процесу А0 в термінах БЧ-технології: Новий
блок в БЧ.
На рис. 2. представлений перший рівень декомпозиції БП А0, який можна
розглядати як послідовне досягнення двох предметних цілей: «Підтвердження
права володіння активом» і «Передача права володіння активом».

Рис .2. Декомпозиція БП «Керувати правом володіння активом», А0

Технічно право володіння активом може бути підтверджено шляхом
надання доступу до активу. Тоді в моделі процес А1 можна назвати «Отримати
доступ в БЧ систему» і інтерпретувати його призначення як виняток
несанкціонованого доступу до активу. У БЧ-системі передача права володіння
активом передбачає виконання як предметно значущих дій (процес «Офорти
волевиявлення», А2), так і виключно технологічних процедур (процес «Провести
системну обробку волевиявлення», А3). Обробка волевиявлення забезпечується
структурно-параметричними і функціональними рішення БЧ-системи. Семантика
процесу А1: кожна транзакція повинна містити інформацію, документує
волевиявлення власника активу на його передачу. Тому доступ в БЧ-систему для
виконання транзакції дозволений тільки власнику активу, або, в IT-термінах,
власнику відповідної облікового запису.
Вхід процесу А1. Волевиявлення власника є складною інформаційною
сутністю. У контексті процесу А1 використовуються реквізити цієї сутності логін
і пароль (когнітивні дані). Також для виконання процесу необхідні дані бази
даних (БД) облікових записів БЧ-системи. Функціонал процесу А1 включає три
стандартні функції управління доступом до облікового запису БЧ-системи:
«Ідентифікувати власника» (А11), «аутентифікувати власника» (А12) і
«авторизувати власника (Забезпечити доступ до активу)», (А13), на Рис. 3. Процес
А1 (А13) має два Виходу.
 Сутність Санкція (дозвіл функції) на А2 на проведення операції з активу
власника.
 Сутність Рахунок власника, що надходить на вхід функції А214.
Управління процесом А11 здійснюється відповідно до Порядку доступу в
БЧ систему, який входить до Правил БЧ-системи. Механізми: доступ в БЧ-
систему проводиться з ОП будь-якого вузла мережі. Для конкретизації
подальшого опису роботи БЧ системи будемо вважати, що доступ відбувається з
вузла. Примітка. Для зручності читання деяких діаграм елементи Управління та
Механізми оформлені тільки текстовими написами (без відповідних дуг). Також
для підвищення інформативності на діаграмах наведено кілька графічних
примітивів, не передбачених нотацією IDEF0. Призначена для користувача мета
«Передача права володіння активом» досягається послідовним виконанням
процесів А2 і А3 (рис. 2.) і з предметної точки зору означає зміну поточного стану
прав володіння активом.

Рис. 3. Декомпозиція процесу «Отримати доступ в БЧ-систему», А1

Процес «Оформити волевиявлення» А2 складається з процесів А21 і А22,
(діаграма декомпозиції А2 не наводиться).
Семантика процесу «Сформувати проект заявки на транзакцію» А21 полягає
в послідовному формуванні власником активу даних планованої транзакції.
Термін «проект заявки ...» використаний для формалізованого відображення
намірів власника на передачу активу.
На Вхід процесу надходять когнітивні дані i-власника: передається k-актив,
при наявності у власника декількох активів K; розмір переданого активу і комісії,
яка може бути сплачена за виконання транзакції, дані j-набувача активу. Також
необхідні системні дані сховища даних облікових записів і поточний час.
Декомпозиція процесу А21 приведена на рис. 4.
 На діаграмі відображені такі функції.
 «Вибрати актив», А211 при роботі БЧ-системи з декількома активу;
 «Визначити розмір активу і комісії», А212, якщо передбачено оплатне
виконання транзакції;
 «Визначити набувача активу» (обліковий запис), А213; • «Зібрати проект
заявки» на транзакцію », А214.
Вихід процесу А21 (А214) - проект заявки на транзакцію, яка містить такі
реквізити: ідентифікатор облікового запису, що передає право володіння k-
активом; ідентифікатор облікового запису, що приймає право володіння k-
активом; кількість переданого активу; час, виконання транзакції; комісія,
пропонована БЧ-системі («Майнеру») за проведення транзакції.

Рис. 4. Декомпозиція процесу «Сформувати проект заявки на транзакцію», А21

Будемо вважати, що вузол формує проект заявки на транзакцію. Для
актуалізації процесу А21 необхідні Управління - санкція процесу А13 і Механізм:
ОП вузла. Процес «Актуалізувати заявку на транзакцію», А22 є комплексним і
включає в себе предметні і технологічні процедури (рис. 5.).
 Рис. 5. Декомпозиція процесу «Актуалізувати заявку на транзакцію», А22
Семантика процесу А22 полягає в верифікації і валідації сформованого
проекту заявки на транзакцію. Під семантичної коректністю будемо розуміти
відповідність даних транзакції правила предметної області, наприклад:
 кількість заявляється власником для передачі активу не повинна
перевищувати кількість цього активу, що знаходиться у володінні, або
граничного значення для однієї транзакції;
 кількість транзакцій власника активу не повинна перевищувати певного
значення в одиницю часу;
 загальна кількість активу, переданого за певний інтервал часу, не повинно
перевищувати встановленого значення;
 час володіння активом не повинно бути менше деякого значення і ін.
Формальна коректність - коректний формат опису транзакції -
встановлюється правила БЧ-системи.
Валідація є результатом застосування електронного підпису (ЕП), що
гарантує справжність, неможливість відмови від авторства транзакції, незмінність
підписаних даних (цілісність).
Входами процесу А22 (А221) є проект заявки на транзакцію і поточні дані
k-активу. Відзначимо, що термін поточні дані не є синонімом терміну баланс,
оскільки БЧ реалізує транзакційний облік даних (не веде баланс) активу. Тому на
вхід А22 БЧ-система видає БЧ - хронологію транзакцій k-активу, дані яких
використовуються в семантичної перевірці.
Перевірка проекту заявки на транзакцію включає функції «Перевірити
семантичну коректність», А221 і «Перевірити формальну коректність», А222
<проекту заявки на транзакцію>.
Виходами функцій верифікації є верифікований V-проект заявки на
транзакцію і санкція на підписання проекту ЕП власника активу (Управління на
А222).
Наведені вище Правила предметної області можна розглядати як
Управління функцією А221, а Правила БЧ-системи в частині вимог до формату
транзакції - як Управління функцією А222.
Процес А22 включає також функцію «Підписати проект заявки ЕП», А223,
яка гарантує волевиявлення власника облікового запису на передачу активу інших
облікових записів і виключає несанкціонований доступ (додатково до А1) до
активу в частині розпорядження.
Електронний підпис є хеш-значення (хеш) даних проекту заявки на
транзакцію (Вхід А223), зашифрованих закритим ключем, асоційованим з
обліковим записом власника активу.
Підписання V-проекту заявки на транзакцію ЕП, А223, в свою чергу,
включає виконання таких функцій (окрема діаграма не наводиться).
 1. «Хешувати» (створити хеш) дані проекту заявки на транзакцію, А2231. Це
гарантує незмінність даних.
2. «Шифрувати» хеш проекту заявки на транзакцію закритим ключем
власника активу (створити ЕП), А2232.
3. «Включити ЕП в проект» заявки на транзакцію, А2233.
Вихід функції А223 - проект заявки на транзакцію з ЕП.
Управління А233 - вихід (санкція) функції перевірки коректності проекту
заявки на транзакцію А232 . Механізм А223: ОП вузла.
Завершує підготовку заявки на транзакцію функція «Передати проект
заявки в БЧ-систему», А224. При надходженні Команди власника активу
(Управління А224) Заявка на транзакцію надходить в БЧ-систему на адреси всіх
вузлів мережі (мемпул непідтверджених заявок). У спеціальній літературі ця
сутність іноді називається «непідтверджена транзакція». Підтвердження
транзакції відбувається після включення заявки в БЧ (А2, А3).
З цього моменту заявка на транзакцію підлягає складної багаторівневої і
багатофункціональної обробки системним процесом, призначеним для включення
непідтверджених транзакцій в реєстр виконаних транзакцій (в предметних
термінах процес «Провести системну обробку волевиявлення», А3). З
технологічної точки зору цей процес полягає в модифікації БЧ, що зберігає дані
транзакцій. Модифікація полягає в створенні нового блоку-кандидата даних, його
верифікації і включенні в існуючу структуру даних (ланцюжок блоків). У БЧ-
системі всі вузли в будь-який момент часу знаходяться в одному з режимів:
обробка даних заявок на транзакцію і створення нового блоку-кандидата або
верифікація коректності нового блоку-кандидата.
В функціональній моделі це означає декомпозицію А3 і виконання БЧ-
системою, відповідно, процесів «Створити блок-кандидат на включення в БЧ»,
А31 і «Верифікувати блок-кандидат», А32. Розглянемо алгоритм і функціонал БЧ-
системи в цих режимах.
Мемпул заявок на транзакції надходить на Вхід процесу А31. Виходом А31
є поширена мережева версія блоку-кандидата на включення в структуру БЧ.
Управління А31 виконується щодо запропонованих нижче системним
Правил (алгоритму) створення блоків. Механізм А31: в процесі спочатку беруть
участь всі М-вузли БЧ системи (функції А311-А313), а потім вузол, першим
вирішив складну хеш-завдання, наприклад, для заявки на транзакцію (функції
А314-А315).
Процес А31 складний, оскільки в його рамках вирішується не тільки власне
завдання модифікації структури даних БЧ, а й завдання підтримки цілісності
хронології даних транзакцій при забезпеченні відкритості БЧ-системи. Процес
А31 включає функції, представлені на рис. 6.
Рис. 6. Декомпозиція процесу «Створити блок-кандидат на включення в БЧ», А31
Функція «Вибрати заявку з мемпулу», А311 виробляє вибір заявки для
подальшої обробки з безлічі заявок, які одночасно знаходяться в мережі. Нехай це
буде певна заявка на транзакцію (Вихід А311). Управління А311 і Механізм А311
показані на рис. 6. Сутність функції «Створити попередній заголовок блоку»,
А312 зручно розглядати на її декомпозиції (Рис. 7).

Рис. 7. Декомпозиція процесу «Створити попередній заголовок блока», А312

Функція «Створити корінь дерева Меркле», A3121 полягає в хешування
даних заявки та виконується всіма вузлами. Вихід: хеш, де відповідно, хеші даних
заявок на транзакцію і будь-який попередньої їй, наприклад, заявки з мемпулу від
вузла.
Функція «Створити хеш-посилання на заголовок попередньому блоку»,
A3122. Вихід: хеш та блок.
Функції A3121-A3122 створюють основу структури даних БЧ -
впорядковану ланцюжок заголовків блоків і дерев Меркле, що містять дані
транзакцій. Після хешування результатів A3121-A3122 процес додавання нового
блоку в БЧ (A31) міг би бути закінчений.
При цьому архітектурні та технологічні (хешування) рішення дозволяють
виявляти зміни: даних транзакції, посилання на дерево Меркле (Рис. 8.), кореня
дерева Меркле, посилання на заголовок блоку, а також заміну транзакції. Ці зміни
неможливі без значних витрат, так як припускають лише додавання хеш-
посилання, що вказує на заголовок нового блоку в ланцюжку і оголошення цього
посилання як нової голови ланцюжка. Але властивість відкритості БЧ-системи
(P2P-системи) актуалізує загрозу зміни хронології даних транзакцій. Тому
необхідно забезпечити її цілісність при збереженні відкритості системи.

Рис. 8. Алгоритм забезпечення цілісності інформації методом двійкового дерева

Меркле
Для вирішення цього завдання використана ідея спонукання інтересантом
до відмови від будь-яких дій, що вносять зміни в БЧ. Це досягається
цілеспрямованим створенням значних організаційно-технологічні труднощі
внесення змін в структуру даних, подолання яких робить зміни економічно
недоцільними. Практична реалізація ідеї забезпечується виконанням наступних
вимог до БЧ-системі.
1. Виявлення будь-яких змін хронології даних транзакцій (див. Вище).
2. Створення ускладненого алгоритму внесення змін до хронологію
транзакцій, який передбачає редагування та примусову перезапис значної
частини усіх дій, починаючи з місця внесення зміни.
3. Рішення складних хеш-завдань, різних для кожного заголовка блоку.
Виконання цих вимог веде до необхідності наявності значних
обчислювальних потужностей для внесення змін в хронологію транзакцій.
Конкретна реалізація викладених підходів до забезпечення цілісності структури
даних БЧ здійснюється виконанням таких функцій.
1. «Встановити необхідний рівень складності», А3123. Рівень складності
рішення хеш-завдання, що визначає час для її вирішення - системно
встановлюється параметр, необхідний для подальшого виконання функції
А313 (рис. 6.).
2. «Встановити поточний час» створення блоку, А3124 (рис. 7.).
3. «Вирішити хеш-завдання для попереднього блоку», А313(рис. 6.).
Функція А313 має два Виходи:
1. Знайдене рішення хеш-завдання (nonce);
2. Команда Зміна режиму 1/2, яка надходить в БЧ-систему. Ця команда
зупиняє функції А313 і актуалізує функції А321 (рис. 9) інших
вузлів.
4. Завершити створення блоку-кандидата», додавши одноразовий випадковий
код (nonce) до попереднього заголовку, А314.
Реалізація даного підходу включає в заголовок кожного блоку БЧ наступні
дані (інформаційна модель блоку-кандидата):
 корінь дерева Меркле, що містить дані транзакції;
 хеш-посилання на заголовок попереднього блоку;
 рівень складності хеш-завдання;
 час початку рішення хеш-завдання;
 одноразовий випадковий код (nonce), вирішальний хеш-завдання.
Функція «Поширити блок-кандидат в мережі», А315. У БЧ (P2P) -системі
кожен вузол підтримує власну версію незмінного БЧ. Тому новостворений вузлом
блок-кандидат повинен бути децентралізовано переданий іншим вузлам.
Управління А315. Передача повідомлень в P2P-системі має Особливості, що
утрудняють їх доставку адресатам. Ці труднощі усуваються спеціальним
алгоритмом і функціоналом (в статті не розглядаються).
Механізм А315: транспортної основою БЧ-системи є Інтернет.
Процес «Верифікувати блок-кандидат», А32 необхідний, оскільки в БЧ-систему
можливе надходження некоректних блоків-кандидатів. Входом А32 є мережева
версія блоку-кандидата. Виходи А32 (А321, на рис. 9.):
 новий блок в БЧ (модернізований БЧ) з включеним новим блоком в разі
верифікації блоку-кандидата;
 команда блоку А313 (Рис. 9.) «продовжити обробку заявок на транзакції»
(продовжити формування нових блоків-кандидатів), зупинену s-вузлом при
знаходженні nonce для транзакції в іншому випадку.
Управління A32 розглядається нижче. Механізм: процес A32 виконується
всіма вузлами БЧ-системи.
 Декомпозиція А32 (рис. 9). Блок-кандидат проходить процедуру
«Перевірити коректність блоку-кандидата», А321, яка визначається коректністю:
даних транзакцій (А3211); заголовків блоків (А3212); рішення хеш-завдання
(nonce), А3213.
Управління. Правила перевірки даних транзакцій містять умови формальної
коректності, семантичної (смислової) коректності та авторизації (див. вище).
Функція А321 актуалізується командою «Зміна режиму 1/2», що надходить з
виходу функції А313 в момент знаходження nonce певним вузлом.
Функція А321 має три виходи. Вихід 1. У разі визнання блоку-кандидата
коректним, актуалізуються функції БЧ-системи: «Додати новий блок в свою
копію БЧ», А322; «Видалити заявку на транзакцію», А323; «Винагородити
вузол», який створив новий блок, А324.

Рис. 9. Декомпозиція процесу «Верифікувати блок-кандидат», А32

Функція А322 включає верифікований блок в копію БЧ. Функція А323
видаляє заявку на транзакцію з мемпулів всіх вузлів БЧ-системи (безлічі заявок на
транзакцію). Функція А324 призначена для виявлення, компенсації витрат
(винагорода) і стимулювання (конкуренція) найбільш ефективних вузлів, що
створюють і перевіряють блоки. Блок А324, не має явного Входу, оскільки
моделює режим генерації БЧ-системою (Механізм) одиниці винагороди (Вихід
вузла).
Вихід 2 А321. У разі некоректності блоку-кандидата БЧ-система також по
команді «Продовжити обробку заявок на транзакції» з Виходу 3 відновлює
зупинений вузлом режим формування блоків-кандидатів (А313), і вузли можуть
завершити цей етап додаванням свого блоку. Дані транзакції з неверифікованого
блоку повертаються в мемпул для повторної обробки.
 Актуалізація (Управління) функцій А322-А325 виробляється визнанням
блоку коректним / некоректним (команди «виконати 1» / «виконати 2»).

Висновок: під час виконання даної лабораторної роботи був розроблений

системний аналіз об’єкта проектування, сформулювалась мета функціонування
системи.