днак він є оптимальним тільки при недовантаження системи, але в умовах перевантаження веде себе досить погано.
Даний метод часто вважається небезпечним через те, що за умови перевантаження системи він може показати небажану поведінку. Однак під час роботи жорстких систем реального часу перевантажень не повинно виникати, тому що невиконання крайнього терміну завдання може призвести до серйозних наслідків. Тому для таких систем необхідно проводити апріорне доказ того, що коли у всіх завдань у системі одночасно виникнуть потреби в системних ресурсах, то всі їх обмеження за часом і раніше будуть виконані. p> 2.3.2.5. Сервер, припускає затримку (DS) і Алгоритм обміну пріоритетами (PE).
Ці методи зберігають доступними ресурси системи, спочатку виділені для апериодических завдань.
Ці методи покращують середній час відповіді системи і відрізняються один від одного способом збереження пропускної здатності. PE алгоритм роздає час виконання, виділений для роботи високопріоритетного періодичного сервера, іншим періодичних завданням з меншим пріоритетом, якщо воно не потрібно для роботи апериодических завдань. p> На відміну від нього DS не віддає час виконання цієї завдання, коли не залишилося жодної апериодической завдання. Замість цього він зберігає це високопріоритетних час виконання або поки не прибуде аперіодична завдання, або поки не закінчиться період сервера. p> Цей метод простіше в реалізації, але гірше у виконанні.
2.4. Методологія розробки програмного забезпечення. p> 2.4.1. Основи методології Real. p> Не зупиняючись, загалом, на процесі розробки програмного забезпечення, перелічимо, які моделі використовуються в Real для опису розроблюваної системи:
В· Модель вимог до системі:
Описова модель - в текстовому вигляді описує деякі вимоги до системи. p> Модель випадків використання - описує вимоги, пред'являються системі її оточенням, тобто відповідає на питання "що і для кого повинна робити система? ". p> Функціональна модель - описує розбиття випадків використання і функцій на підфункції. Дає відповідь на питання "як повинні реалізовуватися функції системи в термінах своїх подфункций? ". p> В· Динамічна модель:
Модель об'єктів - описує ролі об'єктів системи та відповідає на запитання "які об'єкти взаємодіють при виконанні функцій системи?". p> Модель взаємодій - описує сценарії взаємодії об'єктів системи між собою і з користувачами, тобто дає відповідь на питання "як об'єкти взаємодіють один з одним для виконання функцій системи? ". p> Поведінкова модель - описує алгоритми поведінки об'єктів системи, тобто відповідає на питання "як повинен вести себе кожен об'єкт для реалізації функцій системи? ". p> В· Статична модель:
Модель класів - описує внутрішню структуру системи, структури даних, використовувані в ній, тобто відповідає на питання "як повинна виглядати система зсередини? ". p> У Real великий упор був зроблений на зв'язність моделей, на контроль цілісності інформації про проект, представленої всередині як однієї моделі, так і в декількох.
2.4.2. Модель вимог. p> Робота над системою в Real починається з побудови описової моделі, в яку, насамперед, входять первинні вимоги замовника. Серед них можуть бути як функціональні вимоги, так і будь-які інші (ефективність, вартість і т.п.). Описова модель зберігається в Real у вигляді звичайного тексту і формально не пов'язана з іншими моделями. Ця модель може бути використана і для остаточної специфікації нефункціональних вимог. p> На основі вимог замовника формулюється повний список функціональних вимог до системи, які оформляються в термінах моделі випадків використання і моделі функцій. Остаточне технічне завдання на систему може бути згенеровано за моделлю вимог Real у тому вигляді, який потрібен замовнику (ГОСТ, якої міжнародний або внутрішньокорпоративний стандарт і т.п.). p> Модель випадків використання в Real призначена для опису стику системи з оточенням. В її термінах описуються всі користувачі системи, а також всі її функції (випадки використання), помітні з точки зору цих користувачів. Надалі з використанням можуть бути пов'язані класи. Для випадків використання, у свою чергу, можна створювати діаграми цього ж типу, тобто піддавати випадки використання подальшої декомпозиції в рамках тієї ж моделі. p> Функціональна модель призначена для подальшої декомпозиції функцій системи. Вона складається з набору дерев функцій, корінням яких є випадки використання. Дерево може містити вузли двох видів: власне функції і використання описаних раніше функцій. Крім того, функція може мати властивість груповий, це означає, що її "діти" фактично перебувають замість неї на тому ж місці. Зв'язок батьківського вузла з дочірніми може мати мітку, описує характер у зв'язку. p> Відзначимо, що модель випадків використання в Real є підмножиною однойменної моделі UML. Те, що в UML робиться за допом...
