47187

Розробка системи роботи з електронним щоденником

Дипломная

Информатика, кибернетика и программирование

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

Украинкский

2013-11-24

2.34 MB

21 чел.

ЗМІСТ

[0.1] ОГЛЯД ІСНУЮЧИХ МЕТОДІВ ТА ТЕХНОЛОГІЙ У РОЗРОБЦІ СИСТЕМИ ЕЛЕКТРОННОГО ЩОДЕННИКА

[0.1.1] Огляд аналогів інформаційних систем

[0.1.2] Огляд архітектури інформаційних систем

[0.1.3] Технологія мультиагентних систем

[0.1.4] Теоретичні відомості мультиагентних систем

[0.1.5] Характеристики мультиагентних систем

[0.1.6] Технології управління та доступу до баз даних

[0.1.7] DataObjects.Net

[0.1.8] Технологія Hibernate

[0.1.9] Висновки до розділу

[0.2] ПРОЕКТУВАННЯ СИСТЕМИ

[0.2.1] Розробка структури мультиагентної системи щоденник

[0.2.2] Розробка функціональних вимог

[0.2.3] Реєстрація

[0.2.4] Авторизація в системі

[0.2.5] Редагування своїх даних

[0.2.6] Додавання нового контакту

[0.2.7] Призначення нової зустрічі

[0.2.8] Ключеві сценарії

[0.2.9] Авторизація

[0.2.10] Призначення зустрічі

[0.2.11] Шари системи

[0.2.12] Розробка структури бази даних

[0.2.13]  Розробка алгоритму призначення зустрічі

[0.2.14] Розробка шаблонів елементів GUI

[0.2.15] Вибір мови програмування

[0.2.16] Вибір середовища розробки

[0.2.17] Вибір мультиагентної технології

[0.2.18] Вибір СУБД

[0.2.19] Висновок до розділу

[0.3] ПРОГРАМНА РЕАЛІЗАЦІЯ МУЛЬТИАГЕНТНОЇ СИСТЕМИ «ЩОДЕННИК»

[0.3.1] Графічний інтерфейс

[0.3.2]  Реалізація бази даних

[0.3.3] Опис основних блоків програмних застосувань для роботи з базою даних

[0.3.4] Інструкція користувача

[0.3.5] Дослідження якості розробленої системи

[0.3.6]  Висновок до розділу

[0.4] ТЕХНІКО-ЕКОНОМІЧНЕ ОБГРУНТУВАННЯ ПРОЕКТУ

[0.4.1]  Техніко-економічна характеристика пропонованого проекту й обраного аналогу

[0.4.2] Мета, призначення й галузь застосування проекту

[0.4.3] Фактори, що визначають доцільність впровадження проекту

[0.4.4] Джерела фінансування проекту

[0.4.5]   Організаційне забезпечення проекту

[0.4.6] Інформація про продукт

[0.4.7] Забезпеченість кадрами

[0.4.8] Опис етапів виконання проекту  

[0.4.9]  Розрахунок показників економічної ефективності проекту

[0.4.10] Загальна схема розрахунків

[0.4.11] Розрахунок одноразових витрат на проект

[0.4.12] Витрати на оплату праці персоналу

[0.4.13]  Витрати на функціонування проектованого об'єкта  укрупнено включають.

[0.4.14]  Розрахунок накладних витрат

[0.4.15]  Розрахунок інших комерційних витрат

[0.4.16]  Розрахунок поточних витрат

[0.4.17]  Розрахунок показників економічної ефективності проекту

[0.4.18]  Визначення вихідної ціни товару, що виникає в результаті реалізації проектного рішення

[0.4.19]  Висновки з економічного розділу

[0.5] ОХОРОНА ПРАЦІ ТА БЕЗБЕКА У НАДЗВИЧАЙНИХ СИТУАЦІЯХ

[0.5.1] Обґрунтування вибору об’єкта.

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

[0.5.3]  Повітря робочої зони

[0.5.4]  Мікрокліматичні параметри

[0.5.5]  Шум

[0.5.6] Освітлення

[0.5.7]  Вібрація

[0.5.8]  Електромагнітне випромінювання

[0.5.9]  Електробезпека

[0.5.10]  Пожежна безпека

[0.5.11]  Розрахунок звукоізоляції і звукопоглинання

[0.5.12] Розрахунок сумарного рівня кількох джерел шуму

[0.5.13]  Розрахунок еквівалентного рівня шуму

[0.5.14] Розрахунок потрібного зниження рівня шуму

[0.5.15] Поводження в надзвичайних ситуаціях при повенях

[0.5.16] Висновок до розділу

[1] ВИСНОВКИ

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

Додаток А Код програми  94

Додаток Б Відомість до дипломного проекту 105

ВСТУП

Час – для деяких це просто час у зрозумілому тлумаченні, але зараз для багатьох людей, які хоч якось займаються великим та малим бізнесом або просто розуміють, що час плине і його можна потратити без користі для себе, або для свого бізнесу, для таких людей час є синонімом слова гроші. Часто для того, щоб наладити якісь відносини з потенціальним клієнтом або з потенціальним партнером по бізнесу треба з ним зустрітися. Для цього необхідно заздалегідь призначити зустріч. Як правило у обох сторін дуже щільній графік, тому не так просто призначити час для зустрічі. Тому люди, які мають змогу, наймають спеціальних людей, секретарів, які й приходять на поміч, та за допомогою телефону, Інтернету або інших засобів комунікацій назначають зустріч з тим чи іншим. Тобто секретар має при собі календар та розпорядок свого начальника, знаходить вільне місце, зв’язується зі стороною та узгоджує параметри  зустрічі, після обговорення вільного та зручного часу для обох сторін офіціально призначається зустріч та заноситься в розпорядок дня в календар. У наш час роботу секретаря може замінити комп’ютер. Так як комп’ютеру не треба оплачувати за його роботу то це значно заощадить кошти. Але не обов’язково користуватися цим може тільки людина, яка хоче заощадити кошти, цим принципом може користуватися будь-хто, хто цінує зручність  чіткість та швидкість. Адже існують програмні продукти, за допомогою яких можна легко та зручно призначити зустріч людині, яка користується таким самим програмним продуктом. Така програма називається електронним календарем або щоденником. Насправді використовуючи автоматизовані системи для того, щоб спланувати свою роботу та зустрічі, ми можемо заощадити багато часу, а в деяких випадках навіть гроші.

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

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

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

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

  1.  ОГЛЯД ІСНУЮЧИХ МЕТОДІВ ТА ТЕХНОЛОГІЙ У РОЗРОБЦІ СИСТЕМИ ЕЛЕКТРОННОГО ЩОДЕННИКА

  1.  Огляд аналогів інформаційних систем

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

Зараз існує паперова  та електронна версія щоденника. Чому передати перевагу діло кожного. Усе залежить від функціональності та зручності.

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

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

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

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

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

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

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

Щоденник  може включати будь-яку кількість розділів. Визначення цих розділів  −  ключове завдання в розробці індивідуального щоденника. Кожному з основних напрямків у роботі й життя людини в цілому повинен відповідати окремий розділ, який, у свою чергу, може мати будь-яку кількість сторінок.

Охарактеризуємо найбільш важливі й у той самий час універсальні розділи:

  •  «справи (1-й пріоритет)» − найбільш важливі напрямки в житті і роботі.
  •  «справи (2-й пріоритет)» − справи другої черги (як по терміновості, так і за важливістю);
  •  «терміново» − справи, що вимагають негайного втручання й вирішення. Як правило, подібних напрямків у роботі не буває багато одночасно, проте фіксація їх доцільна, тому що іноді навіть саме термінова справа не може бути виконано так швидко, як цього хотілося б;
  •  «начальство» − завдання, доручення, прохання начальства;
  •  «питання» − виникають по ходу виконання роботи питання до керівництва, фахівців;
  •  «ідеї» − методи вирішення якихось складних ситуацій, проблем, пропозиції щодо вдосконалення тієї або іншої діяльності, оригінальні проекти, прогнози;
  •  «завдання» − доручення, завдання підлеглим, розподіл обов'язків, делегування повноважень;
  •  «фінанси» − відображення тієї чи іншої фінансової діяльності, включаючи, у тому числі, особисту бухгалтерію;
  •  «правила» − сукупність правил, принципів роботи, які вимагають періодичного повторення.

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

Структура індивідуального щоденника буде залежати від ряду факторів:

  •  передбачувана щільність використання;
  •  характер і специфіка роботи;
  •  суб'єктивні вподобання.

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

Необхідно відзначити деякі принципи використання щоденника:

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

Підсумуємо, що ж цінного дає щоденник своєму власникові:

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

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

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

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

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

Далі в розділі, дається стислий опис систем-аналогів, та висновки стосовно позитивних та негативних сторін у кожній з реалізацій.

Одним з програм аналогів може виступати календар у програмному продукті Outlook (рис. 1.1).

Рисунок . −  Календар Outlook

Для управління особистим часом в Outlook використовується розділ "Календар". У календарі користувачі можуть зберігати різні події, які називаються  в термінах Outlook зустрічами. На стандартній панелі інструментів розміщені кнопки, за допомогою яких можна керувати режимом відображення календаря. Можливі варіанти перегляду: день, тиждень, місяць.

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

Ще одним аналогом такої системи може виступати система “Google Calendar” (рис. 1.2). Це безоплатна система, якою може користуватися будь-який користувач , який зареєстрований у Google.

Рисунок . – Календар Google

Google Calendar − сервіс для планування зустрічей, подій, справ з прив'язкою до календаря. Можна задавати час зустрічі, повторення, нагадування, запрошувати інших учасників (їм висилається запрошення по ектронній пошті).

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

