Добрый день.
Есть большой проект на .NET состоящий из множества слабо связанных частей, во время проектирования забыли согласовать, как хранить настройки для каждой части, в результате каждый разработчик придумывал на свой вкус и в итоге систему просто невозможно поддерживать. Задача создать подсистему, которая позволит:
1.   Централизованно хранить и изменять настройки в виде строк в БД по имени группы (части системы) и имени настройки.
2.   Получать значение настройки по имени группы (части системы) и имени настройки любой части системы.
Подсистему хочу спроектировать на UML, но знаний мало, а доступная информация туманна. Прошу помочь, кто чем может, указать на ошибки и направить на правильный путь.
Для проектирования использую Visio, ибо куплен (есть бесплатные альтернативы?).
Пока решил сосредоточиться на пункте 2.
Итак:
1.   Диаграмма Сценарий выполнения (use case diagram):

Все просто и понятно.
2.   Диаграмма Деятельности (activity diagram):
a.   Получение одной настройки

b.   Получение набора настроек

Вроде все тоже просто, только что-то у меня диаграмма деятельности сильно смахивает на блок смеху или так и должно быть? И правильно ли указано состояние "Определить одну настройку", это состояние описывается диаграммой "Получение одной настройки" (2.а)
3.   Диаграмма Последовательности (sequence diagram):

А вот тут не пойму как отразить что «Менеджер настроек» возвращает сам объект «Настройка»?
4.   Диаграмма классов (class diagram):

Класс Setting реализует интерфейс ISetting – отношение обобщение. Вроде правильно.
SettingCashe изображен как объект, так как является экземпляром класс Hashtable из .NET. Вроде логично.
SettingCashe может существовать только с  SettingManager – отношение композиция. Вроде по учебнику.
А вот отношение ассоциации между Setting и SettingManager вроде должна быть, но что-то меня смущает, как-то не очевидно это, не чувствую логики, но тем не менее думаю связь между ними должна быть. Как правильно?
Вот на этом пока затык…

1. По ДВИ вообще не понятно. Ху из "Досистема Клиент"?? У Вас вроде все происходит внутри Системы, поэтому человечков не должно быть, максимум один ВИ, но нафиг он Вам нужен?
2, 3. Не совсем понятно что там делается и кто (какая ф-я на ДК) это делает? А что если не надено, то все заканчивается??
4. ОТ куда берутся настройки в Кэше??
5. Тут вообще каша и интрфейсы и объекты и классы. Вам тут помогут Д из ЮМЛ 2:
http://www.xpdian.biz/TheUML2Diagrams.html
Реализация интерфейса не так рисуется вообще.
А про отношения Setting и SettingManager вообще непонятно, кто и как юзает другого

1. По ДВИ вообще не понятно. Ху из "Досистема Клиент"?? У Вас вроде все происходит внутри Системы, поэтому человечков не должно быть, максимум один ВИ, но нафиг он Вам нужен?

Хм... В имени ошибся, должно быть наверное так:

"Подсистема клиент" любая подсистема системы которой необходимо получить настройку.

2, 3. Не совсем понятно что там делается и кто (какая ф-я на ДК) это делает? А что если не надено, то все заканчивается??

Делает подсистема Настройки. Если не найдено, то результат null. Результат null тоже надо указать?

Хм... В имени ошибся, должно быть наверное так:

Предоставить Настройку и Настройки - это ф-ции системы, но никак не ВИ

"Подсистема клиент" любая подсистема системы которой необходимо получить настройку.Делает подсистема Настройки. Если не найдено, то результат null. Результат null тоже надо указать?

Может тогда лучше ДП сделать??

