- •Курс лекцій
- •Видавничих систем”
- •4.2.4. Критерії оцінки і вибору
- •1. Основи методології проектування видавничих систем
- •1.1. Життєвий цикл видавничих систем.
- •1.2. Моделі життєвого циклу вс
- •1.3. Методології й технології проектування вс
- •1.3.1. Загальні вимоги до методології й технології
- •1.3.2. Методологія rad
- •2. Структурний підхід до проектування іс
- •2.1. Сутність структурного підходу
- •2.2. Методологія функціонального моделювання sadt
- •2.2.1. Склад функціональної моделі
- •2.2.2. Ієрархія діаграм
- •2.2.3. Типи зв'язків між функціями
- •2.3. Моделювання потоків даних (процесів)
- •2.3.1. Зовнішня суть
- •2.3.2. Системи і підсистеми
- •2.3.3. Процеси
- •2.3.4. Накопичувачі даних
- •2.3.5. Потоки даних
- •2.3.6. Побудова ієрархії діаграм потоків даних
- •2.4. Моделювання даних
- •2.4.1. Case-метод Баркера
- •2.4.2. Методологія idef1
- •2.4.2. Критерії оцінки і вибору
- •Синтаксично кероване редагування. Можливість введення і редагування початкових кодів на одному або декількох мовах з одночасним синтаксичним контролем.
- •2.4.3. Підхід, використовуваний в case-засобі Vantage Team Builder
- •2.5. Приклад використання структурного підходу
- •2.5.1. Опис предметної області
- •2.5.2. Організація проекту
- •3. Програмні засоби підтримки життєвого циклу по
- •3.1. Методології проектування по як програмні продукти. Методологія datarun і інструментальний засіб se Companіon
- •3.1.1. Методологія datarun
- •3.1.2. Інструментальний засіб se Companіon
- •3.2. Case-засобу. Загальна характеристика і класифікація
- •4. Технологія впровадження case-засобів
- •4.1. Визначення потреб в case-засобах
- •4.1.1. Аналіз можливостей організації
- •4.1.2. Визначення організаційних потреб
- •4.1.3. Аналіз ринку case-засобів
- •4.1.4. Визначення критеріїв успішного впровадження
- •4.1.5. Розробка стратегії впровадження case-засобів
- •4.2. Оцінка і вибір case-засобів
- •4.2.1. Загальні відомості
- •4.2.2. Процес оцінки
- •4.2.3. Процес вибору
- •4.2.4. Критерії оцінки і вибору
- •4.2.4.2. Простота використання
- •4.2.4.3. Ефективність
- •4.2.4.4. Супроводжуваність
- •4.2.4.5. Переносимість
- •4.2.4.6. Загальні критерії
- •4.2.5. Приклад підходу до визначення критеріїв вибору case-засобів
- •4.3. Виконання пілотного проекту
- •4.4. Перехід до практичного використання case-засобів
- •5. Характеристики case-засобів
- •5.4. Локальные средства (eRwin, bPwin, s-Designor, case.Аналитик)
- •5.5. Об'єктно-орієнтовані case-засоби (Rational Rose)
- •5.6. Допоміжні засоби підтримки життєвого циклу по
- •5.6.1. Засоби конфігураційного управління
- •5.6.2. Засоби документування
- •5.6.3. Засоби тестування
- •5.7. Приклади комплексів case-засобів
2.4.3. Підхід, використовуваний в case-засобі Vantage Team Builder
У CASE-засобі Vantage Team Builder (Westmount I-CASE) [14] використовується один з варіантів нотації П. Чена. На ER-діаграмах суть позначається прямокутником, що містить ім'я суті (малюнок 2.36), а зв'язок - ромбом, зв'язаним лінією з кожною з взаємодіючої суті. Числа над лініями означають ступінь зв'язку.
Мал. 2.36. Позначення суті і зв'язків
Зв'язки є багатонаправленими і можуть мати атрибути (за винятком ключових). Виділяють два види зв'язків:
· необов'язковий зв'язок (optional);
· слабкий зв'язок (weak).
У необов'язковому зв'язку (малюнок 2.37) можуть брати участь не всі екземпляри суті.
Мал. 2.37. Необов'язковий зв'язок
На відміну від необов'язкового зв'язку в повному (total) зв'язку беруть участь всі екземпляри хоч би однієї з суті. Це означає, що екземпляри такого зв'язку існують тільки за умови існування екземплярів іншої суті. Повний зв'язок може мати один з 4-х видів: обов'язковий зв'язок, слабкий зв'язок, зв'язок "супертип-підтип" і асоціативний зв'язок.
Обов'язковий (mandatory) зв'язок описує зв'язок між "незалежною" і "залежною" суттю. Всі екземпляри залежної ("обов'язковою") суті можуть існувати тільки за наявності екземплярів незалежної ("необов'язковою") суті, тобто екземпляр "обов'язкової" суті може існувати тільки за умови існування певного екземпляра "необов'язкової" суті.
У прикладі (малюнок 2.38) мається на увазі, що кожен автомобіль має принаймні одного водія, але не кожен службовець управляє машиною.
Мал. 2.38. Обов'язковий зв'язок
У слабкому зв'язку існування однієї з суті, що належить деякій множині ("слабкою") залежить від існування певної суті, що належить іншій множині ("сильною"), тобто екземпляр "слабкої" суті може бути ідентифікований тільки за допомогою екземпляра "сильної" суті. Ключ "сильної" суті є частиною складеного ключа "слабкої" суті.
Слабкий зв'язок завжди є бінарним і обов'язковий зв'язок для "слабкої" суті. Суть може бути "слабкою" в одному зв'язку і "сильною" в іншій, але не може бути "слабкою" більш, ніж в одному зв'язку. Слабкий зв'язок може не мати атрибутів.
Приклад на малюнку 2.39: ключа (номер) рядка в документі може не бути унікальним і повинен бути доповнений ключем документа.
Мал. 2.39. Слабкий зв'язок
Зв'язок "супертип-підтип" зображена на малюнку 2.40. Загальні характеристики (атрибути) типу визначаються в суті-супертипі, суть-підтип успадковує всі характеристики супертипу. Екземпляр підтипу існує тільки за умови існування певного екземпляра супертипу. Підтип не може мати ключа (він імпортує ключ з супертипу). Суть, що є супертипом в одному зв'язку, може бути підтипом в іншому зв'язку. Зв'язок супертипу не може мати атрибутів.
Мал. 2.40. Зв'язок "супертип-підтип"
У асоціативному зв'язку кожен екземпляр зв'язку (асоціативний об'єкт) може існувати тільки за умови існування певних екземплярів кожній з взаємозв'язаної суті. Асоціативний об'єкт - об'єкт, що є одночасно суттю і зв'язком. Асоціативний зв'язок - це зв'язок між декількома "незалежною" суттю і однією "залежною" суттю. Зв'язок між незалежною суттю має атрибути, які визначаються в залежній суті. Таким чином, залежна суть визначається в термінах атрибутів зв'язку між рештою суті.
У прикладі на малюнку 2.41 літак виконує посадку на злітну смугу в заданий час при певній швидкості і напрямі вітру. Оскільки ці характеристики застосовні тільки до конкретної посадки, вони є атрибутами посадки, а не літака або злітної смуги. Пілот, що виконує посадку, пов'язаний набагато сильнішим з конкретною посадкою, чим з літаком або злітною смугою.
Мал. 2.41. Асоціативний зв'язок
Первинний ключ кожного типу суті позначається зірочкою (*).
ER-діаграма повинна підкорятися наступним правилам:
кожна суть, кожен атрибут і кожен зв'язок повинні мати ім'я (зв'язок супертипа або асоціативний зв'язок може не мати імені);
ім'я суті повинне бути унікальне в рамках моделі даних;
ім'я атрибуту повинне бути унікальне в рамках суті;
ім'я зв'язку повинне бути унікальне, якщо для неї генерується таблиця БД;
кожен атрибут повинен мати визначення типу даних;
суть в необов'язковому зв'язку повинна мати ключовий атрибут. Те ж саме відноситься до сильної суті в слабкому зв'язку, супертипу в зв'язку "супертип-підтип" і необов'язковій суті в обов'язковому (повною) зв'язку;
підтип в зв'язку "супертип-підтип" не може мати ключового атрибуту;
у асоціативному або слабкому зв'язку може бути тільки одна асоціативна (слабка) суть;
зв'язок не може бути одночасний обов'язковою, "супертип-підтип" або асоціативною.