Форум Сообщества Аналитиков

Общий раздел => Примеры => Тема начата: mifody от 04 Октября 2008, 18:35:34

Название: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: mifody от 04 Октября 2008, 18:35:34
народ! Начинаю изучать UML
нарисовал UseCase диаграмму
насколько верно ее нарисовал  - не знаю

Можете написать конструктивную критику?
и разнести все мое творение в хлам

(без критики нормально проектировать не научишься)
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: Galogen от 04 Октября 2008, 23:36:57
Здравствуйте.

1. Слово "по критикуйте" не существует. Есть глалог покритикуйте с приставкой по-.

2. Это что Вы нарисовали? Попытка сделать алгоритм? Тогда причем тут use case. Подойдет Activity или DFD модель вообще.

3. Uses уже давно не используется, используется include

4. uses и extendes - зависимости, а не generalizationс соответствующим стереотипом

5. что это за акторы такие Запрос и Ответ, какие это они цели преследуют при взаимодействии с системой

Резюме - читаем книги, изучаем первоосновы языка, т.е. когда и почему следует использовать те или иные диаграммы.
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: mifody от 05 Октября 2008, 03:41:10
1. согласен что с русским у меня хромает )

2. попытка сделать UseCase диаграмму
с точки зрения что актер - пользователь, то да, диаграмма  похожа на алгоритм, но если посмотреть на диаграмму со стороны "ЗАПРОСА", то я думаю что она не раскрывает внутреннего содержания системы (некоторого участка  системы), а показывает варианты использования

3. Uses - в Visio используются "до сих пор" такие обозначения

4. В обще  не понял, сори

5. Цитата :
"Актер представляет собой любую внешнюю по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определённых целей или  решения задачи. ....  Формально в контексте языка UML 2.0 каждый актер специфицирует некоторую роль, которую играет пользователь или любая другая система, взаимодействующая с субъектом". (с)

Так что в принципе Актер - это пользователь, но иницировать работу веб-сервера может и скрипт, который сделает соответствующий запрос, поэтому по-моему мнению, актер в этом случае "запрос"


Резюме ))
Как раз читаю книгу "UML 2  Александра Леоненкова" и пробую делать диаграммы
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: bas от 05 Октября 2008, 11:53:48
Леоненков ничего не даст. Читаем по ВИ в первую очередь Коберна и наш ФАК на гл. странице.
И всегда помним, что ВИ - это ЦЕЛЬ ПОЛЬЗОВАТЕЛЯ по отношению к Системе.
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: Galogen от 05 Октября 2008, 21:47:15
1. согласен что с русским у меня хромает )
К сожалению не у Вас одного. Причина - мало читаем и сильно надеемся на проверку орфографии...

Цитировать
2. попытка сделать UseCase диаграмму
с точки зрения что актер - пользователь, то да, диаграмма  похожа на алгоритм, но если посмотреть на диаграмму со стороны "ЗАПРОСА", то я думаю что она не раскрывает внутреннего содержания системы (некоторого участка  системы), а показывает варианты использования
Актор - это субъект, система объект, который субъект использует для достижения цели. Цель может иметь только субъект, объект имеет назначение. Таким образом, актор - это прежде всего роль некоторой личности, имеющей цель. Другие системы или части системы действительно могут выступать в роли актора, но лишь только как проводники воли одушевленного актора. Помимо оного может еще выступать время, вернее таймер, как тригер, причина начала ВИ. Но в этом случае это делегирование полномочий целеполагающей личности-роли. Эту тонкость следует понимать. Запрос - это информация, структурированная особым образом, которую формулирует актор или система от имени актора. Ответ - есть реакция системы на внешнее воздействие - запрос, и посути является тоже информацией.
Потому совершенно не могу представить какую такую цель преследует Запрос, чтобы воспользоваться системой...
Ваше заблуждение лишний раз убеждает меня в том, что следует сначала освоить основы языка и способы его применения.

Цитировать
3. Uses - в Visio используются "до сих пор" такие обозначения
Это уже устаревшее понятие

Цитировать
4. В обще  не понял, сори
Опять же - для того, чтобы можно было с вами общаться, нужно, чтобы мы говорили на ОДНОМ языке. Этот язык в данном случае UML. Изучите его основы. Generalization или обобщение - это сплошная линия с полым треугольником на конце, которая показывает, что другой ВИ, находящийся на противоположном конце от стрелки, уточняет общий ВИ.
Помимо Generalization или обобщения, между ВИ может быть только зависимость - пунктирная линия с открытой стрелкой и имеющая стереотип расширение или включение (по-старому, использование)

Цитировать
5. Цитата :
"Актер представляет собой любую внешнюю по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определённых целей или  решения задачи. ....  Формально в контексте языка UML 2.0 каждый актер специфицирует некоторую роль, которую играет пользователь или любая другая система, взаимодействующая с субъектом". (с)
Именно. Запрос не сущность, запрос не взаимодействует, а является входным раздражителем - сигналом. Запрос формирует внешняя система - актор или другая система, которая может подавать сигналы. Ответ получает скорее всего та внешняя система или актор, кто данный запрос направил в рассматриваемую систему...

Цитировать
Так что в принципе Актер - это пользователь, но иницировать работу веб-сервера может и скрипт, который сделает соответствующий запрос, поэтому по-моему мнению, актер в этом случае "запрос"

