![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalen1. Мне подумалось: Не миф ли CMM Level.
Ведь кадры-то решают всё.Потому что, как говорит один мой товарищ, если дать обезьяне автомат Калашникова, самое умное, что она сможет с ним делать — это колоть им орехи.
Каким бы хорошим не был процесс, работники должны понимать его цели и принципы, и подгонять процесс под нужды проекта.
А если даже не дать таким людям формальный процесс, то они всё равно составят документацию, которую требует проект.
С другой стороны, у Сергея был такой опыт: людям неудобно было вводить требования в систему [много-денег-RT], они попросили чего-то другого. Им разрешили вводить их в виде Word-овских документов, и тут-то всё и встало: они не знали, в какой форме, по какому шаблону вводить требования.
Вывод из этой истории сделали такой, что даже самым грамотным работникам нужно давать процедуру. И грамотные аналитики (те, которые ставят требования), не растут на деревьях, их нужно учить.
А начинать обучение хорошо именно с процедуры.
В технологии SSADM — той, которую я знаю лучше всего, — для каждой методики есть список документов, которые она создаёт, и для каждого документа подробно описаны:
- а) формат и содержание;
- б) критерии и методы проверки качества, как-то:
- чеклисты с проверочными вопросами;
- методы формальной проверки полноты и непротиворечивости. Например, специальная матрица проверяет, для каждого ли объекта БД есть задача, которая делает ему C,R,U,D.
2. "Domain-driven design" by Eric Evans
Я немного покритиковал Эванса, как оказалдось - потому что недочитал до второй половины.Показалось, что много воды, что одна и та же мысль повторяется на разные лады. Не, мысль очень правильная:
- выделяйте модель предметной области (domain model);
- ведите общий словарь в терминах домена;
- говорите на языке этого словаря друг с другом и заказчиками, пишите код на нём; (два замечания: для заказчика эти слова всё равно будут значить не то, что для вас. Для него пациент - это человек, у которого взяли анализ, плюс личная карточка. А для нас - запись в БД и кусок памяти, определённым образом заполненный байтами).
- создавайте business layer в виде модели домена, и изолируйте его от прочих слоёв.
Но мне объяснили, что дальше идёт несколько очень интересных глав.
Сергей получил от этой книги индульгенцию на классы с именем "*Service". До тех пор он подозревал, что это слово не означает ничего, примерно как "Common", "General", "Object", "Data" или вот более дискуссоинный пример - "Manager". ("Manager" - это м.б. паттерн "utility class"). Ну а теперь мы знаем, что "сервис" бывает не только внутрисистемный, тот, что в словосочетании "Service layer", но и как понятие слоя бизнес-логики ("utility class").
Диме Бочоришвили книга ответила на некие ещё несформулированные вопросы и этим очень понравилась.
Далее о модели предметной области и паттернах, характерных только для модели домена, но не для реализации.
Эванс выделяет такие полезые паттерны для моделей анализа:
- Entity (объект, имеющий identity)
- Value object;
- Composite. Это не GoF-овский Aggregate, он "жёстче". На его элементы нельзя ссылаться извне, их нельзя "вынимать" и без корневого объекта они не бывают. Связь с чёрным даймондом у него внутри навигабельна в обе стороны;
- 1-directional association;
- и что-то ещё;
Меня эта идея натолкнула на мысль, что бывают паттерны модели предметной области ("модели-задачи"), а бывают паттерны модели-решения. Например, такой вот "strong composite" (термин мой) - это паттерн анализа, а Observer - паттерн реализации.
Эту мысль надо развить.
Пообещал себе прочесть фаулеровские "Analysis patterns".
Об отличиях постановки задачи от модели-"постановки задачи" от модели-решения и от собственно решения.
Как вы сами понимаете, даже если мы говорим с заказчиком на одном языке, слово "пациент" значит для нас разные вещи.
Так вот, задача заказчика не эквивалентна модели этой задачи.
Модель-постановка задачи не эквивалентна модели решения; а та не эквивалентна самому решению — программе на языке, скажем, Java.
Потому что:
1) Ассоциация между классами на диаграмме UML, даже именованная, несет не такую семантическую нагрузку, как связь между накладной и товаром, или ссылка между классами в коде на Java. По ней не видно:
- навигабельна ли она в обе стороны или в одну;
- реализована ли она как ссылочное поле или как реестр;
- какие классы могут делать по ней навигацию - только владелец, все, или какоей-то подмножество;
- и ещё много чего по ней не видно, как из области задачи (бизнес-процесса), так и из решения (java-кода).
3) Ну и в SSADM выделяются "модель существующей системы" и "модель проектируемой системы". В терминах этой статьи, они равны понятиям "модель задачи" и "модель решения" соотв.
4) И чтобы модель точно соответствовала предметной области, вместо конструкторов и оператора new для пациента пришлось бы заводить объект-папу и объект-маму. Что есть нонсенс.
Из приколов:
(речь об отображении требований на языки со статической и динамической типизацией): "Сегодня я пассажир, а завтра пациент".
Tags:
Hello.
13/7/07 01:20 (UTC)I am sorry for my English. I only learn this language.
Сорри за спам, но думаю Вас заинтересует и такая книга
15/9/07 13:04 (UTC)http://www.williamspublishing.com/Books/978-5-8459-1296-1.html
Применение DDD и шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и .NET
Джимми Нильссон
Applying Domain-Driven Design and Patterns : With Examples in C# and .NET
Jimmy Nilsson
Сайт книги: www.jnsk.se
Блог автора: http://www.jnsk.se/weblog/
Еще ресурс: www.domaindrivendesign.org
интервью автора: www.infoq.com/interviews/jimmy-nilsson-domain-driven-design
--
С уважением,
Михаил
ИД "Диалектика - Вильямс"
(no subject)
16/9/07 09:11 (UTC)Неудобно говорить, но она у меня уже есть, правда, на английском...