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

Задача: специфицировать требования к функциональному поведению проектируемой системы "типография" (это модель, есесно с некими упрощениями и допущениями).

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

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


Для начала выявленные ВИ:

ВИ.01 Простмотр списка услуг
Актёры: клиент
Цель: получение сведений о предоставляемых услугах
Краткое описание: Клиент заходит на сайт типографии, где получает информацию о предоставляемых услугах.

ВИ.02 Формирование заявки через интернет
Актёры: клиент
Цель: загрузить материалы в систему через интернет, получить номер заявки
Краткое описание: клиент со своей локальной машины загружает материалы в систему типографии, выбирает параметры заявки.

ВИ.03 Формирование заявки локально (в типографии)
Актёры: менеджер
Цель: загрузить материалы в систему с локального компьютера в типографии, получить номер заявки
Краткое описание: менеджер со своего локального компьютера в типографии загружает материалы клиента в систему (если клиенту не нужна только брошюровка), выбирает параметры заявки.

ВИ.04 Изменение статуса заявки
Актёры: кассир, оператор
Цель: изменить статус заявки для попадания заявки в очередь на производство и удаления заявки из очереди после выполнения
Краткое описание: кассир после получения оплаты клиентом заявки устанавливает статус на "оплачено", после чего заявка попадает в очередь на выполнение. Оператор устанавливает статус "выполнено" для обработанной заявки, после чего заявка удаляется из очереди.

ВИ.05 Получение очереди заявок
Актёры: оператор
Цель: взять заявку из очереди на выолнение
Краткое описание: оператор получает список заявок, выбирает заявку на выполнение, после чего система устанавливает для заявки статус "в процессе".

ВИ.06 Изменение параметров услуг
Актёры: менеджер
Цель: добавить, изменить, удалить параметры печати и брошюровки
Краткое описание: менеджер заходит в систему, где добавляет, изменяет или удаляет параметры печати и брошюровки.


Ну и собственно ДВИ в аттаче.
Жду критику по всем аспектам темы. Желательно конструктивную. 

StUtk,

А чем тебе не понравился пример, который мы делали по ВУЗу? Там и описание было и концепция и т.д.

StUtk,
1. Формирование заявки - абстрактный ВИ - его лучше сделать так
2. ИМХО, ассоциации от клиента к ВИ 02
3. ассоциация от менеджера к ВИ 03
4. Менеджер наследует Клиента

StUtk,
А чем тебе не понравился пример, который мы делали по ВУЗу? Там и описание было и концепция и т.д.

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

Ну тогда так:
1. Все ВИ должны быть образованы от ГЛАГОЛА
2. Сформировать заявку через интет или локально с т.з цели Пользователя параллельно, хотя бы п.ч. последовательность действий одинаковая, и это должен быть один ВИ. При этом Менеджер наследует Клиента. Или хотя бы один ВИ наследует другой.
3. ВИ Получить очередь заявок наверное должен быть расширением ВИ Изменить статус услуги, т.к. нет такой цели у Пользователя. Причем Оператор наследует Кассира.

1. Формирование заявки - абстрактный ВИ - его лучше сделать так

Почему лучше? С целью наиболее понятного представления? Абстрактный ВИ может быть связан с каким-нибудь актёром? (с точки зрения нотации)

1. Все ВИ должны быть образованы от ГЛАГОЛА

А как более отглагольно должны выглядеть названия ВИ по сравнению с существующими? Формировать - формирование, получить - получение, изменить - изменение, просмотреть - просмотр?

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

Даже если, клиент формирует заявку через инет с помощью веб-морды, а манагер на месте, скажем, с помощью программулинки, написанной на, к примеру, на джаве?

Даже если, клиент формирует заявку через инет с помощью веб-морды, а манагер на месте, скажем, с помощью программулинки, написанной на, к примеру, на джаве?

Аааааааааааа, побью сейчас
Ну причем тут в ПТ идет архитектура?? Это должно быть все в ограничениях или НФТ, ну на крайняк в примечании в ВИ.

Аааааааааааа, побью сейчас
Ну причем тут в ПТ идет архитектура?? Это должно быть все в ограничениях или НФТ, ну на крайняк в примечании в ВИ.

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

Почему лучше? С целью наиболее понятного представления? Абстрактный ВИ может быть связан с каким-нибудь актёром? (с точки зрения нотации)

Формирование заявки не создает экземпляров. Это абстракция, которая конкретно реализуется либо в заявку клиента, либо в заявку от имени клиента

Абстрактный ВИ может быть связан с актером, если в каждом потомоке ВИ этот актер и участвует.

Пришла мысль. Либо вообще не делить, либо обыграть это с помощью расширения.

Т.е. Формировать заявку - расширяется регистрацией клиента например

Делать так "Менеджер наследует Клиента" - честно говоря очень не нравится, так как читающий эту диаграмму может понять такое наследование по своему...

Мне кажется вообще не стоит смешивать эти два ВИ в одну картинку - меньше путаницы будет

А еще лучше словами, словами - четче и понятнее))

Формирование заявки не создает экземпляров. Это абстракция, которая конкретно реализуется либо в заявку клиента, либо в заявку от имени клиента

Но ведь и другие ВИ тоже не создают экземпляров. Чего-то я не допонимаю...(

И ещё вопрос, а чем не абстрактный ВИ "Формирование заявки" у меня? По этой причине:

Абстрактный ВИ может быть связан с актером, если в каждом потомоке ВИ этот актер и участвует.

?

Но ведь и другие ВИ тоже не создают экземпляров. Чего-то я не допонимаю...(

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

Абстрактный ВИ не имеет явной реализации, он реализуется через свои конкретные ВИ

И ещё вопрос, а чем не абстрактный ВИ "Формирование заявки" у меня? По этой причине:?

Абстрактный имеет стереотип и пишется обычно Наклонным шрифтом

Делать так "Менеджер наследует Клиента" - честно говоря очень не нравится, так как читающий эту диаграмму может понять такое наследование по своему...

Вообще то я тоже так думаю, но с наследованием, я так понимаю, правильнее, и вот как быть в таком случае? Делать как правильно или как понятнее?

А еще лучше словами, словами - четче и понятнее))

Много букв - это утомительно. А ДВИ можно на стену повесить и любоваться. =) Станции и линии метрополитена тоже "зачем-то" рисуют схемой, хотя, можно было бы текстом...))

------------------------------------------------------------------------------

Новый вариант ДВИ:

Много букв - это утомительно. А ДВИ можно на стену повесить и любоваться. =) Станции и линии метрополитена тоже "зачем-то" рисуют схемой, хотя, можно было бы текстом...))

Там связи всего лишь двух типов - переместиться на поезде и пешком (пересадка) - никаких двусмысленностей не допускается. А тут какието пять ВИ вызывают вполне серьезную полемику и неоднозначность!!!! Именно в таких случаях текст работает... А теперь представьте себе что вариантов будет не пять а сто пять и разбираться в такой схеме/схемах да еще при наличии наследований и прочих "прелестей" UML будет очень проблематично и говорить об однозначном прочтении таких диаграмм скорее всего не придется

PS сорри за много букв

А тут какието пять ВИ вызывают вполне серьезную полемику и неоднозначность!!!! Именно в таких случаях текст работает... А теперь представьте себе что вариантов будет не пять а сто пять и разбираться в такой схеме/схемах да еще при наличии наследований и прочих "прелестей" UML будет очень проблематично и говорить об однозначном прочтении таких диаграмм скорее всего не придется

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