Графічний інтерфейс користувача реалізований з використанням форм Microsoft Access. Форми - це об'єкти, в які розташовуються інші об'єкти для створення призначеного для користувача інтерфейсу будь-якого додатку. Модулі складаються з коду, який реалізує функціонування додатку, обробники подій для форм і їх компонент.
В програмі присутні 2 форми, «Пошук», і «Бібліографічні дані», що наведені на рис. 6.2
Рисунок 6.2 – Форма «Бібліографічні дані»
Форма «Пошук», містить поля (критерії), за якими оператор виконує пошук потрібних йому заявок. Форма «Пошук» показана на рисунку 6.3
Рисунок 6.3 – Форма «Пошук»
Були створені запити, за якими оператор веде пошук потрібних йому заявок:
- Знайти заявку за “датою подачі”
- Знайти заявку за “датою публікації”
- Знайти заявку за “номером публікації”
- Знайти заявку за “регістраційним номером”
- Знайти заявку за “назвою”
- Знайти заявку за “МПК”
6.2 Опис функціональності програмного приложення
6.2.1 Діаграма варіантів використання
Для опису функціональних можливостей даного програмного забезпечення використовується діаграма варіантів використання (діаграма прецедентів) мови UML і текстовий опис прецедентів. Діаграма варіантів використання, що представлена на мал. 6.4, показує взаємодію оператора із системою у процесі перегляду заявок на корисну модель.
Рисунок 6.4 – Діаграма варіантів використання
Дана діаграма є вихідним концептуальним представленням або концептуальною моделлю системи в процесі просмотру заявок на корисну модель.
6.2.2 Опис прецедентів
6.2.2.1 Потік подій для прецеденту «Введення інформації»
1. Передумова. Оператор вибрав режим «Введення інформації»
2.Головний потік. Система відображає діалогове вікно, що містить меню для вибору режиму роботи оператора – добавлення інформації, редактування (правка) інформації, видалення інформації. Оператор дає запит на потрібну йому дію. Система відкриває потрібний операторові запит. Оператор виконує потрібні йому дії. Після закінчення роботи оператор дає запит на закінчення роботи. Система зберігає нову інформацію. Прецедент завершується.
2.1 Подпотік “Додання інформації о заявке”.
Система відображає діалогове вікно, що містить запит “Додання інформації о заявке” та “Вихід”. Оператор дає запит на потрібну йому дію. Система відкриває потрібний операторові запит. Оператор виконує потрібні йомудії. Після закінчення роботи оператор дає запит на закінчення роботи. Система зберігає нову інформацію. Прецедент завершується.
2.2 Подпотік “Правка інформації”.
Система відображає діалогове вікно, що містить запит “Правка інформації” та “Вихід”. Оператор дає запит на потрібну йому дію. Система відкриває потрібний операторові запит. Оператор виконує потрібні йомудії. Після закінчення роботи оператор дає запит на закінчення роботи. Система зберігає нову інформацію. Прецедент завершується.
2.2 Подпотік “Видалення інформації о заявке”.
Система відображає діалогове вікно, що містить запит “Видалення інформації о заявке” та “Вихід”. Оператор дає запит на потрібну йому дію. Система відкриває потрібний операторові запит. Оператор виконує потрібні йомудії. Після закінчення роботи оператор дає запит на закінчення роботи. Система зберігає нову інформацію. Прецедент завершується.
6.2.2.2 Потік подій для прецеденту «Перегляд інформації»
1.Передумова. Оператор вибрав режим « Перегляд інформації ».
2.Головний потік. Система відображає діалогове вікно, що містить меню вибору. Користувач вибирає необхідний фільтр. Система фільтрує зображення і надає користувачу. При необхідності користувач запитує інший фільтр. Після закінчення роботи користувач дає запит на закінчення роботи з зображенням. Система зберігає зображення. Прецедент завершується.
6.2.2.3 Потік подій для прецеденту «Друк»
1.Передумова. Оператор вибрав режим «Друк».
2.Головний потік. Користувач дає запит на друк заявки на корисну модель. Система видає оператору параметри друку і запитує дію. Оператор вибирає необхідні параметри. Система роздруковує інформацію о заявке. Оператор дає запит на закінчення роботи. Прецедент завершується.
6.3 Рекомендації до розробки бази даних
Основні відомості
Додаток Microsoft Access 97/2000 (далі Access) є потужною й високопродуктивною 32-розрядною системою керування реляционной базою даних (далі СУБД).
Системні вимоги пропоновані СУБД Access
· Intel 486DX2 – 66 +
· Windows 98/2000/XP або Windows NT (версія не нижче 4.51)
· Не меньш 64 Мб оперативної пам'яті (для спільної роботи з іншими додатками не менш 128 Мб)
· Близько 300 Мб дискового простору (тільки для Access і нових баз даних).
· СУБД розробляються з метою забезпечення ефективної обробки більших обсягів інформації.
· СУБД може легко зв'язувати будь-яка кількість таблиць так, що для користувача вони будуть представлятися однією таблицею. Реалізувати таку можливість в електронних таблицях практично неможливо.
· СУБД мінімізують загальний обсяг бази даних. Для цього таблиці, що містять повторювані дані, розбиваються на кілька зв'язаних таблиць.
Як реляційна СУБД Access забезпечує доступ до всіх типів даних і дозволяє одночасно використати кілька таблиць бази даних. Працюючи в середовищі Microsoft Office, користувач одержує у своє розпорядження повністю сумісні з Access текстові документи (Word), електронні таблиці (Excel), презентації (PowerPoint). За допомогою нових розширень для Internet можна прямо взаємодіяти з даними з World Wide Web і транслювати подання даних мовою HTML, забезпечуючи роботу з такими додатками як Internet Explorer і Netscape Navigator.
Access спеціально спроектований для створення многопользовательских додатків, де файли бази даних є поділюваними ресурсами в мережі. База даних зберігатися в одному файлі, але професійні користувачі воліють розділяти базу даних на два файли: в одному зберігаються об'єкти даних (таблиці, запити), в іншому об'єкти додатка (форми, звіти, макроси, модулі).
В Access реалізована надійна система захисту від несанкціонованого доступу до файлів.
Висновки по розділу
У даному розділі дипломної роботи був розроблен проект бази даних для документів заявки. Функціональні можливості проекту представлені у виді діаграми варіантів використання із описом прецедентів, що демонструє взаємодію оператора із системою в процесі роботи з інформацією про заявки. Архітектурна частина представлена у виді таблиць, що ілюструють загальну архітектурну схему проекту бази даних для роботи з інформацією про заявках.
Запропонована модель повинна бути уточнена на етапі проектування.
7. ВИЗНАЧЕННЯ РОЗМІРУ ВИНАГОРОДИ АВТОРАМ ЗА СТВОРЕННЯ І ВИКОРИСТАННЯ КОРИСНОЇ МОДЕЛІ
7.1 Нормативне регулювання виплати авторської винагороди
Виплата винагороди авторам об’єктів промислової власності проводиться відповідно до Закону України “Про охорону прав на винаходи та корисні моделі”, “Тимчасового положення про охорону об´єктів промислової власності та раціоналізаторських пропозицій в Україні” №479/92, а також відповідно з “Медодичними рекомендаціями по виплаті винагороди авторам об´єктів промислової власності”, ухваленими Методичною радою Держпатента України 07.08.1997р.
Згідно з пунктом 1 статті 9 Закону України “Про охорону прав на винаходи та корисні моделі” роботодавець використовує право на отримання патенту на об´єкт промислової власності (ОПВ), а його автори – на отримання винагороди. Розмір і порядок виплати винагороди за використання ОПВ визначаються умовами письмового договору між роботодавцем та авторами.
У разі, якщо автором використованого ОПВ є особа, яка не знаходиться у трудових відносинах з роботодавцем (керівник підприємства, особи, які пішли на пенсію, звільнені згідно з зкороченням штату і т.п., а також особи, які не є працівниками на період створення ОПС) стосунки між авторами та патентовласниками, використавшими ОПВ, регулюються договором про винагороду за використання ОПВ. (п. 54 “Тимчасового положення про охорону об´єктів промислової власності та раціоналізаторських пропозиціях в Україні” №479/92)
Розмір авторської винагороди за використання ОПВ визначаються умовами Договору між автором і роботодавцем.
Розрахунок прибутку від використання ОПВ і/або собівартості продукції проводиться планово – економічною службою підприємства згідно методичним рекомендаціям Держпатенту України “Визначення прибутку від використання об´єктів промислової власності”.
Порядок виплати винагороди також визначається умовами Договору між авторами і роботодавцем, але винагорода сплачується не пізніше 3-х місяців після закінчення кожного року, в якому використовувався ОПВ і не пізніше 3-х місяців після отримання виручки від продажу ліцензії протягом строку дії патенту.
Дата початку використання ОПВ і технічний об’єкт, в якому він використан, визначається “Актом про використання об’єкту промислової власності” за типовою формою №ІВ – 6.
В КП ХКБМ діє Положення про порядок виплати винагороди за створення та використання ОПВ, згідно якому для виплати авторської винагороди за використання ОПВ повинні бути представлені наступні документи:
- Патент (свідоцтво);
- Акт технічної та патентно – правової експертизи на відповідність використання технічного рішення формулі винаходу (корисної моделі);
- Акт за типовою формою №ІВ – 6;
- Договір між автором та роботодавцем про винагороду;
- Розрахунок собівартості ОПВ, прибутку, виручки від використання у власному виробництві, або від продажу ліцензії на використання ОПВ, засвідчений керівником планово – економічної служби;
- договір співавторів про вклад у створення об’єкта права інтелектуальної власності (ОПІВ) та розподіл винагороди.
7.1.1 Визначення прибутку, одержуваного від використання корисної моделі „Машина для виймання анодних штирів алюмінієвого електролізера”
Корисна модель, яка розглядається, використовується у власному виробництві. Виготовляється продукція згідно з положенням підприємства та договіром між авторами та підприємством.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
