Основные сведения о модель автоматизации пользовательского интерфейса текстовой объектной модели
В этом разделе описывается, как клиентские приложения Microsoft модель автоматизации пользовательского интерфейса обращаются к текстовому содержимому текстового элемента управления.
- Объектная модель элемента управления
- Связанные темы
Текстовые элементы управления предоставляют текстовое содержимое для модель автоматизации пользовательского интерфейса клиентских приложений с помощью простой текстовой объектной модели. Клиентские приложения имеют доступ к текстовой объектной модели через интерфейсы шаблонов элементов управления Text и TextRange , включая IUIAutomationTextPattern и IUIAutomationTextRange. Клиентские приложения могут использовать эти интерфейсы для получения текстового содержимого, текстовых атрибутов и внедренных объектов, таких как таблицы и гиперссылки, из текстовых элементов управления.
Типы элементов управления, поддерживающие модель модель автоматизации пользовательского интерфейса текстовых объектов, включают типы элементов управления Edit и Document. Другие типы элементов управления, такие как подсказка и текст , также могут поддерживать текстовую объектную модель, но они не требуются.
Объектная модель модель автоматизации пользовательского интерфейса текста не предоставляет средств для вставки или изменения текста. Однако некоторые элементы управления позволяют вставлять или изменять текст с помощью интерфейса IUIAutomationValuePattern или прямого ввода с помощью клавиатуры.
Объектная модель элемента управления
Текстовый элемент управления, реализующий собственную модель DOM, может предоставлять модель DOM путем реализации шаблона элемента управления ObjectModel . Предоставление модели DOM может предоставить клиентским приложениям более широкий доступ к содержимому текстового элемента управления и контроль над им.
Клиентское приложение может определить, реализует ли определенный текстовый элемент управления модель DOM, извлекая интерфейс IUIAutomationElement элемента управления. Затем вызовите метод IUIAutomationElement::GetCurrentPropertyValue , указав идентификатор свойства UIA_IsObjectModelPatternAvailablePropertyId и вариант, который получает значение TRUE, если элемент управления реализует модель DOM.
модель автоматизации пользовательского интерфейса и активные специальные возможности
Microsoft Active Accessibility — это устаревший API, который был представлен в Windows 95 и предназначен для обеспечения доступности приложений Windows. Microsoft модель автоматизации пользовательского интерфейса — это новая модель специальных возможностей для Windows, предназначенная для удовлетворения потребностей продуктов специальных возможностей и средств автоматического тестирования. модель автоматизации пользовательского интерфейса предлагает множество улучшений по сравнению со специальными возможностями Microsoft Active. В этом разделе описываются различия между двумя технологиями.
В этом разделе содержатся следующие подразделы.
- Языки программирования
- Серверы и клиенты
- Элементы пользовательского интерфейса
- Представления в виде дерева и навигация
- Роли и типы элементов управления
- Состояния и свойства
- События
- Доступ к активным свойствам и объектам специальных возможностей из модель автоматизации пользовательского интерфейса
- Связанные темы
Языки программирования
Microsoft Active Accessibility основан на компонентной объектной модели (COM) с поддержкой двойных интерфейсов и, следовательно, программируется на языках C/C++ и скриптов.
Когда модель автоматизации пользовательского интерфейса появился, клиентский API был ограничен управляемым кодом, в то время как API поставщика включал как управляемые, так и неуправляемые реализации. В Windows 7 появился новый КЛИЕНТСКИй API на основе COM, упрощающий программирование модель автоматизации пользовательского интерфейса клиентских приложений на C/C++.
Серверы и клиенты
В Microsoft Active Accessibility серверы и клиенты взаимодействуют напрямую, в основном через серверную реализацию интерфейса IAccess .
В модель автоматизации пользовательского интерфейса основная служба находится между сервером (поставщиком) и клиентом. Базовая служба выполняет вызовы интерфейсов, реализованных поставщиками, и предоставляет дополнительные службы, такие как создание уникальных идентификаторов времени выполнения для элементов пользовательского интерфейса. Клиентские приложения получают доступ к этой основной службе путем создания объекта CUIAutomation . Этот объект поддерживает набор клиентских интерфейсов, которые отделены от интерфейсов поставщика. Дополнительные сведения см. в разделе Создание объекта CUIAutomation.
модель автоматизации пользовательского интерфейса поставщики могут предоставлять сведения клиентам Microsoft Active Accessibility, а серверы microsoft Active Accessibility — модель автоматизации пользовательского интерфейса клиентским приложениям. Однако, поскольку microsoft Active Accessibility не предоставляет столько информации, сколько модель автоматизации пользовательского интерфейса, эти две модели не полностью совместимы.
Элементы пользовательского интерфейса
Microsoft Active Accessibility представляет элемент пользовательского интерфейса как интерфейс IAccessible , связанный с дочерним идентификатором. Трудно сравнить два указателя IAccessible , чтобы определить, ссылаются ли они на один и тот же элемент.
В модель автоматизации пользовательского интерфейса каждый элемент представлен в виде объекта, который предоставляет интерфейс IUIAutomationElement клиентам. Элементы можно сравнить по идентификаторам времени выполнения, которые извлекаются с помощью IUIAutomationElement::GetRuntimeId.
Представления в виде дерева и навигация
Элементы пользовательского интерфейса на экране можно рассматривать как древовидную структуру с рабочим столом в качестве корневого элемента, окна приложения — как непосредственные дочерние элементы, а элементы в приложениях — в качестве последующих потомков.
В Microsoft Active Accessibility многие элементы пользовательского интерфейса, не относящиеся к конечным пользователям, предоставляются в древовидной структуре. Клиентские приложения должны проверять все элементы в дереве, чтобы определить, какие элементы являются значимыми.
модель автоматизации пользовательского интерфейса клиентские приложения видят пользовательский интерфейс через отфильтрованное представление. Представление содержит только элементы, которые предоставляют сведения пользователю или с которыми пользователь может взаимодействовать. Доступны предопределенные представления, включающие только элементы управления и только элементы содержимого, а клиентские приложения могут определять пользовательские представления. модель автоматизации пользовательского интерфейса упрощает описание пользовательского интерфейса пользователя и помогает пользователю взаимодействовать с приложениями.
В Microsoft Active Accessibility навигация между элементами является пространственной, например, переход к элементу, который находится слева на экране, логический, например, переход к следующему элементу меню или следующему элементу в порядке табуляции в диалоговом окне или иерархический, например, переход к первому дочернему элементу в контейнере или от дочернего элемента к его родительскому элементу. Иерархическая навигация осложняется тем, что дочерние элементы не всегда являются объектами, реализующими IAccessible.
В модель автоматизации пользовательского интерфейса все элементы пользовательского интерфейса являются COM-объектами, которые предоставляют интерфейс IUIAutomationElement и поддерживают те же основные функции. С точки зрения поставщика COM-объекты реализуют интерфейс, унаследованный от IRawElementProviderSimple. Навигация в основном иерархическая; т. е. от родителей к детям и от одного брата к другому. Однако переход между одноуровневые элементы имеет логический элемент, так как он может соответствовать порядку табуляции. Клиент может перемещаться из любой начальной точки, используя любое отфильтрованное представление дерева с помощью IUIAutomationTreeWalker. Клиент также может переходить к определенным дочерним элементам или потомкам с помощью IUIAutomationElement::FindFirst и IUIAutomationElement::FindAll. Например, можно легко получить все элементы диалогового окна, поддерживающие указанный шаблон элемента управления.
Навигация в модель автоматизации пользовательского интерфейса является более согласованной, чем в Microsoft Active Accessibility. Некоторые элементы, такие как раскрывающиеся списки и всплывающие окна, дважды отображаются в дереве Microsoft Active Accessibility, и навигация из этих элементов может иметь непредвиденные результаты. Для элемента управления rebar трудно правильно реализовать специальные возможности Microsoft Active Accessibility. модель автоматизации пользовательского интерфейса позволяет перенаправить и изменить положение, чтобы элемент можно было разместить в любом месте дерева, несмотря на иерархию, навязанную владением окнами.
Роли и типы элементов управления
Microsoft Active Accessibility использует свойство accRole (IAccessible::get_accRole) для получения описания роли элемента в пользовательском интерфейсе, например ROLE_SYSTEM_SLIDER или ROLE_SYSTEM_MENUITEM. Роль элемента — это основной ключ к его доступным функциональным возможностям. Взаимодействие с элементом управления достигается с помощью фиксированных методов, таких как IAccessible::accSelect и IAccessible::accDoDefaultAction. Взаимодействие между клиентским приложением и пользовательским интерфейсом ограничено тем, что можно сделать с помощью IAccessible.
Напротив, модель автоматизации пользовательского интерфейса отделяет тип элемента управления, описываемый свойством IUIAutomationElement::CurrentControlType (или IUIAutomationElement::CachedControlType), от ожидаемых функциональных возможностей. Функциональность определяется шаблонами элементов управления, которые поддерживаются поставщиком через его реализацию специализированных интерфейсов. Шаблоны элементов управления можно объединить для описания полного набора функциональных возможностей, поддерживаемых определенным элементом пользовательского интерфейса. Некоторые поставщики должны поддерживать определенный шаблон элемента управления. Например, поставщик для поля проверка должен поддерживать шаблон элемента управления Toggle. Другие поставщики должны поддерживать один или несколько шаблонов элементов управления. Например, кнопка должна поддерживать либо переключатель, либо шаблон элемента управления Invoke . Другие не поддерживают шаблоны управления. Например, панель, которую невозможно переместить, изменить размер или закрепить, не имеет шаблонов элементов управления.
модель автоматизации пользовательского интерфейса поддерживает пользовательские элементы управления, которые определяются константой UIA_CustomControlTypeId и могут быть описаны с помощью свойства IUIAutomationElement::CurrentLocalizedControlType (или IUIAutomationElement::CachedLocalizedControlType).
В следующей таблицероли объектов Microsoft Active Accessibility сопоставлены с модель автоматизации пользовательского интерфейса типами элементов управления.
| Активная роль специальных возможностей | модель автоматизации пользовательского интерфейса тип элемента управления |
|---|---|
| ROLE_SYSTEM_PUSHBUTTON | Button |
| ROLE_SYSTEM_CLIENT | Calendar |
| ROLE_SYSTEM_CHECKBUTTON | CheckBox |
| ROLE_SYSTEM_COMBOBOX | ComboBox |
| ROLE_SYSTEM_CLIENT | См . раздел Настраиваемые типы элементов управления. |
| ROLE_SYSTEM_LIST | DataGrid |
| ROLE_SYSTEM_LISTITEM | DataItem |
| ROLE_SYSTEM_DOCUMENT | Document |
| ROLE_SYSTEM_TEXT | Правка |
| ROLE_SYSTEM_GROUPING | Группа |
| ROLE_SYSTEM_LIST | Верхняя часть |
| ROLE_SYSTEM_COLUMNHEADER | HeaderItem |
| ROLE_SYSTEM_LINK | Гиперссылка |
| ROLE_SYSTEM_GRAPHIC | Изображение |
| ROLE_SYSTEM_LIST | Список |
| ROLE_SYSTEM_LISTITEM | ListItem |
| ROLE_SYSTEM_MENUPOPUP | Menu |
| ROLE_SYSTEM_MENUBAR | MenuBar |
| ROLE_SYSTEM_MENUITEM | MenuItem |
| ROLE_SYSTEM_PANE | Панель |
| ROLE_SYSTEM_PROGRESSBAR | ProgressBar |
| ROLE_SYSTEM_RADIOBUTTON | RadioButton |
| ROLE_SYSTEM_SCROLLBAR | ScrollBar |
| ROLE_SYSTEM_SEPARATOR | Separator |
| ROLE_SYSTEM_SLIDER | Slider |
| ROLE_SYSTEM_SPINBUTTON | Spinner |
| ROLE_SYSTEM_SPLITBUTTON | SplitButton |
| ROLE_SYSTEM_STATUSBAR | StatusBar |
| ROLE_SYSTEM_PAGETABLIST | Вкладка |
| ROLE_SYSTEM_PAGETAB | TabItem |
| ROLE_SYSTEM_TABLE | Таблица |
| ROLE_SYSTEM_STATICTEXT | Text |
| ROLE_SYSTEM_INDICATOR | Большой палец |
| ROLE_SYSTEM_TITLEBAR | Заголовка |
| ROLE_SYSTEM_TOOLBAR | ToolBar |
| Tool barROLE_SYSTEM_TOOLTIP | ToolTip |
| ROLE_SYSTEM_OUTLINE | Дерево |
| ROLE_SYSTEM_OUTLINEITEM | TreeItem |
| ROLE_SYSTEM_WINDOW | Окно |
Состояния и свойства
Элементы Microsoft Active Accessibility поддерживают общий набор свойств. Некоторые свойства, такие как accState, должны описывать различные условия в зависимости от роли элемента. Серверы должны реализовать все методы IAccessible , возвращающие свойство, даже те свойства, которые не относятся к элементу .
модель автоматизации пользовательского интерфейса определяет дополнительные свойства, некоторые из которых соответствуют состояниям в Microsoft Active Accessibility. Некоторые свойства являются общими для всех элементов, но другие свойства относятся к типам элементов управления и шаблонам элементов управления. Поставщик модель автоматизации пользовательского интерфейса не должен реализовывать нерелевантные свойства, но может возвращать значение NULL для любых свойств, которые он не поддерживает. Базовая служба модель автоматизации пользовательского интерфейса может получить некоторые свойства от поставщика окон по умолчанию, и они объединяются со свойствами, явно реализованными поставщиком.
Кроме поддержки многих других свойств, модель автоматизации пользовательского интерфейса обеспечивает более высокую производительность, позволяя кэшировать свойства.
В следующей таблице показано соответствие между некоторыми свойствами в двух моделях. Описания идентификаторов свойств модель автоматизации пользовательского интерфейса см. в разделе Идентификаторы свойств элемента автоматизации.
| Активный метод доступа к свойству специальных возможностей | идентификатор свойства модель автоматизации пользовательского интерфейса | Комментарии |
|---|---|---|
| get_accKeyboardShortcut | UIA_AccessKeyPropertyId или UIA_AcceleratorKeyPropertyId | UIA_AccessKeyPropertyId имеет приоритет, если они присутствуют. |
| get_accName | UIA_NamePropertyId | |
| get_accRole | UIA_ControlTypePropertyId | Сопоставление ролей с типами элементов управления см. в предыдущей таблице. |
| get_accValue | UIA_ValueValuePropertyId или UIA_RangeValueValuePropertyId | Допустимо только для типов элементов управления, поддерживающих IUIAutomationValuePattern или IUIAutomationRangeValuePattern. Значения диапазона нормализуются до 0–100 в соответствии с поведением Microsoft Active Accessibility. Значения представлены в виде строк. |
| get_accHelp | UIA_HelpTextPropertyId | |
| AccLocation | UIA_BoundingRectanglePropertyId | |
| get_accDescription | Не поддерживается. | AccDescription не имеет четкой спецификации в Microsoft Active Accessibility, что привело к тому, что серверы помещали различные фрагменты информации в это свойство. |
| get_accHelpTopic | Не поддерживается. |
В следующей таблице показаны идентификаторы свойств модель автоматизации пользовательского интерфейса, соответствующие константам состояния объекта Microsoft Active Accessibility.
| Состояние «Активные специальные возможности» | свойство модель автоматизации пользовательского интерфейса | Активирует изменение состояния WinEvent? |
|---|---|---|
| STATE_SYSTEM_CHECKED | UIA_ToggleToggleStatePropertyId для проверка коробки. UIA_SelectionItemIsSelectedPropertyId для переключателя. | Да |
| STATE_SYSTEM_COLLAPSED | UIA_ExpandCollapseExpandCollapseStatePropertyId (значение = ExpandCollapseState_Collapsed). | Да |
| STATE_SYSTEM_EXPANDED | UIA_ExpandCollapseExpandCollapseStatePropertyId (значение = ExpandCollapseState_Expanded или ExpandCollapseState_PartiallyExpanded). | Да |
| STATE_SYSTEM_FOCUSABLE | UIA_IsKeyboardFocusablePropertyId. | N |
| STATE_SYSTEM_FOCUSED | UIA_HasKeyboardFocusPropertyId. | N |
| STATE_SYSTEM_HASPOPUP | UIA_ExpandCollapseExpandCollapseStatePropertyId для пунктов меню. | N |
| STATE_SYSTEM_INVISIBLE | UIA_IsOffscreenPropertyId (значение = True и IUIAutomationElement::GetClickablePoint завершается ошибкой ). | N |
| STATE_SYSTEM_LINKED | UIA_ControlTypePropertyId (значение = UIA_HyperlinkControlTypeId). | N |
| STATE_SYSTEM_MIXED | UIA_ToggleToggleStatePropertyId (значение = ToggleState_Indeterminate. | N |
| STATE_SYSTEM_MOVEABLE | UIA_TransformCanMovePropertyId. | N |
| STATE_SYSTEM_MULTISELECTABLE | UIA_SelectionCanSelectMultiplePropertyId. | N |
| STATE_SYSTEM_OFFSCREEN | UIA_IsOffscreenPropertyId. | N |
| STATE_SYSTEM_PROTECTED | UIA_IsPasswordPropertyId. | N |
| STATE_SYSTEM_READONLY | UIA_RangeValueIsReadOnlyPropertyId и UIA_ValueIsReadOnlyPropertyId. | N |
| STATE_SYSTEM_SELECTABLE | UIA_IsSelectionItemPatternAvailablePropertyId . | N |
| STATE_SYSTEM_SELECTED | UIA_SelectionItemIsSelectedPropertyId. | N |
| STATE_SYSTEM_SIZEABLE | UIA_TransformCanResizePropertyId. | N |
| STATE_SYSTEM_UNAVAILABLE | UIA_IsEnabledPropertyId. | Да |
Полный список идентификаторов свойств см. в разделе Идентификаторы свойств.
События
В отличие от Microsoft Active Accessibility, механизм событий в модель автоматизации пользовательского интерфейса, не зависит от маршрутизации событий Windows, которая тесно связана с дескрипторами окон и не требует от клиентского приложения настройки перехватчиков. Подписки на события можно настроить для определенных частей дерева, а не только для конкретных событий. Поставщики также могут точно настроить создание событий, отслеживая, какие события прослушиваются.
Клиентам также проще получить элементы, вызывающие события, так как они передаются непосредственно обратному вызову события. Свойства элемента предварительно получаются автоматически, если запрос кэша был предоставлен, когда клиент подписался на событие.
В следующей таблице показано соответствие констант событий Microsoft Active Accessibility и модель автоматизации пользовательского интерфейса идентификаторов событий.
| WinEvent | Идентификатор события модель автоматизации пользовательского интерфейса |
|---|---|
| EVENT_OBJECT_ACCELERATORCHANGE | UIA_AcceleratorKeyPropertyId изменение свойства. |
| EVENT_OBJECT_CONTENTSCROLLED | UIA_ScrollVerticalScrollPercentPropertyId или UIA_ScrollHorizontalScrollPercentPropertyId изменение свойства на соответствующих полосах прокрутки. |
| EVENT_OBJECT_CREATE | UIA_StructureChangedEventId. |
| EVENT_OBJECT_DEFACTIONCHANGE | Эквивалент отсутствует. |
| EVENT_OBJECT_DESCRIPTIONCHANGE | Нет точного эквивалента; Возможно, UIA_HelpTextPropertyId или UIA_LocalizedControlTypePropertyId изменение свойства. |
| EVENT_OBJECT_DESTROY | UIA_StructureChangedEventId. |
| EVENT_OBJECT_FOCUS | UIA_AutomationFocusChangedEventId. |
| EVENT_OBJECT_HELPCHANGE | UIA_HelpTextPropertyId изменения. |
| EVENT_OBJECT_HIDE | UIA_StructureChangedEventId. |
| EVENT_OBJECT_LOCATIONCHANGE | UIA_BoundingRectanglePropertyId изменение свойства. |
| EVENT_OBJECT_NAMECHANGE | UIA_NamePropertyId изменение свойства. |
| EVENT_OBJECT_PARENTCHANGE | UIA_StructureChangedEventId. |
| EVENT_OBJECT_REORDER | Не всегда используется в Microsoft Active Accessibility. В модель автоматизации пользовательского интерфейса не определено непосредственно соответствующее событие. |
| EVENT_OBJECT_SELECTION | UIA_SelectionItem_ElementSelectedEventId. |
| EVENT_OBJECT_SELECTIONADD | UIA_SelectionItem_ElementAddedToSelectionEventId. |
| EVENT_OBJECT_SELECTIONREMOVE | UIA_SelectionItem_ElementRemovedFromSelectionEventId. |
| EVENT_OBJECT_SELECTIONWITHIN | Эквивалент отсутствует. |
| EVENT_OBJECT_SHOW | UIA_StructureChangedEventId. |
| EVENT_OBJECT_STATECHANGE | Различные события изменения свойств. |
| EVENT_OBJECT_VALUECHANGE | UIA_RangeValueValuePropertyId и UIA_ValueValuePropertyId изменены. |
| EVENT_SYSTEM_ALERT | Эквивалент отсутствует. |
| EVENT_SYSTEM_CAPTUREEND | Эквивалент отсутствует. |
| EVENT_SYSTEM_CAPTURESTART | Эквивалент отсутствует. |
| EVENT_SYSTEM_CONTEXTHELPEND | Эквивалент отсутствует. |
| EVENT_SYSTEM_CONTEXTHELPSTART | Эквивалент отсутствует. |
| EVENT_SYSTEM_DIALOGEND | UIA_Window_WindowClosedEventId. |
| EVENT_SYSTEM_DIALOGSTART | UIA_Window_WindowOpenedEventId. |
| EVENT_SYSTEM_DRAGDROPEND | Эквивалент отсутствует. |
| EVENT_SYSTEM_DRAGDROPSTART | Эквивалент отсутствует. |
| EVENT_SYSTEM_FOREGROUND | UIA_AutomationFocusChangedEventId. |
| EVENT_SYSTEM_MENUEND | UIA_MenuModeEndEventId. |
| EVENT_SYSTEM_MENUPOPUPEND | UIA_MenuClosedEventId. |
| EVENT_SYSTEM_MENUPOPUPSTART | UIA_MenuOpenedEventId. |
| EVENT_SYSTEM_MENUSTART | UIA_MenuModeStartEventId. |
| EVENT_SYSTEM_MINIMIZEEND | UIA_WindowWindowVisualStatePropertyId изменение свойства. |
| EVENT_SYSTEM_MINIMIZESTART | UIA_WindowWindowVisualStatePropertyId изменение свойства. |
| EVENT_SYSTEM_MOVESIZEEND | UIA_BoundingRectanglePropertyId изменение свойства. |
| EVENT_SYSTEM_MOVESIZESTART | UIA_BoundingRectanglePropertyId изменение свойства. |
| EVENT_SYSTEM_SCROLLINGEND | UIA_ScrollVerticalScrollPercentPropertyId или UIA_ScrollHorizontalScrollPercentPropertyId изменение свойства. |
| EVENT_SYSTEM_SCROLLINGSTART | UIA_ScrollVerticalScrollPercentPropertyId или UIA_ScrollHorizontalScrollPercentPropertyId изменение свойства. |
| EVENT_SYSTEM_SOUND | Эквивалент отсутствует. |
| EVENT_SYSTEM_SWITCHEND | Нет эквивалента, но событие UIA_AutomationFocusChangedEventId сигнализирует о том, что фокус получил новое приложение. |
| EVENT_SYSTEM_SWITCHSTART | Эквивалент отсутствует. |
| Эквивалент отсутствует. | UIA_MultipleViewCurrentViewPropertyId изменение свойства. |
| Эквивалент отсутствует. | UIA_ScrollHorizontallyScrollablePropertyId изменение свойства. |
| Эквивалент отсутствует. | UIA_ScrollVerticallyScrollablePropertyId изменение свойства. |
| Эквивалент отсутствует. | UIA_ScrollHorizontalScrollPercentPropertyId изменение свойства. |
| Эквивалент отсутствует. | UIA_ScrollVerticalScrollPercentPropertyId изменение свойства. |
| Эквивалент отсутствует. | UIA_ScrollHorizontalViewSizePropertyId изменение свойства. |
| Эквивалент отсутствует. | UIA_ScrollVerticalViewSizePropertyId изменение свойства. |
| Эквивалент отсутствует. | UIA_ToggleToggleStatePropertyId изменение свойства. |
| Эквивалент отсутствует. | Изменение свойства UIA_WindowWindowVisualStatePropertyId |
| Эквивалент отсутствует. | событие UIA_AsyncContentLoadedEventId . |
| Эквивалент отсутствует. | событие UIA_ToolTipOpenedEventId . |
Доступ к активным свойствам и объектам специальных возможностей из модель автоматизации пользовательского интерфейса
Ключевой функцией модель автоматизации пользовательского интерфейса, недоступной в Microsoft Active Accessibility, является возможность получения нескольких свойств с помощью одной операции между процессами.
Существующие клиенты Microsoft Active Accessibility могут воспользоваться этой возможностью с помощью интерфейса IUIAutomationLegacyIAccessiblePattern . Этот интерфейс представляет шаблон элемента управления , который предоставляет свойства и методы Microsoft Active Accessibility в элементах пользовательского интерфейса. При получении элементов приложение может запросить кэширование этого шаблона элемента управления и его свойств.
IUIAutomationLegacyIAccessiblePattern также позволяет клиентам получать свойства Microsoft Active Accessibility из элементов, не имеющих собственной поддержки IAccess.
Изменения в свойствах IUIAutomationLegacyIAccessiblePattern не вызывают события модель автоматизации пользовательского интерфейса.
Разработка средств автоматизации построения объектно-ориентированных программ с явным выделением состояний Текст научной статьи по специальности «Компьютерные и информационные науки»
Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Гуров Вадим Сергеевич, Мазин Максим Александрович, Нарвский Андрей Сергеевич, Шалыто Анатолий Абрамович
UniMod — инструментальное средство для автоматного программирования
Автоматическое завершение ввода условий в диаграммах состояний
Тестовый язык автоматного программирования
Текстовый язык автоматного программирования FSML для инструментального средства UniMod
Методика верификации автоматных программ
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.
Текст научной работы на тему «Разработка средств автоматизации построения объектно-ориентированных программ с явным выделением состояний»
РАЗРАБОТКА СРЕДСТВ АВТОМАТИЗАЦИИ ПОСТРОЕНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ПРОГРАММ С ЯВНЫМ ВЫДЕЛЕНИЕМ СОСТОЯНИЙ В.С. Гуров, М.А. Мазин, А.С. Нарвский, А.А. Шалыто
В последнее время широкое распространение получили пакеты для проектирования программ на языке UML. Они позволяют разработчику создавать модель программы с помощью набора диаграмм. В дальнейшем диаграммы могут быть преобразованы в код на целевом языке программирования.
В языке UML существуют диаграммы для описания как статической структуры программы (диаграммы классов), так и для описания поведения объектов (диаграммы состояний, диаграммы взаимодействия, диаграммы последовательности вызовов).
Существует множество методологий для моделирования статической структуры программ, а также для получения кода на целевом языке. Описание же поведенческой части программы, как правило, носит неформальный характер. Отсутствует семантическая связь с создаваемым впоследствии кодом, т. е. диаграммы, описывающие поведение, используются только для понимания предметной области. Более того, при наличии сложной логики построение диаграмм взаимодействия и диаграмм последовательности вызовов весьма проблематично. В этой ситуации также весьма сложно применять и диаграммы состояний в виде, предлагаемом авторами UML [1], так как в этом случае идентификаторы входных и выходных воздействий на них не разместить. Кроме того, UML-диаграммы состояний имеют ограничения по вложенности автоматов в состояния.
В работе [2] предложен метод проектирования событийных объектно-ориентированных программ с явным выделением состояний, названный SWITCH-технологией. Особенность этого подхода состоит в том, что поведение объектов описывается с помощью конечных автоматов, представляемых в форме графов переходов с нотацией, описанной в работе [3]. Для каждого автомата также строится схема связей, которая задает интерфейс автомата.
Существуют утилиты, позволяющие автоматически получать код из графов переходов. Например, в работе [4] такая утилита предложена в рамках SWITCH-технологии. При этом необходимо отметить, что указанные утилиты обладают ограниченной функциональностью .
Настоящая работа посвящена решению задачи автоматизации построения программ указанного класса — событийных объектно-ориентированных программ с явным выделением состояний. При этом для обеспечения переносимости создаваемых приложений применяется язык программирования Java и язык разметки XML. Для проектирования используется SWITCH-технология и унифицированный язык моделирования UML. Схема связей автомата, которая разрабатывается в соответствии с указанной технологией, записывается с помощью UML-диаграммы классов, а граф переходов — с помощью UML-диаграммы состояний.
1. Процесс моделирования системы
Предлагаемый процесс моделирования системы состоит в следующем:
• на основе анализа предметной области строится концептуальная модель системы -сущности и отношения между ними;
• в отличие от традиционных для объектно-ориентированного программирования подходов [5], из числа сущностей выделяются источники событий, объекты управления и автоматы. Источники событий активны — они по собственной инициативе
воздействуют на автомат. Объекты управления пассивны — они выполняют действия по команде от автомата. Объекты управления также формируют значения входных переменных для автомата. Автомат активируется источниками событий и на основании значений входных переменных и текущего состояния воздействует на объекты управления, переходя их в новое состояние;
• используя нотацию диаграммы классов, строится схема связей автомата, задающая его интерфейс. На этой схеме слева отображаются источники событий, в центре -автоматы, а справа — объекты управления. Источники событий с помощью иМЬ-ассоциаций связываются с автоматами, события которым они поставляют. Автоматы связываются с объектами, которыми они управляют;
• схема связей, кроме задания интерфейса автомата, выполняет функцию, характерную для диаграммы классов — задает объектно-ориентированную структуру программы;
• каждый объект управления содержит два типа методов, которые реализуют входные переменные (х^ ) и выходные воздействия ^к);
• для каждого автомата с помощью нотации диаграммы состояний строится граф переходов типа Мура-Мили, в котором на каждой дуге могут указываться событие (е1), булева формула из входных переменных и формируемые на переходах выходные воздействия. В вершинах могут указываться выходные воздействия и имена вложенных автоматов. Каждый автомат имеет одно начальное и произвольное количество конечных состояний;
• состояния на графе переходов могут быть простыми и сложными. Если в состояние вложено другое состояние, то оно называется сложным. В противном случае состояние является простым. Основной особенностью сложных состояний является то, что наличие дуги, исходящей из сложного состояния, интерпретируется как наличие такой дуги, исходящей из каждого вложенного состояния;
• все сложные состояния неустойчивы, а все простые, кроме начального, — устойчивы. При использовании сложных состояний в автомате при появлении события может выполняться более одного перехода. Это происходит в связи с тем, что сложное состояние является неустойчивым, и автомат осуществляет переходы до тех пор, пока не достигнет первого из простых (устойчивых) состояний. При этом отметим, что, если в графе переходов сложные состояния отсутствуют, то, как и в 8Ш1ТСИ-технологии, при каждом запуске автомата выполняется не более одного перехода;
‘ -seventproviders-pi : . unimod.adapter.standalone,provider,Tinner 11 * «statennachine» A1 : ol «controlledobject» ol : . unirnod,adapter.standalone,co,Counter
i/ E101: String = «elOl» -(Next tick happened>
-► (■ x4: int -¡Returns counter value> (■ zl: void -[Resets counter to zero> (■ z2: void -[Increments counter> (■ z3: void -[Decrements counter> (■ z5: void -[Prints counter into System.out>
o2 «controlledobject» o2 : test,co.Printer
-► « zl: void-[Print «Hello, World!»> (■ z2: void -[Print «Bye, World!»>
Рис. 1. Схема связей автомата
Рис. 2. Граф переходов автомата
• каждая входная переменная и каждое выходное воздействие являются методами соответствующего объекта управления, функциональность которых реализуется вручную на целевом языке программирования.
На рис. 1 приведен пример схемы связей автомата, представленной с использованием UML-нотации диаграммы классов.
На рис. 2 приведен пример графа переходов автомата, представленного с использованием UML-нотации диаграммы состояний.
Множество диаграмм классов и диаграмм состояний, построенных описанным выше образом, задает поведенческую модель системы. Содержимое диаграмм может быть автоматически преобразовано в текстовое описание в формате XML, для последующей передаче интерпретатору.
2. Программный пакет UniMod
Для автоматизации описанного выше процесса моделирования авторами был разработан программный пакет UniMod. Он состоит из следующих частей:
• ядро, которое содержит объектную метамодель конечного автомата, алгоритмы разбора и трансляции булевских выражений на переходах, алгоритмы проверки корректности конечного автомата и среду исполнения XML-описания;
• встраиваемый модуль для платформы Eclipse, который позволяет создавать схемы связей автомата и графы переходов в виде UML-диаграмм, сообщает пользователю об ошибках, допущенных им в процессе проектирования, и предлагает пути их устранения, выполняет генерацию XML-описания, а также позволяет запускать спроектированную автоматную модель «в одно нажатие».
2.1. Интерпретатор .XML-описания модели системы
На языке Java разработана среда для интерпретации XML-описания модели. При этом сначала описание однократно и целиком преобразуется в соответствующее внутреннее объектное представление программы. В результате образуется система, состоящая из среды исполнения и объектного представления программы. Эта система функционирует в соответствии с описанной ниже операционной семантикой:
• при запуске системы инициализируются все источники событий. После этого они начинают воздействовать на связанные с ними автоматы;
• каждый автомат начинает свою работу из начального состояния, а заканчивает в одном из конечных;
• при получении события автомат выбирает все исходящие из текущего состояния переходы, помеченные символом этого события;
• автомат перебирает все выбранные переходы и вычисляет булевы формулы, записанные на них, до тех пор, пока не найдет формулу со значением true;
• если переход с такой формулой найден, автомат выполняет выходные воздействия, записанные на дуге, и переходит в новое состояние. В новом состоянии автомат выполняет выходные воздействия, указанные в этом состоянии, а также запускает вложенные в него автоматы;
• если переход не найден, то автомат продолжает, аналогично изложенному выше, поиск перехода у состояния, в которое вложено текущее состояние;
• при переходе в конечное состояние автомат останавливает все источники событий. После этого работа системы завершается.
При этом как при работе, так и при отладке могут вестись два типа протоколов (логов) — длинный и короткий. Первый из них отражает внутреннее поведение автоматов, в том числе вложенных, записи для которых выделяются отступами. Во втором протоколе отражаются только входные переменные и выходные воздействия.
2.2. Проверка корректности модели системы
В стандарте на язык UML синтаксис и семантика диаграмм определяется набором ограничений, записанных на языке объектных ограничений (Object Constraint Language). Данный набор ограничений должен удовлетворяться для любой правильно построенной диаграммы. Именно на этих ограничениях и основана проверка корректности модели диаграмм. Авторами предлагается расширить множество ограничений следующим образом:
• все состояние на диаграмме состояний должны быть достижимы;
• множество исходящих переходов для любого состояния должно быть полно и непротиворечиво. Это означает, что при обработке любого события не должно быть альтернативных переходов и хотя бы один переход должен выполняться.
Проверка набора ограничений, описанных в стандарте UML, является тривиальной задачей, поэтому дальше описано, как осуществляется проверка дополнительных ограничений, введенных авторами.
UML-диаграммы состояний графами не являются. Чтобы распространить теорию графов на эти диаграммы, их необходимо преобразовать.
Определение 1. Определим UML -диаграмму состояний как тройку D = (Ss>Sc,T), где S s — множество простых состояний, Sc — множество сложных состояний, а T -множество переходов между состояниями, каждый переход задается парой (, s2), где оба элемента принадлежат объединению множеств простых и сложных состояний.
Будем говорить, что диаграмма состояний D’ = (Ss, Sc’, T’) получена из диаграммы
D =(Ss’ Sc,T) исключением сложного состояния sc, если
где init(sc) — начальное состояние в sc. Также будем говорить, что псевдограф G = (V, E) получен из диаграммы состояний D = (Ss, Sc, T) путем исключения всех сложных состояний, если диаграмма D’ = (Ss’, 0, T’) получена из диаграммы D = (Ss, Sc ,T) последовательным исключением всех сложных состояний, V = Ss’, а e = T’.
Утверждение 1. Для каждой диаграммы состояний существует единственный псевдограф, полученный из нее путем исключения всех сложных состояний. То есть процесс исключения всех сложных состояний приводит к одному и тому же результату вне зависимости от порядка исключения состояний.
Все возможные диаграммы состояний можно разбить на классы эквивалентности. Две диаграммы эквивалентны, если им соответствует один и тот же псевдограф. Полученные результаты позволяют распространить теорию графов на диаграммы состояний.
Определение 2. Простое состояние на ЦМЬ-диаграмме состояний называется достижимым, если в псевдографе, полученном исключением всех сложных состояний, соответствующая ему вершина достижима из вершины, соответствующей начальному состоянию на ЦМЬ-диаграмме, которое вложено в сложное состояние, не вложенное ни в какое другое сложное состояние.
Множество достижимых состояний можно построить обходом графа переходов «в глубину» [7]. Время, затрачиваемое на обход графа, пропорционально количеству вершин в нем — 0(У).
Единственность перехода для каждого набора входных воздействий (непротиворечивость) означает, что для каждого состояния условия на всех переходах попарно ортогональны, то есть, если с — условие на 1-ом переходе, то
г Ф 1 ^ с л с = 0
Полнота множества переходов для состояния означает, что
с1 Vс2 V. Vсы = 1
Далее показано, как решить задачу проверки полноты и непротиворечивости графа переходов конечного автомата.
2.3. Разбор, минимизация и интерпретация булевских формул
Для проверки полноты и непротиворечивости множества переходов, для каждой вершины необходимо решать задачу проверки тождественного равенства единице или нулю произвольной булевской формулы. Это ^Р-полная задача [8]. Для ее решения можно использовать два подхода:
• вычисление значений формулы на всех возможных значениях переменных, то есть построение таблицы истинности;
• минимизация булевской формулы. Для тождественно истинных и тождественно ложных формул минимизация приводит к получению константного значения.
Второй подход обладает рядом преимуществ. Во-первых, он позволяет расширить класс используемых булевских формул, дополнив множество литералов одноместными предикатами [9]. Во-вторых, в случае, если формула не является тождеством, то ее минимизированное представление можно использовать для облегчения процесса создания корректных диаграмм. По указанным причинам в состав программного пакета ЦШМоё входит модуль минимизации булевских формул.
Ниже приведена грамматика в виде набора форм Бэкуса-Наура (БНФ), задающая язык формул, для которых реализован алгоритм минимизации.
Терминальные символы имеют следующий смысл: or — дизъюнкция; and — конъюнкция; not — отрицание; id — идентификатор; bool — булевская константа; int — целочисленная константа; op — символ предиката (, >, =,
Построение синтаксического анализатора для данной грамматики осуществлялось с помощью библиотеки ANTLR [10], позволяющей автоматически по заданной LL(k) грамматике [11, 12] строить транслятор входного потока в синтаксическое дерево разбора. Дерево, полученное в результате трансляции, можно использовать для вычисления значений формул во время выполнения программы, а также трансформировать в другое дерево.
Реализованный процесс минимизации булевской формулы основан на трансформации синтаксического дерева разбора и состоит из следующих этапов:
1. приведение формулы к дизъюнктивной нормальной форме (ДНФ);
2. упрощение термов ДНФ с помощью законов идемпотентности, операций переменной с ее отрицанием и операций переменной с константой для булевских переменных;
3. нахождение интервалов целочисленных переменных, входящих в терм, при которых терм не обращается в ложь.
Приведение формулы к ДНФ реализуется с помощью последовательности трансформаций, сохраняющих тождественное равенство соответствующих формул. Формула, приведенная к ДНФ, представляет собой дизъюнкцию термов, каждый из которых -конъюнкция литералов, а каждый литерал — предикат, булевская переменная или ее отрицание.
Для приведения синтаксического дерева к дереву, соответствующему ДНФ, необходимо и достаточно удовлетворить следующие условия:
• узлы, соответствующие логическому отрицанию, должны быть родительскими только по отношению к узлам, соответствующим вхождениям переменных;
• ни один узел, соответствующий конъюнкции, не должен быть предком по отношению к узлам, соответствующим дизъюнкции.
Для выполнения первого условия дерево трансформируется по законам де Моргана
—(а v b) = — а л— b и отрицания отрицания
На рис. 3 приведена трансформация дерева по закону де Моргана для операции «ИЛИ». Для операции «И» соответствующая трансформация приведена на рис. 4. Закон отрицания отрицания показан на рис. 5.
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
Выполнение второго условия достигается трансформацией согласно дистрибутивному закону алгебры логики (рис. 6): а V (Ь л с) = (а V Ь ) л (а V с)
а л (Ь V с) = (а л Ь ) V (а л с)
Рис. 3. Преобразование по закону де Моргана для операции «ИЛИ»
Рис. 4. Преобразование по закону де Моргана для операции «И»
Рис. 5. Преобразование по закону отрицания отрицания
Рис. 6. Преобразование по дистрибутивному закону
Важно отметить, что порядок применения преобразований не безразличен — сначала должно быть удовлетворено первое условие, и лишь затем второе. Если сначала удовлетворить второе условие, а затем первое, то, в общем случае, результирующая формула не будет иметь вид ДНФ, и необходимо будет применять преобразования до тех пор, пока формула не будет приведена к ДНФ, что существенно понизит производительность алгоритма.
После приведения формулы к ДНФ поиск минимальной ДНФ не осуществляется, так как такой поиск является крайне ресурсоемкой операцией. К тому же оптимизация термов для тождественно ложных формул гарантированно приводит к тому, что формула обращается в ложь.
Упрощение термов основывается на применении для булевских переменных законов идемпотентности а V а = а , а л а = а ,
операций переменной с ее отрицанием
а V— а = 1, а л —а = 0 и операций с константой
а V 0 = а, а V1 = 1,
Из формулы исключаются термы, в которые хотя бы одна переменная входит вместе со своим отрицанием. Множественные вхождения одного литерала в терм заменяются единственным вхождением.
Для упрощения термов, в которые входят предикаты над целочисленными переменными, используется специальная техника, описанная далее.
Определение 3. Ядром предиката Р назовем множество значений переменной, на котором предикат Р обращается в истину Кег Р = .
Если в терм входят предикаты Р>, Р2, . Рп от переменной х0, то терм обращается в тождественную ложь, когда
то есть когда при любом значении переменной х0 хотя бы один предикат ложен.
Упомянутая техника состоит в том, чтобы для каждой переменной терма построить пересечение ядер предикатов, в которые она входит, и в случае, если хотя бы одно пересечение пусто, исключить терм из формулы. Заметим, что эта техника не использует целочисленной природы переменных, поэтому может быть распространена на предикаты заданные над произвольным множеством.
Теорема 1. Если ни одно правило для упрощения термов не привело к исключению терма из ДНФ, то существует комбинация значений переменных, обращающая терм в истину.
Доказательство. То, что терм не исключен из формулы ни по одному правилу, означает, что ни одна булевская переменная не входит в формулу со своим отрицанием, и для всех целочисленных переменных пересечение ядер, соответствующих предикатов, не пусто.
В качестве значения булевской переменной возьмем истину, если переменная входит в формулу без отрицания, и ложь — в противном случае. Для целочисленной переменной в качестве значения выберем любое из пересечения ядер, соответствующих ей предикатов. Выбранные значения переменных обращают терм в истину. ■
Как правило, формулы, соответствующие каждому переходу, не слишком длинны. Поэтому, если предварительно привести формулы для условий на каждом переходе к ДНФ и принять за один шаг алгоритма перемножение термов, то можно оценить время, затрачиваемое на проверку полноты и непротиворечивости.
Оценка сложности алгоритма проверки непротиворечивости. Пусть для данного состояния с данным событием связано N переходов, каждый из которых помечен формулой
Количество термов в 1-ой формуле обозначим через ш1
Для проверки непротиворечивости 1-ого и ]-ого условий необходимо привести к ДНФ их конъюнкцию
С, Л С^ = (^ V к V 1 ) л ^ V к V ■
Эта операция займет m’ Х М] шагов. Количество термов в каждой формуле не пре-m = max (mi)
восходит числа ‘ , поэтому количество шагов для проверки непротиворечивости всей системы переходов можно оценить как
Оценка сложности алгоритма проверки полноты. Для проверки полноты необходимо привести к ДНФ отрицание дизъюнкции всех формул С (г = N)
— ( V к V СN ) = —((^1 V к V ^ ) V к ^tN V к V ^ ))
Видно, что приведение этой формулы к ДНФ с помощью описанной выше процедуры и последующая оптимизация термов имеет экспоненциальную от количества формул трудоемкость. Увеличить производительность алгоритма позволяет эвристика, основанная на дополнительной оптимизации термов. Предлагаемая процедура проверки полноты состоит из следующих этапов:
1. построение дизъюнкции формул условий на переходах;
2. оптимизация термов в дизъюнкции;
3. приведение к ДНФ отрицания формулы, полученной на шаге (2);
4. оптимизация термов в формуле, полученной на шаге (3);
5. равенство лжи результирующей формулы означает полноту системы формул. Количество термов за счет оптимизации на шаге (2) сокращается, поэтому приведение к ДНФ на шаге (3) происходит значительно быстрее.
В случае, если система не полна, минимизированная формула, полученная на шаге (4), может быть использована в качестве условия на переходе, который необходимо добавить, для обеспечения полноты.
Теорема 2. Формула, полученная на шаге (4), ортогональна каждой формуле С (> = 1,к, N), и система условий, дополненная этой формулой, полна.
Доказательство. Формула, полученная на шаге (4), тождественно равна
ее конъюнкция с формулой С:
— ( V . V С V . V СN ) Л с = (-с1 Л к Л Л к Л-СN) Л с =
— С Л к Л — С Л с1 Л к Л — СN = —С Л к Л 0 Л к Л — СN = 0
Полнота системы следует из того, что дизъюнкция формулы со своим отрицанием тождественно истинна. ■
Эта теорема используется при построении инструмента для редактирования диаграмм состояний. Если введенная пользователем система переходов не полна, инструмент указывает, какое условие следует задать на переходе для исправления ошибки. Подобным образом может быть использована и формула, полученная в результате проверки непротиворечивости двух условий.
Теорема 3. Пусть с ‘ — формула, полученная в результате минимизации конъюнкции формул С и су. Тогда формулы с л—с’ и су ортогональны. И если система
полна, то система также полна. Доказательство. Проверка ортогональности:
( л —с’) л с> = ( л — (с л с>)) л с> =
С Л Су Л ( — С V —Су ) = ( Л Су Л — С ) V (с1 Л Су Л —Су ) =
( 0 Л су )v(ci Л 0) = 0 Полнота:
с1 Л —С ‘ = с1 Л — (с1 Л Су ) = (с Л — с1 ) V (с1 Л—С у ) = с1 Л — Су
таким образом, дизъюнкция формул равна
с1 V к V (с1 Л С ‘) V к V Су V к V cN = С1 V к V (с1 Л —Су ) V к V Су V к V cN
с V к V (с,- л —Су ) V к V су V. V см = с V. V с, V. V су V к V см
Последняя формула тождественно истинна в силу полноты системы переходов
Теорема 3 также используется при построении инструмента редактирования диаграмм — инструмент подсказывает пользователю пути устранения противоречий в системе условий на переходах.
Встраиваемый модуль для платформы Eclipse (http://www.eclipse.org) входит в состав пакета UniMod и позволяет создавать схемы связей и графы переходов автоматов. Платформа Eclipse обладает рядом преимуществ перед такими продуктами, как, например, IntelliJIDEA или Borland JBuilder:
• является бесплатным продуктом с открытым исходным кодом;
• содержит библиотеку для разработки графических редакторов — Graphical Editing Framework;
• активно развивается фирмой IBM и уже сейчас обладает не меньшей функциональностью, чем упомянутые выше аналоги.
На рис. 7 представлена рабочая область платформы Eclipse с запущенным модулем UniMod. На этом рисунке справа вверху в виде дерева представлена структура разрабатываемого конечного автомата. Узлами дерева являются объекты управления, состояния и переходы между состояниями. Узлу, который представляет объект управления, сопоставлен класс на схеме связей. Узлу, представляющему состояние — состояние на графе переходов. При выделении какого-либо узла в дереве открывается диаграмма, на которой присутствует соответствующий элемент, и он выделяется. Такой подход позволяет легко ориентироваться в структуре создаваемого конечного автомата.
В окне, расположенном в нижней части экрана, отображаются ошибки, найденные при проверке корректности построенной модели.
Для обеспечения удобной и быстрой разработки программ на текстовых языках в современных средствах разработки реализованы:
• подсветка семантических и синтаксических ошибок;
• автоматическое завершение ввода и автоматическое исправление ошибок;
• запуск и отладка программы внутри среды разработки.
В английском языке эти возможности называются «code assist». При создании модуля для платформы Eclipse авторы перенесли указанные подходы на процесс редактирования диаграмм.
Проверка корректности диаграмм происходит следующим образом. В фоновом режиме запускается процесс, который при любом изменении диаграммы проверяет ее на корректность. При нахождении ошибки некорректный элемент на диаграмме выделяется цветом. На рис. 8 приведен пример диаграммы с недостижимым состоянием, которое автоматически выделено красным цветом.
Традиционно автоматическим завершением ввода называется подход, благодаря которому среда по заданному началу лексемы определяет набор допустимых конструкций, префиксом которых данное начало является, и предлагает пользователю выбрать одну из них. Автоматическое исправление ошибок предполагает, что редактор для каждой найденной ошибки указывает пользователю варианты ее исправления.
В случае текстового редактора оба подхода основываются на знании грамматики языка и наборе семантических правил.
2.4. Встраиваемый модуль для платформы Eclipse
Рис. 7. Рабочая область платформы Eclipse
o2,z 6 eiA 11,1 s e23 jü 2. z 1
Dsrarrnected í.zé ^ Connected ^ lOO
ЦП Автоматизированные системы управления и промышленная безопасность
Интегрированная среда разработки (ИСР) – это система программных средств, используемая программистам для разработки программного обеспечения. В английском языке такая среда называется Integrated development environment или сокращённо IDE.
ИСР обычно включает в себя текстовый редактор, компилятор, интерпретатор, средства автоматизации разработки и сборки программного обеспечения и отладчик. Иногда также содержит средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают окно просмотра программных классов, инспектор объектов и диаграмму иерархии классов – для использования при объектно-ориентированной разработке ПО. Большинство современных ИСР предназначенны для разработки программ на нескольких языках программирования одновременно.
Один из частных случаев ИСР – среды визуальной разработки, которые включают в себя возможность визуального редактирования интерфейса программы.
Основным окном, является текстовый редактор, который используется для ввода исходного кода в ИСР и ориентирован на работу с последовательностью символов в текстовых файлах. Такие редакторы обеспечивают расширенную функциональность – подсветку синтаксиса, сортировку строк, шаблоны, конвертацию кодировок, показ кодов символов и т. п. Иногда их называют редакторами кода, так как основное их предназначение – написание исходных кодов компьютерных программ.
Подсветка синтаксиса – выделение синтаксических конструкций текста с использованием различных цветов, шрифтов и начертаний. Обычно применяется в текстовых редакторах для облегчения чтения исходного текста, улучшения визуального восприятия. Часто применяется при публикации исходных кодов в Интернет.
Понятие трансляции, компилятора и интерпретатора было дано в предыдущих лекциях.
Одна из наиболее важных частей ИСР – отладчик, который представляет собой модуль среды разработки или отдельное приложение, предназначенное для поиска ошибок в программе. Отладчик позволяет выполнять пошаговую трассировку, отслеживать, устанавливать или изменять значения переменных в процессе выполнения программы, устанавливать и удалять контрольные точки или условия остановки и т. д.
Наиболее распространёнными отладчиками являются:
— GNU Debugger – отладчик программ от проекта GNU;
— IDA – дизассемблер и низкоуровневый отладчик для операционных систем семейства Windows и GNU/Linux;
— Microsoft Visual Studio – среда разработки программного обеспечения, включающая средства отладки от корпорации Microsoft;
— OllyDbg – бесплатный низкоуровневый отладчик для операционных систем семейства Windows;
— SoftICE – низкоуровневый отладчик для операционных систем семейства Windows;
— Dr. Watson – стандартный отладчик Windows, позволяет создавать дампы памяти;
— WinDbg – бесплатный отладчик от корпорации Microsoft.
Основным процессом отладки является трассировка. Трассировка – это процесс пошагового выполнения программы. В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки. Трассировка может быть начата и окончена в любом месте программы, выполнение программы может останавливаться на каждой команде или на точках останова, трассировка может выполнятся с заходом в процедуры/функции и без заходов.
Наиболее важным модулем ИСР при совместной разработке проектов средней и высокой степени сложности является система управления версиями. Система управления версиями (английская аббревиатура CVS) — программное обеспечение для облегчения работы с изменяющейся информацией. Она позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и многое другое.
Такие системы наиболее широко применяются при разработке программного обеспечения, для хранения исходных кодов разрабатываемой программы. Однако они могут с успехом применяться и в других областях, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов, в частности, они всё чаще применяются в САПР, обычно в составе систем управления данными об изделии. Управление версиями используется в инструментах конфигурационного управления различных устройств и систем.
В нашей стране, возможно в связи с малым количеством масштабных проектов, системы управления версиями распространение не получили, несмотря на то, что их использование является залогом успешной реализации крупных проектов. В связи с этим остановимся подробнее на этой возможности ИСР.
Большинство систем управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, так называемая «рабочая копия». Может быть получена последняя версия или любая из предыдущих, выбранная по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть получена оттуда в любое время. Сервер может использовать дельта-компрессию – способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.
Иногда создание новой версии выполняется незаметно для пользователя (прозрачно) – либо с помощью прикладной программы, имеющей встроенную поддержку такой функции, либо за счёт использования специальной файловой системы. В последнем случае пользователь просто работает с файлом как обычно, и при сохранении файла автоматически создаётся новая версия.
Часто бывает, что над одним проектом одновременно работают несколько человек. Если два человека изменяют один и тот же файл, то один из них может случайно отменить изменения, сделанные другим. Системы управления версиями отслеживают такие конфликты и предлагают средства их решения. Большинство систем может автоматически объединить (слить) изменения, сделанные разными разработчиками. Однако такое автоматическое объединение изменений, возможно обычно только для текстовых файлов и то, только при условии, что изменялись разные (непересекающиеся) части этого файла. Такое ограничение связано с тем, что большинство систем управления версиями ориентированы на поддержку процесса разработки программного обеспечения, а исходные коды программ хранятся в текстовых файлах. Если автоматическое объединение выполнить не удалось, система может предложить решить проблему вручную.
Часто выполнить слияние невозможно ни в автоматическом, ни в ручном режиме, например, в случае, если формат файла слишком сложен или вообще неизвестен. Некоторые системы управления версиями дают возможность заблокировать файл в хранилище. Блокировка не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла (например, средствами файловой системы) и обеспечивает таким образом исключительный доступ только тому пользователю, который работает с документом.
Другие возможности системы управления версиями состоят:
— в создании разных вариантов одного документа-ветки, с общей историей изменений до точки ветвления и с разными – после неё.
— возможности узнать, кто и когда добавил или изменил конкретный набор строк в файле;
— ведении журнала изменений, куда пользователи могут записывать пояснения о том, что и почему они изменили в данной версии;
— контролирует права доступа пользователей, разрешении или запрете чтения или изменения данных в зависимости от того, кто запрашивает это действие.
Отдельным классом являются распределённые системы управления версиями. Такие системы используют распределённую модель вместо традиционной клиент-серверной. Они, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере, в локальном хранилище, и при необходимости отдельные фрагменты истории локального хранилища синхронизируются с аналогичным хранилищем на другом компьютере. В некоторых таких системах локальное хранилище располагается непосредственно в каталогах рабочей копии.
Когда пользователь такой системы выполняет обычные действия, такие, как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений хранилища, принадлежащие разным разработчикам, начинают различаться, и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами изменений (англ. change sets) между пользователями.
Основное преимущество распределённых систем заключается в их гибкости. Каждый разработчик может вести работу независимо, так, как ему удобно, сохраняя промежуточные варианты документов и передавая результаты другим участникам, когда посчитает нужным. При этом обмен наборами изменений может осуществляться по различным схемам. В небольших коллективах участники работы могут обмениваться изменениями по принципу «каждый с каждым», за счет чего отпадает необходимость в создании выделенного сервера. Крупное сообщество, наоборот, может использовать централизованный сервер, с которым синхронизируются копии всех его участников. Возможны и более сложные варианты, например, с созданием групп для работы по отдельным направлениям внутри более крупного проекта.
Для использования систем управления версиями необходимо владеть терминологией этих систем. Общепринятой терминологии не существует, в разных системах могут использоваться различные названия для одних и тех же действий.
Ниже приведены некоторые, наиболее часто используемые варианты. В связи с тем, что системы разрабатывались англоязычным сообществом, а русскоязычная терминология ещё на выработана, используются английские термины.
branch (ветвь) – направление разработки, независимое от других. Ветвь представляет собой копию части (как правило, одного каталога) хранилища, в которую можно вносить свои изменения, не влияющие на другие ветви. Документы в разных ветвях имеют одинаковую историю до точки ветвления и разные – после неё.
check-in, commit, submit – создание новой версии, публикация изменений. Распространение изменений, сделанных в рабочей копии, на хранилище документов. При этом в хранилище создаётся новая версия изменённых документов.
C heck-out, clone – извлечение документа из хранилища и создание рабочей копии.
C onflict – конфликтная ситуация, когда несколько пользователей сделали изменения одного и того же участка документа. Конфликт обнаруживается в случае, когда один пользователь уже опубликовал свои изменения, а второй только пытается их опубликовать и система сама не может корректно слить конфликтующие изменения. Поскольку программа может быть недостаточно разумна для того, чтобы определить, какое изменение является «корректным», второму пользователю нужно самому разрешить конфликт (resolve).
M erge, integration (слияние) — объединение независимых изменений в единую версию документа. Осуществляется, когда два человека изменили один и тот же файл или при переносе изменений из одной ветки в другую.
R epository (хранилище документов) — место, где система управления версиями хранит все документы вместе с историей их изменения и другой служебной информацией.
R evision (версия документа). Системы управления версиями различают версии по номерам, которые назначаются автоматически.
T ag, label (метка) – которую можно присвоить определённой версии документа. Метка представляет собой символическое имя для группы документов, причём описывает она не только набор имён файлов, но и ревизию каждого файла. Ревизии включённых в метку документов могут принадлежать разным моментам времени.
T runk, mainline (ствол) – основная ветвь разработки проекта. Политика работы со стволом может отличаться от проекта к проекту, но в целом она такова: большинство изменений вносится в ствол; если требуется серьёзное изменение, способное привести к нестабильности, создаётся ветвь, которая сливается со стволом, когда нововведение будет в достаточной мере испытано; перед выпуском очередной версии создаётся «релизная» ветвь, в которую вносятся только исправления.
U pdate, sync (обновление, синхронизация) – синхронизация рабочей копии до некоторого заданного состояния хранилища. Чаще всего это действие означает обновление рабочей копии до самого свежего состояния хранилища. Однако при необходимости можно синхронизировать рабочую копию и к более старому состоянию, чем текущее.
W orking copy (рабочая копия) – рабочая (локальная) копия документов.
Рассмотрим возможности ИСР на примере наиболее доступных и популярных версий.
Eclipse (от англ. затмение) – свободная интегрированная среда разработки модульных кроссплатформенных приложений (рисунок 69). Развивается и поддерживается некоммерческой организацией Eclipse Foundation (http://www.eclipse.org/).
Первоначально Eclipse разрабатывалась фирмой «IBM» в качестве корпоративного стандарта ИСР для разработки на разных языках под платформы от данной компании. По сведениям «IBM», проектирование и разработка стоили 40 млн. долл. Исходный код был полностью открыт и сделан доступным после того, как Eclipse был передан для дальнейшего развития независимому от «IBM» сообществу.
В основе Эклипс лежат фреймворк OSGi и SWT/JFace, на основе которых разработан следующий слой – RCP (Rich Client Platform, платформа для разработки полноценных клиентских приложений). RCP служит основой не только для Эклипс, но и для других RCP-приложений, например, Azureus и File Arranger. Следующий слой – сам Эклипс, представляющий собой набор расширений RCP: редакторы, панели, перспективы, модуль CVS и модуль Java Development Tools (JDT).
Эклипс – в первую очередь, полноценная Java ИСР, нацеленная на групповую разработку: поддержка CVS входит в поставку Эклипс, активно развиваются несколько вариантов SVN-модулей, существует поддержка VSS и других. В силу бесплатности и высокого качества, Эклипс во многих организациях является корпоративным стандартом для разработки приложений.
Второе назначение Эклипс – служить платформой для разработки новых расширений, чем он и завоевал популярность: любой разработчик может расширить Эклипс своими модулями. Уже существуют C/C++ Development Tools (CDT), разрабатываемые инженерами QNX совместно с «IBM», и средства для языков COBOL, FORTRAN, PHP и прочие от различных разработчиков. Множество расширений дополняет среду Эклипс менеджерами для работы с базами данных, серверами приложений и др.
Рисунок 69 . Интерфейс главного окна Эклипс
Эклипс написана на Java, потому является платформо-независимым продуктом, за исключением библиотеки SWT, которая разрабатывается для всех распространённых платформ. Библиотека SWT используется вместо стандартной для Java библиотеки Swing. Она полностью опирается на нижележащую платформу (операционную систему), что обеспечивает быстроту и натуральный внешний вид пользовательского интерфейса, но иногда вызывает на разных платформах проблемы совместимости и устойчивости приложений.
Основой Eclipse является платформа расширенного клиента (RCP — от англ. rich client platform). Её компоненты:
— ядро платформы (загрузка Eclipse, запуск модулей);
— OSGi (стандартная среда поставки комплектов (англ. bundles));
— SWT (портируемый инструментарий виджетов);
— JFace (файловые буферы, работа с текстом, текстовые редакторы);
— рабочая среда Эклипс (панели, редакторы, проекции, мастеры).
Другой популярной свободной ИСР является КДевелоп (http://www.kdevelop.org, рис. 70). КДевелоп (англ. KDevelop) — свободная среда разработки программного обеспечения для UNIX-подобных операционных систем. Проект стартовал в 1998 году. КДевелоп распространяется согласно лицензии GNU (General Public License).
Рисунок 70. Интерфейс KDevelop
KDevelop не включает в свой состав компилятор, вместо этого он использует любой компилятор для создания исполняемого кода.
Текущая стабильная версия поддерживает большое количество языков программирования, таких как Ада, Bash, C, C++, Фортран, Java, Pascal, Perl, PHP, Python, Ruby и SQL.
КДевелоп использует встроенный компонент – текстовый редактор – через технологию KParts. Основным редактором является Kate.
— подсветка исходного кода с учетом синтаксиса используемого языка программирования, который определяется автоматически;
— менеджер проектов для проектов разного типа, таких как Automake, qmake для проектов базирующихся на технологиях Qt и Ant для проектов, базирующихся на Java;
— навигатор классов (Class Browser);
— Front-end для GNU Compiler Collection;
— Front-end для GNU Debugger;
— помощников для генерации и обновления определения классов и платформы (framework);
— автоматическая система завершения кода (Си/C++);
— встроенная поддержка системы документирования исходных кодов (Doxygen);
— одна из систем контроля версий: SCM, CVS, Subversion, Perforce и ClearCase;
— функция Quick Open позволяющая быстро перемещаться по файлам.
KDevelop представляет собой «подключаемую» архитектуру. Когда разработчик делает изменения, он должен лишь скомпилировать плагин. Предусмотрена возможность сохранения профилей, указывающих какие плагины должны быть загружены. KDevelop не поставляется со встроенным текстовым редактором, он подключается как плагин. KDevelop не зависит от языка программирования и от платформы, на которой он запускается, поддерживая KDE, GNOME и много других технологий (например, Qt, GTK+ и wxWidgets).
Встроенный отладчик KDevelop позволяет работать графически со всеми средствами отладки, такими как точки останова и трассировки. Он также может работать с динамически подгружаемыми плагинами, в отличие от консольного gdb.
На данный момент существует примерно от 50 до 100 плагинов для данной IDE. Среди наиболее полезных – persistent project-wide code bookmarks, Code abbreviations, позволяющие быстро разворачивать текст, Source formatter, который переформатирует текст для style guide до сохранения, поиск по регулярным выражениям и project-wide поиск/замена.
Последней рассматриваемой ИСР является Microsoft Visual Studio (Microsoft Visual Studio, рис. 71). По сути, Microsoft Visual Studio является линейкой продуктов компании «Майкрософт», включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.
Рисунок 71. Интерфейс Microsoft Visual Studio
Microsoft Visual Studio включает один или несколько компонентов из следующих: Visual Basic.NET, Visual C++, Visual C#, Visual F#, Microsoft SQL Server, Visual InterDev, Visual J++, Visual J#, Visual FoxPro, Visual Source Safe.
Одним из главных преимуществ Майкрософт Визуал Студия является высокое качество документирования процесса разработки и описания возможных проблем в MSDN Library. Однако наиболее интересная для профессионала часть, посвящённая тонкостям разработки, существует только на английском языке.
Также компания «Майкрософт» предлагает бесплатный аналог продукта Visual Studio Express.
30. Эволюция языков программирования
26.08.2014 14:51 Александр
Развитие вычислительной техники сопровождается созданием новых и совершенствованием существующих средств общения программистов с ЭВМ — языков программирования (ЯП).
Под ЯП понимают правила представления данных и записи алгоритмов их обработки, которые автоматически выполняются ЭВМ. В более абстрактном виде ЯП является средством создания программных моделей объектов и явлений внешнего мира.
К настоящему времени созданы десятки различных ЯП от самых примитивных до близких к естественному языку человека. Чтобы разобраться во всем многообразии ЯП, нужно знать их классификацию, а также историю создания, эволюцию и тенденции развития.
Чтобы понимать тенденции развития ЯП, нужно знать движущие силы их эволюции. Для выяснения этого вопроса будем рассматривать ЯП с различных точек зрения.
Во-первых, ЯП является инструментом программиста для создания программ. Для создания хороших программ нужны хорошие ЯП. Поэтому одной из движущих сил эволюции ЯП является стремление разработчиков к созданию более совершенных программ.
Во-вторых, процесс разработки программы можно сравнивать с промышленным производством, в котором определяющими факторами являются производительность труда коллектива программистов, себестоимость и качество программной продукции. Создаются различные технологии разработки программ (структурное, модульное, объектно-ориентированное программирование и другие), которые должны поддерживаться ЯП. Поэтому второй движущей силой эволюции ЯП является стремление к повышению эффективности процесса производства программной продукции.
В-третьих, программы можно рассматривать как аналог радиоэлектронных устройств обработки информации, в которых вместо радиодеталей и микросхем используют конструкции ЯП (элементная база программы). Как и электронные устройства, программы могут быть простейшими (уровня детекторного приемника) и очень сложными (уровня автоматической космической станции), при этом уровень инструмента должен соответствовать сложности изделия. Кроме того, человеку удобнее описывать моделируемый объект в терминах предметной области, а не языком цифр. Поэтому третьей движущей силой, ведущей к созданию новых, специализированных, ориентированных на проблемную область и более мощных ЯП, является увеличение разнообразия и повышение сложности задач, решаемых с помощью ЭВМ.
В-четвертых, совершенствование самих ЭВМ приводит к необходимости создания языков, максимально реализующих новые возможности ЭВМ.
В-пятых, программы являются интеллектуальным продуктом, который нужно накапливать и приумножать. Но программы, как и технические изделия, обладают свойством морального старения, одной из причин которого является их зависимость от типа ЭВМ и операционной среды. С моральным старением программ борются путем их модернизации и выпуска новых версий, однако при высокой динамике смены типов ЭВМ и операционных сред разработчики будут только тем и заниматься, что модернизировать старые программы. Поэтому, ЯП должен обеспечивать продолжительный жизненный цикл программы, и стремление к этому является пятой движущей силой развития ЯП.
29. Трансляция и выполнение программы
26.08.2014 14:42 Александр
Если языки программирования имеет уже более или менее короткую историю развития, то сама технология подготовки программ, написанных на любом языке программирования, вообще сформировались в начале 60 годов и с тех пор не претерпела существенных изменений. Заложенные тогда принципы оказывают влияние на способы использования стандартных библиотечных функций и разработки больших программ, текст которой содержится в нескольких файлах (модульное программирование).
Подготовка программы начинается с редактирования файла, содержащего текст этой программы, который имеет стандартное расширение для данного языка. Затем выполняется его трансляция, которая включает в себя несколько фаз: препроцессор , лексический, синтаксический, семантический анализ , генерация кода и его оптимизация. В результате трансляции получается объектный модуль -некий «полуфабрикат» готовой программы, который потом участвует в ее сборке. Файл объектного модуля имеет стандартное расширение «.obj». Компоновка (сборка) программы заключается в объединении одного или нескольких объектных модулей программы и объектных модулей, взятых из библиотечных файлов и содержащих стандартные функции и другие полезные вещи. В результате получается исполняемая программа в виде отдельного файла (загрузочный модуль, программный файл) со стандартным расширением -«.exe», который затем загружается в память и выполняется.
28. Основные операторы циклов и ветвления
26.08.2014 14:37 Александр
Если в программе возникает необходимость неоднократного выполнения некоторых операторов, то используются операторы повтора (цикла). В языке Паскаль раз личают три вида операторов цикла: while , repeat , for . Они используются для орга низации циклов различных типов. Выражение, управляющее повторениями, долж но иметь булевский тип.
Если число повторений оператора (составного оператора) заранее неизвестно, а задано лишь условие его повторения (или окончания), используются операторы while , repeat . Оператор for используется, если число повторений заранее известно.
Оператор while
Оператор while (пока) часто называют оператором цикла с предусловием за то, что проверка условия выполнения тела цикла производится в самом начале оператора.
Синтаксическая диаграмма для данного оператора выглядит следующим обра зом: