Есть какие-нибудь математические подходы к управлению состоянием сложных объектов?

Question

Обычно я использую ASP.net веб-формы для графического интерфейса пользователя, возможно, одну из самых "отслеживающих состояние" технологий.Но это применимо к любой технологии, у которой есть состояния.Иногда формы бывают сложными, с >30 элементами и > 3 состояниями каждого элемента.Интуитивно понятный способ создания такой формы обычно работает на 90%.Остальные 10% обычно находят тестировщиков или конечных пользователей:).

Проблема, на мой взгляд, в том, что мы должны представить множество сценариев для одного и того же объекта, что намного сложнее, чем следствие независимых операций.

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

Используете ли вы какие-либо математические формализмы и подходы к управлению состоянием сложных объектов?Не такие, как монады в Haskell, но которые можно использовать в более традиционных бизнес-приложениях и языках - Java, C #, C ++.

Возможно, это не полный формализм по Тьюрингу, но 99% тоже будет здорово:).

Извините, если это просто еще один вопрос перекати-поля:)

Answer 1

Используйте передачу сообщений как абстракцию.Преимущества:

1. Трудность со сложным состоянием заключается в сложных взаимодействиях, которые особенно сложны в параллельных системах, таких как типичные графические интерфейсы.Передача сообщений, устраняя общее состояние, предотвращает заражение сложностью состояния в одном процессе.
2. Параллелизм передачи сообщений имеет хорошие основополагающие модели:например, модель актера, CSP, обе из которых повлияли на Erlang.
3. Он хорошо интегрируется с функциональным программированием:посмотри на Эрланг еще раз. Книга Питера ван Роя * Концепции, методы и модели компьютерного программирования это превосходный текст, который показывает фундаментальные компоненты языков программирования, такие как чистые функции и передача сообщений, и как их можно комбинировать.Текст доступен в виде бесплатного PDF-файла.

Answer 2

Возможно, это не полный формализм по Тьюрингу, но 99% тоже будет здорово:).

Извините, но я бы предпочел предоставить NP-полное решение :)

Быстрый ответ от меня был бы следующим Подход, основанный на тестировании.Но читайте дальше, чтобы узнать больше.

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

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

В результате такого процесса вы должны получить ряд простых функций (задач), в основном независимых друг от друга.Это очень важно, потому что тогда вы сможете МОДУЛЬНЫЙ ТЕСТ эти простые сценарии.Кроме того, следовать этому гораздо проще и лучше первый подход к тестированию что позволяет увидеть декомпозицию в самом начале процесса разработки.

Используете ли вы какие-либо математические формализмы и подходы к управлению состоянием сложных объектов?

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

---

Чтобы дать тебе абстрактный пример:

У вас есть сложный сценарий A.Вам всегда нужно писать по крайней мере, 3 теста для каждого сценария:правильный ввод, неправильный ввод и угловой регистр (ы).

Начинаю писать первый тест (правильный ввод) Я понимаю, что тест становится слишком сложным.

В результате я сценарий декомпозиции A в менее сложный A1, A2, A3.Затем я снова начинаю писать тесты для каждого из них (в итоге у меня должно получиться как минимум 3 * 3 = 9 тестов).

Я понимаю , что A1 все еще слишком сложно чтобы проверить, так что я разложите его снова в A1-1, A1-2.Теперь у меня есть 4 разных сценария (A1-2, A1-2, A2, A3) и 3 * 4 = 12 потенциальных тестов.Я продолжаю писать тесты.

После того, как я закончу.Я начать внедрение, так что все мои тесты пройдены.После этого у вас есть 12 доказательств этого сценария A (точнее, его части) работает правильно.Кроме того, вы могли бы написать еще 3 теста для сценария A который объединяет все его разложенные части - этот вид тестирования является часто (но не всегда!) можно рассматривать как Интеграционное тестирование.

Тогда давайте предположим, что в сценарии обнаружена ошибка A.Вы не уверены, к какой части это относится, но вы подозреваете, что это связано с A1-2 или A3.Итак , вы напишите еще 2 теста для каждого из сценариев, чтобы воспроизвести ошибку (напишите такой тест, который не оправдает ваших ожиданий).После того, как вы воспроизвели ошибку, вы исправляете ее и делаете ТАК, чтобы ВСЕ тесты прошли успешно.

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

Есть 2 основные проблемы с этим подходом, IMO.

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

---

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

Так что на самом деле я здесь говорю не о состоянии, а скорее о поведении и доказательстве того, что оно работает правильно.

Исходя из личного опыта, я должен упомянуть, что ASP.NET WebForm технически ОЧЕНЬ сложно протестировать.Чтобы преодолеть это, я бы предложил применить шаблон MVP для ASP.NET Веб-форм.

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