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

Работа добавлена на сайт samzan.net:

Вступ

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

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

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

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

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

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

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

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

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

1 Аналіз існуючих програмних засобів

1.1 Формування вимог користувача до АС

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

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

Інформація повинна включати:

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

Користувач системи повинен мати можливість виконувати наступні запити:

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

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

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

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

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

Для проектування інформаційної системи використовується система управління реляційними базами даних Microsoft SQL Server 2008 і Delphi7 для створення зручного призначеного для користувача інтерфейсу.

1.2  Характеристика об'єкту автоматизації

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

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

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

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

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

•  IBM PC сумісний комп'ютер з операційною системою Windows;
•  монітор;
•  миша;
•  клавіатура;
•  спеціалізований принтер друку квитків(для прикладу DataMax - 3210 з ножем);
•  грошовий ящик;
•  квиткова стрічка(бланки строгої звітності), виготовлена в друкарні на термокартоне. При виготовленні стрічки враховуються побажання клієнта відносно дизайну(эксклюзивности стилю кінотеатру). Виготовлена стрічка повинна відповідати технічним характеристикам, вказаним в документації на принтер(розміри, об'єм намотування в рулон, щільність картону, відбиваюча здатність чорної мітки и.т.д.).

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

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

1.3 Приклади аналогів ПП

1.3.1 SaleTcket

Завдання вирішувані автоматизованою системою SaleTcket:

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

Рисунок 1.1 – Головне вікно програми SaleTcket

Рисунок 1.2 – Вікно продужу білетів SaleTcket

Функціональні можливості системи SaleTcket

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

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

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

Особливості і переваги

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

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

Система "SaleTicket" має просунутий і багатофункціональний апарат підтримки клубних карт, складних знижок, накопичувальних бонусів і інших програм стимулювання збуту. Розгалужена звітність і аналітика по безлічі параметрів, що забезпечує підтримку ухвалення рішень. Сумісність з усіма касовими апаратами, автоматично друк чеки, звітів, проводение повернень і операцій по платіжних картках. Працює з множиною різних квиткових принтерів, як професійних термо-, так і на матричних. У системі реализованны повноцінні функції ON - LINE продажу і бронювання, ON - LINE репертуару, ON - LINE звітності, адміністрування, реально наявний Web- інтерфейс, який постійно удосконалюється. "SaleTcket" - перша система реалізовує повнофункціональний принцип управління мережами кинотеаров та ін. зрелижными підприємствами. Управління розподіленими об'єктами з єдиного центрального офісу. Програма дозволяє працювати більш ніж на 200 робочих місцях одночасно.

Технології і архітектура

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

SaleTicket працює під управлінням операційних систем сімейства Microsoft Windows(2000, XP, Vista, 7).

Cистема автомаизации SaleTicket використовує СУБД MS SQL Server(2000, 2005, 2005 Express). Ця СУБД є найбільш потужною і технологічною платформою для управління базами даних.

Взаємодія між клієнтами і серверами може здійснюється по різних каналах зв'язку, починаючи з традиційних мідної телефонної або витої пари(комутованим або выделеным), Wi - Fi- мереж і закінчуючи передачею даних через Internet, GPRS- з'єднання і так далі Intranet або Internet.

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

1.3.2 UCS-Премьера

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

Функції менеджера

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

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

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

Визначення цін на квитки. Ціна на квиток залежить від двох параметрів - категорії місця і виду квитка. У простому випадку можна мати тільки один вигляд квитків. Але можна також зробити дитячі, ветеранські, квитки вихідного дня і тому подібне. У ціновій схемі вказуються ціни на пари: категорія місця + вид квитка. У простому випадку така пара всього одна, і ціна однакова для усіх покупців і на будь-яке місце. Можна створити декілька цінових схем для різних сеансів. Для кожної пари може бути створений свій макет квитка(тільки при використанні принтерів Datamax).

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

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

Функції касира

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

Напрями розвитку

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

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

1.3.3 Домино 8

Система автоматизації ДОМІНО 8: Кінотеатр фунционально відповідає усім вимогам по обліку і управлінню в кінотеатрах різних форматів.

За допомогою рішення ДОМІНО 8: Кінотеатр можливо:

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

Переваги

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

Система автоматизації ДОМІНО 8: Кінотеатр може вирішувати завдання не лише поодиноких об'єктів, але і об'єктів мережевої структури. У рішенні реалізовані декілька схем роботи мережі : централізованої, децентрализованная, он-лайн.

Механізми мережевого управління в програмі ДОМІНО 8: Кінотеатр реалізовані з урахуванням завдань підвищення "прозорості бізнесу", оптимізації процесів управління і зниження витрат.

У системі ДОМІНО 8: Кінотеатр передбачено мережеве управління репертуаром, що дозволяє підвищити керованість і понизити витрати на персонал.

Інформаційна система ДОМІНО 8: Кінотеатр уміє створювати і відправляти звіти про прокат в автоматичному режимі, що дозволяє оптимізувати роботу співробітників.

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

Рішення ДОМІНО 8: Кінотеатр надає можливість відвідувачеві здійснювати вибір місця без участі касира. Для цього план залу, інформація про вартість квитків і вільні місця виводиться на Touch - screen відвідувача. При цьому відвідувач здійснює вибір на екрані, а касир оформляє купівлю.

Інформаційна система ДОМІНО 8: Кінотеатр дозволяє використати робоче місце касира як для продажу квитків, так і для продажу супутніх товарів. А в кафе і барах можливо організувати продаж квитків на сеанси. В період пікового навантаження це можна використати для збільшення швидкості обслуговування відвідувачів.

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

Рішення ДОМІНО 8: Кінотеатр може працювати з різним устаткуванням: турнікетами, системою управління більярдом, ігровими автоматами.

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

1.3.4 Системи автоматизації кінотеатру Premiera

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

•  інфо-плазма - дозволяє показувати розклад, ролики, рекламу, акції, текстові або звукові звернення на плазмових(чи LCD) панелях в холі кінотеатру;
•  інтеграція з сайтом або SMS- сервісом - дозволяє створити систему бронювання і продажу квитків через ваш сайт(портал) і SMS;
•  Head Office - об'єднує мережу кінотеатрів в єдиний центр управління і звітності;
•  Кіоск - дозволяє продавати квитки через кіоски самообслуговування.

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

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

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

1.3.5 Автоматизація кінотеатру R - Keeper

Автоматизація кінотеатру(кінотеатру-мультиплексу з декількома залами або невеликого кінозалу) за допомогою ПЗ R - Keeper "Прем'єра" дозволяє:

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

Автоматизація кінотеатру R - Keeper, оптимізує роботу персоналу кінотеатру за рахунок використання інтелектуальної телефонної системи. Комп'ютерний автовідповідач, що входить в  R, - keeper "Прем'єру", надасть за запитом інформацію про розклад сеансів, ціни, наявності місць, спеціальних акціях.

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

Забронювати квиток заздалегідь можна 3-мя способами:

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

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

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

Якщо необхідно автоматизувати мережу кінотеатрів, то до системи R - keeper "Прем'єра" встановлюється програмний комплекс управління мережею з головного офиса- "BACK OFFICE".

Центральний сервер "Прем'єра - BACK OFFICE" виконує наступні функції:

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

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

У стандартній схемі автоматизації кінотеатру R - Keeper "Прем'єра" знадобиться:

для оснащення менеджера/керівника кінотеатром:

•  ПК(повнофункціональна робоча станція на платформі PC);
•  для оснащення фойє кінотеатру і входів в зали:
•  турнікети;
•  інформаційний кіоск;

для квиткової каси:

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

для кіно-бару:

•  термінал TouchScreen;
•  монітор відвідувача;
•  фіскальний реєстратор;
•  грошовий ящик;

мережеве устаткування:

•  сервер;
•  комутатор(для об'єднання терміналів і принтерів в єдину комп'ютерну мережу).

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

1.3.6 GiS-Cinema

Вхід в АРМ касир.

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

Рисунок 1.3 – Ідентифікація користувача програми

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

Продаж квитків. Вікно продажів.

"Вікно продажів квитків" - основна робоча область робочого місця, в якій касир виконує свою роботу :

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

Усі сеанси на поточний день в "Вікні продажів" розміщені за часом сеансу. Перемикання між сеансами здійснюється за допомогою закладок. Через певний час(задається в налаштуваннях в АРМ Касира) після початку сеансу закладка стає недоступна касирові і йде зі списку робочої області.

Рисунок 1.4 – Основна робоча область - "Вікно продажу"

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

Рисунок 1.5 – Панель вибору сеансу

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

Рисунок 1.6 – Вибір сеансу через список репертуару

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

Рисунок 1.7 – Панель управління функціями касира

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

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

Рисунок 1.8 – Інформація про вибрані місця

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

Висновок

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

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

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

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

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

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

Дані повинни бути згруповані в системі, таким чином:

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

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

В проектованому програмному продукті повинні бути представлені наступні запити:

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

 

3 Мета

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

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

3.1 Технічне завдання

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

1. Повне найменування системи і її умовне позначення –  

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

2. Шифр теми або шифр (номер) договору – ….. від

.......2014 року

3. Найменування підприємства розробника і замовника системи, їх реквізити– ТПА ОНАХТ, Пантюшин Володимир Володимирович

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

5. Планові терміни початку і  закінчення робіт - ……-……….

6. Порядок оформлення і пред'явлення замовникові результатів робіт із створення системи, її частин і окремих коштів – Протягом періоду ………-………..

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

3.1.2 Призначення і цілі створення (розвитку) системи

1. Вид діяльності що автоматизується  - автоматизується процес роботи менеджера та касира кінотеатра; перелік об' єктів, на яких передбачається використання системи: даний продукт може використовуватися у роботі кінотеатру та театру;

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

3.1.3 Характеристика об'єктів автоматизації

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

2. Відомості про умови експлуатації і характеристики навколишнього середовища – Процесор: Intel Core Intel® Core™ i7-2600 quad-core processor, 3.4 GHz

Модуль пам’яті:  Corsair 8 GB DDR3 SDRAM

Відео карта: 1 GB AMD Radeon HD 6770 graphics

Материнська плата: Intel® Desktop Board DH61AG

3.1.4 Вимоги до системи

Вимоги до системи в цілому:

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

2. Вимоги до персоналу (чисельність користувачів, кваліфікація, режим роботи, порядок підготовки) – 1 користувач з мінімальним знанням ПК (керівництво користувачу додається)

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

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

Вимоги до функцій:

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

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

3. Перелік і критерії відмов -  відмови можуть виникнути в разі відмови з’єднання з базою даних.

Вимоги до видів забезпечення:

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

2. Інформаційному (склад, структура і організація даних, обмін даними між компонентами системи) – реляційна база даних на 7-9 таблиць. Таблиці, пов’язані відношеннями 1 до n і m до n.

3. Лінгвістичному (мови програмування, мови взаємодії користувачів з системою, системи кодування, мови введення-виводу) – Мова програмування Delphi, мова взаємодії користувачів з системою – російська, мови введення-виводу – російська/українська.

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

5. Організаційному (структура і функції експлуатуючих підрозділів, захист від помилкових дій персоналу) – програмний продукт розрахований на експлуатацію багатьох користувачів.

6.  Методичному (склад нормативно-технічної документації) – в комплект програмного продукту планується керівництво користувача.

3.1.5 Склад і зміст робіт із створення системи:

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

2. Терміни виконання :

Аналіз – ….. ,

Проектування – ….. ,

Реалізація – ….. ,

Впровадження – ….. ,

Терміни виконання – …..

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

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

3.1.6 Порядок контролю і приймання системи

1.  Види, склад, об`єм і  методи випробувань системи –   α- , β- тестування, каскадне тестування.

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

3.1.7 Вимоги до складу і змісту робіт по підготовці об'єкту автоматизації до введення системи в дію

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

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

3. Терміни і порядок комплектування і навчання персоналу – для роботи з програмним продуктом необхідна одна людина, термін навчання - 4-7 занять.

3.1.8 Вимоги до документації

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

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

3.1.9 Джерела розробки

Документи і інформаційні матеріали, на підставі яких розробляється ТЗ і система -  http://delphidevelop.ru/  , http://decoding.narod.ru/, http://articles.org.ru/ – дані сайти представляють собою електроні бібліотеки, які мають багато можливостей по роботі з літературою.

4 Технологія створення програмного продукту

4.1 Діаграми потоків даних

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

Так, наприклад, для діаграми потоків DFD перехід від моделі бізнес-процесів організації до моделі системних процесів може відбуватися таким чином:

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

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

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

Опис предметної області

Об'єкт автоматизації

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

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

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

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

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

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

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

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

Крім того, в проектованому продукті представлені наступні запити:

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

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

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

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

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

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

Опис користувачів і груп користувачів системи

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

Робоче місце касира кінотеатру знаходиться на робочій станції касира, в якості якої застосовується IBM PC сумісний комп'ютер.Перед побудовою контекстної діаграми потоків даних - DFD необхідно проаналізувати зовнішні події (зовнішні об'єкти), що роблять вплив на функціонування інформаційно-керуючої системи роботи кінотеатру. Зовнішні об'єкти взаємодіють з ІС шляхом інформаційного обміну з нею. З опису предметної області виходить, що з програмною оболонкою працюють наступні групи людей: касир та відвідувачи. Ці групи є зовнішніми об'єктами. Вони не лише взаємодіють з системою, але так само визначають її межі і зображаються на початковій контекстній діаграмі потоків даних DFD як термінаторів (зовнішні сутності). Початкова контекстна діаграма потоків даних зображена на рис. 4.1. У використовуваній нотації зовнішні сутності позначаються прямокутниками, а процеси - колами.

Рисунок 4.1 - Початкова контекстна діаграма потоків даних (DFD)

Список подій будується у вигляді матриці списку подій (Event List Matrix - ELM) і описує різні дії зовнішніх сутностей і реакцію ІС на них. Ці дії є зовнішніми подіями, що впливають на систему - тренажер. Розрізняють наступні типи подій :

•  NC (Normal Control) -нормальное управління;
•  ND (Normal Data) -нормальные дані;
•  NCD (Normal Control/Data) -нормальное управління/дані;
•  TC (Temporary Control) -временное управління;
•  TD (Temporary Data) -временные дані;
•  TCD (Temporary Control/Data) -временное управління/дані.

Усі дії позначаються як нормальні дані. Ці дані є подіями, які ІС сприймає безпосередньо, наприклад, зміна інформації тестованого, яке має бути відразу зареєстроване. Вони з'являються в діаграмі потоків даних DFD в якості утримуваного потоку даних. Матриця списку подій (ELM) має вигляд представлений в таблиці 4.1. Аналіз функціонального аспекту поведінки системи завершується побудовою повної контекстної діаграми, і представляє діаграму нульового рівня. При цьому процес «управління» декомпозируется на  процеси, що відбивають основні взаємодії з цією системою. Існуючі «абстрактні» потоки даних між термінаторами і процесами трансформуються в потоки, що представляють обмін даними на конкретнішому рівні (таблиця 4.2).

Таблиця 4.1 - Матриця списку подій (ELM)

Опис події	Тип	Реакція системи
Перегляд списку реалізованих квитків	ND	Активізація вікна списку реалізованих квитків - дата продажу квитка, на який сеанс, місце, ряд, назву фільму, жанр, вікові обмеження
Перегляд режиму роботи кінотеатру	ND	Активізація вікна режиму роботи кінотеатру - час проведення сеансу, вартість квитка на цей сеанс
Перегляд репертуару кінотеатру на сьогодні	ND	Активізація вікна репертуару кінотеатру на сьогодні - час проведення сеансу, назва фільму, жанр
Ведення архіву кінотеатру	ND	Активізація вікна архіву кінотеатру - дані про усі фільми, наявні в кінотеатрі
Ведення БД квитків	ND	Виведення усіх квитків проданих за сеанс, виведення усіх квитків проданих за день, виведення усіх квитків, коли-небудь проданих в кінотеатрі
Ведення обліку оплати за квитки	ND	Підрахунок прибутку від реалізації квитків за сеанс; підрахунок прибутку від реалізації квитків за день; підрахунок загального прибутку кінотеатру від реалізації усіх квитків.

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

Повна контекстна діаграма потоків даних приведена на рис. 4.2. Тут накопичувач даних «програмне забезпечення роботи кінотеатру» є абстрактним представленням сховища даних.

 Аналіз функціонального аспекту поведінки системи дає уявлення про вигляд і перетворення даних в системі. Взаємозв'язок між «абстрактними» і «конкретними» потоками даних на діаграмі нульового рівня виражається в діаграмах структур даних (рис. 4.3).

Таблиця 4.2 - Відповідність потоків даних на діаграмах різних рівнів

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

Рисунок 4.2 - Контекстна діаграма потоків даних

Рисунок 4.3 - Діаграма структур даних

4.2 Основні елементи системи

Діаграма прецедентів

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

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

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

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

Рисунок 4.4 - Діаграма Use Case " Моделювання процесу роботи кінотеатру "

Діаграма діяльності

Розробка діаграми діяльності переслідує цілі:

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

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

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

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

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

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

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

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

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

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

Рисунок 4.5 - Діаграма діяльності "Моделювання процесу роботи кінотеатру"

Діаграма станів

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

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

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

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

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

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

Рисунок 4.6 - Діаграма станів "Моделювання процесу роботи кінотеатру"

Діаграма класів

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

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

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

Рисунок 4.7 - Діаграма класів "Моделювання процесу роботи кінотеатру"

1.  Обґрунтування вибору програмних засобів

4.3.1 Аналіз вибору мови програмування

Ми живемо в еру розвитку комп’ютерних технологій. З’явилося багато мов програмування. Одна з найкращих –Borland  Delphi.

Delphi - це комбінація декількох найважливіших технологій:

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

Компілятор, вбудований в Delphi, забезпечує високу продуктивність, необхідну для побудови додатків в архітектурі “клієнт-сервер”. Він пропонує легкість розробки і швидкий час перевірки готового програмного блоку і в той же час забезпечує якість коду. Крім того, Delphi забезпечує швидку розробку без необхідності писати вставки на С або ручного написання коду (хоча це можливо).

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

1.   Аналіз вибору СКБД|із|

Практично всі сучасні СКБД використовують у своїй роботі технологію «клієнт-сервер» і СКБД InterBase не є виключенням. «Клієнт-Сервер» - це модель взаємодії комп'ютерів у мережі.

Сервер - це сама СКБД. Він підтримує всі основні функції СКБД, а саме: визначення даних, обробку даних, захист даних, підтримка цілісності даних і т.д. Зокрема, він надає повну підтримку зовнішнього, концептуального й внутрішнього рівнів. Тому «сервер» у цьому контексті - це просто інша назва для СКБД.

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

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

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

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

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

•  процесори мов запитів;
•  генератори звітів;
•  графічні бізнес-підсистеми;
•  електронні таблиці;
•  процесори звичайних мов;
•  статистичні пакети;
•  засоби керування копіюванням або засобу витягу даних;
•  генератори додатків (включаючи процесори мов четвертого покоління);
•  інші засоби розробки додатків, включаючи CASE-Інструменти (CASE або Computer-Aided Software Engineering - автоматизація розробки програмного забезпечення), і т.д.

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

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

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

Особливості архітектури клієнт-сервер

Обчислювальні завдання розподіляються миж клієнтом і сервером, і обчислення виробляються там, де зручно. Клієнт є інтелектуальним (тобто якщо з робочої станції (клієнт) надходити запити, те ця ж робоча станція може «вирішити», де його краще зробити). Можливість роботи в мережах, де працюють комп'ютери з різними ОС. Багатоплатформенні обчислення (використовуються різні архітектури комп'ютерів (платформи) IBM, Apple)

Загальні вимоги до архітектури клієнт-сервер

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

Розподіл інформації

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

Клієнт - додаток називається зовнішній інтерфейс, а сервер-СКБД - це внутрішній інтерфейс для безпосередньої роботи йз БД.

Існує три стандарти:

1.  грунтується на останніх версіях SQL (засновано на командах Connect - Disconnect (підключитися - відключитися)). Можливості невеликі. Додаток може звертатися й працювати з будь-якою БД, алі активною винна бути тільки одна. Відповідно до цього стандарту, SQL-Клієнт може бути пов'язаний з необмеженою кількістю БД, з яких тільки одна активна, інші пасивні. Кожне з'єднання може підключатися й з'єднуватися неявним образом (БД сама розумиє, що якщо треба, ті вона сама підключається до тієї БД, що ми вказуємо, і ця БД стає активною, а попередня - пасивною).
2.  RDA - Remote Data Access - вилучений доступ до даних. Досить розповсюджений. Ґрунтується на визначенні форматів і протоколів для з'єднання клієнта йз сервером. RDA підтримує мережне оточення OSI (Open System Interconnection - з'єднання відкритих систем). Клієнт формує запити в БД у стандартній форми мови SQL, а сервер підтримує стандартний каталог у стандарті SQL. Потім у ньому задаються стандартні формати подання для передачі повідомлень.
3.  DRDA - стандарт архітектури розподілених реляційних баз даних (Distributed Relstional Database Architecture - DRDA), запропонований компанією IBM (він є стандартом де-факто, алі не де-юре). Стандарти DRDA і RDA мають багато загального, однак, стандарт DRDA відрізняється від стандарту RDA у багатьох важливих відносинах. Зокрема в стандарті DRDA явно проявляється тенденція до відбиття його походження в компанії IBM. Наприклад, у стандарті DRDA клієнт необов'язково винний використовувати стандартну версію мови SQL і дозволене застосування, якого б не було діалекту мови SQL. Наслідком цього, можливо, є підвищення продуктивності, оскільки клієнтові дозволяється використовувати деякі специфічні можливості сервера. Алі, з іншого боку, цей підхід знижує можливості перенесення, оскільки подібні специфічні функції не є схованими від клієнта, тобто клієнтові відомо, з яким типом сервера він з'єднаний. Аналогічно цьому в стандарті DRDA допускається використання будь-яких конкретних особливостей структури каталогу сервера. Формати й протоколи DRDA істотно відрізняються від форматів стандарту RDA. По суті, стандарт DRDA базується на власній архітектурі й власних стандартах IBM, у тієї година, як стандарт RDA ґрунтується на мижнародних стандартах, незалежних від конкретних постачальників.

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

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

Переваги збережених процедур:

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

Недолік збережених процедур - до сьогодні не існує єдиних стандартів.

Висновок

У якості СКБД застосовується Іnterbase v.6.5, тому що вона:   клієнт-    серверна, проста в установці, настроюванні й в адмініструванні, володіє широкими  функціональними можливостями.   Як  середовище розробки інтерфейсної частини обране інтегроване середовище Delphі 7, тому що воно надає широкий спектр засобів для реалізації разнопланових завдань у  програмуванні і є об’єктно ориентованим.

1.   Опис бази даних

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

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

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

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

•  ієрархічна;
•  мережева;
•  реляційна.

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

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

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

Модель предметної області

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

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

Сукупність сутностей і класів зв'язків утворює верхній рівень моделі.

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

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

Рисунок 4.8 - Модель "сутність-зв'язок"

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

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

Програмний продукт представлений проектом - Cinema, який має 4 пов'язаних між собою таблиці:

•  Bilety - інформація реалізованих квитках;
•  Films - інформація про усі наявні в кінотеатрі фільми;
•  Seansy - інформація про час проведення сеансів і вартості квитків на ці сеанси;
•  Today - інформація про фільми, які будуть показані на сьогодні.

База даних складається з різних об'єктів, таких як таблиці, види, домени, збережені процедури, тригери. Об'єкти бази даних містять всю інформацію про її структуру і дані. Реляційні бази даних зберігають усі дані в таблицях. Таблиця це структура, що складається з безлічі неупорядкованих горизонтальних рядків (rows), кожна з яких містить однакову кількість вертикальних стовпців (colums). Перетинання окремого рядка і стовпця називаються полем (field), що містить специфічну інформацію. Багато принципів роботи реляціоної бази даних узяті з визначень відносин (relations) між таблицями.

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

У даному випадку були створені наступні таблиці: SOTRUDNIK, KLIENT, FILM, SEANS, BILETCENA, BILET, PRODUCTS, KAFE, PRODANO.

Візуальне відображення БД представлене у виді схеми на рисунку 4.9

Рисунок 4.9  - Схема БД

Розглянемо кожну таблицю БД більш детально.

Таблиця 4.3 - Опис полів таблиці " SOTRUDNIK "

Назва поля	Опис
ID	Первинний ключ
NAME	Ім'я співробітника
PASS	Паспортні данні
DOSTUP	Права доступу до системи
FOTO	Фото

Таблиця 4.4 - Опис полів таблиці " KLIENT "

Назва поля	Опис
ID	Первинний ключ
NAME	ПІБ клієнта
DATA	Дата замовлення

Таблиця 4.5 - Опис полів таблиці " FILM "

Назва поля	Опис
ID	Первинний ключ
NAME	Назва стрічки
DATA	Дата виходу на екран
SSILKA	Опис

Таблиця 4.6 - Опис полів таблиці " SEANS"

Назва поля	Опис
ID	Первинний ключ
FILM	Назва фільму – зовнішній ключ
DATA	Дата сеансу

Таблиця 4.7 - Опис полів таблиці " BILETCENA"

Назва поля	Опис
ID	Первинний ключ
SEANS	Сеанс - зовнішній ключ
KLASS	Рівень
CENA	Вартість

Таблиця 4.8 - Опис полів таблиці " BILET"

Назва поля	Опис
ID	Первинний ключ
NOMER	Номер
ZONA	Зона
RYAD	Ряд
CENA	Вартість

Таблиця 4.9 - Опис полів таблиці " PRODUCTS  "

Назва поля	Опис
ID	Первинний ключ
NAME	Назва продукту
CENA	Вартість

Таблиця 4.10 - Опис полів таблиці "KAFE "

Назва поля	Опис
ID	Первинний ключ
IND	Номер
KLIENT	Клієнт - зовнішній ключ
DATA	Дата замовлення

Таблиця 4.9 - Опис полів таблиці " PRODANO"

Назва поля	Опис
ID	Первинний ключ
SEANS	Сеанс
BILET	Квиток - зовнішній ключ
T	Відмітка  про оплату

1.  Опис програмних модулів

Структура додатка

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

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

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

procedure TMainForm.CreateMDIChild (const Name: string);

var

Child: TMDIChild;

begin

{ create a new MDI child window }

Child := TMDIChild.Create(Application);

Child.Caption := Name;

if FileExists(Name) then Child.Memo1.Lines.LoadFromFile(Name);

end;

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

До складу системи входять наступні файли:

- файл, що запускається - Project.exe;

- файл бази даних – Kino.gdb;

- файли, що містять довідкову інформацію - *.mht;

- файли, що виникають у ході виконання програми;

- форми додатка - *.dfm;

- модулі додатка - *.pas.

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

Рисунок 4.10  -  Ієрархія компонентів

  Структуру модулів додатка складають наступні файли:

•  BILET.pas – вікно створення нового білету;
•  CENABILET.pas - вікно ведення БД білетів;
•  FILMS.pas – вікно створення інформації про новий фільм;
•  INET.pas - вікно виходу до інтернету;
•  INET2.pas - перегляд залу показу стрічок;
•  KAFE.pas – вікно роботи кафе;
•  KASIR.pas – вікно для роботи касиру кінотеатру;
•  KLIENT.pas – занесення інформації о клієнтові;
•  LOGIN.pas – вікно розмежування прав доступу;
•  MAIN.pas – головне вікно програми;
•  PLAN.pas – вікно створення планів роботи;
•  PRODUKTI_.pas – вікно ведення БД продуктів;
•  SEANS.pas - вікно ведення БД сеансів;
•  SOTRUDNIK.pas – вікно занесення відомостей про співробітників;
•  STATKAFE_.pas – вікно занесення статусу замовлення кафе кінотеатру.

Алгоритми загальних і основних процедур

Алгоритм створення квитка

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

Додавання квитка за заданими критеріями

1) Для додавання квитка за заданими критеріями необхідно ввести відповідні атрибути квитка, за допомогою візуальних компонентів Delphi : Edit1(номер), Edit2(ряд), ComboBox2(зона), ComboBox1(клас місця).

2) Після цього, при натисненні на кнопку Додати(Button1), відбувається виклик процедури, яка динаически заносить дані про квиток у БД :

procedure TBilet_.Button1Click(Sender: TObject);

begin

try

IBTable1.Append;

IBTable1.FieldByName('ID').AsInteger := 0 ;

IBTable1.FieldByName('Nomer').AsInteger := strtoint( edit1.Text);

IBTable1.FieldByName('Zona').AsString := ComboBox2.Text;

IBTable1.FieldByName('Ryad').AsInteger :=  strtoint( edit2.Text);

IBTable1.FieldByName('CENA').AsInteger := strtoint(ComboBox1.Text) ;

IBTable1.post;

except

end;

end;

Автоматичне створення квитка

При натисненні на кнопку АвтоДобавить (Button3), станеться виклик процедури, яка автоматично створюватиме квитки по їх номеру і ряду( за допомогою циклів з параметром)procedure TBilet_.Button3Click(Sender: TObject);

var I,T :integer;

begin

try

For I := 1 to 20 do

For T := 1 to 32 do  begin

IBTable1.Append;

IBTable1.FieldByName('ID').AsInteger := 0 ;

IBTable1.FieldByName('Nomer').AsInteger := T;

IBTable1.FieldByName('Zona').AsString := ComboBox2.Text;

IBTable1.FieldByName('Ryad').AsInteger :=  I;

IBTable1.FieldByName('CENA').AsInteger := strtoint(ComboBox1.Text) ;

IBTable1.post;

end; except end; end;

Алгоритм створення фільму

Алгоритм створення фільму описаний в модулі FILMS.

1) За допомогою візуальних компонентів Delphi, необхідно ввести соответсвующие дані про фільм: Edit1и Edit2(Назва фільму, Посилання на джерело інформації), Memo1(Короткий опис).

2) Для занесення введених даних, необхідно натиснути на кнопку "Додати", яка викличе процедуру обробки події натиснення на кнопку Button1 :

procedure TFILMS_.Button1Click(Sender: TObject);

begin

try

IBTable1.Append;

IBTable1.FieldByName('ID').AsInteger := 0 ;

IBTable1.FieldByName('NAME').AsString :=  edit1.Text;

IBTable1.FieldByName('DATA').AsString :=  Memo1.Text;

IBTable1.FieldByName('ssilka').AsString := Edit2.Text;

IBTable1.post;

except

end;

end;

4.6 Опис інтерфейсу програми

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

Рисунок 4.11 – Головне вікно програми

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

Рисунок 4.12 – Меню "Допомога"

Рисунок 4.13 – Перегляд місць в кінозалі

Рисунок 4.14 – Вихід в інтернет

Залежно від прав доступу система дозволяє працювати в наступних режимах: адміністратор, менеджер, касир і працівник кафе.

Рисунок 4.15 – Вікно введення логіна і пароля

Розглянемо кожен режим детальніше

Режим  адміністратора

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

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

Рисунок 4.16 – Вікно створення клієнтської бази

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

Рисунок 4.17 – Вікно створення бази співробітників

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

Рисунок 4.18 – Вікно ведення статистики відвідуваності кінотеатру

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

Рисунок 4.19 – Вікно ведення статистики відвідуваності кафе

Режим  менеджера

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

Рисунок 4.20 – Головне меню в режимі менеджера

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

Рисунок 4.21 – Вікно створення інформації про трансльовані фільми

Рисунок 4.22 – Опис фільму

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

Рисунок 4.23 – Створення сеансів на трансльовані фільми кінотеатру

Рисунок 4.24 – Створення місць по вибраному сеансу для формування БД квитків

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

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

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

Рисунок 4.26 – Створення інформації по загальній кількості і розташуванню місць кінозалу

Касир

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

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

Рисунок 4.27 – Продаж квитків з вказівкою відповідних параметрів

Рисунок 4.28 –  Друк створеної інформації

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

Рисунок 4.29 – Продаж квитків зі списку доступних(непроданих квитків)

Рисунок 4.30 – Друк створеної інформації

Працівник кафе

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

Рисунок 4.31 – Головне меню в режимі працівника кафе

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

 

Рисунок 4.32 – Створення переліку товару для продажу в кафе

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

Рисунок 4.33 – Продаж товару в кафе кінотеатру

Рисунок 4.34 – Формування чека на оплату

Висновки

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

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

5 Економічні розрахунки

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

Загальні висновки

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

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

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

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

7 Список використовуваних джерел

1. А.Д.Хомоненко, В.М.Цыганков, М.Г.Мальцев, Базы данных– 4-е изд.- СПб.: КОРОНА принт, 2004.-736 с.

2. И.Ю. Баженива, Самоучитель программиста Delphi7  – М.:Кудиц образ, 2003, 448 с.

3. В.З. Гофман, А.Д. Хомоненко, Работа с базами  данных в Delphi   – СПб.:БХВ-Петербург, 2001, 656с.: ил.

4. Джен Л.Харрингтон “Проектирование реляционных баз данных. Просто и доступно” – издательство “Лори”, 2000.-230 с.

5.В.В.Корнеев, А.Ф.Гарев, С.В.Васютин, В.В.Райх “Базы данных. Интеллектуальная обработка информации” – М.: издательство “Нолидж”, 2000.-352 с

6. Ребекка М. Райордан «Основы реляционных баз данных».: Ред.: Русская Редакция, 2001.- 384 с.;

7. В.Д. Житецький, Охорона праці користувачів ПК – Львів: Афіша, 2000,176с.

8. М.Н. Гондзюк, О.П. Желібо, М.О. Халімовський, Основи охорони праці – К.:Каравелла, 2004. – 408с.  

9.Бойчик І.М., Харів П.С., Хопчан М.І., Економіка підприємства: Ред.: Сполом – 1998 – 212 с.

10.http://delphidevelop.ru/

11.www.soft.mail.ru

12. www.gs-vedomosti.ru

13. www.1cbit.ua

14.http://e-campus.vvsu.ru/systems/details/project/10133757/

1. правовая форма Наименование дополнительной номинации
2. Страхование предпринимательского риска
3. тема з идеологии и лидер и лидерство к политические элиты л политические режимы м поли
4. накопители информации Накопители информации представляют собой гамму запоминающих устройств с различ
5. Реферат- Определение примесей в технических целлюлозах
6. экономическим кризисом
7. Теорія розподілу влад
8. Описание и расчет механизированного приспособления для сверления отверстия ~32 ± 0,1 в детали «Подвеска такелажная» на станке 16К20.html
9. РЕФЕРАТ та~ырыбы- Экологиялы~ да~дарыс ЖОСПАР
10. Тема- Общее и особенное в праздновании Пасхи Кугече у русского и марийского народов Урок ИКН в 5м класс
11. Різноманіття тваринного світу України
12. то лицо посмотри Для войны в самый раз ИлюшаИЛЬЯ- Хочешь я тебя проверьЖЕНА- Давай Илюша проверяйИЛЬЯ- Н
13. Этапы эволюции средневекового государства
14. 29 ноября Регламент выступления 20 минут 5 минут вопросы 26 НОЯБРЯ 9
15. Тема ldquo;Изучение стоячих электромагнитных волн в двухпроводной линии
16. степени Почечная недостаточность острого периода
17. Ситуации на стадии судебного разбирательств
18. Криворізький національний університет Перелік освітньокваліфікаційних рівнів та напрямів підготовк
19. деньги их виды и функции Деньги это историческая категория которая является результатом развития то.
20. Внутренняя среда организма человека

Материалы собраны группой SamZan и находятся в свободном доступе