Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: mifody от 04 Октября 2008, 18:35:34
-
народ! Начинаю изучать 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 Александра Леоненкова" и пробую делать диаграммы
-
Леоненков ничего не даст. Читаем по ВИ в первую очередь Коберна и наш ФАК на гл. странице.
И всегда помним, что ВИ - это ЦЕЛЬ ПОЛЬЗОВАТЕЛЯ по отношению к Системе.
-
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)
Следует напомнить, что Вы просили покритиковать. Я и критикую, причем указал Вам на то, что в данном случае следует использовать диаграмму видов деятельности, так как Вы описываете лишь определенный аспект использования системы, некоторый сценарий
-
mifody, рекомендую ознакомится с примерами диаграмм UseCase на сайте в разделе "Примеры"+Коберн. Теория+реализация+явные ошибки, на которые указывают участники форума - хорошая платформа для изучения UML.
-
Так что в принципе Актер - это пользователь, но иницировать работу веб-сервера может и скрипт, который сделает соответствующий запрос, поэтому по-моему мнению, актер в этом случае "запрос"
mifody, а что вы имеете ввиду, когда говорите "запрос"?. Кто этот запрос инициирует, как он начинает работать? Если, запрос является следствием отработки скрипта, то где выполняется этот скрипт, в какой среде, кто его запускает? Хотелось бы услышать ответы на эти вопросы, может быть тогда удасться Вам помочь. То, что описано сейчас на диаграмме похоже на общий алгоритм обработки в системе любого запроса, так сказать "универсальный алгоритм".
Основная идея use case - показать как с помошью системы актор добивается своей цели в виде последовательность запросов актора и откликов (ответов) системы. В основном ВИ пишется как черный ящик, например, Актор выполняет в системе какое-то действие (white box - инициирует запрос), система в ответ на действие актора, выполняет определенные операции (white box - обработка запроса и возврат результатов)
Часто, на практике компонент системы можно представить ввиде актора, по отношению к другому компоненту.
Например, если система многоуровневая, то например уровень представления и бизнес логики можно разделить, и компонент "обработчик http запросов" на web-сервере может быть представлен как актор по отношению к компоненту, выполяющему запрос на сервере приложений, те по сути используется facade
-
Всем спасибо
Ошибки осознал, буду читать
-
Можете написать конструктивную критику?
Такие технологические вещи, как "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