В інтерфейсі можна користуватися «гарячими клавішами», є рядок для швидкого занесення події, наприклад, «Завтра Зустріти Джулі в 6:00 вечора» створить подія на наступний день в 18:00 з назвою «Meet Julie» («Зустріти Джулію»). Зручна функція − автоматичне занесення листів, що містять подібні рядки в тілі листа, у розклад.

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

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

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

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

  1.  Огляд архітектури інформаційних систем

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

Рисунок . – Архітектура − клієнт-сервер

Мережеві багатокористувацькі системи будуються за принципом файл-серверної архітектури (рис. 1.4). Дані у вигляді одного або декількох файлів розміщуються на файловому сервері. Файловий сервер приймає запити, що надходять по мережі від комп'ютерів-клієнтів, і передає їм необхідні дані. Однак обробка цих даних виконується на комп'ютерах-клієнтах. На кожному з комп'ютерів запускається повна копія процесора обробки даних. Будь-яка копія Jet незалежно управляє файлами MDB, що містять дані. Єдиний зв'язок між цими незалежними діями − файл блокувань, який обов'язково створюється для кожного файлу бази даних з розширенням mdb. При цьому кожна копія Jet виконує зміни індексів, роботу із системними таблицями та інші функції, що входять у компетенцію СУБД.

Рисунок . Архітектура файл-сервер

В архітектурі "клієнт-сервер" сервер бази даних не тільки забезпечує доступ до загальних даних, але й бере на себе всю обробку цих даних. Клієнт посилає на сервер запити на читання або зміну даних, які формулюються на мові SQL. Сервер сам виконує всі необхідні зміни або вибірки, контролюючи при цьому цілісність і узгодженість даних, і результати у вигляді набору записів, або коду повернення посилає на комп'ютер клієнта.

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

Архітектура "клієнт-сервер" дозволяє усунути всі зазначені недоліки. Крім того, вона дозволяє оптимально розподілити обчислювальне навантаження між клієнтом і сервером, що також впливає на багато характеристик системи: вартість, продуктивність, підтримку.

  1.  Технологія мультиагентних систем

  1.  Теоретичні відомості мультиагентних систем

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

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

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

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

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

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

  1.  Характеристики мультиагентних систем

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

Агенти мають кілька важливих характеристик:

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

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

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

Агенти можуть обмінюватися отриманими знаннями, використовуючи деяку спеціальну мову й підкоряючись установленим правилам «спілкування» (протоколам) у системі. Прикладами таких мов є Knowledge Query Manipulation Language (KQML) і FIPA's Agent Communication Language (ACL).

Вивчення багатоагентних систем пов'язане з вирішенням проблем штучного інтелекту. Такими як:

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

Модель «Запит − відповідь − Угода» − звичайне явище для МАС. Схема реалізується за кілька кроків:

  •  спочатку всім задається питання на зразок: «Хто може мені допомогти?»;
  •  на що тільки «здатні» відповідають «Я зможу, за таку-то ціну»;
  •  у кінцевому підсумку, встановлюється «угода».

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

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

Головне достоїнство МАС − це гнучкість. Мультиагентна  система може бути доповнена й модифікована без переписування значної частини програми. Також ці системи мають здатність до самовідновлення й володіють стійкістю до збоїв, завдяки достатньому запасу компонентів і самоорганізації.

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

Засоби розробки мультиагентних систем:

  •  NetLogo – програмне оточення для програмування мультиагентних систем;
  •  VisualBots − безкоштовний мультагентний симулятор в Microsoft Excel з Visual Basic синтаксисом;
  •  MASON − Java бібліотека для моделювання мультиагентних систем;
  •  REPAST − набір інструментів для створення систем, заснованих на агентах;
  •  JADE − Java бібліотека для створення мультиагентних систем.

  1.  Технології управління та доступу до баз даних 

  1.  DataObjects.Net

Платформа, яка об'єднує в собі вбудовану базу даних, засоби для реалізації бізнес-логіки й готовий рівень доступу до даних (ORM), що підтримує як найбільш поширені БД (Microsoft SQL Server, Oracle, PostgreSQL), так і вбудовану базу даних.

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

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

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

  1.  Технологія Hibernate

Для роботи з БД у дипломному проекті використовується фреймворк Hibernate.

Hibernate − бібліотека для мови програмування Java, призначена для вирішення завдань об'єктно-реляційного відображення (object-relational mapping − ORM). Вона являє собою вільне програмне забезпечення з відкритим вихідним кодом, яке розповсюджується на умовах GNU Lesser General Public License. Дана бібліотека надає легкий у використанні каркас для відображення об'єктно-орієнтованої моделі даних у традиційні реляційні бази даних.

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

Hibernate не тільки вирішує задачу зв'язку класів Java з таблицями бази даних, але також надає засоби для автоматичної генерації та поновлення набору таблиць, побудови запитів та обробки отриманих даних і може значно зменшити час розробки, який зазвичай витрачається на ручне написання SQL − і JDBC-коду. Hibernate автоматизує генерацію SQL-запитів і звільняє розробника від ручної обробки результуючого набору даних і перетворення об'єктів, максимально полегшуючи перенесення додатків на будь-які бази даних SQL.

Hibernate забезпечує прозору підтримку схоронності даних (persistence), єдина сувора вимога для зберігання класу − наявність конструктора за замовчуванням (без параметрів).

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

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

Hibernate підтримує відображення користувацьких типів значень. Це робить можливим такі сценарії:

  •  перевизначення типу за замовчуванням SQL, Hibernate вибирає при відображенні стовпця властивості;
  •  картування типу Java до колонок БД, ніби вони є звичайними властивостями;
  •  картування однієї властивості в кількох стовпиків.

Hibernate забезпечує використання SQL-подібного мови Hibernate Query Language (HQL), який дозволяє виконувати SQL-подібні запити, записані поруч з об'єктами даних Hibernate. Запити критеріїв надаються як об'єктно-орієнтована альтернатива до HQL.

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

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

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

  1.  ПРОЕКТУВАННЯ СИСТЕМИ

  1.  
    1.  Розробка структури мультиагентної системи щоденник

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

Система повинна мати наступній функціонал:

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

Було розроблено структурну схему системи (рис. 2.1).

Рисунок . − Структурна схема системи електронний щоденник

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

Рисунок . Діаграма прецедентів системи електронний щоденник

  1.  Розробка функціональних вимог

  1.  Реєстрація 

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

Сценарій:

  1.  система виводить на екран вікно реєстрації користувача;
  2.  користувач заповнює поля: логін та пароль (обов’язкові), ім’я, прізвище, по батькові;
  3.  система перевіряє введені данні користувачем та реєструє його у системі;
  4.  успішна реєстрація – користувач отримує доступ до авторизації;
  5.  невдала авторизація – система видає повідомлення про помилку.

  1.  Авторизація в системі

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

Сценарій:

  1.  система виводить на екран форму авторизації;
  2.  користувач вводить логін та пароль, та запитує авторизацію;
  3.  система перевіряє логін та пароль, введений користувачем. Проводить авторизацію;
  4.  успішно виконана авторизація – користувачу надається доступ до функціоналу системи;
  5.  помилка при авторизації – видається повідомлення про помилку.

  1.  Редагування своїх даних

Часто буває,що користувач на швидку руку вписує дані. Тому для цього випадку передбачено редагування даних.

Сценарій:

  1.  система надає користувачеві форму редагування з даними, вже існуючими в системі;
  2.  користувач змінює власні данні на власний розсуд та запитує збереження даних;
  3.  система оновлює данні про користувача.

  1.  Додавання нового контакту

Кожен користувач має свій список контактів. Та має змогу додавати нового контакту.

Сценарій:

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

  1.  Призначення нової зустрічі

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

Сценарій:

  1.  система виводить форму призначення нової зустрічі;
  2.  користувач вводить необхідні данні: час та дата зустрічі, тема та логін користувача з ким планується призначити зустріч;
  3.  система перевіряє можливість призначення зустрічі та повідомляє обох користувачів;
  4.  користувачі дають згоду на призначення зустрічі;
  5.  система записує інформацію про зустріч до календарів обох користувачів.
  6.  якщо користувачі не дають згоду на призначення зустрічі система їх повідомляє про це та дає вибір ввести інші данні або відмінити запит.

  1.  Ключеві сценарії

  1.  Авторизація 

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

Рисунок . – Діаграма послідовності

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

  1.  Призначення зустрічі

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

  1.  користувач повинен бути авторизований
  2.  обрати контакт зі списку контактів;
  3.  обрати потрібний день для зустрічі;
  4.  відправити запит на створення зустрічі.

Для призначення зустрічі необхідно ввести наступні данні:

  1.  дата зустрічі;
  2.  час зустрічі;
  3.  тема зустрічі;
  4.  логін користувача з ким призначається зустріч (користувач повинен бути в списку контактів).

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

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

  1.  Шари системи

Система розподілена на три шари (рис. 2.5):

Рисунок . – Шари системи

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

  1.  Розробка структури бази даних

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

Розглянемо структуру таблиць «user», «user_info» та «contact_list». В таблиці «users» заносяться дані логіну та паролю користувача, в текстовій формі. Поле коду користувача генерується автоматично.

Таблиця .− Опис полів таблиці «users»

Ім’я  поля

Тип даних

Примітка

id

Лічильник

Код користувача

Login

Текстовий

Логін користувача в системі

Pass

Текстовий

Пароль користувача в системі

У таблицю 2.2 заносяться дані імені, прізвища та по батькові користувача, а також код користувача системи з таблиці «users».

Таблиця . − Опис полів таблиці «user_info»

Ім’я  поля

Тип даних

Примітка

Id_user

Числовий

Код користувача з таблиці користувачів

Name

Текстовий

Ім’я користувача

Lastname

Текстовий

Прізвище користувача

MiddleNme

Текстовий

По батькові

