Конспект лекций, страница 11

Косновным документам, регламентируемым технологией Rational Unified Process,относятся: Концепция – определяет глобальные цели проекта и основные особенностиразрабатываемой системы. Существенной частью концепции является постановказадачи разработки, определяющая требования к выполняемым системой функциям. Словарь предметной области (глоссарий) – определяет общую терминологию для всехмоделей и описаний требований к системе.

Глоссарий предназначен для описаниятерминологии предметной области и может быть использован как словарь данныхсистемы. Дополнительные спецификации (технические требования) – содержит описаниенефункциональных требований к системе, таких, как надежность, удобствоиспользования, производительность, сопровождаемость и др.Функциональные требования к системе моделируются и документируются спомощью вариантов использования (use case). Вариант использования (use case) – связныйэлемент функциональности, предоставляемый системой при взаимодействии сдействующими лицами. Действующее лицо (actor) – роль, обобщение элементов внешнегоокружения системы, ведущих себя по отношению к системе одинаковым образом.В контексте процесса управления требованиями варианты использованиятрактуются следующим образом: вариант использования фиксирует соглашение между участниками проектаотносительно поведения системы; вариант использования описывает поведение системы при различных условиях, когдасистема отвечает на запрос одного из участников, называемого основнымдействующим лицом; основное действующее лицо инициирует взаимодействие с системой, чтобы добитьсянекоторой цели.

Система отвечает, соблюдая интересы всех участников.Варианты использования – это вид документации, применяемый, когда требуетсясконцентрировать усилия на обсуждении принципиальных требований к разрабатываемойсистеме, а не на подробном их описании.Стиль их написания зависит от масштаба, количества участников и критичностипроекта. Формат описания варианта использования: Имя – цель в виде краткой активной глагольной фразы Контекст использования – более длинное описание цели Область действия Основное действующее лицо Участники и интересы2Предусловие (определяет, выполнение какого условия гарантирует система перед тем,как разрешить запуск варианта использования) Минимальные гарантии (наименьшие обещания системы участникам, в частности,когда цель основного действующего лица не может быть достигнута) Гарантии успеха (или постусловие – postcondition – устанавливает, что интересыучастников удовлетворяются по успешном завершении варианта использования вконце основного сценария) Триггер (событие, которое запускает вариант использования) Основной сценарий (простой для понимания типичный сценарий, в которомдостигается цель основного действующего лица и удовлетворяются интересы всехучастников) Расширения (запускаются при возникновении определенного условия, содержатпоследовательность шагов, описывающих, что происходит при этом условии, изаканчивается достижением цели или отказом от неё) Список изменений в технологии и данных Вспомогательная информацияСуществуют четыре уровня точности (при описании вариантов использования,расположенные по степени повышения точности): Действующие лица и цели (перечисляются действующие лица и все их цели, которыебудет обеспечивать система).

На этом уровне определяется границы системы, контекств котором она работает. Действующее лицо может: быть активным, посылая запросы всистему; быть пассивным, получая данные от системы. Его роль может исполнятьчеловек – пользователь, устройство, внешняя программная система, время (в случаеесли функциональность запускается по расписанию), температура или другое свойствосостояния окружающей среды, играющее роль триггера. Краткое изложение варианта использования (в один абзац) или основной потоксобытий (без анализа возможных ошибок). Условия отказа (анализ мест возникновения возможных ошибок в основном потокесобытий). Обработка отказа (написание альтернативных потоков событий).Введение перечисленных уровней преследует своей целью грамотное планированиеи экономию времени разработки. В итерационном цикле создания системы не следуетпытаться за один прием подробно описать все требования, их нужно постепенно уточнять,повышая уровень точности.

Выбор первоочередных вариантов использования дляуточнения определяется их приоритетами. Факторами ранжирования вариантовиспользования (и вообще всех требований) по приоритетам являются:• существенное влияние на архитектуру системы;• рискованные, сложные для реализации или срочные функции;• применение новой, неапробированной технологии;• значимость в экономических процессах.Правила написания сценариев:1) Используйте простые предложения: Подлежащее...сказуемое...прямое дополнение...предложный оборот (Система...удерживает...сумму...из остатка на счёте).2) Ясно укажите, кто «владеет мячом». На каждом шаге одно из действующих лиц"владеет мячом" – сообщением и данными, которые одно действующее лицо передаётдругому.3) Пишите, глядя на вариант использования с точки зрения пользователя, а не системы.4) Не показывайте слишком незначительные, мелкие действия.Виды альтернативных сценариев: Некорректное действие действующего лица (ввод неверного пароля). Бездействие основного действующего лица (истечение времени ожидания пароля).3Предложение "система подтверждает" связано с обработкой неподтверждения(неверный учётный номер).Несоответствующая реакция второстепенного действующего лица или её отсутствие(истечение времени ожидания ответа).Внутренняя ошибка в разрабатываемой системе, которая должна быть обнаружена иобработана в обычном порядке (заблокирован автомат для выдачи наличных).Неожиданная и необычная ошибка, которую необходимо обработать (обнаруженоповреждение журнала транзакций).Критически важные недостатки в производительности системы (время реакции неукладывается в 5 секунд).Писать варианты использования следует с позиции пользователя, т.

