Здравствуйте Уважаемые форумчане. Надеюсь на Вашу помощь. Пишу бакалаврскую работу по специальности "Прикладная информатика в экономике" тема работы звучит так: "Автоматизация оформления покупок через веб-портал ОАО Новосибирский Инструментальный Завод". Ездил к начальнику Аналитического отдела завода, чтобы понять что требуется сделать. Была поставлена цель: есть сайт предпрития, необходимо доработать и сделать что-то вроде модуля который бы позволял посетителям выбрать товар, сформировать корзину товаров и оформить заказ, который бы посредством электронной почты отправлялся бы в коммерческий отдел ОАО "НИЗ", где с заказом бы уже работали менеджеры по стандартной схеме, оформление договора, счет-фактур, товарных накладных.
Руководитель ВКРБ поставил передо мной цель: пройти цепочку от функциональной модели к физической посредством объектно-ориентированных CASE-средств. Разработку модуля предполагаем вести по технологии RUP, где важным моментом является на каждом этапе построение диаграмм UML. Так вот, сегодня на ващ суд хочу вынести свою диаграмму USE CASE, которая как мне кажется отражает требования Начальника Аналитического отдела. Честно в UML я практически полный ноль, в университете мы проходили по курсу Разработка и стандартизация но все очень поверхностно, сейчас начинаем изучение в курсе Проектирование Информационных систем, но все равно пока знаний не хватает, пытаюсь читать литературу и вникать во все тонкости.

Граница системы, если я правильно понимаю определение, будет таковой: начиная от формирования заявки на сайте и заканчивая формированием договора и поставкой товара. Наверное так.
Действующие лица (актеры): частное лицо или мелкие предприниматели (акцент будет на них), менеджер по продажам, сам модуль автоматизации заявки, БД коммерческого отдела в котором формируется заявка и все документы необходимые: товарная накладная, счет-фактура, транспортная накладная и центральная складская база (которая передает данные посредством конвертации в локальную БД коммерческого отдела). Необходимо описать ВИ в котором пользователь выбирает товар на сайте, формирует корзину, потом просматривает ее, если надо редактирует, оформляет форму (в которой будет ФИО как связаться адрес и прочая информация от пользователя), потом он отправляет эту форму через модуль, который передает заявку в коммерческий отдел. Менеджер ее проверяет, связывается с тем кто ее оформил, подстверждает ее. Потом начинает формировать договор на поставку, формирует приказ на отгрузку, счет-фактуру, товарную накладную - это в случае если товар есть на складе, в противном случае отказать в заявке. Вот до сюда мне надо построить систему.
Простите что таким примитивным языком изъясняюсь - просто это первый опыт подобной разработки, если так можно сказать.

Batak,

Не хочется Вас обижать, но Вы читали те примеры, которые есть в данном разделе? Я там в каждом примере указываю одни и те же ошибки. Прошу прошерстить раздел, посмотреть ошибки и исправить ДВИ в соответствии со сделанными ранее подсказками. Хорошо, если Вы укажите темы в которых смотрели.

Постарался разобраться в ДВИ и построить что-то похожее. Сильно не бейте, если опять что-то не так.

Ошибки:
1. Сама Система не м.б. Актером
2. Название ВИ должны образовываться от глагола, а у Вас то так то сяк
3. Чем оформить Заказ отличается от Внести данные Заказа?
4. Посмотреть\редактировать\отменить\... Заказ - это CRUD ВИ

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

Batak, я бы на вашем месте полностью откалазлся от зависимостей расширения или включения.
1. рано
2. вы их не совсем хорошо понимаете
3. читателю они тоже малопонятны в массе своей
4. ВИ - это не "мужики с яйцами" - это прежде всего текст
5. ДВИ - иллюстрация того, что должна делать систему - стенд с ярлыками - на котором написаны цели
6. Структуризацию следует делать позже, когда общая концепция, гарницы, пользователи и их цели поняты. когда переходим к реализации ВИ

