Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму(Прочитано 27658 раз)
народ! Начинаю изучать UML
нарисовал UseCase диаграмму
насколько верно ее нарисовал  - не знаю

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

(без критики нормально проектировать не научишься)



Здравствуйте.

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

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

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

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

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

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



1. согласен что с русским у меня хромает )

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

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

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

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

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


Резюме ))
Как раз читаю книгу "UML 2  Александра Леоненкова" и пробую делать диаграммы
« Последнее редактирование: 05 Октября 2008, 03:48:47 от mifody »



Леоненков ничего не даст. Читаем по ВИ в первую очередь Коберна и наш ФАК на гл. странице.
И всегда помним, что ВИ - это ЦЕЛЬ ПОЛЬЗОВАТЕЛЯ по отношению к Системе.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



1. согласен что с русским у меня хромает )
К сожалению не у Вас одного. Причина - мало читаем и сильно надеемся на проверку орфографии...

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

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

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

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

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

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

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

Ага читайте, но если уж вы взялись за use cases почитайте Коберна, его книга у нас в файловом архиве присутствует: здесь

Следует напомнить, что Вы просили покритиковать. Я и критикую, причем указал Вам на то, что в данном случае следует использовать диаграмму видов деятельности, так как Вы описываете лишь определенный аспект использования системы, некоторый сценарий
« Последнее редактирование: 05 Октября 2008, 21:50:21 от Galogen »



mifody, рекомендую ознакомится с примерами диаграмм UseCase на сайте в разделе "Примеры"+Коберн. Теория+реализация+явные ошибки, на которые указывают участники форума - хорошая платформа для изучения UML.



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

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

Часто, на практике компонент системы можно представить ввиде актора, по отношению к другому компоненту.
Например, если система многоуровневая, то например уровень представления и бизнес логики можно разделить, и компонент "обработчик http запросов" на web-сервере может быть представлен как актор по отношению к компоненту, выполяющему запрос на сервере приложений, те по сути используется facade
« Последнее редактирование: 06 Октября 2008, 09:50:53 от Виталий Григораш »
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Всем спасибо
Ошибки осознал, буду читать



Можете написать конструктивную критику?
Такие технологические вещи, как "JSON", "НТМL", "XML" на диаграммах ВИ вообще не показываются. Их целесообразно отображать на диаграммах компонентов.
Суха мой друг теория везде, а древо жизни пышно зеленеет [Гёте]



...
Актор - это субъект, система объект, который субъект использует для достижения цели.
...
Не хочу запутывать mifody. Пишу для Эдуарда.
С точки зрения UML субъект (subject) - это система, поведение которой специфицируется вариантами использования, которые в свою очередь определяются исходя из надобностей действующих лиц.
Другими словами в UML термин subject занят и обозначает то, что я написал выше.



Пишу для Эдуарда.
С точки зрения 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, что переводится на русский в данном случае как объект, предмет.

Человека мы тоже можем называть и объектом и субъектом в зависимости от ситуации.



Леоненков ничего не даст. Читаем по ВИ в первую очередь Коберна и наш ФАК на гл. странице.
И всегда помним, что ВИ - это ЦЕЛЬ ПОЛЬЗОВАТЕЛЯ по отношению к Системе.

Хорошо - а как быть, если система планируется не как человек-система, а как человек-человек?
В ней все взаимодействия должны быть сведены к обмену данными между пользователями. Такого, в сети я не нахожу!



Хорошо - а как быть, если система планируется не как человек-система, а как человек-человек?
Вы сами поняли, что хотели сказать?

В ней все взаимодействия должны быть сведены к обмену данными между пользователями. Такого, в сети я не нахожу!
Если Система планируется для взаимодействия между людьми, то как раз ВИ очень тут подходит. Опять же читаем, что я рекомендовал.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Хорошо - а как быть, если система планируется не как человек-система, а как человек-человек?
В ней все взаимодействия должны быть сведены к обмену данными между пользователями. Такого, в сети я не нахожу!
Пример сценария взаимодействия «Человек-Человек»:
http://www.scribd.com/doc/32795371/Typical-general-short-term-task-execution-via-delegation-scenario




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19