Розробка web-системи з реалізації комп’ютерних комплектуючих з оптимальним пошуком при формуванні заказу

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

ВСТУП

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

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

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

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

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

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

РОЗДІЛ 1. ПРИНЦИПИ РОЗРОБКИ WEB-СИСТЕМ. ІНСТРУМЕНТИ ДЛЯ СТВОРЕННЯ САЙТУ

1.1 Класифікація сайтів

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

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

- динамічні сайти та веб-сторінки. Як вже було згадано, динамічні сторінки не існують в незмінному вигляді на сервері, а формуються за допомогою скриптів. Зміст і вид динамічної сторінки з одним і тим же адресою може бути абсолютно різним у залежності від різних умов - наприклад, в залежності від часу, від конкретного користувача, від введеного користувачем запиту і т. п. Скрипти, що використовуються для формування динамічних веб-сторінок, можуть бути написані на різних мовах. Поширеними мовами веб-програмування є, наприклад, php, perl, asp;

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

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

За структурою web-сторінки поділяються на: гнучкі сторінки та сторінки фіксованого розміру[1].

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

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

Переваги:

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

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

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

Недоліки:

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

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

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

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

Переваги:

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

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

Недоліки:

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

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

Розробка комбінованих web-сторінок.

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

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

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

Класифікація сайтів за призначенням.

Сайт-візитка - зазвичай складається з декількох сторінок і має унікальний, але простий і функціональний дизайн; ідеально підходить для компаній, які хочуть розмістити інформацію про себе і свої послуги в Інтернеті; основні розділи сайту: «Про компанію», «Продукція чи послуги» , «Прайс-листи», «Контактна інформація»; сайт-візитка використовується підприємствами, організаціями та приватними особами.

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

Корпоративний іміджевий web сайт - ідеально підходить для забезпечення іміджевого присутності в Мережі; сайт служить для надання докладної інформації про компанію, історії торгової марки, відомостей про які надають послуги або товари, що поставляються; корпоративний сайт зазвичай містить стрічку новин компанії, засоби публікації інформації про рекламні і торгових акціях, інформацію для преси та інші відомості; нерідко корпоративні сайти поєднують інформацію про компанію з каталогом продукції; використовується ексклюзивний оригінальний дизайн, вигідно представляє компанію; використання нестандартних ідей і рішень в оформленні, процентне співвідношення текст / графіка = 50/50

Інтернет-магазин, він же Мережевий магазин, Електронний магазин, Internet shop, E-shop - інтерактивний веб-сайт що рекламує товар або послугу, приймає замовлення на покупку, пропонує користувачеві вибір варіанту розрахунку, який виписує рахунок на оплату, службовець одночасно підтвердженням замовлення; при цьому адміністратор магазину зобов'язаний:

- організувати доставку товару;

- проконтролювати розрахунки з покупцем за поставку.

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

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

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

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

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

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

Також може являти собою освітній чи розважальний ресурс.

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

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

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

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

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

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

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

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

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

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

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

1.2 Необхідність використання фреймворків

Для розробки сучасних WEB-додатків «голої» мови програмування вже давно недостатньо. Відома ситуація, коли звикли розробляти проекти на php, інколи доводиться писати, переносити купу повторюваного рутинного коду для чергового проекту. З цього положення кожен девелопер викручується по-своєму - одні створюють свої шаблони і використовують їх повсюдно, інші - вибирають всілякі надбудови для мови - CMF (Content Management Framework)[2].

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

1. Постійна структура. При використанні фреймворків потрібно чітке розділення ролей для кожного файлу проекту. Наприклад, якщо фреймворк побудований на архітектурі MVC, то всі створені вами контролери, уявлення та моделі будуть лежати по різних папках. При постійній розробці нових, а також підтримки старих проектів не потрібно ламати голову над питанням: «А куди ж я поклав такий то сценарій?» Або «Де у мене реалізована така-то функція». Крім того, подальшу підтримку таких проектів набагато простіше передавати іншим програмістам. Адже щоб вони змогли розібратися в коді і принципи його побудови, їм достатньо поглянути на документацію фреймворку.

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

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

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

