Сучасні методи і засоби проектування інформаційних систем

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

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

Після побудови контекстних діаграм отриману модель слід перевірити на повноту вихідних даних про об'єкти системи та ізольованість об'єктів (відсутність інформаційних зв'язків з іншими об'єктами).

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

правило балансування - означає, що при деталізації підсистеми або процесу детализирующая діаграма в якості зовнішніх джерел / приймачів даних може мати тільки ті компоненти (підсистеми, процеси, зовнішні сутності, накопичувачі даних), з якими має інформаційний зв'язок деталізіруемая підсистема або процес на батьківській діаграмі;

правило нумерації - означає, що при деталізації процесів повинна підтримуватися їх ієрархічна нумерація. Наприклад, процеси, які деталізують процес з номером 12, отримують номери 12.1, 12.2, 12.3 і т.д.

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

Миниспецификация є кінцевою вершиною ієрархії ДПД. Рішення про завершення деталізації процесу і використанні миниспецификации приймається аналітиком виходячи з наступних критеріїв:

наявності у процесу відносно невеликої кількості вхідних і вихідних потоків даних (2-3 потоку);

можливості опису перетворення даних процесом у вигляді послідовного алгоритму;

виконання процесом єдиною логічного функції перетворення вхідної інформації у вихідну;

можливості опису логіки процесу за допомогою миниспецификации невеликого обсягу (не більше 20-30 рядків).

При побудові ієрархії ДПД переходити до деталізації процесів слід тільки після визначення змісту всіх потоків і накопичувачів даних, що описується за допомогою структур даних. Структури даних конструюються з елементів даних і можуть містити альтернативи, умовні входження і ітерації. Умовне входження означає, що даний компонент може бути відсутнім у структурі. Альтернатива означає, що в структуру може входити один з перерахованих елементів. Ітерація означає входження будь-якого числа елементів у вказаному діапазоні. Для кожного елемента даних може зазначатися його тип (безперервні або дискретні дані). Для безперервних даних може вказуватися одиниця виміру (кг, см і т.п.), діапазон значень, точність представлення та форма фізичного кодування. Для дискретних даних може вказуватися таблиця допустимих значень.

Після побудови закінченої моделі системи її необхідно верифікувати (перевірити на повноту і узгодженість). У повній моделі всі її об'єкти (підсистеми, процеси, потоки даних) повинні бути докладно описані і деталізовані. Виявлені недеталізірованние об'єкти слід деталізувати, повернувшись на попередні кроки розробки. У узгодженої моделі для всіх потоків даних і накопичувачів даних повинне виконуватися правило збереження інформації: всі вступники куди-небудь дані повинні бути лічені, а всі зчитуються дані повинні бути записані. 2.4. Моделювання даних 2.4.1. Case-метод Баркера

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

Найбільш поширеним засобом моделювання даних є діаграми "сутність-зв'язок" (ERD). З їх допомогою визначаються важливі для предметної області об'єкти (сутності), їх властивості (атрибути) і відношення один з одним (зв'язки). ERD безпосередньо використовуються для проектування реляційних баз даних.

Нотація ERD була вперше введена П. Ченом (Chen) і отримала подальший розвиток у роботах Баркера [8]. Метод Баркера буде викладатися на прикладі моделювання діяльності компанії з торгівлі автомобілями. Нижче наведені витримки з інтерв'ю, проведеного з персоналом компанії.

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

Продавець: йому потрібно знати, яку ціну запитувати і яка нижня ціна, за яку можна здійснити операцію. Крім того, йому потрібна основна інформація про машини: рік випуску, марка, модель і т.п.

Адміністратор: його завдання зводиться до складання контрактів, для чого потрібна інформація про покупця, автомашині і продавця, оскільки саме контракти приносять продавцям винагороди за продажі.

Перший крок моделювання - вилучення інформації з інтерв'ю і виділення сутностей.

Сутність (Entity) - реальний або уявний об'єкт, що має істотне значення для аналізованої предметної області, інформація про який підлягає зберіганню (рисунок 2.18).

Рис. 2.18. Графічне зображення сутності

Кожна сутність повинна мати унікальний ідентифікатор. Кожен екземпляр сутності повинен однозначно ідентифікуватися і відрізнятися від всіх інших примірників даного типу сутності. Кожна сутність повинна володіти деякими властивостями:

