Справочники

Следующие книги и документы служат справочниками по этим рекомендациям:

• Building Web Applications with UML, автор Jim Conallen [CONA99]
•  Whitepaper: Modeling Web Application Architectures with UML

Проведение анализа варианта использования

По сравнению с разделом Задача: анализ варианта использования, здесь пограничные классы более сконцентрированы и предназначены для единственной цели. Объекты из этих классов живут недолго, и любым клиентским состоянием (на Web-страницах) необходимо управлять явно с помощью специальных механизмов. Например, страницы Microsoft Active Server используют "cookie" в качестве индексного указателя на карту состояний всех текущих активных клиентов.

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

• Любое упоминание Web-страницы преобразуется в пограничный класс.  
• Любое упоминание гиперссылки преобразуется в ассоциацию, ведущую из пограничного класса в другой пограничный или управляющий класс.  
• Глаголы или описания процессов, как правило, отображаются в управляющие классы.  
• Существительные отображаются в сущностные классы.  

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

Работа с диаграммами взаимодействия

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

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

Субъект на диаграмме последовательности на уровне анализа взаимодействует с пограничным объектом. От субъекта к пограничному объекту отправляется навигационное сообщение.

Создание начальных классов проектирования

Создание начального пограничного класса

Пограничный класс можно отобразить в класс клиентской страницы.

Если пограничный класс включает входную информацию, то обычно его связывают с формой (или Web-формой) посредством агрегирования. Форму можно смоделировать как вложенный класс клиентской страницы, поскольку весь его жизненный цикл контролируется клиентской страницей. У форм всегда есть взаимосвязь передачи на выполнение с серверной страницей, обрабатывающей значения формы; в итоге возвращается новая клиентская страница.

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

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

Если архитектура основана на распределенной системе объектов (такой как RMI, IIOP или DCOM), то клиентская страница может переадресовывать интерфейсы к компонентам, контактирующим непосредственно с сервером через RMI, IIOP или DCOM, в обход HTTP. Такие типы взаимосвязей обычно имеют стереотипы <<rmi>>, <<iiop>> или <<dcom>>, чтобы указать проектировщику все области, через которые будут проходить сетевые данные, обозначая тем самым возможные узкие места.

Создание начального сущностного класса

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

Создание начального управляющего класса

Управляющие классы отображаются в серверные страницы. Контроллеры выражают и координируют бизнес-логику, а также координируют другую логику. Они обычно находятся на сервере. Многие управляющие объекты отвечают за компоновку клиентских страниц (в сущности, их главным выводом является HTML). Управляющие объекты могут взаимодействовать с серверными ресурсами, например базами данных, компонентами среднего уровня, мониторами транзакций и т.п.  

Управляющие классы обычно отображаются в серверные сценарные Web-страницы (активные серверные страницы, серверные страницы Java).