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

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

Спасибо!

Вход
1. Не очень понятна разница между "Заказами" и "Запросами потребителей". Если "запросы потребителей" - то, о чем я подумал, не лучше ли будет разместить их в Контроле?

Выход
2. "Продукция" и "Прибыль" на этом уровне абстракции - суть две стороны одной медали. "Прибыль", наверное, даже правильнее, поскольку название процесса завершается "и продажей".
3. "Реклама" точно не является результатом производства и продажи мебели. С бОльшими на то основаниями ее можно включить в "механизмы". В качестве "двигателя торговли".

Контроль
4. "Политика" в целом неплохо применима к продажной части процесса. Желательно иметь что-то и для производственной.

Механизмы
5. "Сотрудники" - безусловно, а почему отсутствует "оборудование"?

P.S. по "цель"
1. Я бы не стал начинать формулировку цели с "Понять".
2. Эта цель имеет отношение к изображенной модели? Судя по ее содержанию - она относится к более крупной деятельности, частью (артефактом) которой может являться модель. Соответственно, размещение такой цели рядом с моделью может вводить в заблуждение.

P.S. по "цель"
1. Я бы не стал начинать формулировку цели с "Понять".
2. Эта цель имеет отношение к изображенной модели? Судя по ее содержанию - она относится к более крупной деятельности, частью (артефактом) которой может являться модель. Соответственно, размещение такой цели рядом с моделью может вводить в заблуждение.

Леонид, спасибо за анализ. А Вы как бы сформулировали данную цель (итог по сути сформулировать требования к информационной системе)?

А Вы как бы сформулировали данную цель (итог по сути сформулировать требования к информационной системе)?

Например, "разработка исчерпывающей системы требований на создание информационной системы".

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

Например, "разработка исчерпывающей системы требований на создание информационной системы".

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

Леонид, но мы формулируем не вообще цель проекта, а цель моделирования, цель модели. Основное назначение модели - ответить на вопросы, исходя из этого. Как бы Вы уточнили цель модели(моделирования) и соответственно точку зрения?

Леонид, но мы формулируем не вообще цель проекта, а цель моделирования, цель модели. Основное назначение модели - ответить на вопросы, исходя из этого. Как бы Вы уточнили цель модели(моделирования) и соответственно точку зрения?

Да, я просто предложил дать понять, что эта "цель" не нечто самоценное, а лишь звено в цепочке, которое ведет к полезному в жизни результату.

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

Цель, наверное, может быть у процесса моделирования. "Показать. что мы освоили нотацию", "Систематизировать собранные во время обследования данные", "Зафиксировать имеющуюся информацию для передачи дальше" и т.п.

С "точкой зрения" скачать что-то затрудняюсь. Если она действительно нужна, то и так неплохо.

Леонид: http://dit.isuct.ru/ivt/books/CASE/case8/sadt/gl22.htm

урок 2

урок 2

Ужас-ужас:
1. Составьте множество вопросов, на которые должна отвечать модель.
2. С помощью этого набора вопросов определите, как будет использоваться модель.
3. Если вы не можете сформулировать, как она будет использоваться, попробуйте записать еще вопросы...

Все, финиш. Терзания на тему "куда бы пристроить эту модель?".

Я не знаю, как и почему так получилось у Марка и МакГоуэна, но у меня примерно так (применительно к нашему случаю):
1. Подумай, что и зачем ты собираешься делать.
2. Определись, какая модель и чем именно поможет осуществить задуманное.
3. Подумай, какая информация тебе нужна для того, чтобы разработать нужную модель.
4. Придумай вопросы, при помощи которых намерен получить нужную информацию.

То есть, ровно наоборот. Видимо, я совершенно безнадежен.

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

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

Было бы интересно обсудить но не в этой теме.

Кстати, в той же книге сказано:

"1.3. Модель имеет единственный субъект 
Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система ... SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования,"

Обычно, "субъект" - это тот, кто выполняет действия над объектом. "Объект", соответственно, то, над чем выполняются действия.
В книге эти понятия применяются несколько странно - я так и не понял из приведенного раздела, кто там кого моделирует и кто кому задает границы.
Тут вариантов несколько: или переводчик чего-то сильно напортачил, или авторы были где-то глубоко в себе, или с 86 года что-то сильно изменилось.

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

http://thedifference.ru/chem-otlichaetsya-obekt-ot-subekta/

Возможно, этот документ будет более определенным. Но предлагаю дискуссии по корректности или нет методологии вынести за скобки этой темы.

"1.3. Модель имеет единственный субъект 
Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система ... SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования,"

английский subject - это субъект и предмет и объект и тема

английский subject - это субъект и предмет и объект и тема

Да, есть такое. Особенно в "просторечии". Однако у нас это разные вещи, особенно в методологической литературе. Вполне вероятно, путаницу внес переводчик, не разобравшись. Соответственно, я бы не стал предлагать ее студентам. Мало ли, где он там еще не разобрался.
Жаль, не удалось посмотреть, как там в оригинале.

Это не к разбору методологии, а развитие темы "помогала студенту самому выявлять и устранять ошибки моделирования".

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

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

Я имел в виду некий чек лист (экспертная система - это скорее развитие чек листа), по которому студент может себя проверить перед тем, как сдавать работу.

Я имел в виду некий чек лист (экспертная система - это скорее развитие чек листа), по которому студент может себя проверить перед тем, как сдавать работу.

Аналог "ЧАВО" сделать вполне реалистично. Был бы достаточной объем работ студентов и начинающих аналитиков для систематизации и анализа ошибок. Вопрос - где их взять и где взять на них время.