Конспект лекции дисциплины «Графические системы и интерфейс оператора»


НазваниеКонспект лекции дисциплины «Графические системы и интерфейс оператора»
страница13/17
Дата публикации13.03.2013
Размер1.2 Mb.
ТипКонспект
userdocs.ru > Информатика > Конспект
1   ...   9   10   11   12   13   14   15   16   17
^

Реализация OPC компонентов диагностики для контроллеров CoDeSys SP


В качестве базовой реализации элементов данных используется класс CDAIItemBase, определенный на стороне OPC сервера (Рис. 37). Наследование от этого класса позволяет не реализовывать базовую функциональность, которая является общей для всех элементов данных. Методы, которые требуют специфической реализации, можно переопределить в производных классах.



Рис. 37. Иерархия классов элементов данных

Внутри компонента интеграции с помощью механизма наследования определяется базовый класс CPlcItem (Рис. 37) для всех разновидностей элементов данных. Характерной особенностью объектов этого класса является то, что они содержат в себе объект CPlcVarList, который представляет собой связующее звено между запросом к элементу данных компонента интеграции и интерфейсом взаимодействия с устройством электроавтоматики (Рис. 34). Конечной реализацией элементов данных являются классы CPlcItemImpls, унаследованные от CPlcItem, которые реализуют получение диагностических данных от контроллеров.

Обобщенная схема получения диагностических данных OPC клиентами представлена на Рис. 38. При обращении OPC клиента к OPC серверу (вызов 1 на Рис. 38) происходит запрос к элементу данных CPlcItemImpl (вызов 2) компонента интеграции в основном потоке. После этого элемент данных добавляется в очередь запросов (вызов 3) и обрабатывается в отдельном потоке функцией обработки запросов (вызов 4). Дополнительный поток обработки запросов необходим для того, чтобы организовать одновременный доступ к синхронным сервисам OPC сервера для его клиентов.

Функция обработки запросов (вызов 5), выполняемая в отдельном потоке, осуществляет взаимодействие с устройством электроавтоматики через интерфейс PLCHandler (вызовы 6.1. и 6.2). Уведомление элемента данных CPlcItemImpl (вызов 9) о завершении обработки запроса (вызов 7) происходит через скрытое окно (вызов 8). После этого происходит возврат фокуса управления обратно OPC серверу (вызов 10) и OPC клиенту (вызов 11).



Рис. 38. Обработка синхронного запроса OPC клиента

Представленный механизм обработки синхронных запросов к устройству электроавтоматики является универсальным для одновременного использования несколькими OPC клиентами. Наличие очереди обусловлено необходимостью обработки нескольких синхронных запросов от OPC клиентов. Уведомление о завершении работы с интерфейсом PLCHandler, отправляемое через скрытое окно, означает готовность поля данных CPlcVarList.

Вопросы


  1. Назначение интерфейса PlcHandler

  2. Создание/уничтожение и конфигурирование экземпляра CPLCHandler.

  3. Подключение/отключение, получение значений переменных управляющих программ исполняемых на контроллере.

  4. Типы коммуникационных каналов для подключения к PLC.
^

Семестр 9
Р4. Тестирование приложений систем управления через интерфейс оператора

P4. Лекция № 11. Базовые понятия процесса тестирования


Понятие верификации. Жизненный цикл разработки программного обеспечения. Тестирование, верификация и валидация - различия в понятиях. Типы процессов тестирования и верификации и их место в различных моделях жизненного цикла. Задачи и цели процесса верификации.

Верификация - это процесс определения, выполняют ли программные средства и их компоненты требования, наложенные на них в последовательных этапах жизненного цикла разрабатываемой программной системы.

Основная цель верификации состоит в подтверждении того, что программное обеспечение соответствует требованиям. Дополнительной целью является выявление и регистрация дефектов и ошибок, которые внесены во время разработки или модификации программы.

Верификация является неотъемлемой частью работ при коллективной разработке программных систем. При этом в задачи верификации включается контроль результатов одних разработчиков при передаче их в качестве исходных данных другим разработчикам.

Для повышения эффективности использования человеческих ресурсов при разработке верификация должна быть тесно интегрирована с процессами проектирования, разработки и сопровождения программной системы.

Заранее разграничим понятия верификации и отладки. Оба этих процесса направлены на уменьшение ошибок в конечном программном продукте, однако отладка - процесс, направленный на локализацию и устранение ошибок в системе, а верификация - процесс, направленный на демонстрацию наличия ошибок и условий их возникновения.

Кроме того, верификация, в отличие от отладки - контролируемый и управляемый процесс. Верификация включает в себя анализ причин возникновения ошибок и последствий, которые вызовет их исправление, планирование процессов поиска ошибок и их исправления, оценку полученных результатов. Все это позволяет говорить о верификации как о процессе обеспечения заранее заданного уровня качества создаваемой программной системы.
^

