Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 104
Текст из файла (страница 104)
Что мы узнали••••••••583self.roleName.feature:• кратность 1 – возвращает значение свойства (feature);• кратность > 1 – возвращает Bag значений свойств всех участвующих объектов (является сокращенной записью дляself.roleName>collect( feature )).Навигация по нескольким ассоциациям, где все кратности > 1:• self.roleName1.roleName2.feature – возвращает Bag значений этогосвойства (feature) всех участвующих объектов.OCL на диаграммах взаимодействий используется для определения:• сторожевого условия;• селектора линии жизни;• параметров сообщения.OCL на диаграммах деятельностей используется для определения:• узлов вызова действий;• сторожевых условий переходов;• объектных узлов;• операций;• состояния объекта.OCL на диаграммах состояний используется для определения:• сторожевых условий;• условий, накладываемых на состояния;• целей действий;• операций;• значений параметров.Навигация к и от классовассоциаций:• к классамассоциаций – используется имя классаассоциации;• от классовассоциаций – используются имена ролей.Навигация по квалифицированным ассоциациям:• после имени роли в квадратных скобках указывается разделенный запятыми список квалификаторов.Унаследованные ассоциации:• OCLвыражения используются для ограничения типов участников в унаследованных ассоциациях.AПример модели прецедентовA.1.
ВведениеНаш опыт свидетельствует о том, что UMLмодели не терпят бумаги.Если вам когдалибо приходилось распечатывать большую UMLмодель, включая спецификации, вам точно известно, что имеется в виду!UMLмодели лучше представлять в более гибком формате – в виде гипертекста. В настоящее время это или средство моделирования, иливебсайт.Включение полного учебного примера UML в эту книгу сделало бы еенамного толще и дороже.
Мы также несли бы ответственность за намного большее количество уничтоженных деревьев. Поэтому было решено предоставить пример для этой книги на нашем вебсайте(www.umlandtheunifiedprocess.com). Нам кажется, что ориентироваться в электронном варианте легче, чем в бумажном.Предлагаемый вашему вниманию пример охватывает ОО анализ и проектирование, необходимые для создания небольшого вебприложенияэлектронной коммерции. В этом приложении в упрощенном виде приводится несколько наиболее ярких моментов модели прецедентов, чтобы дать представление о том, что доступно на сайте!A.2. Модель прецедентовДанная модель прецедентов создана для простой системы электроннойкоммерции по продаже книг и CD.
Эта система называется ECP (ECommerce Platform – платформа электронной коммерции). На рис. А.1показан окончательный результат моделирования прецедентов.Модель прецедентов обеспечит четкое представление о том, что делаетсистема, но все подробности представлены на вебсайте.585Пример модели прецедентовЕСРLogOnUserUserCloseOrderCardProcessingCompanyAcceptPaymentByCardDispatcher«include»InventorySystemCheckoutDisplayBasketextension pointsmanageBasketextension point:manageBasket«include»«extend»AddltemToBasketCustomerManageBasketCancelOpenOrderBrowseProducts«include»ViewProductsFindProductsFindBooks«include»FindCDsViewBooksCreateNewCustomerDisplayOpenOrdersLogOnCustomerUpdateCustomerDeleteCustomerShopkeeperAddProductToCatalogDeleteProductFromCatalogCreateNewUserSystemAdministratorDeleteUserРис. A.1.
Модель прецедентовViewCDs586Приложение AA.3. Примеры прецедентовНа рис. А.2 представлен сокращенный вариант модели прецедентов.Здесь показаны обычные прецеденты, расширяющий прецедент и отношения «include» и «extend».Прецеденты с рис.
А.2 показаны более подробно на рис. A.3–A.6.В описания прецедентов включены все важные детали, но опущена общая информация (торговая марка компании, информация об автореи версии и др.). Эти данные для каждой компании свои. Во многихкомпаниях разработаны стандартные заголовки, используемые вовсей документации компании.Хотя описание прецедента может храниться непосредственно в инструментальном средстве моделирования UML, часто поддержка этойвозможности довольно слаба и ограничивается простым текстом. Поэтому многие разработчики моделей сохраняют описания прецедентовв формате, предоставляющем большие возможности, таком как Wordили XML, и подключаются к этим внешним документам из моделипрецедентов в инструменте моделирования.
Некоторые идеи по поводуUserCardProcessingCompanyAcceptPaymentByCardDispatcher«include»InventorySystemCheckoutCustomerDisplayBasketextension pointsmanageBasket«extend»ManageBasketРис. A.2. Сокращенный вариант модели прецедентовextension point:manageBasket587Пример модели прецедентовиспользования XML для записи описаний прецедентов представленыв приложении B.Прецедент: CheckoutID: 6Краткое описание:Customer (покупатель) подтверждает заказ. Система создает заказ на основании содержимогокорзины для покупок, и Customer оплачивает заказ.Главные актеры:CustomerВторостепенные актеры:InventorySystem (система управления запасами)Предусловия:1.
Customer входит в систему.Основной поток:1. Прецедент начинается, когда Customer выбирает опцию «checkout».2. Система просит актера InventorySystem предварительно зарезервировать товарные позиции,указанные в корзине для покупок.3. Для каждой отсутствующей позиции.3.1. Система информирует Customer о том, что товар временно недоступен и удален из заказа.4. Система представляет окончательный вариант заказа актеру Customer.
Для каждого продуктазаказ включает идентификатор продукта, имя продукта, количество, цену единицы продукции,общую стоимость данного количества. В заказ также входит адрес поставки, информация кредитнойкарты Customer и общая стоимость заказа, включая налоги и затраты на доставку и упаковку.5. Система просит Customer принять или отклонить заказ.6. Customer подтверждает заказ.7. include( AcceptPaymentByCard ).Постусловия:1. Customer подтвердил заказ.2. Заказанные товары зарезервированы актером InventorySystem.Альтернативные потоки:Нет.Рис. A.3. Описание прецедента Checkout588Приложение AПрецедент: AcceptPaymentByCardID: 1Краткое описание:Покупатель оплачивает заказ кредитной картой.Главные актеры:CustomerВторостепенные актеры:CardProcessingCompany (компания обработки кредитных карт)InventorySystem (система управления запасами)Dispatcher (диспетчер)Предусловия:1.
Customer входит в систему.2. Некоторые наличные товарные позиции были предварительно зарезервированы для актера Customer.Основной поток:1. Прецедент начинается, когда Customer подтверждает заказ.2. Система извлекает информацию кредитной карты Customer.3. Система посылает сообщение в CardProcessingCompany, включающее идентификатор получателя платежа,его аутентификационные данные, имя на карте, номер карты, срок действия карты, сумму сделки.4. CardProcessingCompany дает разрешение на транзакцию.5. Система сообщает Customer, что транзакция с использованием кредитной карты была принята.6. Система дает Customer шифр, чтобы он мог отслеживать заказ.7.
Система указывает актеру InventorySystem зарезервировать необходимые товарные позиции.8. Система посылает заказ актеру Dispatcher.9. Система меняет состояние заказа на ожидающий рассмотрения.10. Система выводит на экран подтверждение заказа, предоставляя актеру Customer возможность распечатать его.Постусловия:1. Заказ получил статус ожидающего рассмотрения.2. С кредитной карты Customer снята соответствующая сумма.3. Некоторые наличные товарные позиции были зарезервированы для обеспечения выполнения заказа.4.
Заказ отправлен актеру Dispatcher.Альтернативные потоки:CreditLimitExceededBadCardCreditCardPaymentSystemDownРис. A.4. Описание прецедента AcceptPaymentByCard589Пример модели прецедентовПрецедент: DisplayBasketID: 13Краткое описание:Система отображает содержимое корзины для покупок актера Customer.Главные актеры:CustomerВторостепенные актеры:Нет.Предусловия:Нет.Основной поток:1. Customer выбирает опцию «display basket» (вывести на экран содержимое корзины).2. Если в корзине нет товаров.2.1. Система сообщает Customer о том, что корзина пуста.2.2.
Прецедент завершается.3. Для каждого продукта в корзине.3.1. Система отображает идентификационный номер, количество, детальную информацию,цену единицы продукции и общую цену.точка расширения: manageBasketПостусловия:Нет.Альтернативные потоки:Нет.Рис. A.5. Описание прецедента DisplayBasketРасширяющий прецедент: ManageBasketID: 20Краткое описание:Customer меняет содержимое корзины.Главные актеры: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. Система обновляет количество для выбранной позиции.Постусловия:Нет.Альтернативные потоки:Нет.Рис.
A.6. Описание прецедента ManageBasketBXML и прецедентыB.1. Применение XML для шаблоновпрецедентовКак видите, UML 2 не определяет формального стандарта для документирования прецедентов. Разработчикам моделей приходится или использовать возможности, предлагаемые инструментальными средствами моделирования UML, которые нередко весьма ограничены, илиприменять собственный подход. В настоящий момент модель прецедентов чаще всего создается в средстве моделирования, а затем прецеденты и актеры подключаются к внешним документам, содержащимих подробные описания.