Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Вступ
Нині можна простежити тенденції до розширення ринку надання всіляких розважальних послуг. Сюди, звичайно ж, варто віднести і кінотеатри. Можна помітити, що кількість кінотеатрів невблаганно збільшується як у великих містах, населення яких перевалює за мільйон, так і в містах поменше. Незважаючи на це існує певний і незмінний список лідерів.
Для того, щоб займати лідерські позиції на ринку, компанії треба реалізовувати три основні напрями стратегічного розвитку своєї мережі.
Безумовно, це збільшення долі на мережевому ринку: входження в міста-мільйонники, великі обласні центри, в яких до цих відчувається нестача сучасних кіноцентрів, і нарощування своєї присутності в регіонах.
По-друге, розробка і реалізація найбільш затребуваної на ринку концепції багатозального кінотеатру для зручності відвідувачів кіноцентрів, яким надається широка репертуарна сітка, і можливість впродовж короткого періоду часу потрапити на улюблений фільм.
По-третє, оптимізація пристрою і функціонування мережі, що має на увазі оцінку економічних показників підприємств, коригування їх пристрою і діяльності.
Процес автоматизації кінотеатру полягає в розробці і впровадженні програмних продуктів для продажу і автоматизованого обліку квитків з урахуванням різних типів посадочних місць, пільгової політики, програм підтримки постійних клієнтів, системи знижок і інших рекламних акцій. Процес автоматизації нерозривно пов'язаний з оновленням не лише програмного забезпечення, але і з оновленням, купівлею нового устаткування і витрат на його впровадження і обслуговування. У цей список треба включити комп'ютер на кожне місце продавця-касира, устаткування серверної, квитковий принтер, грошовий ящики, також різні комутатори і комутацію.
Система повинна дозволити централізувати управління усіма процесами, пов'язаними з прийняттям і виконанням замовлення, дозволити керівникові своєчасно отримувати достовірну інформацію і, виходячи з цього, будувати правильну економічну політику підприємства.
Позитивний ефект від грамотного застосування автоматизованих систем управління в кінотеатрах організаціях незаперечний. А в умовах економічної кризи інформаційні технології можуть стати серйозним інструментом для оптимізації управління, скорочення витрат і дати безперечні конкурентні переваги на ринку. Автоматизація бізнес процесів - запорука ефективного управління. Автоматизація бізнес процесів призводить до зменшення рутинних операцій, дозволяє набагато швидше обслуговувати клієнтів, дає більше можливостей для контролю, бізнес-процеси стають "прозорішими". Істотно покращується робота по плануванню закупівель і постачань і інші плюси. Усе це у свою чергу істотно збільшує зростання прибутку, товарообігу і виручки, скорочує витрати. Зменшення рутинних операцій сприяє значно сприяє скороченню витрат на персонал.
Автоматизація кінозалу або, тим більше, кінотеатру-мультиплексу з декількома залами - сьогодні така ж необхідність, як установка екрану. Хороший звук, якісна картинка і зручні крісла за умовчанням повинні поєднуватися з чіткою роботою системи продажу і бронювання квитків. Адже сучасний кінолюбитель вже відвик від такого анахронізму, як продаж декількох квитків на одно і те ж місце. Йому також важко уявити, що квитки в кіно не можна забронювати по телефону або інтернету.
1 Аналіз існуючих програмних засобів
1.1 Формування вимог користувача до АС
Автоматизація процесів обліку і продажу квитків повинна включати розробку системи, що забезпечує зберігання і обробку даних про досконалі замовлення. Декілька залів різних видів, постійний потік відвідувачів і великий вибір фільмів зобов'язують автоматизувати облік проданих і вільних місць.
Однією з вимог до програмної системи, що розробляється, є зберігання таблиці з початковими даними у файлі. Усі зміни, що вносяться у базу даних, не повинні втрачатися при завершенні роботи з програмою.
Інформація повинна включати:
Користувач системи повинен мати можливість виконувати наступні запити:
АС для кінотеатру повинна складатися з трьох головних модулів.
Модуль адміністрування, призначений для визначення геометрії глядацьких місць, створення і редагування геометричних і цінових схемам, налаштування звітів, налаштуванню форм бланків квитків, управління правами користувачів системи і загальними налаштуваннями і конфігурацією системи.
Модуль продажу і бронювання квитків повинен швидко і легко обслуговувати покупців з можливістю застосування різноманітних знижок і обслуговуванням клубних карт. Необхідно, щоб за результатами роботи автоматично готувалися усі необхідні звіти для бухгалтерії і керівництва. Простий інтерфейс системи повинен дозволяти в найкоротші терміни проводити навчання касирів.
Модуль підготовки звітності і взаєморозрахунків з прокатниками повинен дозволяти повністю автоматизувати підготовку будь-яких звітів для відділу маркетингу і керівництва. Необхідно, щоб облік за договорами з прокатниками в розрізі кожної фільмокопії дозволяв автоматично створювати і експортувати бухгалтерські проводки.
Для проектування інформаційної системи використовується система управління реляційними базами даних Microsoft SQL Server 2008 і Delphi7 для створення зручного призначеного для користувача інтерфейсу.
1.2 Характеристика об'єкту автоматизації
Кінотеатр - ця громадська будівля(чи частина його), обладнана для показу фільмів.
Сучасний кінотеатр може багато що запропонувати глядачеві: цікавий фільм, якісне зображення і хороший звук, комфортні зали із зручними кріслами. Але починається кінотеатр із звичайної квиткової каси, в якій продаються квитки.
Основним функціональним обов'язком касира кінотеатру є процес реалізації квиткових бланків глядачам.
Робоче місце касира кінотеатру знаходиться на робочій станції касира, в якості якої застосовується IBM PC сумісний комп'ютер.
Для організації робочого місця касира з технічного боку, вимагається:
Додатково для організації робочого місця застосовують:
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).
Реєстрація персоналу для роботи на касах. Створюється список персоналу для роботи на касах кінотеатру з визначенням прав доступу.
Побудова звітів. Побудова звітів про минулі сеанси, виручку, відвідуваність, аналітичні звіти. Усі звіти будуються в режимі реального часу. Також можливе створення користувачем власних звітів.
Функції касира
Робоче місце касира - це комп'ютер, сполучений із спеціальним принтером, на якому роздруковуються квитки. Касир залежно від наявних у нього прав може продати квиток на будь-який заведений сеанс або забронювати частину квитків, використовуючи складену менеджером цінову схему; оформити при необхідності повернення грошей. Дії касира контролюються менеджером на менеджерській станції. Каса може працювати в двох режимах звітності : фіскальна і квиткова. У першому випадку до касового терміналу підключається фіскальний реєстратор, в другому касир працює з квитками строгої звітності.
Напрями розвитку
Недоліки: негативною рисою даної інформаційної системи є її ціна. Ліцензія на даний продукт не дешева, програма вільно не поширюється й не для всіх кінотеатрів вона є рентабельною.
1.3.3 Домино 8
Система автоматизації ДОМІНО 8: Кінотеатр фунционально відповідає усім вимогам по обліку і управлінню в кінотеатрах різних форматів.
За допомогою рішення ДОМІНО 8: Кінотеатр можливо:
Переваги
Інформаційна система ДОМІНО 8: Кінотеатр успішно вирішує не лише завдання продажу квитків в кінотеатрах, концертних залах, стадіонах, але і може використовуватися як єдине інтегроване рішення підприємства сфери дозвілля. Завдання управління баром, кафе, магазином супутніх товарів можуть бути без зусиль включені в рішення ДОМІНО 8: Кінотеатр, що дає безперечні переваги в управлінні бізнесом.
Система автоматизації ДОМІНО 8: Кінотеатр може вирішувати завдання не лише поодиноких об'єктів, але і об'єктів мережевої структури. У рішенні реалізовані декілька схем роботи мережі : централізованої, децентрализованная, он-лайн.
Механізми мережевого управління в програмі ДОМІНО 8: Кінотеатр реалізовані з урахуванням завдань підвищення "прозорості бізнесу", оптимізації процесів управління і зниження витрат.
У системі ДОМІНО 8: Кінотеатр передбачено мережеве управління репертуаром, що дозволяє підвищити керованість і понизити витрати на персонал.
Інформаційна система ДОМІНО 8: Кінотеатр уміє створювати і відправляти звіти про прокат в автоматичному режимі, що дозволяє оптимізувати роботу співробітників.
Зручний і ергономічний інтерфейс робочого місця касира в системі ДОМІНО 8: Кінотеатр забезпечує високу швидкість обслуговування відвідувачів, що особливо важливо, оскільки продаж квитків проходить зазвичай в режимі максимального завантаження.
Рішення ДОМІНО 8: Кінотеатр надає можливість відвідувачеві здійснювати вибір місця без участі касира. Для цього план залу, інформація про вартість квитків і вільні місця виводиться на Touch - screen відвідувача. При цьому відвідувач здійснює вибір на екрані, а касир оформляє купівлю.
Інформаційна система ДОМІНО 8: Кінотеатр дозволяє використати робоче місце касира як для продажу квитків, так і для продажу супутніх товарів. А в кафе і барах можливо організувати продаж квитків на сеанси. В період пікового навантаження це можна використати для збільшення швидкості обслуговування відвідувачів.
Інформаційна система ДОМІНО 8: Кінотеатр дозволяє здійснювати планування і бюджетування діяльності підприємства сфери дозвілля. У рішенні для цього реалізовані усі необхідні маханизмы. ДОМІНО 8: Кінотеатр дозволяє формувати прогнозні баланси, репертуарні плани, прогнозувати кількість відвідувачів з урахуванням різних коефіцієнтів.
Рішення ДОМІНО 8: Кінотеатр може працювати з різним устаткуванням: турнікетами, системою управління більярдом, ігровими автоматами.
Недоліки: негативна рису полягає в тім, що користування цією інформаційною системою не можливо без попереднього навчання.
1.3.4 Системи автоматизації кінотеатру Premiera
Великий плюс системи автоматизації кінотеатру Premiera полягає в її модульності, з якою можна істотно розширити її функціональність. На даний момент існують наступні модулі:
У системі Premiera закладені величезні можливості по формуванню звітів - при інсталяції системи встановлюється більше 100 різних звітів.
Мінімальна конфігурація автоматизації кінотеатру - сервер(на якому зберігається база даних системи) і касовий комп'ютер з принтером друку квитків. Стандартна конфігурація кінотеатру - сервер і два касові комп'ютери з принтерами друку квитків.
Недоліки: недостатньо уваги приділено дизайну програми.
1.3.5 Автоматизація кінотеатру R - Keeper
Автоматизація кінотеатру(кінотеатру-мультиплексу з декількома залами або невеликого кінозалу) за допомогою ПЗ R - Keeper "Прем'єра" дозволяє:
Автоматизація кінотеатру R - Keeper, оптимізує роботу персоналу кінотеатру за рахунок використання інтелектуальної телефонної системи. Комп'ютерний автовідповідач, що входить в R, - keeper "Прем'єру", надасть за запитом інформацію про розклад сеансів, ціни, наявності місць, спеціальних акціях.
Окрім цього, через програмне забезпечення "Прем'єра" можна завчасно забронювати квиток на кіносеанс і без зайвої метушні придбати його в окремій касі броні.
Забронювати квиток заздалегідь можна 3-мя способами:
Система "Прем'єра" дозволяє отримати максимальну фінансову віддачу від кінозалів будь-якої конфігурації і побудувати схему залу для глядачів будь-якої структури(з VIP- зонами, лоджіями/балконами, ярусами і тому подібне). "Прем'єра" автоматично привласнює кожному місцю певну цінову категорію. Робота менеджера при цьому полягає в налаштуванні системи на своєму ПК, після чого касові термінали продовжують працювати за заданою ціновою схемою.
Особливо варто відмітити модуль "Монітор відвідувача", який розміщується над вікном каси. "Монітор відвідувача" є плазмовою панеллю/LCD монітор, де відображається інформація про розклад сеансів і вільні місця в залі, демонструються трейлери. Модуль "Монітор відвідувача" значно спрощує і прискорює процес обслуговування відвідувачів кінотеатру.
Якщо необхідно автоматизувати мережу кінотеатрів, то до системи R - keeper "Прем'єра" встановлюється програмний комплекс управління мережею з головного офиса- "BACK OFFICE".
Центральний сервер "Прем'єра - BACK OFFICE" виконує наступні функції:
Менеджер головного офісу в режимі реального часу отримує дані про операції серверів кінотеатрів. У разі потреби, коли кіносеанс переноситься/відміняється, керівник кінотеатром має можливість внести зміни. Щоб узабезпечити себе перед прокатниками і виключити вірогідність зловживань з боку персоналу кінотеатру, головний офіс регламентує права на зміну схем і цін на місцях.
У стандартній схемі автоматизації кінотеатру R - Keeper "Прем'єра" знадобиться:
для оснащення менеджера/керівника кінотеатром:
для квиткової каси:
для кіно-бару:
мережеве устаткування:
Недоліки: негативна рису полягає в тім, що користування цією інформаційною системою не можливо без попереднього навчання.
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 перехід від моделі бізнес-процесів організації до моделі системних процесів може відбуватися таким чином:
Ієрархія екранних форм моделюється за допомогою діаграм послідовностей екранних форм. Сукупність таких діаграм є абстрактною моделлю призначеного для користувача інтерфейсу системи, послідовністю появи екранних форм, що відбиває собою, в додатку. Побудова діаграм послідовностей екранних форм виконується таким чином:
Опис предметної області
Об'єкт автоматизації
Кінотеатр - ця громадська будівля (чи частина його), обладнана для показу фільмів.
Сучасний кінотеатр може багато що запропонувати глядачеві: цікавий фільм, якісне зображення і хороший звук, комфортні зали із зручними кріслами. Але починається кінотеатр із звичайної квиткової каси, в якій продаються квитки.
Основним функціональним обов'язком касира кінотеатру є процес реалізації квиткових бланків глядачам.
У кінотеатрі є розклад, що містить інформацію про кінофільми і вартість квитків. А також в кінотеатрі є каси, в яких відвідувач може придбати квиток на сеанс.
У цій базі даних зберігається інформація як про час проведення сеансів і вартості квитків, так і інформація про вільні місця на сеанс, інформація про поточний фільм, жанр цього фільму, вікові обмеження на перегляд фільму.
Дані згруповані в системі, що розробляється, таким чином:
У системі, що розробляється, є можливість ведення даних : організація таблиць для завдання режиму роботи кінотеатру і посилань на них, введення і редагування даних в таблицях.
Крім того, в проектованому продукті представлені наступні запити:
Вхідний являється інформація, яку користувач вносить у файл бази даних, заповнюючи необхідні поля вибраної таблиці, а також вводячи інформацію у базу даних за допомогою запитів SQL.
Для програмного продукту, що розробляється, вхідний служитиме наступна інформація:
Вихідна інформація - результат виконання запитів, фільтрації даних, виведення необхідної інформації в звіт, друк інформації. Інформація, яка несе виведення або узагальнює вказані дані в загальному вигляді або за певним критерієм.
Вихідною інформацією для цього проекту є інформація, яка дозволяє зробити виведення на друк звітної форми : список реалізованих квитків. Вивід інформації про виручку кінотеатру за певний період.
Опис користувачів і груп користувачів системи
Програмне забезпечення роботи кінотеатру, що розробляється, може бути використане як співробітниками кінотеатру, так і відвідувачами. Співробітник кінотеатру може забезпечувати редагування наявної інформації про наявні фільми, змінювати графік роботи кінотеатру, включати фільми, що знову поступили, в репертуар кінотеатру; а відвідувач може переглядати інформацію про графіку роботи кінотеатру, вартості квитків, фільми на сьогодні.
Робоче місце касира кінотеатру знаходиться на робочій станції касира, в якості якої застосовується IBM PC сумісний комп'ютер.Перед побудовою контекстної діаграми потоків даних - DFD необхідно проаналізувати зовнішні події (зовнішні об'єкти), що роблять вплив на функціонування інформаційно-керуючої системи роботи кінотеатру. Зовнішні об'єкти взаємодіють з ІС шляхом інформаційного обміну з нею. З опису предметної області виходить, що з програмною оболонкою працюють наступні групи людей: касир та відвідувачи. Ці групи є зовнішніми об'єктами. Вони не лише взаємодіють з системою, але так само визначають її межі і зображаються на початковій контекстній діаграмі потоків даних DFD як термінаторів (зовнішні сутності). Початкова контекстна діаграма потоків даних зображена на рис. 4.1. У використовуваній нотації зовнішні сутності позначаються прямокутниками, а процеси - колами.
Рисунок 4.1 - Початкова контекстна діаграма потоків даних (DFD)
Список подій будується у вигляді матриці списку подій (Event List Matrix - ELM) і описує різні дії зовнішніх сутностей і реакцію ІС на них. Ці дії є зовнішніми подіями, що впливають на систему - тренажер. Розрізняють наступні типи подій :
Усі дії позначаються як нормальні дані. Ці дані є подіями, які ІС сприймає безпосередньо, наприклад, зміна інформації тестованого, яке має бути відразу зареєстроване. Вони з'являються в діаграмі потоків даних 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 - Діаграма класів "Моделювання процесу роботи кінотеатру"
4.3.1 Аналіз вибору мови програмування
Ми живемо в еру розвитку комп’ютерних технологій. З’явилося багато мов програмування. Одна з найкращих –Borland Delphi.
Delphi - це комбінація декількох найважливіших технологій:
Компілятор, вбудований в Delphi, забезпечує високу продуктивність, необхідну для побудови додатків в архітектурі “клієнт-сервер”. Він пропонує легкість розробки і швидкий час перевірки готового програмного блоку і в той же час забезпечує якість коду. Крім того, Delphi забезпечує швидку розробку без необхідності писати вставки на С або ручного написання коду (хоча це можливо).
В процесі побудови додаток розробник вибирає з палітри компонент готові компоненти як художник, що робить крупні мазки кистю. Ще до компіляції він бачить результати своєї роботи - після підключення до джерела даних їх можна бачити відображеними на формі, можна переміщатися за даними, представляти їх в тому або іншому вигляді. У цьому сенсі проектування в Delphi мало чим відрізняється від проектування в інтерпретуючому середовищі, проте після виконання компіляції ми одержуємо код, який виконується в 10-20 разів швидше, ніж те ж саме, зроблене за допомогою інтерпретатора.
Практично всі сучасні СКБД використовують у своїй роботі технологію «клієнт-сервер» і СКБД InterBase не є виключенням. «Клієнт-Сервер» - це модель взаємодії комп'ютерів у мережі.
Сервер - це сама СКБД. Він підтримує всі основні функції СКБД, а саме: визначення даних, обробку даних, захист даних, підтримка цілісності даних і т.д. Зокрема, він надає повну підтримку зовнішнього, концептуального й внутрішнього рівнів. Тому «сервер» у цьому контексті - це просто інша назва для СКБД.
Клієнти - це різні додатки, які виконуються поверх СКБД: як додатки, написані користувачами, так і вбудовані додатки, надані постачальниками СКБД або деякими сторонніми постачальниками програмного забезпечення. Звичайно, з погляду сервера різниці миж вбудованими додатками й додатками, написаними користувачем, немає: всі смороду використовують тієї самий інтерфейс сервера.
Додатки, у свою чергу, діляться на декілька чітко визначених категорій.
Додатки, написані користувачами. В основному це звичайні прикладні програми, найчастіше написані або популярною мовою програмування, подібному C, або на спеціалізованих мовах четвертого покоління, хоча в обох випадках ці мови повинні якось зв'язуватися з відповідною підмовою даних.
Додатки, надані постачальниками (часто називаються інструментальними засобами). У цілому, призначення таких засобів - сприяти процесу створення й виконання інших додатків, тобто додатків, які розробляються спеціально для рішення деякого специфічного завдання. Часто ці створювані додатки можуть виглядати зовсім не так, як додатки в загальноприйнятому змисті. І це зрозумило, оскільки саме призначення інструментальних засобів складається в наданні користувачам, особливо кінцевим, можливості створювати додатки без написання традиційних програм. Наприклад, одне з наданих постачальником СКБД інструментальних засобів може бути генератором звітів, за допомогою якого кінцевий користувач зможе одержати відформатований звіт, виконавши звичайний запитий до системи. Кожний такий запитий є, по суті, ні чим іншим, як невеликим спеціальним додатком, написаним мовою дуже високого рівня (зі специфічною назвою), а саме - мовою видачі відповідей.
Інструментальні засоби, що поставляються, діляться на кілька самостійних класів:
Головні завдання систем баз даних - підтримка створення й виконання додатків. Тому якість наявних клієнтських інструментальних засобів винна бути головним враховуючим фактором, що, при виборі СКБД, найбільш підходящої для конкретного замовника. Інакше кажучи, СКБД сама по собі - не єдиний і необов'язково найважливіший фактор, якй потрібно враховувати в цьому випадку.
Тому що система в цілому може бути чітко розділена на дві частини (сервер і клієнти), з'являється можливість роботи цих двох частин на різних машинах. Інакше кажучи, існує можливість організації розподіленої обробки. Розподілена обробка припускає, що окреми машини можна з'єднати якою- небудь комунікаційною мережею таким способом, що виконання одного завдання обробки даних можна буде розподілити на кілька машин цієї мережі.
Як показала практика, ця можливість на стільки приваблива по різних миркуваннях (головним чином, економичним), що термин «клієнт/сервер» ставши застосовуватися майже винятково в тих випадках, коли клієнти й сервер перебувають на різних машинах.
Особливості архітектури клієнт-сервер
Обчислювальні завдання розподіляються миж клієнтом і сервером, і обчислення виробляються там, де зручно. Клієнт є інтелектуальним (тобто якщо з робочої станції (клієнт) надходити запити, те ця ж робоча станція може «вирішити», де його краще зробити). Можливість роботи в мережах, де працюють комп'ютери з різними ОС. Багатоплатформенні обчислення (використовуються різні архітектури комп'ютерів (платформи) IBM, Apple)
Загальні вимоги до архітектури клієнт-сервер
Розподіл інформації
Прикладна програма розподіляється миж клієнтом і сервером для архітектури клієнт-сервер залежно від стандартів.
Клієнт - додаток називається зовнішній інтерфейс, а сервер-СКБД - це внутрішній інтерфейс для безпосередньої роботи йз БД.
Існує три стандарти:
У системах «клієнт/сервер» (як і в розподілених системах у цілому) надзвичайно важливо те, що програмист, що пише додаток, не просто «використовує сервер як деякий метод доступу» і пише код обробки на рівні записів. Функціональність додатка в як можна більшого ступеня винний бути пов'язана йз запитами на рівні безлічей. У противному випадку неминучі істотні втрати в продуктивності системи, пов'язані з передачею занадто великої кількості повідомлень.
Кількість повідомлень миж клієнтом і сервером може бути скорочена ще більше, якщо система надає в розпорядження користувача деякий механізм підтримки збережених процедур. Збережені процедури являють собою, по суті, попередньо відкомпільовані програми, які зберігаються на вузлі сервера (або відоми серверу). Клієнт звертається до збереженої процедури за допомогою механізму виклику вилучених процедур (Remote Procedure Call - RPC). Тому, зокрема, втрати в продуктивності, пов'язані з обробкою даних на рівні записів, можуть бути частково компенсовані за рахунок створення підходящих збережених процедур, що дозволяють виконати обробку даних безпосередньо на вузлі сервера.
Переваги збережених процедур:
Недолік збережених процедур - до сьогодні не існує єдиних стандартів.
Висновок
У якості СКБД застосовується Іnterbase v.6.5, тому що вона: клієнт- серверна, проста в установці, настроюванні й в адмініструванні, володіє широкими функціональними можливостями. Як середовище розробки інтерфейсної частини обране інтегроване середовище Delphі 7, тому що воно надає широкий спектр засобів для реалізації разнопланових завдань у програмуванні і є об’єктно ориентованим.
Логічна модель даних - опис об'єктів предметної області, їх атрибутів і взаємозв'язків між ними в тому об'ємі, в якому вони підлягають безпосередньому зберіганню у базі даних системи.
Логічна модель будується у декілька етапів з поступовим наближенням до оптимального для цих умов варіанту. Ефективність такої моделі залежить від того, наскільки близько вона відображає предметну область, що вивчається. До предметної області відносяться об'єкти(документи, рахунки, операції над ними і ін.), а також характеристики цих об'єктів, їх властивості, взаємодія і взаємний вплив.
Таким чином, при побудові логічної моделі даних спочатку виявляються ті об'єкти, які цікавлять користувачів проектованої бази даних. Потім для кожного об'єкту формулюються характеристики і властивості, що досить повно описують цей об'єкт. Ці характеристики надалі будуть відбиті у базі даних як відповідні поля.
Логічна модель даних будується у рамках одного з трьох підходів до створення баз даних. Виділяють наступні види логічних моделей бази даних :
Ієрархічна модель є деревовидною структурою, яка виражає зв'язку підпорядкування нижнього рівня вищому. Це полегшує пошук інформації у тому випадку, якщо запити мають таку ж структуру.
Мережева модель відрізняється від попередньої наявністю також і горизонтальних зв'язків. Це ускладнює як модель, так і саму базу даних і засобу її управління.
Реляційна модель представляє інформацію, що зберігається, у вигляді таблиць, над якими можливе виконання логічних операцій(операцій реляційної алгебри). Зараз цей вид моделей отримав найбільше поширення. Це пов'язано з порівняльною простотою реалізації, чіткою визначеністю стосунків між об'єктами, простотою зміни структури бази даних.
Модель предметної області
Одним з найбільш зручних інструментів уніфікованого представлення даних, незалежного від програмного забезпечення, що реалізовує його, являється модель "суть-зв'язок"(entity - relationship model, ER - model). Модель "суть-зв'язок" грунтується на деякій важливій семантичній інформації про реальний світ і призначений для логічного представлення даних. Вона визначає значення даних в контексті їх взаємозв'язку з іншими даними. Категорії "суть" і "зв'язок" оголошуються засадничими, і розділення їх робиться на етапі створення конкретних представлень деякої предметної області.
Кожна суть належить до деякого класу, інакше кажучи, їй відповідає деякий тип. Між сутностями є зв'язки, які користувач відносить до певного класу(типу). Таким чином, клас сутностей і клас зв'язків визначають безліч конкретних об'єктів і зв'язків між ними. Деяка суть може належати більш ніж до одного класу.
Сукупність сутностей і класів зв'язків утворює верхній рівень моделі.
Сутності і зв'язки описуються характерними для них атрибутами. Серед атрибутів якої-небудь суті або зв'язку виділяється підсписок, значення атрибутів якого однозначно ідентифікують суть або зв'язок в межах типу. Сутності, зв'язки і атрибути утворюють нижній рівень моделі.
Важливим є той факт, що з моделі "суть-зв'язок" можуть бути породжені усі існуючі моделі даних(ієрархічна, мережева, реляційна, об'єктна), тому вона є найбільш загальною.
Рисунок 4.8 - Модель "сутність-зв'язок"
Реляційна база даних складається з нормалізованих таблиць. В процесі завантаження і коригування бази даних, для отримання інформації по запитах і виведення звітів, а також для вирішення більшості завдань потрібний одночасний доступ до декількох взаємозв'язаних таблиць. Взаємозв'язок між таблицями бази даних встановлюється реляційними співвідношеннями.
Зв'язки, визначені в схемі даних, використовуються автоматично при розробці багатотабличних форм, запитів, звітів, істотно спрощуючи процес їх конструювання.
Програмний продукт представлений проектом - Cinema, який має 4 пов'язаних між собою таблиці:
База даних складається з різних об'єктів, таких як таблиці, види, домени, збережені процедури, тригери. Об'єкти бази даних містять всю інформацію про її структуру і дані. Реляційні бази даних зберігають усі дані в таблицях. Таблиця це структура, що складається з безлічі неупорядкованих горизонтальних рядків (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 |
Відмітка про оплату |
Структура додатка
Для реалізації інформаційної системи автоматизації введення даних про співробітників підприємства ставилася задача розробити модель для побудови додатка, орієнтованого на роботу з базою даних (БД). Під таким додатком мається на увазі набір форм, кожна з яких звичайно відображає ті або інші дані з таблиць БД. Загальна модель була побудована на основі багатовіконого інтерфейсу 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 - Ієрархія компонентів
Структуру модулів додатка складають наступні файли:
Алгоритми загальних і основних процедур
Алгоритм створення квитка
Програмою передбачена дві можливості створення квитка: автоматичне додавання, а так само додавання квитка за заданими критеріями.
Додавання квитка за заданими критеріями
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/