Спасибо всем за комментарии.
Bas: 1. Скажите а почему система не выступает актером в этом случае? Когда читал FAQ по USE CASE там написано, что среди распространенных ошибок является отсутствие самой системы или действующего лица? Или она здесь не является актером потому что, она не внешняя?
2. На счет глагольной формы учел.
3. Здесь я просто хотел показать что пользователь формирует заказ на стороне веб-сервера, потом этот заказ поступает в коммерческий отдел, где менеджер уже регистрирует этот заказ в своей СУБД (может просто ВИ неправильно обозвал?)
4. Извините за вопрос, но что такое CRUD?
Galogen: спасибо за замечания, учел.
Пойду думать дальше.

Вопрос относительно CRUD отпал уже нашел информацию на форуме. Тогда возникает другой вопрос: нужно ли эти CRUD ВИ показывать на диаграмме? Если да - то как корректно отобразить?

1. Актером м.б. Пользователь или ВНЕШНЯЯ Система. Сама ИС, которую Вы разрабатываете, не м.б. Актером, т.к. мы отражаем ВИ как цель Пользователя по отношению к Системе, т.е. Актеры - это внешние сущности по отношению к самой НАШЕЙ Системе.
3. ВИ не отображают архитектурную особенность Системы, Система воспринимается как нечто целое (во всяком случае пока Вы не поймете азы ВИ и не пойдете дальше изучать их). Поэтому у Вас должно быть 1 ВИ с несколькими участвующими Пользователями
4. CRUD ВИ, например, можно назвать "Управлять Заказом"

Вообщем получается так:
Я выделил три актера: СУБД коммерческого отдела (она внешняя система получается у меня), старшего менеджера и пользователя системы автоматизации оформления покупок.

• Цели которые преследует Пользователь при работе с системой: Просмотреть какая есть продукция, сформировать заказ (выбрав нужные позиции товара), просмотреть свой сформированный заказ перед его отправкой, Удалить какие-то позиции из заказа, Добавить новые позиции, Отменить весь заказ
• Цели, которые преследует Менеджер: просмотреть заказ, Оформить заказ, Оформить договор поставки товара
• С разрабатываемой системой взаимодействует внешняя СУБД коммерческого отдела, ее цели: оформить заказ, оформить договор поставки, оформить счет-фактуру, транспортную накладную, товарную накладную

Вот что у меня собственно получилось:

Я не понял про СУБД коммерческого отдела - это что такое? Т.е. у Вас есть Система (и отдельная БД в ней), которую Вы разрабатываете, там хранится каталог продукции и Пользователь делает заказ там, потом этот Заказ передается в другую Систему (СУБД коммерческого отдела) и там уже происходит оформление Заказа и Договора поставки. Так?

Да так. Цель работы: разработать систему (модуль) для существующего сайта завода. Этой системой будет управлять СУБД MySQL в которой и будет храниться каталог продукции, пользователь просматривает продукцию и формирует заказ - подобно корзине в электронном магазине. Потом этот заказ отправляется и попадает в коммерческий отдел где менеджер уже его заносит в свою СУБД коммерческого отдела и тама же формирует договор поставки и все необходимые документы.

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

З.Ы. Уже в какой раз убеждаюсь, что Контекстная Д очень помогает в понимании Системы ...

Понимаю, что я изрядно уже наверное поднадоел Вам  . Но хочу показать свой последний вариант ДВИ. Надеюсь, что он уже будет окончательным.

1. Если Старший Менеджер не смотрит в Вашей Системе Заявку, то его нужно убрать.
2. Сформировать и Отправить Заявку - ЭТО ОДИН ВИ, это одна Цель - Заказать Товар (так даже лучше назвать ВИ), в нем участвует еще Система коммерческого отдела, т.к. в конце Заявка отправляется во внешнюю Систему.
3. Посмотреть Заявку нужно засунуть внутрь CRUD Управлять Заявкой и т.о. будет еще одно объединение двух ВИ.

Bas, большое спасибо за терпение и за Вашу помощь в построении диаграммы. Теперь учтя все замечания представляю последний вариант ДВИ.