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

Простите, но Actor взаимодействует с системой через UC.

Да, но юзкейс, как мы знаем - это последовательность действий типа Пользователь <сделал что-то> ... Система сделала <что-то>. Скорее к функциям системы (или если угодно, к подфункциям, но это тоже функции ...) можно отнести то, что описывается в сценарии как "Система сделала <что-то>", а не действия пользователя ...

Или ты что-то иное имеешь ввиду, когда требуешь рисовать UC на четырехугольнике системы и рисуешь ассоциацию между Actor (вне системы) и UC (внутри системы).

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

И почему это, если пользователь взаимодействует с системой через интерфейс, он окажется внутри системы? Где тебя сейчас искать? В зазеркалье?

Вы неверно интерпретируете сказанное мной. Утверждение, что UC это интерфейс СИСТЕМЫ - это ваше утверждение, а не мое. У меня простой вопрос - шаги юзкейса, которые делает Эктор (например, принимает решение дать кредит или нет) - это функция системы или нет?

Загибаешь!

Отнюдь!

Цитата: lnew от 18 Апреля 2011, 16:42:19

UC не содержит действия пользователя, а описывает взаимодействия пользователя с системой.
А вот система полностью реализует UC (UC Realization), предоставляя пользователю интерфейс, соответствующий описанию UC.
Т.о., UC - это свойство только системы! Значит, это функция? Правда?
А какой пример функции, который не является реализацией UC?

Не согласен, что юзкейс не содержит действий пользователя ... совершенно. Еще как содержит!

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

125

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 15:13:54 »

Ты победил!
Мне добавить нечего.

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

126

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 15:03:17 »

Цитата: Galogen от 18 Апреля 2011, 16:48:38

Word, это многофункциональный инструмент, который наверное невозможно описать в категориях UCs.

Можно ясно определить некий набор UCs по некоторому контектсу задач, в которых Word будет использоваться как инструмент, но какое отношение это имеет к обсуждаемому вопросу??? Мы то говорим о специфицировании заданий на разработку, а не о способе передачи информации для программно-насыщенных систем в целом.

Аналогично и пример с принятием решения, опять выпадает из канвы рассуждения., потому как назначении системы не принять решение, а помочь его принять и скорее будет выливаться: в Оценить действие такого-то фактора на коньюктуру этого, т.е. цель моего использования инструмента в принятии решении, но цель моего конкретного использования инструмента Оценка влияния фактора. Что в данном случае будет функциональным требованием?

Система должна помочь пользователю принять решение? И как это измерить?
Или
Система должна помочь оценить влияние фактора методом стохастически сходящихся детерменистки-расходящикся векторносвернутых скаляров?

Эд, твоя цель как пользователя - принять решение о кредите и внести свое решение в систему ... система тебе для принятия решения дает данные ... Какой будет твоя цель как пользователя?

127

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 16:34:35 »

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

128

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 17 Апреля 2011, 22:58:13 »

Цитата: lnew от 17 Апреля 2011, 20:47:38

Юра!
Ты "замыливаешь" ответы на вполне однозначные вопросы.

Ты же аналитик, а не дипломат.

Объясни, пожалуйста, как с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.

Потом, если хочешь, продолжим дискуссию.

Спасибо.

Мне показалось, что я достаточно ясно сформулировал ... попробую еще раз, с конкретными примерами... итак почему UC не самый удачный вариант описания ВСЕХ интерфейсов системы.
1. Юзкейсы - контекстно зависимая вещь. Я приводил пример текстового редактора Word. Функций у него множество, а мы можем использовать лишь некоторые из них для решения конкретной задачи - эта задача может быть описана одним юзкейсом. Например, моя цель пользователя - создать пачку объявлений для расклейки. При этом, я никогда не буду использовать для этого функции Word слияния, внедрения OLE объектов и т.п. Но это не означает, что этих интерфейсов у Word нет :-). Их нет только в контексте нашей конкретной задачи. Следовательно придется вводить еще одно понятие - контекста использования.
2. Юзкейсы могут включать действия пользователя, которые он не выполняет в системе (или может выполнять в другой системе). Т.е. эти действия никак не связаны с функциональностью конкретной системы, которую мы рассматриваем. Пример: У меня как у банковского клерка есть цель - принять решение выдавать кредит или нет. У нас есть система, которая позволяет на основании входных данных дать оценку степени риска невозврата кредита и в ней же будет регистрироваться решение. Но решение принимает в конечном итоге клерк - выдать кредит или нет. Решение может зависеть от многих факторов - желании получить премию, коньюктуры рынка (борьба за каждого клиента) и т.п. ... Имеем, моя целостная и неделимая цель как пользователя - принять решение о выдаче кредита и зафиксировать это решение в системе. Имеем юзкейс - "Принять решение о кредите". Есть ли такая функция у данной системы? Ответ очевиден - НЕТ .... Только не нужно говорить, что тут напрашиваются два юзкейса - не напрашиваются как раз ни разу :-).

