Здесь краткое резюме моего опыта в замечательном мире "Автоформализации знания". К сожалению, нет ни книги ни статей, опубликованных на английском.
Алексей
(Наш соотечественник, но, к сожалению, ничего, кроме имени - С.К.)
1.1 Проблемная область
Другими словами, очень трудно заниматься картостроением за пределами непосредственно технической области.
Итак, проблема в том, как расколоть трудное, не поддающееся построению карты приложение ?
1.2. Процесс автоформализации знания
Общая идея в том, что единственный способ ее решить - создать среду, где продвинутый пользователь может выразить себя через программирование. Черт сидит в деталях (There devil is in the details).
1.2.1 Пользователь-пилот (Pilot User)
Обычно можно найти "пользователя-пилота": пользователя с продвинутым знанием в предметной области, который также имеет некоторый опыт программирования (например, в пределах институтского курса) или способный усвоить азы программирования.
1.2.2 Инженер поддержки (Support Engineer)
Инженер поддержки создает и поддерживает среду для пользователя-пилота. Очевидно, что мы не можем ожидать многого от пользователя-пилота, кроме способности организовывать готовые вызовы функций в программу. Ключевой элемент в том, что он не обязан делать ничего за пределами этой очень ограниченной области. Всю трудную работу делает инженер поддержки.
1.2.3 Процесс
Инженер поддержки оценивает начальные потребности пользователя-пилота (например, интерфейс к аппаратуре, с которой придется начинать, какие функции ему придется вызывать и т.д.).
Например, в моем собственном опыте, я начал с простой программы с меню, позволяющей пользователю-пилоту выполнять элементарные функции управления оборудованием посредством набора меню, а пользователь-пилот модифицировал ее шаг за шагом до полнофункционального прототипа.
(*)
Пользователь-пилот начал играть с этими вещами. Каждый раз, когда он сталкивался с программной/аппаратной проблемой, то решать ее было ответственностью инженера поддержки: добавлять новые компоненты, улучшать производительность, обсуждать результаты и т.д. После этого шел следующий цикл работы пользователя-пилота и т.д.
Другими словами, пользователь-пилот разбивает проблему на части. Некоторые из них он решает самостоятельно, некоторые передаются инженеру поддержки. Ключевой момент в том, что инженер поддержки не обязан понимать всю проблему, а пользователь-пилот не обязан хорошо программировать.
В конце получится (грубый и медленный, но работающий) прототип разрабатываемой вещи, который можно использовать как основу для формальной спецификации, и затем команда паковщиков с ней разберется.
По моему личному опыту результаты были на удивление хороши. У меня был очень красноречивый эксперимент в этой области. Были ребята, которые разрабатывали новый измеритель вязкости стекла (вискозиметр) и им нужно было управлять им посредством компьютера (это было ооооооочень давно, во времена, когда некоторые химики были не в ладах с компьютерами, не то что сейчас). Проблема была не такой уж и тривиальной, поскольку стекло - очень странная жидкость с сильной зависимостью от температуры и большими разбросами от образца к образцу (кроме того, все процессы мучительно медленные, поэтому требуется полчаса, чтобы температура равномерно распределилась по образцу, чтобы перемещение стало линейным во времени и т.п.).
Я нашел пользователя-пилота, который много программировал на FORTRANе, делая научные расчеты, однако он никогда не занимался управлением с помощью компьютеров. Как я говорил (*) я собрал и откалибровал все элементы аппаратуры и написал подпрограммы, выполняющие операции уровня пользователя: изменение мощности нагревателя, измерение температуры, загрузка (образцов ?), измерение серии перемещений. И я поместил их в простую управляемую через меню программу. Меня несколько раз вызывали помочь ему улучшить ту или другую часть контрольно-измерительной системы и все - он делал остальное сам, работая несколько часов в день месяц. Он получил прибор, который работал при любом человеческом вмешательстве в геометрию образца и был достаточно приспособлен, чтобы справляться с широким диапазоном температур/вязкостей.
В то же самое время, я не знал и до сих пор не знаю ничего о вязкости стекла, кроме самого элементарного понимания. Он не знал и до сих пор не знает ничего об управлении с помощью компьютера. А мы вместе были способны делать вещи с действительно минимальными усилиями с обеих сторон.
Здесь идет интересная часть. Через некоторое время после того, как я начал работать над проектом, они в течение нескольких месяцев разрабатывали спецификации для других парней. После завершения нашего проекта я попросил его сравнить его с последней спецификацией, которую он написал имея реальную программу, которую он разработал. Он нашел 13 отличий:
Он решил, что может прожить без некоторых вещей, которые не дают большого эффекта. Это засчиталось за 2 отличия.
Шесть следующих были на самом деле тривиальны в решении, и он был уверен, что в нормальном процессе спецификация-тестирование-спецификация-тестирование эти моменты были бы решены легко.
Два были менее тривиальными, однако, эти пункты еще можно было решить в процессе спецификация-тестирование-спецификация-тестирование-спецификация-тестирование.
Два были нетривиальными, его ощущение было, что он не смог бы получить их достаточно быстро не играя с вещами сам.
Этот проект был маленьким, однако, с моей точки зрения это красноречивый пример.
Unix - это система, созданная разработчиками программного обеспечения для разработчиков программного обеспечения, и поэтому она так удобна как среда разработки.