Вопрос по диаграмме вариантов использования

Не знаете в какой раздел поместить свою тему? Кладите сюда

Вопрос по диаграмме вариантов использования

Сообщение nasttya » 12 июл 2011, 18:20

Добрый день.
Денис, подскажи, пожалуйста, как в UML решается следующая задача... Например, для системы существуют следующие кейсы:
1.Создать документ (входящий, исходящий, приказ и пр.)
2.Отправить документ на согласование
3.Подписать документ
и т.д.
роли: Регистратор, администратор, сотрудник канцелярии

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

Как отобразить это на диаграмме и как при этом должны описываться сценарии? Есть ли необходимость описывать отдельные сценарии для разных типов документов или этого можно избежать? Имеет ли смысл вообще выделять акторов если акторы (роли) не статичны и не заданы жестко?

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

Заранее благодарю.
nasttya
 
Сообщений: 15
Зарегистрирован: 27 авг 2009, 15:03

Re: Вопрос по диаграмме вариантов использования

Сообщение Denis.Ivanov » 12 июл 2011, 20:20

Добрый вечер

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

2) Что касается типов документов. Документ - это сущность и место ей - на диаграмме классов. Там можно с помощью отношения обобщения специализировать документы, т.е. ввести понятие "входящий документ", "исходящий" и т.п., ввести их атрибуты и пр.

3) Права пользователей, я бы представил в виде матрицы.
В таблице по вертикали пиши операции (создать, отправить, подписать, ...) , а по горизонтали названия документов (входящие, приказы, исходящие и пр.). В ячейках перечисляй те роли, которым разрешена данная операция над данным документом.
Надо понимать, что не все можно нарисовать на UML так, чтобы было понятно и доступно.
Если ты хочешь нарисовать это на UML тебе придется использовать диаграмму деятельности, которая будет описывать метод ... ПроверитьПраваНаОперацию(). Этот метод будет иметь три параметра: тип операции (создать, отправить, подписать, ...), тип документа (входящие, приказы, исходящие и пр.) и роль (регистратор, администратор, ...) Далее путем комбинации элементов диаграммы деятельности (в основном ромбиков) тебе придется описать логику такого плана: если документ=входящий и операция=создать и роль=регистратор, то возвращаем true.
Думаю, понятно, что таблица гораздо нагляднее и легче поддается поддержанию в up-to-date состоянии.
Блок-схема тоже не плоха, на самом деле. Нарисовав ее ты облегчишь жизнь программисту, так как опишеши логику на очень низком уровне и ему останется только перенести ее в код. Но право же, лучше сделать таблицу:)

4) В твоем случае надо различать Действующих лиц, т.е. тех, кто взаимодействует с системой и Роли (назовем их так), т.е. тех, кого придумывает Администратор и назначает им права доступа.

5)
nasttya писал(а):Если, например, какой то кейс аналогичен для нескольких подсистем имеет ли смысл дублировать описание сценария для каждой подсистемы? Например создать резолюцию можно как к входящему так и к исходящему документу в подсистеме Входящие документы и Подсистеме Исходящие документы.


Я бы написал общий сценарий, в котором фигурировал бы не "входящий документ" или "исходящий документ", а просто "документ". У тебя должна быть для данной сущности построена иерархия (см. 2) ), из которой будет понятно, что все то, что относится к "документу" (например, сценарий "создание резолюции") в равной степени применимо как к "входящему документу", так и "исходящему документу"
Denis.Ivanov
Администратор
 
Сообщений: 223
Зарегистрирован: 07 май 2009, 23:16

Re: Вопрос по диаграмме вариантов использования

Сообщение nasttya » 13 июл 2011, 04:45

Денис, спасибо за развернутый ответ.

С ролями и действующими лицами не совсем понятно. Как в данном случае может называться действующее лицо? Если на диаграмме мы отображаем акора и ассоциируем ему некие варианты использования не говорит ли это о том, что указаный акор и есть роль, наделенная набором полномочий? Есть предопределенный набор ролей: регистратор, администратор и пр. Если отображать каких то обстрактных действующих лиц, которые никак не связаны с ролями не запутает ли это разработчика?
nasttya
 
