Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Розробка програмного продукту. Етап проектування та побудова моделі
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Кафедра автоматизованих систем управління
Інформація про роботу
Рік:
2009
Тип роботи:
Звіт
Предмет:
Інформаційні технології
Група:
КН- 411
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет «Львівська політехніка»
Інститут комп’ютерних наук та інформаційних технологій
Кафедра автоматизованих систем управління
Звіт
до лабораторної роботи №2
на тему
“Розробка програмного продукту.
Етап проектування та побудова моделі”
Тема: Розробка програмного продукту. Етап проектування та побудова моделі.
Мета: Ознайомлення з основними задачами, які необхідно розв’язати під час виконання етапу проектування та побудови моделі.
Завдання: Навчитись реалізовувати етап проектування та побудовати модель при розробці програмного продукту комп’ютерних систем.
Теоретична частина
Цей етап потрібний для детального опису реалізації системи. Опис після необхідних змін, зроблених на наступних етапах (реалізації і тестування), буде частиною технічної документації системи.
Всупереч аналізу на етапі проектування, проектувальники повинні знати, що програмне середовище, мови програмування, бібліотеки і інші інструменти будуть застосовані на етапі реалізації.
На цьому етапі виконується перетворення абстрактних понять, використовуваних в аналізі, в детальніші описи всіх конструкцій.
У ПЗ існує декілька складових; одна з них представляє частину проблем, відповідальних за основне виконання функцій і необхідні дані. Вона будує якнайкращу модель, розроблену після аналізу. Інші частини відповідальні за комунікацію з клієнтом, за зберігання і доступ до даних, управління пам'яттю і компоненти управління завданнями.
На етапі проектування також виконується оптимізація моделі.
Програмне середовище забезпечує інструменти, які обмежують раніше розроблену модель, але воно може також забезпечити допоміжний механізм, який дозволяє поліпшити реалізацію. Таким чином проектування будує модель до рамок обмежень та поліпшує можливості програмного середовища.
Фізична структура моделі повинна бути також визначена на цьому етапі.
Таким чином, на етапі проектування виконуються наступні завдання:
специфікація результатів аналізу,
проектування компонентів, які не належать області проблеми,
оптимізація системи
підлаштування моделі до обмежень і варіантів програмного середовища,
визначення фізичної структури.
Детальна модель приводить до вибору з багатьох можливих методів реалізації конструкцій моделі.
Основні конструкції повинні підтримуватися допоміжними:
інтерфейс для роботи з користувачем,
компонент управління даних для зберігання даних,
компонент управління пам'яті,
компонент управління завданнями для їх планування.
Основні чинники успіху етапу проектування:
висока якість моделі,
хороше знання середовища розробки,
узгодженість із стандартами,
перевірка системи,
проектна оптимізація повинна бути виконана на значних фрагментах системи.
Основні результати етапу проектування:
виправлений документ формулювання вимог,
виправлена модель,
детальна специфікація,
документ, що описує проект:
діаграми класів,
діаграми взаємодій,
діаграми станів,
діаграми діяльності,
діаграми компонентів,
визначення ознак класів, складних і елементарних даних, методів.
ресурси інтерфейсу користувача,
проектування баз даних,
фізичний проект структури системи,
виправлений тестовий проект,
планування виконання.
Метою проектування є розробка моделі, необхідної для нормального функціонування системи. У проектуванні середовище програмування відіграє важливу роль, не дивлячись на те, що під час аналізу ним часто нехтують. Проектувальник повинен знати мови програмування, бібліотеки і інструментальні програмні засоби, необхідні для функціонування системи.
Проектувальник повинен зберегти структуру системи, розроблену раніше (в процесі аналізу). А внесені зміни в загальному впливати на проект.
Дії на етапі проектування
На етапі проектування реалізуються деталі, що ігноруються в процесі аналізу. Рівень деталізації залежить від професіоналізму програміста. Проект повинен містити всі деталі необхідні для функціонування системи.
Розробник повинен врахувати всі можливості та обмеження середовища і визначити фізичну структуру системи.
Під час проектування виникають нові терміни і визначення, що поповнюють запас термінів, які використовувалися під час аналізу.
Різні сценарії проектування припускають різні підходи.
Поле і символи доступу опису методу повинні бути індикатором того, як програмістові слід реалізувати клас.
Доступ може бути визначений:
(+) публічний (public) – для всіх функцій і методів,
(#) захищений (protected) – доступ дозволений певному класу певної спеціалізації,
(-) особистий (private) – доступ тільки для функцій певного класу.
Специфікація результатів аналізу
Для етапу проектування необхідне детальне визначення результатів аналізу.
Специфікація складається з правил формулювання і відображення результатів на програмній мові і містить в собі:
1. Визначення методів.
Специфікація методу повинна замінити деякі методи прямим доступом до властивостей. Наприклад метод 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. Користувач очікує знайти посилання на дану сторінку. Як показують дані, користувач очікує віднайти посилання або зліва вгорі, або посередині нижнього колонтитулу. Тому розташування посилання в лівому нижньому кутку зробило б інтерфейс менш інтуїтивним і могло б викликати складнощі у користувача.
Розробка інтерфейсу стала простішою останніми роками, оскільки з'явилися багато графічних інструментів для цієї мети. Також існують системи з управлінням інтерфейсом, наприклад, Zapp Factory, Visual Basic. Візуальні інструменти дають можливість інтерактивно розробляти діалоги, вікна, меню, порозрядні карти відображення інформації і ікони. Вони дають змогу визначити реакцію системи у відповідь на різні події, наприклад, зроблені користувачем (вибір запису в меню, переміщення курсору над певними областями і т.д.), легке і швидке генерування графічного проекту, програмного або інших кодів.
Організація взаємодії з користувачами
Спілкування з користувачем здійснюється:
через командний рядок,
через графічне середовище.
Командний рядок використовується для простих, маленьких систем, прототипів або особливою досвідченою групою користувачів. Ця взаємодія швидша, ніж з використанням повноекранного інтерфейсу.
Швидкість створення інтерфейсу не так важлива, як раніше, для всіх доступних інструментів, які допомагають розробці. Зв'язок, що використовує команди, швидший, але вимагає знання середовища. Тому ми не повинні забувати про клавішні комбінації швидкого виклику.
Середовище вікон простіше для засвоєння початківцями та середньо статистичними користувачами. Воно дає змогу провести незалежне, інтуїтивне вивчення програми, без потреби в знанні семантики текстових команд.
Типові способи взаємодії користувача з системою такі:
командний рядок
вибір умови
клавішні комбінації швидкого виклику
ікони на панелі інструментів
вибір в діалозі
навігація мишею
Введення і читання даних здійснюється
користувачем:
введення параметрів в командний рядок,
введення даних у відповідь на системний запит,
введення даних в діалозі.
системою:
відображення інформації в діалозі,
показ звіту і/або друк,
графічне представлення даних.
Інтерфейс може бути розроблений вже на етапі формулювання вимог.
Дизайн інтерфейсу
Дизайн повинен бути послідовним. Наприклад, використання різних функцій повинне бути подібним, як і використання діалогів.
Прості правила дизайну повинні допомогти:
Правило 1. Мітки повинні знаходиться біля або зверху редагованих полів.
Правило 2. Такі поля, як OK або Cancel, повинні знаходиться з правого боку.
Правило 3. Переклади повинні бути змістовними.
Правило 4. Діалогові вікна повинні відповідати потоку даних між користувачем і системою.
Рис. 1.4. Редагування об'єкту "дохід від одного джерела".
Правило 5. Для часто вживаних команд потрібно використовувати клавіатуру для прискорення роботи досвідченого користувача.
Правило 6. Ми повинні пам'ятати про надсилання підтверджень користувачеві. У випадку об'ємних команд користувач повинен отримувати інформацію про відправлення йому команди. Зображення може бути виконане у формі текстової інформації, відсотків виконання команди, "термометра".
Правило 7. У системи повинна бути проста обробка помилок. Помилка повинна бути показана, а правильні дані повинні використовуватися для виконання наступного завдання.
Правило 8. У системи повинна бути операція "відміна". У найпростішому випадку система повертається до останньої операції. У складніших - до попередніх.
Правило 9. Система повинна давати змогу користувачеві контролювати роботу. Користувачі не люблять операцій, що ініціюються без їх відома. Такі операції не повинні робитися системою, а реакція на команди Esc, Ctr+C, Break… повинна бути дуже швидкою.
Правило 10. Інтерфейс не повинен використовувати дуже багато пам'яті, виділеною користувачеві. Він повинен відображати основну інформацію про виконуване завдання і про стадію завдання.
Правило 11. Зв'язані операції повинні бути об'єднані в один діалог. Якщо це неможливо, операції повинні бути розділені таким чином, щоб зв'язані діалоги були доступні.
Правило 12. Потрібно дотримуватися правила Міллера. Правило Міллера 7+/-2 говорить, що людина може зосередитися на 5-9 елементах. Правило повинне застосовуватися при проектуванні меню, підменю, діалогових полів і т.д. Правило може бути реалізоване шляхом декомпозиції інтерфейсу і його подальшим угрупуванням в об'єднані групи.
3. Модуль бібліотеки
Це - готова процедура або функція, яка використовується в системі.
Структурні діаграми відформатовані зверху-вниз, тобто модулі запиту вище викликаних модулів.
Структурні діаграми являються специфікацією блок-схем даних.
Високорівневий модуль, який є джерелом даних, викликає модуль нижчого рівня, який є одержувачем даних.
Складова організації даних
Будь-яке застосування повинне зберігати дані, отже проектування носія - необхідний елемент проекту.
Постійне зберігання даних виконане в:
файлах;
базі даних (зв'язаній, об’єктно - орієнтованій або інший).
Специфічні елементи даних у формі об'єктів або точної копії можуть бути збережені в одній з форм:
у одному зв'язковому або файлі;
у окремому файлі для кожного типу об'єктів.
Дані обробляються в пам'яті. Таким чином вони повинні бути передані з постійного зберігання в пам'ять. Передача може бути зроблена, коли виникає потреба, або це може бути збережено в буфері згідно призначеному для користувача запиту.
Особливості і характеристики баз даних
Найпростіший метод зберігання даних - зберігати їх на магнітному або оптичному диску. На жаль, збереження їх у формі файлу небезпечно і незручно у використанні.
Таким чином, файлові системи замінені базами даних. База даних - системи, розроблені для зберігання, доступу і управління даними.
База даних характерна постійним зберіганням, обмеженим об'ємом і хорошою організацією.
1. Постійність
Постійність описує факт, що дані повинні бути завжди там, де очікуються. База даних не може бути побудована в пам'яті, оскільки дані можуть бути втрачені, коли виключається живлення. Хорошим носієм може бути папір, магнітний або оптичний диск.
2. Обмеження баз даних
База даних не може містити всіх можливих даних. Вони пов'язані з деякою моделлю дійсності. Прийнята модель, побудована проектувальником, визначає дані, збережені в базі даних.
3. Послідовність бази даних
База даних повинна відповідати реальному представленню даних, ефективною, забезпечувати цілісність, багатократний доступ і операційну обробку, масштабованість, розподіл даних і каскадних рішень. База даних повинна дозволяти операції на даному рівні мови (наприклад. SQL, OQL).
4. Зв'язок з реальністю
Цей постулат є критичним у формулюванні вимоги для бази даних. Наприклад, якщо база даних описує тотожність тобто ім'я, прізвище, адресу, положення і т.д., послідовність означає, що дані зміняться згідно тільки реальним змінам, тобто положення міняється, якщо службовець отримує заохочення. Бази даних повинні оновлюватися згідно з фактичними даними. Якісні зв’язки - це нелегке завдання. Бізнес не може бути повністю комп'ютеризовано. Людина - важливий компонент системи. Процедури повинні розроблятися ретельно, і людський фактор повинен бути врахований в системі. Спосіб відправки інформації повинна бути описана в процедурах. Оновлення даних - одна з найважчих проблем, зокрема, коли є багато баз даних і багато систем в компанії. Таким чином виконується відповідна інтеграція систем (підсистеми) в модулі, і обмін даними виконується модулями.
5. Приклад реалізації
Проект бази даних потрібно робити з урахуванням того, що база даних повинна ілюструвати фрагмент дійсності. Деяка гіпотетична база даних може бути побудована і працювати, але вона може не знайти ніякого застосування. Щоб побудувати базу даних, яка представляє фрагмент дійсності, повинна бути добре визначена область проблем і запропоновані відповідні моделі.
6. Контроль копіювання даних
Точна копія позначає представлення тих же самих даних в різних місцях і в різних формах. Наприклад, база даних постачання міститиме найменування і адреси постачальників, і теж саме міститиме в базі даних покупців. Це приводить до непотрібного збільшення зберігання і робочого навантаження обробки. Деякі операції з даними повинні бути виконані над тими ж даними в списку постачальника і списку закупівлі. Наприклад, зміна адреси повинна бути оновлена в обох списках. Точні копії повинні іноді створюватися і використовуватися. Проте, управління точних копій дуже важливе і повинне представляти особливий інтерес.
7. Складена модель даних
Цілісність позначає зв'язок з дійсністю і з призначеними для користувача вимогами. Цілісність визначена правильністю даних в сенсі їх організації і конструкції. Послідовна модель - модель, яка представляє фрагмент інформації, використання даних бази можливе тільки тоді, коли представлені відповідні відносини. Цілісність позначає відповідність збережених даних і внутрішньої структури - отже, вони відповідають мета-моделі, застосованій в базі даних. Повинен бути автоматичний механізм перевірки цілісності.
8. Доступність даних
Можуть бути бази даних, які забезпечують доступ кому завгодно і у будь-який час. Проте, це не особливість, рекомендована для будь-якої бази даних, зокрема коли користувачі багато разів запрошують дані. Таким чином, доступом до баз даних потрібно управляти, а також необхідний відповідний проект структури і доступу.
9. Безпека даних
Бази даних присутні в багатьох закладах; вони підтримують і використовуються в багатьох випадках. Вони зберігають фінансову інформацію, тотожність, операції і т.д. отже, вони повинні бути захищені. Хороша база даних повинна мати механізми перевірки, дозволу, конфіденційності, цілісності і доступності.
10. Критерії відбору системи управління базами даних (СУБД)
Розвиток інформаційної системи зазвичай не вимагає побудови власної бази даних, оскільки легко використовувати існуюче ПЗ. Вибір СУБД не легкий. Багато аспектів розглядаються, наприклад, що база даних повинна бути реалізована однаково добре і у провайдера і на призначеній для користувача стороні.
Найважливіші критерії відбору СУБД:
1. Продуктивність
Продуктивність описує швидкість реакції на запити і кількість обслуговуваних завдань.
2. Масштабованість
Масштабованість позначає зміну роботи системи при збільшенні кількості користувачів і даних. Це також описує можливість адаптовуватися системи і можливості розширення в умовах високого робочого навантаження.
3. Функціональність
Функціональність описує, які функції є доступними в системі. Вони можуть бути функціями користувача, адміністратора і функціями проектувальника. Часто брак відповідних функцій приводить до потреби покупки нових інструментів і збільшує вартість.
4. Узгодження із стандартами
Узгодження позначає задоволення деяких принципів і прийнятих правил (наприклад мовний стандарт, стандарт протоколу, і т.д.). Згода з широко використовуваними стандартами робить нашу роботу незалежною від постачальника і дозволяє доповнювати нашу систему компонентами від різних постачальників.
5. Зручність і простота використання
Зручність і простота використання - важлива характеристика системи. Системи високої ефективності і надійності, проте дуже важкі у використанні не рекомендуються. Оцінка залежить від користувача, його навичок, підготовки і досвіду. Один користувач може класифікувати систему як важку, інший - як легку.
6. Надійність
Надійність позначає частоту відмов. Чим вище надійність - тим вища вартість. Таким чином, повинне бути виконано балансування надійності (або потреба зупинки роботи) і витрат.
7. Підтримка
Підтримка описує рівень обслуговування і допомоги, забезпечений виробниками. Підтримка - дуже важлива характеристика. Якісна підтримка системи виробником, вимагає відповідних коштів, але при цьому гарантує стійкість роботи.
8. Середовище розробки
Середовище розробки описує, на яких апаратних засобах і програмному забезпеченні система працюватиме.
9. Вартість
Вартість системи включає в себе купівлю, встановлення і експлуатацію.
Незручність в застосуванні реляційної моделі - також неузгодженість інтерфейсу доступу (наприклад, до SQL) і до мови програмування (наприклад, C++). Цю неузгодженість називають неузгодженістю імпедансу.
Незручність реляційної моделі також полягає у тому, що вона не може бути легко розширена, і що немає ніякого систематичного підходу до методів.
Оптимізація проекту
Буквальна і прямолінійна реалізація може призвести до дуже низької ефективності системи.
Причиною може бути швидкість виконання деяких функцій або пам'яті і дуже обширне використання пам'яті деякими системами. У таких випадках слід зробити оптимізацію.
Для оптимізації роботи системи застосовуються наступні методи:
використання статичних змінних замість динамічних,
застосування вкладеного коду замість процедур, що викликаються,
вибір типів з мінімальними величинами.
Ці методи можуть призвести до менш зрозумілого коду замість його оптимізації. Обробка помилок може стати складнішою або неможливою.
Кориснішим було б проведення оптимізації ще на етапі дизайну або навіть аналізу.
Ефективність обробки даних повинна враховуватися в першу чергу. Наприклад, при зміні алгоритму сортування шляхом введення допоміжного файлу з ключами і вказівниками, доступ до відсортованих об'єктів може збільшити швидкість в десятки разів.
Ще одним важливим моментом в знаходженні вузьких місць і обережному поводженню з ними є розуміння процедур. Загальновідомо, що 20% коду займає 80% часу виконання. Затримки можуть бути усунені шляхом написання часто вживаних функцій на мовах низького рівня, наприклад, C.
Часто затримки викликані операціями над базами даних. Перевантаження, необхідне реляційним базам даних, є важливим чинником роботи системи. В деяких випадках оптимізація може відбуватися шляхом нормалізації бази даних, з'єднанням осередків в одну, застосуванням індексів і інших структур.
Оптимізація повинна бути пов'язана з аналізом буферизації в пам'яті та розглядом різних рівнів буферизації.
Обмеження середовища реалізації
Розробник може зустріти багато обмежень в ході реалізації.
Типовими обмеженнями в переході від аналітичної моделі до моделі реалізації є:
відсутність множинного наслідування;
відсутність наслідування;
відсутність віртуальних методів;
відсутність складних атрибутів;
відсутність мультимедійних типів.
Подолання деяких особливостей концептуальної моделі в моделі реалізації є істотним недоліком.
Правильність і якість проекту
Системний проект повинен бути верифіковано, а його якість - оцінена. Правильність означає завершеність, сумісність і узгодженість. Повинні бути збережені принципи системи позначень. Але це не означає, що проект відповідає призначеним для користувача вимогам.
Правильний проект повинен бути:
завершеним;
сумісним;
узгодженим;
повинна зберегтися семантика позначень.
Завершеність проекту означає, що всі класи, властивості, методи, складні і прості дані визначені, як і спосіб реалізації всіх функціональних вимог.
Узгодженість означає семантичну послідовність всієї інформації, що зберігається у всіх діаграмах і специфікації.
Правильність класу і діаграм станів
Всі діаграми проекту повинні бути верифіковані.
У верифікації діаграм класів потрібно враховувати наступне:
ациклічні відносини узагальнення-спеціалізації,
варіанти відносин циклічного об'єднання,
класи, що не мають відношення до інших класів, не повинні бути включені. Але іноді таке трапляється,
введення в специфікацію методів, що мають відношення до вводу, виводу і специфікації результату.
Якість системи
Багато методів і позначень є неформальними, і їх використання залежить від типу проекту. Оцінка якості є важким завданням і під час побудови ПЗ, і при задоволенні користувача: рівень відповідності вимогам, надійність, ефективність і ергономічність. Якість вказує на узгодженість, рівень зв'язків і прозорість. Існують формальні заходи для оцінки якості, і вони є дуже важливими, але не повністю визначають ефективність
Порядок виконання роботи
Ознайомитися з теоретичною частиною.
Виконати реалізацію етапу проектування для свого індивідуального завдання.
Оформити звіт по результатах виконаної роботи
Індивідуальне завдання: Система автоматизації роботи кас залізничного вокзалу.
Система обмінюється даними з користувачами і адміністратором. В основному ці дані являють собою ключові слова пошуку напрямів проїзду, результати пошуку і дані адміністратора. Ключові слова пошуку вводить в систему користувач. Система опрацьовує введені дані і виводить на екран результати пошуку. А коли в базу даних треба ввести зміни, адміністратор передає системі команди.
Параметри пошуку – це структуровані текстові та числові дані, які виводяться в таблиці.
Команди адміністратора – це спеціальні команди, які здійснює адміністратор.
ДАНІ
ОПИС
СУТНОСТІ
Ключові слова
Інформація, пошук, якої здійснює користувач, і яку він вводить в програму.
Користувач, система
Параметри пошуку
Провівши пошук за ключовими словами система виводить на екран результати пошуку.
Користувач, система
Команди адміністратора
Це команди, за допомогою яких адміністратор обмінюється з системою даними, необхідними для редагування бази даних та роботи касирів
Адміністратор, система
Діаграми класів
Система складається з 3-ох модулів: Kasyr, Admin, System_Interface, які включають в себе наступні класи.
Модулі системи
Зв’язки в модулі System_Interface між класами зображені на рисунку нижче
Клас Powyk_Danyx призначений для пошуку необхідної інформації, що міститься в системі. Він містить функції, які дозволяють шукати інформацію за одним чи декількома параметрами, враховуючи налаштування користувача. Даний клас також містить механізми передбачення введення користувачем помилок.
Клас Master призначений для перенесення інформації з бази даних у базу в інтерфейсах користувача.
Клас Onovlennia призначений для оновлення бази даних, що міститься на віддаленому сервері. Якщо інфомрація, що міститься на даному сервері є застарілою(зміна напряму проїзду, видалення певного рейсу тощо), то відбувається оновлення бази даних.
Клас Forma_Meniy – це основне вікно програми на робочому даного модуля. З його допомогою користувач може переходити до пошуку потрібного напряму проїзду, стану системи та іншої необхідної інформації.
Модуль Kasyr містить елементи, які є необхідними для коректної роботи касира. Його класи містяться нижче:
Клас Dialog являє собою осоновне діалогове вікно класу касир, через яке здійснюється пошук та обмін інформацією із системою. З його допомогою користувач може змінити налаштування пошуку і запустити пошук по деяким параметрам.
Клас Powyk_Napriamy i Nadannia_Informacii є складовими класу Dialog. За допомогою них відбувається обмін інформацією із адміністратором та системою загалом.
Клас Ogliad – це елемент вікна, який висвітлює базу даних у вигляді таблиці. Він приймає від користувача запити на сортування даних за одним чи кількома параметрами а також запити на маніпулювання базою даних на рівні користувача.
За допомогою класу Zberegennia_Danyx касир має можливість зберігати необхідні дані, які потрібні йому для подальшої роботи касирів.
Клас Login відповідає за залогінення користувача, який працює на даному комп’ютері. Під час залогінення касир може розпочинати роботу, якщо логін був введений неправильно буде видано повідомлення про помилку та неможливість подальшої роботи.
Модуль Admin містить елементи, з яких складається інтерфейс адміністратора. З його допомогою адміністратор може редагувати базу даних, додавати та видаляти з неї інформацію. Зв’язки між класами цього модуля зображені нижче.
Клас Forma – це основне вікно програми на робочому комп’ютері адміністратора. З його допомогою користувач може переходити до пошуку потрібного напряму, функцій роботи касира та бази даних, змінювати властивості системи та редагувати її роботу.
Клас Parol мітить механізми, що захищають від несанкціонованого доступу. Це стартовий клас, з якого починається робота програми. Він викликає вікно для паролю, і якщо пароль неправильний, завершує роботу програми. Якщо ж правильний, відкриває вікно для редагування бази даних.
В класі Redagyvannia реалізоване основне вікно для редагування бази даних.
Класи Informacia_Dani i Fynkcii_Kasyr є компонентами вище описаного класу. За допомогою них здійснюється обмін інформацією із касиром та віддаленим сервером.
Клас Onovlennia виконує оновлення бази даних. Тобто за допомогою нього відбувається зміна даних в базі напряму (додавання, видалення, редагування) та вцілому в системі.
За допомогою класу Zapyt адміністратор має змогу відсилати запити системі для отримання необхідної інформації.
Зв’язки об’єкту
Модулі Admin_Interface, System_Interface не взаємодіють між собою, але використовують класи модуля Main. Модуль Main є автономним і являється по суті набором інструментів, з допомогою яких інтерфейси маніпулюють базою даних. Посилання на класи модуля Main знаходяться в усіх класах, завдання яких полягає в доступі до бази даних.
Зв’язки екземплярів об’єктів класів
Структурні зв’язки
Структурні зв’язки системи автоматизацій роботи кас залізничного вокзалу є розподілені на 2 режими роботи. Основний режим це основне вікно, в якому відбуваються всі основні операції такі як, надсилання повідомлень, за допомогою яких є можливість визначити стан сисеми, здійснювати операцію продажу квитків і виконувати інші необхідні операції. В основному вікні також відбувається операції оновлення інформації напрямів в БД.
В режимі обслуговування можна можна здійснювати управління роботи окремих компонент системи. Управління ФП передбачає налаштування СОМ-порту з яким з’єднаний ФП та управління параметрами цього ФП, які передбачені в протоколі самого фіскального принтера. Управління касирами відбувається для визначення користувачів системи, а також для кожного з них можна вибрати різні рівні доступу до функцій системи.
Компоненти системи
Компоненти системи
Компонент для віддаленого доступу до сервера даних дозволяє здійснити обмін даними із базою напрямів. Компонент адміністрування дозволяє редагувати базу даних. Компонент програмного інтерфейсу дозволяє побудувати вікно програми.
Модульні діаграми
Модулі системи
Всі модулі взаємодіють з модулем Main, який містить механізми пошуку та функції, які дозволяють маніпулювати інформацією з бази даних на рівні користувача. Модулі Admin_Interface, System_Interface реалізовують інтерфейси до системи, тому не мають зв’язків між собою.
Інтерфейс системи
Програмний інтерфейс касира
Програмний інтерфейс адміністратора
1.)Поле напрямку
В поле напрямку вводяться ключові слова для пошуку бажаного напрямку.
2.)Поле дати
В поле дати вводиться дата відправлення поїзду в форматі рік/місяць/день (напр.: 2009.01.01)
3.)Кнопка "Пошук"
Нею запускається швидкий пошук, який вишукує ключові слова за усіма параметрами бази даних.
4.)Таблиця з результатами пошуку.
Після проведення пошуку система виводить результати в цю таблицю, розкладаючи дані у відповідні комірки. В останній комірці "Вартість" містяться дані про вартість поїздки з усіма податками.
5.) Кнопка "Головне меню"
Ця кнопка дозволяє перейти з меню пошуку до головного меню програми. Де користувач може закінчити свій сеанс
6.) Кнопка "База даних"
Доступна лише в режимі адміністратора і при її натисненні відображається база даних поїздів.
Натиснувши цю кнопку, адміністратор зберігає відредаговану базу даних. Попередня версія бази даних автоматично зберігається, щоб можна було при бажанні її відновити.
7.)Кнопка "Редагувати БД"
Натиснувши цю кнопку, адміністратор відкриває базу даних для редагування. Попередня версія бази даних автоматично зберігається, щоб можна було при бажанні її відновити.
8.) Тип вагону.
Дана команда призначена для вибору типу вагону, в якому буде здійснюватися проїзд (купе, плацкарт, СВ). Відповідно до зміни типу вагону буде змінюватися і вартість проїзду та рівень послуг, що будуть надаватися безпосередньо в поїзді.
База даних проекту
База даних напрямів проїзду міститься в папці з програмою і являє собою структурований файл з текстовою інформацією, захищений від несанкціонованих змін і видалення.
Запис поданий у вигляді структури:
Напрям проїзду (20 символів)
Дата відправлення (20 символів)
№ п/п (10 символів)
Дата (20 символів)
Напрямок (50 символів)
Вагон (5 символів)
Місце (5 символів)
Вартість (10 символів)
Сумарна довжина даних про один квиток буде 140 символів.
Структура фізичної системи проекту
Фізична структура системи
Завдання адміністратора полягає в редагуванні бази даних через робочий комп’ютер.
Касир має доступ до системи через робочий комп’ютер в касі.
Глосарій
Визначання класів
Main
Powyk – призначений для пошуку інформації в базі даних
Master – призначений для перенесення інформації з бази даних в у базу в інтерфейсах користувача.
System_Interface
Forma – головне вікно касира
Ogliad – таблиця, яка висвітлює інформацію з бази даних бібліотеки
Dialog – вікно, що висвітлює пошук.
Admin_Interface
Redagyvannia – вікно адміністратора для редагування бази даних
View – таблиця з даними у вікні адміністратора, яка дозволяє змінювати дані
Password – вікно для введення паролю, яке займається перевіркою правильності паролю і містить механізми захисту від несанкціонованого доступу
Powyk – вікно для складного пошуку.
Визначення комплексних і елементарних даних
Система отримує від користувачів пошукові дані, які являють собою текстову інформацію плюс налаштування (якщо використовується складний пошук). У відповідь система передає результати пошуку (інформацію з бази даних).
Також адміністратор, змінюючи базу даних, надсилає системі корективи, які являють собою текстову інформацію плюс команди типу: зберегти, відмінити, замінити в певному місці.
Визначення методів
Функції маніпулювання базою даних на рівні користувача
сортувати комірки за параметром SortBy
метод швидкого пошуку даних QuickSearch
метод завантаження інформації з бази даних GetData
Редагування бази даних
збереження бази даних SaveDB
відміна останньої зміни UnDo
відміна всіх змін UnDoAll
повторити останню дію ReDo
видалити поле Delete
додати поле Add
метод додавання тексту AddText
Робота системи
метод завантаження системи Main
запуск швидкого пошуку EngageQuickSearch
відкриття вікна для складного пошуку OpenSearchWindow
запуск складного пошуку EngageSearch
метод пересилання запиту на сортування отриманих даних за певним параметром SortDB.
Розклад
Часова діаграма виконання проекту.
Таблиця 2.2.
Учасник проекту
Задачі
Заробіток
Персонал
Менеджер проекту
Представляє проект клієнту, слідкує за виконанням проекту, узгоджує питання з замовником.
7200грн.
1
Розробник
Реалізовують поставлену задачу, пише документацію.
4300грн.
5
Тестер
Тестує реалізований проект, виявляє помилки та повідомляє їх розробникам.
2100грн.
4
Загальний час виконання проекту – 4 місяці.
Загальна вартість проекту 102400 грн.
Висновок: Підчас виконання цієї лабораторної роботи я ознайомився з основними задачами, які необхідно розв’язати під час виконання етапу проектування та побудови моделі, навчився реалізовувати етап проектування та побудував модель при розробці програмного продукту комп’ютерних систем
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора