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