Унифицированный процесс – это процесс, управляемый прецедентами, которые отражают сценарии взаимодействия пользователей. Фактически, это взгляд пользователей на программную систему снаружи. Таким образом, одним из важнейших этапов разработки, согласно RUP, будет этап определения требований, который заключается в сборе всех возможных пожеланий к работе системы, которые только могут прийти в голову пользователям и аналитикам. Позднее эти данные должны будут систематизированы и структурированы, но на данном этапе в ходе интервью с пользователями и изучения документов, аналитики должны собрать как можно больше требований к будущей системе, что не так просто, как кажется на первый взгляд. Пользователи часто сами не представляют, что они должны получить в конечном итоге. Для облегчения этого процесса аналитики используют диаграммы прецедентов (рис. 2)
Рис. 2. Фрагмент диаграммы использования (прецедентов)
Диаграмма представляет собой отражение действующих лиц (актантов), которые взаимодействуют с системой, и реакцию программных объектов на их действия. Актантами могут быть как пользователи, так и внешние агенты, которым необходимо передать или получить информацию. Значок варианта использования отражает реакцию системы на внешнее воздействие и показывает, что должно быть сделано для актанта.
Для детализации конкретного прецедента используется диаграмма активности (Activity Diagram), пример которой дан на рис 3.
Рис. 3. Пример диаграммы активности
Простота диаграммы прецедентов позволяет аналитикам легко общаться с заказчиками в процессе определения требований, выявлять ограничения, налагаемые на систему и на выполнение отдельных требований, таких, например, как время реакции системы, которые в дальнейшем попадают в раздел нефункциональных требований.
Также диаграмма прецедентов может использоваться для создания сценариев тестирования, поскольку все взаимодействия пользователей и системы уже определены.
Для того чтобы верно определить требования, разработчики должны понимать контекст (часть предметной области), в котором будет работать будущая система. Для этого создаются модель предметной области и бизнес-модель, что является различными подходами к одному и тому же вопросу. Часто создается что-то одно: модель предметной области или бизнес-модель.
Отличия этих моделей в том, что модель предметной области описывает важные понятия, с которыми будет работать система и связи их между собой. Тогда как бизнес-модель описывает бизнес-процессы (существующие или будущие), которые должна поддерживать система. Поэтому кроме определения бизнес-объектов, вовлеченных в процесс, эта модель определяет работников, их обязанности и действия, которые они должны выполнять.
Для создания модели предметной области используется обычная диаграмма классов, однако для создания бизнес-модели ее уже явно недостаточно. В этом случае применяется диаграмма прецедентов с использованием дополнительных значков, которые отражающие сущность бизнес-процессов – это бизнес-актант, бизнес-прецедент, бизнес-сущность и бизнес-управление. Эта модель намного ближе к следующей модели, создаваемой в процессе разработки – модели анализа.
Анализ
После определения требований и контекста, в котором будет работать система, наступает черед анализа полученных данных. В процессе анализа создается аналитическая модель, которая подводит разработчиков к архитектуре будущей системы. Аналитическая модель – это взгляд на систему изнутри, в отличие от модели прецедентов, которая показывает, как система будет выглядеть снаружи.
Эта модель позволяет понять, как система должна быть спроектирована, какие в ней должны быть классы и как они должны взаимодействовать между собой. Основное ее назначение - определить направление реализации функциональности, выявленной на этапе сбора требований и сделать набросок архитектуры системы.
В отличие от создаваемой в дальнейшем модели проектирования, модель анализа является в большей степени концептуальной моделью и только приближает разработчиков к классам реализации. Эта модель не должна иметь возможных противоречий, которые могут встретиться в модели прецедентов.
Для отображения модели анализа при помощи UML используется диаграмма классов со стереотипами (образцами поведения) «граничный класс», «сущность», «управление», а для детализации используются диаграммы сотрудничества (Collaboration) (рис 4). Стереотип «граничный класс» отображает класс, который взаимодействует с внешними актантами, «сущность» – отображает классы, которые являются хранилищами данных, а «управление» – классы, управляющие запросами к сущностям.
Рис. 4. Пример диаграммы сотрудничества
Нумерация сообщений показывает их порядок, однако назначение диаграммы не в том, чтобы рассмотреть порядок обмена сообщениями, а в том, чтобы наглядно показать связи классов друг с другом.
Если акцентировать внимание на порядке взаимодействия, то другим его представлением будет диаграмма последовательности (Sequence), показанная на рис 5. Эта диаграмма позволяет взглянуть на обмен сообщениями во времени, наглядно отобразить последовательность процесса. При использовании такого инструмента для создания моделей как Rational Rose, эти два вида диаграмм могут быть созданы друг из друга автоматически.
Рис. 5. Пример диаграммы последовательности действий
Решение о том, какую из двух диаграмм нужно создавать первой, зависит от предпочтений конкретного разработчика. Поскольку эти диаграммы являются отображением одного и того же процесса, то и та и другая позволяют отразить взаимодействие между объектами.