Мне кажется, из представленных диаграмм не складывается  цельного представления о системе, а поскольку требуемая доработка касается большинства ее программных компонентов, это было бы очень желательно.
М.б, я чего-то не понимаю, но по-моему, из диаграмм последовательности и действия следует, что:
1) Будет иметь место трехзвенка (клиент – сервер_приложений - БД), где 'Менеджер настроек' будет выступать для клиентов в роли сервера приложений при получении настроек.
2) 'Менеджер настроек' будет почему-то использовать оперативную память для долговременного хранения данных – эта самая хэш-таблица (наверно, здесь все-таки 'хэш’, а не ‘кэш’ ) - что как-то нетрадиционно, а к БД он обращается только в самом крайнем случае – если уж ничего не находит. Вы уверены, что так и должно быть?
Вот для клиента вполне допустимо хранить эти данные в хэше (векторе, связном списке и т.д.), но клиент у вас сам к БД не обращается.

to bas:

Реализация интерфейса не так рисуется вообще.

А где можно было бы посмотреть, как она рисуется? Вот здесь мне попадалось нечто весьма похожее: http://www.intuit.ru/department/pl/umlbasics/14/3.html. Только отношение реализации обозначено пунктиром, а не сплошной линией.

to bas: Расшифруйте, пожалуйста, сокращения ВИ и ДП
to Золотая рыбка: В системе в целом будет доработка, точнее "переключение" получение настроек от собственного механизма на получение через "Менеждер настроек".
1) Да, это обычная трехзвенка, "Менеждер настроек" станет сервером приложений на следующей итерации разработки.
2) Я не вижу препятствий что-бы кэшировать данные на сервере, это снизит нагрузку на БД, хотя это и не обязательно и возможно на следующих этапах разработки будет введена настройка хэшировать или нет.

Только отношение реализации обозначено пунктиром, а не сплошной линией.

У Visio нет такого элемента.
В общем вот что у меня в итоге вышло:
1.   Диаграмма Сценарий выполнения (use case diagram):

2. Диаграмма Деятельности (activity diagram):
2.1. Получение одной настройки:

2.2. Получение набора настроек

3.   Диаграмма Последовательности (sequence diagram):
3.1. Получение одной настройки:

3.2. Получение набора настроек

4.   Диаграмма классов (class diagram):

Смущает наличие связей между SettingManager и Setting и между SettingDAO и Setting.

to bas:А где можно было бы посмотреть, как она рисуется? Вот здесь мне попадалось нечто весьма похожее: http://www.intuit.ru/department/pl/umlbasics/14/3.html. Только отношение реализации обозначено пунктиром, а не сплошной линией.

Ну да. Все верно. Вот еще например:
http://www.agilemodeling.com/style/interface.htm

to bas: Расшифруйте, пожалуйста, сокращения ВИ и ДП

Читаем ФАК.

to bas: Спасибо, полезная ссылка.

to Tixo:

В системе в целом будет доработка....

Думаю, было бы неплохо иметь общее описание системы в UML-нотации, раз предполагается использовать UML ... М.б. диаграмма развертывания http://www.intuit.ru/department/pl/umlbasics/13/2.html ?..

кэшировать данные на сервере

Ну вам виднее. Наверно, в этом подходе есть свои преимущества.

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

По поводу последнего варианта диаграмм не могу ничего сказать - че-то у меня картинки отображаться перестали. (

Да их просто тихо (Tixo) убрали

Кинул картинки в другое место и поправил ссылочки, теперь отображаются?

По поводу ДК.
- на диаграмме данные базы (SettingDAO) и данные кэша друг от друга никак не зависят
- появляется третий вариант хранения того же набора настроек - SettingCollection в виде ArrayList.
Мне кажется, SettingManager предназначен для управления набором данных (SettingCollection), который может быть представлен в разных физических реализациях. При этом изменение SettingCollection должно автоматически переноситься на все реализации. Наверно, можно посмотреть в сторону паттерна 'Наблюдатель'. http://www.intuit.ru/department/pl/umlbasics/14/4.html
Прилагаю сокращенную ДК - как вариант.

И еще по поводу человечка - вряд ли он здесь нужен. Он же некую внешнюю по отношению к системе сущность обозначает.