2Irr
А для BPMN пока кроме Visio не видел ничего, но там синтаксис не контролируется. Есть есть что лучше для BPMN, буду признателен за информацию...

Средства для рисования BPMN мы как раз обсуждали в ветке http://www.uml2.ru/forum/index.php?topic=150.0
Сразу могу сказать, что в EA есть валидация модели по синтаксису BPMN. С error'ами и worning'ами. Я проверяла :-)

А вы не догадываетесь? Просто он пока не так распространён, его нотацию не поддерживают популярные диаграммеры, по нему нет литературы, учебных курсов. А за IDEF (и SADT вообще) стоит старая школа аналитиков, менеджеров и т.д.

А ларчик просто открывался...
Я думала, вдруг тут зарыта какая-нибудь методологическая собака. А тут всего лишь особенности распространения, их я тоже заметила

А как тогда понимать IDEF4 - Object-Oriented Design, IDEF10 - Implementation Architecture Modeling, IDEF11 - Information Artifact Modeling, IDEF12 - Organization Modeling, IDEF13 - Three Schema Mapping Design, IDEF14 - Network Design?

Кстати, я бы не отказался увидеть IDEF8 - User Interface Modeling в нормальном виде, а то у меня картинки битые.

А есть возможность увидеть где-нибудь спецификации всех этих IDEFX? А то я маньяк-коллекционер :-)

А как тогда понимать IDEF4 - Object-Oriented Design, IDEF10 - Implementation Architecture Modeling, IDEF11 - Information Artifact Modeling, IDEF12 - Organization Modeling, IDEF13 - Three Schema Mapping Design, IDEF14 - Network Design?

А вот для всего этого (с 4-го по 14-й) и существует UML :-)
За исключением User Interface Modeling.
IDEF4 - схемы получились очень поверхностными. На них не отображается некоторая существенная и важная для разработчика часть информации, которая отображается на диаграммах классов в UML и на диаграммах последовательностей (инициализация объекта). Кроме того, некоторые вещи разбиты на 4 разных вида диаграмм в IDEF4. Это сколько же времени нужно потратить, сколько листов бумаги перевернуть... IMHO, "слишком много букафф" - это тоже не есть хорошо. Информация должна подаваться в концентрированном виде.
И потом, опять же, рассеивать информацию по 10 разным видам диаграмм или попытаться собрать ее  в 4-х или 5-ти видах - есть разница, правда?
Словом, все, что выше 3-ки в IDEF - довольно тяжеловесно.
Поэтому Буч, Рембо и Якобсон не зря потратили свое время. Кстати, одним из самых выдающихся ходов в UML я считаю разделение диаграмм на статические и динамические. На динамических в концентрированном виде преподносится все то, что мы хотели бы узнать о поведении модели.
В IDEF же, мне кажется, несколько наивный подход: есть такая вещь как классы - рисуем классы. Есть такая вещь как методы - рисуем методы. А есть аргументы - рисуем и их. На разных диаграммах, причем. Это как раз то, что в первую очередь может прийти в голову человеку с аналитическим складом ума.
А вот у создателей UML, как мне кажется, все-таки преобладает синтетическое мышление.

А есть возможность увидеть где-нибудь спецификации всех этих IDEFX? А то я маньяк-коллекционер :-)

Спецификации IDEF(0-3) - в архиве в PDF на той странице, которая явилась поводом для дебатов. Ссылка под названием "Текст стандартов IDEF".
Насчет всех - пока не знаю.

Для начала, посмотрите сюда: http://www.idef.com/ или http://www.idef.ru/ или http://idef0.ru/ или http://www.cfin.ru/vernikov/idef/
У меня в архивах есть pdf для 0-5, а также 9:
bpr.pdf
compendium.pdf
idef0.pdf
IDEF0_KB.PDF
IDEF1MR-part1.pdf
IDEF1MR-part2.pdf
Idef1x.pdf
Idef3_fn.pdf
idef3_kbsi_report.pdf
Idef4.pdf
Idef5.pdf
Idef9.pdf
IDEFFAMI.pdf

