Добрый день,

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

Вот что у меня есть.
Краткая постановка задачи:

Компания передает контрагентам безвозмездно товары для их реализации. Соответственно нужно иметь возможность отражать в системе факты передачи товаров контрагентам, факта реализации товаров со склада контрагента, проводить инвентаризацию товаров у контрагента и получать товары от контрагента обратно.

Как я себе вижу картину вариантов использования:
1. Учет товаров переданных контрагенту
1.1 Передача товаров контрагенту. Может выполняться любой из "Подчиненных ВИ"
1.1.1 Передача товаров без ордеров оформлением документа "Передача товаров контрагенту"
1.1.2 Передача по ордерной схеме оформлением документов "Передача товаров контрагенту", "Расходный ордер на товары", "Приходный ордер на товары"
1.2 Реализация товаров у контрагента
1.2.1 Оформление документа "Отчет о продаже"
1.3 Проведение инвентаризации товаров у контрагента
1.3.1 Если выявилась недосдача - списание товаров
1.3.2 Если выявились излишки - оприходование товаров на склад компании, затем - 1.1. (Передача товаров контрагенту)
1.4 Прием товаров от контрагента
1.4.1 Если выявилась недосдача - списание товаров
1.4.2 Если выявились излишки - оприходование товаров на склад компании

1. Как Вы понимаете существуют разные уровни рассмотрения вариантов использования и область контекста.
2. ВИ не декомпозируются - это будет неправильно, но можно декомпозировать цели
3. Естественно начинать сверху вниз от целей бизнеса к целям пользователей
4. Естественным инструментом декомпозии в UML является пакет
5. Подсистема разбивается еще на ряд подсистем, задач, модулей, компонентов
6. Для каждого такого деления выстраивается модель взаимодействия, которая включает описание ВИ, причем диаграмма тут имеет последнее значение
7. Вариант использование - это элементарный бизнес-процесс производимый одним человеком в одном месте за один сеанс деятелности и приводящий к ощутимому результату, изменению состояния системы
8. ВИ описывает потребную с точки зрения пользователй функциональность системы
9. Логика работы такой функциональности может описываться диаграммами деятельности в первую очередь, а такжде системными диаграммами последовательностей во вторую

Кстати документо оборот лучше описыать с помощью DFD имхо

1. Как Вы понимаете существуют разные уровни рассмотрения вариантов использования и область контекста.
2. ВИ не декомпозируются - это будет неправильно, но можно декомпозировать цели
3. Естественно начинать сверху вниз от целей бизнеса к целям пользователей
4. Естественным инструментом декомпозии в UML является пакет
5. Подсистема разбивается еще на ряд подсистем, задач, модулей, компонентов
6. Для каждого такого деления выстраивается модель взаимодействия, которая включает описание ВИ, причем диаграмма тут имеет последнее значение
7. Вариант использование - это элементарный бизнес-процесс производимый одним человеком в одном месте за один сеанс деятелности и приводящий к ощутимому результату, изменению состояния системы
8. ВИ описывает потребную с точки зрения пользователй функциональность системы
9. Логика работы такой функциональности может описываться диаграммами деятельности в первую очередь, а такжде системными диаграммами последовательностей во вторую

Кстати документо оборот лучше описыать с помощью DFD имхо

