ЗМІСТ

Перелік умовних позначень, символів, одиниць, скорочень і термінів   6

Вступ.. 7

1. Проектно-конструкторський розділ.. 8

1.1 Загальносистемні рішення. 8

1.1.1 Загальні положення. 8

1.1.2 Опис процесу діяльності 11

1.1.3 Схема функціональної структури. 18

1.1.4 Опис функцій, що автоматизуються. 24

1.2 Огляд наявних аналогів. 26

1.3 Постановка задачі 31

1.3.1 Призначення розробки. 31

1.3.2 Цілі та задачі розробки. 31

1.3.3 Опис постановки задачі 33

1.4 Рішення з інформаційного забезпечення. 35

1.4.1 Перелік первісних сигналів і даних. 35

1.4.2 Перелік вихідних сигналів (документів) 36

1.4.3 Опис інформаційного забезпечення системи. 37

1.4.4 Опис організації інформаційної бази. 40

1.4.5 Опис масивів інформації 42

1.5 Рішення з технічного забезпечення. 44

1.5.1 Загальні положення. 44

1.5.2 Структура комплексу технічних засобів: 44

1.5.3 Засоби обчислювальної техніки. 44

1.5.4 Апаратура передачі даних. 46

1.6 Рішення з математичного забезпечення. 49

1.6.1 Постановка задачі 49

1.6.2 Опис алгоритму вирішення. 49

1.7 Опис програмного забезпечення. 49

1.7.1 Засоби розробки. 49

1.7.2 Архітектура програмного забезпечення. 53

1.7.3 Специфікація функцій. 64

1.7.4 Опис звітів. 66

Висновки по розділу. 66

2. Технологічний розділ.. 67

2.1 Опис організаційної структури. 67

2.2 Керівництво користувача. 67

2.3 Опис технологічного процесу обробки даних. 72

2.4 Висновки по розділу. 73

3. ОРГАНІЗАЦІЙНО-ЕКОНОМІЧНИЙ РОЗДІЛ.. 74

4. РОЗДІЛ ОХОРОНИ ПРАЦІ. 76

Висновки.. 77

ПЕРЕЛІК ПОСИЛАНЬ.. 78

ДОДАТОК А  Тексти програмного коду.. 80

Перелік умовних позначень, символів, одиниць, скорочень і термінів

Здесь могут располагаться описание основных терминов, расшифровка аббревиатур и т.д.

Вступ

Описать актуальность будущей разработки: обосновать проблему, выделить нерешённые части. Указать производителей (людей), занимающихся решением проблем в данной области.

Определить мировые тенденции в решении проблемы.

Определить связь данной разработки с другими (при наличии). 

1 Проектно-конструкторський розділ

1.1 Загальносистемні рішення

1.1.1 Загальні положення

У розділі «Загальні положення» наводять:

– найменування проектованої АС і найменування документів, їхні номери і дату затвердження, на підставі яких ведуть проектування АС;

– перелік організацій, що беруть участь у розробці системи, терміни виконання стадій;

– мету, призначення і галузі використання АС;

– підтвердження відповідності проектних рішень діючим нормам i правилам техніки безпеки, пожежно - та вибухо - безпеки і т. ін. ;

– відомості щодо використаних при проектуванні нормативно-технічних документів;

– відомості про НДР, передовий досвід, винаходи, що використовувалися при розробці проекту;

– черговість створення системи і обсяг кожної черги. 

Другими словами, надо описать общие сведения, к примеру:

– конкурирующие программные продукты (обязательно со ссылкой на источники!);

– законодательство, регламентирующее законы/нормы для выполнения;

– место разработки в рамках системы.

В данном разделе могут располагаться диаграммы, таблицы, рисунки общего характера.

К примеру: 

На даний момент вигляд Інтернет-магазинів з продажу комп’ютерної техніки України має наступний вигляд (табл. 1.1, 1.2):

Таблиця 1.1

Інтернет - магазини з продажу комп’ютерів України

Таблиця 1.2

Інтернет - магазини з продажу комп’ютерів за кордоном

ИЛИ

На даний момент в столиці функціонує 118 готелів різної форми власності. З них 23 об’єкти відносяться до категорії «великих готелів», 60 вважаються «малими готелями», інші – гуртожитки  (хостели). Загальний номерний фонд Києва оцінюється у 8,7 тисяч номерів, загальною місткістю 15,6 тисяч місць. Таким чином готелі столиці здатні забезпечити проживання близько 1 млн. чоловік на рік (рис.1.1).

Рисунок 1.1 – Структура готельного фонду

Головну роль у виборі туристом готелю відіграє класифікація, яка характеризує якість надаваних послуг. У світі діє близько 30 типів систем класифікації готелів. В Україні за основу прийнята французька система зірок.

Міжнародними сертифікатами на сьогоднішній день володіють 55 київських готелів.

– п’ять зірок мають 3 готелі («Премьер Палас», «Опера», «Hayat»);

– чотири зірки мають 8 готелів («Національний» , «Президент-готель», «Київский», «Київ», «Дніпро», «Подол-плаза», «Ривьєра», «Redisson SAS»);

– три зірки мають 17 готелів («Либідь», «Турист», «Славутич», «Братислава», «Салют», «Русь», «Україна», «Пролїсок», «Кооператор», «Експрес», «Дружба», «Хрещатик», «Спорт», «Домус готель», «Джинтама», «Адрія», «Ардена»);

– дві зірки мають 20 готелів («Дніпровський», «Госфельдслужба», «Верховина» та інші);

– одна зірка – 7 готелів;

– не сертифіковані – 65 готелів. 

ИЛИ 

В 2005 році загальний оборот платіжної системи CyberPlat ® досяг суми 1 мільярд 120 мільйонів доларів США. З них 97% припадають на оборот по прийому платежів від абонентів операторів мобільного зв'язку, 1% - від абонентів супутникового і кабельного телебачення. Решта 2% - платежі за фіксований зв'язок, комунальні послуги та доступ в Інтернет. З такими високими показниками "Кіберплат" (CyberPlat ®), безумовно, є найбільшою платіжною системою Росії. Загальна кількість точок прийому платежів системи "Кіберплат" (CyberPlat ®) збільшилася в першому півріччі 2006 року з 15000 до 21000.Настільки стійкий і динамічний ріст бізнесу став можливий завдяки підключенню до CyberPlat ® нових торгових мереж, дилерських компаній, мереж електронних терміналів самообслуговування, а також відділень і філій різних банків, насамперед у регіонах.

