Існуючим аналогом є програма «1С: Управління Виробничим Підприємством для України». Програма «Управління виробничим підприємством» дозволяє планування, управління та облік робіт з технічного обслуговування і ремонтів. Підсистема дозволяє вести облік різних видів технічного обслуговування, а саме:

- ведення нормативно-довідкової бази даних;

- планування обслуговування обладнання;

- облік результатів проведення ремонтів;

- підрахування вартості обладнання.

Класифікатор видів обслуговування має вигляд (див. рис 1.2.1):

Рисунок 1.2.1 - Класифікатор видів обслуговування

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

Довідник «Причини обслуговування ОС» містить причини для обслуговування обладнання, наприклад, регламентоване обслуговування, плановий ремонт і так далі (див. рис. 1.2.2).

Рисунок 1.2.2 - Причини обслуговування ОС

У довіднику «Нормативи обслуговування ОС» зберігаються нормативи на виконання робіт з ремонту та обслуговування. Передбачено кілька станів затвердження. Поточний стан фіксується в реквізиті «Стан». Після затвердження нормативу присвоюється значення «Затверджено», вказується дата затвердження (див. рис. 1.2.3).

Рисунок 1.2.3 - Нормативи обслуговування ОС

Зміст робіт вибирається з довідника «Номенклатура» в реквізиті «Обслуговування». Кількість ітерацій з обслуговування вказується в полі «Кількість». Норматив по обслуговуванню може бути або періодичним, або з вироблення. Дані нормативів використовуються при аналізі обладнання, що вимагає обслуговування, за допомогою обробки «Формування замовлень на обслуговування ОС».

Документ «Замовлення на обслуговування ОС» фіксує замовлення на обслуговування устаткування. Подальше обслуговування також може вестися за замовленнями. Замовлення оформляються вручну або за допомогою обробки «Формування замовлень на обслуговування обладнання» (див. рис. 1.2.4).

Рисунок 1.2.4 - Замовлення на обслуговування ОС

Обробка «Формування замовлень на обслуговування обладнання» використовується в підсистемі для визначення обладнання, що потребує ремонту і для генерації «Замовлення на обслуговування ОС» (див. рис. 1.2.5).

Рисунок 1.2.5 - Формування замовлень на обслуговування обладнання

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

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

Сучасні вимоги до ІС “ГППР” надає адміністрації та співробітникам унікальну можливість отримувати повну і достовірну інформацію про наявне устаткування, включаючи:

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

- облікову інформацію;

- ціни на деталі обладнання;

- терміни придатності деталей;

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

Розглянемо приклад проектування бази даних предметної області "ГППР".

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

Система бази даних буде складатися з таких таблиць;

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

1) назва цеху;

2) електронна адреса цеху;

3) назва обладнання з його характеристиками;

4) деталі обладнання з термінами придатності;

- таблиця відділу постачання:

1) деталі з терміном закінчення придатності;

2) дата прийому нової деталі;

3) кількість отриманих деталей;

- таблиця бухгалтерії:

1) куплені деталі;

2) вартість;

3) дата сплати.

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

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

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

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

- організувати систему авторизації користувачів в базі даних ІС “ГППР” (адміністрація, співробітники експлуатаційних цехів, відділ постачання, бухгалтерія);

- організувати пошук та сортування даних по найчастіше використовуваних полях;

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

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

- відстежувати термін придатності деталей обладнання;

- надсилати оповіщення на електронну адресу в певний цех та на локальний комп'ютер цеху.

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

Завершальним етапом аналізу предметної області є побудова концептуальної моделі предметної області (див рис. 1.1).

Размещено на http://www.allbest.ru/

Рисунок 1.1 - Концептуальна модель предметної області

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

2. ПРОЕКТУВАННЯ БАЗИ ДАНИХ

2.1 UML - моделювання

Більшість існуючих методів об'єктно-орієнтованого аналізу і проектування (ООАП) включають як мову моделювання, так і опис процесу моделювання. Мова моделювання - це нотація (в основному графічна), яка використовується методом для опису проектів. Нотація є сукупністю графічних об'єктів, які використовуються в моделях; вона є синтаксисом мови моделювання[4].

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

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

