UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• второстепенных актеров – взаимодействуют с прецедентом после его инициации. • предусловия – ограничения системы, которые оказывают влия ние на выполнение прецедента; • основной поток – последовательность декларативных, упорядо ченных во времени шагов прецедента; • постусловия – ограничения системы, возникающие в результате выполнения прецедента; • альтернативные потоки – список альтернатив основному потоку. • Можно сократить число прецедентов, позволив ограниченное коли чество ветвлений в рамках основного потока событий. Для этого: • применяйте ключевое слово Если (If) для ветвлений, возникаю щих на конкретных шагах потока; • ветвления, которые могут возникнуть на любом шаге основного потока, помещайте в секцию Альтернативный поток в описании пре цедента. • Повторения в рамках потока можно показать с помощью ключевых слов: • Для (выражение, описывающее итерации); • Пока (логическое условие). • У каждого прецедента есть один основной поток – «идеальный» сценарий, когда все идет так, как запланировано. • Более сложные прецеденты могут иметь один или более альтерна тивных потоков. Это пути в прецеденте, представляющие исключе ния, ответвления и прерывания. • Ключевые альтернативные потоки выявляются путем анализа ос новного потока и поиска: • альтернатив; • ситуаций, связанных с появлением ошибки; • прерываний. • Прецедент необходимо расщеплять на альтернативные потоки, только если это повышает ценность модели. • Требования в модели требований могут быть сопоставлены с преце дентами при помощи матрицы отображаемости требований. 118 Глава 4. Моделирование прецедентов • Моделирование прецедентов лучше всего подходит для систем, в ко торых: • преобладают функциональные требования; • много типов пользователей; • много интерфейсов для взаимодействия с другими системами. • Моделирование прецедентов меньше подходит для систем, в кото рых: • преобладают нефункциональные требования; • мало пользователей; • мало интерфейсов. 5 Дополнительные аспекты моделирования прецедентов 5.1. План главы В настоящей главе рассматриваются некоторые дополнительные аспек ты моделирования прецедентов. И в завершение приводятся несколько советов и рекомендаций. Мы обсудим отношения, которые могут возникать между актерами и актерами и между прецедентами и прецедентами. К ним относятся: • обобщение актеров – отношение обобщения между обобщенным ак тером и конкретным актером; • обобщение прецедентов – отношение обобщения между обобщен ным прецедентом и специализированным прецедентом; • «include» (включить) – отношение между прецедентами, которое по зволяет одному прецеденту включать в себя поведение другого; • «extend» (расширить) – отношение между прецедентами, которое позволяет одному прецеденту расширять свое поведение одним или более фрагментами поведения другого. Важно сохранять максимальную простоту модели, поэтому эти отно шения надо применять аккуратно и только там, где они действительно делают модель прецедентов более понятной. Можно легко увлечься «include» и «extend», но необходимо избегать этого. 5.2. Обобщение актеров В примере на рис. 5.2 между двумя актерами, Customer (клиент) и Sales Agent (торговый агент), можно найти много общего в том, как они взаи модействуют с системой Sales (товарооборот) (здесь SalesAgent может управлять куплей продажей от имени Customer). Оба актера иницииру ют прецеденты ListProducts (представить список продуктов), OrderProducts 120 Глава 5. Дополнительные аспекты моделирования прецедентов 5.8. Что мы узнали изучаем отношение «extend» изучаем обобщение актеров изучаем обобщение прецедентов изучаем отношение «include» 5.2. Обобщение актеров 5.3. Обобщение прецедентов 5.4. Отношение «i n clude» 5.5. Отношение «exte n d» 5.5.1. Расширяющий прецедент 5.5.2. Несколько сегментов вставки 5.5.3. Условные расширения 5.6. Когда использовать дополнительные возможности 5.7. Советы и рекомендации по написанию прецедентов 5.7.1. Делать прецеденты короткими и простыми 5.7.2. Фокусироваться на том что, а не как 5.7.3. Избегать функциональной декомпози ции Ри с. 5 .1. Пл ан гл ав ы 5.2. Обобщение актеров 121 (заказать продукты) и AcceptPayment (принять платеж). По сути, един ственное отличие между ними в том, что SalesAgent может иницииро вать прецедент CalculateCommission (вычислить комиссию). Кроме того, из за сходства поведения этих актеров на диаграмме возникает масса пересекающихся линий. Это указывает на наличие некоего общего по ведения, которое может быть вынесено и представлено в виде более обобщенного актера. Обобщение актеров выносит поведение, общее для двух или более акте ров, в актера родителя. Общее поведение можно вынести путем обобщения актеров (рис. 5.3). Тем самым мы создаем абстрактного актера, называемого Purchaser (по купатель), который взаимодействует с прецедентами ListProducts, Order Products и AcceptPayment. Customer и SalesAgent – это конкретные актеры, потому что данные роли могут выполнять реальные люди (или другие системы). Purchaser – абстрактный актер, поскольку он является аб стракцией, введенной просто для представления общего поведения (возможности делать покупки) двух конкретных актеров. Customer и SalesAgent наследуют все роли и отношения с прецедентами своего абстрактного родителя. Таким образом, как видно из рис. 5.3, и Customer, и SalesAgent взаимодействуют с прецедентами ListProducts, Or derProducts и AcceptPayment. Они наследуют это от своего родителя, Pur chaser. Кроме того, SalesAgent взаимодействует с прецедентом Calculate Commission. Это поведение не является унаследованным, оно характер но для актера SalesAgent. Как видим, разумное использование абстракт ных актеров может упростить диаграмму прецедентов. Это также упрощает семантику модели прецедентов, потому что появляется воз можность интерпретировать разные вещи одинаково. Следует отметить, что актер родитель в обобщении актеров не всегда абстрактен. Это может быть конкретная роль, исполняемая человеком OrderProducts ListProducts Система Sales AcceptPayment CalculateCommission Customer SalesAgent Рис. 5.2. Пример двух актеров с общим поведением 122 Глава 5. Дополнительные аспекты моделирования прецедентов или системой. Однако хорошим стилем считается делать актера роди теля абстрактным для сохранения простоты семантики обобщения. Актер потомок может использоваться везде, где ожидается актер предок. Мы увидели, что если два актера одинаково общаются с одним и тем же набором прецедентов, их можно обобщить в другом (возможно, аб страктном) актере. Актеры потомки наследуют роли и отношения с пре цедентами от актера родителя. Актер потомок может использоваться вместо актера предка. Это принцип замещаемости, с помощью которо го можно проверить правильность использования обобщения для лю бого классификатора. В данном примере SalesAgent или Customer могут использоваться вместо P urchaser везде (т. е. взаимодействовать с прецедентами ListProducts, Or derProducts и AcceptPayment). Таким образом, обобщение актеров являет ся правильной стратегией. 5.3. Обобщение прецедентов Обобщение прецедентов используется, если есть один или более преце дентов, которые на самом деле являются специализациями более об щего прецедента. Как и обобщение актеров, этот прием следует приме нять, только если он упрощает модель прецедентов. Обобщение прецедентов выносит поведение, общее для одного или бо лее прецедентов, в родительский прецедент. Система Sales Purchaser SalesAgent Customer предок или родитель потомки или дети Упрощать можно с помощью обобщения актеров! обобщение абстрактный актер ListProducts OrderProducts AcceptPayment CalculateCommission Рис. 5.3. Общее поведение вынесено в актера родителя 5.3. Обобщение прецедентов 123 В обобщении прецедентов дочерние прецеденты представляют более специализированные формы их родителей. Потомки могут: • наследовать возможности родительского прецедента; • вводить новые возможности; • переопределять (менять) унаследованные возможности. Дочерний прецедент автоматически наследует все возможности своего родителя. Однако не все возможности прецедента могут быть переоп ределены. Ограничения приведены в табл. 5.1. Таблица 5.1 В UML 1.5 прецеденты имели атрибуты и операции, в UML 2 их нет. Фактически атрибуты и операции прецедентов не имели особого зна чения, они редко использовались и редко поддерживались инструмен тальными средствами UML. Согласно спецификации UML 1.5, опера ции прецедента даже не могли быть запрошены извне, поэтому трудно представить, зачем они вообще были нужны. Итак, как же осуществляется документирование обобщения прецеден тов в описаниях прецедентов? Спецификация UML по этому поводу безмолвствует. Однако существует несколько довольно стандартных методов. Мы предпочитаем использовать простой язык тегов для обо значения пяти возможностей в дочернем прецеденте. Есть два правила применения этого метода: • Каждый номер шага в потомке сопровождается номером эквива лентного шага родителя, если таковой имеется. Например: 1. (2.). Некоторый шаг. • Если шаг потомка переопределяет шаг родителя, его номер сопро вождается буквой «o» (что значит overridden – переопределенный) и родительским номером шага. Например: 6. (o6.) Другой шаг. В табл. 5.2 представлен синтаксис всех пяти возможных вариантов. На рис. 5.4 показан фрагмент диаграммы прецедентов системы Sales. Здесь есть родительский прецедент FindProduct (найти продукт) и две его специализации: FindBook (найти книгу) и FindCD (найти CD). На рис. 5.5 показано описание родительского прецедента FindProduct. Обратите внимание на ее очень высокий уровень абстракции. Возможность прецедента Наследование Добавление Переопределение Отношение Да Да Нет Точка расширения Да Да Нет Предусловие Да Да Да Постусловие Да Да Да Шаг основного потока Да Да Да Альтернативный поток Да Да Да 124 Глава 5. Дополнительные аспекты моделирования прецедентов Таблица 5.2 Возможность… Пример обозначения Унаследована без изменений 3. (3.) Покупатель вводит запрашиваемый критерий. Унаследована и перенумерована 6.2. (6.1.) Система сообщает Покупателю, что соответствующие продукты не найдены. Унаследована и переопределена 1. (о1.) Покупатель выбирает опцию «найти книгу». Унаследована, переопределена и перенумерована 5.2. (о5.1.) Система выводит на экран стра ницу с данными максимум пяти книг. Добавлена 6.3. Система повторно выводит на экран страницу поиска «найти книгу». Система Sales FindProduct FindBook FindCD Customer Рис. 5.4. Фрагмент диаграммы прецедентов системы Sales Прецедент: FindProduct Главные актеры: Customer Предусловия: Нет. Постусловия: Нет. Основной поток: 1. Customer выбирает опцию «найти продукт». 2. Система запрашивает у Customer критерий поиска. 3. Customer вводит запрашиваемый критерий. 4. Система ищет продукты, соответствующие критерию от Customer. 5. Если система находит соответствующие продукты 5.1. Система выводит на экран список соответствующих продуктов. 6. Иначе 6.1. Система сообщает Customer о том, что соответствующие продукты не найдены. ID: 6 Краткое описание: Customer ищет продукт. Альтернативные потоки: Нет. Второстепенные актеры: Нет. Рис. 5.5. Описание родительского прецедента FindProduct 5.3. Обобщение прецедентов 125 Один из дочерних прецедентов, FindBook, показан на рис. 5.6. Здесь де монстрируется применение нашего стандарта обозначения переопре деленных или новых возможностей. Как видно из рис. 5.6, дочерний прецедент FindBook намного более конкретный. В нем более абстракт ный родитель специализирован для работы с конкретным типом про дуктов – книгами. Если в родительском прецеденте нет потока событий или поток событий не завершен, это абстрактный прецедент. Абстрактные прецеденты до вольно широко распространены, потому что могут использоваться для описания поведения на самых высоких уровнях абстракции. Посколь ку в абстрактных прецедентах поток событий отсутствует или является неполным, они не могут быть выполнены системой. Вместо потока со бытий в абстрактных прецедентах используется простое высокоуровне вое текстовое описание поведения, которое должны реализовать их по томки. Это описание можно поместить в раздел «Краткое описание». Как мы уже видели, унаследованные возможности в дочерних преце дентах показать сложно. Приходится применять определенный язык тегов или соглашение об обозначениях, что обычно сбивает с толку за переопределенный переопределенный унаследованный без изменений переопределенный переопределенный добавленный переопределенный и перенумерованный добавленный добавленный унаследованный без изменений добавленный перенумерованный Прецедент: FindBook Главные актеры: Customer Предусловия: Нет. Постусловия: Нет. Основной поток: 1. (o1.) Customer выбирает опцию «найти книгу». 2. (o2.) Система запрашивает у Customer критерий поиска книги, включающий автора, название, ISBN или тематику. 3. (3.) Customer вводит запрашиваемый критерий. 4. (o4.) Система ищет книги, соответствующие критерию от Customer. 5. (o5.) Если система находит соответствующие книги. 5.1. Система выводит на экран текущий бестселлер. 5.2. (o5.1.) Система выводит на экран данные по максимум пяти книгам. 5.3. Для каждой книги система выводит название, автора, цену и ISBN. 5.4. Пока есть другие соответствующие запросу книги, система предостав ляет Customer опцию для отображения следующей страницы с книгами. 6. (6.) Иначе 6.1. Система выводит на экран текущий бестселлер. 6.2. (6.1.) Система сообщает Покупателю о том, что соответствующие книги не найдены. ID: 7 Краткое описание: Customer ищет книгу. Альтернативные потоки: Нет. ID родителя: 6 Второстепенные актеры: Нет. Рис. 5.6. Описание дочернего прецедента FindBook 126 Глава 5. Дополнительные аспекты моделирования прецедентов интересованные стороны. Поскольку прецеденты предназначены для общения с заказчиками, это является серьезной проблемой. Другой недостаток состоит в том, что приходится вручную изменять таблицу соответствия между родителями и потомками, если один из них меня ется. Это утомительно и может приводить к большому числу ошибок. Одно из решений данной проблемы – ограничить родительский преце дент так, чтобы в нем не было основного потока, а только краткое опи сание семантики. Тогда не надо беспокоиться о наследовании или пере определении. В этом случае с помощью прецедентов можно легко и эф фективно показать, что один или более прецедентов на самом деле яв ляются просто особыми вариантами более общего прецедента. Более общий прецедент позволяет рассматривать систему более абстрактно и может указать на возможности оптимизации системы ПО. 5.4. Отношение «include» Иногда в прецедентах присутствует многократное описание одних и тех же действий. Например, рассмотрим систему Personnel (персонал) (рис. 5.7). Практически любое действие системы начинается с получе ния данных о конкретном служащем. Если бы эту последовательность событий приходилось писать каждый раз, когда необходимы данные служащего, прецеденты имели бы повторяющиеся части. Отношение «include», устанавливаемое между прецедентами, позволяет включить поведение одного прецедента в поток другого прецедента. Отношение «include» выносит шаги, общие для нескольких прецеден тов, в отдельный прецедент, который потом включается в остальные. Включающий прецедент мы называем базовым, а тот прецедент, кото рый включается, включаемым. Включаемый прецедент предоставляет поведение своему базовому прецеденту. В базовом прецеденте необходимо точно указать место, где должно быть включено поведение включаемого прецедента. Синтаксис и се мантика отношения «include» немного напоминают вызов функции. FindEmployeeDetails ViewEmployeeDetails ChangeEmployeeDetails DeleteEmployeeDetails «include» «include» Cистема Personnel базовый прецедент отношение включения включаемый прецедент «include» Manager Рис. 5.7. Отношение «include» 5.5. Отношение «extend» 127 Отношение «include» имеет простую семантику (рис. 5.8). Базовый пре цедент выполняется до момента включения. Затем выполнение пере ходит во включаемый прецедент. По завершении включаемого преце дента управление вновь возвращается в базовый прецедент. Базовый прецедент является незавершенным без всех его включаемых прецедентов. Они – неотъемлемые части базового прецедента. Однако включаемые прецеденты могут быть как полными, так и неполными. Если включаемый прецедент неполный, он просто содержит часть по тока событий, которая имеет смысл только тогда, когда включена в со ответствующий базовый прецедент. Обычно такие прецеденты называ ют фрагментом поведения. В этом случае говорят, что экземпляр вклю чаемого прецедента не может быть создан, т. е. он не может быть ини циирован актерами напрямую. Он может выполняться, только если он включен в соответствующий базовый прецедент. Однако если включае мый прецедент полный, он ведет себя как обычный прецедент. Его эк земпляры могут быть созданы, и он может инициироваться актерами. Включаемый прецедент приведен на рис. 5.9. Он является неполным и, следовательно, его экземпляры не могут быть созданы. |