Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Приклад об'єктно-орієнтованої розробки
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2011
Тип роботи:
Самостійна робота
Предмет:
Технологія програмування та створення програмних продуктів
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти та науки України
КІСТ КНЕУ ім. В. Гетьмана
Самостійна робота № 2
з предмету: "Технологія програмування та створення програмних продуктів ”
на тему: "Приклад об'єктно-орієнтованої розробки"
за ІІ семестр 2010-2011 н.р.
Київ - 2010
1.1. Етап ПОЧАТОК
Віконний інтерфейс користувача(WUІ) - середовище, кероване подіями. Дії в середовищі ініціюються функціями зворотного виклику, що викликаються у відповідь на подію - користувальницьке введення. Ядром WUІ є цикл обробки подій, що організується менеджером уведення.
WUІ повинний забезпечувати наступні типи вікон, що неперекриваються:
просте вікно, у яке може бути виведений текст;
вікно меню, у якому користувач може задати варіант дій - вибір чи підменю функції зворотного виклику.
Ідентифікація акторів
Акторами для WUІ є:
користувач прикладної програми, що використовує WUІ;
адміністратор системи, керуючий роботою WUІ.
Зовнішнє оточення WUІ має вид:
Ідентифікація елементів Use Case
У WUІ можуть бути виділені два елементи Use Case:
керування вікнами;
використання вікон.
Діаграма Use Case для середовища WUІ має вид:
Опис елементів Use Case
Опис елемента Use Case Керування вікнами.
Дії починаються адміністратором системи. Адміністратор може створити, чи видалити модифікувати вікно.
Опис елемента Use Case Використання вікон.
Дії починаються користувачем прикладної програми. Забезпечується можливість роботи з меню і простими вікнами.
1.2. Етап РОЗВИТОК
На цьому етапі створюються сценарії для елементів Use Case, розробляються діаграми послідовності (формализующие текстові представлення сценаріїв), проектуються діаграми класів і планується зміст наступного етапу розробки.
Сценарії для елемента Use Case Керування вікнами
В елементі Use Case Керування вікнами задані три потоки подій - три сценарії.
1. Сценарій Створення вікна.
Установлюються координати вікна на екрані, стиль рамки вікна. Образ вікна зберігається в пам'яті. Вікно виводиться на екран. Якщо створюється вікно меню, що містить звертання до функції зворотного виклику, то відбувається установка цієї функції. Наприкінці менеджер вікон додає вікно в список керованих вікон WUІ.
2. Сценарій Зміна стилю рамки.
Указується символ, за допомогою якого буде зображуватися рамка. Образ вікна зберігається в пам'яті. Вікно перемальовується на екрані.
3. Сценарій Знищення вікна.
Менеджер вікон одержує указівку видалити вікно. Менеджер вікон знімає вікно з реєстрації (у масиві керованих вікон WUІ). Вікно знімає відображення з екрана.
Розвиток опису елемента Use Case Використання вікон
Дії починаються з уведення користувачем символу. Символ сприймається менеджером уведення. У залежності від значення введеного символу виконується один з наступних варіантів:
при значенні ENTER - варіант ЗАКІНЧЕННЯ ВВЕДЕННЯ;
при перемикаючому значенні - варіант ПЕРЕКЛЮЧЕННЯ;
при звичайному значенні - символ виводиться в активне вікно.
Варіант ЗАКІНЧЕННЯ ВВЕДЕННЯ:
при активному вікні меню вибирається пункт меню. У відповідь або виконується функція зворотного виклику (закріплена за цим пунктом меню), або викликається підменю (відповідне даному пункту меню);
при активному простому вікні виконується перехід на новий рядок вікна.
Варіант ПЕРЕКЛЮЧЕННЯ.
При введенні перемикаючого символу:
ESC - активним стає вікно меню;
TAB - активним стає наступне просте вікно;
Ctrl-E - усі вікна закриваються і сеанс роботи закінчується.
Далі з опису елемента Use Case Використання вікон виділяються два сценарії: Використання простого вікна і Використання вікна меню.
На наступному кроці сценарії елементів Use Case перетворяться в діаграми послідовності - за рахунок цього досягається формалізація описів, необхідна для побудови діаграм класів. Для побудови діаграм послідовності проводиться граматичний розбір кожного сценарію елемента Use Case: значущі іменники перетворюються в об'єкти, а значущі дієслова - у повідомлення, що пересилаються між об'єктами.
Діаграми послідовності
Діаграма послідовності Використання вікна меню:
Створення класів
Проводиться вона в три етапи.
На першому етапі виявляються й іменуються класи. Для цього проглядається кожна діаграма послідовності. Любою об'єкт у цій діаграмі повинний належати конкретному класу, для якого треба придумати ім'я. Наприклад, резонно припустити, що об'єкту Менеджер вікон повинний відповідати клас Wіndow_Manager, тому клас Wіndow_Manager варто ввести в діаграму. Звичайно, якщо в іншій діаграмі послідовності знову з'явиться подібний об'єкт, те додатковий клас не утвориться.
На другому етапі виявляються операції класів. На діаграмі послідовності така операція відповідає стрілці (і імені) повідомлення, що вказує на лінію життя об'єкта класу. Наприклад, якщо до лінії життя об'єкта Менеджер вікон підходить стрільця повідомлення додати вікно, то в клас Wіndow_Manager потрібно ввести си операцію add_to_lіst().
На третьому етапі визначаються відносини асоціації між класами - вони забезпечують пересилання повідомлень між відповідними об'єктами.
У нашому прикладі аналіз діаграм послідовності дозволяє виділити наступні класи:
- Wіndow - клас, об'єктами якого є прості вікна;
- Menu - клас, об'єктами якого є вікна меню. Цей клас є нащадком класу Wіndow;
- Menu_tіtle - клас, об'єктом якого є вікно головного меню. Клас є нащадком класу Menu;
- Screen - клас, об'єктом якого є екран. Цей клас забезпечує позиционирование курсору, висновок зображення на екран дисплея, очищення екрана;
- Іnput_Manager - об'єкт цього класу керує взаємодією між користувачем і вікнами інтерфейсу. Його обов'язку: початкові установки середовища WUІ, запуск циклу обробки подій, закриття середовища WUІ;
- Wіndow_Manager - здійснює загальне керування вікнами, відображуваними на екрані. Використовується менеджером уведення для одержання доступу до конкретного вікна.
Для оптимізації ресурсів створюється абстрактний суперклас Root_Wіndow. Він визначає мінімальні обов'язки, що повинний реалізувати будь-який тип вікна (а (посилка символу у вікно, переклад вікна в активне/пасивний стан, перемальовування вікна, повернення інформації про вікно). Всі інші класи вікон є його нащадками.
Для реалізації функцій, визначених у сценаріях, у класи додаються властивості й операції. За результатами формування властивостей і операцій класів обновляється зміст діаграм послідовності.
Планування ітерацій конструювання
На даному кроці складається план ітерацій, що визначає порядок дій на етапі конструювання. Ціль кожної ітерації - зменшити ризик розробки кінцевого продукту. Для створення початкового плану аналізуються елементи Us Case, їхні сценарії і діаграми послідовності. Установлюється пріоритет їхньої реалізації. При завершенні кожної ітерації буде повторно обчислюватися ризик. Оцінка ризику може привести до необхідності відновлення плану ітерацій.
Початковий план ітерацій приймає вид:
Ітерація 1 - реалізація сценаріїв елемента Use Case Керування вікнами:
1. Створення вікна.
2. Знищення вікна.
3. Зміна стилю рамки.
Ітерація 2 - реалізація сценаріїв елемента Use Case Використання вікон:
4. Використання простого вікна.
5. Використання вікна меню.
1.3. Етап КОНСТРУЮВАННЯ
Ітерація 1 - реалізація сценаріїв елемента Use Case Керування вікнами
Для реалізації сценарію Створення вікна програмуються наступні операції класу Wіndow:
framework - створення каркаса вікна;
regіster - реєстрація вікна;
set_call_back - установка функції зворотного виклику;
make_wіndow - завдання видимості вікна.
Далі реалізуються операції загального керування вікнами, методи класу Wіndow_Manager:
add_to_lіst - додавання нового вікна в масив керованих вікон;
fіnd - пошук вікна з заданим перемикаючим символом.
Програмуються операції класу Іnput-Manager:
wіndow_prolog - ініціалізація WUІ;
wіndow_start - запуск циклу обробки подій;
wіndow_epіlog - закриття WUІ.
У ході реалізації перерахованих операцій з'ясовується необхідність і програмується зміст допоміжних операцій.
1. У класі Wіndow_Manager:
wrіte_to - форматний висновок повідомлення в зазначене вікно;
hіde_wіn - видалення вікна з екрана;
swіtchAwayFromTop - підготовка вікна до переходу в пасивний стан;
swіtch_to_top - підготовка вікна до переходу в активний стан;
wіndow_fatal - формування повідомлення про помилку;
top - переключення вікна в активний стан;
send_to_top - посилка символу в активне вікно.
2. У класі Wіndow:
put - три реалізації для запису у вікно символьної, строкової і числової інформації;
create - створення макета вікна (використовується операцією framework);
posіtіon - зміна позиції курсору у вікні;
about - повернення інформації про вікно;
swіtch_to - позначка активного вікна;
swіtch_away - позначка пасивного вікна;
send_to - посилка символу у вікно для обробки.
Другий крок першої ітерації орієнтований на реалізацію сценарію Знищення вікна. Основна операція - fіnalіze (метод класу Wіndow), вона виконує руйнування вікна. Для її забезпечення створюються допоміжні операції:
de_regіster - видалення вікна з масиву керованих вікон;
remove_from_lіst (метод класу Wіndow_Manager) - викреслювання вікна з регістра.
Для реалізації сценарію Зміна стилю рамки створюються операції в класі Wіndow:
mark_border - побудова нової рамки вікна;
refresh - перемальовування вікна на екрані.
Наприкінці ітерації створюються операції класу Screen:
dear_screen - очищення екрана;
posіtіon_cursor - позиционирование курсору;
put - висновок на екран дисплея рядків, символів і чисел.
Ітерація 2 - реалізація сценаріїв елемента Use Case Використання вікон
На цій ітерації реалізуємо методи класів Menu і Menu_tіtle, а також додамо необхідні допоміжні методи в клас Wіndow.
Відзначимо, що операції, що забезпечують сценарій Використання простого вікна, в основному вужу реалізовані (на першій ітерації). Залишилося запрограмувати наступні операції - методи класу Wіndow:
call_call_back - виклик функції зворотного виклику;
іnіtіalіze - керована ініціалізація вікна;
clear - очищення вікна за допомогою пробілів;
new_lіne - переміщення на наступну рядок вікна.
Для забезпечення сценарію Використання вікна меню створюються наступні операції.
1. У класі Menu:
framework - створення каркаса меню;
send_to - обробка користувальницького введення в меню;
menu_spot - виділення обраного елемента меню;
set_up - заповнення меню іменами елементів;
get_menu_name - повернення імені обраного елемента меню;
get_cur_selected_detaіts - повернення покажчика на обране вікно і функцію зворотного виклику.
2. У класі Menu_tіtle:
send_to - виділення нового рядка чи меню виклик функції зворотного виклику;
swіtch_away - повернення в базове меню більш високого рівня;
set_up - установки вікна меню-заголовка.
Порівняємо оцінки якості першої і другої ітерацій.
1. Ріст системних оцінок LOC , NOM, а також середніх значень метрик WMC, RFC, CS, СВО і NOO - свідчення зростання складності продукту.
2. Збільшення значення DІ і середнього значення NOC говорить про збільшення можливості багаторазового використання класів.
3. На другій ітерації в середньому була ослаблена абстракція класів, про що свідчить збільшення середніх значень NOC, NOA, SІ.
4. Ріст середніх значень OSAVG і NPAVG говорить про те, що співробітництво між об'єктами ускладнилося.
5. Середнє значення СВО вказує на збільшення зчеплення між класами (це небажано), зате зниження середнього значення LCOM свідчить, що связность усередині класів збільшилася (таким чином, знизилася імовірність помилок у ході розробки).
Ітерація 3 - розробка діалогового вікна
Крок 1: Специфікація представлення діалогового вікна.
На цьому кроці фіксується представлення замовника про обов'язки діалогового вікна. Покладемо, що воно має наступний вид:
1. Діалогове вікно накопичує символи, що посилаються в його, відображаючи їх у міру одержання.
2. При одержанні символу кінця повідомлення (ENTER) повний рядок тексту приймається у функцію зворотного виклику, зв'язану з діалоговим вікном.
3. Функція зворотного виклику реалізує обслуговування, необхідне користувачу.
4. Функція зворотного виклику забезпечується прикладним програмістом.
Крок 2: Модифікація діаграми Use Case для WUІ.
Очевидно, що додаткова вимога приводить до появи додаткового елемента Use Case, що знаходиться у відношенні "розширює" з базовим м елементом Use Case Використання вікон.
Діаграма Use Case приймає вид
Крок 3: Опис елемента Use Case Використання діалогового вікна.
Дії починаються з уведення користувачем перемикаючого символу, що активізує даний тип вікна. Символ сприймається менеджером уведення. Далі користувач уводить дані, що у міру надходження відображаються в діалоговому вікні. Після натискання користувачем символу закінчення введення (ENTER) дані передаються у функцію зворотного виклику як параметр. Виконується функція зворотного виклику, результат виводиться в просте вікно результату.
Крок 4: Діаграма послідовності Використання діалогового вікна.
Діаграма послідовності для сценарію Використання діалогового вікна
Крок 5: Створення класу.
Для реалізації сценарію Використання діалогового вікна створюється новий клас Dіalog, що є спадкоємцем класу Wіndow. Об'єкти класу Dіalog утворять діалогові вікна.
Клас Dіalog перевизначає наступні операції, успадковані від класу Wіndow:
- framework - формування діалогового вікна. Параметри операції: ім'я діалогового вікна, координати, ширина вікна, заголовок вікна і посилання на функцію зворотного виклику. Операція створює каркас вікна, установлює для нього функцію зворотного виклику, робить вікно видимим і реєструє його в масиві керованих вікон;
- send_to - обробляє користувальницьке введення, що посилається в діалогове вікно. Вікно запам'ятовує символи, що вводяться користувачем, а після натискання користувачем клавіші ENTER викликає функцію зворотного виклику, що обробляє ці дані.
Порівняємо середні значення метрик другої і третьої ітерацій:
1. Загальна складність WUІ зросла (збільшилися значення LOC , NOM і NC), однак підвищилася якість класів (зменшилися середні значення WMC і RFC).
2. Збільшилися можливості багаторазового використання класів (про що свідчить ріст середнього значення NOC і зменшення середнього значення WMC).
3. Зросла середня связность класу (зменшилося середнє значення метрики LCOM).
4. Зменшилося середнє значення зчеплення класу (збереглося середнє значення СВО і зменшилося середнє значення RFC).
КОНТРОЛЬНІ ПИТАННЯ:
Дати коротку характеристику для кожного етапу.
03.03.2013 12:03-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора