М. Фаулер, К. Скотт - UML. Основы - 2002 (1158629), страница 7
Текст из файла (страница 7)
Например: Наша клиенты могут располагаться в несиолькох различных пунитах, и в каждом из зтох пунктов мы предоставляем набор услуг. В определенньш момент времена клиент получает счет за все услуги, оказанные в данном пункте. Нам нужно, чтобы клиенту выставлялся счет за все услуга, оказанные во всех пунктах. Мы называем зто консолодорованным счепюм. Этот фрагмент содержит слова «клиент», «пункт» и «услуга». Что означают эти термины т Как они соотносятся друг с другом7 Концептуальная модель предметной области дает начало ответам на эти вопросы и в то же время закладывает основу модели объектов, которая будет позже использоваться в процессе разработки для представления объектов системы.
Я использую термин модель предметной области для определения любой модели, главное назначение которой состоит в описании той части реального мира, в рамках которого создается компьютерная система. Такая модель не зависит от стадии, на которой находится процесс разработки. Заметим, что Рациональный унифицированный процесс определяет термин «модель предметной области» более тщательно. Эта тема детально изложена в книге Джекобсона, Буча и Рамбо, 1999 (231. Я придерживаюсь точки зрения большинства известных мне разработчиков из объектного сообщества. Исследование Для построения модели предметной области особенно полезны следую- щие два метода языка БМЬ.
Основным методом, который я использую для построения моделей предметной области, является диаграмма классов, рассматриваемая с концептуальной точки зрения (см. главу 4). Эти диаграммы могут быть использованы для представления понятий, которые применяют бизнес-аналитики при исследовании соответствующей бизнес-системы, и для представления особенностей объединения этих понятий в единой модели. Во многих случаях именно диаграммы классов определяют некоторый терминологический словарь для описания соответствующей предметной области.
Если предметная область также обладает явно выраженным элементом потока работ, я предпочитаю представлять этот аспект с помощью диаграмм деятельности (см. главу 9). Главной особенностью диаграмм деятельности является их способность изображать параллельные процессы, которые очень важны для исключения ненужных последовательностей в бизнес-процессах. Некоторые разработчики предпочитают пользоваться диаграммами взаимодействия (см. главу 5) для исследования взаимодействия различных ролей в бизнес-системе. Рассматривая совместно исполнителей и деятельности, они приходят к лучшему пониманию соответствующего бизнес-процесса. Лично я предпочитаю использовать диаграммы деятельности для изображения того, что необходимо сделать в первую очередь, а также чтобы определить, кто и что будет делать впоследствии. Моделирование предметной области может оказаться весьма важным дополнением вариантов использования. В процессе выявления и описания вариантов использования я предпочитаю предъявлять их эксперту предметной области и анализировать его реакцию на свое понимание соответствующей бизнес-системы.
При этом целесообразно прибегать к помощи концептуальных диаграмм классов и диаграмм деятельности. В такой ситуации можно обойтись минимумом обозначений, совсем не беспокоясь о строгости и делая на диаграмме множество поясняющих примечаний. Также нет необходимости фиксировать каждую деталь. Вместо этого нужно сосредоточиться на других более важных проблемах и областях предполагаемого риска. Это позволяет изображать множество несвязанных диаграмм, не беспокоясь при этом о согласованности и взаимозависимостях между ними. После рассмотрения большинства существенных вопросов, необходимо объединить различные диаграммы в единую согласованную модель предметной области.
С этой целью я использую одного или двух экспертов предметной области, у которых есть желание поглубже вникнуть в процесс моделирования. На этом этапе важно придерживаться Глава 2. Основы процесса разработки концептуальной точки зрения на проект, но в то же время придать ему большую строгость. После этого построенная модель может быть использована в качестве начального представления для построения классов на фазе построения. Если модель получилась большой, удобно использовать пакеты для разделения модели на составные части, после чего объединить диаграммы классов и деятельности, нарисовав пару диаграмм состояний для тех классов, которые имеют интересные жизненные циклы.
Построенную подобным образом исходную модель предметной области следует рассматривать как базовый остов, а вовсе не как некоторую модель высокого уровня. Термин «модель высокого уровня» означает отсутствие множества деталей. В нескольких ситуациях я уже встречался с подобной ошибкой, состоящей, например, в установке «Не указывайте в данных моделях атрибуты».
В результате получаются совершенно бессодержательные модели. Вполне очевидно, что такие модели вызывают насмешки у разработчиков. Однако вы не можете воспользоваться и прямо противоположным подходом и строить детальную модель. Если вы пойдете по этому пути, потребуются столетия, и вы умрете от «аналитического» паралича. Выход заключается в выявлении наиболее важных деталей и концентрации усилий именно на них. Большинство деталей выявится в ходе итеративной разработки. Именно поэтому я предпочитаю рассматривать подобную модель как базовый остов, который служит фундаментом для последующих моделей. Хотя она и содержит детали, но составляет только небольшую часть нашего проекта.
Естественно, она не скажет вам, как отделить «мясо от костей», именно в этом состоит искусство опытного аналитика, а я пока не разобрался, как это делается. Как только определены варианты использования, они позволят управлять дальнейшим моделированием предметной области. При появлении очередных вариантов использования команда разработчиков должна оценить, содержат ли они нечто такое, что способно оказать сильное влияние на модель предметной области.
Если содержат, то их нужно исследовать и далее, а если нет, то такие варианты использования следует отложить на некоторое время в сторону. Команда, занятая построением модели предметной области, должна представлять собой небольшую группу (от двух до четырех человек), в состав которой входят разработчики и эксперты предметной области. Наименее жизнеспособная команда состоит из одного разработчика и одного эксперта предметной области. Эта команда должна интенсивно работать в течение всей фазы исследования, пока не завершатся все прения относительно атой модели.
В течение этого времени руководитель проекта должен следить за тем, чтобы команда, с одной стороны, не завязла в трясине мелких деталей, Исследование а с другой стороны, не ушла в рассмотрение операций слишком высокого уровня. И то и другое не позволит им твердо стоять ногами на земле. Когда они обретут понимание того, что делают, погружение в детали станет для них самой большой опасностью.
В этом случае задание жесткого срока завершения работы поможет сконцентрировать внимание в нужном направлении. Для понимания требований к системе следует построить прототип для любых составных частей вариантов использования. Построение прототипа (прототипирование, ргоСоСур1пя) — это хороший способ для достижения наилучшего понимания динамики функционирования системы. Я использую построение прототипа всякий раз, когда у меня нет полной уверенности относительно того, каким образом будет функционировать подверженная риску часть системы. Такого прототипа может оказаться вполне достаточно для понимания степени риска и оценки объема работы по его снижению.
Обычно я не строю прототип для картины в целом, а напротив, использую общую модель предметной области, чтобы выделить те ее части, которые требуют построения прототипов. Думаю, что разработчикам, впервые приступающим к использованию языка ПМ1., построение прототипов более необходимо. Это поможет им понять, как диаграммы языка ПМ1 соответствуют современному программированию. Когда вы используете некоторый прототип, не следует ограничиваться только той средой, в которой выполняется разработка конечного продукта. Например, для построения и анализа прототипа я часто использую язык Вта11Са1К даже если разрабатываю программную систему на языке С++.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