5. Оперативна допомога. Отримати кваліфіковану допомогу при використанні фреймворку просто і швидко. Будь популярний і функціональний CMF має спільноти, постійно займаються тестуванням і підтримкою.

1.2.1 Аналіз можливостей фреймворку Code Igniter

CodeIgniter - популярний MVC фреймворк з відкритим вихідним кодом, написаний на мові програмування PHP, для розробки повноцінних веб-систем та програм. Розроблено компанією EllisLab, а також Ріком Еллісом (Rick Ellis) і Полом Бурдик (Paul Burdick)[3,4].

Перший публічний реліз фреймворку стався 28 лютого 2006 року. З виходом версії 2.0 28го січня 2011 CodeIgniter розділився на дві гілки:

- CodeIgniter Core - гілка, яка робить акцент на стабільності, у зв'язку з чим розвивається повільно. Ця версія фреймворку є ядром популярної CMS ExpressionEngine 2.0.

- CodeIgniter Reactor - гілка, яку розвиває спільноту. Ця гілка розвивається швидко і містить найновіші можливості.

CodeIgniter відрізняє простота, яка досягається завдяки наступним факторам:

- якісна і повна документація з прикладами, а так само велика спільнота і Wiki;

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

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

- малий розмір дистрибутива (розмір складає приблизно 2 Мб);

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

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

Можливості.

- підтримка баз даних MySQL, PostgreSQL, MSSQL, SQLite, Oracle;

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

- підтримка як сегментованих ЧПУ, так і звичайних URL-ів з передачею параметрів;

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

- володіє можливістю кешування на стороні сервера SQL-запитів і генеруються html-сторінок. З версії 2.0 для кешування можуть використовуватися XCache або APC;

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

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

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

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

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

5. Active Record. У CI використовується модифікована версія патерну Active Record Database. За допомогою Active Record, робота з базою даних перетворюється на суцільне задоволення. Більше не доведеться писати численні «SELECT» для вибору даних, достатньо лише скористатися методами цього класу, а це всього дві невеликі строчки коду. Крім спрощеного доступу до БД, цей клас дозволяє забути про використовувану СУБД. Ви можете побудувати додаток, використовуючи MySQL, а потім також легко запустити його під Oracle. І це ще не все. До всього іншого, AR дозволяє хоч трохи, але убезпечити роботу з СУБД, тому що при складанні запитів всі значення екрануються.

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

7. Архітектура MVC. CI заточений під архітектуру MVC (Model-View-Controller), що дозволяє відокремити логіку від відображення. При роботі в команді (програмісти + дизайнери), такий підхід буде дуже потрібний.

Model View Controller (MVC) - архітектура програмного забезпечення, що дозволяє розділити модель даних, користувальницький інтерфейс і керуючу логіку на три окремі складові[5,6]. Причому розділити її так, що зміна одного не вплине на роботу інших компонентів. Використовувати цю архітектуру дуже зручно при розробці великих проектів, робота над якими йде в команді. Наприклад, працюючи над проектом, програмістам не потрібно піклуватися про майбутній інтерфейс. Їх мета - отримати і обробити дані, а потім відправити їх користувачеві. Вид, в якому користувач отримає ці дані, програмістів хвилювати не повинен. Це вже робота дизайнерів і верстальників, які можуть паралельно створювати стиль відображення для отриманих даних. Що ж стосується програмістів, то вони теж можуть розподіляти свою роботу - наприклад, частина розробників може зосередитися на розробці логіці програми, а інша - на проектуванні структури бази даних. Як видно з прикладів, при використанні MVC стає можливим розпаралелити роботу команди, тим самим підвищити загальну продуктивність. Отже, MVC складається з сутностей:

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

2. View (подання) - відповідає за передачу користувачеві оброблених даних.