Також передбачена таблиця для занесення контактів користувача (Табл.  2.3). У ній зберігаються дані про список контактів кожного користувача. Містить поле коду користувача, взятого з таблиці користувачів (власник контактів) та код контакту, який також зв’язаний з таблицею користувачів системи.

Таблиця . − Опис полів таблиці «contact_list»

Ім’я  поля

Тип даних

Примітка

idUser

Числовий

Код користувача − власника списку контактів

idUserContact

Числовий

Код користувача − контакт

У базі користувачів таблиця контактів містить два id які відносяться до таблиці users, тобто буде зберігатися попарно, наприклад: Петро Іван, Петро Ігор, тобто Петро має двох друзів Івана та Ігоря.

База даних календаря містить дві таблиці data та metting. У першу заноситься  дані про дату зустрічі та час зустрічі. У другу таблицю заносяться дані про саму зустріч, тобто с ким зустріч назначена, та тема зустрічі.

  1.   Розробка алгоритму призначення зустрічі

У процесі розробки системи був розроблений алгоритм роботи системи, створення зустрічі (рис. 2.6).

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

Рисунок . − Схема алгоритму призначення зустрічі

  1.  Розробка шаблонів елементів GUI

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

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

Для початку при запуску програмного продукту виводиться вікно авторизації (рис. 2.7). Воно містить такі елементи: поле вводу логіну, поле вводу паролю, та три кнопки. Кнопка «Ок» при якій відбувається процес авторизації, кнопка «Отмена» − відміняються всі дії та програма закривається, та кнопка «Реєстрації».

Рисунок . − Вікно авторизації

Для реєстрації користувача в системі розроблена форма реєстрації (рис. 2.8).

Рисунок . – Форма «Реєстрація»

Також був розроблений шаблон головної панелі користувача (рис. 2.8). До панелі входить панель календаря – простий календар, панель контактів, панель розпорядку зустрічей на конкретно обраний день, а також дві кнопки добавити новий контакт та кнопка для призначення зустрічі.

Рисунок . − Головна панель користувача

Рисунок . − Призначення зустрічі

  1.  Вибір мови програмування

Існує безліч мов програмування. Для розробки системи потрібно, щоб мова програмування мала наступні властивості:

  •  об'єктно-орієнтована мова;
  •  інструмент мережевого програмування;
  •  інструмент роботи з агентами.

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

Основні можливості мови:

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

  •  набір стандартних колекцій, таких, як масив, список, стек і т. д.;
  •  наявність простих засобів створення мережевих додатків (у тому числі з використанням протоколу RMI);
  •  наявність класів, що дозволяють виконувати HTTP-запити й обробляти відповіді;
  •  вбудовані в мову засоби створення багато поточних додатків;
  •  уніфікований доступ до баз даних:
  •  на рівні окремих SQL-запитів − на основі JDBC, SQLJ;
  •  на рівні концепції об'єктів, що мають здатність до зберігання в базі даних − на основі Java Data Objects і Java Persistence API;
  •  підтримка шаблонів;
  •  паралельне виконання програм.

  1.  Вибір середовища розробки

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

  •  Idea;
  •  Eclipse;
  •  NetBeans;

Idea дуже зручна у використанні, але вона являється платною середою розробки. NetBeans як і Eclipse являються безоплатними середовищами програмування.  NetBeans потребую потужний комп’ютер для того, щоб можна було без зависань спокійно працювати. Також одним з плюсів цього середовища – являється редактор форм. Редактор форм являється як плюсом, так і мінусом. Для не досвідченого програміста редактор форм здаватиметься дуже зручним, але він не дозволяє після генерації коду, змінювати його.

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

  1.  Вибір мультиагентної технології

Так як проект, як описано вище, буде розроблятися за допомогою мови програмування Java, а також проект буде використовувати мультиагнетну технологію, то для розробки системи потрібно обрати бібліотеку для забезпечення мультиагентності.

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

  •  Mason;
  •  SemanticAgent;
  •  Jade.

Mason – швидка система дискретного моделювання мультиагентності для мови програмування Java.

JADE повністю написана на мові програмування Java з використанням таких можливостей, як Java RMI, Java CORBA IDL, Java Serialization і Java Reflection API. Вона спрощує розробку мультиагентних систем завдяки використанню FIPA-специфікацій та за допомогою ряду інструментів (інструментів), які підтримують фази виправлення помилок (налагодження) і розгортання (установки), системи.

SemanticAgent є реалізацією SAM (Semantic Agent Model), він є основою для програмування МАС з використанням семантичних веб-технологій. Агенти запрограмовані, як розширена кінцевий автомат використанням SWRL. SemanticAgent побудований на основі Jade.

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

 

  1.  Вибір СУБД

Як було зазначено вище, для розробки використовується мова програмування Java, і так, як система, яка розробляється, повинна мати БД, то для виконання системи треба обрати СУБД.

Існує безліч СУБД, таких як:

  •  Oracle;
  •  Firebird;
  •  Interbase;
  •  IBM DB;
  •  Informix;
  •  MS SQL Server;
  •  Sybase Adaptive Server Enterprise;
  •   PostgreSQL;
  •  MySQL;
  •  HSQLDB.

Для розробки системи обираємо СУБД HSQLDB, так як вона має безліч переваг. По-перше, вона повністю розроблена на мові програмування Java і має 100 відсоткову сумісність з Java, має дуже невеликий розмір.

HSQLDB − реляційна СУБД з відкритим вихідним кодом. Поширюється за власною ліцензією, близькою до ліцензії BSD. Підтримує стандарти SQL-92 , SQL: 1999 , SQL: 2003 і SQL: 2008.

HSQLDB повністю написана на Java і відрізняється невеликим розміром (розмір близько 1100 кБ для версії 2.0). Може використовуватися і як окремий сервер з підтримкою мережних з'єднань за JDBC , і у вигляді бібліотеки для використання безпосередньо в коді програми.

HSQLDB використовується в багатьох відомих програмних продуктах, зокрема, в LibreOffice , OpenOffice.org , JBoss , Openfire , JAMWiki.

Можливості HSQLDB:

  •  оригінальний код, заснований на всебічному дослідженні теорії бази даних і стандарту SQL;
  •  підтримка передових можливостей SQL, на відміну від інших рішень open-source;
  •  сама швидка й повна реалізація SQL open-source для маленьких баз і баз даних середнього розміру;
  •  три моделі контролю на операціями транзакцій, включаючи блокування, базуються на моделі MVC;
  •  повністю багатопоточний;
  •  компактна кодова модель.

Підтримка Java:

  •  100% Java код;
  •  підтримка JDK 1.1.x, 1.2.x, 1.3.x, 1.4.x, 1.5.x, 1.6.x in HSQLDB 1.8.1 та 1.5.x і 1.6.x в HSQLDB 2.0;
  •  розширення інтерфейсу JDBC підтримують пакетні команди і повернення значення у вигляді списку;
  •  оновлюється;
  •  повна підтримка JDBC DatabaseMetaData і ResultSetMetaData;
  •  збережені процедури й функції;
  •  повна підтримка для об'єктів PreparedStatement для прискорення запитів.

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

У даному розділі був проведений повний аналіз теми дипломного проекту, а саме мультиагентна система «щоденник». Було спроектовано алгоритм роботи програми, призначення зустрічі. Також було описано та обрано технології, які використовуватимуться в написанні даного проекту. У результаті проектування системи було обрано ряд технологій:

  •  мова програмування Java;
  •  мультиагентна бібліотека Jade;
  •  СУБД – HSQLDB;
  •  cередовище розробки Eclipse IDE;
  •  фреймворк Hibernate.

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

  1.  ПРОГРАМНА РЕАЛІЗАЦІЯ МУЛЬТИАГЕНТНОЇ СИСТЕМИ «ЩОДЕННИК»

  1.  
    1.  Графічний інтерфейс

Для створення графічного інтерфейсу розроблюваної системи із двох технологій, передбачених для створення інтерфейсу AWT та SWING було використано SWING. SWING відноситься бібліотеки до класів JFC, яка представляє собою набір бібліотек для розробки графічних оболонок.

Swing − інструментарій для створення графічного інтерфейсу користувача (GUI) мовою програмування Java. Це частина бібліотеки базових класів Java (JFC, Java Foundation Classes).

Swing розробляли для забезпечення функціонального набору програмних компонентів для створення графічного інтерфейсу користувача, ніж у інструментарію AWT. Компоненти Swing підтримують специфічні look-and-feel модулі, що динамічно підключаються. Завдяки ним можлива емуляція графічного інтерфейсу платформи (тобто до компоненту можна динамічно підключити інші, специфічні для даної операційної системи вигляд і поведінку). Основним недоліком таких компонентів є відносно повільна робота, хоча останнім часом це не вдалося підтвердити через зростання потужності персональних комп'ютерів. Позитивна сторона − універсальність інтерфейсу створених програм на всіх платформах.

Конкретно для створення вікон інтерфейсу використовувалися класи JFame та JPanel. Для створення об’єкту класу JFrame передбачено чотири конструктори:

  •  JFrame() – створює нове вікно, яке спочатку невидиме;
  •  JFrame(GraphicsConfiguration gc) – створює вікно з конфігурацією екрану пристрою та назвою вікна;
  •  JFrame(String title) – створює нове вікно з зазначеною назвою;
  •  JFrame(String title, GraphicsConfiguration gc) – створює нове вікно з конфігурацією екрану та із зазначеною назвою.

Для створення вікна мною було використано наступні методи класу JFame:

  •  setDefaultCloseOperation(int operation) – метод для встановлення реакції вікна при його закритті;
  •  setJMenuBar(JMenuBar menubar) – метод для установки створеного головного меню у вікно;
  •  add(Component comp) −  метод для добавлення компоненту на вікно;
  •  setLayout(LayoutManager manager) – метод для створення та встановлення нового менеджеру розстановки компонентів.

