Верно. Я только хотел показать, что к нам доставляют СВТ. А ведь действительно, зачем это показывать, если это нас не касается...
Картинка Bussines_UseCase.jpg - так должна выглядеть ДБВИ ?

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

Это именно мой случай. Тогда вообще от клиента можно избавиться в диаграммах, если я описываю систему, в которой клиент не учавствует

Естественно!

Ясно. Мой научный руководитель говорит, что этой ER-диаграммы вполне достаточно для части проектирования.

Все зависит от того, что вы понимаете под ER-диаграммой, что ваш преподаватель. Я под ней понимаю - статическую структуру. Сама по себе корректно созданная она определяет набор ограничений (а ограничения реально выводятся из требований): связи между сущностями, типы связей, типы процедур ссылочной целостности, ключи и доменные определения (включая дефолтные значения и правила ввода значений (маски, проверки, форматы)). Этого может быть достаточно в определенных случаях. Но ER-диаграмма не определяет поведение системы, она лишь может указать на ограничения такого поведения

Кстати UML вполне подходит для рисования ЕR-диаграмм, более того если на диаграмме классов для ряда сущностей вы определите операции (а в смысле ER - это могут быть триггеры и хранимые процедуры, возможно функции определяемые пользователями, или некие алгоритмы которые будут исполняться на клиентском приложении), то вы частично опишите поведение, которое в дальнейшем можно развернуть с диаграммами активностей, диаграммами последовательности и состояний

Всем здравствуйте!
Посмотрите пожалуйста мои варианты ВИ. Я думаю мне достаточно этого.
Или я (опять) вообще ничего не понял и мне лучше не делать UML (ООП), а проще описать структурным (IDEF0, DFD).
Долго не отвечал, т.к. иду с обратной стороны (писал приложение). В принципе, уже почти написал (есть ввод справочников (формы), ввод клиентов (формы с выбором данных из справочников и просто текстовый ввод), ввод средств вычислительной техники (СВТ) - тоже формы с выбором из справочников производителей, категорий и моделей и вводом серийников и инвентарников.
Форма оформления сервисного листа помогает выбрать(если оформлен) клиента; показать (если оформлял) СВТ, которые бывали в ремонте и закреплены за этим клиентом и ввести новую единицу, если в списке нет этой единицы; показывает выбранные (или введенные в момент оформления) клиента и единицу СВТ  и позволяет заполнить остальные поля (контактную информацию и т.д.).
Теперь хочу сделать генерацию заявки на работу по сервисному листу (первоначальную - диагностика), и если понадобится что-либо делать - открывать новые заявки используя номер сервисного листа.
Я понимаю, что сначала идет проектирование, а уж потом реализация. Но я, к примеру, не пойму пока не реализую хотя бы раз (то есть пойти обратным путём) - а уж потом когда я буду себе представлять как реализуется то, что спроектировал - тогда буду в дальнейшем делать всё по-правилам

Забыл приаттачить картинки ВИ

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

Но - это не все требования к системе. Т.е. одних ВИ недостаточно для проектирования системы. Это нужно учитывать.

Мне кажется последняя диаграмма (на другие я не обращаю внимание) не совсем корректна. Я вообще у вас не улавливаю разницу между БВИ и СВИ.

На самом деле ошибки есть
1. зачем демонстрировать уточняющие роли, что они дополнительного показывают? Другое дело, если бы Вы тем самым показали, что у разных ролей могут быть разные цели использования (ВИ)
2. Ввод информации о СВТ и ввод информации о клиенте - бессмысленен без оформление сервисного листа, вернее наоборот оформление всегда включает первые два действия, а смысл этой демонстрации?
3. связано с пунктом 1 - не показана дифференциация пользователей  их целей - отсюда и ВИ использования системы не совсем внятные
4. а это связано с тем, что неясны цели использования системы, ее назначение

Но - это не все требования к системе. Т.е. одних ВИ недостаточно для проектирования системы. Это нужно учитывать.

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

Мне кажется последняя диаграмма (на другие я не обращаю внимание) не совсем корректна. Я вообще у вас не улавливаю разницу между БВИ и СВИ.

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

На самом деле ошибки есть
1. зачем демонстрировать уточняющие роли, что они дополнительного показывают? Другое дело, если бы Вы тем самым показали, что у разных ролей могут быть разные цели использования (ВИ)
2. Ввод информации о СВТ и ввод информации о клиенте - бессмысленен без оформление сервисного листа, вернее наоборот оформление всегда включает первые два действия, а смысл этой демонстрации?
3. связано с пунктом 1 - не показана дифференциация пользователей  их целей - отсюда и ВИ использования системы не совсем внятные
4. а это связано с тем, что неясны цели использования системы, ее назначение

1. Вроде бы понятно.
2. Не знал. Почему-то думал, что именно так и надо показывать (уточнять). Теперь понятно.
3. Вроде бы понятно. Постараюсь переделать и показать что получилось.
4. Цели использования системы:
а)Открыть новый сервисный лист для внесения данных о клиенте, СВТ, причине обращения с возможностью печати копии для клиента.
б)Сформировать заявку на ремонт/обслуживание СВТ клиента по открытому сервисному листу.
в)Отслеживать сформированные заявки на предмет своевременного их выполнения.
г)Формирование отчетов для анализа эффективности выполненных работ
д)Сбор статистических данных.