Інший приклад динамічного розвитку ринку є компанія ОСМП (Об’єднана Система Мобільних Платежів). Динаміку росту могла поглянути на рис. 1.2. 

Рисунок 1.2 –  Динаміка розвитку ОСМП

1.1.2 Опис процесу діяльності

Здесь может описываться следующее:

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

– то как будет происходить автоматизация (в случаях, если вручную ранее эта задача не решалась никак);

– то, как происходит в общем случае подобная деятельность.

В разделе могут приводиться диаграммы состояний, активности и последовательности – для описания бизнес процессов.

Бажано крім використати як UML так і IDEF0(або BPMN 2.0) у якості моделювання предметної області. 

Примеры. 

Розглянемо приклад, у якому показано які дії має виконати користувач для розсилки резюме роботодавцям,  за допомогою UML діаграми діяльності (рисунок 1.3): 

Рисунок 1.3 – Схема структурна діяльності 

ИЛИ 

Розглянемо детальніше, які дії виконують учасники процесу, за допомогою UML діаграми діяльності (рисунок 1.4): 

Рисунок 1.4 – Схема структурна діяльності

Приклад 2.

У загальному випадку, Help Desk складається з наступних логічних компонентів (рисунок 1.5):

- підсистема реєстрації заявок про інциденти;

- база даних заявок;

- підсистема відстеження статусу заявки та оповіщення;

- база знань;

- підсистема адміністрування;

- підсистема звітності. 

Рисунок 1.5 – Загальна структура системи Help Desk

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

Основними поняттям у системах класу Help Desk є запит та інцидент. Запит [Ошибка! Источник ссылки не найден.] – звертання до служби підтримки підприємства. Інцидент [Ошибка! Источник ссылки не найден.] – різновид запиту, який визначає будь-які події, що не є частиною нормальної роботи послуги, яка веде (може призвести) до зупинення чи зменшення якості цієї послуги.

Схема структурна станів запиту в системі Help Desk приведена на рисунку 1.2. 

Рисунок 1.6 – Схема структурна станів запиту

Після виникнення запиту відбувається його реєстрація у Системі співробітником банку. Далі запит класифікується за типом:

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

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

- запити на зміну стану системи – наприклад установку нового обладнання та програмного забезпечення.

Найвищий пріоритет обслуговування у системі мають запити на обробку інцидентів, найменший – запити на зміну станів системи.

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

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

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

Найчастіше системи Help Desk організують за багаторівневим принципом [Ошибка! Источник ссылки не найден.]:

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

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

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

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

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

На рисунку 1.3 приведена структурна схема процесу обробки запиту у системі Help Desk за допомогою нотації BPMN 2.0 [Ошибка! Источник ссылки не найден.].

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

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

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

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

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

Якщо запит не може бути вирішений, то керівник фіксує опис запиту та визначає можливі строки його обробки.

1.1.3 Схема функціональної структури

Розділ  «Схема функціональної структури» містить:

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

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

– деталізовані схеми частин функціональної структури (при необхідності).

Этот раздел обязательно описывается в дипломах, тема которых звучит как «Система … », «АРМ ..»,. Здесь должны быть отображены:

– основные функциональные блоки проектируемой системы и описаны связи между блоками;

– связи системы с внешней средой.

В данном разделе должны быть размещены рисунки, отображающие функциональную структуру. Это могут быть диаграммы компонентов UML, SADT-диаграммы или обычные функциональные схемы.

Примеры:

Створення підсистеми формування і ведення реєстру паспортів підконтрольних об’єктів обумовлене необхідністю отримання повної та всебічної інформації про кожну організацію чи установу, яка може бути об’єктом проведення ревізії чи перевірки органами ДКРС.  Для отримання інформації необхідна взаємодія нової підсистеми із вже існуючими підсистемами та підсистемами ІАС ДКРС, що зображено на рисунку 1.5. 

Рисунок 1.8  – Структура взаємодії підсистеми  «Підконтрольні об’єкти» з існуючими підсистемами та підсистемами ІАС ДКРС

ИЛИ

Всю систему умовно можна поділити на два функціональні рівні: графічний та алгоритмічний. Модулі операційного рівня взаємодіють із зовнішньою СУБД, використовуючи прикладний мережевий рівень для доступу. Взаємодія між означеними елементами системи відбувається виключно на рівні інтерфейсів (табл.1.2).

Таблиця 1.3

Опис підсистем та елементів системи

Продовження таблиці 1.3

Продовження таблиці 1.3

Продовження таблиці 1.3

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

Рисунок 1.9 – Функціональна схема системи електронної бібліотеки

1.1.4 Опис функцій, що автоматизуються

В данном разделе описывают функции, которые будут выполняться. Описание производится в виде диаграммы вариантов использования. 

Для проектування діаграми використання спочатку необхідно визначити дійових осіб  (акторів), а потім визначити, які дії у системі може виконувати кожен з акторів. На рисунку 1.7 приведені актори системи: 

Рисунок 1.10 – Актори системи

Нижче наведений опис кожного з акторів.

– Адміністратор. Співробітник туристичної фірми, який має змогу вносити зміни до бази даних із інформацією про туристичні послуги, а також є ключовою особою при формуванні договору між клієнтом та туристичною фірмою.

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

– Користувач. Незареєстрований користувач сайту (гість). Має права лише на перегляд інформації про туристичні послуги.

Тепер визначимо дії, які можуть виконувати актори системи (рисунок 1.8): 

Рисунок 1.11 – Схема структурна варіантів використання

Розпишемо детальніше деякі з варіантів використань:

– перегляд турів:

а) переглянути можливі тури – ознайомлення з турами, представленими на сайті;

б) перегляд новин – ознайомлення з "гарячими" пропозиціями;

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

– бронювання туру:

а) реєстрація – заповнення анкети на сайті, для збереження своїх даних в системі;

б) оформлення заявки – заповнення спеціальної форму на замовлення туру;

в) друк контракту – друк контракту з сайту згідно із підтвердженим замовленням;

