скажите а какие диагрыммы вы бы использовали?

скажите а какие диагрыммы вы бы использовали?

А те, которые помогут составить внятное и понятное описание системы.

Я, например, не очень понимаю, ЧТО вы пытаетесь описать?

Конструкцию фреймвёрка? Модель системы?

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

Любая система - это совокупность таких описаний, совокупность описаний с разных точек зрения.

UML- язык, но не МЕТОДОЛОГИЯ. ТО как использовать язык решать Вам.

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

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


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

Либо вообще имеет смысл абстрагироваться от имеющегося и выстроить все с нуля.

Для отображения элементах используемого Шаблона - подойдут кооперации или структурированные классификаторы.

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

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

Попробуйте начать с большой контекстной диаграммы (кубики и стрелочки), на которой изобразите основные компоненты (функциональные и/или физические) системы, внешние системы, контрагенты и информационный обмен между ними. Далее можно провести функциональную декомпозицию каждого модуля. Для этого можно, например, использовать диаграммы потоков данных (DFD), где показать информационный обмен внутри каждого модуля http://ru.wikipedia.org/wiki/DFD. Однако, на мой взгляд, лучше для декомпозиции использовать сценарии использования системы(СИС). СИСы можно рисовать в каком-нибудь средстве визуального моделирования типа Visio или Rational Rose, однако простых текстовых описаний будет вполне достаточно.
Все эти модели и описания можно свести вместе в wiki системе. Если нет своей, то можно воспользоваться гугл сайтами.
Опять же, не зацикливайтесь на моделях. Сделайте сначала простое описание. При необходимости вносите пояснения в него при помощи диаграмм.

Спасибо за советы.
Вообще возникает такая ситуация когда приходится работать над готовым проектом будь то сайт, интернет магазин или веб приложение без какой либо документаций, неговоря уже и про ТЗ.
Поэтому доработка становится трудной и мучительной. Хорошо если имеется CMS, а вот если индивидуальная разработка то это ваще ж..
Каждый раз начиная свой проект хочется все сделать как надо ТЗ->проектирование->разработка. И хочется чтоб это было как то универсально. Если по ТЗ уже сформировался кое какой стандарт, то в проектированнии все размыто и не ясно, какие диаграммы? сколько? некоторые говоритят 1-2 (class и use case) будет вполне достаточно.
Недавно нашел рисунок каторый прояснил какие диаграммы долджны присутсвтовать в проектировании предметной области и какие этапы проектирования.

Если по ТЗ уже сформировался кое какой стандарт, то в проектированнии все размыто и не ясно, какие диаграммы? сколько? некоторые говоритят 1-2 (class и use case) будет вполне достаточно.

Почитайте Брукса. Все уже изобретено и придумано

В проектирование вовсе ничего не размыто. Проектирование это решения по ТЗ.

Подходы бывают разные - это правда, разные методики и методологии.

Описанные вами задачи - типичные для использования UML.

Делаем так - составляем словарь предметной области, он же может позволить сформировать концептуальную модель классов (классы предметки)

Определяем роли пользователей и рисуем use cases.

Далее определяем реализацию каждого use case - в виде текстового описания, в виде диаграмм деятельности, в виде диаграмм последовательности (коммуникации). Особенно последняя. Соотносим появившиеся объекты на этих диаграммах с концептуальной моделью классов, дорабатываем ее, превращая в модель проектирования, т.е. добавляем класс реализации (программные): страницы, обработчики, утилиты, перечисления, контроллеры и т.п.

Определяем ответственности классов - добавляем операции, описываем взаимодействие появившихся объектов классов через диаграммы состояний, деятельности, коммуникации и последовательности

Применяем последовательно шаблоны и принципы проектирования - описываем это через кооперации.

Группируем по пакетам, по компонентам. Компоненты распределяем по узлам, компоненты связываем артефактами

По сути нужно получить сборочный чертеж - т.е. чертеж на монтаж можно сказать системы.