Этот вопрос может быть очень простым или сложным.
Simple:
Смоделируйте их с классами, стереотипированными <> или <>, как предложил swarraj. Хотя имхо, на самом деле нет нужды стереотипировать их, поскольку вы можете указать, что они были страницами сервлета или jsp, просто заставив их реализовать интерфейсы HttpServlet или HttpJspPage. Поскольку большинство инструментов моделирования сегодня довольно скупы на использование стереотипов (допускается только один - даже если самая последняя спецификация допускает множественное число), я бы хотел зарезервировать использование стереотипов для вещей, которые не могут быть выражены каким-либо другим способом - и это оказывают глубокое влияние на понимание модели.
Комплекс:
Предупреждение: я сделал эту тему центром моей карьеры в последнее время, и поэтому мои мнения в этой области достаточно сильны, поэтому не воспринимайте то, что я пишу, слишком серьезно: -).
Когда я впервые сделал переход к веб-приложениям с клиентского сервера, я хотел применить свои проверенные и успешные передовые методы ОО, но столкнулся с небольшим камнем преткновения, когда дело дошло до проектирования веб-страниц моделирования (в то время MS ASP). Основная проблема заключается в том, что существует одна концептуальная веб-страница, но она проявляется очень по-разному на сервере и клиенте. Например, любая данная веб-страница содержит как код для заполнения своего динамического содержимого при его сборке на сервере, так и клиентские сценарии и гиперссылки, которые характеризуют ее на клиенте. Смешивание этих двух в одном классе в модели UML показалось мне очень запутанным.
Я не мог просто игнорировать вещи на стороне клиента, так как это было (imho) архитектурно значимым. Навигационные маршруты, клиентские сценарии, формы / поля, апплеты и т. Д. Были важны для меня как архитектора и дизайнера и должны были быть частью модели проекта. Тогда возник большой вопрос: как правильно моделировать такие вещи наряду с материалами для создания страниц (взаимодействия JSP и сервлетов с ресурсами на стороне сервера)? Решение должно было соответствовать современным методам моделирования Java и быть наиболее важным с той же степенью абстракции и детализации (две ключевые концепции моделирования).
Суть решения, которое я предложил, состоит в том, чтобы смоделировать эти отдельные аспекты веб-страницы как отдельные классы (один для уровня клиента и один для уровня сервера). Они оба реализуются одним и тем же компонентом, и именно благодаря реализации этого компонента концепция страницы становится понятной как единое целое. Также через компонент реализуются URL.
Поскольку это сложное решение, лучше всего лишь указать на недавнюю вступительную статью, которую я написал для январского выпуска журнала Software Development Magazine (январь 2001 г.). Или этот более старый из «Коммуникаций ACM» (том 42, № 10) (который, по-видимому, доступен в сети в виде PDF-файла). Наконец, «бесстыдный плагин», я написал книгу, подробно описывающую это: «Создание веб-приложений». с UML ", в серии технологий Addison Wesley Object. Хотя эта книга в значительной степени сосредоточена на технологиях ASP, эти концепции могут быть применены к JSP / Servlet, PHP и даже CFM. В настоящее время я работаю над следующим изданием, которое будет включать (и даже фокусироваться на) имплементации J2EE.
Предоставлено - http://www.jguru.com/faq/view.jsp?EID=334159