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

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

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

Розміщено на http://www.allbest.ru/

Омський державний інститутсервісу

Моделювання інформаційних системз використанням мови UML

Методичні вказівки до виконання курсової роботи

І.В. Червенчук

  • Вступ
  • 2 . Уніфікована мова моделюванняUML
  • 4. Розробка моделі програмної системи засобамиUML
  • 5. Питання реалізації інформаційної системи
  • 6. Теми курсових робіт
  • бібліографічний список

Вступ

У роботі розглядаються питання розробки інформаційних систем із використанням уніфікованої мови моделювання UML, що є основою для виконання курсової роботи з дисципліни "Інформаційні системи та процеси. Моделювання та управління". Опрацьовуються основні етапи раціонального уніфікованого процесу розробки інформаційних систем, наводяться приклади та ілюстрації. Дано варіанти завдань до виконання курсових робіт.

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

1. Загальні вимоги до виконання курсової роботи

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

Типова назва курсової роботи виглядає як "Розробка інформаційно-довідкової системи _ назва _ "

Вступ

1. Змістовий огляд предметної галузі. Основні вимоги до системи

2. Розгорнута модель інформаційної системи

2.1 Вид з погляду прецедентів

2.2 Вид з погляду проектування

2.3 Вид з погляду реалізації

2.4 Вигляд з погляду процесів (при необхідності)

2.5 Вид з погляду розгортання (при необхідності)

3. Реалізація інформаційної системи

Висновок

Додаток Лістинг програми або головного модуля

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

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

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

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

У висновку коротко підбиваються основні підсумки роботи: розроблена UML-модель системи, система реалізована за допомогою такого середовища програмування, що розроблена система дозволяє, переваги використовуваних підходів (на основі моделювання) до проектування систем.

моделювання інформаційна система мова

Курсова робота має містити 20-30 сторінок друкованого тексту із ілюстраціями. В обов'язковому порядку мають бути наведені діаграми прецедентів, класів, взаємодії.

2. Уніфікована мова моделювання UML

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

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

UML - це мова для візуалізації, специфікації, конструювання та документування артефактів програмних систем, що базується на об'єктно-орієнтованому підході.

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

UML – це мова візуалізації, при цьому UML – це не просто набір графічних символів. За кожним із них стоїть добре певна семантика(див. ) Таким чином, модель, написана одним розробником, може бути однозначно інтерпретована іншою або навіть інструментальною програмою.

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

UML – це мова конструювання. Хоча UML не є мовою візуального програмування, моделі, створені за його допомогою, можуть бути переведені безпосередньо на різні конкретні мови програмування. Іншими словами, UML-модель можна відобразити такими мовами, як Java, C++, Visual Basic, і навіть на таблиці реляційної базиданих чи стійкі об'єкти об'єктно-орієнтованої бази даних. Ті поняття, які переважно передавати графічно, так і надаються в UML; ті ж, які краще описувати у текстовому вигляді, виражаються за допомогою мови програмування.

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

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

UML – це мова документування

Компанія, що випускає програмні засоби, крім коду, що виконується, виробляє й інші документи, в тому числі:

вимоги до системи;

архітектуру;

проект;

вихідний код;

проектні плани;

випробування;

прототипи;

версії та ін.

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

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

Розглянемо розробку моделі інформаційної системи засобами мови UML з прикладу розробки автоматизованого робочого місця секретаря кафедри (далі АРМ секретаря кафедри).

3. Опис предметної області

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

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

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

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

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

Об'єкти взаємодіють між собою через свої властивості, що породжує ситуацію. Ситуації – це взаємозв'язки, що виражають взаємовідносини між об'єктами. Ситуації у предметної області описуються у вигляді висловлювань про предметної області. на даному етапіможна використовувати методи обчислення висловлювань та обчислення предикатів, тобто формальної математичної логіки. Наприклад, вислів "Програміст і менеджер є службовцями компанії" описує ставлення включення. Таким чином, вся інформація про об'єкти та сутності предметної області описується за допомогою тверджень природною мовою.

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

Отже, ставиться завдання розробити систему "АРМ секретаря кафедри", яка б дозволяла вести автоматизований облікданих про співробітників та студентів кафедри ІВТ ОмДТУ, забезпечувала гнучкі можливості при вирішенні запланованих та незапланованих специфічних завдань обробки облікових даних.

У рамках вирішення завдання розробки АРМ секретаря кафедри виділимо такі сутності:

викладачі - викладачі кафедри;

студенти- учні вишу цієї спеціальності;

