Главная » UML » Настройка UML под процесс

0

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

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

Использование UML не подразумевает обязательную разработку документов или загрузку сложных CASE-систем.

Анализ требований

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

•       Прецеденты,   которые  описывают,   как  люди   взаимодействуют с системой.

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

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

 

•          Диаграмма состояний, которая может оказаться полезной, если концепция имеет своеобразный жизненный цикл с различными состояниями и событиями, которые изменяют эти состояния.

Анализируя состояния, помните, что самое важное – это взаимодействие с вашими пользователями и клиентами. Обычно это непрограммисты, и они не знакомы с UML и другими подобными технологиями. Несмотря на это я успешно применял перечисленные приемы при общении с людьми, не имеющими инженерной подготовки. Чтобы добиться этого, надо свести количество нотаций к минимуму. Не следует вводить элементы, специфичные для программной реализации.

Будьте готовы в любой момент отойти от правил UML, если это поможет улучшить взаимопонимание. Наибольший риск в случае применения UML для анализа состоит в том, что вы строите диаграммы, не совсем понятные специалистам в конкретной предметной области. Такая диаграмма хуже, чем бесполезная; она лишь способна вселить в разработчиков ложное чувство уверенности.

Источник: Фаулер М.UML. Основы, 3-е издание. – Пер. с англ. – СПб: Символ-Плюс, 2006. – 192 с.,ил.

По теме:

  • Комментарии