Для створення інтерфейсу також використовувались такі графічні компоненти, як:

  •  JLebal − напис;
  •  JButton − кнопка;
  •  JTextField – текстове поле;
  •  JComboBox – випадаючий список;
  •  JList − список;

Мало того, щоб створити графічний інтерфейс, для того, щоб була реакція системи на вплив користувача, в Java існує клас інтерфейс ActionListener.

ActionListener – це клас-слухач. Для роботи треба перевизначити один метод ActionPerformed(), який має лише один параметр – об’єктне посилання на об’єкт класу ActionEvent. Для того щоб елемент інтерфейсу реагував на натискання користувачем, треба виповнити метод addActionListener().

Коли користувач натисне кнопку, об’єкт – кнопка створить об’єкт класу ActionEvent та викличе метод actionPerformed(event).

Зв'язок створених форм між собою та можливість переходу користувачем від одної форми до іншої зображені на малюнку(рис. 3.1).

Рисунок . – Діаграма переходів

  1.   Реалізація бази даних

У дипломному проекті було спроектовано базу даних згідно опису у попередньому розділі. (рис. 3.2).

Таблиця user містить три поля (лістинг 3.1). Ідентифікатор користувача, поле id –  має цілочислений тип даних, а також інформація в дане поле вноситься автоматично – лічильником. Поле логін має буквений тип даних varchar),  так як користувач маже бути зареєстрований тільки один раз, то поле повинно бути унікальним. Поле пароль має також буквений тип даних, але може повторюватись.

Лістинг 3.1 – Скрипт створення таблиці USER

create table user

(

   id smallint,

   login varchar(20) not null,

   pass  char(33) not null,

   user_fk varchar(40),

   constraint pk_user primary key (id)

);

Рисунок . − Схема бази даних таблиці користувачів

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

Лістинг 3.2 – Скрипт створення таблиці user_info

create table user_info

(

   name varchar(40) not null,

   lname varchar(33) not null,

   constraint pk_user primary key (user)

);

Для зберігання інформації про контакти користувача була розроблена таблиця contacts (лістинг 3.1).

Лістинг 3.3 – Скрипт створення таблиці User

create table contacts

(

  iduser smallint,

  idcontct smallint,

);

Таблиця contacts містить у собі два поля: поле з числовим значенням коду користувача-власника контакту та поле з числовим типом даних – користувач контакт. Обидва користувачі повинні бути зареєстровані в системі.

Також на стороні клієнта передбачено створення бази зустрічей користувача (рис.3.3).

Рисунок . − Схема бази даних зустрічей

  1.  Опис основних блоків програмних застосувань для роботи з базою даних

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

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

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

  1.  Інструкція користувача

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

Рисунок . − Вікно авторизації

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

Рисунок . − Вікно головної користувацької панелі

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

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

Користувач системи має змогу добавляти до себе в контакти користувача, який є вже  користувачем даної  системи. Для цього на панелі контактів треба натиснути лише кнопку «add». Після чого з’явиться вікно для введення логіну користувача якого ви хочете добавити до свого списку контактів (рис. 3.6).

Рисунок . Вікно додавання нового контакту

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

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

Для призначення зустрічі треба натиснути кнопку призначення зустрічі та ввести в необхідні поля: дату, час тему та логін контакту з яким планується зустріч(рис. 3.8).

Рисунок . − Вікно реєстрації

Рисунок . − Вікно призначення нової зустрічі

  1.  Дослідження якості розробленої системи

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

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

  1.  запускаємо сервер;
  2.  запускаємо клієнтську частину для обох користувачів;
  3.  проходимо авторизацію для обох користувачів(рис. 3.9);
  4.  у користувачів ще не має запланованих зустрічей;
  5.  один з користувачів починає створювати зустріч, вводячи необхідну інформацію: час зустрічі, день зустрічі, тему зустрічі, та контакт з ким буде призначена зустріч.
  6.  користувачу з ким призначається зустріч, отримує повідомлення з інформацією про зустріч. Він має два варіанти вибору, підтвердити, або відмовити.
  7.  якщо користувач підтвердив, то користувачу-відправнику приходить повідомлення про згоду. Та запитується згода на запис нової зустрічі до бази.

Рисунок . – Авторизація користувачів «test», «vernand»

Рисунок . – Призначення зустрічі

Рисунок .− План дня зі створеною зустріччю

У другому випадку один з користувачів уже має заплановану зустріч:

  1.  запускаємо сервер;
  2.  запускаємо клієнтську частину для обох користувачів;
  3.  проходимо авторизацію для обох користувачів;
  4.  користувач test має заплановану зустріч;
  5.  користувач vernand створює зустріч  у той самий час (як і у користувача test);
  6.  так як на цей час встановлена зустріч, користувачу vernand приходить повідомлення про це та пропонується обрати інший час зустрічі;
  7.  після узгодження часу зустрічі створюється зустріч.

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

Приведемо порівняння із системою аналогом Outlook у таблиці 3.1

Таблиця  3.1 – Порівняння систем Outlook та системи «Щоденник»

Назва системи

Займає оперативної пам’яті

Займає постійної пам’яті

Час запуску

Мультиагентна система «Щоденник»

1152 Кб

29.1 Кб

1.68 с

Microsoft Outlook

35664 Кб

218365 Кб

0.97 с

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

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

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

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

  1.  ТЕХНІКО-ЕКОНОМІЧНЕ ОБГРУНТУВАННЯ ПРОЕКТУ

  1.  
    1.   Техніко-економічна характеристика пропонованого проекту й обраного аналогу

  1.  Мета, призначення й галузь застосування проекту

Дослідженню підлягає дипломній проект «Мультиагентна система – «Щоденник»».

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

  1.  Фактори, що визначають доцільність впровадження проекту

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

  1.  Джерела фінансування проекту

Розробка дипломного проекту «Мультиагентна система «Щоденник»», виповнена повністю розробником. Фінансування проекту також здійснюється за кошти самого розробника

  1.    Організаційне забезпечення проекту

  1.  Інформація про продукт

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

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

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

  1.  Забезпеченість кадрами 

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

  •  розробник системи;
  •  консультанти  з  області  проектування  систем.

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

  1.  Опис етапів виконання проекту  

Склад усіх робіт приведено в таблиці 4.1.

Таблиця 4.1 – Склад робіт проекту та їх тривалість

Етап

Зміст робіт

Виконавець

Термін

виконання, Т (дні)

категорія

кількість

Розробка

технічного

завдання

Отримання завдання

на розробку

розробник

1

1

Складання плану

робіт проекту

розробник

1

1

Оформлення

Технічного завдання (ТЗ) на розробку

розробник

1

3

Розробка

проектної  документації

Складання вимог  до  дипломного проекту

розробник

1

3

Архітектура

дипломної програми

розробник

1

8

Оформлення проектної  документації

розробник

1

2

Розробка концепції

Аналіз сучасного

стану проблеми

розробник

1

3

Аналіз існуючих

систем  для реалізації   даної задачі.

розробник

1

4

Аналіз засобів і

методів для реалізації

проекту.

розробник

1

2

Огляд існуючих

систем

розробник

1

5

Розробка

проекту

Огляд відомих

технічних рішень

розробник

1

7

Реалізація

Проекту

Розробка основних

функціональних вимог

розробник

1

4

Розробка  структури проектованої системи

розробник

1

8

Реалізація

Проекту

Підготовка   основної частини  документації проекту

розробник

1

6

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

Етап

Зміст робіт

Виконавець

Термін

виконання, Т (дні)

категорія

кількість

Реалізація

Проекту

Підготовка   основної частини  документації проекту

розробник

1

6

Розробка   додаткових модулів (інтерфейс користувача)

розробник

1

3

Доопрацювання програмної  системи

розробник

1

2

Розробка економічного обґрунтування

дипломного

проекту

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

розробник

1

8

Охорона

праці

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

розробник

1

8

Завершення

проекту

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

розробник

1

2

Створення презентації

розробник

1

5

Захист проекту та закриття  проекту

розробник

1

1

Всього днів

100

  1.   Розрахунок показників економічної ефективності проекту

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

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

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

  1.  Загальна схема розрахунків

Очікуваний економічний ефект визначається за формулою:

,       (4.1)

де Еріч – річна економія на поточних витратах, грн.;

    Кп – одноразові витрати на проект, грн.;

    Ен – нормативний коефіцієнт ефективності одноразових витрат.

Річна  економія  складається  з  економії поточних витрат і приросту прибутку у зв'язку із впровадженням проекту в такий спосіб:

                    ,          (4.2)

де Pб, Pn – поточні витрати до й після впровадження проекту, грн.;

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

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

,      (4.3)

де  Knp – одноразові витрати на розробку проекту, грн.;

     Kco – одноразові витрати на спеціальне устаткування, грн.;

     Kcon –  супутні одноразові витрати, грн.

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

,       (4.4)

Якщо ≥, то проект ефективний.

Розраховується  термін окупності одноразових витрат проекту

,       (4.5)

  1.  Розрахунок одноразових витрат на проект

Для  споживача  проекту  одноразовими  будуть  усі  витрати,  які  він  повинен понести  у  зв'язку  з  переходом  на  експлуатацію  продукту,  що  виникли  в  рамках проекту.  У  загальному  вигляді  ці  витрати  можна  виразити  формулою  (4.3). Витрати на розробку проекту К п визначаються на основі тривалості кожного етапу, починаючи  з  розробки  концепції  проекту  й  включаючи  етап  упровадження проекту. Дана інформація зведена в таблиці 4.1.

Трудомісткість  розробки  проекту  T n  може  бути  визначена  як  сума  величин трудомісткості  виконання  окремих  етапів  проекту.  Трудомісткість  етапів проектування  встановлюється  за  фактичними  витратами  часу  (календарного)  у люд./дн. з усіма роботами, виконуваними в рамках цих етапів. У даному проекті трудомісткість дорівнює 100 людино-дням.

