Читаю в настоящее время книгу Дуга Розенберга и Мэта Стефенсона Use Case Driven Object Modeling with UML: Theory and Practice.
Книга написано просто, экономно и прагматично. В начале дается теория, которая подкрепляется практикой с моделями и диалогами, далее даются задания и производится разбор этих заданий.
Книга посвящена использованию процесса ICONIX. Процесс, управляемый вариантами использования, что означает, что UC - основа разработки и принятия решения по каждому факту. UC используют все от аналитика до конкретного программиста.
В ходе чтения обнаружил, что Розенберг совершенно иначе трактует вопросы создания вариантов использования, причем явно идет в пику Коберну и другим гуру по UC.
Ради справедливости стоит заметить. Что первые 15 лет, Дуг зарабатывал на жизнь в качестве программиста, затем уже перешел в менеджеры проекта и даже основал собственную компанию. Мэт из Лондона - Java программист, лидер проекта, технический архитектор.
В чем же отличия?
1. Вариант использования должен описываться в стиле двух параграфов (абзацев) - один для основного потока, другой для альтернативных. стр.52 (англ издание)
2.Вариант использование описывается с использованием раскадровок, прототипов или экранных форм. Т.е. по сути ВИ должен содержать элементы интерфейса (возможно - это свзяано например с тем, что разработка систем с нуля, сейчас редко происходит, всегда изучается уже имеющиеся системы и их наработки)
3. вместо includes и extends следует использовать invokes и precedes. Активно избегать обобщения.
4 вариант использования описывается в сжатом формате. Если не удается описать в сжатом формате, ВИ следует разделить на несколько. (это как авторы потом объясняют проявляется при рисовании robustness diagram на которой нужно изобразить все потоки: основной и альтернативный, так же как sequence)
в частности автор комментируя шаблон Коберна в известной его книге пишет:
Here’s an example of a long and particularly ghastly (in our opinion) use case template
from renowned guru Alistair Cockburn’s book Writing Effective Use Cases:4
We regard this template as ghastly because, while it is theoretically elegant in that it
comprehensively covers everything you might possibly want to discuss in conjunction with
a use case, in practice, if you require your team to “fill out the long form” use case template,
they will rapidly discover that
1. They are wasting time.
2. Wasting time will turn them off to the entire modeling process.
3. They can mindlessly fill out the form without focusing on the important parts (basic
course and alternate courses) of the use case, and nobody will know the difference.
We’ve seen this happen in the real world on many occasions.
Consider the statements we just made as warnings about ways you might build up resistance
to doing use cases, which offers an excuse to ditch modeling altogether—and we all
know what happens then. (Hint: “The code’s written, so I guess we’re done!”)
Далее на странице 93 в конце идет объяснение того, почему не следует писать UC слишком абстрактно. Надо сказать довольно убедительно.
Many books about use cases, especially those that are focused strictly on use cases as a
requirements definition technique, preach writing use cases that are “abstract, essential,
technology-free, and implementation-independent.” Our approach is a bit different, as
you’ll see in the following review segment, since we both come from a programming background
(most programmers would call the aforementioned use cases “vague, ambiguous,
incomplete, and incorrect”).
далее идет диалог Аналитика и Читателя-эксперта, который проверяет варианты.
Читая книгу, я вижу практичность и убедительность доводов Розенберга, тем более они подкреплены примером. Правда пример Интернет-магазин.
Меня убеждают и слова Коберна и других гуру UC.
В результате меня заклинило
Кто же прав: Коберн или Розенберг? Или по другому в каком контексте правы оба?
Обращаюсь к нашим аналитикам за помощью. Давайте разберем это по полочкам!
Просмотр сообщений
