Институт управления, бизнеса и права учебно-методический комплекс (стр. 3 )

1.  Внешнее представление, когда моделируется окружение или рабочая среда системы.

2.  Описание поведения системы, когда моделируется ее поведение.

3.  Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой.

Такие методы как структурный анализ и объектно-ориентированный анализ, обеспечивают основу для детального моделирования системы как части процесса постановки и анализа требований. Большинство структурных методов работают с определенными типами системных моделей.

Практическая разработка требований не должна ограничиваться только моделями, построенными с помощью тех или иных методов. Например, объектно-ориентированные методы обычно не предполагают применения для разработки моделей потоков данных. Однако такие модели полезны для объектно-ориентированного анализа, поскольку отражают понимание системы пользователей и могут помочь идентифицировать объекты и действия с ними.

Различные типы системных моделей основаны на разных подходах к абстракции:

1.  Модель обработки данных. Диаграммы потоков данных показывают последовательность обработки данных в системе.

2.  Композиционная модель. Диаграммы «сущность-связь» показывают, как системные сущности составляются из других сущностей.

3.  Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.

4.  Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики.

5.  Модель «стимул-реакция». Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.

Спецификация требований часто пишутся естественным языком, тем не менее, разработаны методы описания требований, которые структурируют спецификацию и уменьшают размытость определений: графические нотации, языки описания программ, структурированный язык спецификаций. Результатом спецификации становится документ, содержащий предварительные требования к системе.

Спецификация требований является последним этапом формирования требований. Она позволяет собрать воедино и упорядочить все требования, полученные на этапах сбора и моделирования требований.

Традиционно при описании требований использовались электронные таблицы Excel, текстовые процессоры класса Word или текстовые редакторы, такие как Framemaker, Tex, Latex. Современные методики рекомендуют использовать XML-формат для представления документа, содержащего описание требований.

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

Во время процесса аттестации требований должны быть выполнены различные типы проверок документации требований:

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

2.  Проверка на непротиворечивость. Спецификация требований не должна содержать противоречий. Это означает, что в требованиях не должно быть противоречащих друг другу ограничений или различных описаний одной и той же системной функции.

3.  Проверка на полноту. Спецификация требований должна содержать требования, которые определяют все системные функции и ограничения, накладываемые на систему.

4.  Проверка на выполнимость. На основе знания существующих технологий требования должны быть проверены на возможность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы.

Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности:

1.  Обзор требований. Обзор требований – это процесс просмотра системной спецификации для нахождения неточных описаний и ошибок. К этому процессу привлекается большое количество лиц, как со стороны заказчика, так и со стороны разработчиков. Обнаруженные во время обзора противоречия, ошибки и упущения в требованиях должны быть зафиксированы документально.

2.  Прототипирование. Прототип является начальной версией программной системы, которая используется для демонстрации концепций, заложенных в системе, проверки вариантов требований, а также поиска проблем, которые могут в ходе разработки и эксплуатации системы. Прототип ПО помогает на двух этапах процесса разработки системных требований: постановки и проверки требований. На этапе постановки требований пользователи могут экспериментировать с системными прототипами, что позволяет им проверять, как будет работать система. В результате могут сформироваться новые требования. На этапе проверки требований прототип позволяет обнаружить ошибки и упущения в ранее принятых требованиях.

3.  Генерация тестовых сценариев. Требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить проблемы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить и необходимо пересмотреть.

4.  Автоматизированный анализ непротиворечивости. Если требования представлены с использованием инструментальных CASE-средств, то можно выполнить автоматизированный анализ непротиворечивости. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в ней. Анализатор требований готовит отчет обо всех обнаруженных противоречиях.

3. Документирование требований

Документ, содержащий требования, также называется спецификацией системных требований, - это официальное предписание для разработчиков программной системы. Он содержит пользовательские требования и детализированное описание системных требований.

Многие организации, такие как, Министерство обороны США и Институт инженеров по электротехнике и радиоэлектронике IEEE, разработали собственные стандарты документирования спецификаций. Наиболее известный стандарт IEEE/ANSI . Данный стандарт предполагает следующую структуру спецификации.

1. Введение

1.1. Цели документа

1.2. Назначение программного продукта