Розрахунок одноразових витрат Kn може бути представлений у вигляді кошторису витрат у таблиці 4.2.

Витрати на спеціальне  встаткування Kco – це витрати, пов'язані із придбанням, орендою (якщо в цьому є необхідність) комп'ютерного, лабораторного устаткування, верстатного парку або іншого устаткування, необхідного для виконання проектних, науково-дослідних, експериментальних робіт проекту. Визначається на основі ринкової вартості з надбавкою 10 – 15 %.

В нашому випадку до цієї статті витрат відноситься придбання комп’ютерної  техніки. Значення цих витрат становить:

К = 3600 + 3600 х 0,15 = 4140 (грн.).

Супутні одноразові витрати  Kcon   розраховуються за формулою:

    (4.6)

де Kmp – витрати на доставку спроектованого виробу до місця експлуатації, грн. (можуть бути прийнятими в межах 2 –  6 % від ціни виробу);

K м – витрати на установку, монтаж, налагодження виробу, грн;

Knp – інші витрати, пов'язані з демонтажем замінного компонента устаткування або будь-якої його  частини  і та. ін., грн.;

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

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

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

Усі результати приведених розрахунків зводимо у таблицю кошторису

витрат (таблиця 4.2).

Таблиця 4.2  Кошторис витрат на проект

п п

Найменування

статті

Сума,

грн

Алгоритм розрахунку

1

Матеріали й комплектуючі вироби, необхідні для розробки проекту

860

– кількість і-го матеріалу;

– ринкова ціна і-го матеріалу

2

Транспортно-заготівельні витрати

86

10 – 12 % від п. 1

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

п п

Найменування

статті

Сума,

грн.

Алгоритм розрахунку

3

Витрати на машинний час, використовуваний при

розробці проекту

900

– час використання машинного часу на і-му етапі проекту;

– ціна 1 години роботи ЕОМ на і-му етапі проекту

4

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

4800

Виходячи із трудомісткості розробки , кількості фахівців і посадових окладів(табл.1)

5

Додаткова заробітна плата учасників проекту

480

10 % від п. 4

6

Нарахування на соціальне страхування

2006

38,0 % від (п. 4 + п. 5)

7

Накладні витрати

4224

80 % від (п. 4 + п. 5)

8

Разом виробнича собівартість

13356

∑(п.1 – п.7)

9

Інші комерційні витрати

2671

20 % від п. 8

10

Одноразові витрати на розробку проекту

16027

∑(п. 8 + п. 9)

11

Витрати на спеціальне  устаткування

4140

Визначається на основі його ринкової вартості з надбавкою 10 – 15 %

12

Супутні одноразові витрати

500

Розраховуються за формулою (8)

13

Одноразові витрати на проект

2066

∑(п. 10 +п. 11+ п. 12)

  1.  Витрати на оплату праці персоналу

Річний фонд основної заробітної плати персоналу (робітники-фахівці, електронщики, наладчики):

,      (4.7)

де Чі – чисельність фахівців і-ї  категорії, люд.;

Зі – річний фонд оплати праці фахівця і-й  категорії, грн.

Розробник працює 100 робочих днів зі ставкою 30 грн./день.

Кожний з трьох консультантів, який залучений у проекті, працює в сукупності 15 робочих днів зі ставкою 40 грн./день.  

Отже основна заробітна плата складає:

Зосн = 1 x100  30 + 3  15  40 = 4800 (грн.).

Річний фонд додаткової заробітної плати:

,      (4.8)

де Кдоп – коефіцієнт додаткової заробітної плати (у розрахунках можна прийняти  Кдоп=0.1);    

Приймаючи значення коефіцієнту Кдоп = 0.1, маємо:

Кдоп = 4800  0.1 = 480 (грн.)

Нарахування на соціальне страхування:

,     (4.9)

де Кнач – коефіцієнт нарахувань на соціальне страхування:  

  1.  соціальне страхування на випадок пенсійного забезпечення (31, 8 %);
  2.  соціальне страхування на випадок тимчасової втрати працездатності (2,9 %);
  3.  соціальне страхування по безробіттю (1,3 %);
  4.  соціальне страхування від нещасних випадків і професійних захворювань (умовно приймається 2,0 %), у розрахунках можна приймати Кнач=0.38 .

За формулою (4.9) отримуємо:

Знач = (4800 + 480)×0,38=2006 (грн.).

Загальні витрати на оплату праці складуть:

.      (4.10)

Зопл = 4800 + 480 + 2006 = 7286 (грн.)

  1.   Витрати на функціонування проектованого об'єкта  укрупнено включають.

Вартість машинного часу при функціонуванні об'єкта:

,       (4.11)

де   Т – машинний час, необхідний для експлуатації об'єкта, година;

См – вартість однієї години роботи обчислювального комплексу, грн.

Вважаємо що значення Т складається зі 60 днів в середньому по 3 години, а  вартість однієї години складає 5 грн. Тоді  Змв складає:

Змв = 60 × 3 × 5 = 900 (грн.).

Вартість додаткових матеріалів при експлуатації об'єкта:

,      (4.12)

де    Зі  – кількість i-го виду матеріалів, шт., кг і т.д.;

Сі – вартість (ринкова ціна) і-го виду матеріалу, грн.

Результат розрахунків представлений в таблиці 4.3.

Таблиця 4.3 – Розрахунок матеріальних витрат

Найменування

матеріальних витрат

Кількість

Ціна, грн.

Канцелярські товари

50

Бумага Аone А4,

2

80

Друк

1

Оренда сервера

500

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

Найменування

матеріальних витрат

Кількість

Ціна, грн.

Інтернет

100

Диск

1

5

Робота ПК

50

Отже, загальна сума матеріальних витрат становить 860 грн.

Витрати на функціонування об'єкта:

,      (4.13)

де  Змв – вартість машинного часу при функціонуванні об'єкта, грн.;

Змат – вартість видаткових матеріалів при експлуатації об'єкта, грн.

Отже, загальна сума функціонування об'єкта становить 900 грн.

  1.   Розрахунок накладних витрат

Накладні витрати можуть становити порядку 80 –  120 % від основної й додаткової заробітної плати персоналу, зайнятого експлуатацією об'єкта:

     (4.14)

де Кнакл – коефіцієнт, що визначає величину накладних витрат.

У нашому випадку накладні витрати становлять:

Знакл =(4800 + 480) × 0,8 = 4224 (грн.)

  1.   Розрахунок інших комерційних витрат

Інші  комерційні  витрати  можуть  становити 1 – 5 % від   суми  всіх поточних витрат:

   (4.15)

де  Кпр – коефіцієнт, що визначає величину інших витрат.

З пр =(7286 + 900 +  4224)×0.05= 580 грн.

  1.   Розрахунок поточних витрат

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

  1.  витрати  на  оплату  праці персоналу, зайнятого  експлуатацією «продукту» проекту, грн.;
  2.   витрати на функціонування проектованого об'єкта (витрати машинного  часу, матеріальні витрати), грн.;
  3.  накладні витрати в умовах експлуатації, грн.;
  4.   інші витрати.

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

Для базового варіанту Ч = 2, річний фонд оплати праці розраховується за умови, що 1 фахівець працює 12 місяців з оплатою 3500,00 грн./міс:

(грн.).

Для проектного варіанту Ч = 2, річний фонд оплати праці розраховується за умови, що 1 фахівець працює 12 місяців з оплатою 3500,00 грн./міс.Заробітня плата зросла , а час виконання цієї роботи  зменшився навпіл.

(грн.).

За формулою (6.8) значення фонду додаткової заробітної плати складає:

(грн.);

За формулою (6.9) нарахування на соціальне страхування складає:

(грн.);

(грн.).

Сумуючи значення витрат (формула 6.10) на заробітню плату отримуємо:

(грн.);

(грн.).

За формулою (6.11) розраховуємо вартість машиного часу:

(грн.);

(грн.).

За  формулою  4.11  проводимо  розрахунок    матеріальних   витрат (таблиця 4.2) для базового та проектованого варіантів. Отже загальні матеріальні витрати для базового та проектованого варіантів становлять =3600,00грн.

Сумуючи значення матеріальних витрат та витрат машинного часу отримуємо витрати на функціонування системи:

(грн.);

(грн.).

Накладні витрати становлять 90% від основної та додаткової заробітньої плати. За формулою 4.12 обчислюємо накладні витрати:

(грн.);

(грн.).

Інші комерційні витрати становлять 2 % від суми всіх поточних витрат (формула 6.14):

     (4.14)

де – коефіцієнт, що визначає величину інших витрат.

У нашому випадку маємо:

(грн.)

(грн.)

У підсумку можна визначити поточні витрати (формула 3.15) для базового Рб та проектованого варіантів Рп:

.       (4.16)

(грн.)

(грн.)

  1.   Розрахунок показників економічної ефективності проекту

Приймаючи ∆П рівним 8000 грн. за формулою 4.2 обчислюємо річну економію:

Еріч = (220393,00 - 160833,00) + 8000 = 67560,00 (грн.)

За формулою  4.1 обчислюємо економічний ефект впровадження проекту:

Ео = 67560,00 – 20666× 0,3 = 61359,00 (грн.)

Коефіцієнт ефективності одноразових витрат (за формулою 4.4) складає:

Ер = 67560,00 / 20666= 3,26

Так як Ер більше ніж Ен, який дорівнює 0,9, то проект можна вважати ефективним та доцільним.

Термін окупності одноразових витрат проекту (за формулою 4.5):

20666/ 67560,00 = 0,31 (року).

  1.   Визначення вихідної ціни товару, що виникає в результаті реалізації проектного рішення

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

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

Даний метод застосовується:

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

