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

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

Візуальне моделювання в 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 Обґрунтування вибору програмних засобів

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

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

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

- високопродуктивний компілятор в машинний код;

- об'єктно-орієнтована модель компонент;

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

- засоби, що масштабуються, для побудови баз даних.

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

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

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

Практично всі сучасні СКБД використовують у своїй роботі технологію «клієнт-сервер» і СКБД 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, тому що воно надає широкий спектр засобів для реалізації разнопланових завдань у програмуванні і є об'єктно ориентованим.

4.4 Опис бази даних

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

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

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

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

- ієрархічна;

- мережева;

- реляційна.

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

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

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

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

Одним з найбільш зручних інструментів уніфікованого представлення даних, незалежного від програмного забезпечення, що реалізовує його, являється модель "суть-зв'язок"(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	Відмітка про оплату

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

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

Для реалізації інформаційної системи автоматизації введення даних про співробітників підприємства ставилася задача розробити модель для побудови додатка, орієнтованого на роботу з базою даних (БД). Під таким додатком мається на увазі набір форм, кожна з яких звичайно відображає ті або інші дані з таблиць БД. Загальна модель була побудована на основі багатовіконого інтерфейсу 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 - Формування чека на оплату

Висновки

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

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

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

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

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

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

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

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

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 с.

Размещено на Allbest.ur

...