Вроде с вариантами немного разобрался, теперь дальше.
Мне нужно построить диаграмму классов, но тут у меня не все так просто.
Надо использовать библиотеки МФС.
Архитектура док/вид.
Почти все мои классы наследуются от библиотечного CDialog.
Как лучше поступить.
Подключить к проекту мфс.
Или просто создать класс CDialog.
И диаграмма у меня страшненькая получается .

ИМХО для модели разницы не будет, а вот для кодогенерации предпочтительнее первый вариант.

Воопчем незнаю чего нарисовал.

Сначала предлагаю нарисовать объекты предметной области и связи между ними (business\domain objects model), а потом переходить к проектированию приложения.

что такое bisiness/domen objects model я толком не понял, но думаю что нечто такое.
Однако возникли вопросы, как учесть работников библиотеки на данной диаграмме.

Что-то типа такого

1. Не понятно почему у Книги может быть много Карточек
2. Один Автор может написать несколько Книг и одна Книга может быть написана несколькими Авторами
3. Не понятно куда делись Заказы Книг и как Вы будете вычислять Должников
4. Работники Библиотеки наверное принимают Книги от Поставщика и Читателей и отдают их Читателям

Не могу понять как правильно отобразить работников на диаграмме.
Чего то тут накинул.
Это примерно так представляется или я неправ.
Насчет должников: поиск должников выполняется по формулярам книг.

Нужны названия на связях, например, Автор "написал" Книгу, чтобы было более понятно.

Опять же не понятно как Читатель связан с Карточкой?
Зачем нужен Формуляр одновременно и Заказ? Мне кажется под Заказом должно быть Каталог Книг.

Думаем логически:
1. Читатель делает Заказ, Заказ оформляется на Книгу, Библиотекарь принимает Заказ
2. Заведующая принимает Книгу
3. Книга принадлежит Категории

vov1k, небольшой совет.

Составьте словарь предметной области. Попытайтесь по возможности точно определить каждый его элемент.
Затем рисуйте диаграмму. Сначала определитесь с классами и ассоциациями между ними. Причем кратности спешить ставить не следует.
Постепенно добавляйте атрибуты. Уточняйте кратности.
Дайте ассоциациям наименование.
Возможно следует придумать роли (т.е. дать названия концам ассоциации)
Не следует ли использовать квалифицированные ассоциации

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

Получение ответов можно сформулировать на языке OCL.

Все переделал, не знаю так или нет.

Аааааааааааааааа, все не так.

Давайте начнем с малого:
1. Сотрудники библиотеки оформлены правильно
2. Есть Книга или по Вашему Каталожная Карточка, мне больше нравится первое название
3. Книгу могут написать несколько Авторов, а один Автор может написать много Книг
4. Книгу принимает Заведующая, проставляя в Книге дату приема
5. Читатель делает Заказ,
6. Заказ оформляется на Книгу
7. Библиотекарь выдает книгу по Заказу
8. Другой Библиотекарь может принять Книгу по Заказу
9. и т.д.
Давайте оформите пока то что я написал и потом пойдем дальше.

ну, что понял, то и сделал.

я себе все это немного иначе представляю:
ну скажем функции библиотекаря на выдаче
1. Выдача книги читателю
    библиотекарь заносит в формуляр книги номер читателя и дату выдачи, а так же в формуляр читателя номер книги и дату выдачи(как я понимаю у читателя должно быть несколько формуляров на каждую взятую книгу, а у книги сохраняться все формуляры в которых указаны все читатели, читавшие эту книгу. по этим формулярам проще выполнять поиск книг и отслеживать должников).
2. прием заказов на книги.
    то есть читатель приходит в библиотеку, не находит нужной книги и заказывает её библеотекарю.
    и библ. создает заказ на книгу, куда заносит данные книги и данные читателя.
    когда данная книгу поступает в библиотеку, библиотекарь должен будет известить об этом читателя, чтоб тот пришел и забрал книгу.
3. добавление нового читателя
4. чтобы отмечать выданные книги, хранящиещя в чит. зале(то есть их на руки не выдают) и книги которые есть в наличии, я думаю надо ввести в книгу атрибут скажем "код доступа".
при возврате книги нужно указать в формулярах книги и читателя дату возврата.

Я думаю должно быть что то такое.
??

Хорошо, значит я немного не правильно понял. Делаем все по порядку.

1. Библиотекарь выдает Книгу Читателю по Формуляру и может другой Библиотекарь принять туже Книгу от того же Читателя.
2. Все что Вы описали - это функциональность, в статике будет просто Библиотекарь принимает Заказ на Книгу от Читателя
3. Это функциональность, к ДБО отношения не имеет
4. Думаю учет выдачи Книг в чит. зал можно сделать также как в п. 1. В Книгу можно добавить атрибут тип (для Чит. зала, для Выдачи)

Нужно оформить то что я написал и двигаться дальше.

Хочу представить небольшую диаграмму, которая надеюсь будет в тему.

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

Я вот попробовал отобразить факт взаимодействия библиотекарей и читателей с фондом, без включения поведенческих аспектов.

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

У данной модели есть недостаток, он не хранит историю взятия тех или иных книг, поэтому вряд ли нам удасться узнать, какие книги наиболее популярны, сколько раз бралась та или иная книга.

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

От ответов на эти вопросы, общая модель данных будет меняться