ничего не понял(

Хочу разложить большую подсистему на меньшие составляющие. Как мне это сделать с использованием UML?

Плохо, раз ничего не поняли :-( ...
По-всей видимости вы не поняли самого главного -- юзкейсы это не ФУНКЦИИ системы, и не всегда бизнес-процессы как таковые ... это цели пользователя, т.е. взгляд на систему со стороны пользователя, а не со стороны декомпозиции функций системы.
Разложение системы на меньшие составляющие в каком смысле? С т. з. функциональности системы? Или с т.з. ее архитектурного дизайна???

Плохо, раз ничего не поняли :-( ...

Ногами сильно не пинайте. Я только встал на путь анализа и проектирования. До этого заказы мы выполняли "по наитию".
То что ЮзКейс - это цель - я понял из книги Коберна (хотя книга далась тяжело). Но почему не возможна декомпозиция цели - я не понимаю. Допустим Цель - "Учет товаров переданных контрагенту". Что бы достичь данной цели пользователь должен 1."Передавать товары контрагенту" и т.д.
Чем не декомпозиция?

Пока писал ответ - пришла в голову мысль: "А можно ли назвать "Учет товаров переденных контрагенту" целью?

Сергей,

Давайте разобьем ВИ на два типа пока - БВИ (уровня неба) и СВИ (уровня цели Пользователя)
И начнем с БВИ.

Например "Учесть товары, переденные контрагенту" распишите с т.з. БВИ  виде сценария. Т.е. выберите основной сценарий, по кот. присходит учет и альтернативные. Так м.б. быть будет более понятно.

А вообще описывать БП с помощью БВИ - это не самый лучший вариант.

Ногами сильно не пинайте. Я только встал на путь анализа и проектирования. До этого заказы мы выполняли "по наитию".
То что ЮзКейс - это цель - я понял из книги Коберна (хотя книга далась тяжело). Но почему не возможна декомпозиция цели - я не понимаю. Допустим Цель - "Учет товаров переданных контрагенту". Что бы достичь данной цели пользователь должен 1."Передавать товары контрагенту" и т.д.
Чем не декомпозиция?

Цель декомпозируема - это факт. Но ВИ не функция, ВИ отражает цель пользователя, а не является ее сам по себе. ВИ это способ использования системы для достижения ЦЕЛИ. Естественно возможны варианты. Эти варианты и описывает ВИ. Такие варианты называются для ВИ сценариями. Сценарий может быть успешным - цель достигнута, и не успешным - цель не достигнута или достигнута лишь частично. ВИ - это соглашение о том, как пользователь использует систему, чтобы достичь своих целей - в данном случае выполнить свои функциональные обязанности. Можно ли назвать целью Напечать отчет? А зачем? не есть ли отчет результат достижения цели?
ВИ - можно сказать транзакция - она или выполняется или не выполняется. В ходе транзакции выполняются разные ФУНКЦИИ, обладающие АЛГОРИТМАМИ. Вот функции можно декомпозировать, а как декомпозировать ВИ - на шаги? А разве шаг есть часть цели (подцель)? Конечно нет!

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

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

Если вы используете понятие бизнес ВИ, то по сути описываете вариант использования бизнес-системы, т.е. некоторый бизнес-процесс. Описываете как складывается взаимодействие.

Бизнес ВИ не декомпозируется - а реализуется через часть пользовательских ВИ, задает для них контекст

Пока писал ответ - пришла в голову мысль: "А можно ли назвать "Учет товаров переденных контрагенту" целью?

Цель имеет два состояния - (ничего не напоминает) соответственно - задайте себе вопрос достигнута цель: Учета товаров переданных контрагенту или нет. Каков критерий измерения достижения цели?
Или задайте вопрос, а зачем учитывать товары переданные контрагенту, каков интерес?

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

А вообще описывать БП с помощью БВИ - это не самый лучший вариант.

БАС, а как же тогда?

Эдуард, спасибо за столь развернутый ответ!

Чувствую, что истина где-то рядом, но уловить не могу.
Можете мне хотя бы намекнуть, каким образом можно описать цель "Учесть товары, переданные контрагенту"

БАС, а как же тогда?

Когда-то, после долгого изучения, я понял, что не знаю "с лёту" как можно описывать БП кроме как через БВИ
Вот, например, посмотрите здесь:
http://www.sql.ru/forum/actualthread.aspx?tid=441853

Единственный способ овладеть техникой ВИ  - это делать и еще раз делать примеры. Посмотрите здесь пример:
http://www.uml2.ru/forum/index.php?topic=286.0

Можете мне хотя бы намекнуть, каким образом можно описать цель "Учесть товары, переданные контрагенту"

Кто лучше вас может ответить на этот вопрос? Но я попробую.

Цель - это некое состояние, которое мы хотим достигнуть. Что мы хотим достигнуть в "Учесть товары, переданные контрагенту". Действительно ли это наша цель? Или это задача, которую мы должны выполнить, чтобы достигнуть чего-то, что и будет конкретной целью?

Однако можем ли мы сказать, что пользователь желает, хочет, обязан "Учесть товары, переданные контрагенту". Кажется вполне разумным. Но что такое учесть? Записать в журнале список товаров и имя контрагента? Внести в базу данных накладную, которая фиксирует факт передачи товаров контрагенту? Чувствуете разницу между учесть и записать, фиксировать факт. Конечно, можно оставить и учесть, если это понятно и понимаемо без всяких возражений.

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

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

Читая вспомнила... Была поставлена задача разработать регламент по взаимодействию гос. органов и банка второго уровня для оформлении кредита физического лица. Чтобы оградить его несчатстного от беготни в гос. органы за справками. На месте банк запрашивает необходимую информацию у гос. органов о данном физ. лице и выдает или не выдает кредит. Встал вопрос определения конечной цели: гос. органы утверждали, что конечной целью с их позиции является получение справки о... физическим лицом. Банки утверждали, что запрос справок для физ. лица не является целью, основной целью является получение кредита, а процессы гос. органов являются обеспечивающими в данном БП. И конечно физ. лицо было на стороне банка . Вот как бывает! 

anastazya,

Денис вроде бы даже делал доклад о моделировании противоречий\удовлетворении Целей... А чем все закончилось??