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

×


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

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


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »
901
Артем, почитайте UML2 Superstructure Specification


Вот это настоящий RTFM! :)

Цитировать
Interaction Overview Diagrams define Interactions through a variant of Activity Diagrams (described in Clause 12, “Activities”) in a way that promotes overview of the control flow.
Interaction Overview Diagrams focus on the overview of the flow of control where the nodes are Interactions or InteractionUses. The Lifelines and the Messages do not appear at this overview level.

Interaction Overview Diagrams use Activity diagram notation where the nodes are either Interactions or InteractionUses. Interaction Overview Diagrams are a way to describe Interactions where Messages and Lifelines are abstracted away. In the purest form all Activities are InteractionUses and then there are no Messages or Lifelines shown in the diagram at all.

UML - это всё ещё средство улучшения взаимопонимания? ;)

902
Сценарии, назовите ЭТО сценариями и делайте ВСЕ ЧТО ХОТИТЕ!
Рисуйте себе статику и динамику КАК УГОДНО -- дерево функций в виде иерархической диаграммы, Взаимодействие, activity ... богатейший арсенал в распоряжении. Зачем рисовать диаграмму ВИ обязательно???? Просто чтобы buzzword использовать?
 

Я скажу по секрету: диаграммы ВИ я вообще не рисовал. До сих пор такой необходимости не возникало.

А вот сами... хм... сценарии мы более-менее освоили.

903
З.Ы. Гриша, показательно, что у тя нет ни одной цитаты от Коберна :)

Мы говорим "usecase", подразумеваем Коберна, мы говорим "Коберн", подразумеваем usecase. ;)

904
Ну что еще можно сказать :)

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

ИМХО у нас получилась путаница, Вы говорите, что Тр. хорошо описывать в виде сценария, я с этим не спорю и даже поддерживаю, но только поэтому Вы назваете эти сценария ВИ, с чем я не согласен.

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

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

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

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

905
Интересно посмотреть на определения Use Case в интернет.

Первое определение - из Википедии. Именно такой трактовки, насколько я понимаю, придерживается BAS:

Цитировать
A use case is a description of a system’s behaviour as it responds to a request that originates from outside of that system.

Остальные определения, насколько я понял, содержатся в глоссариях различных проектов. Здесь трактовки более широкие, не настолько однозначные. Но интересны тем, что взяты из не учебников, а из реальной практики.

Цитировать
Use case is a sequence of actions that an actor (a person, external entity or another system) performs within a system to achieve a particular goal. Or from inside out, a use case is a sequence of actions a system executes that yield observable results of value to a particular actor.
http://costg9.plan.aau.dk/Bremen2001/Rados/RadosGlossary.htm

Цитировать
Use case describes, from a user’s perspective, a behaviourally related set of transactions that are normally performed together to produce some value for the user. Use cases may be modelled at varying degrees of abstraction, essential use cases, the most abstract, are technologically and implementation independent whereas real use cases describe how the use case actually operates in a particular environment.
http://highered.mcgraw-hill.com/sites/0077110005/student_view0/glossary.html

Цитировать
A use case is a description of how end-users will use a software code. It describes a task or a series of tasks that users will accomplish using the software, and includes the responses of the software to user actions. Use cases may be included in the Software Requirements Document (SRD) as a way of specifying the end-users' expected use of the software.
http://mydocs.epri.com/docs/SDRWeb/processguide/glossary.html

Цитировать
A specific way of using the system by performing some part of the functionality. Each use case constitutes a complete course of action initiated by an actor, and it specifies the interaction that takes place between an actor and the system. The collected use cases specify all the existing ways of using the system.
http://www.iram.fr/~lucas/almassr/SSR-UC-Glossary.html

Цитировать
A Use Case is a series of steps an actor performs on a system to achieve a goal. Actors are "objects" of any type, such as people, parts or other systems.

Следующее определение интересно тем, что помещено почему-то в описание типов данных. Оно самое короткое, но вполне выражает суть.

Цитировать
use case — type of interaction between a system and its environment.

Ну и у тестировщиков, как всегда, свой взгляд на вещи. :)

Цитировать
Use Case
The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.
http://mavericsys.blogspot.com/2007/11/software-testing-dictionary.html

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

Вариант использования описывает последовательность взаимодействия. Это очень мощный инструмент для анализа требований, их описания и последующего тестирования (а также, как показывает опыт, для разработки пользовательской документации). Почему его нельзя использовать там, где есть взаимодействие?

