- •Вопросы:
- •Лекция №5-6. Базовые элементы платформы приложений су для построения интерфейса пользователя. Концепция открытой модульной архитектуры в приложениях прикладного программного обеспечения
- •Компоненты каркаса
- •Конфигурирование компонентов в составе системы
- •Вопросы
- •Лекция №9-10. Принципы классификации прикладных компонентов систем управления. Принцип трехуровневого конфигурирования компонентов в приложениях су. Инструменты конфигурирования и их принципы работы.
- •Виртуальная структура прикладной области
- •Преобразование исходных кодов в новый формат языков .Net
- •Обобщенно использование двоичных компонентов заключается в следующем:
- •Вопросы
- •Лекция №13-14. Инструменты отладки приложений в .Net Framework 2.0 и выше.
- •Сборка мусора в .Net Framework
- •Причины смешивания управляемого и неуправляемого кодов
- •2. В чём заключается Концепция CoDeSys?
- •Для высших стандартов качества системы существует три аспекта:
- •Интерфейс PlcHandler предоставляет следующие функции и сервисы:
- •Реализация opc компонентов диагностики для контроллеров CoDeSys sp
- •Вопросы
- •Каскадный жизненный цикл
- •Тестирование, верификация и валидация - различия в понятиях
- •Задачи и цели процесса верификации
- •2) Сценарии на формальных языках
- •Принцип использования коммерческих приложений для тестирования пользовательского интерфейса
- •Обзор Quickt Test. Основные понятия
- •Использование объекта DataTable и параметризация
- •Распознавание объектов в qtp и уникальность их свойств
- •5. Использование объекта DataTable и параметризация
- •6. Распознавание объектов в qtp и уникальность их свойств
- •5. Практический (лабораторный) комплекс Лабораторная работа №1
- •Лабораторная работа №2
- •Лабораторная работа № 3
- •6. Перечень тестовых вопросов для промежуточного и итогового контроля
- •197.Группа компьютеров, связанных каналами передачи информации и находящихся в пределах территории, ограниченной небольшими размерами: комнаты, здания, предприятия, называется:
Преобразование исходных кодов в новый формат языков .Net
В данном случае имеется возможность для преобразования исходных кодов (С++, VisualBasic, JavA в формат приемлемый для компиляции в среде .NET. Для С++ этот переход имеет следующие возможности:
Перекомпиляция приложения с использованием опции /CLR
Переписывание системных сервисов (c использованием классов .NET)
Переход к managed code (использование C++ managed extensions)
Переход к verifiable code (поддающийся проверке код), уничтожение адресной арифметики, явная запись boxing / unboxing (преобразование структурного типа в ссылочный и наоборот – упаковка / распаковка) и т.д. Процесс перехода к managed C++ может быть постепенным. Однако существуют трудности взаимодействия между managed и unmanaged code (например, распространение исключений, сборка мусорA. Переход к управляемым указателям должен производиться одновременно для всех связанных указателей (нельзя использовать управляемый указатель в неуправляемом коде). Существуют также трудности использования сложных типов данных (ограничение названия: 256 символов).Для не менее популярных языков программирования VisualBasic и Java предусмотрено преобразование исходных кодов с применением специальных механизмов преобразования. Для преобразования исходных кодов VisualBasic применяется подсистема обновления проекта (Upgrade project), где возможно произвести настройки конвертирования. Для Java используется специальный инструмент JUMP (Java Users Migration Path). В качестве решения проблемы независимости от платформы исполнения, предлагается миграция в C#.
Использование двоичных компонентов для организации взаимодействия с компонентами .NET
Обобщенно использование двоичных компонентов заключается в следующем:
Взаимодействие с COM компонентами:
COM сервисы для .NET
.NET сервисы для COM
Использование вызовов функций из DLL
Существует ряд важных причин для использования взаимодействия COM и .NET:
Взаимодействие необходимо для сохранения финансовых вложений в COM-приложения
Для осуществления постепенной пошаговой миграции на новую платформу
Некоторые приложения никогда не будут переписываться под .NET и поэтому необходимо двустороннее взаимодействие, для внедрения новых компонентов в существующие приложения
Естественно для решения задачи взаимодействия с COM модулями необходимо обеспечить какой-то промежуточный уровень. Этот уровень транслирует вызовы .NET в вызовы COM, представляя типы COM в виде типов .NET и наоборот.
Для
взаимодействия с сервисами COM, роль
промежуточного уровня в .NET выполняет
служба RWC (Runtime Callable Wrapper – вызываемая
оболочка времени выполнения)
Рис.
13
Взаимодействие .NET c COM сервисом
Типы данных из COM можно использовать как обычные управляемые типы:
Можно создавать экземпляры с помощью new
Можно ловить исключения
Можно даже расширять типы данных и наследовать от них! При использовании COM сервисов происходит преобразование типов данных. Модуль RCW предоставляет типы COM для клиента .NET точно так же, как будто это обычные типы .NET. При этом происходит скрытие низкоуровневых интерфейсов (такие как IUnknown, IDispatch, IConnectionPoint и другие). С другой стороны для обеспечения доступа клиента COM к типу .NET используется специальный промежуточный уровень называемый CCW (COM Callable Wrapper – оболочка для COM с возможностью вызовA. Роль CCW представлена на рисунке (Рис. 20):
Рис.
14
Взаимодействие COM c сервисом .NET
Модуль CCW автоматически реализует множество служебных интерфейсов COM, чтобы создать у клиентов COM полную иллюзию, что они имеют дело с соклассом. Помимо этого модуль CWW, конечно же, реализуют пользовательские интерфейсы типов .NET, включая так называемый интерфейс класса (специальный интерфейс, в который помещаются все свойства, методы, поля и события, которые определены в типе как public). CCW также управляет экземплярами, исключениями, преобразованием сигнатур и т.д. Использование вызова функций, реализованных в традиционных двоичных модулях, из кода .NET обеспечивается службой активизации платформ (Platform Invocation Services, PInvoke). PInvoke передаёт параметры при вызове функций, транслируя типы данных .NET в их аналоги в традиционном двоичном коде.
Рис.
15
Использование вызовов DLL
