Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: cr2sh от 11 Января 2016, 17:40:12
-
Впервые пишу ВИ, поэтому столкнулся с вопросом, с которым не могу справиться самостоятельно.
Система имеет в целом несколько вариантов развертывания (в т.ч. клиент-сервер). Требования к системе представляются целиком. Т.е. нет отдельного клиента, отдельного сервера и т.п. При этом сервер также является и клиентом.
Как представить в ВИ хотя бы данный вариант?
Как в виде актора будет выступать сеть? Банальное "актор: сеть, ВИ: передача данных", думаю, не самый удачный вариант.
Заранее спасибо за помощь!
-
Впервые пишу ВИ, поэтому столкнулся с вопросом, с которым не могу справиться самостоятельно.
Система имеет в целом несколько вариантов развертывания (в т.ч. клиент-сервер). Требования к системе представляются целиком. Т.е. нет отдельного клиента, отдельного сервера и т.п. При этом сервер также является и клиентом.
Как представить в ВИ хотя бы данный вариант?
Как в виде актора будет выступать сеть? Банальное "актор: сеть, ВИ: передача данных", думаю, не самый удачный вариант.
Заранее спасибо за помощь!
Вы с помощью ВИ сценарии взаимодействия описываете? Можете привести пару примеров?
-
Какая сеть? При чём здесь сеть?
Контекстную диаграмму нарисовать можете?
Обычно при развёртывании происходит взаимодействие дистрибутива с ОС.
Т.е. в качества агентов могут выступать Администратор и ОС. А в качестве проектируемой системы — дистрибутив.
-
Хм...
Ладно, начнем по порядку.
- Приложение проектируемой системы может делать 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)
-
Кстати, на счет пожарного датчика - все таки склоняюсь к тому, что окружающая среда в данном случае будет актором
По аналогии с обсуждаемым тут: http://www.uml2.ru/forum/index.php?topic=1082.0 (http://www.uml2.ru/forum/index.php?topic=1082.0)
Ух ты, какой некротопик. Полезно почитать свои комментарии семилетней давности. :) Сейчас я бы сказал так: метод вариантов использования подразумевает некоторый контекст, и если разрабатываемая система не вписывается в этот контекст, то этот метод либо не нужно применять, либо надо называть как-то по-другому. Чтобы люди, тоже знакомые с этим контекстом, не использовали его неправильно.
С учётом всего написанного в дополнение.
ВИ как метод выявления и описания требований были созданы, в первую очередь, для описания взаимодействия пользователей (людей) с системой. Тут важны два положения:
а) У людей, использующих систему, всегда есть цели, для достижения которых система создаётся. ВИ описывает сценарий достижения этой цели.
б) Люди находятся за пределами системы. Поэтому граница системы - важный элемент диаграммы ВИ.
Но быстро выяснилось, что на место людей можно поставить и другие системы, отчего стройная концепция модели ВИ начала немного размываться.
Пока мы рассматриваем взаимодействие типа "клиент-сервер", всё более-менее нормально. У клиентов можно выделить цели, клиенты однозначно находятся за пределами систем-серверов, а их взаимодействие с серверами хорошо описывается сценариями.
Но раз уж мы поставили на место актора не человека, а клиента-железяку, то возникает соблазн любую железяку использовать в качестве актора. Но если при этом нарушаются обозначенные выше положения, то вместо вариантов использования получается невнятная каша.
У датчика дыма нет цели, он свой сигнал выдал - а там хоть трава не расти. Поэтому датчик дыма не стоит рассматривать в качестве актора.
Кроме того, датчик дыма обычно является частью системы.
Поэтому я бы тут метод ВИ вообще не применял, а описывал бы требования другими методами.
У базы данных теоретически может быть цель, если она рассматривается в роли клиента. Но в большинстве случаев ВИ, в которых БД назначена актором, просто неграмотно разработаны.
Я видел ВИ, в которых актором выступала банковская карта. Отвратительные ВИ, надо сказать - они ничего не добавляли к пониманию системы, а только всё запутывали.
Мне трудно представить себе "сеть" в роли актора. Возможно, вы вкладываете в это слово какой-то другой смысл. Какую цель может преследовать сеть по отношению к системе?
Нет цели - нет ВИ.
Есть цель - ищите того, кто её преследует.
-
Сразу спасибо за то, что присоединились к обсуждению =)
Поэтому я бы тут метод ВИ вообще не применял, а описывал бы требования другими методами.
Увы, как я уже ранее говорил, здесь я ограничен шаблоном. Конечно, там еще есть диаграмма контекста, но я таки до конца и не понял, могут ли там отображаться элементы окружения, не являющиеся акторами?
У датчика дыма нет цели, он свой сигнал выдал - а там хоть трава не расти. Поэтому датчик дыма не стоит рассматривать в качестве актора.
Кроме того, датчик дыма обычно является частью системы.
Да, но
1) В данном случае я рассматриваю как актора внешнюю среду, которая определенным образом информирует датчик
2) Поток данных направлен от среды к кейсу, а от кейса - пользователю, который в этот момент совершает действия вроде "слушаю" или "смотрю", т.е. пользователь в данном случае использования системы не инициирует действие, НО преследует цель - получить уведомление /наблюдать за обстановкой. Поскольку от него не исходит инициация или действие, то я логически пришел к выводу, что инициатором как раз у нас является внешняяя среда. И в целом пофиг - человек там или среда. Мы же можем взять подобный пример - прослушка человека, скажем. Один человек говорит, система передает, а второй слушает. Так ли важно, приследует ли цель "говорить" первый человек? Может цель он и не приследует, но действие инициации по отношению к системе совершает.
С другой стороны... Все это можно представить как транслятор потока информации, принимаегого системой. При этом поведение транслятора (а следовательно, и сам поток) существуют самостоятельно и к системе отношения не имеют с точки зрения термина "использовать" - цель использования отсутствует.
В итоге моя логика пришла к поиску одного единственного ответа на вопрос - выявить признаки, идентифицирующие актора
- наличие определенных целей по отношению к системе (вот как раз этот пункт определяет, является ли внешняя среда актором)
- существование потока данных хотя бы в одну сторону
- всегда вне системы (если не идет речь о подсистемах)
- "обладает поведением" (как писал ранее SOLar)
Последний пункт (сначала показалось что) на мой взгляд не является признаком актора, ибо возможен вариант: Актор: рабочий, цель: выполнить инструкцию, сценарий: нажать на кнопку (и ... все! сообщение "нажми на кнопку" может приходить из другой системы, а она вне контекста)
Однако проблемы начинаются таки когда мы начинаем говорить о сети как сетевом окружении, включающем в себя в т.ч. и активное сетевое оборудование и т.п. - задача - получить пакет, смаршрутизировать, передать. Цели вроде как есть (обеспечение работоспособности системы). и потоки данных есть, и поведение - "этот пакет направо, а этот -налево". Но где грань, отличающая активку от 1 единственной витой?... =(
Вот тут пришла идея переформулировать признак 1: наличие определенных целей по отношению к системе, достигаемых с помощью системы
В то же время, если добавить этот признак, то в некоторой мере становится лишним и признак 4, и становится сложно объяснить каких целей с помощью системы достигают какие-нибудь интерфейсы...
Ну эт мои дебри мысли, а я с ВИ столкнулся впервые, поэтому критика приветствуется. Я еще подумаю, над дебильными примерами =)
P.S.: про сеть и др. частные случаи мне тут пояснили уже, согласен =)
-
Поток данных направлен от среды к кейсу, а от кейса - пользователю, который в этот момент совершает действия вроде "слушаю" или "смотрю
Насколько я помню ВИ, не может быть никакого "потока данных" от актора к ВИ и обратно. ВИ это цель Актора относительно системы. Не может быть потока данных от Актора к Цели. Цель у Актора либо есть либо нет.
С моей точки зрения, вопрос так как его ставит автор топика скорее всего не имеет решения. Нельзя при помощи ВИ разрисовать структуру и поведение системы (я понял вопрос автора именно так). Нужно использовать другие типы диаграмм: контекстную, data-flow diagram, robustness diagram, component diagram, deployment diagram, возможно другие.
-
Насколько я помню ВИ, не может быть никакого "потока данных" от актора к ВИ и обратно. ВИ это цель Актора относительно системы. Не может быть потока данных от Актора к Цели. Цель у Актора либо есть либо нет.
Спасибо за дополнение! Сергей (SАLar) в устной беседе мне это пояснил.
С моей точки зрения, вопрос так как его ставит автор топика скорее всего не имеет решения.
На самом деле вопрос уже нашел решение =) Главное - нужно было понять, как правильно =)
-
Смешались в кучи кони, люди...
-
То, что вы решили играть в угадайку со своим начальником — это ваше право. Но чего же вы, сука, нас в это втягиваете?
Самое смешное, что я только сегодня понял, что мой нач (видимо подсознательно) действительно любит угадайку =) (где тут смайлик "смех сквозь слезы"?)