- •1 Билет
- •1) Стандарт орс (назначение и общее представление, орс сервер, орс группа, орс item).
- •2) Процесс разработки по систем управления(обычный подход – «waterfall», итеративный подход).
- •2 Билет.
- •1) По систем управления. Основные понятия(представление о классах, сом интерфейсах, ActiveX).
- •Билет №3.
- •2) Оригинальные инструментальные средства разработки программного обеспечения систем управления (nCsApp Wizard, State Machine Builder).
- •Билет №4.
- •1) Основные классы mfc (cObject, коллекции, cString, cWnd, механизм документа отображение).
- •2) Идеи компонентного подхода (базовый интерфейс iUnknown, включение, агрегация).
- •IUnknown
- •5 Билет.
- •1) Операционные системы реального времени и системы управления (классификация систем реального времени, Windows nt & rtx, VxWorks, многопоточность).
- •2) Поддержка com в Windows nt (реестр Widows, dcom, реализация сервера в процессе, реализация сервера за пределами процесса).
- •6 Билет.
- •1)Средства синхронизации потоков на примере Windows nt & rtx (Критическая секция,mutex, семафор, shared memory, приоритеты, ...).
- •2) Распределенная модель системы управления (Пример выделения компонентов на базе геометрического канала).
- •Глава 4. Технологии разработки программного обеспечения систем управления 221
- •7 Билет.
- •2.2.3. Базовые понятия операционной системы реального времени
- •2.2.4. Использование в системах управления операционной системы Windows nt
- •2) Общее представление, назначение и использование ActiveX (место ActiveX-элементов в системе управления, способы их создания на базе mfc и на базе atl).
- •4.4.1. Базовые понятия
- •9 Билет.
- •1)Стратегия диспетчеризации на базе расширения rtx (основные потоки системы управления с использованием Windows nt и rtx).
- •2)Назначение страниц свойств, сериализация свойств (стандартные и пользовательские property page).
- •2) Назначение страниц свойств, сериализация свойств (стандартные и пользовательские property page).
- •10 Билет.
- •1) Базовые функции коммуникационной среды (запрос, управление, отображение, вспомагательные функции; выделение фазы обмена данными).
- •2) Идеи ole-автоматизации (базовый интерфейс iDispatch, его ключевые функции).
2) Распределенная модель системы управления (Пример выделения компонентов на базе геометрического канала).
4.4.1. Базовые понятия
Компонентная модель СОМ лежит в основе таких технологий разра-
ботки прикладного программного обеспечения систем управления, как
DCOM, OLE, OLE Автоматизация, ActiveX и ОРС (рис. 134). Компонент-
ная объектная модель СОМ делает стандартную структуру объекта регу-
лярной, управляет его жизненным циклом и общением с другими объекта-
ми [81]. Другими словами, СОМ определяет правила структурирования
объектов и их распределения в памяти, создания и уничтожения объектов,
взаимодействия объектов между собой. Компонентная модель существует
в рамках клиент-серверной архитектуры, когда клиент и сервер (компо-
нент) связаны через СОМ-интерфейс. СОМ-интерфейс специфицирует
функциональные возможности, которые компонент предлагает некоторой
программе или другим компонентам.
От стандартного СОМ-интерфейса IUnknown произведены все осталь-
ные. Интерфейс IUnknown обязателен в любом компоненте и предназна-
чен для (С++)-программистов; он обращает к методам (функциям) ин-
терфейса через таблицу виртуальных методов [82]. Располагая указате-
лем на IUnknown, клиент может запросить и другие интерфейсы
компонента. Производный от IUnknown интерфейс наследует три базо-
вых метода: QuerylnterfaceO, позволяющий клиенту получить указатель
на любой интерфейс компонента из другого указателя интерфейса; AddO
и ReleaseO, поддерживающие механизм управления временем жизни кли-
ента. С этой целью компонент хранит внутренний «счетчик ссылок» на
своих клиентов. Если счетчик обнуляется, объект выгружает себя из памя-
ти. При запросе указателя на интерфейс метод QuerylnterfaceO неявно
вызывает метод AddO для увеличения содержимого счетчика, а после окон-
чания работы с интерфейсом клиент явно вызывает метод ReleaseO для
уменьшения содержимого счетчика ссылок.
Компонент может располагать одним или несколькими СОМ-интерфей-
сами; клиент, в свою очередь, может пользоваться сервисом от нескольких
СОМ-интерфейсов. Это значит, что один СОМ-сервер может обслуживать
нескольких клиентов, а один СОМ-клиент может получать сервис от не-
скольких компонентов (рис. 135).
СОМ-сервер и СОМ-интерфейс имеют свои глобальные уникальные
идентификаторы GUID (Globally Unique Identifier). Один и тот же СОМ-сер-
вер на двух разных компьютерах будет иметь один и тот же идентификатор
GUID, а разные СОМ-серверы на разных компьютерах не могут иметь оди-
наковых интерфейсов. Уникальность GUID обеспечивается тем, что при
изменении компонента или интерфейса утилита guidgen.exe генерирует
новые идентификаторы на основе уникального сетевого адреса и точного
времени запроса на создание GUID. Идентификаторы компонента (клас-
са) и интерфейса обозначаются соответственно CLSID и IID.
Компоненты СОМ бинарно совместимы, что означает, что компонент
будет совместимым для использования с любыми другими СОМ-компо-
нентами независимо от языка, на котором он создан. Объекты и компонен-
ты, разработанные на разных языках программирования и работающие в
различных операционных системах, могут взаимодействовать без каких-
либо изменений в двоичном (исполняемом) коде.
Любой клиент, желающий воспользоваться сервисом компонента, нуж-
дается в предварительных сведениях о его интерфейсе. Существует техно-
логия, которая обеспечивает клиентов информацией о типах компонента.
Файл, содержащий такую информацию, создается с помощью языка опре-
деления интерфейсов - IDL (Interface Definition Language).
Еще одно важное понятие - это фабрика классов (class factory). Фабри-
ка порождает неинициализированный экземпляр объекта класса, т. е. не-
кую заготовку, из которой впоследствии создаются экземпляры. Пусть при-
ложение служит для управления автоматической линией, в которой рабо-
тают десятки различных приводов с разными контроллерами. При
разработке системы управления необходимо разработать компонент для
каждого контроллера. Фабрика классов сокращает подобную работу, она
генерирует полуфабрикат в виде экземпляра объекта класса, из которого
затем инициализируются компоненты для каждого контроллера приводов.
Фабрика классов сама представляет собой компонент со стандартным ин-
