Впервые пишу ВИ, поэтому столкнулся с вопросом, с которым не могу справиться самостоятельно.
Система имеет в целом несколько вариантов развертывания (в т.ч. клиент-сервер). Требования к системе представляются целиком. Т.е. нет отдельного клиента, отдельного сервера и т.п. При этом сервер также является и клиентом.
Как представить в ВИ хотя бы данный вариант?
Как в виде актора будет выступать сеть? Банальное "актор: сеть, ВИ: передача данных", думаю, не самый удачный вариант.
Заранее спасибо за помощь!

Впервые пишу ВИ, поэтому столкнулся с вопросом, с которым не могу справиться самостоятельно.
Система имеет в целом несколько вариантов развертывания (в т.ч. клиент-сервер). Требования к системе представляются целиком. Т.е. нет отдельного клиента, отдельного сервера и т.п. При этом сервер также является и клиентом.
Как представить в ВИ хотя бы данный вариант?
Как в виде актора будет выступать сеть? Банальное "актор: сеть, ВИ: передача данных", думаю, не самый удачный вариант.
Заранее спасибо за помощь!

Вы с помощью ВИ сценарии взаимодействия описываете? Можете привести пару примеров?

Какая сеть? При чём здесь сеть?

Контекстную диаграмму нарисовать можете?

Обычно при развёртывании происходит взаимодействие дистрибутива с ОС.

Т.е. в качества агентов могут выступать Администратор и ОС. А в качестве проектируемой системы — дистрибутив.

Хм...
Ладно, начнем по порядку.

• Приложение проектируемой системы может делать 3 вещи
  - быть условно обработчиком данных и передавать на сервер (последнее не обязательно, если экземпляр сам является сервером)
  - быть сервером
  - быть клиентом
  Кратности не описываю, но они есть. При этом возможно любое совмещение этих функций для одного экземпляра приложений в зависимости от того, как его развернуть.
• Функциональные требования описываются в основном через варианты использования, прочие варианты описания есть, но данную задачу не решают, ибо относятся к определенным типам функциональных требований
• Сценарий является частью описания варианта использования
• Из слов начальника было сделан тонкий намек, что все это нужно как-то в требованиях однозначно отразить, и по всей видимости именно в варианте использования
• Также был дан намек, что канал передачи данных - тоже актор
• У меня есть два предположения, но дабы не смутить, сделаю текст серым  (может я херню напишу, а она на ответ повлияет). Для чтения - выделить мышью:
  1. Актор: администратор, ВИ: установка приложения, Сценарий1: ..., Сценарий2: ..., и т.п.
  2. Актор: Сеть, ВИ: передать данные, Сценарий: компонент передает данные в сеть, сеть передает данные другому компоненту (образно)
• Начальник не любит давать подсказки, отправляя со словами "ну ты же аналитик"

Действующее лицо (Aсtor) - обладает поведением (может выполнить действие с if).
(с) А. Коберн

Сеть поведением не обладает.
----------------------------------------------------
ВИ. Развертывание приложения
ОДЛ: Администратор
SuD: Установщик
[Предусловие: ... (необязательно)]
Основной сценарий:
1. ОДЛ запускает инсталлятор
2. SuD ...
...
----------------------------------------------------

PS.
1. Купите: http://www.ozon.ru/context/detail/id/8747662/

2. Очень хороший вариант пройти тренинг. http://school.system-analysis.ru/trainings/use-case-bas/ Я собираюсь переводить его в вариант онлайн. Нужны будут люди для обкатки. Могу вас взять. Для того, чтобы кардинально улучшить качество написания ВИ вам понадобится 2-4 часа (проверено многолетним, с 2005, опытом проведения). Т.е. за выходные я вас натаскаю. Ваша плата - комментарии, замечания и предложения по улучшению (при смене формата будет куча накладок).

   

• Из слов начальника было сделан тонкий намек, что все это нужно как-то в требованиях однозначно отразить, и по всей видимости именно в варианте использования
• Также был дан намек, что канал передачи данных - тоже актор

…   

• Начальник не любит давать подсказки, отправляя со словами "ну ты же аналитик"

Ну т.е. вы хотите, чтобы какие-то посторонние люди на форуме, не психотерапевты, помогли вам в ваших психологических играх с вашим начальником?