1.3. Определения и аббревиатуры

1.4. Список литературы и других источников

1.5. Обзор спецификации

2. Общее описание

2.1. Описание программного продукта

2.2. Функции программного продукта

2.3. Пользовательские характеристики

2.4. Общие ограничения

2.5. Обоснования, предположения и допущения

3. Спецификация требований охватывает функциональные, нефункциональные и интерфейсные требования.

В таблице описаны возможные варианты спецификации, построенной на основе стандарта IEEE.

Таблица 2.1. Структура спецификации требований

Раздел	Описание
Предисловие	Определяется круг лиц, на который рассчитан данный документ. Описываются предыдущие версии разрабатываемого продукта, а также изменения, внесенные в каждую версию. Дается обоснование для создания новой версии продукта.
Введение	Развернуто обосновывается необходимость создания системы. Перечисляются системные функции. Показывается, как разработка системы соответствует бизнес-стратегии компании-заказчика
Глоссарий	Дается описание технических терминов, используемых в документе
Пользовательские требования	Описываются сервисы, предоставляемые пользователем и нефункциональные системные требования
Системная архитектура	Приводится высокоуровневое представление возможной системной архитектуры с указанием, как распределены системные функции по компонентам системы. Обязательно должны быть выделены повторно используемые (уже существующие) компоненты
Системные требования	Описываются функциональные и нефункциональные требования
Системные модели	Представляются объектные модели, модели потоков данных и др.
Эволюция системы	Приводятся основные предположения и допущения, на которых базируется система, а также ожидаемые (прогнозируемые) изменения в аппаратных средствах, потребностях пользователя и др.
Приложения	Приводится специализированная информация, относящаяся к разрабатываемой системе, например, описание аппаратных средств или базы данных, с которыми должна работать системы.
Указатели	Приводятся алфавитный указатель, указатель диаграмм или системных функций

Хота стандарт IEEE не идеален, он может служить отправной точкой при написании спецификации. Конечно, необходимо также учитывать стандарты, принятые в организации – разработчике ПО.

Лекция 3. Стадия анализа при разработке Web-приложений

План

1. Анализ прецедентов

2. Стадия анализа

3. Диаграммы последовательностей

4. Диаграммы сотрудничества

5. Диаграммы видов деятельности

Содержание

1. Анализ прецедентов

Анализ прецедентов является иным видом деятельности, выполнение которого не­обходимо обеспечить на завершающей стадии описания прецедентов. В процессе ICONIX этот вид деятельности называется анализом робастности, который является неотъемлемой частью всего процесса. При анализе прецедента ре­шаются следующие задачи.

■ Идентификация классов и объектов, которые будут ответственны за выполнение последовательности событий, описанных в прецеденте.

■ Идентификация обязанностей, атрибутов и ассоциаций классов.

■ Формулировка возможности использования определенных механизмов, обеспе­чиваемых выбранной архитектурой.

В унифицированном процессе RUP основными результатами анализа прецедента является набор его реализаций и объекты уровня анализа (analysis-level object). Реали­зация каждого прецедента представляет собой набор диаграмм последовательностей, диаграмм классов и текстовых документов, которые в терминах объектов описывают, как данный прецедент выполняется в системе. Реализация прецедента является шаб­лоном, который конкретизирует типичный ход событий прецедента. Связь "реализует" (realizes) связывает прецедент с его реализацией. Все диаграммы последовательностей и кооперации классов описывают, как прецедент выполняется в системе в соответствии с его реализацией, а не исходным описанием.

Классы анализа можно отнести к одному из трех типов: граничные (boundary), моделирующие сущности предметной области (entity) и управляющие (control).

Граничные объекты (boundary objects) обеспечивают интерфейс между испол­нителем и системой. Обычно экземпляры этих объектов представляют собой диалоговые окна ввода данных или специальные элементы управления поль­зовательского интерфейса. В Web-приложениях такие объекты могут пред­ставлять целые Web-страницы.

Объекты из предметной области (entity objects) — это описанные в прецеден­те сущности, которые будут использоваться и на более поздних стадиях про­цесса разработки. Заказы, покупатели, товары и платежные ведомости явля­ются объектами-сущностями, экземпляры которых могут появляться в раз­личных сценариях, описанных в прецедентах.

