51089

ПРОГРАМНА СИСТЕМА УПРАВЛІННЯ ОНЛАЙН ЗАМОВЛЕННЯМИ ЗАКЛАДУ ХАРЧУВАННЯ

Дипломная

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

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

Украинкский

2014-02-10

1.73 MB

11 чел.

Факультет прикладної математики

Кафедра програмного забезпечення комп’ютерних систем

“ЗАТВЕРДЖЕНО”

Завідувач кафедри

__________ І.А. Дичка

“___” ____________ 2011 р.

ПРОГРАМНА СИСТЕМА УПРАВЛІННЯ ОНЛАЙН ЗАМОВЛЕННЯМИ ЗАКЛАДУ ХАРЧУВАННЯ

Пояснювальна записка

ПЗКС.045440-03-81

“ПОГОДЖЕНО”

Керівник проекту:

__________А.В. Петрашенко

Нормоконтроль:                Виконавець:  

   

__________М.В. Онай                 __________А.В. Дяченко

2011

ЗМІСТ

[1] ЗМІСТ

[2] ВСТУП

[3] СПИСОК ТЕРМІНІВ, СКОРОЧЕНЬ ТА ПОЗНАЧЕНЬ

[4] 1. АНАЛІЗ МОВ ПРОГРАМУВАННЯ ТА ТЕХНОЛОГІЙ РОЗРОБКИ ІНТЕРНЕТ МАГАЗИНІВ

[4.1] 1.1. Порівняння мов програмування PHP та C#

[4.2] 1.2. Створення клієнтських додатків для баз даних MS SQL Server

[4.3] 1.3. Особливості створення web-додатків за допомогою ASP .NET

[5] 2. СТРУКТУРА ПРОЕКТУ

[5.1] 2.1. Загальна структура

[5.2] 2.2. Структура бази даних

[5.3] 2.3. Опис ролей системи

[5.4] 2.4. Модуль взаємодії із базою даних

[6] 3. ОПИС РОЗРОБЛЕНИХ АЛГОРИТМІВ

[6.1] 3.1. Опис інтерфейсів користувача

[6.2] 3.2. Алгоритм реєстрації користувачем замовлення

[6.3] 3.3. Алгоритм обробки замовлення персоналом кухні

[7] 4. АНАЛІЗ РОЗРОБЛЕНОГО ПРОЕТУ

[7.1] 4.1. Особливості реалізації

[7.2] 4.2. Порівняння з іншими аналогами

[7.3] 4.3. Рекомендації щодо подальшого вдосконалення

[8] 5. ОХОРОНА ПРАЦІ

[8.1] 5.1. Виявлення та аналіз ШНВШ. Заходи з охорони праці

[8.2] 5.2. Пожежна безпека

[8.3] 5.3. Блискавкозахист

[9] ВИСНОВОК

[10] СПИСОК ВИКОРИСТАНИХ ЛІТЕРАТУРНИХ ДЖЕРЕЛ

[11] ДОДАТКИ

ВСТУП

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

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

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

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

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

В ході виконання роботи було проаналізовано ринок існуючих програмних засобів, мов програмування та технологій розробки інтернет магазинів, їх переваги та недоліки. Таке дослідження дало змогу звернути особливу увагу на усунення знайдених недоліків в розроблюваному програмному продукті. Серед технологій, які використовувались у розробці була використана мова програмування під платформу Microsoft .NET С# та технологія ASP.NET, яка в сукупності із мовою С# та технологією AJAX являє собою сильний інструмент для створення інтернет-сайтів, порталів, магазинів та іншого. Для створення та підтримки бази даних була використана СУБД MS SQL Server 2008.  

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

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

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

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

 

СПИСОК ТЕРМІНІВ, СКОРОЧЕНЬ ТА ПОЗНАЧЕНЬ

ASP –  Active Server Pages (активні серверні сторінки);

HTML – HyperText Markup Language (мова розмітки гіпертексту);

XSLT – Extensible Stylesheet Language Transformations (мова перетворення       XML документів);

XML – eXtensible Markup Language (розширена мова розмітки);

AJAX – Asynchronous Javascript and XML (асинхронний Javascript та XML);

CLR Common Language Runtime (загальне середовище виконання);

ADO ActiveX Data Objects (об’єкти даних ActiveX);

SOAP Simple Object Access Protocol (простий протокол доступу до об’єктів).

1. АНАЛІЗ МОВ ПРОГРАМУВАННЯ ТА ТЕХНОЛОГІЙ РОЗРОБКИ ІНТЕРНЕТ МАГАЗИНІВ

1.1. Порівняння мов програмування PHP та C#

1.1.1. Мова програмування PHP

PHP або Personal Home Page Tools – скриптова мова програмування, була створена для генерації HTML-сторінок на стороні web-сервера. Мова програмування PHP є однією з найпоширеніших мов, що використовуються у сфері web-розробок (разом із Java, .NET, Perl, Python, Ruby). PHP підтримується переважною більшістю хостинг-провайдерів. PHP – проект відкритого програмного забезпечення.

PHP інтерпретується web-сервером в HTML-код, який передається на сторону клієнта.

На відміну від скриптової мови JavaScript, користувач не бачить PHP-коду, бо браузер отримує готовий HTML-код. Це є перевага з точки зору безпеки, але погіршує інтерактивність сторінок.

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

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

Наявні інтерфейси до багатьох баз даних:

  •  вбудовані бібліотеки для роботи з MySQL, PostgreSQL, mSQL, Oracle, dbm, Hyperware, Informix, InterBase, Sybase.
  •  через стандарт відкритого інтерфейсу зв'язку з базами даних (Open Database Connectivity Standard – ODBC) можна підключатися до всіх баз даних, до яких існує драйвер.

Стратегія Open Source, і розповсюдження початкових текстів програм в масах, безсумнівно справили благотворний вплив на багато проектів, в першу чергу – Linux хоч і успіх проекту Apache сильно підкріпив позиції прихильників Open Source. Це відноситься і до історії створення РНР, оскільки підтримка користувачів зі всього світу виявилася дуже важливим чинником в розвитку проекту РНР.

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

Ефективність є дуже важливим чинником при програмуванні для середовищ розрахованих на багато користувачів, до яких належить і web. Важливою перевагою PHP є те, що ця мова належить до інтерпретованих. Це дозволяє обробляти сценарії з достатньо високою швидкістю. За деякими оцінками, більшість PHP-сценаріїв (особливо не дуже великих розмірів) обробляються швидше за аналогічні їм програми, написані на Perl. Проте, щоб не робили розробники PHP, виконувані файли, отримані за допомогою компіляції, працюватимуть значно швидше – в десятки, а іноді і в сотні разів. Але продуктивність PHP цілком достатня для створення цілком серйозних web-застосунків.

  1.  Мова програмування C#

Мовапрограмування C# це об'єктно-орієнтована мова з безпечною системою типізації для платформи Microsoft .NET.

Синтаксис C# близький до С++ і Java. Мова має строгу статичну типізацію, підтримує поліморфізм, перевантаження операторів, вказівники на функції-члени класів, атрибути, події, властивості, винятки, коментарі у форматі XML. Перейнявши багато що від своїх попередників – мов С++, Delphi, Модула і Smalltalk – С#, спираючись на практику їхнього використання, виключає деякі моделі, що зарекомендували себе як проблематичні при розробці програмних систем: так, C# не підтримує множинне спадкування класів (на відміну від C++) або виведення типів (на відміну Haskell).

