М. Фаулер, К. Скотт - UML Основы (1114905), страница 14
Текст из файла (страница 14)
Конечно, эта терминология не является точной, но обычно считается, что вариант использования системы описывает особенности взаимодействия с программным обеспечением, в то время как вариант использования бизнес-процесса представляет собой реакцию на действие клиента или некоторое событие.
У меня нет особых причин углубляться в рассмотрение этих вопросов. На ранних этапах исследования я больше изучаю варианты использования бизнес-процессов, но думаю, что варианты использования системы являются более полезными для планирования.
По-моему, размышления о вариантах использования бизнес-процесса приносят большую пользу, особенно при рассмотрении альтернативных способов реализации потребностей актеров. В своей работе я вначале концентрирую внимание на вариантах использования бизнес-процесса, после чего перехожу к рассмотрению вариантов использования системы, которые должны обеспечивать выполнение этого бизнес-процесса. В конце этапа исследования я рассчитываю иметь по меньшей мере одно множество вариантов использования системы для каждого из вариантов использования бизнес-процесса. При этом, как минимум, варианты использования бизнес-процесса следует идентифицировать и стараться специфицировать их в первую очередь.
63 Когда следует применять варианты использования Когда следует применять варианты использования Я просто не могу представить себе ситуацию, в которой можно было бы обойтись без вариантов использования. Они являются совершенно необходимым средством при анализе требований, планировании и управлении итеративной разработкой. Работа с вариантами использования является одной из самых важных задач на этапе исследования. Большая часть ваших вариантов использования сформируется на этапе исследования проекта, однако в ходе дальнейшей работы вы можете обнаружить дополнительные особенности.
Имейте это постоянно в виду и не ослабляйте свое внимание. Каждый вариант использования является потенциальным требованием к системе, и пока оно не выявлено, вы не сможете перейти к планированию его реализации. Некоторые разработчики вначале составляют перечень вариантов использования и обсуждают их, после чего приступают к моделированию. По моему мнению, концептуальное моделирование с участием пользователей помогает выявить варианты использования. Поэтому я склонен одновременно работать с вариантами использования и заниматься концептуальным моделированием. Важно помнить, что варианты использования служат внешним представлением системы. Именно поэтому не следует ожидать каких-либо взаимозависимостей между вариантами использования и классами внутри системы. Сколько вариантов использования следует сформировать? В ходе недавнего заседания комиссии ООРЯ1.А некоторые эксперты по вариантам использования утверждали, что для проекта с трудоемкостью 10 человеко-лет необходимо около дюжины вариантов использования.
Но зто только базовые варианты использования; каждый из таких вариантов использования может заключать в себе несколько сценариев и альтернативных вариантов использования. Мне также встречались проекты аналогичной трудоемкости с более чем сотней отдельных вариантов использования. (Если подсчитать количество альтернативных вариантов использования для дюжины базовых вариантов использования, то их общее количество как раз и будет около 100.) Сколько нужно, столько и используйте их в своей работе. Где найти дополнительную информацию Хорошей и небольшой книгой по вариантам использования является книга Шнайдера (ЯсЬпеЫег) и Винтера ( тУ1птегв), 1998 (391. В этом издании рассматриваются еще отношения языка 1)М1, версии 1.1, такие как использование и расширение, но по моему мнению она остается лучшей книгой по работе с вариантами использования.
Следует также б4 Глава 3. Варианты использования рекомендовать сборник работ Алистера Кокберна (А11вЬз1г СосЫЬпгп) в Интернете по адресу: ЬИртбтетЬегв.аойсот/асосЬЬиги. Первая книга Айвара Джекобсона, 1994 1241 послужила толчком для многих других работ, и она по-прежнему остается современной. Сле- дующая книга А. Джекобсона, 1995 1251 также является полезной, по- скольку в ней сделан акцент на вариантах использования бизнес-про- цессов.
Диаграммы классов: основы Диаграмма классов по праву занимает центральное место в объектноориентированном подходе. Фактически любая методология включает в себя некоторую разновидность диаграмм классов. Помимо своего широкого применения диаграммы классов концентрируют в себе большой диапазон понятий моделирования. Хотя их основные элементы используются практически всеми, более сложные понятия применяются не так часто. Именно поэтому я разделил рассмотрение диаграмм классов на две части: основы (данная глава) и дополнительные понятия (см, главу 6).
Диаграмма классов описывает типы объектов системы и различного рода статические отношения, которые существуют между ними. Имеется два основных вида статических отношений: ассоциации (например, клиент может взять напрокат ряд видеокассет); ° подтипы (медсестра является разновидностью личности). На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между объектами. На рис 4.1 изображена типичная диаграмма классов.
Глава 4. Диаграммы классов: основы Крзтнтсть: обвителыяя датаПолучения оплачен номер: Строка цена: Дены.и имя аижс рейтингкредита();Строка вить() ь() отпра закрыт Корпоративный клиент Индивидуальный клиент номерйредитнойКарточки контапиоеИмя рейтингКредита лимитКредита Атрибуты (рейтингКредита() == «низкий! напсмнить() счетЗз Месяц(Целое) Операции .-"" , ...--и« отчет о продавал 0" 'Че -. Крвпюспс необязательнзя количество: Цене цена: Деньги удовлетворен: Булез Товар Рмс. 4.1. Диаграмма классов Особенности представления Перед тем как приступить к описанию диаграмм классов, хотелось бы обратить ваше внимание на одну тонкость, связанную с характером использования этих диаграмм разработчиками. Эта тонкость обычно никак не документируется, однако существенно влияет на способ интерпретации диаграмм и поатому имеет серьезное отношению к тому, что именно вы описываете с помощью модели.
Имя ропн Ч Позиции 1 Обобщение (если Заказ.клиент.рейтингКредита == низкий», то значение Змат.оплачен должно быть истинным) / Особенности представления Следуя сказанному Стивом Куком (Баете Соо)с) и Джоном Дзниелсом (,)о)тп 1)ап1е)в), 1994 113), я утверждаю, что существуют три различные точки зрения на построение диаграмм классов или любой другой модели, однако эти различия в наибольшей степени касаются диаграмм классов: ° Концептуальная точка зрения, Если рассматривать диаграммы классов с концептуальной точки зрения, то они служат для представления понятий изучаемой предметной области.
Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. В действительности, концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать независимо от языка программирования.
(Кук и Дэниелс называют такую точку зрения первичной). ° Точка зрения спецификации. В этом случае мы переходим к рассмотрению программной системы, при этом рассматриваем только ее интерфейсы, но не реализацию. Объектно-ориентированная разработка подчеркивает существенное различие между интерфейсом и реализацией, но на практике оно часто игнорируется, поскольку нотация класса в объектно-ориентированных языках программирования объединяет в себе как интерфейс, так и реализацию. Это весьма досадно, поскольку ключевым фактором эффективного объектно-ориентированного программирования является программирование именно интерфейса класса, а не его реализации. Это хорошо описано в первой главе книги Гаммы и др., 1995 ~20].
Вы часто слышите слово «тип», когда речь идет об интерфейсе класса; тип может иметь несколько классов, которые его реализуют, а класс может реализовывать несколько типов. ° Точка зрения реализации. С этой точки зрения мы действительно имеем дело с классами, опустившись на уровень реализации. Эта точка зрения, вероятно, встречается наиболее часто, однако во многих ситуациях точка зрения спецификации является более предпочтительной для аналитика.
Понимание точки зрения разработчика крайне важно как для построения, так и для чтения диаграмм классов. К сожалению, различия между отмеченными особенностями представления не столь отчетливы, и большинство разработчиков при построении диаграмм смешивают различные точки зрения. Я полагаю, что часто не имеет большого значения различие между концептуальной точкой зрения и точкой зрения спецификации, и гораздо важнее различать особенности представления с точки зрения спецификации и реализации.
В дальнейшем при рассмотрении диаграмм классов я постараюсь подчеркнуть, насколько сильно каждый элемент диаграммы зависит от точки зрения. 68 Глава 4. Диаграммы классов: основы Особенности представления диаграмм классов не являются частью формального описания языка ()МЬ, однако я пришел к выводу, что они являются исключительно важными при построении и анализе моделей. Язык 1)МЬ можно использовать с любой из этих точек зрения.
Вы можете явно указать особенность представления, снабдив класс стереотипом (см. главу 6). Можно также пометить класс как «класс реализации», чтобы явно указать на точку зрения реализации, или пометить его как «тип» для концептуальной точки зрения и точки зрения спецификации. Ассоциации На рис. 4.1 изображена простая диаграмма классов, понятная каждому, кто имел дело с обработкой заказов клиентов. Рассмотрим каждый фрагмент этой диаграммы и укажем их возможную интерпретацию с различных точек зрения. Начнем с ассоциаций. Ассоциации представляют собой отношения между экземплярами классов (сотрудник работает в компании, компания имеет несколько офисов). С концептуальной точки зрения ассоциации представляют концептуальные отношения между классами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
