UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
99 ты должны быть полностью исключены из моделей. Это обусловле но тем, что разрешение на применение синонимов может привести к возникновению двух более или менее одинаковых классов с раз ными именами. Кроме того, если позволить эпизодическое употреб ление всех синонимов, можно с уверенностью ожидать, что семан тика терминов со временем будет отличаться. • Омонимы – это слова, одинаковые по звучанию, но разные по значе нию. В этом случае всегда возникают проблемы общения, посколь ку разные стороны говорят на разных языках, но при этом уверены, что говорят об одном и том же. Способ решения – выбрать одно зна чение для определенного термина, а для других омонимов, возмож но, ввести новые термины. В глоссарии проекта должен быть указан предпочтительный термин и под его определением перечислены все синонимы. При этом, вероят но, некоторым деловым партнерам придется привыкать к другой тер минологии. Обычно тяжело заставить заинтересованные стороны из менить используемый ими язык, но при некоторой настойчивости это го удается добиться. UML не устанавливает каких либо стандартов для глоссария проекта. Лучше всего, если глоссарий будет максимально простым и кратким. Можно применять формат словаря с сортировкой слов и выражений по алфавиту. Возможно, будет достаточно простого текстового докумен та, но для больших проектов может потребоваться сетевой глоссарий в формате HTML/XML или даже в виде несложной базы данных. За помните, что чем глоссарий понятней и проще в использовании, тем сильнее его положительное влияние на проект. Часть примера глоссария проекта приведена в табл. 4.1. Если у слова нет синонимов или омонимов, это явно указывается словом «нет» (поле не оставляется пустым). Такой прием подчеркивает, что данный вопрос был рассмотрен. Это придает глоссарию хороший стиль. Термины и определения глоссария проекта также будут использовать ся в модели UML. Необходимо гарантировать, что эти два документа синхронизированы. К сожалению, большинство инструментальных средств моделирования UML не обеспечивают какой либо поддержки синхронизации модели UML и глоссария, поэтому подобная синхро низация обычно выполняется вручную. Таблица 4.1. Глоссарий проекта для Clear View Training ECP (платформа для электронной торговли) Термин Определение Catalog Список всех продуктов, имеющихся в продаже в Clear View Training в настоящее время. Синонимы: нет Омонимы: нет 100 Глава 4. Моделирование прецедентов Таблица 4.1 (продолжение) 4.4. Деятельность UP: Детализация прецедента После создания диаграммы прецедентов и выявления актеров и клю чевых прецедентов приступают к точному определению каждого пре цедента по очереди. Эту деятельность UP известна как Детализация пре цедента (рис. 4.7). Термин Определение Checkout Электронный аналог реальной кассы супермаркета. Место, где покупатели могут оплатить продукты, нахо дящиеся в их корзине для покупок. Синонимы: нет Омонимы: нет Clear View Training Компания с ограниченной ответственностью, специали зирующаяся на продаже книг и CD. Синонимы: CVT Омонимы: нет Credit card Карточка, например VISA или Mastercard, которая мо жет использоваться для оплаты. Синонимы: карточка Омонимы: нет Customer Сторона, покупающая продукты или сервисы у Clear View Training. Синонимы: нет Омонимы: нет Составитель спецификации прецедентов Детализация прецедента Модель прецедентов [в общих чертах] Глоссарий проекта Прецедент [детализированный] Модель требований Рис. 4.7. Деятельность UP: Детализация прецедента. Адаптировано с рис. 7.1 [Jacobson 1] с разрешения издательства Addison Wesley 4.5. Спецификация прецедентов 101 Здесь важно отметить, что некоторые или все прецеденты можно опи сывать по мере их выявления, не соблюдая строгой очередности. На против, в книге всегда очень сложно представить параллельную дея тельность, поскольку книга по природе своей линейна! Итог этой деятельности – более детализированный прецедент. Сюда входят, по крайней мере, имя прецедента и его спецификация. 4.5. Спецификация прецедентов UML стандарта для спецификации прецедента не существует. Однако широко используется шаблон, приведенный на рис. 4.8. Есть и более сложные шаблоны, но из собственного опыта мы знаем, что при моде лировании прецедентов лучше всего придерживаться максимальной простоты. Выберите стандарт для спецификации прецедентов. Важно, чтобы организация выбрала стандарт для спецификаций преце дентов, который будет постоянно использоваться в проектах. Отсутствие таких стандартов в компании делает весь процесс моделирования преце дентов излишне сложным. В рамках одного проекта возникает масса разных форматов, уровней детализации или даже интерпретаций того, что является, а что не является прецедентом. Простой и эффективный стандарт для спецификаций прецедентов может помочь обеспечить ус Прецедент: PaySalesTax Главные актеры: Time (Время) Предусловия: 1. Конец налогового периода. Постусловия: 1. Налоговое управление получает соответствующую сумму Налога с оборота. Основной поток: 1. Прецедент начинается в конце налогового периода. 2. Система определяет сумму Налога с оборота, которую необходимо выплатить Налоговому управлению. 3. Система посылает электронный платеж в Налоговое управление. имя прецедента актеры, вовлеченные в прецедент состояние системы до начала прецедента фактические этапы прецедента состояние системы после окончания прецедента Альтернативные потоки: Нет. альтернативные потоки ID: 1 идентификатор прецедента Краткое описание: Выплата налога с оборота в Налоговое управление по окончанию налогового периода. краткое описание неявный актер Time Второстепенные актеры: TaxAuthority (налоговое управление) Рис. 4.8. Шаблон спецификации прецедента 102 Глава 4. Моделирование прецедентов пешный анализ прецедентов. В этой и следующей главах мы предлагаем такой стандарт. В наш шаблон простой спецификации прецедента входит следующая информация: • имя прецедента; • ID прецедента; • краткое описание – абзац, в котором изложена цель прецедента; • актеры, задействованные в прецеденте; • предусловия – условия, которые должны выполниться, чтобы пре цедент мог осуществиться; это ограничения на состояние системы; • основной поток – шаги выполнения прецедента; • постусловия – условия, которые должны выполниться по оконча нию прецедента; • альтернативные потоки – список альтернативных основному пото ку событий. Позже, когда будут рассматриваться более сложные прецеденты, этот шаблон будет расширен для включения дополнительной информации. Прецедент, представленный на рис. 4.8, касается выплаты Налога с обо рота – формы налога, взимаемого с продаж во многих странах. В дан ном примере Налоговое управление в любом случае тем или иным об разом получает соответствующую сумму налога. Поэтому факт полу чения денег здесь заявлен как постусловие прецедента. Записывайте прецеденты на структурированном естественном языке. Хороший способ записи прецедента – «структурированный англий ский» (или русский, или любой другой язык, являющийся для вас род ным). В следующих разделах будет представлен простой стиль, кото рый можно использовать для эффективного выражения прецедентов. 4.5.1. Имя прецедента Не существует UML стандарта по присваиванию имен прецедентам. Мы всегда записываем имена прецедентов в стиле UpperCamelCase: от дельные слова имени прецедента записываются слитно, каждое слово начинается с заглавной буквы. Прецеденты описывают поведение системы, поэтому имя прецедента всегда должно быть глаголом или глагольной группой, например Pay SalesTax (выплата налога с оборота). Всегда надо стремиться выбрать имя, короткое и описательное одновременно. Человек, работающий с моделью прецедентов, должен по одному его имени четко понимать назначение моделируемой бизнес функции или процесса. В этой и сле дующих главах можно найти множество примеров имен прецедентов. 4.5. Спецификация прецедентов 103 Имя прецедента является его уникальным идентификатором в рамках модели прецедентов. 4.5.2. ID прецедента Хотя имена прецедентов в рамках одной модели прецедентов должны быть уникальными, со временем они могут меняться. Следовательно, надо ввести другой постоянный идентификатор, уникально идентифи цирующий конкретный прецедент в проекте. Обычно мы используем просто число. При работе с альтернативными потоками (раздел 4.5.7) можно приме нять иерархическую систему нумерации. В этом случае легко устанав ливается взаимосвязь между альтернативным и основным потоками. Например, если прецедент стоит под номером X, его альтернативные потоки будут пронумерованы как X.1, X.2,..., X.n. 4.5.3. Краткое описание Это должен быть один абзац, в котором изложена цель прецедента. По пытайтесь уловить суть прецедента – прикладное значение, которое он имеет для актеров. 4.5.4. Актеры Главные актеры инициируют прецедент. С точки зрения отдельного прецедента существует два типа актеров: • главные актеры – актеры, инициирующие прецедент; • второстепенные актеры – актеры, взаимодействующие с прецеден том после его инициации. Второстепенные актеры не инициируют прецедент. Каждый прецедент всегда инициируется одним актером. Однако один и тот же прецедент в разные моменты времени может инициироваться разными актерами. Любой актер, который может инициировать пре цедент, является главным актером. Все остальные актеры – второсте пенные. 4.5.5. Предусловия и постусловия Предусловия и постусловия – это ограничения. • Предусловия ограничивают состояние системы, необходимое для запуска прецедента. Они как привратники, которые не дают актеру инициировать прецедент до тех пор, пока не будут выполнены все их условия. 104 Глава 4. Моделирование прецедентов • Постусловия ограничивают состояние системы после выполнения прецедента. Предусловия ограничивают состояние системы, необходимое для запус ка прецедента. Постусловия ограничивают состояние системы после выполнения прецедента. На это можно посмотреть по другому. Предусловия определяют усло вия, которые должны быть истинными для того, чтобы прецедент мог быть инициирован. Постусловия определяют, какие условия будут ис тинными после выполнения прецедента. Предусловия и постусловия помогают спроектировать правильно функционирующую систему. Предусловия и постусловия должны быть простыми выражениями о состоянии системы, которые затем определяются как истинные или ложные. Их называют логическими условиями. Если прецедент не имеет предусловий или постусловий, хорошим сти лем считается надпись «Нет» в соответствующих разделах специфика ции прецедента. Это показывает, что данный вопрос был рассмотрен, иначе незаполненный раздел указывает на некоторую двусмыслен ность. 4.5.6. Основной поток Основной поток описывает «идеальный» ход развития событий в преце денте. Этапы прецедента представляются в виде потока событий. Прецедент можно представить как дельту реку с множеством ответвляющихся рукавов. У каждого прецедента есть один основной поток (основной рукав дельты). Остальные, меньшие рукава – это альтернативные по токи прецедента. Эти альтернативные потоки могут перехватывать ошибки, ответвления и прерывания основного потока. Основной поток иногда называют основным сценарием (primary scenario), а альтерна тивные потоки – второстепенными сценариями (secondary scenarios). Основной поток регистрирует этапы прецедента, отражающие «иде альную» ситуацию, когда все идет, как ожидается и хочется, то есть не возникает ошибок, отклонений, прерываний или ответвлений. Отклонения от основного потока можно смоделировать двумя способа ми, которые вскоре будут рассмотрены. 1. Простые отклонения – создаются ветвления основного потока (раз дел 4.5.6.1). 2. Сложные отклонения – создаются альтернативные потоки (раздел 4.5.7). 4.5. Спецификация прецедентов 105 Основной поток всегда начинается с действий главного актера, на правленных на инициацию прецедента. Удачным способом начала по тока можно считать следующую форму записи: 1. Прецедент начинается, когда <актер> <действие>. Помните, что время тоже может быть актером, поэтому прецедент мо жет начинаться временным выражением, как на рис. 4.8. Поток событий состоит из последовательности коротких этапов, декла ративных, пронумерованных и упорядоченных во времени. Каждый этап потока прецедента должен быть выражен в следующей форме: <номер> <кто либо> <совершает некоторое действие>. Поток событий прецедента может быть представлен в повествователь ной форме, однако это не рекомендуется, поскольку данная форма яв ляется слишком неопределенной. Ниже приведен пример нескольких этапов прецедента PlaceOrder (раз местить заказ). 1. Прецедент запускается, когда покупатель выбирает опцию «разместить заказ». 2. Покупатель заполняет в форме свои имя и адрес. Это правильно сформированные прецеденты. В обоих случаях мы име ем простое декларативное выражение о том, что некоторая сущность осуществляет некоторое действие. А вот пример неверного описания этапа прецедента: 2. Вводятся данные покупателя. Использование пассивного залога для описания любого этапа является неверным. На этом конкретном этапе фактически допущены три важ ных пропуска. • Кто вводит данные покупателя? • Куда вводятся эти данные? • Что конкретно подразумевается под «данными покупателя»? Важно различать и избегать пропусков при написании потоков преце дентов, даже если об этом можно сказать или догадаться исходя из контекста. Прецедент должен быть точным описанием части выпол няемых функций системы! Если в процессе анализа встречаются неопределенности, пропуски или обобщения, полезно ставить следующие вопросы. • Кто именно…? • Что именно…? • Когда именно …? • Где именно …? 106 Глава 4. Моделирование прецедентов 4.5.6.1. Ветвление потока Спецификация UML не определяет способа представления ветвления потока. Мы пользуемся идиомой, которая позволяет представить ветвление простым способом без записи отдельного альтернативного потока. Для этого используется ключевое слово Если (If). Ветвление потока можно сократить, уменьшая число прецедентов, но пользоваться этим надо умеренно! Стоит отметить, что некоторые разработчики моделей прецедентов вы ступают против ветвления в прецедентах. Они утверждают, что если есть ответвление, значит, должен быть описан новый альтернативный поток. Строго говоря, этот аргумент заслуживает внимания. Однако мы занимаем более пракматичную позицию и считаем, что небольшое простое ветвление потока допустимо, потому что оно сокращает общее число альтернативных потоков и обеспечивает более компактное пред ставление требований. 4.5.6.2. Ключевое слово Если (If) Для представления ответвления потока используйте ключевое слово Если (If). Пример, приведенный на рис. 4.9, показывает хорошо структу рированный поток событий с двумя ветвями. Каждая ветвь начинается Прецедент: ManageBasket Главные актеры: Покупатель Предусловия: 1. Содержимое корзины для покупок является видимым. Постусловия: Нет. Основной поток: 1. Прецедент начинается, когда Покупатель выбирает товарную позицию в корзине. 2. Если Покупатель выбирает «удалить позицию». 2.1. Система удаляет позицию из корзины. 3. Если Покупатель вводит новое количество. 3.1. Система обновляет количество товаров в корзине. ID: 2 Краткое описание: Покупатель меняет количество товаров в корзине. Альтернативные потоки: Нет. Второстепенные актеры: Нет. Рис. 4.9. Прецедент с двумя ветвлениями 4.5. Спецификация прецедентов 107 с ключевого слова Если и простого логического выражения, такого как Если пользователь вводит новое количество, которое может быть истинным ( true) или ложным (false). Структурированный текст под выражением Ес ли – это то, что произойдет, если логическое выражение истинно. С по мощью отступов и нумерации можно четко обозначить тело выраже ния Если без использования слов конец если (endif) или другого заверша ющего выражение синтаксиса. Поскольку события ветвления могут произойти, а могут и не произой ти в зависимости от обстоятельств, они не могут генерировать постус ловия, которые должны выполняться обязательно. Поэтому ветвление может сократить число постусловий прецедента. 4.5.6.3. Повторение в потоке Иногда некоторое действие в потоке событий необходимо повторить несколько раз. В моделировании прецедентов это встречается не часто, но на всякий случай полезно иметь некоторую стратегию для обработ ки таких вариантов. Спецификация UML не определяет способа представления повторений в потоке, поэтому мы предлагаем простые выражения с ключевыми словами Для (For) и Пока (While). 4.5.6.4. Ключевое слово Для (For) Смоделировать повторение можно с помощью ключевого слова Для. Формат следующий: n. Для (выражение, описывающее итерации) n.1. Сделать что то n.2. Сделать что то другое n.3. … n+1. Выражение, описывающее итерации, – это некоторое выражение, ре зультат которого – количество итераций. Каждая структурированная строка после выражения Для повторяется столько раз, сколько опреде лено в выражении. Пример приведен на рис. 4.10. 4.5.6.5. Ключевое слово Пока (While) Ключевое слово Пока (While) используется для моделирования последо вательности действий в потоке событий, которые осуществляются до тех пор, пока некоторое логическое условие истинно. Формат в данном случае следующий: n. Пока (логическое условие) n.1. Сделать что то n.2. Сделать что то другое n.3. … n+1. |