Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Задания, лекции / Червенчук

.pdf
Скачиваний:
54
Добавлен:
02.05.2015
Размер:
818.35 Кб
Скачать

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

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

Известно два основных типа WEB-архитектур: тонкий клиент (thin client) и толстый клиент (thick client). В первом случае основная часть обязанностей и программных функций ложится на серверную сторону, клиент содержит минимум, обеспечивающий работу приложения. Основные преимущества тонкого клиента это скорость и переносимость. Минимизация компонентов клиентской стороны упрощает проблему работы приложения с различными браузерами. Однако в данных условиях на клиентской стороне отсутствует возможность поддерживать высокий уровень сервиса взаимодействия с пользователем.

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

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

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

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

71

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

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

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

4.1.ВИРТУАЛЬНЫЙ КАТАЛОГ

Вначале моделирования нужно создать область формирования классов (виртуальный каталог». В логическом представлении это пакет со стереотипом «virtual directory», представляющий физический каталог в целевой сети. Все классы из виртуального каталога будут генерироваться в соответствующем физическом каталоге. На рис. 4.1. показаны варианты UMLобозначений для виртуального каталога (в режимах «label» (рис. 4.1, а)

и«icon» (рис. 4.1, б)).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

<<virtual directory>>

 

 

 

 

 

 

My_virtual_directory

 

 

 

 

 

 

My_virtual_directory

 

 

 

 

 

 

 

 

 

 

а

 

б

Рис. 4.1. UML-обозначений виртуального каталога

Среды моделирования, поддерживающие моделирование Web-при- ложений, например Rational Rose, имеют инструментальные средства, позваляющие определить виртуальную область, в которую впоследствии будут помещаться созданные Web-объекты [2].

72

4.2.СТЕРЕОТИПЫ WEB-КЛАССОВ

ВUML используется три предопределенных стереотипа классов, ориентированных на моделирование Web-приложений: клиентская страница, серверная страница и HTML-страница (HTML-форма).

Клиентская страница (Client Page) – это страница формата HTML,

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

ставлением данных. Клиентская страница не имеет прямого

доступа

к бизнес-объектам сервера, такие возможности имеют только серверные

страницы. Стандартная пиктограмма клиентской страницы

показана

на рис. 4.2.

 

 

Функции клиентской страницы программируются на

 

 

VB Script или Java Script. Любые используемые сценарии

 

 

должны быть сценариями клиентской стороны. Напри-

My_Client_Page

мер, клиентская страница может самостоятельно сфор-

 

 

мировать текстовое сообщение.

Рис. 4.2.

Клиентская страница имеет доступ к любым ресур-

Клиентская

сам клиентского компьютера, включая:

страница

 

 

элементы Active X, являющиеся компонентами модели Microsoft COM, и загружающиесянаклиентский компьютерпомеренеобходимости;

объекты Java Script, реализующие сценарии, которые присутствуют

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

апплеты Java, содержащие программы, написанные на языке Java, представленные в форме байт-кода. По сравнению с ActiveX, имеют большие возможности, запускаются практически на любой платформе при поддержке Java-машины. Как правило, представляют собой «тяжелые» компоненты и требуют достаточно большой производительности от клиента.

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

73

M yServerPa ge
Рис. 4.4.
Серверная страница

Управляющие элементы ActiveX и Java-апплеты могут моделироваться и как классы (логический вид с точки зрения разработки), и как компоненты (вид с точки зрения реализации) с соответствующими стереотипами («Applet» и «ActiveX»). Как правило, элемент управления базируется на нескольких классах, поэтому представление его в виде компонента предпочтительно. На рис. 4.3 показаны элементы управления ActiveX (рис. 4.3, а) и апплеты Java (рис. 4.3, б) как компоненты.

 

 

 

 

 

 

<<Applet>>

 

 

<<ActiveX>>

 

 

 

 

 

 

 

 

 

 

MyActiveX

 

 

 

MyApplet

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

а

 

 

 

б

Рис. 4.3. Компоненты Web-моделирования

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

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

Серверная страница – объект, которому доступны ресурсы сервера. В отличие от клиентской страницы серверная страница имеет полный доступ к ресурсам сервера. На рис. 4.4 показана пикто-

грамма серверной страницы.

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

верную страницу. Разделение на серверную страницу и клиентские страницы позволяетотделить логику представления от бизнес-логики.

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

74

данных. Серверная страница определяет бизнес-обработку и построение клиентской страницы.

Серверная страница имеет свойства, определяющие физическое имя страницы (ASP, JCP или HTML) и синхронизацию RTE (определяет, будет ли генерироваться страница).

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

Стандартная пиктограмма HTML-формы показана на рис. 4.5.

Клиентская страница может иметь несколько форм.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Любая форма на клиентской странице связана с ней от-

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ношением композиции, представляющей собой форму

MyForm1

агрегирования с выраженными правами владения.

Рис. 4.5. HTML-

Поля формы моделируются как атрибуты формы

 

форма

со стереотипом «HTML Input». Подобно клиентской

и серверной страницам формы имеют большой набор предопределенных свойств.

Форма HTML является по сути набором полей ввода. Выделяются три типа полей: поля ввода (HTML Input), поля выбора (HTML Select) и поля текста (HTML TextArea).

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

Полевыборапозволяетвыбратьодноилинесколькозначенийизсписка. Поле текста – многострочное текстовое поле, используемое для работы с большим количеством текста. Можно указать отображаемое число

строк и другие характеристики.

MyForm2

<<HTML Input>> OKbutton : Button <<HTML Input>> PasswordBox : Password <<HTML Select>> HTML_Select : Select <<HTML ТехтArea>> Text1 : Text

Рис. 4.6. Атрибуты HTML-формы

Все указанные типы полей становятся атрибутами формы, которые выводят эти поля. При генерации кода учитываются как данные поля, так и их характеристики (рис. 4.6).

75

4.3. ОТНОШЕНИЯ

После того как в модели определены основные классы, необходимо указать связи между ними. Между Web-элементами существует четыре типа отношений: связывания (link relationship), построения, (build relationship), отношение перенаправления (redirect relationship) и передачи (submit relationship).

Отношение связывания служит для представления гипертекстовой ссылки между двумя клиентскими страницами или между серверной и клиентской страницами. Связь изображается отношением ассоциации с навигацией и стереотипом «link» (рис. 4.7).

<<Link>>

My ClientPage1

My ClientPage2

Рис. 4.7. Отношение связывания

Отношение построения указывает на то, что серверная страница формирует клиентскую. Как и отношение связывания, отношение построения моделируется ассоциацией, но уже со стереотипом «build».

Например, в Rational Rose при создании серверной страницы клиентская формируется автоматически и связывается с серверной отношением построения, причем клиентская моделируется вложенной в серверную станицу. Любая клиентская страница строится только одной серверной страницей, но одна серверная может сформировать несколько клиентских. Для серверной страницы можно создать дополнительный nested class и связать с ним серверную страницу отношением построения (рис. 4.8).

<<build>>

MyServerPage

MyClient2

 

 

(from MyServerPage)

Рис. 4.8. Отношение построения

76

Отношение перенаправления имеет три атрибута: Page (страница), RTE Synchronization (определяет генерацию страницы), Resolve Relative Paths (разрешение относительных путей) – и предписывает автоматическое разрешение относительных путей. Моделируется ассоциацией со стереотипом «redirect».

Отношение передачи служит для пересылки HTML-формой информации на сервер. Когда пользователь завершит заполнение формы, информация пересылается для обработки на сервере. Отношение передачи моделируется ассоциацией со стереотипом «forward» (рис. 4.9).

<<forward>>

Form2 MySrvPage2

Рис. 4.9. Отношение передачи

Развитые системы моделирования, такие как Rational Rose, имеют мощные средства обратного проектирования страниц ASP, JSP и HTML, позволяющие от готового проекта перейти к модели и средствам генерации кода. Так, страница ASP после обратного проектирования становится классом со стереотипом «Serve Page» и ассоциированным с ним «Client Page», полученные страницы объединяются отношением связывания. Сценарии VB Script и Java Script на серверных страницах ASP и JSP моделируются как операции соответствующего странице класса. Все элементы управления формы становятся атрибутами формы (рис. 4.10).

<<build>>

ConfBron.asp

confirm()

ConfBron.asp_ client Form1

(from ConfBron.asp_ client)

<<HTML Input>> OkButton : Button = OK

<<HTML Input>> CancelButton : Buton = Cancel

<<HTML Input>> Race_Nommber : Text <<HTML Input>> City_to : City

<<HTML Input>> City_from : City <<HTML Input>> Date_of_Race : Date <<HTML Input>> Time_o_Race : Time

Рис. 4.10. Пример обратного проектирования

77

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

4.4. ПРИМЕР МОДЕЛИРОВАНИЯ WEB-ПРИЛОЖЕНИЯ

Рассмотрим процесс моделирования Web-приложений на примере разработки интернет-пособия для студентов медицинской академии. Разрабатываемое электронное учебное пособие (ЭУП) ориентировано на дистанционное обучение студентов-медиков по теме «Туберкулез».

4.4.1. Вид с точки зрения прецедентов

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

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

Действующее лицо (актер) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ.

78

Рис. 4.11. Диаграмма прецедентов

На диаграмме прецедентов (рис. 4.11) представлены следующие элементы:

1.Действующее лицо «Администратор», т. е. человек, который может изменять информацию в учебном пособии, удалять её, заносить новые данные. Тогда как у актера «Пользователь» таких прав нет. Последний может вызывать справку, просматривать информационный материал пособия, нормативные документы, пользоваться словарем и выполнять задания, а именно: отвечать на контрольные вопросы, решать тесты и задачи.

2.Варианты использования. В данном проекте были созданы такие варианты использования, как «просмотр пособия» и «редактирование». Каждый из этих прецедентов можно детализировать. Вариант использования «просмотр пособия» включает: «вызов справки», «просмотр документов», «выполнение заданий», «просмотр информационного материала», «просмотр словаря». А вариант использования «редактирование» включа-

79

ет: «удаление», «изменение», «создание». Здесь используется отношение включения, представляющее собой стереотипную зависимость.

3. Отношения ассоциации отражают связь между действующим лицом и вариантом использования. Отношения между актером «Администратор» и вариантами использования «редактирование» и «просмотр пособия» являются ассоциациями. Соответственно отношение между актером «Пользователь» и вариантом использования «просмотр пособия» также является ассоциацией.

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

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

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

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

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

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

80

Соседние файлы в папке Задания, лекции