Планується спочатку продати систему в кількості 100 копій продукту з врахуванням 30-ти відсоткової націнки від суми одноразових витрат:

Ц = 20666+ 20666× 0,3 = 26865 (грн.)

Тобто, ціна проектного рішення дорівнює 26865 грн. (за 100 копій). В перерахунку на одну копію система коштуватиме 269 грн.

  1.   Висновки з економічного розділу

У результаті, провівши розрахунки, були одержані наступні результати:

ціна розробленого проекту складає 26865 грн. (за 100 екземплярів) при його трудомісткості 100 люд./дн., при цьому одноразові та поточні (проектні) витрати відповідно складають 160833  грн. та 220039 грн., проте річна економія складає 88077,48 грн. і витрати на розробку проекту окупляться приблизно за 16,48 місяців. Можна зробити висновок, що впровадження проекту є економічно доцільним.

Зведемо всі отримані результати у таблицю 4.4

Таблиця 4.4 – Основні техніко-економічні показники проекту

Найменування показника

Умовні позначки

Одиниця виміру

Значення показника

Результати проекту (обсяг реалізації робіт, послуг)

проектні

n

шт.

100

Трудомісткість проекту

Т

люд./дн.

100

Ціна проектного рішення (продукту)

Ц

грн.

26865

Одноразові витрати

Kn

грн.

20666

Поточні витрати

базові

Рб

грн.

160833

проектні

Рп

грн.

220039

Річна економія

Еріч

грн.

67560

Річний економічний ефект

Ео

грн.

61359

Коефіцієнт економічної ефективності одноразових витрат

Ер

3,26

Термін окупності одноразових витрат

рік

0,31

 

  1.  ОХОРОНА ПРАЦІ ТА БЕЗБЕКА У НАДЗВИЧАЙНИХ СИТУАЦІЯХ

  1.  
    1.  Обґрунтування вибору об’єкта.

Головною частиною даної дипломної роботи є розробка мультиагентної системи «Щоденник» Тому,  що це відповідно припускає використання ПЕОМ, то як об’єкт дослідження виберемо умови праці в лабораторії обчислювального центра, що складається з ПЕОМ і автоматизованого місця робітника.

Стисла характеристика об’єкта дослідження: приміщення 20м2 з двома вікнами 2 на 2,5 м обладнане спліт-системою LG, штучним освітленням: 4 світильника по 4 лампи потужністю 30 Вт, опалення здійснюється батареями центрального опалення.

Категорія приміщення 1А. Робота оператора ЕОМ відноситься до категорії «легка 1А».

  1.  Аналіз небезпечних і шкідливих виробничих факторів і розробка заходів, спрямованих на усунення чи зниження шкідливого впливу виявлених факторів

  1.   Повітря робочої зони

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

– підвищена запиленість повітря робочої зони;

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

– підвищена чи знижена вологість.

Причини виникнення вищевказаних факторів:

– запилення із зовнішнього середовища;

– поломка вентилятора (джерело: корпус ПЕОМ);

– недостатнє кондиціонування чи вентиляція.

Нормування проводиться згідно СНиП №4086–86 «Санитарные нормы микроклимата производственных помещений».

Для ліквідації недоліків повітря робочої зони згідно СНиП 2.04.05 – 91 використовується сучасна спліт-система кондиціонування фірми LG, яка забезпечує фільтрацію підвищеної запиленості повітря робочої зони, також регулювання температури поверхні чи встаткування матеріалів і регулювання вологості.

Приміщення провітрюється припливно-витяжною вентиляцією. Опалення забезпечується батареями центрального опалення.

  1.   Мікрокліматичні параметри

Дана лабораторія, де виконується дипломна робота, відноситься до категорії приміщення 1А.

Робота оператора ЕОМ відноситься до категорії «легка 1А», робоче місце постійне. Мікрокліматичні параметри нормуються для холодного та теплого періодів року.

Таблиця 5.1 – Припустимі й оптимальні параметри для теплого і холодного періоду року у приміщенні

Найменування параметра

Період року

Холодний

Теплий

оптимальне

припустиме

оптимальне

припустиме

Температура

22

21

23

22

  Відносна вологість, %

40

75

40

75

Швидкість руху        повітря, м/с

0,1

0,1

0,1

0,1

Нормування проводиться згідно ГОСТ 12.1.005–88 «Общие санитарно-гигиенические требования к воздуху рабочей зоны».

Для ліквідації недоліків повітря робочої зони згідно СНиП 2.04.05 – 91 використовується сучасна спліт-система кондиціонування фірми LG А07LHB, яка забезпечує фільтрацію підвищеної запиленості повітря робочої зони, також регулювання температури поверхні чи устаткування матеріалів і регулювання вологості.

Встановлена спліт-система LG А07LHB має наступні технічні характеристики:

  •  продуктивність:
  1.  охолодження (БТЕ/ч): 7,000;
  2.  обігрів (БТЕ/ч): 7,300.
  •  електричні параметри:
  1.  напруга, частота, фази (В, Гц, ф): 220~240,50/1
  •  технічні параметри:
  •  рівень шуму (Внутр./Зовн.) (дб(А), выс.ск, 1м): 32/45
  •  діапазон температур (Охолодження): 18 - 30
  •  діапазон температур (Обігрів): 16 - 30

У даній лабораторії згідно технічним вимірюванням температура повітря 20оС, вологість повітря 40%, швидкість руху повітря 0,1 м/с.

  1.   Шум

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

Нормування виробляється згідно ГОСТ 12.1.003–83 «Шум. Общие требования безопасности».

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

Рівень звукового тиску в дБ в октавних смугах з середньо геометричними частотами, Гц

Рівень звуку й еквівалентні рівні звуку, дБА

63

25

250

500

1000

2000

4000

8000

71

61

54

49

45

42

40

38

50

79

2

54

50

46

43

40

38

52

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

Для захисту від зовнішнього шуму застосовуються п’ятикамерні металопластикові вікна виробництва німецької фірми «REHAU».

Нормування виробляється згідно ГОСТ 12.1.003-83 «Шум. Общие требования безопасности».

  1.  Освітлення

Небезпечними й шкідливими факторами є:

– відсутність чи недостатність природного освітлення;

– недостатня освітленість робочої зони;

– пряме чи відбите світло.

Причини виникнення вищевказаних факторів:

– відсутність чи недостатні розміри вікон;

– відсутність чи недостатня кількість світильників

– недоліки освітлення і або неправильне розташування дисплея.

Розмір пікселя залежить від класу монітора. У даному випадку використовується монітор SVGA з розміром пікселя 0,234 мм.

Пікселем на екрані монітора є крапка розміром 0,24 х 0,24 мм. Фон, з яким працює користувач, має чорний, білий, або зелений колір, колір символів коливається від чисто білого до чорного, включаючи всі можливі кольори, однак вибір залежить від працюючого на ЕОМ. Контраст і чіткість зображення можна регулювати, не втручаючись в програму, для чого необхідно скористатися регулюванням на моніторі.

Нормування природного освітлення проводиться згідно СНиП–II–4–79 «Естественное и исскуственное освещение»:

Таблиця 5.3 – Нормування природного освітлення

Розмір пікселя

Розряд зорової роботи

Коефіцієнт природного висвітлення при бічному освітленні

0,24x0,24

5

0,6

Нормування штучного освітлення здійснюється згідно СНиП–II–4–79«Естественное и исскуственное освещение»:

Таблиця 5.4 – Нормування штучного освітлення

Найменший розмір об'єкта дозволу

Розряд зорової роботи

Підрозряд

Контраст із фоном

Фон

Штучне висвітлення при комбінованому висвітленні, лк

0,24 – 0,24

5

а

малий

темний

300

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

Для ліквідації недоліків освітлення використовуються 4 світильника по 4 лампи ЛД 30 потужністю 30 Вт.

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

Для покращення освітлення застосовують газорозрядні лампи.

Припустима пульсація освітленості для здійснення зорових робіт складає10 %. Пульсація дисплею перевищує припустиме значення в 2 – 2,5 рази.

З метою створення комфортних умов праці для кожного з працюючих підбирають висоту і кут нахилу клавіатури і дисплея. Встановлюються 15-ти хвилинні перерви кожні 1 – 2 години роботи. Ці заходи проводяться для зменшення стомлюваності людини, що працює на ПЕОМ.

Нормування штучного й природного висвітлення здійснюється згідно СНиП-II-4-79 «Естественное и исскуственное освещение».

  1.   Вібрація

Причинами виникнення вібрації є: вентиляція, периферійні пристрої, комплектуючі пристрої комп’ютера. Робота оператора ЕОМ відноситься до категорії 3 тип «у».

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

Нормування виробляється згідно ГОСТ 12.1.012–90 «Вибрационная безопасность. Общие требования».

Таблиця 5.5 – Рівень вібрації

Средньогеометрична частота смуг

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

Заводоуправління, конструкторське бюро, лабораторії і навчальні приміщення, ОЦ

м/ с2

1/1окт

дБ

1/1окт

м/ с2

1/1окт

дБ

1/1окт

1,6

2,0

0,02

86

0,18

91

2,5

3,15

4,0

0,014

83

0,063

82

5,0

6,3

8,0

0,014

83

0,032

75

10,0

12,5

Продовження Таблиці 5.5

Средньогеометрична частота смуг

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

Заводоуправління, конструкторське бюро, лабораторії і навчальні приміщення, ОЦ

16,0

0,028

89

0,028

75

20,0

25,0

31,5

0,056

95

0,028

75

40,0

50,0

63,0

0,112

101

0,032

75

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

Нормування виробляється згідно ГОСТ 12.1.012-90 «Вибрационная безопасность. Общие требования».

  1.   Електромагнітне випромінювання