НАЙТИ ДИАГРАММЫ ПО ЖУРНАЛУ, вставить DFD, вставить скрипты

Рисунок 3.1 - Діаграма взаємодії груп об'єктів

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

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

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

Розглянемо діаграму взаємодії користувачів бази даних.

Діаграми взаємодії (interaction diagrams) є моделями, що описують поведінку взаємодіючих груп об'єктів.

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

Якщо користувач зайде під обліковим записом “Адміністратор”, то йому будуть доступні всі компоненти програми і всі функції.

Якщо ж користувач зайде в програму під обліковим записом “Співробітник”, то він може тільки проглядати дані про характеристики обладнання, а також виконувати пошук та сортування даних.

Розглянемо діаграму послідовності "Авторизація користувачів", яка представлена на рисунку 3.2. Якщо користувач не введе правильний логін і пароль, або система не знайде даних про такого користувача, то вхід в систему не відбудеться.

Рисунок 3.2 - Діаграма послідовності "Авторизація користувачів"

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

При цьому слід переконатися, що не пропущені істотні характеристики, представлені в початкових даних (див. рис. 3.3).

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

- кожна операція повинна виконувати одну просту функцію;

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

Отримана в результаті діаграма класів предметної області показана на рисунку 3.3.

Вставить все по оповещениям из Visual Studia

Размещено на http://www.allbest.ru/

Рисунок 3.3 - Діаграма класів предметної області

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

2.2 Побудова ER - діаграми

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

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

При розробці ER-моделей повинні отримати наступну інформацію про предметну область:

- список суті предметної області;

- список атрибутів суті.

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

Кожне обладнання повинно мати свій набір технічних характеристик, отже, можна виділити суть “Двигуни” та суть “Силові трансформатори”. Для опису устаткування необхідні наступні дані, їх можна визначити як атрибути суті “Двигуни”: найменування (id_eng), тип (type_eng), рік виготовлення (year), стаціонарний номер (stat_num_eng), заводський номер (zav_num_eng), завод-виробник (id_plant) та суті “Силові трансформатори”: тип (type), потужність (power), напруга (tens), струм (current), Ек (Ek), схема з'єднання (scheme), вага масла (weight), стаціонарний номер (stat_num), заводський номер (zav_num), завод-виробник (id_plant).

Відношення таблиць для бази даних «ГППР» можна представити таким чином:

- Цех > Двигуни - 1-M;

- Цех > Силові трансформатори - 1-M.

Розглянувши, яка суть і атрибути нам необхідні для проектування бази даних «ГППР», можна спроектувати ER - діаграму (див. рис. 3.4).

2.3 Побудова схеми реляційної бази даних в 3-ій нормальній формі

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

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

Існує декілька правил нормалізації баз даних. Кожне правило називається “Нор-мальною формою”. Якщо виконується перше правило, говорять, що база даних представлена в “першій нормальній формі”. Якщо виконуються три перших правила, вважається, що база даних представлена в “третій нормальній формі”. Є і інші рівні нормалізації, проте для більшості додатків досить нормалізувати бази даних до третьої нормальної форми.

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

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

Побудуємо схему реляційної бази даних і перевіримо, чи знаходитися вона в 3-ій нормальній формі (див. рис 3.5).

Отримана схема полегшить нормалізацію бази даних.

Розглянемо функціональні залежності таблиці “Силові трансформатори”.

Залежності:

- Id_тран - первинний ключ (PK);

- Id_тран > Тип, Потужність, Напруга, Струм, Ек, Схема з'єднання, Вага масла Заводський номер, Стаціонарний номер;

- Id_цех - зовнішній ключ (FK) з таблицею Завод.

Поля Тип, Потужність, Напруга, Струм, Ек, Схема з'єднання, Вага масла, Заводський номер, Стаціонарний номер - неключові і не залежать один від одного і повністю функціонально залежать від первинного ключа Id_тран. Надмірних даних також не існує, оскільки поле Id_цех зв'язано зовнішнім ключем (FK) з відповідною таблицею. Дана таблиця не має транзитивних залежностей, отже, таблиця “Силові трансформатори ” знаходиться в 3-ій нормальній формі.

