- •Семестр 9 р1. Принципы построения пользовательского интерфейса в приложениях систем управления р1: Лекция №1. Обобщенная архитектура прикладной составляющей программного обеспечения систем управления
- •Жизненный цикл изделия и программные средства его поддержки
- •Обобщенная архитектура систем управления электроавтоматикой
- •Характеристики современного процесса разработки прикладной составляющей электроавтоматики
- •Вопросы:
- •Р1: Лекция №2. Базовые элементы платформы приложений су для построения интерфейса пользователя
- •Компоненты каркаса
- •Компоненты конфигурирования
- •Компоненты средств интерфейса пользователя
- •Конфигурирование компонентов в составе системы
- •Вопросы
- •Р1: Лекция №3. Принципы классификации прикладных компонентов систем управления
- •Виртуальная структура прикладной области
- •Матрица компонентов
- •Анализ и систематизация набора прикладных компонентов с применением матрицы
- •Определение минимально необходимого набора прикладных компонентов системы
- •Вопросы
- •Семестр 9 р2. Технологии .Net в разработке приложений систем управления р2: Лекция №4. Основные понятия платформы .Net
- •Строительные блоки .Net (clr, cts, cls)
- •Преимущества с#
- •Промежуточный язык msil
- •Работа с пространствами имен
- •Память в приложениях .Net
- •Проверка наличия утечек
- •Получение дополнительной информации о пространстве имен и типах сборки
- •Вопросы
- •Р2: Лекция №5. Принципы взаимодействия .Net с разработанным кодом
- •Преобразование исходных кодов в новый формат языков .Net
- •Использование двоичных компонентов для организации взаимодействия с компонентами .Net
- •Вопросы
- •Р2: Лекция №6. Инструментарий процесса разработки
- •P2: Лекция №6. Инструменты отладки приложений в .Net Framework 2.0 и выше Утилиты
- •Загрузка расширения отладки sos
- •Примеры:
- •Базовые различия
- •Сборка мусора в .Net Framework
- •Причины смешивания управляемого и неуправляемого кодов
- •Концепция CoDeSys
- •Окно приложения Сodesys:
- •P3. Лекция № 9. Возможности CoDeSys как открытой системы
- •Архитектура приложений современных систем управления
- •Выявление открытых интерфейсов среды
- •Встраивание сцены трёхмерного моделирования объекта управления
- •P3. Лекция № 10. Взаимодействие с аппаратными средствами платформы CoDeSys
- •Основные характеристики и назначение
- •Построения средств диагностики и управления устройствами электроавтоматики на базе opc технологии
- •Особенности механизмов работы opc серверов
- •Реализация интерфейсов opc в сервере
- •Реализация opc компонентов диагностики для контроллеров CoDeSys sp
- •Вопросы
- •Семестр 9 р4. Тестирование приложений систем управления через интерфейс оператора p4. Лекция № 11. Базовые понятия процесса тестирования
- •Жизненный цикл разработки программного обеспечения
- •Модели жизненного цикла
- •Каскадный жизненный цикл
- •Спиральный жизненный цикл
- •Экстремальное программирование
- •Тестирование, верификация и валидация - различия в понятиях
- •Задачи и цели процесса верификации
- •P4. Лекция № 12. Использование пакетов автоматизации тестирования
- •Методы проведения тестирования пользовательского интерфейса, повторяемость тестирования пользовательского интерфейса
- •1) Ручное тестирование
- •2) Сценарии на формальных языках
- •Тестирование удобства использования пользовательских интерфейсов.
- •Принцип использования коммерческих приложений для тестирования пользовательского интерфейса
- •Обзор Quickt Test. Основные понятия
- •Использование Actions, Iterations
- •Использование объекта DataTable и параметризация
- •Распознавание объектов в qtp и уникальность их свойств
- •P4. Лекция № 13 Модульное тестирование
- •Цели и задачи и модульного тестирования
- •Понятие модуля и его границ. Тестирование классов
- •Подходы к проектированию тестового окружения
- •P4. Лекция № 14. Возможности uiAutomation
- •Начальное представление
- •Представление элемента управления
- •Представление содержимого
- •Шаблоны элементов управления uia
Базовые различия
При работе с управляемым кодом программист размещает объекты в управляемой динамически распределяемой области памяти, используя оператор new (создать), причем освобождать их с помощью соответствующих операторов delete (удалить) не нужно. Это освобождает программиста от заботы об утечках памяти, и позволяет сосредоточить основное внимание на важных и полезных задачах, таких как более точная реализация проекта программы, что повышает производительность программирования и качество программного обеспечения.
Неуправляемый код C++ .NET должен самостоятельно управлять динамически распределяемой областью в памяти традиционными способами C++, используя операторы new (создать) и delete (удалить). Так как одним из наиболее общих недостатков в программах на C++ является ужасающая утечка памяти, поэтому использование управляемого кода C++ .NET может оказать очень положительное воздействие на многие разработки программного обеспечения.
Сборка мусора в .Net Framework
Сборщик мусора - это подсистема платформы .Net, предназначенная для того, чтобы очищать память. Идея состоит в том, что вся динамически выделяемая память распределяется в области кучи. Всякий раз когда .NET обнаруживает, что управляемая куча данного процесса заполнилась и нуждается в приведении в порядок, он вызывает сборщик мусора. Этот сборщик мусора проходит по всем переменным, находящимся в контексте вашего кода, и проверяет ссылки на объекты, расположенные в области кучи, чтобы идентифицировать, какие из них доступны из кода, то есть, чтобы узнать, на какие объекты существуют ссылки. Любой объект с отсутствием ссылок рассматривается как такой, к которому больше не будет осуществляться доступ из кода, потому объект может быть удален. Подобный этому механизм сборки мусора применяется и в Java.
Сборка мусора работает в .NET потому что IL спроектирован так, чтобы облегчить этот процесс. Принципы организации IL гласят, что вы не можете получить ссылки на существующий объект иначе, кроме как копированием существующих ссылок, а также то, что IL - язык безопасный к типам. В данном контексте мы имеем в виду, что если существует какая-то ссылка на обьект, то в этой ссылке содержится информация, достаточная для того, чтобы в точности определить тип объекта.
Механизм сборки мусора невозможно применить с таким языком, как например неуправляемый С++, потому что С++ допускает свободное приведение указателей к другим типам.
Одно важное свойство сборки мусора заключается в том, что это недетерминированный процесс. Другими словами, вы не можете знать, когда будет вызван сборщик мусора; он будет вызван тогда, когда CLR решит, что в этом есть необходимость, хотя также можно перекрыть этот процесс и вызвать сборщик мусора из вашего приложения.
Ограничения на использование управляемых типов в C++
Существует множество правил, которые ограничивают использование управляемых типов (классов, структур, интерфейсов), что ведет к затруднениям в работе с ними по сравнению с традиционными неуправляемыми типами в C++:
-
Управляемый тип не может быть наследован из неуправляемого типа. С другой стороны, неуправляемый тип не может быть наследован из управляемого типа. Это значит, что структуры иерархий наследственности управляемых и неуправляемых классов всегда отделены друг от друга.
-
В отличие от неуправляемых типов, управляемые не поддерживают множественную наследуемость реализации.
-
Управляемый тип может, очевидно, содержать член, который является указателем на управляемый объект. Управляемый тип также может содержать элемент данных, который является неуправляемым объектом или указателем на таковой. С другой стороны, неуправляемый тип не может включать в себя экземпляр управляемого типа или указатель на таковой.
-
Неуправляемый класс, в котором не указан явно базовый класс, является независимым корневым классом. В то же время, управляемый класс, в котором не указан явно ни один класс в качестве базового, является производным от корневого класса System: :Object.
-
К объекту, участвующему в сборке мусора (т.е. к экземпляру управляемого класса), можно получить доступ только посредством указателя (или ссылки) на объект в управляемой динамически распределяемой области памяти. Это является отличием от неуправляемых типов, которые могут содержаться либо непосредственно в переменной типа значения, либо к ним можно получить доступ посредством указателя на неуправляемую динамически распределяемую область памяти.
