суббота, 24 августа 2013 г.

Эрик Эванс о бреши в базе знаний

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


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

четверг, 22 августа 2013 г.

Эрик Эванс об отличии ddd подхода от устаревшего "каскадного"

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

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

Эрик Эванс о составляющих успеха эффективного моделирования

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

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

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

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

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

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

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

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

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

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


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

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

понедельник, 19 августа 2013 г.

Эрик Эванс о трех фундаментальных способах использования модели при разработке

 Выбор модели в предметно-ориентированном проектировании определяется тремя фундаментальными способами ее использования при разработке программы. 

1. Модель и арxuтектура программы взаимно определяют друг друга. Именно тесная связь между моделью и ее программной реализацией определяет важность и нужность самой модели, а также гарантирует, что проделанный при ее разработке анализ отражен в конечном результате, Т.е. в работающей программе. Связь между моделью и реализацией помогает также в процесс е дальнейшей доработки программы и выпуска ее новых версий, поскольку и сам программный код можно интерпретировать, основываясь на понимании модели. 

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

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


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

Эрик Эванс о модели предметной области

Модель предметной области - это не некая нарисованная схема, а идея, которую схема должна отражать. Это не просто знания специалиста по данному предмету; это строго организованная выборка из такого знания. Схема может наглядно изображать модель, передавать информацию о ней, но того же самого можно добиться и при помощи программного кода или предложения на "человеческом языке". Моделирование предметной области не нацелено на создание максимально "реалистичной" модели. Даже в мире осязаемых, реальных вещей наша модель будет всего лишь искусственным творением. Но моделирование не состоит и в том, чтобы просто сконструировать программный механизм, который бы давал нужный результат. Процесс моделирования чем-то близок к съемке фильма - это тоже примерное изображение реальности , служащее конкретной цели. Даже в документальном фильме не показывают реальную жизнь совсем без прикрас. Как кинематографист выбирает отдельные аспекты реальной жизни и показывает их в своеобразном виде для раскрытия сюжета или передачи послания фильма, так и специалист, моделирующий предметную область, выбирает модель сообразно с ее применимостью .


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

Linux: генерация рандомной строки для пароля

 cat /dev/urandom | tr -dc '[:alnum:]' | fold -w ${1:-20} | head -n 1