М. Фаулер, К. Скотт - UML Основы, страница 7

Представьте себе текстовый процессор, который я использую в данный момент. Одним из вариантов использования может быть «проверка правописания», другим — »создание предметного указателя для документа». Важной особенностью вариантов использования является то, что каждый из них определяет некоторую функцию, которая понятна пользователю и имеет для него определенное значение. Разработчик может отреагировать, например, следующим образом: На реализацию функции создания предметного указателя у меня уидеп1 два месяца. 6стыпакже вариант использования, связанныи с поддержкои грамматическои проверки. Думаю, зто может занять п1ри месяца.

В нашем распоряжении люлько три месяца на выполнение проекта — что вы «отели бы получить в первую очередь? Глава 2. Основы процесса разработки Варианты использования являются основой для общения и взаимопонимания между пользователями и разработчиками при планировании проекта. Одна из наиболее важных вещей, которые необходимо сделать на фазе исследования, — это определение всех возможных вариантов использования разрабатываемой вами системы. На практике, разумеется, вы не в состоянии определить абсолютно все варианты.

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

При этом сама картина бизнес-деятельности находится в голове у одного или нескольких пользователей. Например: Наша клиенты могут располагаться в несиолькох различных пунитах, и в каждом из зтох пунктов мы предоставляем набор услуг. В определенньш момент времена клиент получает счет за все услуги, оказанные в данном пункте. Нам нужно, чтобы клиенту выставлялся счет за все услуга, оказанные во всех пунктах.

Мы называем зто консолодорованным счепюм. Этот фрагмент содержит слова «клиент», «пункт» и «услуга». Что означают эти термины т Как они соотносятся друг с другом7 Концептуальная модель предметной области дает начало ответам на эти вопросы и в то же время закладывает основу модели объектов, которая будет позже использоваться в процессе разработки для представления объектов системы. Я использую термин модель предметной области для определения любой модели, главное назначение которой состоит в описании той части реального мира, в рамках которого создается компьютерная система. Такая модель не зависит от стадии, на которой находится процесс разработки.

Заметим, что Рациональный унифицированный процесс определяет термин «модель предметной области» более тщательно. Эта тема детально изложена в книге Джекобсона, Буча и Рамбо, 1999 (231. Я придерживаюсь точки зрения большинства известных мне разработчиков из объектного сообщества. Исследование Для построения модели предметной области особенно полезны следую- щие два метода языка БМЬ. Основным методом, который я использую для построения моделей предметной области, является диаграмма классов, рассматриваемая с концептуальной точки зрения (см.

главу 4). Эти диаграммы могут быть использованы для представления понятий, которые применяют бизнес-аналитики при исследовании соответствующей бизнес-системы, и для представления особенностей объединения этих понятий в единой модели. Во многих случаях именно диаграммы классов определяют некоторый терминологический словарь для описания соответствующей предметной области. Если предметная область также обладает явно выраженным элементом потока работ, я предпочитаю представлять этот аспект с помощью диаграмм деятельности (см. главу 9). Главной особенностью диаграмм деятельности является их способность изображать параллельные процессы, которые очень важны для исключения ненужных последовательностей в бизнес-процессах. Некоторые разработчики предпочитают пользоваться диаграммами взаимодействия (см.

главу 5) для исследования взаимодействия различных ролей в бизнес-системе. Рассматривая совместно исполнителей и деятельности, они приходят к лучшему пониманию соответствующего бизнес-процесса. Лично я предпочитаю использовать диаграммы деятельности для изображения того, что необходимо сделать в первую очередь, а также чтобы определить, кто и что будет делать впоследствии.

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

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

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

На этом этапе важно придерживаться Глава 2. Основы процесса разработки концептуальной точки зрения на проект, но в то же время придать ему большую строгость. После этого построенная модель может быть использована в качестве начального представления для построения классов на фазе построения. Если модель получилась большой, удобно использовать пакеты для разделения модели на составные части, после чего объединить диаграммы классов и деятельности, нарисовав пару диаграмм состояний для тех классов, которые имеют интересные жизненные циклы.

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

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

Большинство деталей выявится в ходе итеративной разработки. Именно поэтому я предпочитаю рассматривать подобную модель как базовый остов, который служит фундаментом для последующих моделей. Хотя она и содержит детали, но составляет только небольшую часть нашего проекта.

Естественно, она не скажет вам, как отделить «мясо от костей», именно в этом состоит искусство опытного аналитика, а я пока не разобрался, как это делается. Как только определены варианты использования, они позволят управлять дальнейшим моделированием предметной области. При появлении очередных вариантов использования команда разработчиков должна оценить, содержат ли они нечто такое, что способно оказать сильное влияние на модель предметной области. Если содержат, то их нужно исследовать и далее, а если нет, то такие варианты использования следует отложить на некоторое время в сторону. Команда, занятая построением модели предметной области, должна представлять собой небольшую группу (от двух до четырех человек), в состав которой входят разработчики и эксперты предметной области.