Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: vov1k от 26 Февраля 2009, 12:11:45
-
Вроде с вариантами немного разобрался, теперь дальше.
Мне нужно построить диаграмму классов, но тут у меня не все так просто.
Надо использовать библиотеки МФС.
Архитектура док/вид.
Почти все мои классы наследуются от библиотечного 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. В Книгу можно добавить атрибут тип (для Чит. зала, для Выдачи)
Нужно оформить то что я написал и двигаться дальше.
-
Хочу представить небольшую диаграмму, которая надеюсь будет в тему.
Я вовсе не хочу навязать свое решение. Но надо помнить, что структура данных, а это именно то, что мы пока исследуем, будет сильно зависить от контекста использования системы.
Я вот попробовал отобразить факт взаимодействия библиотекарей и читателей с фондом, без включения поведенческих аспектов.
Ясно, что кто-то создает и редактирует системный каталог
Ясно, что кто-то принимает новые книги и включает их в общий фонд, и кто-то списывает книги, по той или иной причине.
Ясно, что желательно иметь информацию о состоянии фонда: сколько книг на руках, сколько книг на месте, есть ли книги, экземпляры, которой выданы и т.д.
У данной модели есть недостаток, он не хранит историю взятия тех или иных книг, поэтому вряд ли нам удасться узнать, какие книги наиболее популярны, сколько раз бралась та или иная книга.
Поэтому как мне кажется и важно начинать с вариантов использования или хотите с функциональной модели, чтобы понять какие функции будут в системе, кем будут они выполняться, нужно ли учитывать кто и когда принял книгу, кто и когда выдал книгу и т.п.
От ответов на эти вопросы, общая модель данных будет меняться
-
Чего то я уже начинаю запутываться.
-
vov1k,
А кто Вам говорил про Формуляр Читателя??
Просто от Формуляра Книги отходят 4 связи: 2ве к Библиотекарю (выдал, принял), 1на к Книге (кукую книгу выдали), 1на к Читателю (кому выдали).
В самом Формуляре должны быть атрибуты даты выдачи и даты приема.
Все.
Оформите это и пойдем дальше.
-
vov1k, давайте немного разберемся.
Что вы пытаетесь изобразить? структуру классов предметной области, информацию о которой вы планируете хранить в некой базе данных? Или же вы пытаетесь описать просто объекты предметной области Библиотека?
Действующие лица, к которым вы причислили только сотрудников библиотеки действительно важны.
Почему? Да хотя бы потому, чтобы понять - что нужно им от будущей системы, которая будет автоматизировать некоторые аспекты их работы. Какие именно?
1. работа по ведению библитечного фонда: прием новых книг, создание картотеки, ведение различных видов каталогов, списание книг
2. работа по выдаче и приему выданных книг на абонементе, оформление читателей, т.е. их регистрация и поддержание формулярных данных в актуальном состоянии, аннулирование договора с читателем, возможно взымание с них платы за аренду книг, штрафов за просроченные книги
3. возможно учет выдаваемых читателям книг и периодики в читальных залах
Действующим лицом может быть и читатель, если при создании системы предусматривается такая возможность, что поиск книг в каталогах, отслеживание своих формуляров будет доступно и читателям.
Однако пусть читатели с системой не работают - они статика, информацию о них следует хранить. Однако хранится не сам читатель, а информация о нем. Хранится она в формуляре. Скольку формуляров может иметь один читатель? Возможно один на абонементе, один в читальном зале? А зачем нам нужен формуляр в читальном зале, для какой цели?
Ясно, что при создании системы во множестве формуляров у одного читателя надобность отпадает автоматически. И библиотекарь абонемента, и библиотекарь читального зала могут получать одну и туже информацию.
Следовательно формуляр документ по сути идентифицирующий читателя.
Далее одна и таже книга может быть представлена во множетсве экземпляров. Т.е. мы можем выделить понятие Описание книги - каталожная карточка, и собственно книга как вещественная сущность. Ясно, что каждый экземпляр книги индивидуален, он имеет специальный (уникальный) номер (спросите любого библитекаря вам ответят).
В каталоге хранится не книга, в каталоге хранится описание книги - карточка.
Как библитекарь узнает, что свободных экземпляров данной книги нет в наличии - да просто ее нет на полке. Поскольку имеется специальный классификационный номер книги, библиотекарь знает где искать книгу в книжном фонде.
Зачем могут быть нужны сотрудники библиотеки на вашей диаграмме. Они могут быть нужны, если требуется хранить информацио о том, кто сегодня выдавал книги в первую смену. Кто оприходовал поступление новой партии товаров и т.п.
Если эти сведения не нужны, то сотрудники библиотеки на диаграмме лишние. Они нужны только для идентификации будущего окружения системы, выявления ее функциональных характеристик.
Сотрудник библиотеки - вероятный пользователь системы. Возможно у вас будет разделение прав доступа к информации. По этой причине вам возможно надо будет хранить информации для идентификации пользователя и знание его прав на доступ к информации. Тогда нужно добавить класс Пользователь, Права доступа, но не более
Если в вашей системе существует предварительный заказ на книгу, т.е. можно как-то встать в очередь на нее или что-то подобное, то наверное стоит рассмотреть сущность Заказ. Но опять же это можно делать постепенно...
Мне, кажется, вы слишком усложняете свою задачу. Попробуйте посмотреть на нее проще и ближе к сути решаемой проблемы
-
bas
нарисовал как ты сказал, но давай дальше пока двигаться не будем я хочу разобраться чего к чему
galogen
пасиб за норм объяснение специфики работы библиотеки
я около часа провел в библиотеке но там не так внятно объясняют :)
-
Ура, мы продвинулись в перед. Нужно еще назвать связи, это лучше делать с помощью названий в самих связях, а не ноутами.
Я что-то упустил тот факт, что выдается не Книга как таковая а ее Экземпляр. Поэтому добавляем:
1. Книга имеет много Экземпляров
2. Экземпляр может выдается и приниматься разными Библиотекарями, Экземпляр берет Читатель. Все это оформляется через Формуляр. Т.е. книгу в последней Д нужно заменить на Формуляр.
-
Вроде так .
-
Мне нравится. Только не хватает названий связей и не нужен атрибут в Формуляре - Номер сит билета, т.к. есть уже ссылка на Читателя, а у него есть этот Номер.
Теперь рисуем следующее:
1. Заведующая принимает Экземпляр Книги
2. Читатель делает Заказ на определенную Книгу, а Библиотекарь принимает Заказ
3. Книга должны быть определенной Категорией, а Категория иерархична
4. Подумайте о выдаче Книги в чит. зал.
-
Немного не ясно про категорию книги.
Категория это вроде специфики книги (учебник, роман, повесть и др).
-
Немного не ясно про категорию книги.
Категория это вроде специфики книги (учебник, роман, повесть и др).
Насколько я понял из рисунка, здесь речь идёт о классификации УДК.
Каждой нормально изданной книге присваиваются коды классификации ББК (http://ru.wikipedia.org/wiki/ББК), УДК (http://gsnti-norms.ru/norms/common/doc.asp?2&/norms/udc/udcs.htm) и ISBN (http://ru.wikipedia.org/wiki/ISBN).
В читальных залах и научно-технических библиотеках, для облегчения поиска, книги расставлены в соответствии с кодом классификации (те, в которых мне доводилось бывать, использовали УДК).
Было бы замечательно, если бы их и в магазинах так расставляли. Но в реальности продавцы расставляют их, исходя из названия, или вообще по цвету обложки. Например, книгу "Психбольница в руках пациентов" (это о юзабилити) я как-то обнаружил в разделе "Психиатрия" (возможно, потому, что издатель присвоил ей обязательный, но не несущей полезной информации ISBN, и при этом не позаботился о присвоении кодов ББК и УДК).
-
Да, что-то похожее уже есть. Замечания:
1. Заказ делается на определенную Книгу, т.е. Заказ должен ссылаться на Книгу, и не содержать дублированные атрибуты Книги
2. Экземпляр Книги может приходить по определенному Заказу
3. Я бы объединил Библиотекаря (Б) в чит и Б на выдачи в одного Б, от него две связи к Формуляру. А Б в чит и Б на выдачи обобщаются в Б.
-
Немного не ясно про категорию книги.
Категория это вроде специфики книги (учебник, роман, повесть и др).
Насколько я понял из рисунка, здесь речь идёт о классификации УДК.
Каждой нормально изданной книге присваиваются коды классификации ББК (http://ru.wikipedia.org/wiki/ББК), УДК (http://gsnti-norms.ru/norms/common/doc.asp?2&/norms/udc/udcs.htm) и ISBN (http://ru.wikipedia.org/wiki/ISBN).
Нет я немного о другом говорил, например о такой Классификации (http://www.books.ru/shop/show/9000000).
-
Вроде ничего не забыл
-
Вот. Отлично. Теперь немного расставить элементы чтобы красиво выглядело и связи не пересекались и вообще будет супер.
-
Ну специфические функции описаны, хорошо.
Но есть еще общие (поиск книги, отслеживание должников)
их тут нужно ?
И у читателя есть атрибут адрес, его возможно надо сделать тоже объектом и включить в читателя?
-
Ну специфические функции описаны, хорошо.
Но есть еще общие (поиск книги, отслеживание должников)
их тут нужно ?
И у читателя есть атрибут адрес, его возможно надо сделать тоже объектом и включить в читателя?
1. Где описаны специфические функции??
2. Это уже Функциональные Требования и к Статической ДБО никакого отношения не имеет.
3. Адрес нужно добавить в атрибут Читателя
-
ну если ДБО построена, что делать дальше?
диаграммы взаимодействия?
-
Можно для каждого ВИ сформировать список ВИ Реализации и в каждом ВИ Реализации построить Д Взаимодействия:
http://www.agilemodeling.com/artifacts/robustnessDiagram.htm
-
Ну, насколько я понял из книг, мне надо определить реализующий ви,
и составить для его реализации диаграммы классов(классы кот. учствуют в данном ви) и диаграммы взаимодействия для этого ви.
И если надо составлять диаграмму классов, то мне нужно уже использовать классы библиотеки мфс ?
-
И если надо составлять диаграмму классов, то мне нужно уже использовать классы библиотеки мфс ?
ИМХО пока нет. Это PIM (http://en.wikipedia.org/wiki/Platform-independent_model), поэтому пока без привязки к языку программирования.
-
Ну чего то чем дальше в лес, тем больше дров ...
Я составил реализация варианта использования добавить читателя (основн. сценарий).
Или я о5 все напутал ?
-
Похоже на правду. Только не нужна ДК в этом случае, а только Д Взаимодействия.
Нужно переименовать Обработчик в Обработчик Читателя, и не понятно откуда у Вас Взялся Список Читателей? Последний должен браться из ДБО
-
То есть все должно выглядеть примерно так ?
Мне нужно будет на каждый ви сделать такие диаграммы?
И нужно ли делать диаграммы на альтернативные варианты?
-
Да, это то, что надо.
Нужно теперь показать не успешное добавление Читателя. Я обычно это показываю на другой Д, прикрепленному к этому же ВИ Реализации.
А как правильно?
-
Мне нужно будет на каждый ви сделать такие диаграммы?
Ни в коем случае! Возможно, чисто с учебной целью Вы можете попытаться создать диаграммы на каждый ВИ и даже на каждый сценарий ВИ.
Но на практике так никто делать не будет. Связываться с диаграммами следует тогда, когда это целесообразно и облегчает понимание. Либо выступает инструментом анализа, проверки логичности и т.п.
И нужно ли делать диаграммы на альтернативные варианты?
Выше я уже сказал свое мнение. Здесь хочу добавить, что ясных указаний на это нет. Одни считают, что если строить диаграммы последовательности, то на каждый сценарий ВИ и базовый и альтернативный. Другие наоборот утверждают, что нужно постараться все изобразить на одной диаграмме.
UML2 имеет для этого достаточные средства. Но повторюсь, все зависит от цели построения такой диаграммы...
-
Ну я думаю должно получиться нечто такое .
-
Ну я думаю должно получиться нечто такое .
Неа! А где классы-сущности. Где то, что хранится. Вы изобразили граничные классы, есть управляющий класс. А куда девалось то, что собственно и составляет предметную область?
-
Чего-то нарисовал, но по моему чегото не то.
-
Ну почему не то?? Вроде все правильно. Только хорошо бы еще слева добавить Пользователя нужного + еще не хватает обратного сообщения от Сущности "Читатель"
-
Ну наверное что то такое.
Только немного непонятно, для чего пользователя указывать?
-
Vov1k,
итак вы на стадии аналитической модели. Следуя Розенбергу, а, мне кажется, Вы действительно ему следуете, управляющий класс (обработчик читателя) следует наименовать по названию ВИ. Хотя, конечно, дело стиля. В английском обычно к имени ВИ добавляется слова Handler, Manager, Controller. Например Оформить заказ (RegisterOrder), будет выглядет как RegisterOrderHandler, RegisterOrderManager, RegisterOrderController.
Роль этого элемента модели - управление, диспетчирезация, распределение. Это прослойка между элементами интерфейса и бизнес-логикой. При этом в дальнейшем, наверняка, управляющий класс распадется на несколько взаимодействующих элементов согласно какому-ту паттерну проектирования или логики архитектурного решения.
В Вашем случае Проверка данных читателя мне кажется не очень логичной. Действительно, что значит проверка данных? На чем она базируется? Если это корректность введенных данных, то тут мы имеем дело с обработчиком событий и элементов формы (интерфейса), чаще всего такая логика относится к логике представления и она не должна содержать бизнес-логики. В вашем же случае получается, что класс Обработчик читателя помимо чисто распорядительной функции (т.е. протокольной) должен еще содержать элементы бизнес-логики. Т.е. сообщение самому себе в данном случае мне кажется логической , аналитической ошибкой.
Далее, наименование сообщений по сути прототипы операций соотвествующих классов. Операции моделирую поведение или действие, потому просто Данные читателя плохо. Должно быть скорее Сохранить(данные читателя). Аналогичной сообщение должно идти от Обработчика к классу-сущности.
Причем, как я понимаю, сначала будет произведена проверка нет ли объекта с подобными данными (причем вряд ли будут проверяться ВСЕ данные) и в случае отрицательного ответа будет создаваться НОВЫЙ объект читателя, потом заносится данные, потом сохранятся ...