Задания, лекции / Червенчук
.pdfшому числу компьютеров, не заботясь об особенностях настройки каждого из них. При этом, однако, предъявляются дополнительные требования к приложениям, чтобы они работали в условиях разных конфигураций,
сразными операционными системами, с различными браузерами. Естественно, не все компоненты могут работать в разных средах, поэтому разработчику необходимо провести дополнительную работу по адаптации приложения к различным условиям.
Известно два основных типа 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
Управляющие элементы 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