14. Структурна модель предметної області іс.

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

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

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

16. Функціональна структура Функція (операція) є деякий перетворювач вхідних об'єктів у вихідні. Послідовність взаємозв'язаних по входах і виходах функцій складає бізнес-процес. Функція бізнес-процеса може породжувати об'єкти будь-якої природи. На зовнішньому рівні моделювання визначається список основних бізнесу-функцій або видів бізнес-процесів. Зазвичай таких функцій налічується 15–20. На концептуальному рівні виділені функції декомпозіруются і будуються ієрархії взаємозв'язаних функцій. На внутрішньому рівні відображується структура інформаційного процесу в комп'ютері: визначаються ієрархічні структури програмних модулів, що реалізовують функції, що автоматизуються.

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

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

19. Технічна структура Топологія визначає територіальне розміщення технічних засобів по структурних підрозділах підприємства, а комунікація — технічний спосіб реалізації взаємодії структурних підрозділів. На зовнішньому рівні моделі визначаються типи технічних засобів обробки даних і їх розміщення по структурних підрозділах. На концептуальному рівні визначаються способи комунікацій між технічними комплексами структурних підрозділів: фізичне переміщення документів, машинних носіїв, обмін інформацією по каналах зв'язку і так далі На внутрішньому рівні будується модель "клієнт-серверної" архітектури обчислювальної мережі. Описані моделі наочної області націлені на проектування окремих компонентів ІС: даних, функціональних програмних модулів, програмних модулів, що управляють, програмних модулів інтерфейсів користувачів, структури технічного комплексу. Для якіснішого проектування вказаних компонентів потрібна побудова моделей, що зв'язали різні компоненти ІС між собою

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

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

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

22. Декомпозиція є основним поняттям стандарту IDEF0. Принцип декомпозиції застосовується при розбитті складного процесу на складові його функції. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі. Декомпозиція дозволяє поступово і структуровано представляти модель системи у вигляді ієрархічної структури окремих діаграм, що робить її менш перевантаженою і легко засвоюваної. Останнім з понять IDEF0 є глосарій. Для кожного з елементів IDEF0 - діаграм, функціональних блоків, інтерфейсних дуг - існуючий стандарт передбачає створення та підтримку набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений даним елементом. Цей набір називається глосарієм і є описом суті даного елемента. Глосарій гармонійно доповнює наочний графічний мову, забезпечуючи діаграми необхідної додаткової інформацією.

23. Модель IDEF0 завжди починається з представлення системи як єдиного цілого - одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстною діаграмою. У пояснювальному тексті до контекстної діаграмі повинна бути вказана мета (Purpose) побудови діаграми у вигляді короткого опису і зафіксована точка зору (Viewpoint). Визначення і формалізація мети розробки IDEF0-моделі є вкрай важливим моментом. Фактично мета визначає відповідні області в досліджуваній системі, на яких необхідно фокусуватися в першу чергу.

24. Стандарт IDEF0 містить набір процедур, що дозволяють розробляти й погоджувати модель великою групою людей, що належать до різних галузей діяльності модельованої системи. Зазвичай процес розробки є ітеративним і складається з наступних умовних етапів: 1) Побудова первісної моделі є динамічним процесом, протягом якого автори опитують компетентних осіб про структуру різних процесів, створюючи моделі діяльності підрозділів. 2) Поширення чернетки для розгляду, узгоджень та коментарів. На цій стадії відбувається обговорення чернетки моделі з широким колом компетентних осіб (в термінах IDEF0 - читачів) на підприємстві. 3) Офіційне затвердження моделі. Затвердження узгодженої моделі відбувається керівником робочої групи в тому випадку, якщо у авторів моделі і читачів відсутні розбіжності з приводу її адекватності.

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

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

27. Переваги методики DFD відносяться: можливість однозначно визначити зовнішню суть, аналізуючи потоки інформації усередині і поза системою; можливість проектування зверху вниз, що полегшує побудову моделі «як повинно бути»; наявність специфікацій процесів нижнього рівня, що дозволяє здолати логічну незавершеність функціональної моделі і побудувати повну функціональну специфікацію системи, що розробляється.

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

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

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

