Например, такая ситуация:
контекст: абонемент библиотеки
- вход: прочитанная книга
- выход: запись в читательском о том, что книга возвращена
- функ. блок: принять книги

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

На самом деле книга остается в модели; может, например, перейти в два потока: идентифицированные книги и неидентифицированные.
Читательский билет на входе и читательский билет на выходе. Внутри есть функция по его модификации, но сущность не меняется. Если запись ведется в отдельном журнале или как отдельная сущность вводится в компьютер, то ее можно учитывать в моделировании как порожденную.

Есть более изощренные моменты:
контекст: абонемент библиотеки
- вход: читательский билет
- выход: электронный формуляр читателя
- процесс: идентификация читателя

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

вопрос: читательский билет преобразуется в ходе идентификации в формуляр читателя
ответ: ну в общем, так и есть

Аналогично предыдущему. Важно! Читательский билет возвращается читателю, но по нему определен формуляр. На вход идут: читательский билет, база формуляров. Управляющим: правило определения. Выход: читательский билет - обратно читателю надо направить (по идее его надо провести за рамки системы), формуляр читателя.

внимание далее:
- вход: электронный формуляр читателя
- выход: формуляр читателя с отметкой о сдаче
- процесс: списание книги с формуляра читателя

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

Внимание вопрос к аудитории: Скажите, пожалуйста, а как вы объясняете, производите обзор и рецензию в подобных случаях? Какие правила и проверки вы используете? Спасибо

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

Отлично! Обратите внимание чек в оригинале есть. Задача заведома содержала ошибку, по товарам мы согласовали потоки, а по деньгам? Деньги аккумулируются в блоке? Во что они должны трансформироваться?
Достаточно ли нам данных для формирования чека? Откуда следует брать по-вашему эти данные?

По чеку: ориентировался на рисунок.
ИМХО, По остальным вопросам: опирать при моделировании необходимо на:
1. Границы описания - юзкейсы. Юзкейс по А. Кобурну "Эффективное написание юзкейсов": Экземпляр юзкейса (сценарий) это последовательность действий, выполняемых в системе, которые позволяют получить результат, наблюдаемый для актера этой системы, юзкейс определяется как совокупность всех своих сценариев. (конец цитаты). Ключевое слово для меня: позволяет получить результат для актера системы. Покупатель приходит за покупкой в магазин в данном случае может быть границей моделирования. Все сущности я стараюсь протягивать из вне модели (т.е. деньги покупатель приносит с собой, цены на товары и ассортимент тоже входные даннные (за границами моделирования), ну и так далее...
2. Все объекты приходящие в юзкейс снаружи должны из него выйти в том или ином виде (тоже физичном). Такой "закон сохранения материи" )))

Прекрасный анализ, но давайте договорим о треминологии.

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

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

По чеку: ориентировался на рисунок.

Ваша правда, обшибся при перерисовывании

ИМХО, По остальным вопросам: опирать при моделировании необходимо на:
1. Границы описания - юзкейсы.

Что такое юзкейсы - догадываюсь. Но правильно ли будет отождествлять юзкей и функциональный блок IDEF0. Лично я не отождествляю, поскольку иначе мы впадем в крамольную ситуация: функциональная декомпозиция юзкейса!

Ваша правда, обшибся при перерисовывании
Что такое юзкейсы - догадываюсь. Но правильно ли будет отождествлять юзкей и функциональный блок IDEF0. Лично я не отождествляю, поскольку иначе мы впадем в крамольную ситуация: функциональная декомпозиция юзкейса!

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

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

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

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

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

Эдуард, попробуйте попользовать некоторое время нотацию Щедровицкого. Она малоизвестна, но мне кажется она хорошо прочищает мозг. После нее станет проще верифицировать нотацию IDEF0.
Понятно, что это IMHO, но все таки настоятельно рекомендую.

Эдуард, попробуйте попользовать некоторое время нотацию Щедровицкого. Она малоизвестна, но мне кажется она хорошо прочищает мозг. После нее станет проще верифицировать нотацию IDEF0.
Понятно, что это IMHO, но все таки настоятельно рекомендую.

Сергей, а где можно с этой нотацией познакомится? Ссылок не укажешь?

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

В данной дискуссии, я пытался ответить участникам (и себе )) ) на вопрос: как сам определяю моделируемые сущности, т.е. выделяю необходимые для модели.

Подход, который использую, не всегда работает при наличии состояний у одного объекта. Типичная проблема: "электронный формуляр" и "электронный формуляр с записью о возврате книги" разделить четко не удается. У меня это получается одна сущность и функция в глубине модели (2 и глубже уровень), которая производит над сущностью изменения. Хотелось бы услышать мнения коллег, как они решают подобные задачи.

Эдуард, попробуйте попользовать некоторое время нотацию Щедровицкого. Она малоизвестна, но мне кажется она хорошо прочищает мозг. После нее станет проще верифицировать нотацию IDEF0.

Присоединяюсь к вопросу о ссылках - изучить очень интересно.