3. Controller (Контролер) - займається інтерпретацією запитуваних, відправлених користувачем даних, взаємодіє з моделлю для їх отримання. Важливо помітити, що Code Igniter, на відміну від інших MVC-фреймворків не примушує використовувати MVC в повній мірі. Якщо вам не зручно ділити код на три складові, то це робити зовсім необов'язково. Для створення робочої програми ви можете обмежитися одним лише контролером, організувавши в ньому все логіку і роботу з СУБД. Тим не менш, розуміння MVC, дозволить у майбутньому з легкістю освоювати альтернативні фреймворки.

8. Підтримка шаблонизатору. Незважаючи, на те, що CI не вимагає обов'язкового використання шаблонизатору, при бажанні їм можна скористатися.

9. Дружність до пошуковиків. Завдяки своїм URL'ам, Code Igniter відмінно дружить з пошуковими система і піддається індексації.

10. Повна сумісність з php 4. Хоч зараз це не настільки актуально, але пару років тому, коли у більшості хостерів була встановлена четверта версія цього інтерпретатора, Code Igniter вигідно відрізнявся на тлі конкурентів. Так, що якщо ви до цих пір застрягли у вчорашньому дні або використовуватися php4 вас зобов'язують інші причини, то тепер ви зможете це робити разом з Code Igniter.

1.2.2 Порівняння властивостей фреймворків Code Igniter та Yii

Документація.

Функціонал CodeIgniter описан досить компактно, простою мовою і відмінно оформлені. Пишеться документація виключно розробниками.

Yii[6] більш складний і досить молодий. Тому документація не охоплює деяких цікавих місць (втім, непогано описаних в API). Тим не менше, від цього розробник не страждає: описані найтиповіші моменти, які в більшості випадків і доведеться використовувати. Мова документації більше схожий на науковий. Оформлення акуратне, але не викликає розчулення як це робить документація з CodeIgniter.

Сумісність.

Yii написаний на PHP5.2 (з PHP5.3 теж працює) і не підтримує PHP4. Використовується досить багато нового для PHP5.2 функціоналу. Для роботи необхідний PDO (PHP Data Objects) - інтерфейс для доступу до баз даних.

CodeIgniter сумісний з PHP4 і використовує PHP як на рівні четвертої версії, так і на PHP5.2.

Автозавантаження.

У CI дуже непогано зроблена завантаження класів. Дещо вантажиться автоматично, решта - через $ this-> load. У Yii автоматично вантажиться все, що зазначено в файлах конфігурації.

Роутер.

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

Контролер.

Для іменування в Yii використовуються постфікси MyController проти My в CI, actionMyCool () проти mycool в CI. Це вирішує проблему з дублюючими іменами класів, і відкритими методами часто виникає в CI.

Загалом, в Yii контролер більш гнучкий.

З незручностей: параметри, передані через URL доводиться отримувати з $ _GET, а не з параметрів методу, як це було в CI.

Відображення.

View у CodeIgniter слабкий, хоча, якщо використовувати сторонні рішення [8, 9] усе не так вже і погано.

Yii в цьому плані дуже гарний. Підтримуються layout-и, вкладені view, віджети, є API для реалізації своїх шаблонизатор (з уже реалізованих «компілюванні») в код на PHP.

Модель.

У CI модель безпосередньо пов'язана з базою даних. Інших моделей просто немає.

У Yii модель може використовувати ActiveRecord, а може і не працювати з базою.

Валідація форм.

Валідатор в Yii на голову випереджає CodeIgniter. Можна використовувати валідатори моделі, є досить багато вбудованих правил валідації і легко реалізувати свої.

Чого немає в Yii.

Вбудованих класів для роботи з поштою, зображеннями, FTP, ZIP, Trackback.

Також у Yii немає хелперів в тому вигляді, який був у CI, але ніщо не забороняє їх реалізувати ... або запозичити, наприклад, з Kohana.

Чого немає в CI.

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

У даній роботі вибір був зроблений на користь CodeIgniter, тому що:

- дуже докладна документація російською мовою;

- гнучкість;

- простота у вивченні;

- швидкість роботи;

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

РОЗДІЛ 2. ПРОЕКТУВАННЯ СИСТЕМИ

2.1 Застосування парсингу для створення web-системи з реалізації комп'ютерних комплектуючих з оптимальним пошуком при формуванні заказу

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

