Горспода, возник у меня по ходу изучения (довольно, увы, поверхностного) трудов Коуберна вопрос..
Алистер, описывая варианты использования и давая рекомендации по их сочинению, говорит: дескать, цели бывают разного уровня, по степени важности и общности чтоли.
И нехило бы как то это обозначать.
Еще коуберн поругивает современные CASE средства как излишне формализующие процесс.
Вопрос такой: (даже несколько)
1. Есть ли в CASE средствах поддержка таой фичи, как разный уровень целей?
2. Есть ли смысл представлять одну бизнес задачу на разных уровнях в виде use case?
3. Есть ли возможность, рисуя одну use cases diagramm, с различными уровнями целей, смотреть как бы "срез" диаграммы по заданой глубине уровня? Надо ли это?
Спасибо всем!
Я весьма доверчив, когда речь идет о моих словах. Я верю всему, что
говорю, хотя и знаю, что я лжец.
Здравствуйте, Astellar, Вы писали:
A>2. Есть ли смысл представлять одну бизнес задачу на разных уровнях в виде use case?
Безусловно есть. Например у тебя есть UC верхнего уровня "Печать отчётов". В одной системе этот UC сведётся к "нажать на кнопку соответствующего отчёта" (т.е. к тривиальному действию) или к нескольким тривиальным UC более низкого уровня ("Печать отчёта за день", "печать отчёта за неделю"), а в другой — там может включаться "авторизация пользователя", "контроль времени печати", "контроль ресурсов доступных для печати", "извещение контроллирующей организации" и т.д. — куча совершенно не тривиальных дейсвий.
Сравни к примеру UC "получение наличных" в кассе сбербанка или в банкомате
A>3. Есть ли возможность, рисуя одну use cases diagramm, с различными уровнями целей, смотреть как бы "срез" диаграммы по заданой глубине уровня? Надо ли это?
Потребность — есть. Правда на мой взгляд не столько в просмотре диаграмм, сколько в удобной группирвке тесктовых описаний UC
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Astellar, Вы писали:
A>>2. Есть ли смысл представлять одну бизнес задачу на разных уровнях в виде use case? AF> Безусловно есть. Например у тебя есть UC верхнего уровня "Печать отчётов". В одной системе этот UC сведётся к "нажать на кнопку соответствующего отчёта" (т.е. к тривиальному действию) или к нескольким тривиальным UC более низкого уровня ("Печать отчёта за день", "печать отчёта за неделю"), а в другой — там может включаться "авторизация пользователя", "контроль времени печати", "контроль ресурсов доступных для печати", "извещение контроллирующей организации" и т.д. — куча совершенно не тривиальных дейсвий. AF> Сравни к примеру UC "получение наличных" в кассе сбербанка или в банкомате
A>>3. Есть ли возможность, рисуя одну use cases diagramm, с различными уровнями целей, смотреть как бы "срез" диаграммы по заданой глубине уровня? Надо ли это? AF> Потребность — есть. Правда на мой взгляд не столько в просмотре диаграмм, сколько в удобной группирвке тесктовых описаний UC
Воот, спасибо
А вот теперь самое интересное: ЕСТЬ ли такие средства, или можно удивить общественность?
Я весьма доверчив, когда речь идет о моих словах. Я верю всему, что
говорю, хотя и знаю, что я лжец.
AF> Если есть чем — удивляй!
Да вот в том то и вопрос: я не знаком со всеми CASE средствами. Вдруг уже реализовано? Сама идея просто понравилась, представил, как выглядело бы..
Я весьма доверчив, когда речь идет о моих словах. Я верю всему, что
говорю, хотя и знаю, что я лжец.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Astellar, Вы писали:
A>>2. Есть ли смысл представлять одну бизнес задачу на разных уровнях в виде use case? AF> Безусловно есть. Например у тебя есть UC верхнего уровня "Печать отчётов". В одной системе этот UC сведётся к "нажать на кнопку соответствующего отчёта" (т.е. к тривиальному действию) или к нескольким тривиальным UC более низкого уровня ("Печать отчёта за день", "печать отчёта за неделю"), а в другой — там может включаться "авторизация пользователя", "контроль времени печати", "контроль ресурсов доступных для печати", "извещение контроллирующей организации" и т.д. — куча совершенно не тривиальных дейсвий. AF> Сравни к примеру UC "получение наличных" в кассе сбербанка или в банкомате
Если говорить про подход Коберна, то UC верхнего уровня должен называться "Печатать отчет". Насчет отношений включения и расширения лдя UC, то у Коберна тоже есть свое мнение на этот счет . Обычно UC уровня "воздушный змей" или "облако", является контекстом для юзкейсов уровня "цель пользователя".
A>>3. Есть ли возможность, рисуя одну use cases diagramm, с различными уровнями целей, смотреть как бы "срез" диаграммы по заданой глубине уровня? Надо ли это? AF> Потребность — есть. Правда на мой взгляд не столько в просмотре диаграмм, сколько в удобной группирвке тесктовых описаний UC
Графически отношения UC с разными уровнями целей можно показать используя как раз UML-диаграммы UC, например через стереотипы, которые будут обозначать уровни UC. А можно просто в тексте высокоурвневого UC делать ссылки на более низкоуровневые UC, если нет возможзности использования CASE-средств с поддержкой UML.
Идея просто понравилась. Скрывать не буду, проект претендует на звание научной работы..
слепить CASE средство для бизнес-аналитиков, не замудреное непосредственно проектироованием архитекруты ПО, но дающее возможность рассматривать задачу с разной глубиной подробности.
А если все это уже есть, так и смысла такой работы нету.
А еслит этого нет — то надо подумать, есть ли смысл
К чему и призываю
Я весьма доверчив, когда речь идет о моих словах. Я верю всему, что
говорю, хотя и знаю, что я лжец.
Здравствуйте, Astellar, Вы писали:
A>Идея просто понравилась. Скрывать не буду, проект претендует на звание научной работы.. A>слепить CASE средство для бизнес-аналитиков, не замудреное непосредственно проектироованием архитекруты ПО, но дающее возможность рассматривать задачу с разной глубиной подробности. A>А если все это уже есть, так и смысла такой работы нету. A>А еслит этого нет — то надо подумать, есть ли смысл A>К чему и призываю
В UML на диаграмме UC делаешь связь между более абстрактным и более конкретным юзкейзами и делаешь стереотип связи include, если конкретных юзкейзов в абстрактном несколько, либо realise, если конкретный юзкейз один — полностью соответствует абстрактному, только расписан более подробно.
В IDEF0 — декомпозиция функции и есть переход на более конкретный уровень.
Здравствуйте, Astellar, Вы писали:
A>Горспода, возник у меня по ходу изучения (довольно, увы, поверхностного) трудов Коуберна вопрос.. A>Алистер, описывая варианты использования и давая рекомендации по их сочинению, говорит: дескать, цели бывают разного уровня, по степени важности и общности чтоли. A>И нехило бы как то это обозначать. A>Еще коуберн поругивает современные CASE средства как излишне формализующие процесс. A>Вопрос такой: (даже несколько) A>1. Есть ли в CASE средствах поддержка таой фичи, как разный уровень целей? A>2. Есть ли смысл представлять одну бизнес задачу на разных уровнях в виде use case? A>3. Есть ли возможность, рисуя одну use cases diagramm, с различными уровнями целей, смотреть как бы "срез" диаграммы по заданой глубине уровня? Надо ли это?
Есть такая методология ARIS от компании IDS Sheer. Также есть сопутствующие программные продукты, которые поддерживают эту методологию. Там есть диаграммы целей (Objectives), которые в дальнейшем развёртываются в диаграммы функций и далее в USE-Cases.
Многие знакомые бизнес-аналитики этими инструментами пользуются.
Здравствуйте, byur, Вы писали:
B>Графически отношения UC с разными уровнями целей можно показать используя как раз UML-диаграммы UC, например через стереотипы, которые будут обозначать уровни UC.
Т.е. остается лишь наложить фильтр на UC по параметру "стереотип" — и получим любое количество уровней представления UC-модели.
Насколько я представляю, именно такая концепция реализована в Borland Together Architect (просто у меня пока руки до этого не дошли, чтобы сказать более определенно).
Здравствуйте, Astellar, Вы писали:
A>1. Есть ли в CASE средствах поддержка таой фичи, как разный уровень целей?
Смотря что понимать под CASE.
В Rational Rose/Together подобная задача легко решается при помощи указания стереотипа useCase'a.
В CaliberRM (и, наверное, в RequisitePro) уровень цели можно указать явно, при помощи соответствующего свойства, либо, неявно, заданием соотетствующей иерархии.
A>2. Есть ли смысл представлять одну бизнес задачу на разных уровнях в виде use case?
Не очень понятен вопрос.
Если идёт речь про функциональную декомпозицию бизнес-задачи — отчего бы и не представить.
Если говорится про зависимость уровня цели бизнес-задачи от точки зрения пользователя — тут сложно сказать...
Тот же useCase "Сформировать отчет за месяц" для бухгалтера может быть облаком, а для топ-менеджера — мелкой рыбкой. Как представить подобную зависимость от точки зрения, не очень понятно.
A>3. Есть ли возможность, рисуя одну use cases diagramm, с различными уровнями целей, смотреть как бы "срез" диаграммы по заданой глубине уровня? Надо ли это?
Имхо не стоит зацикливаться на рисовании диаграмм, более важно нормально описать вариант использования.
Кстати, по личному опыту, гораздо удобнее для описания вариантов использования пользовать вещи класса CaliberRM (и им подобные), а не рисовалки вида роза/тугезер. Удобнее в них работать с текстом, да и с иерархией работать проще.
Здравствуйте, cvoronin, Вы писали:
C>Здравствуйте, Astellar, Вы писали:
A>>2. Есть ли смысл представлять одну бизнес задачу на разных уровнях в виде use case? C>Не очень понятен вопрос. C>Если идёт речь про функциональную декомпозицию бизнес-задачи — отчего бы и не представить. C>Если говорится про зависимость уровня цели бизнес-задачи от точки зрения пользователя — тут сложно сказать... C>Тот же useCase "Сформировать отчет за месяц" для бухгалтера может быть облаком, а для топ-менеджера — мелкой рыбкой. Как представить подобную зависимость от точки зрения, не очень понятно.
Для этого и определяют scope, после чего все становиться на свои места
Здравствуйте, segeyros, Вы писали:
S>Здравствуйте, byur, Вы писали:
B>>Графически отношения UC с разными уровнями целей можно показать используя как раз UML-диаграммы UC, например через стереотипы, которые будут обозначать уровни UC.
S>Т.е. остается лишь наложить фильтр на UC по параметру "стереотип" — и получим любое количество уровней представления UC-модели. S>Насколько я представляю, именно такая концепция реализована в Borland Together Architect (просто у меня пока руки до этого не дошли, чтобы сказать более определенно).
Если я правильно понимаю понятие "фильтр", то дав запрос типа "покажи-ка мне все UC со стереотипом "облако"" -- можно получить список названий высокоуровневых UC (UС заданного уровня), а не любое кол-во уровней.
Здравствуйте, byur, Вы писали:
B>Здравствуйте, cvoronin, Вы писали:
B>Для этого и определяют scope, после чего все становиться на свои места
Дык оно, конечно, становится, то легче от этого не становится
В IDEF в этом отношении проще — делается отдельная модель, в которой явно прописывается scope —
а с useCase'ами такое, пожалуй, проделать сложнее... Не то что трудно, но менее очевидно.