Сообщений: 15
Зарегистрирован: 27 авг 2009, 15:03

Re: Вопрос по диаграмме вариантов использования

Сообщение Denis.Ivanov » 13 июл 2011, 08:02

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

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

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

Может я не правильно понял задачу. Тогда уточни.

Что касается твоих вопросов.

nasttya писал(а):Как в данном случае может называться действующее лицо?

Мне кажется я ответил на этот вопрос выше. По крайне мере он должен следовать из моего понимания задачи.

nasttya писал(а):Если на диаграмме мы отображаем акора и ассоциируем ему некие варианты использования не говорит ли это о том, что указаный акор и есть роль, наделенная набором полномочий?

Совершенно верно, если "набор полномочий" коррелируется с ассоциированными вариантами использования.

nasttya писал(а):Есть предопределенный набор ролей: регистратор, администратор и пр. Если отображать каких то обстрактных действующих лиц, которые никак не связаны с ролями не запутает ли это разработчика?


Надо понимать что ты в итоге хочешь показать на диаграмме и кому она предназначена. Абстрактные ДЛ нужны только для того, чтобы снизить количество ассоциаций.
Пояснения тут и тут.
Denis.Ivanov
Администратор
 
Сообщений: 223
Зарегистрирован: 07 май 2009, 23:16

Re: Вопрос по диаграмме вариантов использования

Сообщение nasttya » 13 июл 2011, 18:54

Денис, большое спасибо. Все доходчиво и понятно!! Про абстрактных ДЛ, это я с терменологией погорячилась :oops: . Про них ты мне уже объяснял с этим понятно.
nasttya
 
Сообщений: 15
Зарегистрирован: 27 авг 2009, 15:03

Re: Вопрос по диаграмме вариантов использования

Сообщение nasttya » 13 июл 2011, 21:02

Denis.Ivanov писал(а):Добрый вечер
Не надо путать способы использования системы и реальные бизнес-процессы.

Это да. Но вот, что интересно... Получается, что варианты использования могут возникать в рамках какого то бизнес-процесса? Или все же не так? Как связать эти две вещи? Мне бы например хотелось отобразить и сам процесс, так как он происходит в системе и связать его с кейсами.
nasttya
 
Сообщений: 15
Зарегистрирован: 27 авг 2009, 15:03

Re: Вопрос по диаграмме вариантов использования

Сообщение Denis.Ivanov » 14 июл 2011, 18:57

Из данной задаче можно вывести такой бизнес-процесс (я напишу его в виде последовательности шагов - бизнес-действий)
1.1) создать документ
1.2) распечатать документ
1.3) отдать на подпись начальнику
1.4) подарить секретарше начальника коробку конфет
1.5) забрать подписанный документ

Я не пишу условия типа, "если документе не подпишут, то его надо переделать, а потом опять отдать на подпись", чтобы не усложнять.

Варианты использования для системы, которая помогла бы в этом бизнес-процессе, могли бы быть следующими:
2.1) создать документ
2.2) распечатать документ
2.3) изменить состояние документа ("отдан на подпись", "одобрен начальством" и т.п.)


Чтобы отразить бизнес-процесс воспользуйся диаграммой деятельности (опиши 5 шагов, как последовательность действий) и используй "дорожки", чтобы показать, какие бизнес-действия связаны с программной системой (1.1, 1.2), а какие не связаны (1.4) или связаны косвенно (1.3, 1.5)

Далее каждое бизнес-действие, связанное с программной системой, свяжи с соответствующим вариантом использования.
1.1 - 2.1
1.2 - 2.2
Вариант использования 2.3 - косвенно присутствует в бизнес-действиях (1.3, 1.5), т.е. предполагается, что отдав на подпись документ пользователь системы подойдет к компьютеру и изменит его статус, а в идеале это должна сделать секретарша, со своего рабочего места.

Ну вот что-то такое получается, хотя все конечно очень зависит от конкретной ситуации.
Denis.Ivanov
Администратор
 
Сообщений: 223
Зарегистрирован: 07 май 2009, 23:16

Re: Вопрос по диаграмме вариантов использования

Сообщение nasttya » 20 июл 2011, 07:18

Хорошая идея страссировать БП и ВИ, однако мне усложнили задачу. Необходимо как то описать БП, которые могут динамически изменяться в зависимости от настроек системы, т.е. может меняться маршруты прохождения документов , так же могут переспределяться полномочия между ролями. Получается, что работа каждого ВИ может проходить очень даже по разному и ДЛ могут быть разными. В планах получить некую коробку (конструктор), которую можно было бы настраивать в зависимости от потребностей Заказчика. На текущем этапе моя задача заключается в выявлении и описании требований понятных для разработчика. Как подойти к моделированию такой задачи ума не приложу. Задача усложняется еще и тем что сроки очень маленькие.Можешь ли ты что-то посоветовать в данной ситуации? Может избрать другой подход к моделированию и описанию? Может что то почитать где предлагается решение подобных задач? Возможно ты сам сталкивался с такими задачами? Буду рада любому совету.
nasttya
 
Сообщений: 15
Зарегистрирован: 27 авг 2009, 15:03

Re: Вопрос по диаграмме вариантов использования

Сообщение Denis.Ivanov » 20 июл 2011, 09:05

Мне кажется у меня есть, что тебе предложить.

Посмотри сначала на эту картинку
developer-teste-bug.png
developer-teste-bug.png (52.96 ) Просмотров: 8348


Здесь нарисовано как (все сильно упрощено) программист и тестировщик работают с багами.
Левая и центральная диаграммы - диаграммы деятельности, которые описывают что должны делать программист и тестировщик соответственно.
Правая диаграмма (диаграмма состояний) - жизненный цикл бага.

Если ты внимательно посмотришь на эти диаграммы (я постарался цветом выделить общие участки), то увидишь, что между деятельностью лиц (программист + тестировщик), которые работают над багом и состояниями бага существует однозначное соответствие.

К чему я веду? Любая деятельность (в твоем случае бизнес-деятельность) может быть представлена не только в виде набора деятельностей субъектов (например, сотрудника канцелярии, администратора...), но и адекватно отображаться через состояния объектов (например, приказа, входящего документа...), над которые эти субъекты совершают действия.

Твоя задача очень хорошо сюда ложится.
nasttya писал(а):Необходимо как то описать БП, которые могут динамически изменяться в зависимости от настроек системы, т.е. может меняться маршруты прохождения документов , так же могут переспределяться полномочия между ролями. Получается, что работа каждого ВИ может проходить очень даже по разному и ДЛ могут быть разными.


Я думаю, что тебе на первом этапе надо сосредоточится НЕ на деятельности действующих лиц и описывать НЕ их бизнесс-процессы, а уделить все внимание состояниям, в которых пребывают объекты, т.е. "входящие документы", "приказы" и пр.

Ведь по сути в таких задачах описания есть два пути в зависимости от того, что является постоянным: процесс (последовательность действий) или точка приложения процесса (состояния объекта и переходы между ними).
Обычно детерминированными (т.е. предопределенными) делают процессы, но у тебя обратный случай - процессы могут меняться, а значит постоянством должны обладать объекты, над которыми проводится работа.
Если же и то, и другое может меняться, то компактное описание всего этого хозяйства не возможно в принципе.
Denis.Ivanov
Администратор
 
Сообщений: 223
Зарегистрирован: 07 май 2009, 23:16

Re: Вопрос по диаграмме вариантов использования

Сообщение nasttya » 20 июл 2011, 18:48

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

Как отображать такие хитросплетения? Когда действие осуществляется над одним объектом, то все вроде понятно из того что ты нарисовал, а когда этих объектов много и статусов много?!

И что интересно, как из того, что ты отобразил можно перейти к функциональным требованиям? Уф...
nasttya
 
Сообщений: 15
Зарегистрирован: 27 авг 2009, 15:03

След.

Вернуться в Все остальноe