Технічне проектування полягає у відображенні вимог середовища функціонування і розроблення системи та визначенні всіх конструкцій як композицій компонентів. На цьому етапі відбувається прив’язка проекту до технічних особливостей платформи реалізації, СУБД, організації комунікацій, наявності фактора реального часу, виконавських вимог, таких, як швидкість реагування системи на зовнішні стимули тощо.
Об’єкти моделі аналізу вимог погоджуються з урахуванням перелічених вище особливостей, формалізуються всі стимули, які посилає чи отримує об’єкт, і всі операції, що є відповіддю на зазначені стимули.
Кожний з наведених вище аспектів прив’язки може потребувати побудови допоміжних інтерфейсних або керуючих об’єктів чи корекції існуючих. До того ж може виявитися можливість використання готових підсистем, чий устрій дещо відрізняється від підсистем, які були досі визначені на основі аналізу вимог. Тоді вносяться відповідні корективи до моделі аналізу вимог та архітектури системи.
Наступним кроком проектування може бути врахування певних властивостей, які зазвичай належать до так званих показників якості. Зупинимося на деяких з них.
Надійність функціонування (operational reliability). Надійність функціонування системи можна значно підвищити, якщо передбачити і відпрацювати виняткові ситуації під час роботи системи. Тестування системи проводиться, щоб переконатися, що реалізація системи відповідає висунутим до неї вимогам. Але вимоги здебільшого обумовлюють, що має робити система, тоді як важливо також обумовити, чого вона не має робити. Одним із шляхів для цього є явна фіксація ситуацій, які унеможливлять правильну роботу системи (так звані виняткові ситуації).
Причинами виникнення виняткових ситуацій можуть бути: помилки користувача при зверненні до системи чи під час підготовки даних; непередбачені збіги обставин функціонування системи (невиявлені під час тестування помилки проектування); випадкові збої обладнання тощо. При цьому система може реагувати по-різному: відмовитися виконувати певну послугу, виконати її помилково або зруйнувати якісь дані. Вочевидь, для другої і третьої з перелічених реакцій неможливо передбачити наслідки, тоді як для першої можна докласти певних зусиль, щоб відновити роботоздатність системи, наприклад, виконати один з наведених нижче варіантів робіт:
відновити попередній стан системи (що передував винятковій ситуації) і спробувати застосувати іншу стратегію виконання послуги;
відновити попередній стан системи, внести необхідні корективи і повторити виконання послуги із старою стратегією;
відновити попередній стан системи, сформувати повідомлення про помилку й зупинити систему в очікуванні реакції користувача.
Ми бачимо, що забезпечення надійності системи вимагає для кожної її послуги передбачення виняткових ситуацій, аналізу їхніх причин та наслідків, побудови механізму відтворення попереднього стану (для чого необхідна певна стратегія запам’ятовування поточного стану системи) та виправлення ситуації. Для забезпечення таких дій застосовуються типові засоби:
подвійне обчислення й порівняння результатів або їхніх контрольних сум, у тому числі виконаних на різних процесорах;
таймери, що визначають часові інтервали фіксації поточного стану;
додаткові перевірки коректності даних, які передають актори чи зовнішні системи або окремі компоненти однієї системи.
Усі зазначені вище дії втілюються в додаткових компонентах проекту і призводять до додаткових витрат на певні надмірні перестороги, які є ціною за надійність функціонування системи. Доцільність таких витрат визначається виключно специфікою систем. Якщо наслідки помилок незворотні, наприклад, як у систем підвищеного ризику (космічні та ядерні системи, моніторинг хворих, керування реальними об’єктами), доводиться йти на дублювання процесів і додаткові перевірки. Іноді навіть використовують паралельну роботу кількох команд або взаємну перевірку комп’ютерів, що працюють паралельно, коли один з них здійснює моніторинг іншого. Так, кажуть, що для керування системою ШАТЛ сім комп’ютерів дублюють один одного.
Переносимість системи (system portability). Під таким терміном розуміють можливість змінювати певні використовувані сервісні системи (операційні системи, системи комунікацій у мережах, СУБД тощо) шляхом локального настроювання відповідних модулів. Зазвичай йдеться про переносимість щодо конкретного типу сервісних систем, наприклад, переносимість щодо СУБД, переносимість щодо системи файлів тощо. Для реалізації таких властивостей визначаються об’єкти, які взаємодіють з типом сервісних систем, щодо якого декларується переносимість. Кожний з визначених у такий спосіб об’єктів замінюється на такий, що взаємодіє не безпосередньо із сервісною системою, а з якимсь абстрактним об’єктом-посередником, котрий здійснює трансформацію абстрактного інтерфейсу в інтерфейс конкретної сервісної системи. Об’єкт-посередник при цьому має властивість настроюватися на конкретну сервісну систему.
Так, на рис. 4.3 об’єкт-посередник має призначені для нього операції створення файлу, читання з файлу, записування у файл, модифікації записів файлу, знищення файлу.
Рисунок 4.3 - Об’єкт-посередник
При цьому об’єкти прикладної системи, які звертаються до цього об’єкта за виконанням певних послуг для роботи з файлом, не опікуються подробицями організації файлу в конкретному середовищі його реалізації. Такі подробиці інкапсулює в собі об’єкт-посередник, який, залежно від настроювання, звертається при цьому до системи файлів MS-DOS або UNIX. Таким чином, точку можливих варіацій відносно використання тієї чи іншої системи управління файлами чітко локалізовано, що дає нам право стверджувати про забезпечення стійкості системи, що будується, відносно зміни системи даного сервісу (управління файлами).
Подібні об’єкти-посередники доцільно проектувати для будь-якої передбачуваної можливості зміни вимог, яку не можна реалізувати простою заміною значень певних параметрів.
Нотації для подання продуктів проектування. Продукти проектування подаються переважно в нотаціях, які базуються на моделях аналізу вимог, більшість розглянутих нами діаграм (таких, як діаграми сутності-зв’язку, діаграми переходів у стани, діаграми потоків даних дій, діаграми класів тощо) активно використовуються як нотація для продуктів проектування. Але для них у зазначених діаграмах задіяно об’єкти проекту, що детальніше відображають не лише вимоги до розробки, а й рішення, які сприяють втіленню цих вимог. Звісно, нотації, запропоновані авторами різних методів об’єктно-орієнтованого аналізу та проектування, мають свою специфіку подання наведених вище діаграм.
Досить виразний набір діаграм для моделювання проекту має вже згадуваний метод UML подання у розділі 5.
На рис. 4.4 подано зображення класу об`єкта дата за методом С. Шлеєр та С. Меллора.
Рисунок 4.4 - Діаграма класу дата
Клас позначається прямокутником, під верхньою лінією якого пишеться його ім’я. Шестикутниками всередині прямокутника зображено атрибути класу, кожен шестикутник поділено горизонтальною лінією, над нею зазначається ім’я атрибута, а під нею - тип, до якого він належить. Так само позначені параметри зовнішніх операцій, які може виконувати клас. Самі операції позначаються прямокутниками всередині прямокутника класу. До кожної операції зовні веде лінія, над лінією розміщуються шестикутники вхідних параметрів відповідної операції, під лінією - вихідні, а на лінії - вхідні - вихідні.
Подана на рис. 4.4 діаграма класу визначає, що клас дата має атрибути день, місяць, рік і може виконувати такі операції: створити дату, додати до дати дні, знайти інтервал (у днях) між двома датами, знайти вчорашню або завтрашню дату, перевірити, котра з двох дат передує іншій. Для всіх наведених операцій на діаграмі визначено вхідні та вихідні параметри.
Зазначимо, що атрибут місяць визначає можливі значення від 1 до 12, атрибут день - від 1 до кінцевої дати кожного місяця, атрибут рік - чотири цифри року.
Нотація проектування за методом І. Джекобсона фактично увійшла як складова до методу UML, який буде подано в розділі 5.
Контрольні запитання і завдання
1. Визначте завдання етапу проектування програмного забезпечення.
2. Опишіть процеси етапу проектування.
3. Сформулюйте завдання концептуального проектування.
4. Які є засоби матеріалізації зв’язків у логічних структурах даних?
5. Перелічіть ключові чинники, котрі впливають на проектування інтерфейсів.
6. Назвіть нефункціональні вимоги, які треба врахувати на стадії проектування.
7. Які шари може бути виділено в сучасній архітектурі програмного забезпечення?
8. Якими аргументами треба керуватися при об’єднанні фрагментів програмного забезпечення в системи?
9. Які способи об’єднання об’єктів у системи Ви знаєте?
10. Опишіть процеси забезпечення надійності функціонування системи.
11. Які є способи забезпечення переносимості системи?
12. Які нотації використовують для подання продуктів проектування?
Вінницький національний технічний університет