Методологія

Глава 1 Система позначень

Елементи системи позначень

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

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

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

Діаграми класів

Класи. Кожен клас повинен мати ім'я; якщо ім'я занадто довге, його можна скоротити або збільшити сам значок на діаграмі. Для деяких мов, особливо - для C + + і Smalltalk, ми повинні вимагати, щоб кожен клас мав ім'я, унікальне в системі. На деяких значках класів корисно перераховувати кілька атрибутів і операцій класу. Атрибути і операції на діаграмі представляють прообраз повної специфікації класу, в якій оголошуються всі його елементи. Якщо ми хочемо побачити на діаграмі більше атрибутів класу, ми можемо збільшити значок; якщо ми зовсім не хочемо їх бачити - ми видаляємо розділяємо межу і пишемо лише ім'я класу. Атрибути використовуються в аналізі та проектуванні для вираження окремих властивостей класу. Ім'я атрибута повинно бути недвозначно в контексті класу. Операції зазвичай зображаються всередині значка класу тільки своїм ім'ям. Щоб відрізняти їх від атрибутів, до їх іменами додаються дужки. Імена операцій повинні розумітися в контексті класу однозначно відповідно до правил перевантаження операцій вибраної мови реалізації.

Відношення між класами. Класи рідко бувають ізольовані, навпаки вони вступають у відносини один з одним. Значок асоціації з'єднує два класи і означає наявність семантичного зв'язку між ними. Асоціації часто відзначаються іменниками, наприклад Employment (місце роботи), що описують природу зв'язку. Клас може мати асоціацію з самим собою (так звана рефлексивна асоціація). Позначення потужності пишеться у кінця лінії асоціації і означає число зв'язків між кожним екземпляром класу на початку лінії з примірниками класу в її кінці. Значок успадкування, що представляє відношення "загальне / приватне", виглядає як значок асоціації зі стрілкою, яка вказує від підкласу до суперкласу. Значок агрегації позначає відношення "ціле / частина" (зв'язок "has") і виходить з значка асоціації додаванням зафарбованої гуртка на кінці, що позначає агрегат. Знак використання позначає відношення "клієнт / сервер" і зображається як асоціація з порожнім гуртком на кінці, відповідному клієнту. Цей зв'язок означає, що клієнт має потребу в послугах сервера, тобто операції класу-клієнта викликають операції класу-сервера або мають сигнатуру, в якій повертається значення або аргументи належать класу сервера.

Категорії класів. Категорія класів - це агрегат, що складається з класів та інших категорій класів, у тому ж значенні, в якому клас - агрегат, що складається з операцій та інших класів. Категорії класів служать для розбиття логічної моделі системи. Кожен клас системи повинен "жити" у єдиній категорії або знаходитися на самому верхньому рівні системи. На відміну від класу, категорія класів не має операцій або станів в явному вигляді, вони містяться в ній неявно в описах агрегованих класів. Як і для класу, для категорії потрібне ім'я, яке має бути унікальне в даній моделі. Категорія класів представляє собою інкапсульовані простір імен Деякі класи в категорії можуть бути відкритими, тобто експортуватися для використання за межі категорії. Решта класи можуть бути частиною реалізації, тобто не використовуватися ніякими класами. За замовчуванням усі класи в категорії визначаються як відкриті, якщо явно не вказано протилежне.

Діаграми станів і переходів

Стани. Діаграма станів і переходів показує: простір станів даного класу; події, які спричиняють перехід з одного стану в інший; дії, які відбуваються при зміні стану. Стан представляє собою підсумковий результат поведінки системи. У будь-який момент часу стан об'єкта визначає набір властивостей (зазвичай статичний) об'єкта і поточні (зазвичай динамічні) значення цих властивостей. Під "властивостями" мається на увазі сукупність усіх зв'язків і атрибутів об'єкта. Ми можемо узагальнити поняття стану так, щоб воно було застосувати і до об'єкта, і до класу, так як всі об'єкти одного класу "живуть" в одному просторі станів. Кожен стан повинен мати ім'я; якщо воно виявляється занадто довгим, то його можна скоротити або збільшити значок стану. Кожне ім'я стану повинне бути унікальною в своєму класі. На значках деяких станів корисно вказати асоційовані з ними дії.

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

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

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

Діаграми взаємодії

Діаграма взаємодії використовується, щоб простежити виконання сценарію в тому ж контексті, що і діаграма об'єктів. До певної міри діаграма взаємодії є просто інший спосіб подання діаграми об'єктів. Перевага діаграми взаємодій в тому, що на ньому легше читається порядок посилки повідомлень, а перевага діаграми об'єктів у тому, що вона краще підходить для багатьох об'єктів зі складними викликами і допускає включення іншої інформації: зв'язку, значення атрибутів, ролі, блок-схеми та видимість . Діаграми взаємодії не вводять нових понять або позначень. Швидше, вони беруть істотні елементи діаграми об'єктів і перебудовують їх. Імена об'єктів діаграми взаємодій (ті ж, що і на діаграмі об'єктів) записуються горизонтально у верхній її частині. Під кожним з них малюється вертикальна пунктирна лінія. Відправлення повідомлень (які можуть позначати події або виклики операцій) показуються горизонтальними стрілками, з тим же синтаксисом і позначеннями синхронізації, що і на діаграмі об'єктів. Діаграми взаємодії часто краще діаграм об'єктів передають семантику сценаріїв на ранніх етапах життєвого циклу розробки, коли ще не ідентифіковані протоколи окремих класів.