Рисунок 3.5 - Схема бази даних “ГППР ”

Таблиця “Двигуни” з функціональною залежністю:

- Id_двиг - первинний ключ (PK);

- Id_двиг > Найменування агрегата, Тип_дв, Рік виготовлення, Заводський номер_дв, Стаціонарний номер_дв;

- Id_цех - зовнішній ключ (FK) з таблицею Цех.

Поля Тип Найменування агрегата, Тип, Рік виготовлення, Заводський номер, Стаціонарний номер - не ключові і не залежать один від одного і повністю функціонально залежать від первинного ключа Id_двиг. Надмірних даних також не існує, оскільки поле Id_цех зв'язано зовнішнім ключем (FK) з відповідною таблицею. Дана таблиця не має транзитивних залежностей, отже, таблиця “Двигуни ” знаходиться в 3-ій нормальній формі.

Розглянемо таблицю “Цех”. Залежності:

- Id_цех - первинний ключ (PK);

- Id_цех > Назва цеху, Адреса, Телефон.

Поля Назва цеху, Адреса, Телефон - неключові і не залежать один від одного і повністю функціонально залежать від первинного ключа Id_цех. Дана таблиця не має транзитивних залежностей, тобто таблиця “Цех” знаходиться в 3-ій нормальній формі.

3. ОПИС ПРОГРАМИ

3.1 Загальні відомості

Для реалізації даного проекту було вибрано середовище розробки Visual Studio 2008 Professional Edition. Дане середовище розробки є повним набором засобів, що допомагають прискорити процес реалізації задуму розробника.

Як мова програмування був вибраний С# (C Sharp) - об'єктно-орієнтована мова програмування для платформи .NET.

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

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

- підтримувані операційні системи: Windows Server 2003, Windows Server 2008, Windows Vista, Windows XP;

- процесор: Pentium з тактовою частотою 1 MГц або аналогічний процесор (рекомендується Pentium з тактовою частотою 2 Ггц або аналогічний процесор);

- ОЗУ: не менше 256 МБ (рекомендується 1 ГБ);

- жорсткий диск: може бути потрібно до 100 МБ доступного дискового простору і 400 МБ для додаткових програм;

- дисковод для компакт-дисків або DVD-дисків: не потрібний;

- екран: дозвіл 800 x 600, 256 кольорів (рекомендується дозвіл 1024 x 768, high color (32-розрядний колір)).

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

- Microsoft .NET Framework 3.5;

- Mysql-connector-net-6.2.2;

- Mysql Server-6.0.6-alpha-win32;

- EMS SQL Manager 2010 for MYSQL.

3.2 Призначення і логічна структура

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

В результаті дипломного проекту була організована система авторизації користувачів в базі даних ІС “ГППР” в програмному модулі “Авторизація користувачів” в базі даних ІС “ГППР” з категоріями користувачів: адміністрація, співробітники експлуатаційних цехів, відділ постачання, бухгалтерія.

Кожній категорії користувачів визначені повноваження роботи з даними, такі як:

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

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

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

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

Для адміністрації станції реалізована можливість формування наступних звітів в програмному модулі “Звіти”:

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

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

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

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

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

Логічна структура відображена на рисунку 4.1:

Рисунок 4.1 - Логічна структура бази даних

3.4 Опис фізичної моделі бази даних

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

Для адміністрування і перегляду бази даних скористаємося програмним продуктом EMS SQL Manager 2010 for MYSQL.

База даних equipment_db програмного модуля ІС «Електротехнічне обладнання» складається з 3 таблиць. Розглянемо структури даних таблиць.

Таблиця “Transform_equip” призначена для зберігання даних з технічними характеристиками силових трансформаторів.

Таблиця “Transform_equip” складається з первинного ключа id_tran з типом даних integer (чисельний) і поля type, scheme з типом даних varchar (символьний), power, tens, current, Ek, stac_num, zav_num - чисельні типи. Зв'язана зовнішнім ключем id_plant з таблицею Plant. Таблиця зберігає дані про характеристики трансформаторів (див. рис. 4.2).

