181

Варианты Использования (Use Case) / Re: Структурные Диаграммы представления ВИ

« : 08 Апреля 2007, 21:28:45 »

Как я понял Коберна, он никогда не отрицал (и даже наоборот) роли контекстной диаграммы (на которой показаны границы систем, действующие лица и основные цели). В частности эта диаграмма может быть сделана с использованием 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), т.е. "если (граница отбражается) то…"

182

Варианты Использования (Use Case) / Re: Структурные Диаграммы представления ВИ

« : 07 Апреля 2007, 21:53:35 »

Скепсис в большей степени вызывают не столько сами диаграммы, сколько "только диаграммы" (читай "только диаграммы юзкейсов и ничего больше").

К сожалению, дело обстоит не совсем так.  Цитата из Коберна (стр 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, но к сожалению его взгляд на использование графических средств анализа и представления результатов является шагом назад, который серьезно оппонирует попыткам создания новых средств анализа и моделирования даже в качестве дополнительных к "текстовым инструментам" .

183

Варианты Использования (Use Case) / Re: Структурные Диаграммы представления ВИ

« : 06 Апреля 2007, 00:58:46 »

А насчет использования дигарамм UC, поднятой автором этой темы, ИМХО значительная часть скепсиса по поводу их применения связана с тем, что их "просто не умеют готовить".  То, что диграмма UC дает возможность окинуть общим взглядом предстоящее поле деятельности, отобразить основных фигурантов проекта (декомпозировать, как правило, еще нечего) и в какие именно специальные области деятельности эти фигуранты-акторы вовлечены, позволяет эффективно использовать диаграмму в качестве карты (roadmap) для обсуждения с самими акторами диаграммы, а также основы для дальнейшей детализации этих видов деятельности. Поэтому эта диаграмма ИМХО может быть целиком отнесена к арсеналу средств бизнес-аналитика.

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

По мере доработки диаграммы по результатам обсуждения, сам факт, какие акторы с какими областями  деятельности (трактуемыми как элементы диаграммы - собственно UC) связаны часто оказывается весьма информативным для обсуждения и даже неожиданным для некоторых интервьюируемых акторов, позволяют отделить важное от второстепенного. Гляда на диаграмму собседник при повторном обсуждении часто вспоминает важные детали.

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

К сожалению, в практике автоматизации бизнеса (особенно отечественного) очень часто задачи автоматизации отдельных видов деятельности превалируют на собственно интеграциоными задачами. Там где фактически идет автоматизации технологического процесса, связанного с конкретной профессиональной специализацией, детальное описание процесса (алгоритм) часто явлется единственно значимым для работы. Попытка рисовать юзкейсы для таких работ приводит к тому, что в качестве юзкейсов на таких диаграммах появляются обезличенные универсальные операции. Взаимосвязь таких операций с акторами и между собой без наглядной причнно-следственно связи получается достаточно бессмысленной (имею в виде именно диагрмму UC, а не диаграммы взимодействия и пр.). Особенно забавно, когда такие юзкейсы в руководствах по UML рисуют именно для таких случаев - типа "актор наливает себе чашку кофе" .
 
Практике текстового описания алгоритмов столько же лет, сколько программированию, широкое же применение диаграмм в качестве специального инструмента (а не иллюстративного материала)  менеджмента и анализа бизнеса  началось гораздо позже - примерно в 70-е годы 20 века. Возможно, этот факт играет не последню роль в отношении к графическим средствам описания и анализа бизнес- процессов...

184

Системный Анализ и Требования / Re: Исторические основания системного анализа

« : 03 Апреля 2007, 18:57:09 »

Были люди, которые изучали и пропагандировали системный анализ  еще в советские времена, с соблюдением смысла и содержания, который вкладывали в эту область знаний те, кто её в это время формировал. В частности,  С. Никаноров: 

Есть перевод работы Оптнера с предисловием С. Никанорова.

185

Системный Анализ и Требования / Re: Исторические основания системного анализа

« : 01 Апреля 2007, 23:36:23 »

История и описание содержания системного анализа в отечественной и англоязыной литературе заметно отличается. Например, в Википедии приводится следующее определение, данное академиком Н.Н.Моисеевым:
«Системный анализ — это совокупность методов, основанных на использовании ЭВМ и ориентированных на исследование сложных систем — технических, экономических, экологических и т.д. Результатом системных исследований является, как правило, выбор вполне определенной альтернативы: плана развития региона, параметров конструкции и т.д. Поэтому истоки системного анализа, его методические концепции лежат в тех дисциплинах, которые занимаются проблемами принятия решений: теории операций и общей теории управления». Несмотря на то, что он оговаривается, что дает достаточно узкое определение "системного анализа", такое понимание в целом достаточно характерно для отечественных специалистов.

В отличие от от отечественных теоретиков системного анализа, англоязычные источники, непример, (1), (2) дают более развернутую историю системного анализа, причем возникновение системного анализ датируется достаточно однозначно сороковыми годами 20 века.

В зарубежных источниках появление системного анализа связывают с попытками применять подходы и методы работы, характерные для научных и инженерных дисциплин, к более широкому кругу явлений и процессов, связанных человеческой деятельностью. Этот шаг собственно и связывают с появлением системного анализа.
Как правило, при обсуждении предмета системного анализа речь идет не просто о сложных инженерных системах (системы оружия и пр.) а о комплексе продуктов, способах их изготовления, а также, что существенно, организации их производства, использования и управления этими процессами. Т.е. предпринимается попытка рассмотрения как некоего единого целого не просто "сложных систем", а процессов различной природы (технических и традиционно относивших к "гумантарной" природе человека). Новые системные продукты также получаются за счет взаимодействия специалистов различных направлений, взимного "проникновения" знаний и технологий между дисциплинами, ранее развивавшимися относительно независимо.

К сожалению, в отечественных исторических материалах "дискретность" возникновения системного анализа вуалируется, основания для его возникновения также артикулированного не проговариваются (отголоски гонения марксистов на кибернетиков?). При этом акцентируется трактовка системного анализ как "просто" анализа любого, к чему приложимо определение "сложный"...

186

Конференции Семинары и Тренинги / Re: МСК - Семинар "Разработка требований и состава работ"

« : 31 Марта 2007, 12:06:26 »

Если различать:
1. способы, приемы, методы мышления, анализа ситуации, применяемые конкретным аналитиком для выделения и упорядочивания  для себя значимой для дальнейшей работы (и обсуждения) информации (в частности, для формулирования требований).
2. способы явного представляения информации в соответствии с принятыми стандартами:
- предполагающими оперирование явно очерченным набором понятий,
-детерминированной стандартом логикой взаимосвязи между ними, а аткже
- представление информации в предписаных стандартом нотациях,
в виде пригодном для представления информации другим участниками проекта.

Предложенный на семинаре подход представляет собой интересную попытку акцентировать значимость средств анализа (мышления) аналитика, соответствующих п.1.
Грубо говоря - есть карта с центральным элементом, который фокусирует внимание аналитика на организацию информации вокруг центрального (организующего таким образом всю схемы) эемента. "Недопущение" возникновения других таких организующих фокусов на схеме обеспечивает целостность представления информации о системе. Целостность, понимается как подчиненность всей информации единому, центральному организующему началу, изображаемому на схеме-карте центральным элементом.
Не умаляя значимости конкретных рекомендаций по способам применения предложенной методики, представляется весьма важным отметить данное качество  (п.1) предложенного подхода.