В теме 20 ответов, и 5 участников, последнее обновление сделано пользователем 
Julia 14 г назад.
-
Сообщения
-
Всем привет.
Тут в большинстве своем, как вижу, обсуждаются темы довольно абстрактные.
Я хотел бы удариться в конкретику и реальную проблему, с которой столкнулся на проектах.
Сначала вступление:
В моем представление есть несколько концепций визуализации вариантов использования (что кому ближе и удобнее) и среди них есть 2 близко знакомых мне лично:
1) Упрощенно, юз кейсы "ромашкой" — то бишь чисто то, что мы можем получить от системы без временных связей между юз кейсами.
2) Юз кейсы, визуально отражающие последовательность их выполнения.
Я лично предпочитаю вариант номер 2 и знаю, что такой способ пользуется определенной популярностью в силу своей наглядности.
Но при таком отображении, ассоциации отображаются только между актером и юз кейсами высшего уровня (остальные, так как они расширяют юз кейсы высшего уровня, не имеют графического отображения ассоциации с актером).
Так вот.. ситуация.. Представим, что у нас 2 актера и 3 юз кейса, как показано на диаграмме ниже:
Проблема в том, как показать, что актер 2 имеет право выполнить юзе кейс "удалить сущность", а актер 1 нет.
Варианты:
1) Поставить прямую ассоциацию на месте красной линии на рисунке. но в данном случае возникнет представление, что данный юз кейс актер может выполнить напрямую, минуя юз кейс "просмотреть список сущностей".
2) Ваши варианты???Я лично в таком случае обхожусь пометками и комментами на диаграмме, но это не очень наглядный способ.
Если поделитесь мнениями, буду признателен.Я отвечу, наверное, немного не так, как ты ожидаешь.
Когда-то давно, мы обсуждали подобные случаи. С тех пор, я пришел к следующему выводу.
Лично мое мнение, что в данном случае происходит нецелевое использование UC диаграмм. В частности, во втором твоем варианте ты пытаешься показать больше, чем может UC диаграмма: последовательность выполнения действий. Я считаю, что для такой цели необходимо использовать другие виды диаграмм: Activity, Sequence, Timing.
Опять же, не стоит забывать про цель, которую ты преследуешь на конкретной диаграмме. Если целей у тебя несколько (показать всевозможные UC, показать все взаимосвязи между UC, показать какие актеры имеют отношение к соответствующим UC), то может имеет смысл разделить диаграмму на несколько? Ведь пытаясь достичь несколько целей сразу, ты загромождаешь диаграмму дополнительными элементами, снижая уровень её читаемости и понятности.Лично я тоже предпочитаю вариант №2, т.е. тоже стараюсь отобразить последовательность выполнения вариантов использования.
Но при этом я не проставляю ассоциации между всеми актерами и вариантами использования. Поскольку это достаточно сильно нагружает диаграмму, особенно если модель вариантов использования достаточно развернутая. Как правило, я ограничиваюсь только ассоциацией между одним актером и основными вариантами использования и отображением взаимосвязи между актерами. Ассоциацию между вариантами использования и актерами я документирую в табличном виде в документе. Как показывает практика, наглядность и понимание картины вцелом от этого не страдают. В любом случае, одной диаграммой вариантов использования всего не покрыть, поэтому я и не стараюсь отобразить как можно больше информации на 1 диаграмме
Всем спасибо за ответы!
Я бы прокомментировал некоторые мысли выше:Я считаю, что для такой цели необходимо использовать другие виды диаграмм: Activity, Sequence, Timing.
Ну тут на самом деле вопрос — мы следуем UML-нотации или кастомизируем ее под личные нужды. Activity и Sequence диаграммы, насколько я представляю, применяются в основном для визуализации конкретных прецедентов. А вот расписать целую юз кейс диаграмму с помощью одной или набора behavioral диаграмм — я пока не особо представляю, как это будет смотреться.
По этому же поводу, если интересно, я уже создавал тему на linkedin.com — How to properly reflect sequence of use cases in UML? (http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1216497&discussionID=12486006&goback=.anh_1216497).
Вообще после обдумывания я пришел к выводу, что диаграммы, помещенные мною в изначальный пост — неверны с точки зрения использования элементов.
Связь "extend" не предназначена для использования в данном контексте. Но тем не менее есть альтернативные стереотипы (в EA — встроенные, в других тулах в случае отсутствия — пользовательские) — "preceds" и "invokes". Учитывая то, что в EA — это стандартные элементы юз кейс диаграмм, я предполагаю, что не только я один решил использовать юз кейс диаграммы немного нетипично:).Уважаемый коллега Gerych я подготовил для Вас довольно подробный ответ по решению описанной выше проблемы с диаграммами в качестве иллюстраций, но что-то никак не догоняю, как втиснуть сюда в текст рисунки. Я давил кнопку Img, но там он должен быть как ссылка. Подскажите, пожалуйста как выйти из положения?Я обычно обхожусь без Img. Внизу под кнопками "Сохранить", "Отправить" есть таб "Добавить вложения". Добавляйте ваш рисунок как вложение, через предпросмотр убедитесь, что рисунок отображается в сообщении и все должно быть ОК.Внизу под кнопками "Сохранить", "Отправить" есть таб "Добавить вложения".
Большое спасибо, все понятно!
Вы упомянули, что то, что я хотел изобразить, "показывается элементарным образом".
Не могли бы показать, как?
Нужно с рациональными эффортами отобразить варианты использования системы и последовательность их выполнения с точки зрения интерфейса. В моем варианте (его можно глянуть тут) рациональность достигается использованием только одной диаграммы (ну то есть можно было, конечно, построить диаграмму последовательностей или активностей, как дополнение, но это все же еще один рисунок). Я знаю, что есть вариант (если не ошибаюсь, расширение стандарта UML) использовать связь precedes, которая добавляет динамики в юз кейс модель. Что бы вы посоветовали?Буду очень рад оказаться Вам полезным и дать развернутый ответ! Извините за задержку, было много работы (вчера выиграли тендер!!!)
Но прежде всего я хочу заметить, что коллега Юрий Веденин совершенно правильно, хотя и очень кратко, уже, в принципе, ответил:
что в данном случае происходит нецелевое использование UC диаграмм. В частности, во втором твоем варианте ты пытаешься показать больше, чем может UC диаграмма: последовательность выполнения действий. Я считаю, что для такой цели необходимо использовать другие виды диаграмм: Activity, Sequence, Timing.
— это по поводу последовательностей и того, что показано на диаграмме 2 и
Если целей у тебя несколько (показать всевозможные UC, показать все взаимосвязи между UC, показать какие актеры имеют отношение к соответствующим UC), то может имеет смысл разделить диаграмму на несколько?
— а это как сделать диаграмму 3 более понятной, применяя только нотацию UML.
Теперь постараюсь дать свое объяснение.nousy123,Спасибо за развернутый ответ. Я в целом согласен с тем, что вы изложили в приаттаченном документе. И хоть ничего нового я для себя не почерпнул, но все же почитать было интересно.
Также от себя прокомментирую некоторые ваши фразы:1.
Никаких последовательностей, в том числе, последовательностей включения в базовый и последовательностей расширения базового, Use Case-диаграммы НЕ отображают.
В строго нативном UML — не отображают. В его версиях, адаптированных под конкретные нужды (не мной
) — ну, вы знаете, что я тут скажу…
Хочу отметить, что одно из достоинств UML — его расширяемость, позволяющая как минимум вводить собственные стереотипы. Поэтому если я соединю 2 юз кейса связью depends и поставлю над ней, к примеру, стереотип "прикинь, этот юз кейс похож на вон тот", я все еще действую в рамках UML нотации. Но вы можете возразить, мол, а поймут ли, то, что я написал, другие люди. И вы будете абсолютно правы — это будет на моей совести. Если я уверен, что меня поймут и предпочтут мой вариант, то я так и сделаю (что собственно и описано в моих постах выше).2.
Других связей между Use Case, в том числе и precedes ни в UML 1.5, ни в UML 2.0 нет.
Хм.. Если вам интересно, то precedes связь — часть open modeling language, руку к которому кстати, что не безынтересно, также приложили Буч и Якобсон. И цель этой связи — добавление поведенческого аспекта в юз кейс диаграммы.. Это так, про классиков поговорить.. Но мы же UML тут обсуждаем, поэтому ближе к телу
— считайте, что это dependency связь с кастомным стереотипом. Про допустимость своих стереотипов я уже отписал выше. Ну а dependency — абсолютно валидная согласно UML стандарту связь (extend, include — это dependency c "официальными" стереотипами).3. Теперь насчет связи extend… Все, что напишу ниже не считайте истиной в последней инстанции — просто хочется порассуждать на эту тему.
Итак, официальное определение связи extend (OMG UML specification (UML Superstructure Specification, v2.1.1, p. 587)):This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case.
Какие выводы я могу сделать из этого определения:
1)
У вас же здесь это просто выбор актера, который это делает через GUI, и никакого условия (решающего правила) указать не возможно.
А чем решение актера не extension point? Могу процитировать еще такую фразу (на этот раз из хелпа Enterprise Architect — скажу честно, было лень искать нечто подобное по OMG UML spec, поэтому ваше право эту фразу не принимать): An extending Use Case often expresses alternate flows. Разве alternate flows не могут определяться выбором актера и его решением, как ему пойти дальше/с чего начать/чем закончить?
2) Вы утверждаете, что в моем случае нужно было 2 юз кейса — просмотреть список с удалением и просмотреть список без удаления. Цитирую определение выше: extended use case is defined independently of the extending use case. Это означает, что расширяемый юз кейс ничего не знает о том, что его расширяет. Думаю дальше объяснять не нужно.
В любом случае, еще раз спасибо вам за то, что потратили время на этот вопрос и удачи в этом нелегком деле.
Поэтому если я соединю 2 юз кейса связью depends и поставлю над ней, к примеру, стереотип "прикинь, этот юз кейс похож на вон тот", я все еще действую в рамках UML нотации. Но вы можете возразить, мол, а поймут ли, то, что я написал, другие люди. И вы будете абсолютно правы — это будет на моей совести. Если я уверен, что меня поймут и предпочтут мой вариант, то я так и сделаю (что собственно и описано в моих постах выше).
Скажу Вам коллега честно, что меня эти сомнения и вопросы тоже раньше очень сильно волновали. И мне казалось, что раз язык открытый, а мне не удается что-либо показать его стандартными средствами, то я всегда вправе внести свои стереотипы, которые мне и, возможно другим будут понятнее. И так я думал до тех пор, пока, кажется в 2001(или в 2000) году не посетил на выставке "CeBit" в Ганновере стенд "Rational Software" и пообщался с представителями фирмы. Стенд был двухэтажный, на втором этаже они принимали посетителей и отвечали на вопросы, а на первом размещались отдельные презентационные группы, которые демонстрировали сугубо специфические направления (например, группа от Commerzbank демонстрировала Rational Rose со своими специфическими стереотипами, заточенными под особенности моделирования банковской деятельности, другая группа от концерна Simens демонстрировала RR, но уже со специальными стереотипами для моделирования микропроцессорных систем и т.д.). Во время нашего общения мне было сказано, что конечно, я могу туда сам вносить, что мне угодно, вплоть до разработанных самостоятельно стереотипов, но только ведущие фирмы-разработчики, законодатели моды в своем направлении могут их узаконить в качестве общепринятых стандартов, а мои нововведения останутся понятными, только мне самому. Кроме того мне было пояснено, что в стандарт уже введено все, что требуется для моделирования основных категорий. Они водили меня по нижним стендам и старались объяснить специфику. После этой встречи я по другому взлянул на то, что я делаю и полностью отказался от введения собственных элементов и от фривольного употребления связей, но самое интересное в том,что все оказалось совершенно просто показать стандартными методами! Зачем вводить свое, только мне понятное и только мной принимаемое, если все можно легко отобразить стандартными средствами?
В строго нативном UML — не отображают. В его версиях, адаптированных под конкретные нужды (не мной ) — ну, вы знаете, что я тут скажу…
В языке UML заложен механизм для представления трех основных категорий анализа это:
1. Представление Logical View. Моделирование сущностей предметной области, объектов, классов (все это является именами существительными)
2. Представление Use Case View. Моделирование функциональности: бизнес-актеры и их функциональные обязанности, актеры и Use Case
3. Представление Process View. Моделирование процессов, алгоритмов, последовательностей, состояний и условий перехода из одного в другое.
Встает вопрос, если последовательности моделируются в отдельном представлении и именно для этого предназначенными диаграммами, то зачем я буду использовать то, что для этих целей не предназначено? Конечно и винт можно не отверткой, а ножом откручивать, но из этого не следует правила,что ножи служат для выворачивания винтов и шурупов.Хм.. Если вам интересно, то precedes связь — часть open modeling language, руку к которому кстати, что не безынтересно, также приложили Буч и Якобсон.
Возможно, но ни в стандарте UML 1.5, ни в стандарте UML 2.0 я этой связи не нахожу! Возможно, она применяется для каких-то специфических вещей, но мы обсуждаем возможности стандартных методов.
А чем решение актера не extension point? Могу процитировать еще такую фразу (на этот раз из хелпа Enterprise Architect — скажу честно, было лень искать нечто подобное по OMG UML spec, поэтому ваше право эту фразу не принимать): An extending Use Case often expresses alternate flows. Разве alternate flows не могут определяться выбором актера и его решением, как ему пойти дальше/с чего начать/чем закончить?
Формально или лучше сказать утрированно, каждое решение актера нажать ту или иную клавишу или пункт меню, или еще какие-либо с GUI являются extension point и в качестве Guard Condition мы можем в квадратных скобках указать "Клавиша нажата" и "Клавиша НЕ нажата". Тогда функционал практически любой программной системы можно тоже утрированно показать одним "большим" базовым Use Case-ом с кучей присоединенных к нему extend "маленьких", но такого нигде нет, потому, что обычная диаграмма "ромашкой" уже представляет этот выбор актера. В обычной Use Case-диаграмме ассоциация между актером и Use Case уже предусматривает нажатие соответствующей клавиши — в этом смысл ассоциации! Поэтому связь extend правильнее применять для показа не выбора актера нажать ту или иную клавишу, а именно для решения со строгими граничными условиями, как я показал Вам в своем примере.
Вы утверждаете, что в моем случае нужно было 2 юз кейса — просмотреть список с удалением и просмотреть список без удаления. Цитирую определение выше: extended use case is defined independently of the extending use case. Это означает, что расширяемый юз кейс ничего не знает о том, что его расширяет. Думаю дальше объяснять не нужно.
В притаченном файле, я, извиняюсь, вообще написал, что в Вашем случае я бы применил самую первую из представленных мной там диаграмм, т.е. вообще без всяких extend. Потом я привел пример из двух диаграмм с более корректным использованием связи extend — и в реальном проекте я бы так две диаграммы и оставил бы. Но так как Вы хотели, чтобы была одна диаграмма, я свел все в одну, и в своем примере, и потом как могло бы быть в Вашем случае, но при этом я уже ранее сказал, что такая диаграмма мне совершенно не нравится и тут я только хотел показать, что в Вашем случае имеют место не один, а два разных юз кейса с разными сценариями, и только один один из них расширяется функционалом "Удалить сущность", а второй нет. Что тут Вас смутило? Это не моя диаграмма, а Ваша, а я ее только чуточку подправил, чтобы выйти из ситуации, когда один актер может удалить сущность, а второй нет.
А чем решение актера не extension point?
Дам еще иллюстрацию на это утверждение.
В первом случае покажем решение актера как extension point:atm-chart.jpg
Во втором случае я не показывал выбор актера как extension point. Какая из диаграмм по Вашему мнению лучше и читабельней?И хоть ничего нового я для себя не почерпнул, но все же почитать было интересно.
Спасибо, но на какую-то новизну, расписывая стандартные применения, согласитесь, вряд ли приходится рассчитывать. У меня есть и свои некотрые методики и взгляды, которые можно трактовать как новые, но они НЕ противоречат, а дополняют стандартные подходы. И об этом я рассчитываю написать в своей книге. Только вот врмени ее писать катастрофически не хватает…
Я понял вашу точку зрения. Спасибо за ответы. Я уже, в принципе, все что хотел сказать, высказал. Надеюсь вы тоже остались довольны дискуссией.Я понял вашу точку зрения.
Спасибо за то, что вы все же постарались понять мою точку зрения, ну, а отвергать ее или принимать, это ваш личный выбор.
В заключение, я хотел бы высказать еще следующие мысли, частично из классиков, а частично мои:
1. «Варианты использования управляют архитектурой программной системы, а архитектура системы оказывает влияние на выбор вариантов использования» (это из классиков), и я всегда стараюсь об этом помнить. Каждый Use Case уникален и его поведение реализуется уникальной, только для него созданной архитектурой. В конечном итоге, какие мы создали Use Case-диаграммы, такую архитектуру мы и получим на выходе. Поэтому, создавая отдельный юз кейс, я не только показываю, ЧТО должна делать система, но и представляю его сценарий и прикидываю КАКИМИ ОБЪЕКТАМИ и, соответственно, классами можно реализовать это поведение.
2. Каждая функция бизнес-логики системы должна иметь отображение в Use Case-диаграмме (в виде отдельного юз кейса или входить в более общий) – это свойство трассируемости. Учитывая это, я стараюсь создавать Use Case-диаграммы, которые, по сути, являются «чертежами» (а не «эскизными набросками»), по которым можно управлять процессом разработки и создавать архитектуру программной системы. А любой чертеж требует стандартной нотации и семантики, и не терпит вольных отступлений.Вот, кажется тоже все, что я хотел здесь сказать. Желаю вам успеха и творческих побед!
Для всех интересующихся я притачу стандарт UML 2.0 на русском и немецком (от OOSE, вдруг есть кто кроме меня работает с немцами) языках.
[img]http://pics.picvol.com/timeusecases49230[/img]
Всем привет!
Очень приятно, что находятся темы (и форумы), где обсуждаются конкретные примеры.
Хотелось бы задать один уточняющий вопрос.
Герман, скажите, пжл, что имеется ввиду под стереотипом связи "extends"?
Я лично знакома с "extend".Extend и имеется в виду. Быстро рисовал, по памяти.
Вы должны авторизироваться для ответа в этой теме.