кожна сутність повинна мати унікальне ім'я, і ​​до одного і того ж імені повинна завжди застосовуватися одна й та ж інтерпретація. Одна і та ж інтерпретація не може застосовуватися до різних імен, якщо тільки вони не є псевдонімами;

сутність володіє одним або декількома атрибутами, які або належать сутності, або успадковуються через зв'язок;

сутність володіє одним або декількома атрибутами, які однозначно ідентифікують кожний примірник сутності;

кожна сутність може мати будь-якою кількістю зв'язків з іншими сутностями моделі.

Звертаючись до наведених вище уривків із інтерв'ю, видно, що сутності, які можуть бути ідентифіковані з головним менеджером - це автомашини і продавці. Продавцю важливі автомашини та пов'язані з їх продажем дані. Для адміністратора важливі покупці, автомашини, продавці і контракти. Виходячи з цього, виділяються 4 сутності (автомашина, продавець, покупець, контракт), які зображуються на діаграмі таким чином (малюнок 2.19).

Рис. 2.19.

Наступним кроком моделювання є ідентифікація зв'язків.

Зв'язок (Relationship) - пойменована асоціація між двома сутностями, значима для розглянутої предметної області. Зв'язок - це асоціація між сутностями, при якій, як правило, кожен примірник однієї сутності, званої батьківської сутністю, асоційований з довільним (у тому числі нульовою) кількістю примірників другий сутності, що називається сутністю-нащадком, а кожен примірник сутності-нащадка асоційований точно з одним примірником сутності-предка. Таким чином, примірник сутності-нащадка може існувати тільки при існуванні сутності батька.

Зв'язки може даватися ім'я, яке виражається граматичним обігом дієслова і поміщається біля лінії зв'язку. Ім'я кожного зв'язку між двома даними сутностями повинно бути унікальним, але імена зв'язків у моделі не зобов'язані бути унікальними. Ім'я зв'язку завжди формується з точки зору батька, так що пропозиція може бути утворене з'єднанням імені сутності-предка, імені зв'язку, виразу ступеня й імені сутності-нащадка.

Наприклад, зв'язок предмету з контрактом може бути виражена таким чином:

продавець може отримати винагороду за 1 або більше контрактів;

контракт має бути ініційований рівно одним продавцем.

Ступінь зв'язку та обов'язковість графічно зображаються такий спосіб (рис. 2.20).

Описавши також зв'язки інших сутностей, отримаємо наступну схему (рисунок 2.22).

Рис. 2.22.

Останнім кроком моделювання є ідентифікація атрибутів.

Атрибут - будь-яка характеристика сутності, значима для розглянутої предметної області і призначена для кваліфікації, ідентифікації, класифікації, кількісної характеристики або вираження стану сутності. Атрибут представляє тип характеристик або властивостей, асоційованих з безліччю реальних або абстрактних об'єктів (людей, місць, подій, станів, ідей, пар предметів і т.д.). Примірник атрибута - це певна характеристика окремого елемента множини. Примірник атрибута визначається типом характеристики і її значенням, званим значенням атрибута. У ER-моделі атрибути асоціюються з конкретними сутностями. Таким чином, примірник сутності повинен володіти єдиним певним значенням для асоційованого атрибута.

Атрибут може бути або обов'язковим, або необов'язковим (малюнок 2.23). Обов'язковість означає, що атрибут не може приймати невизначених значень (null values). Атрибут може бути або описовим (тобто звичайним дескриптором сутності), або входити до складу унікального ідентифікатора (первинного ключа).

Унікальний ідентифікатор - це атрибут або сукупність атрибутів і / або зв'язків, призначена для унікальної ідентифікації кожного примірника даного типу сутності. У разі повної ідентифікації кожний примірник даного типу сутності повністю ідентифікується своїми власними ключовими атрибутами, в іншому випадку в його ідентифікації беруть участь також атрибути іншої сутності-предка (рисунок 2.24).

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

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

З урахуванням наявної інформації доповнимо побудовану раніше діаграму (рисунок 2.25).

Крім перерахованих основних конструкцій модель даних може містити ряд додаткових.

Підтипи і супертіпи: одна сутність є узагальнюючим поняттям для групи подібних сутностей (рисунок 2.26).

Взаємно виключають зв'язку: кожен екземпляр сутності бере участь тільки в одній зв'язку з групи взаємно виключають зв'язків (рисунок 2.27).

Рис. 2.25.

