Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 25

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 25)

(о5.1.) Система выводит на экран страницу с данными максимум пяти книг.Добавлена6.3. Система повторно выводит на экранстраницу поиска «найти книгу».Система SalesFindProductCustomerFindBookFindCDРис. 5.4. Фрагмент диаграммы прецедентов системы SalesПрецедент: FindProductID: 6Краткое описание:Customer ищет продукт.Главные актеры:CustomerВторостепенные актеры:Нет.Предусловия:Нет.Основной поток:1.

Customer выбирает опцию «найти продукт».2. Система запрашивает у Customer критерий поиска.3. Customer вводит запрашиваемый критерий.4. Система ищет продукты, соответствующие критерию от Customer.5. Если система находит соответствующие продукты5.1.

Система выводит на экран список соответствующих продуктов.6. Иначе6.1. Система сообщает Customer о том, что соответствующие продукты не найдены.Постусловия:Нет.Альтернативные потоки:Нет.Рис. 5.5. Описание родительского прецедента FindProduct1255.3. Обобщение прецедентовПрецедент: FindBookID: 7ID родителя: 6Краткое описание:Customer ищет книгу.Главные актеры: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.) Система сообщает Покупателю о том, что соответствующиеперенумерованныйкниги не найдены.Постусловия:Нет.Альтернативные потоки:Нет.Рис. 5.6. Описание дочернего прецедента FindBookОдин из дочерних прецедентов, FindBook, показан на рис. 5.6.

Здесь демонстрируется применение нашего стандарта обозначения переопределенных или новых возможностей. Как видно из рис. 5.6, дочернийпрецедент FindBook намного более конкретный. В нем более абстрактный родитель специализирован для работы с конкретным типом продуктов – книгами.Если в родительском прецеденте нет потока событий или поток событийне завершен, это абстрактный прецедент. Абстрактные прецеденты довольно широко распространены, потому что могут использоваться дляописания поведения на самых высоких уровнях абстракции.

Поскольку в абстрактных прецедентах поток событий отсутствует или являетсянеполным, они не могут быть выполнены системой. Вместо потока событий в абстрактных прецедентах используется простое высокоуровневое текстовое описание поведения, которое должны реализовать их потомки. Это описание можно поместить в раздел «Краткое описание».Как мы уже видели, унаследованные возможности в дочерних прецедентах показать сложно.

Приходится применять определенный языктегов или соглашение об обозначениях, что обычно сбивает с толку за126Глава 5. Дополнительные аспекты моделирования прецедентовинтересованные стороны. Поскольку прецеденты предназначены дляобщения с заказчиками, это является серьезной проблемой. Другойнедостаток состоит в том, что приходится вручную изменять таблицусоответствия между родителями и потомками, если один из них меняется.

Это утомительно и может приводить к большому числу ошибок.Одно из решений данной проблемы – ограничить родительский прецедент так, чтобы в нем не было основного потока, а только краткое описание семантики. Тогда не надо беспокоиться о наследовании или переопределении. В этом случае с помощью прецедентов можно легко и эффективно показать, что один или более прецедентов на самом деле являются просто особыми вариантами более общего прецедента. Болееобщий прецедент позволяет рассматривать систему более абстрактнои может указать на возможности оптимизации системы ПО.5.4. Отношение «include»Иногда в прецедентах присутствует многократное описание одних и техже действий.

Например, рассмотрим систему Personnel (персонал)(рис. 5.7). Практически любое действие системы начинается с получения данных о конкретном служащем. Если бы эту последовательностьсобытий приходилось писать каждый раз, когда необходимы данныеслужащего, прецеденты имели бы повторяющиеся части. Отношение«include», устанавливаемое между прецедентами, позволяет включитьповедение одного прецедента в поток другого прецедента.Отношение «include» выносит шаги, общие для нескольких прецедентов, в отдельный прецедент, который потом включается в остальные.Включающий прецедент мы называем базовым, а тот прецедент, который включается, включаемым. Включаемый прецедент предоставляетповедение своему базовому прецеденту.В базовом прецеденте необходимо точно указать место, где должнобыть включено поведение включаемого прецедента.

Синтаксис и семантика отношения «include» немного напоминают вызов функции.Cистема Personnelбазовый прецедентChangeEmployeeDetailsViewEmployeeDetailsвключаемыйпрецедент«include»«include»FindEmployeeDetailsde»ManagerDeleteEmployeeDetails«incluотношение включенияРис.

5.7. Отношение «include»1275.5. Отношение «extend»Прецедент: ChangeEmployeeDetailsПрецедент: ViewEmployeeDetailsПрецедент: DeleteEmployeeDetailsID: 1Краткое описание:Manager меняет данные служащего.ID: 2Краткое описание:Manager просматривает данные служащего.ID: 3Краткое описание:Manager удаляет данные служащего.Главные актеры:ManagerВторостепенные актеры:Нет.Предусловия:1. Manager входит в систему.Основной поток:1. include (FindEmployeeDetails).2. Система выводит данные служащего.3. Manager меняет данные служащего.…Постусловия:1.

