Инкапсуляцией
 Скачать 0.92 Mb.
|
|
Создание диаграмм Вариантов Использования В среде Rose диаграммы Вариантов Использования создаются в представлении Вариантов Использования. Главная диаграмма (Main) предлагается вам по умолчанию. Для моделирования системы можно разработать столько дополнительных диаграмм, сколько нужно. Для получения доступа к Главной диаграмме Вариантов Использования:
Для создания новой диаграммы Вариантов Использования:
Связывание файлов и ссылок с диаграммой Вариантов Использования В среде Rose вы можете прикрепить к диаграмме Вариантов Использования файл или адрес Интернета (URL). Например, таким образом можно связать с диаграммой любой вспомогательный документ, например спецификации требований высокого уровня, документы концептуального характера или даже проектный план. Все связанные файлы и ссылки будут показаны в браузере под соответствующей диаграммой Вариантов Использования. По двойному щелчку мыши на файле или ссылке в браузере откроется соответствующее приложение и загрузится ваш документ, находящийся в файле или по указанному адресу Интернета. Для прикрепления файла к диаграмме Вариантов Использования:
Панель инструментов диаграмм Вариантов Использования Когда открывается диаграмма Вариантов Использования, на панели инструментов диаграммы появляются соответствующие пиктограммы. Описание некоторых кнопок панели приведено в таблице 3.1. Далее рассматривается применение этих кнопок для создания вариантов использования, действующих лиц и других элементов ваших диаграмм.   Работа с вариантами использования Вариант использования — это описание на "высоком уровне" фрагмента функциональности, которую обеспечивает система. Иначе говоря, вариант использования иллюстрирует, как можно использовать систему. Например, автоматический банкомат (ATM) предоставляет клиенту некоторый базовый набор функциональных возможностей. Он позволяет снимать деньги, делать вклад, переводить деньги с одного счета на другой, просматривать свой баланс, изменять идентификационный номер или производить оплату по безналичному расчет) с кредитной карточки. Каждая из описанных транзакций является способом, которым клиент может использовать систему. Таким образом, каждый из них — это самостоятельный вариант использования. На языке UML вариант использования изображают следующим образом:  Преимущество вариантов использования заключается в том, что можно отделить реализацию системы от описания ее принципиальных основ. Они позволяют заострить внимание на наиболее важных вещах — удовлетворении потребностей и ожиданий заказчиков — без необходимости углубления в детали реализации. Взглянув на варианты использования, пользователь сможет понять, что будет делать система, и обсудить сферу ее применения в самом начале работы над проектом. Варианты использования предлагают подход, отличающийся от традиционных методов. Разделение проекта на варианты использования является таким способом изучения системы, который ориентирован на сам процесс, а не на его реализацию. Если при использовании функциональной декомпозиции задача заключается в последовательном разбиении проблемы на небольшие фрагменты, с которыми будет работать готовая система, то подход вариантов использования сосредоточен прежде всего на том, что ожидает от системы пользователь. В начале работы над проектом возникает естественный вопрос: "Как обнаружить варианты использования?" Лучше всего внимательно прочитать документацию заказчика. Часто помогает также рассмотрение области использования системы на высоком уровне и документов концептуального характера. Учтите мнение каждого из заинтересованных лиц проекта. Подумайте, чего они ожидают от готового продукта. Каждому заинтересованному лицу можно задать следующие вопросы:
Как уже упоминалось ранее, варианты использования — это не зависящее от реализации высокоуровневое представление того, что пользователь ожидает от системы. Рассмотрим каждый фрагмент этого определения по отдельности. Прежде всего варианты использования не зависят от реализации. Представьте себе, что вы пишете руководство по работе с системой. Необходимо, чтобы ваши варианты использования можно было реализовать на языках Java, C++, Visual Basic или на бумаге. Варианты использования заостряют внимание на том, что должна делать система, а не на том, как она должна это делать. Проблемы реализации вариантов использования описываются ниже. Варианты использования — это высокоуровневое представление системы. Если, например, в вашей модели содержится 3000 вариантов использования, вы теряете преимущество простоты. Создаваемый вами набор вариантов использования должен предоставить пользователям возможность увидеть всю систему целиком на самом высоком уровне. Поэтому вариантов использования не должно быть слишком много, чтобы клиенту не пришлось долго блуждать по страницам документации с целью выяснения того, что будет делать система. В то же время вариантов использования должно быть достаточно для полного описания поведения системы. Модель типичной системы обычно содержит от 20 до 50 вариантов использования. Для разбиения вариантов использования на части применяются связи различных типов, так называемые связи использования и расширения. Для лучшей организации системы можно также формировать группы вариантов использования, объединяя их в пакеты (см. ниже). Наконец, варианты использования заостряют внимание на том, что пользователи хотят получить от системы. Каждый вариант использования должен представлять собой завершенную транзакцию между пользователем и системой. Названия вариантов использования должны быть деловыми, а не техническими терминами. В рассматриваемом нами примере ATM нельзя назвать вариант использования "Интерфейс с банковской системой, осуществляющий перевод денег с кредитной карточки и наоборот". Вместо этого лучше дать название "Оплатить по карточке" — так будет понятнее для заказчика. Варианты использования обычно называют глаголами или глагольными фразами, описывая при этом, что пользователь видит как конечный результат процесса. Его не интересует, сколько других систем задействовано в варианте использования, какие конкретные шаги надо предпринять и сколько строчек кода требуется написать, чтобы заплатить по счету карточкой Visa. Для него важно только, чтобы оплата была произведена. Еще раз повторим, вы должны заострить внимание на результате, который потребитель ожидает от системы, а не на действиях, которые нужно предпринять для достижения этого результата. Но как убедиться, что вы обнаружили все варианты использования? Для этого следует ответить на вопросы:
Документирование потока событий Варианты использования начинают описывать, что должна будет делать ваша система. Но чтобы фактически разработать систему, потребуются более конкретные детали. Они определяются в документе, называемом "потоком событий" (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы и что — сама система. Поток событий также не должен зависеть от реализации. Составляя этот документ, представьте себе, что создается автоматизированная система. Однако на данном этапе вас еще не должно волновать, будет ли она написана на языке C++, PowerBuilder или Java. Ваша цель — описать, что будет делать система, а не как она будет это делать. Обычно поток событий содержит:
Рассмотрим последовательно эти составные части. Описание Каждый вариант использования должен иметь связанное с ним короткое описание того, что он будет делать. Например, вариант использования "Перевести деньги" системы ATM может содержать следующее описание: Вариант использования "Перевести деньги" позволяет клиенту или служащему банка переводить деньги с одного счета до востребования или сберегательного счета на другой. Следует делать описание коротким и "к месту", при этом оно должно определять типы пользователей, выполняющих вариант использования, и ожидаемый ими конечный результат. Во время работы над проектом (особенно, если проект длинный) эти описания будут напоминать членам команды, почему тот или иной вариант использования был включен в проект и что он должен делать. Четко документируя таким образом цели каждого варианта использования, можно уменьшить неразбериху, возникающую среди разработчиков. Предусловия Предусловия варианта использования — это такие условия, которые должны быть выполнены, прежде чем вариант использования начнет свою работу. Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска данного варианта использования. Не у всех вариантов использования бывают предварительные условия. Ранее мы упоминали, что диаграммы Вариантов Использования не должны отражать порядок их выполнения. Однако с помощью предусловий можно документировать и такую информацию. Например, предусловием одного варианта использования может быть то, что в это время должен выполняться другой. Основной и альтернативный потоки событий Конкретные детали вариантов использования отражаются в основном в альтернативном потоках событий. Поток событий поэтапно описывает, что должно происходить во время выполнения заложенной в варианты использования функциональности. Поток событий уделяет внимание тому, что (а не как) будет делать система, причем описывает это с точки зрения пользователя. Первичный и альтернативный потоки событий содержат:
Например, поток событий варианта использования "Снять деньги" может выглядеть следующим образом: Основной поток
Альтернативный поток А1: ввод неправильного идентификационного номера
Альтернативный поток А2: недостаточно денег на счету
Поток ошибок Е1: ошибка в подтверждении запрашиваемой суммы
Документируя поток событий, можно использовать нумерованные списки (как это сделано в данном примере), ненумерованные списки, разбитый на параграфы текст и даже блок-схемы. Поток событий должен быть согласован с определенными ранее требованиями. Описывая поток, помните о тех, кто будет читать ваш документ. При его изучении заказчики будут проверять, соответствует ли он их ожиданиям, а аналитики — соответствует ли он требованиям к системе. Менеджер проекта захочет лучше понять, что же будет создано, а также сделать или обновить оценки проекта. Работая над потоком, избегайте детальных обсуждений того, как он будет реализован. Уделяйте внимание обмену информацией между пользователями и системой, но не подробному описанию ее реализации. Постусловия Постусловиями называются такие условия, которые должны быть выполнены после завершения варианта использования. Работа с действующими лицами Действующее лицо (actor) — это то, что взаимодействует с создаваемой системой. Если варианты использования описывают все, что происходит внутри области действия системы, действующие лица определяют все, что находится вне ее. На языке UML действующие лица представляют в виде фигур:  Действующие лица делятся на три основных типа: пользователи системы, другие системы, взаимодействующие с данной и время.
Поместить действующее лицо на диаграмму Вариантов Использования можно следующим образом:
Как и варианты использования, каждое действующее лицо в Rose имеет подробные спецификации. В окне спецификации действующего лица вы можете определить его имя, стереотип, количество экземпляров (множественность — cardinality) и другие детали. Назначение стереотипа для действующего лица Как и в случае вариантов использования, для действующего лица в окне его спецификации может быть определен стереотип. Если вы измените существующий стереотип действующего лица, Rose автоматически изменит и пиктограмму, представляющую действующее лицо на диаграмме Вариантов Использования. Вместо символа действующего лица будет использован стандартный прямоугольник, такой же, что и для класса. Для действующего лица не поставляется никаких других стереотипов, кроме стереотипа Actor (Действующее лицо). Однако вы всегда можете определить свои собственные стереотипы и использовать их в ваших моделях. Для назначения действующему лицу стереотипа:
Задание множественности действующего лица В среде Rose можно указать, сколько экземпляров конкретного действующего лица будет использоваться. Например, существует множество людей, играющих роль действующего лица-клиента, но только один человек, играющий роль действующего лица-менеджера. Чтобы зафиксировать этот факт, можно использовать поле Cardinality (Множественность) окна спецификации. Создание абстрактного действующего лица Абстрактным называется действующее лицо, не имеющее экземпляров. Иными словами, его множественность равна нулю. Например, у вас может быть несколько действующих лиц: служащий с почасовой оплатой, служащий с окладом и служащий, нанятый на определенное время. Все они являются разновидностями четвертого действующего лица — служащего. Однако никто в компании не является просто служащим — каждый относится к одному из трех вышеназванных типов. Действующее лицо "Служащий1' существует только для того, чтобы показать общность между этими тремя типами. У него нет экземпляров, так что это абстрактное действующее лицо. Пример абстрактного действующего лица приведен на рис.  Подробное описание того, как рисовать стрелки между действующими лицами, приводится ниже. Для создания абстрактного действующего лица:
Работа со связями В языке UML для вариантов использования и действующих лиц поддерживается несколько типов связей. Это связи коммуникации (communication), использования (uses), расширения (extends) и обобщения действующего лица (actor generalization). Связи коммуникации описывают связи между действующими лицами и вариантами использования. Связи использования и расширения отражают связи между вариантами использования, а связи обобщения действующего лица — между действующими лицами. Связи коммуникации Связь коммуникации (communicates relationship) — это связь между вующим лицом. На языке UML связь коммуникации изображают  Направление стрелки показывает, кто инициирует коммуникацию. В приведенном выше примере действующее лицо Клиент инициирует коммуникацию с системой для запуска функции "Снять деньги". Вариант использования также может инициировать коммуникацию с действующим лицом:  В данном примере вариант использования инициирует коммуникацию с действующим лицом Кредитная система. Когда выполняется вариант использования "Произвести оплату", система ATM инициирует коммуникацию с Кредитной системой, чтобы завершить транзакцию. Информация при этом движется в обоих направлениях: от ATM к Кредитной системе и обратно; стрелка показывает только, кто инициирует коммуникацию. Каждый вариант использования должен быть инициирован действующим лицом; исключения составляют лишь варианты использования в связях использования и расширения. Для добавления связи коммуникации:
Для удаления связи коммуникации:
Связь использования Связь использования (uses relationship) позволяет одному варианту использования задействовать функциональность другого. С помощью таких связей обычно моделируют многократно применяемую функциональность, встречающуюся в двух или более вариантах использования.  Связь расширения Связь расширения (extends relationship) позволяет варианту использования только при необходимости применять функциональные возможности, предоставляемые другим вариантом использования. Она напоминает связь использования. В обоих типах отношений некоторая общая функциональность выделяется в отдельный вариант использования.  Связь обобщения действующего лица С помощью связи обобщения действующего лица (actor generalization relationship) показывают, что у нескольких действующих лиц имеются общие черты. Например, ваши клиенты могут быть двух типов корпоративные и индивидуальные. Это отношение моделируется с помощью нотации, представленной на рис.  Работа с примечаниями При работе над диаграммой имеет смысл связывать примечания (notes) с действующими лицами и вариантами использования. Например, иногда нужно пояснить, почему конкретное действующее лицо взаимодействует с конкретным вариантом использования, почему вариант использования участвует в связях использования или расширения или почему одно действующее лицо наследует от другого. Добавление примечаний в Rose выполняется с помощью кнопки Note (Примечание) панели инструментов. Добавление примечаний на диаграмму На диаграмму можно поместить примечания двух типов: собственно примечания (notes) и текстовую область (text box). В общем случае, примечания позволяют добавить комментарий к какому-то одному элементу диаграммы, а текстовая область содержит сведения, общие для всей диаграммы, например ее имя. Поместить на диаграмму примечание можно следующим образом:
 Работа с пакетами На языке UML такие элементы, как действующие лица, варианты использования, классы и компоненты, можно сгруппировать в пакеты (packages). В частности, в представлении Вариантов Использования можно сгруппировать в пакеты варианты использования и действующих лиц. На языке UML пакет изображается следующим образом:  Создание пакетов Для упорядочения элементов модели в среде Rose можно создавать столько пакетов, сколько нужно. При необходимости, для лучшей организации разрешается помещать один пакет внутрь другого. При создании нового пакета Rose автоматически создает диаграмму Package Overview (Обзор пакета) и список ассоциаций (Associations list). Для добавления пакета на диаграмму:
|