"Может просто не повезло IDEF? Появился UML и другие передовые нотации, в этом может дело?"
Нет. UML - не замена IDEF, и он не "более прогрессивен".
Просто у IDEF и UML - разные задачи. IDEF - это функциональный подход. В фокусе процесс, а не объект (за исключением разве что IDEF1x).

Да конечно я прекрасно это понимаю.
IDEF0 или лучше сказать то, что составляет SADT, а сюда входят еще и DFD (кстати в литературе встречал такое высказывание, что мол есть IDEF0 и SADT(т.е. DFD) - очень был удивлен такой информации), также SDT (так кажетcя) - безусловно даже позиционируется как функциональное моделирование и составляет чаксть структурного подхода в анализе и проектировании систем. Это подход отрывает данные и функции, за что его часто и критикуют применительно к программным системам.
Опять же имеет смысл немного углубиться в историю. Расцвет CASE средств приходится на начало 90-х и произошел благодаря активному распространнению объектной парадигмы. Именно CASE срества стали реальными благодаря ООП. Развитие идея ООП столкнулось с проблемой средств описания задач и систем для реализации их как раз на ООЯ.
А поскольку была проблема описания, были попытки применить для этого имеющиеся структурные методы. Опыт оказался неочень удачным, за исключением средств для моделирования и проектирования реляционных БД. Результатом и стали методы типа Гради Буча, которые объединившись, дали UML.
Однако переход к UML требовал перестройки мышления, потому IDEF и DFD остаются актуальными. Кроме того, нужно признать, что в определенном смысле у IDEF и DFD есть свои очень эффективные средства для выражения.
Тот же Маклаков предлагает подход синтеза IDEF0 и диаграмм вариантов использования. Да и Скотт Амблер частенько показывает более эффективное использование DFD для определенных целей.
Как мне думается, изначально ниша UML - это диаграммы классов и им сопутствующие. Варианты использования - вовсе не оо подход, а другой вид на описание системы. Диаграмма ВИ куда более применима для описания пользователей и функциональности системы, которую эти пользователи хотят видеть в системе. Здесь это проявляется куда четче, чем например в DFD. А IDEF0 совсем в этом смылсе не применим.
Да IDEF0 безусловно гораздо более применим для материально-технических, чем информационных систем. потому его лучше позиционировать именно как инструмент бизнес-моделирования, выделение подсистем, модулей и т.п.
 
 

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

Вполне возможно. Тем более, что структурным метододам и структурному типу мышления в программировании пока боьше лет, чем  ООП, да и ООП не перекрывает всех возможностей или лучше сказать является наследником структурного метода.

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

Абсолютно с Вами согласен.

Когда мы переходим к проектированию системы, в фокусе уже не процессы, а объекты и взаимодействия между ними. UML возник тогда, когда объектно-ориентированный подход к программированию стал нормой, и предназначен именно для того, чтобы строить архитектурные модели. Использовать его в каких-то других целях, наверное, можно, но лично мне представляется нецелесообразным.

Однако мир состоит из объектов, а не функций и процессов. Функции и процессы есть стороны хаарактеристики функционирования объектов. Но все зависит от типа декомпозиции, и многие дороги ведут в Рим.

Я видела, разумеется, попытки использовать UML (точнее, Use Cases) для функционального описания системы, но...
В фокусе Use Case - не функция. В фокусе Use Case - цель, ради которой выполняется то-то и то-то. Попытки подменить одно другим, как правило, приводят к очень печальному результату.

На нашем сайте есть методичка - http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=72.
Может она подаст Вам несколько идей. Но согласен, что возможно use case не столь специфичен. Хотя мои студенты настолько навострились описывать бизнес-процессы с помощью use case, что теперь я не могу никак их переучить писать системные варианты использования