В нашей практике ВИ идеально подходят, например, для описания взаимодействия приложения терминала ("наша система") с банковским хостом ("внешняя система").
Есть основной сценарий, есть альтернативы, есть начальные условия, есть целевые и минимальные гарантии. Одинаково понятно и разработчику, и заказчику, и тестировщику. То есть выглядит как ВИ и используется как ВИ.

А если что-то выглядит как утка, крякает как утка, плавает как утка и летает как утка, но не укладывается в концепцию "диаграммы уток" - то как его следует называть?

Я допускаю, конечно, что я просто чего-то не знаю. Так дай ссылочку - попробую разобраться, в чём я не прав.

907
Ну почему на сайтах, считающих себя серьёзными, используются рекламные технологии, которым только на порносайтах и место?

Начинаю читать статью, вникать в текст, и вдруг его закрывает внезапно выскочивший рекламный баннер. Руки за такое отрывать "веб-мастерам" надо.

(Вообще-то я добрый, но только что обнаружил, что уборщица опять выбросила табак и уголь для кальяна, посчитав их ненужным мусором.)

908
То есть на ДВИ это, конечно, изобразить трудно. Но разве ДВИ это панацея? ИМХО, всего лишь один из методов кластеризации пользовательских требований.

Получается, вопрос такой: если ВИ нельзя разместить на ДВИ, то он не имеет права на существование? Или это просто терминологическая проблема, и его всего лишь не нужно называть вариантом использования (хотя бы вслух ;))?

909
П.ч. наша ИС не может быть изображена на ДВИ как актер. Т.е. в лучшем случае получим одного Актера (внешняя ИС) и куча ВИ, кот. не будут являться ВИ по сути, и такая Д не даст никакой ценности.

Да почему наша ИС не может быть актором? Где это написано и какой в этом смысл?

910
Я предлагаю копнуть глубже. Давайте сначала определимся с семантическим полем понятий "иерархия", "субъект" и "объект". :)

О чём вообще речь идёт? В каком контексте нужно определять понятия? И что такое "процесся", кстати? Деепричастие? ;)

911
Да, насчёт сетчатки это я, конечно, загнул.
Наверное, всё-таки по радужной оболочке. :)

912
Т.е. два человеа подходят к двери и одновременно пытаются зайти в эту дверь?

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

Это я фантазирую, конечно.


По-моему, если вариант использования позволяет компактно описать требуемое поведение системы так, чтобы оно было однозначно (в смысле, одинаково) воспринято закзачиком, разработчиком и тестировщиком, то это хороший ВИ.

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

Если представить себе реализацию, то система должна ждать любого их двух событий - запрос с ридера 1 или запрос с ридера 2. После обработки обоих запросов она снова должна ждать двух событий в любом порядке. Если ещё остался соблазн использовать ветвления "для красоты", то можно добавить ещё парочку событий - экспоненциальный рост количества комбинаций в конце концов убедит кого угодно. :)


Я что хочу сказать. Я не вижу необходимости в каких-либо жёстких ограничениях по числу действующих лиц (хотя признаю разумные ограничения по заранее достигнутому соглашению). Тот же Коберн даёт только рекомендации (и сам, кстати, постоянно это подчёркивает). Очень хорошие рекомендации, и их можно считать "классикой", но не догмы. И выражения "нельзя использовать" или "ни в коем случае" применительно к описаниям требований считаю, как минимум, спорными, пока не будут представлены исчерпывающие доказательства и объяснения, почему именно нельзя.

913
Как один ВИ с простым ветвлением
или как один ВИ с альтернативой
Или как два ВИ причем один из ВИ есть расширение первого
Один ВИ открыть дверь, другой аутифицироваться

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

т.е. после размышления имеем три варианта использования системы:
Войти в здание
Выйти из здания
Аутентификация как отдельный под ВИ, который может иметь и самостоятельно значение

А зачем мне все эти сложности - два ВИ вместо одного или один ВИ с ветвлением, если в процедуре изначально участвуют два человека, и система должна взаимодействовать с обоими? Кому это облегчит жизнь?

914
Странно, публиковал ответ, а его не вижу. Я удивляюсь не незнанию человека, а нашему образованию. Это же классика!

А чему удивляться? Для меня, например, что DFD, что ДНД - всё едино.

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

Вот я уже раз двадцать заглядывал в словарь, чтобы вспомнить, что такое BPMS. И опять забыл.
А такие сокращения как IDEF0, IDEF1 и т. д. вообще придумали злобные извращенцы. ;)

915
Картинка с хабра. Понимаете ли вы блок-схемы?

http://img224.imageshack.us/img224/5206/flowchartszh0.png

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »