Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Galogen от 29 Августа 2011, 09:05:26
-
К вопросу об именовании вариантов использования мы обращались периодически.
Что интересно в мировом сообществе тоже идут дискуссии. Общаясь с Putcha V. Narasimham (http://www.linkedin.com/profile/view?id=2079074&authType=name&authToken=KU4G&goback=%2Egmp_1216497&trk=anet_mfeed_profile) я обнаружил, что он именует варианты использования с точки зрения системы. Т.е. вместо Посмотреть меню или Сделать заказ (для Клиента), он пишет Предоставить меню и Принять заказ. На мой вопрос: "Почему он поступает именно так?", получил ответ:
The Use Case Names are the "Names of Services" that "the System provides". They are very short. If we do not adopt a strict convention we would not know "with reference to what we are giving a particular name to Use Case".
If you name a use case "make payment" it is difficulty to say who makes payment to whom?
If the standard reference is the system, then it means that system makes payment to whoever (Actor) is connected to the Use Case.
If the Actor makes payment, then the system needs to receive the payment. With reference to the system the use case name should be "Enable Payment" or "Receive Payment"...the use case Goal in both the cases is "Actor makes payment to the System and obtains receipt"
My proposed convention is based on typical naming in banks. When a bank says "Payment" it means "Bank pays". "Receipts" means, "Bank receives".
If Use Case Goals are fully written as Use Case Names, then there is NO NEED for any convention.
We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names. One can guess what is intended form commonsense but cannot infer from the Use Case Name.
Во вложении таблица Акторов и Вариантов использования в авторском оригинальном исполнении
Что вы думаете об этом? Какие аргументы за или против выскажите?
-
Думаю, что, может, практически данный подход и применим - описывать ВИ с точки зрения системных сервисов (но, только при условии, что выделены все ДЛ). Однако, при этом получается отступление от самого толкования ВИ как цели пользователя в системе.
Здесь я вижу некоторое пересечение в недавно созданной мною темой (http://www.uml2.ru/forum/index.php?topic=4394.msg29795#msg29795).
-
Преображенский: Так что же вы читаете? Робинзона Крузо?
Шариков: Эту - как её?.. Переписку Энгельса с этим... Как его, дьявола?.. С Каутским.
Преображенский: Позвольте узнать, что вы можете сказать по поводу прочитанного?
Шариков: Да не согласен я.
Преображенский: Что, с Энгельсом или с Каутским?
Шариков: С обоими
:)
В корне не согласен с подходом товарища Putcha. Возникает вопроос, проводился ли вообще этап, именно, Бизнес анализа?! Определялись ли бизнес проблемы, которые необходимо решить с помощью открываемого проекта, выявлялись ли Business Actors, определялись ли их Goals, вообще, каким образом формируется список будущих Use Cases? Если путем функциональной (или системной) декомпозиции будущей системы, то это врядли получится, так как на этапе формирования Busines Use Cases видение системы еще только самое общее... Прикинуть-то можно, только ценность такой прикидки будет нулевая.
Если смогу выкроить полчасика, постараюсь изложить свою точку зрения нашему зарубежному коллеге на "Use Case Professionals" :)
Кстати, возвращаясь к эпиграфу...
Здесь я вижу некоторое пересечение в недавно созданной мною темой.
Павел, мне показалось, что в подходе, описанном в твоем посте, для определения Use Cases опять же используются тот самый метод функциональной декомпозиции... Меня учили (и я с этим согласен), что это мягко говоря "неверный" подход. Дело не в чистоте учения! :) Дело в том, что такой подход уведет вас в сторону и создаст море проблем. Каких, можно обсудить
Короче! Не согласен я! ;D
-
Павел, мне показалось, что в подходе, описанном в твоем посте, для определения Use Cases опять же используются тот самый метод функциональной декомпозиции... Меня учили (и я с этим согласен), что это мягко говоря "неверный" подход. Дело не в чистоте учения! :) Дело в том, что такой подход уведет вас в сторону и создаст море проблем. Каких, можно обсудить
Короче! Не согласен я! ;D
Да, там нечто подобное: сначала декомпозируем систему на модули/подсистемы, а в рамках каждой подсистемы ДЛ выполняют определённые ВИ (но ВИ выполняются как ДЛ, так и, возможно, сервисом системы). Почему это неверный подход? В данном подходе, на мой взгляд, проявляется некое пересечение с ГОСТ 34.602-89, где изначально необходимо определить структуру системы, а потом уже написать функциональные требования к каждому модулю. Однако ФТ могут же быть описаны и с помощью ВИ.
Почему бы не описать с помощью ВИ требования к модулям?
По какой причине метод функциональной декомпозиции не является верным, почему он уведёт в сторону и к каким последствиям его применение может привести? Давайте обсудим.
Спасибо.
-
Друзья, мне кажется дело тут не в подсистемах и декомпозиции.
Возьмем актора/роль Клиент (Patron). Что хочет получить клиент от использования системы?
Разместить заказа на питание (сделать заказ на обед). Зачем? Он хочет поесть в столовой, ресторане или другом общественном месте. Там реализована система электронного меню, которая должна была ускорить процесс обслуживания и дать больше возможности при выборе блюда. Потому чтобы добиться своей цели Пообедать, клиент использует нашу систему чтобы Разместить заказа.
Естественно мы пишим в требованиях нечто вроде: "Система должна Принимать заказы клиентов"
В результате наш индийский коллега в ходе своего жизненного и профессионального опыта делает вывод, что ВИ следует именовать в терминах сервиса. Но это сразу приводит нас к тому, что ВИ=функция (feature)
-
Естественно мы пишим в требованиях нечто вроде: "Система должна Принимать заказы клиентов"
Это пример того, как пользовательские требования декомпозируются функциональными.
индийский коллега в ходе своего жизненного и профессионального опыта делает вывод, что ВИ следует именовать в терминах сервиса. Но это сразу приводит нас к тому, что ВИ=функция (feature)
Коллега неправ. ВИ - это высокоуровневые цели пользователя по отношению к системе, и именоваться должны в терминах целей пользователя.
-
Но это сразу приводит нас к тому, что ВИ=функция (feature)
В том смысле, что UC - функции, реализующие высокоуровневые пользовательские цели, можно согласиться. Имхо.
Но никак не обратное - ес-сно, не всякая функция есть UC.
-
Из профиля уважаемого индийца я сделал вывод, что он работает и преподаёт в Индии.
Эд, ты не мог бы уточнить у него, о каких именно ошибках идёт речь во фразе «We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names»?
У меня есть подозрение, что если у них возникают типовые ошибки в интерпретации названий способов применения, то это может иметь больше отношения к индийской культуре и её отражению в индийском английском, чем к методу вообще.
-
:)
В корне не согласен с подходом товарища Putcha. Возникает вопроос, проводился ли вообще этап, именно, Бизнес анализа?! Определялись ли бизнес проблемы, которые необходимо решить с помощью открываемого проекта, выявлялись ли Business Actors, определялись ли их Goals, вообще, каким образом формируется список будущих Use Cases? Если путем функциональной (или системной) декомпозиции будущей системы, то это врядли получится, так как на этапе формирования Busines Use Cases видение системы еще только самое общее... Прикинуть-то можно, только ценность такой прикидки будет нулевая.
Александр, Putcha всего лишь предложил названия, альтернативные тем, что заявлены у Вигерса: http://processimpact.com/process_assets/sample_requirements_documents.zip
За основу взят перечень способов применения из образца документа Вигерса, поэтому вопросы не имеют смысла.
-
Я в определенной степени выступаю от имени индийского коллеги и хочу пояснить его мнение (как мне кажется).
Он разделяет мнение, что ВИ выражает цель пользователя. Но он считает это сложным моментом, трудным для понимания. Это подчеркивается его последней фразой (последний абзац). И потому предлагает делать так, как предлагает он, потому что это более понятно (с его точки зрения из его личного опыта)
-
Эд, ты не мог бы уточнить у него, о каких именно ошибках идёт речь во фразе «We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names»?
У меня есть подозрение, что если у них возникают типовые ошибки в интерпретации названий способов применения, то это может иметь больше отношения к индийской культуре и её отражению в индийском английском, чем к методу вообще.
Попробую
-
Давайте обсудим.
Павел, с удовольствием. Выбираем день, время, созваниваемся и обсуждаем. Один часовой устный разговор заменяет месячную переписку
-
... пользовательские требования декомпозируются функциональными.
А, если одно пользовательское требование покрывается одним функциональным? Всегда ли мы говорим о декомпозиции одних требований другими, или все-таки они состоят в других "родственных" отношениях? :)
ВИ - это высокоуровневые цели пользователя по отношению к системе...
Что такое высокоуровневые? А, бывают низкоуровневые? Как они выглядят, что описывают, в какой форме?
У меня есть подозрение, что если у них возникают типовые ошибки в интерпретации названий способов применения, то это может иметь больше отношения к индийской культуре и её отражению в индийском английском, чем к методу вообще.
Денис, отличная идея! :) Теперь, если мы будем писать плохие UC мы будем объяснять американцам, что это наша национальная специфика, мы так понимаем английский! :)
За основу взят перечень способов применения из образца документа Вигерса, поэтому вопросы не имеют смысла
Денис, да не важно, что взято за основу, главное, что бы они понимали, что такое UC. Последовательность операций, выполняемых модулем - это все что угодно: алгоритм работы программы, циклограмма, или что-то еще но никак НЕ UC.
Опять же, с удовольствием пообщаюсь на эту тему, но голосом. На развернутые сочинения просто нет времени :(
Да, и не совсем понял по поводу "...вопросы не имеют смысла"
-
Да, и не совсем понял по поводу "...вопросы не имеют смысла"
Александр, вы знакомы с примерами документов Вигерса, опубликованными на его сайте processimpact.com? Сравните текст его документа с текстом индийца. И переадресуйте вопросы Вигерсу, если не находите проработки бизнес-части в документах Вигерса.
-
Денис, да не важно, что взято за основу
А мне важно, тем более что вы начали рыть в сторону «да понимают ли они, что делают».
главное, что бы они понимали, что такое UC.
А вам это зачем?
Вообще разговор беспредметный до тех пор, пока мы не узнаём, в чём заключалась проблема, которую решал индиец и актуальна ли она для участников форума.
А то, знаете ли, можно и холодильник в синий цвет покрасить — как вам идея? по-моему, здорово, давайте обсудим, плюсы-минусы-подводные камни.
-
А, если одно пользовательское требование покрывается одним функциональным? Всегда ли мы говорим о декомпозиции одних требований другими, или все-таки они состоят в других "родственных" отношениях?
В контексте жизненного цикла требований утверждение, что пользовательские требования декомпозируются функциональными (или нефункциональными) вполне правомерно. Считаете, нет?
Что такое высокоуровневые? А, бывают низкоуровневые? Как они выглядят, что описывают, в какой форме?
Бывают, конечно. Например, шаги сценария, входящего в UC и выполняемые пользователем, которые представить в виде самостоятельного UC нельзя никак. Хотя на некотором уровне функциональной декомпозиции они тоже являются целями пользователя.
-
Мальчики и девочки,
грамотный аналитик должен знать язык потенциального конкурента, потому публикую переписку. Думаю в ней нет никаких личных аспектов.
1. синий - первая реплика Пушта
2. Темно-крансный мой ответ вопрос
3. зеленый вторая реплика в ответ на мой вопрос Пушта
Putcha: The Use Case Names are the "Names of Services" that "the System provides". They are very short. If we do not adopt a strict convention we would not know "with reference to what we are giving a particular name to Use Case".
If you name a use case "make payment" it is difficult to say who makes payment to whom?
Why? UC is a part of usage model. This model includes Actors: at least one External Entity (Primary Actor) (who "makes payment " ) and SuD (whom makes payment ). This "whom" is customer (client) of SuD
Putcha: There are two possibilities of payments. Consider an Electronic Shop---the SuD here. SuD buys Goods from Seller and in turn sells Goods to Buyers. In this case both Buyers and Sellers are primary users (SuD is created to serve both of them). SuD 1 receives payments from Buyers and 2 makes payments to the Sellers later. Payments are involved in both the cases of 1 and 2. They need to be distinguished. One way is full expression as given at 1 and 2. If you wish to use a short expression "receives payments" or "makes payments", they should be with ref to SuD in all cases.
Another example is BANK (real or electronic). It (BANK) RECEIVES money and PAYS money.
Putcha: If the standard reference is the system, then it means that system makes payment to whoever (Actor) is connected to the Use Case.
Why again? Actor makes payment by means of SuD. Actor USES the system to make payment. "Make payment" is not an actor goal. Perhaps this goal is to have comfort conditions for a living
Putcha: Please consider End-to-End Transaction involving External Seller and External Buyer (Actors in this case). When a sale occurs, Buyer pays 1 to SuD and SuD pays 2 to Seller. In case 1 Sud RECEIVES payment and in case 2, SuD MAKES payment. That must be clearly indicated in the naming of use cases. Here we are concerned with Use Case Goals ....not ultimate goals of people.
Putcha: If the Actor makes payment, then the system needs to receive the payment. With reference to the system the use case name should be "Enable Payment" or "Receive Payment"...the use case Goal in both the cases is "Actor makes payment to the System and obtains receipt"
Я: Yes but it shall be the SYSTEM goal not the Actor. Actor doesn't want to receive or enable. To recieve or to enable is system responsibility I think.
Putcha: In Use Case Diagram we have only Use Case Goals (there are no separate System Goals. The System is there to enable Actors to Achieve their Use Case Goals). It acts as an intermediary or medium between Buyer and Seller who are NOT directly connected.
With reference to SuD, "Receive Payment" means SuD Receives Payment from the associate Actor (Buyer here). If the use Case Name is "Enable Payment", it means the SuD ENABLES the associated Actor (Buyer here) to PAY. If the Actor associated is Seller the use case name must change. Here SuD "Makes Payment" to Seller. Seller "Receives Payment" FROM SuD but Use Case here SHOUD NOT be named "Receive Payment" because the implied reference here is Seller (which is not correct).
My proposed convention is based on typical naming in banks. When a bank says "Payment" it means "Bank pays". "Receipts" means, "Bank receives".
Putcha:If Use Case Goals are fully written as Use Case Names, then there is NO NEED for any convention.
We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names. One can guess what is intended form commonsense but cannot infer from the Use Case Name.
Я: Could you explain me what kind of confusions in interpreting the Use Case Names have a lot of students and professionals
Putcha: One example involving Buyer Seller is discussed above. There are other such cases. I will compile and send them to you. Thank you.
-
В контексте жизненного цикла требований утверждение, что пользовательские требования декомпозируются функциональными (или нефункциональными) вполне правомерно. Считаете, нет?
Меня смутило слово "декомпозируются". Я привык, что функциональные требования описывают функциональность системы, которая должна помочь пользователю решить его задачи, достичь его цели (goal). Ведь именно User Goals ложаться в основу User Requirements. Т.е. создание набора Functional Requirements - это просто поппытка прикинуть, какая функциональность должна быть реализована. И этот набор создается необязательно путем "декомпозиции" (как, по какому принципу?) пользовательских требований. Отношения между User Requirements и Functional Requirements могут любыми: один ко многим, многие ко многим (т.е. одно пользовательское требование реализуется разными функциональными требованиями, но при этом одно функциональное требование может реализовывать несколько пользовательских в том или ином объеме), многие к одному...
Бывают, конечно. Например, шаги сценария, входящего в UC и выполняемые пользователем, которые представить в виде самостоятельного UC нельзя никак. Хотя на некотором уровне функциональной декомпозиции они тоже являются целями пользователя.
Если мы говорим о пользовательских требованиях, то я бы остановился на "высокоуровневых", как вы их называете. Называть шаги UC, описывающие воздействие пользователя на систему, низкоуровневыми пользовательскими тербованиями, как-то не очень правильно. "Пользователь нажал кнопку Ок" разве это пользовательское требование? Разве это решает какую-то его бизнес проблему? Разве это отражает какую-то его бизнес потребность?
Что пишет библия?
User requirements describe user goals or tasks that the users must be able to perform with the product. Valuable ways to represent user requirements include use cases, scenario descriptions, and event-response tables. User requirements therefore describe what the user will be able to do with the system. An example of a use case is "Make a Reservation" using an airline, a rental car, or a hotel Web site.
Software Requirements, Second Edition
by Karl E. Wiegers ISBN:0735618798
Microsoft Press © 2003 (516 pages)
Т.е. это нечто законченное и значимое с точки зрения бизнеса заказчика. Отдельное действие, вырванное из контекста, типа нажатия на кнопку для пользователя отдельного и законченного смысла не имеет. Поэтому, мое мнение, пользовательским требованием быть не может.
Мы помним, что все требования мы должны валидировать с заказчиком. Если мы предложим заказчику для согласования пользовательские требования в виде "пользователь выбрал пункт меню <menu item>" впрядли он будет счастлив
Как вы считаете?
-
Отношения между User Requirements и Functional Requirements могут любыми: один ко многим, многие ко многим (т.е. одно пользовательское требование реализуется разными функциональными требованиями, но при этом одно функциональное требование может реализовывать несколько пользовательских в том или ином объеме), многие к одному...
Это все так. Но, видимо, вы говорите только о функциональной декомпозиции, тогда как мне кажется значений у этого слова больше. Если применительно к ИС мы можем говорить о "декомпозиции по жизненному циклу" (и термин такой есть), то применительно к требованию почему нет? Пользовательские и функциональные требования относятся к разным стадиям процесса работы с требованиями, можно даже говорить о процессе преобразования требований, полученных от заказчика, в функциональные и нефункциональные. Я в данном случае имела в виду именно это, интуитивно по-моему не менее понятное, чем другие, значение слова "декомпозиция". Про системы так говорят, см ниже. Если к требованиям эти значения почему-либо неприменимы, тогда да, я неправа. :)
Декомпозиция по жизненному циклу. Признак выделения подсистем — изменение закона функционирования подсистем на разных этапах цикла существования системы «от рождения до гибели». Рекомендуется применять эту стратегию, когда целью системы является оптимизация процессов и когда можно определить последовательные стадии преобразования входов в выходы.
Декомпозиция по физическому процессу. Признак выделения подсистем — шаги выполнения алгоритма функционирования подсистемы, стадии смены состояний. Хотя эта стратегия полезна при описании существующих процессов, результатом ее часто может стать слишком последовательное описание системы, которое не будет в полной мере учитывать ограничения, диктуемые функциями друг другу. При этом может оказаться скрытой последовательность управления. Применять эту стратегию следует, только если целью модели является описание физического процесса как такового.
http://victor-safronov.narod.ru/systems-analysis/lectures/rodionov/07.html (http://victor-safronov.narod.ru/systems-analysis/lectures/rodionov/07.html)
-
базука и alex6565, последнее олимпийское. Здесь ведется обсуждение правил именования варианта использования. Озвучен взгляд иностарнных коллег, который привел меня в изумление. Я пытаюсь выяснить у своих отечественных коллег, а что они думают об этом. Ваша же дискуссия идет параллельно. Предлагаю сделать тему и вести дискуссию там, темы ваши могу туда перекинуть
-
базука и alex6565, последнее олимпийское. Здесь ведется обсуждение правил именования варианта использования. Озвучен взгляд иностарнных коллег, который привел меня в изумление. Я пытаюсь выяснить у своих отечественных коллег, а что они думают об этом. Ваша же дискуссия идет параллельно. Предлагаю сделать тему и вести дискуссию там, темы ваши могу туда перекинуть
Опусти пистолет!
Все вопросы мы уже закрыли в личке :)
Эдуард, не проще ли дать коллегам ссылку на эту дисскуссию на Use Case Professionals, вместо того, что бы работать двунаправленным транслятором идей?
-
Эдуард, не проще ли дать коллегам ссылку на эту дисскуссию на Use Case Professionals, вместо того, что бы работать двунаправленным транслятором идей?
[поставил на предохранитель]
1. туда нужно записаться для начала
2. мы ее не ведем в группе, а лично по переписке
-
Друзья, вот что обнаружилось по ходу.
В ряде книг, посвященных разработке ПО и UML от буржуйских коллег: Мацяшек, например. Обнаружил такие рассуждения:
"Прецеденты использования можно называть. ориентируясь на субъект или действующее лицо... Название П.И. с т.зр. действующих лиц не всегда рекомендуется. Легко понять, что их следует называть, занимая позицию внешних действующих лиц. Однако в этом случае труднее установить связь между прецедентами и моделями/артефактами, разработанными позднее, поскольку эти модели и артефакты тесно связаны с внутренним устройством субъектов и подсистем"
Мой уважаемый коллега Пушта из Индии в присланных мне для прочтения материалах пишет:
"ВИ - именованная служба (сервис) системы, которая, как ожидается, обеспечивает ДЛ или действующим лицам, играющим ту же роль, достижение определенной цели"
Далее идет Соглашение о именовании вариантов использования. Формулировки соглашения появились в ходе общения со студентами AMSSOI 2010 Batch:
1. Имя варианта использования относится всегда к систем, а НЕ ДЛ (выделено)
2. Используй глагол, выражающий службу (сервис), которую система выполняет (обеспечивает)
E.g Show contents (NOT View Contents), Present Welcome / Home Page, Give Options and Instructions (NOT SELECT OPTIONS), Receive Payment (Not “Payment”), Capture Decisions, Capture Recommendations, Deliver Cash (NOT Collect Cash), Read Card (NOT INSERT CARD)
3. Используй префикс "Делать возможным" для действий исполняемых действующим лицом
E.g “Enable Registration / Log-in” or “Enable Payment” or “Enable Decision Making” or “Enable Recommendations” or “Enable Card Insertion”
Как я понимаю нет стандарта определяющего правила наименования ВИ, но есть хорошие и плохие практики.
Возникает вопрос: и тот и другой подход именований уместен . А каким образом Вы именуете свои варианты использования, какими правилами руководствуетесь и, если можно, почему
-
С одной стороны, мы говорим о важности отражения цели в ВИ и в его названии,
но с другой - почему мы так мало говорим о целях использования ВИ?
ВИ и ТЗ могут быть написаны с разными целями, для разных групп пользователей. Отсюда и детальность описания, отсюда способ именования.
-
С одной стороны, мы говорим о важности отражения цели в ВИ и в его названии,
но с другой - почему мы так мало говорим о целях использования ВИ?
ВИ и ТЗ могут быть написаны с разными целями, для разных групп пользователей. Отсюда и детальность описания, отсюда способ именования.
1. Потому что я начал тему и задал вопрос именно о правилах именования.
2. Категорически не согласен, это будет вносить еще более серьезную путаницу
-
Интересное набюдение, сделанное мною во время перевода статьи и ответов на вопросы: http://www.uml2.ru/forum/index.php?topic=4413.msg30153#msg30153