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

Наступною задачею при описі предметної області є моделювання документів.

Ціль моделювання документів – описати атрибути документів, їхні типи, значення, правила формування для:

1. Проектування користувальницького інтерфейсу системи;

2. Проектування Бази даних системи;

3. Формування альбому вихідних форм системи.

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

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

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

ІНФОРМАЦІЙНЕ ЗАБЕЗПЕЧЕННЯ

Вхідна інформація, тобто дані, що використовуються як вхідні для прийняття рішень системою:

· Ім‘я слухача;

· Прізвище слухача;

· Дата народження слухача;

· Ідентифікаційний номер.

Вихідна інформація. Такою інформацією є дані, що з’являються в результаті роботи системи:

· Оцінка за випускні іспити;

· Номер отриманого диплома.

АЛГОРИТМ РОЗВ ’ЯЗАННЯ ЗАДАЧІ

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

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

Загальний алгоритм розв’язання задачі такий: використовуємо Usecasedіagram для відображення списку операцій, що повинна виконувати наша система. Кожен Usecase - це деякий процес (послідовність дій), тому ми повинні використовувати Sequencedіagram для його деталізації. На цій діаграмі ми відображаємо об'єкти з предметної області (об'єкти, що беруть участь у процесі); таким чином, ми одержуємо екземпляри деяких класів і їхню взаємодію. Sequencedіagram відображає сам процес, статична картина взаємодії об'єктів відображається за допомогою Classdіagram. Переходимо до Classdіagram, на якій зображуються класи нашого проекту. Далі класи поєднуються в компоненти, що відображаються на Componentdіagram, де показується залежність компонентів між собою. В даному випадку нам не потрібно створюватиDeploymentdіagram, на якій відображається розміщення компонентів на комп'ютерах.

Першою була створена діаграма прецедентів. Вона має вигляд, який показаний на малюнку 1

Малюнок 1 Use Case Diagram (Main)

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

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

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

Наступною була створена діаграма класів, яка зображена на малюнку 2.

Малюнок 2 Classdiagram