Мова C# розроблялась як мова програмування прикладного рівня для CLR і, як така, залежить, перш за все, від можливостей самої CLR. Це стосується, перш за все, системи типів C#. Присутність або відсутність тих або інших виразних особливостей мови диктується тим, чи може конкретна мовна особливість бути трансльована у відповідні конструкції CLR. Так, з розвитком CLR від версії 1.1 до 2.0 значно збагатився і сам C#; подібної взаємодії слід чекати і надалі. (Проте ця закономірність порушена з виходом C# 3.0, що є розширеннями мови, що не спираються на розширення платформи .NET.) CLR надає C#, як і всім іншим .NET-орієнтованим мовам, багато можливостей, яких позбавлені «класичні» мови програмування. Наприклад, збірка сміття не реалізована в самому C#, а проводиться CLR для програм, написаних на C#.

Специфікація C# визначає мінімальний набір бібліотек типів і класів, на який має розраховувати компілятор. На практиці, C# найчастіше використовується з якоюсь реалізацією Common Language Infrastructure.

1.2. Створення клієнтських додатків для баз даних MS SQL Server

 1.2.1. База даних MS SQL Server

Microsoft SQL Server – це комерційна система керування базами даних, що розповсюджується корпорацією Microsoft. Мова, що використовується для запитів до неї це Transact-SQL. Використовується як для невеликих і середніх за розміром баз даних, так і для великих баз даних масштабу підприємства [4].

Останні дві версії продукту це SQL Server 2005 та SQL Server 2008.

SQL Server 2005 є наступником SQL Server 2000. На додаток до системи керування реляційними базами даними включає також систему керування даними XML. Для цього було визначено тип даних xml, який може використовуватись або як тип даних у стовпцях таблиць бази даних, або як літерал у запитах. XML-стовпці можуть бути асоційовані з схемами XSD (збережені дані XML перевіряються схемами). Перед збереженням у базі даних XML перетворюється на двійковий тип даних. Були розроблені спеціальні індексуючи методи для даних XML. Дані XML запитуються з використанням XQuery (до SQL Server 2005 доданий деякі розширення до мови T-SQL, що дозволяють вкладення запитів XQuery до T-SQL). Крім того, були визначені нові розширення XQuery, названі XML DML, які дозволяють робити з даними XML модифікації на основі запитів. SQL Server 2005 також дозволяє серверу бази даних бути оприлюдненим через web-сервіси з використанням пакетів TDS, що приховані у запитаз SOAP. Коли дані доступні web-сервіси, результати повертаються як XML. Стосовно реляційних даних, до T-SQL були додані властивості керування помилками та підтримка рекурсивних запитів. SQL Server 2005 також включає нові алгоритми індексування та покращену систему відновлення після помилок. Сторінки даних стали містити контрольну суму для кращого відновлення після помилок, також була додана підтримка оптимістичного паралелізму. Контроль дозволів і доступу був зроблений більш детальним, а процесор запитів став керувати паралельним виконанням запитів у більш ефективний спосіб. Природно, підтримується поділ на таблиці та індекси, тому масштабування бази даних на кластери відбувається легше. До SQL Server 2005 було введене CLR SQL, що дозволило йому об'єднатися з платформою .NET Framework.

Мета випуску SQL Server 2008 це зробити керування даними самоналаштовуваним, самоорганізованим та самопідтримуваним. SQL Server 2008 також включає підтримку структурованих і напівструктурованих даних, у тому числі цифрові медіа-формати для зображень, звуків, відео й інших мультимедійних даних. Ключовим нововведенням SQL Server 2008 є розвинені засоби управління ресурсами (resource governor), що дозволяють ефективно управляти і розподіляти робоче навантаження за допомогою відстежування рівня завантаження процесора і обсягу пам'яті, що займають працюючі застосунки. Microsoft виділяє засоби управління на основі політик, розширені можливості з складання звітів і проведенню аналізу, а також розвинені засоби управління інтелектуальними ресурсами підприємства.

Серед нових можливостей і удосконалень Microsoft SQL Server 2008 це поява нових типів даних, а саме просторових даних, кращу сумісність з застосунками сторонніх розробників, наприклад Oracle, тіснішу інтеграцію з Office, оптимізовані засоби шифрування даних, засоби управління на основі політик, а також покращені інструменти звітності і аналізу.

Microsoft SQL Server в якості мови запитів використовує версію SQL, що отримала назву TRANSACT-SQL (скорочено T-SQL), з багатьма розширеннями. T-SQL дозволяє використовувати додатковий синтаксис процедур, що зберігаються і забезпечує підтримку транзакцій (взаємодія бази даних з керуючим застосунком).

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

SQL Server підтримує надлишкове дублювання даних за трьома сценаріями:

  •  знімок;
  •  історія змін;
  •  синхронізація з іншими серверами.

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

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

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

SQL Server 2005 має вбудовану підтримку .NET Framework. Завдяки цьому, процедури бази даних, що зберігаються, можуть бути написані на будь-якій мові платформи .NET з використанням повного набору бібліотек, доступних для .NET Framework. На відміну від інших процесів, .NET Framework виділяє додаткову пам'ять і будує засоби керування SQL Server, не використовуючи вбудовані засоби Windows. Це підвищує продуктивність порівняно із загальними алгоритмами Windows, оскільки алгоритми розподілу ресурсів спеціально налагоджені для використання у структурах SQL Server.

1.2.2. Технологія ADO.NET

Один із засобів реалізації клієнтської частини програми взаємодії із Microsoft SQL Server надає технологія ADO.NET.

ADO.NET або ActiveX Data Objects .NET це наборім класів, що реалізують програмні інтерфейси для полегшення підключення до баз даних з програми незалежно від особливостей реалізації конкретної системи управління базами даних і від структури самої бази даних, а також незалежно від місця розташування цієї самої бази, зокрема, в розподіленому середовищі (клієнт-серверний додаток) на стороні сервера. ADO.NET широко використовується спільно з технологією web-програмування з використанням об'єктів ASP.NET для доступу до розташованих на сервері баз даних з боку клієнта. Рішення навіть найпростішої задачі, пов'язаної з даними, передбачає використання безлічі різноманітних об'єктів представників класів ADO.NET, які знаходяться між собою в досить складних взаєминах.

Робота з базою даних на рівні додатку це робота:

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

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

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

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

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

Недоліки такого підходу стали виявлятися після появи додатків, орієнтованих на Інтернет.

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

Факт поганого масштабування додатків з постійним з'єднанням відомий давно. З'єднання з парою клієнтів обслуговується додатком добре, 10 клієнтів обслуговуються гірше, 100 набагато багато гірше.

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

Модель доступу це модель компромісна. У ряді випадків вона програє за продуктивністю традиційної моделі, і для цих випадків рекомендується замість ADO.NET використовувати ADO.

Об'єктна модель ADO.NET реалізує від'єднаний доступ до даних. При цьому в середовищі Visual Studio .NET існує безліч вбудованих майстрів і дизайнерів, які дозволяють реалізувати механізми доступу до бази даних ще на етапі розробки програмного коду.

