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

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

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

Этот блок является контекстом и,как упоминалось в разделе 4.3.1, он представляет границу системы,98Глава 4. Моделирование прецедентовмоделируемую прецедентами. Актеры располагаются вне контекста(они внешние по отношению к системе), а прецеденты, составляющиеповедение системы, располагаются внутри контекста (они внутренниепо отношению к системе). Это проиллюстрировано на рис. 4.6.Отношение между актером и прецедентом обозначается сплошной линией. Это символ ассоциации в UML.

Ассоциациям посвящена глава 9. Ассоциация между актером и прецедентом показывает, что актер и прецедент какимто образом взаимодействуют.имя контекста системыMail order systemграница системыотношениевзаимодействияPlaceOrderCancelOrderShipProductShippingCompanyCustomerCheckOrderStatusпрецедентактерRequestCatalogDispatcherРис. 4.6. Диаграмма прецедентов4.3.4. Глоссарий проектаВ глоссариий проекта должна быть отражена бизнестерминологияи жаргон.Глоссарий проекта – возможно, один из самых важных артефактовпроекта.

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

Остальные вариан4.3. Деятельность UP: Выявление актеров и прецедентов99ты должны быть полностью исключены из моделей. Это обусловлено тем, что разрешение на применение синонимов может привестик возникновению двух более или менее одинаковых классов с разными именами. Кроме того, если позволить эпизодическое употребление всех синонимов, можно с уверенностью ожидать, что семантика терминов со временем будет отличаться.•Омонимы – это слова, одинаковые по звучанию, но разные по значению. В этом случае всегда возникают проблемы общения, поскольку разные стороны говорят на разных языках, но при этом уверены,что говорят об одном и том же.

Способ решения – выбрать одно значение для определенного термина, а для других омонимов, возможно, ввести новые термины.В глоссарии проекта должен быть указан предпочтительный термини под его определением перечислены все синонимы. При этом, вероятно, некоторым деловым партнерам придется привыкать к другой терминологии. Обычно тяжело заставить заинтересованные стороны изменить используемый ими язык, но при некоторой настойчивости этого удается добиться.UML не устанавливает какихлибо стандартов для глоссария проекта.Лучше всего, если глоссарий будет максимально простым и кратким.Можно применять формат словаря с сортировкой слов и выражений поалфавиту. Возможно, будет достаточно простого текстового документа, но для больших проектов может потребоваться сетевой глоссарийв формате HTML/XML или даже в виде несложной базы данных.

Запомните, что чем глоссарий понятней и проще в использовании, темсильнее его положительное влияние на проект.Часть примера глоссария проекта приведена в табл. 4.1. Если у слованет синонимов или омонимов, это явно указывается словом «нет» (полене оставляется пустым). Такой прием подчеркивает, что данный вопросбыл рассмотрен. Это придает глоссарию хороший стиль.Термины и определения глоссария проекта также будут использоваться в модели UML.

Необходимо гарантировать, что эти два документасинхронизированы. К сожалению, большинство инструментальныхсредств моделирования UML не обеспечивают какойлибо поддержкисинхронизации модели UML и глоссария, поэтому подобная синхронизация обычно выполняется вручную.Таблица 4.1.

Глоссарий проекта для Clear View Training ECP(платформа для электронной торговли)ТерминОпределениеCatalogСписок всех продуктов, имеющихся в продаже в ClearView Training в настоящее время.Синонимы: нетОмонимы: нет100Глава 4. Моделирование прецедентовТаблица 4.1 (продолжение)ТерминОпределениеCheckoutЭлектронный аналог реальной кассы супермаркета.Место, где покупатели могут оплатить продукты, находящиеся в их корзине для покупок.Синонимы: нетОмонимы: нетClear View Training Компания с ограниченной ответственностью, специализирующаяся на продаже книг и CD.Синонимы: CVTОмонимы: нетCredit cardКарточка, например VISA или Mastercard, которая может использоваться для оплаты.Синонимы: карточкаОмонимы: нетCustomerСторона, покупающая продукты или сервисы у ClearView Training.Синонимы: нетОмонимы: нет4.4. Деятельность UP: Детализация прецедентаПосле создания диаграммы прецедентов и выявления актеров и ключевых прецедентов приступают к точному определению каждого прецедента по очереди.

Эту деятельность UP известна как Детализация прецедента (рис. 4.7).Модель прецедентов[в общих чертах]Составитель спецификациипрецедентовМодель требованийДетализацияпрецедентаПрецедент[детализированный]Глоссарий проектаРис. 4.7. Деятельность UP: Детализация прецедента. Адаптировано с рис. 7.1[Jacobson 1] с разрешения издательства Addison+Wesley1014.5. Спецификация прецедентовЗдесь важно отметить, что некоторые или все прецеденты можно описывать по мере их выявления, не соблюдая строгой очередности. Напротив, в книге всегда очень сложно представить параллельную деятельность, поскольку книга по природе своей линейна!Итог этой деятельности – более детализированный прецедент. Сюдавходят, по крайней мере, имя прецедента и его спецификация.4.5.

Спецификация прецедентовUMLстандарта для спецификации прецедента не существует. Однакошироко используется шаблон, приведенный на рис. 4.8. Есть и болеесложные шаблоны, но из собственного опыта мы знаем, что при моделировании прецедентов лучше всего придерживаться максимальнойпростоты.Выберите стандарт для спецификации прецедентов.Важно, чтобы организация выбрала стандарт для спецификаций прецедентов, который будет постоянно использоваться в проектах. Отсутствиетаких стандартов в компании делает весь процесс моделирования прецедентов излишне сложным.

В рамках одного проекта возникает массаразных форматов, уровней детализации или даже интерпретаций того,что является, а что не является прецедентом. Простой и эффективныйстандарт для спецификаций прецедентов может помочь обеспечить усимя прецедентаидентификатор прецедентакраткое описаниеактеры, вовлеченныев прецедентсостояние системыдо начала прецедентаПрецедент: PaySalesTaxID: 1Краткое описание:Выплата налога с оборота в Налоговое управление по окончанию налогового периода.Главные актеры:Time (Время)Второстепенные актеры:TaxAuthority (налоговое управление)Предусловия:1.

Конец налогового периода.Основной поток:фактические этапыпрецедентасостояние системы послеокончания прецедентаальтернативные потокинеявный актер Time1. Прецедент начинается в конце налогового периода.2. Система определяет сумму Налога с оборота, которую необходимо выплатитьНалоговому управлению.3. Система посылает электронный платеж в Налоговое управление.Постусловия:1. Налоговое управление получает соответствующую сумму Налога с оборота.Альтернативные потоки:Нет.Рис.

4.8. Шаблон спецификации прецедента102Глава 4. Моделирование прецедентовпешный анализ прецедентов. В этой и следующей главах мы предлагаемтакой стандарт.В наш шаблон простой спецификации прецедента входит следующаяинформация:•имя прецедента;••ID прецедента;краткое описание – абзац, в котором изложена цель прецедента;••актеры, задействованные в прецеденте;предусловия – условия, которые должны выполниться, чтобы прецедент мог осуществиться; это ограничения на состояние системы;••основной поток – шаги выполнения прецедента;постусловия – условия, которые должны выполниться по окончанию прецедента;•альтернативные потоки – список альтернативных основному потоку событий.Позже, когда будут рассматриваться более сложные прецеденты, этотшаблон будет расширен для включения дополнительной информации.Прецедент, представленный на рис.

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

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

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