Існують різні способи використання UML. Мартін Фаулер викликає ці режими UML і визначає чотири: UML як нотатки , UML як ескіз , UML як креслення та UML як мову програмування .
UML як мова програмування ніколи не знімався. У цій галузі проводилися деякі роботи під різними назвами, як, наприклад, модель, керована архітектурою або моделювання програмної інженерії. При такому підході ви створюєте високо деталізовані моделі вашої програмної системи та генеруєте код із цих моделей. Можливо, є деякі випадки використання, коли такий підхід є корисним, але не для загального програмного забезпечення, і особливо не за межами великих компаній, які можуть дозволити собі інструменти, які використовують цей підхід. Це також трудомісткий процес - я можу вводити код для класу швидше, ніж можу створити всі графічні моделі, необхідні для його реалізації.
UML як креслення часто вказує на проект "великий дизайн на передній план" . Звичайно, це не повинно бути. Модель також може бути повністю описана для певного приросту. Але ідея полягає в тому, що час витрачається на створення дизайну у вигляді моделей UML, які потім передаються комусь для перетворення в код. Всі деталі прописані, і перетворення в код має тенденцію бути більш механічним.
UML як ескіз та UML як нотатки схожі за своєю природою, але відрізняються залежно від того, коли вони використовуються. Використання UML як ескізу означає, що ви будете робити ескізи конструкцій, використовуючи позначення UML, але діаграми, ймовірно, не будуть повними, але будуть зосереджені на певних аспектах дизайну, які потрібно спілкуватися з іншими. UML як Notes подібний, але моделі створюються після коду, щоб допомогти зрозуміти базу коду.
Коли ви це замислюєтесь, я думаю, що все вище стосується будь-яких нотацій моделювання. Ви можете застосувати його до діаграм взаємозв'язків сутності, діаграм IDEF , позначень моделювання бізнес-процесів тощо. Незалежно від позначення моделювання, ви можете вибрати, коли ви застосовуватимете його (раніше як специфікацію, після як альтернативне подання) та скільки деталей (повні деталі до основних аспектів).
Інша сторона цього - культура з відкритим кодом.
Часто проекти з відкритим кодом починають вирішувати проблему, з якою стикається окрема особа (або сьогодні компанія). Якщо його запускає особа, кількість розробників становить 1. У цьому випадку накладні комунікації надзвичайно низькі, і немає необхідності повідомляти про вимоги та дизайн. У компанії, швидше за все, буде невеликий колектив. У цьому випадку вам, ймовірно, доведеться повідомити про можливості дизайну та обговорити компроміси. Однак після прийняття дизайнерських рішень вам необхідно або підтримувати свої моделі, оскільки база коду змінюється з часом, або викинути їх. У термінах Agile Modeling "постійно документуйте" і підтримуйте "єдине джерело інформації" .
Як короткий бік, існує думка про те, що код - це дизайн, і що моделі - це лише альтернативні погляди на дизайн. Джек Рівз написав три есе про код як дизайн , і там також обговорюються вікі на C2, обговорюючи ідеї, що вихідним кодом є дизайн , дизайн - вихідний код , вихідний код та моделювання . Якщо ви підписуєтесь на це переконання (що я і роблю), то вихідний код - це реальність, і будь-які діаграми повинні просто існувати, щоб зрозуміти код і, що ще важливіше, обґрунтування того, чому код є тим, що він є.
Успішний проект з відкритим кодом, як і той, про який ви згадуєте, має участь у всьому світі. Ці учасники, як правило, є технічно компетентними в технологіях, що живлять програмне забезпечення, і, ймовірно, також є користувачами програмного забезпечення. Співавтори - це люди, які можуть читати вихідний код так само легко, як і моделі, і можуть використовувати інструменти (IDE та інструменти зворотного проектування) для розуміння коду (включаючи створення моделей, якщо вони відчувають потребу). Вони також можуть створювати ескізи потоку самостійно.
З чотирьох режимів, які описує Фоулер, я не думаю, що ви знайдете проект з відкритим кодом або дуже багато проектів де-небудь, які використовують мови моделювання як мови програмування або креслення. Це залишає нотатки та ескіз як можливе використання для UML. Нотатки будуть створені вкладником для учасника, тому ви, ймовірно, не знайдете їх, завантажених ніде. Ескізи зменшуються в ціні, оскільки код стає більш повним і, ймовірно, не підтримуватиметься, тому що це вимагатиме лише зусиль з боку учасників.
У багатьох проектах з відкритим кодом не доступні моделі, оскільки це не додає вартості. Однак це не означає, що моделі не створили хтось на початку проекту чи люди не створили власні моделі системи. Просто підтримувати одне джерело проектної інформації: вихідний код.
Якщо ви хочете знайти людей, що обмінюються дизайнерською інформацією, я рекомендую переглянути будь-які форуми чи списки розсилки, які використовуються учасниками. Часто ці форуми та списки розсилки служать проектною документацією для проектів. Ви можете не знайти офіційного UML, але ви можете знайти там якесь графічне зображення дизайнерської інформації та моделей. Ви також можете зайти в чати або інші канали зв'язку проекту - якщо ви бачите людей, які говорять про дизайнерські рішення, вони можуть спілкуватися з графічними моделями. Але вони, ймовірно, не стануть частиною сховища, оскільки вони не є цінними, коли вони служать своєму призначенню в цілях.