2.2. Моделювання системи

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

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

Така діаграма явно демонструє функції, розробленого мною проекту модуля «Облік персоналу» для автоматизованої інформаційної системи «Управління персоналом корпорації». Контекстна та декомпозована діаграма зображені на рис.2.4 та рис.2.5.

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

Рис 2.5 Декомпозована діаграма

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

Діаграми варіантів використання призначені для:

• Визначення спільного кордону функціональності проектованої системи;

• Сформулювати загальні вимоги до функціонального поведінки проектованої системи

• Розробка вихідної концептуальної моделі системи;

• Створення основи для виконання аналізу, проектування, розробки і тестування.

Діаграма варіантів використання складається з ряду елементів. Основними елементами є: варіанти використання або прецедент (use case), актор або дійова особа (actor) і відносини між акторами і варіантами використання (relationship).

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

Рис 2.6 Варіанти використання керівником проекту модуля «Облік персоналу».

Рис 2.7 Варіанти використання персоналом проекту модуля «Облік персоналу».

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

Фактично даний тип діаграм може використатися й для відбиття станів модельованого об'єкта, однак, основне призначення діаграми активності (аctіvіty dіagram) у тому, щоб відбивати бізнес-процеси об'єкта. Цей тип діаграм дозволяє показати не тільки послідовність процесів, але й розгалуження й навіть синхронізацію процесів. Він дозволяє проектувати алгоритми поводження об'єктів будь-якої складності.

У контексті мови UML діяльність (actіvіty) являє собою сукупність окремих обчислень, виконуваних автоматом, що приводять до деякого результату або дії (actіon). На діаграмі діяльності відображається логіка й послідовність переходів від однієї діяльності до іншої, а увага аналітика фокусується на результатах. Результат діяльності може привести до зміни стану системи або поверненню деякого значення.

Рис.2.8 Блок-схема роботи проекту модуля «Облік персоналу».

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

Існує два види діаграм взаємодії: діаграми послідовності (sequence dіagrams) і кооперативні, або співробітництва (collaboratіon dіagrams). Діаграми послідовності визначають тимчасову послідовність переданих повідомлень, порядок, вид і тип повідомлення, що відбуваються в рамках варіанта використання.

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

Рис.2.9 Діаграма взаємодії персоналу та керівника за допомогою проекту модуля «Облік персоналу».

2.2.5 Модель бази даних. Модель сутність-зв'язок (ER-модель) (англ. entity-relationship model, ERM) – модель даних, що дозволяє описувати концептуальні схеми предметної області.

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

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

ER-модель являє собою формальну конструкцію, яка сама по собі не наказує ніяких графічних засобів її візуалізації. У якості стандартної графічної нотації, за допомогою якої можна візуалізувати ER-модель, була запропонована діаграма сутність-зв'язок (ER-діаграма) (англ. entity-relationship diagram, ERD).

Рис.2.10 Модель ЕR- діаграм

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

Побудова схеми бази даних

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

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

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

Рис.2.11 Схема даних