Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Gevorg от 21 Марта 2007, 12:14:57
-
ссылки на подход Коберна и RUP.
Ага, про Коберна... Кого ни спрошу - отмахиваются:
У Коберна, в его Writing Effective Use Cases есть UML-диаграммки,
эдакая модель понятий - контекст для Use Case.
Там Goal, Responsibility, Actor, Action и т.д.
Насколько я понял из книжки, сам Коберн признаётся, что это суровый драфт, который ещё править и править...
У меня по этому поводу 2 вопроса:
- Что уважаемые форумчане лично думают про эти самые диаграммы?
- и что знают про мнения и работы других в этом направлении?.
-
Ага, про Коберна... Кого ни спрошу - отмахиваются:
У Коберна, в его Writing Effective Use Cases есть UML-диаграммки,
эдакая модель понятий - контекст для Use Case.
Там Goal, Responsibility, Actor, Action и т.д.
Насколько я понял из книжки, сам Коберн признаётся, что это суровый драфт, который ещё править и править...
У меня по этому поводу 2 вопроса:
- Что уважаемые форумчане лично думают про эти самые диаграммы?
- и что знают про мнения и работы других в этом направлении?.
Во-первых, книга написана достаточно давно.
Во-вторых, книга посвящена функциональным требованиям в виде вариантов использования.
В-третьих, существуют как сторонники визуализации, так и потивники.
В-четвертых, использоание визуальных диаграмм оправдано тогда, когда они действительно улучшают понимание. Например, как внутренние артефакты проекта.
-
В-третьих, существуют как сторонники визуализации, так и потивники.
ага, меня интересуют результаты сторонников визуализации :-)
и критика этих результатов
-
ага, меня интересуют результаты сторонников визуализации :-)
и критика этих результатов
При условии наличия описанных в спецификации юзкейсов добавление "иллюстраций" в виде диаграммы юзкейсов вполне полезно, т.к. позволяет охватить одним взглядом что к чему. А если исользовать ТОЛЬКО диаграмму UC, (и не дополнять ее ни чем) то толку от нее никакого ... и все скатиться к функциональной декомпозиции, только для ее представления почему-то выбрана будет именно UML UC диаграмма ... ну разве что запудрить мозги заказчику, типа "умеем картинки на UML малевать".
-
UML UC диаграмма ... ну разве что запудрить мозги заказчику, типа "умеем картинки на UML малевать".
В-четвертых, использоание визуальных диаграмм оправдано тогда, когда они действительно улучшают понимание.
так здесь 2 направления для визуализации:
- собственно, функциональных требований (UML UC диаграмма)
- модели понятий вокруг- и для- понимания инструмента под названием Use Case (в каком-то смысле - метамодель).
с мнением по первому направлению - полностью согласен.
Но мои вопросы были относительно второго.
-
Если честно, я не совсем понял вопроса. Что значит "модели понятий вокруг" и "понимание инструмента UC" ... можно пояснит подробнее, чтобы мы могли дать вразумительный ответ?
-
Согласен с Юрием.
На лицо нечеткое понимание того. а что нужно заявителя и неумение точно передать смысл вопроса.
-
Вот, перенабранные из книжки диаграммы, про которые спрашивал.
Снимаю предыдущие свои вопросы и заменяю на детские:
- что это такое?
- как оно правильно называется?
- кому это было интересно и кто брался развивать\дорабатывать\править?
(и если были таковые, то где посмотреть их результаты?)
-
- что это такое?
- как оно правильно называется?
- кому это было интересно и кто брался развивать\дорабатывать\править?
(и если были таковые, то где посмотреть их результаты?)
1. Представление Коберна о возможной структуре понятия действующее лицо
2. Диаграмма классов
3. Коберн привел эти диаграммы для того, кому нравится строить диаграммы
4. Кто и что брался развивать? Иерархию понятия действующего лица? Так не нравится - можно свое видение предложить
Далее UML средство формализации проектирования прежде всего.
Думаю нет необходимости пояснять значимость диаграммы классов.
Порядок использования UML трактуется в рамках определенного процесса. Процесс предлагает и методологию использования . Разные процессы могут трактовать порядок и метод использования UML диаграмм по своему.
Писатель пишет прозу, поэт умудряется писать стихи, ученый пишет статьи, двоечник делает кучу ошибок, кто-то умеет использовать язык виртуозно, другой косноязычен: однако все используют язык - русский например.
UML - это язык, язык тезаурусный, язык символьный.
Не могу понять вопроса, в чем проблема, какая цель?
Тысячи людей с успехом используют UML. Тысячи успешно используют Use Case диаграммы, на разных уровнях абстракции, кто-то сопровождает такие диаграммы текстом, другие предпочитают делать диаграммы деятельности или последовательности.
Другие считаю, что вполне достаточно таблички Действующие лица и их цели, дополняя это текстовым описанием сценариев.
Рамбо например советует для особо сложных сценариев ВИ представлять диаграммы деятельности и диаграммы последовательности.
Другие вообще ясно и однозначно утверждают - одна графическая диаграмма заменяет десятки и сотни строк текста. Тескт неодназначен, картинка мол однозначна, елси сделана по правилам.
Сами по себе картинки конечно важны, но имеет больше смысла, когда эти картинки постепенно преобразуются в модель приложения и на ее основе генерируется каркас кода.
Технология MDA позволяет сформировать диаграмму классов, которая становится управляемым объектным пространством приложения (BOLD, ECO).
Диаграмма состояния позволяет сгенерировать соотвествующий код для отслеживания изменений состояния объекта (ECO)
Логика использования канонических диаграмм заложена в том или ином процессе разработки. При этом некоторые процессы могут использовать смешанные языки моделирования как на разных так и на одном этапе моделирования, проектирования.
Я например могу видеть такую цепочки: Use Case -> Диаграмма классов (VOPC) -> диаграмма последовательности (диаграмма кооперации) -> уточнение диаграммы классов (выявление опреация) -> диаграмма состояний для избранный объектов
-
Эд, я думаю ты пошел немного не в том направлении. Коберн хотел показать статическую структуру, что у кого есть, а не как во что преаобразуется.
Вот посмотрим на диаграмму 2, она наиболее простая:
Основоной Актер имеет какие-то цели, каждая цель представляется одним или несколькими ВИ, каждый ВИ имеет некую ответсвенность. Что такое SuD - я не понял.
В принципе все Д очень информативны и представляют собой правильную структуру. Возможно их можно как-то использовать для дальнейшей автоматической гененрации - надо подумать.
-
Эд, я думаю ты пошел немного не в том направлении. Коберн хотел показать статическую структуру, что у кого есть, а не как во что преаобразуется.
Вот посмотрим на диаграмму 2, она наиболее простая:
Основоной Актер имеет какие-то цели, каждая цель представляется одним или несколькими ВИ, каждый ВИ имеет некую ответсвенность. Что такое SuD - я не понял.
В принципе все Д очень информативны и представляют собой правильную структуру. Возможно их можно как-то использовать для дальнейшей автоматической гененрации - надо подумать.
Саша, позволь не согласиться. Более того, это ты пошел немного не в ту область. Читай, что пишет автор сообщения.
Я ему лишь отвечаю. по существу вопроса, как я его понял.
Чуть позже я просто описываю проблему использования UML и акцентирую внимания на форме его использования.
А про диаграммы приведенные автором сообщения я ничего такого и не говорю. И вовсе, как ты приписываешь мне, я не интерпритирую так Коберна. Почитай внимательно ответ на вопрос в виде 1-4 пункта. Далее идет уже философствование на заданную тему.
А SuD это система проектируема, рассматирваемая система, system under discussion (or under design)
-
1. Представление Коберна о возможной структуре понятия действующее лицо
там ещё есть Цель, Интерес, Действие...
получается уже целая модель поведения.
меня живо интересует,
кто ещё строил подобные модели, свои независимые, или на основе этих, Коберновских.
-
там ещё есть Цель, Интерес, Действие...
получается уже целая модель поведения.
меня живо интересует,
кто ещё строил подобные модели, свои независимые, или на основе этих, Коберновских.
Я не строил. То что приведено у Коберна вполне адекватно. Но естественно может быть расширено улучшено оптимизиовано и прочее. Вопрос лишь для чего? Поянтия рассмотренны довольно глубоко и всестороне. Я просто пока не вижу необходимости что-то улучшать. Тем более повторюсь сам Коберн относится к диаграммам такого рода скорее как к игрушке, он просто отдает дань любителям графических образов. И по-моему весьма не плохо.
Важно лишь понять что Вы сами хотите получить от такой диаграммы?
-
Важно лишь понять что Вы сами хотите получить от такой диаграммы?
... Возможно их можно как-то использовать для дальнейшей автоматической гененрации - надо подумать.
Возможно их можно использовать для теоротических изысканий в области генереации диаграмм из текста или как-то еще ...
Я вообще хотел поднять тему "Наука в области Анализа", т.е. расмотреть модные веянья в Анализе и UML в частности для написания диссера.
-
Возможно их можно использовать для теоротических изысканий в области генереации диаграмм из текста или как-то еще ...
Я вот хочу спросить - это свойство аналитика додумывать за других их задачи и цели?
Пост опубликовал Gevorg, он инициатор и заявитель.
А некто bas имхо лишь участник дискуссии. Предложения для своего видения проблемы - безусловно хорошо, однако чреевато..
Я вообще хотел поднять тему "Наука в области Анализа", т.е. расмотреть модные веянья в Анализе и UML в частности для написания диссера.
Вообще странная тема наука в области анализа. Мне кажестя скорее анализ в области науки:-)) Вообще модные веяния - это не наука.
Научное исследование - квинтэссенсия познания нового. В самом научном исследовании многое от того, что мы тут обсуждаем. Для диссертации кандидатской следует ставить задачу поуже и почетче. Например не "Исследование свойств плазмохимических систем", а скажем "Исследование свойств плазмохимических систем в верхних слоях ионосферы". А в нашем случае "использование холистического подхода для того-то". При этом любое научное исследование дает: исходное состояние проблемы, задачи, области исследования, актуальность проведения научных изысканий, обоснование такой актуальности и новизны. Потом уже даются результаты деятельности и осмысление их.
Например можно выдвинуть и доказать принципы холистического подхода, провести анализ на предмет достоинств и недостатков других подходов. Показать пример доказываемого подхода и тот же пример реализованный другими устоявшимися методами. Тут и проявляется достоинство или недостатки.
По нашей теме можно подумать так: есть некая графическая или необязательно но некая строго формализованная модель с правилами и ограничениями, которая описывает модель действующие лица и их цели. Далее есть текстовое описание - куча первичных, вторичных документов, постановка задачи, интервью, сценарии и т.д. ит.п.
Некий "генератор формализма" - используя заложенную модель производит анализ всей информации по всяким строгим и сложным правилам и скажем формирует модель действующие лица, строит ВИ и прочее...
Пока это сказка имхо, хотя как мне читалось, тенденции к этому есть, так называемые самопрограммирующиеся системы...
-
Злой ты стал Эд :) Я просто высказал свое мнение, а ты сразу "некто bas" ...
Я просто не понял, что обращался именно к создателю топика.
Надо в общем тему создавать про Науку ....
-
Злой ты стал Эд :)
У какой я злой - не подходи а то укушу ;D
Я просто высказал свое мнение, а ты сразу "некто bas" ...
Я просто не понял, что обращался именно к создателю топика.
Ну это простая художественная обработка текста, чтобы передать эмоциональное отношение:-) Ничего личного, дружище:-))
Надо в общем тему создавать про Науку ....
Для начала надо определится с темой научных изысканий
-
.. сам Коберн относится к диаграммам такого рода скорее как к игрушке, он просто отдает дань любителям графических образов...Важно лишь понять что Вы сами хотите получить от такой диаграммы?
я как раз отношусь к таким "любителям графических образов", и мне подобные игрушки понадобились для улучшения понимания Use Case-а, как средства описания функциональных требований.
Взялся вчитываться в эти Коберновские диаграммы, - и попал в странную ситуацию:
диаграммы есть, - а понимания не добавляют.
Наоборот, переворачивают и те представления, которые сложились при прочтении текстовой части книги.
Начал спрашивать у знающих людей - оказалось, у них такого рассогласования не возникало...
но и особого интереса тоже.
Вывод: разбираться нужно самому, по ходу задавая частные вопросы.
-
Вот посмотрим на диаграмму 2, она наиболее простая:
Основоной Актер имеет какие-то цели, каждая цель представляется одним или несколькими ВИ, каждый ВИ имеет некую ответсвенность. Что такое SuD - я не понял.
В оригинале у Коберна написано:
This model fragment expresses that use case is the primary actor's goal, calling upon the responsibility of the system under design (SuD).
Я не силён в английском, но мне кажется, что описание Коберна намного более примитивное по сравнению с тем, что привёл BAS.
у меня здесь вопросы:
- как всё-таки, трактуется стрелочка с закрашенным треугольником на конце в общем случае.
- что ближе к современному пониманию ЮзКейса?
-- примитивное Коберновское ЮзКейс - это цель основного Актёра или
-- Юз-Кейс (или их набор) не есть цель, а есть некое представление цели (одной или нескольких?),
(если я правильно понял BASa)
- что же тогда такое по Коберну Ответственность? другое название для ЮзКейса?
-
Судя по диаграмме и моих знаниях о представленных понятиях отношения с закрашенной стрелочкой - это отношения "состоит из", то есть агрегация.
Полый не закрашенный ромб - это агрегация, закрашенный - композиция, т.е. более строгий вид агрегации, когда с изчезновением агрегата(композита) уничтожаются его части или агрегат перестает иметь смысл.
Системный болок состоит из - бла бла, тут агрегация, поскольку это блабла вполне самостоятельное имеет значение.
Рубашка состоит из рукава, воротника, кокетки спинки грудки. Разорвем рубашку - цельность исчезла.
Окно - имеет меню, строку состояние, окно редактирование, кнопки панели инструментов - закрываем окно изчезает все - это композиция.
Коберн к сожалению относится к картинкам халатно - потому у него стрелочки теряют свою информативнойсть. Стрелка с полым равнобедернным треугольником (незакрашенная) - это обощение, генерелизация, моделирует наследование. У Кобрена закрашено. Там где агрегация тоже есть стрелка и очень похожа на равноберенный треугольник - думаю это может быть просто навигация - иначе просто теряется смысл, связь не может быть с одного конца обобщением, а с другого агрегацией. Думаю в этом случае мы имеем самоассоциацию с агрегацией, т.е. поведение агрегирует другие виды поведения. Ну нельзя же самое себя наследовать верно?, а направление навигации показывает что поведение-агрегат прослеживается только в сторону поведения-части
Далее рисунок 2. Поведение. Ориентированное на цель поведение включает обязанности, цели и действия.
1 ДЛ имеет разные виды поведения: это некие обязанности (служебные и т.д.), цели, которые также определяют поведение, действия (некоторые шаги - взять, написать, подписать, распечать) Через действия ДЛ может либо взаимодейстовать с другим ДЛ (сотрудником) либо с неким участником через его интерес к систем. Бухгалтер производит начисления коммунальных платежей некой коммунальной службе( наша система гарантирует коммунальной службе полную информацию о платежах...)
-
Вообще, жалко, что народ не был на вчерашнем семинаре. Там как раз (к моему сожалению очень подробно) рассказывалось один из методов составления ВИ:
1. Берем ВИ, вчерашний пример - это "Запланировать курс"
2. Берем всех выделенных на раннем этапе ЗЛ (заинтересованных лиц) и для каждого расписываем что-то же делает его счастливым (его ответственность) в рамках этого ВИ
3. Расписываем этот ВИ, чтобы удовлетворить все потребности из п. 2, хотя по сути актер один - "Админмитратор Курсов"
-
Вообще, жалко, что народ не был на вчерашнем семинаре. Там как раз (к моему сожалению очень подробно) рассказывалось один из методов составления ВИ:
1. Берем ВИ, вчерашний пример - это "Запланировать курс"
2. Берем всех выделенных на раннем этапе ЗЛ (заинтересованных лиц) и для каждого расписываем что-то же делает его счастливым (его ответственность) в рамках этого ВИ
3. Расписываем этот ВИ, чтобы удовлетворить все потребности из п. 2, хотя по сути актер один - "Админмитратор Курсов"
Может сделаешь нормальный пост с примерами, либо статью опубликуешь "По результатам семинара...."
-
Как Асхат выложит материалы (что-бы ничего не забыть) сделаю обобщающую статью ...
-
Вообще, жалко, что народ не был на вчерашнем семинаре
а конспект семинара где-то есть?
-
Велась видео запись и есть презентация Дена (ведущего семинара), будет все выложено в ближайшее время на сайте www.agilerussia.ru. Дальнейшие вопросы по семинару в ветке: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=195.0
-
А насчет использования дигарамм UC, поднятой автором этой темы, ИМХО значительная часть скепсиса по поводу их применения связана с тем, что их "просто не умеют готовить". То, что диграмма UC дает возможность окинуть общим взглядом предстоящее поле деятельности, отобразить основных фигурантов проекта (декомпозировать, как правило, еще нечего) и в какие именно специальные области деятельности эти фигуранты-акторы вовлечены, позволяет эффективно использовать диаграмму в качестве карты (roadmap) для обсуждения с самими акторами диаграммы, а также основы для дальнейшей детализации этих видов деятельности. Поэтому эта диаграмма ИМХО может быть целиком отнесена к арсеналу средств бизнес-аналитика.
Особенно интересно применение этих диграмм для задач, связанных именно с интеграцией различных специализированных областей деятельности, если рисовать такие диаграммы по материалам интервью с акторами. И использовать их именно в качесте средства бизнес-анализа. В таких задачах деятельности самих акторов досточно хорошо капсулированы на уровне бизнеса и проблема в большей степени связана не с описанием их внутреннего функционирования, а именно с установлением в некотором обозримом виде их взимосвязей через общие области деятельности.
По мере доработки диаграммы по результатам обсуждения, сам факт, какие акторы с какими областями деятельности (трактуемыми как элементы диаграммы - собственно UC) связаны часто оказывается весьма информативным для обсуждения и даже неожиданным для некоторых интервьюируемых акторов, позволяют отделить важное от второстепенного. Гляда на диаграмму собседник при повторном обсуждении часто вспоминает важные детали.
Выделение областей деятельности требует агрегирования отдельных специализированых видов деятельности. Иногда полезно, наоборот, разделить некоторые специализации, традиционно считающимися неделимыми. Важен также дизайн диаграммы, размещение элементов в наглядном, по возможности, симметричном виде. Вид симметрии также иногда выявляет некоторые неожиданные взаимосвязи между областями деятельностями.
К сожалению, в практике автоматизации бизнеса (особенно отечественного) очень часто задачи автоматизации отдельных видов деятельности превалируют на собственно интеграциоными задачами. Там где фактически идет автоматизации технологического процесса, связанного с конкретной профессиональной специализацией, детальное описание процесса (алгоритм) часто явлется единственно значимым для работы. Попытка рисовать юзкейсы для таких работ приводит к тому, что в качестве юзкейсов на таких диаграммах появляются обезличенные универсальные операции. Взаимосвязь таких операций с акторами и между собой без наглядной причнно-следственно связи получается достаточно бессмысленной (имею в виде именно диагрмму UC, а не диаграммы взимодействия и пр.). Особенно забавно, когда такие юзкейсы в руководствах по UML рисуют именно для таких случаев - типа "актор наливает себе чашку кофе" :).
Практике текстового описания алгоритмов столько же лет, сколько программированию, широкое же применение диаграмм в качестве специального инструмента (а не иллюстративного материала) менеджмента и анализа бизнеса началось гораздо позже - примерно в 70-е годы 20 века. Возможно, этот факт играет не последню роль в отношении к графическим средствам описания и анализа бизнес- процессов...
-
2. Берем всех выделенных на раннем этапе ЗЛ (заинтересованных лиц) и для каждого расписываем что-то же делает его счастливым (его ответственность) в рамках этого ВИ
3. Расписываем этот ВИ, чтобы удовлетворить все потребности из п. 2, хотя по сути актер один - "Админмитратор Курсов"
Не чуствуешь как от этого "пахнет Коберном" с его "защитить интересы всех стейкхолдеров" ;-) ?
-
А насчет использования дигарамм UC, поднятой автором этой темы, ИМХО значительная часть скепсиса по поводу их применения связана с тем, что их "просто не умеют готовить".
Скепсис в большей степени вызывают не столько сами диаграммы, сколько "только диаграммы" (читай "только диаграммы юзкейсов и ничего больше").
-
Скепсис в большей степени вызывают не столько сами диаграммы, сколько "только диаграммы" (читай "только диаграммы юзкейсов и ничего больше").
К сожалению, дело обстоит не совсем так. Цитата из Коберна (стр 226 из текста из библиотеки сайта):
"The Unified Modeling Language defines graphical icons that people are determined to use. It
does not address use case content or writing style, but it does provide lots of complexity for people
to discuss. Spend your energy learning to write clear text instead. If you like diagrams, learn the
basics of the relations, and then set a few, simple standards to keep the drawings clear."
Т.е. в третьем предложении г.Коберн совершенно недвусмысленно советует предпочесть текстовое описание юзкейса использованию его графических представлений. Для тех кто все таки захочет использовать диаграммы он в этом предложении даже не предлагает придерживаться стандартов UML! Характерно, что при переводе:
"Унифицированный язык моделирования UML определяет набор используемых гpaфических нотаций. Он не касается содержания варианта использования и стиля изложения, но создает значительные сложности при их обсуждениях. Вместо этого лучше научиться писать ясные тексты. Если вам нравятся диаграммы, освойте основы отношений и затем введите несколько простых стандартов, чтобы диаграммы были понятны."
третье предложение в цитируемом фрагменте было смягчено и вот этой фразы "Вместо этого" соответствующей instead в оригинале, в переводе нет.
На стр. 230 русскоязычного издания сказано:
"С тех пор как вышла книга Object-Orieпted Software Eпgiпeeriпg (1993) многие авторы при создании вариантов использования сфокусировали внимание на фиryрах из палочек и эллипсах, упуская из виду, что варианты использования это текстовая форма представления. "
Трудно себе представить человека, который после прочтения этого пассажа насчет "фигур и палочек" захочет разобраться с UML нотацией и применить графическое представление юзкейса для пользы дела….
В целом трактовка Коберном графического представления UML носит достаточно противоречивый характер. Наряду с цитированными выше фрагментами, прямо указывающими на необходимость предпочтения текстового описания графическим у него есть и более взвешенные рекомендации (стр. 238):
"Рисунок это двумерная мнемоническая схема, которая служит выделению связей. Применяйте его для данной задачи, а не заменяйте им текст"
Но примеры диаграмм вариантов использования, например на стр. 231, даже почерпнутые из книги Буча ИМХО крайне неудачны, потому что диаграммы юзкейсов на уровне системы без (диаграмм) "юзкейсов на уровне цели", по терминологии Коберна, действительно бессмысленны, а приведенный им пример скорее относятся именно к такой ситуации.
Коберном проделана выдающаяся работа по окультуриванию практики описания алгоритмов, и его рекомендации по текстовому описанию юзкейсов действительно важный шаг в развитии IT, но к сожалению его взгляд на использование графических средств анализа и представления результатов является шагом назад, который серьезно оппонирует попыткам создания новых средств анализа и моделирования даже в качестве дополнительных к "текстовым инструментам" .
-
Можно я вставлю маленькое слово?
1. Спор об использовании или не использовании графических средств ведется давно. В каждом лагере есть свои аргументы в пользу использования своей концепции взгляда.
Как я понимаю, использование текстовой формы или графического представления ВИ зависит от уровня представления и изучения. На уровне бизнеса, взаимодействия с заказчиком подойдет любая форма, помогающая найти общий язык. Контекстная диаграмма ВИ Коберном вполне поддерживается, посмотрите, он называет ее модель Действующие лица и Цели. Т.е. Диаграмма ВИ может использоваться в этом случае, но скорее только как СОДЕРЖАНИЕ, однако в этом виде ничего показательного особо нет, потому Коберн и говорит - достаточно изобразить ее в виде таблицы. Все люди по крайней мере с 7 лет учаться читать и в этом деле их можно считать профессионалами. А вот рисовать диаграммы UML учать в вузах, да и не во всех, и не во всех специальностях.
Другие авторы говорят "Используйте графические средства - лучше один раз увидеть, чем 10 раз прочитать. Ибо при прочтении многие понимают это по своему, а графическую интерпретацию - однозначно. Тем более совсем несложно пояснить что обозначает человечек и овальчик"
2. Далее. Тема называется структурные диаграммы для представления ВИ. Если говорить точно, ВИ есть часть поведения системы и часть модели взаимодействия системы с окружением. Структурная диаграмма отображает структуру, т.е. нечто статичное. Конечно можно назвать ВИ функциональной структурой - но правильно ли это будет.
Т.е. я хочу задать вопрос, а явяляется ли тема правильно сформулированной, в том ли направлении идет дискуссия?
-
К сожалению, дело обстоит не совсем так. Цитата из Коберна (стр 226 из текста из библиотеки сайта)
Коберном проделана выдающаяся работа по окультуриванию практики описания
алгоритмов, и его рекомендации по текстовому описанию юзкейсов действительно важный шаг в развитии IT, но к сожалению его взгляд на использование графических средств анализа и представления результатов является шагом назад, который серьезно оппонирует попыткам создания новых средств анализа и моделирования даже в качестве дополнительных к "текстовым инструментам" .
На самом деле мне не понятно, таки почему это "дело обстоит не совсем так" ... и почему ТОЛЬКО диаграммы юзкейсов не должны вызывать скепсис?? Особенно если учесть тот факт, что практика использования только диаграмм юзкейсов фактически приводит к функциональной декомпозиции но на юзкейсах ... и запросто при этом встречаем ВИ "Отправка уведомления о регистрации на мероприятие", который в лучшем случае будет "included". Никто не отрицает, что использование диаграммы юзкейсов в качестве "оглавления", предваряющего собственно текстовые спецификации вполне полезно, более того, я сам часто использовал диаграммы ВИ в "Modern SRS", но обязательно за ними следовали и сами юзкейсы. Кроме этого еще и графически показывал связь м/у диаграммами уровня "облака" и "user goal". Так что речь тут в большей степении о том, что имеет смысл использовать диаграммы СОВМЕСТНО с текстовыми спецификациями ... Но при этом, одни текстовые спеки дают больше value, чем одни диаграммы.
[/quote]
-
Как я понял Коберна, он никогда не отрицал (и даже наоборот) роли контекстной диаграммы (на которой показаны границы систем, действующие лица и основные цели). В частности эта диаграмма может быть сделана с использованием UML.
Пожалуйста, не могли бы Вы дать ссылку на страницы русскоязычного издания, которые иллюстрировали бы данную трактовку Коберном роли диаграммы Use cases?
ИМХО практически везде, где Коберн описывает применение диаграмм UC он сначала предлагает не совсем удачные решения по графическому изображению UC, а потом сам же сетует на их несовершенство, например, в разборе примера на стр. 41-46 русскоязычного издания Коберн вырабатывает более-менее приемлемое изображение UC: "Я бы предпочел нестандартную диаrpaмму варианта использования (см. рис. 3.3), чтобы показать связь двух систем".
но тут же (на стр. 46) выносит ему приговор:
"Эта диаrрамма более наrлядна, но ее труднее сопровождать. Диаrрамма должна помоrать вам и вашим читателям лучше понимать друr друrа."
1.Непоятно - в чем нарушение стандарта на рис. 3.3? По крайней мере сравнивая с текстом UML Superstructure 2.0 (который, правда, принят после опубликования книги) нарушений пока не вижу...
2. Глубокомысленный пассаж насчет трудности сопровождения также не подкреплен конкретными аргументами.
То, что есть мнение против слишком точного рисования диаграмм Use Case с одной стороны не отрицает их применение, а с другой стороны имеет под собой веские основания.
Давайте представим себе двух аналитиков: один ИТ специалист - системный аналитик, второй - заместитель генерального директора по финансам.
Первый знает UML и все его тонкости и может даже сделать документ, описывающий сценарии с использованием средства моделирования, тогда для него жизненно важна точнось диаграмм и модели (в противном случае документ не сгенерируется правильно).
Второй не знает UML и пишет документы в MS Word - для него рисование точной диаграммы Use Case выльется в дополнтельные хлопоты.
То, что для финансового директора привычно написание документов в Word совсем не означает, что он сядет писать UC для требуемой ему системы прилежно сверяясь с рекомендациями Коберна. Вероятнее всего ИТ специалист приведет ряд интервью с замом по финансам, они выяснят, что нужно, и это будет зафиксировано в виде, удобном как для Заказчика, так и для разработчиков системы. Диаграммы рисовать (или описывать текстовые юзкейсы) будет тот из них, кто лучше умеет это делать. Рисование диаграмм (в процессе обсуждения) существенно облегчает процесс обсуждения, даже если диаграммы недостаточно строго следуют принятым стандартам UML. Следует специально отметить, что в данном случае мы рассматриваем именно процесс анализа деятельности подлежащей автоматизации.
Представим, что добавились пара сценариев. Первый аналитик изменит модель и перегенерирует документацию. второй добавит разделы в документ и будет вынужден синхронизировать картинку с содержанием документа (лишняя работа).
Насколько общим является Ваше утверждение в этом фрагменте о том, рисование диаграмм даже в дополнение к текстовому описанию является "лишней работой"? Оно относится только к рассматриваемому примеру или Вы считаете, что они никогда не приносят пользы для описания, анализа системы?
Когда они вместе будут читать документ, первый будет жаловаться, что второй рисует не по стандарту UML, а первый будет говорить, что он не понимает тонкостей UML (чем, например овальчик отличается от перечеркнутого овальчика) и не собирается понимать, так как для данного конкретного документа нотация изображения роли не играет.
Эх, побольше бы таких Заказчиков, обсуждение с которыми упирается в особенности применения стандартов UML и лучших практик описания юзкейсов! По моим наблюдениям на этом этапе, как правило идет обсуждение ПО СУТИ автоматизируемых процессов и главные трудности описания Заказчиком устройства деятельности предприятия в крупных формах связаны с противоречиями и "наворотами" в собственных представлениях Зазказчика о бизнес-логике предприятия, а не в столкновении этой бизнес-логики с теми или иными особенностями стандарта их описания, будь то стандарт диаграммы UML или текстового описания юзкейса.
По этому (как мне кажется) Коберн говорит: важна контекстная диаграмма, отражающая границы систем по отношению к действующим лицам и друг-другу (в качестве тех 20%, приносящих 80% ясности - это уже я говорю), но не так важно, чтобы на ней были все-все варианты использования и все связи между ними, для уяснения полного списка есть содержание текстового документа.
Извините, при всем уважении к Вашему стремлению быть правильно понятым, данные утверждения представляются нелостаточно аргументированными без подкрепления данного утверждения ссылками на текст Коберна (ведь речь идет именно о точке зрения Коберна, а не Вашей собственной).
Даже если принять данное представление об использовании диаграммы UC, в качестве истинной, такая трактовка её использования несколько отличается от зафиксированной стандартом UML superstructure, поскольку как раз границы системы не являются необходимыми для отображения: "If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle." (Use Case Notation, p. 579), т.е. "если (граница отбражается) то…"
-
На самом деле мне не понятно, таки почему это "дело обстоит не совсем так" ... и почему ТОЛЬКО диаграммы юзкейсов не должны вызывать скепсис?? Особенно если учесть тот факт, что практика использования только диаграмм юзкейсов фактически приводит к функциональной декомпозиции но на юзкейсах ... и запросто при этом встречаем ВИ "Отправка уведомления о регистрации на мероприятие", который в лучшем случае будет "included". Никто не отрицает, что использование диаграммы юзкейсов в качестве "оглавления", предваряющего собственно текстовые спецификации вполне полезно, более того, я сам часто использовал диаграммы ВИ в "Modern SRS", но обязательно за ними следовали и сами юзкейсы. Кроме этого еще и графически показывал связь м/у диаграммами уровня "облака" и "user goal". Так что речь тут в большей степени о том, что имеет смысл использовать диаграммы СОВМЕСТНО с текстовыми спецификациями ... Но при этом, одни текстовые спеки дают больше value, чем одни диаграммы.
1. Мне в принципе близок Ваш подход к использованию диаграмм юзкейсов. Когда я писал о том что "дело обстоит не совсем так", это относилось к Вашему утверждению о том, что никто в принципе не возражает против использования диаграмм (в частности, юзкейсов, как я понимаю) в дополнение к текстовому описанию. Я указал, что Коберн в этом отношении занимает фактически более жесткую позицию по сравнению с Вашей. Цитаты , которые я привел, свидетельствуют о гораздо жестком оппонировании (фактически, возражении) использованию диаграмм, даже в дополнение к текстовому описанию. Нет практически ни одного примера использования диаграмм UML в его книге, в которых рассмотрение способов их использования не сопровождались бы впоследствии уничижительными замечаниями в адрес этих диаграмм, напрочь дезавуирующих любые утверждения об их возможной полезности, которые он делает перед этим. Цитаты в подтверждение я и привел в предыдущем посте.
2. Наряду с вопросами применения диаграмм в конкретных проектах, не менее интересным представляется применение диаграмм для формирования паттернов бизнес-уровня, которые ухватывали бы типовые модели ведения бизнеса. Бизнес-анализ в сфере менеджмента, управления предприятиями давно уже использует различные модели, также использующие диаграммные представления. Такие схемные представления широко распространены в так называемых развитых странах и нашли свое отражение и в модульных структурах ERP-систем. Да и в отечественном бизнесе термин "типовая схема управления" уже стала привычной . Несмотря на то, что управленцы давно понимают друг друга с полуслова и могут оперировать такими крупноблочными схемными представлениями для организации бизнеса, описание этих схем лишено той четкости, которая обычно требуется для задач автоматизации деятельности. В то же время при внедрении автоматизированных систем (особенно типовых решений) неизбежна встает задача выделения типовых схемы управления из всего многообразия подходов к управлению, культивируемых конкретным Заказчиком. И эта работа занимает существенную часть времени затрачиваемого на проектирование/внедрение системы.
При этом представляется важным решение двух задач:
1. Каким образом можно упорядочить системные представления о различных видах бизнеса с целью их дальнейшего применения в других проектах(ускорить, облегчить этап бизнес-анализа)?
2. Возможно ли обеспечить взаимопонимание IT и бизнес структур за счет использования близких (схемных?) представлений (ускорить, облегчить передачу информации о бизнесе разработчикам)?
Можно ли считать эффективным для целей п. 2 использование традиционных текстовых представлений?
Работа управленца - конструктора управленческих схем давно уже напоминает работу конструктора-машиностроителя и схемы (чертежи) давно уже стали неотъемлемой частью проектной документации. И схема управления давно уже не может быть заменена текстовым перечнем (содержанием) включающих её элементом. Для достаточно больших схем именно затраты на выстраивание структуры связей, а не разработку (приобретение) отдельных компонентов вносит основной вклад в valuе этих систем.
Отечественный бизнес пока дает достаточный простор для различных доморошенных фанатазий на тему управления, но при достижении определенного уровня этого бизнеса приобщение к мировой культуре управления становится актуальной и бизнес целиком предается в руки западных управленцев и IT-систем.
Вопрос: могут ли быть
1. разработаны типовые схемные представления о бизнесе (в том числе и зарубежном), учитывающие отечественную специфику и, возможно, опыт,
2. конкурентоспособные на мировом уровне и
3. сопрягаемые как с существующими моделями как в сфере менеджмента, так и IT, в частности, с использованием UML?
Как обеспечить сопряжение схемно мыслящего бизнеса и текстово мыслящего IT сообщества?
-
Я не совсем понимаю тему спора.
Книга Коберна направлена на использование современных методов описания функциональных требований к системам. Хотя такое переводное название на самом деле не отражает истинное название книги, которая достаточно четко ставить область ее использования и изучение: Написание эффективных вариантов использования.
Т.е. книга посвящена НАПИСАНИЮ, но не РИСОВАНИЮ вариантов использования. И отражает личный опыт и убеждения автора.
Использовать или не использовать диаграммы. Когда их использовать и в каком виде? Я думаю, по мере развития графических средств и инструментов моделирования, создания языков формального описания и т.п. будет происходить (и происходит) взаимопроникновение идеологии и понимания как в сферу бизнеса, так и в сферу ИТ.
Использование графических средств формализации на начальных стадиях развития проекта вполне оправдано. Еще более оправдано это, если и бизнес-анализ, и анализ приложения, его проектирование ведется в одном ключе с использованием единого подхода, нотаций и т.п. Конечно, это облегчает использование результатов бизнес-анализа в проектировании. Именно это мы и видим порой, когда изучаем некоторые примеры использования UML для бизнес-анализа, формирования бизнес-требований
-
Если вспомнить начало топика, то надо признать, что мы отклонились от темы.
Разговор был о том, что структуру самого ВИ можно нарисовать в виде Class Diagram.
Да, меня заинтересовала именно эта возможность, в целях прояснения для себя самого понятия ВИ.
изначально, даже при всей своей любви к диаграммам, я придерживался общепринятого принципа:
текстовое представления ВИ - основа,
диаграмка зависимостей ВИ - факультативный элемент.
Но в процессе работы над текстовым описанием ЮзКейса всегда хотелось иметь в голове или даже перед глазами хорошо проработанную диаграмму - модель понятий из предметной области под названием "как правильно писать ВИ", да ещё и с мэппингом элементов этой модели на поля ЮзКейс-шаблона.
В этом направлении и старался вынести вопросы на форум.
Похоже, получилось неудачно.
Или вопросы формулировал плохо, - или тема не интересная.
Обсуждение ушло в другом направлении, и у меня, по ходу его развития, возникли "крамольные" вопросы:
а может просто диаграмма ВИ сама по себе слабый инструмент?
а если её доработать, то и получится дать любителям визуальных представлений приличный инструмент для создания ЮзКейсов?
-
а может просто диаграмма ВИ сама по себе слабый инструмент?
давай рассуждать логически и исторически.
Сами варианты использования придуманы и введены ц употребление Якобсоном. Сначала они назывались usage case, потом превратились в брендовое название use case. Как я понимаю, исходно, это были действительно текстовые сценарии. Возможно содержащие простое описание и позволяющие структурное связывание. После объединения усилий по разработке единого стандарта объектной парадигмы, варианты использования были включены в нотацию UML. Овалы предназначены, на мой взгляд, для задания контекста и скрытия деталей на определенном уровне абстракции - классическая инкапсуляция. Детали варианта использования в зависимости от уровня представления раскрываются в текстовом описании или использовании других диаграмм: диграмм деятельности, последовательности и даже состояний.
Рамбо говорит, используйет текстовое описание там где это действительно проще и понятнее, а диаграмму деятельности лучше использовать, если ВИ имеет сложную структуру. Для отображения временной зависимости и отображения деталей используется диаграмма последовательности, которая в при проектировании классов еще добавляет и операции классов.
Диаграмма вариантов использования начинается с простого перечисления действующих лиц (лиц которые используют системы) и вариантов использования этой системы ими. Этот уровень хорош для последующих дискуссий и правильного понимания функциональности системы с разных точек зрения. Т.е. каждое действующее лицо символизирует определенную точку зрения на функциональность системы.
На уровне бизнеса или на уровне системы все это отображджает внешний взгляд на систему как черного ящика - ее устройство скрыто, внимание сосредоточено на том, что должна делать система для удоволетворения потребностей ДЛ и какие внешние связи-интерфейсы должны быть установлены.
При переходе на системный уровень естественно возникнет желание структурировать диаграмму ВИ: с помощью зависимостей включения, расширения или связей обобщения. В результате первоначальный набор возможно и сохраняется, взаимное соотношение составных элементов может изменится: номральный приницп системного анализа: модель состава перетекает в модель структуры.
Использование графических средств на ранних этапах позволяет моделировать разные слои решения в едином подходе, сокращая этап разработки и обеспечивае повторное использование ранее созданных элементов.
Конечно, можно разработать структуру, некую инструкцию, систему тестовых вопросов, но будет ли польза, поскольку веротяно ВИ одна и с самых неформальных частей проекта, на мой взгляд.
Я вот сейчас изучаю Telelogic System Architect. Он пока поддерживает версию 1.3 или 1.4 UML, но например там реализован такой инструментарий: делаешь диаграмму ВИ, входишь в редактирование самого ВИ, а там целый шаблон в виде формы ввода: шаги, предусловия, постусловия и т.п. Хорошо это или нет, удобнее такой подход или нет (по сравнению например с написанием в виде докмента док и подключения как гиперссылки) Возможно тут есть преимущество сопровождения, формирования отчета, использования трассировочного инструмента DOORS. Вероятно, из такой структуру при желании можно сгенерировать диаграмму дейятельности (правда я еще не пробывал только начал изучение)
Вряд ли имеет смысл говорить о слабости инструментов или проработке стандарта. Вероятно будет все это иметь смысл, когда будет придуман и реализован исполняемый UML во всех его проявлениях