Діаграми модулів. Діаграма модулів показує розподіл класів та об'єктів по модулях у фізичному проектуванні системи. Кожна окрема діаграма модулів представляє деякий ракурс структури модулів системи. При розробці ми використовуємо діаграму модулів, щоб показати фізичний поділ нашої архітектури. Основними елементами діаграми модулів є модулі та їх залежності.

Модулі. Кожен модуль повинен мати ім'я; звичайно це ім'я відповідного фізичного файлу в каталозі проекту. Як правило, такі імена пишуться без суфіксів, які розпізнаються по типу значка. Якщо ім'я надто довге, ми, як звичайно, або скорочуємо його, або розширюємо значок. Кожне повне ім'я файлу повинне бути унікальним. Кожен модуль містить або опис, або визначення класів та об'єктів, а також інші конструкції мови. За ідеєю, "розкривши" значок модуля на діаграмі, ми повинні потрапити всередину відповідного файлу.

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

Діаграми процесів.

Діаграми процесів використовуються, щоб показати розподіл процесів по процесорах у фізичному проекті системи. Окрема діаграма процесів показує один ракурс структури процесів системи. При розробці проекту ми використовуємо діаграму процесів, щоб показати фізичну сукупність процесорів і пристроїв, що забезпечують роботу системи. Основні елементи діаграми процесів - процесори, пристрої і їхні з'єднання.

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

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

Застосування системи позначень

Результат об'єктно-орієнтованого проектування. Зазвичай результатами аналізу системи будуть набори діаграм об'єктів, діаграм класів і діаграми станів і переходів. Проектування системи, в яке входить розробка її архітектури та реалізації, породжує діаграми класів, об'єктів, модулів, процесів, а також динамічні ракурси цих діаграм. Існує наскрізний зв'язок між цими діаграмами, що дозволяє нам простежити вимоги від реалізації назад до специфікації. Почавши з діаграм процесів, можна знайти головну програму, яка визначена на деякій діаграмі модулів. Ця діаграма модулів містить набори класів та об'єктів, визначення яких ми знайдемо на відповідних діаграмах класів або об'єктів. Автоматизованим інструментам проектування можна доручити перевірку цілісності, обмежень і повноти документації. Вони також допомагають розробнику легко і швидко переглядати результати аналізу та розробки. Використання автоматизованих інструментів дозволяє звільнити розробника від тягаря узгодження деталей, дозволяючи йому зосередитися на творчих аспектах процесу проектування. Описана тут система позначень годиться як для маленьких систем, що містять декілька класів, так і для великих проектів з кількома тисячами класів. Ця система позначень особливо зручна для організації ітераційного процесу розробки.