Т.е. по пункту 3+4 можно сделать диаграмму СВИ, где актер зав.склад будет ассоциироваться к ВИ (д), а актер начальник будет ассоциироваться с ВИ (г) ?

4. Цели использования системы:
а)Открыть новый сервисный лист для внесения данных о клиенте, СВТ, причине обращения с возможностью печати копии для клиента.
б)Сформировать заявку на ремонт/обслуживание СВТ клиента по открытому сервисному листу.
в)Отслеживать сформированные заявки на предмет своевременного их выполнения.
г)Формирование отчетов для анализа эффективности выполненных работ
д)Сбор статистических данных.

Т.е. по пункту 3+4 можно сделать диаграмму СВИ, где актер зав.склад будет ассоциироваться к ВИ (д), а актер начальник будет ассоциироваться с ВИ (г) ?

Да, сейчас больше понятно, что должна делать система, какой функциональностью она должна обладать.
Иерархия ролей будет нужна, если каждая уточняющая роль может делать то, что делает более общая + нечто свое. Таким образом мы задаем разделение использования по ролям.
Что может делать абстрактный сотрудник?
Что может делать каждый сотрудник в указанной ролью?

Я бы составил табличку: Роль - Возможные ВИ
Из анализа таблички, можно было бы сделать требуемую иерархию

Здравствуйте.
Вот я и дописал приложение. Всё работает и радует глаз
Посмотрите пожалуйста ещё раз ВИ - можно ли эту ДСВИ оставлять в таком виде.
Заинтересованные лица:
1) Руководитель – желание знать кто, когда и сколько заявок выполнил по оформленным сервисным листам, как быстро, как качественно (т.к. повторные сервисные листы от одного клиента по одной и той же причине вероятнее всего говорят о некачественно выполненной работе).
2) Зав.склад – желание оперативно предоставлять отчеты руководству о находящихся на хранении единицах СВТ (готовые к выдаче после ремонта, ожидающих запчастей, списанных, полученных по распоряжениям для выдачи на новые рабочие места или замены существующим)
3) Технолог – желание оперативно отслеживать ход выполнения ремонта единиц СВТ по своей зоне ответственности за определенные рабочие места (для последующей установки и/или настройки дополнительного ПО).
4) Администратор СПД – желание оперативно отслеживать ход выполнения ремонта единицы СВТ для последующей настройки СВТ (ведь для работы в СПД необходимо ввести ПК в домен, установить антивирус, настроить сетевые подключения и т.д.)
5) Электроник – желание один раз оформить новую единицу СВТ и закрепить её за одним пользователем (чтобы в дальнейшем при оформлении в ремонт/обслуживание выбирать нужного клиента и его СВТ из списка оформленных ранее).
Ещё приложил ДД (так как я всё равно её сделал, чтобы сразу и оценили, можно ли в таком виде оставить). А ДА (диаграммой активности) её вообще нельзя называть? Или это просто старое название ДД ?

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

Даже если сравнить с другими названиями ВИ бросается в глаза в одном случае информационность действия, а в другом материальность что ли

Далее... диаграмму можно сделать более понятной и обозримой
Электроник выполняет все ВИ кроме последнего
Руководитель, технолог и администратор - практически не отличаются, что странно
Завсклада делает 3 вещи из того, что делает электроник + тоже что и руковдитель

Можно поиграться отношением обобщения

По поводу ДСВИ.
Если это системные варианты использования, то некоторые формулировки я бы все-таки изменил
Прием СВТ (не помню правда что такое С) - мне кажется так звучит бизнес ВИ, а на уровне системы Электроник что-то для этого делает

Средства вычистительной техники. Долго мы к этому слову привыкали

Проведение ТО и ремонта СВТ - это некий процесс, но не как не ВИ, это все-таки некоторая совокупность ВИ системного уровня...
Выдача СВТ - аналогично