Рисунок 4.2 - Опис реалізації таблиці Transform_equip

Таблиця “Engine_equip” складається з первинного ключа id_eng з типом даних integer (чисельний) і поля type_eng, name з типом даних varchar (символьний), year, stac_num_eng, zav_naum_eng - чисельні типи. Зв'язана зовнішнім ключем id_plant з таблицею Plant. Таблиця зберігає дані про характеристики двигунів (див. рис. 4.3).

Рисунок 4.3 - Опис реалізації таблиці Engine_equip

Таблиця “Plant” призначена для зберігання даних про експлуатаційні цехи обладнання (див. рис. 4.4).

Рисунок 4.4 - Опис реалізації таблиці Plant

Таблиця “Details” призначена для зберігання даних про терміни використання деталей певного обладнання (див. рис. 4.5).

Рисунок 4.5 - Опис реалізації таблиці Details

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

3.5 Опис програмної реалізаціі

namespace NotificationService

{

partial class NotificationService : ServiceBase

{

public NotificationService()

{

InitializeComponent();

if (!System.Diagnostics.EventLog.SourceExists("EmailSource"))

{

System.Diagnostics.EventLog.CreateEventSource("EmailSource", "EmailLog");

}

eventLogEmail.Source = "EmailSource";

eventLogEmail.Log = "EmailLog";

Timer scheduleTimer = null;

scheduleTimer = new Timer();

scheduleTimer.AutoReset = true;

scheduleTimer.Interval = 1*60*60*1000;//интервал 1 час

scheduleTimer.Enabled = true;

scheduleTimer.Elapsed += new ElapsedEventHandler(scheduleTimer_Elapsed);

}

protected override void OnStart(string[] args)

{

scheduleTimer.Start();

eventLogEmail.WriteEntry("Started");

}

protected void scheduleTimer_Elapsed(object sender, ElapsedEventArgs e)

{

ServiceEmailMethod();

}

private void ServiceEmailMethod()

{

eventLogEmail.WriteEntry("In Sending Email Method");

NotificationComponent.GetEmailIdsFromDB getEmails = new NotificationComponent.GetEmailIdsFromDB();

getEmails.connectionString = ConfigurationManager.ConnectionStrings["magazine_dbConnectionString1"].ConnectionString;

getEmails.storedProcName = "Notification_proc";

System.Data.DataSet ds = getEmails.GetMailIds();

NotificationComponent.Email email = new NotificationComponent.Email();

email.fromEmail = "knure_magazine@mail.ru";

email.fromName = "Notification KNURE";

email.subject = "Система оповещения ХНУРЭ";

email.smtpServer = "smtp.mail.ru";//"smtp.gmail.com";

email.smtpPort = 2525;//587;

email.smtpCredentials = new System.Net.NetworkCredential("knure_magazine@mail.ru", "magazine");

foreach (System.Data.DataRow dr in ds.Tables[0].Rows)

{

email.messageBody = "<h4>Здравствуйте, Вас приветствует cистема оповещения ХНУРЭ!!!</h4><br/><h5>" + dr["Message"].ToString() + "</h5><br/><h4>С уважением, ХНУРЭ.</h4>";

bool result = email.SendEmailAsync(dr["Email"].ToString());

if (result == true)

{

eventLogEmail.WriteEntry("Message Sent SUCCESS to - " + dr["Email"].ToString());

getEmails.storedProcName = "DeleteNotification_proc";

ds = getEmails.GetMailIds();

}

else

{

eventLogEmail.WriteEntry("Message Sent FAILED to - " + dr["Email"].ToString());

}

}

}

protected override void OnStop()

{

scheduleTimer.Stop();

eventLogEmail.WriteEntry("Stopped");

}

protected override void OnPause()

{

scheduleTimer.Stop();

eventLogEmail.WriteEntry("Paused");

}

protected override void OnContinue()

{

scheduleTimer.Start(); ;

eventLogEmail.WriteEntry("Continuing");

}

protected override void OnShutdown()

{

scheduleTimer.Stop();

eventLogEmail.WriteEntry("ShutDowned");

}

}

}

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