З іншого боку, завдання отримання доступу до даних може бути вирішена безпосередньо під час виконання програми. Концепція доступу до даних в ADO. NET заснована на використанні двох компонентів:

  •  набору даних (представляється об'єктом класу DataSet) з боку клієнта. Це локальне тимчасове сховище даних;
  •  провайдера даних (представляється об'єктом класу DataProvider). Це посередник, що забезпечує взаємодію програми та бази даних з боку бази даних (в розподілених додатках з боку сервера).

Об'єктна модель ADO.NET передбачає існування (при написанні програми для роботи з базою даних використання) двох множин класів, виконують чітко визначені завдання при роботі з базою даних: класи приєднаних об'єктів, класи від'єднаних об'єктів.

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

1.3. Особливості створення web-додатків за допомогою ASP .NET

ASP.NET це технологія створення web-застосунків і web-сервісів від компанії Microsoft. Вона є складовою частиною платформи Microsoft .NET і розвитком старішої технології Microsoft ASP. На даний момент останньою версією цієї технології є ASP.NET 4.0 [7].

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

Хоча ASP.NET бере свою назву від старої технології Microsoft ASP, вона значно від неї відрізняється. Microsoft повністю перебудувала ASP.NET, грунтуючись на Common Language Runtime (CLR), який є основою всіх застосунків Microsoft. NET. Розробники можуть писати код для ASP.NET, використовуючи практично будь-які мови програмування, що входять у комплект. NET Framework (C#, Visual Basic.NET, і JScript. NET). ASP.NET має перевагу у швидкості в порівнянні зі скриптовими технологіями, тому що при першому зверненні код компілюється і поміщається в спеціальний кеш, і згодом тільки виконується, не вимагаючи витрат часу на парсинг, оптимізацію, і т. д.

Основні переваги ASP.NET перед ASP це:

  •  компільований код виконується швидше, більшість помилок відловлюється ще на стадії розробки;
  •  значно поліпшена обробка помилок часу виконання, з використанням блоків try .. catch;
  •  користувальницькі елементи управління (controls) дозволяють виділяти часто використовувані шаблони, такі як меню сайту;
  •  використання метафор, вже застосовуються в Windows-застосунках, наприклад, таких як елементи керування та події;
  •  розширюваний набір елементів управління і бібліотек класів дозволяє швидше розробляти за стосунки;
  •  ASP.NET спирається на багатомовні можливості .NET, що дозволяє писати код сторінок на VB.NET, Delphi.NET, Visual C/C++ тощо;
  •  можливість кешування всієї сторінки або її частини для збільшення продуктивності;
  •  можливість кешування даних, що використовуються на сторінці;
  •  можливість поділу візуальної частини та бізнес-логіки з різних файлів («code behind»);
  •  розширювана модель обробки запитів;
  •  розширена подієва модель;
  •  розширювана модель серверних елементів керування;
  •  наявність master-сторінок для завдання шаблонів оформлення сторінок;
  •  підтримка CRUD-операцій при роботі з таблицями через GridView;
  •  вбудована підтримка AJAX;
  •  ASP.NET має перевагу у швидкості в порівнянні з іншими технологіями, заснованими на скрипковій мові.

Технологія ASP.NET це об'єктно-орієнтована модель розробки Web-додатків. Самі ASP.NET-сторінки є об'єктами класів. Можна створювати програмний код з можливістю його повторного використання класами. Ці класи можна використовувати для створення екземплярів об'єктів.

Об'єктна модель являє собою  ієрархію об'єктів, що надають розробникам певні особливості. У ASP.NET використовується нова структура Web-сторінок, яка відрізняється від структури ASP-сторінок і забезпечує підтримку об'єктної моделі для збереження вмісту ASP.NET-сторінки. Додано новий клас елементів управління серверні елементи управління. Можна додавати власні коментарі і пов'язувати ці дані з серверними елементами управління. Для оформлення Web-сторінок є набори директив, які призначені для установки параметрів. Наприклад, параметри TraceContext і isEnabled дозволяють, відповідно, включити і вимкнути механізм відстеження web-запитів.  

Дані про сеанс роботи кожного окремого користувача зберігає об'єкт «session». Об'єкт «application» використовується для зберігання глобальних змінних, які містять інформацію, загальнодоступну для всіх користувачів Web-додатка, наприклад, вітальне повідомлення або індекс відвідування Web-сторінки. Цей об'єкт є колекцією різнорідних елементів. Користувачі спільно використовують об'єкти Web-додатки, тому потрібно гарантувати, що кілька користувачів не зможуть одночасно змінювати змінні, що зберігаються в об'єкті application. Для блокування вмісту колекції об'єктів від зміни застосовується метод Lock, для розблокування метод Unlock. Так само існують методи Contents.Remove і Contents.RemoveAll, які видаляють один елемент із сімейства Contents або все відразу відповідно.

За допомогою об'єкта ObjectContext виконується фіксація або відкат транзакцій, керованих MTS. Транзакції можуть бути ініційовані зі сторінки ASP.NET. Методи SetComplete і SetAbort об'єкта ObjectContext використовуються, відповідно, для фіксації і відкоту транзакцій.

Об'єкт response можна використовувати для передачі вихідної інформації клієнтові. Методи об'єкта response:

  •  AddHeader   встановлює заголовок HTML ім'я рівним значенню;
  •  AppendToLog додає рядок в кінець запису журналу webсервера, що відноситься до цього запиту;
  •  BinaryWrite   записує надану інформацію в поточний висновок HTTP без перетворення наборів символів;
  •  Clear стирає будь буферізованние висновок HTTP;
  •  End зупиняє обробку файлу .asp і повертає поточний результат;
  •  Flush негайно передає буферізованние висновок;
  •  Redirect  відправляє оглядачеві повідомлення про перенаправлення, викликаючи спробу оглядача підключитися до іншого URL;
  •  Write записує змінну у вигляді рядка в поточний висновок HTTP.

В об'єкті request зберігається інформація, що відправляється браузером клієнта на сервер в HTTP-запиті. Після обробки запиту за допомогою об'єкта request користувачеві відправляється відповідна інформація. За допомогою методу BinaryRead об'єкт request отримує дані, передані клієнтом серверу, як частину запиту POST.

Об'єкт server дозволяє отримати доступ до властивостей і методів Web-сервера. За допомогою методу СreateObject можна створити екземпляр об'єкта server, Execute виконує файл .asp. Так само існує можливість співставлення зазначеного віртуального шляху з фізичним шляхом це робить метод MapPath. А Transfer передає всю інформацію про поточний стан іншого файлу .аsp для обробки.

Об'єкт session використовується для зберігання інформації про користувача сеансах. Значення змінних об'єкта session зберігаються, навіть коли користувач переходить на іншу сторінку Web-додатки. Цей об'єкт створюється при організації користувачем сеансу і знищується при його завершенні. Наприклад, в ньому можна зберігати реєстраційну інформацію кожного користувача, який відвідує сайт віртуального магазину. Ця інформація залишається доступною для всього Web-додатки навіть при переході користувача на інші Web-сторінки сайту. Об'єкт session використовує три методи: Abandon для знищення об'єкт session та звільнення його ресурсів, а Contents.Remove і Contents.RemoveAll для видалення одного елемента або всіх елементів з сімейства Contents відповідно.  

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

Модель відокремленого коду (code-behind) ASP.NET надає перевагу винесення прикладного коду з HTML-розмітки в файл відокремленого коду. Ця модель передбачає створення для кожної Web-сторінки ASP.NET двох файлів: файлу розмітки (.аspx) з дескрипторами HTML і дескрипторами елементів управління, і файлу коду (.сs) з вихідним кодом сторінки (за умови, що для програмування Web-сторінки застосовується мова C#). Така модель забезпечує більш зручну схему організації, дозволяючи відокремлювати користувальницький інтерфейс від програмної логіки, що має дуже важливе значення при створенні складних сторінок.  

Для вказівки використовуваного класу в сторінці .aspx застосовується атрибут Inherits, а для вказівки класу, в якому міститься відокремлений код-атрибут CodeFile:

Приклад:

 <% @ Page Language = "C #" AutoEventWireup = "true" CodeFile = "MyTestCodePage.aspx.cs" Inherits = " MyTestCodePage "%>  

Web-сторінки в Web-проектах завжди використовують модель відокремленого коду. Однак вони включають один додатковий файл з розширенням .aspx.desginer.cs, в якому містяться оголошення для всіх наявних на них елементів керування. Це означає, що якщо створити сторінку з ім'ям Default.aspx, то можна отримаєте файл Default.aspx.cs з класом відокремленого коду і файл Default.aspx.designer.cs з оголошеннями елементів управління. Під час компіляції ці два файли будуть об'єднані. У беспроектном Web-сайті файли з оголошеннями елементів управління створені не будуть, оскільки ця частина коду генерується під час компіляції системою ASP.NET.

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

Технологія ASP.NET тісно взаємодіє із технологією AJAX.

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

  •  стандартні засоби відображення сторінок, такі як (X) HTML і CSS;
  •  динамічні засоби відображення інформації та взаємодії з користувачем – Document Object Model;
  •  обмін даними та їх обробка – XML та XSLT;
  •  механізми асинхронної передачі даних з сервера за допомогою об'єкта XMLHttpRequest;
  •  JavaScript, який об'єднує все це разом.

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

 Використання AJAX дозволяє створювати набагато зручніші web-інтерфейси користувача на тих сторінках сайтів, де необхідна активна взаємодія з користувачем.

2. СТРУКТУРА ПРОЕКТУ

Наочне зображення загальної структури варіантів використання розробленої системи наведено на рис. 1.

Рис. 1. Схема варіантів використання wсистеми

У системі можна виділити наступні варіанти використання (Use Case):

  •  UC01: замовник може обрати страву з меню;
  •  UC02: адміністратор може модифікувати меню та переглядати статистику;
  •  UC03: повинен бути список страв, які необхідно приготувати на кухні;
  •  UC04: повинен бути список страв приготованих на кухні та страв, характер яких не зв’язаний із приготуванням на кухні (наприклад, напої);
  •  UC05:  кожен користувач має бути авторизованим та мати доступ до тих модулів, на які поширюються його права.

2.1. Загальна структура

2.1.1. UC01: вибір замовником страви

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

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

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

2.1.2. UC02: редагування та перегляд статистики

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

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

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

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

2.1.3. UC03: обробка замовлення персоналом кухні

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

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

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

2.1.4. UC04: обробка замовлення персоналом доставки

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

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

Кожне замовлення в списку має статуси: «зроблено на кухні», «зроблено не на кухні», «готові до відвантаження», «доставка», «доставлене», що дає додаткові можливості для моніторингу за станом замовлення.

Список приготованих та готових до відправки страв також сортується за часом.

2.1.5. UC05: реєстрація та авторизація користувача

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

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

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

Привілеї співробітників полягають у наступному:

  •  право бачити і працювати зі сторінкою кухні;
  •  право бачити і працювати зі сторінкою доставки.

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

2.2. Структура бази даних

2.2.1. Таблиці зберігання інформації про замовлення

Рис. 2. Таблиці бази даних які відносяться до інформації про  замовлення

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

Таблиця «Orders» призначена для реєстрації замовлення для певного користувача, містить наступні поля:

  •  OrderId  поле ідентифікації запису у таблиці;
  •  UserId  містить ідентифікаційний номер користувача, для якого створене замовлення;
  •  Status – містить номер поточного статусу замовлення;
  •  OrderDate – поле дати створення замовлення.

Таблиця «OrderItems» призначена для зберігання інформації про певні страви, обрані користувачем для одного ордеру. Містить наступні поля:

  •  OrderItemId поле ідентифікації запису у таблиці;
  •  OrderId – поле показує, до якого номеру ордеру відносить поточний запис;
  •  UserId – поле показує, до якого користувача відноситься поточний запис;
  •  DishId – поле вказує ідентифікаційний номер страви даного запису;
  •  Count – поле містить кількість обраних користувачем страв;
  •  Price – поле містить ціну, за якою було зроблено замовлення;
  •  StatusItem – поле зберігає поточний статус даного елемента замовлення.

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

  •  DishId  поле ідентифікації запису у таблиці;
  •  Name – поле містить назву даної страви;
  •  Description – поле містить опис страви;
  •  DishType – поле вказує тип страви, на основі доступних у таблиці DishType полів генерується меню;
  •  Structure – поле містить короткий опис структури;
  •  Price – поле містить поточну ціну страви;
  •  Kitchened – поле зберігає статус страви, який позначає відноситься ця страва до тих, що готуються на кухні чи ні;
  •  DishStatus – поле позначає статус доступності страви в даний момент;
  •  WeekDish поле містить позначення, яке визначає чи є ця страва стравою тижня.

Таблиця «DishesPhoto» призначена для зберігання фотографії страви. Містить наступні поля:

  •  DishPhotoId – поле ідентифікації запису у таблиці;
  •  DishType – поле вказує, до якої страви належить дана фотографія;
  •  DishPhoto – поле зберігає фотографію.

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

Таблиця «DishType» призначена для зберігання інформації про типи страв. На основі їх формуються головні елементи меню. Містить наступні поля:

  •  DishTypeId поле ідентифікації запису у таблиці;
  •  DishType – поле зберігає тип страви у вигляді числа;
  •  DishTypeValue – поле зберігає строкове значення типу страви.

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

  •  Meats (Страви із м’яса);
  •  Fishes (Страви із риби);
  •  Sushi (Суші);
  •  Birds (Страви із птиці);
  •  Soups (Супи);
  •  Salads (Салати);
  •  Vegetables (Страви із овочів);
  •  Garnish (Гарніри);
  •  Drinks (Напої);
  •  Other (Інші страви).

Таблиця «StatusType» призначена для зберігання можливих типів статусів, наприклад статус для замовлення або для страви . Містить наступні поля:

  •  StatusId поле ідентифікації запису у таблиці;
  •  StatusType – поле містить тип статусу.

У таблиці «StatusType» представлені наступні типи статусів:

  •  Order (Тип статусів для замовлень);
  •  Order Item (Тип статусів для елементів замовлення);
  •  Dishes (Тип статусів для страв).

Таблиця «Statuses» призначена для зберігання можливих статусів. Містить наступні поля:

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

У таблиці «Statuses» представлені статуси трьох типів.

Статуси для типу «Order»:

  •  Not completed;
  •  Confirm;
  •  Processing;
  •  Ready for delivery;
  •  Delivering;
  •  Delivered.

Статуси для типу «OrderItem»:

  •  Not ready;
  •  Ready.

Статуси для типу «Dishes»:

  •  Not available;
  •  Avaliable.

2.2.1 Таблиці зберігання інформації про користувача

Рис. 3. Таблиці бази даних які відносяться до інформації про користувача

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

Таблиця «Users» призначена для зберігання необхідної інформації про користувача. Основні поля:

  •  UserId  поле ідентифікації запису у таблиці;
  •  UserName – поле зберігає ім’я користувача;
  •  DateOfBirthday – поле зберігає дату народження користувача;
  •  MobileAliass – поле зберігає номер контактного мобільного телефону користувача;
  •  IsAnonymous – чи є користувач авторизованим у системі.

Таблиця «MemberShip» призначена для зберігання додадкової інформації про користувача. Основні поля:

  •  UserId  поле ідентифікації, до якого користувача відноситься запис у таблиці;
  •  Password – поле зберігає пароль користувача;
  •  Email – поле зберігає електронну адресу користувача;
  •  CreateDate – поле зберігає дату створення акаунту користувача системи.

Таблиця «Roles» призначена для зберігання інформації про ролі, які визначені для користувачів. Основні поля:

  •  RoleId – поле ідентифікації запису у таблиці;
  •  RoleName – поле зберігає назву ролі, визначеної для користувача.

Таблиця «UsersInRoles» призначена для зберігання інформації про користувачів та ролі які їм належать. Основні поля:

  •  UserId  поле ідентифікації користувача;
  •  RoleId – поле ідентифікації ролі.

У системі передбачені наступні ролі:

  •  гість (guest);
  •  адміністратор (admin);
  •  кухар (cooker);
  •  кур’єр (deliver).

 Ролі користувачів зберігаються у таблиці «Roles» бази даних.

2.3. Опис ролей системи

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

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

Зареєстрований користувач який належить до персоналу закладу має певні права. Так адміністратори, наприклад, мають роль «admin», та мають певні особливі можливості а саме доступ до деяких елементів  меню (рис. 4), недоступних для інших користувачів.

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

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

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

Наступний користувач системи з певними правами це кухар. Кухар має роль «cooker» у системі. Це користувач, який має доступ до сторінки із списком замовлень відфільтрованих для виконання на кухні (рис. 5), тобто страв які повинні бути приготовані, наприклад стек чи салат, а не інші типу різних напоїв.

Рис. 5. Вигляд меню для користувача з правами кухаря

Користувачу з правами кухара доступний елемент меню «Kitchen», який дозволяє перейти на сторінку персоналу кухні саме користувачу який має роль «cooker».

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

Рис. 6. Вигляд меню для користувача з правами кур’єра

Користувачу з правами кур’єра доступний елемент меню «Delivery» (рис. 6),  який дозволяє перейти на сторінку персоналу, який відповідає за доставку а  саме користувачам які має роль «deliver».

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

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

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

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

2.4. Модуль взаємодії із базою даних

Модуль взаємодії із базою даних являє собою клас із деякими приватними полями, недоступними для зовнішнього користування та списком методів, доступних для зовнішнього користування та за допомогою яких можливо виконувати певні операції із базою даних. Умовна внутрішня структура модуля зображена на рис. 3. В основі модуля взаємодії із базою даних лежить технологія ADO.NET, за допомогою неї здійснюються запити та внесення та отримання інформації. ADO.NET широко використовується спільно з технологією web-програмування з використанням об'єктів ASP. NET для доступу до розташованих на сервері баз даних з боку клієнта 

Рис. 7. Блок операцій із базою даних

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

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

  •   private string connStr.

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

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

Функція вибору всіх страв із бази даних: 

  •  public List<Dish> GetAllDishes(ref SqlCacheDependency dep).

Функція «GetAllDishes» приймає параметр змінну «dep» типу «SqlCacheDependency», ця змінна потрібна для того, щоб провести кешування даних, щоб актуальність елементів меню співпадала із даними в базі. Вона повертає або задає рядок, який показує, які бази даних і таблиці використовуються для залежності кеша Microsoft SQL Server.

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

Функція вибору страви тижня із бази даних:

  •  public Dish GetWeekDish().

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

Повертає функція об’єкт класу «Dish», він формується у тілі функції на основі даних з бази.

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

  •  public List<DishType> GetAllTypeOfDishes(ref SqlCacheDependency dep).

Функція «GetAllTypeOfDishes» приймає параметр змінну dep типу «SqlCacheDependency», ця змінна потрібна для того, щоб провести кешування даних, щоб актуальність головних елементів меню співпадала із даними в базі.

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

Функція створення замовлення для користувача в базі даних:

  •  public int createOrderForUser(Guid id).

Функція «createOrderForUser» приймає параметр змінну «id» типу «Guid», ця змінна позначає ідентифікаційний номер користувача, для якого в базі даних створюється запис в таблиці «Orders», де зберігаються дані про замовлення

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

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

  •  public Guid insertAnnonymUser(AnonymUser user).

Функція «insertAnnonymUser» приймає параметр  «user» типу «AnonymUser» який містить інформацію реєстрації анонімного користувача.

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

Функція отримання із бази даних адреси користувача:

  •  public String GetUserAddress(Guid userID).

Функція «GetUserAddress» приймає параметр  «userID типу «Guid» який містить ідентифікаційний номер користувача.

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

Функція отримання ідентифікаційного номеру користувача із бази даних:

  •  public Guid GetUserIdByOrderID(int orderID).

Функція «GetUserIdByOrderID» приймає параметр  «orderID» типу «int» який містить номер замовлення.

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

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

  •  public List<Orders> GetAllOrders(ref SqlCacheDependency dep).

Функція «GetAllOrders» приймає параметр змінну «dep» типу «SqlCacheDependency», ця змінна потрібна для того, щоб провести кешування даних, щоб актуальність списку замовлень у вигляді меню співпадала із даними в базі.

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

Функція позначення страви у списку замовлень як виконану:

  •  public void  dishCompleated(Dish dish, int orderid).

Функція «dishCompleated» приймає параметр змінну «dish» типу «Dish» та параметр «orderid» типу «int». Змінна «dish» це страва яку необхідно посначити а змінна «orderid» це номер замовлення для якого виконується ця операція.

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

Функція позначення замовлень як виконане у базі даних:

  •  internal void setOrderStatusFinish(int p).

Функція «setOrderStatusFinish» приймає параметр змінну «p» типу «int». Даний параметр позначає номер замовлення для якого виконані всі його елементи. У тілі функції проходить звернення до таблиці бази даних «Orders» та зміна статусу замовлення у ній.

Функція позначення замовлень як доставлене у базі даних:

  •  public void deliveringStatusForOrder(int orderid).

Функція deliveringStatusForOrder приймає параметр змінну «orderid» типу «int». Даний параметр позначає номер замовлення для якого потрібно змінити статус на «доставляється». У тілі функції проходить звернення до таблиці бази даних «Orders» та зміна статусу замовлення у ній.

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

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

  •  public void updateDish(Dish dish).

Функція «updateDish» приймає параметр змінну «dish» типу «Dish». Даний параметр позначає страву інформацію про яку необхідно оновити. Клас «Dish»  являє собою відображення структури таблиці «Dishes» бази даних у системі. У тілі функції проходить звернення до таблиці бази даних та зміна усіх елементів страви. Так як клас  «Dish» є повним відображенням таблиці в системі він також містить та ідентифікаційний номер страви, отже зміна пройде успішно.

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

Функція додання нової страви у базу даних:

  •  public void addDish(Dish dish).

Функція «addDish» приймає параметр змінну «dish» типу «Dish». Даний параметр позначає страву інформацію про яку необхідно внести до бази. У тілі функції проходить звернення до таблиці бази даних та внесення інформації про нову страву. Ідентифікаційний номер страви при внесенні її до бази створиться автоматично на основі ідентифікаційного поля таблиці «Dishes».

Функція використовується персоналом адміністрації, коли потрібно внести нову страву, адміністратор використовує теж вікно що і для редагування але обравши пункт меню «new dish» усі поля редагування будуть пустими для внесення нової інформації .

Функція видалення страви із бази даних:

  •  public void removeDish(int id).

Функція «removeDish» приймає параметр змінну «id» типу «int». Даний параметр позначає ідентифікаційний номер страви яку необхідно видалити із бази. У тілі функції проходить звернення до таблиці бази даних «Dishes» та видалення страви по параметру «id».

Функція використовується персоналом адміністрації, коли потрібно видалити страву, адміністратор використовує теж вікно що і для редагування. Персоналу у разі редагування будуть доступні кнопки «Refresh» та «Delete». За допомогою останньої інформація про страву буде видалена.

3. ОПИС РОЗРОБЛЕНИХ АЛГОРИТМІВ

3.1. Опис інтерфейсів користувача

Інтерфейси користувача були розроблені згідно із варіантами використання системи.

  Варіант перший, де замовник може обрати страву з меню (рис. 8).

Рис. 8. Сторінка вибору страви

Інтерфейс головної сторінки складається з таких елементів:

  •  шапка сторінки;
  •  головне меню сайту;
  •  основна частина сторінки.

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

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

Основна частина сторінки, складається із трьох частин.

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

  •  назву;
  •  актуальну ціну;
  •  фотографію готової страви.;
  •  опис;
  •  структуру.

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

Варіант другий, де адміністратор може модифікувати меню та переглядати статистику (рис. 9).

Рис. 9. Сторінка адміністратора для редагування елементів меню

Інтерфейс головної сторінки складається з таких елементів:

  •  шапка сторінки;
  •  меню ресторану для адміністратора сайту;
  •  основна частина сторінки.

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

Головне меню сайту у першій частині містить елементи посилання на інші частини сайту, деякі із них аналогічне попереднім описам окрім того що, як видно з рис. 8 з’явились додаткові елементи меню «Modify» та «Statistic», які доступні користувачу системи admin, який має відповідні права адміністратора.

Основна частина сторінки, складається із трьох частин.

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

Друга – це опис обраної страви, містить інформацію про страву у вигляді елементів для редагування інформації, зміни страви тижні, містить наступні елементи:

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

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

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

На рис. 10 зображений елемент меню new dish, за допомогою якого можна додати нову страву, а всі елементи для редагування за замовчанням стануть пустими. Також замість кнопок редагування та видалення страви з’явиться кнопка додання страви.

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

Рис. 11. Сторінка статистики популярності страв

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

  •  шапка сторінки;
  •  головне меню сайту;
  •  основна частина сторінки.

Шапка сторінки аналогічна попереднім описам, так само як і головне меню.

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

  •  назва;
  •  кількість;
  •  ціна.

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

Варіант третій, де замовлення представляються у вигляді списку страв, які необхідно приготувати на кухні (рис. 12):

Рис. 12. Сторінка персоналу кухні

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

  •  шапка сторінки;
  •  головне меню сайту;
  •  основна частина сторінки.

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

Головне меню сайту у першій частині містить елементи посилання на інші частини сайту, деякі із них аналогічне попереднім описам окрім того що, як видно з рис. 12 з’явився додатковий елемент меню «Kitchen», який доступний користувачу системи «cooker», який має відповідні права персоналу кухні.

Основна частина сторінки, складається із трьох частин.

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

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

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

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

Номер замовлення – це порядковий номер надходження замовлення до бази даних.

Дата створення замовлення – це дата коли замовлення було зареєстроване замовником.

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

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

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

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

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

Рис. 13. Сторінка персоналу доставки

Інтерфейс сторінки персоналу доставки (рис. 13) складається з таких елементів:

  •  шапка сторінки;
  •  головне меню сайту;
  •  основна частина сторінки.

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

Основна частина сторінки, складається із трьох частин.

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

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

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

Номер замовлення – це порядковий номер надходження замовлення до бази даних.

Дата створення замовлення – це дата коли замовлення було зареєстроване замовником.

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

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

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

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

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

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

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

Рис. 14. Сторінка реєстрації користувача

Інтерфейс сторінки реєстрації користувача (рис. 14) складається з таких елементів:

  •  шапка сторінки;
  •  головне меню сайту;
  •  основна частина сторінки.

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

Основна частина сторінки, складається із двох частин.

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

  •  ім’я користувача;
  •  пароль;
  •  підтвердження паролю;
  •  електронна адреса;
  •  дата народження;
  •  телефонний номер;
  •  адреса доставки.

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

Якщо користувач має профіль у системі він може увійти до нього ввівши свій логін та пароль (рис. 15).

Рис. 15. Сторінка авторизації користувача

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

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

Рис. 16. Сторінка короткої реєстрації користувача

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

  •  шапка сторінки;
  •  головне меню сайту;
  •  основна частина сторінки.

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

Основна частина сторінки, складається із двох частин.

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

  •  ім’я користувача;
  •  телефон;
  •  адреса.

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

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

Рис. 17. Сторінка кошику користувача

Інтерфейс сторінки короткої реєстрації користувача (рис. 17)  складається з таких елементів:

  •  шапка сторінки;
  •  головне меню сайту;
  •  основна частина сторінки.

Основна частина сторінки, складається із двох частин.

Перша – це форма кошику і вигляді таблички, у якій присутні наступні стовпці даних:

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

Друга частина – це кнопка реєстрації замовлення та інформація про загальну суму замовлення.

3.2. Алгоритм реєстрації користувачем замовлення

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

До того моменту, коли користувач побачить сторінку із меню але після того як він зробить запит на дану адресу система виконає етап зв’язку із базою даних, для отримання інформації на основі якої відбудеться відображення меню. А саме за допомогою модуля зв’язку із базою даних «DB_Operation», на етапі формування сторінки, відбудеться запит функції модуля «GetAllTypeOfDishes»  до таблиці «DishType», яка отримає список усіх наявних типів страв для формування головних елементів меню. У таблиці містяться наступні елементи:

  •  Meats (Страви із м’яса);
  •  Fishes (Страви із риби);
  •  Sushi (Суші);
  •  Birds (Страви із птиці);
  •  Soups (Супи);
  •  Salads (Салати);
  •  Vegetables (Страви із овочів);
  •  Garnish (Гарніри);
  •  Drinks (Напої);
  •  Other (Інші страви).

Отже головні елементи меню матимуть саме такі назви, які відповідають типам страв

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

Наступним кроком буде отримання інформації про страву тижня. Цей етап також формується на етапі завантаження сторінки. Виконавши функцію модуля «DB_Operation», яка отримує страву позначену як страва тижня, а саме «GetWeekDish» система отримає страву, яка буде відображена користувачеві на головній сторінці. Користувачеві буде відображена наступна інформація про страву:

  •  назва;
  •  актуальна ціна;
  •  фотографія готової страви.;
  •  опис;
  •  структура.

Пройшовши всі етапи формування головна сторінка буде відображена користувачеві.

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

Сесія дозволяє зберігати дані користувача у пам’яті доки він користується системою та переходить між сторінками. Кошик користувача зберігається у сесії у вигляді списку об’єктів типу «Dish», який відображає інформацію про страву у базі даних у вигляді доступному для обробки у системі. На всіх сторінках у шапці сайту у правому кутку відображається іконка кошику. Вона відображає поточний стан кошику, може бути два стани: пустий та не пустий (рис. 18).

Рис. 18. Стани іконки кошику

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

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

Рис. 19. Таблиця замовлення користувача

Таблиця містить наступні елементи

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

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

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

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

  •  ім’я користувача;
    •  телефон;
    •  адреса.

Але також буде посилання «Have account?», яке перенаправить користувача, у разі натиснення, якщо він має власний зареєстрований профіль у системі, на сторінку авторизації.

При натисненні кнопки «Create» перед внесенням даних в базу, система проводить валідацію. Наприклад, якщо поле імені буде пустим, поле адреси буде пустим, або поле номеру телефону буде пустим чи не відповідатиме формату то буде видане повідомлення про помилку та внесення даних не відбудеться. Правильний формат телефону це (xxx)xxx-xx-xx, де х – це цифра. Підказка щодо правильного формату дається сірим текстом користувачеві і полі введені телефону.  Якщо ж дані успішно пройшли валідацію то система зробить звернення до модуля зв’язку із базою даних «DB_Operation»  для виклику функції «insertAnnonymUser». Функція вносить дані про користувача та перенаправляє його на зад на сторінку кошику. На сторінці кошику відбувається реєстрація замовлення користувача за допомогою функції «CreateOrderForUser» де вхідним параметром буде ідентифікаційний номер щойно зареєстрованого користувача. Реєстрація відбувається на етапі формування сторінки і вже на сформованій сторінці користувач побачить повідомлення про успішну реєстрацію та адресу на яку буде доставлене замовлення.

Інший варіант замовлення можливий у тому випадку, якщо користувач має власний профіль, тоді він може увійти до систему натиснувши посилання «Sign in» на правій  стороні головного меню сайту або натиснувши «Have account?» на формі короткої реєстрації.  У цьому випадку його буде пере направлено на сторінку авторизації, де ввівши свій логін та пароль користувач авторизується у системі.

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

3.3. Алгоритм обробки замовлення персоналом кухні

Після етапу реєстрації замовлення, наступним є етап обробки замовлення персоналом кухні.

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

До того моменту, коли користувач побачить сторінку кухні але після того як він зробить запит на дану адресу система виконає етап зв’язку із базою даних, для отримання інформації на основі якої відбудеться відображення елементів замовлення у вигляді меню. А саме за допомогою модуля зв’язку із базою даних «DB_Operation», на етапі формування сторінки, відбудеться запит функції модуля «GetAllOrders»  до таблиці «Orders», яка отримає список усіх наявних замовлень для  формування елементів меню.

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

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

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

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

Коли персонал кухні виконає даний  елемент замовлення та натисне кнопку «done» елемент зникне зі списку та буде помічений у базі даних як готовий, у разі готовності усіх елементів замовлення статус самого замовлення міняється на «ready for delivery», тобто замовлення зникає зі списку персоналу кухні. За зміну статусу замовлення відповідає тригер бази даних «checkOrderItems», у разі зміни даних в таблиці «OrderItems» тригер перевіряє для якого елементу замовлення було змінено статус, та якщо для цього замовлення у даній таблиці статус «ready» мають усі елементи тригер міняє статус замовлення на «ready for delivery».

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

4. АНАЛІЗ РОЗРОБЛЕНОГО ПРОЕТУ

4.1. Особливості реалізації

При розробці проекту були використані сучасні технології розробки, такі як технологія створення web-додатків ASP.NET,  для зберігання інформації та генерування на основі неї елементів меню, база даних MS SQL Server.

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

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

З використанням технологій використаних при розробці, замовник системи отриму всебічну та широку підтримку з певною гарантією надійності. Адже такі інструменти як MS SQL Server та платформа .NET не є безкоштовними, а значить Microsoft дбає про супровід, підтримку та безпеку використання даних технологій. Окрім цього вони досить часто оновлюються новими версіями, патчами, що дає змогу використовувати при розробці нові, сучасні елементи, роблячи внутрішню структуру проекту та дизайн більш зручними та гнучкими а також гарантує безпеку даних.

4.2. Порівняння з іншими аналогами

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

osCommerce або Open Source Commerce – це движок інтернет-магазинa. Він може бути встановлений на будь-якому web-сервері з підтримкою PHP і MySQL. Це вільне програмне забезпечення з GNU General Public License. Вільне програмне забезпечення, а це означає, що існують певні проблеми. Великі магазини  навряд чи будуть використовувати такі технології, адже маючи значний грошовий та товарообіги вони ризикують бути зламаними.

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

  •  сумісно з PHP 4.x, 5.x і MySQL 4.x, 5.x;
  •  працює з усіма основними браузерами;
  •  вбудована багатомовність, за замовчуванням встановлені англійська, німецька, іспанська мови. Доступні російська, українська та багато інших;
  •  майстер інсталяції (wizard);
  •  необмежене число розділів і товарів.
  •  адміністрування:
  •  підтримує необмежену кількість продуктів і розділів категорій;
  •  підтримка фізичних і віртуальних (завантажуються) товарів;
  •  легкість резервного копіювання та відновлення даних;
  •  статистика товарів і замовників;
  •  багатомовна підтримка;
  •  підтримка декількох валют.
  •  клієнтська частина:
  •  реєстрація покупців;
  •  всі замовлення зберігаються в базі даних;
  •  клієнти можуть переглядати історію і статуси своїх замовлень;
  •  тимчасова корзина для гостей і постійна для клієнтів;
  •  швидкий і дружній інтерфейс пошуку;
  •  безпека з підтримкою SSL (Secure Sockets Layer);
  •  зручна навігація по сайту;
  •  клієнт може мати кілька адрес доставки у своїй адресній книзі.
  •  система оплати та доставки:
  •  підтримка численних типів платежів (чеки, платіжні доручення);
  •  підтримка численних платіжних систем (модулям) (2CheckOut, PayPal, Authorize.Net, iPayment, RuPay, Webmoney);
  •  налаштування методів оплати для різних областей;
  •  розрахунок доставки на основі ваги та ціни товару, зони доставки. Безліч модулів розрахунку доставки;
  •  розрахунок податків.

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

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

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

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

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

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

  •  систему управління змісту масштабу підприємства (Enterprise Content Management System системи управління змістом підприємств);
  •  система управління web-вмістом (Web Content Management System).

В силу того, що ECMS мають глибоку внутрішню класифікацію за предметним областям (HRM, DMS, CRM, ERP і т. д.) термін CMS замістив собою WCMS, перетворившись на синонім системи управління сайтами. Подібні CMS дозволяють управляти текстовим і графічним наповненням web-сайту, надаючи користувачеві інтерфейс для роботи з вмістом сайту, зручні інструменти зберігання і публікації інформації, автоматизуючи процеси розміщення інформації в базах даних і її видачі в HTML.

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

Генерація сторінок по запиту. Системи такого типу працюють на основі зв'язки «Модуль редагування → База даних → Модуль подання». Модуль уявлення генерує сторінку із змістом при запиті на нього, на основі інформації з бази даних. Інформація в базі даних змінюється за допомогою модуля редагування. Сторінки заново створюються сервером при кожному запиті, що в свою чергу створює додаткове навантаження на системні ресурси. Навантаження може бути багато разів знижена при використанні коштів кешування, які є в сучасних web-серверах.

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

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

4.3. Рекомендації щодо подальшого вдосконалення

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

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

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

5. ОХОРОНА ПРАЦІ

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

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

5.1. Виявлення та аналіз ШНВШ. Заходи з охорони праці

5.1.1. Повітря робочого середовища

Відповідно до ДСН 3.3.6.042 – 99 роботи в офісі відносять до категорії легка Ia. Дана робота належить до категорії робіт сидячи і не потребуючих фізичної напруги, при яких витрата енергії становить до 120 ккал/год. Оптимальні значення параметрів мікроклімату, прийняті даним проектом, наведені в табл. 1.

Таблиця 1

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

Період року

Категорія робіт

Температура, C

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

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

Холодний

Легка

22-24

40-60

0,1

Теплий

Легка

23-25

40-60

0,1

Температура корпусу ЕОМ та периферійних пристроїв встановлюються за наступною формулою:

,

де tптемпература зовнішньої поверхні обладнання,

   tопт – оптимальна температура приміщення.

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

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

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

5.1.2. Виробниче освітлення

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

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

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

В табл. 2 представлені санітарні норми освітлення, наведені значення параметрів освітлення, прийняті проектом.

Таблиця 2

Норми параметрів освітлення

Розряд зорових робіт

Характер зорових робіт

Освітле-

ність при штучному освітленні

Значення КЕО, %

При природному освітленні

При суміщеному освітленні

Спеці-

альне

Верх-

нє

Спеці-

альне

Верх-

нє

IVa

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

300

0,2

1

0,2

0,7

Система штучного освітлення комбінована. В офісі використовуються люмінесцентні лампи типу ЛД. Прийнята напруга – 220 В.

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

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

Контроль освітленості здійснюється люксметром Ю-116 1-2 рази в рік, а також після ремонту освітлювальних установок.

5.1.3. Захист від виробничого шуму та вібрації

За ДСН 2.2.4/2.1.8.562-96 при виконанні основної роботи на ПЕОМ рівень шуму на робочому місці не повинен перевищувати 50 дБ.

Зниження рівня шуму в приміщенні з ПЕОМ досягається шляхом використання звуковбирних матеріалів з максимальними коефіцієнтами звукопоглинання в області частот 63-8000 Гц для обробки приміщень підтверджених спеціальними акустичними розрахунками. В офісних приміщеннях застосовуються сучасні віконні профілі з двохкамерними або трьохкамерними склопакетами і звукоізоляція зовнішніх стін плитами з різними наповнювачами такими як скловата або кам’яна вата.

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

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

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

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

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

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

Захисне заземлення виконується навмисним з’єднанням металевих частин електроустановок з «землею» або її еквівалентом.

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

Відповідно ГОСТ 12.1.038-82 допустимі рівні напруги дотику (Uд) і струму, що проходить через тіло людини (Iл) дорівнює: при нормальному режимі роботи електроустаткування Uд = 2 В, а Iл = 0.3 мА при τ ≤ 10 хв; при аварійному відповідно 36 В і 6 мА при τ > 1 с.

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

Напруга дотику визначається наступною формулою:

Як видно з рівняння, при порушенні ПБЕ можливі електротравми з важкими наслідками.

5.1.5. Безпека роботи з обладнанням

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектом передбачені наступні міри пожежної безпеки:

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

Додаткові організаційні заходи:

  •  встановлення в приміщенні апарату для швидкого виклику екстреної служби;
  •  фізична доступність розеток для ручного відключення живлення ПЕОМ.

5.3. Блискавкозахист

Блискавкозахист – це комплекс заходів та спеціальних пристосувань для забезпечення безпеки приміщення, а також майна та людей, що знаходяться в ньому. Згідно з діючим Національним стандартом України ДСТУ Б В.2.5-38:2008 блискавкозахист будівель підрозділяється на зовнішній і внутрішній.

Зовнішній блискавкозахист складається з наступних частин:

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

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

ВИСНОВОК

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

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

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

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

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

СПИСОК ВИКОРИСТАНИХ ЛІТЕРАТУРНИХ ДЖЕРЕЛ

Виейра, Роберт. Программирование баз данных Microsoft SQL Server 2005. Базовый курс [Текст] / Роберт Виейра. — М. : «Диалектика», 2007. — 832 с.

Хендерсон, Кен. Профессиональное руководство по SQL Server: структура и реализация [Текст] / Кен Хендерсон. — М. : Издательский дом «Вильямс», 2006. — 1056 с.

Гандерлой, Майк. Освоение Microsoft SQL Server 2005 [Текст] / Майк Гандерлой, Джозеф Джорден, Дейвид Чанц. — М.: «Диалектика», 2007. — 2204 с.

Огляд Microsoft SQL Server [Електронний ресурс]. – Режим доступу: http://uk.wikipedia.org/wiki/Microsoft_SQL_Server#cite_note-2k8-2. – Дата доступу: січень 2012. – Microsoft SQL Server.

Мак-Дональд, Мэтью. Microsoft ASP.NET 4.0 с примерами на C# 2010 для профессионалов, 4-е издание = Pro ASP.NET 4.0 in C# 2010, Fourth Edition [Текст] / Мэтью Мак-Дональд, Адам Фримен, Марио Шпушта. — М. : «Вильямс», 2011. — 1424 с.  

Камерон, Роб. ASP.NET 3.5, компоненты AJAX и серверные элементы управления для профессионалов [Текст] / Роб Камерон, Дэйл Михалк. — М. : «Вильямс», 2009. — 608 с.

Огляд ASP.NET [Електронний ресурс]. – Режим доступу: http://uk.wikipedia.org/wiki/ASP.NET. – Дата доступу: січень 2012.  ASP.NET

Мержевич, Влад. HTML и CSS на примерах [Текст] / Влад Мержевич.  С.-П. :  БХВ-Петербург, 2009.  448 с.

Рейли, Дуглас Дж. Создание приложений Microsoft ASP.NET [Текст] / Дуглас Дж. Рейли.  М. : Издательско-торговый дом «Русская Редакция», 2002.  464 с.

Microsoft Corporation. Разработка Web-приложений на Microsoft Visual Basic .NET и Microsoft Visual C# .NET. Учебный курс MCAD/MCSD [Текст] : пер. с англ.  М. : Издательско-торговый дом «Русская Редакция», 2003.  704 с.

Браст, Эндрю Дж. Разработка приложений на основе Microsoft SQL Server 2005 [Текст] / Эндрю Дж. Браст, Стивен Форте.  М. : Издательстко-торговый дом «Русская редакция», 2007.  878 с.

ДОДАТКИ

ПЗКС.045440-06-99. Взаємодія модулів. Схема структурна.

ПЗКС.045440-07-99. Алгоритм реєстрації користувачем замовлення. Схема алгоритму.

ПЗКС.045440-08-99. Алгоритм проходження замовлення через етапи системи. Схема алгоритму.

Таблиці бази даних та їх взаємозв’язки. Плакат.

Схема варіантів використання системи. Плакат.

Модуль взаємодії із базою даних. Плакат.

CD диск із даними та технічною документацією.


 

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

67172. ДИАГРАММА СОСТОЯНИЯ ЖЕЛЕЗО-ЦЕМЕНТИТ: ФАЗЫ, СТРУКТУРНЫЕ СОСТАВЛЯЮЩИЕ 53.5 KB
  Соединение Fe3С цементит неустойчиво метастабильно и при соответствующих условиях медленном охлаждении возможна кристаллизация из жидкости свободного углерода в виде графита. Железо-углеродистые сплавы содержащие 667 С могут кристаллизоваться по двум типам диаграмм...
67173. Роздрібний товарооборот. Товарооборот роздрібних торгових підприємств 37.84 KB
  Товарооборот роздрібних торгових підприємств Соціально економічна характеристика роздрібного товарообороту Сутність значення товарообороту підприємства як економічної категорії та показника діяльності Склад і структура роздрібного товарообороту Товарооборот роздрібних торгових підприємств...
67174. Основы теории массового обслуживания 233.5 KB
  Рассмотрим сначала некоторые понятия которые характеризуют стохастическую неопределенность когда неопределенные факторы входящие в задачу представляют собой случайные величины или случайные функции вероятностные характеристики которых либо известны либо могут быть получены из опыта.
67175. КУЛЬТУРА ЗАПАДНОЕВРОПЕЙСКОГО СРЕДНЕВЕКОВЬЯ 115.5 KB
  В условиях сословноиерархической структуры общества пронизанной сверху донизу сословной замкнутостью и отношениями вассального служения сюзерену; в процессе бесконечных войн которые несли голод разрушение смерть и ощущение трагизма человеческой жизни...
67176. Организация разработки требований к сложным программным средствам 139 KB
  Проекты программных средств различаются по уровню сложности масштабу и необходимому качеству. Чаще всего проблемами с которыми встретились не достигшие своих целей проекты программных продуктов являются: недостаток информации от пользователя...
67177. ПОЛИТИЧЕСКАЯ СИСТЕМА И ГОСУДАРСТВО 138.5 KB
  Любое государство функционирует в определенной социальной среде зависит от экономики и культуры общества его структуры психологии и ценностных предпочтений граждан в свою очередь оказывая на них мощное воздействие.
67178. ОБЩИЕ ПРИНЦИПЫ АНЕСТЕЗИОЛОГИИ. ИНГАЛЯЦИОННЫЙ НАРКОЗ 278 KB
  Универсальной и общепризнанной теории действия анестетиков нет. Ранние теории наркоза в настоящее время представляются полностью несостоятельными: Коагуляционная теория Кьюн 1864 коагуляция белка под влиянием эфира и хлороформа обнаружилось что коагуляция происходит только при концентрациях значительно превышающих терапевтические.
67179. Проблеми державного відтворення української культури у 1917-1920 рр. та особливості національно-культурного розвитку українських земель у 1920-1930-х рр. XX століття 133 KB
  Відкриття Української Академії наук УАН. відбулося територіальне роз'єднання українських земель завершилося формування української нації ускладнилася соціальна структура та політизувалося суспільне життя. Ця орієнтація зумовила вивчення проблем етнографії фольклору мови а також стимулювала бажання...
67180. Повернення об’єктів функціями. Потенційні проблеми 74.5 KB
  Якщо об'єкти можна передавати функціям, то з таким самим успіхом функції можуть повертати об'єкти. Щоби функція могла повернути об'єкт, по-перше, необхідно оголосити об'єкт, який повертається нею, типом відповідного класу. По-друге, потрібно забезпечити повернення...