Я прочитал книгу, вдохновился и хочу рассказать про неё. Книга старая, в оригинале написана в 2002 году, но при этом довольно ёмкая. И, что самое главное, в книге хорошо описан процесс проектирования системы: от прототипа интерфейса до постановок задач на разработку. Ещё в книге подробно показано взаимное влияния диаграмм UML друг на друга.
Здесь лирическое отступление в виде пропевочки на мотив Б.Б. Гребенщикова:

UML мёртв, а я еще нет...

Итак, пора бы уже раскрыть первую тайну. Что это за книга?

Процесс проектирования, описанный в книге, на мой взгляд направлен прежде всего на обеспечение полноты требований.

Авторы рассказывают про модели системы и связи между ними. Набор моделей, как известно, снижает риск пропуска требований и риск реализации функциональности, которая не соответствует требованиям.

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

Как тут не вспомнить старый афоризм:

Все модели неверны, но некоторые полезны

И пора уже раскрыть вторую тайну. Как же называется процесс, описанный в книге?

Книга описывает процесс по методологии ICONIX. Методология основана на языке UML. При этом, она (цитата):

легче, чем RUP, генерит больше документации, чем XP и поможет вам избавиться от «аналитического паралича», не жертвуя при этом анализом и проектированием

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

Память подбрасывает очередной флешбек в виде цитаты:

разница между теорией и практикой состоит в том, что теоретически такой разницы быть не должно, а практически она существует.

Идем дальше. В книге, как и в самом ICONIX, за основу берутся 4 ключевых UML-диаграммы:

1. Модель прецедентов

2. Диаграмма последовательности

3. Диаграмма пригодности

4. Диаграмма классов

Диаграммы разбиваются на две группы:

1. динамическая модель

2. статическая модель.

В совокупности эти диаграммы иллюстрируют принципы, на которых
основан весь процесс (изнутри наружу, снаружи внутрь и сверху вниз – все
одновременно):

1. Движемся внутри, отталкиваясь от требований пользователя

2. Движемся наружу, отталкиваясь от основных абстракций предметной области.

3. Спускаемся вниз от высокоуровневых моделей к детальному проекту.

Давайте рассмотрим более внимательно каждый тип диаграмм.

Диаграмма классов и диаграмма прецедентов

Разработка системы начинается с выявления объектов предметной области, отношений между ними и первого варианта диаграммы классов. Также на этом этапе авторы рекомендуют создавать приблизительные прототипы интерфейса, если это возможно.

После этого переходят к выявлению прецедентов и созданию диаграммы прецедентов с группировкой по схожести. Если созданы прототипы интерфейса, то первые объекты и прецеденты можно извлекать из них.

Прецеденты являются отправной точкой для детального проектирования:

пройти все стадии от частичного понимания каждого прецедента через диаграммы последовательности до ассоциированных с ними элементов детального проекта.

А также прецеденты помогают проверять модели на соответствие требованиям до перехода к кодированию:

гарантировать, что реализация (как), представленная в детальном проекте, соответствует спецификации (что)

Диаграмма пригодности

Отдельно хочу выделить диаграмму пригодности. Она создается после первой версии диаграммы классов и модели прецедентов. Для себя я определил, что на диаграмму пригодности можно смотреть как на проекцию из двумерного пространства прецедентов с измерениями сущности и времяна пространство с одним измерением: сущности.

Диаграмма пригодности связывает динамическую и статическую модели, которые упоминались ранее.

Для построения диаграммы пригодности нужно ответить на два вопроса:

1. Какие объекты нужны для каждого прецедента?

2. Какие функции будут выполнять объекты?

По существу, диаграмма пригодности - это диаграмма классов, на которой изображаются пиктограммы трех видов:

1. Граничный объект - объекты, которыми пользуются актеры (примечание: это цитата из книги, сам я предпочитаю слово “актОр”) для взаимодействия с системой

2. Сущностный объект - обычно, это объект из модели предметной области

3. Управляющий объект - контроллеры, выполняющие функцию “клея” между сущностными и граничными объектами

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

В книге вводятся четыре основных правила:

1. Актеры могут общаться только с граничными объектами.

2. Граничные объекты могут общаться только с контроллерами и актерами.

3. Сущностные объекты могут общаться только с контроллерами.

4. Контроллеры могут общаться с граничными объектами, сущностными объектами и другими контроллерами, но не с актерами.

Авторы предлагают проводить анализ пригодности для каждого прецедента, включая его основной и все альтернативные потоки.

Приведем еще полноценный пример диаграммы из книги для книжного магазина:

Итак, диаграмма пригодности позволяет:

• Выявить объекты, которые нужны для каждого прецедента. Тем самым, уточнить и модель предметной области, и заложить основу для проектирования диаграмм последовательности

• Уточнить прецеденты, находя несоответствия и пробелы в описаниях

Цитата из книги:

Диаграмма пригодности напоминает диаграмму кооперации из UML: на ней изображены объекты, участвующие в сценарии, и способы их взаимодействия. Анализ пригодности не входит в ядро UML, но требует некоторых стереотипов. Он был частью метода Objectory, созданного Джекобсоном. Эта неформальная методика весьма полезна для уточнения прецедентов и выявления объектов, которые для них необходимы, но по какой-то причине не вошли в модель предметной области. Создавая язык UML, «три амиго» знали о существовании этой техники, но не включили ее в основную часть стандарта. Вместо этого они разработали специализированные расширения для процесса Objectory с помощью механизма стереотипов, который позволяет связывать нестандартные пиктограммы с любыми символами. При анализе пригодности в роли таких стереотипов выступают пиктограммы классов.

Диаграмма последовательностей

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

И еще. Обратите внимание, что текст прецедента пишется рядом с диаграммой последовательностей. Очень удобно, что в одном месте и текст, и иллюстрирующая его диаграмма.

Заключение

Процесс построения диаграмм обеспечивает согласованность между ними и достаточную проработку для сравнительно простого перехода к кодированию. В финале отмечу, что мне понравилось и что не понравилось в книге.

Что понравилось:

• Явно показан путь от прототипов интерфейсов до постановки задачи в разработку

• Даны конкретные упражнения, в которых разобраны типовые ошибки.

• Книга ёмкая. В сумме с упражнениями и приложениями - 160 страниц. Содержательных около сотни.

Что не понравилось:

• Описание прецедентов хотя и имеет формализованный характер, все же довольно “сырые” и непрактичные. Я бы предпочел описания, которые были бы ближе к Алиестру Коберну

• Диаграммы последовательности не всегда корректно отрисованы. Например, часто не показан ответ

• Рассматривалась отдельная система в вакууме. В реальности же достаточно много интеграций. Хотя, если честно, аппроксимировать не так уж и сложно.

По содержанию и смыслу очень напомнило книгу Эдуарда Галиасканова “Анализ и проектирование систем с использованием UML. Учебное пособие для вузов”.

Надеюсь, статья открыла что-то новое для читателей или побудила интерес к самостоятельному прочтению книги.