Видимо я что-то пропустил мимо ушей. Вы же мне уже советовали при оформлении сервисного листа не показывать include работы по вводу информации о клиенте и его СВТ. Я вывернул всё наоборот и показал прием и выдачу.
А надо наверное нарисовать ВИ:
1 - оформление сервисного листа,
2 - оформление наряда на выполение работ,
3 - отображение хода выполнения работ (или лучше написать фиксация выполненных работ),
2 - изменение статуса сервисного листа (закрываем сервисный лист когда все работы выполнены).
Эти ВИ касаются только электроников. По идее они могут иметь возможность сидеть в системе и смотреть информацию о клиентах, СВТ и в поисках прочих статистических данных, но зачем? Они же работают (ремонт и обслуживание СВТ). Пусть поиском нужных данных  их анализом занимается руководитель группы.
Зав.склад мною изменен на руководителя группы, т.к. нет у нас зав.склада (это я уже тут выдумывать начал непонятно зачем). Выдает нам технику и запчасти девушка (мат.ответственное лицо) - вот для неё я и написал этот сайт, чтобы она могла нормально анализировать собранную информацию.

Даже если сравнить с другими названиями ВИ бросается в глаза в одном случае информационность действия, а в другом материальность что ли

Вроде бы понял ошибку. Исправил диаграмму.

Далее... диаграмму можно сделать более понятной и обозримой
Электроник выполняет все ВИ кроме последнего
Руководитель, технолог и администратор - практически не отличаются, что странно
Завсклада делает 3 вещи из того, что делает электроник + тоже что и руковдитель

Я поменял завсклад на руководителя группы и убрал отношения электроника и тех ВИ, которые относятся и к руководителю группы.

Можно поиграться отношением обобщения

А можно так оставить как на последнем слайде?

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

Вот, лично мне нравится такой вариант больше. По-моему, он в данном случае уже ориентирует нас на то, что должна делать система
Вторая диаграмма мне не совсем понятна. Это какой-то, как я понимаю, симбиоз. Вообще по РУП далее следует реализация ВИ: т.е. по каждому ВИ делается какой-то комплект реализующих его диаграмм (классов, коммуникации, последовательности и т.п.). Отображения форм, мне представляется лишним, потому как каждая линия коммуникации между актером и ВИ предполагает наличие какого-то интерфейса: графического пользовательского или программного.
Обычно это отображается на диаграмма реализации. Т.е. форма становится классом
Вопрос декомпозиции тем способом, что вы изобразили вызывает вопросы:
1. действительно ли каждый раз, когда оформляется сервисный лист вводится информация о клиенте и о СВТ
2. можно ли вводить информацию о клиенте и СВТ, не оформляя сервисный лист (на диаграмма говорится да)
3. если информацию о клиенте и свт можно вводит независимо, не означает ли, что при оформлении сервисного листа нужно найти уже введенного клиента и выбрать СВТ из его списка СВТ?

Так или иначе, все-таки не стоит перегружать ДВИ какой-либо сложной логикой. Главное наглядность и понятность. Поведенческие моменты лучше демонстрировать через конкретные сценарии

По диаграмме классов. Тут следует спросить себя, что я хочу передать этой диаграммой? Отвечает ли диаграмма на поставленную задачу? Не противоречит ли она другим диаграммам?

А вот так нормально будет, если оставить СДВИ без изменения?

Не влезли все изображения.
Кстати по поводу вопроса декомпозиции тем способом, что я изобразил:
============================================================================================
1. действительно ли каждый раз, когда оформляется сервисный лист вводится информация о клиенте и о СВТ
2. можно ли вводить информацию о клиенте и СВТ, не оформляя сервисный лист (на диаграмма говорится да)
3. если информацию о клиенте и свт можно вводит независимо, не означает ли, что при оформлении сервисного листа нужно найти уже введенного клиента и выбрать СВТ из его списка СВТ?
============================================================================================
1. А разве нельзя подразумевать, что даже если выбираешь информацию из выпадающего списка - всё равно она вводится в сервисный лист (в таблицу Service_list коммандой insert intо) ?
2. Да, можно.
3. Да - именно так.

1. А разве нельзя подразумевать, что даже если выбираешь информацию из выпадающего списка - всё равно она вводится в сервисный лист (в таблицу Service_list коммандой insert intо) ?

Это уже способ реализации. Т.е. что делает система когда вводится новый клиент? Запускается ВИ создать нового клиента, а как это будет реализовано, это уже второй вопрос, возможно у вас будут несколько разных вариантов.
Однако вводить клиента командой insert - это моветон на мой взгляд, такое допустимо для каких-то перечислений

Это уже способ реализации. Т.е. что делает система когда вводится новый клиент? Запускается ВИ создать нового клиента, а как это будет реализовано, это уже второй вопрос, возможно у вас будут несколько разных вариантов.

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

Однако вводить клиента командой insert - это моветон на мой взгляд, такое допустимо для каких-то перечислений

Возможно я не так выразился.
Insert добавляет в таблицу сервисного листа только индекс клиента (id). Сами данные клиента вносятся в таблицу Клиента.
Или я что-то не так понял? Почему моветон? Можно как то по другому добавлять данные в таблицы помимо комманды insert ?