На этот раз я достаточно четко сформулировал ответ?

129

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 17 Апреля 2011, 20:09:48 »

Ну, хорошо! Как хочешь.

Ты считаешь, что функции и UC разные вещи?

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

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

1. Можно говорить об отношении пользователя к использованию системы, но это еще не все.

Речь идет о контексте использования?

2. Есть рекомендации именовать UC в терминах названия цели пользователя. Но даже эллипс с названием - это еще не цель. UC - это описание последовательности взаимодействий пользователя с системой для достижения цели. И в этом смысле UC ведет себя в точности как описание внешнего поведения функции.

Я бы сказал, что в данном случае скорее у системы может быть высокоуровневая функция, которая тождественна юзкейсу.

3. Функция и UC, конечно, разное.
- Функция в ПО - это некоторый выделенный фрагмент, который можно выполнить. Где-то в документации есть описание (назначение, указания на предусловия, правила запуска, результат и т.п.).
- UC выполнить невозможно по определению: это описание (у Коберна - соглашение ...). Его сначала нужно реализовать: проанализировать, спроектировать, закодировать, интегрировать в систему. И с этой (я позволю себе дать условное название) реализацией UC поступают точно так же, как с функцией

Мы не говорим про реализацию, а следовательно о функциях можно вести речь только с т.з. RDM. Поэтому говорить об исполнении функций на этом уровне не имеет смысла.

4. Если отождествлять описание и реализацию (это разное, но допустим в этом контексте), то функция - это понятие более широкое, чем UC: любой UC - это функция, но не любая функция - это UC.

Ну я бы все-таки не так категорично определял. Хотя-бы потому, что UC вполне может содержать ряд шагов (действий) пользователя, которые он не делает при помощи system under consideration, но они необходимы для достижения цели пользователя. UC при этом будет существовать, т.к. пользователь имеет определенную цель, но такой функции в системе может попросту не быть! Пример - целью пользователя является принятие решения о выдаче или не выдаче кредита физлицу. Ни одна банковская система не имеет такой функции (решение будет принимать ЧЕЛОВЕК)!!! Но UC такой вполне может существовать :-).

Цитата: lnew от 17 Апреля 2011, 00:35:46

5. ООП предполагает, что все функциональные требования к системе выражаются с использованием UC. О каких других функциях системы ты говоришь? И как они выражаются, определяются?

Это не ООП предполагает, а один из рекомендованных RUP способов. Я бы сказал так, что ООП имеет в своем арсенале множество методологий, фреймворков и подходов, и RUP всего лишь один из них.
Не случайно RUP есть еще один артефакт-документ Supplementary Specification, который как раз был создан для инкапсулирования (внимание) функциональных и нефункциональных требований, которые не были охвачены юзкейсами!

130

Конференции Семинары и Тренинги / Re: ЛАФ 2011 подготовка

« : 17 Апреля 2011, 01:40:36 »

До Питера на машине я точно не поеду ... в прошлом году ездили в Новгород Великий - мне хватило :-). Я за подмосковье, или Владимирскую область .. :-). Например рядом со мной есть этот ДО http://www.sputnikrest.ru/.

131

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 17 Апреля 2011, 01:31:38 »

А вообще-то, Юра, я сожалею, что завел эту бодягу.

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

И какая, суть, разница, декомпозиция это или детализация, является прецедент описанием функции, или нет.
Нам их "рисовать" правильно нужно!.

И это главное.

Ну почему ... подискутировать на "общефилософские" вопросы иногда очень интересно :-). А то сидишь в рутине конкретных проектов ... заказчику же это рассказывать не будешь :-).

132

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 17 Апреля 2011, 01:28:34 »

Цитата: lnew от 16 Апреля 2011, 23:13:22

И вопрос, на который я ответа не получил:

Интерфейсами системы скорее будут функции, а не UC в целом. Т.к. набор функций системы сущность менее зависимая от контекста использования системы, чем UC. Пример - текстовый редактор Word. При его множестве функций, для набора и распечатки текста "Hello world" мы не будем задействовать все его функции. А UC будет существовать - получить распечатку "Hello world". UC можно признать интерфейсом, только вводя понятие контекста использования - т.е. при определенном контексте использования это будет единственным интерфейсом.

133

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 17 Апреля 2011, 01:21:30 »

Спасибо за ответ, но он меня не удовлетворил.
1. Декомпозиция не всегда иерархия (элемент этой декомпозиции м.б элементом многоразового использования, т.е. элементом и другой декомпозиции).

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

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

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

3. UC (описание взаимодействий для достижения цели) декомпозируется в набор описаний отдельных действий по достижению этой цели.

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