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

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

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

5.11 в базовом130Глава 5. Дополнительные аспекты моделирования прецедентовпрецеденте ReturnBook точка расширения overdueBook находится междушагами 3 и 4 потока событий.Отношение «extend» предоставляет хороший способ обработки исключительных ситуаций или ситуаций, когда нужен гибкий каркас, поскольку невозможно предсказать (или просто не известны) все возможные расширения.5.5.1.

Расширяющий прецедентРасширяющие прецеденты обычно не являются полными прецедентами, поэтому, как правило, их экземпляр не может быть создан. Обычно они состоят всего из одного или нескольких фрагментов поведения,называемых сегментами вставки. Отношение «extend» определяет точку расширения в базовом прецеденте, в которой будет введен сегментвставки. Здесь действуют следующие правила:• Отношение «extend» должно определять одну или несколько точекрасширения базового прецедента. В противном случае предполагается, что отношение «extend» относится ко всем точкам расширения.• В расширяющем прецеденте должно быть столько же сегментоввставки, сколько точек расширения определено в отношении«extend».• Два расширяющих прецедента могут «расширять» один базовыйпрецедент в одной и той же точке расширения.

Но в этом случае порядок выполнения расширений не определен.В примере на рис. 5.12 в расширяющем прецеденте всего один сегментвставки IssueFine (назначить штраф).Расширяющий прецедент может также иметь предусловия и постусловия. Предусловия должны быть выполнены, в противном случае сегРасширяющий прецедент: IssueFineReturnBookextension pointsoverdueBookID: 10Краткое описание:Сегмент 1: Librarian записывает и распечатывает штраф.Главные актеры:Librarianextension point: overdueBook«extend»Второстепенные актеры:Нет.Сегмент 1 предусловия:1. Возвращенная книга просрочена.единственная вставка расширяющегопрецедента IssueFine вводитсяв точке вставки overdueBookпрецедента ReturnBookПоток сегмента 1:1. Librarian вводит данные штрафа в систему.2.

Система распечатывает штраф.IssueFineСегмент 1 постусловия:1. Штраф записан в системе.2. Система распечатала штраф.Рис. 5.12. Расширяющий прецедент с одним сегментом вставки1315.5. Отношение «extend»мент не выполняется. Постусловия ограничивают состояние системыпосле выполнения сегмента.У самих расширяющих прецедентов могут быть расширяющие иливключаемые прецеденты. Однако лучше избегать такой вложенности,поскольку это сильно усложняет систему.5.5.2.

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

Обратимся к примеру, изображенному на рис. 5.13. Пусть после записии распечатки штрафа выполнение возвращается в основной поток дляобработки других просроченных книг, после чего в точке расширенияpayFine (выплатить штраф) должнику предлагается заплатить общуюсумму штрафа. Конечно, такая процедура более эффективна, чем взимание платежей по каждому штрафу в отдельности (так произошлобы, если бы эти два сегмента были сведены в один сегмент IssueFine).При создании расширяющих прецедентов с несколькими сегментаминеобходимо четко нумеровать каждый сегмент, как показано нарис.

5.13, поскольку здесь важен порядок сегментов: первый сегментРасширяющий прецедент: IssueFineID: 10Краткое описание:Сегмент 1: Librarian записывает и распечатывает штраф.Сегмент 2: Librarian принимает платеж по штрафу.ReturnBookextension pointsoverdueBookpayFineГлавные актеры:LibrarianВторостепенные актеры:Нет.Сегмент 1 предусловия:1. Возвращенная книга просрочена.Поток сегмента 1:1. Librarian вводит данные штрафа в систему.2. Система распечатывает штраф.extension points: overdueBook, payFine«extend»первый сегмент расширяющегопрецедента IssueFine вводится в точкерасширения overdueBook, а второйсегмент – в точке payFineIssueFineСегмент 1 постусловия:1.

Штраф записан в системе.2. Система распечатала штраф.Сегмент 2 предусловия:1. Штраф взыскан с должника.Поток сегмента 2:1. Librarian принимает платеж по штрафу от должника.2. Librarian вводит выплаченный штраф в систему.3. Librarian распечатывает квитанцию об уплате штрафа.Сегмент 2 постусловия:1. Штраф зарегистрирован как выплаченный.2. Система распечатала квитанцию об уплате штрафа.Рис. 5.13. Расширяющий прецедент с двумя сегментами вставки132Глава 5.

Дополнительные аспекты моделирования прецедентоввставляется в первой точке расширения и т. д. Поэтому надо очень аккуратно записывать сегменты в правильном порядке, а затем придерживаться его.5.5.3. Условные расширенияПример на рис. 5.14 демонстрирует другой, более гуманный подходк должнику: если он впервые задержал книгу, выдается предупреждение, а штраф выписывается только при повторном нарушении правил.Это можно смоделировать путем добавления нового расширяющегопрецедента IssueWarning (выдать предупреждение) и введения условийв отношения «extend». Условия (conditions) – это логические выражения. Вставка осуществляется только в том случае, если выражениеистинно.Обратите внимание, что расширяющий прецедент IssueWarning вводится только в точке расширения overdueBook (просроченная книга).