Управляющие объекты (control objects) связаны с процессами. Эти объекты представляют виды деятельности системы, которые зачастую могут быть име­нованными. Создание платежной ведомости, документа и счета-фактуры, а также обновление каталога товаров являются достаточно важными процессами, чтобы присвоить им имя.

Как и любой другой класс, эти классы уровня анализа имеют связи друг с другом. Классы и их взаимосвязи изображаются на диаграммах классов. Исполнители также могут отображаться на диаграммах, чтобы упростить выделение связи интерфейса с соответствующей ролью. Ассоциации между объектами подчиняются определенным правилам.

■  Исполнители могут взаимодействовать только с граничными объектами.

■  Объекты-сущности могут взаимодействовать только с объектами-
контроллерами.

■  Объекты-контроллеры могут взаимодействовать с любым объектом, включая другие экземпляры контроллеров.

Один из способов анализа прецедента состоит в выделении из его описания суще­ствительных и глаголов. Существительные являются кандидатами для объектов-сущностей, а глаголы — для контроллеров. Первоначальный анализ сценария New Customer (Новый покупатель), представленного на рис. 3.2, приводит к созданию диаграммы, показанной на рис. 3.3.

Рис. 3.2. Простая диаграмма устойчивости

Результаты анализа прецедента помогут группе формулировки требований лучше разобраться с тем, что же собой представляет прецедент, особенно его технические аспекты. Эти два артефакта не являются абсолютно необходимыми для эксперта предметной области, однако они полезны для технических специалистов группы. Ес­ли в процессе описания прецедента не был выполнен его анализ, то это обязательно нужно осуществить позже. При обнаружении противоречий или других проблем их разрешение потребует гораздо больших усилий, чем в случае их выявления на стадии формулировки требований.

Рис. 3.3. Более сложная диаграмма устойчивости

2. Стадия анализа

При построении Web-приложений, или распределенных объектных систем, вы­полняются те же виды деятельности, что и при создании обычных программных сис­тем. Поскольку на стадии анализа основное внимание концентрируется на функцио­нальных требованиях к системе, тот факт, что часть или вся система в целом будет реализована на базе технологии Web, является несущественным. Если в функцио­нальных требованиях упоминается об использовании определенной технологии, то нужно избегать всех ссылок на архитектурные элементы.

Стадия анализа начинается с проверки группой анализа модели прецедентов, са­мих прецедентов и их сценариев, а также системных функциональных требований, не включенных в описание прецедентов. Группа анализа идентифицирует объекты и классы объектов, которые могут сотрудничать для обеспечения требуемого поведения системы. Поскольку объекты, классы и принципы построения объектно-ориентированных программных систем обсуждаются во многих книгах, здесь эти концепции подробно рассматриваться не будут.

Если ранее был выполнен анализ устойчивости, то у группы разработчиков дол­жен быть исходный набор классов и основных операций или процессов. Кроме ана­лиза устойчивости, процесс идентификации классов и их взаимосвязей может облег­чить и другие средства.

Методы анализа

1. Классические подходы

Выделить (Меллор): осязаемые предметы, роли, события, взаимодействие.

Выделить (Росс): люди, места, предметы, организации, концепции, события.

Выделить (Йордан): структуры, устройства, события, роли, места, организационные единицы.

2. Анализ предметной области

Выделить те объекты, операции и связи, которые эксперты данной области считают наиболее важными.

Этапы:

- построение скелетной модели предметной области в ходе консультаций с экспертами в этой области,

- изучение существующих в данной области систем и представление результатов в стандартном виде,

- определение сходства и различий между системами при участии экспертов,

- уточнение общей модели для приспособления к нуждам конкретной системы.

3. Анализ поведения системы

Классы формируются на основе групп объектов, демонстрирующих сходное поведение.

Этапы:

- выделить части системы,

- выделить формы поведения системы,

- сопоставить формы поведения с частями системы и определить какая часть инициирует поведение и какие части в нем участвуют,

- выделить инициаторов и участников, играющих существенные роли и зафиксировать в качестве объектов системы,