Спасибо, gshamanov. Ваше мнение действительно интересно, чувствую, что Вы все это пропустили через себя.

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

Тем не менее нотация IDEF0 без большого акцентирования на ней как на стандарте, достаточна удобная нотация для объяснение некоторых подходов: функционального, процедурного, алгоритмического, кибернетического.

Хотя я понимаю гибкость и выразительность eEPC, BPMN. Универсальность use cases. Понимаю и жесткую ограниченность IDEF0, но, возможно, именно эта ограниченность, жесткость, порой искусственная, не дает растечься мыслью по древу?

Мне понравилась мысль Водолея  в ходе моделирования писать нечто вроде user stories на тему моделирования. Мне кажется, имеет так же смысл делать обмен моделями между студентами и обсуждениями того, что и как понял и соответствует ли это тому, что хотели сказать авторы (правда времени мало).

Вот собираю практические правила и практики. которым возможно надо следовать ...

Пардон за задержку.

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

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

Как ты определяешь (какие критерии) что две функции одинаковы/различны по нагрузке?

если коротко - "я так вижу!" (с) :о))) т.е. мне обычно не нужно много над этим думать - привычка выработалась. бывают, конечно, разные случаи, но, т.к. рука набита (скромн.), обычно все получается быстро. сегодня как раз обсуждали тему моделирования, так коллеги отводят на формулировку и уточнение  названия функции чуть не треть всего времени моделирования (на самом деле от 20 до 30 процентов). с этим я, конечно, не согласен.

Да согласен может и так. Что исключить книгу из рассмотрения?

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

с таким же успехом можно и водку арендовать - в Ебурге / Челябе на этом целый бизнес построен и в некотором смысле даже формуляры есть, не говоря уже о CRM  :о))

не могу сказать, что понял посыл данной фразы. повтори плиз?

Без проблем

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

:о))

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

Подход, который использую, не всегда работает при наличии состояний у одного объекта. Типичная проблема: "электронный формуляр" и "электронный формуляр с записью о возврате книги" разделить четко не удается. У меня это получается одна сущность и функция в глубине модели (2 и глубже уровень), которая производит над сущностью изменения. Хотелось бы услышать мнения коллег, как они решают подобные задачи.

дело в том, что это РАЗНЫЕ сущности, а Вы, видимо, подходите к ним как к одной.
поясню. насколько я понял, формуляр книги (эдакий вкладыш) содержит данные о предыдущих выдачах/сдачах книги, т.е. по сути является базой данных о перемещениях книги между читателями и библиотекой. записями (сущностями) этой базы данных являются отдельные операции выдачи/сдачи со своими данными о читателе и дате.
так что ложки нет...

P.S. 2 Galogen я что-то не уловил ранее. разговор идет только о сдаче книги читателем? т.е. это букинистический магазин, а не библиотека, получается? :о))
вообще говоря, система будет замкнутой, если добавить в нее выдачу книг читателям. тогда и поиск книг по каталогу добавится и т.п. операции, о которых я писал раньше

P.S. 2 Galogen я что-то не уловил ранее. разговор идет только о сдаче книги читателем? т.е. это букинистический магазин, а не библиотека, получается? :о))
вообще говоря, система будет замкнутой, если добавить в нее выдачу книг читателям. тогда и поиск книг по каталогу добавится и т.п. операции, о которых я писал раньше

Естественно. Просто в качестве примера выделен процесс Сдача книги читателем (такое выделение сделано студентами, и я не говорю. что это единственное представление ситуации)

если коротко - "я так вижу!" (с) :о))) т.е. мне обычно не нужно много над этим думать - привычка выработалась. бывают, конечно, разные случаи, но, т.к. рука набита (скромн.), обычно все получается быстро. сегодня как раз обсуждали тему моделирования, так коллеги отводят на формулировку и уточнение  названия функции чуть не треть всего времени моделирования (на самом деле от 20 до 30 процентов). с этим я, конечно, не согласен.

ну это понятно, только вот и надо вытащить модель твоих "видений" на поверхность наблюдаемого опыта:)

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

если все свести именно к информации, то ясно, что все объекты - информационные, а не реальные. Но если в системе циркулируют и те и другие?

Без проблем:о))
смысл в том, что суть анализа и построенной на его основе модели - определить информационные связи функций, а не их последовательность во временном аспекте

Ты полагаешь, что я это не понимал раньше?

дело в том, что это РАЗНЫЕ сущности, а Вы, видимо, подходите к ним как к одной.
поясню. насколько я понял, формуляр книги (эдакий вкладыш) содержит данные о предыдущих выдачах/сдачах книги, т.е. по сути является базой данных о перемещениях книги между читателями и библиотекой. записями (сущностями) этой базы данных являются отдельные операции выдачи/сдачи со своими данными о читателе и дате.
так что ложки нет...

Т.е. на выходе и входе верхнего уровня такой модели необходимо вводить сущность "запись в формуляре". Не получится большое количество таких сущностей на входе-выходе?