По всем пунктам - уточнения:
IDEF и CASE - разные вещи. :-)
SADT и CASE - тоже. :-) SADT - это всего лишь "идеологическая основа" для IDEF, насколько я понимаю.
1-я редакция IDEF0 - начало 80-х, а не 90-х. В это время люди еще вовсю на FORTRAN'е писали. Не все, конечно, но многие. Например, в CERN "официальным языком" той поры был FORTRAN :-) А у некоторых прихвостней Западапрогрессивных организаций в ходу был ANSI C.
Сейчас, конечно, все перешли на C++. Даже те, кто не смог освоить C++, оставили FORTRAN и пишут на ANSI C. Ну или на Java, на худой конец.
Маклаков - умный дядька. Я тоже часто так делаю (о чем, собственно, и речь была в начале).
Про UML в описании БП - ну, я не спорю, при помощи универсального, мощного языка пожно описать все что угодно.
Но
бизнес-модель включает в себя следующие ключевые компоненты
* бизнес-функции, описывающие, ЧТО делает бизнес;
* бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;
* организационную структуру, определяющую, ГДЕ исполняются бизнес-функции и бизнес-процессы;
* фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
* роли, определяющие, КТО исполняет бизнес-процессы;
* правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.
Для описания БП необходимо включить в модель бизнес-процессов следующие атрибуты процессов:
* воздействия, инициирующие каждый шаг бизнес-процесса;
* исполнителей каждого шага;
* воздействия, регламентирующие данный шаг;
* результат, получаемый на выходе конкретного шага бизнес-процесса.

Если пункт второй (исполнители) с грехом пополам еще можно нарисовать в UML, то что делать с остальными - непонятно.
А вот в IDEF0 с ними ясно, что делать.

Я думаю, что с использованием стереотипов и надписей на связях в UML можно выкрутиться в области рисования бизнес-процессов. Туда ложатся любые множества объектов и связей между ними. Согласен, что не всегда есть в этом смысл, точнее - это не очень удобно.

Выкрутиться можно, но неподготовленному человеку придется очень много объяснять, что же это такое. + Если вы подрядчик, а у заказчика несколько проектов, и каждый из подрядчиков использует свою нотацию (UML с выкрутасами, ARIS, IDEF), то будет очень сложно :-)

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

Да, и для меня сквозная трассировка слоев требований, архитектуры, тестирования - одна из основных ценностей моделирования в целом :-) С учетом трудности понимания заказчиком UML'я при описании бизнес-процессов пока вижу один выход: связка BPMN (бизнес-модель) + UML (модели требований, анализа, архитектуры). Средства, которые поддерживают и то, и другое уже есть, например, Enterprise Architect. Но пока такая связка еще в стадии исследования, т.е. решение еще не проверено полностью: нет у меня пока ни готовой модели, ни нотации и правил трассировок между слоями, хотя EA между элементами BPMN и UML коннекторы рисует легко :-)

Но пока такая связка еще в стадии исследования, т.е. решение еще не проверено полностью: нет у меня пока ни готовой модели, ни нотации и правил трассировок между слоями, хотя EA между элементами BPMN и UML коннекторы рисует легко :-)

Как будет - интересно было бы почитать небольшой отчетик. А может даже семинар на эту тему сделать.

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

Сейчас трассировка (технически) - не проблема, даже если мы используем разные инструменты для моделирования бизнес-процессов и архитектуры. Telelogic и IBM это делают, насчет остальных - сама не пробовала, но подозреваю, что тоже умеют.
Что конкретно использовать - думаю, здесь просто нужно посмотреть, что будет удобнее. И к чему привыкла Ваша команда. Потому что переходить от одного инструмента для моделирования к другому нужно все-таки не потому, что "так хочется" или "кто-то считает это более прогрессивным", а после:
* детальной проработки требований к этому инструменту (т.е. формулирования принципа, "почему нам без этого не обойтись")
* обучения всех участников процесса работе с этим инструментом.
* выполнения как минимум одного пилотного проекта с использованием этого инструментария.