– перевірка системи:

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

б) оновлення системи;

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

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

1.2 Огляд наявних аналогів

Тут наводиться опис наявних рішень або огляд ринку програмних продуктів

Приклад 1

В ході пошуку схожих вирішень було виявлено деякі підходи зі схожою функціональністю:

– Cisco IOS router software [11];

– Cisco WAN Optimization and Application Acceleration [12];

– Network Load Balancing Services (NLBS) [10];

– динамічна маршрутизація на основі принципів функціонування нейронних мереж [13];

– алгоритм альтернативних маршрутів [9].

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

В таблиці 1.1 наведено короткий опис характерних особливостей існуючих підходів. 

Таблиця 1.1

Характеристика існуючих підходів

Продовження таблиці 1.1

Приклад 2

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

- система EMLAB [3];

- система Decibel Planner [4].

Аналіз функціональності існуючих програмних продуктів

Основними функціями системи Decibel Planner є:

- визначення загального покриття за найкращим значенням чи за другим найкращим значенням;

- ідентифікація передавача, що забезпечує найкраще покриття і найкраще покриття за другим найкращим критерієм вище порогу чутливості приймача;

- визначення числа передавачів, що забезпечують покриття в деякому положенні;

- визначення областей інтерференційних перешкод від суміжного і сусіднього каналів вище визначеного користувачем інтерференційного каналу;

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

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

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

- розрахунок складного складового покриття для різних фаз при налагодженні мережі;

- розрахунок покриття і інтерференційний аналіз в одно частотних мережах з затриманою ретрансляцією.

Основними функціями системи EMLAB є:

- загальне радіо покриття кількох систем антен (до 100);

- зона найкращого сервісу (оцінка зон, що найкраще покриваються кожною передаючою системою в групі);

- розрахунок інтерференції;

- розрахунок зони покриття одно частотних мереж з можливістю оптимізації аналізу за окремими параметрами (синхронізація, тип сервісу, модуляція, тощо).

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

1.3 Постановка задачі

1.3.1 Призначення розробки

Тут описується призначення розробки

1.3.2 Цілі та задачі розробки

В даному підрозділі описується саме цілі (мета) розробки та задачі, які необхідно вирішити для їх (її) реалізації.

Мета (цілі) розробки – це результат, для досягнення якого, власне, і проводиться розробка. Визначити мету (цілі) розробки, значить відповісти на питання «Навіщо Ви її виконуєте?».

Тут описуємо те, що отримаємо у результаті виконання робіт, які зміни відбудуться в існуючій ситуації. Ціль завжди знаходиться за межами діяльності. Все, що ми виконуємо - це вирішення певних задач, а досягнений результат і є ціль. При цьому повинна існувати можливість виміру цілі та оцінки рівня іі досягнення. Зазвичай починається словами «покращення…»,  «підвищення (зниження…)…», «обумовлення…», «виявлення…». 

Приклад 1

1.3.1 Призначення розробки

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

1.3.2 Цілі та задачі розробки

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

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

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

– знаходження маршрутів, які заважають прокладенню поточного шляху для маршруту;

– знаходження кабеля з найбільшою відносною завантаженістю в мережі;

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

Приклад 2

1.3.1 Призначення розробки

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

1.3.2 Цілі та задачі розробки

Основними цілями розробки комплексу задач є:

- підвищення прибутковості мережі мобільного зв’язку за рахунок більш ефективного розміщення базових станцій зв’язку;

- підвищення якості обслуговування клієнтів.

Для досягнення поставлених цілей мають бути вирішені такі задачі:

– дискретизація карти;

– визначення потенціальних місць розміщення базових станцій;

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

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

– облік встановлених (діючих) базових станцій зв’язку. 

Приклад 3

1.3.1 Призначення розробки

Призначенням комплексу задач є визначення плану перевезення продукції до споживачів, при якому транспортні витрати є мінімальними; формування відповідної звітності.

1.3.2 Цілі та задачі розробки

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

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

– облік філій підприємства, які постачають продукцію;

– облік споживачів підприємства;

– ведення географічних пунктів маршрутів перевезення (ведення мапи);

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

– облік замовлень, зроблених споживачами;

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

– розрахунок вартості перевезення продукції від одного пункту до іншого;

– облік транспорту підприємства;

– підрахунок збитків та прибутків підприємства та його філій, пов’язаних із транспортуванням продукції.

1.3.3 Опис постановки задачі

При описании постановки задачи обязательно надо указать цель создания системы, и задачи, которые должны решаться для достижения поставленной цели. 

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

Метою створення автоматизованої системи підтримки діяльності готелю є:

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

- надання можливості адміністратору додаткових послуг вносити корективи у меню ресторану та перелік додаткових послуг;

- надання можливості адміністративному персоналу переглядати звіти щодо прибутковості та завантаженості готелю;

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

Для цього мають бути вирішені такі задачі:

– облік готельного фонду;

– облік додаткових послуг;

– облік клієнтів готелю.

При цьому мають бути реалізовані такі функції:

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

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

– обрахування вартості перебування в готелі, відповідно до додаткових умов клієнта;

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

1.4 Рішення з інформаційного забезпечення

1.4.1 Перелік первісних сигналів і даних

У розділі  «Перелік первісних сигналів» вказують:

- для аналогового сигналу — найменування величини, що вимірюється, одиниці виміру, діапазон зміни, вимоги точності та періодичності виміру, тип сигналу;

- для дискретного сигналу — найменування, розрядність та періодичність, тип сигналу;

для сигналу типу «так-ні» — джерело формування та смислове значення сигналу.

У розділі  «Перелік первісних даних» вказують:

- найменування, кодове позначення, значущість реквізитів первісних даних;

- найменування і кодові позначення документів або повідомлень, що містять ці дані. 

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

Наприклад:

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

Дані по проектам

– номер – номер проекту у розрізі типу;

– назва – назва проекту;

– клієнт – клієнт, з яким укладається проект;

– стадія – стадія, на якій перебуває проект;

– стан – стан роботи менеджера з проектом;

– тип – тип проекту;

– постачальник – контрагент, який виконує поставку послуг;

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

– дата закінчення – дата, офіційного формування договору.

Дані по договорам

– номер – номер договору по регламенту;