Как же я такое ненавижу. Как же люди выбирают себе дурацкую работу и потом годами мучают себя и пристают к другим людям от того, что почему-то "не могут" поговорить с заказчиком, руководителем, научным руководителем, коллегой.

То, что вы решили играть в угадайку со своим начальником — это ваше право. Но чего же вы, сука, нас в это втягиваете?

То, что вы решили играть в угадайку со своим начальником — это ваше право. Но чего же вы, сука, нас в это втягиваете?

Где вы видите угадайку? Я описал вкратце ситуацию,в  которой нахожусь, и информацию, которой владею.
Плюс вы забываете про контекст всей этой "оперы". Описывать не буду, но "играть" мне без вариантов.
У меня не было вопрос по поводу начальника и его поведения и т.п. - в мои планы обсуждение данных вопросов не входит, ибо это не вне сферы моего влияния, а нытьем страдать я не любитель. И вообще. Он начальник, его право, как говорится =)

Ситуация, в которой вы находитесь, это "пойди туда, не знаю куда, найди то, не знаю что", а потом "если мне не понравится найденное, ты и виноват".

У вашего руководителя есть какие-то ожидания относительно результата вашей работы. У него возможно даже есть понимание, как именно должен выглядеть результат.

Возможно, он просто таким образом тренирует вас, задаёт коаны, бьёт палкой и хлопает одной ладонью. Но это ваш личный путь с "учителем".

Если бы вы не цитировали начальника, я бы понимал так, что это ваша собственная задача. Из цитат видно, что вы пытаетесь выставить себя жертвой обстоятельств и просите помочь поиграть в эти обстоятельства.

Цитаты вашего начальника ничего, НИЧЕГО не добавляют к собственно задаче. Научитесь сначала брать задачу от руководителя так, чтобы были понятны критерии её приёмки, а потом уже ставьте задачи другим (разработчикам в форме требований).

По сути вопроса — вы даже ни разу не назвали сценарий, который хотите моделировать.

Действующее лицо (Aсtor) - обладает поведением (может выполнить действие с if).
(с) А. Коберн
Сеть поведением не обладает.

Ну я пока Вигерса читаю, там "Действующее лицо ~ actor — лицо, играющее конкретную роль...".
Вот собственно из этих соображений и вытекло у меня, что сеть (как совокупность сетевого окружения и внешних сетей) играет роль передачи информации...
Условно говоря у нее есть тоже алгоритмы поведения (обращение к конкретному элементу сети, например).
Тогда уточню пару моментов:
1) Для меня мегастранным (сособенно с учетом вами сказанного) кажется включение в акторы database на некоторых диаграммах. Есть ли в этом какая-нибудь логика?
2) Взять другой пример: датчик дыма (часть системы) и внешнее окружение (возможный источник дыма) - здесь также нет актора? Т.е. закуривший над датчиком человек не является актором? Ведь тут ситуация следующая: в случае пожара датчик дыма должен запустить действия в системе, должна подняться тревога, хотя пользователя / оператора / наблюдателя рядом может и не быть.
Или в таком случае лучше рассматривать датчик как актора?
3) Такс, ищу обход. Скажите, на контекстной диаграмме будут отражены и сетевое окружение (служащее для передачи данных), и окружающая среда (возможный источник пожара из второго случая)?

1. Купите: http://www.ozon.ru/context/detail/id/8747662/

Спасибо за совет! К сожалению, сейчас физически не успею захватить, но в закладки добавил, обязательно куплю/найду прочитаю.

2. Могу вас взять. Для того, чтобы кардинально улучшить качество написания ВИ вам понадобится 2-4 часа (проверено многолетним, с 2005, опытом проведения). Т.е. за выходные я вас натаскаю. Ваша плата - комментарии, замечания и предложения по улучшению (при смене формата будет куча накладок).

Спасибо! С радостью! Главное по времени совпасть =) Напишите, как можно узнать информацию подробнее (или дать вам мой номер/мейл)?

Ситуация, в которой вы находитесь...

