Используемый в разработке программного обеспечения инструментарий не ограничивается только лишь системой управления проектом и интегрированной средой разработки. Для моделирования и проектирования разработаны специализированные инструменты, о которых обязательно нужно знать разработчикам и уметь применять. В этом посте я хочу рассказать про наш опыт использования Enterprise Architect (EA) в собственных проектах.

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

• Поддержка UML построена в целом на базе RUP, что будет полезно для команд, которые используют этот фреймворк, то есть при создании нового проекта автоматически создается дерево моделей и представлений по RUP. Не всегда это удобно, но легко модифицируется. Вы можете описывать прецеденты, логические модели, поведенческие модели (диаграммы состояний и последовательностей), модели данных, компонентов и диаграммы развертывания. В этом плане EA не заменим для работы аналитиков, разработчиков и архитекторов.
• Возможности кодогенерации и создания скриптов моделей могут пригодиться командам, которые используют методологию MDD (model driven development), по сути EA нацелен именно на подобные команды. Из неудобств моделирования баз данных хочу отметить отсутствие автоматической возможности переключаться между логическим и физическим уровнем данных, отлично реализованном в ERWin. Настройка физических аспектов элементов базы данных конечно не такая гибкая как в более специализированных инструментах.
• В последних версиях EA появились возможности по управлению требованиями и изменениями (issue, defect), которые можно привязывать непосредственно к элементам модели. Аналитики теперь могут вести требования непосредственно в моделях EA. Мы эту возможность не использовали, но она будет крайне полезна адептам MDD. Тестировщики могут описывать приемочные тесты непосредственно в EA для каждого элемента модели. Все члены команды могут списывать затраченные часы, связанные с моделированием или реализацией отдельных элементов модели.
• EA предлагает использовать большое количество проектных метрик, рассчитываемых в основном на сложности элементов модели и связях между элементами. Вы можете использовать эти метрики для оценки рисков, с которыми может столкнуться команда в рамках работы над проектом.
• В EA есть возможность отслеживать изменения моделей, выполняемые участниками. Для этого необходимо создавать baseline, после чего текущую версию или предыдущий baseline можно сравнивать с любым другим baseline.

Что касается вопросов интеграции, то EA можно использовать совместно с Eclipse и VSTS, организовать контроль версий моделей при помощи систем контроля версий. Отдельно хотелось бы отметить возможность организации единого репозитория проектов и моделей на базе СУБД. В этом случае все участники команды могут работать с единым хранилищем всей информации, сосредоточенной в моделях EA.

При разработке достаточно сложного или крупного приложения необходимо уделять особое внимание проектированию и документированию его архитектуры. В DEVPROM есть отдельная фаза, которая называется "Проектирование" в рамках которой участники проекта могут готовить соответствующие диаграммы или модели. Существует достаточно много инструментов для проектирования и документирования программной архитектуры и дизайна. В DEVPROM можно загружать готовые модели или вставлять изображения подготовленных диаграмм. Это может быть особенно полезно, если не все участники проекта владеют или хотят устанавливать дополнительное ПО для просмотра диаграмм.