– назва – назва договору;

– клієнт – клієнт, з яким укладається договір;

– відповідальний – менеджер, що працює з клієнтом;

– тип – тип договору;

– стан – стан договору;

– дата початку – дата, підписання договору з однієї з сторін;

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

– реквізити – включають в себе суму, частоту оплати, валюту;

– проект – посилання на проект.

Ещё пример:

Первісними даними для АС “Кадри” є:

– дані нормативно-довідникової інформації, що імпортуються з інших систем;

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

– дані трудових книжок співробітників;

– дані паспортів.

Опис вхідних даних приведений у таблиці 1.4. 

Таблиця 1.4

Опис первісних даних

1.4.2 Перелік вихідних сигналів (документів)

Документ складається з таких розділів:

- перелік вихідних сигналів;

- перелік вихідних документів.

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

Розділ «Перелік вихідних документів» містить перелік вихідних документів із зазначенням їхніх найменувань, кодових позначень, переліку і значущості реквізитів, користувачів інформації.

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

Наприклад: 

Вихідними документами є звіти, які генеруються системою для відображення відомостей про роботу платіжних терміналів. Нижче наведені приклади макетів звітів (табл. 1.5 – 1.6)

Таблиця 1.5

Звіт по інкасаціям за період

Таблиця 1.6

Обороти по терміналам:

Ще приклад:

Вихідними документами для АС «Кадри» є наступні:

– трудовий договір;

– звіт по співробітниках;

– звіти для Державної податкової адміністрації.

У таблиці 1.7 наведений опис вихідних документів:

Таблиця 1.7

Опис вихідних документів

1.4.3 Опис інформаційного забезпечення системи

У документ входять розділи:

- склад інформаційного забезпечення;

- організація інформаційного забезпечення;

У розділі  «Склад інформаційного забезпечення» вказують найменування і призначення всіх баз даних і наборів даних.

У розділі  «Організація інформаційного забезпечення» наводять:

- принципи організації інформаційного забезпечення системи;

- обґрунтування вибору носіїв даних і принципи розподілу інформації за типами носіїв.

Розділ "Склад інформаційного забезпечення" повинен бути обов'язково!

Приклад:

У наступній таблиці (таблиця 1.8) приведений перелік таблиць, у які має бути завантажена інформація.

Таблиця 1.8

Перелік таблиць

Ещё пример 

База даних складається з 14 таблиць пов’язаних між собою. Далі приводиться перелік таблиць (табл. 1.9).

Таблиця 1.9

Перелік таблиць

Продовження таблиці 1.9

1.4.4 Опис організації інформаційної бази

Містить опис логічної і фізичної структур бази даних. Документ складається з двох частин:

- опис внутрішньомашинної інформаційної бази;

- опис позамашинної інформаційної бази.

Частини документа містять наступні розділи:

- логічна структура;

- фізична структура (для внутрішньомашинної інформаційної бази);

- організація ведення інформаційної бази.

У розділі  «Логічна структура» наводять опис складу даних, їхніх форматів і взаємозв'язків між даними.

Розділ  «Фізична структура» містить опис вибраного варіанта розташування даних на конкретних машинних носіях.

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

Таким чином розділ повинен обов'язково описати структури даних (у вигляді діаграм ERD, PDM або XML). При необхідності може бути описана структура розміщення бази даних на конкретних фізичних вузлах.

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

Приклад фізичної структури БД:

У таблицях 1.10 – 1.11 наведені структура таблиць.

Таблиця 1.10

Перелік стовпців таблиці WH_D_ORG

Таблиця 1.11

Перелік стовпців таблиці A_WH_D_ORG__D_ORG

Структурна схема БД наведена у додатку В, лист <тут вказується номер листа>.

Інший приклад структури таблиць: 

Далі розглянемо таблиці бази даних у табличному форматі (таблиці 1.12 – 1.13).

Таблиця 1.12

Таблиця клієнтів

Таблиця 1.13

Таблиця контрактів

1.4.5 Опис масивів інформації

Документ містить:

- найменування масиву;

- позначку масиву;

- найменування носіїв інформації;

- перелік реквізитів в порядку їх слідування у записах масиву із зазначенням по кожному реквізиту: позначення, довжини в знаках і діапазону зміни (при необхідності), логічних і семантичних зв'язків з іншими реквізитами даного запису й іншими записами масиву;

- оцінку обсягу масиву;

- інші характеристики масиву (при необхідності).

У даному розділі обов'язково необхідно привести оцінку обсягів масивів інформації.

Gриклад:

Орієнтовний обсяг даних масивів інформації представлений у таблиці 1.14

Таблиця 1.14

Масиви інформації

1.5 Рішення з технічного забезпечення

Опис комплексу технічних засобів

Опис комплексу технічних засобів повинен відповідати вимогам Технічного завдання та розділу 4.2 ГОСТ РД 50-34.698-90.

Документ містить розділи:

- загальні положення;

- структура комплексу технічних засобів;

- засоби обчислювальної техніки;

- апаратура передачі даних.

Приклад:

1.5.1 Загальні положення

В разделе "Общие положения" приводят исходные данные, использованные при проектировании технического обеспечения АС.

1.5.2 Структура комплексу технічних засобів:

– Телекомунікаційна схема.

– Центральний вузол бази даних           .

– Сервер застосувань центрального вузла.

– Регіональні вузли.

– Клієнтські робочі місце.

– Локальна мережа.

1.5.3 Засоби обчислювальної техніки

Опис центрального вузла бази даних

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

Опис серверу застосувань центрального вузла

Інформаційна система Аграрної біржі є трирівневою: база даних - сервер застосувань - клієнт.

Сховищем даних є об’єктно-реляційна СКБД промислового рівня Oracle.

Середнім рівнем системи є сервер застосувань центрального вузла, що здійснює роботу з даними безпосередньо в базі даних, перевірку прав доступу, зокрема на рівні окремих об'єктів (записів в БД), виконання «важких» операцій, що вимагають великої обчислювальної потужності.

Надається опис переваг архітектри, задачі серверу застосувань, специфікація сервера застосувань центрального вузла

Опис типового регіонального вузла