- сформировать классы на основе групп объектов, демонстрирующих сходное поведение.

4. Анализ вариантов (сценариев)

Вариант поведения – сценарий, начинающийся с того, что пользователь системы инициирует операцию или последовательность взаимосвязанных действий.

Этапы:

- выделить основные сценарии,

- выполнить раскадровку сценариев,

- установить какие объекты участвуют в сценарии, каковы обязанности каждого объекта и как они взаимодействуют в терминах операций,

- расширить набор сценариев, учитывая исключительные ситуации и вторичное поведение.

5.CRC-карты

Карты CRC (Class-Responsibility-Collaboration) являются простым средством, кото­рое можно применять для идентификации классов и их обязанностей. Карта CRC — это просто индексная карта, содержащая имя класса, его обязанности и имена других классов, с которыми данный класс взаимодействует (сотрудничает). Карты CRC пре­красно подходят для осуществления "атаки мозгового штурма".

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

6. Неформальное описание (метод Аббота)

В текстовых описаниях прецедентов и требований вы­полняется поиск важных существительных и глаголов. Необходимо в тексте подчеркнуть существительные и глаголы. Существительные – кандидаты на роль классов, глаголы могут стать именами операций.

7. Ролевые игры (role playing) являются иным видом деятельности группы анализа, ко­торый помогает идентифицировать и разрабатывать классы системы. Члены группы анализа "играют" роли частей системы. Эти роли могут относиться к пользователям, самой системе, другим системам или даже сущностям системы. Группа анализа "про­игрывает" сценарии, описанные в прецедентах, и ее члены обсуждают работу системы. При этом все участники этого процесса делают заметки об обязанностях тех сущностей, роли которых они играют. В ролевых играх зачастую задействуются и карты CRC.

В конечном счете в процессе анализа выполняется предварительное отображение требуемого поведения в структурные элементы системы — классы и их сотрудничест­во. Язык UML предоставляет механизм визуального представления этих структурных элементов на диаграмме. На рис. 3.4 показаны три класса, составляющих вир­туальную торговую тележку. Поскольку эти классы являются частью модели анализа, на диаграмме представлены лишь основные открытые свойства и операции. В процес­се проектирования, когда эта модель будет усовершенствована, на диаграмму будут добавлены дополнительные свойства и операции.

Рис. 3.4. Более сложная диаграмма устойчивости

3. Диаграммы последовательностей

Структурное представление системы представляет собой лишь один из артефактов этапа анализа. Выражение способа взаимодействия между классами является как ча­стью модели анализа, так и определения классов. Для представления динамики взаи­модействия классов в состав языка UML входит диаграмма взаимодействий (interaction diagram), которая может быть следующих типов: диаграмма сотрудничест­ва, последовательностей и видов деятельности. На этих диаграммах с помощью клас­сов и элементов связи между ними отображается динамическое поведение системы.

В процессе формулировки требований и определения прецедентов описываются простые сценарии, затем представляемые с помощью диаграмм взаимодействий ( рис. 3.5).

В процессе анализа фрагмента сценария Checkout (Оплата покупки), представ­ленного на рис. 3.5, можно перейти к диаграмме, показанной на рис. 3.6. С помощью классов, определенных в процессе анализа, на рисунке представлена основная идея этого сценария.

Рис.3.5 Простая диаграмма последовательностей, созданная на основе сценария прецедента

Рис. 3.6. Диаграмма последовательностей, усовершенствованная в процессе анализа

Приведенное выше обсуждение видов деятельности на этапе анализа в равной сте­пени можно применить практически к каждой объектно-ориентированной системе независимо от ее архитектуры. Если архитектура известна, как в данном случае, то граничные объекты и объекты-контроллеры можно рассмотреть с другой точки зре­ния. Позднее, на этапе проектирования, эти граничные объекты могут привести к созданию в системе страниц HTML, а объекты-контроллеры — к созданию динамиче­ских Web-страниц серверной части приложения. Для аналитика это означает, что функциональность, связанная с граничными объектами, может и должна быть оче­видной. Таким образом, каждый граничный объект должен оставаться связанным с единственной задачей.

4. Диаграммы сотрудничества