Однако (как и ранее) расширяющий прецедент IssueFine вводится и в точкеReturnBookextension pointsoverdueBookpayFine«extend»condition: {первое нарушение}extension points:overdueBookIssueWarningусловие«extend»condition: {!первое нарушение}extension points:overdueBook, payFineIssueFineРис. 5.14. Добавление условного расширяющего прецедентаРасширяющий прецедент: IssueWarningID: 11Краткое описание:Сегмент 1: Librarian выдает предупреждение.Главные актеры:LibrarianВторостепенные актеры:Нет.Сегмент 1 предусловия:1. Возвращенная книга просрочена.Поток сегмента 1:1.

Librarian вводит данные предупреждения в систему.Сегмент 1 постусловия:1. Предупреждение записано в системе.Рис. 5.15. Описание условного расширяющего прецедента5.6. Когда применять дополнительные возможности133overdueBook, и в точке payFine (выплатить штраф). Это свидетельствуето том, что IssueWarning (рис. 5.15) содержит только один сегмент вставки, тогда как IssueFine (как мы уже видели) – два.5.6. Когда применять дополнительныевозможностиПрименяйте дополнительные возможности, только если они упрощаютмодель и делают ее более понятной.Применяйте дополнительные возможности, только если они упрощают модель прецедентов. Мы вновь убеждаемся в том, что лучшие модели прецедентов – это простые модели.

Запомните, что модель прецедентов – это изложение требований, то есть она должна быть понятнойне только разработчикам моделей, но и заинтересованным сторонам.Простая модель прецедентов, в которой дополнительные возможностиприменяются редко или вообще отсутствуют, предпочтительнее модели, переполненной дополнительными возможностями, даже если последняя кажется разработчику более изысканной.Учитывая опыт моделирования прецедентов в различных компаниях,можно сделать следующие выводы:• обычно заинтересованные стороны после небольшой тренировкии обучения могут без труда разбираться в актерах и прецедентах;• заинтересованным сторонам сложнее воспринимать обобщение актеров;• широкое использование отношения «include» затрудняет пониманиемоделей прецедентов – заинтересованным сторонам и разработчикам моделей приходится рассматривать несколько прецедентов дляполучения полной картины;• у заинтересованных сторон возникают большие сложности с пониманием отношения «extend» даже после подробных объяснений;• как это ни удивительно, многие разработчики объектных моделейневерно понимают семантику отношения «extend»;• обобщение прецедентов следует применять, только если в системеиспользуются абстрактные (а не конкретные) родительские прецеденты, в противном случае это сильно усложняет дочерние прецеденты.5.7.

Советы и рекомендации по написаниюпрецедентовВ данном разделе предлагается несколько советов и рекомендацийпо написанию прецедентов.134Глава 5. Дополнительные аспекты моделирования прецедентов5.7.1. Делайте прецеденты короткими и простымиОсновной девиз: «Делайте прецеденты короткими, делайте их простыми». Они должны включать именно такой объем информации, которого достаточно для записи требований. К сожалению, в некоторых проектах разработчики избегают простого и сжатого изложения и стремятся к непомерному увеличению объема документации.

Гради Бучназывает эту тенденцию «бумажной жадностью».Есть хорошее правило: основной поток прецедента должен помещаться на одной странице. Немного больше, и прецедент практически наверняка окажется слишком длинным. В реальности большинство прецедентов короче половины страницы.Начать надо с упрощения фраз (использовать только короткие повествовательные предложения, как описано в разделе 3.6.2). Затем удалить все детали проектирования (см.

следующий раздел). Если прецедент попрежнему слишком велик, необходимо повторно проанализировать проблему. Вероятно, прецедент можно разбить на несколькопрецедентов либо выделить альтернативные потоки.5.7.2. Фокусируйтесь на том «что», а не «как»Помните, прецеденты создаются для того, чтобы понять, чего актерыждут от системы, а не как она должна это осуществлять. «Как» становится ясно позже, при проектировании. Смешение «что» с «как» является повсеместной проблемой.

Разработчик, работая над прецедентом,придумывает какоето решение. Рассмотрим, к примеру, следующийфрагмент прецедента:...4. Система просит Покупателя подтвердить заказ.5. Покупатель нажимает кнопку OK....В данном примере разработчик прецедента представил себе некийпользовательский интерфейс: форму с кнопкой «ОК». Изза этого прецедент перестал быть простым изложением требований, это первичный проект. Лучше записать шаг 5 следующим образом:...5.

Покупатель соглашается с заказом....Детали проектирования (которые пока неизвестны!) должны оставаться вне прецедента.5.7.3. Избегайте функциональной декомпозицииФункциональная декомпозиция не подходит для моделей прецедентов.1355.7. Советы и рекомендации по написанию прецедентовLibrarySystemИзбегайте функциональнойдекомпозиции«include»AddBookMaintainBooks«include»DeleteBook«include»AddTicket«include»«include»RunLibraryMaintainTicketsLibrarian«include»DeleteTicket«include»LendBook«include»MaintainLoans«include»ReturnBookРис.

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

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