Використання елементів UML в RUP
| Представлення | Елементи |
| Варанти | Актори Варіанти використання Асоціації Діаграми варіантів використання Діаграми послідовності Діаграми кооперацій Пакети |
Продовж. табл. 3.1
| Логічне | Класи Діаграми класів Асоціації Діаграми дій Діаграми станів Пакети |
| Компонентів | Компоненти Діаграми компонентів Пакети |
| Розміщення | Процеси Процесори Пристрої Діаграми розміщення |
Таким чином, можливості моделювання ІС в RUP повністю визначаються можливостями UML.
Однак більшість сучасних методологій проектування носять “процесний” характер і не орієнтовані на використання якоїсь визначеної мови моделювання. Це стосується, в першу чергу, гнучких (Agile) методологій – SCRUM, eXtreme Programming (XP), Crystal, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development Method (DSDM) та ін. Тобто в них специфікують процеси, що відбуваються при розробці, вимоги до команди розробників, але не вказуються мови і засоби моделювання, як це робиться, наприклад, в RUP. Одна і та ж методологія може використовувати різні інструменти залежно від досвіду та компетенції команди розробників.
Появу компонентного підходу до проектування розглядають як розвиток об’єктного підходу для проектування великих розподілених систем.
Компонентна розробка ПЗ (Component Based Development – CBD) – це спосіб розробки, при якому можливе повторне використання раніше створених компонентів за умови, що вони розроблялися з цією можливістю повторного використання.
До плюсів повторного використання ПЗ відноситься: підвищення надійності; зменшення проектних ризиків; ефективне використання фахівців; дотримання стандартів; прискорення розробки.
У той же час виникають проблеми підвищення вартості супроводу системи, пошуку і адаптації компонентів та ін.
Під компонентом, зазвичай, розуміють незалежний модуль програмного коду, призначений для повторного використання і розгортання.
Компоненти відрізняються також від класів об’єктно-орієнтованих мов за цілим рядом характеристик:
· компонент є більшою структурною одиницею, ніж клас. Реалізація компонента часто складається з декількох тісно взаємопов'язаних класів;
· компонент, зазвичай, не прив'язаний до певної мови програмування.
У той же час поняття “компонент” відмінне від традиційного поняття “програмний модуль”, оскільки компонент є самостійною атомарною для розгортування програмною одиницею, яка може поставлятися чи видалятися окремо від всієї іншої системи, тоді як програмний модуль має чітко описаний інтерфейс з оточенням.
Набір правил визначення інтерфейсів компонентів та їхніх реалізацій, а також правил, за якими компоненти працюють у системі і взаємодіють один з одним, прийнято поєднувати під назвою “компонентної моделі” (component model).
Існує декілька компонентних моделей від різних розробників, серед найбільш відомих:
· COM (Component Object Model), COM+ від Mіcrosoft;
· EJB (Enterprise Java-Beans) від Sun Mіcrosystems;
· ССM (CORBA Component Model) від OMG.
Компонентна модель COM визначає протокол для створення і використання компонентів як усередині одного процесу, так і між різними процесами або комп'ютерами. Додатки для COM-моделі можуть створюватися засобами таких мов і середовищ розробки, як Vіsual Basіc, C++, .NET та ін., однак орієнтовані на ОС від Mіcrosoft. Тоді як JavaBeans не має властивості незалежності від мови програмування, проте підтримує різні платформи. CORBA ж відрізняється досить громіздким IDL-интерфейсом і як результат – складністю відображення однієї мови в іншу.
Застосування компонентного програмування покликане забезпечити більш просту і швидку розробку прикладного ПЗ на основі використання готових модулів-компонентів. Повторне застосування компонентів, дозволяє істотно скоротити витрати і терміни розробки ПЗ.
Найбільшою мірою орієнтованими на компонентну розробку є гнучкі методології та методології Microsoft Solutions Framework (MSF) – MSF for Agile Software Development та MSF for CMMI Process Improvement.
MSF рекомендує якнайчастіше збирати поточні версії всіх компонентів рішення для проведення тестування й аналізування. Цей підхід застосовується як до розробки програмного коду, так і до створення компонентів апаратного і ПЗ.
Модель проектної групи MSF (Microsoft Solutions Framework Team Model) описує підхід Майкрософта до організації працюючого над проектом персоналу і його діяльності в цілях максимізації успішності проекту. Дана модель визначає ролеві кластери, їх сфери компетенції і зони відповідальності, а також рекомендації членам проектної групи, що дозволяють їм успішно здійснювати свою місію по втіленню проекту в життя.
MSF і MOF пропонують перевірені роками рекомендації й методики по ефективному плануванню, розробці, впровадженню і супроводу бизнес‑рішень. Вони дозволяють максимізувати успішність і ефективність IT-проектів впродовж всього ЖЦ ІТ. У основу пропонованих концепцій покладено великий досвід, одержаний Майкрософт при здійсненні великих проектів у сфері ПЗ, досвід консультантів майкрософту, а також кращі з методик, напрацьовані світовою IT-індустрією.
Рішення бізнесу повинні створюватися з урахуванням поставлених термінів і в рамках відведеного бюджету. Цього легше добитися, застосовуючи підхід, що затвердений, перевірений. MSF пропонує перевірені методики для планування, створення і впровадження успішних рішень в IT-індустрії. Він не містить жорстких інструкцій; натомість пропонується гнучкий і масштабований підхід, здатний задовольнити потреби організації або проектної групи будь-якого розміру. Рекомендації MSF складаються із застосовних для більшості проектів принципів, моделей і дисциплін по управлінню розробниками, процесами і технологічними елементами.
MOF пропонує рекомендації, що допомагають забезпечити надійність (reliability), доступність (availability), зручність в супроводі (supportability) і керованість (manageability) IT-рішень, побудованих на базі продуктів і технологій Майкрософта. Принципи, моделі і дисципліни MOF піднімають кадрові, технологічні і технічні питання, що відносяться до управління складними (complex), розподіленими (distributed), різнорідними (heterogeneous) IT-системами.
Модель проектної групи MSF розроблялася протягом декількох років і виникла в результаті осмислення недоліків пірамідальної, ієрархічної структури традиційних проектних груп.
Відповідно до моделі MSF проектні групи будуються як невеликі багатопрофільні команди, члени яких розподіляють між собою відповідальність і доповнюють сфери компетенцій один одного. Це дозволяє чітко сфокусувати увагу на потребах проекту.
MSF включає ряд основних принципів. У цьому розділі говориться про тих з них, які мають відношення до успішної роботи команди.
Модель проектної групи MSF грунтується на твердженні про рівноправність ролей в команді. Кожен ролевий кластер представляє унікальну точку зору на проект, і в той же час ніхто не не в змозі успішно представляти всі можливі погляди, що відображають якісно різні цілі. Для дозволу цієї дилеми команда соратників (команда рівних, team of peers), що працює над проектом, повинна мати чітку форму звітності перед зацікавленими сторонами (stakeholders) при розподіленій відповідальності за досягнення загального успіху.
В рамках проектної групи кожен ролевий кластер звітує перед всією командою (як і перед всією організацією) про досягнення своєї мети. Кажучи інакше, кожен ролевий кластер звітує за свій внесок в остаточний результат. Відповідальність розподіляється серед членів команди, взаємозалежних з двох причин: по-перше, діяльність кожного з ролевих кластерів не може бути ізольована від роботи інших; по-друге, команда ефективніша, якщо кожному її члену зрозуміла повна картина того, що відбувається. Цей взаємозв'язок диктує необхідність для всіх членів команди висловлювати свою думку і вносити певний внесок в рішення питань, які лежать поза сферою їх звітності, забезпечуючи повноцінне використання всього спектру знань, компетенції й досвіду команди. Всі члени команди відповідають за успіх проекту; вони розділяють честь і славу у разі позитивного результату і повинні удосконалювати свій професійний рівень, працюючи над уроками менш вдалих проектів.
MSF відстоює необхідність вироблення єдиного бачення (shared vision) проекту, що формує цілісний підхід проектної групи до розробки IT-рішення.
Необхідно чітко розуміти цілі та завдання проекту або процесу, оскільки це основа всіх допущень про функціонування рішення в рамках організації-замовника. Це відноситься до сприйняття рішення як проектною групою, так і самим замовником. Загальне бачення чітко обкреслює зроблені припущення і забезпечує єдність мети всіх зацікавлених сторін. Це одна з основ моделі проектної групи MSF. Коли всі учасники проекту розуміють це і виробляють єдине бачення, вони набувають можливості погоджувати свої дії із загальною командною метою.
Не маючи такого бачення, члени проектної групи можуть керуватися поглядами, що суперечать один одному, на мету проекту, що значно утруднить роботу команди як єдиного цілого. І навіть у разі успіху члени команди навряд чи зможуть оцінити свій внесок, оскільки ця оцінка залежить від прийнятої точки зору.
Концепція “команди соратників” (teem of peers) означає рівноправне становлення кожної з ролей в команді. Це сприяє вільному спілкуванню, збільшує командну відповідальність і зумовлює рівну важливість кожної з шести якісних цілей. Щоб досягти успіху в рамках команди соратників (команди рівних), кожний з її членів, незалежно від ролі, повинен нести відповідальність за якість продукту, розуміти інтереси замовника і суть вирішуваного завдання бізнесу.
Хоча соратники рівні, ухвалення рішення методом консенсусу між ролями не тотожно ухваленню рішення методом консенсусу між співробітниками. Кожен ролевий кластер вимагає певної внутрішньої організаційної ієрархії для розподілу роботи і управління його ресурсами. Керівники ролевих кластерів відповідальні за організацію роботи, управління і координацію дій команди, тоді як її члени мають можливість зосередитися на своїх індивідуальних завданнях.
Малі багатопрофільні команди (small, multidisciplinary teams) мають ряд безперечних переваг. Одна з них – велика оперативність дій порівняно з крупними колективами. Тому при роботі над великими проектами краще створювати команди команд – набір малих груп, працюючих паралельно. При цьому працівники, що є експертами в певних областях або мають специфічні функції, одержують повноваження діяти в рамках своїх сфер компетенції.
Усередині проектної групи – і навіть усередині окремого ролевого кластера – існують завдання, що вимагають різних професійних навиків. Всі члени команди або ролевого кластера різні, що мають освіту, досвід і спеціалізацію, вносять свій унікальний внесок в роботу колективу і, у результаті, в створення кінцевого продукту.
Одна з цілей моделі проектної групи – зменшення витрат взаємодії. Як наслідок, команди мають менше перешкод для ефективного обміну інформацією. Крім структури організації, важливу роль в ефективності її внутрішніх і зовнішніх інформаційних потоків грає просторова близькість співробітників. Проте, хоча ідеальним вибором є зближення робочих місць, вимоги бізнесу і сучасні технологічні нововведення в комунікаціях роблять можливим створення успішних “віртуальних” команд.
Віртуальні команди – це команди, що взаємодіють і спілкуються головним чином за допомогою електронних комунікацій. Обмін інформацією в них йде через кордони країн і організацій, простір і час. Зв'язок з колегами через Internet в режимі реального часу корінним чином міняє принципи роботи і обміну інформацією. Internet стає для членів команди новим комунікаційним стандартом, і ПЗ, що робить можливою віддалену колективну роботу, відкриває шлях до подальшого підвищення продуктивності в нових умовах.
Для віртуальних команд модель проектної групи MSF є ключовою. Без належного рівня організації, об'єднуючого всі робочі ролі в єдине ціле, віддаленість працівників зажадала б ще більшої кількості дискусій, договорів і взаємозв'язків, жорсткішого планування і додаткових інструментів моніторингу проекту для забезпечення злагодженості роботи.
Життєво важлива складова віртуальної команди – це упевненість кожного її члена в можливості покластися на інших, що досягається виробленням загальної корпоративної культури, невпинною управлінською роботою і, як тільки це стає можливим, – перенесенням роботи в одне місце.
MSF заснований на постулаті про шість якісних цілей, досягнення яких визначає успішність проекту. Ці цілі обумовлюють модель проектної групи. Тоді як за успіх проекту відповідальна вся команда, кожний з її ролевих кластерів, визначуваних моделлю, асоційований з однією із згаданих шести цілей і працює над її досягненням.
Шість ролевих кластерів моделі проектної групи – це “Управління продуктом” (Менеджер продукту – product management), “Управління програмою” (Менеджер програми – program management), “Розробка” (Розробник – development), “Тестування” (Тестер – test), “Задоволення споживача” (Інструктор – user experience) і “Управління випуском” (Логистік – release management). Вони відповідальні за різні сфери компетенції (functional areas) і пов'язані з ними цілі і завдання. Іноді ролеві кластери називають просто ролями. Але у будь-якому разі суть концепції залишається тією ж – побудувати основу виробничих відносин і пов'язану з нею модель команди такими, щоб вони були пристосовуваними (масштабованими) для задоволення потреб будь-якого проекту. Одна роль (або один кластер) може бути представлена одним або декількома співробітниками, залежно від розміру проекту, його складності й професійних навиків, потрібних для реалізації всіх сфер компетенції кластера.
Модель проектної групи MSF підкреслює важливість побудови ролевих кластерів відповідно до потреб бізнесу. Угрупування зв'язаних областей компетенції, кожна з яких має свою специфіку, забезпечує хорошу збалансованість команди. Чітке визначення цілей підвищує рівень відповідальності та сприяє кращому їх сприйняттю проектною командою, що негайно позначається найкращим чином на якості випущеного продукту. Оскільки кожна з цілей однаково необхідна для успішності проекту, всі ролі знаходяться в рівноправних партнерських взаємовідношеннях з рівною значущістю при ухваленні рішень.
Використання ролевих кластерів не має на увазі і не нав'язує ніякої спеціальної структури організації або обов'язкових посад. Адміністративний склад ролей може широко варіюватися в різних організаціях і проектних групах. Найчастіше ролі розподіляються серед різних підрозділів однієї організації, але іноді частина їх відводиться співтовариству споживачів або зовнішнім відносно до організації консультантам і партнерам. Ключовим є чітке визначення працівників, відповідальних за кожен ролевий кластер, їх функцій, відповідальність й очікуваного внеску в кінцевий результат. Приведений на рис. 3.8 приклад не визначає вимог до організації груп напрямку. Наприклад, не всі групи напрямку повинні включати роль “Задоволення споживача”; вони повинні бути організовані відповідно до покладених на них завдань.
Рис. 3.8. Ролеві кластери моделі проектної групи MSF
Модель проектної групи MSF не забезпечує успіх сама по собі. Є багато інших чинників, що визначають успіх або невдачу проекту, але структура проектної групи, безумовно, вносить істотний внесок.
Навіть за наявності компетентних зацікавлених і працелюбних людей невірна структура команди здатна звести нанівець їх зусилля, замість того щоб привести їх до успіху. Погана структура команди може послужити причиною збільшення часу розробки, зниження якості, пониження морального духу, підвищення текучості кадрів і, зрештою, привести до відміни проекту.
Успішний проект завжди має хороший старт, який звичайно включає формування технічного завдання на проектування, початковий вибір створюваних моделей, організацію групи аналітиків, вибір Комітету технічного контролю і складання графіка робіт. Такий початок приводить до створення плану проекту, який координує зусилля багатьох людей і робить проект керованим.
Технічне завдання виробляється на найпершому етапі проекту (іноді технічне завдання називають концепцією проекту). У технічному завданні визначаються призначення, сфера, обмеження, очікувані результати і переваги проекту. Технічне завдання може також включати нарис плану проекту, який допомагає документувати попередні пропозиції організаторів і керівників проекту. Звичайно на цьому етапі зайняті невеликі колективи. Проте якщо проект дуже малий, він може бути ініційований одним автором.
Основні пункти роботи – які створювати моделі і в які терміни – плануються після формування технічного завдання. Це допомагає визначити найбільш важливі об'єкти, прояснити цілі проекту і розробити його детальний план. Перш ніж визначити основні пункти роботи, варто з'ясувати, що відомо з даної проблеми, яку нову інформацію треба зібрати і які джерела її доступні для проекту. Може бути навіть побудувати декілька невеликих SADT-моделей, щоб одержати ці відомості. Наприклад, часто будують модель самого проекту за допомогою SADT, щоб визначити, які моделі створюватимуться (поточні операції, майбутні операції, план перетворень, архітектура системи). План, заснований на такій інформації, швидше приведе до створення точних і корисних моделей.
Вірно вибрані основні пункти роботи служать базою правильного підбору колективу фахівців. Варто визначити число експертів, авторів, читачів і допоміжний персонал (бібліотекар, діловоди і технічні оформлювачі) для отримання необхідних результатів (уявлення про необхідний обсяг робіт дають огляди проектів в частині VI.), а також хто увійде до Комітету технічного контролю. Ці особи повинні відповідати за вирішення конфліктів (рис. 3.9).
Рис. 3.9. Групи напрямів
Design/IDEF дає також можливість створювати інформаційні моделі, які представляють як власні дані, так і зв'язки між ними в системі.
Інформація, що міститься в IDEF-моделях, експортується в будь-яку БД, а самі моделі можуть бути експортовані в Design/CPN – пакет динамічного моделювання і аналізування складних систем.
IDEF – cімейство стандартів обстеження організацій і проектування ІС.
Історично першим в 1981 р. був розроблений стандарт IDEF0 в рамках програми автоматизації промислових підприємств, позначений ICAM (Integrated Computer Aided Manufacturing). Методологія IDEF0 є наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Teqnique), яка була запропонована департаментом Військово-Повітряних Сил США. Власне сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF=ICAM DEFinition). В процесі практичної реалізації учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізування процесів взаємодії в промислових системах. При цьому, окрім вдосконаленого набору функцій для опису процесів бізнесу, однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках “аналітик-фахівець”. Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, з безпосередньою участю всіх аналітиків і фахівців, зайнятих в рамках проекту.
В результаті пошуку відповідних рішень народилася методологія функціонального моделювання IDEF0. З 1981 р. стандарт IDEF0 зазнав декілька незначних зміни, в основному обмежувального характеру, і остання його редакція була випущена в грудні 1993 р. Національним Інститутом По Стандарам і Технологіях США (NIST).
Наприкінці 90-х років XX ст., коли на пострадянському ринку в належній мірі з'явилася конкуренція і рентабельність діяльності підприємств стала різко падати, керівники відчули величезні складнощі при спробах оптимізувати витрати, щоб продукція залишалася одночасно і прибуткової, і конкурентоздатної. Якраз у цей момент абсолютно чітко виявилася необхідність мати модель діяльності підприємства, яка відображала б всі механізми і принципи взаємозв'язку різних підсистем в рамках одного бізнесу.
Саме ж поняття “моделювання процесів” бізнесу прийшло в побут більшості аналітиків одночасно з появою на ринку складних програмних продуктів, призначених для комплексної автоматизації управління підприємством. Подібні системи завжди мають на увазі проведення глибокого передпроектного обстеження діяльності компанії. Результатом цього обстеження є експертний висновок, в якому окремими пунктами виносяться рекомендації по усуненню “вузьких місць” в управлінні діяльністю. На підставі цього висновку, безпосередньо перед проектом впровадження системи автоматизації, проводиться так звана “реорганізація процесів бізнесу”, іноді достатньо серйозна і хвороблива для компанії. Це і природно, колектив, складений роками, завжди складно примусити “думати по-новому”. Подібні комплексні обстеження підприємств завжди є складними і такими, що істотно відрізняються час від часу завданнями. Для вирішення подібних завдань моделювання складних систем існують добре обкатані методології і стандарти. До таких стандартів відносяться методології сімейства IDEF. З їх допомогою можна ефективно відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначаються самим розробником, що дозволяє не перенавантажувати створювану модель зайвими даними.
В теперішній час до сімейства IDEF можна віднести наступні стандарти:
· IDEF0 – Function Modeling – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, предстає перед розробниками і аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків – в термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи;
· IDEF1 – Information Modeling – методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати і аналізувати їх структуру і взаємозв'язки;
· IDEF1X (IDEF1 Extended) – Data Modeling – методологія побудови реляційних структур. IDEF1X відноситься до типу методологій “Суть-взаємозв'язок (ER – Entity-Relationship)” і, як правило, використовується для моделювання реляційних БД, що мають відношення до даної системи;
· IDEF2 - Simulation Modeling – методологія динамічного моделювання розвитку систем. У зв'язку з вельми серйозними складнощами аналізування динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на самому початковому етапі. Проте в даний час присутні алгоритми та їх комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 у динамічні моделі, побудовані на базі “розфарбованих мереж Петрі” (CPN – Color Petri Nets);
· IDEF3 – Process Description Capture – методологія документування процесів, що відбуваються в системі, яка використовується, наприклад, при дослідженні технологічних процесів на підприємствах. З допомогою IDEF3 описуються сценарій і послідовність операцій для кожного процесу. IDEF3 має прямий взаємозв'язок з методологією IDEF0 – кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;
· IDEF4 – Object-oriented Design – методологія побудови об'єктно-орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру об'єктів і закладені принципи їх взаємодії, тим самим дозволяючи аналізувати і оптимізувати складні об'єктно-орієнтовані системи;
· IDEF5 – Ontology Description Capture – методологія онтологічного дослідження складних систем. За допомогою методології IDEF5 онтологія системи може бути описана за допомогою певного словника термінів і правил, на підставі яких можуть бути сформовані достовірні твердження про стан даної системи в деякий момент часу. На основі цих тверджень формуються висновки про подальший розвиток системи і проводиться її оптимізація;
· IDEF6 - Design Rationale Capture;
· IDEF7 - Information System Audit Method;
· IDEF8 - User Interface Modeling;
· IDEF9 - Scenario-driven Info Sys Design Spec;
· IDEF10 - Implementation Architecture Modeling;
· IDEF11 - Information Artifact Modeling;
· IDEF12 - Organization Modeling;
· IDEF13 - Three Schema Mapping Design;
· IDEF14 - Network Design.
Як CASE-пакет по розробці ПЗ Design/IDEF підтримує перші стадії створення програмного продукту:
· формулювання вимог і цілей проекту – визначення того, що проектована система робитиме;
· розробка специфікацій – формалізований опис вимог;
· створення проекту – визначення підсистем і взаємодій між ними;
· документування проекту – створення БД проекту, текстуальний опис складових проекту;
· аналізування проекту – перевірка проекту на повноту і несуперечність.
Результатом роботи пакета Design/IDEF є проект програмної системи, що складається з двох частин:
· проекту функціональної структури системи, що містить ієрархічно зв'язані сторінки з IDEFO-діаграмами і що описує всі модулі (аж до елементарних функцій) системи, їх взаємозв'язки, вхідні і вихідні параметри;
· проекту інформаційної структури системи – логічної моделі її БД, що описує всі структури і взаємозв'язки даних.
Обидва проекти перевіряються на повноту і несуперечність, супроводжуються БД проекту і документацією.
Design/IDEF працює в різних операційних середовищах: можна будувати моделі на IBM PC під MS-Windows, Macintosh або під Unix X Window System і переносити діаграми з одного операційного середовища в інше.
Основні елементи і поняття IDEF0
Графічна мова IDEF0 проста і гармонійна. В основу методології покладено чотири основних поняття.
Першим з них є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображається у вигляді прямокутника і втілює собою деяку конкретну функцію в рамках даної системи. На вимоги стандарту назва кожного функціонального блоку повинна бути сформульована в дієслівному нахилі (наприклад, “проводити послуги”, а не “виробництво послуг”).
Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:
верхня сторона має значення “Управління” (Control);
ліва сторона має значення “Вхід” (Input);
права сторона має значення “Вихід” (Output);
нижня сторона має значення “Механізм” (Mechanism).
Кожен функціональний блок в рамках єдиної даної системи повинен мати свій унікальний ідентифікаційний номер.
Обов'язкова наявність інтерфейсних дуг, що управляють, є однією з головних відмінностей стандарту IDEF0 від інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).
Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розбитті складного процесу на складові його функції. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі.
Декомпозиція дозволяє поступово і структуровано представляти модель системи у вигляді ієрархічної структури окремих діаграм, що робить її менш переобтяженою і легко засвоюваною.
Модель IDEF0 завжди починається з представлення системи як єдиного цілого – одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстною діаграмою і позначається ідентифікатором “А-0”.
У тексті пояснення до контекстної діаграми повинна бути вказана мета (Purpose) побудови діаграми у вигляді короткого опису і зафіксована точка зору (Viewpoint).
Визначення і формалізація мети розробки IDEF0 – моделі є украй важливим моментом. Фактично мета визначає відповідні сфери в досліджуваній системі, на яких необхідно фокусуватися в першу чергу. Наприклад, якщо ми моделюємо діяльність підприємства з метою побудови надалі на базі цієї моделі інформаційної системи, то ця модель буде істотно відрізнятися від тієї, яку б розробляли для того ж самого підприємства, але вже з метою оптимізації логістичних ланцюжків.
В середовище Visual Studio Team System інтегруються шаблони процесів залежно від того, яка процесна методологія розробки обрана для проекту, – якийсь з варіантів гнучкої (Agile) розробки, SCRUM, EUP, FDD чи CMMI. В Visual Studio Team System можуть використовуватися також візуальні конструктори с багатими можливостями для моделювання.
Так, на рівні платформ програмування компонентність підтримується досить широко. Але на рівні засобів візуального моделювання, призначених для аналізування і проектування таких систем, компонентність підтримується слабко і неповно.
При компонентній розробці деякими авторами пропонується спиратися на моделювання на основі UML. При цьому у UML компонент ототожнюється з класом або елементом фізичної структури ПЗ. Досліджено також можливості використання інших методів графічного моделювання при компонентній розробці ПЗ – зокрема, мови SDL (Specification and Description Language), моделей методології ROOM та ін.
Варто відмітити, що досить часто при проектуванні систем з використанням компонентних технологій взагалі не передбачається графічне моделювання, і розробники спираються лише на документування коду.
Так, компонентна розробка в рамках COM передбачає використання ієрархії класів MFC – узгодження префіксів імен класів, інтерфейсів при кодуванні.
Таким чином, на прикладі компонентної розробки можна константувати, як графічне моделювання може бути витіснене за рахунок представлення у доступній формі семантики взаємозв’язків між елементами системи.
Взагалі, поява компонентної розробки ПЗ висунула нові вимоги до моделювання систем, і застосування існуючих мов візуального моделювання виявилось занадто громіздким і сповільнюючим процеси.
Як структурне програмування обумовило появу структурних методів моделювання систем, об’єктно-орієнтоване програмування – появу об’єктно-орієнтованого підходу до проектування та об’єктно-орієнтованих мов візуального моделювання, так і компонентна розробка ПЗ вимагає іншого погляду на процеси моделювання систем.
Тому ряд колективів розробляють мови моделювання, орієнтовані на моделювання саме компонентних архітектур. Серед них Platform-Independent Component Modeling Language (PICML), а також Cadena, розроблена Kansas State University (KSU), та ін.
Cadena забезпечує каркас моделювання компонентів та перевірки моделей формальними методами (яка відсутня в PІCML). Проте, на відміну від PІCML, Cadena не підтримує об’єднання компонентів в пакети, генерацію описів розгортання та планування розгортання, ієрархічне моделювання компонентних збірок.
Необхідно також відмітити, що початкові ідеї компонентного підходу щодо поширення бібліотек компонентів та формування на їх основі програм не набули глобального розмаху в зв’язку з конкуренцією розробників компонентних моделей.
Розвитком компонентного підходу для веб-розробки можна вважати технологію веб-сервісів.
Ідеї, висловлені консорціумом OMG (Object Managemant Group) в концепції MDA (Model Driven Architecture – загальна архітектура модель-орієнтованої розробки ІС), були направлені на те, щоб об’єднати в рамках єдиної архітектури ті можливості автоматизації процесів побудови ІС, які існують на теперішній час.
Для підкреслення рівня даної концепції, варто зазначити, що OMG об’єднує на сьогодні більше 900 членів, включаючи основних виробників обчислювальної техніки і ПЗ (ІBM, Netscape, Hewlett-Packard, Phіlіps Telecommunіcatіons N.V., Oracle, Sun Mіcrosystems, 3Com Corporatіon, Amerіcan Aіrlіnes, Canon, Іnc., Data General, Unіsys Corporatіon та ін.) та займається розробкою, розповсюдженням і супроводженням специфікацій, орієнтованих на забезпечення витривалості, повторного використання та інтероперабельності бізнес-додатків.
Як головний постулат даної архітектури можна прийняти твердження про те, що основою сучасного методу проектування має бути деяка модель, яка дозволяла б описувати ІС та використовувалась при розробці нових версій систем чи при розробці аналогічних ІС. Практично, MDA є методом використання моделей при розробці ІС.
Основним сподіванням при розробці концепції MDA було забезпечення визначення машинопрочитуваних додатків та моделей даних, що будуть гнучкими у довготривалій перспективі при:
· реалізації ІС (за рахунок нової інфраструктури реалізації, що може бути інтегрована з існуючими проектами);
· інтеграції ІС (за рахунок існування при інтеграції не лише розробки, але й її проекту, може бути автоматизоване створення мостів для інтеграції даних та зв’язків з новими інфраструктурами);
· експлуатації ІС (оскільки розробники матимуть доступ до специфікацій проекту – спрощуються процеси експлуатації);
· тестуванні та моделюванні (оскільки моделі використовуються, для генерування коду, вони можуть бути перевірені на предмет задоволення вимог, протестовані на різних інфраструктурах та використані для моделювання поведінки системи).
· Архітектура виділяє методи та інструментальні засоби, які необхідно використовувати для: визначення системи незалежно від платформи; визначення платформ; вибору конкретної платформи для системи та перетворення специфікації системи під цю платформу.
Концепцією чітко виділяється ряд моделей, їх зв’язок та використання.
Так, перша модель, названа CIM (Computation Independent Model – обчислювально незалежна модель) або доменною моделлю чи словником, не описує деталі структури системи, а містить відображення вимог до системи, ситуації, в яких система використовується, сформульовані експертами і, таким чином, дозволяє їм оперувати загальними поняттями. Для побудови такої моделі відповідно із специфікаціями можуть бути використані декілька UML-моделей двох типів: моделі з інформаційної точки зору та моделі з точки зору підприємства.
Другий тип моделі, передбачена MDA, – PIM (Platform Independent Model – платформо-незалежна модель) має описувати ІС незалежно від платформи (тобто без деталей її застосування на певній платформі) для того, щоб мати можливість використовувати цю модель із цілим рядом аналогічних платформ. Під платформами тут розуміється набір підсистем чи технологій, які забезпечують певну функціональність через інтерфейси (наприклад: CORBA, J2EE, Microsoft .NET та ін.). Дана модель може складатися із ряду специфікацій моделей – з інформаційної точки зору, з точки зору підприємства, з обчислювальної точки зору. В модель закладається лише бізнес-логіка, сценарії використання, функціональні вимоги й інша інформація про взаємодію системи з користувачем і про бажане поводження системи. При використанні MDA рекомендується доводити платформо-незалежну модель за досить високим ступенем деталізації, аж до використання високорівневої платформо-незалежної мови програмування для опису функціональності і створення виконуваної моделі. Однак деталі практичної реалізації не повинні бути присутніми у платформо-незалежній моделі.
Відображення одного типу моделей в іншій передбачає специфікацію перетворень будь-яких моделей, побудованих із використанням деякої мови для PIM у моделі деякою мовою для PSM.
Є різні можливості для відображення моделей, зокрема використання:
· так званих “маркерів” (концептів відображення, в якості як елементів MOF-моделі чи інших метамоделей, типів, ролей та стереотипів з моделей);
· метамоделей, заданих у певному форматі (наприклад MOF);
· патернів-шаблонів відображення (що можуть включати певний набір маркерів).
Взагалі, ідеологію MDA можна зобразити у вигляді декількох рівнів (рис. 3.10). На самому верхньому рівні використовуються основні стандарти – UML, MOF XMI, за допомогою яких будуються метамоделі і моделі систем та встановлюються правила обміну даними. Перетворення в моделі PSM здійснюється з допомогою розроблених OMG стандартних відображень, різних для кожної платформи проміжного шару, – UML-профілів. Завдяки тому, що перетворення PІМ в PSM стандартизоване, можуть бути створені інструменти-аналізатори й генератори опису моделей, що істотно спрощують і автоматизують це перетворення. Далі описуються компонентні моделі, які складаються з інфраструктури розподілених об'єктів, підтримки транзакцій, механізмів подій, служби імен і служби підтримки довготривало існуючих об'єктів. І нарешті, застовуються галузеві стандарти, типові моделі ПрО.
Розробниками MDA велика увага приділена стандартизації сервісів і інтерфейсів. Передбачено значну кількість описів сервісів, як стандартних, тобто загальних для будь-якої сфери програмування, так і специфічних для певної сфери (компонентні розподілені системи, додатки реального часу, бізнес-додатки й т.д.). Стандартні сервіси й інтерфейси спрощують клієнтські додатки й виконують інтеграцію нових компонентів у середовище MDA простішою. Тобто MDA передбачає розробку стандартних сервісів, які підтримують відразу декілька технологій проміжного шару. Наприклад, можна створити репозитарий об'єктів, що надає відповідний сервіс системам як на базі CORBA, так і на базі Web-сервісів. Це не тільки спрощує розробку ПЗ, але й дозволяє організувати взаємодію різних систем.
Рис. 3.10. Використання стандартів в MDA
Так, якщо застосувати до PІМ кілька стандартних відображень на різні платформи, можна одержати кілька платформо-залежних моделей системи. Після необхідної доробки по цих моделях можна одержати реалізацію системи на декількох технологічних платформах. Тобто можна багаторазово використовувати одну платформо-незалежну модель, замість того щоб розробляти реалізацію системи на кожній платформі “з нуля”.
В MDA передбачена також можливість створення гетерогенних систем, частини яких функціонують на різних платформах проміжного шару й здатні взаємодіяти. Інструментарій, що проводить відображення, може не тільки створити PSM для кожної частини системи, але й, проаналізувавши їхню взаємодію на основі платформо-незалежної моделі, згенерувати сутності (опис інтерфейсів, код посередників, мостів і медіаторів), необхідні для міжплатформної взаємодії фрагментів системи – підсистему-адаптер.
У 2006 р. було розроблено розширення UML – мову SysML (Systems Modeling Language), яка на сьогодні фактично стала самостійною мовою. Як основні “стовпи”, що забезпечують всебічний опис систем, SysML виділяються моделювання:
1) структури системи (ієрархії та взаємодії між частинами) за рахунок модифікації діаграм класів у два типи діаграм блоків;
2) поведінки системи за рахунок модифікації діаграм дій та використання діаграм станів і послідовностей;
3) вимог до системи за рахунок введення нового типу діаграм для специфікації вимог – Requіrement Dіagrams;
4) властивостей об’єктів з допомогою нового типу діаграм – Parametric Dіagrams.
Так, для опису структури системи в SysML замість класичних UML-діаграм (класів, об'єктів й ін.) використовуються діаграми внутрішніх і зовнішніх блоків – модульних одиниць, інкапсулюючих атрибути, операції й обмеження, а також розподіл в інші модельні елементи та вимоги.
Взагалі, діаграми UML набули в SysML конкретного змісту, а також зв’язності через механізми розподілу (аllocation), зв’язку значень та верифікації.
Мова отримала можливості для підтримки розробки систем на різних стадіях – від специфікації вимог, аналізування і проектування до тестування працездатності.
Як і UML, SysML є мовою, а не методологією. Варіант використання SysML на різних стадіях створення ІС від компанії Telelogic подано на рис. 3.11.
Рис. 3.11. Процес розробки систем, оснований на використанні SysML
В SysML підтримується обмін моделями і даними в форматі XML Metadata Interchange (XMI), і як видно з рис. 3.11, отримані моделі передбачається зберігати в репозиторії з метою їх повторного використання.
На теперішній час SysML усоблює найбільш системний підхід до графічного моделювання складних систем, орієнтована саме на розробку на основі моделей й існує цілий ряд засобів, що її підтримують: Artіsan Studіo, SysML Toolkіt (EmbeddedPlus), Magіc Draw, Sparx Systems Enterprіse Archіtect, ІBM / Telelogіc Tau and Rhapsody, TopCased, Vіsіo SysML template та ін.
Проектування баз даних
Створення і впровадження в практику сучасних ІС АБД висуває нові завдання проектування, які неможливо вирішувати традиційними прийомами і методами. Велику увагу необхідно приділяти питанням проектування БД. Від того, наскільки успішно буде спроектована БД, залежить ефективність функціонування системи в цілому, її життєздатність і можливість розширення і подальшого розвитку. Тому питання проектування БД виділяють як окремий, самостійний напрям робіт при розробці ІС.
Проектування БД – це ітераційний, багатоетапний процес ухвалення обгрунтованих рішень в процесі аналізування інформаційної моделі ПрО, вимог до даних з боку прикладних програмістів і користувачів, синтезування логічних і фізичних структур даних, аналізування і обгрунтування вибору програмних і апаратних засобів. Етапи проектування БД пов'язані з багаторівневою організацією даних. Розглядаючи питання проектування баз даних, дотримуватимемося такого багаторівневого представлення даних: зовнішнього, інфологічного, логічного (даталогічного), внутрішнього.
Таке представлення рівнів даних не єдине. Існують й інші варіанти багаторівневого представлення даних. Так, відповідно до пропозицій дослідницької групи по системах управління даними Американського національного інституту стандартів ANSI/X3/SPARC, а також CODASYL (Conference on Data Systems Languages), як правило, виділяються три рівні представлення даних:
1) зовнішній (з погляду кінцевого користувача і прикладного програміста);
2) концептуальний (з погляду СУБД);
3) внутрішній (з погляду системного програміста).
Відповідно до цієї концепції зовнішній рівень – це частина (підмножинність) концептуальної моделі, необхідна для реалізації якого-небудь запиту або прикладної програми. Тобто, якщо концептуальна модель виступає як схема, підтримувана конкретною СУБД, то зовнішній рівень – це деяка сукупність підсхем, необхідних для реалізації конкретної прикладної програми або запиту користувача.
Існує також інша точка зору, відповідно до якої під зовнішнім рівнем розуміють більш загальні поняття, пов'язані з вивченням і аналізом інформаційних потоків ПрО та їхньою структуризацією. Деякі автори вводять допоміжний рівень, пойменованим “інфологічним”. Він може виступати як самостійний або бути складовою зовнішнього рівня. Така концепція доцільніша з погляду розуміння процесу проектування БД.
Тому розглядатимемо інфологічний рівень як самостійний рівень представлення даних. Зовнішній рівень в цьому разі виступає як окремий етап проектування, на якому вивчається все позамашинне інформаційне забезпечення, тобто форми документування і представлення даних, а також зовнішнє середовище, в якому функціонуватиме БнД з погляду методів фіксації, збирання і передачі інформації в БД.
При проектуванні БД на зовнішньому рівні необхідно вивчити функціонування об'єкта управління, для якого проектується БД; всю первинну і вихідну документацію з погляду визначення того, які саме дані необхідно зберігати в БД. Зовнішній рівень – це як правило, словесний опис вхідних і вихідних повідомлень, а також даних, які доцільно зберігати в БД. Опис зовнішнього рівня не виключає наявність елементів дублювання, надмірності й неузгодженості даних. Тому для усунення цих аномалій і суперечностей зовнішнього опису даних виконується інфологічне проектування. Інфологічна модель є засобом структуризації ПрО і розуміння концепції семантики даних. Інфологічну модель можна розглядати в основному як засіб документування і структуризації форми представлення інформаційних потреб, яка забезпечує несуперечливе спілкування користувачів і розробників системи.
Всі зовнішні уявлення інтегруються на інфологічному рівні, де формується інфологічна (канонічна) модель даних, яка не є простою сумою зовнішніх представлень даних.
Інфологічний рівень є інформаційно-логічною моделлю (ІЛМ) ПрО, з якої виключена надмірність даних та відображені інформаційні особливості об'єкта управління без урахування особливостей і специфіки конкретної СУБД. Тобто інфологічне представлення даних орієнтовано переважно на людину, яка проектує або використовує БД.
Логічний (концептуальний) рівень побудований з урахуванням специфіки і особливостей конкретної СУБД. Цей рівень представлення даних орієнтований більше на комп'ютерну обробку і на програмістів, які займаються її розробкою. На цьому рівні формується концептуальна модель даних, тобто спеціальним способом структурована модель ПрО, яка відповідає особливостям і обмеженням вибраної СУБД. Модель логічного рівня, підтримувану засобами конкретної СУБД, називають ще “даталогічною”.
Інфологічна і даталогічна моделі, які відображають модель однієї ПрО, залежні між собою. Інфологічна модель може легко трансформуватися в даталогічну модель.
Внутрішній рівень пов'язаний з фізичним розміщенням даних в пам'яті ЕОМ. На цьому рівні формується фізична модель БД, яка включає структури зберігання даних в пам'яті ЕОМ, в тому числі опис форматів записів, порядок їх логічного або фізичного приведення в порядок, розміщення за типами пристроїв, а також характеристики і шляху доступу до даних.
Від параметрів фізичної моделі залежать такі характеристики функціонування БД: обсяг пам'яті та час реакції системи. Фізичні параметри БД можна змінювати в процесі її експлуатації з метою підвищення ефективності функціонування системи. Зміна фізичних параметрів не зумовлює необхідності зміни інфологічної і даталогічної моделей.
Схеми взаємозв'язку рівнів представлення даних в БД, зображених на рис. 3.12. Проектування БД – це складний і трудомісткий процес, який вимагає залучення багатьох висококваліфікованих фахівців. Від того, наскільки кваліфіковано спроектована БД, залежать продуктивність ІС і повнота забезпечення функціональних потреб користувачів і прикладних програм. Невдало спроектована БД може ускладнити процес розробки прикладного ПЗ, зумовити необхідність використання складнішої логіки, яка, у свою чергу, збільшить час реакції системи, а надалі може привести до необхідності перепроектування логічної моделі БД. Реструктуризація, або внесення змін в логічну модель БД, це дуже небажаний процес, оскільки він є причиною необхідності модифікації або навіть перепрограмування окремих завдань.
Всі роботи, виконувані на кожному етапі проектування, повинні інтегруватися із словником даних. Кожен етап проектування розглядається як певна послідовність ітеративних процедур, в результаті яких формується певна модель БД.
Рис. 3.12. Схема взаємозв'язку рівнів представлення даних в БД
Зовнішній рівень – підготовчий етап інфологічного проектування. Метою проектування на зовнішньому рівні є розробка позамашинного інформаційного забезпечення, яке включає систему вхідної (первинної) документації, що характеризує певну ПрО, систему класифікації й кодування ТЕІ, а також перелік відповідних вихідних повідомлень, які потрібно формувати за допомогою БнД.
Існують два підходи до проектування БД на зовнішньому рівні: “від предметної області” і “від запиту”. Підхід “від предметної області” полягає в тому, що формується зовнішнє інформаційне забезпечення всієї ПрО без урахування потреб користувачів і прикладних програм. Іноді цей підхід називають “об'єктним” або “непроцесним”.
При підході “від запиту” основним джерелом інформації щодо ПрО є вивчення запитів користувачів і потреб прикладних програм. Цей підхід також має назву “процесний” або “функціональний”. При такому підході БД проектується для виконання поточних завдань управління без урахування можливості розширення системи і виникнення нових завдань управління.
Перевага підходу “від предметної області” – це його об'єктивність, системність при відображенні ПрО і стійкість інформаційної моделі, можливість реалізації великої кількості прикладних програм і запитів, зокрема незапланованих при створенні БД. Недоліком цього підходу є значний обсяг робіт, які необхідно виконати при визначенні інформації. що підлягає зберіганню в БД, що відповідно ускладнює і збільшує термін розробки проекту.
Функціональний підхід орієнтований на реалізацію поточних вимог користувачів і прикладних програм без урахування перспектив розвитку системи. При його використанні можуть виникнути складнощі в агрегації вимог різних користувачів і прикладних програм. Проте, при такому підході значно зменшується трудомісткість проектування, і тому можливо створити систему зіз високими експлуатаційними характеристиками.
Проте узятий окремо будь-який з цих методів не може дати досить інформації для проектування раціональної структури БД. Тому при проектуванні БД доцільно спільно використовувати ці два підходи. Якщо схемно представити процес проектування БД на зовнішньому рівні, то він складається з таких робіт.
1. Визначення функціональних завдань ПрО, які підлягають автоматизованому рішенню. Оскільки основною метою створення БД є забезпечення інформацією функцій обробки даних, то, перш за все, необхідно вивчити всі функції ПрО (об'єкта управління), для якої розробляється БД, і проаналізувати їх особливості. Функції й функціональні особливості об'єкта управління необхідно вивчати в нерозривному зв'язку з вивченням функціональних вимог до даних з боку майбутніх користувачів інформаційної системи. Вивчення і аналізування передбачають виявлення інформаційних потреб і визначення інформаційних потоків. Ці роботи можна виконувати обстеженням ПрО і анкетуванням її співробітників. Результатом такого вивчення може бути перелік функціональних завдань, які повинні вирішуватися автоматизованим способом з використанням БД.
2. Вивчення і аналізування оперативних первинних документів. Вивчивши функції і визначивши перелік функціональних завдань, які підлягають автоматизованому рішенню, переходять до вивчення оперативних документів, використовуваних на вході кожного завдання або їх комплексу. Вивчивши і проаналізувавши всі оперативні документи (як зовнішні, так і внутрішні), використовувані на вході кожного завдання, визначають, які реквізити цих документів потрібно зберігати в БД.
3. Вивчення нормативно-довідкових документів. На третьому кроці вивчають і аналізують всю нормативно-довідкову документацію. До такої документації належать різні класифікатори, кошториси, договори, нормативи, законодавчі акти по податковій політиці, планова документація і т.п. Розподіл і окремий аналіз оперативної і нормативно-довідкової інформації обумовлені технологічно. У БД розрізняються технології створення і ведення файлів умовно-постійної інформації, розміщеної в нормативно-довідковій документації, і файлів оперативної інформації.
4. Вивчення процесів перетворення вхідних повідомлень у вихідні. Перш за все, вивчаються всі вихідні повідомлення, які видаються на друк або на екран і зберігаються у вигляді вихідних масивів. Це необхідно для того, щоб визначити, які з атрибутів вхідних повідомлень потрібно зберігати в БД для отримання вихідних повідомлень. Крім того, на цьому етапі визначаються ті показники, які одержують під час рішення задачі в результаті виконання певних обчислень. По кожному розрахунковому показнику варто визначити алгоритм його формування і переконатися в тому, що цей показник можна одержати на основі атрибутів оперативної і нормативно-довідкової інформації, визначених на другому і третьому кроках. Якщо певних даних не вистачає для повного виконання розрахунків, необхідно повернутися назад, провести додаткове дослідження і визначити, де і яким способом можна одержати атрибути, яких не вистачає.
Крім того, потрібно визначитися, які з розрахункових показників доцільно зберігати в БД. Показники, одержані розрахунковим шляхом, як правило, в БД не зберігаються. Вийнятком є випадки, коли розрахунковий показник потрібно використовувати для вирішення інших завдань або для даного завдання, але в наступні календарні періоди.
При проведенні проектних робіт на зовнішньому рівні треба враховувати те, що для виконання певних функцій в БД необхідно зберігати додаткові дані, які не відображені в документах (дані календаря, статистичні дані й т.п.). Узагальнена схема процесу вивчення документів і даних при проектуванні на зовнішньому рівні зображена на рис. 3.13. Таке вивчення необхідно провести по кожному функціональному завданню або їх комплексу, які вирішуватимуться за допомогою БД.
Рис. 3.13. Узагальнена схема процесу проектування на зовнішньому рівні
Результатом проектування на зовнішньому рівні буде перелік атрибутів (реквізитів) оперативної і умовно-постійної інформації, які необхідно зберігати в БД, з вказівкою джерел їх отримання і форми уявлення. Проте цей перелік не виключає можливості існування в ньому надмірності, дублювання, неузгодженості та інших недоліків. Тому на цьому процес не закінчується, а здійснюється перехід до етапу інфологічного проектування.
Основними складовими елементами інфологічної моделі є суть (інформаційні об'єкти), зв'язки між ними та їх атрибути (властивості).
Суть – будь-який помітний об'єкт (об'єкт, який можна відрізнити від іншого), інформацію про який необхідно зберігати в БД. Суттю можуть бути люди, місця, літаки, рейси, смак, колір і т.д. Необхідно розрізняти такі поняття, як тип суті й екземпляр суті. Поняття “тип суті” відноситься до набору однорідних осіб, предметів, подій або ідей, виступаючих як ціле. “Екземпляр суті” відноситься до конкретного об’єкта в наборі. Наприклад, типом суті може бути МІСТО, а екземпляром – Москва, Київ і т.д.
Атрибут – пойменована характеристика суті. Його найменування повинне бути унікальним для конкретного типу суті, але може бути однаковим для різного типа суті (наприклад, КОЛІР може бути визначений для деякої суті: СОБАКА, АВТОМОБІЛЬ, ДІМ і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про суть. Прикладами атрибутів для суті АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КОЛІР і т.п. Тут також існує відмінність між типом і екземпляром. Тип атрибута КОЛІР має багато екземплярів або значень: Червоний, Синій, Банановий, Біла ніч і т.д., проте кожному екземпляру суті привласнюється тільки одне значення атрибута.
Абсолютна відмінність між типами суті й атрибутами відсутня. Атрибут є таким тільки у контексті з типом суті. У іншому контексті атрибут може виступати як самостійна суть. Наприклад, для автомобільного заводу колір – це тільки атрибут продукту виробництва, а для лакофарбної фабрики колір – тип суті.
Ключ – мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр суті. Мінімальність означає, що виключення з набору будь-якого атрибуту не дозволяє ідентифікувати суть по тих, що залишилися. Для суті Розклад ключем є атрибута Номер_рейса або набір: Пункт_відправлення, Час_вильоту і Пункт_призначення (за умови, що з пункту до пункту вилітає в кожен момент часу один літак).
Зв'язок – асоціювання двох або більш сутностей. Якби призначенням БД було тільки зберігання окремих, не зв'язаних між собою даних, то її структура могла б бути дуже простою. Проте одною з основних вимог до організації БД є забезпечення можливості відшукання однієї суті за значеннями інших, для чого необхідно встановити між ними певні зв'язки. А оскільки в реальних БД нерідко містяться сотні або навіть тисячі суті, то теоретично між ними може бути встановлено більше мільйона зв'язків. Наявність такої безлічі зв'язків і визначає складність інфологічних моделей.
Метою інфологічного проектування є створення структурованої інформаційної моделі ПЗ, для якої розроблятиметься БД. При проектуванні на інфологічному рівні створюється інформаційно-логічна модель (ІЛМ), яка повинна відповідати таким вимогам:
· забезпечення найбільш природних для людини способів збору і представлення тієї інформації, яку передбачається зберігати в створюваній БД;
· коректність схеми БД, тобто адекватне відображення модельованої ПрО;
· простота і зручність використання на наступних етапах проектування, тобто може легко відображатися на моделі БД, підтримуваних відомими СУБД (мережеві, ієрархічні, реляційні й ін.).
Інформаційно-логічна модель повинна бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам.
Суть інфологічного моделювання полягає у виділенні суті (інформаційних об'єктів ПрО), яка підлягає зберіганню в БД, а також у визначенні характеристик (атрибутів) об'єктів і взаємозв'язків між ними.
Існує два підходи до інфологічного проектування: аналізування об'єктів і синтезування атрибутів. Підхід, базований на аналізуванні об'єктів, називається низхідним, а на синтезуванні атрибутів – висхідним.