ювати свої бібліотеки класів, створювати виконувані моделі і запускати їх, а також запускати спеціальні підсистеми (оптимізації та символічного аналізу).
Передбачається, що кожної моделі (проекту) відповідає певна тека, в якій зберігаються файл внутрішнього подання проекту (mvb), файли установок проекту і виконуваної моделі (ini), а також картинки для анімації, DLL користувача та т.п. Опис проекту та бібліотек класів зберігається вигляді дерева об'єктів в об'єктно-орієнтованої базі даних MVBase (окремий файл з розширенням mvb на кожен проект і бібліотеку класів). Бібліотеки класів (за винятком стандартної бібліотеки SysLib) є звичайними проектами, їх можуть створювати і редагувати користувачі. p align="justify"> Опис проекту користувач може надавати та змінювати як у візуальному, так і в текстовому вигляді. При відкритті в інтегрованому середовищі якого проекту його внутрішнє подання автоматично розгортається в візуальне уявлення. У будь-який момент за допомогою спеціальної команди може бути отримано текстовий опис проекту на спеціальній мові Model Vision Language (MVL), що включає в себе два текстових файла: власне функціональний опис (розширення mvl) і опис візуальних елементів (розширення pra). Імпорт проекту з текстового представлення здійснюється спеціальним MVL-компілятором. [4]
Опис проекту включає в себе опис класів і пристроїв, глобальних констант і алгоритмічних процедур і функцій, а також опис конкретної конфігурації віртуального стенду, з якою буде проводитися обчислювальний експеримент. Передбачається, що віртуальний стенд є пристроєм-контейнером TestBench - примірником зумовленого класу _CTestBench. Користувачеві необхідно помістити в його локальну структуру конкретні локальні пристрої - екземпляри класів, визначених у даному проекті або імпортуються з підключених до проекту бібліотек класів. Стандартна бібліотека класів SysLib, що включає визначення типових блоків (лінійні і нелінійні блоки, генератори сигналів і т.д.), підключена до будь-якого проекту за замовчуванням. При створенні виконуваної моделі програмний код створюється тільки для класів, реально використовуваних (прямо чи опосередковано, через інші класи) в TestBench. br/>В
Рис. 3.1
Всі візуальні редактори працюють в режимі так званої В«інкрементальною компіляціїВ», тобто по завершенні введення якої-небудь закінченої конструкції вони негайно перевіряють її синтаксичну і семантичну правильність в контексті вже існуючого опису і при виявленні помилок виводять відповідні повідомлення.
При генерації виконуваної моделі спочатку проводиться повний комплексний аналіз контроль класів, що використовуються в TestBench, а потім для кожного класу генерується відповідний програмний модуль на проміжному мові програмування і залежно від типу моделі генерується відповідний головний модуль програми. Потім отримана програма компілюється за доп...