У лабораторії присутні наступні джерела електромагнітного випромінювання: дисплей і трансформатор. Нормується за ГОСТ 12.1.006–84 «Электромагнитные поля радиочастот. Допустимые уровни на рабочих местах и требования к проведению контроля» і за ГОСТ 12.1.002–84 «Электрические поля промышленной частоты. Допустимые уровни напряженности и требования к проведению контроля на рабочих местах». При інтенсивному і тривалому характері випромінювання можуть виникнути злоякісні пухлини, катаракти. Незважаючи на це гігієнічних норм для персоналу, що систематично піддається ЕМП інфрачервоних частот, не існує.

Дисплейні монітори являють собою джерела інтенсивних електромагнітних полів і інфрачервоних частот. У більшості моніторів магнітне поле поблизу трансформатора рядкового розгорнення монітора складає приблизно 70,5 А/м; напруженість полю частотою 50 Гц на відстані 30 см від екрана близька до 15 А/м, на відстані 50 см – 8 А/м.

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

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

Нормується за ГОСТ 12.1.002-84 «Электрические поля промышленной частоты. Допустимые уровни напряженности и требования к проведению контроля на рабочих местах» і за ГОСТ 12.1.006 – 84 «Электромагнитные поля радиочастот. Допустимые уровни на рабочих местах и требования к проведению контроля».

Для захисту від впливів ЕМП інфрачервоних частот необхідно проводити наступні заходи:

– застосування рідкокристалічних моніторів.

– віддалення робочого місця від джерела ЕМП. Якщо на відстані 10 см від екрану монітора напруженість магнітного поля дорівнює 40 – 190 А/м, то на відстані 70 см від екрану – не більш 8 А/м. Користувачам, що бажають знизити рівень опромінення, варто розташуватися так, щоб відстань до екрану монітора складала величину, рівну довжині витягнутої руки;

– устаткування розміщують на відстані не менш 1,2 м від бічних і задніх стінок інших моніторів;

– захист часом; необхідно проводити за монітором не більш 4 годин на добу і не більш 20 годин на тиждень;

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

Нормується за ГОСТ 12.1.002–84 «Электрические поля промышленной частоты. Допустимые уровни напряженности и требования к проведению контроля на рабочих местах» і за ГОСТ 12.1.006–84 «Электромагнитные поля радиочастот. Допустимые уровни на рабочих местах и требования к проведению контроля».

  1.   Електробезпека

Причинами появи небезпечних факторів є:

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

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

Таблиця 5.6 – Проходження електричного струму крізь Людину

Частота струму

Струм, що проходить крізь людину, мА

відчутний струм,

не більше 10 хв.

неприпустимий струм,

не більше 3 хв.

50 Гц

0,6

4

У приміщенні використовується контурне заземлення устаткування згідно до вимог ГОСТ 12.1.030-81 «Электробезопасность.Защитное заземление, зануление»

Нормування проводиться згідно ГОСТ 12.1.019–79 «Электробезопасность. Общие требования и номенклатура видов защиты».

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

Нормується за ГОСТ 12.1.019–79 «Электробезопасность. Общие требования и номенклатура видов защит».

  1.   Пожежна безпека

Згідно ГОСТ 12.1.004–91 «Пожарная безопасность. Общие требования» приміщення з ПК відносяться до категорії пожежної небезпеки Д (приміщення з негорючими речовинами і матеріалами в холодному стані).

Нормується згідно ГОСТ 12.1.004–91 «Пожарная безопасность. Общие требования».

Для забезпечення пожежної безпеки роблять наступні заходи:

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

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

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

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

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

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

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

Нормування виробляється згідно ГОСТ 12.1.004–91 «Пожарная безопасность. Общие требования».

  1.   Розрахунок звукоізоляції і звукопоглинання

В ізольованому приміщенні працює вентиляційна установка з рівнем звукового тиску =105 дБА. Стіни приміщення товщиною у дві цеглини (52 см). Поверхнева щільність цегляної кладки товщиною 1 м становить1640 кг/м2. Визначимо можливе використання суміжного приміщення за нормами «ГОСТ 12.1.003–88».

  1.  Маса 1 м2 стіни:

(кг/м2).

  1.  звукоізолююча здатність однорідної цегляної стіни:

(дБА).

  1.  рівень звукового тиску безпосередньо за стіною у суміжному приміщенні:

(дБА).

  1.  порівнюючи  з нормованими значеннями рівня звуку у дБА (таблиця 3.1), визначаємо, що суміжне приміщення може бути використаним навіть для робочої кімнати управління.

Визначимо оптимальну ширину зазору між звукопоглинаючими перфорованими панелями і стіною, щоб забезпечити умову максимального звукопоглинання. Частота шуму джерела коливань =600 Гц, рівень шуму =87 дБА, швидкість звуку в повітрі =340 м/с, товщина звукопоглинаючого шару =6 см. Визначити також ефективність звукоізоляції при масі одиниці площі: панелі =10 кг/м2, стіни – =420 кг/м2.

а) Оптимальна величина зазору:

(м).

б) Рівень шуму за стіною (ефективність звукоізоляції):

(дБА).

Визначимо рівень звуку біля вікон лабораторії, розташованої на відстані 120 м від компресорної установки. Рівень звуку на відстані 1 м приміщення від компресорної установки становить 90 дБА.

Рівень звуку біля будинку за формулою для відстані більше 30 м:

 

  1.  Розрахунок сумарного рівня кількох джерел шуму

У лабораторії одночасно працюють 3 комп’ютери, рівень звуку яких у розрахунковій точці становить: 50, 52, 51 дБА. Визначимо сумарний загальний рівень звуку.

Сумарний рівень визначаємо за формулою енергетичного складання, користуючись спрощеним методом зведення у степінь:

(дБА)

Або інакше:

  1.  різниця двох більших рівнів:  (дБА).
  2.  додаток для різниці у 4 дБА за таблицею 5.3 становить 5,5 дБА.
  3.  сума двох рівнів за формулою (3.8):  (дБА).
  4.  різниця між сумарним рівнем звуку від двох машин і рівнем звуку від третьої машини: 54,5−50=4,5(дБА).
  5.  додаток для різниці у 4,5 дБА дорівнює 1,35.
  6.  сума рівнів звуку трьох машин:55,5+1,35=55,85 (дБА).

  1.   Розрахунок еквівалентного рівня шуму

У виробничому приміщенні протягом 8-годинної робочої зміни рівень звуку  становив: 50, 57, 53, 50 дБА тривалістю відповідно інтервалами часу : 1, 2, 1, 4 год. Допустимий рівень звуку =66 дБА. Визначити еквівалентний рівень звуку і зіставити його з допустимим.

  1.  Еквівалентний рівень звук (дБА) за формулою:

(дБА).

  1.  розрахований еквівалентний рівень звуку:

=71 дБА>=66 дБА.

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

  1.  Перевіряємо дотримання умови :

;

8<9 – умова дотримана.

  1.  За формулою (3.10) отримаємо:

  1.  =63,1 (год.), тобто установка може працювати протягом усієї зміни.

  1.  Розрахунок потрібного зниження рівня шуму

У приміщенні одночасно працюють 3 комп’ютери, рівень шуму від яких у розрахунковій точці становить (дБА): 50, 52, 51. Визначимо потрібне зниження рівня шуму для кожного з джерел шуму з тим, щоб загальний їх рівень не перевищував =66 дБА.

Розв’язання представимо у формі таблиці.

Для джерел шуму «1» і «2» , тому ;

;  для «1» і «2» джерел:16>8; 14>8, тому не враховуються два джерела, приймаються до розрахунку: =3–2=1 джерело; .

Знаходимо потрібне зниження шуму для кожного джерела за формулою:

та заносимо отримані значення до зведеної таблиці.

В останній колонці таблиці отримаємо значення знижених рівнів шуму кожного з комп’ютерів:

Таблиця 5.7 – Зведена таблиця розрахунки до прикладу

Джерело шуму

1

50

16

16

2

52

14

14

Висновок: загальний рівень шуму після відповідного зниження рівнів шуму кожного з комп’ютерів не буде перевищувати допустимого.

  1.  Поводження в надзвичайних ситуаціях при повенях

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

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

У разі руйнування гідроспоруди утворюється хвиля прориву, коли вода поширюється з великою швидкістю (3–25 км/год), висота хвилі становить 10–20 м, виникає катастрофічне затоплення значної території за малий час.

На території України можливі катастрофічні затоплення зі зруйнуванням гребель, дамб, водопропускних споруд на 12 гідровузлах та 16 водосховищах річок Дніпро, Дністер, Сіверський Донець, Південний Буг. Площа затоплення може сягнути 8294 км2, у зону затоплення потрапляють 536 населених пунктів та 470 промислових підприємств.

У разі руйнування гребель гідроспоруд Дніпровського каскаду територія можливого затоплення становитиме 700 тис. га з населенням майже 1,5 млн осіб, буде виведено з ладу 270 промислових підприємств, 14 електростанцій, 2000 км ліній водного та газового постачання багатьох населених пунктів.

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