Уважаемый Денис! Сейчас возможно что угодно в данной ситуации, ничего отрицать не буду.
Но и в обсуждение этого "болота" вступать не хочу - для обоих это излишняя трата времени, вы уж извините.
Сейчас у меня одно желание - разобраться в МЕГАкратчайшие сроки.
Требования к приемке конечно же есть - заполненный шаблон. Примеров его заполнения в полной мере, увы, нет. Как-то так.
Сценарий вам описать, к сожалению не могу. Вы уж извиняйте - комтайна, с этим у нас весьма строго. Для простоты - представьте систему пожарной безопасности, состоящей из множества датчиков, определенных узлов, терминалов наблюдения за состоянием и т.п. По логике работы система будет близка.

Ну напишите N метасценария, в которых со стороны системы будут выступать M компонентов.

Там, где 1 компонент:
1. Пользователь запрашивает выполнение операции
2. Система выполняет операцию и сообщает о её успехе пользователю

Там, где 2 компонента:
1. Пользователь запрашивает выполнение операции
2. Подсистема 1 (клиент?) убеждается в выполнение всех условий для выполнения операции
3. Подсистема 1 (клиент) вызывает подсистему 2 (сервер)
4. Подсистема 2 (сервер) выполняет операцию и возвращает результат подсистеме 1
5. Подсистема 1 (клиент) сообщает пользователю об успехе выполнения операции

Там, где 3 компонента — ну, вы поняли.

Ну напишите N метасценария, в которых со стороны системы будут выступать M компонентов.

Денис, спасибо! Идею понял. Напрямую, к сожалению, ее не получится использовать (тут что ни действие, то такая ситуация), однако N различных сценариев можно прописать при настройке подключения (после или во время установки). В целом подход понял.

Кстати, на счет пожарного датчика - все таки склоняюсь к тому, что окружающая среда в данном случае будет актором
По аналогии с обсуждаемым тут: http://www.uml2.ru/forum/index.php?topic=1082.0

Кстати, на счет пожарного датчика - все таки склоняюсь к тому, что окружающая среда в данном случае будет актором
По аналогии с обсуждаемым тут: http://www.uml2.ru/forum/index.php?topic=1082.0

Ух ты, какой некротопик. Полезно почитать свои комментарии семилетней давности. Сейчас я бы сказал так: метод вариантов использования подразумевает некоторый контекст, и если разрабатываемая система не вписывается в этот контекст, то этот метод либо не нужно применять, либо надо называть как-то по-другому. Чтобы люди, тоже знакомые с этим контекстом, не использовали его неправильно.

С учётом всего написанного в дополнение.

ВИ как метод выявления и описания требований были созданы, в первую очередь, для описания взаимодействия пользователей (людей) с системой. Тут важны два положения:
а) У людей, использующих систему, всегда есть цели, для достижения которых система создаётся. ВИ описывает сценарий достижения этой цели.
б) Люди находятся за пределами системы. Поэтому граница системы - важный элемент диаграммы ВИ.

Но быстро выяснилось, что на место людей можно поставить и другие системы, отчего стройная концепция модели ВИ начала немного размываться.

Пока мы рассматриваем взаимодействие типа "клиент-сервер", всё более-менее нормально. У клиентов можно выделить цели, клиенты однозначно находятся за пределами систем-серверов, а их взаимодействие с серверами хорошо описывается сценариями.
Но раз уж мы поставили на место актора не человека, а клиента-железяку, то возникает соблазн любую железяку использовать в качестве актора. Но если при этом нарушаются обозначенные выше положения, то вместо вариантов использования получается невнятная каша.

У датчика дыма нет цели, он свой сигнал выдал - а там хоть трава не расти. Поэтому датчик дыма не стоит рассматривать в качестве актора.
Кроме того, датчик дыма обычно является частью системы.
Поэтому я бы тут метод ВИ вообще не применял, а описывал бы требования другими методами.

У базы данных теоретически может быть цель, если она рассматривается в роли клиента. Но в большинстве случаев ВИ, в которых БД назначена актором, просто неграмотно разработаны.
Я видел ВИ, в которых актором выступала банковская карта. Отвратительные ВИ, надо сказать - они ничего не добавляли к пониманию системы, а только всё запутывали.

Мне трудно представить себе "сеть" в роли актора. Возможно, вы вкладываете в это слово какой-то другой смысл. Какую цель может преследовать сеть по отношению к системе?
Нет цели - нет ВИ.
Есть цель - ищите того, кто её преследует.