Данные служащего изменены.Главные актеры:ManagerВторостепенные актеры:Нет.Предусловия:1. Manager входит в систему.Основной поток:1. include (FindEmployeeDetails).2. Система выводит данные служащего.…Главные актеры:ManagerВторостепенные актеры:Нет.Предусловия:1.

Manager входит в систему.Основной поток:1. include (FindEmployeeDetails).2. Система выводит данные служащего.3. Manager удаляет данные служащего.…Постусловия:1. Данные служащего удалены.Альтернативные потоки:Нет.Альтернативные потоки:Нет.Постусловия:1. Система вывела на экран данныеслужащего.Альтернативные потоки:Нет.Рис. 5.8.

Семантика отношения «include»Отношение «include» имеет простую семантику (рис. 5.8). Базовый прецедент выполняется до момента включения. Затем выполнение переходит во включаемый прецедент. По завершении включаемого прецедента управление вновь возвращается в базовый прецедент.Базовый прецедент является незавершенным без всех его включаемыхпрецедентов. Они – неотъемлемые части базового прецедента. Однаковключаемые прецеденты могут быть как полными, так и неполными.Если включаемый прецедент неполный, он просто содержит часть потока событий, которая имеет смысл только тогда, когда включена в соответствующий базовый прецедент. Обычно такие прецеденты называют фрагментом поведения. В этом случае говорят, что экземпляр включаемого прецедента не может быть создан, т.

е. он не может быть инициирован актерами напрямую. Он может выполняться, только если онвключен в соответствующий базовый прецедент. Однако если включаемый прецедент полный, он ведет себя как обычный прецедент. Его экземпляры могут быть созданы, и он может инициироваться актерами.Включаемый прецедент приведен на рис. 5.9. Он является неполными, следовательно, его экземпляры не могут быть созданы.5.5. Отношение «extend»Отношение «extend» – способ введения нового поведения в существующий прецедент.128Глава 5. Дополнительные аспекты моделирования прецедентовПрецедент: FindEmployeeDetailsID: 4Краткое описание:Manager ищет данные служащего.Главные актеры:ManagerВторостепенные актеры:Нет.Предусловия:1.

Manager входит в систему.Основной поток:1. Manager вводит ID служащего.2. Система ищет данные служащего.Постусловия:1. Система нашла данные служащего.Альтернативные потоки:Нет.Рис. 5.9. Пример неполного включаемого прецедентаОтношение «extend» предоставляет возможность ввести новое поведение в существующий прецедент (рис. 5.10). Базовый прецедент предоставляет набор точек расширения (extension points) – точек входа,в которые может быть добавлено новое поведение. А расширяющийпрецедент предоставляет ряд сегментов вставки, которые можно ввестив базовый прецедент в места, указанные точками входа.

Как вскоре будет показано, отношение «extend» может использоваться для того, чтобыточно указать, какие именно точки расширения базового прецедентаподлежат расширению.В отношении «extend» любопытно то, что базовый прецедент ничего незнает о расширяющих прецедентах, он просто предоставляет для нихточки входа. Базовый прецедент абсолютно полон и без расширений.Это существенно отличает «extend» от отношения «include», где базовыеCистема Libraryбазовый прецедентReturn book«extend»Borrow bookLibrarianFind bookРис. 5.10. Отношение «extend»расширяющий прецедентIssue fineотношениерасширения1295.5. Отношение «extend»Прецедент: ReturnBookID: 9Краткое описание:Librarian возвращает взятую книгу.базовый прецедентГлавные актеры:LibrarianReturnBookextension pointsoverdueBookВторостепенные актеры:Нет.Предусловия:1.

Librarian входит в систему.extension point: overdueBook«extend»точкарасширенияимя точкирасширенияIssueFineрасширяющий прецедентОсновной поток:1. Librarian вводит ID читателя.2. Система выводит данные читателя, включаясписок взятых им книг.3. Librarian находит возвращаемую книгув списке книг.точка расширения: overdueBook4.

Librarian возвращает книгу.…Постусловия:1. Книга возвращена.Альтернативные потоки:Нет.Рис. 5.11. Обозначение точек расширенияпрецеденты остаются неполными без включаемых прецедентов. Болеетого, точки расширения на самом деле не вводятся в поток событий базового прецедента; они накладываются поверх потока.Точки расширения обозначаются в потоке событий базового прецедента, как показано на рис. 5.11. Точки расширения также можно показать на диаграмме прецедентов, перечислив их в новой ячейке пиктограммы базового прецедента.Обратите внимание на то, что точки расширения в основном потоке непронумерованы. Они появляются между пронумерованными шагамипотока. UML явно определяет тот факт, что точки расширения фактически существуют в слое поверх основного потока.

Следовательно, онивообще не являются его частью. Этот слой подобен прозрачной пленке,наложенной поверх основного потока, на которую нанесены точки расширения. Основная идея введения этого слоя – сделать поток базовогопрецедента полностью независимым от точек расширения. Иначе говоря, поток базового прецедента не знает (или не интересуется), в каких точках происходит его расширение.

Это позволяет использоватьотношение «extend» для создания произвольных или специальных расширений потока базового прецедента.При использовании «extend» базовый прецедент выступает в роли модульного каркаса, к которому можно подключать расширения в предопределенных точках расширения. В примере на рис.

Характеристики

Список файлов книги