Примітка. Наявність в інструментальних CASE-засобах вбудованої підтримки візуалізації різних діаграм мови UML дозволяє до деякої міри виключити помилкове використання

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

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

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

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

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

Поиск по сайту: