Розробка програмного продукту. Етап проектування та побудови моделей.
Лабораторна робота № 3
Міністерство Освіти
і Науки України
Національний університет
“Львівська
політехніка”
Кафедра автоматизованих систем
управління
Методичні вказівки
до лабораторної роботи № 3
“Розробка програмного продукту.
Етап проектування та побудова моделі”
з дисципліни
“Технологія програмування та створення програмних продуктів”
для студентів базового напрямку підготовки по спеціальності
“Комп’ютерні науки” (шифр 0804)
Львів-2011
Методичні вказівки до лабораторної роботи № 3 “Розробка програмного продукту. Етап проектування та побудова моделі” з дисципліни “Технологія програмування та створення програмних продуктів” для студентів спеціальності - шифр 0804 “Комп’ютерні науки”/ Укл. доц. Ковівчак Я.В.,
Львів: Національний університет “Львівська політехніка”, 2011.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2011 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2011 р.
Лабораторна робота № 3
Розробка програмного продукту. Етап проектування та побудова моделі
Мета: Ознайомлення з основними задачами, які необхідно розв’язати під час виконання етапу проектування та побудови моделі.
Завдання: Навчитись реалізовувати етап проектування та побудувати модель при розробці програмного продукту комп’ютерних систем.
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. Діалогові вікна повинні відповідати потоку даних між користувачем і системою.
Рис. 1.4. Редагування об'єкту "дохід від одного джерела".
Правило 5. Для часто вживаних команд потрібно використовувати клавіатуру для прискорення роботи досвідченого користувача.
Правило 6. Ми повинні пам'ятати про надсилання підтверджень користувачеві. У випадку об'ємних команд користувач повинен отримувати інформацію про відправлення йому команди. Зображення може бути виконане у формі текстової інформації, відсотків виконання команди, "термометра".
Правило 7. У системи повинна бути проста обробка помилок. Помилка повинна бути показана, а правильні дані повинні використовуватися для виконання наступного завдання.
Правило 8. У системи повинна бути операція "відміна". У найпростішому випадку система повертається до останньої операції. У складніших - до попередніх.
Правило 9. Система повинна давати змогу користувачеві контролювати роботу. Користувачі не люблять операцій, що ініціюються без їх відома. Такі операції не повинні робитися системою, а реакція на команди Esc, Ctr+C, Break… повинна бути дуже швидкою.
Правило 10. Інтерфейс не повинен використовувати дуже багато пам'яті, виділеної користувачеві. Він повинен відображати основну інформацію про виконуване завдання і про стадію завдання.
Правило 11. Зв'язані операції повинні бути об'єднані в один діалог. Якщо це неможливо, операції повинні бути розділені таким чином, щоб зв'язані діалоги були доступні.
Правило 12. Потрібно дотримуватися правила Міллера. Правило Міллера 7+/-2 говорить, що людина може зосередитися на 5-9 елементах. Правило повинне застосовуватися при проектуванні меню, підменю, діалогових полів і т.д. Правило може бути реалізоване шляхом декомпозиції інтерфейсу і його подальшим групуванням в об'єднані групи.
Рис. 1.5. Групування полів. Два функціонально рівних рішення.
Структуровані схеми/діаграми
Наступні елементи використовуються в структурному підході: