КПЗ_Лаб5_c#

Шаблони проектування

Ціль

∙Навчитись використовувати шаблони проектування;

∙Реалізувати запропоноване завдання

Завдання

У даному практичному завданні описується перша ітерація процесу розробки простої пакетної програми, що виконує розрахунок зарплати. Користувацькі історії, включені в це практичне заняття, гранично спрощені. Наприклад, спрощеним є алгоритм розрахунків податків. У цьому завданні буде виконано деякий швидкий аналіз, а також сеанс проектування, які зазвичай мають місце в початковий момент стандартної ітерації розробки ПЗ. Вибрано користувацькі історії для даної ітерації, які тепер потрібно перевести у форму, придатну для практичної реалізації. Наведені в Uml-діаграми є поверхневими ескізами майбутньої системи.

Специфікація

Наступні замітки з'явилися в результаті бесід із замовником. Предметом цих бесід були користувацькі історії, обрані для етапу першої ітерації.

∙Деякі співробітники працюють на погодинній основі. Для них використовується погодинна ставка, яка вводиться в одне з полів запису, відповідної до цього працівника. У якості джерела вхідних даних застосовуються щоденні картки табельного обліку,

уякі вносяться записи, що включають відомості про дати й кількість відпрацьованих годин. Ставка за понаднормові години

упівтора раза перевищує звичайну ставку. Виплата грошей проводиться по п'ятницях.

∙Деякі працівники одержують фіксовану ставку. У цьому випадку виплата грошей проводиться в останній робочий день місяця. Величина місячної зарплати зберігається в одному з полів запису для даного працівника.

∙Деякі зі співробітників одержують комісійні, нараховані на основі їх окладів. Їм доводиться заповнювати торговельні квитанції, у яких вони вказують дати й суми укладених угод. Величина комісійних вказується в одному з полів запису, відповідної до співробітника. Усі комісійні виплачуються по п'ятницях.

∙Співробітники можуть самі вибирати метод платежу. Вони можуть одержувати платіжні чеки, що відсилаються на вибрану поштову адресу; вони можуть передавати свої платіжні чеки касирові; також можна зробити так, щоб платіжні чеки переводилися на банківський депозит на зазначений вами рахунок.

∙Деякі співробітники входять у певні об'єднання (спілки). У цьому випадку відповідний запис включає поле, у якому визначається величина щотижневого внеску. Причому величина внеску обчислюється на підставі розміру зарплати. Крім цього, від самого об'єднання може виходити ініціатива щодо зміни розміру внесків для окремих членів об'єднання. Розміри цих внесків визначаються щотижня, а також вони повинні обчислюватися на основі суми наступної виплати.

∙Додаток, що виконує розрахунки зарплати, запускається по робочих днях, у результаті чого визначається величина зарплати співробітників, що працювали в цей день. Система повідомляє дату, якою закриваються виплати співробітникам. Завдяки цьому можна обчислити суми платежів, починаючи від дати останньої оплати й завершуючи зазначеною датою.

Початок роботи супроводжується генеруванням схеми бази даних. У процесі розв'язання цієї проблеми використовується якийсь вид реляційної бази даних, а сформульовані користувачем вимоги є джерелом ідей щодо типів застосовуваних полів і таблиць. Проектування робочої схеми й перехід до розробки запитів не складе особливих зусиль. У результаті застосування подібного підходу генерується додаток, центральне місце в якому займає база даних. Насправді бази даних представляють деталі реалізації. Тому перехід до розгляду самих баз даних повинен здійснюватися якнайпізніше. Досить багато прикладів додатків, які складним образом переплетені з базами даних тільки тому, що споконвічно підвищена увага приділялася саме базам даних. Зверніть увагу на визначення абстракції: розширення є істотним, а виключення — недоречне. Розглядати базу даних недоречно на даній стадії проекту, оскільки її функції обмежуються зберіганням і забезпеченням доступу до даних.

Аналіз за методом варіантів використання

Давайте замість організації зберігання даних у системі почнемо з розгляду поведінки системи. Саме цей фактор є ключовим у справі визначення цінності самої системи. Один з методів одержання відомостей про поведінку системи і їх подальший аналіз полягає в створенні варіантів використання. Згідно з визначенням Джекобсона (Jacobson), формат запису варіантів використання нагадує формат користувацьких історій, розповсюджених у практиці екстремального програмування. Відмінність варіанта використання від користувацької історії полягає в більш ретельній "проробці" деталей (у першому випадку). Подібні вдосконалення мають сенс тільки в тому випадку, якщо була обрана реалізація користувацької історії в поточній ітерації. У процесі проведення аналізу за допомогою методу варіантів використання розглядаються користувацькі історії й тести

прийнятності з метою пошуку сигналів, створюваних користувачами системи. Потім здійснюються спроби формулювання відповідних реакцій системи на ці сигнали. Як приклад зверніть увагу на перелік користувацьких історій, обраних для наступної ітерації.

1.Додавання запису про нового працівника.

2.Видалення запису у випадку звільнення працівника.

3.Проводка табеля.

4.Проводка торговельних квитанцій.

5.Проводка членських внесків.

6.Зміна відомостей про працівника (погодинна ставка, величина податку).

7.Щоденне виконання програми розрахунків зарплати.

Ну а тепер спробуємо перетворити кожну користувацьку історію в пророблений варіант використання. При цьому можуть знадобитися додаткові подробиці, що дозволяють спроектувати код таким чином, щоб відповідати вимогам кожної історії.

Додавання запису про працівника Варіант використання 1: додавання запису про нового працівника

Факт додавання нового співробітника підтверджується виконанням транзакції AddEmp. Ця транзакція включає ім'я співробітника, адресу, а також призначений йому табельний номер. Сама транзакція існує в трьох формах:

AddEmp <EmpID> "<name>" "<address>" H <hourly-rate>

AddEmp <EmpID> "<name>" "<address>" S <monthly-salary> AddEmp <EmpID> "<name>" "<address>" C <monthly-salary>

<commision-rate>

При цьому створюється запис про співробітника, поля якого одержують відповідні значення.

Повідомлення про помилку

An error in the transaction structure (Помилка в структурі транзакції) Якщо структура транзакції некоректна, виводиться повідомлення про помилку, причому не вживають які-небудь дії.

Існує три форми транзакції AddEmp, причому всі вони використовують поля <EmpID>, <name> і <address>. Можна скористатися шаблоном Command з метою створення абстрактного базового класу AddEmployeeTransaction із трьома похідними класами:

Рис.1. Ієрархія класів AddEmployeeTransaction

AddHourlyEmployeeTransaction,

AddSalariedEmployeeTransaction і

AddCommissionedEmployeeTransaction. (рис. 1). Описана структура відповідає принципу персональної відповідальності

(SRP, Single-Responsibility Principle), оскільки кожне завдання виконується у власному окремому класі. Альтернативний варіант— розміщення всіх виконуваних завдань у єдиному модулі. Хоча при цьому скорочується кількість класів у системі, що приводить до її спрощення, але, у той же час увесь код, що виконує обробку транзакцій, зосереджується в одному місці. У результаті, створюється великий модуль, що чревато появою помилок. У першому варіанті використання розглядається запис про працівника. Його використання автоматично веде до появи деякого виду бази даних. І знову міркування про структуру записів або полів приводять нас до думки про необхідність переходу до бази даних, хоча не слід

піддаватися цій спокусі. Насправді, у розглянутому практичному випадку потрібне створення запису про працівника. Яка об'єктна модель застосована в цьому випадку? Які функції трьох різних транзакцій у цьому випадку? Ці транзакції створюють три різні види об'єктів, що моделюють записи про працівників, причому при цьому імітуються три різні види транзакцій AddEmp. На рис. 2 демонструється застосовувана в цьому випадку структура.

Рис. 2. Можлива ієрархія класів Employee

Видалення запису про працівника Варіант використання 2: видалення запису про працівника

Записи про співробітників видаляються у випадку, якщо виконується транзакція DelEmp.

