Формальные методы и предприятия

Итак...

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

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

Да, я перешел от "обвинить их" в "вините нас", -)

Итак, мой вопрос: используете ли вы какие-либо формальные методы в своей компании? Вы их представили или были предварительными условиями? Какие методы вы используете, чтобы очистить туман от математики от страха людей и побудить их использовать формальные методы? Как вы думаете, отсутствуют ли текущие инструменты для более общего использования?

Ответ 1

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

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

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

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

Ответ 2

Спасибо за все материалы. Они очень проницательны. Позвольте мне немного плакать (не считайте это личным, хотя: -)

Большинство людей, похоже, думают, что формальные методы - это просто проверка программы. Или критические системы. Это может быть правдой, если мы преследуем конечное клише: доказать, что мы делаем программу правильно (v.s. validation, которая спрашивает, как сказал вкладчик, если мы делаем правильную программу).

Но рассмотрите инструменты поиска/проверки модели, такие как сплав. Обучение использованию такого инструмента требует небрежного количества времени для тех, кто используется для UML и OO. Тем не менее, это может дать вам мгновенное представление о вашей модели. Обычно требуется не более 10 минут, чтобы найти встречный пример на достаточно небольшом подмножестве модели, которую вы пытаетесь использовать (и это включает в себя описание модели в сплаве в первую очередь).

В качестве примера возьмем технику требований. Обычно вы получаете много UML. Тем не менее, мало кто использует OCL, и многие бизнес-правила неофициально аннотируются на естественном языке. Зачем? Ограничения по времени?

Теперь рассмотрим тот факт, что большинство просто использует свое чувство кишки, чтобы доказать, что модель является выполнимой. Опять же, почему? Я могу взять такое же количество времени (возможно, даже меньше, так как мне не нужно заботиться о рисовании эстетики), чтобы написать эту модель в Alloy и просто проверить на выполнимость? И какая математика мне теперь нужна? "Предикаты"? Причудливое имя для IFs и booleans;-) Quantifier? Необычные имена для ForEachs()...

Как насчет больших информационных систем? Они не должны быть критическими... Просто попробуйте проанализировать в своей голове концептуальную (а не реализацию!) Диаграмму с более чем 600 классами. Я вижу, что многие люди ударяют головой в стену с легкомысленными ошибками модели, потому что они пропустили какое-то ограничение, или модель позволяет глупым вещам.

Дело в том, что не нужно использовать формальные подходы от головы до хвоста. Конечно, я мог бы доказать целое приложение в Coq и подтвердить, что он на 100% совместим с некоторыми спецификациями. Это может быть подход Computer Scientist/Mathematician.

И все же, с философией GTD, почему я не могу делегировать некоторые задачи для компьютера и позволить ему помочь улучшить мою разработку? Действительно ли это вопрос "времени" или простое, простое отсутствие технических возможностей и желание учиться/заниматься?

Ответ 3

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

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

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

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

Ответ 4

Я читаю курс "Спецификация и проверка". В рамках структуры курса мы делаем следующее: 1. Инструменты обучения, такие как PVS (система проверки прототипов) http://pvs.csl.sri.com/ и SMV (программное моделирование и проверка) http://www.cs.cmu.edu/~modelcheck/smv.html 2. Кроме того, мы делаем диссеминирование аварий, которые произошли из-за сбоев программного обеспечения. Напр. - Неспособность Ariane V

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

Ответ 5

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

Забавно, что одни и те же люди более чем счастливы создавать совершенно бесполезные диаграммы UML в гигантских количествах.

Я думаю, что для этого есть две основные причины:

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

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

Ответ 6

Формальные методы не имеют смысла в системах, где стоимость отказа низкая.

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