4. ОПИС ЗАХИСТУ СИСТЕМИ ІНФОРМАЦІЇ

Для запуску розробленого програмного продукту необхідна наявність на персо-нальному комп'ютері встановленого Mysql Server (локального), або доступ через ЛОМ (локальна обчислювальна мережа) до Mysql Server на серверній станції (тобто дане застосування працює як клієнт-сервер).

Розглянемо настроювання установки сервера Mysql Server-6.0.6-alpha-win32 на персональний комп'ютер:

- при установці сервера необхідно вказати:

1) хост - localhost;

2) користувач - root;

3) пароль - gnusmas.

- для коректного відображення російських символів необхідно змінити конфігураційний файл my.ini, який розташовується: C:\Program Files\MySQL\MySQL Server 6.0\my.ini

У даному файлі необхідно змінити настройки відображення шрифтів для клієнта і сервера Mysql:

[mysql]

default-character-set=latin1 (на utf8)

[mysqld]

default-character-set=latin1 (на utf8)

Після установки сервера Mysql необхідно відновити базу даних із створеної копії (dump_equipment.sql). Для цього необхідно скопіювати файл з копією бази в: C:\Documents and Settings\Ім'я облікового запису користувача. Зайти в командний рядок (cmd) і відновити базу даних за допомогою утиліти mysql, де необхідно вказати користувача, пароль, хост і ім'я бази даних: mysql -uroot -pgnusmas -hlocalhost < dump_equipment.sql.

Після відновлення бази даних можна встановити EMS SQL Manager 2010 for MYSQL - це високопродуктивна програма для розробки і адміністрування баз даних MYSQL. SQL Manager for MYSQL працює з будь-якими версіями MYSQL, починаючи з версії 3.23, підтримує всі найновіші функції MYSQL.

Також необхідно перевірити чи встановлено на персональному комп'ютері Microsoft .NET Framework 3.5, і встановити Mysql-connector-net-6.2.2, який призначений для взаємодії .NET додатків з джерелами даних MYSQL.

Після установки всіх додаткових компонентів можна викликати програму “ГППР”, запустити виконуваний файл “Equipment.exe”, після чого з'явиться вікно авторизації, де необхідно вказати:

- категорію користувача - Адміністратор;

- ім'я - root;

- пароль - admin.

Після виконаних дій з'явиться головне вікно програми

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

5. АНАЛІЗ ДОСЛІДНОЇ ЕКСПЛУАТАЦІЇ І МОЖЛИВИХ ЗАСТОСУВАНЬ

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

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

ВСТАВИТЬ ТЕСТИРОВАНИЕ ИЗ ЖУРНАЛА

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

Для версії 4.21а дуже великий вважалася база даних розміром 10-15 Гб (хоча деякі організації, наприклад, Sprint, працювали з базами даних розміром 60 Гб і більше). Високошвидкісна паралельна обробка робить можливою підтримку роботи з базами даних розміром 100 Гб і більше на відповідним чином конфігуровані системах. Не тільки процес створення страхувальних копій виконується швидше, але і такі операції, як перевірка цілісності бази даних (виконується командою DBCC), сильно виграють від використання паралельного сканування і збільшених блоків вводу / виводу. Можливість збереження в страхувальної копії (відновлення з копії) індивідуальних таблиць дозволяє скоротити час, необхідний на збереження (відновлення) окремих таблиць бази даних. Підтримка розповсюдження баз даних на знімних носіях (таких як CD-ROM) дозволяє випускати різного роду довідники або інформаційні матеріали. Цікаво відзначити, що гнучкість SQL Server виявляється і при роботі з дуже маленькими обсягами інформації. Так, для того щоб базу даних можна було зберегти на дискеті, її мінімальний розмір знижений до 1 Мб.

Максимальний розмір бази даних 10 Гбайт - файл журналу.

Максимальне число потоків клієнта 30 - Відповідає про макс. 50 одночасних користувачів

Максимальна SMP 4 Процесора

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

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

Максимальні розміри таблиць

MySQL 3.22: до 4 ГБ