До регіонального вузла відноситься частина загальної телекомунікаційної схеми від модему регіонального рівня до клієнтського місця. Типовий регіональний вузол представляє собою ланцюг пристроїв (Рис. 1.1 ):

- модем;

- сервер доступу;

- комутатор;

- база даних та сервер застосувань (обидва програмні компоненти на регіональному рівні використовують один фізичний сервер);

- клієнтське місце.

Рис. 1.1 Типовий регіональний вузол

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

Конфігурація серверу на регіональному рівні (сервер БД та сервер застосувань):

1. Корпус: 2U Rackmount, 2 блоки живлення 2x500 W з гарячою заміною

2. Чипсет: Intel E7520

3. Процесор: 2 шт. Intel Xeon 3,0 GHz, 2Mb. 800 MHz

4. Пам'ять: 4 Gb DDR II - 400ECC Registered

5. HDD: 4 шт. HDD SATA 140Gb

6. Контролер: Підтримка SATA Raid 0.1.5; гаряча заміна

7. Мережа: контролер Gigabit Ethernet

8. Відеокарта: ATI Rage XL 8 Mb

9. Оптичний пристрій: CD-ROM

10. Дисковод: FDD 1,44

Опис клієнтського робочого місця

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

Конфігурація клієнтського місця на центральному рівні:…

1.5.4 Апаратура передачі даних

Опис телекомунікаційної схеми.

Основи для функціонування розрахунково-клірингової системи аграрної біржі складають:

1. Центральний обчислювальний вузол, який вміщує централізовану базу корпоративних даних.

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

3. Інфраструктура архівування та тривалого збереження інформації.

4. Автономна система гарантованого електропостачання.

5. Розгалужена комбінована комунікаційна інфраструктура в межах України, орієнтована на постійне з’єднання по виділеним лініям, каналам мережних провайдерів.

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

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

Комунікаційна інфраструктура укомплектована такими технічними засобами на центральному рівні:

- сервером віддаленого доступу в достатній комплектації – як вузлового комунікаційного засобу;

- модемний пул.

На регіональному рівні:

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

- модеми з комутаційним доступом.

Для забезпечення ефективної функціональності РКІС необхідно забезпечити постійне виділене з’єднання між центральному рівнем та всіма комунікаційними центрами регіонального рівня.

Прийнята технологія передбачує використання стеку протоколів TCP/IP.

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

Всі мережеві пристрої, інтегровані на регіональному рівні, повинні підтримувати централізоване керування за допомогою стандартних протоколів SNMP та RMON.

За допомогою вказаних протоколів повинна здійснюватися інтерактивна діагностика всіх сіткових ланок з централізованого пункту.

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

Технічна схема ІС 

Рис. 1.2. Комунікаційна та мережева інфраструктура

Опис локальної мережі

Локальна обчислювальна мережа (ЛОМ) інформаційної системи Аграрної біржі включає в себе комунікації (кабелі зв’язку) та мережне обладнання (комутатори, концентратори, маршрутизотори, модеми тощо).

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

1.6 Рішення з математичного забезпечення

1.6.1 Постановка задачі

1.6.2 Опис алгоритму вирішення

1.7 Опис програмного забезпечення

1.7.1 Засоби розробки

Наводиться обґрунтування вибраних засобів розробки

Приклад 1

При створенні програмного продукту були використанні оболонка програмування на Java [20], як IDE Eclipse Helios [21].

Одне з головних переваг мови Java - її незалежність від платформи, на якій виконуються програми. Таким чином, один і той самий код можна запускати під управлінням операційних систем Windows, Linux, FreeBSD, Solaris, Apple Mac та ін. Це стає дуже важливим, коли програми завантажуються за допомогою глобальної мережі Інтернет і використовуються на різних платформах. Іншим, не менш важливою перевагою мови Java, є велика схожість з мовою програмування C++. Тому тим програмістам, які знайомі з синтаксисом С і С++ буде просто освоїти Java. Крім того, Java - повністю об'єктно-орієнтована мова, навіть більшою мірою, ніж С++. Всі сутності в мові Java є об'єктами, за винятком небагатьох основних типів (primitive types), наприклад чисел. Свого часу об'єктно-орієнтоване програмування (ООП) замінило структурне програмування.

Java Архітектура для XML Binding (JAXB) [15] дозволяє розробникам мапувати (ставити у відповідність) класи )Java у XML файли. JAXB має дві основні властивості: здатність створювати класи Java з XML і навпаки - створювати XML файли з класів Java [16]. JAXB особливо корисна, коли специфікаціґ є складною і часто змінюється. JAXB є частиною платформи Java SE і одним з інтерфейсів API у платформі Java EE, також є частиною Java Web Services Development Pack (JWSDP). JAXB 1.0 був розроблений в рамках Java Community Process як JSR31.

Приклад 2

При створенні програмного продукту були використані такі засоби для програмування на Python як IDE Eclipse [10] з плагіном PyDev [11] а також база даних MySQL.

Python [12] проста у використанні, та водночас повноцінна мова програмування, що надає багато засобів для структурування і підтримки великих програм. Вона краще за С обробляє помилки, і, будучи мовою дуже високого рівня, має вбудовані типи даних високого рівня, такі як гнучкі масиви і словники, ефективна реалізація яких на C потребує значних витрат часу.

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

Python - інтерпретована мова, що дозволяє заощадити значну кількість часу, що зазвичай витрачається на компіляцію. Інтерпретатор можна використовувати інтерактивно, що дозволяє експериментувати з можливостями мови, писати шаблони програм або тестувати функції при розробці “знизу-вверх”. Він також зручний як настільний калькулятор. Python дозволяє писати дуже компактні й зручні для читання програми. Програми, написані мовою Python, звичайно значно коротші еквівалента на C або C++ з декількох причин:

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

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

– немає необхідності в оголошенні змінних;

