, що описує прецедент, різна, але типове опис має містити наступні розділи:
короткий опис;
предусловия;
- деталізований опис потоку подій: основний потік і альтернативні потоки;
- постумови.
Для подальшого більш докладного розгляду та документування виділяється прецедент «Організації віддаленого обміну даними».
Наведемо описову специфікацію даного прецеденту:
прецедент дає можливість користувачу пройти ідентифікацію для отримання доступу на сервер;
основний потік: після запуску FTP протоколу користувач підключається під своїм логіном і паролем до серверного додатком для обміну файлами. Альтернативний потік: клієнт може передавати і приймати інформацію в тому випадку, якщо адміністратор не обмежив його правами доступу;
якщо прецедент закінчився успішно, отримані результати автоматично зберігаються і відображаються без повідомлень про помилки.
Діаграма прецедентів показана на малюнку 3.1.
Малюнок 3.1. Діаграма прецедентів
. 3 Побудова діаграми послідовності
Діаграма послідовності показує обмін повідомленнями між об'єктами, впорядкованими у вигляді тимчасової послідовності.
У процесі ICONIX діаграми послідовності - це основний робочий продукт проектування. Для кожного прецеденту створюється діаграма, що описує головну і альтернативну послідовності дій. У результаті виходить ядро ??динамічної моделі, в якому визначено поведінку системи під час виконання і те, як реалізується це поведінка. Діаграма послідовності складається з чотирьох основних елементів:
тексту послідовності дій в прецеденті, який записується зверху вниз по лівій стороні;
об'єктів, перенесених прямо з діаграми придатності та представлених у вигляді прямокутників, в яких у форматі «об'єкт: клас» записується ім'я або номер примірника об'єкта та ім'я класу об'єкта;
повідомлень, зображуваних стрілками, які спрямовані від одного об'єкта до іншого;
методів (операцій), які подаються у вигляді прямокутників. Вони розташовані на пунктирних лініях, що відповідають тим об'єктам, яким методи належать. Довжину прямокутника можна використовувати для того, щоб показати фокус управління в послідовності: метод володіє управлінням аж до точки, в якій прямокутник кінчається.
Діаграма послідовності показана на малюнку 3.2.
Рисунок 3.2. Діаграма послідовності
Рисунок 3.2. Діаграма кооперації
. 4 Діаграма класів
Систему утворює системне стан. Стан є функцією вмісту системної інформації в заданий момент часу. Визначення стану системи описується в моделі класів. Розрізняють класи-сутності, які визначають інформацію системи; прикордонні класи, які визначають GUI-об'єкти; для управління програмної логікою існують керуючі класи.
Моделювання класів - ітеративний покроковий процес.
На початку розробки програмного забезпечення будується модель предметної області, яка служить для виявлення об'єктів, що використовуються в діаграмі класів.
Моделювання класів призводить до функціонального підходу, прихильники об'єктно-орієнтованого підходу воліють називати його проблемно-орієнтованим.
Діаграма класів показана на малюнку 3.3.
Малюнок 3.4 Діаграма класів
Висновок
Слід зауважити, що застосовуються в даній роботі технології, зокрема технологія віртуалізації, були розроблені порівняно давно. Теоретичні основи були підготовлені провідними математиками ще на початку минулого століття. Проте зважаючи несовершенности апаратних засобів того часу, вони набули застосування набагато пізніше.
На якомусь етапі еволюції архітектури обчислювальних машин відмова від багатьох блискучих ідей минулого став історичною необхідністю. Незважаючи на це, останнім часом спостерігається зворотний процес, коли багато концепції золотого століття кібернетики переглядаються і знаходять застосування в сучасних інформаційних технологіях.
Однією з головних функцій віртуалізації є захист фізичної системи від випадкових збоїв, помилкових дій користувача, а також навмисних спроб вивести її з ладу. Середа, в якій, працює користувач, а також додатки користувацького рівня, в даному випадку, є максимально абстрагованими від фізичного середовища системи. У перебігу всього часу з моменту виникнення віртуальні машини вико...