MySQL 3.23 +: до 8 млн ТБ (263 байт)

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

Час очікування конекту: 120 секунд

ВИСНОВКИ

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

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

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

Для реалізації даного проекту були вибрані середовища розробки Visual Studio 2008 Professional Edition та Mysql Server.

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

1. Васькевіч, Д. Стратегії клієнт/сервер [Текст] / Д. Васькевіч. - Київ: Діалектика, 1997.

2. Дейт, К. Введення в системи баз даних [Текст] : пер. с англ. - К. А. Птіцин; Київ: Діалектика, 1998. - 784 с.

3. Алан Шаллоуей, Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию [Teкст]/ Алан Шаллоуей. - CП: Вильямс, 2002 г. - 288с.

4. Атре, Ш. Структурний підхід до організації баз даних [Текст] / Ш. Атре. - М.: Фінанси і статистика, 1983.

5. Ладиженський, Г.М. Системи управління базами даних - коротко про головне [Текст] / Г. М. Ладиженський. //СУБД. - 1995. - №1,2,3,4.

6. Чен, П. Модель "суть-зв'язок" - крок до єдиного уявлення про дані [Текст] / П. Чен. //СУБД. - 1995. - №3. - С.137-158.

7. Васильев, А. А. - Електрооборудование станций и подстанций [Текст] : учебник для техникумов / А. А. Васильев. - Москва: Енергоатомиздат, 1987.

8. Рожкова, Л. Д. Електрооборудование станций и подстанций [Текст] : учебник для техникумов / Л. Д. Рожкова, Козулин В. С. - Москва: Енергоатомиздат, 3-е изд., 1987.

9. ДСан ПиН 3.3.2-007-98. Государственные санитарные правила и нормы работы с визуальными дисплейными терминалами электронно-вычислительных машин.

10. НПАОП 0.00-1.28-10. Правила охорони праці при експлуатації ЕОМ.

11. ГОСТ 12.0.003-74. ССБТ. Опасные и вредные производственные факторы. Классификация.

12. НПАОП 40.1-1-32-01 Правила будови електроустановок. Електрообладнання спеціальних установок.

13. ДСН 3.3.6.042-99. Санітарні норми мікроклімату виробничих приміщень.

14. Дзюндзюк Б.В., Іванов В.Г., Охрана труда. Сборник задач. - Х.: НВП центр ХНУРЕ, 2006. - 242с.

15. НАПБ Б.03.002-2007 Нормы определения категорий помещений, зданий и наружных установок по взрывопожарной и пожарной опасности.

16. НПАОП 40.1-1.32-01 Правила будови електроустановок. Електрообладнання спеціальних установок.

17. НАПБ Б.01.008-2004 Правила експлуатації вогнегасників.

18. ДБН В.2.5-13-98 Инженерное оборудование зданий и сооружений. Пожарная автоматика зданий и сооружений.

ДОДАТОК А

А.1 Аналіз умов праці на робочому місці планового відділу експлуатаційного цеху

Виробниче приміщення належить комунальному підприємству «Харківські теплові мережі», філії «Теплоелектроцентраль-3». В приміщенні цеху знаходиться офісна кімната з 6 робочими місцями співробітників відділу, котрі є користувачами ПЕОМ. В приміщенні відділу, крім шести ПЕОМ, є один багатофункціональний пристрій для друкування паперових документів. Розміри приміщення: довжина - 7м., ширина - 7м., висота - 3,5м. В приміщенні є природне та штучне освітлення, воно обладнане системою опалення та кондиціювання.

Згідно з п. 2.3 ДСан ПіН 3.3.2-007-98 для одного працюючого необхідна площа виробничого приміщення не менше 6м², об'єм повітряного середовища - не менше 20м³ [1]. В даному приміщені на кожну людину припадає 8,1м² та 28,6м³ відповідно. Приміщення задовольняє вимогам ДСанПіН 3.3.2-007-98.

Розглянемо систему «Людина - Машина - Середовище» (Л-М-С) [2]. Вона описує взаємний вплив людини, машини та середовища один на одного, тобто взаємодію між користувачем ПЕОМ, персональним комп'ютером та навколишнім середовищем (див. рис. А.1).