Жизненный цикл разработки программного обеспечения


Коллективная разработка, в отличие от индивидуальной, требует четкого планирования работ и их распределения во время создания программной системы. Один из способов организации работ состоит в разбиении процесса разработки на отдельные последовательные стадии, после полного прохождения которых получается конечный продукт или его часть. Такие стадии называют жизненным циклом разработки программной системы. Как правило, жизненный цикл начинается с формирования общего представления о разрабатываемой системе и его формализации в виде требований верхнего уровня. Завершается жизненный цикл разработки вводом системы в эксплуатацию. Однако, нужно понимать, что разработка - только один из процессов, связанных с программной системой, которая также имеет свой жизненный цикл. В отличие от жизненного цикла разработки системы, жизненный цикл самой системы заканчивается выводом ее из эксплуатации и прекращением ее использования.

^ Жизненный цикл программного обеспечения - совокупность итерационных процедур, связанных с последовательным изменением состояния программного обеспечения от формирования исходных требований к нему до окончания его эксплуатации конечным пользователем.

В контексте данного курса практически не будут затрагиваться такие этапы жизненного цикла, как системная интеграция и сопровождение. Для целей курса достаточно ограничиться упрощенным представлением, что после реализации кода и доказательства его соответствия требованиям разработка ПО завершается.
^

Модели жизненного цикла


Любой этап жизненного цикла имеет четко определенные критерии начала и окончания. Состав этапов жизненного цикла, а также критерии, в конечном итоге определяющие последовательность этапов жизненного цикла, определяется коллективом разработчиков и/или заказчиком. В настоящее время существует несколько основных моделей жизненного цикла, которые могут быть адаптированы под реальную разработку.
^

Каскадный жизненный цикл


Каскадный жизненный цикл (иногда называемый водопадным) основан на постепенном увеличении степени детализации описания всей разрабатываемой системы. Каждое повышение степени детализации определяет переход к следующему состоянию разработки (Рис. 39).



Рис. 39 Каскадная модель жизненного цикла

На первом этапе составляется концептуальная структура системы, описываются общие принципы ее построения, правила взаимодействия с окружающим миром, - определяются системные требования.

На втором этапе по системным требованиям составляются требования к программному обеспечению - здесь основное внимание уделяется функциональности программной компоненты, программным интерфейсам. Естественно, все программные комплексы выполняются на какой-либо аппаратной платформе. Если в ходе проекта требуется также разработка аппаратной компоненты, параллельно с требованиями к программному обеспечению идет подготовка требований к аппаратному обеспечению.

На третьем этапе на основе требований к программному обеспечению составляется детальная спецификация архитектуры системы - описываются разбиение системы по конкретным модулям, интерфейсы между ними, заголовки отдельных функций и т.п.

На четвертом этапе пишется программный код, соответствующий детальной спецификации, на пятом этапе выполняется тестирование - проверка соответствия программного кода требованиям, определенным на предыдущих этапах.

Особенность каскадного жизненного цикла состоит в том, что переход к следующему этапу происходит только тогда, когда полностью завершены все работы предыдущего этапа. То есть сначала полностью готовятся все требования к системе, затем по ним полностью готовятся все требования к программному обеспечению, полностью разрабатывается архитектура системы и так далее до тестирования.

Естественно, что в случае достаточно больших систем такой подход себя не оправдывает. Работа на каждом этапе занимает значительное время, а внесение изменений в первичные документы либо невозможно, либо вызывает лавинообразное изменения на всех других этапах.

Как правило, используется модификация каскадной модели, допускающая возврат на любой из ранее выполненных этапов. При этом фактически возникает дополнительная процедура принятия решения.

Действительно если тесты обнаружили несоответствие реализации требованиям, то причина может крыться: (а) в неправильном тесте, (б) в ошибке кодирования (реализации), (в) в неверной архитектуре системы, (г) в некорректности требований к программному обеспечению и т.д. Все эти случаи требуют анализа, для того чтобы принять решение о том, на какой этап жизненного цикла надо возвратиться для устранения обнаруженного несоответствия.
^

V-образный жизненный цикл


В качестве своеобразной "работы над ошибками" классической каскадной модели стала применяться модель жизненного цикла, содержащая процессы двух видов - основные процессы разработки, аналогичные процессам каскадной модели, и процессы верификации, представляющие собой цепь обратной связи по отношению к основным процессам (Рис. 40).



Рис. 40 V-образный жизненный цикл

Таким образом, в конце каждого этапа жизненного цикла разработки, а зачастую и в процессе выполнения этапа, осуществляется проверка взаимной корректности требований различных уровней. Данная модель позволяет более оперативно проверять корректность разработки, однако, как и в каскадной модели, предполагается, что на каждом этапе разрабатываются документы, описывающие поведение всей системы в целом.
^