Актер в этом случае, может быть и скрипт, который посылает запрос. Но не сам запрос. Хотя я очень сомневаюсь, что скрипт может быть актером. Скрипт скорее всего начинает формирование и передачу запроса к веб-серверу под влиянием внешнего воздействия, который инициировал реальный актер, даже если это таймер, например.

Цитировать
Резюме ))
Как раз читаю книгу "UML 2  Александра Леоненкова" и пробую делать диаграммы

Ага читайте, но если уж вы взялись за use cases почитайте Коберна, его книга у нас в файловом архиве присутствует: здесь (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=65)

Следует напомнить, что Вы просили покритиковать. Я и критикую, причем указал Вам на то, что в данном случае следует использовать диаграмму видов деятельности, так как Вы описываете лишь определенный аспект использования системы, некоторый сценарий
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: anastazya от 06 Октября 2008, 07:12:32
mifody, рекомендую ознакомится с примерами диаграмм UseCase на сайте в разделе "Примеры"+Коберн. Теория+реализация+явные ошибки, на которые указывают участники форума - хорошая платформа для изучения UML.
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: Виталий Григораш от 06 Октября 2008, 09:45:45
Так что в принципе Актер - это пользователь, но иницировать работу веб-сервера может и скрипт, который сделает соответствующий запрос, поэтому по-моему мнению, актер в этом случае "запрос"

mifody, а что вы имеете ввиду, когда говорите "запрос"?. Кто этот запрос инициирует, как он начинает работать? Если, запрос является следствием отработки скрипта, то где выполняется этот скрипт, в какой среде, кто его запускает? Хотелось бы услышать ответы на эти вопросы, может быть тогда удасться Вам помочь. То, что описано сейчас на диаграмме похоже на общий алгоритм обработки в системе любого запроса, так сказать "универсальный алгоритм".
Основная идея use case - показать как с помошью системы актор добивается своей цели в виде последовательность запросов актора и откликов (ответов) системы. В основном ВИ пишется как черный ящик, например, Актор выполняет в системе какое-то действие (white box - инициирует запрос), система в ответ на действие актора, выполняет определенные операции (white box - обработка запроса и возврат результатов)

Часто, на практике компонент системы можно представить ввиде актора, по отношению к другому компоненту.
Например, если система многоуровневая, то например уровень представления и бизнес логики можно разделить, и компонент "обработчик http запросов" на web-сервере может быть представлен как актор по отношению к компоненту, выполяющему запрос на сервере приложений, те по сути используется facade
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: mifody от 06 Октября 2008, 10:24:24
Всем спасибо
Ошибки осознал, буду читать
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: Алексей Шемис от 06 Октября 2008, 13:36:13
Можете написать конструктивную критику?
Такие технологические вещи, как "JSON", "НТМL", "XML" на диаграммах ВИ вообще не показываются. Их целесообразно отображать на диаграммах компонентов.
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: Денис Иванов от 06 Октября 2008, 16:36:46
...
Актор - это субъект, система объект, который субъект использует для достижения цели.
...
Не хочу запутывать mifody. Пишу для Эдуарда.
С точки зрения UML субъект (subject) - это система, поведение которой специфицируется вариантами использования, которые в свою очередь определяются исходя из надобностей действующих лиц.
Другими словами в UML термин subject занят и обозначает то, что я написал выше.
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: Galogen от 06 Октября 2008, 18:02:20
Пишу для Эдуарда.
С точки зрения UML субъект (subject) - это система, поведение которой специфицируется вариантами использования, которые в свою очередь определяются исходя из надобностей действующих лиц.
Другими словами в UML термин subject занят и обозначает то, что я написал выше.
Все так, Денис. Пусть в UML на английском это и так. Я же говорил не об UML прочтении термина, а то как мы понимаем это по-русски.
Тем не менее дам справку:
subject I
1.   1) предмет, тема (разговора и т. п.)
2.   предмет, дисциплина
3.   1) объект, предмет
6.   субъект, человек
8.   филос., юр.
1) субъект
conscious /thinking/ subject — мыслящий субъект
subject of international law — субъект международного права
2) субстанция, реальность

Т.е. действительно система - это subject, что переводится на русский в данном случае как объект, предмет.

Человека мы тоже можем называть и объектом и субъектом в зависимости от ситуации.
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: minona от 15 Июня 2010, 00:11:01
Леоненков ничего не даст. Читаем по ВИ в первую очередь Коберна и наш ФАК на гл. странице.
И всегда помним, что ВИ - это ЦЕЛЬ ПОЛЬЗОВАТЕЛЯ по отношению к Системе.

Хорошо - а как быть, если система планируется не как человек-система, а как человек-человек?
В ней все взаимодействия должны быть сведены к обмену данными между пользователями. Такого, в сети я не нахожу!
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: bas от 15 Июня 2010, 02:13:48
Хорошо - а как быть, если система планируется не как человек-система, а как человек-человек?
Вы сами поняли, что хотели сказать?

В ней все взаимодействия должны быть сведены к обмену данными между пользователями. Такого, в сети я не нахожу!
Если Система планируется для взаимодействия между людьми, то как раз ВИ очень тут подходит. Опять же читаем, что я рекомендовал.
Название: Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму
Отправлено: Denis Beskov от 15 Июня 2010, 02:31:44
Хорошо - а как быть, если система планируется не как человек-система, а как человек-человек?
В ней все взаимодействия должны быть сведены к обмену данными между пользователями. Такого, в сети я не нахожу!
Пример сценария взаимодействия «Человек-Человек»:
http://www.scribd.com/doc/32795371/Typical-general-short-term-task-execution-via-delegation-scenario