Python розширювана мова: знання C дозволяє додавати нові функції, що вбудовуються, або модулі для виконання критичних операцій з максимальною швидкістю або написання інтерфейсу до комерційних бібліотек, доступним тільки у двійковій формі. Інтерпретатор мови Python може бути вбудований у програму, написану на C, і використовувати його як розширення або командну мову для цієї програми. Python використовується в даний час десятками тисяч програмістів в усьому світі, і число людей, що використовують його, швидко зростає, подвоюється і потроюється щороку. Python приваблює користувачів з ряду причин. Він використовується для розробки програм і дозволяє провести розробку набагато швидше, ніж традиційні мови типу C, C++ або Java . Ця мова працює однаково добре на Windows, UNIX, Macintosh, і OS/2, може використовуватися, для легкої розробки як малих додатків чи сценаріїв, так і для розгортання великих програм. Python пропонує доступ до могутнього і легкого у використанні комплекту 29 інструментальних засобів графічного інтерфейсу користувача. Традиційні машинні мови типу C і Pascal мають ряд характеристик, наприклад, сувора типізація, базові типи, складні (і звичайно довгі) цикли, і потреба у великих кількостях кодів для виконання відносно малих задач. Java досить новий, але розділяє більшість характеристик, включених у цей перелік. Програмісти, знайомі з традиційними мовами погодяться, що відсутність суворої типізації полегшує роботу з Python.

Відмінностей Python від інших мов доволі багато, перерахуємо основні з них:

– керування пам'яттю - цілком автоматичне — не потрібно хвилюватися щодо розподілу або звільнення пам'яті; немає загрози “небезпечного посилання”; Java - єдина мова, що пропонує таку концепцію.

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

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

Ці та інші особливості Python роблять розгортання додатків надзвичайно швидким. Продуктивність створеного додатку залежить від його особливостей. Звичайно, для чисельного алгоритму, що виконує звичайну арифметику цілого числа в циклі 'for', неважливо, на якій мові він написаний. Але для “середнього” додатка, збільшення продуктивності може бути просто дивовижним. Один недолік Python, у порівнянні з найбільш традиційними мовами, полягає в тому, що це - не цілком компільована мова; замість цього, вона частково транслює програму до внутрішньої форми байт-коду, і цей байт-код виконується інтерпретатором Python. Однак, у перспективі – сучасні комп'ютери мають так багато невикористовуваного обчислювального потенціалу, що для 90% додатків швидкодія зв'язана з вибором мови. Java теж компілюється в байт-код, але в даний час працює повільніше ніж Python у більшості випадків. Крім того, дуже просто об'єднати Python з модулями, написаними на C або C++, які можна використовувати, щоб збільшити швидкість роботи програм в критичних ділянках.

MySQL [13] — вільна система керування реляційними базами даних.

Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.

MySQL — компактний багатопотоковий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.

MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.

MySQL вважається гарним рішенням для малих і середніх застосувань. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатопотоковості, що підвищує продуктивність системи в цілому.

Для некомерційного використання MySQL є безкоштовним. Можливості сервера MySQL:

– простота у встановленні та використанні;

– підтримується необмежена кількість користувачів, що одночасно працюють із БД;

– кількість рядків у таблицях може досягати 50 млн.;

– висока швидкість виконання команд;

наявність простої і ефективної системи безпеки.

1.7.2 Архітектура програмного забезпечення

Доцільна побудова наступних діаграм UML фази уточнення:

Особливості використання діаграми послідовності

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

Особливості використання діаграми класів

Для збереження множини і атрибутів персистентних (тобто таких, які постійно зберігаються) класів в базі даних передбачаються таблиці. Тому логічно очікувати на певну відповідність між множиною персистентних класів та множинами сутностей на ER-діаграмі структури БД, а також на відповідність зв’язків асоціації між класами та між відповідними множинами сутностей на ER-діаграмі.

Особливості використання діаграми компонентів

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

Приклади

1.7.2.1 Діаграма послідовності

Приклад діаграми послідовності для для процесу введення первинного документу (ПД) Дефектна відомість для обліку оприбуткування запчастин і брухту в Технічній службі автотранспортного підприємства (ТС)

На діаграмі задіяні наступні класи:

Рис.8.1. Діаграма послідовності для прецеденту Введення ПД "Дефектна відомість" для ремонту авто в системі управління ресурсами автопідприємства

1.7.2.2 Діаграма класів

Створення діаграми класів для відображення ієрархії успадкування

Як і в лабораторній роботі 4, розглянемо прецедент Введення ПД "Дефектна відомість" для ремонту авто.

• Створимо нову діаграму класів. Для цього зручно відчинити контекстне меню на представленні Logical View:

Рис.8.2. Створення нової діаграми класів 

• Створимо або виведемо на діаграму класів необхідні класи для показу їхнього успадкування. Відобразимо 3 ієрархії успадкування, які стосуються прецеденту:

• Типи первинних документів (ПД).

• Типи рядків  ПД.

• Види матеріальних цінностей (МЦ). 

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

Якщо класу не існує, треба його створити тим же локальним меню, або скористатись меню Tools\Create\Class, або (найзручніший спосіб) обравши клас на панелі діаграми, клікнути на полі діаграми в потрібному місці. В нашому прикладі довелося створити всі класи. 

• Встановимо зв’язки узагальнення (зворотні до успадкування) між класами одної ієрархії. Для цього на панелі діаграми слід обрати стрілку Generalization та протягнути її від дочірнього класу до батьківського:

Рис.8.3. Встановлення зв’язку узагальнення між класами 

• Визначимо і введемо атрибути і функції, які належать до батьківських класів. Видимість усіх цих атрибутів установлюємо Public. 

Рис.8.4. Додавання атрибуту до класу 

Це зручніше зробити за допомогою контекстного меню в полі переліку атрибутів (або, відповідно, операцій) специфікації класу. 

• Оцінимо, чи є батьківські класи абстрактними. Якщо реалізація операцій однакова для різних дочірніх класів і тому міститься в батьківському класі, цей батьківський клас не є абстрактним. В іншому разі він таким є, ставимо відповідну галочку (рис. 8.5), і відтепер назва класу виводиться курсивом.

Рис.8.5. Встановлення властивості класу Абстрактний. 

Інші деталі класів залишаємо для другої діаграми класів, де будуть показані зв’язки класів крім узагальнення.

• В підсумку маємо наступну діаграму, яка відображає зв’язки узагальнення класів:

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

Створення діаграми класів для відображення усіх властивостей та зв’язків класів

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

• Створимо ще одну діаграму класів та виведемо на ній класи, при необхідності створимо нові класи.

