Я прочитал книгу, вдохновился и хочу рассказать про неё. Книга старая, в оригинале написана в 2002 году, но при этом довольно ёмкая. И, что самое главное, в книге хорошо описан процесс проектирования системы: от прототипа интерфейса до постановок задач на разработку. Ещё в книге подробно показано взаимное влияния диаграмм UML друг на друга. Здесь лирическое отступление в виде пропевочки на мотив Б.Б. Гребенщикова: UML мёртв, а я еще нет... Итак, пора бы уже раскрыть первую тайну. Что это за книга? Процесс проектирования, описанный в книге, на мой взгляд направлен прежде всего на обеспечение полноты требований.  Авторы рассказывают про модели системы и связи между ними. Набор моделей, как известно, снижает риск пропуска требований и риск реализации функциональности, которая не соответствует требованиям.  Ведь что такое модели? Это упрощенное представление каких-то отдельных аспектов системы, которое приносит пользу. И здесь действует правило - если мы на одной модели упустили какие-то моменты, то велика вероятность, что сможем заметить их на другой модели. Каждая модель - это своего рода точка зрения на будущую систему.  Как тут не вспомнить старый афоризм: Все модели неверны, но некоторые полезны И пора уже раскрыть вторую тайну. Как же называется процесс, описанный в книге?  Книга описывает процесс по методологии ICONIX. Методология основана на языке UML. При этом, она (цитата):  легче, чем RUP, генерит больше документации, чем XP и поможет вам избавиться от «аналитического паралича», не жертвуя при этом анализом и проектированием Чуть ли не главное достоинство книги - наглядные примеры на основе учебного кейса. В качестве учебного кейса выбрано создание книжного интернет-магазина. Пример, конечно, рафинированный, но, тем не менее, хорошо иллюстрирует теорию. Для еще лучшего понимания тем в книгах приводятся упражнения на поиск ошибок в учебных диаграммах вместе с правильными диаграммами. Память подбрасывает очередной флешбек в виде цитаты: разница между теорией и практикой состоит в том, что теоретически такой разницы быть не должно, а практически она существует. Идем дальше. В книге, как и в самом ICONIX, за основу берутся 4 ключевых UML-диаграммы: Модель прецедентов Диаграмма последовательности Диаграмма пригодности Диаграмма классов Диаграммы разбиваются на две группы:  динамическая модель статическая модель. В совокупности эти диаграммы иллюстрируют принципы, на которых основан весь процесс (изнутри наружу, снаружи внутрь и сверху вниз – все одновременно): Движемся внутри, отталкиваясь от требований пользователя Движемся наружу, отталкиваясь от основных абстракций предметной области. Спускаемся вниз от высокоуровневых моделей к детальному проекту. Давайте рассмотрим более внимательно каждый тип диаграмм. Разработка системы начинается с выявления объектов предметной области, отношений между ними и первого варианта диаграммы классов. Также на этом этапе авторы рекомендуют создавать приблизительные прототипы интерфейса, если это возможно. После этого переходят к выявлению прецедентов и созданию диаграммы прецедентов с группировкой по схожести. Если созданы прототипы интерфейса, то первые объекты и прецеденты можно извлекать из них.  Прецеденты являются отправной точкой для детального проектирования: пройти все стадии от частичного понимания каждого прецедента через диаграммы последовательности до ассоциированных с ними элементов детального проекта. А также прецеденты помогают проверять модели на соответствие требованиям до перехода к кодированию: гарантировать, что реализация (как), представленная в детальном проекте, соответствует спецификации (что) Отдельно хочу выделить диаграмму пригодности. Она создается после первой версии диаграммы классов и модели прецедентов. Для себя я определил, что на диаграмму пригодности можно смотреть как на проекцию из двумерного пространства прецедентов с измерениями сущности и времяна пространство с одним измерением: сущности. Диаграмма пригодности связывает динамическую и статическую модели, которые упоминались ранее.   Для построения диаграммы пригодности нужно ответить на два вопроса: Какие объекты нужны для каждого прецедента? Какие функции будут выполнять объекты? По существу, диаграмма пригодности - это диаграмма классов, на которой изображаются пиктограммы трех видов: Граничный объект - объекты, которыми пользуются актеры (примечание: это цитата из книги, сам я предпочитаю слово “актОр”) для взаимодействия с системой Сущностный объект - обычно, это объект из модели предметной области Управляющий объект - контроллеры, выполняющие функцию “клея” между сущностными и граничными объектами Диаграмма пригодности помогает находить недостающие объекты, атрибуты и взаимодействия с помощью проверки простых правил. В книге вводятся четыре основных правила: Актеры могут общаться только с граничными объектами. Граничные объекты могут общаться только с контроллерами и актерами. Сущностные объекты могут общаться только с контроллерами. Контроллеры могут общаться с граничными объектами, сущностными объектами и другими контроллерами, но не с актерами. Авторы предлагают проводить анализ пригодности для каждого прецедента, включая его основной и все альтернативные потоки. Приведем еще полноценный пример диаграммы из книги для книжного магазина: Итак, диаграмма пригодности позволяет: Выявить объекты, которые нужны для каждого прецедента. Тем самым, уточнить и модель предметной области, и заложить основу для проектирования диаграмм последовательности Уточнить прецеденты, находя несоответствия и пробелы в описаниях Цитата из книги: Диаграмма пригодности напоминает диаграмму кооперации из UML: на ней изображены объекты, участвующие в сценарии, и способы их взаимодействия. Анализ пригодности не входит в ядро UML, но требует некоторых стереотипов. Он был частью метода Objectory, созданного Джекобсоном. Эта неформальная методика весьма полезна для уточнения прецедентов и выявления объектов, которые для них необходимы, но по какой-то причине не вошли в модель предметной области. Создавая язык UML, «три амиго» знали о существовании этой техники, но не включили ее в основную часть стандарта. Вместо этого они разработали специализированные расширения для процесса Objectory с помощью механизма стереотипов, который позволяет связывать нестандартные пиктограммы с любыми символами. При анализе пригодности в роли таких стереотипов выступают пиктограммы классов. Дальше дополняется модель предметной области. И строим диаграммы последовательностей.  Взаимодействия - есть не что иное, как методы в объектах. Для каждого взаимодействия должен быть соответствующий метод в объектах, который его реализует. Таким образом, мы наполним наши объекты методами.  И еще. Обратите внимание, что текст прецедента пишется рядом с диаграммой последовательностей. Очень удобно, что в одном месте и текст, и иллюстрирующая его диаграмма. Процесс построения диаграмм обеспечивает согласованность между ними и достаточную проработку для сравнительно простого перехода к кодированию. В финале отмечу, что мне понравилось и что не понравилось в книге. Что понравилось: Явно показан путь от прототипов интерфейсов до постановки задачи в разработку Даны конкретные упражнения, в которых разобраны типовые ошибки. Книга ёмкая. В сумме с упражнениями и приложениями - 160 страниц. Содержательных около сотни.  Что не понравилось: Описание прецедентов хотя и имеет формализованный характер, все же довольно “сырые” и непрактичные. Я бы предпочел описания, которые были бы ближе к Алиестру Коберну Диаграммы последовательности не всегда корректно отрисованы. Например, часто не показан ответ Рассматривалась отдельная система в вакууме. В реальности же достаточно много интеграций. Хотя, если честно, аппроксимировать не так уж и сложно. По содержанию и смыслу очень напомнило книгу Эдуарда Галиасканова “Анализ и проектирование систем с использованием UML. Учебное пособие для вузов”. Надеюсь, статья открыла что-то новое для читателей или побудила интерес к самостоятельному прочтению книги.  имитатор бурной деятельности