Завдяки парсингу в системі створено пошук комп'ютерних комплектуючих по декількох магазинах постачальниках з метою їх реалізації по обраним оптимальним параметрам, як вартість товару та список властивостей[10,11].

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

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

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

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

2.2 Аналіз бібліотек парсинга

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

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

Краща бібліотека вибиралася з таких критеріїв як:

- швидкість;

- документація;

- зручність.

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

<?php

$html = file_get_contents('http://itc.ua/');

$tstart = microtime(true);

/* Далі код бібліотеки */

...

/* Кінець коду бібліотеки */

$tend = microtime(true);

$totaltime = ($tend - $tstart);

file_put_contents('results/'.$file_to_result.'.txt', "done in: $totaltime sec\r\n", FILE_APPEND);

?>

Вибірка по селекторам типу «. Classname»

PHPQuery[12]:

...

include('phpQuery.php');

$pq = phpQuery::newDocumentHTML($html);

$to_echo;

foreach ($pq->find('.topic') as $topic){

$to_echo = pq($topic)->text().'<br />';

}

...

(Середній час виконання: 0.0605466580391 секунд)

Simple HTML DOM[13]:

...

include('libraries/simple_html_dom.php');

$shd = str_get_html($html);

$to_echo;

foreach ($shd->find('.topic') as $topic){

$to_echo = $topic->plaintext.'<br />';

}

...

(Середній час виконання: 0.268265895843 секунд)

Zend DOM Query[14,15,16]:

...

include('Zend/Dom/Query.php');

$znd = new Zend_Dom_Query($html);

$to_echo;

foreach ($znd->query('.topic') as $topic){

$to_echo = $topic->nodeValue.'<br />';

}

...

(Середній час виконання: 0.0236939692497 секунд)

Nokogiri:

...

include('nokogiri.php');

$saw = new nokogiri($html);

$to_echo;

foreach ($saw->get('.topic') as $topic){

if ($topic['#text'] != '') {

$to_echo = $topic['#text'].'<br />';

}

}

...

(Середній час виконання: 0.0218371343613 секунд)

Порівняємо результати:

Бібліотека:PHPQuerySimple HTML DOMZend DOM QueryNokogiri

Час («.classname»):0,0605470,2682660,0236940,021837

Час («#id»):0,0523740,3738920,0253660,023089

Час («parent child»):0,0543760,2567890,0210130,020093

Час («tag[attr=val]»):0,0432210,2536960,0152930,014254

Рейтинг: 3421

Документація.

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

PHPQuery. Блог знаходиться за адресою - phpquery-library.blogspot.com

Документація недостатньо зручна і відсутня на російській мові. В Інтернеті присутня велика кількість статей і прикладів використання.

Simple HTML DOM. Документація знаходиться за адресою - simplehtmldom.sourceforge.net

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

Zend DOM Query. Документація знаходиться за адресою - framework.zend.com. Є як російська, так і англійська версія документації, але знайти дійсно корисні приклади використання було дуже складно.

Nokogiri: Офіційній документації та інших статей в Інтернеті не знайшов.

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

2.3 Розробка інформаційної моделі

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

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

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

- визначення сутностей;

- визначення залежностей між сутностями;

- завдання первинних і альтернативних ключів;

- визначення атрибутів сутностей;

- приведення моделі до необхідного рівня нормальної форми;

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

- генерація бази даних.

2.4 Опис основних об'єктів та їх атрибутів

Таблиця 2.1 Опис об'єкту product

Об'єкт	Короткий опис
ProductID	Первинний ключ
Type	Містить інформацію про тип комплектуючого
Name	Найменування комплектуючого
Url	Посилання до товару
ImageUrl	Посилання до зображення товару
Price	Вартість товару
Status	Відображає наявність товару
Site	Містить інформацію про сайт, який надає товар
SKU	Складський номер
Rating	Рейтинг товару
Date	Дата додавання товару до бази даних

Таблиця 2.2 Опис об'єкту dict_property

Об'єкт	Короткий опис
PropertyID	Первинний ключ
NameProperty	Найменування властивості
RussianName	Російська назва властивості
Comment	Коментар до властивості
PropertyType	Тип
IsHidden	Статус відображення властивості

Таблиця 2.3 Опис об'єкту product_property

Об'єкт	Короткий опис
ProductPropoertyID	Первинний ключ
ProductID	Зовнішній ключ товару
PropertyID	Зовнішній ключ властивості
OriginalName	Найменування властивості
Value	Значення
ChangeDate	Дата зміни

2.5 Нормалізація бази даних

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

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

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

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

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

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

2.6 Принципи та етапи тестування програмного забезпечення

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

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

Інше визначення тестування (у Г. Майерса) тестування - це процес виконання програми з метою виявлення в ній помилок. Таке визначення мети стимулює пошук помилок в програмах. Звідси також ясно, що "вдалим" тестом є такий, на якому виконання програми завершилося з помилкою. Навпаки, "невдалим" можна назвати тест, який не виявив помилку в програмі.

Визначення Г. Майерса вказує на об'єктивну трудність тестування: це деструктивний (тобто зворотний творчому) процес. Оскільки програмування - процес конструктивний, ясно, що більшості розробників програмних засобів складно "переключитися" при тестуванні створеної ними продукції.

У Майерса сформульовані також основні принципи організації тестування:

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

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

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

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

5) необхідно ретельно підбирати тест не тільки для правильних (передбачених) вхідних даних, але і для неправильних (непередбачених);

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

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

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