е.:GUIGUIлогикаМАГИЯданныеТипичные ошибки в сценариях: Отсутствует система. Отсутствует основное действующее лицо. Слишком много деталей пользовательского интерфейса. Слишком низкий (подробный) уровень описания.Связи между вариантами использования и действующими лицами отображаются надиаграмме вариантов использования:ПеревестиденьгиИзменитьидентификационныйномерСделатьвкладКлиентОсуществитьоплатуСнять деньгисо счетаКредитная системаПоказатьбалансПравила составления этих диаграмм:1) Каждый вариант использования должен быть инициирован действующим лицом.42) Не моделируйте связи между действующими лицами.3) Не соединяйте стрелкой два варианта использования непосредственно. Диаграммыданного типа описывают только, какие варианты использования доступны системе, ане порядок их выполнения. На диаграммах варианты использования могут бытьсвязаны либо зависимостями (связями включения или расширения) или обобщением(наследованием).

Для отображения порядка выполнения вариантов использованияприменяют диаграммы деятельности.4) Избегайте многочисленных и запутанных связей между действующими лицами ивариантами использования.Для снижения сложности начальная модель вариантов использования может бытьподвергнута структуризации, в ходе которой выделяются вспомогательные вариантыиспользования (включаемые или расширяющие). Сложность снижается за счет вынесениячасти описаний из основного варианта использования во включаемый (который можетбыть включен в несколько ВИ, что еще больше упрощает модель) или расширяющий.Выполнить<<extend>>ускоренноеснятие денегСнять деньгиКлиентсо счета<<include>>АутентифицироватьклиентаИнструментом структуризации также является обобщение вариантов использования.Снять деньгиКлиентВыполнитьтранзакциюПеревести деньгиВнести деньгиПри обобщении в базовый ВИ выносится описание общее для всех наследников,дочерние ВИ специализируют описание базового, они участвуют во всех связяхрасширения и/или включения базового.

Обобщение может быть использовано и длядействующих лиц. В таком случае дочерние действующие лика наследуют связикоммуникации родительского действующего лица.Методика моделирования вариантов использования в технологии Rational UnifiedProcess предусматривает специальное соглашение, связанное с группировкой структурныхэлементов и диаграмм модели. Это соглашение включает следующие правила:• Все действующие лица, варианты использования и диаграммы вариантовиспользования помещаются в пакет с именем Use Case Model.• Если моделируется сложная многофункциональная система, то совокупность всехдействующих лиц и вариантов использования может разделяться на пакеты.

В качествепринципов разделения могут использоваться: структуризации модели в соответствии с типами пользователей (действующих лиц); функциональная декомпозиция; разделение модели на пакеты между группами разработчиков (в качестве объектов5управления конфигурацией).Дисциплина определения требований в рамках RUP описывается следующимнабором ролей и деятельностей:Написание Выявление нуждконцепции заинтересованныхлицСистемныйаналитикУправлениезависимостямиСоставлениеглоссарияСтруктурированиеUse-Case ModelРецензентпо требованиямОписаниеUse CaseUse-CaseписательРецензированиетребованийМоделирование ПрототипированиеUIUIРазработчик UIАрхитекторПоиск акторови вариантовиспользованияРасстановка приоритетовUse CaseНаборы рабочих продуктов определения требований:Use-CaseписательСистемныйаналитикотвечает заUse-CaseНуждыModelзаинтересованныхлицКонцепцияотвечает заДополнительная Глоссарий АтрибутытребованийспецификацияРазработчикUIАрхитекторотвечает заОписание архитектурыUse Case Use-Case Packageотвечает заUse-CaseраскадровкиUser-InterfaceпрототипыГраничныеклассыСпецификация требований в технологии Rational Unified Process не требуетобязательного моделирования бизнес-процессов организации, для которых создается ПО,однако, наличие бизнес-моделей существенно упрощает построение системной моделивариантов использования.