МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів
Контакти
Тлумачний словник Авто Автоматизація Архітектура Астрономія Аудит Біологія Будівництво Бухгалтерія Винахідництво Виробництво Військова справа Генетика Географія Геологія Господарство Держава Дім Екологія Економетрика Економіка Електроніка Журналістика та ЗМІ Зв'язок Іноземні мови Інформатика Історія Комп'ютери Креслення Кулінарія Культура Лексикологія Література Логіка Маркетинг Математика Машинобудування Медицина Менеджмент Метали і Зварювання Механіка Мистецтво Музика Населення Освіта Охорона безпеки життя Охорона Праці Педагогіка Політика Право Програмування Промисловість Психологія Радіо Регилия Соціологія Спорт Стандартизація Технології Торгівля Туризм Фізика Фізіологія Філософія Фінанси Хімія Юриспунденкция |
|
|||||||
Рекомендації по графічному зображенню діаграм мови UMLПри графічному зображенні діаграм слід дотримуватися наступних основних рекомендацій: · Кожна діаграма повинна служити закінченим представленням відповідного фрагмента модельованої наочної області. Йдеться про тому, що в процесі розробки діаграми необхідно врахувати всі єства, важливі з точки зору контексту даної моделі і діаграми. Відсутність тих або інших елементів на діаграмі служить ознакою неповноти моделі і може зажадати її подальшого доопрацювання. · Всі єства на діаграмі моделі мають бути одного рівня вистави. Тут мається на увазі узгодженість не лише імен однакових елементів, але і можливість вкладення окремих діаграм один в одного для досягнення повноти вистав. В разі достатній складних моделей систем бажано дотримуватися стратегії послідовного уточнення або деталізації окремих діаграм. · Вся інформація про єства має бути явно представлена на діаграмах. У мові UML за відсутності деяких символів на діаграмі можуть бути використані їх значення за умовчанням (наприклад, в разі неявної вказівки видимості атрибутів і операцій класів), проте, необхідно прагнути до явної вказівки властивостей всіх елементів діаграм. · Діаграми не повинні містити суперечливої інформації. Суперечність моделі може служити причиною серйозних проблем при її реалізації і подальшому використанні на практиці. Наприклад, наявність замкнутих доріг при зображенні стосунків агрегації або композиції наводить до помилок в програмному коді, який реалізовуватиме відповідні класи. Наявність елементів з однаковими іменами і різними атрибутами властивостей в одному просторі імен також наводить до неоднозначної інтерпретації і може бути джерелом проблем. · Кожна діаграма має бути самодостатньою для правильної інтерпретації всіх її елементів і розуміння семантики всіх використовуваних графічних символів. Будь-які тексти пояснень, які не є власними елементами діаграми (наприклад, коментарями), не повинні братися до уваги розробниками. В той же час загальні фрагменти діаграм можуть уточнюватися або деталізувати на інших діаграмах цього ж типа, утворюючи вкладені або підлеглі діаграми. Таким чином, модель системи на мові UML є пакетом ієрархічно вкладених діаграм, деталізація яких має бути достатньою для подальшої генерації програмної коди, що реалізовує проект відповідної системи. · Кількість типів діаграм для конкретної моделі застосування строго не фіксована. Для простих програмних засобів немає необхідності будувати всіх без виключення типів діаграм. Деякі з них можуть бути просто відсутніми в проекті системи, і це не вважатиметься помилкою розробника. Наприклад, модель системи може не містити діаграму розгортання для застосування, що виконується локально на комп'ютері користувача. Поважно розуміти, що перелік діаграм залежить від специфіки конкретного проекту системи. · Будь-яка модель системи повинна містити лише ті елементи, які визначені в нотації мови UML. Мається на увазі вимога починати розробку проекту, використовуючи лише ті конструкції, які вже визначені в метамоделі UML. Як показує практика, ці конструкцій цілком достатньо для представлення більшості типових проектів програмних систем. І лише за відсутності необхідних базових елементів мови UML слід використовувати механізми їх розширення для адекватного представлення конкретній моделі системи. Не допускається перевизначення семантики тих елементів, які віднесені до базової нотації метамоделі мови UML. На закінчення цієї лекції слід зазначити, що наявність в інструментальних CASE-средствах вбудованої підтримки візуалізації різних діаграм мови UML дозволяє в деякій мірі виключити помилкове використання графічних символів, а також контролювати унікальність імен елементів діаграм. Проте, оскільки вся відповідальність за остаточний контроль несуперечності моделі лежить на розробнику, необхідно пам'ятати, що недостатньо формальний характер мови UML і можливість його розширення може служити джерелом потенційних помилок, які в повному об'ємі навряд чи будуть виявлені інструментальними засобами. Саме ця обставина вимагає від всіх розробників глибокого знання нотації і семантики всіх елементів мови UML.
Читайте також:
|
||||||||
|