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



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

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



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

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

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

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



Хм...
Ладно, начнем по порядку.
  • Приложение проектируемой системы может делать 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, опытом проведения). Т.е. за выходные я вас натаскаю. Ваша плата - комментарии, замечания и предложения по улучшению (при смене формата будет куча накладок).
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



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

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

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



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



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




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

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

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

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

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

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



    Действующее лицо (Aсtor) - обладает поведением (может выполнить действие с if).
    (с) А. Коберн
    Сеть поведением не обладает.
    Ну я пока Вигерса читаю, там "Действующее лицо ~ actor — лицо, играющее конкретную роль...".
    Вот собственно из этих соображений и вытекло у меня, что сеть (как совокупность сетевого окружения и внешних сетей) играет роль передачи информации...
    Условно говоря у нее есть тоже алгоритмы поведения (обращение к конкретному элементу сети, например).
    Тогда уточню пару моментов:
    1) Для меня мегастранным (сособенно с учетом вами сказанного) кажется включение в акторы database на некоторых диаграммах. Есть ли в этом какая-нибудь логика?
    2) Взять другой пример: датчик дыма (часть системы) и внешнее окружение (возможный источник дыма) - здесь также нет актора? Т.е. закуривший над датчиком человек не является актором? Ведь тут ситуация следующая: в случае пожара датчик дыма должен запустить действия в системе, должна подняться тревога, хотя пользователя / оператора / наблюдателя рядом может и не быть.
    Или в таком случае лучше рассматривать датчик как актора?
    3) Такс, ищу обход. Скажите, на контекстной диаграмме будут отражены и сетевое окружение (служащее для передачи данных), и окружающая среда (возможный источник пожара из второго случая)?
    1. Купите: http://www.ozon.ru/context/detail/id/8747662/
    Спасибо за совет! К сожалению, сейчас физически не успею захватить, но в закладки добавил, обязательно куплю/найду прочитаю.
    2. Могу вас взять. Для того, чтобы кардинально улучшить качество написания ВИ вам понадобится 2-4 часа (проверено многолетним, с 2005, опытом проведения). Т.е. за выходные я вас натаскаю. Ваша плата - комментарии, замечания и предложения по улучшению (при смене формата будет куча накладок).
    Спасибо! С радостью! Главное по времени совпасть =) Напишите, как можно узнать информацию подробнее (или дать вам мой номер/мейл)?
    « Последнее редактирование: 12 Января 2016, 14:31:36 от cr2sh »



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



    Ну напишите 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

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

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

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

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

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

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

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

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

    Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)




     

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