- •Охарактеризуйте поняття „інформаційна система”. Основні історичні етапи розвитку інформаційних систем. Структура інформаційної системи.
- •Загальні принципи побудови інформаційних систем. Які процеси забезпечують роботу інформаційної системи? Які є можливі результати застосування інформаційних систем?
- •Канонічне проектування інформаційної системи.
- •Охарактеризуйте життєвий цикл інформаційної системи. Моделі життєвого циклу інформаційної системи. Переваги і недоліки моделей життєвого циклу інформаційної системи.
- •Типове проектування інформаційної системи.
- •Наведіть особливості і основні прийоми роботи з програмою All Fusion Process Modeler bPwin для побудови і аналізу діаграм відомих вам методологій структурного аналізу.
- •Структура представлень моделі idef0 в case засобі All Fusion Process Modeler bPwin, їх призначення і особливості. Охарактеризуйте каркас діаграми в методології idef0.
- •Охарактеризуйте імітаційне моделювання інформаційних систем.
- •Наведіть основні критерії класифікації інформаційних системи та прокласифікуйте відповідно до них інформаційні системи.
- •Наведіть і охарактеризуйте складові структури інформаційної системи, які забезпечують її роботу.
- •Охарактеризуйте методологію структурного аналізу інформаційних систем sadt. Наведіть коротку порівняльну характеристику її складових та приклади з відомих вам методологій аналізу.
- •Опишіть технологію idef0. Нарисуйте елементи нотації і наведіть їх інтерпретацію. Наведіть приклади діаграм.
- •Розщеплення і злиття моделей у технології idef0. Що означають стрілки, які розгалужуються або зливаються в методології idef0? Правила іменування стрілок, які розгалужуються або зливаються.
- •Тунелювання стрілок на діаграмах функціональних моделей. Типи тунелів, їх функціональне призначення. Наведіть графічну нотацію на прикладах діаграм.
- •Методика dfd для побудови моделі інформаційної системи. Нарисуйте елементи нотації і наведіть їх інтерпретацію. Відмінність її семантики від idef0.
- •Характеристика методики idef3. Нарисуйте елементи нотацій і наведіть їх інтерпретацію. Відмінність її семантики від idef0 і dfd.
- •Методи побудови систем класифікації для інформаційного забезпечення інформаційної системи, їх переваги і недоліки.
- •Кодування інформації. Методи організації кодування інформації для інформаційної системи. Їх переваги і недоліки.
- •Уніфікована система документації для інформаційної системи.
- •Інформаційна база інформаційної системи і способи її організації. Структура файлів інформаційної бази.
- •Охарактеризуйте процеси прямого інжинірингу інформаційної системи в методології idef1x.
- •Дайте характеристику sadt методу побудови діаграм idef1x. Наведіть приклади відповідних діаграм.
- •Дайте характеристику основних понять семантичних моделей даних логічного рівня представлення в idef1x.
- •Охарактеризуйте процеси зворотного інжинірингу інформаційної системи в методології idef1x.
- •Сутність в моделі idef1x. Типи зв'язків в моделі idef1x. Потужність зв'язків в моделі idef1x. Атрибути сутностей в моделі idef1x. Наведіть відповідні елементи нотації.
- •Як за допомогою case засобів організувати перенос інформаційної бази інформаційної системи з однієї системи баз даних на іншу, реалізувати сервісні функції перевірки моделей, волюметрії?
- •Типи залежних сутностей. Охарактеризуйте їх, наведіть відповідні елементи нотації.
- •Типи ключів, які розрізняють в моделі idef1x. Охарактеризуйте їх, дайте критерії вибору. Наведіть відповідні елементи нотації.
- •Суть поняття домену у прикладній програмі eRwin. Використання доменів для розділення елементів логічного і фізичного рівня моделі. Правила валідації і розширені атрибути в моделі даних.
- •Нормалізація моделі інформаційної бази інформаційної системи. Денормалізація моделі даних.
- •Поняття „семантична модель даних” для інформаційної системи. Що таке семантична мережа, правила як її побудувати у прикладній програмі eRwin?
- •Групування моделей за рівнями в idef1x. Категорії логічна, фізична модель в idef1x.
- •Правила валідації і значення за замовчуванням у моделях даних. Трігери і збережувані процедури у моделях даних. Розширені атрибути у моделях даних. Проектування сховищ даних.
- •Підтримка проектування і масштабування моделей баз даних в програмі All Fusion Erwin Data Modeler.
- •Якою є мета моделювання даних для інформаційного забезпечення інформаційної системи? Коротка характеристика моделей.
- •Як організувати і для чого взаємодію All Fusion Erwin Data Modeler і All Fusion Process Modeler bPwin? Інтеграція інформаційних та функціональних моделей.
- •Назвіть основні прийоми побудови схем реляційної бази даних за результатами інформаційної моделі.
- •Назвіть і дайте характеристику основних понять діаграм сутність - зв’язок.
- •Наведіть характеристику складових загальної структури мови uml.
- •Основні (канонічні) та спеціальні (допоміжні) діаграми uml.
- •Семантика і нотація діаграм розгортання. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
- •Семантика і нотація діаграми послідовностей. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
- •Семантика і нотація діаграм компонентів. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
- •Семантика і нотація діаграми об’єктів. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
- •Семантика і нотація діаграми пакетів. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
- •Семантика і нотація діаграми станів. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
- •Семантика і нотація діаграми варіантів використання. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
- •Семантика і нотація діаграми класів. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
- •Послідовність побудови моделей в uml. Якими діаграмами їх наповнюють і для чого?
- •Нотація uml як графічна інтерпретація семантики для її візуального представлення. Наведіть відповідні позначення і дайте їх інтерпретацію.
- •Основні рекомендації під час графічного зображення діаграм uml. Загальні і спеціальні діаграми uml.
- •Особливості зображення діаграм мови uml – типи візуальних позначень, основні типи графічних конструкцій.
- •Типи діаграм uml, їх класифікація і коротка характеристика застосовності.
- •Пакетна структура метамоделі мови uml
- •Структура модельних представлень для формального опису мови uml.
- •На яких принципах моделювання складних систем базується використання мови uml?
Наведіть характеристику складових загальної структури мови uml.
Загальна структура мови UML складається з:
1. Семантика мови UML. Представляє метамодель, яка забезпечує найбільш абстрактний синтаксис ООП на мові UML.
2. Нотація мови UML. Графічна нотація для візуального представлення семантики мови UML.
Семантика мови UML визначається для двох видів об'єктних моделей: структурних і поведінкових. Структурні (статичні) моделі описують структуру сутностей або компонентів системи, включаючи їхні класи, інтерфейси, атрибути й зв'язки. Моделі поводження (динамічні) описують поведінку або функціонування об'єктів системи, включаючи їхні методи, взаємодію (співробітництво) між ними, а також процес зміни станів окремих компонентів і системи в цілому.
Основні (канонічні) та спеціальні (допоміжні) діаграми uml.
Структурні діаграми:
Діаграми класів - використовуються для моделювання класів. Діаграми компонент – для моделювання компонентної структури розподілених систем. Діаграми об’єктів – діаграми для використання екземплярів класу. Д-ми композитних структур – для моделювання складних структурних компонентів системи. Д-ми розгортань – для моделювання і розміщення апаратних частин системи. Д-ми пакетів – для розбиття системи на частини. Д-ми профілів – показують, що саме розширюють відповідні елементи моделі, названі стереотипами.
Діаграми поведінки:
Д-ма активностей – зображає складні алгоритми. Д-ма прецедентів(USE CASE) – зображує функціональність системи. Д-ма кінцевої автоматики – аналіз поведінки реактивних систем. Д-ми взаємодії – послідовного моделювання часових аспектів системи. Д-ми схем взаємодії – організація ієрархії діаграм послідовності. Д-ми комунікації – як послідовності, тільки більше за взаємодію елементів. Часові д-ми – дозволяють показувати внутрішню динаміку деяких компонентів системи.
Загальні діаграми практично не залежать від предмету моделювання і можуть застосовуватись в будь-якому проекті. До Загальних д-м відносять: д-ми використання, класів, автоматів, діяльності, послідовностей, комунікацій, компонентів, розміщення.
Спеціальні діаграми: слугують для доповнення якої-небудь загальної діаграми об’єктів, композиційної структури, взаємодії, синхронізації та пакетів. Перелік перших д-м часто називають канонічними, бо вони складають невід’ємну частину нотації. Використовують перехід від концептуального погляду.
Семантика і нотація діаграм розгортання. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
Актор (зовнішня сутність) представляє собою абстрактний опис класу джерел/приймачів повідомлень, які безпосередньо взаємодіють з системою, підсистемою або класом. Він є описом ролі, яку відіграє користувач (людина або інша система, підсистема, клас) під час взаємодії з інформаційною системою. На найвищому рівні акторами можуть виступати оператор, системний адміністратор, адміністратор бази даних, користувач, певний клас пристроїв і т.п. Кожна роль вимагає для себе деякого визначеного сервісу.
Залежно від режиму взаємодії одна людина або фізичний об’єкт може представляти собою декілька акторів (різні ролі), наприклад, оператор або адміністратор. Зображення актора на діаграмах UML у вигляді стилізованого чоловічка з відповідним до його ролі написом.
Актор знаходиться поза межами системи і його внутрішня структура не визначається.
Іноді актора представляють за допомогою символу класу з відповідним стереотипом. "Стереотипізовану" форму представлення використовують, як правило, для відображення системних акторів, або у тих випадках коли актор має властивості, які повинні бути наведені на діаграмі.
З системою актори взаємодіють через повідомлення, або, якщо, використовувати терміни use case моделювання, то вони взаємодіють з системою через варіанти використання або прецеденти. Один і той же актор може бути пов'язаний з декількома прецедентами, і, навпаки, один прецедент може бути пов'язаний з декількома різними акторами. Зв'язки між актором і прецедентом завжди бінарні, тобто, представляють відношення типу "один -до одного". Це не заперечує сказаного вище: насправді, один актор може бути пов'язаний з декількома прецедентами, але тільки за допомогою окремих зв’язків, по одному на кожен прецедент. Актори не можуть бути пов’язані один з одним. Єдиний тип зв’язку між акторами, який є можливим, це успадкування (наслідування, generalization). Сказане не забороняє спілкування між акторами в реальному світі, просто під час створення моделі варіантів використання, таке спілкування і його відображення на діаграмі вважають несуттєвим.
Варіант використання (прецедент, use case) – абстрактний опис класу сервісу або сервісних функцій, які надаються актору системою у відповідь на його запити. Сервіс може надавати система у цілому, підсистема або клас. Таким чином, варіант використання означає моделювання деякої частини функціональності або поведінки системи. Варіант використання має ім'я і означає деяку послідовність дій, з точки зору зовнішнього джерела/приймача (актора).
Всі діаграми в UML представлені спеціальними графічними нотаціями, які, як правило, містять вершини (представлені геометричними фігурами), які пов’язані ребрами (різними дугами або стрілками).
Елементи нотації і їх інтерпретація.
-сукупність операцій, які визначають
сервіс, який надається класом або
компонентом діаграми.
-зовнішня стосовно системи сутність,
яка взаємодіє із системою і
використовує її функціональні можливості для досягнення певної мети або р-ку часткових завдань.
-опис послідовно виконуваних дій, які
приводять до
суттєвого для актора результату.
-опис
сукупності екземплярів акторів і
об’єктів ,і їх взаємодії в
процесі вирішення конкретного завдання.
-фіз частина с-ми, модулі с-ми, які
забезпечують реалізацію
узгодження набору інтерфейсу.
-
фіз частина с-ми,яка надає ресурси для
розвязку завдань.
-пояснююча
сутність
Семантика і нотація діаграми діяльності (активності). Нарисуйте елементи нотації і наведіть їх інтерпретацію.
Діаграма діяльності (Activity Diagram) відноситься до загальної діаграми поведінки, вона один з часткових випадків діаграми станів (але до діаграм станів не зводяться). Будуються на рівні моделей проектування Designer Model. Під час побудови поведінки, виникає потреба алгоритмічної деталізації. Вимоги до зображення послідовності зростають. Семантика , нотації, дають можливість відобразити певні стани і переходи між цими станами. Основним напрямком діаграм діяльності є візуалізувати особливості реалізації класів, за умови представлення алгоритмів їх виконання; кожен стан може бути представлений на виконанні операції чи її частини, дозволяє описати реакцію системи на внутрішні події. На діаграмі діяльності (ДД) відображається логіка або послідовність переходу від 1-ї до 2-ї і увага фіксується на результаті діяльності; власне цей результат може вплинути на зміну стану системи або повернути значення. Час явним чином не вказується в ДД. Елементарна дія (action state – стан дії (зображується у вигляді горизонтально видовженого прямокутника з заокругленими кутами)) – це атомарне обчислення, яке виконується і приводить до зміни системи чи повертає значення, дія миттєва і не піддається перериванню ззовні. Діяльність – тривалі неатомарні обчислення. Стан дії – специфічний випадок стану з деякою вхідною дією і хоча б одним переходом, який виходе з цього стану. Цей перехід неявно передбачає, що описана дія (action state) завершилась. Один з способів іменування у формі дієслова або у вигляді певної обчислювальної операції. Існує можливість використати subactivity state (підстан діяльності) (зображується горизонтально видовженим прямокутником із позначкою скобки), коли система розглядається з певним 0-вим наближенням. Наявні псевдостани. Кожна діаграма володіє одним початковим і одним кінцевим псевдо станом (• Initial state, ּFinal state). Реалізується зверху вниз від Initial state до Final state. Переходи (Transition) – реакція об’єкту на деяку подію; об’єкт виконує дію, яка прикріплена до переходу, і змінює свій стан. Кожному стану відповідає своя множина переходів. Час переходу вважають нульовим, тобто перехід миттєвий. Розрізняють переходи: тригерні (кріпиться подія, перехід реагує на неї); нетригерні (подія може бути явно не прикріплена). Ці переходи передбачають, що елементарна дія в стані завершилась, спрацьовують відразу після завершення дій в стані. Зображуються: →. Сторожові умови прописуються в квадратних дужках [ ], їх кріплять до переходу, коли переходів є декілька після певного стану, з яких є лише один істинний. В UML розгалуження носить назву Decision (Рішення), логічне АБО. (зображають у вигляді ромбу). Якщо лог. АБО, то стрілки входять зліва і зверху в ромб, а при потребі зобразити рішення як злиття, стрілки входять зліва і справа в ромб, а виходить вниз. Паралельні гілки обчислень використ. для зображення розпаралелювання і забезпечують синхронізацію. Зображується: ▬ Логіка таких І береться з мереж Петрі (вперше використали в IDEF2). Concurent fork (розпаралелення) – одна стрілка входить і декілька виходить, Concurent join (злиття) – декілька входить і одна виходить. Діаграма діяльності може бути представлена як спеціальний випадок діаграм станів, де більшість станів – дії, більшість переходів – не тригерні переходи, які спрацьовують в станах, які є джерелами. Доріжки (swinlane) – діаграма діяльності ділиться зверху. Як правило, пишуть кому доріжка належить, порядок їх розміщення семантично немає значення. Доріжки асоціюють з діями певних структурних підрозділів організації, а кожен такий підрозділ несе відповідальність в рамках своєї доріжки. Перехід між підрозділами можливий, коли відбувається перехід до потоку управління в відповідний підрозділ. Зображуються об’єкти на діаграмах діяльності – прямокутником , заголовок – назва об’єкта і через «:» назва класу об’єкту, підкреслені лінією. Можуть бути анонімні (без імені) і позакласові об’єкти (без класу). В ДД об’єкти мають додатковий зміст, адже вони ініціюють виконання певних дій, або визначають деякий результат цих дій. Один і той же об’єкт на ДД може бути представлений декілька разів (може бути з іншим вмістом). Об’єкти під’єднуються до станів стрілками ─ ─ →. Якщо об’єкти зображаються у доріжках, то можуть бути і на межах доріжок, тоді перехід до наступного стану в сусідній доріжці є асоційований з готовністю деякого документу (стану), якщо ж об’єкт зображається в рамках одної доріжки, то він визначається лише цією доріжкою. Для ДД можливе несхідне (↓) і висхідне (↑).