Как будет - интересно было бы почитать небольшой отчетик. А может даже семинар на эту тему сделать.

Создание отчета у меня в планах, но это замедляется тем, что я пока слабо разобралась в самой нотации BPMN, из-за этого я попробовала еще не все функции EA для BPMN, мало информации для отчета.

С учетом трудности понимания заказчиком UML'я при описании бизнес-процессов пока вижу один выход: связка BPMN (бизнес-модель) + UML (модели требований, анализа, архитектуры). Средства, которые поддерживают и то, и другое уже есть, например, Enterprise Architect. Но пока такая связка еще в стадии исследования, т.е. решение еще не проверено полностью:

Могу сказать с уверенностью решение есть и очень хорошее. Дороговатое, вероятно, но тут извините.
Это решение называется фирма Teleleogic.
Для начала - поскольку всем тут очень важна бизнес-составляющая (а мое мнение, это вообще отдельная тема: бизнес-моделирование и далее проектирование ИТ-решения), то инструмент System Architect идеален - он не просто поддерживает все мыслимые на сегодняшний день нотации, но и дает средства интеграции всего этого богатства в рамках какого-либо фреймвёрка, например Захмана и других, в том числе ориентированных на стандарт IDEF.

Далее идет прямая интеграция с DOORS для документирования и управления требованиями.

Потом переходим к UML средствам для проектирования системы в ООП парадигме, используя Rapsody или Tau

наташа, мой ответ. Не сочтите за позерство, но

IDEF и CASE - разные вещи. :-)
SADT и CASE - тоже. :-)

Кто бы сомневался, но, по-моему, я не где не ставлю знака равенства.

SADT - это всего лишь "идеологическая основа" для IDEF, насколько я понимаю.

Почитайте, например, выдержку отсюда и отсюда.

1-я редакция IDEF0 - начало 80-х, а не 90-х.

Я же не про редакцию говорил, а про инструменты. А как вы заметили, это две большие разницы. А вообще если вы почитали ссылки, SADT = IDEF0, просто одно скажем так научное название предложенное автором и последователями, а IDEF0 название стандарта принятого США, после успешного его применения для формирования бюджета, кажется.
 

Сейчас, конечно, все перешли на C++. Даже те, кто не смог освоить C++, оставили FORTRAN и пишут на ANSI C. Ну или на Java, на худой конец.

А некоторые пишут на Delphi, php, Ruby, и т.п.

Маклаков - умный дядька.

Только книги его страдают техницизмом, а практической работы в них очень мало. От того ценность его книг маловата. Правда в статьях отыгрывается. Думаю это он спецом делает, иначе кто к нему на курсы будет ходить

бизнес-модель включает в себя следующие ключевые компоненты
* бизнес-функции, описывающие, ЧТО делает бизнес;

диаграммы деятельности, последовательности, состояний + описание

* бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;

Варианты использования и сценарии уровня бизнеса.

* организационную структуру, определяющую, ГДЕ исполняются бизнес-функции и бизнес-процессы;

диаграмма классов - читай актеров

* фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;

Excel- таблицы не подойдут? Можно и диаграмму состояний
 

* роли, определяющие, КТО исполняет бизнес-процессы;

диаграмма классов - читай актеров

* правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.

особые требования в сценариях, сторожевые условия, тегированные значения + таблицы, таблицы или текст...
 

Для описания БП необходимо включить в модель бизнес-процессов следующие атрибуты процессов:
* воздействия, инициирующие каждый шаг бизнес-процесса;

предусловия в описании варианта использования

* исполнителей каждого шага;

шаги сценария в стиле прозрачный ящик с описанием бизнес-вокеров или диаграмма деятельности с "дорожками" отвественности

* воздействия, регламентирующие данный шаг;

сторожевые условия, комментарии, тегированные значения, ограничения

* результат, получаемый на выходе конкретного шага бизнес-процесса.

постусловия, особые и доптребования в описании сценария.