• Створимо зв’язки. В цьому прикладі класи типів рядків є класами-асоціаціями, які в свою чергу асоціюються з нащадками класу МЦ. В однонаправленої асоціації (рис.8.6) стрілка вказує на клас, множинність якого 1. Ненаправлена асоціація створюється для зв’язків один до одного та багато до багатьох (за допомогою меню Tools\Create\Association). 

Рис.8.7. Послідовність створення однонаправленої асоціації 

• Вкажемо множинність кожного зв’язку шляхом виклику контекстного меню біля кінця зв’язку і вказавши значення Multiplicity (рис.8.8). Спробуємо пояснити множинність зв’язку на прикладі зв’язку від класу Рядок списання деталі (множинність 0..*) до класу Дефектна відомість (множинність 1). 

Рис.8.8. Вказання множинності одної сторони зв’язку

Після цього діаграма має вигляд (рис.8.9):

Рис.8.9. Діаграма класів зі зв’язками асоціації 

• Для виводу зв’язку залежності відобразимо на діаграмі клас Сервер БД. Клас Дефектна відомість звертається до серверних збережених процедур, зокрема, при проведенні ПД. Тому проводимо зв’язок залежності від ПД до сервера.

• Аналізуючи можливість уключення в діаграму вкладених класів, класу інтерфейсу, зв’язків реалізації та агрегації, доходимо висновку, що вони в моделі відсутні.

• Після встановлення зв’язків для кожного класу по можливості треба визначити в його специфікації:

• Видимість класу;

• Множинність класу;

• Стійкість класу;

• Паралелізм класу;

• Чи є клас абстрактним.

• Остаточно діаграма класів має вигляд: 

Рис.8.10. Остаточний вигляд діаграми класів зі зв’язками асоціації та залежності

Приклад діаграми класів для задачі планування виробництва

На рисунку 4.1 представлена структурна схема класів, які відповідають за виконання таких функцій програми, як встановлення з’єднання з СУБД Oracle, робота з даними, робота з транзакціями, складання та прогнозування плану випуску продукції та формування звітів «План виробництва».

Діаграма містить п’ять класів, а саме:

- «MainForm» - головний клас програми, відповідає за взаємодію програми з базою даних та містить основні функції роботи програми;

- «PasswordForm» - клас, що відповідає за коректне з’єднання з базою даних та запускає головний модуль програм;

- «ParametrPrograming» - клас у якому містяться функції, що виконують складання та прогнозування плану випуску продукції кожного виду;

- «ForecastPrice» - клас функції якого виконують прогнозування ринкових цін;

- «CreateReport» - клас призначенням якого є генерація звітів. 

Рисунок 1.12 – Структурна схема класів

1.7.2.3 Діаграма компонентів

Приклад

Головними компонентами модуля є: головна сторінка програми «Main Frame:Data Master», сторінка редагування класів «Main Frame: Edit Classes», з’єднання з БД «Eclipse Link» та пакет очищення даних «Data Base: Pack data cleaning», що надає усі данні до інтерфейсу модуля.

Для встановлення з’єднання з БД компонент «Eclipse link» має інтерфейс «Connection parametrs», що приймає на вхід параметри з’єднання.

Компонент «Main Frame:Data Master» через інтерфейс «Class structure» приймає на вхід назви класів та елементів класів. Через інтерфейс «Data Master» приймаються параметри майстер даних та через «Data master parameters» передаються до БД.

Компонент «Main Frame: Edit Classes» через інтерфейс «Arrays of class elements» приймає на вхід клас та масив елементів. Через інтерфейс «Edit Classes» приймаються параметри змін у класах. Та через «Edit arrays of class elements» здійснюються зміни до БД. На рисунку 4.5 представлена схема структурна компонентів модуля очистки даних. 

Рисунок 4.5 – Схема структурна компонентів

1.7.2.4 Діаграма розгортання

Приклад

Модуль очистки даних працює у контейнері EJB. Контейнер містить у собі компоненти з’єднання з БД – Eclipse Link, та компонети формування майстер даних «DataMaster», редагування «EditClasses» та очищення даних «DataCleaning». Процес очистки даних виконується на стороні БД за допомогою пакета функції «pack_data_cleaning». Доступ до серверних об’єктів Java машини виконується з клієнтських об’єктів через інтерфейс RMI.

На рисунку 4.6 представлена діаграма розгортання. 

Рисунок 1.6 – Діаграма розгортання

1.7.3 Специфікація функцій

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

Приблизний приклад (таблиця наведена неповна)

Функції класів програмного забезпечення наведені в таблиці 4.9.

Таблиця 4.9

Функції класів програмного забезпечення

1.7.4 Опис звітів

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

За допомогою програми можливий збір статистичних даних для побудови звітів «План виробництва».

Звіти створюються за допомогою відкритого COM-застосування, для роботи з сервером Microsoft Word. Даний додаток дозволяє посилати досить великий набір команд серверу Word і створювати звіти будь-якої складності та деталізації. При написанні коду будемо використовувати .Net збірку взаємодії з програмами Microsoft Office – Microsoft.Office.Interop.Word [12], для роботи нам потрібно лише одна частина даної збірки, а саме Word.Application. Головним в ієрархії об’єктів Word.Application є об’єкт Document. Інформація про об’єкти Document зберігається у вигляді посилань на відкриті документи у властивості Document. Document – це пустий лист, на якому генерується звіт «План виробництва».

Звіт «План виробництва» генерується автоматично при виборі в програмі пункту меню «Згенерувати звіт» і зберігається під назвою «План.doc» в папці Reports, що знаходиться в кореневій папці. Згенерований звіт має вигляд зображений на рисунку 4.6, де показано … 

<Тут має бути зразок згенерованого звіту>

Рисунок 4.6 – Вигляд звіту «План виробництва»

Висновки по розділу

2 Технологічний розділ

2.1 Опис організаційної структури

В підрозділі наводимо структуру організації, де впроваджується ПЗ.

2.2 Керівництво користувача

В підрозділі описуємо та за можливості демонструємо керівництво користувача.

Приклад, який наведено нижче використовуємо як наглядний.

Приклад:

Для запуску програмного застосування можна скористатися двома шляхами:

- з графічного інтерфейсу подвійним кліком лівою кнопкою миші по файлу bachelor.jar;

