5. Рекомендації по графічному зображенню діаграм мови uml

При графічному зображенні діаграм слід дотримуватися наступних основних рекомендацій:

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

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

• Вся інформація про сутності має бути явно представлена на діаграмах. В UML за відсутності деяких символів на діаграмі можуть бути використані їх значення за замовчуванням (наприклад, у випадку неявного вказівки видимості атрибутів і операцій класів), тим не менш, необхідно прагнути до явного вказівки властивостей всіх елементів діаграм.

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

• Кожна діаграма повинна бути самодостатньою для правильної інтерпретації всіх її елементів і розуміння семантики всіх використовуваних графічних символів. Будь пояснювальні тексти, які не є власними елементами діаграми (наприклад, коментарями), не повинні прийматися до уваги розробниками. У той же час загальні фрагменти діаграм можуть уточнюватися або деталізуватися на інших діаграмах цього ж типу, утворюючи вкладені або підлеглі діаграми. Таким чином, модель системи на мові UML являє собою пакет ієрархічно вкладених діаграм, деталізація яких повинна бути достатньою для подальшої генерації програмного коду, що реалізує проект відповідної системи.

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

• Будь-яка модель системи повинна містити тільки ті елементи, які визначені в нотації мови UML. Мається на увазі вимога починати розробку проекту, використовуючи тільки ті конструкції, які вже визначені в метамоделі UML. Як показує практика, цих конструкцій цілком достатньо для представлення більшості типових проектів програмних систем. І лише за відсутності необхідних базових елементів мови UML слід використовувати механізми їх розширення для адекватного представлення конкретної моделі системи. Не допускається перевизначення семантики тих елементів, які віднесені до базової нотації метамоделі мови UML.

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