Суть проблемы в следующем: для дипломного проекта нужно составить диаграммы классов, но так как я этим никогда не занимался, то никак не могу разабраться с простой, как я думаю, задачей. Значит так, имеется несколько классов, каждый сам по себе, т.е. нет наследования, но все они используют некоторые функции друг друга. Например класс content использует класс db для чтения данных из БД, оба этих класса используют класс dialogs для вывода сообщений (об ошибках, успешном заершении и т.д.), та вот как указать эти связи на диаграмме? Прошу сильно не пинать, т.к. про UML услышал 2 недели назад и знания нулевые, если нужны классы для примера, то могу выложить в формате MS Visio. Заранее благодарен за помощь.

Вы эти диаграммы на основе чего собрались делать - модели в голове, реально созданного кода, алгоритмов, прописанных в блок-схемах?

Вам что-нибудь про ОО читали? Принципы распределения обязанностей по классам, CRC-карточки, слабое связанность, сильное зацепление,  шаблоны GRASP? (Это всё не про UML, на всякий случай).

Всё это делается на основе созданного кода. Про всё вами вышеперечисленное слышу впервые  .

Самый простой вариант - использовать тип связи "зависимость" (dependency).

А вообще см.:
1) главу 6 книги "Основы UML" Фаулера (Fowler - UML Distilled).
2) описание шаблона Low Coupling из набора GRASP, описанного в главе 16.8 книги Крэга Лармана "Применение UML и шаблонов проектирования" (Craig Larman - Applying UML and Patterns).

Есть ещё дешёвый метод - сделать автоматизированный инженерный анализ кода (reverse engineering) с помошью какого-нибудь мощного CASE-средства, но это совсем для ленивых, и не факт, что получится правильно

Последний вопрос, если класс content вызывает функцию из класса db, которая возвращает результат, то стрелки должны быть в обоих направлениях?

Последний вопрос, если класс content вызывает функцию из класса db, которая возвращает результат, то стрелки должны быть в обоих направлениях?

Нет, только от content -> db. Т.к. content опирается на интерфейс класса db и зависит от него, т.е. от его модификаций. А классу db пофигу, кто его вызывает и кому он будет возвращать - главное, что он зафиксировал свой интерфейс, а следовательно - как его можно вызвать и что он обязуется возвратить в ответ.

Принципы распределения обязанностей по классам, CRC-карточки, слабое связанность, сильное зацепление,  шаблоны GRASP? (Это всё не про UML, на всякий случай).

Извините что влезаю, посоветуйте литературу по этим вопросам. Хотел купить "Унифицированный процесс разработки программного обеспечения" Бутча но в Москве нигде не нашел в наличии.

Извините что влезаю, посоветуйте литературу по этим вопросам. Хотел купить "Унифицированный процесс разработки программного обеспечения" Бутча но в Москве нигде не нашел в наличии.

А вы зря путаете ООП и процесс разработки ПО. Для первого в качестве нотации используется UML, для второго как образец зачастую - RUP, но возможны любые варианты.

Я уже выше по тексту ответил, что на тему проектирования одна из лучших книг - Крэга Лармана, ещё можно посмотреть Бертрана Мейера