9) слід враховувати так званий "принцип скупчення помилок": імовірність наявності не виявлених помилок в деякій частині програми прямо пропорційна числу помилок, вже виявлених в цій частині;

10) слід завжди пам'ятати, що тестування - творчий процес, а не ставитися до нього як до рутинного заняття.

Існує два основних види тестування: функціональне і структурне. При функціональному тестуванні програма розглядається як "чорний ящик" (тобто її текст не використовується). Відбувається перевірка відповідності поведінки програми її зовнішньої специфікації. Чи можливо при цьому повне тестування програми? Очевидно, що критерієм повноти тестування в цьому випадку був би перебір всіх можливих значень вхідних даних, що нездійсненно.

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

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

Але навіть якщо припустити, що вдалося досягти повного структурного тестування деякої програми, в ній, тим не менш, можуть міститися помилки, так як:

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

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

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

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

1) тестування окремих модулів;

2) спільне тестування модулів;

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

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

На перших двох етапах використовуються передусім методи структурного тестування, так як:

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

- Наступні етапи тестування орієнтовані на виявлення помилок різного типу, які не обов'язково пов'язані з логікою програми.

При тестуванні як окремих модулів, так і їх комплексів повинні бути вирішені дві задачі:

1) побудова ефективної безлічі тестів;

2) вибір способу комбінування (збирання) модулів при створенні тестового варіанту програми.

сайт парсинг фреймворк

РОЗДІЛ 3 WEB-СИСТЕМА SEARCHSKU

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

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

<?php

if (!defined('BASEPATH'))

exit('No direct script access allowed');