Якими ж повинні бути дії населення під час повеней?

  1.  слід навчитися прогнозувати можливі повені, щоб бути готовими до їхнього виникнення. За кілька місяців можна прогнозувати ті повені, що викликаються весняними, літніми й осінніми паводками. Нагінні повені можна передбачити за кілька годин.
  2.  якщо населення було завчасно попереджене про повінь, то слід побудувати на ріках і в інших місцях передбачуваної повені відповідні гідротехнічні споруди Також необхідно вживати заходів щодо підготовки й проведення завчасної евакуації населення і сільськогосподарських тварин, вивезення матеріальних цінностей з районів можливого затоплення.
  3.  комісія з боротьби з повінню зобов'язана оголосити про евакуацію у випадку повені. Населення оповіщають по місцевому телебаченню й радіо. Людей на службі й виробництві оповіщають через адміністрацію підприємств І установ Населенню розповідають про збірні евакопункти, обговорюються терміни збору, маршрути проходження й інші відомості.
  4.  якщо в населення достатньо часу для евакуації, то можливою є й евакуація майна.
  5.  Люди евакуюються в прилеглі населені пункти, що знаходяться поза зонами затоплення. Розселяють населення в громадських будинках або на житловій площі місцевих жителів.
  6.  на підприємствах і в установах при загрозі затоплення змінюється режим-роботи, а в деяких випадках робота припиняється. Захист певної частини матеріальних цінностей іноді передбачається на місці, для чого закладаються приямки, входи І віконні отвори підвалів і нижніх поверхів будинків.
  7.  у зоні можливого затоплення тимчасово припиняють роботу школи І дошкільні установи: дітей переводять у школи й установи в безпечних місцях.
  8.  якщо повені трапляються зненацька, то оповіщення населення здійснюється будь-якими засобами оповіщення, у тому числі й за допомогою гучномовців.
  9.  раптові повені вимагають особливих дій населення. Під час піднімання води людям, що живуть на перших поверхах будинків, необхідно покинути квартири і піднятися на верхні поверхи. Якщо ж вони проживають в одноповерховому будинку, то слід піднятися на горище.
  10.  людей, що зникли на затопленій території, необхідно відразу ж починати розшукувати. Для цього потрібно залучити екіпажі плаваючих засобів формувань цивільної оборони і всі інші наявні сили й засоби. Ті, кого рятують, зобов'язані виявляти витримку й самовладання, виконуючи усі вимоги рятувальників. У жодному разі не рекомендується переповнювати рятувальні засоби (катери, човни, плоти і т. п.). Це може викликати затоплення і врятованих, і рятувальників. Опинившись у воді, необхідно скинути із себе важкий одяг і взуття, відшукати поблизу предмети, що плавають або стирчать над водою, І скористатися ними до отримання допомоги.
  11.  обстановка в районі повені може різко ускладнитися в результаті руйнування гідротехнічних споруд. У цьому випадку проводяться роботи з метою підвищити захисні властивості існуючих дамб, гребель І насипів; запобігти або ліквідувати підмив водою земляних споруджень і наростити їхню висоту.
  12.  боротьба з повінню в період льодоходу включає усунення заторів, що утворюються на ріках.

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

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

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

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

ВИСНОВКИ

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

Програма, готова до використання й не вимагає додаткової адаптації й налаштування. Система у тестуванні показала себе дуже швидкою та малогабаритною. В оперативній пам’яті вона займає лише 1152 Кб та 29,1 Кб система займає на диску постійної пам’яті. Також було проведене тестування на швидкість запуску системи, вона становить 0,97 секунди, що удвічі перевищує швидкість запуску аналогу Outlook. Виграш в швидкості, та пам’яті дає обрано мова програмування Java.  У системі передбачена можливість призначення зустрічі з користувачем такої самої системи. Цього дуло досягнуто завдяки використанню мультиагентної технології, яка дозволяє приховати таємну інформацію, та автоматизувати процес призначення зустрічі. Усього декілька кроків і оформлення зустрічі готове.


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

1. Фарафонов В.П. Программирование баз данніх в Java / Фарафонов В.П. – М.: Тритон, 2005. – с.173.

2. Кандзюба С.П. «Базы данных и приложения» / Кандзюба С.П., Громов В.Н. – Наукові праці ДонДТУ. – Донецк.: – 2002. – випуск 38. – С.110-114.

3. Проектирование клиент-серверных информационных систем [Електронний ресурс] / Портал магістрів ДонНТУ — стаття. — Режим доступу: http://masters.donntu.edu.ua/2008/fvti/reznichenko/library/article02.htm

4. Тимоти Бадд – Объектно-Ориентированное Программирование − 2005-296с.

5. Wikipedia − Відкрита енциклопедія [Електронний ресурс] / Інтернет енциклопедія. − Режим доступу: http://ru.wikipedia.org/wiki.

6.Кунгурцев О.Б. Об'єктно-орієнтована технологія створення програмних продуктів. / Кунгурцев О.Б. − Одеса: BMB, 2006. −182 с.

12. Малахов Є.В. Методичні рекомендації для студентів усіх спеціальностей денної та заочної форм навчання Інституту комп'ютерних систем. / Малахов Є.В., Погорецька В.Я., Чугунов А.А. та ін. - Одеса: Наука і техніка, 2008. - 24с

13. Йохна В.А. Економіка і організація інноваційної діяльності. / Йохна В.А., Стадник В.В. - Навч. посіб. - К.: Академія, 2005

14. ГОСТ ССБТ 12.1.005-88. Загальні санітарно-гігієнічні вимоги до повітря робочої зони

15.СНіП ІІІ-7-79. Оптимальні і допустимі параметри для холодного і теплого періодів року

16. ГОСТ 12.1.003-83. Шум. Загальні вимоги до безпеки

17. ГОСТ 12.1.006-84. Електромагнітні поля радіочастот. Допустимі рівні на робочих місцях і вимоги до проведення контролю

18. ГОСТ 12.1.033-81. Пожежна безпека

19. СНіП 2.04.05-91. Опалювання, вентиляція і кондиціонування повітря

20. ГОСТ 12.1.005-88. Загальні санітарно-гігієнічні вимоги до повітря робочої зони.



 

А также другие работы, которые могут Вас заинтересовать

30931. Проектирование информационных систем (ИС) CASE средствами 638.5 KB
  Современные крупные проекты ИС характеризуются как правило следующими особенностями: сложность описания достаточно большое количество функций процессов элементов данных и сложные взаимосвязи между ними требующая тщательного моделирования и анализа данных и процессов; наличие совокупности тесно взаимодействующих компонентов подсистем имеющих свои локальные задачи и цели функционирования например традиционных приложений связанных с обработкой транзакций и решением регламентных задач и приложений аналитической обработки...
30932. Філософія та соціологія 410 KB
  Комунікативна повсякденна практика, навколо якої утворюється життєвий світ, забезпечується спільною грою культурного відтворення, соціальної інтеграції та соціалізації, яка в цій практиці укорінена. Життєвий світ як результат соціалізації, тобто структурованості суспільними і культурними зв’язками.
30933. Проектная деятельность на уроке английского 25.65 KB
  Проектная методика позволяет вести индивидуальную работу над темой которая вызывает наибольший интерес у каждого участника проекта что несомненно влечет за собой повышенную мотивированную активность учащегося. В основе проекта лежит какаято проблема. Структурирование содержательной части проекта; 5. Предполагает собой наличие выходной информации по данному проекту причем результат данной деятельности может быть различным в зависимости от индивидуальных возможностей или способностей участников проекта.
30934. Основы общей теории перевода (ЛИНГВИСТИЧЕСКИЕ ПРОБЛЕМЫ) 2.06 MB
  Перевод общественно-политической литературы на материале переводов с немецкого, английского, французского, отчасти испанского языков на русский. Основы общей теории перевода (лингвистические проблемы) на тех же материалах...
30935. ПСИХОЛОГО-ПЕДАГОГИЧЕСКАЯ ХАРАКТЕРИСТИКА ДЕТЕЙ С НАРУШЕНИЕМ ЗРЕНИЯ 318 KB
  ПЛАКСИНА ПСИХОЛОГОПЕДАГОГИЧЕСКАЯ ХАРАКТЕРИСТИКА ДЕТЕЙС НАРУШЕНИЕМ ЗРЕНИЯ Учебное пособие М. Психологопедагогическая характеристика детей с нарушением зрения. Ребенок с нарушением зрения как предмет изучения тифлопедагогики. Если общая педагогика рассматривает само понятие и развитие личности то тифлопедагогика как составная часть общей педагогики занимается рассмотрением личности имеющей нарушение зрения.
30936. Административное право. Государственное управление как объект административно-правового регулирования 1.07 MB
  В систему федеральных органов исполнительной власти входят федеральные министерства федеральные службы и федеральные агентства. В этих целях федеральный министр осуществляет следующие функции: утверждает ежегодный план и показатели деятельности федеральных служб и федеральных агентств а также отчет об их исполнении; вносит в Правительство Российской Федерации по представлению руководителя федеральной службы федерального агентства проект положения о федеральной службе федеральном агентстве предложения о предельной штатной численности...
30937. Сельскохозяйственное производство 100.45 KB
  Рассматривая организацию производства надо иметь в виду что во всех отраслях народного хозяйства кроме сельского хозяйства процесс производства продукции связан с превращением потенциальной в кинетическую энергию в работу. Время производства сельскохозяйственной продукции определяется главным образом естественными условиями роста развития и размножения растений и животных. Несовпадение времени производства сельскохозяйственной продукции с рабочим временем приводит к сезонности сельскохозяйственного труда и необходимости во многих...
30938. Лекарственные растения 1.31 MB
  Чай из аира: 2 чайные ложки примерно 3 г мелко нарезанного очищенного от коры корневища аира заливают 1 4 л кипящей воды и настаивают примерно 15 минут. После процеживания чай нужно пить тепловатым. Сверх того чай из корневища аира используют как моющее средство против кожных сыпей и перхоти. В результате чай из корня алтея с успехом применяют при болях в желудке и кишечнике а также при поносе.
30939. АНАЛИЗ ХОЗЯЙСТВЕННОЙ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ 3.17 MB
  Принятию всякого решения финансового характера предшествуют аналитические расчеты, поэтому практически любой представитель аппарата управления предприятием - от топ-менеджеров до рядовых специалистов (бухгалтер, финансовый менеджер, экономист) - просто обязан быть хорошим аналитиком. Очевидно, что анализ, являющийся одной из составных частей грамотного управления финансами, должен выполняться не только в ретроспективе, но и, что нередко более важно, в перспективе.