2) Разработчики могут дополнительно интегрировать свой движок валидации или воспользоваться сторонними фреймворками: Castle Validator, EntLib Validation Library. Возможности валидации ASP.NET MVC 2 разработаны с учетом легкости расширения архитектуры валидации.
Это означает, что производить валидацию очень просто в ряде распространенных случаев, при этом сохраняется гибкость для расширения.
До сохранения в базу данных, мы хотим убедиться, что введенная информация корректна, а если нет - вывести соответствующее сообщение об ошибке:
Мы хотим, чтобы валидация происходила на двух сторонах - сервере и клиенте, а также хотим удостовериться, что код соответствует принципу DRY(“don’t repeat yourself”) - мы применяем правила валидации один раз, после этого все контроллеры, действия и представления соблюдают их.
Я реализую данный сценарий, используя VS 2010, но вы так же сможете это сделать и в VS 2008.
У класса четыре свойства, созданные при помощи автоматически реализуемых свойств в C#, которые появились и в VB с VS 2010.
Добавим в наш проект класс-контроллер «FriendsController», который расширим двумя методами действий «Create». Первый метод вызывается во время GET запроса /Friends/Create - он отобразит пустую форму для ввода данных о человеке. Второй метод вызывается во время POST запроса /FriendsCreate - он привязывает введенные данные формы к объекту Person, проверяет на наличие ошибок при связывании и, если ошибок не произошло, в конечном итоге сохраняет в базу данных (саму реализацию работы с базой данных реализуем чуть позже). Если введенные данные в форму содержат ошибки, метод вернет пользователю форму с ошибками:
После создания нашего контроллера, мы можем нажать правой кнопкой по одному из методов действия и выбрать «Add View», мы воспользуемся скафолдингом для создания «Create» представления, которое принимает объект Person:
Visual Studio сгенерирует для нас файл представления Create.aspx в директории \Views\Friends нашего проекта. Обратите внимание на использование :
А сейчас, когда мы запустим приложение и перейдем на /Friends/Create, то получим пустую форму для ввода данных:
На данный момент ничто не остановит нас при вводе не корректных данных.
В ASP.NET MVC 2 разработчики могут легко добавлять декларативные атрибуты валидации в классы модели или модели представления, которые в дальнейшем используются при операции связывании с моделью. Чтобы увидеть это в действии, давай-те обновим класс Person, добавив несколько атрибутов. Добавим определение «using» для пространства имен “System.ComponentModel.DataAnnotations”, а далее оформим свойства Person, используя атрибуты валидации , , и
Обратите внимание на объявление текста ошибок, как строк. Вы можете объявить их в файлах ресурсов и локализировать в зависимости от выбранного пользователем языком или культурой. Более детально о локализации ошибок валидации .
И вот, когда у нас добавлены атрибуты валидации в класс Person, давайте перезапустим наше приложение, чтобы увидеть реакцию на некорректно введенные данные, отправив их на сервер:
Заметили, как у нас все стало прилично? Текст ошибки подсечен красным, а сама ошибка выведена рядом с полем. Форма сохраняет введенный данные, так что мы избавляем пользователя от нужды вводить их повторно. И как же, черт побери, все это происходит?
Чтобы понять принцип работы, давайте взглянем на метод действия Create, который обрабатывает POST запрос нашей формы:
Когда наша HTML форма возвращает данные серверу, вызывается выше приведенный метод. Так как метод действия принимает объект Person, как параметр, ASP.NET MVC создаст объект Person и автоматически свяжет входящие данные формы с его значениями. Так же, как часть данного процесса, произойдет проверка на соответствие правилам валидации DataAnnotation объекта Person. В случае удачной проверки, ModelState.IsValid вернет true и мы сохраним результат в базу и перекинем пользователя на home-страницу.
Если произойдет любая ошибка валидации, наш метод действия вновь отобразит форму с не правильными данными объекта Person. Это реализовывается с помощью последней строки в приведенном выше коде.
Сообщения об ошибках отображаются на странице благодаря вспомогательному методу <%= Html.ValidationMessageFor() %> после каждого <%= Html.TextBoxFor() %> в форме Create. Вспомогательный метод Html.ValidationMessageFor() отобразит соответствующее сообщение об ошибке для любого не валидного свойства модели, переданного в представление:
Удобство данного паттерна в простоте внедрения в код, а также простота в добавлении или изменении правил валидации нашего класса Person, без надобности изменять код за пределами модели. Возможность определить правила валидации в одном месте и принудительное использование данных правил в любом уголке приложения позволяет нам быстро развивать наше приложение с минимальными усилиями, при это избегая дублирование кода.
Одной из вкусностей в ASP.NET MVC 2 является архитектура валидации, которая поддерживает проверку на сервере и на клиенте. Для этого нам всего-лишь нужно добавить два JavaScript скрипта в представлении и написать одну строчку кода:
После добавления трех строчек ASP.NET MVC 2 будет использовать валидационные метаданные, которые мы указали в классе Person и создаст логику валидации на стороне клиента, используя JavaScript. Пользователь же увидит ошибку, как только перейдет на другой элемент.
Чтобы увидеть проверку на клиенте в действии, перезапустим приложение и заполним первые три текстовых поля корректными данными, а далее попробуем нажать «Create». Заметьте каким образом мы получили информацию об ошибке, никакой отправки данных на сервер не произошло:
Если мы введем текст, который не является корректным адресом электронной почты, то ошибка сразу изменится с «Email required» на «Not a valid email», оба сообщения мы объявили ранее в классе Person:
Когда же мы введем корректный адрес электронной почты - сообщение об ошибке исчезнет и фон текстового поля вернется в нормальное состояние:
Нам не нужно писать никакого собственного JavaScript кода для добавления логики валидации. Наш код до сих пор соответствует принципу DRY.
По причинам безопасности правила валидации всегда запускаются на сервере, даже если вы включили проверку на стороне клиентов. Это предотвращает от попыток хакеров обмануть ваш сервер обходя валидацию на клиенте.
Клиентская JavaScript валидация может работать с любым фреймворком/движком, который вы используете с ASP.NET MVC. Нет ограничений в использовании DataAnnotation, вся инфраструктура работает независимо от DataAnnotation и может работать с Castle Validator, EntLib Validation Block или любым другим решением.
Если вы не желаете использовать наши JavaScript файлы, вы можете заменить их на плагин валидации jQuery и использовать его. Дополнение ASP.NET MVC Futures будет включать в себя поддержку jQuery валидации.
Но вы можете объявить свой собственный атрибут валидации и использовать его. Вы можете создать полностью новый атрибут наследуясь от класса ValidationAttribute, который находится в пространстве имен System.ComponentModel.DataAnnotations. А можете создать атрибут на основе существующих, если хотите просто расширить их функциональность.
Например, для поддержания чистоты кода в нашем классе Person мы хотим создать новый атрибут валидации , который инкапсулирует регулярное выражение для проверки электронных адресов. Простой способ - унаследоваться от класса RegularExpression и вызывать конструктор класса RegularExpression с соответствующим регулярным выражением:
Теперь мы можем обновить класс Person и использовать наш новый атрибут валидации взамен предыдущего регулярного выражения, согласитесь - код стал чище:
Когда вы создаете собственный атрибут валидации, то можете определить правила проверок на сервере и клиенте.
Напоследок, для создания собственных атрибутов, которые обращаются к индивидуальным свойства объекта, вы можете обращаться к атрибутам валидации на уровне класса. Это позволяет вам реализовать логику в связке с несколькими свойствами в объекте. Например, можете посмотреть на атрибут «PropertiesMustMatchAttribute», который находится в файле AccountModels.cs/vb в стандартном шаблоне приложения ASP.NET MVC 2 (File>New ASP.NET MVC 2 Web Project в VS 2010).
Сейчас мы используем с C# класс старого образца (часто называемыем, как «POCO» класс - «plain old CLR object»). Один из подходов - написать отдельно код, который привязывает существующий класс к базе данных. На сегодняшний день, такие решения на основе объектно-реляционной проекции (ORM), как NHibernate отлично поддерживают стиль POCO связи. ADO.NET Entity Framework (EF), который выйдет с.NET 4 так же поддерживает POCO связи и, как NHibernate, дополнительно поддерживает возможность связи через код, не используя файлов связи или конструтора.
Если наш объект Person был связан с базой данных одним из перечисленных способов, то нам не нужно вносить никаких изменений в класс Person.
А что если мы используем визуальный инструмент для наших ORM-связей?
Сегодня, многие разработчики использующие Visual Studio не пишут собственную ORM-логику связей, а используют встроенные в VS конструкторы, чтобы решить данную проблему.
Часто возникает вопрос при использовании DataAnnotation (или любой другой формы атрибутов, основанных на валидации) - «как вы примените правила, когда модель объекта, с который вы работаете, создана с помощью GUI конструктор?». Например, если мы взамен класса Person, оформленного в стиле POCO, создадим класс Personal в Visual Studio, используя GUI-интсрумент связей - LINQ to SQL или ADO.NET EF:
На скриншоте вы видите класс Person, объявленный с помощью конструктора ADO.NET EF в VS 2010. Верхнее окно определяет класс Person, нижнее - отображает редактор связей, а именно, как свойства привязываются к таблице базы данных «People». После сохранение автоматически сгенерируется класс Person. Это удобно, за исключением того, что при каждом изменении вам нужно будет сохранять файл, что приведет к полной перегенерации класса Person и вы потеряете все объявленные атрибуты валидации.
Решение, которое поможет применить к автоматически созданному классу дополнительные метаданные атрибутов - дружественные классы. Фактически - вы создаете отдельный класс, который содержит ваши атрибуты валидации и метаданных, а далее привязываете его к сгенерированному классу, применяя атрибут «MetadataType» к сгенерированному partial-классу. Например, мы хотим применить правила валидации, которые использовали ранее, к классу Person, созданному с помощью конструктора LINQ to SQL или ADO.NET EF, для этого вынесем наш код валидации в класс «Person_Validation» и свяжем его с классом «Person»:
Данный вариант уступает в элегантности варианту POCO, но у него преимущество в работе с большинством инструментов или с сгенерированным конструкторами кодом в Visual Studio.
Для этого заменяем «Todo» метку в классе FriendsController тремя строчками кода, которые будут сохранять нового друга в базу данных. Ниже представлена полная версия класса FriendsController, который работает с ADO.NET EF:
Теперь, когда мы посетим URL /Friends/Create, то сможем легко добавить новый объект People в список наших друзей в базе данных:
Валидация всех данных происходит на клиенте и на сервере. Мы можем легко добавлять/изменять/удалять правила валидации и они будут использованы в обязательном порядке любым контроллером или представлением в наше приложении.
При моделировании исследователь должен быть уверен в корректности модели, в соответствии модели реальному прототипу. Точность математического моделирования зависит от того, насколько хорошо математическая модель отражает свойства объекта. Исследователю важно знать, с какой погрешностью он получает результат, потому что в случае большой погрешности расчет теряет смысл.
На точность моделирования влияют следующие особенности:
■ упрощение модели;
■ ошибки при построении модели;
■ использование элементов с низкой точностью, с линейной аппроксимацией;
■ наличие в модели вырожденных конечных элементов;
■ некорректные связи;
■ некорректные параметры моделей;
■ некорректные свойства элементов;
■ некорректные начальные и граничные условия;
■ погрешности метода расчетов.
На основании результатов испытаний, таких, например, как показания приборов, вносятся изменения в математическую модель. В итоге создается модель, результаты использования которой совпадают с реальными объектами с заданной погрешностью.
Верификация модели (model verification) – проверка ее истинности, адекватности. Дословный перевод с английского: verification – это: 1) контроль, проверка; Sync: check, examination; 2) удостоверение, подтверждение (предсказания, сомнения) (а); подтверждение под присягой (б); 3) засвидетельствование. В отношении к дескриптивным моделям верификация модели сводится к сопоставлению результатов расчетов по модели с соответствующими данными действительности – фактами и закономерностями экономического развития. В отношении нормативных (в том числе оптимизационных) моделей положение сложнее: в условиях действующего экономического механизма моделируемый объект подвергается различным управляющим воздействиям, не предусмотренным моделью; надо ставить специальный экономический эксперимент с учетом требований чистоты, т.е. устранения влияния этих воздействий, что представляет собой трудную, во многом еще не решенную задачу.
Верификация имитационной модели есть проверка соответствия ее поведения предположениям экспериментатора. Когда модель организована в виде вычислительной программы для компьютера, то сначала исправляют ошибки в ее записи на алгоритмическом языке, а затем переходят к верификации. Это первый этап действительной подготовки к имитационному эксперименту. Подбираются некоторые исходные данные, для которых могут быть предсказаны результаты просчета. Если окажется, что ЭВМ выдает данные, противоречащие тем, которые ожидались при формировании модели, значит, модель неверна, т.е. не соответствует заложенным в нее ожиданиям. В обратном случае переходят к следующему этапу проверки работоспособности модели – ее валидации.
Валидация модели (model validation) – проверка соответствия данных, получаемых в процессе машинной имитации, реальному ходу явлений, для описания которых создана модель. Она производится тогда, когда экспериментатор убедился на предшествующей стадии (верификации) в правильности структуры (логики) модели, и состоит в том, что выходные данные после расчета на компьютере сопоставляются с имеющимися статистическими сведениями о моделируемой системе.
В более общем виде верификация – это подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены. Если образно, то верификация – процедура сопоставления того, что сделано (или еще пока делается), с тем, что было задумано (предписано) сделать, т.е. сопоставление законченного или промежуточного результата с входными требованиями – "взгляд назад".
Валидация – подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены. Образно говоря, валидация – это процедура сопоставления того, что задумано сделать (или еще пока делается), с тем, что необходимо потребителю для конкретного применения, т.е. сопоставление планируемого или промежуточного результата деятельности с текущими выходными требованиями – "взгляд вперед". Дословный перевод с английского: validation – это: 1) ратификация, утверждение, Sync: ratification; 2) легализация, признание законной силы, придание юридической силы.
Верификация является инструментом валидации, ее частью. Верификация продолжается вплоть до момента кодирования программы, а валидация осуществляется непосредственно после. Поэтому в практике моделирования с использованием ЭВМ верификация и валидация моделей завершается после проведения вычислительного эксперимента и подтверждения его результатами соответствия как реальным процессам исследуемого объекта, так соответствия конкретным условиям применимости (или требованиям). Однако в большинстве случаев процессы верификации, валидации, тестирования и реализации пересекаются по времени.
Используются два подхода к валидации программного обеспечения. Первый подход, дедуктивный, представлен такими направлениями исследований, как автоматическое доказательство теорем, использованием мультимножеств и графов, а также разнообразных специализированных алгебр. Программная система описывается в рамках некоего формализма, после чего выполняется строгое математическое доказательство обладания данной системой теми или иными свойствами. Второй подход – модельный; его последователи не стремятся вписать систему в рамки теории, а вместо этого строят модель системы, которую можно рассматривать как машину или автомат. Любое требование к системе проверяется для каждого возможного состояния автомата.
Модельный подход поддерживает не только полную, но и частичную верификацию, которая может быть направлена на проверку только одного небольшого свойства, абстрагировавшись от менее важных деталей системы. Иными словами, для проведения верификации необязательно добиваться формализации всех без исключения требований спецификации. В отличие от тестирования и использования симуляторов, в модельном подходе не существует такого понятия, как вероятность обнаружения ошибки: если ошибка есть, она будет обнаружена за конечное время.
В том случае, когда свойство оказывается нарушенным, в виде контрпримера предоставляется диагностирующая информация.
Процесс проверки моделей не требует ни ручного управления со стороны пользователя, ни высокого уровня профессионализма. Имея модель, можно автоматически проверять на ней необходимые свойства. Процесс проверки интегрируется в стандартный цикл проектирования, позволяя, как показывает практика, уменьшить время создания приложений с учетом проведения рефакторинга программного кода.
Однако у модельного подхода есть и слабые стороны. Верификация осуществляется по модели, а не по реальной системе, поэтому ценность полученного результата напрямую зависит от корректности модели, что требует высокого уровня подготовки персонала, создающего модели программ. Модельный подход не может эффективно применяться без точных алгоритмов принятия решений. Нет гарантий полноты: проверяются только те свойства, которые указаны явно.
Построение моделей и формулировка требований требуют высокого уровня знаний и умения их применять. Результаты могут вводить в заблуждение (верификатор – тоже программа и тоже может ошибаться, модель может содержать ошибку; правда, основные процедуры проверки моделей формально доказаны с помощью пакетов автоматического доказательства теорем). Нет верификаторов, поддерживающих обобщения, например, нельзя проверить систему, если в ней не зафиксировать число сущностей.
Примеры успешного применения модельного подхода можно обнаружить, изучая процесс разработки сложных систем, оперирующих большими объемами данных: СУБД, комплексы потоковой обработки речевой и текстовой информации, системы обеспечения информационной безопасности. Модельный подход к верификации программного обеспечения позволяет при правильном разбиении всего комплекса, проектировании и разработке модулей и атомарных составляющих выявлять логические ошибки еще на этапе проектирования. Так, при разработке программного обеспечения потоковой обработки растровых изображений в рамках модельного подхода была сформирована модель для верификации менеджера заданий для потоковой обработки и обработчиков атомарных заданий, позволившая выявить ошибки в проектировании протоколов взаимодействия модулей комплекса и алгоритме определения обработчика атомарного задания. Данная модель основана на использовании сетей Петри и сопутствующих алгоритмов.
Говоря о функциональности, обычно подразумевают некоторое множество атрибутов, рассчитанных на существование определенного набора функций и их специальных свойств, достигающих поставленных целей:
■ пригодность. Выполняет ли приложение предназначенную ему задачу? Может быть верифицировано путем моделирования правильного сопутствующего окружения (подход, аналогичный тестированию);
■ точность. Насколько точны результаты работы приложения? Трудно реализуется при модельном подходе; логическая верификация в данном случае будет более эффективна;
■ безопасность. Не происходит ли неавторизованной утечки информации? Верифицируется напрямую с формулированием соответствующих запросов. Также существует целый ряд немодельных верификаторов, решающих эту же задачу;
■ соответствие. Соответствует ли реализованная функция данному стандарту? Стандарт используется как спецификация (источник требований), реализация функции моделируется;
■ совместимость. Может ли данное приложение общаться с соответствующими программными продуктами от других производителей? Близким приближением является подразумеваемая совместимость при наличии соответствия стандарту и отсутствии недокументированных возможностей. При необходимости более точной проверки выполняет автоматическое дизассемблирование и эмуляцию заданных участков программного кода, ручную отладку, построение графа передачи управления и данных.
Множество атрибутов надежности характеризует способность программного обеспечения поддерживать определенный уровень предоставляемых услуг при данных условиях и в течение заданного промежутка времени:
■ завершенность. Является ли изначально предоставляемый уровень услуг достаточным? Все ли было реализовано? Это свойство по определению не может быть проверено формальным тестированием: на каждую ожидаемую функцию формулируется требование (или множество требований), которое проверяется на модели;
■ устойчивость к ошибкам. Ведет ли себя программа адекватно в случае предоставления заведомо неверных входных данных? Очень неэффективно и громоздко реализуется в модельном подходе, существуют неплохие методы тестирования, решающие эту проблему;
■ устойчивость к окружению (прочность ). Может ли приложение работать нормально в нестандартном или неустойчивом окружении? Применение модельного подхода в данном случае возможно только при наличии возможности моделирования окружения. Однако корректное моделирование стресс-ситуации – весьма нетривиальная задача;
■ восстанавливаемость. Может ли приложение продолжать работу после сбоя? Как правило, это свойство явно прописывается в программе и нуждается только в проверке. Может быть проверено как модельной верификацией, так и тестированием.
Множество атрибутов по удобству пользования характеризует трудности при использовании программного обеспечения и их субъективную оценку тем или иным множеством пользователей:
■ понятность. Насколько интуитивно ясен пользовательский интерфейс приложения? Не поддается научной формализации. Несмотря на то что менее формальные правила существуют уже давно, модельная верификация невозможна;
■ обучаемость. Приспосабливается ли приложение к специфике пользователя? Используются алгоритмы искусственного интеллекта, которые могут быть верифицированы, соответственно может быть верифицирован и признак;
■ управляемость. Легко ли управлять работой приложения? Эта область, традиционная для бета-тестирования, в последнее время переходит в руки специалистов по пользовательским интерфейсам.
Множество атрибутов производительности выявляет связь уровня предоставляемых приложением услуг с объемом используемых при этом ресурсов:
■ поведение во времени. Адекватен ли временной график использования ресурсов? В данном случае нужно тестировать реальную систему, а не ее модель (например, для нахождения утечки памяти). Абсолютно не подходит для модельной верификации;
■ использование ресурсов. Эффективно ли используются ресурсы? Имеется направленность на реальную систему, и существуют эффективные методы формального тестирования, которые в основном базируются на смеси сетей Петри и специализированных языков описания моделей верификации, при прогонке которых происходит количественная оценка потенциально используемых ресурсов; максимальное значение дает вполне эффективную оценку, пригодную для большинства реализаций;
■ алгоритмизация. Насколько оптимальны использованные алгоритмы? Классический анализ алгоритмов вместе с формальной их верификацией дает быстрые и точные результаты.
Множество атрибутов поддержки связано с усилиями по внесению определенных изменений в работающее приложение:
■ анализируемость. Насколько легко определить части, нуждающиеся в изменении? Не поддается формализации;
■ изменяемость. Какие усилия требуются для внесения изменений? Не поддается формализации, уровень может быть установлен априори;
■ настраиваемостъ. Можно ли достичь желаемого эффекта без изменения самой программы, изменяя только настройки? Задача решается тестированием в реальных условиях;
■ стабильность. Как ведет себя программа при внесении изменений на лету? Эффективно решается модельной верификацией с помощью недетерминированных параллельных процессов;
■ тестируемость. Насколько легко проверяется работа изменившегося контура? Решается параллельно с тестированием или превентивно явным образом и к верификации отношения практически не имеет.
Множество атрибутов переместимости характеризует способность программного обеспечения быть перенесенным из одного окружения в другое:
■ приспособляемость. Может ли приложение изменяться в соответствии с изменениями окружения? Взаимодействующие недетерминированные последовательные процессы дают хороший результат, в том числе и в модельном подходе;
■ устанавливаемость. Может ли приложение устанавливаться на разные платформы или в разные конфигурации? Как правило, явно задается в спецификации и явно реализуется и в проверке не нуждается;
■ согласованность. Какие стандарты были использованы в приложении? Не нуждается в проверке, однако само соответствие стандартам проверять можно и нужно;
■ заменяемость. Может ли приложение быть использовано так же, как его эквивалент от другого производителя? Зависит ли от списка опций соответствующих приложений, которые могли бы быть или должны были быть реализованы?
Это относится к фазе формулирования требований, поэтому в верификации не участвует.
Приведенный общий список свойств, которые могут быть проверены с помощью техник модельной верификации и валидации, краток, насколько это максимально возможно. Свойства, не упомянутые (например, масштабируемость или живучесть), но встречающиеся на практике, могут быть сведены к данному списку. Важно отметить, что верификация и валидация моделей, реализуемых средствами вычислительной техники, может выполняться тестированием программного обеспечения, используемого при моделировании, на уровне системных, архитектурных и функциональных требований к программному обеспечению, в то время как тестирование его кода не заменяет процедур верификации и валидации моделей.
Валидация цифровой модели изделия
Александр Щеляев
Менеджер отдела вычислительной гидродинамики, ООО «ТЕСИС»
Современный технологический цикл производства основан на использовании трехмерного электронно-цифрового представления модели изделия. Описание геометрических обводов изделия является первичной информацией, описывающей объект и требования к качеству его изготовления. Следовательно, геометрические обводы изделия, методика их создания/построения и методика их передачи из одной рабочей среды в другую с сохранением целостности должны являться объектами пристального внимания со стороны контролирующих структур предприятия. Информационные инструменты по работе с CAD-моделью, используемые в промышленности, как и любой другой инструментарий, требуют постоянного контроля результата их применения, а также документирования процесса их использования в соответствии с требованиями системы менеджмента качества предприятия. Подобные требования на западном рынке сформулированы как на уровне международных стандартов серии ISO 9000, так и на уровне требований отдельных корпораций, например Boeing D6-51991. На практике это означает, что любые операции с CAD-моделью изделия должны заканчиваться валидацией CAD-модели с целью обнаружения нарушения целостности описания геометрических обводов изделия как на уровне геометрии и топологии (см. статью «Программный комплекс 3DTransVidia — качественная трансляция цифровой модели изделия» // САПР и графика. 2014. № 6), так и на уровне семантических объектов и атрибутов. Результат валидации должен быть задокументирован и сохранен для последующей работы по усовершенствованию рабочего процесса. Под операциями с CAD-моделью в первую очередь понимают трансляцию модели из одного формата в другой или ее передачу между различными программными продуктами, используемыми в производственной цепочке. Под валидацией понимают проверку качества CAD-модели на всех стадиях ее применения в рамках электронного документооборота внутри производственного цикла. Проверка осуществляется методом сравнения производной CAD-модели после трансляции (импорта) с оригинальной CAD-моделью, принятой в качестве эталона.
Рассмотрим методику проведения валидации CAD-модели на примере схемы взаимодействия корпорации Boeing со своими подрядчиками (смежниками) в рамках международной кооперации по производству пассажирских самолетов. Корпорация Boeing, как головное предприятие, в рамках кооперации отвечает за разработку нового самолета, изготовление наиболее ответственных агрегатов или узлов и окончательную сборку. Изготовление всех остальных деталей, узлов и агрегатов самолета осуществляют смежники корпорации, расположенные по всему миру. Корпорация Boeing при работе в гражданских проектах в качестве среды проектирования и поддержки жизненного цикла самолета использует программные продукты фирмы Dassault Systemes (в том числе CAD-систему CATIA различных версий и поколений). Все попытки навязать смежникам работу в аналогичных продуктах фирмы Dassault Systemes привели бы к росту себестоимости самолетов Boeing, так как смежники начали бы закладывать в себестоимость изделия издержки на покупку и техническое сопровождение недешевого программного обеспечения фирмы Dassault Systemes. Корпорация Boeing позволяет своим смежникам использовать в их работе любые программные продукты, которые им удобны и выгодны как с экономической точки зрения, так и с точки зрения технических возможностей. Однако, чтобы устранить возможные негативные последствия от работы в мультибрендовой CAD/CAM/CAE/CAI-среде, корпорация Boeing ввела в действие корпоративный стандарт D6-51991, который обязаны соблюдать все смежники. Данный стандарт регламентирует взаимодействие головной корпорации с соисполнителями в части контроля качества использования цифровых моделей изделий. Одновременно с этим на рынке появились программные продукты, которые позволяют автоматизировать процесс валидации и, в том числе, поддерживают стандарт D6-51991. Если смежник не может доказать головной корпорации, что он адекватно отслеживает качество цифровой модели изделия, полученной от Boeing, то он не допускается для работы в проектах Boeing. Требования Boeing являются жесткими, но они заставляют всех смежников вырабатывать организационные и технические меры по корректному использованию CAD-моделей для обеспечения гарантированного качества выпускаемой продукции. Стандарт Boeing D6-51991 гласит, что «смежник отвечает за трансляцию данных, используемых при изготовлении (в производстве) и при техническом контроле, и должен иметь ясный процесс документирования обоих этапов. Документированный процесс должен включать методику проверки точности трансляции» (рис. 1).
Одним из таких программных продуктов, который полностью поддерживает требования стандарта Boeing D6-51991, является CompareVidia (рис. 2).
Программа CompareVidia выполняет проверку CAD-модели, полученной в результате трансляции (импорта), сравнивая ее с эталонной CAD-моделью. Программа CompareVidia позволяет выполнять проверку на трех различных уровнях:
Типовая схема рабочего процесса валидации представлена на рис. 3.
Эталонная модель, предварительно прошедшая проверку в корпорации Boeing, предоставляется смежнику в формате CATIA (без дерева построения) и дополнительно — в формате STEP. Смежник, получив модель, открывает ее в своих CAD/CAM/CAE/CAI-приложениях для выполнения соответствующих операций своего технологического цикла и сохраняет в формате STEP. После этого в программу CompareVidia загружается оригинальная CAD-модель и деривативная. Для этого в CompareVidia задаются критерии проверки и их численные параметры.
При использованииГлобальных проверок необходимо задать процентную точность проверки интегральных характеристик (рис. 4).
При использовании Локальных проверок необходимо задать линейную и угловую точность проверки (рис. 5).
При необходимости определить сохранность атрибутов или семантических объектов необходимо задать соответствующие параметры проверки (рис. 6).
Стандартные требования проверки геометрии CAD-модели до недавнего времени включали исключительно проверку геометрических обводов на соответствие заданной точности. Подобная методика долгое время успешно использовалась при подготовке модели к изготовлению, однако не позволяла отслеживать изменения топологии геометрической модели, которые могут происходить из-за отличия в реализации математических функций геометрического ядра той или иной CAD-системы. Например, система CATIA V4 имеет поддержку полиномов более высоких степеней по сравнению с современными CAD-системами. Следует отметить, что нарушение топологии CAD-модели, как правило, не приводит к нарушению описания геометрических обводов в пределах задаваемой точности, не искажает твердотельного описания, поэтому по формальным признаком это не является браком (рис. 7).
Однако при дальнейшем использовании подобной CAD-модели на производстве могут появиться проблемы, связанные со спецификой работы CAM-приложений. Например, значительная часть CAM-приложений строит маршрут движения обрабатывающего инструмента для станков с ЧПУ на основе характеристик поверхностей, из которых состоит CAD-модель обрабатываемой детали. В первую очередь алгоритм нацелен на приоритетное построение траектории движения инструмента вдоль длинных кромок обрабатываемой поверхности. Это позволяет реализовать установившийся режим обработки и достигать максимальной скорости движения инструмента. Границы поверхностей в CAD-модели определяются ее топологией, и если топология трансформировалась, то одна поверхность сегментируется на несколько поверхностей меньшего размера. В CAM-приложениях это приводит к перестроению траекторий движения инструмента и к увеличению количества участков, где инструмент меняет направление своего движения. В месте изменения направления движения меняется регулярность обработки поверхности, приводящая к изменению шероховатости поверхности (рис. 8), что эквивалентно получению брака на производстве.
В подобной ситуации оказался один из подрядчиков Boeing — компания Triumph Interiors, которая отвечает за производство рам для иллюминаторов пассажирского лайнера. Математическая модель рамы от Boeing прошла полную валидацию и удовлетворяла геометрическим требованиям качества. Полный комплект рам для иллюминаторов на весь самолет был изготовлен и отправлен заказчику. Однако вся партия вернулась как забракованная. Анализ показал, что валидация CAD-модели не затрагивала проверку топологии. При этом в процессе чтения CAD-модели в CAM-приложение топология модели трансформировалась, что и привело к изменению в режимах обработки на станке (рис. 9). Таким образом, более полная валидация позволила найти источник проблемы, устранить брак в производстве, а компании Triumph Interiors остаться в проекте Boeing.
Необходимо отметить, что в итоге сама корпорация Boeing пришла к решению ужесточить критерии проверки CAD-модели и в обязательном порядке проверять целостность топологии. Отклонение от этого требования допускается только в исключительных случаях и с оговоркой, что результат не повлияет на качество продукции.
Другой важной возможностью для производства является проверка целостности PMI-объектов — как в векторном представлении, где текстовые символы представлены как набор полилиний, так и в символьном представлении, с редактируемым текстом. Отдельно проверяется целостность семантических связей, то есть связь PMI-объекта с поверхностью CAD-модели (рис. 10).
Современный процесс контроля качества изготовления продукции также опирается на использование CAD-модели. Выполненные средствами стационарных или мобильных координатно-измерительных машин (КИМ) замеры конкретных деталей предоставляют массив контрольных точек, которые в CAI-приложениях (Computer Aided Inspection) накладываются на эталонную CAD-модель, а затем строится карта отклонений между реальным изделием и его математической моделью. При этом необходимо понимать, что CAI-приложение также построено на базе какого-то геометрического ядра, а значит, всегда следует проверять, что импортированная в это приложение CAD-модель не претерпела никаких деформаций.
С точки зрения валидации данных на этапе метрологического контроля значительное удобство работы и скорость ее проведения привносят следующие возможности программы CompareVidia:
В соответствии с требованиями современных стандартов качества процесс валидации CAD-модели должен быть задокументирован для последующего возможного расследования причин появления ошибок в геометрическом или топологическом описании CAD-модели.
В программном комплексе CompareVidia результаты валидации автоматически оформляются в виде отчета с приведением всей статистики сравниваемых моделей, количества ошибок, их типов, расположения ошибок на модели, их численных характеристик и т.д. Глубина представленной в отчете информации может быть настроена пользователем. Отчет может быть сохранен в форматы 2D/3D PDF, HTML или TXT и распечатан для подписания ответственным лицом (рис. 12).
CompareVidia является программным комплексом, который, в том числе, оценивает качество CAD-модели во время валидации. По-этому совершенно логично можно задаться вопросом о методике проверки точности валидации с помощью CompareVidia.
В качестве методики оценки точности работы CompareVidia компанией ASCO, одним из поставщиков Boeing и Airbus, был предложен сравнительный подход, где проверяется эталонная модель, содержащая заведомо внесенные в нее отклонения (изменение линейных парамет-ров элементов построения, изменение углового положения, смещение центров отверстий и пр.). В результате валидации «дефектной» модели с помощью программы CompareVidia были обнаружены все заложенные в модель ошибки с точным определением их численных характеристик (рис. 13).
Программа CompareVidia поддерживает следующие форматы: CATIA V4, CATIA V5, ProE/Creo, UG NX, Inventor, SolidWorks, Solid Edge, JT, STEP, IGES, ACIS, Parasolid, SAT, VDA-FS, VRML, STL, MESH, QIF, 3DXML и Adobe 3D PDF (рис. 14).
Как и все продукты, предлагаемые компанией ТЕСИС в области контроля качества цифровой модели, CompareVidia также допускает выбор точности и единиц измерения при открытии сравниваемых моделей (рис. 15).
Работа со сборкой позволяет выполнять все операции, которые доступны на уровне отдельной детали, а также проверять целостность сборочного документа: наличие или отсутствие отдельных деталей; изменение в конструктивном описании деталей; контроль структуры сборки.
Архитектура программного комплекса CompareVidia базируется на модульном описании и поддержке скриптового языка на базе XML. Это позволяет интегрировать CompareVidia в рабочий цикл документооборота предприятия, где проверку деталей и создание отчетности можно автоматизировать на любом уровне. Существует возможность пакетной обработки массива файлов.
Система лицензирования может выдавать лицензию на работу CompareVidia как в локальном режиме для одного рабочего места, так и в сетевом — как плавающую сетевую лицензию. Лицензирование организовано по типам CAD-форматов на чтение и запись, а также по возможности пакетной трансляции и использованию режима работы Track Engineering Changes (TEC), для локализации мест обнаружения ошибок на модели без количественной оценки ошибки.
Система лицензирования CompareVidia не требует наличия на рабочем месте лицензий соответствующих CAD-систем и работает исключительно в автономном режиме. Пользователю доступны все поддерживаемые разработчиками версии CAD-форматов.
Программный комплекс CompareVidia является одним из флагманских продуктов в линейке геометрических инструментов, предлагаемых компанией ТЕСИС. Система обладает русскоязычным интерфейсом, русскоязычной документацией и технической поддержкой. Компания ТЕСИС предлагает внедрение системы, включая обучение и техническое сопровождение. С информацией о новых версиях программного комплекса CompareVidia можно ознакомиться на сайте компании ТЕСИС
(www.tesis.com.ru
).
Цель работы – изучить методы проверки соответствия разработанной имитационной модели реальной системе.
В ходе выполнения лабораторной работы студент должен научится проводить верификацию имитационной модели путем построения логической блок-схемы и интерактивного контроля за ходом моделирования при помощи встроенной в специализированный язык GPSS/H программы отладки; проверять правильность построения концептуальной модели в компьютере; проводить валидацию имитационной модели путем сопоставления результатов экспериментов с результатами аналитических расчетов.
Примечание
Предполагается, что студент, знаком с теорией систем массового обслуживания и основами моделирования систем на специализированном языке GPSS/H.
2. Теоретические положения
2.1. Верификация и валидация имитационных моделей
Если модель неправильно отображает динамику системы, то, очевидно, что и полученные с ее помощью результаты будут неправильными. Поэтому одной из главных проблем при моделировании является проверка соответствия разработанной модели реальной системе. В России подобную проверку называют адекватностью, а за рубежом — делят на верификацию и валидацию.
Верификация — это проверка правильности построения концептуальной модели в компьютере. Она используется при сравнении концептуальной модели с ее компьютерным представлением и отвечает на вопросы: правильно ли модель выполняется на компьютере? Правильно ли представлены входные параметры и логическая структура модели?
Для верификации используют методы:
1. Проверка корректности результатов на «крайние» значения. При этом:
— задают нулевые значения входных параметров модели и анализируют результаты. Если результаты не нулевые, то проверяют и уточняют модель;
— задают значения входных параметров модели, которых не может быть в реальной системе, и по результатам моделирования оценивают правильность реакции модели;
— проводят длительное моделирование и оценивают результаты. При этом выявляют ошибки и подозрения: загрузка обслуживающих приборов нулевая; число вхождений заявок в прибор не нулевое, а загрузка прибора равна нулю; число входов в очередь равно ее текущему содержимому.
2. Аналитический подсчет характеристик и сравнение их с модельными результатами. За длительный прогон вручную подсчитывают использование прибора и сравнивают расчетное значение с результатами моделирования. Но есть характеристики, которые невозможно посчитать аналитически, например, среднее время обслуживания заявки. Тем не менее, параметры в модели взаимосвязаны и проверка одной характеристики повышает доверие (или не доверие) к другим параметрам и модели в целом, даже если точные связи между характеристиками неизвестны и изменяются от прогона к прогону.
3. Построение логической блок-схемы и интерактивный контроль за ходом моделирования при помощи программ отладки. Составляют простую логическую блок-схему для какого-либо узла модели. Например, для одноканальной СМО можно составить блок схему, изображенную.
Затем, используя встроенные в пакеты имитационного моделирования программы отладки проверяют, соответствует ли логика работы модели построенной блок-схеме. При этом используют:
— прогон до определенного времени или события и вывод информации за данный период времени;
— приостановку моделирования по значению текущей величины переменной выделенного компонента модели (очереди, прибора, счетчика, атрибута).
4. Использование имитационного следа. Имитационный след это детальная распечатка изменений модели в течение времени. Его разрабатывают специально для использования в имитационных программах. Он позволяет просматривать величину выбранных переменных в каждый момент приращения времени (от события к событию). При анализе такого имитационного следа можно выявить ошибки и несоответствия модели реальной системе.
5. Документирование модели и проверка лицом не участвующим в разработке модели. Этим методом часто пренебрегают. Но если разработчик модели пишет краткие комментарии в компьютерной модели, проводит определение всех переменных и параметров и делает пометки главных модулей модели, это значительно облегчает кому-либо и самому разработчику модели проверить ее логику.
6. Проверка по анимации. В последнее время программное обеспечение для имитационного моделирования соединяют с программами компьютерной анимации. Анимация позволяет проследить работу модели, выводя на монитор динамику работы ее элементов в виде графических аналогов реальной системы. При помощи анимации выделяют характерные виды ошибок: несвоевременное движение, исчезновение или наложение объектов, отображающих пакеты данных, машины, людей и т.д.
Валидация — проверка является ли модель, допустимым представлением реальной системы. Цель валидации – двойная, во-первых, создать модель, которая представляет поведение реальной системы как можно более полно. Во вторых, увеличить приемлемый уровень достоверности модели, чтобы модель можно было использовать для анализа системы и принятия решений.
Вообще нет общепринятых количественных оценок валидации моделей. Большинство авторов считают, что если отклонение результатов моделирования от показателей реальной системы или определенных другим методом не превышает 7-10%, то модель считается валидной.
Хотя верификация и валидация концептуально различны, обычно они проводятся одновременно. Некоторые методы даже идентичны (например, проверка модели по анимации, создание имитационного следа).
При выполнении ответственных инженерных расчетов численными методами для обоснования корректности расчетных моделей рекомендуется применять процедуру верификации и валидации модели , разработанную и предложенную ведущими мировыми организациями в области инженерных расчетов - NAFEMS (International Association for the Engineering Modelling, Analysis and Simulation Community) и ASME (American Society of Mechanical Engineers).
Исследователь-расчетчик последовательно создает расчетную схему и два вида моделей – математическую и численную. Математическая модель - математическое представление реального объекта или системы. Численная модель - программный код, реализующий представление объекта или системы в форме, приближенной к алгоритмическому описанию, включающей набор данных, характеризующих свойства системы и динамику их изменения со временем.
Применительно к данным видам моделей для проверки их адекватности используются подход верификации и валидации . Верификация проводится в области математики, а валидация – в области физики.
Как следует из данного определения, процесс верификации позволяет достичь уверенности в корректности численной модели. Процесс верификации модели состоит из двух шагов:
- Верификация программного кода для подтверждения того, что математические модели и алгоритмы численного решения систем уравнений работают корректно;
- Верификация вычислений для подтверждения того, что дискретизация расчетной области выполнена корректно, и дискретное решение с необходимой степенью точности соответствует математической модели.
Проведение верификации программного кода относится к области ответственности разработчика программного обеспечения, который должен использовать современные методики и системы управления качеством, а также проводить тщательное тестирование каждого релиза программного кода.
Пользователи программного обеспечения также должны осозновать, что несут часть ответственности за верификацию программного кода, даже в случаях, когда у них нет доступа к исходному коду. Одним из распространенных способов верификации программного кода является сравнение результатов расчета с аналитическим решением. Подобное сравнение является основным способом пользовательского тестирования. К сожалению, сложность большинства доступных аналитических решений задач физики затрудняет их использование даже для относительно стандартных возможностей большинства современных коммерческих программных продуктов. Сравнение численного и аналитического решений возможно только для простых - модельных и тестовых задач.
Второй составляющей процесса верификации является верификация вычислений – определение точности численного решения для заданной дискретизации расчетной области. Численное и аналитическое решения apriori отличаются, поскольку дискретное решение является лишь аппроксимацией аналитического. Поэтому целью верификации вычислений является установление количественного значения погрешности для заданной дискретной модели.
Погрешности, связанные с дискретизацией, наиболее часто определяются путем сравнения полученного численного решения с другими численными решениями на двух дополнительных дискретных моделях (вычислительных сетках) с уменьшенным размером ячейки (элемента). Целью сравнений решений на различных сетках является определение практической сходимости решения в интересующей исследователя области. Основная ответственность за верификацию вычислений лежит на исследователе – пользователе программного продукта. При том, что разработчик программного кода, несомненно, должен отвечать за корректность разработанных алгоритмов, он не может нести ответственность за то, что созданная пользователем расчетная сетка (дискретная модель) будет достаточно качественной для достижения алгоритмической точности. Таким образом, за ошибки в расчетах вследствие грубой или некорректно созданной расчетной сетки, полностью отвечает пользователь программного продукта. Недостаточные исследования чувствительности численного решения к размеру элемента расчетной сетки являются наиболее часто встречающимся упущением исследователей при проведении расчетов численными методами, при том, что данная техника верификации достаточно проста для реализации.
Ни один из этапов верификации не позволяет определить, насколько выбранные модели адекватны объекту исследования. Оценка соответствия численной модели реальному миру относится к задачам валидации, которая позволяет определить, насколько физические явления и законы, включенные исследователем в расчетную модель, соответствуют постановке исходной задачи и достаточны для получения требуемых решений.
Способ взаимодействия физической и математической дисциплин в процессе верификации и валидации схематически представлен на рисунке.
После выбора расчетной схемы процесс верификации и валидации расходится на две ветви. Левая ветвь относится к области математического моделирования, а правая – к области физического эксперимента. В конечном итоге лишь физические наблюдения могут подтвердить или опровергнуть адекватность выбранной расчетной схемы и математической модели для представления объекта исследования. Тесное взаимодействие инженеров-расчетчиков и экспериментаторов требуется на всех стадиях процедуры верификации и валидации, т.к. математическая и физическая модели обязательно будут отличаться. Как простой пример, рассмотрим задачу нагружения балки, заделанной на одном конце. С точки зрения математика граничное условие заделки является тривиальным, но в физической лаборатории не существует оборудования, обеспечивающего такое явление как полная заделка, вследствие конечной жесткости оборудования и трехмерного характера физической модели, в отличие от математической модели балки. Таким образом, некоторые элементы расчетной схемы достаточно просто включить как в математическую, так и в физическую модель, а иные – гораздо сложнее. Для понимания природы этих расхождений и их возможного устранения должны проводиться предварительные расчеты, что отражено на схеме.
Также крайне важно, чтобы результаты эксперимента не были бы известны расчетчикам заранее, до получения численного решения. Основная причина этого – убедиться в "предсказательных возможностях" численной модели. Если результаты эксперимента известны расчетчику заранее, что естественным будет желание «настроить» модель на конкретный результат. Это снижает уровень доверия к численной модели.
Дополнительно важно отметить, что в моделировании и эксперименте важна роль неопределенности и, как следствие - повторяемости реузльтатов. Ожидается, что при проведении одного и того же эксперимента результаты должны в определенной степени коррелировать между собой. Степень корреляции необходимо измерять. Точно также любая численная модель содержит ряд параметров (например, свойства материалов), которые являются в реальном мире не детерминистическими, а стохастическими величинами. Соответственно, при проведении численного моделирования необходимо проводить оценку чувствительности решения к неопределенности исходных данных.
При подготовке статьи использованы материалы сайта www.nafems.org