По существу, диаграммы сотрудничества идентичны диаграммам последовательно­стей. Фактически CASE-средство Rational Rose даже позволяет автоматически преобра­зовать диаграммы сотрудничества в диаграммы последовательностей. Даже если оба типа диаграмм рассмотреть семантически, то они иллюстрируют одно и то же, однако ин­формация представляется в различной форме. Диаграмма последовательностей фокуси­руется на временном факторе: каждое событие жестко привязывается к временной оси. На диаграммах сотрудничества основное внимание уделяется экземплярам объектов. При этом объекты могут помешаться в любое место диаграммы вместе с линиями свя­зей, иллюстрирующими передачу сообщений между объектами. Для отображения по­рядка следования каждое сообщение нумеруется и помещается над соответствующей линией связи. На рис. 3.7 показана диаграмма сотрудничества, полученная после преоб­разования диаграммы последовательностей, представленной на рис. 3.6.

Рис. 3.7. Диаграмма сотрудничества

5. Диаграммы видов деятельности

Еще одним типом диаграммы, которую полезно использовать в модели анализа, является диаграмма видов деятельности (activity diagram). Ее удобно применять для представления последовательности выполняемых действий. По определению на таких диаграммах отображается поток видов деятельности, которые последовательно вопло­щаются в конкретные действия. На диаграммах видов деятельности не используются напрямую объекты и классы модели анализа. Эти диаграммы предназначены для представления динамического поведения на более высоком уровне, чем позволяют диаграммы последовательностей и сотрудничества.

С другой стороны, диаграммы видов деятельности можно использовать для моде­лирования определенной операции (рис. 3.8). В этом случае они очень похожи на

блок-схему. Правильно спроектированную диаграмму видов деятельности можно рас­сматривать как потенциальную отправную точку для генерации кода и обратного про­ектирования, поскольку все необходимые для кодирования операции детали представ­ляются на ней достаточно подробно. Не известно ни одного CASE-средства, ко­торое предоставляло бы возможность генерации кода на таком низком уровне.

Рис. 3.8. Диаграмма видов деятельности для операции ComputeTax

При создании большинства систем, за исключением, возможно, самых простых из них, анализ выполняется группой специалистов. Каждый член этой группы обычно ра­ботает с одним пакетом или набором пакетов. Причем эта работа выполняется незави­симо и одновременно. На начальных стадиях члены группы анализа часто собираются вместе, интенсивно обсуждают и уточняют открытые интерфейсы своих пакетов. Как только модель становится более совершенной, а интерфейсы — более устойчивыми, столь частые обсуждения становятся не нужными. Однако по-прежнему очень важно проводить обсуждение и пересматривать текущие результаты. Это позволит убедиться в том, что каждый из участников проекта движется в правильном направлении.

В некотором смысле пакет можно рассматривать как завершенный и готовый для передачи на стадию проектирования артефакт. Обычно это означает, что имеются все необходимые прецеденты и сценарии, в том числе и альтернативные. Перед перехо­дом к стадии проектирования пакет должен быть еще раз проанализирован.

Лекция 4. Стадия проектирования при разработке Web-приложений

План

1.Стадия проектирования

2. Проектирование "тонкого" Web-клиента

Содержание

1. Стадия проектирования

Проектирование — это этап разработки, когда выполняется пер­вый шаг по переходу от понятий предметной области к про­граммным объектам.

Проектирование начинается с построения модели анализа и ар­хитектуры системы. Эти модели используются в качестве основ­ной отправной точки.

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

На стадии анализа работа в основном была связана лишь с диаграммами классов и взаимодействий. Однако на этапе проектирования вводится новое понятие — диа­грамма компонентов.

Обычно компоненты преобразуются в исполняемые файлы, классы Java, статиче­ские или динамически связываемые библиотеки. Компонент представляет собой сущность, которая реализует набор интерфейсов. Интерфейс — это "мост" между логическим и физическим представлениями системы. По­просту говоря, интерфейсы — это открытые функции, которые могут быть вызваны из-за пределов компонентов. Интерфейс определяет имя функции, ее параметры, соответствующие им типы данных, необязательные пара­метры, а также тип возвращаемого значения. Компонент может предоставлять не­сколько интерфейсов.

