Документирование веб-приложения Поток / [закрытый] Iteraction
4 ответа
Мы использовали диаграммы классов UML, используя вариант эссе Коналлена Моделирование дизайна веб-приложений с помощью UML . Вы обнаружите, что это эссе развилось в различных воплощениях в сети и даже стало книгой Building-Web-Applications-UML-2nd .
Мой двухцентовый тур по подходу, который мы использовали:
Следуя статье Коналлена, мы определили новые объекты UML (стереотипы) для представления веб-страницы или части страницы, чтобы мы могли различать серверный код. (например, сервлет Java или JSP] из клиентского HTML / javascript / AJAX, который он сгенерировал. Например:
- [web page]
- [панель навигации]
- [page-content]
- [header]
- [нижний колонтитул]
Появились новые ассоциации, например:
- [builds] - относится серверный код веб-страницы или фрагмент страницы, который он сгенерировал
- [видимая-ссылка] - используется между клиентскими страницами на диаграмме карты сайта
- [ссылка ] - URL-ссылка, то есть запрос GET
- [отправляет] - формирует сообщение обратно на сервер, т.е.POST-запрос
- [перенаправление клиента] - перенаправление на стороне клиента
- [перенаправление сервера] - да
Наконец, несколько новых диаграмм ( в основном это просто специализации диаграмм классов), например:
- [карта сайта] -> как диаграмма классов - показывает статические отношения ([очевидные -link] s) между [веб-страницами] с точки зрения пользователя
- [page-generation] -> как диаграмма классов - показывает классы, статически связанные с отображением определенной сети страница: какой код сгенерировал ее, какой код обрабатывает отправку сообщения
- [page-Composition] - как диаграмма классов - показывает элементы, составляющие данную [веб-страницу]
- [диаграммы последовательности] - Единственное другое изменение состояло в том, что диаграммы последовательности теперь могли включать в себя объекты на стороне клиента в качестве действующих лиц.
Хорошие новости:
- мы нашли расширения значков Rational Rose, необходимые для того, чтобы диаграммы выглядели наполовину приличными.
Плохая новость:
- этот подход потребовал много работы - теперь у нас было вдвое больше сущностей для моделирования, так как теперь мы моделировали сущности на стороне клиента в дополнение к классам на стороне сервера.
Прочтите одну из статей Коналлена, чтобы увидеть фотографии того, о чем я говорю, но, как я уже сказал, не следовал строго его подходу - мы взяли только те части, которые нам были нужны. Надеюсь это поможет.
Примеры использования как часть диаграмм действий используются некоторыми моими коллегами, но, возможно, это хорошо для некоторого статического обзора навигации высокого уровня.
Я собираюсь разработать собственный DSL, который будет напоминать формат сценария BDD, используемый в Cucumber с Webrat. ИМХО, такие сценарии содержат достаточно информации для создания моделей взаимодействия и веб-страниц.
В прошлом я использовал диаграммы состояний UML для документирования навигации по страницам в веб-приложениях.
Я рекомендую использовать подход 37signals при разработке приложений.
Каждая страница должна иметь цель. Сосредоточьтесь в первую очередь на этой цели и создайте вокруг нее все остальное.
Процесс:
- набросайте основные части с помощью маркера и бумаги
- Элемент списка
- проигнорируйте детали на ранней стадии (они просто мешают)
- создайте что-нибудь как можно скорее (т.е. создайте несколько HTML-файлов со ссылками на другие страницы, чтобы показать, как приложение будет работать
- после того, как поток сайта установлен, затем добавьте компоненты дизайна и начните программировать
. Намного проще добавить программирование к чему-то, что уже было разработано и продумано, по сравнению с разработкой приложения для обхода существующего программирования (что в большинстве случаев требует переписывания кода для адаптации к проблемам дизайна / последовательности операций, которые были упущены вначале).