Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
586 Приложение A
A.3. Примеры прецедентов
На рис. А.2 представлен сокращенный вариант модели прецедентов.
Здесь показаны обычные прецеденты, расширяющий прецедент и от
ношения «include» и «extend».
Прецеденты с рис. А.2 показаны более подробно на рис. A.3–A.6.
В описания прецедентов включены все важные детали, но опущена об
щая информация (торговая марка компании, информация об авторе
и версии и др.). Эти данные для каждой компании свои. Во многих
компаниях разработаны стандартные заголовки, используемые во
всей документации компании.
Хотя описание прецедента может храниться непосредственно в инст
рументальном средстве моделирования UML, часто поддержка этой
возможности довольно слаба и ограничивается простым текстом. По
этому многие разработчики моделей сохраняют описания прецедентов
в формате, предоставляющем большие возможности, таком как Word
или XML, и подключаются к этим внешним документам из модели
прецедентов в инструменте моделирования. Некоторые идеи по поводу
«include»
User
CardProcessingCompany
AcceptPaymentByCard
Dispatcher
InventorySystem
Checkout
Customer
DisplayBasket
extension points
manageBasket
extension point:
manageBasket
ManageBasket
«extend»
Рис. A.2. Сокращенный вариант модели прецедентов
Пример модели прецедентов 587
использования XML для записи описаний прецедентов представлены
в приложении B.
Прецедент: Checkout
Главные актеры:
Customer
Предусловия:
1. Customer входит в систему.
Постусловия:
1. Customer подтвердил заказ.
2. Заказанные товары зарезервированы актером InventorySystem.
Основной поток:
1. Прецедент начинается, когда Customer выбирает опцию «checkout».
2. Система просит актера InventorySystem предварительно зарезервировать товарные позиции,
указанные в корзине для покупок.
3. Для каждой отсутствующей позиции.
3.1. Система информирует Customer о том, что товар временно недоступен и удален из заказа.
4. Система представляет окончательный вариант заказа актеру Customer. Для каждого продукта
заказ включает идентификатор продукта, имя продукта, количество, цену единицы продукции,
общую стоимость данного количества. В заказ также входит адрес поставки, информация кредитной
карты Customer и общая стоимость заказа, включая налоги и затраты на доставку и упаковку.
5. Система просит Customer принять или отклонить заказ.
6. Customer подтверждает заказ.
7. include( AcceptPaymentByCard ).
ID: 6
Краткое описание:
Customer (покупатель) подтверждает заказ. Система создает заказ на основании содержимого
корзины для покупок, и Customer оплачивает заказ.
Альтернативные потоки:
Нет.
Второстепенные актеры:
InventorySystem (система управления запасами)
Рис. A.3. Описание прецедента Checkout
588 Приложение A
Рис. A.4. Описание прецедента AcceptPaymentByCard
Прецедент: AcceptPaymentByCard
Главные актеры:
Customer
Предусловия:
1. Customer входит в систему.
2. Некоторые наличные товарные позиции были предварительно зарезервированы для актера Customer.
Постусловия:
1. Заказ получил статус ожидающего рассмотрения.
2. С кредитной карты Customer снята соответствующая сумма.
3. Некоторые наличные товарные позиции были зарезервированы для обеспечения выполнения заказа.
4. Заказ отправлен актеру Dispatcher.
Основной поток:
1. Прецедент начинается, когда Customer подтверждает заказ.
2. Система извлекает информацию кредитной карты Customer.
3. Система посылает сообщение в CardProcessingCompany, включающее идентификатор получателя платежа,
его аутентификационные данные, имя на карте, номер карты, срок действия карты, сумму сделки.
4. CardProcessingCompany дает разрешение на транзакцию.
5. Система сообщает Customer, что транзакция с использованием кредитной карты была принята.
6. Система дает Customer шифр, чтобы он мог отслеживать заказ.
7. Система указывает актеру InventorySystem зарезервировать необходимые товарные позиции.
8. Система посылает заказ актеру Dispatcher.
9. Система меняет состояние заказа на ожидающий рассмотрения.
10. Система выводит на экран подтверждение заказа, предоставляя актеру Customer возможность распечатать его.
ID: 1
Краткое описание:
Покупатель оплачивает заказ кредитной картой.
Альтернативные потоки:
CreditLimitExceeded
BadCard
CreditCardPaymentSystemDown
Второстепенные актеры:
CardProcessingCompany (компания обработки кредитных карт)
InventorySystem (система управления запасами)
Dispatcher (диспетчер)
Пример модели прецедентов 589
Рис. A.5. Описание прецедента DisplayBasket
Рис. A.6. Описание прецедента ManageBasket
Прецедент: DisplayBasket
Главные актеры:
Customer
Предусловия:
Нет.
Постусловия:
Нет.
Основной поток:
1. Customer выбирает опцию «display basket» (вывести на экран содержимое корзины).
2. Если в корзине нет товаров.
2.1. Система сообщает Customer о том, что корзина пуста.
2.2. Прецедент завершается.
3. Для каждого продукта в корзине.
3.1. Система отображает идентификационный номер, количество, детальную информацию,
цену единицы продукции и общую цену.
точка расширения: manageBasket
ID: 13
Краткое описание:
Система отображает содержимое корзины для покупок актера Customer.
Альтернативные потоки:
Нет.
Второстепенные актеры:
Нет.
Расширяющий прецедент: ManageBasket
Главные актеры:
Customer
Предусловия:
1. Система отображает корзину для покупок.
Постусловия:
Нет.
Основной поток:
1. Пока Customer вносит изменения в корзину.
1.1. Customer выбирает товарную позицию в корзине.
1.2. Если Customer выбирает «remove item» (удалить позицию).
1.2.1. Система отображает сообщение «Вы уверены, что хотите удалить из корзины
выбранную позицию?».
1.2.2. Customer подтверждает удаление.
1.2.3. Система удаляет выбранную позицию из корзины.
1.3. Если Customer вводит новое количество для выбранной позиции.
1.3.1. Система обновляет количество для выбранной позиции.
ID: 20
Краткое описание:
Customer меняет содержимое корзины.
Альтернативные потоки:
Нет.
Второстепенные актеры:
Нет.
B
XML и прецеденты
B.1. Применение XML для шаблонов
прецедентов
Как видите, UML 2 не определяет формального стандарта для докумен
тирования прецедентов. Разработчикам моделей приходится или ис
пользовать возможности, предлагаемые инструментальными средства
ми моделирования UML, которые нередко весьма ограничены, или
применять собственный подход. В настоящий момент модель преце
дентов чаще всего создается в средстве моделирования, а затем преце
денты и актеры подключаются к внешним документам, содержащим
их подробные описания. Эти документы обычно создаются в текстовом
редакторе, однако это не лучший инструмент для решения данной за
дачи. Хотя он обеспечивает возможность форматирования и структу
рирования описаний прецедентов и актеров, в нем нельзя отразить се
мантику этой структуры.
Мы считаем, что структурированные XMLдокументы – естественный
формат описаний прецедентов. XML – это язык семантической размет
ки, поэтому в нем семантическая структура документа отделена от его
форматирования. Описание прецедента или актера, представленное
в виде XMLдокумента, можно трансформировать разными способами
с помощью XSL [Kay 1]. Описания можно генерировать как HTML, PDF
или как документы текстового редактора. Кроме того, можно делать за
просы к описаниям для получения определенной информации.
Структура XMLдокумента может быть описана на языке описания
XMLсхемы (XML Schema Definition Language, XSL). Несколько прос
тых XMLсхем для актеров и прецедентов представлены на нашем веб
сайте. Они доступны для загрузки и использования по лицензии GNU
(GNU General Public License) (подробности см. по адресу www. gnu.org).
XML и прецеденты 591
Подробное описание XML и XSL выходит за рамки как этой книги, так
и нашего вебсайта. Однако на сайте предлагаются полезные ссылки
на образовательные ресурсы по XML и XSL.
Поскольку применение XML требует специальных редакторов, и заин
тересованным сторонам может быть сложно его использовать, недавно
нами был разработан простой подход создания прецедентов (и других
документов проекта) в XML и других форматах. Он кратко обсуждает
ся в следующем разделе.
B.2. SUMR
SUMR (произносится «саммэ») расшифровывается как Simple Use case
MarkupRestructured (простая реструктурированная разметка преце
дентов). Это текстовый язык разметки для прецедентов. Документы
SUMR без труда можно трансформировать в XML, HTML и другие фор
маты.
SUMR обладает целым рядом преимуществ.
• Он очень прост – синтаксис разметки можно выучить за минуту.
• Для него не требуются изощренные текстовые редакторы или воз
можности редактирования – SUMRдокументы можно создавать
в любом текстовом редакторе, поддерживающем простой текст.
В случае необходимости SUMRтекст можно вводить прямо в поле
HTMLформы.
• Он структурированный – SUMRдокументы имеют схему. Можно
создать собственную схему или использовать предоставляемые на
ми стандартные схемы.
• Он бесплатен согласно разрешению для копирования GNU (www.gnu.
org/copyleft).
Чтобы вы почувствовали, что такое SUMR, на рис. B.1 приведен про
стой прецедент, размеченный как SUMRдокумент.
Синтаксис прост: все, что начинается и заканчивается двоеточиями
(например, :это:), – это тег. Тело тега начинается на следующей строке
после тега и продолжается до следующей пустой строки.
SUMR занимается исключительно структурой и семантикой докумен
та, а не его представлением. Он позволяет быстро и эффективно фик
сировать важную информацию, не забивая голову форматированием,
шаблонами документов или сложными языками разметки.
У каждого SUMRдокумента может быть схема, определенная в специ
альном теге :schema:. Схема SUMR – SUMRдокумент, определяющий
теги, которые могут использоваться в других SUMRдокументах. На
рис. B.2 показана SUMRсхема нашего примера прецедента. Как види
те, правильно описанные схемы SUMR могут быть самодокументируе
мыми.
592 Приложение B
Когда есть схема, инструменты SUMR можно использовать для:
• трансформирования прецедентов, соответствующих схеме, в XML;
• генерирования образцовых таблиц стилей XSL для преобразования
XML в
• XHTML плюс каскадная таблица стилей (Cascading Style Sheet,
CSS);
• XMLFO (форматирующие объекты XML).
Рис. B.1. Прецедент, размеченный как SUMR+документ
file AddItemToBasket.uc
:schema:
UseCase.sss
:name:
AddItemToBasket
:id:
2
:parents:
1. None
:primaryActors:
1. Customer
:secondaryActors:
1. None
:brief:
1. The Customer adds an item to their shopping basket.
:pre:
1. The Customer is browsing products.
:flow:
1. The Customer selects a product
2. The Customer selects "add item".
3. The system adds the item to the Customer's shopping basket.
4. :inc:DisplayBasket
:post:
1. A product has been added to the Customer's basket.
2. The contents of the basket are displayed.
:alt:
1. None
:req:
1. None
XML и прецеденты 593
Рис. B.2. SUMR+схема прецедента
file UseCase.sss
:schema:
UseCase.sss
:name:
Write the name of the use case here. Use case names are
in UpperCamelCase with no spaces.
:id:
Write the unique project identifier for the use case here.
:parents:
Write the names of the parent use cases here.
If this use case has no parents, write None here.
:primaryActors:
Write the names of the primary actors here.
There must be at least one primary actor.
:secondaryActors:
List the names of the secondary actors here.
Secondary actors participate in the use case, they do not start the use case.
If there are no secondary actors, write None here.
:brief:
Write a brief description of your use case here. This description
should be no more than a couple of paragraphs.
:pre:
Write the preconditions here, one on each line.
If the use case has no preconditions, write None here.
:flow:
Write the main flow here.
Each step should be timeordered and declarative.
:ext:WriteExtensionPointsLikeThis
Note that extension points are NOT numbered.
If you need to show nested steps
Indent them by one space for each level of indent like this.
Include other use cases like this :inc:AnotherUseCase. This is the final step.
:post:
Write the postconditions here, one on each line.
If there are no postconditions, write None here.
:alt:
List the names of the alternative flows here, one on each line.
If there are no alternative flows, write None here.
:req:
List any special requirements related to the use case here. These are
typically nonfunctional requirements.
If there are no special requirements, write None here.
594 Приложение B
Инструменты SUMR генерируют стандартные таблицы стилей. Это по
лезная возможность – не нужно писать таблицы стилей с нуля, доста
точно только настроить их. Это также очень гибкий подход, поскольку
таблицы стилей предоставляют практически полный контроль над
формированием представления SUMRдокументов.
На рис. B.3 представлен пример прецедента с рис. B.1, трансформиро
ванного в XML одним из инструментов SUMR.
Как только прецедент представлен в формате XML, можно использо
вать сгенерированные таблицы стилей XSL для его дальнейшей транс
формации. Вариант, обеспечивающий максимальную гибкость, – это
трансформация XML в XMLFO; после этого с помощью Apache FOP
(http://xml.apache.org/fop/index.html) его можно преобразовать во мно
жество других форматов вывода, включая PDF и PostScript. На рис. B.4
показан прецедент, сформированный как PDF с помощью стандартной
таблицы стилей XMLFO, сгенерированной из схемы. В стандартном
стиле практически не на что смотреть, но его можно как угодно на
строить, редактируя сгенерированную таблицу стилей, которая его
описывает.
И наконец, на рис. B.5 представлен простой структурированный ре
дактор документов SUMR, который мы включили в набор инструмен
тов. Он может проверять соответствие прецедента или актера его схе
ме, имеет средства подсветки синтаксиса и автонумерации. Это заме
чательный инструмент для малых и средних моделей прецедентов.
Найти более подробную информацию по SUMR и загрузить инстру
менты и примеры схем можно на нашем вебсайте (www.umlandtheuni+
fiedprocess.com).
Надеемся, вам понравится работать с этим набором инструменталь
ных средств. Для нас ценен любой отзыв, который вы можете оставить
на нашем вебсайте.
XML и прецеденты 595
Рис. B.3. Прецедент с рис. B.1, трансформированный в XML одним
из инструментов SUMR
file AddItemToBasket.uc
<?xml version="1.0" encoding="UTF8"?>
<UseCase.sss>
<schemaSection>
<schema>UseCase.sss</schema>
</schemaSection>
<nameSection>
<name>AddItemToBasket</name>
</nameSection>
<idSection>
<id>2</id>
</idSection>
<parentsSection>
<parents>1. None</parents>
</parentsSection>
<primaryActorsSection>
<primaryActors>1. Customer</primaryActors>
</primaryActorsSection>
<secondaryActorsSection>
<secondaryActors>1. None</secondaryActors>
</secondaryActorsSection>
<briefSection>
<brief>1. The Customer adds an item to their shopping
basket.</brief>
</briefSection>
<preSection>
<pre>1. The Customer is browsing products.</pre>
</preSection>
<flowSection>
<flow>1. The Customer selects a product</flow>
<flow>2. The Customer selects "add item".</flow>
<flow>3. The system adds the item to the Customer's shopping
basket.</flow>
<flow>4. :inc:DisplayBasket</flow>
</flowSection>
<postSection>
<post>1. A product has been added to the Customer's basket.</post>
<post>2. The contents of the basket are displayed.</post>
</postSection>
<altSection>
<alt>1. None</alt>
</altSection>
<reqSection>
<req>1. None</req>
</reqSection>
</UseCase.sss>