29. Oracle Designer представляє собою інструмент, що дозволяє проектувати дані, моделювати бізнес-процеси, створювати діаграми потоків даних і функціональні моделі, а також реалізовувати їх у вигляді серверних об'єктів. Цей продукт головним чином призначений для застосування разом з СУБД Oracle і підтримує всі особливості даної СУБД, хоча з його допомогою можна здійснювати і зворотне проектування для СУБД інших виробників.

30. Об'єктно-орієнтоване програмування - це метод програмування, оснований на поданні програми у вигляді сукупності взаємодіючих об'єктів, кожен з яких є екземпляром певного класу, а класи є членами певної ієрархії наслідування.

Об'єктно-орієнтований підхід полягає в наступному наборі основних принципів:

• Все є об'єктами.

• Всі дії та розрахунки виконуються шляхом взаємодії (обміну даними) між об'єктами, при якій один об'єкт потребує, щоб інший об'єкт виконав деяку дію. Об'єкти взаємодіють, надсилаючи і отримуючи повідомлення. Повідомлення — це запит на виконання дії, доповнений набором аргументів, які можуть знадобитися при виконанні дії.

• Кожен об'єкт має незалежну пам'ять, яка складається з інших об'єктів.

• Кожен об'єкт є представником (екземпляром, примірником) класу, який виражає загальні властивості об'єктів.

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

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

31. Абстрагування є одним з основних методів, що застосовується до рішення складних задач. Його основна задача відділити основне від дріб’язкового (зерно від полови).

Існує цілий ряд корисних абстракцій, що застосовуються для класифікації об’єктів реального світу:

- абстракція сутності (об’єкт є корисною моделлю деякої сутності в предметній області);

- абстракція поведінки (об’єкт складається з узагальненої множини операцій);

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

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

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

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

32. Модульність – це властивість системи, яка була розкладена на внутрішньо зв’язні, але слабо зв’язані між собою модулі.

В різних мовах програмування механізм модульності реалізовано по різному. Інтуїтивний в С++, інтерфейс в заголовкових файлах (*.h), а реалізація у файлах програм (*.cpp) і зв’язок між модулями реалізовується за допомогою директиви #include. В Ada та Object Pascal є спеціальні ключові слова для визначення інтерфейсу модулю та його реалізації.

Ієрархія – це впорядкування абстракцій, розклад їх за рівнями.

Основними видами ієрархічних структур є структура класів (ієрархія “is-a” [“є”]) та структура об’єктів (ієрархія “part of” [“частина ...”])

40. Уніфікована мова моделювання UML) - це наступник того покоління методів ООАП, які з'явилися наприкінці 80-х і початку 90-х рр… UML є прямим об'єднанням і уніфікацією методів Буча, Рамбо і Якобсона, однак доповнює їх новими можливостями. Головними в розробці UML були наступні цілі:

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

• передбачити механізми розширюваності та спеціалізації для розширення базових концепцій;

• забезпечити незалежність від конкретних мов 6

41. Діаграми класів є центральною ланкою об'єктно-орієнтованих методів. Діаграма класів визначає типи об'єктів системи і різного роду статичні зв'язки, які існують між ними. Є два основних види статичних зв'язків:

• асоціації (наприклад, клієнт може зробити замовлення);

• підтипи (приватний клієнт є різновидом клієнта).

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

концептуальний аспект - діаграми класів відображають поняття досліджуваної предметної області (моделюється організації). Ці поняття, природно, будуть відповідати реалізують їх класам, однак таке пряме відповідність часто відсутня• аспект специфікації - модель спускається на рівень ПЗ, але розглядаються тільки інтерфейси, а не програмна реалізація класів (під інтерфейсом тут розуміється набір операцій класу, видимих ​​ззовні);

• аспект реалізації - модель дійсно визначає реалізацію класів ПЗ. Цей аспект найбільш важливий для програмістів.

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

42. Діаграми взаємодії (interaction diagrams) є моделями, що описують поведінку взаємодіючих груп об'єктів.

Як правило, діаграма взаємодії охоплює поведінку об'єктів в рамках тільки одного варіанту використання. На такій діаграмі відображаються ряд об'єктів і ті повідомлення, якими вони обмінюються між собою.

Існують два види діаграм взаємодії: діаграми послідовності (sequence diagrams) і кооперативні діаграми (collaboration diagrams).

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

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

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