Use Case vs. Use Cases - какая должна быть степень детализации?(Прочитано 64178 раз)
Юра!
Ты "замыливаешь" ответы на вполне однозначные вопросы.

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

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

Спасибо.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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

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

Спасибо.

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


На этот раз я достаточно четко сформулировал ответ?
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Ну на вопрос ты не ответил.

Ты сформулировал непонятную для меня фразу. Думаю, не только я не понял. Расшифруй, если можешь, свои слова.

Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.

Каждое слово по отдельности у меня сомнений не вызывает. Но что фраза означает - я не понимаю.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



А стоит ли противопоставлять функцию и UC?
Если, конечно, принять как аксиому, что функция=алгоритм, тогда вопрос уже обсуждался
Вариант использования или Алгоритм?

если нет, то следует ли устраивать такие идеологические споры? Не следует ли дать точное онтологическое определение понятию функция, вариант использования, определить сходные и отличные черты и договорится ...
« Последнее редактирование: 18 Апреля 2011, 14:27:26 от Galogen »



Цитата: Galogen
Не следует ли дать точное отнологическое определение понятию функция....

угу, дай...
Лью воду...



Эдуард! Где тут идеология?

На нашем форуме это часто бывает: увидел аналитик, что другой аналитик в написании иностранного слова ошибся или actor-а "субъектом" назвал (м.п. - из официального перевода!) и святое негодование!

Каюсь. Увидел фразу "непонятную".

Могу обсуждать и UC для Word, и UC принятия решения, и отстоять свою позицию без "замыливания", конкретно.

А сейчас, во второй раз, предлагаю эту бодягу прекратить. И если вопрос в выяснении истины, то предлагаю обсудить это в личной переписке.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Эдуард! Где тут идеология?
Каюсь. Увидел фразу "непонятную".
Леонид, а если я на вашей стороне?



Функция (работа) (лат. functio — совершение, исполнение) — деятельность, роль объекта в рамках некоторой системы, работа производимая органом, организмом; роль, значение чего-либо.

В инженерном искусстве и в области психологии, выражаясь обычным языком, функция обозначает принадлежность к чему-либо, что используется/применяется для устремлений, решения задач, намерений, достижения цели. Фактически это может быть реализовано используя различные физические процессы и один процесс может нести множество функций (Adam Maria Gadomski, 1987). Например, основная функция часов, показывать время, может быть реализована различными физическими процессами, такими как атомный, электронный или механический процесс.

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

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

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

Функция (лат. functio — исполнение) — обязанность, круг деятельности

В литературоведении фу́нкция — это действие персонажа как актанта. Синоним слова акция.

Фу́нкция — в программировании — это поименованная часть программы, которая может вызываться из других частей программы столько раз, сколько необходимо. Функция, в отличие от процедуры, обязательно возвращает значение.

О каком из перечисленных типов определений мы рассуждаем?



Эдуард!

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

Ну какая, в сущности, разница для практиков, можно ли UC называть подкатегорией функции (не функции в программировании, а в широком смысле).

Мы с Юрием, в большинстве случаев, одинаково определяем UC, понимаем, зачем использовать абстрактные UC, и что требования бывают функциональные и не функциональные и т.д. Вот это имеет смысл!

Или ты о примерах с Word и принятия решений?
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Ну ... я уже высказал свою точку зрения - я не думаю, что дискуссия бесполезна. Очень даже интересно пообсуждать ...
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Ну на вопрос ты не ответил.

Ты сформулировал непонятную для меня фразу. Думаю, не только я не понял. Расшифруй, если можешь, свои слова.

Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.

Каждое слово по отдельности у меня сомнений не вызывает. Но что фраза означает - я не понимаю.

Ты победил!
Мне добавить нечего.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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

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

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



По второму вопросу целиком согласен: цель пользователя - получить информацию для принятия решения. Но на диаграмме вполне можно нарисовать эллипс с надписью "Принятие решения". Ведь UC - это не эллипс, а описание последовательности взаимодействий. Пренятие решения - вне границ используемой системы. Точно так же, как решить, нажать OK или Cancel!

По поводу Word, если интересует мое мнение, чуть позже. Мне сейчас отойти надо.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Простите, попросили лампочку вывернуть!

По второму вопросу целиком согласен: цель пользователя - получить информацию для принятия решения. Но на диаграмме вполне можно нарисовать эллипс с надписью "Принятие решения". Ведь UC - это не эллипс, а описание последовательности взаимодействий. Пренятие решения - вне границ используемой системы. Точно так же, как решить, нажать OK или Cancel!

По поводу Word, если интересует мое мнение, чуть позже. Мне сейчас отойти надо.

Возвращаясь к предыдущему: цель пользователя - получить информацию для принятия решения и/или зафиксировать решение.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Относительно первого - Word.

Ну почему же, Эдуард. Требования к любому инструменту, реализующему взаимодействия, можно описать с помощью UC.

И Юрий правильно определил цель пользователя. М.б., я другими словами, но содержание то же, что у Юры: создание, чтение и редактирование текстового документа. Внутри эллипса вполне допустимо написать: "Работа с документом". Единственная цель. Один UC уровня пользователя.
Затем можно написать огромное текстовое описание пользовательского UC по Коберну или нарисовать огромную (по площади и глубине) диаграмму деятельности со множеством вложений.

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

Я не знаю, использовал ли Microsoft термины UC, UCI, UCE. Но есть вещи, которые выполняются одинаково или почти одинаково, независимо от того, как их называют. Думаю, Word делали не один год, определяли цели, рисовали какие-то схемы взаимодействий, определяли спецификации (процессов, функций, UC - все равно, как они их называли!), планировали, для реализации функциональности создавали или использовали существующие классы и компоненты.

Ну, не нравится кому-то называть это UC. Ради Бога! Это как материя, существует независимо от нашего сознания.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru




 

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