Обсуждение

На плохих примерах можно доказать всё, что угодно. Я б must выбрасывал также как и возвратные конструкции, строя всё по схеме Источник - действие - дополнительные условия. В такой постановке напортачить очень сложно. Аттрибутная же запись нужна для чёткого определения местоположения термина в пространстве объектов. "Кошка" по уровню неопределённости сильно отличается от "Кошка в серую и чёрную полоску. Ухо белое. Любит мороженную селёдку и рыбий жир" Последнее не понял. Это аналог прохождения по техпроцессу на конвейере различных типов изделий?

Основной пафос презентации Ross -- запись формального текста на псевдоестественном (controlled English) языке. Утверждается, что простые люди этот язык понимают и могут верифицировать написанное, а айтишники смогут много более просто привести к нечитаемым людьми, но легко исполняемым формам. Уже есть несколько десятков фирм, которые используют такой подход в своем софте. То, что очень сложно напортачить на C# или Haskell -- это очевидно. Но простые люди отвергают языки, на которых очень сложно напортачить. Поэтому простые люди не смогут верифицировать, правильно ли их простые мысли отражают программисты. И ровно поэтому в конечном итоге получается ерунда: портачат не в записи на языке, а в несоответствии "надежной записи" общепринятой картине мира. Дискуссию про атрибутную запись и безатрибутную запись я знаю. Более того, атрибутная запись давно и надежно выигрывает у всех программистов. Что не мешает четко определять местоположение термина в пространстве фактов у записей безатрибутных. Не в пространстве объектов, а в пространстве фактов (ибо там не столько объектами, сколько ролями оперируют). Заметка про форму жизненного цикла относится к жизненному циклу чего угодно (любых рукотворных объектов) -- включая прохождение по техпроцессу на конвейере различных типов изделий (с возможным прохождением не по конвейеру, а также захватом всех предыдущих конвейеру стадий и всех последующих, от задумки до списывания в утиль). К программному обеспечению и людям это тоже относится.

Верификация в неопределённых терминах не дорого стоит. Уточнение же терминов - процесс не менее трудоёмкий, чем поиск атрибутов. То, что программисты не умеют выражать свои мысли - известно. Английский тоже много кто может, но вот приличную прозу написать - единицы. Диаграммы техпроцессов на конвейерах существуют. Их технологи используют. Только писать "программист А думает десять минут, а потом передаёт результаты программисту Б" несколько безнадёжно.

Уточнение терминов в фактографической записи и поиск атрибутов -- это синонимы. Чудес не бывает, трудоемкость одна. Разница в результате: простые люди не смогут валидизировать запись с атрибутами (просто не смогут прочесть), а прочесть controlled Dutch, например, смогут. Писать эти "организационные нормы" не менее тяжело, чем любой другой программистский текст. Разница только в возможности какого-нибудь стороннего эксперта прочесть и заметить, что написана ахинея. В атрибутных записях шанса на это прочтение нет. Насчет диаграмм техпроцессов на конвейерах: форма жизненного цикла, конечно, может быть задана диаграммой (а если не может быть, то и говорить не о чем. Буквы -- это ведь те же диаграммы ;). Но тут речь про другое, давно различили практики и процессы. Форма жизненного цикла -- раскладка последовательности самого верхнего уровня. А в вашем примере и роли уже назначены исполнителям, и самые детальные операции приведены и жизненным циклом не пахнет (разве что жизненным циклом полупереваренной мелкой мысли). Когда говорят про agile, итерации и прочая -- это определяют форму жизненного цикла. Когда говорят "сначала дизайн, и ну их напрочь, этих аджильщиков, без дизайна и архитектуры дальше не двинемся" -- это тоже определение формы жизненного цикла.

В этом свете имеет смысл рассмотреть немецкий. В чиновьичем немецком простые слова могут стоят в такой комбинации, что понять текст сможет только высокообразованный немец, причём излечёт из него три различных смысла. Я видел исходный код, в котором надо было долго и упорно копаться, и видел такой, который читался с листа. Насчёт замечания ахинеи - сторонние эксперты обычно думают над нечётким текстом совсем не то, что программисты. В результате получаются дыры во всех путях кроме главного. А в вашем примере и роли уже назначены исполнителям, и самые детальные операции приведены и жизненным циклом не пахнет Стоп-стоп-стоп. Если происходит отход от норм качества, звучит громкий сигнал, весь процесс останавливается и все обсуждают причины и способы предупреждения. После чего процесс перестраивается, инструкции дополняются и всё (через пять минут, день, месяц) запускается дальше. Программирование - процентов на 90 конвейер. А чек-листы и инструкции используют единицы. Вот и существуют "дикие потенциалы улучшения" на любой вкус.

Про немецкий есть свеженький (апрель) вариант методики: http://www.rulespeak.com/de/. RuleSpeak является одним из трех формальных методов представления формата SBVR (http://www.omg.org/spec/SBVR/1.0/). Насчет ваших примеров про программистов, так вы обсуждаете какой-то непонятный мне уровень абстракции метода разработки на непонятном мне уровне детальности. Я же в постинге привел пример из стандарта, маленький кусочек, и в текстах стандарта четко определена область использования и все другие термины. Я не понимаю, как вы по крохотному кусочку текста из 150 примерно страниц делаете выводы про то, что там еще может быть написано...

RuleSpeak - это не формализация, а рекомендации. По моему опыту, полезны только те вещи, которые можно проверить тулами. Желательно, выведя красивые диаграммки. вы обсуждаете какой-то непонятный мне уровень абстракции метода разработки на непонятном мне уровне детальности. Может быть. Полное описание получится объёмным. Да и некогда этим заниматься. И комментирую я не стандарт, а текст в контексте постинга.

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

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

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

Про логический забыли, помню только я, да мой знакомый, который 20 лет не программирует :).

сорри за вторжение, крайне интересный у вас и презентации у меня вопрос 15288/2008 уже переведен? он доступен где-то?

Да, переведен. Насчет доступности -- это вопрос сложный, ибо там ведь копирайтами со всех сторон обложено, и в открытом доступе его нет. Но члены русского отделения INCOSE его как-то получают ;) Вступайте (http://www.incose.org) и присылайте мне member number по почте -- и посмотрим, что можно сделать :)