Спиральный жизненный цикл


Оба рассмотренных типа жизненных циклов предполагают, что заранее известны все требования пользователей или, по крайней мере, предполагаемые пользователи системы настолько квалифицированы, что могут высказывать свои требования к будущей системе, не видя ее перед глазами.

Естественно, такая картина достаточно утопична, поэтому постепенно появилось решение, исправляющее основной недостаток V-образного жизненного цикла - предположение о том, что на каждом этапе разрабатывается очередное полное описание системы. Этим решением стала спиральная модель жизненного цикла (Рис. 41).



Рис. 41 Спиральный жизненный цикл

В спиральной модели разработка системы происходит повторяющимися этапами - витками спирали. Каждый виток спирали - один каскадный или V-образный жизненный цикл. В конце каждого витка получается законченная версия системы, реализующая некоторый набор функций. Затем она предъявляется пользователю, на следующий виток переносится вся документация, разработанная на предыдущем витке, и процесс повторяется.

Таким образом, система разрабатывается постепенно, проходя постоянные согласования с заказчиком. На каждом витке спирали функциональность системы расширяется, постепенно дорастая до полной.
^

Экстремальное программирование


Реалии последних лет показали, что для систем, требования к которым изменяются достаточно часто, необходимо еще больше уменьшить длительность витка спирального жизненного цикла. В связи с этим сейчас стали весьма популярными быстрые жизненные циклы разработки, например, жизненный цикл в методологии eXtreme Programming (XP).

Основная идея жизненного цикла экстремального подхода - максимальное укорачивание длительности одного этапа жизненного цикла и тесное взаимодействие с заказчиком. По сути, на каждом этапе происходит реализация и тестирование одной функции системы, после завершения которых система сразу передается заказчику на проверку или эксплуатацию.

Основная проблема данного подхода - интерфейсы между модулями, реализующими эту функцию. Если во всех предыдущих типах жизненного цикла интерфейсы достаточно четко определяются в самом начале разработки, поскольку заранее известны все модули, то при экстремальном подходе интерфейсы проектируются "на лету", вместе с разрабатываемыми модулями.

^

Тестирование, верификация и валидация - различия в понятиях


Несмотря на кажущуюся схожесть, термины "тестирование", "верификация" и "валидация" означают разные уровни проверки корректности работы программной системы. Дабы избежать дальнейшей путаницы, четко определим эти понятия (Рис. 42).

^ Тестирование программного обеспечения - вид деятельности в процессе разработки, который связан с выполнением процедур, направленных на обнаружение (доказательство наличия) ошибок (несоответствий, неполноты, двусмысленностей и т.д.) в текущем определении разрабатываемой программной системы. Процесс тестирования относится в первую очередь к проверке корректности программной реализации системы, соответствия реализации требованиям, т.е. тестирование - это управляемое выполнение программы с целью обнаружения несоответствий ее поведения и требований.



Рис. 42 Тестирование, верификация и валидация

Верификация программного обеспечения - более общее понятие, чем тестирование. Целью верификации является достижение гарантии того, что верифицируемый объект (требования или программный код) соответствует требованиям, реализован без непредусмотренных функций и удовлетворяет проектным спецификациям и стандартам. Процесс верификации включает в себя инспекции, тестирование кода, анализ результатов тестирования, формирование и анализ отчетов о проблемах. Таким образом, принято считать, что процесс тестирования является составной частью процесса верификации, такое же допущение сделано и в данном учебном курсе.

^ Валидация программной системы - целью этого процесса является доказательство того, что в результате разработки системы мы достигли тех целей, которые планировали достичь благодаря ее использованию. Иными словами, валидация - это проверка соответствия системы ожиданиям заказчика. Вопросы, связанные с валидацией, выходят за рамки данного учебного курса и представляют собой отдельную интересную тему для изучения.

Если посмотреть на эти три процесса с точки зрения вопроса, на который они дают ответ, то тестирование отвечает на вопрос "Как это сделано?" или "Соответсвует ли поведение разработанной программы требованиям?", верификация - "Что сделано?" или ""Соответствует ли разработанная система требованиям?", а валидация - "Сделано ли то, что нужно?" или "Соответствует ли разработанная система ожиданиям заказчика?".
^

Задачи и цели процесса верификации


Сначала рассмотрим цели верификации. Основная цель процесса - доказательство того, что результат разработки соответствует предъявленным к нему требованиям. Обычно процесс верификации проводится сверху вниз, начиная от общих требований, заданных в техническом задании и/или спецификации на всю информационную систему, и заканчивая детальными требованиями к программным модулям и их взаимодействию. В состав задач процесса входит последовательная проверка того, что в программной системе:

  • общие требования к информационной системе, предназначенные для программной реализации, корректно переработаны в спецификацию требований высокого уровня к комплексу программ, удовлетворяющих исходным системным требованиям;

  • требования высокого уровня правильно переработаны в архитектуру ПО и в спецификации требований к функциональным компонентам низкого уровня, которые удовлетворяют требованиям высокого уровня;

  • спецификации требований к функциональным компонентам ПО, расположенным между компонентами высокого и низкого уровня, удовлетворяют требованиям более высокого уровня;

  • архитектура ПО и требования к компонентам низкого уровня корректно переработаны в удовлетворяющие им исходные тексты программных и информационных модулей;

  • исходные тексты программ и соответствующий им исполняемый код не содержат ошибок.

Кроме того, верификации на соответствие спецификации требований на конкретный проект программного средства подлежат требования к технологическому обеспечению жизненного цикла ПО, а также требования к эксплуатационной и технологической документации.

Цели верификации ПО достигаются посредством последовательного выполнения комбинации из инспекций проектной документации и анализа их результатов, разработки тестовых планов тестирования и тест-требований, тестовых сценариев и процедур и последующего выполнения этих процедур. Тестовые сценарии предназначены для проверки внутренней непротиворечивости и полноты реализации требований. Выполнение тестовых процедур должно обеспечивать демонстрацию соответствия испытываемых программ исходным требованиям.

На выбор эффективных методов верификации и последовательность их применения в наибольшей степени влияют основные характеристики тестируемых объектов:

  • класс комплекса программ, определяющийся глубиной связи его функционирования с реальным временем и случайными воздействиями из внешней среды, а также требования к качеству обработки информации и надежности функционирования;

  • сложность или масштаб (объем, размеры) комплекса программ и его функциональных компонентов, являющихся конечными результатами разработки;

  • преобладающие элементы в программах: осуществляющие вычисления сложных выражений и преобразования измеряемых величин или обрабатывающие логические и символьные данные для подготовки и отображения решений.

Определим некоторые понятия и определения, связанные с процессом тестирования как составной части верификации. Майерс дает следующие определения основных терминов (Г. Майерс Надежность программного обеспечения М.: «Мир», 1980. 360 с):

Тестирование - процесс выполнения программы с целью обнаружения ошибки.

^ Тестовые данные - входы, которые используются для проверки системы.

Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований.

^ Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.

Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку.

Ошибка - действие программиста на этапе разработки, приводящее к тому, что в программном обеспечении содержится внутренний дефект, который в процессе работы программы может привести к неправильному результату.

Отказ - непредсказуемое поведение системы, приводящее к неожидаемому результату, которое могло быть вызвано дефектами, содержащимся в ней.

Таким образом, в процессе тестирования программного обеспечения, как правило, проверяют следующее:

  • программное обеспечение соответствует требованиям на него;

  • в ситуациях, не отраженных в требованиях, программное обеспечение ведет себя адекватно, то есть не происходит отказ системы;

  • наличие типичных ошибок, которые делают программисты.
1   ...   9   10   11   12   13   14   15   16   17

Похожие:

Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconПлан-конспект лекции Тема лекции «Культура Античности»
Зелинский Ф. Ф. Древний мир и мы. Научно популярные статьи [1904]. Спб., 1997. ("Из жизни идей", т. 2)
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconВопросы к зачёту (1-й семестр)
Прикладное программное обеспечение: системы управления базами данных, графические редакторы
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconЛабораторная работа Оценка соответствия эргономических параметров рабочего места оператора пэвм
Рассмотреть составляющие элементы рабочего места оператора персонального компьютера (ПК). Ознакомиться с принципами оптимальной организации...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconКонспект лекции План лекции Цель, задачи и объекты анализа финансовой...
Одним из видов экономического анализа является финансовый анализ, который с определенной долей условности подразделяется на внутренний...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconС. П. Филин Концепции современного естествознания: конспект лекций
Конспект лекций соответствует требованиям Государственного образовательного стандарта высшего профессионального образования РФ и...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconДжеф Раскин, Интерфейс: новые направления в проектировании компьютерных систем
...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» icon«Психодиагностика. Конспект лекций»: Эксмо; Москва; 2008 isbn 978-5-699-26681-4
Книга предназначена длястудентов-психологов и представляет собой конспект лекций по психодиагностике. Подробное изложение материала...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconПрограмма лекции Адрес Время проведения лекции Участники лекции 12...

Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconТема №1 Первичные графические элементы композиции и основные принципы ее организации
Онятие. Система, структура. Психологические особенности восприятия визуальной информации. Зоны активного восприятия. Взаимосвязь...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconДисциплины
Всего часов 108, из них аудиторных занятий 48 (лекции – 32, практические занятия –16)
Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2015
контакты
userdocs.ru
Главная страница