Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Розробка програмного продукту. Етап реалізації
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Інститут комп’ютерних наук та інформаційних технологій
Факультет:
КН
Кафедра:
Не вказано
Інформація про роботу
Рік:
2012
Тип роботи:
Звіт до лабораторної роботи
Предмет:
Технологія програмування та створення програмних продуктів
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет «Львівська політехніка»
Інститут комп’ютерних наук та інформаційних технологій
Кафедра АСУ
Звіт
до лабораторної роботи №4
“Розробка програмного продукту.
Етап реалізації”
з дисципліни
“ Технологія програмування та створення програмних продуктів ”
Львів 2012
Мета: Ознайомлення з основними задачами, які необхідно розв’язати під час виконання етапу реалізації
Завдання: Навчитись реалізовувати моделі, які були побудовані на попередньому етапі проектування
Теоретична частина
Етап реалізації виконується в певному середовищі розробки і визначає надійність проекту. Вона досягається униканням або виправленням помилок.
Всі помилки усунути не можливо. Але ми можемо зменшити ймовірність їх виникнення, застосовуючи наступне:
відхід від небезпечних методів, наприклад використання вказівників,
обмежені принципи доступу (розділення пам'яті, принципи діапазону, інкапсуляція),
використання типізованих мов і компіляторів,
використання мов високого рівня,
послідовність у використанні інтерфейсів між модулями,
врахування надзвичайних ситуацій (порожні множини, цикли, невизначеності),
використання існуючих компонентів,
мінімум відмінностей між концептуальною моделлю і моделлю реалізації.
Немає методів без помилок, але ми можемо стверджувати, що програма виконуватиметься, не дивлячись на помилки. Такий механізм називають прикриттям помилок.
Він вимагає:
виявлення помилок,
опрацювання помилок,
виправлення помилок.
Опрацювання помилок є можливим, якщо виконана відповідна діагностика, можливо - вказання рядка з помилкою.
Існує два методи опрацювання помилок:
перевірка даних, наприклад, виконання тестованих формул,
порівняння результатів декількох версій модулів.
Ключові чинники успіху:
високоякісна і детальна специфікація,
хороше знання середовища розробки,
відповідність стандартів,
опрацювання помилок.
Основні результати етапу:
покращений документ, що описує вимоги,
покращена аналітична модель,
покращений проект,
код з перевіреними модулями,
звіт про перевірені модулі,
розроблена база даних,
планування етапу тестування.
Ця стадія виробництва програмного забезпечення (ПЗ) увійшла до ери автоматизованого виробництва ПЗ. Тут використовуються такі інструменти, як швидка розробка програм (Rapid Application Development, RAD) і мови високого рівня.
Покращені інструменти програмування і методи автоматизованої реалізації прискорюють виробництво ПЗ.
Надійність програмного забезпечення
Надійність є найголовнішим чинником створення ПЗ. Вимоги клієнтів до ПЗ зазвичай ростуть швидше, ніж вимоги до апаратури. Зараз існує надзвичайно різноманітне ПЗ і воно постійно ускладнюється.
На першому етапі необхідна надійність повинна задаватися умовно, що дозволило б виробникові спланувати всі кроки і розмістити ресурси для того, щоб досягти поставлених завдань.
Основними методами збільшення надійності є:
запобігання помилкам;
визначення похибки помилок.
Запобігання помилкам
Всіх помилок уникнути неможливо, але є способи, що допоможуть зменшити їхню кількість:
Не використовувати методи з великою вірогідністю помилок (наприклад, використання вказівників і т.п.);
Використання принципу обмеженого доступу (інкапсуляція, розділення пам'яті і т.д.);
Використання мов і компіляторів з перевіркою відповідності типів;
Використання мов високого рівня;
Строго визначати інтерфейси користувача;
Приділити увагу виключенням (порожні множини, порожні цикли, нульові значення, змінні, що не були ініціалізовані, і т.д.);
Використання готових компонентів (бібліотеки, класи і т.д.);
Мінімізація відмінностей між абстрактною моделлю і моделлю реалізації.
Небезпечні техніки
Програміст може подолати проблему різними способами. Шляхи і вибір методу залежить від проблеми, досвіду, його переваг, вибору мови, середовища і т.п.
Але методів з більшою вірогідністю помилки слід уникати. Іноді їх дійсно необхідно застосувати. У таких випадках методи обробки помилок і контролю результатів повинні розроблятися дуже ретельно.
Найнебезпечнішою технікою програмування є:
Використання команди "goto". Ця команда може призвести до труднощів розуміння програм і їх підтримки (внесення подальших змін).
Використання чисел з плаваючою крапкою. Числа мають обмеження по точності, і обчислення можуть накопичувати відхилення від реальних чисел.
Використання вказівників і адресної арифметики з їх використанням. Вказівники є надзвичайно небезпечними. Вони дозволяють проникнути в пам'ять і здійснити в ній будь-які зміни. На них необхідно звертати увагу.
Паралельне обчислення. Паралельні обчислення приводять до складної залежності часу і так званому галопуванню (залежить від випадкових результатів деяких потоків). Їх важко перевірити.
Використання виключень і переривань. Використання цієї техніки веде до паралелізму і провокує такі ж проблеми. Так само це може "підвісити" програму.
Використання рекурентних співвідношень. Програму з рекурентними співвідношеннями важко зрозуміти і трасувати.
Використання динамічного розподілу пам'яті. Динамічний розподіл пам'яті без контролю даних може призвести до втрат інформації і "підвісити" програму.
Несподівані побічні ефекти у функціях і процедурах.
Використання складних виразів без дужок. Таке відбувається, коли програмісти покладаються на пріоритет операторів і уникають дужок. Це не веде до збільшення продуктивності. Але підхід може викликати багато помилок і труднощів в управлінні.
Обробка даних багатьма процесами без синхронізації (блокування, транзакції). Деякі з методів є корисними, але їх потрібно використовувати обережно.
Принцип обмеженого доступу
Принцип обмеженого доступу - один з основних принципів безпеки. Він полягає в тому, що доступ дозволяється тільки до необхідних даних.
Він може бути сформульований таким чином:
Все, що повинно бути схованим, слід приховати.
Програміст не повинен мати доступу до даних, що не є потрібними для виконання певного завдання. Права доступу повинні бути обмежені. Типові мови програмування не задовільняють цю вимогу. Воно застосовується в операційних системах, наприклад, DOS і WINDOWS.
Принцип обмеженого доступу реалізується інкапсуляцією (відомою з Modula 2) і об'єктно-орієнтованим підходом.
приватні поля, змінні, методи
таблиці експорту
таблиці імпорту (визначають внутрішні ресурси)
Строгий контроль типів
Типізація - це вираз (і деяка абстракція програмування), який застосовується до деяких одиниць програмування (змінні, процедури, методи, дані, функції, параметри, події, виключення, модулі).
Тип визначає значення даних і є формальним обмеженням конструкції змінних і об'єктів.
Мета типізації - керувати формальним програмуванням.
Типізація підтримує об'єктно-орієнтоване програмування. Ім'я зазвичай відображає семантику об'єкту, наприклад, D представляє дані (від Data). У мовах з сильною типізацією (наприклад, Pascal і Modula2) така ідентифікація повинна бути присутньою в оголошенні типів. Оголошення перевіряються (наприклад, якщо програміст оголосить X як ціле число (integer), компілятор перевірить, чи всі виклики сприймають X як ціле число.
Сильна типізація запобігає помилкам в 80% випадків. На жаль, в багатьох комерційних продуктах цей контроль не повний, або ним і зовсім нехтують (Smalltalk, SQL).
Система сильного статичного контролю типів містить наступні елементи:
Специфікація всіх видів змінних і об'єктів, наприклад:
Typedef TypWorker = struct{string name, int salary, Works_in, int salary_without_taxes()};
TypWorker Worker;
Визначення сигнатури всіх операторів, процедур, функцій, методів, наприклад:
Boolean works_long (in TypWorker wrkr, in WorkSphere, out years_works)
Визначення інтерфейсів, класів і інших інкапсульованих абстракцій.
При визначенні параметрів ми вказуємо параметри вводу і виводу.
Правила типізації інтерфейсу є важливими для всіх конструкцій мови. У аналізі семантики повинне бути проведене визначення результуючих типів конструкцій. Перевірка типів посилань - перевірка типів в методах, процедурах і т.д. Також перевіряється, чи немає посилань на типи, які не оголошені або недоступні.
Похибка
Жодна техніка не гарантує, що програма не матиме помилок. Похибка помилки означає, що програма працюватиме нормально навіть коли вона матиме помилки.
Тому програма повинна:
виявляти помилки;
відновлюватися після помилки, коректно завершуватися;
проводити корекцію помилок, тобто вносити зміни, щоб позбутися помилки.
Важливо провести діагностику помилки. Рядок коду, в якому відбулася помилка, повинен бути визначений.
Є два основні методи автоматичного виявлення помилок:
Перевірка коректності даних. Метод складається з розміщення додаткових рядків в код для того, щоб перевірити коректність даних.
Порівняння декількох версій модулів.
Порівняння декількох версій модулів
Порівняння декількох версій модулів дає удосконалення надійності. Це застосовується лише в особливих випадках, оскільки вимагає великих інвестицій. Це використовується тільки для надзвичайно важливих програм.
Багатоваріантне програмування може бути реалізоване декількома способами:
Перший з них називається n-версії. Він розробляється n незалежними програмістами. Програми виконуються паралельно і результати порівнюються PCU. У разі розбіжності PCU вибирає правильний результат, наприклад, "голосування" використовується для ухвалення рішень. Службові дані для таких обчислень є важливим чинником. Проблема критично важлива для таких систем, як системи реального масштабу часу (Real Time Systems, RTS), для яких потрібно брати до уваги час реакції, наприклад, на погодні умови або кут нахилу літака.
Характеристики n-рівневого рішення паралельні, з одночасним відкриттям операцій над загальними даними декількома незалежними модулями.
Рисунок 1.
Інше рішення - це програмування з допоміжними модулями. Метод припускає існування двох модулів, один з яких активний, а інший використовується для перевірки результатів активного модуля. Якщо виявляється будь-яка некоректність, додатковий операційний модуль замінює базовий модуль. Існують різні версії паралельних рішень.
Рисунок 2
Транзакції
Транзакція - послідовність операцій що виконуються, які не можуть бути розділені і є одним цілим.
Транзакція складається з наступних операцій:
читання даних x транзакцією T,
запис даних x транзакцією T,
відміна транзакції T,
ухвалення транзакції T.
Транзакції використовуються для компактності та у випадку паралельних операцій.
Якщо виконується значна кількість процесів, компактність може не дотриматися і є можливість виникнення помилок.
У таблиці 1. наведена схема роботи двох процесів А і B, які використовують загальні дані.
Таблиця 1.
У Таблиці 1. наведено два паралельні процеси, які не порушують компактність.
Таблиця 2.
У таблиці 2. наведено два процеси, які порушують компактність.
Блок 6 не компактний. Є два процеси, які при незалежному виконанні дадуть результат 11. Відсутність синхронізації призведе до того, що один з процесів не буде оновлений.
Приклад: ми маємо 4 автори, які оновлюють тест. Якщо немає ніякого протоколу щодо оновлень, деякі виправлення можуть бути втрачені.
Транзакції роблять можливою підтримку сумісності процесів. При цьому ручна синхронізація або домовленості не потрібні.
Транзакції захищають від неповних виконань, які можуть з'явитися після збоїв.
Уявімо банківську систему з наступними операціями над рахунками клієнта F.
Клієнт читає магнітну картку і авторизується
Клієнт оголошує суму
Рахунок перевіряється
Залишок на рахунку зменшується на вказану суму
Посилається замовлення передачі
Касир знімає суму з рахунку
Касир проводить оплату
Питання полягає в тому, що трапиться, якщо між операцією 4 і 5 відбудеться відключення електрики. Рахунок зменшиться, клієнт не отримає грошей, фактичні дані втрачаються, директор скаже, що заяву слід писати електростанції, клієнт не погодиться і загрожуватиме позивом до суду і т.п.
Транзакції гарантують компактність даних і захищають від апаратного збою, помилок ПЗ, проблем з персоналом і т.д.
Постулати ACID
Транзакції гарантують відновлення до стану перед виникненням помилки. Це - основний принцип для забезпечення надійності програмного забезпечення, що працює з базами даних.
Під транзакціями розуміють наступні властивості:
(A) Атомарність – у всіх транзакціях виконується або одна операція, або нічого.
(C) Цілісність – якщо транзакція увійшла до цілісної бази даних, то поля і база даних повинні теж залишитися цілісними.
(I) Ізоляція – транзакція не знає про інші транзакції і не втручається в їх дії. Дії, що виконуються однією транзакцією, не повинні бути видимі іншим, поки не будуть отримані результати.
(D) Стійкість – після того, як транзакція завершиться, результати записуються на жорсткий диск і не можуть бути змінені випадковим чином, наприклад, відключенням електрики.
Транзакції в SQL
У SQL кожна транзакція починається з почати транзакцію (BEGIN TRANSACTION), і закінчується операцією фіксування(COMMIT), що позначає правильне закінчення, або відкат (ROLLBACK) (або відміна (ABORT)), означає повернення до початкового стану (або відміну) транзакції.
Такі команди, як вибрати, вставити, відновити, видалити, створити запускають транзакцію, якщо вона ще не була запущена.
Транзакція виконується, поки команда фіксувати (підтверджуюча) або відкат(що перериває або повертає). Транзакція може містити в собі такі слова, як видалити, створити, вставити, створити і т.д.
Приклад транзакції з командами відміна та фіксування наведені на рис. 3:
Рисунок 3. Приклад використання транзакцій.
Застосування блокування та проблеми, пов'язані з цим
Транзакції вимагають застосування спеціальних модулів (планувальників) і протоколу обробки транзакцій.
Щоб уникнути проблем з розподіленою обробкою використовуються блокування.
Існує два типи блокувань:
Блокування X-типу – повністю блокує доступ до транзакції
Блокування S-типу - це блокування передбачає режим "лише читання", але транзакцію не можна модифікувати.
У реляційній базі даних найчастіше використовується протокол двофазного блокування 2PL.
Правила приведені нижче:
Якщо операції pi(x) можуть виконуватися, блокування застосовується на транзакцію Ti і операція виконується. Якщо операція не може виконуватися, вона розміщується в чергу.
Видалення блокування виконується після завершення транзакції.
Якщо блокування було видалене з транзакції, транзакцію вже не можна заблокувати.
Згідно з правилами є дві фази виконання транзакцій. У першій фазі ставляться блокування, а в другій вони видаляються. Перша фаза довша за другу.
Рисунок 4. Протокол 2PL.
Застосування блокування може призвести до взаємного блокування і зависання. Використання блокування змушує транзакцію дочекатися звільнення ресурсу. Розглянемо три транзакції:
Транзакція А блокує ресурс X і вимагає доступу до ресурсу Y. Транзакція B блокує доступ до ресурсу Y і запитує доступ до ресурсу X. Виходить взаємоблокування, і жодна з транзакцій не може завершитися.
Приклади блокувань зображені на малюнку:
Рисунок 5. Взаємоблокування транзакцій.
Рисунок 6. Взаємоблокування транзакцій.
Взаємоблокування є серйозною проблемою і можуть вплинути на результат роботи.
Методи боротьби з взаємоблокуваннями:
Метод 1.
Виявлення взаємних блокувань і переривання циклу. Для виявлення взаємних блокувань використовується споруджений граф. Переривання циклу відбувається шляхом видалення однієї з конфліктуючих транзакцій і її повторним запуском. Вибір ґрунтується на різних критеріях: остання, з найменшим робочим навантаженням, з низьким пріоритетом.
Метод 2.
Уникнення взаємних блокувань. Є багато таких методів, наприклад:
Попередній запит ресурсу: перед початком кожна транзакція визначає свої потреби. Зміни не вносяться. Недолік - зниження ефективності паралельного обчислення.
Чекай-помри (wait-die): якщо транзакція намагається дістати доступ до заблокованого ресурсу, вона відміняється. Це неприпустимо для діалогових систем, оскільки користувач може бути збентежений потребою багатократного введення даних. Це зменшує продуктивність.
Часова мітка і розбиття транзакцій
У обробках транзакцій застосовуються схеми, засновані на впорядкуванні до потрібної часової мітки. Кожній транзакції привласнюється унікальна часова мітка, коли вона запускається. Часова мітка визначає свою позицію в часовій послідовності в процесі виконання транзакцій. Впорядковування часових міток засноване на конфліктах операцій і є дуже простим:
Запит транзакції на запис об'єкту був можливим тільки тоді, коли об'єкт був прочитаний і записаний востаннє попередніми транзакціями. Запит транзакції на читання об'єкту можна задовольнити лише якщо об'єкт був востаннє записаний попередніми транзакціями.
Це правило припускає, що є лише одна версія кожного об'єкту, і обмежує доступ до транзакції за один раз. Якщо кожна транзакція має свої власні версії об'єктів, то декілька транзакцій можуть звернутися до об'єкту одночасно.
Проблема блокування також має відношення до розбиття. Розбиття визначається рішенням, яка транзакція повинна бути неподільною, щоб її не можна було заблокувати.
Розглядаються наступні рівні:
база даних,
відносини,
записи,
елементи запису,
індивідуальний атрибут,
фізичні аспекти пам'яті.
Великі частини розбиття можуть забезпечити відповідність, але мають небагато паралельних процесів. Малі ж вимагають багато блокувань і обслуговування.
Можливість системного відновлення від операційної аварійної відмови є тільки завдяки представленню операційного словника, в якому зареєстровані або просто всі дані, або всі різні дані. Обробка транзакцій вимагає додаткового робочого навантаження і використання системи.
Середовище реалізації
Середовище процедурних мов
Це традиційне середовище реалізації. Процеси і модулі можуть бути представлені цілими програмами. Групи Процедур і функцій відповідають системним функціям. Пам'ять і контейнери в проекті відповідають структурам мови.
Процедурні мови не забезпечують достатні механізми для контролю доступу до даних. Доступ до структур отримується легко. Є інші мови, наприклад, Ada, Modula 2, які мають досконаліші механізми.
Об'єктно-орієнтовані середовища
Середовища, що застосовують об'єктно-орієнтований підхід, корисні, оскільки відображення між проектною моделлю і моделлю реалізації просте.
Проте їх не достатньо у разі великих проектів і тоді вони вимагають складної обробки даних і використання баз даних.
Більшість об'єктно-орієнтованих мов - це гібридні мови, які були розроблені, ґрунтуючись на процедурних мовах, з додаванням до них об'єктної орієнтації. Одна з таких мов - C++.
Такі мови, як Eiffel, Visual Age, і Smalltalk показують, що гібридні мови стають все менш популярними.
Середовища реляційних баз даних
Найрозвиненіші середовища зараз використовують реляційні бази даних.
Їхні переваги:
множинний доступ;
автоматична перевірка цілісності;
користувачеві привласнюються права доступу;
висока надійність;
розширюваність (обмежена);
високий рівень доступу (SQL, ODBC, JDBC).
Також є і недоліки:
ускладнені відображення абстрактної моделі;
низька ефективність для деяких завдань;
обмежена типізація;
недолік механізмів інкапсуляції і інших об'єктно-орієнтованих механізмів;
збільшена довжина програми.
Об'єктно-орієнтована база даних
Перевага об'єктно-орієнтованої бази даних - вищий рівень абстракції. Це полегшує проектування і реалізацію одного і того ж застосування в ефективнішій, сумісній і однорідній формі.
Досягнуте спрощення і систематичний підхід до розробки проекту, зменшення відстані між фазою аналізу, розробки і програмування, мінімальні поняття ввели вищий рівень абстракції.
Об'єктно-орієнтований підхід вводить більшу кількість понять, саме тому реляційна модель розширює мозкову функцію.
Об'єктно-орієнтовані бази даних (ObjectStore, O2, Versant, Gemstone, Poet, Objectivity/DB, Jasmine, Jade і т.д.) вже є розвинутими, але все ще ведуть боротьбу за клієнтів.
Об'єктно-орієнтовано-реляційні середовища баз даних
Завдяки успіху об'єктно-орієнтованого підходу багато понять були введені в реляційні середовища.
Підхід називається "гібридним" або "об'єктно-орієнтовано-реляційним". Сервер з назвою "Універсальний сервер" також стає популярним, що означає можливість зберігання і обробки об'єктів, відносин, мультимедійних даних і т.п. Концептуальна ідея полягає в тому, щоб застосувати відомі реляційні технології (наприклад, SQL) і ввести об'єктну орієнтацію "вищого рівня".
Об'єктно-орієнтовано-реляційні системи (Oracle-8, Informix Dynamic Server і т.п.) розвиваються поступово.
Середовище програм користувача
Приклад середовища програми користувача - Microsoft Office, документи якого можуть бути оброблені багатьма програмами.
Наприклад, найважливішими особливостями Microsoft Excel є: повністю процедурна мова Visual Basic для програм, добре розроблена об'єктна бібліотека, яка надає майже всі пакети, дозволяє реєстрацію макроозначень, можливість створення інтерфейсного діалогу, розміщуючи поля у листах, обладнана відлагоджувачем, має вдосконалений метод роботи з DLL, DDE, OLE, ODBC.
Перераховані методи роблять MS Office середовищем, яке може використовуватися для розробки програм зі складним логічним і швидким прикладним розвитком.
Інструментарій CASE на етапі реалізації
Прогрес інструментів CASE останнім часом полегшив життя програмістів. Вони можуть застосовувати інструменти CASE безпосередньо для перегляду діаграм і словника баз даних. Деякі системи CASE генерують коди, які створюють діаграми і шаблони.
Типовими кодовими елементами є:
скрипти, що створюють відношення в базі даних;
визначення структури даних;
заголовки процедур і функцій;
визначення класів;
заголовки методів.
Код завершується багатьма коментарями, що засновані на словнику баз даних. Деякі з інструментів CASE мають інтерфейс для RAD.
Чинники успіху і результати етапу реалізації
Успіх етапу реалізації залежить від багатьох чинників. Найголовніші - якість проекту, хороше знання середовища і відповідність стандартам.
Основними результатами етапу реалізації є:
Розширений документ, що описує вимоги;
Розширена аналітична модель;
Розширений проект, який в даний момент завершується документацією;
Код, що складається з протестованих модулів;
Звіт, що описує результати тестів;
Спроектована і створена база даних;
Розклад етапу тестування.
Приклад виконання етапу реалізації
Згідно з поставленими вимогами до етапу реалізації, було проведено реалізацію продукту Cinema. Далі наведені основні результати даного етапу:
Розширений документ, що описує вимоги
На даному етапі розробки ПЗ не було внесено ніяких змін до документу описання вимог, оскільки було реалізовано лише ті вимоги, які було поставлено.
Розширена аналітична модель
Аналітична модель не була змінена порівняно з етапом розробки цієї моделі, було використано тільки її можливості для реалізації цього програмного забезпечення.
Розширений проект, який у даний момент завершується документацією
На даний момент проект складається з трьох частин (модулів):
Admin – це частина проекту, яка відповідає за налаштування та зміну програми, відповідає за підтримку правильності її роботи .
Sys_core – частина проекту, яка відповідає за основні функції, які може виконувати дана програма.
Users – частина проекту, яка відповідає за функції та дії користувачів.
Опис класів модуля Sys_core, який описує функції системи. Реалізований на мові Java , оскільки Java підтримує багатопоточне програмування, яке дозволяє легко розробляти програми, що викинують багато процесів одночасно, підтримує функцію "прибирання сміття", що дуже корисно.
Модуль Sys_core містить класи, які використовуються системою для :
RellCinema – зв’язок з іншими кінотеатрами та обмін інформацією
Secure – захист від атак зловмисників та взлому системи, попередження збоїв системи
ErrorProc – виправлення помилок в системі
UsersInfo – відображення інформації про користувачів
Protocols – управління протоколами
Опис класів модуля Users, який описує можливості та функції користувачів.
Даний модуль реалізований на мові Borland Builder C++ 6.0. Компілятор цієї мови на даний час, є найшвидшим у світі, його швидкість компіляції складає понад 200 тисяч рядків у хвилину. А оскільки в даному модулі відбувається взаємодія з користувачем, то швидкість виконання операцій має одне з найважливіших значень.
Модуль Users містить класи, які описують різні дії користувачів системи:
Register – реєстрація в системі
Search – пошук інформації про фільми за певним критерієм
Is_Ticket – збір інформації про наявність вільних квитків
Buy_Ticket – купівля квитка
Change_Num – зміна кількості квитків у замовленні
Pay_Ticket – оплата кредитною карткою, перевірка наявності грошей на рахунку
Discount – призначений для надання знижок постійним клієнтам, ідентифікації користувачів у базі
Log_In_Out – вхід/вихід із системи
Main - описаний інтерфейс системи, за допомогою цього класу виконуються всі основні операції системи.
Опис класів модуля Admin, призначеного для редагування стану системи і її налаштувань,внесення змін у базу даних, оновлення сторінок. Реалізований на мові Java, оскільки основна перевага мови java полягає в тому, що вона незалежна від платформи, де передбачається запускати написаний нею додаток. :
Модуль Admin містить класи, які використовуються для налаштування системи та редагування бази даних.
SysInfo – інформація про стан системи, кількість користувачів
DBEdit – редагування, зміна бази даних, налаштування системи
ChangeWeb – зміна інтерфейсу сайту.
Опис тестування класів
Клас Register відображає вікно з полями для заповнення. Якщо користувач вводить некоректну інформацію (логін вже використовується, невірний пароль і т. ін.) чи заповнить не всі поля, то система виводить інформацію про помилку та дає змогу користувачу ввести дані повторно. Якщо ж реєстрація пройшла успішно – на поштову скриньку користувача відсилається лист з підтвердженням реєстрації та здійснюється вхід в систему.
Клас Search здійснює пошук інформації про фільм за назвою. Якщо такого фільму не знайдено в базі, система повертає користувачу інформацію про відсутність інформації та просить перевірити правильність написання. Якщо ж всі дані були введені коректно і система знайшла потрібну інформацію – користувач отримує інформацію по даному фільму ( короткий зміст, проморолик, час показу у всіх кінотеатрах Львова)
Клас Is_Ticket збирає інформацію про наявність квитків на сеанс. Якщо вільних квитків вже немає, то виводить відповідне повідомлення, в протилежному випадку - надає користувачу інформацію про наявні квитки ( перелік вільних місць).
Клас Buy_Ticket. Якщо користувач вирішив придбати квиток на сеанс, він повинен оформити замовлення. Для цього необхідно заповнити форму та перевірити наявність квитків на обраний фільм. Якщо форма заповнена невірно (введені некоректні дані чи не всі поля заповнені), то користувач отримує повідомлення з проханням редагувати дані, якщо ж немає квитків на вказаний сеанс - повідомлення з інформацією про відсутність місць Якщо ж все введено вірно і вільні квитки є в наявності, то формується замовлення і користувач отримує відповідне повідомлення.
Клас Log_In_Out. Запитує у користувача логін і пароль для входу в систему. Якщо введені дані некоректні – виводить повідомлення про помилку і прохання ввести дані повторно. Для введення надається три спроби. Якщо ж все введено вірно – здійснює вхід в систему.
Клас Change_Num викликає форму з замовленням та дає змогу користувачу змінити кількість квитків у замовленні. У разі відсутності потрібної кількості квитків - користувач отримує відповідне повідомлення, в протилежному випадку - вносяться необхідні зміни в замовлення .
Клас Pay_Ticket. Перевіряє коректність номеру рахунку, який вказаний в замовленні та наявність там коштів. В разі нестачі коштів на рахунку користувач отримує відповідне повідомлення , та повідомлення з проханням ввести ще один номер рахунку в зв’язку з відсутністю коштів на попередньому.
Клас Discount ідентифікує замовника в базі та перевіряє можливість надання знижки. Якщо такого користувача в базі не було знайдено, оскільки це його перше замовлення, то він отримує повідомлення в відмовою у наданні знижки. Якщо ж замовник є постійним клієнтом, то здійснюються відповідні зміни в рахунку та він отримує знижку.
Клас SysInfo. У відповідь на запит користувача видає інформацію про систему і усіх зареєстрованих користувачів. Якщо запит некоректний – виводить інформацію про помилку і прохання повторити введення.
Клас DBEdit. У випадку внесення змін у базу даних (видалення, додавання чи редагування існуючих записів) надсилає прохання про підтвердження операції. Якщо ж користувач(можливо лише в режимі адміністратор) підтвердив виконання дії - вносить зміни та зберігає базу даних. Після чого оновлює інформацію в системі.
Клас ChangeWeb. У випадку будь-якої зміни інтерфейсу надсилає прохання про підтвердження зміни.
Якщо ж користувач(можливо лише в режимі адміністратор) підтвердив виконання дії - вносить зміни та зберігає їх.
Клас ErrorProc. У відповідь на будь-які помилки видає системне повідомлення. У випадку дій користувача, які перевищують можливості даного користувацького рівня, надсилає повідомлення про помилку і прохання ввійти як адміністратор для доступу до всіх функцій системи. Якщо ж помилка несуттєва – обмежується лише коротким інформаційним повідомленням.
Клас Secure. Заблоковує можливість входу в систему даного користувача у разі неправильного введення логіна та паролю три рази підряд. У відповідь на спробу несанкціонованого доступу в систему чи спробу зламати захист системи надсилає аварійне повідомлення адміністратору, який і приймає всі наступні рішення.
Розклад етапу тестування
Тестування авторизації користувача в систему. Вхід під різними режимами доступу
Перевірка можливості управління даними про користувачів. Збереження та відновлення параметрів користувача. Встановлення прав доступу користувачам
Перевірка зв’язку з базою даних та іншими кінотеатрами
Перевірка системних установок, їх збереження та відновлення в вікні установок
Перевірка доступності пунктів меню системи відповідно до функціональних можливостей користувача.
Перевірка механізму формування замовлення квитка та внесення змін до замовлення, видалення замовлення.
Перевірка можливості бронювання квитка та надання знижки постійним клієнтам.
Перевірка механізму пошуку фільму за назвою.
Механізм створення квитка. Створення вихідного документа в форматі DBF в папці квитків. Механізм збільшення значень продажу в системі після здійснення замовлення та отримання користувачем квитка
Перевірка на стабільність системи. Неможливість виходу з програми в процесі замовлення квитка. Неможливість виконання заборонених функцій системи. Активація режиму адміністратора в системі без зміни користувача
Висновок. Під час виконання цієї лабораторної роботи я ознайомилась з основними задачами, які необхідно розв’язати під час виконання етапу реалізації.
13.02.2013 23:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора