Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - cr2sh

Страницы: 1
1
То, что вы решили играть в угадайку со своим начальником — это ваше право. Но чего же вы, сука, нас в это втягиваете?
Самое смешное, что я только сегодня понял, что мой нач (видимо подсознательно) действительно любит угадайку =) (где тут смайлик "смех сквозь слезы"?)

2

Насколько я помню ВИ, не может быть никакого "потока данных" от актора к ВИ и обратно. ВИ это цель Актора относительно системы. Не может быть потока данных от Актора к Цели. Цель у Актора либо есть либо нет.
Спасибо за дополнение! Сергей (SАLar) в устной беседе мне это пояснил.
С моей точки зрения, вопрос так как его ставит автор топика  скорее всего не имеет решения.
На самом деле вопрос уже нашел решение =) Главное - нужно было понять, как правильно =)

3
Сразу спасибо за то, что присоединились к обсуждению =)
Поэтому я бы тут метод ВИ вообще не применял, а описывал бы требования другими методами.
Увы, как я уже ранее говорил, здесь я ограничен шаблоном. Конечно, там еще есть диаграмма контекста, но я таки до конца и не понял, могут ли там отображаться элементы окружения, не являющиеся акторами?

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

Последний пункт (сначала показалось что) на мой взгляд не является признаком актора, ибо возможен вариант: Актор: рабочий, цель: выполнить инструкцию, сценарий: нажать на кнопку (и ... все! сообщение "нажми на кнопку" может приходить из другой системы, а она вне контекста)
Однако проблемы начинаются таки когда мы начинаем говорить о сети как сетевом окружении, включающем в себя в т.ч. и активное сетевое оборудование и т.п. - задача - получить пакет, смаршрутизировать, передать. Цели вроде как есть (обеспечение работоспособности системы). и потоки данных есть, и поведение - "этот пакет направо, а этот -налево". Но где грань, отличающая активку от 1 единственной витой?... =(
Вот тут пришла идея переформулировать признак 1: наличие определенных целей по отношению к системе, достигаемых с помощью системы
В то же время, если добавить этот признак, то в некоторой мере становится лишним и признак 4, и становится сложно объяснить каких целей с помощью системы достигают какие-нибудь интерфейсы...
Ну эт мои дебри мысли, а я с ВИ столкнулся впервые, поэтому критика приветствуется. Я еще подумаю, над дебильными примерами =)

P.S.: про сеть и др. частные случаи мне тут пояснили уже, согласен =)

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

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

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

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

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


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

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

Страницы: 1