Реализация компонента осуществляется с использованием классов и их взаимодей­ствий, которые отображаются в логическом представлении. В логическом представле­нии каждый класс реализует, как минимум, один компонент. Абстрактные классы оп­ределяют интерфейсы, которые могут быть реализованы многими компонентами.

Диаграмма компонентов позволяет визуализировать компоненты, интерфейсы и их взаимосвязи. Компоненты изображаются на диаграмме с использованием условного обозначения, представленного на рис. 1. Интерфейсы изображаются в виде кружка с линией. Зависимости между элементами диаграммы изображаются с помощью пунктирных линий со стрелками.

На диаграммы компонентов можно помещать пиктограммы классов, которые по­зволяют отобразить зависимости и реализацию. Компоненты реализуются с помощью классов, и эта взаимосвязь изображается с использованием пунктирной линии со стрелкой. На рис. 2 показан компонент Shopping Cart (Торговая тележка), реали­зуемый с помощью классов ShoppingCart и ShoppingCartltem.

На этапе проектирования можно выделить следующие виды
деятельности.

■ Распределение объектов по слоям, таким как клиент, сервер и т. д.

■ Отделение пользовательских интерфейсов или Web-страниц.

Рис. 1. Диаграмма компонентов

Рис. 2. Реализация компонента с использованием классов

При проектировании Web-приложений используется два основных вида деятельности, которые существенно отличаются от видов деятельности при проектировании других систем:

- разделение объектов на клиентские и серверные,

- определение Web-страниц пользовательского интерфейса.

Расширение языка UML для Web-приложений определяет нотацию, которую можно использовать для изображения сис­темных компонентов Web-технологии вместе с другими частями модели.

2. Проектирование "тонкого" Web-клиента

Архитектурный шаблон Thin Web Client налагает на использование Web-страниц наиболее строгие ограничения. Он определяет, что каждая страница может содержать только те архитектурные элементы, которые определены текущей версией языка HTML.

Процесс проектирования проще всего начать с непосредственного преоб­разования модели анализа. К этому виду деятельности можно приступить лишь тогда, когда выбрана определенная архитектура системы. В приложениях на базе шаблона Thin Web Client исполните­ли взаимодействуют только с клиентскими страницами, а страницы сервера — лишь с серверными ресурсами. Таким образом, на диаграмму последовательностей нужно поместить клиентскую и серверную страницы. Проще всего это осуществить, напря­мую преобразовав граничные объекты модели анализа в клиентские страницы, а объ­екты-контроллеры — в страницы сервера.

Диаграмма последовательностей модели анализа описывает сценарий Checkout (Оплата покупки) прецедента. Модификацию диаграммы последовательно­стей можно начать, заменив граничные объекты и объекты-контроллеры на клиентские и серверные страницы. На рис. 3 показана усовершенствованная диаграмма последовательностей. Представленный на ней процесс начинается с того, что испол­нитель отправляет сообщение клиентской странице ShoppingCart. Это сообщение, по существу, является командой-запросом на страницу Checkout, и, возможно, на клиентской странице ShoppingCart ее можно реализовать с помощью дескриптора якоря (<а href="Checkout. asp">).

Страница сервера Checkout загружается Web-сервером и, поскольку с ней связан стереотип <<Server Page>>, запускает соответствующий механизм обработки сцена­риев (в данном случае, активных страниц сервера). В соответствии с принятой логи­кой страница передает экземпляру Cart исполнителя сообщение Checkout. Все бизнес-правила или логика предметной области, которые связаны с оплатой покупки, содержащейся в торговой тележке, инкапсулируются в объекте Cart. Большинство деталей процесса оплаты покупки на диаграмме (рис. 3) не показаны, однако их можно представить на дополнительных диаграм­мах. Этот процесс может включать создание транзакций или промежуточных объектов, требуемых для оплаты товаров, которые содержатся в торговой тележке. Страницы сервера, даже если они могут реализовать этот тип бизнес-правил, зачастую являются далеко не лучшим местом для их размещения, поскольку возможность их повторного использования ограничена обработкой страниц. Если поместить эти бизнес-правила в компилируемые модули сервера, их смогут многократно использо­вать и системы, не являющиеся Web-приложениями.