Рекурсивна зв'язок: сутність може бути пов'язана сама з собою (малюнок 2.28).

Неперемещаемие (non-transferrable) зв'язку: примірник сутності не може бути перенесений з одного примірника зв'язку в іншій (рисунок 2.29).

Рис. 2.29. Неперемещаемая зв'язок 2.4.2. Методологія IDEF1

Метод IDEF1, розроблений Т. Ремей (T. Ramey), також заснований на підході П. Чена і дозволяє побудувати модель даних, еквівалентну реляційної моделі в третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створена її нова версія - методологія IDEF1X. IDEF1X розроблена з урахуванням таких вимог, як простота вивчення і можливість автоматизації. IDEF1X-діаграми використовуються поруч поширених CASE-засобів (зокрема, ERwin, Design / IDEF).

Сутність в методології IDEF1X є незалежною від ідентифікаторів або просто незалежною, якщо кожен екземпляр сутності може бути однозначно ідентифікований без визначення його відносин з іншими сутностями. Сутність називається залежною від ідентифікаторів або просто залежною, якщо однозначна ідентифікація примірника суті залежить від його ставлення до іншої сутності (малюнок 2.30).

Рис. 2.30. Сутності

Кожній сутності присвоюється унікальне ім'я та номер, розділяються косою рисою "/" і поміщаються над блоком.

Зв'язок може додатково визначатися за допомогою вказівки ступеня або потужності (кількості примірників сутності-нащадка, яке може існувати для кожного екземпляра сутності-предка). У IDEF1X можуть бути виражені такі потужності зв'язків:

кожен примірник сутності-предка може мати нуль, один або більше пов'язаних з ним примірників сутності-нащадка;

кожен примірник сутності-предка повинен мати не менше одного пов'язаного з нею примірника сутності-нащадка;

кожен примірник сутності-предка повинен мати не більше одного пов'язаного з нею примірника сутності-нащадка;

кожен примірник сутності-предка пов'язаний з деяким фіксованим числом екземплярів сутності-нащадка.

Якщо примірник сутності-нащадка однозначно визначається своїм зв'язком з сутністю-батьком, то зв'язок називається ідентифікуючої, в іншому випадку - неидентифицирующей.

Зв'язок зображується лінією, проведеної між сутністю-батьком і сутністю-нащадком з точкою на кінці лінії у сутності-нащадка. Потужність зв'язку позначається як показано на рис. 2.31 (потужність за замовчуванням - N).

Рис. 2.31. Потужність зв'язку

Идентифицирующая зв'язок між сутністю-батьком і сутністю-нащадком зображується суцільною лінією (рисунок 2.32). Сутність-нащадок в ідентифікує зв'язку є залежною від ідентифікатора сутністю. Сутність-батько в ідентифікує зв'язку може бути як незалежної, так і залежною від ідентифікатора сутністю (це визначається її зв'язками з іншими сутностями).

Рис. 2.32. Идентифицирующая зв'язок

Пунктирна лінія зображує неидентифицирующей зв'язок (малюнок 2.33). Сутність-нащадок в неидентифицирующей зв'язку буде незалежною від ідентифікатора, якщо вона не є також сутністю-нащадком в якій-небудь ідентифікує зв'язку.

Рис. 2.33. Неидентифицирующей зв'язок

Атрибути зображаються у вигляді списку імен усередині блоку сутності. Атрибути, що визначають первинний ключ, розміщуються вгорі списку і відділяються від інших атрибутів горизонтальній рисою (рисунок 2.34).

Рис. 2.34. Атрибути і первинні ключі

Сутності можуть мати також зовнішні ключі (Foreign Key), які можуть використовуватися в якості частини або цілого первинного ключа або неключових атрибута. Зовнішній ключ зображується за допомогою приміщення всередину блоку сутності імен атрибутів, після яких слідують букви FK в дужках (рисунок 2.35).

Рис. 2.35. Приклади зовнішніх ключів 3. Характеристики CASE-засобів 3.1. Silverrun + JAM 3.1.1. Silverrun

CASE-засіб Silverrun американської фірми Сomputer Systems Advisers, Inc. (CSA) використовується для аналізу і проектування ІС бізнес-класу [22] і орієнтоване більшою мірою на спіральну модель ЖЦ. Воно застосовується для підтримки будь-якої методології, заснованої на роздільному побудові функціональної та інформаційної моделей (діаграм потоків даних і діаграм "сутність-зв'язок").