- з консолі за допомогою команди java -jar bachelor.jar.

Головне вікно застосування містить меню користувача, панель інструментів. Головне вікно застосування показано на рисунку 5.1. 

Рисунок 2.1 – Головне вікно програмного застосуванняДля підключення до БД потрібно вибрати пункт меню База, підпункт Підключення (рисунок 5.2). Там є можливість ввести параметри підключення, як показано на рисунку 5.3. Параметри підключення можна змінювати відповідно до встановленої БД. 

Рисунок 2.2 – Підключення до бази даних

Рисунок 2.3 – Введення параметрів підключення до БД

Далі, після натиснення на кнопку ОК, вводимо необхідні логін та пароль як показано на рисунку 5.4. 

Рисунок 2.4 – Введення логіна та паролю для підключення до БД

Натиснувши на кнопку Оформити замовлення, з’явиться вікно (рисунок 5.5), куди слід ввести сої дані (назва підприємства, МФО підприємства, контактний телефон). Також слід вказати, яку продукцію і в який термін її слід доставити. Останнім вказується пункт призначення. 

Рисунок 2.5 – Оформлення замовлення на поставку продукції

Щоб обрати поточну дату та дату поставки (день, до якою замовлення повинне обов’язкове бути виконане), слід натиснути на кнопку . Далі з’явиться календар (рисунок 5.6) і можна обрати зручну дату, натиснувши на останню. 

Рисунок 2.6 – Оформлення замовлення на поставку продукції (робота з календарем) 

Після введення усіх даних слід натиснути кнопку Підтвердити. Тоді з’явиться бланк з уведеною інформацією (рисунок 5.7). Якщо не всі поля були заповнені або були некоректно заповнені поля (рисунок 5.8), то з’явиться відповідне повідомлення (рисунок 5.9). 

Рисунок 2.7 – Інформація про замовлення 

Рисунок 2.8 – Некоректне заповнення інформації 

Рисунок 2.9 – Повідомлення про помилкове уведення даних 

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

Рисунок 2.10 – Повідомлення про оформлення замовлення

Щоб переглянути види продукції, які виготовляються на підприємствах, слід натиснути на кнопку Перегляд продукції головного меню (рисунок 5.11). 

Рисунок 2.11 – Перегляд продукції

Щоб переглянути інформацію про транспортний відділ, слід натиснути на кнопку Інформація про транспортний відділ головного меню (рисунок 5.12). 

Рисунок 2.12 - Перегляд інформація про транспортний відділ

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

Рисунок 2.13 – Побудова плану доставки продукції

2.3 Опис технологічного процесу обробки даних

У розділі вказують:

1) склад і послідовність виконання технологічних операцій з приймання, контролю, обробки, зберігання, видачі даних та інших операцій, які виконуються;

2) перелік документації, що супроводжує даний технологічний процес. 

Для даного розділу достатньо навести 1-3 діаграми послідовності  UML (або в нотації BPMN 2.0) виконання операцій процесів (наприклад "Обробка замовлення", "Розрахунок вартості"), де об’єктами взаємодії будуть персонал та елементи вашої системи.

Розділ не потрібно заповнювати, якщо дані діаграми наведені у розділі 1.5 (Архітектура ПЗ).

2.4 Висновки по розділу

Наводяться висновки до технолологічного розділу.

3 ОРГАНІЗАЦІЙНО-ЕКОНОМІЧНИЙ РОЗДІЛ

4 РОЗДІЛ ОХОРОНИ ПРАЦІ 

Висновки

ПЕРЕЛІК ПОСИЛАНЬ

Приклади бібліографічного опису 

1. Конференция

ФИО первого автора. Название [Текст]: материалы Дальше название конференции полностью, Место проведения, даты проведения: тезисы / ИОФ всех авторов /  [редкол.: ФИО (голова) и др.]. – Сколько всего страниц.– В надзаг.: То, что сверху титульного листа. – Город печатания: издательство, год. – С. от – до.

Примеры

Томашевский В.М. Віртуальний університет – нові технології навчання [Текст]: матеріали XV міжнародної наук.-практ. конф. “Інформаційні технології в економіці, менеджменті і бізнесі. Проблеми Науки, практики і освіти”, Київ, 25-26 лютого 2010 р. : тези доповідей / В.М. Томашевський, Ю.Л. Новіков, П.А. Камінська / [редкол.: І.І. Тимошенко (голова) та ін.]. – 323 с. – В надзаг.: МОН України Асоціація навчальних закладів України приватної форми власності, Європейський університет. – С.292–294. 

или 

Баляница Н.А. Определение формальных моделей основных моделируемых конструкций языка POSES ++ для расширения возможностей системы ISS 2000 [Текст] : матеріали міжнародної наук. конф. “Інтелектуальні системи прийняття рішень та прикладні аспекти інформаційних технологій”, Євпаторія, 18-22 травня 2009 : збірка наукових праць, Т. 1 / Н.А. Баляница, Н.В. Богушевская. – Херсон: ПП Вишемирський В.С.,  2009. – С.12–15. 

2. Книга

ФИО первого автора. Название [Текст]/ ИОФ всех авторов / / Город печатания: издательство, год. – Кол-во с. 

Примеры 

Буч Г. Язык UML. Руководство пользователя [Текст] / Г. Буч, Д. Рамбо, А. Джекобсон // Пер. с анл. – М.: ДМК Пресс, 2001. – 432 с. 

Транспортная логистика: Учебник для транспортных вузов [Текст]  / под общей редакцией Л.Б. Миротина–М.: Издательство „Экзамен”, 2003.– 512с. 

3. Интернет- ресурс 

Сайт розробників стандарту OMG [Електронний ресурс] // Режим доступу: http://www.omg.org 

Антипина Г. Arena – система имитационного моделирования [Електронний ресурс] / Г. Антипина, Ярцев А. – Режим доступу:   http://interface.ru/sysmod/arena.htm 

4. Статья 

Логвинский В.В. Организация базы данных схем городского ландшафта[Текст] /В.В. Логвинский //Науковий вісник Кременчуцького університету економіки, інформаційних технологій і управління "Нові технології". – Кременчук: ПП Щербатих О.В., 2009.–№1(23). – с.200-204.

З повагою ІЦ "KURSOVIKS"!