Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Galogen от 13 Апреля 2011, 17:45:53
-
Есть такая задача:
Необходимо сконструировать автомат для продажи билетов. Требования к системе просты. Этот автомат принимает монеты достоинством 1, 2, 3 и 5 руб. и выдает билеты стоимостью 5 руб.
При зрелом рассуждении родились две диаграммы использования. Вопрос знатокам, умницам и умникам, какая из диаграмм правильная? Может правильные обе? Почему?
-
Это для какой категории читателей тест?
-
Это для какой категории читателей тест?
Это не тест, это абсолютно взрослый вопрос
-
Use cases во второй диаграмме не подпадают под определение (пользователь хочет купить билет, а не копейка свои отдать!).
Если хочется подробнее, и процессы (и последующие решения по ним) из второй диаграммы предполагается иметь как авуары многоразового использования, их можно поместить на первую диаграмму с отношениями <<include>> от основного.
-
А можно
прокомпостировать билет и не поехать напихать в автомат монет и уйти, не покупая билета?
Или получить сдачу, не напихав предварительно монет?
Или купить билет без денег?
Если можно, то я за вторую диаграмму. :) Если нет - за первую.
-
Use cases во второй диаграмме не подпадают под определение (пользователь хочет купить билет, а не копейка свои отдать!).
разрешите отвечу цитатой:
A use case is behaviored classifier which specifies behavior of a subject (system under construction or consideration) by describing a set of sequences of actions performed by the system to yield an observable result of some value to one or more actors or other stakeholders of the system. In other words, each use case describes a unit of complete and useful functionality that the subject provides to its users.
This functionality, which is initiated by an actor, must always be completed for the use case to complete. It is considered complete if after its execution the subject will be in a state in which no further inputs or actions are expected and the use case can be either initiated again or is in an error state. (http://www.uml-diagrams.org/use-case-diagrams.html#use-case)
И добавить. Пассажир вообще-то хочет куда-то доехать. Вряд ли ему нужен и проездной билет, как мне думается, если продолжать Вашу мысль в развитии :)
Если хочется подробнее, и процессы (и последующие решения по ним) из второй диаграммы предполагается иметь как авуары многоразового использования, их можно поместить на первую диаграмму с отношениями <<include>> от основного.
Сложно как-то вы изъясняетесь :), с трудом понял, что Вы имели в виду. Нет, не хочется. Мне хочется как можно проще, и максимально понятно тому, кто будет разрабатывать систему.
А можно прокомпостировать билет и не поехать напихать в автомат монет и уйти, не покупая билета?
Напихать денег и уйти можно, однако автомат все равно выдаст билет (ну если не выдаст - это проблемы пассажира:))
Прокомпостировать низя.
Или получить сдачу, не напихав предварительно монет?
Можно - чужую, или 0 монет :) Но по-серьезному, будем считать, что контроль существует. Пример увиденный мною в английском автобусе. Там нет контролеров, платишь водителю. Причем он шельма видит сразу и не стесняется напоминать. Покупаешь билет примерно так - как я описал выше: кидаешь монеты - получаешь билет, или даешь водиле, он там сам тебе выдает билет.
Или купить билет без денег?
Размечтался!
Если можно, то я за вторую диаграмму. :) Если нет - за первую.
Понятно, ты за вторую.
Раскрою секрет моих логических размышлений.
1 Диаграмма была получена вследствие также рассуждений, что и у lnew. Какова цель использования автомата - приобрести проездной билет.
2 диаграмма появилась в ходе критики первой и некоторых обсуждений. Критика такова. Мы описали ВИ с точки зрения использования автомата пассажиром. Возникает вопрос, а какая собственно функциональность субъекта (объекта, системы под рассмотрением) тут описывается? Если с позиции системы, то что? Выдать проездной билет? Или что?
Если каждая связь-ассоциация между Актером и Субъектом - есть отражение некоторого интерфейса, то какой интерфейс мы увидим в ВИ Приобрести проездной билет?
В результате получился второй вариант диаграммы, возможно не идеальный, но
принять монету (функциональность автомата!) - предполагает наличие некоторого интерфейса для принятия монеты и отображения суммы
выдать билет - тут может не так очевидно я согласен (но если я еду семьей? или хочу получить больше билетов а не один?)
выдать сдачу - тут может не так очевидно я согласен (но см. выше)
вернуть деньги - да понимаю это странно, но я положил 4 монеты а их сумма не равна стоимости билета, и я хочу вернуть их и положить другую монету?
С другой стороны, не следует ли считать 1 диаграмму диаграммой бизнес ВИ, а 2 диаграммой системных ВИ?
-
С другой стороны, не следует ли считать 1 диаграмму диаграммой бизнес ВИ, а 2 диаграммой системных ВИ?
Для меня диаграмма ВИ - это один из первых шагов анализа. Да, наверное, это можно назвать диаграммой бизнес-ВИ, хотя у меня приставка "бизнес" до сих пор вызывает внутренний протест (я всё пытаюсь представить, как будет выглядеть эта формулировка в ТЗ на какую-нибудь военную систему).
Системных ВИ или сценариев или как-их-там-ещё-называют обычно так много, что помещать их на диаграмму для восприятия человеком нет смысла.
Хотя некоторые, я где-то слышал, даже генерят код из таких диаграмм - для них это, наверное, имеет смысл. Но тогда эта диаграмма уже не для людей, а для роботов.
Вторая диграмма ошибочна в любом случае, потому что Пассажиру все эти кнопки не нужны. Если даже яйца представляют "системные ВИ", мужики должны быть другими.
-
Я человек простой. Автор дал определение. Это аксиома. Спорить с этим определением не смысла. Придумай свой термин и дай ему определение и используй, как хочешь!
Правда, есть некоторые разночтения между определениями UML и Коберна.
В UML это взаимодействие между субъектом и системой (она подразумевается, систему и на диаграммах, как правило, не показывают), а у Коберна система - равноправный субъект. Но есть активный (первичный) субъект. Тот, чья цель выполняется.
В данном случае первичным субъектом является пассажир, а никак не автомат. Т.о., вторая диаграмма точно не верна.
Что касается помещения на первую диаграмму абстрактных (не имеющих своих экземпляров) прецедентов включения из второй диаграммы, то я не знаю, Эдуард, что тебя возмутило?! Обычная практика выделения существенных общих частей, которые много где используются.
И конечно же первая диаграмма, даже расширенная предлагаемым способом, не описывает бизнес процесс (принятый синоним BUC).
Бизнес пассажиру не билет предлагает, а услугу по перевозке.
-
ИМХО вторая Д - это детализация первой, и ВИ 2ой Д совсем низкого уровня (если по Коберну). А ВИ "доехать до т. В" - это ВИ уровня облака.
При данном маленьком примере обе Д имеют право на жизнь (если только во 2ом случае называть ВИ от действий пользователя, н-р, "Получить сдачу"), но если разрабатывается большая Система, то второй вариант не приемлем - Д будет в этом случае только мешать.
-
У меня вопрос.
Хорошо. Пассажир хочет купить билет и ему систему нужна - нарисовали. Но вот работникам автовокзала (пусть там стоит данный автомат) хочется уменьшить время выдачи билета пассажиру. И по-моему это тоже эффект от использования системы. Надо это показывать или нет? Если надо то как?
-
Вопрос действительно интересный! Пошел за попкорном :о)))
2 Денис Иванов: IMHO а работник автовокзала (и почему, кстати, "авто-"?) - actor? Он ведь не использует эти UC, разве что в целях тестирования какого-нибудь.
И потом зачем ему уменьшать время выдачи билета? Можно ведь поставить несколько автоматов (как впрочем и было раньше).
Целесообразнее сократить время обслуживания и увеличить интервалы между обслуживаниями (ну там рулон бумаги для билетов потолще, монетоприемник поглубже и популенепробиваемей, корпус повандалоустойчивее, электричество поменьшеупотреблениестей).
P.S. кстати, вопрос: автомат выдает только один вид билетов? может стоит добавить выбор билета хотя бы по пункту назначения?
-
А вставление карты в картопринмник банкомата - это Use Case? Система выполняет обработку. И кому-то это надо!
А заполнение поля идентификатора пользователя в форме ввода - это Use Case? Система выполняет обработку. И кому-то это надо!
Абсурд!
Авторы идеи дали очень продуктивное определение, ключевыми элементами которого являются существенность, реализация цели первичного субъекта, видимый результат, имеющий ценность для субъекта.
Те, кто знаком с RUP (в разработке начальных версий которого участвовали те же авторы) знают, что Use Case - это элемент планирования результатов итераций, каждая из которых, по RUP, предусматривает выпуск системы (внутренней или внешней версии). Один из признаков прецедента, в таком случае: при пошаговой поставке можно выпустить продукт, выполняющий единственный Use Case!
Ну, и нужно различать Use Case от UML и от Коберна. У них разные определения. Но, с некоторыми натяжками, сопоставлять уровни UML и Коберна можно.
Я себе представляю примерно так:
UML Коберн
Capability UPIA Облако
BUC Змей
Основной UC Море
Абстрактный UC Рыба
нет (Операция?) РакИ не надо забывать, что эти уровни имеют своих субъектов:
- если первая диаграмма - бизнес, то субъект - клиент бизнеса, а не пользователь системы! Кто нибудь слышал, чтобы целью бизнеса было приобретение билета? Если только для перепродажи (раньше это называлось "спекуляция", теперь - "посредничество").
-
Относительно степени детализации.
RUP (и "три амигос") рекомендует сначала определять субъектов, а уже потом - use cases.
Если Вы определили и согласовали субъектов, то дальше для определения степени детализации можно спокойно использовать определение. Никаких если уже не будет!
Ну и еще одна идея из RUP, которую я часто использую, если есть несколько уровней моделирования, например, "предприятие", "бизнес", "системы".
Каждый следующий уровень детализирует (и реализует) предыдущий:
- возможности предприятия (capability) -> функциональные области бизнеса -> системы
- операционные задачи -> BUC (бизнес-процессы) -> функциональные области систем
действия диаграммы деятельности -> системные UC
действия диаграммы деятельности -> абстрактные UC (если существенные!)
Не надо на меня ругаться. Это схема размышлений, а не обязательное правило!!!
Но полезно!
-
Друзья, спасибо за интерес к теме и за ваши комментарии и предложения.
Я вижу, что польза от таких дускуссия есть, хотя бы образовательная. И очень хорошо их начинать именно так, как я сделал - с рисунка и общего контекста.
to lnew, вы пишите
Автор дал определение. Это аксиома. Спорить с этим определением не смысла. Придумай свой термин и дай ему определение и используй, как хочешь!
какой автор? какое определение?
Авторы идеи дали очень продуктивное определение, ключевыми элементами которого являются существенность, реализация цели первичного субъекта, видимый результат, имеющий ценность для субъекта.
Какие авторы? какое определение?
"set of sequences of actions performed by the system to yield an observable result of some value to one or more actors or other stakeholders of the system"
видимый (а что есть видимый?) результат, имеющий НЕКОТОРОЕ значение (ценность) для
разве возврат денег - не НЕКОТОРАЯ ценность для пассажира? (соглашусь по поводу выдачи билета и получения сдачи, хотя, а если получать несколько билетов, а если будет процедура как в банкомате - ожидание следующей операции??)
У меня вопрос.
Хорошо. Пассажир хочет купить билет и ему систему нужна - нарисовали. Но вот работникам автовокзала (пусть там стоит данный автомат) хочется уменьшить время выдачи билета пассажиру. И по-моему это тоже эффект от использования системы. Надо это показывать или нет? Если надо то как?
То есть ты полагаешь, что диаграмма использования должна отражать все эффекты использования системы?
-
В дополнении к обсуждению. что вы думаете об этой диаграмме. Поясняет ли она действие 1 диаграммы UC и устраняет потребность во второй?
-
Добрый день, коллеги!
Разрешите поучаствовать в вашей дискуссии.
На мой взгляд первая диаграмма является более правильной, поскольку отражает именно предназначение, для которого существует система (автомат), хотя я дополнил бы её вариантом использования "Вести учёт билетов", поскольку проездные билеты относятся к БСО и должно быть строго учтены. Также я считаю, что на диаграмме должны присутствовать и работники транспортного предприятия, например, инкассаторы или техники, которые занимаются обслуживанием данного автомата. В конце концов не пассажир же будет конструировать этот автомат, а скорее всего автотранспортная компания.
-
Коллеги, давайте не умножать сущностей сверх меры.
Есть задача - автомат продажи билетов. Определен принцип его работы.
Учет билетов крайне просто. Вставили рулон билетов - знаете количество, кончился рулон, значете сколько продано, сравнили с деньгами, узнали кто кого ну это самое... обманул
-
То есть ты полагаешь, что диаграмма использования должна отражать все эффекты использования системы?
Спасибо, что помог сформулировать мне мой вопрос:)
Итак.
Должна ли диаграмма использования отражать ВСЕ эффекты использования системы?
-
Коллеги, давайте не умножать сущностей сверх меры.
Есть задача - автомат продажи билетов. Определен принцип его работы.
Учет билетов крайне просто. Вставили рулон билетов - знаете количество, кончился рулон, значете сколько продано, сравнили с деньгами, узнали кто кого ну это самое... обманул
Если рассматривать данную задачу с такой "упрощённой" точки зрения, то, на мой взгляд, первая диаграмма ВИ, вполне поясняется представленной диаграммой деятельности и более подходит для визуализации задачи, нежели диаграмма ВИ №2
-
Может быть, это старческий маразм, и я разучился ясно излагать свои мысли!
В первом контексте я имел ввиду любого автора любой концепции (термина и определения). Мы можем использовать слово, которым обозначен термин, в другом контексте. Тот, кто использует эти термины (они разные, они обозначают разные вещи и имеют разные определения) в близком контексте, на мой взгляд, должен указывать, какое именно понятие он имеет ввиду.
Наглядный пример - Use Case по UML и по Коберну. Это близкие, но разные понятия. В UML - это всегда "черный ящик", у Коберна - это может быть и "черный", и "прозрачный" ящик. В ядре UML есть только один уровень (взаимодействие пользователя с компьютерной системой), у Коберна их пять. В определении UML - это класс (набор экземпляров), у Коберна - это "соглашение о ...." (долго перепечатывать!).
Авторы во втором контексте - это авторы UML и понятия Use Case в смысле UML (Буч, Рамбо и Джекобсон, "три друга"). Они же - "инициаторы" создания RUP. В принципе, RUP можно рассматривать как описание технологии использования UML (сам язык, естественно, технологии иметь не может). Рекомендации RUP можно рассматривать как дополнительный материал, отражающий точку зрения авторов UML.
Можно и не использовать, воля ваша! Но это будет ваша концепция, ваш термин. Это язык! Кто-то Вас не поймет!
А теперь представьте себе автомат на вокзале, единственной функцией которого является возврат денег! Вы не согласны с рекомендацией RUP о существенности и планировании пошаговой поставки? Тогда другой пример, более строгий:
Представьте себе полноценный автомат, к нему подходит человек с целью возвратить свои деньги. Если автомат функционирует правильно, то он не отдаст чужие деньги. Т.о., полный процесс должен включать и засовывание монеток в монетоприемник! А это у вас отдельный Use Case?
Но Возврат денег вполне может рассматриваться как абстрактный Use Case, расширяющий основной UseCase при некоторых условиях (уровень рыбы у Коберна).
Еще раз прошу извинить за "мутный" язык. Простым языком говорить разучился. Жена меня называет "прикладной теоретик".
-
В дополнении к обсуждению. что вы думаете об этой диаграмме. Поясняет ли она действие 1 диаграммы UC и устраняет потребность во второй?
Вполне!
Примечание: Касается только UML2.
В узел (кроме Merge и Join) не может входить больше одного потока управления. Большинство инструментов это не контролируют. Но правилами это интерпретируется как последовательность двух элементов: Join и сам элемент, например, Action. Т.е. в данной ситуации управление никогда не будет передано из действия (и конец никогда не наступит!).
В данном случае (в UML2) стрелки от Начала и от Решения должны входить в Merge, а затем в первое действие.
То же относится к Финалу.
Конечно, если не предполагается использование преобразований (MDA), а ситуация по логике ясна, это можно и не соблюдать, особенно при ручном рисовании. Но, как я заметил по себе, лучше правила соблюдать всегда, чтобы случайно не проколоться.
-
Представьте себе полноценный автомат, к нему подходит человек с целью возвратить свои деньги. Если автомат функционирует правильно, то он не отдаст чужие деньги. Т.о., полный процесс должен включать и засовывание монеток в монетоприемник! А это у вас отдельный Use Case?
неее, не надо путать отождествлять процесс и use case.
-
неее, не надо путать отождествлять процесс и use case.
Не понял критики?
Безусловно, Use Case описывает некоторый особый процесс, определенный в UML. М.б. я выразился некорректно.
А что по смыслу неверно?
-
IМНО процесс позволяет достигнуть цели - купить билет (либо в приведенном Вами варианте - получить деньги). для достижения этой цели необходимо использовать несколько UC, т.е. процесс реализуется несколькими (или всеми) UC
С другой стороны, существует процесс, который реализуется только одним UC и полностью им охватывается. Наверное, сюда же может быть отнесен какой-нибудь внутренний процесс автомата, стартующий при выполнении некоторого UC -та же выдача сдачи.
Это я к тому, что процесс - это одно, а UC - другое. они между собой могут быть связаны, а могут и нет.
-
В узел (кроме Merge и Join) не может входить больше одного потока управления. Большинство инструментов это не контролируют. Но правилами это интерпретируется как последовательность двух элементов: Join и сам элемент, например, Action. Т.е. в данной ситуации управление никогда не будет передано из действия (и конец никогда не наступит!).
В данном случае (в UML2) стрелки от Начала и от Решения должны входить в Merge, а затем в первое действие.
То же относится к Финалу.
А нарисовать? Что много буковок и трудно понять о чем речь
-
Я-таки, не понял :)
Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?
Да и вопрос, а если Actor = Пассажир, а Субъект = Монетоприемник, чья единственная функция - принимать монеты
Будет ли это правильно?
-
В общем случае, процесс может и не иметь выраженной цели. Пример: "Это вполне естественный природный процесс!"
Экземпляр UC описывает процесс взаимодействия (у Коберна - Actor & Actor, в UML - Actor & System). UС - это совокупность всех возможных вариантов процесса (в том числе - неудачных) для достижения цели первичного субъекта (primary actor) в UML и всех взаимодейстующих субъектов (у Коберна).
В книжке Коберна (русский перевод): глава 2, Вариант использования как соглашение о поведении, раздел 2.1, Взаимодействие действующих лиц, имеющих цели.
В RUP - рекомендации по именованию: название должно раскрывать цель первичного актера.
Что прецедент описывает варианты процесса, я думаю, сомнения не вызывает.
Но в принципе, критика правильная: то, что написал аналитик, не должно допускать толкований.
-
А нарисовать? Что много буковок и трудно понять о чем речь
Рисовать не умею.
Могу диаграмму прислать по почте.
Merge обозначается таким же ромбиком, как Decision, но Decision имеет один вход и много выходов по условию, а Merge- много входов и один выход.
В UML1 Merge небыло, а Decision допускал много входов и много выходов. Любой сигнал проскакивает без задержки.
Fork и Join. В UML1 была "полоса синхронизации" (не помню, как элемент назывался) для распараллеливания потоков. Сколько из первой полосы вышло, столько должно войти во вторую. Пока не войдут все, курсор дальше не идет.
В UML2 Fork - это элемент, обозначающий разветвление: один вход и множество (безусловных) выходов. Каждая нить может выполняться, и может либо объединиться с другими потоками управления в элементе Join, либо завершиться узлом Activity Final (завершается весь процесс) или Flow Final (прекращается только эта нить управления).
Элемент Join: много входов и один выход. Те потоки, которы прибежали раньше, ждут, пока не придут все.
-
Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?
Да, но только не связанными напрямую с Пассажиром (Билетопокупателем).
Мой вариант диаграммы ВИ:
С Пассажиром связан один ВИ: Продажа билета.
ВИ Продажа билета "включает" ВИ: Прием оплаты, Выдача билета
ВИ Возврат оплаты "расширяет" ВИ Прием оплаты.
ВИ Выдача сдачи "расширяет" ВИ Выдача билета.
Другим Актором будет Администратор, ВИ: Обслуживание.
ВИ Обслуживание "включает" ВИ: Контроль состояния, Инкассация, Загрузка билетов.
-
В дополнении к обсуждению. что вы думаете об этой диаграмме. Поясняет ли она действие 1 диаграммы UC и устраняет потребность во второй?
(http://www.uml2.ru/forum/index.php?action=dlattach;topic=3729.0;attach=3379)
Нет не поясняет (в смысле не полностью поясняет), нет не устраняет (необходимость и корректность второй UC пока не очевидна).
-
Я-таки, не понял :)
Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?
Да и вопрос, а если Actor = Пассажир, а Субъект = Монетоприемник, чья единственная функция - принимать монеты
Будет ли это правильно?
Выражаю свое мнение по второму вопросу (по первому повторяться смысла нет).
Если у монетоприемника есть цель, и он может привлечь пассажира, то можно, только у ассоциации нужно стрелку поставить, что манетоприемник инициирует взаимодействие.
В жизни ситуация нереальная. Он что, в зале ожидания будет человека за руку хватать?
Иначе это будет "проход через турникет", см. выше все обсуждения.
-
Нет не поясняет (в смысле не полностью поясняет), нет не устраняет (необходимость и корректность второй UC пока не очевидна).
Обоснование?
-
А из какого простите контекста вы вообще говорите об автомате в каком-то вокзале?
Я вообще имел в виду, обычный автомат, ручной прототип которого долгие годы существовал во всех видах общественного городского транспорта :)
Если у монетоприемника есть цель, и он может привлечь пассажира, то можно, только у ассоциации нужно стрелку поставить, что манетоприемник инициирует взаимодействие.
В жизни ситуация нереальная. Он что, в зале ожидания будет человека за руку хватать?
Иначе это будет "проход через турникет", см. выше все обсуждения.
Ничего, простите не понял. Монетоприемник элемент рассматриваемой системы, цель у пассажира в использовании части общего устройства - монетоприемника, а вы мне что тут ответили, я что-то не могу понять
-
А вот то что можно легко ошибиться с уровнем детализации вариантов использования, не указывает ли на явный недостаток UML?
-
А вот то что можно легко ошибиться с уровнем детализации вариантов использования, не указывает ли на явный недостаток UML?
Не указывает. Поскольку варианты использования, это только часть UML, причем часть как бы, стоящая несколько в стороне.
Правда подобным недугом страдают все методологии ибо это болезнь мозга, а не языка
-
Извини.
Я невнимательно прочитал. Увидел слово Субъект. А в русском переводе RUP 7.x Субъект = Actor.
Наверное, нужно использовать английские слова.
Если пассажир - actor, а манетоприемник - system, то все правильно.
Такие системы стоят, например, в церкви для сбора пожертвований прихожан. Но это же вырожденный случай.
Я сейчас попробую тебе выложить две диаграммки про Merge и Fork.
-
В общем случае, процесс может и не иметь выраженной цели. Пример: "Это вполне естественный природный процесс!"
я еще не так могу выражаться :о))) поверьте на слово. а если серьезно, мы же говорим о некоем конкретном процессе получения билета. соответственно, в данном случае должна идти речь о конкретном результате: "билет получен" (в данном случае наличие сдачи несущественно, ибо это как раз один из вариантов) или "билет не получен, деньги возвращены" (мало ли передумал или денег не хватило).
прецедент описывает варианты процесса
IMHO будет лучше не "варианты", а "элементы","функции","составляющие" и т.п., т.е. то, из чего процесс состоит. но может и весть процесс описывать.
-
Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?
тут же что важно - точка зрения.
если мы рассматриваем систему с точки зрения пассажира, то будет, соответственно:
- забрать/получить деньги
- забрать/получить сдачу
- забрать/получить билет
- внести деньги (засунуть их в дырочку монетоприемника)
если с точки зрения автомата, то как ты написал.
следствием может быть интересная особенность, если мы разрабатываем автомат для пользователя, то наличие пользователя при работе автомата сама собой разумеющаяся вещь. а в случае разработки автомата самого по себе, то наличие пользователя bla-bla-bla - обязательное требование :о))) это может быть важно при твоем любимом тестировании.
так что ты уж определись...
Да и вопрос, а если Actor = Пассажир, а Субъект = Монетоприемник, чья единственная функция - принимать монеты
Будет ли это правильно?
я бы сказал, что нет.
лучше всех, кого надо, в actor'ы записать, а кого не надо - тех вообще забыть. предлагаю монетоприемник забыть до определенного времени (пока проектировать состав подсистем не начнем). ну и термин "субъект" не надо использовать, чтобы не забивать голову честным людям.
-
Эдуард, не нашел как в личных сообщениях вставить картинку.
Не всем это интересно.
Это фрагмент описания бизнес процесса (в RUP - синоним BUC) ("белый ящик").
Диаграммы представлены с целью показать использование некоторых новых (относительно UML1) элементов диаграммы деятельности UML2.
-
Эдуард, не нашел как в личных сообщениях вставить картинку.
Не всем это интересно.
Спасибо, в личке нельзя ...
-
я еще не так могу выражаться :о))) поверьте на слово. а если серьезно, мы же говорим о некоем конкретном процессе получения билета. соответственно, в данном случае должна идти речь о конкретном результате: "билет получен" (в данном случае наличие сдачи несущественно, ибо это как раз один из вариантов) или "билет не получен, деньги возвращены" (мало ли передумал или денег не хватило).
IMHO будет лучше не "варианты", а "элементы","функции","составляющие" и т.п., т.е. то, из чего процесс состоит. но может и весть процесс описывать.
Я опять неточно выразился: use case (класс) описывает все возможные варианты (в том числе - неудачные) достижения цели. Под вариантом я здесь понимаю совокупность "одинаковых" экземпляров (в смысле "пути" выполнения).
Что касается "билет получен", то цель пользователя системы состоит только в этом: корректно получить билет (со здачей и т.п.) Но цель обращения к системе одна, и Use Case один! (Если не плодить UCE и/или UCI). И Эдуард правильно поступил, нарисовав диаграмму деятельности. Скорее всего, этот небольшой Use Case не будет иметь существенных (сложных, требующих отдельного описания и планирования, частей.
Примечание: В RUP имеется ввиду архитектурная существенность.
-
но ведь очевидно, что этот единственный UC (как и сошлись раньше) - предметного уровня (привет военным об бизнеса!).
и этого недостаточно, чтобы разработать систему, в т.ч. ответить на вопрос - нужен монетоприемник или нет. или нужно ли предусмотреть купюроприемник (или оба два) или считыватель карточек (или все три). вот и изгаляемся с детализацией. думаю, что и она предметного уровня, только более детальная (на то она и детализация).
-
но ведь очевидно, что этот единственный UC (как и сошлись раньше) - предметного уровня (привет военным об бизнеса!).
и этого недостаточно, чтобы разработать систему, в т.ч. ответить на вопрос - нужен монетоприемник или нет. или нужно ли предусмотреть купюроприемник (или оба два) или считыватель карточек (или все три). вот и изгаляемся с детализацией. думаю, что и она предметного уровня, только более детальная (на то она и детализация).
Да, Вадим, ты идею понял. Именно так. Действительно, будет ли достаточно такой диаграммы и возможно ДД для проектировщика? Разработчика? Достаточно ли информации тестировщику? Конструктуру внешней оболочки?
Далее я предложу еще такую примитивную диаграммку.
Тут уже класс и его операции методы, а они суть его ответственности, которые выводятся возможно из вариантов использования, и возможно из деятельностей.
Или может следовало бы показать структуру этого автомата через его части?
-
Вообще, спецификация UML подразумевает, что любой модельный элемент должен иметь краткое описание.
Этого описания д.б. достаточно только для принятия решения "делать-не делать". Но ничего о том, как делать.
В определении Use Case говорится, что это описание последовательностей (экземпляров) взаимодействий.
- UML предложил описывать с помощью диаграмм деятельности (элементы диаграммы тоже должны иметь описания!)
- Коберн, к тому времени не читавший UML, предложил шаблон текстового описания, вполне справедливо считая описание процессов с помощью UC diagram "блудом" (но этого в UML и не предлагалось). Все начало книжки этому посвящено!
Т. о. становится понятно, что должна делать система в ответ на действия пользователя, но ничего о том, как она должна работать. Там может и не быть упоминания "монетоприемника", но там должно быть написано, что система берет деньги, считает, дает сдачу и т.п. (диаграмма, которую представил Эдуард).
Работа аналитика (роли) на этом заканчивается, если не считать поддержку в актуальном состоянии в связи с изменением взглядов пользователя или разработчиков.
К стати, именно эта часть бизнес-процесса (не до конца) представлена на моем фрагменте выше.
Ну, и так далее.
Резюме: фактически перечень прецедентов - это несколько иное представление целей всех потенциальных пользователей. А их описания представляют функциональные (что должна делать) требования к системе.
Спасибо тем, кто прочитал эту нудятину до конца!
-
Да, Вадим, ты идею понял. Именно так. Действительно, будет ли достаточно такой диаграммы и возможно ДД для проектировщика? Разработчика? Достаточно ли информации тестировщику? Конструктуру внешней оболочки?
Далее я предложу еще такую примитивную диаграммку.
Тут уже класс и его операции методы, а они суть его ответственности, которые выводятся возможно из вариантов использования, и возможно из деятельностей.
Или может следовало бы показать структуру этого автомата через его части?
Если есть разделение на аналитиков и разработчиков, то диаграмма классов - это уже реализация. Аналитик, как правило, не должен ограничивать разработчика в способах реализации требований.
К диаграмме деятельности эта новая диаграмма ничего не добавляет.
Если в жизни, дальше нужно создавать модель анализа или проектную модель, в которой для каждого use case создавать кооперацию use case realization и рисовать диаграммы последовательности, имея перед глазами соответствующую диаграмму деятельности.
Я иногда такой курс читаю в московском Интерфейсе. Правда, я основной упор делаю на "беззатратное" документирование проектов разработки ПО.
-
Дааа, тема пошла интереснааааяя
Действительно, будет ли достаточно такой диаграммы и возможно ДД для проектировщика? Разработчика? Достаточно ли информации тестировщику? Конструктуру внешней оболочки?
разумеется недостаточно. однако не стоит забывать, что мы сейчас еще только анализируем, а не проектируем (граница между этими этапами конечно размытая, но тем не менее). это, кстати, к вопросу "как делать?" формально говоря, мы на него сейчас еще ответить не можем. поэтому нам, помимо аналитиков и разработчиков, еще понадобятся проектировщики (они-то и соединяют первых и вторых).
Далее я предложу еще такую примитивную диаграммку.
Соглашусь с Леонидом, эта диаграмма ничего сейчас не дает, кроме перечня вариантов возможных монет. а это сейчас несущественно. Поэтому предлагаю перейти к его предложению по другим диаграммам. С последовательностью очевидно возникнет некоторая трудность, т.к. у нас еще не определены подэлементы автомата, и она (диаграмма) тоже может нам ничего не дать.
P.S. согласен с Коберном: определить процесс с помощью UC невозможно, хотя что описание UC очень на него похоже и может показаться, все это является одним и тем же.
-
Во первых, не все так плохо.
Спецификация каждого use case, полученная с помощью диаграммы деятельности или по Коберну (я генерю спецификации по своему шаблону из диаграмм, и они получается точь в точь, как описания Коберна) - это почти готовый тесткейс (добавить, что ввести и что ждать). Почти готовое руководство пользователя.
Когда в диаграмме описываются взаимодействия, они могут описываться в термина граничных классов анализа (boandory).
Диаграмму последовательности многие используют как раз для поиска необходимых модельных элементов. Есть такая замечательная книжка Лармана: Применение UML и шаблонов проектирования. И в RUPе, насколько я помню, эта технология используется.
Откуда брать классы? Придумывать? Не метод для проектировщика, и тем более для аналитика! Смотрим на диаграмму Эдуарда. Там в описании написано:
- Система выводит сообщение о необходимости оплаты
- Пользователь вводит в приемное устройство купюры достоинством ...
На диаграмме создаем линию жизни приемного устройства. Это экземпляр граничного класса. Думаем, создаем класс. От пользователя рисуем сообщение (принятьДеньги()) к созданной ранее линии жизни устройства. В классе ручками или автоматом создаем операцию с тем же именем.
Скорее всего, устройство приема будет идентифицировать дензнаки и считать. Соответственно нужны приватные операции идентифицироватьДензнак() и т.д.
Для хранения суммы создаем атрибут.
И т.д. по диаграмме деятельности (или по описанию Коберна).
Необходимые классы, их атрибуты и операции "вытекают" из логики use case. Use Case - очень продуктивная идея!
При реализации следующего use case какие-то элементы уже есть. Может быть, к ним надо добавить атрибуты и операции, или использовать уже имеющиеся.
Конечно, это еще не окончательные классы. Разные языки, платформы, особенности технологии! Но такую систему можно сделать!
-
все-таки, думаю, не надо уподобляться Шерлоку Холмсу, ставящему в тупик своего коллегу Ватсона :о)))
лучше все же пояснять внимающему человечеству, откуда берется "приемное устройство" (и потом про купюры разговора не шло :о))) и про сообщение о необходимости оплаты тоже).
Диаграмму последовательности многие используют как раз для поиска необходимых модельных элементов. Есть такая замечательная книжка Лармана: Применение UML и шаблонов проектирования.
Ага, так и делал. И книжка одна из самых полезных и тоже любимых в свое время.
-
Друзья, спасибо за продуктивную дискуссию. Думаю не стоит сила тратить на эту задачу. Всем она достаточно понятна, либо у многих свое оригинальное ее понимание. Цель дискуссии все-таки сводилась именно к диаграмме ВИ, и вопросу насколько она практична и полезна в дальнейшем.
Впрочем у меня нет никаких возражений сделать из этой задачи образец моделирования. С вашей помощью, конечно.
Кстати, мне кажется, мы как -то игнорировали вопрос Дениса Иванова.
-
Ну, тут уж я додумываю. Я же не эту конкретную задачу решаю. Как я понимаю, мы с обсуждения совершенно абстрактной диаграммы начали, и цели разработки продукта, и даже требований, не ставили. Если это не так, извините.
Считается, что аналитик, по крайней мере в общем случае, не должен ограничивать проектировщика. Черт его знает сейчас, какие устройства там будут. Но что деньги будет брать приемное устройство, понятно. М.б., это будет манетоприемник, может - щель в крышке. То же и про деньги. Если там написано "купюры", значит я не о том думал, когда писал. Самое нейтральное, наверное, "дензнаки".
-
Спасибо, что помог сформулировать мне мой вопрос:)
Итак.
Должна ли диаграмма использования отражать ВСЕ эффекты использования системы?
А что такое эффекты? Тем более ВСЕ?
Диаграмм, обычно, рисуют много, каждая для иллюстрации чего-то:
- обзор главных use cases системы
- все use cases определенного ator-а
- контекст определенного use case
Для достаточно большой системы все use case на одной диаграмме никогда не рисуют.
Но
полный список всех use case должен охватывать цели обращения к системе всех actor-ов.
-
Вот чего не ожидал - так это ТАКОЙ дискуссии по очевидному ответу :-). Эд - если подходить к вопросу с прикладной точки зрения, то более правильно использовать первую диаграмму с одним юзкейсом. Если говорить о Коберне, то это юзкейс уровня "Цель пользователя" (User Goal).
-
Извини.
Я невнимательно прочитал. Увидел слово Субъект. А в русском переводе RUP 7.x Субъект = Actor.
Наверное, нужно использовать английские слова.
Ага, еще юзкейс называют "прецедентом" :-). Переводить Actor как Субъект, это нужно иметь ну очень сильный философско-сисмтемноаналитический бекграунд :-). Мне больше нравится "Основное действующее лицо", хотя тоже "не фонтан", т.к. лицо ассоциируется с человеком ....
-
По actor = субъект можно обратиться в IBM.
А если по русски, то в старом словаре по системотехнике я нашел такой термин: актор (от англ. actor) - субъект взаимодействия в системе. Правда, это было очень давно, и с тех пор человеческая фантазия родила "актера" и т.д.
М.б. IBM-овские переводчики нашим словарем воспользовались?
-
Эд - если подходить к вопросу с прикладной точки зрения, то более правильно использовать первую диаграмму с одним юзкейсом.
Такой вариант UC похож на ответ козопаса Шерлоку Холмсу. На вопрос: "Сэр, вы не подскажете, где мы находимся?", он ответил: "В корзине, прикрепленной к воздушному шару".
Задача автора "спроектировать систему". Первый вариант UC не отвечает на вопрос - что должна делать система Автомат для достижения цели Пассажира (Билетоприобретателя). Этот UC - бизнес ВИ, и не отражает концептуальную модель системы.
-
Такой вариант UC похож на ответ козопаса Шерлоку Холмсу. На вопрос: "Сэр, вы не подскажете, где мы находимся?", он ответил: "В корзине, прикрепленной к воздушному шару".
Задача автора "спроектировать систему". Первый вариант UC не отвечает на вопрос - что должна делать система Автомат для достижения цели Пассажира (Билетоприобретателя). Этот UC - бизнес ВИ, и не отражает концептуальную модель системы.
Почему не отвечает? Система должна продать билет пассажиру. А не ботинки ему почистить, например.
(А такое требование тоже может возникнуть в процессе разработки - эти заказчики такие заказчики!)
А термин "концептуальная модель" требует раскрытия.
-
Почему не отвечает? Система должна продать билет пассажиру. А не ботинки ему почистить, например.
(А такое требование тоже может возникнуть в процессе разработки - эти заказчики такие заказчики!)
Из данного UC "Приобрести проездной билет" - не следует что автомат должен: принимать оплату (монетами), возвращать оплату, выдавать билет, выдавать сдачу.
Например я приобретаю билет через интернет и выполняю электронную регистрацию. Оплата безналичная, билет в бумажном виде не выдается, оплата может быть безналичной и т.д.
У автора задача спроектировать (сконструировать) устройство автомат для продажи билетов, исходя из дополнительного описания система должна выполнять такие функции как: приемка оплаты, выдача билета, выдача сдачи.
Насчет концептуальности диаграммы ВИ:
http://www.intuit.ru/department/pl/umlbasics/3/ (http://www.intuit.ru/department/pl/umlbasics/3/)
"Диаграмма вариантов использования - это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:
- Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы
- Сформулировать общие требования к функциональному поведению проектируемой системы
- Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей
- Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями
Назначение данной диаграммы состоит в следующем: проектируемая программная система представляется в форме так называемых вариантов использования, с которыми взаимодействуют внешние сущности или актеры. При этом актером или действующим лицом называется любой объект, субъект или система, взаимодействующая с моделируемой бизнес-системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру. Другими словами каждый вариант использования определяет набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования."
-
Из данного UC "Приобрести проездной билет" - не следует что автомат должен: принимать оплату (монетами), возвращать оплату, выдавать билет, выдавать сдачу.
Например я приобретаю билет через интернет и выполняю электронную регистрацию. Оплата безналичная, билет в бумажном виде не выдается, оплата может быть безналичной и т.д.
У автора задача спроектировать (сконструировать) устройство автомат для продажи билетов, исходя из дополнительного описания система должна выполнять такие функции как: приемка оплаты, выдача билета, выдача сдачи.
И что, всё проектирование должно вестись прямо на этой диаграмме?
А в от длинной цитаты про концептуальную модель я оставлю только последнюю фразу:
При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования."
-
Из данного UC "Приобрести проездной билет" - не следует что автомат должен: принимать оплату (монетами), возвращать оплату, выдавать билет, выдавать сдачу.
Боюсь быть неправильно понятым, поэтому добавляю ещё один пост. :)
Если вам удобнее отразить все эти особенности на ДВИ - отражайте на здоровье.
Любая диаграмма - это инструмент а) анализа и б) обмена информацией. Если она эффективно решает эти задачи, то это хорошая, годная диаграмма.
Диаграмма 2 на исходном рисунке мне не нравится именно потому, что она может быть неправильно понята. Если на неё посмотрит разработчик (или проектировщик интерфейса автомата), то на выходе вы можете получить 4 кнопки на автомате: "Принять монету", "Выдать билет", "Выдать сдачу", "Вернуть деньги". Причём реализованные в железе.
Как инструмент анализа, она, наверное, может быть представлена в таком виде, но только как черновик. Включать её в концепцию или в документ с требованиями нельзя. Потому что если что-то может быть понято неправильно, оно будет понято именно так.
-
Модель (а не диаграмма) UC должна отвечать на большинство вопросов, поставленных DinamoYA.
(Эта модель не должна отвечать, как устроена система.)
Но диаграмма UC - это только часть модели.
Выше в этой теме уже говорилось, что, в соответствии с UML, каждому UC соответствуют:
- краткое описание назначения этого UC (оно раскрывает название)
- описание последовательности взаимодействий участников (в виде диаграммы деятельности (тоже комментированной описаниями каждого узла) или в виде текстового описания).
Если вы хотите все это представить на одной диаграмме UC, Вам просто не хватит нотаций (два типа сущностей и до пяти типов отношений (вместе со стереотипами!))
Критике такого подхода Коберн посвятил почти половину своей книги.
Но мы уже начали "перепевать" тему по третьему разу. К сожалению, новые участники не читают дискуссию с начала.
-
Соглашусь с Леонидом и Гришей.
2 DinamoYA, ИМХО у Вас есть сильное не понимание модели ВИ.
Пользовательский ВИ - это в первую цель пользователя. Ну нет цели у Пользователя засунуть в автомат деньги! У него есть цель - получить билет, а уже все детали функционирования ВИ (что делает Пользователь и как отвечает Система) описываются в виде сценария ВИ или ДД/ДП/ДВ.
-
Пользовательский ВИ - это в первую цель пользователя. Ну нет цели у Пользователя засунуть в автомат деньги! У него есть цель - получить билет, а уже все детали функционирования ВИ (что делает Пользователь и как отвечает Система) описываются в виде сценария ВИ или ДД/ДП/ДВ.
Уважаемый bas, Вы не могли бы раскрыть что вы вкладываете в термин "Пользовательский ВИ", в чем по вашему выражено наше непонимание сути диаграммы ВИ.
Формируя свои ответы я исходил из самого первого сообщения уважаемого Автора "Use Case vs. Use Cases - какая должна быть степень детализации?".
В его вопросе нигде не сказано с какой точки зрения мы должны посмотреть на проектируемую систему.
У Пассажира нет цели засунуть деньги я с вами согласен, но ведь у "Автомата" (утрирую, конечно у его владельца) - есть бизнес-цель - "получить деньги взамен билета". Данная цель неявна и не отражена на представленных автором диаграммах.
Ранее я предложил свой вариант диаграммы ВИ демонстрирующую точку зрения на проектируемую систему Автомат http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642 (http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642)
Мой вариант диаграммы ВИ:
С Пассажиром связан один ВИ: Продажа билета.
ВИ Продажа билета "включает" ВИ: Прием оплаты, Выдача билета
ВИ Возврат оплаты "расширяет" ВИ Прием оплаты.
ВИ Выдача сдачи "расширяет" ВИ Выдача билета.
Другим Актором будет Администратор, ВИ: Обслуживание.
ВИ Обслуживание "включает" ВИ: Контроль состояния, Инкассация, Загрузка билетов.
Пока этот вариант Автором или другими участниками не прокомментирован (возможно потому что не представлена картинка).
-
Уважаемый bas, Вы не могли бы раскрыть что вы вкладываете в термин "Пользовательский ВИ", в чем по вашему выражено наше непонимание сути диаграммы ВИ.
Формируя свои ответы я исходил из самого первого сообщения уважаемого Автора "Use Case vs. Use Cases - какая должна быть степень детализации?".
В его вопросе нигде не сказано с какой точки зрения мы должны посмотреть на проектируемую систему.
У Пассажира нет цели засунуть деньги я с вами согласен, но ведь у "Автомата" (утрирую, конечно у его владельца) - есть бизнес-цель - "получить деньги взамен билета". Данная цель неявна и не отражена на представленных автором диаграммах.
Ранее я предложил свой вариант диаграммы ВИ демонстрирующую точку зрения на проектируемую систему Автомат http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642 (http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642)
Пока этот вариант Автором или другими участниками не прокомментирован (возможно потому что не представлена картинка).
Невнимательно читали! Такой вариант предлагался почти в самом начале. Как вариант, если абстрактные UC имеют архитектурную существенность.
-
И что, всё проектирование должно вестись прямо на этой диаграмме?
Уважаемый, greesha, где вы на моем примере диаграммы ВИ (извините что в тексте, картинку пока не нарисовал) увидели "проектирование"? Что вы вкладываете в этот термин?
На данном этапе я пытаюсь ответить на первоначальный вопрос автора какая из диаграмм правильная.
Есть бизнес-процесс продажи билета через автомат: от "инициирования покупателем функции покупки билета" до "выдачи билета (и сдачи) или возврата денег (при отказе)".
Первая "не правильна" потому что не описаны функции автомата и не отвечает на вопрос что делает автомат взаимодействуя с пользователем, вторая тем что в данном представлении не отражает в комплексе целевого назначения автомата - "продать билет путем приемки оплаты и выдачи билета".
Основная задача первого этапа - сформулировать требования к проектируемому автомату.
Чтобы это сделать необходимо сначала обозначить какие функции будет выполнять автомат при взаимодействии с пользователем.
bas, считает, что следует отобразить только один ВИ (функцию или процесс) - "Приобрести проездной билет".
Я считаю что это бизнес ВИ, и он должен быть отображен с использованием соответствующих стереотипов.
При этом дополнительно имеет смысл добавить на такую бизнес ВИ актора Продавец и отобразить ВИ "Продать проездной билет".
Но это примеры бизнес ВИ, который не позволяет показать какие функции должна выполнять проектируемая система, с учетом текстового описания задачи уважаемым Galogen'ом. В этом описании обозначено что автомат должен: принимать оплату, возвращать оплату, выдавать билет, выдавать сдачу.
Опять же вернусь к примеру с интернет заказом билетов. Получается что система интернет продаж и автомат по продаже билетов будут иметь одинаковую диаграмму ВИ поскольку и та и другая система помогают Пассажиру достичь бизнес-цели "Приобрести проездной билет" (а продавцу цели Получить оплату за билет).
Под собственно проектированием я подразумеваю уже последующие шаги, ответ на вопросы как автомат будет выполнять эти функции, через какие интерфейсы, в какой последовательности и т.п.
-
Да!...
Конечно, граница между моделированием бизнеса и систем размыта!
Но что-то я в данном случае бизнеса не вижу.
Некоторые, например RUP, подразделяют BUC на основной бизнес, поддержку бизнеса и управление бизнесом. К какой категории, уважаемый, вы отнесете "Приобретение билета"?
Нормальный пользователь подходит к нормальной системе и выполняет свою цель. Где тут бизнес? Если покупатель BActor, то кто системный Actor?
Тогда любой UC является BUC?
Наверное, мы о разном UML-е речь ведем!
-
Но что-то я в данном случае бизнеса не вижу.
Некоторые, например RUP, подразделяют BUC на основной бизнес, поддержку бизнеса и управление бизнесом. К какой категории, уважаемый, вы отнесете "Приобретение билета"?
Нормальный пользователь подходит к нормальной системе и выполняет свою цель. Где тут бизнес? Если покупатель BActor, то кто системный Actor?
Тогда любой UC является BUC?
Наверное, мы о разном UML-е речь ведем!
Под понятием "бизнеса" в этом случая я понимаю "деятельность направленную на удовлетворение потребностей".
В данном примере у потребителя есть потребность "приобрести билет" (вызвана требованием иметь билет для поездки куда либо), у продавца потребность - "получить деньги" (за саму ли услуги продажи билета или за услугу для которой приобретается билет не важно).
Это и есть в моем понимании "бизнес ВИ". В предложенном БВИ будет только два ВИ.
Эти потребности заинтересованных сторон предложено реализовать через систему "автомат по продаже билетов".
Автор в одном из сообщений упомянул что точка зрения на диаграмму ВИ должна быть "Мне хочется как можно проще, и максимально понятно тому, кто будет разрабатывать систему."
Тому кто будет проектировать автомат не так важен бизнес ВИ. Ему нужно понимание какие функции и для кого выполняет система, какие в связи с этим есть ограничения и исключения.
-
Есть такая задача:
Необходимо сконструировать автомат для продажи билетов. Требования к системе просты. Этот автомат принимает монеты достоинством 1, 2, 3 и 5 руб. и выдает билеты стоимостью 5 руб.
При зрелом рассуждении родились две диаграммы использования. Вопрос знатокам, умницам и умникам, какая из диаграмм правильная? Может правильные обе? Почему?
Эдуард Геннадьевич, на мой взгляд, правильной из 2-х представленных диаграмм является 1-я, т.к. она отражает верхнеуровневую цель пользователя, которую он хочет достичь с помощью Системы (собственно говоря, цель в данной области действия одна). Как ранее говорил Александр Байкин, если применять теорию Коберна, она будет соответствовать уровню "воздушного змея".
2-я диаграмма не совсем корректна. Почему?
1. Она, в отличие от первой, находится на ином уровне абстракции.
2. Действующим лицом должен быть не пользователь, а сама Система.
3. Если 2-я диаграмма отображает поведение Системы, то незачем применять элемент диаграммы "Границы Системы" (прямоугольник).
А вообще, я бы 1-ю диаграмму декомпозировал на диаграмму деятельности, шагами которой были бы названия, приведённые во 2-й диаграмме. Почему я бы так сделал? В диаграмме 2 явно прослеживается бизнес-процесс.
Смотрю, что в теме уже были такие предложения. Соглашусь с ними.
-
Основная задача первого этапа - сформулировать требования к проектируемому автомату.
А на каком этапе тогда мы определяем границы системы - будет она билеты продавать или ботинки чистить?
Ну ладно, чёрт с ними, с ботинками - это провокационное предложение, конечно.
Но, скажем, почему бы не использовать автомат для размена монет, без покупки билета? Вторая диаграмма это не запрещает.
-
Уважаемый bas, Вы не могли бы раскрыть что вы вкладываете в термин "Пользовательский ВИ", в чем по вашему выражено наше непонимание сути диаграммы ВИ.
Мда, смешались в кучу кони RUP, люди Коберн... В общем, если смотреть с т.з. РУПа, то я рассматриваю (надесь, и все) этот пример, как модель Системных ВИ. В понятие МОДЕЛЬ ВИ я включаю:
Use Case Model, which consists of:
* Use case diagram: A visual representation of system users (actors) and the services they request from the system.
* Actor definitions: A textual description of the requestors of services provided by your system, and services provided to your system.
* Use case descriptions: Textual descriptions of the major services provided by the system under discussion.
http://www.ibm.com/developerworks/rational/library/5383.html
Можно еще тут почитать:
http://rup.hops-fp6.org/process/modguide/md_ucmod.htm
У Пассажира нет цели засунуть деньги я с вами согласен, но ведь у "Автомата" (утрирую, конечно у его владельца) - есть бизнес-цель - "получить деньги взамен билета". Данная цель неявна и не отражена на представленных автором диаграммах.
Где Вы такого актера нашли на исходной Д: владелец?
Ранее я предложил свой вариант диаграммы ВИ демонстрирующую точку зрения на проектируемую систему Автомат http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642 (http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642)
1. Нарисуйте, будет понятнее
2. Еще раз повторюсь, что данный простой пример не показательный, можно хоть до функций детализировать... Но при проектировании БОЛЬШОЙ системы, данные ВИ включения и расширения на Д лишние.
-
Под понятием "бизнеса" в этом случая я понимаю "деятельность направленную на удовлетворение потребностей".
В данном примере у потребителя есть потребность "приобрести билет" (вызвана требованием иметь билет для поездки куда либо), у продавца потребность - "получить деньги" (за саму ли услуги продажи билета или за услугу для которой приобретается билет не важно).
Это и есть в моем понимании "бизнес ВИ". В предложенном БВИ будет только два ВИ.
Эти потребности заинтересованных сторон предложено реализовать через систему "автомат по продаже билетов".
Автор в одном из сообщений упомянул что точка зрения на диаграмму ВИ должна быть "Мне хочется как можно проще, и максимально понятно тому, кто будет разрабатывать систему."
Тому кто будет проектировать автомат не так важен бизнес ВИ. Ему нужно понимание какие функции и для кого выполняет система, какие в связи с этим есть ограничения и исключения.
Совершенно точно, что у Вас разные представления как с теоретиками бизнеса, так и с RUP, что такое бизнес (и бизнес процесс).
Но если Вы можете точно сформулировать, что Вы под этим понимаете, это делает Вам честь!
Только другие могут Вас не понять!
-
Какая жаркая дискуссия! Но, надеюсь, полезная. По крайней мере, выделяются две точки зрения, вокруг которых и идет спор.
Кроме того, мы видим разногласия по поводу определения бизнес. Я бы предложил уйти от него вообще. Будем говорить о предметном взгляде и системном.
Когда я начинал тему, у меня не то, что было сомнение (1 диаграмма получилась у меня инстинктивно, исходя из массы тех знаний, что успели накопиться в голове), просто я подумал (и мысль впоследствии подтвердилась) а как смотрит на это тот, кто делает, реализует дальше. Полезна ли ему эта диаграмма?
Пока я вижу ответ - сама по себе бесполезна. Описание или диаграмма деятельности скорее всего будет нести больше информации. Но... это только в этом конкретном случае.
Кроме того, если совокупность ВИ должна определить назначение системы, то может ВИ следует сформулировать как: "Выдать проездной билет за внесенную оплату" , а не "Приобрести проездной билет"?
Кстати мысль(высказанная DinamoYA) о том, что одна и таже ДВИ, вдруг моделирует классы разных систем и никак этот факт не отражает вполне интересна и не раз приходила мне в голову. Правда, тут на форуме есть пояснение, что модель использования не ограничивается ДВИ
-
Диаграмма UC не бесполезная. Она является неотъемлемой частью UCM, и предназначена только для того, чтобы указать и структурировать цели пользователей (actor), которые должна выполнять система.
Краткое описание UC - это требование к системе выполнить цель. Когда UC много - это функциональные требования верхнего уровня.
Описание последовательности взаимодействий - набор детализирующих требований к системе в терминах обязанности системы уметь реализовать эти взаимодействия.
Нужно и полезно все!!!
Коберн диаграмм не рисует вообще, но суть та же (за исключением расширения на пять уровней и черный (объектный подход) и прозрачный ящик)
-
1. Нарисуйте, будет понятнее
А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51
-
А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51
Прекрасная диаграмма, если абстрактные UC архитектурно существенные и их планируется разрабатывать каждый по отдельности.
Иначе это лишняя работа. Диаграмма не описывают порядок выполнения основного UC (по этой диаграмме тоже нельзя сделать систему). Все равно нужно делать описание в текстовом виде или с использованием диаграммы деятельности (или другой, позволяющей описывать процессы).
Ну и второе: это тот случай, когда авторам не хватило нотаций UML, и они ввели собственный (не UML) стереотип (или ключевое слово, не знаю, они изображаются одинаково). Это допустимо в рамках группы разработчиков, но посторонние не поймут.
Это как раз то, о чем пишет Коберн, обосновывая (на мой взгляд, ошибочно) бесполезность диаграмм UC. И приводит похожие примеры.
-
А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51
Почему же конкуренты - это наши друзья )
Ваша диаграмма тоже имеет право на жизнь в данном конкретном небольшом примере.
ИМХО дальше не имеет смысла обсуждать, поэтому откланиваюсь ...
-
Леонид, а что такое архитектурно существенные варианты использования? Каков критерий их отбора, отображения?
-
Из данного UC "Приобрести проездной билет" - не следует что автомат должен: принимать оплату (монетами), возвращать оплату, выдавать билет, выдавать сдачу.
Например я приобретаю билет через интернет и выполняю электронную регистрацию. Оплата безналичная, билет в бумажном виде не выдается, оплата может быть безналичной и т.д.
У автора задача спроектировать (сконструировать) устройство автомат для продажи билетов, исходя из дополнительного описания система должна выполнять такие функции как: приемка оплаты, выдача билета, выдача сдачи.
Просьба не отождествлять функции системы и варианты использования, это разные вещи, с несколько разным назначением. Функции системы, это взгляд с точки зрения системы "на мир ее окружающий" :-), т.е. это в т.ч. то, что система экспонирует наружу. Юзкейс - это именованная цель пользователя по отношению к системе (бизнес- или технической). При этом функции легко декомпозируемы, юзкейсы - только в пределах отношений между уровнями описаний (т.е. не декомпозируемы). Очевидно, в процессе выполнения сценариев юзкейса будут использованы те или иные функции. Более того, на основании юзкейсов могут быть определены сами функции системы (подход сверху-вниз). Как в прочем и по набору функций можно придумать юзкейсы, но нужно иметь определенную фантазию :-) (подход снизу-вверх).
Так же очевидно, что для проектирования системы одних юзкейсов не достаточно, если под проектированием мы понимаем, как минимум blueprint.
По-прежнему продолжаете считать мой ответ, ответом Шерлока Холмса?
-
Ну, это термин из RUP-а. Изначально использовался в планировании.
Для снижения рисков производится сортировка UC по их потенциальному влиянию на архитектуру продукта.
Т.к. в RUP фактически каждый UC предполагает выпуск (внутренней или внешней версии), производится анализ степени изменения архитектуры от выпуска к выпуску. Незначительность изменения архитектуры сигнализирует о достижении стабильной архитектуры (веха Архитектура жизненного цикла).
Основной элемент планирования в RUP - это UC. Отсюда признак (и мера) существенности: планируется отдельно или нет.
Ведь когда мы описываем UC, например, в диаграмме деятельности, мы, для упрощения восприятия, часто используем структурные действия, например, Call Bechavior, описания которых приводим на отдельных диаграммах. Т.е. мы выполняем некоторую декомпозицию описания исходного UC. Вот признаками существенности этих частей является факт полезности выделения их в абстрактные UC, которые потом включаются в план разработки.
Например, некоторая часть процесса выполняется по условию. В большинстве случаев это условие не выполняется. Если все дело только в том, чтобы какому-то элементу присвоить "а" или "в", мы особо не задумываемся, делаем сразу. Но если по условию выполняется серьезный процесс, и его реализация задержит выпуск системы, которая может ограниченно функционировать и без этой ветки, соответствующий фрагмент выделяется в абстрактный UCE. Потому, что он архитектурно существенный.
Ну, то же самое с UCI: есть смысл выделять, или проще в каждом UC этот несущественный фрагмент повторить.
UCI ставятся в план перед первым использующим основным UC, UCE - после включающего UC.
-
Юра! Это, наверное, очень строгие определения.
Но у меня вопрос: функции системы и функциональные требования к системе - это сильно разное?
Сам знаешь, у меня системноаналитический ум, и я не сразу все схватываю.
-
Юра, прости, а как понимать, что UC не декомпозируемы?
UC как описание процесса? как формулировка функционального требования? как "название"?
Но:
- любой сложный процесс можно декомпозировать в подпроцессы, параллельные и последовательные
- соответственно, требования к подпроцессам - это части требования UC
Наверное, ты, как всегда, прав. Но что ты имеешь ввиду?
И чем система проявляет себя в среде, как не интерфейсами (те же UC), если не вспоминать нефункциональные требования, например, цвет корпуса компьютера?
-
Юра! Это, наверное, очень строгие определения.
Но у меня вопрос: функции системы и функциональные требования к системе - это сильно разное?
Сам знаешь, у меня системноаналитический ум, и я не сразу все схватываю.
Леонид Борисович, учитывая что вопрос отношений функций и юзкейсов всплывает периодически, я в свое время написал заметку в своем блоге http://yurybuluy.blogspot.com/2010/12/use-cases.html. Позволю себе адресовать к ней в качестве ответа на вопрос, и конечно же рад буду услышать ваше мнение.
-
Юра, прости, а как понимать, что UC не декомпозируемы?
UC как описание процесса? как формулировка функционального требования? как "название"?
Но:
- любой сложный процесс можно декомпозировать в подпроцессы, параллельные и последовательные
- соответственно, требования к подпроцессам - это части требования UC
Наверное, ты, как всегда, прав. Но что ты имеешь ввиду?
И чем система проявляет себя в среде, как не интерфейсами (те же UC), если не вспоминать нефункциональные требования, например, цвет корпуса компьютера?
Декомпозиция - как правило это иерархия. Говоря о функциях, можно построить дерево функций, где наверху будет некая "большая функция", уровнем ниже - ее детализация. Юзкейсы не имеют как таковой строгой иерархии, иначе они бы выродились в функции. В то же время, если принимать "классификацию" Коберна - он определяет уровни целей юзкейсов, и соответственно можно говорить о контексте - например, юзкейсы уровня моря МОГУТ (но не обязательно должны) выполняются в контексте юзкейсов уровня змея/облака. Невозможность построения иерархии юзкейсов вполне может быть трактовано, как их недекомпозируемость.
-
Декомпозиция - как правило это иерархия. Говоря о функциях, можно построить дерево функций, где наверху будет некая "большая функция", уровнем ниже - ее детализация. Юзкейсы не имеют как таковой строгой иерархии, иначе они бы выродились в функции. В то же время, если принимать "классификацию" Коберна - он определяет уровни целей юзкейсов, и соответственно можно говорить о контексте - например, юзкейсы уровня моря МОГУТ (но не обязательно должны) выполняются в контексте юзкейсов уровня змея/облака. Невозможность построения иерархии юзкейсов вполне может быть трактовано, как их недекомпозируемость.
Спасибо за ответ, но он меня не удовлетворил.
1. Декомпозиция не всегда иерархия (элемент этой декомпозиции м.б элементом многоразового использования, т.е. элементом и другой декомпозиции).
2. Декомпозиция допускает, что элементы дочернего уровня представляют собой нечто иное, чем их агрегат (в нашем случае элемент декомпозиции UC вовсе не обязан быть UC).
3. UC (описание взаимодействий для достижения цели) декомпозируется в набор описаний отдельных действий по достижению этой цели.
4. UC - это описание функции (но не любой, а отвечающей некоторым требованиям, сформулировнным в определении термина UC).
5. UC не может выродится в функцию, не являющуюся UC, т.к. в этом случае не будет соответствовать определению UC.
-
И вопрос, на который я ответа не получил:
И чем система проявляет себя в среде, как не интерфейсами (те же UC), если не вспоминать нефункциональные требования, например, цвет корпуса компьютера?
Спасибо.
-
А вообще-то, Юра, я сожалею, что завел эту бодягу.
В конце концов, на практике мы совершенно одинаково понимаем, как найти UC, и для чего его можно использовать.
И опишем, наверное, похоже.
И какая, суть, разница, декомпозиция это или детализация, является прецедент описанием функции, или нет.
Нам их "рисовать" правильно нужно!.
И это главное.
-
Спасибо за ответ, но он меня не удовлетворил.
1. Декомпозиция не всегда иерархия (элемент этой декомпозиции м.б элементом многоразового использования, т.е. элементом и другой декомпозиции).
Ну говоря вообще ... сам факт использование одного и того же элемента в разных классификациях, не влияет на его место в конкретной классификации (влиять может положение в той или иной классификации). Функциональная декомпозиция как раз иерархична. И мы используя ее как аналогию, обсуждаем возможность построения подобной декмопозиции для юзкейсов.
2. Декомпозиция допускает, что элементы дочернего уровня представляют собой нечто иное, чем их агрегат (в нашем случае элемент декомпозиции UC вовсе не обязан быть UC).
Речь шла именно о декомпозиции юзкейсов на юзкейсы, детализирующие верхнеуровневый (по аналогии с функциями). Посему говоря, что декомпозируя юзкейс мы можем получить нечто иное - не опровергает мой тезис :-).
3. UC (описание взаимодействий для достижения цели) декомпозируется в набор описаний отдельных действий по достижению этой цели.
Отдельные действия - это не юзкейсы. Хотя, при желании, можно найти такие юзкейсы уровня змея (по Коберну), ряд шагов которых могут быть отдельными юзкейсами уровня моря. Например, это может быть при описании процесса рассмотрения выдачи кредита в банке, но с некоторой натяжкой и допущениями.
4. UC - это описание функции (но не любой, а отвечающей некоторым требованиям, сформулировнным в определении термина UC).
5. UC не может выродится в функцию, не являющуюся UC, т.к. в этом случае не будет соответствовать определению UC.
Я предпочитаю это формулировать иначе - скорее это некоторые функции могут соответствовать юзкейсам, а не юзкейс - функцимя :-).
-
И вопрос, на который я ответа не получил:
Интерфейсами системы скорее будут функции, а не UC в целом. Т.к. набор функций системы сущность менее зависимая от контекста использования системы, чем UC. Пример - текстовый редактор Word. При его множестве функций, для набора и распечатки текста "Hello world" мы не будем задействовать все его функции. А UC будет существовать - получить распечатку "Hello world". UC можно признать интерфейсом, только вводя понятие контекста использования - т.е. при определенном контексте использования это будет единственным интерфейсом.
-
А вообще-то, Юра, я сожалею, что завел эту бодягу.
В конце концов, на практике мы совершенно одинаково понимаем, как найти UC, и для чего его можно использовать.
И опишем, наверное, похоже.
И какая, суть, разница, декомпозиция это или детализация, является прецедент описанием функции, или нет.
Нам их "рисовать" правильно нужно!.
И это главное.
Ну почему ... подискутировать на "общефилософские" вопросы иногда очень интересно :-). А то сидишь в рутине конкретных проектов ... заказчику же это рассказывать не будешь :-).
-
Просьба не отождествлять функции системы и варианты использования, это разные вещи, с несколько разным назначением. Функции системы, это взгляд с точки зрения системы "на мир ее окружающий" :-), т.е. это в т.ч. то, что система экспонирует наружу. Юзкейс - это именованная цель пользователя по отношению к системе (бизнес- или технической). При этом функции легко декомпозируемы, юзкейсы - только в пределах отношений между уровнями описаний (т.е. не декомпозируемы). Очевидно, в процессе выполнения сценариев юзкейса будут использованы те или иные функции. Более того, на основании юзкейсов могут быть определены сами функции системы (подход сверху-вниз). Как в прочем и по набору функций можно придумать юзкейсы, но нужно иметь определенную фантазию :-) (подход снизу-вверх).
Так же очевидно, что для проектирования системы одних юзкейсов не достаточно, если под проектированием мы понимаем, как минимум blueprint.
По-прежнему продолжаете считать мой ответ, ответом Шерлока Холмса?
Ну, хорошо! Как хочешь.
Ты считаешь, что функции и UC разные вещи?
Мне непонятно, как с помощью функций система смотрит на мир и что сиситема экспонирует наружу (в ООП), кроме своих интерфейсов, которые, на начальной стадии разработки определяются именно UC!
Но то, что UC - это именованная цель пользователя по отношению к системе, на мой взгляд, не соответствует пониманию "отцов-основателей".
1. Можно говорить об отношении пользователя к использованию системы, но это еще не все.
2. Есть рекомендации именовать UC в терминах названия цели пользователя. Но даже эллипс с названием - это еще не цель. UC - это описание последовательности взаимодействий пользователя с системой для достижения цели. И в этом смысле UC ведет себя в точности как описание внешнего поведения функции.
3. Функция и UC, конечно, разное.
- Функция в ПО - это некоторый выделенный фрагмент, который можно выполнить. Где-то в документации есть описание (назначение, указания на предусловия, правила запуска, результат и т.п.).
- UC выполнить невозможно по определению: это описание (у Коберна - соглашение ...). Его сначала нужно реализовать: проанализировать, спроектировать, закодировать, интегрировать в систему. И с этой (я позволю себе дать условное название) реализацией UC поступают точно так же, как с функцией
4. Если отождествлять описание и реализацию (это разное, но допустим в этом контексте), то функция - это понятие более широкое, чем UC: любой UC - это функция, но не любая функция - это UC.
5. ООП предполагает, что все функциональные требования к системе выражаются с использованием UC. О каких других функциях системы ты говоришь? И как они выражаются, определяются?
-
Ну, хорошо! Как хочешь.
Ты считаешь, что функции и UC разные вещи?
Мне непонятно, как с помощью функций система смотрит на мир и что сиситема экспонирует наружу (в ООП), кроме своих интерфейсов, которые, на начальной стадии разработки определяются именно UC!
Но то, что UC - это именованная цель пользователя по отношению к системе, на мой взгляд, не соответствует пониманию "отцов-основателей".
Не нужно забывать, что у "отцов-основателей" стояла задача, кроме всего прочего, сделать коммерческий продукт, который был назван RUP :-). Кроме этого -вопрос. Сколько юзкейсов вы в среднем выделяете в более-менее развитой с т.з. взаимодействия с пользователем системе?
1. Можно говорить об отношении пользователя к использованию системы, но это еще не все.
Речь идет о контексте использования?
2. Есть рекомендации именовать UC в терминах названия цели пользователя. Но даже эллипс с названием - это еще не цель. UC - это описание последовательности взаимодействий пользователя с системой для достижения цели. И в этом смысле UC ведет себя в точности как описание внешнего поведения функции.
Я бы сказал, что в данном случае скорее у системы может быть высокоуровневая функция, которая тождественна юзкейсу.
3. Функция и UC, конечно, разное.
- Функция в ПО - это некоторый выделенный фрагмент, который можно выполнить. Где-то в документации есть описание (назначение, указания на предусловия, правила запуска, результат и т.п.).
- UC выполнить невозможно по определению: это описание (у Коберна - соглашение ...). Его сначала нужно реализовать: проанализировать, спроектировать, закодировать, интегрировать в систему. И с этой (я позволю себе дать условное название) реализацией UC поступают точно так же, как с функцией
Мы не говорим про реализацию, а следовательно о функциях можно вести речь только с т.з. RDM. Поэтому говорить об исполнении функций на этом уровне не имеет смысла.
4. Если отождествлять описание и реализацию (это разное, но допустим в этом контексте), то функция - это понятие более широкое, чем UC: любой UC - это функция, но не любая функция - это UC.
Ну я бы все-таки не так категорично определял. Хотя-бы потому, что UC вполне может содержать ряд шагов (действий) пользователя, которые он не делает при помощи system under consideration, но они необходимы для достижения цели пользователя. UC при этом будет существовать, т.к. пользователь имеет определенную цель, но такой функции в системе может попросту не быть! Пример - целью пользователя является принятие решения о выдаче или не выдаче кредита физлицу. Ни одна банковская система не имеет такой функции (решение будет принимать ЧЕЛОВЕК)!!! Но UC такой вполне может существовать :-).
5. ООП предполагает, что все функциональные требования к системе выражаются с использованием UC. О каких других функциях системы ты говоришь? И как они выражаются, определяются?
Это не ООП предполагает, а один из рекомендованных RUP способов. Я бы сказал так, что ООП имеет в своем арсенале множество методологий, фреймворков и подходов, и RUP всего лишь один из них.
Не случайно RUP есть еще один артефакт-документ Supplementary Specification, который как раз был создан для инкапсулирования (внимание) функциональных и нефункциональных требований, которые не были охвачены юзкейсами!
-
Юра!
Ты "замыливаешь" ответы на вполне однозначные вопросы.
Ты же аналитик, а не дипломат.
Объясни, пожалуйста, как с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.
Потом, если хочешь, продолжим дискуссию.
Спасибо.
-
Юра!
Ты "замыливаешь" ответы на вполне однозначные вопросы.
Ты же аналитик, а не дипломат.
Объясни, пожалуйста, как с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.
Потом, если хочешь, продолжим дискуссию.
Спасибо.
Мне показалось, что я достаточно ясно сформулировал ... попробую еще раз, с конкретными примерами... итак почему UC не самый удачный вариант описания ВСЕХ интерфейсов системы.
1. Юзкейсы - контекстно зависимая вещь. Я приводил пример текстового редактора Word. Функций у него множество, а мы можем использовать лишь некоторые из них для решения конкретной задачи - эта задача может быть описана одним юзкейсом. Например, моя цель пользователя - создать пачку объявлений для расклейки. При этом, я никогда не буду использовать для этого функции Word слияния, внедрения OLE объектов и т.п. Но это не означает, что этих интерфейсов у Word нет :-). Их нет только в контексте нашей конкретной задачи. Следовательно придется вводить еще одно понятие - контекста использования.
2. Юзкейсы могут включать действия пользователя, которые он не выполняет в системе (или может выполнять в другой системе). Т.е. эти действия никак не связаны с функциональностью конкретной системы, которую мы рассматриваем. Пример: У меня как у банковского клерка есть цель - принять решение выдавать кредит или нет. У нас есть система, которая позволяет на основании входных данных дать оценку степени риска невозврата кредита и в ней же будет регистрироваться решение. Но решение принимает в конечном итоге клерк - выдать кредит или нет. Решение может зависеть от многих факторов - желании получить премию, коньюктуры рынка (борьба за каждого клиента) и т.п. ... Имеем, моя целостная и неделимая цель как пользователя - принять решение о выдаче кредита и зафиксировать это решение в системе. Имеем юзкейс - "Принять решение о кредите". Есть ли такая функция у данной системы? Ответ очевиден - НЕТ .... Только не нужно говорить, что тут напрашиваются два юзкейса - не напрашиваются как раз ни разу :-).
На этот раз я достаточно четко сформулировал ответ?
-
Ну на вопрос ты не ответил.
Ты сформулировал непонятную для меня фразу. Думаю, не только я не понял. Расшифруй, если можешь, свои слова.
Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.
Каждое слово по отдельности у меня сомнений не вызывает. Но что фраза означает - я не понимаю.
-
А стоит ли противопоставлять функцию и UC?
Если, конечно, принять как аксиому, что функция=алгоритм, тогда вопрос уже обсуждался
Вариант использования или Алгоритм? (http://www.uml2.ru/forum/index.php?topic=160.msg7215#msg7215)
если нет, то следует ли устраивать такие идеологические споры? Не следует ли дать точное онтологическое определение понятию функция, вариант использования, определить сходные и отличные черты и договорится ...
-
Не следует ли дать точное отнологическое определение понятию функция....
угу, дай...
-
Эдуард! Где тут идеология?
На нашем форуме это часто бывает: увидел аналитик, что другой аналитик в написании иностранного слова ошибся или actor-а "субъектом" назвал (м.п. - из официального перевода!) и святое негодование!
Каюсь. Увидел фразу "непонятную".
Могу обсуждать и UC для Word, и UC принятия решения, и отстоять свою позицию без "замыливания", конкретно.
А сейчас, во второй раз, предлагаю эту бодягу прекратить. И если вопрос в выяснении истины, то предлагаю обсудить это в личной переписке.
-
Эдуард! Где тут идеология?
Каюсь. Увидел фразу "непонятную".
Леонид, а если я на вашей стороне?
-
Функция (работа) (лат. functio — совершение, исполнение) — деятельность, роль объекта в рамках некоторой системы, работа производимая органом, организмом; роль, значение чего-либо.
В инженерном искусстве и в области психологии, выражаясь обычным языком, функция обозначает принадлежность к чему-либо, что используется/применяется для устремлений, решения задач, намерений, достижения цели. Фактически это может быть реализовано используя различные физические процессы и один процесс может нести множество функций (Adam Maria Gadomski, 1987). Например, основная функция часов, показывать время, может быть реализована различными физическими процессами, такими как атомный, электронный или механический процесс.
Во многих случаях это понятие может быть использовано в переносном смысле, например, отнесением цели к процессам природного естественного отбора. В физике, функции в техническом смысле не существует, потому что понятие цели не определено.
Функция — математическое понятие, отражающее связь между элементами множеств. Более точно, это «закон», по которому каждому элементу одного множества (называемому областью определения) ставится в соответствие некоторый элемент другого множества (называемого областью значений).
Функциона́льность (обычно в технике и программном обеспечении) — набор возможностей (функций), которые предоставляет данная система или устройство.
Функция (лат. functio — исполнение) — обязанность, круг деятельности
В литературоведении фу́нкция — это действие персонажа как актанта. Синоним слова акция.
Фу́нкция — в программировании — это поименованная часть программы, которая может вызываться из других частей программы столько раз, сколько необходимо. Функция, в отличие от процедуры, обязательно возвращает значение.
О каком из перечисленных типов определений мы рассуждаем?
-
Эдуард!
Я действительно сожалею, что сорвался.
Эта дискуссия не может иметь положительного результата.
Ну какая, в сущности, разница для практиков, можно ли UC называть подкатегорией функции (не функции в программировании, а в широком смысле).
Мы с Юрием, в большинстве случаев, одинаково определяем UC, понимаем, зачем использовать абстрактные UC, и что требования бывают функциональные и не функциональные и т.д. Вот это имеет смысл!
Или ты о примерах с Word и принятия решений?
-
Ну ... я уже высказал свою точку зрения - я не думаю, что дискуссия бесполезна. Очень даже интересно пообсуждать ...
-
Ну на вопрос ты не ответил.
Ты сформулировал непонятную для меня фразу. Думаю, не только я не понял. Расшифруй, если можешь, свои слова.
Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.
Каждое слово по отдельности у меня сомнений не вызывает. Но что фраза означает - я не понимаю.
Ты победил!
Мне добавить нечего.
-
Word, это многофункциональный инструмент, который наверное невозможно описать в категориях UCs.
Можно ясно определить некий набор UCs по некоторому контектсу задач, в которых Word будет использоваться как инструмент, но какое отношение это имеет к обсуждаемому вопросу??? Мы то говорим о специфицировании заданий на разработку, а не о способе передачи информации для программно-насыщенных систем в целом.
Аналогично и пример с принятием решения, опять выпадает из канвы рассуждения., потому как назначении системы не принять решение, а помочь его принять и скорее будет выливаться: в Оценить действие такого-то фактора на коньюктуру этого, т.е. цель моего использования инструмента в принятии решении, но цель моего конкретного использования инструмента Оценка влияния фактора. Что в данном случае будет функциональным требованием?
Система должна помочь пользователю принять решение? И как это измерить?
Или
Система должна помочь оценить влияние фактора методом стохастически сходящихся детерменистки-расходящикся векторносвернутых скаляров?
-
По второму вопросу целиком согласен: цель пользователя - получить информацию для принятия решения. Но на диаграмме вполне можно нарисовать эллипс с надписью "Принятие решения". Ведь UC - это не эллипс, а описание последовательности взаимодействий. Пренятие решения - вне границ используемой системы. Точно так же, как решить, нажать OK или Cancel!
По поводу Word, если интересует мое мнение, чуть позже. Мне сейчас отойти надо.
-
Простите, попросили лампочку вывернуть!
По второму вопросу целиком согласен: цель пользователя - получить информацию для принятия решения. Но на диаграмме вполне можно нарисовать эллипс с надписью "Принятие решения". Ведь UC - это не эллипс, а описание последовательности взаимодействий. Пренятие решения - вне границ используемой системы. Точно так же, как решить, нажать OK или Cancel!
По поводу Word, если интересует мое мнение, чуть позже. Мне сейчас отойти надо.
Возвращаясь к предыдущему: цель пользователя - получить информацию для принятия решения и/или зафиксировать решение.
-
Относительно первого - Word.
Ну почему же, Эдуард. Требования к любому инструменту, реализующему взаимодействия, можно описать с помощью UC.
И Юрий правильно определил цель пользователя. М.б., я другими словами, но содержание то же, что у Юры: создание, чтение и редактирование текстового документа. Внутри эллипса вполне допустимо написать: "Работа с документом". Единственная цель. Один UC уровня пользователя.
Затем можно написать огромное текстовое описание пользовательского UC по Коберну или нарисовать огромную (по площади и глубине) диаграмму деятельности со множеством вложений.
Мне непонятно почему, но многие забывают очень важную роль UC как объекта планирования в итерационном инкрементном процессе разработки.
Если об этом вспомнить, то проясняется необходимость декомпозиции (ой! ...выделения...) абстрактных UC, в нашей ситуации, в основном это UCE.
Я не знаю, использовал ли Microsoft термины UC, UCI, UCE. Но есть вещи, которые выполняются одинаково или почти одинаково, независимо от того, как их называют. Думаю, Word делали не один год, определяли цели, рисовали какие-то схемы взаимодействий, определяли спецификации (процессов, функций, UC - все равно, как они их называли!), планировали, для реализации функциональности создавали или использовали существующие классы и компоненты.
Ну, не нравится кому-то называть это UC. Ради Бога! Это как материя, существует независимо от нашего сознания.
-
Например, основная функция часов, показывать время, может быть реализована различными физическими процессами, такими как атомный, электронный или механический процесс.
Сильно! Электронный способ показывания времени ... понимаю, не говоря о механическом, даже двоичный могу понять (есть и такие часы - для программистов). Но АТОМНЫЙ??? может это все-таки способ функционирования механизма, обеспечивающего нужную точность хода, а не способ показывания времени?
по аналогии, т.н. кварцевые (а на деле, считай, электрические, ибо внутри батарейка и кварцевый генератор, который от нее питается) часы и механические с точки зрения показывания времени могут иметь одинаковый интерфейс (то бишь со стрелками и циферблатом). или вот механические заводные и автоматические, внешне тоже ну оччень одинаковые, а внутри (кое в чем) разные. опять же внутреннее устройство т.н. кварцевых и электронных часов может быть практически совершенно одинаковым, но средства показывания времени реализованы по-разному: один на ЖК, другой на стрелках и традиционном или не очень циферблате. или вот у меня часы имеют и то, и другое.
Функциона́льность (обычно в технике и программном обеспечении) — набор возможностей (функций), которые предоставляет данная система или устройство.
вот про это. фактически, что можно с помощью программы, системы или устройства сделать (или получить).
теперь только термин "набор возможностей" или просто "возможность" осталось определить :о)))
-
Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.
а если рассмотреть в качестве системы, например, телевизор (или какой-нить другой прибор)? разве не будут сняты эти вопросы? (вспомнился фрагмент из какого-то фильма про каменскую, где на кофеварке был приклеен стикер с надписью "нажми на кнопку будет кофе")
потом по аналогии можно рассмотреть софтовый телевизор и сравнить получившиеся результаты. тоже научный метод познания.
-
а если рассмотреть в качестве системы, например, телевизор (или какой-нить другой прибор)? разве не будут сняты эти вопросы? (вспомнился фрагмент из какого-то фильма про каменскую, где на кофеварке был приклеен стикер с надписью "нажми на кнопку будет кофе")
потом по аналогии можно рассмотреть софтовый телевизор и сравнить получившиеся результаты. тоже научный метод познания.
С помощью UC можно описать, как варить кофе, а с помощью SysML кофеварку спроектировать (без конструктивных чертежей, конечно, но интерфейсы между конструктивными элементами показываются).
Процесс, конечно же, начинается с определения цели, UC...
-
Сильно! Электронный способ показывания времени ... понимаю, не говоря о механическом, даже двоичный могу понять (есть и такие часы - для программистов). Но АТОМНЫЙ??? может это все-таки способ функционирования механизма, обеспечивающего нужную точность хода, а не способ показывания времени?
ай-яй-яй, господин аналитик. Так проколоться
основная функция часов, показывать время, может быть реализована различными физическими процессами, такими как атомный, электронный или механический процесс.
Ни о каких механизмах речи нет, есть речь о процессе, с помощью которого реализуется функция.
Тем не менее - это не мои слова.
Ну а по поводу интерфейса http://ru.wikipedia.org/wiki/Интерфейс
-
основная функция часов, показывать время, может быть реализована различными физическими процессами, такими как атомный, электронный или механический процесс.
ну да, ну да...
так как все-таки атомный процесс показывает время, хотел бы я услышать. про "говорящие часы" в Москве все знают, как с этим обстоит в других городах - не в курсе.
какой бы процесс, механизм или еще что-либо подобное не был использован в часах, он всего лишь "считает время" параллельно ходу самого времени. а показывает время какой-либо индикатор - либо стрелочный (с циферблатом), либо жк, лампочный, да какой угодно.
так что наезд мимо кассы, однако...
-
Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.
С помощью UC можно описать... а с помощью SysML спроектировать ...
Это все понятно. на то UC и нужен, чтобы описывать. Но описывает UC не столько функции, а способ взаимодействия с системой - можно было бы даже сказать процесс взаимодействия (правда, тут я остаюсь на своей позиции), необходимый для решения конкретной задачи пользователя при участии системы, например: приобретение того же билета с помощью автомата.
Поэтому я и предложил обсудить функции и интерфейсы на примере телевизора или, на худой конец, кофеварки. Для того, чтобы пойти "от частного к общему" дальнейшее направление было - обсудить Ф и И в аналогичном по назначению программном обеспечении. Возможно тогда будет ясно... отличие функций, интерфейсов и UC.
Процесс, конечно же, начинается с определения цели, UC...
согласен, хотя вообще-то не о том речь-то...
-
Относительно первого - Word.
...
Я не знаю, использовал ли Microsoft термины UC, UCI, UCE. Но есть вещи, которые выполняются одинаково или почти одинаково, независимо от того, как их называют. Думаю, Word делали не один год, определяли цели, рисовали какие-то схемы взаимодействий, определяли спецификации (процессов, функций, UC - все равно, как они их называли!), планировали, для реализации функциональности создавали или использовали существующие классы и компоненты.
Скорее нет, чем да :о))) потому что сколько бы времени (пока!) ни прошло с момента его создания, какие бы компоненты и классы ни насоздавали и не использовали, но почему-то форматирование таблицы в ворде делается принципиально иначе, чем в экселе. видимо (точнее, так и есть), там другая команда над ним работала. и были (а может и нет) у нее свои UC ... или что они там используют.
-
Word, это многофункциональный инструмент, который наверное невозможно описать в категориях UCs.
Можно ясно определить некий набор UCs по некоторому контектсу задач, в которых Word будет использоваться как инструмент, но какое отношение это имеет к обсуждаемому вопросу??? Мы то говорим о специфицировании заданий на разработку, а не о способе передачи информации для программно-насыщенных систем в целом.
Аналогично и пример с принятием решения, опять выпадает из канвы рассуждения., потому как назначении системы не принять решение, а помочь его принять и скорее будет выливаться: в Оценить действие такого-то фактора на коньюктуру этого, т.е. цель моего использования инструмента в принятии решении, но цель моего конкретного использования инструмента Оценка влияния фактора. Что в данном случае будет функциональным требованием?
Система должна помочь пользователю принять решение? И как это измерить?
Или
Система должна помочь оценить влияние фактора методом стохастически сходящихся детерменистки-расходящикся векторносвернутых скаляров?
Эд, твоя цель как пользователя - принять решение о кредите и внести свое решение в систему ... система тебе для принятия решения дает данные ... Какой будет твоя цель как пользователя?
-
Ты победил!
Мне добавить нечего.
Почему функциями смотрит на мир, а не юзкейсами - потому, что функция, это некоторое свойство системы, которое "принадлежит" ей. А юзкейс, содержит еще и действия пользователя, которые как вы верно заметили, могут находиться за границами этой системы (следовательно не "принадлежат" системе). И если утверждать, что юзкейс - это интерфейс системы, значит тогда следует признать, что Эктор со своими действиями входит в систему. Что противоречит определению :-). Теперь более четко ответил на вопрос?
-
Эд, твоя цель как пользователя - принять решение о кредите и внести свое решение в систему ... система тебе для принятия решения дает данные ... Какой будет твоя цель как пользователя?
Думаю моя конечная цель принять решение, однако цель использования системы - Получить данные для принятия решения и Зафиксировать это решение.
Да в начальном моем сообщении, все возможно очевидно.
(http://www.uml2.ru/forum/index.php?action=dlattach;topic=3729.0;attach=3372;image)
и
(http://www.uml2.ru/forum/index.php?action=dlattach;topic=3729.0;attach=3379;image)
против
(http://www.uml2.ru/forum/index.php?action=dlattach;topic=3729.0;attach=3374;image)
Хотя я в первых двух рисунках потерял возможность вернуть деньги, но на самом деле как раз первая мысля была правильная, нельзя вернуть деньги - едешь - плати :)
-
Почему функциями смотрит на мир, а не юзкейсами - потому, что функция, это некоторое свойство системы, которое "принадлежит" ей. А юзкейс, содержит еще и действия пользователя, которые как вы верно заметили, могут находиться за границами этой системы (следовательно не "принадлежат" системе). И если утверждать, что юзкейс - это интерфейс системы, значит тогда следует признать, что Эктор со своими действиями входит в систему. Что противоречит определению :-). Теперь более четко ответил на вопрос?
Какой функцией - читай интерфейсом, молоток смотрит на мир? (имхо можно ли вообще использовать такое сочетание?)
-
Почему функциями смотрит на мир, а не юзкейсами - потому, что функция, это некоторое свойство системы, которое "принадлежит" ей. А юзкейс, содержит еще и действия пользователя, которые как вы верно заметили, могут находиться за границами этой системы (следовательно не "принадлежат" системе). И если утверждать, что юзкейс - это интерфейс системы, значит тогда следует признать, что Эктор со своими действиями входит в систему. Что противоречит определению :-). Теперь более четко ответил на вопрос?
Простите, но Actor взаимодействует с системой через UC.
Или ты что-то иное имеешь ввиду, когда требуешь рисовать UC на четырехугольнике системы и рисуешь ассоциацию между Actor (вне системы) и UC (внутри системы).
И почему это, если пользователь взаимодействует с системой через интерфейс, он окажется внутри системы? Где тебя сейчас искать? В зазеркалье?
Загибаешь!
UC не содержит действия пользователя, а описывает взаимодействия пользователя с системой.
А вот система полностью реализует UC (UC Realization), предоставляя пользователю интерфейс, соответствующий описанию UC.
Т.о., UC - это свойство только системы! Значит, это функция? Правда?
А какой пример функции, который не является реализацией UC?
-
Какой функцией - читай интерфейсом, молоток смотрит на мир?
Это элементарно, Ватсон!
вообще-то молотки бывают разные, да и под определение системы не очень подходит, но как-то так:
- интерфейс один - ручка (типа, за нее нужно держать subj)
- интерфейс два - плоская ударная часть (типа, ей бьют по чему-либо: гвоздям, пальцам, головам :о))))
- интерфейс три - узкая часть (в зависимости от конструкции, типа, ей гвозди выдергивают или там в сложных местах забивают, куда основной интерфейс забивания не пролезает)
-
Простите, но Actor взаимодействует с системой через UC.
Или ты что-то иное имеешь ввиду, когда требуешь рисовать UC на четырехугольнике системы и рисуешь ассоциацию между Actor (вне системы) и UC (внутри системы).
И почему это, если пользователь взаимодействует с системой через интерфейс, он окажется внутри системы? Где тебя сейчас искать? В зазеркалье?
Загибаешь!
UC не содержит действия пользователя, а описывает взаимодействия пользователя с системой.
А вот система полностью реализует UC (UC Realization), предоставляя пользователю интерфейс, соответствующий описанию UC.
Т.о., UC - это свойство только системы! Значит, это функция? Правда?
А какой пример функции, который не является реализацией UC?
какое-то нагромождение понятий.
Вроде как UC = описание взаимодействия с системой, грубо говоря описание последовательности нажатий кнопок. Если между нажатиями пользователь должен выполнять какие-нибудь строго (или не очень строго) предписанные действия, описываемые в UC, то значит система их (эти действия) охватывает, т.е. возникает коллизия между определением и содержанием границы системы.
UC при этом не принадлежит системе и не является ее свойством. Он ее всего лишь описывает в ракурсе "как с нею взаимодействовать пользователю". в этом описании "упоминаются" используемые пользователем функции (вот они - свойства системы) для достижения его цели.
-
Это элементарно, Ватсон!
Холмс, опиши на хорошем английском и связано через функции интерфейс молотка, please mister.
-
какое-то нагромождение понятий.
Вроде как UC = описание взаимодействия с системой, грубо говоря описание последовательности нажатий кнопок. Если между нажатиями пользователь должен выполнять какие-нибудь строго (или не очень строго) предписанные действия, описываемые в UC, то значит система их (эти действия) охватывает, т.е. возникает коллизия между определением и содержанием границы системы.
UC при этом не принадлежит системе и не является ее свойством. Он ее всего лишь описывает в ракурсе "как с нею взаимодействовать пользователю". в этом описании "упоминаются" используемые пользователем функции (вот они - свойства системы) для достижения его цели.
Может быть, я пишу сложно. Но так UML устроен.
UML рассматривает любой объект с двух точек зрения: снаружи (что объект делает) и изнутри (как он это делает взаимодействием своих внутренних объектов).
Дихотомия "UC - UCRealization" - это как раз такой случай. Это один элемент, который представляет две точки зрения: аналитика и проектировщика (кодера).
В системе не может быть UC, если нет UCRealization. Ну, а UCRealization не может существовать без UC хотя бы потому, что UC - это описание функциональности UCRealization.
Т.о., если быть абсолютно точным, то UCRealization реализует функцию системы, а UC - описывает эту функцию в терминах взаимодействий системы с внешним миром (actor-ом человеком или другой системой). Другими словами, UC описывает функцию системы. Полный набор всех UC описывает все функции системы.
Если кто из аналитиков не помнит, UCRealization на диаграммах представляется эллипсом с пунктирным контуром и должна иметь одинаковое с UC название. Это стандартный стереотип UML модельного элемента Collaboration.
-
Холмс, опиши на хорошем английском и связано через функции интерфейс молотка, please mister.
Можно на русском?
UC 1: Забивание гвоздя
Краткое описание: Дядька берет молоток за ручку правой рукой и, предварительно замахнувшись, ударяет плоской ударной поверхностью по шляпке гвоздя, предварительно приставленного к нужному месту.
Primary actor: Дядька
Actor: Гвоздь
Думаю, этого достаточно. Можно нарисовать диаграмму деятельности, предусмотрев альтернативный поток на случай, если гвоздь согнется, и цикл, если за один раз не выйдет!
-
не обязательно правой, а в остальном, прекрасная маркиза....
опять же можно ввести родительский UC "ударение молотком", а от него произвести дочерние "ударение молотком по пальцам", "забивание молотком гвоздя", "забивание молотком самореза", "забивание молотком насмерть" :о)))
-
Холмс, опиши на хорошем английском и связано через функции интерфейс молотка, please mister.
насколько хорошем? :о)) прошу указать критерии хорошести. а то, понимаешь, english speaking people are very very different <произносится с индийским акцентом> (for example http://www.youtube.com/watch?v=dABo_DCIdpM :о)))
-
не обязательно правой, а в остальном, прекрасная маркиза....
При внимательном рассмотрении я обнаружил ряд недостатков.
В общем случае, не рекомендуется ограничивать проектировщика в выборе решений, наилучшим образом реализующих цель пользователя: Забить гвоздь. Например, мы ограничили проектировщика определением элементов интерфейсов "Ручка" и "Плоская ударная поверхность".
Проектировщик создаст кооперацию реализации UC и начнет рисовать диаграмму последовательности. В процессе рисования и определятся соответствующие объекты: экземпляры ручки и "ударника" с его плоской поверхностью.
На основе модели реализации будет уточнено и детализировано описание UC (не обязательно, но полезно, т.к. описание UC - это плацдарм для написания руководства пользователя и тест-кейса).
Я работаю в RSA и наделал множество шаблонов SoDA на разные случаи жизни. Спецификацию UC, Руководство пользователя и TestCase я генерю из одной и той же модели UC.
-
не понял к чему это, но ограничения задаются требованиями, например, чтобы "молоток" можно было поднять одной рукой, иначе он превратится в "кувалду". насчет "плоской" - мог бы забрать назад. но, признаться, не уверен, что не получится какая-нибудь "шарообразная" или "конусообразная", что не соответствовало бы ожиданиям (несмотря на уверения проектировщика, что последние исследования английский ученых показывают, что оптимальной формой для ударной части является именно шар и, особенно, конус). так что это ограничение скорее всего тоже растет из требований.
-
не понял к чему это, но ограничения задаются требованиями, например, чтобы "молоток" можно было поднять одной рукой, иначе он превратится в "кувалду". насчет "плоской" - мог бы забрать назад. но, признаться, не уверен, что не получится какая-нибудь "шарообразная" или "конусообразная", что не соответствовало бы ожиданиям (несмотря на уверения проектировщика, что последние исследования английский ученых показывают, что оптимальной формой для ударной части является именно шар и, особенно, конус). так что это ограничение скорее всего тоже растет из требований.
Конечно, требования есть функциональные и нефункциональные ("чтобы можно было поднять одной рукой"). И гвоздь можно забить не только молотком. Но если нужно точно молотком, то нужно указать на молоток.
В книжке Альтшуллера "Алгоритм изобретения" (к ПО никакого отношения не имеет. Знаю, т.к. "в прошлой жизни" в должностные обязанности входило - зарегистрировать не меньше одного изобретения в год) есть пример ВАЗа: огромная территория и ремонтникам нужно быстро перемещаться. В задании было определено транспортное средство, а не велосипед и не тачка (которая с одним колесом)!
Ограничения нужно устанавливать осторожно.
В начале 90-x на Калининской АЭС было требование на поставку любого ПО: язык PowerBuilder. Обоснование: 100% работников IT прошло соответствующее обучение и за деньги Еврокомиссии было закуплено соответствующее программное обеспечение. Редкий случай, когда требование использования платформы было обосновано.
Так что, м.б. и шарообразная поверхность. Исполнитель несет ответственность, чтобы гвозди можно было забивать (сапожные или в доску: гвозди и молотки разные).
-
Друзья, я про молоток вот почему приплел. Может это, конечно, бред, но -
все что вы тут про молоток рассказали - все это ВАРИАНТЫ ЯГО ИСПОЛЬЗОВАНИЯ (кстати и кувалда сюда жа)
и это правильно! Но молоток как некое устройство (на систему, конечно, не тянет) имеет важную и нужную ФУНКЦИЮ - обеспечить необходимое давление на единицу площади в единицу времени - читай усилить ударную мощность человеческой руки ... для естественно важных целей человеческого организма, воли, разума, таланта, потребности.
Но ... ясно и, наверное, очевидно, что просто знания функции маловато, тут аспекты использования тоже важны, так как в конечном итоге определят и эргономику, и эстетику, и практичность
-
А кто говорит, что одних только функциональных требований достаточно.
Классификация требований FURS+. Но "F" здесь то, ради чего, собственно, делается система (молоток).
-
Простите, но Actor взаимодействует с системой через UC.
Да, но юзкейс, как мы знаем - это последовательность действий типа Пользователь <сделал что-то> ... Система сделала <что-то>. Скорее к функциям системы (или если угодно, к подфункциям, но это тоже функции ...) можно отнести то, что описывается в сценарии как "Система сделала <что-то>", а не действия пользователя ...
Или ты что-то иное имеешь ввиду, когда требуешь рисовать UC на четырехугольнике системы и рисуешь ассоциацию между Actor (вне системы) и UC (внутри системы).
"Большая графическая мистификация" (с) Коберн .... :-). Как раз про это. Более правильно говорить о том, что ряд шагов юзкейса делается пользователем (и не принадлежит системе), а ряд - системой, и принадлежат ей. Это можно явно показать только на activity диаграмме (сделав скажем два swimlane - Пользователь и Система, как это было у Лармана). А вообще - юзкейс, он скорее в голове пользователя, а не в системе :-). Поэтому я бы интерпретировал эллипс в пределах скоупа (прямоугольника) не как однозначное нахождение всего юзкейса в системе, а только как ассоциацию достижения (или недостижения, когда говорим об альтернативных сценариях, которые могут привести к неуспеху) цели пользователя посредством данной системы, именно таким набором сценариев, и именованных в терминах цели пользователя.
И почему это, если пользователь взаимодействует с системой через интерфейс, он окажется внутри системы? Где тебя сейчас искать? В зазеркалье?
Вы неверно интерпретируете сказанное мной. Утверждение, что UC это интерфейс СИСТЕМЫ - это ваше утверждение, а не мое. У меня простой вопрос - шаги юзкейса, которые делает Эктор (например, принимает решение дать кредит или нет) - это функция системы или нет?
Загибаешь!
Отнюдь!
UC не содержит действия пользователя, а описывает взаимодействия пользователя с системой.
А вот система полностью реализует UC (UC Realization), предоставляя пользователю интерфейс, соответствующий описанию UC.
Т.о., UC - это свойство только системы! Значит, это функция? Правда?
А какой пример функции, который не является реализацией UC?
Не согласен, что юзкейс не содержит действий пользователя ... совершенно. Еще как содержит!
Кстати вы так и не ответили на вопрос про количество юзкейсов, которые в среднем вы выделяете в системе ... сколько их?
-
А кто говорит, что одних только функциональных требований достаточно.
Классификация требований FURS+. Но "F" здесь то, ради чего, собственно, делается система (молоток).
Функциональные требовании = функции системы? (Эд говорит о функциях, а не о требованиях к ним ...)
-
Я выражаю все функциональные требования через UC.
А по количеству как скажешь? Где то много, где мало. Ну, в системе управления ремонтом для АЭС Tihange где-то, наверное, до 50 (основных) доходило (список на две с половиной страницы елочкой, почти три года проект был).
И детализация разная. От краткого описания до storyboard (с диаграммами граничных классов), в зависимости от сложности.
У меня за много лет уже стандартные приемы наработаны, т.ч. это не трудно - модель сделать. Труднее информацию нужную собрать (особенно, когда с языком напряженка).
-
Сегодня, обсудили со студентами данную задачу (ну тут которую я ставил в начале).
Интересно, что никто не предложил UCs типа выдать сдачу, выдать билет, принять монету. Правда был предложен ВИ вернуть деньги, но в дальнейшей дискуссии сами же студенты предложили его убрать, т.к. чудно использовать систему для возврата денег :)
Последующее обсуждение привело к ряду структурных диаграмм и поведенческих. Потратили на это примерно 1,5 часа.
Предложил - кто по нашей модели может реализовать то, что мы тут напридумывали.
Один парнишка меньше чем за 40 минут сделал это
-
Классно!
-
А чем программки отличаются? :)
-
Только версиями .net Framework?
-
А чем программки отличаются? :)
ответ в вопросе
Только версиями .net Framework?