огою не увійшла в Real частини моделі випадків використання, в Real пропонується робити за допомогою моделі функцій, яка є варіацією функціональної моделі із структурних методологій розробки програмного забезпечення. Модель функцій Real заснована на моделі функцій SDL, однак звідти були прибрані деякі деталі (В Real НЕ передбачається так широко використовувати модель функцій, оскільки не хотілося б підштовхувати розробника до алгоритмическому методом розробки системи) і додані використання функцій, групи функцій, а також зв'язок з моделлю випадків використання.
2.4.3. Динамічна модель. p> Вона описує поведінку системи - взаємодія між різними її компонентами, взаємодія системи з її оточенням і поведінку самих компонент. p> На початкових етапах розробки можна дотримуватися однієї з двох стратегій. Перша: спочатку уточняти класи системи, а потім об'єкти і сценарії взаємодії. Вона буде використовуватися з більшою ймовірністю, якщо розробникам добре знайома предметна область. Можлива і інша стратегія - у тому випадку, якщо на етапі аналізу доводиться вивчати незнайому предметну область. Основне призначення моделі об'єктів - опис різних ролей, які можуть відігравати екземпляри класів системи. Кожній функції з функціональної моделі Real можна зіставити діаграму об'єктів, призначення якої - описати типову "конфігурацію" об'єктів, задіяних у здійсненні даної функції, а також описати зв'язки між ними. При використанні об'єктно-орієнтованого підходу виконання функцій системи реалізується як спільна діяльність декількох об'єктів. Основними її елементами є об'єкти-ролі і відносини між ними.
Динаміку взаємодії об'єктів для реалізації функції ( модель взаємодії ) зручно представляти у вигляді сценаріїв. У цих сценаріях беруть участь об'єкти-ролі, визначені на діаграмі об'єктів для даної функції або її надфункцій. Сценарій представляє собою упорядковану в часі послідовність подій, якими, як правило, є посилки і прийоми повідомлень об'єктами.
Побудова сценаріїв для функції починається з визначення "прямих гілок", тобто ідеального виконання функції. При цьому з розгляду виключаються граничні, помилкові ситуації, окремі випадки і т.п., для них згодом теж будуються сценарії або вони специфицируются іншими засобами. p> Поведінкова модель описує поведінку складають систему класів з допомогою розширеного кінцевого автомата і представлена ​​в Real двома нотаціями: в стилі STD і SDL. Фактично, поведінкова модель визначає процеси, протікають в системі в термінах станів, подій і дій. Надалі будемо говорити про поведінкової моделі окремого класу. Побудова такої моделі можна почати з аналізу всіх сценаріїв, в яких беруть участь об'єкти-ролі даного класу. Проектування поведінки системи (поведінки її класів) на основі сценаріїв, а не безпосередньо, дозволяє в більш наочному вигляді представляти загальні процеси, що протікають в програмному забезпеченні, і, відштовхуючись від них, конструювати внутрішнє поведінка учасників цих процесів.
2.4.4. Статична модель. p> Після того, як створено основні сценарії системи, можна переходити до специфікації їх учасників - об'єктів, тобто до побудови моделі класів. Ця модель класів будується протягом всього процесу розробки програмного забезпечення.
У Real в моделі класів можуть бути наступні види сутностей:
• клас - опис групи однорідних об'єктів;
• шаблон - параметризрвані клас з можливістю отримання з нього звичайного класу підстановкою значень параметрів;
• інтерфейс - опис правил взаємодії класів;
• уявлення - аналог конструкції VIEW мови SQL. p> Модель класів Real реалізує досить повне підмножина моделі класів UML. Крім того, в ній є інтерфейси і порти з ROOM, при цьому останні істотно розширені. Модель класів Real містить також кошти моделювання схеми баз даних. <В
3. Реалізація прототипу системи реального часу.
3.1. Життєвий цикл розробки. p> Розробка складається з двох основних частин: планувальника завдань РВ і прикладного докладання. Прямих залежностей між етапами проектування даних систем немає. Однак, існують логічні зв'язки. Додаток будується на основі створеного планувальника, що передбачає знання про надані їм інтерфейсах. Планувальник, у свою чергу, будується з урахуванням особливостей додатку, який є додатком контролю, тобто орієнтованим на обробку зовнішніх стохастичних подій.
На діаграмі 1 представлені етапи розробки програмної системи. Виконані в рамках даної роботи, виділені чорним кольором, передбачувані до виконання надалі - сірим.
Для планувальника обрана V - подібна модель життєвого циклу. Вона застосовується для додатків, при проектуванні яких розробникам доводиться досліджувати нову проблемну область. Відмінною особливістю цієї моделі життєвого циклу є наявність зворотних зв'язків вже на етапах тестування і вер...
