Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Розробка програмного продукту. Етап проектування та побудова моделі
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Інститут комп’ютерних наук та інформаційних технологій
Факультет:
КН
Кафедра:
Не вказано
Інформація про роботу
Рік:
2010
Тип роботи:
Звіт до лабораторної роботи
Предмет:
Технологія програмування та створення програмних продуктів
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет «Львівська політехніка»
Інститут комп’ютерних наук та інформаційних технологій
Кафедра АСУ
Звіт
до лабораторної роботи №3
“Розробка програмного продукту.
Етап проектування та побудова моделі”
з дисципліни
“ Технологія програмування та створення програмних продуктів ”
Мета: Ознайомлення з основними задачами, які необхідно розв’язати під час виконання етапу проектування та побудови моделі.
Завдання: Навчитись реалізовувати етап проектування та побудувати модель при розробці програмного продукту комп’ютерних cистем.
1. Теоретична частина
Цей етап потрібний для детального опису реалізації системи. Опис після необхідних змін, зроблених на наступних етапах (реалізації і тестування), буде частиною технічної документації системи.
Всупереч аналізу на етапі проектування, проектувальники повинні знати, що програмне середовище, мови програмування, бібліотеки і інші інструменти будуть застосовані на етапі реалізації.
На цьому етапі виконується перетворення абстрактних понять, використовуваних в аналізі, в детальніші описи всіх конструкцій.
У ПЗ існує декілька складових, одна з них представляє частину проблем, відповідальних за основне виконання функцій і необхідні дані. Вона будує якнайкращу модель, розроблену після аналізу. Інші частини відповідальні за комунікацію з клієнтом, за зберігання і доступ до даних, управління пам'яттю і компонентами управління завданнями.
На етапі проектування також виконується оптимізація моделі.
Програмне середовище забезпечує інструменти, які обмежують раніше розроблену модель, але воно може також забезпечити допоміжний механізм, який дозволяє поліпшити реалізацію. Таким чином проектування будує модель до рамок обмежень та поліпшує можливості програмного середовища.
Фізична структура моделі повинна бути також визначена на цьому етапі.
Таким чином, на етапі проектування виконуються наступні завдання:
специфікація результатів аналізу;
проектування компонентів, які не належать області проблеми;
оптимізація системи;
підлаштування моделі до обмежень і варіантів програмного середовища;
визначення фізичної структури.
Детальна модель приводить до вибору з багатьох можливих методів реалізації конструкцій моделі.
Основні конструкції повинні підтримуватися допоміжними:
інтерфейс для роботи з користувачем;
компонент управління даних для зберігання даних;
компонент управління пам'яті;
компонент управління завданнями для їх планування.
Основні чинники успіху етапу проектування:
висока якість моделі;
хороше знання середовища розробки;
узгодженість із стандартами;
перевірка системи;
проектна оптимізація повинна бути виконана на значних фрагментах системи.
Основні результати етапу проектування:
виправлений документ формулювання вимог;
виправлена модель;
детальна специфікація;
документ, що описує проект:
діаграми класів;
діаграми взаємодій;
діаграми станів;
діаграми діяльності;
діаграми компонентів;
визначення ознак класів, складних і елементарних даних, методів.
ресурси інтерфейсу користувача;
проектування баз даних;
фізичний проект структури системи;
виправлений тестовий проект;
планування виконання.
Метою проектування є розробка моделі, необхідної для нормального функціонування системи. У проектуванні середовище програмування відіграє важливу роль, не дивлячись на те, що під час аналізу ним часто нехтують. Проектувальник повинен знати мови програмування, бібліотеки і інструментальні програмні засоби, необхідні для функціонування системи.
Проектувальник повинен зберегти структуру системи, розроблену раніше (в процесі аналізу). А внесені зміни в загальному мають впливати на проект.
Дії на етапі проектування
На етапі проектування реалізуються деталі, що ігноруються в процесі аналізу. Рівень деталізації залежить від професіоналізму програміста. Проект повинен містити всі деталі необхідні для функціонування системи.
Розробник повинен врахувати всі можливості та обмеження середовища і визначити фізичну структуру системи.
Під час проектування виникають нові терміни і визначення, що поповнюють запас термінів, які використовувалися під час аналізу.
Різні сценарії проектування припускають різні підходи.
Поле і символи доступу опису методу повинні бути індикатором того, як програмістові слід реалізувати клас.
Доступ може бути визначений:
(+) публічний (public) – для всіх функцій і методів;
(#) захищений (protected) – доступ, дозволений певному класу певної спеціалізації;
(-) особистий (private) – доступ тільки для функцій певного класу.
Специфікація результатів аналізу
Для етапу проектування необхідне детальне визначення результатів аналізу.
Специфікація складається з правил формулювання і відображення результатів на програмній мові і містить в собі:
1. Визначення методів.
Заголовки і параметри додаються до функцій і рішень для того, щоб позначити які з них повинні бути віртуальними (динамічні зв'язки), а які – статичними.
Рис. 1.1. Складання запису на мові C/C++.
Специфікація методу повинна замінити деякі методи прямим доступом до властивостей. Наприклад метод GetLastName, SetLastName, представлений під час аналізу, повинен бути заміщений прямим доступом до останнього імені на етапі проектування. Інша специфікація може приймати форму заміщених атрибутів відповідних методів. Наприклад, атрибут Вік або атрибут Прибуток може бути замінений методами, що підраховують значення: Вік = Сьогодні - Дата_народження; Прибуток = Загальний_прибуток - Кредити.
2. Специфікація асоціативного виконання
Асоціації можуть бути виконані багатьма шляхами. Зазвичай - представленням нових атрибутів.
Вони можуть бути:
об'єкти дочірнього класу;
вказівники на дочірній клас;
ідентифікація об'єктів дочірнього класу;
ключові значення дочірнього класу.
Оголошення на даній мові залежить від способів зв'язків і числа асоціацій.
3. Спеціальні правила для перетворення зв'язаних об'єктом схем у схеми відношення
Наступний проект із специфікації описує первинні компоненти, щоб виконати завдання базової системи.
Проте, завершене програмне забезпечення повинно бути доповнене іншими компонентами:
компонент інтерфейсу користувача;
компонент управління даними;
компонент управління пам'яттю;
компонент управління завданнями (планування).
Рис. 1.2. Компоненти системи.
Проектувальник повинен визначити компоненти, які безпосередньо не пов'язані з областю використання і розширити модель, проектуючи їх виконання.
Швидка розробка програм (rapid application development, RAD)
Швидкою розробкою програм називаються методи швидкого прототипування або отримання готових застосувань. Термін RAD використовується іноді як синонім мов/середовищ розробки нового покоління (4GL). Приклади RAD-інструментів: Borland Delphi RAD Pack, IBM Visual Age (для Small Talk), Microsoft Access Developer’s Toolkit, Microsoft Visual FoxPro Professional, Visual Studio FoxPro, PowerBuilder Desktop, Power++ та інші.
Легка реалізація деяких функцій повинна розвинути прямі відносини між призначеним для користувача інтерфейсом (діалоги, звіти) і управлінням базою даних (зазвичай, зв'язаною). Компоненти області найменше підпорядковані комп'ютеризації. Обмеження і нетипові особливості виключають застосування RAD.
Дизайн інтерфейсу
З точки зору користувача, інтерфейс програми є дуже важливим і його функціональність може визначити думку користувача про продукт.
Тому розробник повинен витрачати багато часу і зусиль на розробку інтерфейсу, який відповідає очікуванням користувача. Рекомендується врахувати переваги тих чи інших варіантів перед початком роботи над проектом. Це можна зробити, якщо проглянути ПЗ користувача і спосіб його використання. Також рекомендується робити інтерфейс інтуїтивно зрозумілим.
Рис. 1.3. Створення посилання на індекс.
Як приклад ми можемо взяти створення посилання на індекс, що зображене на рис. 1.3. Користувач очікує знайти посилання на дану сторінку. Як показують дані, користувач очікує віднайти посилання або зліва вгорі, або посередині нижнього колонтитулу. Тому розташування посилання в лівому нижньому кутку зробило б інтерфейс менш інтуїтивним і могло б викликати складнощі у користувача.
Розробка інтерфейсу стала простішою останніми роками, оскільки з'явилося багато графічних інструментів для цієї мети. Також існують системи з управлінням інтерфейсом, наприклад, Zapp Factory, Visual Basic. Візуальні інструменти дають можливість інтерактивно розробляти діалоги, вікна, меню, порозрядні карти відображення інформації та ікони. Вони дають змогу визначити реакцію системи у відповідь на різні події, наприклад, зроблені користувачем (вибір запису в меню, переміщення курсору над певними областями і т.д.), легке і швидке генерування графічного, програмного проекту або інших кодів.
Організація взаємодії з користувачами
Спілкування з користувачем здійснюється:
через командний рядок;
через графічне середовище.
Командний рядок використовується для простих, маленьких систем, прототипів або особливою досвідченою групою користувачів. Ця взаємодія швидша, ніж з використанням повноекранного інтерфейсу.
Швидкість створення інтерфейсу для всіх доступних інструментів, які допомагають розробці, не так важлива як раніше. Зв'язок, що використовує команди, швидший, але вимагає знання середовища. Тому ми не повинні забувати про клавішні комбінації швидкого виклику.
Середовище вікон простіше для засвоєння початківцями та середньо статистичними користувачами. Воно дає змогу провести незалежне, інтуїтивне вивчення програми, без потреби в знанні семантики текстових команд.
Типові способи взаємодії користувача з системою такі:
командний рядок;
вибір умови;
клавішні комбінації швидкого виклику;
ікони на панелі інструментів;
вибір в діалозі;
навігація мишею.
Введення і читання даних здійснюється:
користувачем:
введення параметрів в командний рядок;
введення даних у відповідь на системний запит;
введення даних в діалозі;
системою:
відображення інформації в діалозі;
показ звіту і/або друк;
графічне представлення даних.
Інтерфейс може бути розроблений вже на етапі формулювання вимог.
Дизайн інтерфейсу
Дизайн повинен бути послідовним. Наприклад, використання різних функцій повинне бути подібним, так як і використання діалогів.
Прості правила дизайну:
Правило 1. Мітки повинні знаходиться біля або зверху редагованих полів.
Правило 2. Такі поля як OK або Cancel, повинні знаходитися з правого боку.
Правило 3. Переклади повинні бути змістовними.
Правило 4. Діалогові вікна повинні відповідати потоку даних між користувачем і системою.
Правило 5. Для часто вживаних команд потрібно використовувати клавіатуру для прискорення роботи досвідченого користувача.
Правило 6. Ми повинні пам'ятати про надсилання підтверджень користувачеві. У випадку об'ємних команд користувач повинен отримувати інформацію про відправлення йому команди. Зображення може бути виконане у формі текстової інформації, відсотків виконання команди, "термометра".
Правило 7. У системи повинна бути проста обробка помилок. Помилка повинна бути показана, а правильні дані повинні використовуватися для виконання наступного завдання.
Правило 8. У системи повинна бути операція "відміна". У найпростішому випадку система повертається до останньої операції. У складніших - до попередніх.
Правило 9. Система повинна давати змогу користувачеві контролювати роботу. Користувачі не люблять операцій, що ініціюються без їх відома. Такі операції не повинні робитися системою, а реакція на команди Esc, Ctr+C, Break… повинна бути дуже швидкою.
Правило 10. Інтерфейс не повинен використовувати дуже багато пам'яті, виділеної користувачеві. Він повинен відображати основну інформацію про виконуване завдання і про стадію завдання.
Правило 11. Зв'язані операції повинні бути об'єднані в один діалог. Якщо це неможливо, операції повинні бути розділені таким чином, щоб зв'язані діалоги були доступні.
Правило 12. Потрібно дотримуватися правила Міллера. Правило Міллера 7+/-2 говорить, що людина може зосередитися на 5-9 елементах. Правило повинне застосовуватися при проектуванні меню, підменю, діалогових полів і т.д. Правило може бути реалізоване шляхом декомпозиції інтерфейсу і його подальшим групуванням в об'єднані групи.
Структуровані схеми/діаграми
Наступні елементи використовуються в структурному підході:
1. Модуль
Це активний компонент програми, тобто процедура або функція (або і те, і інше).
2. Виклик
Виклик - це дія, розпочата модулем, який є підмодулем.
3. Модуль бібліотеки
Це готова процедура або функція, яка використовується в системі.
4. Дані
Це відношення в базі даних, файлів або змінних в програмі.
5. Прапорці потоку даних
Виклик, пов'язаний з потоком даних від модуля запиту до викликаного модуля і навпаки. Перший відповідає параметрам вводу, останній - параметрам виводу.
Рис. 1.10. Прапорці потоку даних.
Рис. 1.11. Використання даних.
Структурні діаграми відформатовані зверху вниз, тобто модулі запиту знаходяться вище викликаних модулів.
Структурні діаграми являються специфікацією блок-схем даних.
Високорівневий модуль, який є джерелом даних, викликає модуль нижчого рівня, який є одержувачем даних.
Рис. 1.12. Структурні діаграми проти DFD.
Складова організації даних
Будь-яке застосування повинне зберігати дані, отже проектування носія – необхідний елемент проекту.
Постійне зберігання даних виконане в:
файлах;
базі даних (зв'язаній, об’єктно - орієнтованій або інший).
Специфічні елементи даних у формі об'єктів або точної копії можуть бути збережені в одній з форм:
у одному зв'язаному файлі;
у окремому файлі для кожного типу об'єктів.
Дані обробляються в пам'яті. Таким чином вони повинні бути передані з постійного зберігання в пам'ять. Передача може бути зроблена коли виникає потреба або дані можуть бути збережені в буфері згідно призначеного для користувача запиту.
Особливості і характеристики баз даних
Найпростіший метод зберігання даних - зберігання їх на магнітному або оптичному диску. На жаль, збереження їх у формі файлу небезпечно і незручно у використанні.
Таким чином, файлові системи замінені базами даних. Бази даних - системи, розроблені для зберігання, доступу і управління даними.
Найважливіші критерії відбору СУБД:
1. Продуктивність
Продуктивність описує швидкість реакції на запити і кількість обслуговуваних завдань.
2. Масштабованість
Масштабованість позначає зміну роботи системи при збільшенні кількості користувачів і даних. Це також описує можливість адаптовуватися системі і можливості розширення в умовах високого робочого навантаження.
3. Функціональність
Функціональність описує які функції є доступними в системі. Вони можуть бути функціями користувача, адміністратора і функціями проектувальника. Часто брак відповідних функцій приводить до потреби покупки нових інструментів і збільшує вартість.
4. Узгодження із стандартами
Узгодження позначає задоволення деяких принципів і прийнятих правил (наприклад мовний стандарт, стандарт протоколу, і т.д.). Згода з широко використовуваними стандартами робить нашу роботу незалежною від постачальника і дозволяє доповнювати нашу систему компонентами від різних постачальників.
5. Зручність і простота використання
Зручність і простота використання – важлива характеристика системи. Системи високої ефективності і надійності, проте, дуже важкі у використанні, не рекомендуються. Оцінка залежить від користувача, його навичок, підготовки і досвіду. Один користувач може класифікувати систему як важку, інший – як легку.
6. Надійність
Надійність позначає частоту відмов. Чим вища надійність - тим вища вартість. Таким чином, повинне бути виконане балансування надійності (або потреба зупинки роботи) і витрат.
7. Підтримка
Підтримка описує рівень обслуговування і допомоги, забезпечених виробниками. Підтримка – дуже важлива характеристика. Якісна підтримка системи виробником вимагає відповідних коштів, але при цьому гарантує стійкість роботи.
8. Середовище розробки
Середовище розробки описує на яких апаратних засобах і програмному забезпеченні система працюватиме.
9. Вартість
Вартість системи включає в себе купівлю, встановлення і експлуатацію.
10. Реляційна база даних
Більш загальні бази даних на ринку – реляційні бази даних.
Не дивлячись на їх популярність і загальне використання реляційні бази даних мають деякі незручності. Вони можуть бути і повинні бути відмічені на етапах аналізу і проектування, зокрема в об'єктно-орієнтованому підході.
Великі відмінності в реляційній і об'єктно-орієнтованій моделі підвищують потребу отримання нетривіальних картографій в переході від об'єктно-орієнтованої моделі (наприклад в OMT) до реляційної. Постійний формат створення багатократних версій стає важким рішенням для гнучкого формату полів, графіки, файлів, тексту і т.д. Прогрес, що спостерігається в базах даних, все ще недостатній, зокрема, внаслідок перевантаження обробки запитів.
На рис. 1.13. показано об'єктно-орієнтовану зразкову і реляційну модель для однієї системи. Об'єктно-орієнтована модель ясніша.
Рис. 1.13. Неузгодженість об'єктно-орієнтованої зразкової і реляційної моделі.
Незручність в застосуванні реляційної моделі – також неузгодженість інтерфейсу доступу (наприклад, до SQL) і до мови програмування (наприклад, C++). Цю неузгодженість називають неузгодженістю імпедансу.
Незручність реляційної моделі також полягає у тому, що вона не може бути легко розширена і не має ніякого систематичного підходу до методів.
Оптимізація проекту
Буквальна і прямолінійна реалізація може призвести до дуже низької ефективності системи.
Причиною може бути швидкість виконання деяких функцій або пам'яті і дуже обширне використання пам'яті деякими системами. У таких випадках слід зробити оптимізацію.
Для оптимізації роботи системи застосовуються наступні методи:
використання статичних змінних замість динамічних;
застосування вкладеного коду замість процедур, що викликаються;
вибір типів з мінімальними величинами.
Ці методи можуть призвести до менш зрозумілого коду замість його оптимізації. Обробка помилок може стати складнішою або неможливою.
Кориснішим було б проведення оптимізації ще на етапі дизайну або навіть аналізу.
Ефективність обробки даних повинна враховуватися в першу чергу. Наприклад, при зміні алгоритму сортування шляхом введення допоміжного файлу з ключами і вказівниками, доступ до відсортованих об'єктів може збільшити швидкість в десятки разів.
Ще одним важливим моментом в знаходженні вузьких місць і обережному поводженню з ними є розуміння процедур. Загальновідомо, що 20% коду займає 80% часу виконання. Затримки можуть бути усунені шляхом написання часто вживаних функцій на мовах низького рівня, наприклад, C.
Часто затримки викликані операціями над базами даних. Перевантаження, необхідне реляційним базам даних, є важливим чинником роботи системи. В деяких випадках оптимізація може відбуватися шляхом нормалізації бази даних, з'єднанням осередків в один, застосуванням індексів і інших структур.
Оптимізація повинна бути пов'язана з аналізом буферизації в пам'яті та розглядом різних рівнів буферизації.
Обмеження середовища реалізації
Розробник може зустріти багато обмежень в ході реалізації.
Типовими обмеженнями в переході від аналітичної моделі до моделі реалізації є:
відсутність множинного наслідування;
відсутність наслідування;
відсутність віртуальних методів;
відсутність складних атрибутів;
відсутність мультимедійних типів.
Подолання деяких особливостей концептуальної моделі в моделі реалізації є істотним недоліком.
Фізична структура системи
Одне із завдань етапу проектування – описати фізичну структуру системи.
Вона включає:
Опис структури початкового коду, тобто визначення початкових файлів, їх взаємозв'язків і знаходження компонентів.
Декомпозиція системи на конкретні програми.
Фізичний розподіл даних і програм.
Правильність і якість проекту
Системний проект повинен бути верифікований, а його якість – оцінена. Правильність означає завершеність, сумісність і узгодженість. Повинні бути збережені принципи системи позначень. Але це не означає, що проект відповідає призначеним для користувача вимогам.
Правильний проект повинен бути:
завершеним;
сумісним;
узгодженим;
повинна зберегтися семантика позначень.
Завершеність проекту означає, що всі класи, властивості, методи, складні і прості дані визначені, як і спосіб реалізації всіх функціональних вимог.
Узгодженість означає семантичну послідовність всієї інформації, що зберігається у всіх діаграмах і специфікації.
Правильність класу і діаграм станів
Всі діаграми проекту повинні бути верифіковані.
У верифікації діаграм класів потрібно враховувати наступне:
ациклічні відносини узагальнення-спеціалізації;
варіанти відносин циклічного об'єднання;
класи, що не мають відношення до інших класів, не повинні бути включені. Але іноді таке трапляється;
введення в специфікацію методів, що мають відношення до вводу, виводу і специфікації результату.
Якість системи
Багато методів і позначень є неформальними і їх використання залежить від типу проекту. Оцінка якості є важким завданням і під час побудови ПЗ, і при задоволенні користувача: рівень відповідності вимогам, надійність, ефективність і ергономічність. Якість вказує на узгодженість, рівень зв'язків і прозорість. Існують формальні заходи для оцінки якості, вони є дуже важливими, але не повністю визначають ефективність.
Узгодженість
Узгодженість описує ступінь відповідності частин системи один одному і взаємини операцій. Критерії декомпозиції дуже важливі. Вони визначають вид узгодженості.
Критерії декомпозиції
1. Випадкова декомпозиція. Розділення на модулі відбувається із-за неможливості охопити всю систему в різних завданнях.
2. Логічна декомпозиція. Різні компоненти виконують подібні функції, наприклад, обробку помилок, проведення подібних обчислень.
3. Часова декомпозиція. Компоненти працюють в однаковий час.
4. Послідовна декомпозиція. Компоненти працюють в певній послідовності. Вихідні дані одного компоненту є вхідними для іншого.
5. Функціональна декомпозиція. Всі компоненти потрібні для виконання однієї функції.
Рівні зв'язку компонентів
У хорошому проекті зв'язки між компонентами повинні бути слабкі. Це визначає декомпозицію проекту на частини, а ПЗ - на модулі.
Зв’язки визначають використання загальних даних процесами або модулями, потік даних між процесами, зв’язки класів, передачу повідомлень, наслідування. Зв’язки можуть бути виміряні за допомогою введення певних мір.
Прозорість
Якісний проект повинен бути прозорим, тобто чітким і легким для розуміння. Прозорість визначають наступні чинники:
– Відображення реальності;
– Компоненти і їх зв’язки повинні відображати структуру системи. Тісні зв'язки проекту з реальністю дозволяють полегшити його розуміння і підтримку.
Узгодженість і рівень зв’язків компонентів
Слабкі зв’язки компонентів один з одним спрощують підтримку і заважають розповсюдженню помилок. Сильна узгодженість робить код зрозумілим, чітким і спрощує його виконання. Метою повинне бути досягнення сильної узгодженості і слабкої зв'язаності.
Зрозуміла термінологія
Термінологія визначає легкість розуміння проекту. Вона повинна бути зрозумілою користувачеві, який не знайомий з подробицями проекту. Також вона повинна бути послідовною – перед початком проекту повинна пройти узгодження термінів.
Зрозуміла і повна специфікація
Специфікація повинна бути написана на чистій і зрозумілій мові. Слід уникати професійного сленгу.
Відповідна складність компонентів на кожному рівні
Застосування наслідування і методів в класах спрощує розуміння проекту.
Нефункціональні вимоги на етапі проектування
Нефункціональні вимоги повинні бути визначені на етапі аналізу. На етапі проектування вони систематизуються та формулюються проектні рішення.
Необхідно врахувати наступні групи вимог:
1. Вимоги до робочих характеристик.
Вимоги до інтерфейсу (протоколи, формати файлів).
Експлуатаційні вимоги.
Вимоги до ресурсів (число процесорів, об'єм вінчестера).
Контрольні вимоги.
Тестові вимоги.
Вимоги документування.
Вимоги безпеки.
Вимоги портативності.
Вимоги якості:
підбір методу проектування;
можливість повторного використання;
підбір інструментів;
можливість зовнішнього доступу.
Вимоги по надійності.
Інструкція по технічному обслуговуванню.
Можливість усунення відмов або несправностей.
Результати етапу проектування
Основними результатами на етапі проектування є:
Удосконалений документ з описом вимог.
Удосконалена модель.
Специфікації проекту, які є в словнику даних.
Опис проекту, що містить (у разі об'єктно-орієнтованого підходу):
діаграми класів;
зв’язки об’єкту;
структурні зв'язки ;
модульні діаграми;
глосарій:
визначення класів;
визначень атрибутів;
визначення комплексних і елементарних даних;
визначення методів.
Ресурси інтерфейсу для меню, діалогів.
База даних проекту.
Структура фізичної системи проекту.
Виконання розкладу.
Успіх і якість результатів етапу проектування залежить від відповідності рекомендацій і стандартів, наприклад, послідовне використання нотацій і форм, а також хороше знання середовища реалізації.
Продукт повинен бути перевірений і верифікований командою програмістів та протестований зі всіх можливих сторін.
Детальний документ проекту
Модель проекту повинна бути записана в документі під назвою «Детальний Документ Проекту» (ДДП).
Мета підготовки цього документа полягає в тому, щоб виділити всі деталі про вимоги до програмного забезпечення, сформульовані в документі. У ДДП необхідно виділити всі вимоги, – це допоможе уникнути проблем в експлуатації. Стиль повинен бути систематичним і точним. Мова і діаграми повинні бути ясними і такими, що піддаються зміні. Значення всіх термінів повинне бути чітко визначене.
Діаграма класів
Система складається з 3-х модулів: Users, Admin, Sys_core, які включають в себе наступні класи:
Рис.1 Модулі системи.
Модуль Sys_core містить класи, які використовуються системою для :
RellCinema – зв’язок з іншими кінотеатрами та обмін інформацією
Secure – захист від атак зловмисників та взлому системи, попередження збоїв системи
ErrorProc – виправлення помилок в системі
UsersInfo – відображення інформації про користувачів
Protocols – управління протоколами
Модуль Users містить класи, які описують різні дії користувачів системи:
Register – реєстрація в системі
Search – пошук інформації про фільми за певним критерієм
Is_Ticket – збір інформації про наявність вільних квитків
Buy_Ticket – купівля квитка
Change_Num – зміна кількості квитків у замовленні
Pay_Ticket – оплата кредитною карткою, перевірка наявності грошей на рахунку
Discount – призначений для надання знижок постійним клієнтам, ідентифікації користувачів у базі
Log_In_Out – вихід із системи
Main - описаний інтерфейс системи, за допомогою цього класу виконуються всі основні операції системи.
Модуль Admin містить класи, які використовуються для налаштування системи та редагування бази даних.
SysInfo – інформація про стан системи, кількість користувачів
DBEdit – редагування, зміна бази даних, налаштування системи
ChangeWeb – зміна інтерфейсу сайту.
Звязки між класами вказаних модулів зображено на рисунках 2, 3, 4 :
Рис. 2. Звязки між класами в модулі Admin
Рис. 3. Звязки між класами в модулі Sys_care
Рис. 4. Звязки між класами в модулі Users
Модульні діаграми
Рис. 5 Зв’язки між модулями
Модуль Admin взаємодіє з Sys_core та Users, бо для виконання своїх функцій він повинен мати зв'язок (взаємодіяти) з деякими класами цих модулів. Users повинен взаємодіяти із Sys_core тому, що має набір функцій, які використовуються модулем Sys_core.
Структурні зв’язки
Рис 6. Структура системи
Після авторизації система передбачає можливість редагування параметрів системи, її адміністрування(керування списком користувачів, корекція роботи системи, надання/обмеження доступу) та відбувається автоматичне оновлення бази даних.
Компоненти системи
Рис. 7 Компоненти системи
Компонент Sys_core має всі необхідні функції для управління даними, а також полегшує роботу самої системи, не перевантажуючи її цими функціями.
Інтерфейси
Система передбачає різні режими доступу (Гість, Звичайний користувач, Дирекція кінопалацу, Касир кінопалацу, Адміністратор). Інтерфейси сайту для всіх режимів відрізняються. Нижче зображено декілька з них:
Рис. 8. Інтерфейс системи для незареєстрованого користувача
Рис. 9. Інтерфейс системи для зареєстрованого користувача
Рис. 10. Інтерфейс системи для дирекції кінотеатру
Короткий опис інтерфейсу системи
1 - Поля для логування.
2 - Поля для пошуку
3 – Посилання на список фільмів, які можна переглянути в кінопалаці сьогодні
4 – Посилання на коротку інформацію про фільм
5 - Інформація про час та дату показу цього фільму протягом тижня в усіх кінотеатрах Львова
6 – Вибір кінотеатру (в даному випадку обрано Кінопалац)
7 – Незабаром у кінотеатрах Львова
8 - Розклад сеансів всіх фільмів, які можна переглянути в Кінопалаці протягом тижня
9 – Режим дирекції , можливість редагувати дані та додавати нові.
Поля для легування -- це поля, які дозволяють логуватися в системі. Коли користувач залогований, система визначає його права для роботи в системі. Існують 5 режимів роботи: звичайний користувач, гість, адміністратор, дирекція кінотеатру, касир кінотеатру.
Поля для пошуку використовуються для введення інформації, по якій буде відбуватися пошук фільму. В даному випадку передбачено пошук по назві
Посилання на список фільмів, які можна переглянути в Кінопалаці сьогодні – дані про фільми, які йдуть в Кінопалаці сьогодні.
Посилання на коротку інформацію про фільм - дозволяє переглянути детальнішу інформацію про фільм, прочитати відгуки глядачів, подивитися короткий промо ролик
Інформація про час та дату показу цього фільму протягом тижня в усіх кінотеатрах Львова – дуже зручна функція, оскільки дає можливість користувачу обрати найбільш зручний час для перегляду обраного фільму.
Вибір кінотеатру - Дозволяє користувачу переключатися між Кінопалацом, Кінопалацом Коперніка, та Кінопалацом ім..Довженка (в даному випадку обрано Кінопалац).
Незабаром у кінотеатрах Львова – фільми, які найближчим часом з’являться в Кінопалацах Львова. Користувач може прочитати коротку інформацію про фільм, дізнатися дату прем’єри .
Розклад сеансів всіх фільмів, які можна переглянути в Кінопалаці протягом тижня – тут є розклад сеансів усіх фільмів, які транслюються в Кінопалаці. Зручно для тих користувачів, які віддають перевагу котромусь з кінотеатрів.
Режим дирекції , можливість редагувати дані та додавати нові – представник дирекції має змогу редагувати розклад сеансів, змінювати акції в кінотеатрі, читати та видаляти відгуки користувачів, переглядати список замовлень. На сайті ці функції зручно згруповані в головному меню.
Замовляти квитки на сайті неможливо в режимі Гостя, саме тому система пропонує користувачу зареєструватися. На сайті можна переглянути розклад сеансів всіх кінотеатрів Львова певного дня, замовити та забронювати квиток, прочитати детальну інформацію про фільм (що просто необхідно для правильного вибору). Якщо ж користувач вже вирішив який фільм бажає подивитися, на сайті можливо отримати всю потрібну інформацію : в яких кінотеатрах та коли буде показ фільму, ціна квитка та відгуки глядачів.
База даних системи
Для роботи системи необхідно мати базу даних, яка містить в собі інформацю про усі операції виконані системою, список постійних клієнтів, дані про фільми.
База знаходиться на головному комп’ютері і складається з 4 таблиць, зв’язаних між собою :
Таблиця Фільми містить такі поля:
ID_Фільму (Число, обов’язкове поле)
Назва фільму (Текстове поле, 25 символів)
Жанр (Текстове поле, 15 символів)
В ролях (текстове поле, 50 символів)
Про фільм (текстове поле, 200 символів)
Таблиця Сеанси містить такі поля:
ID_Фільму (Число, обов’язкове поле)
Дата показу ( Час та дата)
Вартість квитка ( Грошове поле)
Зал (Текстове поле, 15 символів)
Таблиця Замовлення складається з наступних полів:
ID_Клієнта (Число, обов’язкове поле)
ID_Фільму (Число, обов’язкове поле)
Кількість квитків (Числове поле, ціле)
Номер замовлення (Числове поле, ціле)
Дата замовлення (Час та дата)
Таблиця Клієнти містить поля:
ID_Клієнта (Число, обов’язкове поле)
Прізвище (Текстове поле, 15 символів)
Ім’я (Текстове поле, 15 символів)
Номер кредитної картки ( Числове поле, довге ціле)
Кількість замовлень всього ( Числове поле, ціле)
Структура фізичної системи проекту
Система
Квиток
Користувач та адміністратор
Рис. 11. Фізична структура системи
З системою взаємодіють користувач і адміністратор. Адміністратор слідкує за правильною роботою системи, а користувач виконує операції, які впливають на стан системи. Система взаємодіє з базою даних, де зберігається вся інформація про фільми. Базу даних система використовує для різноманітних операцій, без неї система взагалі не зможе нормально функціонувати. Результатом роботи системи є квиток.
Розклад
Рис. 12. Часова діаграма виконання проекту.
Таблиця 1
Учасник проекту
Задачі
Заробіток
Персонал
Менеджер проекту
Представляє проект клієнту, слідкує за виконанням проекту, узгоджує питання з замовником.
15000грн.
1
Розробник
Реалізовує поставлену задачу, пише документацію.
10000грн.
3
Тестувальник
Тестує реалізований проект, виявляє помилки та повідомляє їх розробникам.
5300грн.
2
Загальний час виконання проекту становить 4 місяці.
Загальна вартість проекту 210 400 грн.
13.02.2013 23:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора