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

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

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

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

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

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

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

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

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

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Особливості графічного зображення діаграм мови UML	\|	Поняття, види та чинники формування виробничих потужностей підприємства.

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.003 сек.