Каков Ваш опыт с проверкой модели программного обеспечения? [закрытый]
Существует 3 способа управления памятью: -
GC работает только для управляемых ресурсов, поэтому .NET предоставляет Dispose и Finalize для выпуска неуправляемых ресурсов, таких как поток, подключение к базе данных, COM-объекты и т. д. ..
1) Dispose
Dispose следует вызывать явно для типов, которые реализуют IDisposable.
Программист должен вызывать это либо с помощью Dispose (), либо с помощью функции Create
Используйте GC.SuppressFinalize (this), чтобы предотвратить вызов Finalizer, если вы уже использовали dispose ()
2) Finalize или Distructor
Он называется неявным после того, как объект имеет право на очистку, финализатор для объектов вызывается последовательно по потоку финализатора.
Недостатком реализации финализатора является то, что его восстановление памяти задерживается, поскольку финализатор для такого класса / типов должен быть вызван предварительной очисткой,
3) GC.Collect ()
Использование GC.Collect () не обязательно устанавливает GC для сбора, GC все еще может переопределять и запускать, когда захочет.
также GC.Collect () будет запускать трассировочную часть сбора мусора и добавлять элементы в очередь финализатора, но не вызывать финализаторы для типов, которые обрабатываются другим потоком .
Используйте WaitForPendingFinalizers, если вы хотите убедиться, что все финализаторы были вызваны после вызова GC.Collect ()
4 ответа
Я только что закончил класс на образцовой проверке и крупных инструментах, которые мы использовали, было Вращение и SMV. Мы закончили тем, что использовали их для проверки свойств на общих проблемах синхронизации, и я нашел SMV просто немного легче использовать.
Хотя эти инструменты были забавой использовать, я думаю, что они действительно сияют, когда Вы комбинируете их с чем-то, что динамично осуществляет ограничения на Вашу программу (так, чтобы было немного легче проверить 'полезные' вещи о Вашей программе). Мы закончили тем, что брали платформу Spring WebFlow, которая использует XML для записи конечного автомата как файл, который указывает, какие веб-страницы могут перейти к который другие, и использующий SMV, чтобы смочь выполнить проверку на упомянутых приложениях (бесстыдный разъем здесь).
Для ответа на последний вопрос я думаю, что образцовая проверка определенно полезна, чтобы иметь, но я больше склоняюсь к использованию поблочного тестирования как техника, которая заставляет меня чувствовать себя комфортно в отношении поставки моего конечного продукта.
Я провел некоторое исследование на том предмете в течение моего времени в университете, развернув состояние, Исследовав Средство проверки Модели блока.
Мы использовали виртуальную машину для обхода каждого возможного пути/состояния программы, с помощью* и некоторая эвристика, в зависимости от вида ошибки (мертвая блокировка, ошибки ввода-вывода...)
Это было вдохновлено Первооткрывателем Java, и это работало с кодом C++. (Все GCC могло скомпилировать),
Но в наших событиях этот вид технологии не будет скоро использоваться в бизнес-приложениях, из-за связанных с GUI проблем, работа, необходимая для создания начальной тестовой среды и огромных требований к аппаратным средствам. (Вам нужно много RAM и дискового пространства из-за гигантского пространства состояний),
Я использовал ВРАЩЕНИЕ для нахождения проблемы параллелизма в программном обеспечении PLC. Это нашло неподозреваемое состояние состязания, которое будет очень жестко найти контролем или тестированием.
Между прочим, есть ли "ВРАЩЕНИЕ для Макетов" книга? Я должен был изучить это из "книги" Средства проверки Модели ВРАЩЕНИЯ и различных учебных руководств онлайн.
Мы использовали несколько средств проверки моделей в обучении, проектировании систем и разработке систем. В наш набор инструментов входят SPIN, UPPAL, Java Pathfinder, PVS и Bogor. У каждого есть свои сильные и слабые стороны. Все находят проблемы с моделями, которые людям просто невозможно обнаружить. Их удобство использования варьируется, хотя большинство из них автоматизируются кнопками.
Когда использовать программу проверки моделей? Я бы сказал, что каждый раз, когда вы описываете модель, которая должна иметь (или не иметь) определенные свойства, и она больше, чем несколько концепций. Любой, кто думает, что может описать и понять что-то большее или более сложное, обманывает себя.