студенти навчаються в групах, групає організуючою (об'єднавчою) сутністю для студентів;

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

дисципліна- Дисципліна, що викладається (предмет, курс).

Ведені сутності мають низку атрибутів, які ми визначимо надалі.

Ведемо два типи користувачів: рядовий користувач(надалі користувач, і адміністратор. Передбачається, що користувачможе звертатися до системи із запитом, виводити звіти, адміністратордодатково може модифікувати дані. Наприклад, у ролі користувача може бути помічник секретаря кафедри, у ролі адміністратора сам секретар, чи відповідальний викладач.

З урахуванням введених термінів систем, що розробляються, повинна забезпечувати:

організацію повного та достовірного обліку всіх співробітників та студентів кафедри;

інформаційну підтримку прийнятих управлінських рішень, формування повної та достовірної інформації про освітніх процесахта результати діяльності кафедри;

скорочення трудовитрат на підготовку первинних документів та звітів;

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

зручний інтерфейс користувача;

розмежування повноважень рядових користувачів та адміністратора.

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

4. Розробка моделі програмної системи засобами UML

Мова UML є мовою специфікації та візуалізації, основними одиницями її є діаграми.

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

діаграми класів

діаграми об'єктів;

діаграми прецедентів;

діаграми послідовностей;

діаграми кооперації;

діаграми станів;

діаграми дій (діяльності);

діаграми компонентів;

діаграми розгортання.

Концептуальна модель UML

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

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

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

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

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

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

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

На діаграмі розгортання представлена ​​конфігурація обробних вузлів системи та розміщених у них компонентів. Діаграми розгортання відносяться до статичного виду архітектури системи з погляду розгортання. Вони пов'язані з діаграмами компонентів, оскільки у вузлі зазвичай розміщуються один або кілька компонентів.

Тут наведено неповний перелік діаграм, які застосовуються в UML. Інструментальні засоби дозволяють генерувати інші діаграми, наприклад, такі як діаграми профілю баз даних, діаграми WEB-додатків і т.д.

4.1 Розробка виду з погляду прецедентів

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

Прецедент (Use case) - це опис послідовності виконуваних системою дій, яка виробляє спостережуваний результат, значимий для якогось певного акт е ра (Actor). Прецедент застосовується для структурування поведінкових сутностей моделі. Прецедент лише декларує опис будь-якої дії системи, відповідаючи питанням "що робити?", але не вказує якими засобами. Конкретна реалізація поведінки, що специфікується прецедентом, забезпечується класом, кооперацією класів або компонентом.

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

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

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

Повертаючись до моделювання АРМ секретаря кафедри, виділимо прецеденти:

Редагуванняданих,

Пошукстудента,

Пошуквикладача,

Видачаспискущо викладаютьсядисциплін,

Авторизація.

Елементи діаграми прецедентів (прецеденти та актори) мають бути пов'язані відносинами.

Найбільш поширеним ставленням між прецедентами, прецедентами та акторами є асоціація. У деяких випадках можуть бути використані відносини узагальнення. Ці відносини мають той самий сенс, що і на діаграмі класів.

Крім того, між прецедентами в мові UML визначено дві специфічні залежності – відношення включення та відношення розширення.

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

Відносини включення зображуються як залежностей зі стереотипом "include". Щоб специфікувати місце в потоці подій, де базовий прецедент включає поведінку іншого, ви просто пишете слово include, за яким слідує ім'я прецедента.

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

Відношення розширення зображують як залежності зі стереотипом "extend". Точки розширення базового сценарію перераховуються у додатковому розділі. Вони просто мітки, які можуть з'являтися в потоці базового прецеденту.

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

У нашому випадку, прецедент редагуванняданихвключає прецеденти: введенняданих, видаленняданих, змінаданих.

Діаграму прецедентів АРМ секретаря кафедри показано на рис.1.

Мал. 1. Діаграма прецедентів АРМ секретаря кафедри

Прецедент пошукстудентапередбачає пошук на прізвище та пошук за підсумками успішності.

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

Потоки подій можуть бути описані за допомогою неструктурованого тексту, структурованого тексту (що містить службові слова: ЯКЩО,ДОТЕХПІРБУВАЙі т.п.), спеціалізованої формальної мови (псевдокоду).

При описі прецеденту потоком подій важливо позначити також основний і альтернативний потокиповедінки системи.

Наприклад розглянемо опис потоку подій прецеденту авторизація.

Основний потік подій. Прецедент починається, коли система запитує у користувача його вхідне ім'я (Login) та пароль (Password). Користувач може ввести його з клавіатури. Завершується введення натисканням кнопки Enter. Після цього система перевіряє введені Login та пароль, і якщо вони відповідають адміністратору, підтверджує повноваження адміністратора. У цьому прецедент закінчується.

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

Винятковий потік подій. Клієнт може будь-якої миті до натискання клавіші Enter стерти свої Login і пароль.

Винятковий потік подій. Якщо клієнт ввів Login і пароль, що не відповідають адміністратору, йому пропонується зробити повторне введення або увійти в систему на правах пересічного користувача.

Очевидно, що опис прецеденту потоком подій передбачає деякий алгоритм, який можна подати на діаграмі діяльності (рис. 2).

Діаграма алгоритму повинна містити початкову та кінцеву вершини, причому лише одну початкову та одну кінцеву. Діаграма містить виконувані вершини - діяльності (позначаються округленими прямокутниками), умовні вершини (decision - вибір, розпізнавання, позначаються ромбиками) та зв'язку.

Подібними діаграмами можна пояснити виконання інших прецедентів, таким чином доповнити вид системи з точки зору прецедентів використання.

Мал. 2. Авторизація користувача. Діаграма діяльності.

4.2 Розробка виду з погляду проектування

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

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

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

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

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

підтримує чіткий поділ специфікацій абстракції та її реалізації;

зрозумілий і простий, але водночас допускає розширення та адаптацію до нових завдань.

У рамках розробки моделі АРМ секретаря кафедри визначимо класи: викладачі, студенти, аспіранти, дисципліни, групи. Очевидно, що перші мають багато спільних атрибутів, тому введемо абстрактний клас персона, який інкапсулюватиме всі властивості, що відносяться до людини в контексті системи, що розробляється (прізвище, ім'я, адреса і т.д.). В даному випадку персонабуде суперкласом і зв'язуватиметься ставленням узагальнення із класами викладачі, студенти, аспіранти.

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

При моделюванні класу T_ ADRатрибут індексзадаємо за допомогою примітивного типу T_ POSTIDX, Який визначається як шестизначне десяткове число. Примітивні типи моделюються стереотипом type" діапазон значень вказується через обмеження, укладені у фігурні дужки.

В класі викладачвиділимо специфічні атрибути, які стосуються лише викладача: посада, уч. ступінь(наукова ступінь), уч. звання (вчене звання), розряд(Розряд єдиної тарифної сітки). Атрибути уч. ступіньі уч. званнякраще визначити спеціалізованими типами через перерахування. Перерахування моделюються класом із стереотипом " enum" (enumeration - перерахування), допустимі значеннязаписуються як атрибути, мітки, що визначають видимість атрибутів при цьому пригнічуються. У прикладі через перерахування введемо спеціалізовані класи T_Повинен, Т_УчСт, Т_УчЗв, Що визначають відповідно можливі посади, вчені ступені, вчені звання через перерахування В даному випадку, як і скрізь у подібних випадках при створенні класів, що специфікують атрибути основного класу, встановлюються відносини залежності.

Для класу студентвводиться специфічний атрибут номерзаліковки. Для класу аспіранти визначаються специфічними атрибутами. форманавчанняі датанадходження. Форма навчання визначатиметься спеціальним класом через перерахування Т_ФормОбуч(очна, заочна).

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

Клас дисциплінамає атрибути: номер, назва, цикл. Атрибут циклза допомогою введеного через перерахування спеціалізованого типу Т_Цикливизначає до якого циклу відноситься дисципліна: до циклу гуманітарних та соціально-економічних дисциплін, математичних та природничих дисциплін, загальнопрофесійних дисциплін, спеціальних дисциплін.

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

Мал. 3. Діаграма класів АРМ секретаря кафедри (варіант 1)

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

На введеному безлічі класів необхідно визначити зв'язки. Зв'язки узагальнення та залежності були вже визначені, залишилося визначити асоціацію.

Студентиформуються в групи, у разі асоціація матиме вигляд агрегації. Агрегація передбачає відношення типу частина-ціле, позначається суцільною лінією з ромбиком на кінці з боку цілого (у нашому випадку групи). Множинність відношення студенти-групи "багато до одного". Кожна групавідноситься до певної спеціальності, У свою чергу певної спеціальності може відповідати кілька груп, тому асоціація група-спеціальність також має тип множинності "багато до одного".

В даному випадку, як і в більшості інших, напрям асоціацій двосторонній, тому навігацію краще придушувати (зняти галочку в полі Navigable опції Detail Role)

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

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

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

Мал. 4. Діаграма класів АРМ секретаря кафедри (варіант 2)

В кожній групеє староста групи, цей факт можна відобразити додатковою асоціацією (дамо їй ім'я староста) від групи до студентів з типом множинності "один до одного". У разі можна явно вказати навігацію.

Аспірантитакож можуть вести заняття з певної дисципліни у певних груп: асоціації "багато до багатьох" аспіранти-групи, аспіранти-дисципліни. Деякі аспіранти можуть вести заняття, тому тип множинності кінцях асоціації буде 0. n.

Підсумкова діаграма класів наводиться на рис. 3.

Мал. 5. Спрощена діаграма класів

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

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

На рис. 5 поряд з основними класами, відповідними концептуальним елементам системи показано також клас T_ ADR, що розкриває структуру адреси, цей клас також має важливе значення, оскільки містить необхідні елементиданих для викладачіві аспірантів- Нащадків класу персона.

Перейдемо визначення інтерфейсів. Класи взаємодіють з зовнішнім світомчерез інтерфейси.

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

Помістимо на діаграму клас електроннатаблиця, В якому інкапсульовані всі властивості та операції електронної таблиці, що дозволяє редагувати дані. Структуру даного класурозкривати через велику складність не будемо. Так у сучасних засобахРозробки додатків користувач користується готовими класами та шаблонами, успадковуючи їх можливості, наприклад бібліотека VCL (Delphi) містить клас TTable, що інкапсулює можливості електронної таблиці. Нащадки класу електроннатаблицяє конкретними електронними таблицями, що містять конкретні дані щодо викладачів, аспірантів, студентів, груп, дисциплін та спеціальностей. Роблячи відповідні класи нащадками класу електроннатаблиця, ми декларуємо для цих класів всі властивості та операції, властиві електронним таблицям (реєстрацію у системі, вставку, видалення, редагування даних, сортування тощо.).

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

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

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

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

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

Для управління правами доступу та авторизацією користувача введемо клас менеджердоступу. Менеджер доступу має атрибут закритого типу доступу таблицяпаролів, який є екземпляром класу КодірТабл(кодована таблиця), що містить паролі ( password) та вхідні імена ( login) користувачів-адміністраторів. Передбачається, що можливості службового класу КодірТаблне дозволяють сторонньому користувачеві зчитувати паролі користувачів. На даному етапі проектування ми просто декларуємо такі можливості, не зупиняючись на механізмі їх реалізації, але припускаючи, що такі інкапсульовані в клас КодірТабл.

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

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

Мал. 6. Підсумкова діаграма класів АРМ секретаря кафедри

Підсумкова діаграма наводиться на рис. 6.

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

Розглянемо процес створення нового запису про студента засобами діаграми послідовності.

Створення нового запису передбачає права адміністратора, тому дійовою особою цієї взаємодії буде адміністратор ( адмін). Цей елемент вже був введений на діаграмі прецедентів, тому перетягнемо його на діаграму послідовності з браузера виду з погляду прецедентів.

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

Ведемо об'єкти: формавведення, менеджерзаписів, запис про студента Петрове(як конкретний приклад запису про студента), менеджертранзакцій. Цей набіроб'єктів є типовим при модифікації запису таблиці бази даних.

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

Менеджерзаписів- об'єкт, що має стандартний набір можливостей з управління даними при роботі з електронною таблицею. Цей набір можливостей успадковується класом студентивід класу електроннатаблиця. Для об'єкту Менеджерзаписівявно вказується клас, екземпляром якого він є - студенти.

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

Менеджертранзакцій- об'єкт, що забезпечує виконання закінченої операції над базою даних, у разі створення нового запису про студента Петрова. На цей об'єкт покладається виконання ряду системних функцій, що супроводжують трансакцію Прикладом менеджерів трансакцій є, наприклад, BDE (використовуються для доступу з програм Delphi до баз даних Paradox, Dbase та ін), ADO (використовується для доступу до баз MS Access з різних програм).

Діаграма послідовності введення нового запису про студента в АРМ секретаря кафедри представлена ​​на рис. 7.

Мал. 7. Введення даних про студента. Діаграма послідовності.

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

За бажання можна дана взаємодіяподати діаграмою кооперації, що ілюструє насамперед структурний аспект взаємодії (рис.8). Цю діаграмуможна побудувати з попередньої автоматичному режимі(У Rational Rose натисканням клавіші F5).

Мал. 8. Введення даних про студента. Діаграма кооперації.

За потреби проект можна доповнити й іншими діаграмами взаємодії, які розкривають роботу прецедентів.

4.3 Розробка профілю реляційної бази даних

Якщо для реалізації системи використовується об'єктно-орієнтована СУБД (ООСУБД), побудована в попередньому розділі діаграма об'єктів є остаточною моделлю і прямим керівництвом до реалізації інформаційної системи. В тому ж випадку, коли як інформаційне ядро ​​інформаційної системи передбачається використовувати реляційну базу даних (РБД), необхідно розробити ще одну діаграму, діаграму профілю реляційної бази даних.

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

Таблиця ( Table) - набір записів у базі даних за певним об'єктом, складається зі стовпців.

Стовпець ( Column) - компонент таблиці, що містить один із атрибутів таблиці (поле таблиці).

Первинний ключ ( Primary key) – можливий ключ, вибраний для ідентифікації рядків таблиці.

Зовнішній ключ (Foreign key) - один або кілька стовпців однієї таблиці, що є первинними ключамиіншої таблиці.

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

Зберігаючи процедура ( Stored procedure) – незалежна процедурна функція, що виконується на сервері.

Домени ( Domains) – допустимий набір значень для атрибуту або стовпця.

Крім даних сутностей можуть бути введені деякі додаткові сутності, що відображають специфічні аспектимоделі БД.

Подібні документи

    Методології розробки інформаційних систем у вітчизняній та зарубіжній літературі. Державні та міжнародні стандарти у галузі розробки програмного забезпечення. Розробка фрагменту інформаційної системи „Навчально-методичний ресурс”.

    курсова робота , доданий 28.05.2009

    Визначення поняття "система". Історія розвитку та особливості сучасних інформаційних систем. Основні етапи розвитку автоматизованої інформаційної системи. Використання вітчизняних та міжнародних стандартіву галузі інформаційних систем.

    презентація , додано 14.10.2013

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

    презентація , доданий 02.04.2013

    Роль структури управління інформаційної системі. Приклад інформаційних систем. Структура та класифікація інформаційних систем. Інформаційні технології. Етапи розвитку інформаційних технологій. Види інформаційних технологій.

    курсова робота , доданий 17.06.2003

    Поняття CASE-засобів як програмних засобів, що підтримують процеси створення та супроводу інформаційних систем (ІС). Особливості IDEF-технології розробки ІВ. Опис нотації IDEF0. Розробка функціональних моделей бізнес-процесу.

    презентація , додано 07.04.2013

    Сутність уніфікованої мови моделювання, її концептуальна модель та принцип дії, загальні правилата механізми. Моделювання поняття "компетентність". Діаграма класів, що описують навчальний процес. Реалізація заданої інформаційної системи.

    дипломна робота , доданий 17.02.2015

    Розвиток інформаційних систем. Сучасний ринокфінансово-економічного прикладного програмного забезпечення Переваги та недоліки впровадження автоматизованих інформаційних систем. Методи проектування автоматизованих інформаційних систем.

    дипломна робота , доданий 22.11.2015

    Поняття інформаційної системи, види інформаційних систем. Аналіз інструментальних засобівдля розроблення автоматизованих інформаційних систем. Вимоги до програми та програмного виробу. Розробка форм графічного інтерфейсу та баз даних.

    дипломна робота , доданий 23.06.2015

    Рішення щодо інформаційної безпеки. Системи для датацентрів. Що таке обладнання центру обробки даних | Основні поняття та принципи моделювання. Вибір способу вирішення завдань. Метод допустимих напрямів Зойтендійка, алгоритм Франка-Вульфа.

    курсова робота , доданий 18.05.2017

    Концепція інформаційної системи. Етапи розвитку інформаційних систем. Процеси інформаційної системі. Інформаційна система з відшукання ринкових ніш, зниження витрат виробництва. Структура інформаційної системи Технічне забезпечення.

"Комп'ютерне математичне моделювання" Завдання вивчення розділу. Опанування моделюванням як шляхом пізнання навколишньої дійсності (науково-дослідницький характер розділу) - показується, що моделювання у різних галузях знань має схожі риси, найчастіше для різних процесів вдається отримати дуже близькі моделі; - демонструються переваги та недоліки комп'ютерного експериментупорівняно з натурним експериментом; - Показується, що і абстрактна модель, і комп'ютер надають можливість пізнавати навколишній світ, керувати ним на користь людини. Вироблення практичних навичок комп'ютерного моделювання. Дається загальна методологія комп'ютерного математичного моделювання. На прикладі низки моделей із різних галузей науки і практики практично реалізуються всі етапи моделювання від постановки завдання до інтерпретації результатів, отриманих під час комп'ютерного експерименту. Сприяння професійної орієнтації учнів. Виявлення схильності учня до дослідницької діяльності, розвиток творчого потенціалу, орієнтація на вибір професії, пов'язаної з науковими дослідженнями Подолання предметної роз'єднаності, інтеграція знань. В рамках курсу вивчаються моделі різних галузей науки з використанням математики. Розвиток та професіоналізація навичок роботи з комп'ютером. Опанування ППО загального та спеціалізованого призначення, системами програмування.


Поняття моделі є ключовим у загальної теоріїсистем. Моделювання як потужний – а часто й єдиний – метод дослідження передбачає заміщення реального об'єкта іншим – матеріальним чи ідеальним.
Найважливішими вимогами до будь-якої моделі є її адекватність об'єкту, що вивчається, в рамках конкретного завдання і реалізованість наявними засобами.
У теорії ефективності та інформатики моделлю об'єкта (системи, операції) називається матеріальна або ідеальна (подумки) система, створювана та/або використовувана при вирішенні конкретного завдання з метою отримання нових знань про об'єкт-оригінал, адекватна йому з точки зору досліджуваних властивостей і більше проста, ніж оригінал, в інших аспектах.
Класифікація основних методів моделювання (і відповідних їм моделей) представлена ​​на рис. 3.1.1.
При дослідженні економічних інформаційних систем (ЕІС) знаходять застосування всі методи моделювання, однак у цьому розділі основна увага буде приділена семіотичним (знаковим) методам.
Нагадаємо, що семіотикою (від грецьк. semeion - знак, ознака) називають науку про загальних властивостяхзнакових систем, т. е. систем конкретних чи абстрактних об'єктів (знаків), з кожним у тому числі зіставлено деяке значення . Прикладами таких систем є будь-які мови

Мал. 3.1.1. Класифікація методів моделювання

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

Ще за темою 3. ТЕХНОЛОГІЯ МОДЕЛЮВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ Методи моделювання систем:

  1. Імітаційні моделі економічних інформаційних систем Методологічні засади застосування методу імітаційного моделювання
  2. Розділ III ОСНОВИ МОДЕЛЮВАННЯ СИСТЕМИ МАРКЕТИНГУ ПОСЛУГ
  3. РОЗДІЛ 1. ДИНАМІЧНІ СИСТЕМИ, ЯКІ КЕРУЮТЬСЯ, ЯК ОБ'ЄКТ КОМП'ЮТЕРНОГО МОДЕЛЮВАННЯ
  4. Основи структурного моделювання маркетингової системи медичних послуг
  5. Розділ IV ПРИКЛАД ПРИКЛАДНОГО ВИКОРИСТАННЯ МОДЕЛІ СИСТЕМИ МАРКЕТИНГУ В ІМІТАЦІЙНОМУ МОДЕЛЮВАННІ
  6. Концепція моделювання фінансової сфери маркетингових систем

Навчальний посібник для вузів

2-ге вид., перераб. та дод.

2014 м.

Тираж 1000 екз.

Формат 60х90/16 (145x215 мм)

Виконання: у м'якій обкладинці

ISBN 978-5-9912-0193-3

ББК 32.882

УДК 621.395

Гриф УМО
Рекомендовано УМО з освіти в галузі телекомунікацій як навчального посібникадля студентів вищих навчальних закладів, які навчаються за спеціальностями «Мережі та системи комутації», «Многоканальні телекомунікаційні системи»

Анотація

Розглянуто алгоритми моделювання дискретних та безперервних випадкових величинта процесів. Викладено принципи та алгоритми моделювання інформаційних сигналів, описуваних Марківськими процесами з дискретним та безперервним часом Розглянуто принципи моделювання систем масового обслуговування. Описано особливості опису та використання фрактальних та мультифрактальних процесів для моделювання телекомунікаційного трафіку. Аналізуються методи та приклади моделювання інформаційних систем з використанням спеціалізованих пакетів прикладних програм Matlab, Opnet, Network simulator.

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

Вступ

1 Загальні принципи моделювання систем
1.1. Загальні поняттямоделі та моделювання
1.2. Класифікація моделей
1.3. Структура моделей
1.4. Методологічні засади формалізації функціонування складної системи
1.5. Моделювання компонентів
1.6. Етапи формування математичної моделі
1.7. Імітаційне моделювання
Контрольні питання

2 Загальні принципи побудови систем та мереж зв'язку
2.1. Концепція побудови систем та мереж зв'язку
2.2. Багаторівневі моделі мережі
2.2.1. Трирівнева модель
2.2.2. Архітектура протоколів ТСР/ІР
2.2.3. Еталонна модель OSI
2.3. Структура мереж зв'язку
2.3.1. Глобальні мережі
2.3.2. Локальні обчислювальні мережі
2.3.3. Топології обчислювальної мережі
2.3.4. Локальні мережі Ethernet
2.4. Мережі Frame Relay
2.5. IP-телефонія
Контрольні питання

3 Моделювання випадкових чисел
3.1. Загальні відомості про випадкові числа
3.2. Програмні методи генерування рівномірно розподілених випадкових чисел
3.3. Формування випадкових величин із заданим законом розподілу
3.3.1. Метод зворотних функцій
3.3.2. Наближені методи перетворення випадкових чисел
3.3.3. Метод відсіювання (метод генерації Неймана)
3.4. Методи, що ґрунтуються на центральній граничній теоремі
3.5. Алгоритми моделювання часто вживаних випадкових величин
3.6. Алгоритми моделювання корельованих випадкових величин
3.7. Формування реалізацій випадкових векторів та функцій
3.7.1. Моделювання n-вимірної випадкової точки з незалежними координатами
3.7.2. Формування випадкового вектора (у рамках кореляційної теорії)
3.7.3. Формування реалізацій випадкових функцій

4 Моделювання дискретних розподілів
4.1. Розподіл Бернуллі
4.2. Біноміальний розподіл
4.3. Розподіл Пуассона
4.4. Моделювання випробувань у схемі випадкових подій
4.4.1. Моделювання випадкових подій
4.4.2. Моделювання протилежних подій
4.4.3. Моделювання дискретної випадкової величини
4.4.4. Моделювання повної групи подій
4.5. Потоки подій
4.6. Обробка результатів моделювання
4.6.1. Точність та кількість реалізацій
4.6.2. Первинна статистична обробкаданих
Контрольні питання

5 Алгоритми моделювання стохастичних сигналів та перешкод у системах зв'язку
5.1. Алгоритм моделювання нестаціонарних випадкових процесів
5.2. Алгоритми моделювання стаціонарних випадкових процесів
5.3. Методи моделювання сигналів та перешкод у вигляді стохастичних диференціальних рівнянь
5.4. Приклади моделей випадкових процесів у системах зв'язку
5.4.1. Моделі інформаційних процесів
5.4.2. Моделі перешкод
5.4.3. Характеристика основних видів перешкод
Контрольні питання

6 Марківські випадкові процеси та їх моделювання
6.1. Основні поняття марковського випадкового процесу
6.2. Основні властивості дискретних ланцюгів Маркова
6.3. Безперервні марківські ланцюги
6.3.1. Основні поняття
6.3.2. Напівмарківські процеси
6.3.3. Процеси загибелі та розмноження
6.4. Моделі безперервних марківських випадкових процесів на основі стохастичних диференціальних рівнянь
6.5. Моделювання марківських випадкових процесів
6.5.1. Моделювання дискретних процесів
6.5.2. Моделювання скалярних безперервнозначних процесів
6.5.3. Моделювання безперервнозначних векторних процесів
6.5.4. Моделювання гаусівського процесу із дробово-раціональною спектральною щільністю
6.5.5. Моделювання багатозв'язкових послідовностей
6.5.6. Моделювання марківських процесів за допомогою формувальних фільтрів
6.5.7. Алгоритм статистичного моделювання марківських кіл
Контрольні питання

7 Приклади марківських моделей
7.1. Марківські моделі мовного діалогу абонентів
7.1.1. Стан мовного сигналу
7.1.2. Моделі діалогу
7.2. Марківські моделі мовного монологу
7.3. Пуасонівський процес, керований марківським у моделях мови
7.4. Марківські моделі цифрових послідовностей на виході кодеку G.728
7.5. Статистичне ущільнення джерела мовних пакетів з урахуванням марківської моделі телефонного діалогу
7.6. Марківська модель бездротового каналуз механізмом ARQ/FEC
7.7. Пакетування помилок
7.8. Розрахунок характеристик потоку помилок за параметрами моделі
7.8.1. Оцінка параметрів потоку помилок
7.8.2. Оцінка адекватності моделі потоку помилок
7.9. Марківські моделі оцінки QoS мультимедійних сервісів реального часу в Інтернеті
7.9.1. Поняття мультимедійних сервісів реального часу
7.9.2. Аналіз та моделювання затримок та втрат
7.10. Моделі потоків мультимедійного трафіку
Контрольні питання

8 Системи масового обслуговування та їх моделювання
8.1. Загальна характеристика систем масового обслуговування
8.2. Структура системи масового обслуговування
8.3. Системи масового обслуговування з очікуванням
8.3.1. Система обслуговування M/M/1
8.3.2. Система обслуговування M/G/1
8.3.3. Мережі з більшим числомвузлів, з'єднаних каналами зв'язку
8.3.4. Пріоритетне обслуговування
8.3.5. Система обслуговування M/M/N/m
8.4. Системи масового обслуговування із відмовими
8.5. Загальні засади моделювання систем масового обслуговування
8.5.1. Метод статистичних випробувань
8.5.2. Блокові моделі процесів функціонування систем
8.5.3. Особливості моделювання з використанням Q-схем
Контрольні питання

9 Моделювання інформаційних систем з використанням типових технічних засобів
9.1. Моделювання систем та мови програмування
9.2. Основні відомості про мову GPSS
9.2.1. Динамічні об'єкти GPSS. Транзактно-орієнтовані блоки (оператори)
9.2.2. Апаратно-орієнтовані блоки (оператори)
9.2.3. Багатоканальне обслуговування
9.2.4. Статистичні блоки GPSS
9.2.5. Операційні блоки GPSS
9.2.6. Інші блоки GPSS
9.3. Імітаційне моделювання мережі ETHERNET у середовищі GPSS
Контрольні питання

10 Моделювання систем передачі
10.1. Типова системапередачі даних
10.2. Перешкодостійкість передачі дискретних сигналів. Оптимальний прийом
10.3. Оцінка ймовірності помилкового прийому дискретних сигналів із повністю відомими параметрами
10.4. Перешкодостійкість дискретних сигналів із випадковими параметрами
10.5. Перешкодостійкість дискретних сигналів при некогерентному прийомі
10.6. Перешкодостійкість дискретних сигналів з випадковими суттєвими параметрами
10.7. Алгоритми формування дискретних сигналів
10.8. Алгоритм формування перешкоди
10.9. Алгоритм демодуляції дискретних сигналів
10.10. Структура імітаційного комплексу та його підпрограм
10.11. Програмне середовище Mathworks Matlab та пакет візуального моделювання Simulink
10.11.1. Технічний описта інтерфейс
10.11.2. Пакет візуального моделювання Simulink
10.11.3. Створення та маскування підсистем
10.11.4. Пакет розширень Communications Toolbox
10.12. Моделювання блоків системи передачі даних стандарту WiMAX
10.12.1. Моделювання передавача
10.12.2. Моделювання каналу передачі
10.12.3. Моделювання приймача
10.12.4. Реалізація моделі в системі Mathlab
10.13. Результати імітаційного моделюваннясистеми WiMAX
Контрольні питання

11 Самоподібні процеси та їх застосування в телекомунікаціях
11.1. Основи теорії фрактальних процесів
11.2. Мультифрактальні процеси
11.3. Оцінка показника Херста
11.4. Мультифрактальний аналіз із використанням програмного забезпечення
11.4.1. Опис програмного забезпечення
11.4.2. Приклади оцінки ступеня самоподібності
11.5. Алгоритми та програмне забезпечення для мультифрактального аналізу
11.6. Вплив самоподібності трафіку на характеристики системи обслуговування
11.7. Методи моделювання самоподібних процесів у телетрафіку
11.8. Дослідження самоподібної структури трафіку Ethernet
11.9. Перевантажувальне керування самоподібним трафіком
11.10. Фрактальний броунівський рух
11.10.1. RMD-алгоритм генерації ФБД
11.10.2. SRA-алгоритм генерації ФБД
11.12. Фрактальний Гаусівський шум
11.12.1. БПФ-алгоритм синтезу ФГШ
11.12.2. Оцінка результатів моделювання
Контрольні питання

12 Моделювання вузла телекомунікаційної мережі
12.1. Основні положення протоколу Frame Relay
12.2. Проектування вузла мережі Frame Relay
12.3. Результати імітаційного моделювання маршрутизатора FR із кодеками G.728 на вході
12.4. Вплив самоподібності трафіку на QoS
Контрольні питання

13 Спеціалізовані системи імітаційного моделювання обчислювальних мереж
13.1. Загальна характеристика спеціалізованих пакетів прикладних програм мережевого моделювання
13.2. Загальні принципи моделювання серед OPNET Modeler
13.3. Приклади застосування OPNET
13.3.1. Модель для оцінки якості обслуговування
13.3.2. Реалізація моделі локальної мережі
Контрольні питання

14 Імітаційне моделювання за допомогою мережного імітатора Network simulator 2
14.1. Історія створення та архітектура пакету NS2
14.2. Створення об'єкта імітатора
14.3. Створення топології мережі
14.4. Завдання параметрів генераторів
14.4.1. Exponential On/Off
14.4.2. Pareto On/Off
14.5. Два основні алгоритми організації черги
14.6. Адаптивна маршрутизація в NS2
14.6.1. Інтерфейс прикладного програмування на рівні користувача
14.6.2. Внутрішня архітектура
14.6.3. Розширення на інші класи
14.6.4. Недоліки
14.6.5. Список команд, що використовуються для імітації динамічних сценаріїв у NS2
14.6.6. приклад динамічна маршрутизаціяу NS2
14.7. Запуск програми сценарію в NS2
14.8. Процедура обробки результатів моделювання
14.9. Приклад моделювання бездротової мережі
14.10. Приклад імітаційного моделювання якості передачі потокового відеоз використанням пакета NS 2
14.10.1. Структура програмно-апаратного комплексу для оцінки якості потокового відео
14.10.2. Функціональні модулі ПАК
14.10.3. Оцінка якості відео

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

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

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

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

У зв'язку з диверсифікацією діяльності надійшло замовлення від керівництва фірми «Безенчук та компаньйони» на розробку інформаційної системи з метою підвищення ефективності управління.

Фірма займається виробництвом та реалізацією меблів. Є каталог типових меблів, вироблених фірмою. Замовник може вибрати меблі за каталогом та/або зробити замовлення по власним описом. Після формування замовлення складається договір. Фірма приймає у замовників нових меблів старі меблі, вартість яких віднімається з ціни замовлення. Прийняті старі меблі виставляються на продаж або можуть бути здані на прокат. Після закінчення певного терміну незатребувані старі меблі здаються на дров'яний склад. Ведеться архів з інформацією про виконані замовлення. Клієнти, які раніше укладали договори з фірмою, отримують знижку під час укладання нового договору. Матеріали та комплектуючі, необхідні для виготовлення меблів, фірма купує у постачальників.

Функціональне моделювання ІВ

Існує кілька різних методик та засобів розробки структурно-функціональних моделей ІВ. Одним з поширених є метод, заснований на побудові діаграм потоків даних (DFD - Data Flow Diagrams)

Діаграма потоків даних

DFD - метод структурного аналізу, що оперує поняттями "потік даних" і "процес" для опису системи у вигляді набору функціональних компонентів (процесів), пов'язаних потоками даних. Відповідно до основного принципу структурного аналізу опис системи ґрунтується на послідовній деталізації її функцій, яка відображається у вигляді ієрархічно організованого набору графічних образів (діаграм).

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

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

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

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

Наприклад, функція ІВ, призначена для формування замовлення меблів та укладання договору на її виготовлення, на діаграмі може бути представлена ​​процесом «замовлення меблів». Цей процес як вхідні дані повинен отримувати інформацію про замовника, необхідну для укладання договору і інформацію про меблі, що їм замовляються (тип, опис, розміри та ін.). Графічне зображенняцього процесу та відповідних потоків даних:

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

Контекстна діаграма

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

Контекстна діаграма для описаного вище прикладу наведено на рис.4.

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

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

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

Для «клієнта-покупця» потік даних «каталог старих меблів» - це відомості про наявні старі меблі, прийняті від замовників. Потік «купівля/прокат старих меблів» - це інформація про обрані клієнтом старі меблі, які він бажає придбати або взяти на прокат.

У той же час на практиці можливі ситуації, коли клієнт-замовник і клієнт-покупець будуть однією і тією ж особою.



ПОХОДЖЕННЯ СТАТТІ