1. согласен что с русским у меня хромает )
К сожалению не у Вас одного. Причина - мало читаем и сильно надеемся на проверку орфографии...
2. попытка сделать UseCase диаграмму
с точки зрения что актер - пользователь, то да, диаграмма похожа на алгоритм, но если посмотреть на диаграмму со стороны "ЗАПРОСА", то я думаю что она не раскрывает внутреннего содержания системы (некоторого участка системы), а показывает варианты использования
Актор - это субъект, система объект, который субъект использует для достижения цели. Цель может иметь только субъект, объект имеет назначение. Таким образом, актор - это прежде всего роль некоторой личности, имеющей цель. Другие системы или части системы действительно могут выступать в роли актора, но лишь только как проводники воли одушевленного актора. Помимо оного может еще выступать время, вернее таймер, как тригер, причина начала ВИ. Но в этом случае это делегирование полномочий целеполагающей личности-роли. Эту тонкость следует понимать. Запрос - это информация, структурированная особым образом, которую формулирует актор или система от имени актора. Ответ - есть реакция системы на внешнее воздействие - запрос, и посути является тоже информацией.
Потому совершенно не могу представить какую такую цель преследует Запрос, чтобы воспользоваться системой...
Ваше заблуждение лишний раз убеждает меня в том, что следует сначала освоить основы языка и способы его применения.
3. Uses - в Visio используются "до сих пор" такие обозначения
Это уже устаревшее понятие
4. В обще не понял, сори
Опять же - для того, чтобы можно было с вами общаться, нужно, чтобы мы говорили на ОДНОМ языке. Этот язык в данном случае UML. Изучите его основы. Generalization или обобщение - это сплошная линия с полым треугольником на конце, которая показывает, что другой ВИ, находящийся на противоположном конце от стрелки, уточняет общий ВИ.
Помимо Generalization или обобщения, между ВИ может быть только зависимость - пунктирная линия с открытой стрелкой и имеющая стереотип расширение или включение (по-старому, использование)
5. Цитата :
"Актер представляет собой любую внешнюю по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определённых целей или решения задачи. .... Формально в контексте языка UML 2.0 каждый актер специфицирует некоторую роль, которую играет пользователь или любая другая система, взаимодействующая с субъектом". (с)
Именно. Запрос не сущность, запрос не взаимодействует, а является входным раздражителем - сигналом. Запрос формирует внешняя система - актор или другая система, которая может подавать сигналы. Ответ получает скорее всего та внешняя система или актор, кто данный запрос направил в рассматриваемую систему...
Так что в принципе Актер - это пользователь, но иницировать работу веб-сервера может и скрипт, который сделает соответствующий запрос, поэтому по-моему мнению, актер в этом случае "запрос"
Актер в этом случае, может быть и скрипт, который посылает запрос. Но не сам запрос. Хотя я очень сомневаюсь, что скрипт может быть актером. Скрипт скорее всего начинает формирование и передачу запроса к веб-серверу под влиянием внешнего воздействия, который инициировал реальный актер, даже если это таймер, например.
Резюме ))
Как раз читаю книгу "UML 2 Александра Леоненкова" и пробую делать диаграммы
Ага читайте, но если уж вы взялись за use cases почитайте Коберна, его книга у нас в файловом архиве присутствует:
здесьСледует напомнить, что Вы просили покритиковать. Я и критикую, причем указал Вам на то, что в данном случае следует использовать диаграмму видов деятельности, так как Вы описываете лишь определенный аспект использования системы, некоторый сценарий
Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму