Рубрика: эванс

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

1. Слишком много уже имеющегося кода придется одновременно заменять на новый.
2. Большие проекты могут затормозиться из-за того, что дополнительная нагрузка по управлению ими превзойдет имеющиеся возможности.
3. Приложениям со специализированными требованиями могут быть навязаны такие модели, которые не полностью cooтветствуют их задачам, поэтому реализацию важных операций придется выносить куда-то в другое место.
4. И напротив, попытка удовлетворить всех одной моделью добавит в нее столько вариантов и параметров, что ею станет трудно пользоваться.

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

Эрик Эванс «Предметно-ориентированное проектирование»

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

В старой «каскадной методике» (waterfall тethod) специалисты по предметной области выдавали информацию аналитикам; те ее поглощали и абстрагировали, а затем передавали результат программистам, которые и писали программы. Этот подход неудачен, поскольку совершенно лишен обратной связи. Создание модели целиком возложено на аналитиков, а исходными данными им служит только информация от специалистов. Аналитики не имеют возможности научиться чему-либо у программистов или проанализировать результаты работы черновых версий программы. Знания протекают в одном направлении, но не накапливаются.

 1 . Установили связь между моделью и ее реализацией. 

Уже в самом грубом прототипе присутствовала существенная связь с действительностью, и после всех последующих доработок эта связь сохранилась. 

2. Ввели в обиход язык, основанный на модели. 

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

3. Разработали информоемкую модель. 

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

4. Занимались дucстилляцией модели. 

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

5. Экспериментировали и nроводили мозговые штурмы. 

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

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

Эрик Эванс «Предметно-ориентированное проектирование»