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

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

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

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Рис. 5.16. Пример функциональной декомпозицииПри анализе прецедентов широко встречается следующая ошибка:создается ряд «высокоуровневых» прецедентов, которые затем разбиваются на ряд прецедентов более низкого уровня и т. д.

до «элементарных» прецедентов, достаточно детализированных для реализации. Такой подход к разработке программного обеспечения называется функциональной декомпозицией. Он абсолютно ошибочен в применениик моделированию прецедентов.Рассмотрим пример. На рис. 5.16 аналитик описал работу библиотечной системы с помощью одного высокоуровневого прецедента RunLibrary (управление библиотекой). Затем путем функциональной декомпозиции разложил его на все более и более детализированные уровни.Многим неОО аналитикам рис.

5.16 кажется вполне приемлемым.Однако с точки зрения моделирования прецедентов в предложенномпримере содержится много ошибок:•Модель сосредоточена не на фиксировании требований, а на искусственном структурировании этих требований – существует множество возможных вариантов декомпозиции.•Модель описывает систему как набор вложенных функций. ОднакоОО системы в действительности являются наборами взаимодействующих объектов, обменивающихся сообщениями. Здесь очевидное концептуальное несоответствие.136Глава 5. Дополнительные аспекты моделирования прецедентов••Интерес представляют только описания прецедентов самого низкого уровня: AddBook (добавить книгу), DeleteBook (удалить книгу), AddTicket (добавить формуляр), DeleteTicket (удалить формуляр), LendBook(выдать книгу) и ReturnBook (вернуть книгу).

Более высокие уровнипросто вызывают нижние и ничего не привносят в модель с точкизрения отражения требований.Модель сложна и непонятна заинтересованным сторонам: в ней несколько абстрактных прецедентов (RunLibrary, MaintainBooks (обслуживание книг), MaintainTickets (обслуживание формуляров) и MaintainLoans (обслуживание выдачи книг)) и много отношений «include»с более низкими уровнями абстракции.Применение функциональной декомпозиции говорит о том, что аналитик неправильно продумал систему. Обычно это свидетельствует о том,что он обучен более традиционным методам процедурного программирования и пока что не уловил принципа ОО программирования. В этомслучае лучше привлечь опытного разработчика моделей прецедентовв качестве руководителя и консультанта.Не все примеры функциональной декомпозиции так очевидны, какприведенный на рис.

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

Что мы узналиМы изучили приемы углубленного моделирования прецедентов. Основная задача моделирования – создать простую понятную модельпрецедентов, в которой вся необходимая информация представленамаксимально четко и лаконично. Модель прецедентов, не использующая расширенные возможности, всегда предпочтительнее той, где такмного обобщений, отношений «include» и «extend», что невозможно понять, о чем идет речь.

Здесь лучшее правило: «Если сомневаешься, невключай».Мы узнали следующее:• Обобщение актеров обеспечивает возможность вынести поведение,общее для двух или более актеров, в актерародителя.• Актерродитель является более обобщенным, чем его потомки,а потомки – более специализированными, чем их родитель.• Дочерний актер везде может заменять актерародителя – этопринцип замещаемости.5.8. Что мы узнали••••137Актерродитель обычно абстрактный – он определяет абстрактную роль.• Дочерние актеры конкретны – они определяют конкретные роли.• Обобщение актеров может упрощать диаграммы прецедентов.Обобщение прецедентов позволяет вынести возможности, общиедля двух или более прецедентов, в родительский прецедент.• Дочерние прецеденты наследуют все возможности родительскихпрецедентов.• Дочерние прецеденты могут вводить новые возможности.• Дочерние прецеденты могут переопределять родительские возможности за исключением отношений и точек расширения.• В дочерних прецедентах мы применяем простые обозначения:• унаследованный без изменений – 3.

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

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