Данная статья представляет собой краткое изложение моего опыта работы c диаграммами вариантов использования (use-case diagram). Я постарался написать ее простым языком, а также описал некоторые нюансы, которые показали свою полезность при моделировании.
Под "программой" в статье понимается любое ПО: десктоп-приложения, веб-приложения, библиотеки, консоли и т.п.
Зачем нужна диаграмма вариантов использования?
Любая программа создается для того, чтобы удовлетворять потребности какой-либо группы людей (например, графический редактор используется дизайнерами), или предоставлять свой функционал для использования другими программами. Функционал, который реализован в программе, можно представить как некоторое, иногда очень большое, количество операций (действий) над чем-либо (документы, настройки и т.п.), которые пользователь может выполнять в программе. Тот же графический редактор, например, может изменять размеры изображений, удалять "красные глаза" на фотографиях, изменять цветовую гамму, сохранять изображение в jpg или bmp-формате и многое другое. Т.о., любую программу можно представить как конечный набор операций, предназначенных для использования конечным количеством тех или иных групп потребителей. Диаграмма вариантов использования служит для того, чтобы выявить, упорядочить и ограничить операции, реализуемые в программе, необходимые для пользователей, которые, как предполагается, будут с этой программой работать. Соответственно, данная диаграмма составляется на самом раннем этапе работы на программой, когда есть только какие-то общие идеи и концепции, но нет точного перечня того, что будет делать программа. Речь идет не только о написании программ с нуля, но и о расширении функционала существующего ПО.
Что из себя представляет диаграмма.
Если коротко, то в наглядной графической форме на диаграмме показано, "кто" "что делает".
"Кто" - группы пользователей, которые будут работать с программой, называются актерами или действующими лицами. Здесь следует заметить, что речь идет не о конкретных пользователях (Иванова Маргарита Львовна), а о тех ролях, в которых они выступают, работая с системой (бухгалтер). Например, с графическим редактором могут работать два действующих лица - фотограф и дизайнер - за которыми могут скрываться как тысячи людей, так и один человек. Иногда актер может точно соответствовать должности пользователя в компании - кладовщик, бухгалтер, логист.
"Что делает" - функции программы, которыми пользуются действующие лица, называются вариантами использования. Как вы уже поняли, вариант использования отвечает на вопрос: что делает? Есть хорошее правило наименование варианта использования начинать с глагола в неопределенной форме или оглагольного существительного: "Открыть файл", "Преобразование записи человеческой речи в текстовый формат", "Провести бухгалтерскую проводку". Как видно из приведенных названий, за каждым вариантом использования всегда скрывается какой-то процесс (бизнес-процесс или просто какое-то действие в программе), в который вовлечен актер. Актер может инициировать этот процесс, пользоваться его результатами, контролировать его ход. Данные процессы могут быть очень объемными и/или сложными, но в рамках диаграммы сущность процесса не имеет значения, важно показать, что он есть и будет использоваться тем или иным действующим лицом. Диаграмма вариантов использования не отображает, как этот процесс будет реализован, какие шаги в него входят, какие объекты создаются и т.п. Для это существуют другие диаграммы.
Между актерами и вариантами использования, а также между вариантами использования и другими вариантами использования, существуют отношения. Отношения между сущностями регламентируются несколькими простыми правилами:
- Актер каждый всегда связан хоть с одним вариантом использования (иначе следует вывод, что актер просто не использует функционал программы)
- Каждый вариант использования связан либо актером, либо с другим вариантом использования (иначе следует вывод, что в программе есть никому не нужный функционал)
Отношения между вариантами использования могут быть следующих видов:
- include - вариант А входит в вариант Б, т.е. вариант Б является обобщением действий дочерних вариантов. Например: "Открыть файл" (вариант А) входит в "Работать с файлом" (вариант Б).
- extend - вариант А делает то же самое, что и вариант Б, но с некоторыми дополнениями (А "расширяет" Б). Пример: "Создать документ на основе шаблона" (вариант А) есть расширение для "Создать документ" (вариант Б).
- generalization - своего рода комбинация вышеуказанных случаев. Например, "Синхронизировать с веб-хранилищем" (Вариант А) входит в "Сохранить файл" (Вариант Б).
Как происходит моделирование.
Определяются возможные действующие лица, для каждого из этих лиц определяются варианты использования. Процесс этот творческий и итеративный. Очень хорошо, если диаграмму моделируют несколько человек, чтобы предложить как можно больше вариантов. Также желательно провести моделирование не одномоментно, а в несколько "сеансов", чтобы хотя бы раз посмотреть на результат на "свежую" голову и при необходимости внести коррективы.
Для моделирования можно использовать различное специализированное программное обеспечение (Rational Rose, MS Visio) или дешевый и сердитый вариант - карандаш и бумага.
При создании диаграммы есть ряд тонкостей, о которых хотелось бы упомянуть.
Любая диаграмма UML, в т.ч. и диаграмма вариантов использования, это УПРОЩЕННАЯ модель реальной системы, поэтому если диаграмма получается запутанной и сложной (большая не значит запутанная и сложная!), вероятно, что-то сделано не так, и требуется остановиться и подумать, как все упростить. Модель не может быть сложнее системы, которую она моделирует. Точнее, модель должна быть НАМНОГО ПРОЩЕ моделируемой системы.
Также следует отметить, что не существует идеально правильной нотации UML. В каждой компании и в каждом проекте могут быть свои нюансы. Например, в MS Visio отношение include называется uses, и есть дополнительные элементы - constrain'ы и др. Это не значит, что один вариант нотации правилен, а другой нет. Если последующая разработка на основе диаграммы была успешна, то и нотацию следует считать правильной. Другое дело, что в рамках одного проекта следует договориться об используемой нотации так, чтобы все диаграммы делались в одном ключе, на основе одних сущностей, и в дальнейшем этой нотации придерживаться.
Если вариантов использования получается слишком много, их можно сгруппировать, добавив промежуточный обобщающий вариант использования ("Работа с файлом"). Можно большую по количеству элементов диаграмму разделить на несколько меньших диаграмм, описав отдельные варианты использования на других диаграммах. В целом, уровень детализации определяется создателем диаграммы исходя из здравого смысла и контекста задачи, для которой делалась диаграмма. Автору видел легко читаемые диаграммы вариантов использования на листах формата А1.
Разнообразные уточнения, в т.ч. технического характера (в каком виде будет результат работы с вариантом использования, наметки классов и т.п.), следует обязательно фиксировать, например, как примечания к диаграмме, все это пригодится в дальнейшем.
Объект, над которым выполняется действие в варианте использования, возможно будет (а возможно, не будет, это не жесткое правило) являться экземпляром класса в программе (при использовании ООП, конечно), а действия, над ним выполняемые - методы этого класса. Например: варианты использования "Сохранить статью", "Редактировать статью", "Печатать статью" преобразуются в класс CArticle и методы CArticle.Save, CArticle.Edit, CArticle.Print.
Есть смысл при создании диаграммы найти (придумать) как можно больше вариантов использования. Исходя из этого, можно подготовить составить план (roadmap), какие варианты будут реализованы в бета-версии, что в релизе, что в последующих версиях. Также, с прицелом на будущий функционал, спроектировать техническую реализацию программы, например, предусмотреть возможность аддонов и расширений.
Что с этим делать дальше?
Подготовить roadmap, как было описано выше.
Диаграмма вариантов использования служит отличным дополнением к ТЗ или любой другой спецификации создаваемой программы.
Для вариантов использования, по которыми скрываются сложные процессы, можно делать диаграммы деятельности (activity diagram) или последовательности (sequence diagram), описывающие ход процесса. Если диаграмма вариантов использования описывает, ЧТО система делает, то эти диаграммы говорят, КАК система делает ту или иную функцию.
Диаграмма вариантов использования также является одним из основных документов для создания диаграммы классов.
Пример диаграммы.
Диаграмма для desktop-приложения: блокнот с функциональностью wiki. В одном файле сохраняются несколько статей. Для статей существует история и возможность добавлять теги.
Данная диаграмма приведена лишь как иллюстрация к статье. Соответственно, рассмотрены только два варианта использования: "Работать с файлом", "Работать со статьей". Детализация также не очень глубокая. Можно было добавить варианты для работы с тегами, с таблицей и др. Все отношения "include" между вариантами показаны обычными линиями.
И еще.
Замените слово "программа" на слово "изделие". При проектировании "железа" все принципы остаются те же.
