26 декабря 2010 · Комментарий

Без заголовка

Всё много хуже :-) Что должно быть первичным: "документ требований" или "модель с требованиями"? Есть практика "поднятия 2D бумажных документов в 3D цифру". Хочется сделать такую же технологию для поднятия бумажных старинных требований в модельную цифру -- чтобы дальше развивать и использовать эти требования уже в цифре. Все эти "трассировки" нужны при этом главным образом на стадии отладки точности подъема. Аннтирование для меня -- это есть технология "подъема в цифру": берем кусок текста, и в аннотации пишем для него фрагмент модели. Но в случае 2D-->3D процесс по факту формален. В случае требований входная "бумага" неполна, бесструктурна, не соответствует никакой метамодели -- а выходная "цифра" тоже не имеет метамодели. С другой стороны, более-менее понятно, какие артефакты идут дальше по этой цепочке: архитектурные описания, которые тоже обычно пропущены (ибо сразу идут рабочие развернутые артефакты -- чертежи и расчеты, а вся "архитектура" растворена в протоколах совещаний, по которым принимались те или иные архитектурные решения). Теперь считаем обратную цепочку: все процессы приёмки сдачи, документооборота (не оборота данных!) настроены на тексты -- и если удастся сделать "приличные цифровые требования" (то есть собрать все аннотации в объединенную из них модель, убрать неизбежные противоречия, добавить недостающее и т.д.), то нужно предусмотреть какую-то их выгрузку в бумажной форме, что не сводится к аннотированию и представляет ровно обратную задачу генерации текста из аннотаций (а не генерации аннотаций по тексту). В программировании иногда рассматривается вопрос о парсерах-генераторах, которые работают в двух направлениях. Вот такой бы парсер-генератор сделать бы для требований: тексты с одной стороны, модели с другой, и возможность редактирования в любой из этих форм с автоматическим отображением изменений в другой форме. Аннотатор -- это "ручной парсер" для этой целевой архитектуры, не более того.

К записи · К обсуждению