class M_parser_rozetka_CPU extends CI_Model {

public function addNewProduct($data) {//Додавання распарсеного товару

$query = $this->db->query('SELECT * FROM product where name like '."'".$data['name']."'". 'ORDER BY productid');

if ($query->num_rows()==0){//Оновлення запису з властивостями товару, якщо він вже був доданий

$query = $this->db->query("INSERT INTO product(name,url,imageurl,price,status,site,lowername,type) VALUE

('" . $data['name'] . "','" . $data['ahref'] . "',

'" . $data['img'] . "','" . $data['priceuah'] . "',

'" . $data['status'] . "','" . $data['site'] ."',

'" . strtolower($data['name']) . "','" . "cpu" ."')");

public function parserCPU(){

$iPage=1;

$icountParser=0;

$linkCPU = 'http://hard.rozetka.com.ua/processors/c80083/';

do{

$html_code = file_get_contents($linkCPU);

$document = phpQuery::newDocument($html_code);

$td_detail = $document->find("td.detail");

foreach($td_detail as $td){

$icountParser++;

$pq = pq($td);

$name = $pq -> find("a");//пошук посилання на ЦПУ, найменування ЦПУ

$ahref = $name->attr("href");//отримання посилання на детальний опис процесору

$name = pq($name)->text();

$dataHardware['site']="Rozetka";

$dataHardware['name'] = trim($name);

$dataHardware['ahref'] = $ahref;

$dataHardware['status'] = $pq->find("div.status")->text();

$dataHardware['priceuah'] = $pq->find("div.uah")->text();

$html_codeMore = file_get_contents($ahref);//отримання детального опису за отриманим посиланням

$documentMore = phpQuery::newDocument($html_codeMore);

$dataHardware['img'] = $documentMore->find("div.p-details")->find("img")->attr("src");

//echo $dataHardware['img']."<br/>";

$div_detail = $documentMore->find("div.pp-tab-characteristics");

$tableProp = $div_detail->find("table");

$trArr = $tableProp->find("tr");

$i=-1;

foreach($trArr as $tr){

$i++;

$ptr = pq($tr);

$dataHardware["propName".$i]=$ptr->find("td.title")->text();

$dataHardware["propField".$i]=$ptr->find("td.field")->text();

}

//echo "<hr>";

$this->addNewProduct($dataHardware);

}

$iPage++;

$linkCPU="";

$td_pages = $document->find("td.pages");

$li_pages = $td_pages->find("li");

foreach($li_pages as $pages){

$page = pq($pages);

$availPage = $page->find("a")->text();

if ($availPage>=$iPage){//знайдена наступна сторінка зі списком процесорів

$linkCPU="http://hard.rozetka.com.ua/processors/c80083/"."page=".$iPage;

}

}while($linkCPU!="");

echo "Count= ".$icountParser;

}

}

?>

3.2 Огляд інтерфейсу системи

На рисунку 3.1 нижче наведено загальний вид системи SEARCHSKU.

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

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

Нижче, зліва знаходиться блок парсингу сайтів Rozetka, Fotomag за наступними типами комплектуючих:

- процесор;

- жорсткий диск;

- SSD-накопичувач;

- відео карта;

- ОЗУ;

- материнські плати;

- корпус;

- блок живлення

Рис 3.1 - Загальний вид системи

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

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

Рис. 3.2 - Фільтр даних БД

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

У майбутньому систему можна розширювати з метою пошуку по більшій базі сайтів, що дозволить підвищити оптимальність заказу.

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

4.1 Охорона праці

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

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

Регулювання охорони праці в Україні здійснюється: Конституцією України; Законом України «Про охорону праці» від 21.11.2002 року № 229 - IV ; Законом України «Про загальнообов'язкове державне страхування від нещасних випадків та професійних захворювань» від 08.07.2010 р. № 2-3; Кодексом законів про працю; нормативними актами міністерств, відомств та локальними нормативними актами.

4.1.1 Аналіз будівельно-планувальних особливостей базового об'єкту

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

Загальна площа приміщення 34м², висота - 3м, приміщення має 4 вікна. Кількість працюючих в приміщенні 5 осіб. Отже, на одного працюючого в приміщенні припадає: 34 : 5 = 6,8 (м²/чол.) робочої площі. Можна зробити висновок, що нормативи розмірів та забезпечення працюючих робочою площею дотримано, оскільки норматив складає 6 (м²/чол.), якщо використовуються комп'ютери. Система опалення, вентиляції та світла штучна. За небезпекою ураження електричним струмом управлінське приміщення належить до приміщень без підвищеної небезпеки ураження електричним струмом працюючих. План приміщення наведений на рис. 4.1.

1 - вікна; 2 - робочі столи з комп'ютерами; 3 - шафа; 4 - двері

Рисунок 4.1 - План приміщення економічного відділу ТОВ «Знанія»

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

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

На підприємстві штучне освітлення, яке обладнане системою загального рівномірного освітлення. Застосовують лампи накалювання, потужністю 100 Вт, кількість ламп у світильнику - 2 шт.

4.1.2 Аналіз шкідливих і небезпечних виробничих чинників

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

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

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

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

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

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