UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
has sent с параметрами Семантика anObject^aMessage( 1, 2 ) Возвращает true, если aMessage(...) послано в an Object с параметрами, имеющими значения 1 и 2. anObject^aMessage( ?:Integer, ?:Integer ) Возвращает true, если aMessage(...) послано в an Object с параметрами типа Integer. get messages с параметрами Семантика anObject^^aMessage( 1, 2 ) Возвращает Sequence всех сообщений, посланных в anObject с параметрами, имеющими значения 1 и 2. anObject^^aMessage( ?:Integer, ?:Integer ) Возвращает Sequence всех сообщений, посланных в anObject с параметрами типа Integer. Операция Subject Семантика attach( o : Observer ) Присоединяет объект Observer. detach( o : Observer ) Отсоединяет объект Observer. notify() Вызывает операцию update() каждого объекта Observer – вызывается, когда Subject меняется и желает уведомить объекты Observer об этом изменении. +attach( o : Observer ) +detach( o : Observer ) +notify() Subject subjects 0..* observers 0..* +attach( s : Subject ) +detach( s : Subject ) +update( s : Subject ) Observer Рис. 25.24. Пример применения шаблона Observer 25.13. Что мы узнали 579 post: каждый наблюдатель должен быть уведомлен через вызов update() self.observers.forAll( observer | observer^update() ) В данном постусловии происходит перебор всех observers в Set и провер ка получения ими сообщения update(). Оператор ^ – это оператор «has sent». Он возвращает true, если указанное сообщение было послано операцией. Он может использоваться только в постусловиях. Если сообщение синхронное (вы знаете, что оно вернется), можно про верять возвращаемое значение сообщения: context Subject::notify( ) post: возвращаемое значение update( ) должно быть true для каждого наблюдателя self.observers.forAll( observer | observer^update().hasReturned() implies observer^update().result() ) 25.13. Что мы узнали В этом введении в OCL мы узнали следующее: • OCL – стандартное расширение UML. Он может: • определять запросы; • определять ограничения; • определять тело операции запроса; • определять бизнес правила во время разработки модели. • OCL не язык действий для UML. Он не может: • менять значения элемента модели; • определять тело операции (кроме операций запроса); • выполнять операции (кроме операций запроса); • динамически определять бизнес правила. • OCL выражения. • Состоят из: • контекста пакета (необязательно) – определяет пространство имен для OCL выражения; • контекста выражения (обязательно) – определяет экземпляр контекста для выражения; • одного или более выражений. • Контекст выражения может быть определен явно или путем раз мещения OCL выражения в примечании к элементу модели. 580 Глава 25. Введение в OCL • Экземпляр контекста – образец экземпляра контекста выражения: • OCL выражения записываются в рамках экземпляра контекста. • Типы OCL выражений. • inv: – инвариант: • применяется к классификаторам; • экземпляр контекста – экземпляр классификатора; • инвариант должен быть true для всех экземпляров классифи катора. • pre: – предусловие операции: • применяется к операциям; • экземпляр контекста – экземпляр классификатора, которому принадлежит операция; • предусловие должно выполняться для обеспечения возмож ности выполнения операции. • post: – постусловие операции: • применяется к операциям; • экземпляр контекста – экземпляр классификатора, которому принадлежит операция; • постусловие должно быть истинным после выполнения опе рации; • ключевое слово result обозначает результат операции; • feature@pre возвращает значение свойства (feature) до выполне ния операции: • @pre может использоваться только в постусловиях; • OclMessage может использоваться только в постусловиях. • body: – определяет тело операции: • применяется к операциям запроса; • экземпляр контекста – экземпляр классификатора, которому принадлежит операция. • init: – задает начальное значение: • применяется к атрибутам или концам ассоциаций; • экземпляр контекста – атрибут или конец ассоциации. • def: – добавляет атрибуты и операции в классификатор с помо щью стереотипа «OclHelper»: • применяется к классификатору; • экземпляр контекста – экземпляр классификатора; • добавляет атрибуты и операции в классификатор с помощью стереотипа «OclHelper»: • может использоваться только в OCL выражениях. 25.13. Что мы узнали 581 • let – определяет локальную переменную: • применяется к OCL выражению; • экземпляр контекста OCL выражения. • derive: – определяет производное значение: • применяется к атрибутам или концам ассоциаций; • экземпляр контекста – экземпляр классификатора, которому принадлежит операция. • Комментарии: • /* многострочные */ • однострочные • Старшинство операций: • :: • @pre • • > • not ^ ^^ • * / • + • if then else endif • > < <= >= • = <> • and or xor • implies • Система типов OCL. • OclAny: • супертип всех типов OCL и типов UML модели. • OclType: • подкласс OclAny; • перечисление всех типов ассоциированной UML модели. • OclState: • подкласс OclAny; • перечисление всех состояний ассоциированной UML модели. • OclVoid: • тип «null» в OCL – имеет единственный экземпляр под назва нием OclUndefined. • OclMessage – используется для: • подтверждения отправки сообщения; 582 Глава 25. Введение в OCL • подтверждения возвращения сообщения; • получения возвращаемого значения сообщения; • возвращения коллекции сообщений, отправленных объекту. • Примитивные типы OCL: • Boolean; • Integer; • Real; • String. • Tuples – структурированный тип: • Tuple { имяЧасти1:типЧасти1 = значение1, имяЧасти2:типЧасти2 = зна чение2, ... } • Инфиксные операторы – для их добавления в типы UML просто оп ределяется операция с соответствующей сигнатурой, например =(параметр) : Boolean. • Коллекции: • Set – { unordered, unique } (применяется по умолчанию) • OrderedSet – { ordered, unique } • Bag – { unordered, nonunique } • Sequence – { ordered, nonunique } • Операции над коллекциями должны инициироваться с помощью оператора –>. • Итерационные операции: • коллекция–> <операцияИтератора>(<переменнаяИтератора>:<Тип> | <вы ражениеИтератора>); • <переменнаяИтератора> и <Тип> необязательны. • Навигация в рамках экземпляра контекста: • self – организует доступ к экземпляру контекста; • оператор «точка» – организует доступ к возможностям экземп ляра контекста. • Навигация по ассоциациям: • self – организует доступ к экземпляру контекста; • имя роли – обозначает объект или набор объектов на конце ассо циации; • оператор «точка» – перегружен: • self.roleName: • кратность 1 – обеспечивается доступ к объекту на конце ассоциации; • кратность >1 – обеспечивается доступ к коллекции на кон це ассоциации; 25.13. Что мы узнали 583 • self.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 (E Commerce Platform – платформа электронной коммерции). На рис. А.1 показан окончательный результат моделирования прецедентов. Модель прецедентов обеспечит четкое представление о том, что делает система, но все подробности представлены на веб сайте. Пример модели прецедентов 585 Рис. A.1. Модель прецедентов DeleteProductFromCatalog ЕСР LogOnUser User CloseOrder AcceptPaymentByCard CardProcessingCompany Dispatcher «include» «include» «include» «include» Checkout DisplayBasket extension points manageBasket AddltemToBasket InventorySystem Customer SystemAdministrator «extend» extension point: manageBasket ManageBasket CancelOpenOrder BrowseProducts ViewProducts FindProducts FindBooks FindCDs ViewCDs CreateNewCustomer LogOnCustomer UpdateCustomer DeleteCustomer Shopkeeper AddProductToCatalog CreateNewUser DeleteUser DisplayOpenOrders ViewBooks 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 меняет содержимое корзины. Альтернативные потоки: Нет. Второстепенные актеры: Нет. |