DelEmp <EmpID>

При виконанні цієї транзакції видаляється запис відповідного працівника. Повідомлення про помилку

Invalid or unknown EmpID (Невідомий або некоректно зазначений табельний номер працівника)

Якщо поле <EmpID> структуроване неправильно, або зазначений некоректний запис працівника, транзакція виводить повідомлення про помилку, причому не вживають які-небудь інші дії.

Проводка картки табельного обліку Варіант використання 3: проводка картки табельного обліку

У результаті виконання транзакції Timecard у системі створюється запис, відповідно до картки табельного обліку, яка зв'язується із записом відповідного працівника.

Timecard <EmpID> <date> <hours>

Повідомлення про помилку 1

The selected employee is not hourly ( Для обраного працівника не зазначений табель)

У цьому випадку система виводить відповідне повідомлення про помилку й не вживає яких-небудь дій надалі.

Повідомлення про помилку 2

An error in the transaction structure (Помилка в структурі транзакції) Система виводить відповідне повідомлення про помилку, не вживаючи при цьому яких-небудь подальших дій.

При виконанні цього варіанта використання деякі транзакції застосовуються до певних категорій працівників, підкреслюючи ідею про те, що різні категорії представлені різними класами. У цьому випадку також проявляється взаємозв'язок між картками табельного обліку й працівниками на погодинній оплаті. На рис. 3 продемонстрована можлива статична модель, що демонструє подібний рід взаємозв'язку.

Рис. 3. Зв'язок між торговельними квитанціями Hourlyemployee і

Timecard

Проводка торговельних квитанцій Варіант використання 4: проводка торговельної квитанції

У результаті виконання транзакції SalesReceipt система створює новий запис, відповідно до торговельної квитанції, і зв'язує її із працівником, якому виплачуються комісійні.

SalesReceipt <EmpID> <date> <amount>

Повідомлення про помилку 1

The selected employee is not hourly (Обраному співробітникові не нараховуються комісійні)

У цьому випадку система виводить відповідне повідомлення про помилку, не вживаючи при цьому яких-небудь дій.

Повідомлення про помилку 2

An error in the transaction structure (Помилка в структурі транзакції) Система виводить відповідне повідомлення про помилку, не вживаючи при цьому яких-небудь дій.

Рис. 4. Працівники, що одержують комісійні із продажів, і торговельні квитанції

Цей варіант використання нагадує варіант 3. Тут з'являється структура, показана на рис. 4.

Проведення оплати за членство в організації Варіант використання 5: проведення оплати за членство в організації

У результаті виконання цієї транзакції система створює запис, пов'язаний з оплатою членства, і зв'язує його з кодом певної організації-одержувача платежу.

ServiceCharge <memberID> <amount>

Повідомлення про помилку

Poorly formed transaction (Погано сформована транзакція) Якщо транзакція недостатньо добре сформована або не визначає номер існуючої організації, транзакція виводить відповідне повідомлення про помилку.

Цей варіант використання демонструє, що для членів якої-небудь організації (об'єднання) не завжди досить вказівки табельного номера працівника. Кожна організація підтримує власну схему нумерації для своїх членів. Тому системою повинна надаватися можливість встановлювати зв'язок між членами якоїсь організації й іншими працівниками. Існує безліч способів установки такого роду взаємозв'язки, тому щоб уникнути можливої помилки відкладемо ухвалення остаточного рішення. Можливо, що обмеження, які накладаються іншими компонентами системи дозволять вибрати оптимальний розв'язок.

Лише одне можна затверджувати цілком точно. Існує безпосередній взаємозв'язок між членами організації і їх витратами. На рис. 5 демонструється можлива статична модель, що ілюструє цей взаємозв'язок.

Рис. 5. Проводка платежів за членство в організації

Зміна відомостей про працівника Варіант використання 6: зміна відомостей про працівника

У результаті виконання цієї транзакції система змінює відомості, зазначені в записі для відповідного працівника. Існує кілька можливих варіантів цієї транзакції.