ну если ДБО построена, что делать дальше?
диаграммы взаимодействия?

Можно для каждого ВИ сформировать список ВИ Реализации и в каждом ВИ Реализации построить Д Взаимодействия:
http://www.agilemodeling.com/artifacts/robustnessDiagram.htm

Ну, насколько я понял из книг, мне надо определить реализующий ви,
и составить для его реализации диаграммы классов(классы кот. учствуют в данном ви) и диаграммы взаимодействия для этого ви.
И если надо составлять диаграмму классов, то мне нужно уже использовать классы библиотеки мфс ?

И если надо составлять диаграмму классов, то мне нужно уже использовать классы библиотеки мфс ?

ИМХО пока нет. Это PIM, поэтому пока без привязки к языку программирования.

Ну чего то чем дальше в лес, тем больше дров ...
Я составил реализация варианта использования добавить читателя (основн. сценарий).
Или я о5 все напутал ?

Похоже на правду. Только не нужна ДК в этом случае, а только Д Взаимодействия.
Нужно переименовать Обработчик в Обработчик Читателя, и не понятно откуда у Вас Взялся Список Читателей? Последний должен браться из ДБО

То есть все должно выглядеть примерно так ?
Мне нужно будет на каждый ви сделать такие диаграммы?
И нужно ли делать диаграммы на альтернативные варианты?

Да, это то, что надо.

Нужно теперь показать не успешное добавление Читателя. Я обычно это показываю на другой Д, прикрепленному к этому же ВИ Реализации.
А как правильно?

Мне нужно будет на каждый ви сделать такие диаграммы?

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

И нужно ли делать диаграммы на альтернативные варианты?

Выше я уже сказал свое мнение. Здесь хочу добавить, что ясных указаний на это нет. Одни считают, что если строить диаграммы последовательности, то на каждый сценарий ВИ и базовый и альтернативный. Другие наоборот утверждают, что нужно постараться все изобразить на одной диаграмме.
UML2 имеет для этого достаточные средства. Но повторюсь, все зависит от цели построения такой диаграммы...

Ну я думаю должно получиться нечто такое .

Ну я думаю должно получиться нечто такое .

Неа! А где классы-сущности. Где то, что хранится. Вы изобразили граничные классы, есть управляющий класс. А куда девалось то, что собственно и составляет предметную область?

Чего-то нарисовал, но по моему чегото не то.

Ну почему не то?? Вроде все правильно. Только хорошо бы еще слева добавить Пользователя нужного + еще не хватает обратного сообщения от Сущности "Читатель"

Ну наверное что то такое.
Только немного непонятно, для чего пользователя указывать?

Vov1k,

итак вы на стадии аналитической модели. Следуя Розенбергу, а, мне кажется, Вы действительно ему следуете, управляющий класс (обработчик читателя) следует наименовать по названию ВИ. Хотя, конечно, дело стиля. В английском обычно к имени ВИ добавляется слова Handler, Manager, Controller. Например Оформить заказ (RegisterOrder), будет выглядет как RegisterOrderHandler, RegisterOrderManager, RegisterOrderController.

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

В Вашем случае Проверка данных читателя мне кажется не очень логичной. Действительно, что значит проверка данных? На чем она базируется? Если это корректность введенных данных, то тут мы имеем дело с обработчиком событий и элементов формы (интерфейса), чаще всего такая логика относится к логике представления и она не должна содержать бизнес-логики. В вашем же случае получается, что класс Обработчик читателя помимо чисто распорядительной функции (т.е. протокольной) должен еще содержать элементы бизнес-логики. Т.е. сообщение самому себе в данном случае мне кажется логической , аналитической ошибкой.

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

Причем, как я понимаю, сначала будет произведена проверка нет ли объекта с подобными данными (причем вряд ли будут проверяться ВСЕ данные) и в случае отрицательного ответа будет создаваться НОВЫЙ объект читателя, потом заносится данные, потом сохранятся ...