Анализ пригодности

Для связывания статической и динамической моделей надо ответить на два основных вопроса. Во-первых, какие объекты нужны для каждого прецедента? (Второй вопрос обсуждается в главе 7.) Для ответа на этот вопрос воспользуемся техникой анализа пригодности, разработанной А. Джекобсоном.

Диаграмма пригодности (Robustness Diagram) напоминает диаграмму кооперации из UML: на ней изображены объекты (точнее – классы), участвующие в сценарии, и способы их взаимодействия. Анализ пригодности не входит в ядро UML, но требует некоторых стереотипов. Он был частью метода Objectory, созданного Джекобсоном. Эта неформальная методика весьма полезна для уточнения прецедентов и выявления объектов, которые для них необходимы, но по какой-то причине не вошли в модель предметной области.

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

По существу, диаграмма пригодности в UML - это диаграмма классов, хотя в оригинальной концепции Джекобсона она была ближе к диаграммам кооперации, на которых показываются не классы, а их экземпляры. Но в настоящее время это диаграмма классов, на которой вместо обычных в UML символов классов изображаются пиктограммы трех видов (рис. 5.1):

• граничные (<<boundary>>) объекты, которыми актеры пользуются для взаимодействия с системой;
• сущностные (<<entity>>) объекты - обычно из модели предметной области (см. главу 2);
• управляющие (<<control>>) объекты (обычно называются контроллерами, так как им ничего не соответствует в реальном мире), выполняющие функции «клея» между граничными и сущностными объектами.

На рис. 5.1 изображены пиктограммы для трех видов объектов.

В процессе ICONIX эта простая, но исключительно полезная техника служит связующим звеном между анализом (что) и проектированием (как) - рис. 5.2.

Эта диаграмма объясняет, почему процесс разработки программного обеспечения такой сложный. Дело в том, что начинаем мы с уровня требований, на котором размышляем только о том, что нужно пользователям от системы, не задумываясь о деталях реализации, а затем меняем угол зрения, сосредотачиваясь исключительно на проектировании. При этом на диаграмме последовательности (см. главу 7) отражено, как взаимодействуют экземпляры объектов, существующие во время исполнения. Одна из самых трудных проблем при разработке программного обеспечения - переход от взгляда на мир с позиции «что делать» к взгляду с позиции «как делать». Именно для решения этой задачи и предназначен анализ пригодности.

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

Любопытно, что в литературе по языку UML эта методика практически не упоминается. Но наш опыт показывает, что от нее напрямую зависит успешность работы над проектом.

На рис. 5.3 показано место анализа пригодности в общей картине процесса ICONIX.