Если пункт второй (исполнители) с грехом пополам еще можно нарисовать в UML, то что делать с остальными - непонятно.

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

А вот в IDEF0 с ними ясно, что делать.

Да в IDEF0 есть четкие позиции для входов: управление, механизм или чистые входы. Но тажа нотация Эриксона-Пенкера лекго интегрируется в UML диаграммы.
Но опять же - дело вкуса, дело широты кругозора и практики обучения.


[/quote]

...
И потом, опять же, рассеивать информацию по 10 разным видам диаграмм или попытаться собрать ее  в 4-х или 5-ти видах - есть разница, правда?
Словом, все, что выше 3-ки в IDEF - довольно тяжеловесно.

Поэтому Буч, Рембо и Якобсон не зря потратили свое время. Кстати, одним из самых выдающихся ходов в UML я считаю разделение диаграмм на статические и динамические. На динамических в концентрированном виде преподносится все то, что мы хотели бы узнать о поведении модели.

В IDEF же, мне кажется, несколько наивный подход: есть такая вещь как классы - рисуем классы. Есть такая вещь как методы - рисуем методы. А есть аргументы - рисуем и их. На разных диаграммах, причем. Это как раз то, что в первую очередь может прийти в голову человеку с аналитическим складом ума.
А вот у создателей UML, как мне кажется, все-таки преобладает синтетическое мышление.

Ну не сказал бы, наибольшей интегрированностью и полнотой диаграмм всё-таки обладают ARIS eEPC и IDEF0. У первого на одной диаграмме отображаются действия, ресурсы, исполнители, документы, механизмы, у второго почти то же самое, только менее наглядно. А вот в UML на каждом типе диаграмм отображаются только 2-3 категории моделирования, причём наверное действительно классы их них самая богатая.

Мне кажется более вероятными следующие причины такой разницы в подходах между функциональными нотациями методологиями 60-70х и объектными 80-90-х - во времена первых в мире ИС доминировали ТРАНСФОРМАЦИОННЫЕ системы, которые сильно напоминали обычное производство, а в последние десятилетия доминируют РЕАКТИВНЫЕ системы, в которых на первое место вышли взаимодействия и которые потребовали для себя новых инструментов.

Вот что об этом пишет R.J. Wieringa в книге "Design Methods for Reactive Systems: Yourdon, Statemate, and the UML", точнее, он делает акцент на необходимости моделирования того, что он называет "окружением" (environment):

"A reactive system is a system that, when switched on, is able to create desired effects in its environment by enabling, enforcing, or preventing events in the environment. For example, real-time, embedded, and control systems are reactive systems because, when they are switched on, they enforce a certain desirable behavior on their environment. Information systems, groupware systems, workflow management systems, ERP systems, e-commerce systems, and EDI systems are reactive too because they provide desired information and enable communication and collaboration between people or organizations in their environment. Other examples of reactive systems are word processors and operating systems.

...

Reactive systems can be contrasted with transformational systems, which exist to transform an input into an output. Compilers, assemblers, and routines in a library of mathematical functions are transformational systems. The execution of a database query can also be viewed as a transformational system; the query execution maps a query and a database state into a set of data. The entire database server, however, is reactive because it exists to allow its environment to ask queries. A diagnostic expert system is a transformational system; it may enter an interactive dialog to acquire all relevant data about a malfunctioning machine, but when all data are provided, the expert system will produce its diagnosis as output, after which it is finished.

...

Methods for the design of transformational systems must specify the transformation to be computed by the system, the logical structure of the input and output data, and the algorithm that computes the transformation. The behavior and structure of the environment is not particularly important for these systems. They will perform the same transformation in different environments. A widely used design approach for transformational systems is, therefore, functional decomposition, a method by which external functionality is mapped to internal components of the system.

By contrast, reactive systems are in close interaction with their environment. Design methods for reactive systems must contain techniques to describe the environment and the structure of the interaction with the environment. Functional decomposition is not the only nor the most important design approach for reactive systems; the structure of the environment is at least as important."