Рисунок А.1 - Система Л-М-С

На цьому рисунку можна побачити взаємний вплив усіх складових системи «Людина - Машина - Середовище». Ця система побудована для 6 працівників з відповідною кількістю робочих місці.

Таблиця 6.1 - Перелік зв'язків у системі Л-М-С

Подобные документы

• Інформаційна система "Відділення банку"

  Аналіз предметної галузі, постановка задачі, проектування бази даних. UML-моделювання, побудова ER-діаграми, схеми реляційної бази даних у третій нормальній формі. Призначення і логічна структура. Опис фізичної моделі бази даних, програмної реалізації.
  
  курсовая работа [3,5 M], добавлен 28.11.2011
  

• База даних інформаційної системи "Лікарня"

  Виявлення основних сутностей предметної області. Побудова схеми реляційної бази даних. Вбудовані процедури і тригери. Опис архітектури програмної системи і концептуальної моделі бази даних, програмної реалізації та інтерфейсу користувача додатку.
  
  курсовая работа [4,3 M], добавлен 05.12.2012
  

• Облік наданих поліграфічних послуг у типографії

  Специфікація вимог користувачів підсистеми, нормативні документи. Опис вхідної та вихідної інформації, алгоритм проектування. Побудова реляційної бази даних. Тестування підсистеми. Формування запитів на мові SQL. Розробка інформаційної підсистеми.
  
  курсовая работа [160,8 K], добавлен 12.11.2014
  

• Концепція автоматизованого програмування

  Розробка бази даних для обробки інформації про діяльність туристичного агентства. Визначення предметної області, вхідних та вихідних даних, їх організації. Генерація схеми бази даних. Реалізація функціональних вимог. Інструкція з експлуатації системи.
  
  курсовая работа [5,3 M], добавлен 12.05.2015
  

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

  Опис інструментальних засобів розробки програмного забезпечення. Загальний склад, структура і інформаційна діаграма схеми даних. Опис полів таблиць структурної схеми бази даних. Первісні дані системи обліку студентів коледжу, що навчаються за контрактом.
  
  дипломная работа [869,3 K], добавлен 13.09.2014
  

• Розробка бази даних будівельних витрат для розрахунку на будівництво

  Визначення та опис бази даних, її структура та зміст головних компонентів, вимоги та напрямки застосування, сторони-учасники, інформаційне забезпечення. Системний аналіз за вхідною та вихідною документацією, побудова ER-моделі, реалізація сутностей.
  
  курсовая работа [586,1 K], добавлен 02.07.2015
  

• Меблева фірма: розробка бази даних

  Розробка бази даних для меблевої фірми. Обстеження і аналіз предметної області та побудова концептуальної, логічної та фізичної моделі цієї бази даних. Використання мови програмування Visual Basic при написанні програмного коду, що обслуговує базу даних.
  
  курсовая работа [1,4 M], добавлен 24.10.2010
  

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

  Вибір методів та засобів створення інформаційної системи для обліку і перегляду продукції на складі. Розробка моделі даних для реляційної бази даних, прикладного програмного забезпечення. Тестування програмного додатку, виявлення можливих проблем.
  
  курсовая работа [1,1 M], добавлен 22.09.2015
  

• Поняття про інтегровану базу даних як одну із складових програмних забезпечень АРМ

  Поняття та переваги реляційної бази, автоматизація аналізу даних. Опис основних компонентів сховища даних AS/400. Процес перетворення оперативних даних в інформаційні. Багатовимірні бази даних (MDD). Опис даних і створення файлів в інтеграційних базах.
  
  реферат [36,8 K], добавлен 14.01.2012
  

• Інформаційна система "Облік мобільних терміналів"

  Структура підприємства "Newtone", опис його інформаційних систем. Аналіз обліку терміналів як об’єкта інформатизації. Завдання, розв'язувані за допомогою системи. Інформаційна структура бази даних. Опис програми, форм, звітів. Блок-схема системи.
  
  дипломная работа [1,4 M], добавлен 24.02.2011
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам