16

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 10 Апреля 2012, 08:03:16 »

Если создание модели вызывает такие сложности, то насколько просто будет даваться её чтение потребителем?
Практичность «вопроса» в чём?

Разработка ведется для нужд нашей компании, "потребитель" в UML вообще ни ухом, ни рылом. Функциональные требования описываются в UML скорее для нужд разработчика, для более ясного понимания системы и упрощения дальнейшего анализа, разработки и сопровождения. К тому же я попутно хотел бы с ним освоиться: вещь нужная, а знаю его только по книжкам. Попрактиковаться, освоить CASE-средства, в таком вот акцепте.

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

Я бы все-таки избегал обощения модератором свойств автора. Это суть реализации, разделение полномочий на исполняемые действия, а не суть задач. Автор  - это не модератор, это однозначно. Потому не надо нарушать логику предметной области в угоду изобразительного искусства.

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

Но в МВИ мы ведь описываем функциональность, а не архитектуру. Что будет делаться, а не как. А с точки зрения функционала транслирование (в это определение включаю все: от публикации до управления своей трансляцией) и модерирование - действительно разные вещи. Может быть, действительно идеологически более верно пока что плюнуть на схожесть функций этих актеров, сделать:
Автор трансляции -> CRUD Трансляции
Модератор трансляции -> Модерировать трансляцию
А уже на фазе анализа и проектирования внести ясность: что такой-то и такой-то функционал будет реализован одним и тем же классом, т.к. по сути это одно и то же?

Я сам уже склоняюсь к такому варианту, но в силу неопытности до конца не уверен...

Потому спрашивается, если есть модератор, наверное, есть и администратор? Почему бы его не изобразить?

Ну, сами требования еще на стадии формирования. По идее, конечно нужен юзер с более высокими чем у модера привелегиями. Просто об это еще подумать не успели 

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

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

Обобщение акторов показывает не способы распределения ролей. То, что Вы описываете, будет означать, что в роли Пользователя могут выступать как Модератор, так и Автор и, соответственно, они могут участвовать во всех UC, в которых участвует Пользователь [выполняя его роль].

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

17

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 09 Апреля 2012, 16:17:52 »

Ну а логически подумать? Автор наследует действия Модератора по управлению трансляцией.

Да, точно, спасибо.


Т.е. есть несколько путей:

1) Забить болт на все хитрости и просто выделить столько ВИ, сколько нужно.



2) Таки использовать обобщение, указав все тонкости (по разграничению прав и неполном наследовании) в спецификации.




3) Использовать CRUD-паттерн (как я понял, там используется несколько основных потоков в ВИ). С этим колдунством пока не разобрался. Уже скачал книжку "Современные методы описания функциональных требований" (Алистер Коберн) - там по этой теме целая глава, а еще вот эту темку. Но у меня уже поздний вечер, так что вникать буду завтра...

Не буду здесь грузить. Будет интересно - пишите в личку.

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

Еще рекомендация: не используйте термин "прецедент". Это просто неверный перевод термина USE CASE. И уже очень давно не используется.

Это я Вендрова начитался Буду иметь в виду.

Большое спасибо всем откликнувшимся. Уж завтра-то я эту гаденькую диаграммку дорисую... 


P.S. сорри за портянку, не нашел у вас тега MORE.

P.S.S. Кстати, по ссылке с гугла Варианты использования CRUD PHP выдает сообщение об ошибке и херит сессию (Боже, храни гуглкэш!).

18

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 09 Апреля 2012, 09:58:21 »

Очевидно, автор может что-то делать только со СВОЕЙ трансляцией, модератор может делать РАЗРЕШЕНИЯ по любой из трансляций. Ясно, что никакого обощения уточнения тут нет, т.е. мы не можем сделать генерализацию, т.к. ни при каких обстоятельствах нельзя сказать:
модератор - это автор, но частично можно было бы сказать - автор - это модератор (но только своих трансляций), однако это все-таки не полное наследование (а выброчное), тоже нельзя применить явно.

Вот-вот, это самое мне покоя и не давало, потому и прибежал советоваться.

Кстати а что за система?

Если кратко - то что-то вроде видеотрансляций на сайте. Автор создает трансляцию, зрители к ней подключаются и зыркают. У трансляции есть несколько настроек (например: защита паролем, только для взрослых и др.). Плюс текстовый чат.

Автор может создать новую трансляцию, закрыть (удалить) свою текущую, изменить настройки своей текущей трансляции.
Модератор может удалить любую трансляцию или изменить настройки любой трансляции. Если модератор трансляцию создает, то он становится ее Автором... т.е. это функционал уже другого актера.

Но все, что касается именно трансляций - это скорее ПОДсистема, т.к. в проекте еще предусмотрена возможность видеоконференций и прочего. Т.е. утверждение:

Ваша модель использования небольшая

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

Как я понял, особого выхода нет и нужно делать ВИ:
Создать трансляцию (хотя он получится смехотворно малым) - его будет осуществлять Автор.
Модерировать трансляцию (или Управлять трансляцией) - подразумевается удаление трансляции и изменение ее настроек. Этот ВИ может осуществляться и Автором, и Модератором.

Что-то вроде этого?

(со стрелочкой в сторону модератора - косяк, еще не разобрался как следует с инструментарием RSA)

3. Между "Модератором" и "Создателем трансляции" поставил бы связь обобщение, и в бизнес-правилах ВИ "Модерировать трансляцию" написал бы, что Модер может изменять/удалять любые трансляции, а Создатель может это делать только со своими.

Кстати да, мысль была, но уверенности в правильности не было... А кого "во главу угла" при этом ставить Создателя (Автора)? Но опять таки, модератор может модерировать не только трансляции, но и конференции... Т.е. все-таки лучше разделить эти роли между актерами "Модератор Трансляции", "Модератор Конференции"?.. Лицо вроде одно, но роли разные...

Спасибо за ответы.

19

Примеры / Модель прецедентов использования - практический вопрос

« : 09 Апреля 2012, 08:08:10 »

Здравствуйте! У меня маловато опыта в использовании UML при проектировании, и сейчас вылезла одна неясность.

Пытаюсь создать более-менее адекватную модель прецедентов использования, вот ее кусочек.
Есть актеры:
1) Создатель трансляции - может создать трансляцию, удалить или изменить ее настройки;
2) Модератор - модерирует, т.е. также может удалять трансляцию или изменять ее настройки. Но не создавать, поскольку в этом случае он будет выступать в качестве "Создателя трансляции", т.е. в другой роли;
3) Зритель трансляции - соответственно, любуется на все это безобразие;

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

Как быть при создании вариантов использования? Множить сущности (модератор того, модератор сего, модератор десятого...) мне кажется не кошерным. По существу у него простые надзорные функции в разных разделах проекта: может править, может удалять.

Напрашиваются 2 варианта использования:
а) Транслирование - создание, удаление, изменение настроек;
б) Модерирование трансляции - удаление, изменение настроек;

Наблюдается дублирование функционала... Вроде как, при этом следует использовать связь "включение". После модификации прецедентов получаем:
Транслирование <- Управление трансляцией



Правильно ли в данном случае диаграмма отражает суть концепции? Т.е. что актер "Модератор" применяет вариант использования "Управление трансляцией", который сам является включением в вариант использования "Транслирование", который, в свою очередь используется актером "Создатель трансляции". Вообще, правомерна ли такая загогулина в UML?

Может быть все это следовало бы реализовать как-то иначе?

И еще пара отвлеченных вопросов. Существуют ли какие-либо общепринятые правила именования вариантов использования. Обратил внимание, что в RSA применяется конструкция ${use.case}. Т.е. именование с прописных букв и вместо пробелов точки? Возбраняется ли в Rational Software Architect применять русский язык, в частности - для именования элементов (актеры, варианты и т.п.)?

Большое спасибо.