Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => IDEF ARIS BPMN и пр. => Тема начата: Galogen от 23 Декабря 2011, 23:56:47
-
Уважаемые коллеги, друзья.
Многие из вас знают, что я преподаю в университете. В том числе и структурные методы анализа и проектирования. Среди них встречается (пока) и IDEF0. IDEF0 достаточно прост. Есть неплохая книга деМарко. И все равно возникают разные проблемы с выбором и интерпретации модели. Особенно в дискуссиях со студентами, которые настолько горячие порой бывают, что они пишут некоторую неправду, например в prepodam.net :)
Казалось чего проще:
прямоугольник - функциональный блок, символизирующий деятельность, процесс, операцию или действие;
3 вида входа - 1 просто вход (то, что является материалом изменения в блоке), управление (то, что регламентирует работу по изменению входа), механизм (то, с помощью чего производится изменение входа)
выход - результат преобразования.
Входами чаще всего являются материальные и информационные объекты.
Сколько бы не приводилось примеров, как бы подробно не обсуждались они, все равно, когда кто-то приступает к практической работе, производит массу ошибок и синтаксического, и логического характера.
Например, такая ситуация:
контекст: абонемент библиотеки
- вход: прочитанная книга
- выход: запись в читательском о том, что книга возвращена
- функ. блок: принять книги
вопрос: правильно ли я понимаю, что книга на входе преобразуется в информацию том, что она сдана?
ответ: вполне, книга же возвращена и осталась в библиотеке
Есть более изощренные моменты:
контекст: абонемент библиотеки
- вход: читательский билет
- выход: электронный формуляр читателя
- процесс: идентификация читателя
казалось бы очень логично, читатель подает билет, библиотекарь вводит номер его, система отображает электронный формуляр читателя.
вопрос: читательский билет преобразуется в ходе идентификации в формуляр читателя
ответ: ну в общем, так и есть
внимание далее:
- вход: электронный формуляр читателя
- выход: формуляр читателя с отметкой о сдаче
- процесс: списание книги с формуляра читателя
вопрос: электронный формуляр читателя преобразуется в формуляр читателя с отметкой о сдаче?
ответ: да нет, электронный формуляр читателя остается в системе он же никуда не выходит, он же внутри системы
вопрос: так откуда же возник формуляр читателя с отметкой о сдаче
ответ: ну так на входе же был читательский билет...
Внимание вопрос к аудитории: Скажите, пожалуйста, а как вы объясняете, производите обзор и рецензию в подобных случаях? Какие правила и проверки вы используете? Спасибо
-
Ну привет, приехали...
Проблема в том, что "писатели" моделей многого не знают, и не понимают многого. Возможно, их просто плохо учили :о)) Nothing personal only business))) А может им просто до фонаря.
Очевидно, что они (подобные студенты) не знают / не понимают:
- что такое "функция"
- какие виды информации (данных) используются, как они используются / преобразуются в информационные объекты
- что такое состояние, в т.ч. состояние информационных объектов
- какие операции могут выполняться с информационными объектами (их можно назвать в ОО стиле - методами обработки), как меняющие состояния объектов, так и порождающие из одних объектов другие.
(кстати, эти преобразования - одна из самых сложных тем, потому что здесь очень большая вариативность возможна)
ну и так далее (навскидку вспомнил далеко не все)
Могу дать рекомендацию - дать сколько-нибудь внятные определения и на каждом занятии у каждого их спрашивать, до тех пор пока от зубов отскакивать не будет.
Второе - на этом уровне подготовки нельзя вот так просто начать рисовать модель и обойтись без этих и подобных ошибок, в качестве положительного примера предварительной работы перед моделированием могу привести книжку Баркера. Суть в том, что моделирование - это некоторый алгоритм (последовательность действий) по анализу и графической фиксации его результатов, основанный на методологии... Поэтому и подходить к разработке модели нужно алгоритмически: делай раз, делай два и т.д. И вот эта-то последовательность и должна отскакивать как от зубов... Оно конечно от ошибок не избавит, но кардинально уменьшит их количество и степень принципиальности.
Кстати, был в мое студенческое время смешной, но показательный случай на подобную тему (но в контексте программирования: преподаватель спрашивает нас, студентов, есть массив чисел, его нужно отсортировать, что делаем? первый ответ был: берем и сравниваем... (и смех, и грех) Можешь, кстати, провести подобный эксперимент у себя... скорее всего услышишь много интересного... но не относящегося к делу...
(между прочим, уже ближе к концу курса только в единичных случаях и самые нерадивые студенты не могли внятно рассказать о программировании алгоритма сортировки)
-
Спасибо, Водолей.
Алгоритм есть. Он описан в книге деМарко, книгах Эдварда Йордана, в методических материалах, дается на лекциях.
Он достаточно прост (пропуская правила декомпозиции, только касаясь конкретного блока):
- дайте название блоку в формате Глагол (отглагольное существительное) дополнение (чаще всего основной выход блока)
- определите выходы блока
- определите управляющие входы
- определите входы (стараясь понять какой вход нужен для получения выхода)
- определите механизмы
- прочитайте всю полученную картинку (блок под Управлением преобразует Вход в Выход, используя Механизм)
Замечено, сложность возникает при смешивании материальных и информационных потоков. Причем могу сказать не только студенты ошибаются. Видел массу моделей, предлагаемые как образцы, но содержащие вопиющие ошибки.
Коллеги рассказывали о модели, в которой на входе был клиент, а на выходе белье. Куда девался при этом клиент никто особо не переживал.
Вот скажи, плиз, моделируем магазин.
Функция: Продать товар
Выход: проданный товар, чек
Вход: деньги
Управление: цена, политика скидок, правила продажи
Механизм: Кассир, Покупатель, POS-система
Что тут правильно или не правильно?
-
1. Буду продолжать придерживаться своего мнения - это не алгоритм, в нем, например, не говорится что может быть выходом, а что не может. А термин "стараясь понять" откровенно порадовал. Чтобы "понять" смысл предложения, нужно не только буквы знать, и в слова их уметь складывать, но и что-то еще - правда? Вот этого-то и нет у студентов.
2. Насчет клиентов и белья... Это, конечно, довольно показательно, но вообще-то бывают ситуации, когда "внутри" модели из одного (входного) документа порождается другой. Например, в той же химчистке может быть следующая ситуация, когда при чистке вещь клиента портится и тот пишет претензию, чтобы получить возмещение ущерба.
3. Следуя логике "клиента и белья", на модели непонятно откуда взялся товар (который оказался проданным) :о)))
Здесь может быть применена известная формула тов.К.Г.Маркса "товар-деньги-товар", например, на момент получения денег на вход товар вполне может быть на складе продавца (но может и не быть - вспоминаем схему работы наших интернет-магазинов :о))))
Хотя я бы деньги на входе заменил на какую-нибудь заявку, а проданный товар на выходе - на чек на проданный товар. Но это существенно зависит от точки зрения. Да и границы системы было бы неплохо определить...
-
За что я тебя люблю, Водолеюшка, так это за твои ясные обтекаемые ответы :)
1. Буду продолжать придерживаться своего мнения - это не алгоритм, в нем, например, не говорится что может быть выходом, а что не может. А термин "стараясь понять" откровенно порадовал. Чтобы "понять" смысл предложения, нужно не только буквы знать, и в слова их уметь складывать, но и что-то еще - правда? Вот этого-то и нет у студентов.
На самом деле у студентов много чего есть. Частенько нет должной мотивации или стимуляции - это факт, но понятие у них есть.
Да я не стал расписывать тут полную методику, пока не вижу особого смысла. Кроме того, я же указал, что мой алгоритм мало отличается от первоисточников, в мелких деталях, собственных наблюдений.
О выходе я говорил выше (ниже) в первом посте. Могу сказать: выход - это результат работы блока, то ради чего нам и нужен этот блок, его назначение, записанное в виде названия, которое в свою очередь должно содержать основной результат. Выход - это продукт, результат обработки, новые данные, которые кому-то, чему-то нужны....
2. Насчет клиентов и белья... Это, конечно, довольно показательно, но вообще-то бывают ситуации, когда "внутри" модели из одного (входного) документа порождается другой. Например, в той же химчистке может быть следующая ситуация, когда при чистке вещь клиента портится и тот пишет претензию, чтобы получить возмещение ущерба.
Да, именно. Вообще я подчеркнул бы особенность, связанную с информацией. Например, IDEF0 строго говорит, что должен быть выход и управление - это обязательно, вход желателен, но не всегда. Когда описываются преобразования материальных потоков - вход обязателен, иначе не будет материального выхода. С информацией проще, поскольку управление тоже информация и оно особый вход.
Насчет возмещение ущерба - да претензия - это управление-спусковое событие - возмещение ущерба же не берется из воздуха - это либо деньги, либо услуга, либо восстановленная испорченная вещь.
3. Следуя логике "клиента и белья", на модели непонятно откуда взялся товар (который оказался проданным) :о)))
Здесь может быть применена известная формула тов.К.Г.Маркса "товар-деньги-товар", например, на момент получения денег на вход товар вполне может быть на складе продавца (но может и не быть - вспоминаем схему работы наших интернет-магазинов :о))))
Хотя я бы деньги на входе заменил на какую-нибудь заявку, а проданный товар на выходе - на чек на проданный товар. Но это существенно зависит от точки зрения. Да и границы системы было бы неплохо определить...
Естественно это зависит от точки зрения и цели моделирования. Но в данном случае не уравновешаны материальные потоки.
Деньги не превращаются в товар - деньги превращаются в прибыль (доход, прибавочную стоимость, заложенную в цену товара).
Деньги необходимое условие для получение, покупки товара. Соответственно на входе тоже должен быть товар.
Если я не прав, то как правильно?
-
Да, именно. Вообще я подчеркнул бы особенность, связанную с информацией. Например, IDEF0 строго говорит, что должен быть выход и управление - это обязательно, вход желателен, но не всегда. Когда описываются преобразования материальных потоков - вход обязателен, иначе не будет материального выхода. С информацией проще, поскольку управление тоже информация и оно особый вход.
в теории - да.
вопрос-то в том, как правильно выбрать точку зрения, определить границы системы, увязать входы/выходы/управление, то, сё...
короче, описать модель как систему...
Насчет возмещение ущерба - да претензия - это управление-спусковое событие - возмещение ущерба же не берется из воздуха - это либо деньги, либо услуга, либо восстановленная испорченная вещь.
ну да, возмещение ущерба - процесс, запускаемый претензией. все остальное в обсуждаемом контексте несущественно...
Деньги не превращаются в товар - деньги превращаются в прибыль (доход, прибавочную стоимость, заложенную в цену товара).
Деньги необходимое условие для получение, покупки товара. Соответственно на входе тоже должен быть товар.
это всё и другой оперы. (деньги - вообще-то эквивалент товара)
не надо перескакивать с материальных потоков (заготовка - обработать деталь - обработанная деталь) на информационные - одно другое не заменяет. информационная система "дублирует" выполнение материальных транзакций за счет преобразований информационных объектов, которые не заменяют материальные. (кстати, многие пользователи информационных систем бьются смертным боем, чтобы по максимуму отождествить или хотя бы максимально приблизить отражение в информационной системе материальных операция, типа оприходования/отпуска товара на/со склада: нет операции в системе - нет товара).
-
не надо перескакивать с материальных потоков (заготовка - обработать деталь - обработанная деталь) на информационные - одно другое не заменяет. информационная система "дублирует" выполнение материальных транзакций за счет преобразований информационных объектов, которые не заменяют материальные. (кстати, многие пользователи информационных систем бьются смертным боем, чтобы по максимуму отождествить или хотя бы максимально приблизить отражение в информационной системе материальных операция, типа оприходования/отпуска товара на/со склада: нет операции в системе - нет товара).
Что значит не надо перескакивать.
Кто-то - автор - моделирует систему. Он отображает материальный поток и информационный поток. Естественно одно другое не заменяет. Ясно, что информационный поток сопровождает материальный. Ясно, что если мы говорим о требованиях к информационной системе, мы рассуждаем о информационных потоках.
Однако вопрос был: как вы объясняете (своим студентам, своим сотрудникам, своим оппонентам). Каковы правила?
Ты вот высказал: не прописано как выбирать выход, вход, управление.
Ну вот скажи!
Может ли, к примеру, входящий в блок Принять книгу поток Книга оседать в этом блоке и не иметь выхода, кроме пометки о сдаче в формуляре? Если выходящим должен быть "принятая (сданная) книга", то должна ли она выходить из системы, если мы рассматриваем границы абонемента библиотеки?
Если мы рассматриваем модель с точки зрения библиотекаря абонемента, может ли быть механизмом сам библиотекарь-абонемента?
В принципе "дезинтеграция" материальных объектов нормальна, в сетях Петри, вернее их расширении Е-сети, существует типичная конструкция - Аккумулятор, роль которого гасить выходящие из системы заявки-метки, если ты понимаешь о чем я толкую. Но будет ли это частью работы абонемента? Т.е. на входе книга - на выходе только информация (при сдаче) и на входе информация - на выходе книга (при выдаче). Правда я бы вообще не разделял эти две операции. Я бы назвал их Прием/выдача книг. И у меня было управление (а может механизм) Фонд библиотеки...
-
в теории - да.
вопрос-то в том, как правильно выбрать точку зрения, определить границы системы, увязать входы/выходы/управление, то, сё...
короче, описать модель как систему...
Согласен - это одно из самых сложных моментов, но и это момент логических построений...
А какие у тебя подходы? Как ты это делаешь? Обращаюсь к тебе (других видимо нет :)
-
я в последнее время idef0 только рецензирую :о)) а не рисую...
я же как-то тебе писал об этом...
самое первое и самое главное - определяем цель системы и ее рамки, делаем гипотезы о точках зрения: сколько их и какими они могут быть. (на примере библиотеки - читатель, библиотекарь, директор завода зав.библиотекой.) для каждого из них одни и те же информационные сущности будут означать что-то свое. по возможности уже на этой стадии можно сформулировать ряд вопросов к системе.
потом надо описать систему словами в виде простых предложений, это чем-то похоже на user story (а может user story и есть). это позволит определить границы системы. из предложений выделяем действия = глаголы и сущности = существительные. если говорить в терминах idef0, то сущности - это стрелки, действия - они активити и есть. важно составив подобным образом словарь системы не выходить за его рамки, иначе придется пересматривать границы. можно отсортировать сущности по принципу "глубины"
дополнительно я обычно для каждой сущности определяю в ОО стиле, что с ней можно вообще делать с точки зрения того, от чей т.зр. составляется модель: что с книгой (сдать/принять, проверить, положить на полку, выдать), что с формуляром (заполнить? что еще?), и т.п., но это в явном виде в стандартной методике вроде отсутствует. мне так легче рассматривать сущности, в конце концов они чаще всего имеют вполне ясное и понятное отражение в реальном мире.
рисуем А0, ориентируемся на цель, рамки, сущности. потом пробуем детализировать, пытаясь увязать модели по глубине, чтобы на одном уровне определялись функции примерно похожие по нагрузке, например: принять книгу, заполнить формуляр - д.б. на модели одного уровня.
тут будут уместны твои вопросы
1. Может ли, к примеру, входящий в блок Принять книгу поток Книга оседать в этом блоке и не иметь выхода, кроме пометки о сдаче в формуляре?
2. Если выходящим должен быть "принятая (сданная) книга", то должна ли она выходить из системы, если мы рассматриваем границы абонемента библиотеки?
3. Если мы рассматриваем модель с точки зрения библиотекаря абонемента, может ли быть механизмом сам библиотекарь-абонемента?
попробую ответить:
1. А что с книгой-то происходит? С самой книгой ничего, она физически перемещается из рук читателя, через несколько других рук, на свое место на полочке, которое указывает библиотечный каталог. В принципе при некоторых ракурсах рассмотрения можно отражать во входах/выходах разные состояния книги: книга, полученная от читателя, книга на столе регистратора, книга на полке.
С формуляром IMHO проще - это вторая цепочка (потому что формуляр это информационная карточка книги (в определенном смысле). Когда книга на руках, он где лежит? Когда книгу сдают, что с формуляром происходит? Когда книгу на полку кладут, куда формуляр девается? и т.п.
Тут либо книга и формуляр всегда вместе "путешествуют", либо по-разному...
2. Почему выходом должна быть книга-то? Или мы рассматриваем в качестве системы операцию сдачи/приемки? Если нет, то вообще говоря, выходов может быть много и разных, отчетность какая-нибудь с анализом востребованности литературы, например... Короче говоря, надо на задачу смотреть (цель какая? границы какие? - не могу сказать, что сейчас внятно понимаю термин "границы абонемента библиотеки" )
3. ну а почему нет. если хочешь, назови его "я - библиотекарь абонемента".
одна из проблем при рисовании моделей idef0 - попытка соблюсти последовательность, что, я считаю, не совсем верно, т.к. как первичнее функциональная структура, т.е. из каких функций состоит модель, и как они между собой связаны информационно (там временного измерения нет), а не событие - реакция (это в арисе так).
последний этап - проверка. нужно попытатся "прокрутить" систему: дали что-то нужное на вход, что и как будет при этом входе.
твой пример с книгой, очевидно, вызывает трудности из-за того, что границы системы не ясны и с точкой зрения не все в порядке, или мне только так кажется.
-
других видимо нет :)
другие не занимаются такой ерундой - они моделируют сразу на UML
-
другие не занимаются такой ерундой - они моделируют сразу на UML
А ты резок, как я посмотрю. Назови мне в UML альтернативу IDEF0, т.е. что обладает относительной простотой изображения и возможность легко и просто использовать функциональную декомпозицию. Что дает возможность оторваться от структурных моментов и сосредоточиться на назначении? К тому же в ГОСе это прописано, мы вынуждены знакомить с этим студентов.
я в последнее время idef0 только рецензирую :о)) а не рисую...
я же как-то тебе писал об этом...
самое первое и самое главное - определяем цель системы и ее рамки, делаем гипотезы о точках зрения: сколько их и какими они могут быть. (на примере библиотеки - читатель, библиотекарь, директор завода зав.библиотекой.) для каждого из них одни и те же информационные сущности будут означать что-то свое. по возможности уже на этой стадии можно сформулировать ряд вопросов к системе.
мы это делаем, тем же примерно способом.
потом надо описать систему словами в виде простых предложений, это чем-то похоже на user story (а может user story и есть). это позволит определить границы системы. из предложений выделяем действия = глаголы и сущности = существительные. если говорить в терминах idef0, то сущности - это стрелки, действия - они активити и есть. важно составив подобным образом словарь системы не выходить за его рамки, иначе придется пересматривать границы. можно отсортировать сущности по принципу "глубины"
дополнительно я обычно для каждой сущности определяю в ОО стиле, что с ней можно вообще делать с точки зрения того, от чей т.зр.
этот этап у нас производится иначе. истории мы не пишем. студенты описывают имеющуюся систему. однако составляют списки функций и данных и производят группировку и анализ этих данных.
составляется модель: что с книгой (сдать/принять, проверить, положить на полку, выдать), что с формуляром (заполнить? что еще?), и т.п., но это в явном виде в стандартной методике вроде отсутствует. мне так легче рассматривать сущности, в конце концов они чаще всего имеют вполне ясное и понятное отражение в реальном мире.
отталкивание от сущностей - одни из способов структурирования пространства, можно идти иным путем - системным (функциональным, кибернетическим), все -таки мы строим иерархию функций, а не ирерахию сущностей. Хотя одно может дополнять другое.
рисуем А0, ориентируемся на цель, рамки, сущности. потом пробуем детализировать, пытаясь увязать модели по глубине, чтобы на одном уровне определялись функции примерно похожие по нагрузке, например: принять книгу, заполнить формуляр - д.б. на модели одного уровня.
Как ты определяешь (какие критерии) что две функции одинаковы/различны по нагрузке?
тут будут уместны твои вопросыпопробую ответить:
1. А что с книгой-то происходит? С самой книгой ничего, она физически перемещается из рук читателя, через несколько других рук, на свое место на полочке, которое указывает библиотечный каталог. В принципе при некоторых ракурсах рассмотрения можно отражать во входах/выходах разные состояния книги: книга, полученная от читателя, книга на столе регистратора, книга на полке.
С формуляром IMHO проще - это вторая цепочка (потому что формуляр это информационная карточка книги (в определенном смысле). Когда книга на руках, он где лежит? Когда книгу сдают, что с формуляром происходит? Когда книгу на полку кладут, куда формуляр девается? и т.п.
Да согласен может и так. Что исключить книгу из рассмотрения?
2. Почему выходом должна быть книга-то? Или мы рассматриваем в качестве системы операцию сдачи/приемки? Если нет, то вообще говоря, выходов может быть много и разных, отчетность какая-нибудь с анализом востребованности литературы, например... Короче говоря, надо на задачу смотреть (цель какая? границы какие? - не могу сказать, что сейчас внятно понимаю термин "границы абонемента библиотеки" )
именно ее и рассматриваем. абонемент библиотеке - место где читатели берут и сдают книги.
одна из проблем при рисовании моделей idef0 - попытка соблюсти последовательность, что, я считаю, не совсем верно, т.к. как первичнее функциональная структура, т.е. из каких функций состоит модель, и как они между собой связаны информационно (там временного измерения нет), а не событие - реакция (это в арисе так).
не могу сказать, что понял посыл данной фразы. повтори плиз?
последний этап - проверка. нужно попытатся "прокрутить" систему: дали что-то нужное на вход, что и как будет при этом входе.
точно так. собираюсь усилить тем, что буду в следующем году просить студентов обмениваться моделями и пусть рецензируют.
твой пример с книгой, очевидно, вызывает трудности из-за того, что границы системы не ясны и с точкой зрения не все в порядке, или мне только так кажется.
понятно, что пример вырван из контекста. точка зрения библиотекаря абонемента. границы системы - именно абонемент библиотеки
-
границы абонемента библиотеки
Я плохо знаю эту предметную область, но если под абонементов подразумевается носитель информации о том какие книги выдаются и возвращаются читателем, то материальный вход "книги" не входит в данный контекст, здесь входом будет информация о возвращаемой книге.
-
Я плохо знаю эту предметную область, но если под абонементов подразумевается носитель информации о том какие книги выдаются и возвращаются читателем, то материальный вход "книги" не входит в данный контекст, здесь входом будет информация о возвращаемой книге.
Друзья, спасибо за интерес к теме. Толкьо дискуссия пошли не в том русле.
Абонемент тут не причем, и все же. Я говорю мы рассматриваем работу абонемента библиотеки с точки зрения библиотекаря (или руководителя данного отдела). Изучается именно работа, не автоматизация, автоматизации дальше, если вообще до нее дойдем.
Типичный процесс:
Студент пришел в библиотеку, чтобы сдать/взять книги. Он подходит на абонемент, подает библотекарю читательский (называет его номер).
Библитекарь перед формуляр читателя.
Студент выкладывает книги на сдачу.
Библитекарь вытаскивает формуляр книги из формуляра читателя и расскладывает по соответствующим книгам. Если остаются формуляры книг и срок их возврата истек, библиотекарь предлагает продлить книги на следующий срок.
Студент берет каждый из предложенных формуляров и указывает новую дату возврата и свою подпись.
Далее Студент подает новое требование на книги.
Если книга в наличии, тогда библотекарь приносит книгу, вынимает формуляр и подает студенту.
Студент указывает дату возврата и свою подпись на каждом формуляре книги.
Библиотекарь выдает книги, помещает все формуляры книг в формуляр читателя и помещает его в картотеку.
Вот типичный сценарий, наблюдаемый мною в нашей библиотеке. Он естественно может идти с множеством вариаций
-
Замечено, сложность возникает при смешивании материальных и информационных потоков. Причем могу сказать не только студенты ошибаются. Видел массу моделей, предлагаемые как образцы, но содержащие вопиющие ошибки.
Коллеги рассказывали о модели, в которой на входе был клиент, а на выходе белье. Куда девался при этом клиент никто особо не переживал.
Вот скажи, плиз, моделируем магазин.
Функция: Продать товар
Выход: проданный товар, чек
Вход: деньги
Управление: цена, политика скидок, правила продажи
Механизм: Кассир, Покупатель, POS-система
Что тут правильно или не правильно?
По собственному опыту могу сказать, что объекты не должны появляться без действий и исчезать бесследно.
В данном случае:
1. Входными данными является также "Корзина". Имеется в виду корзина набранных покупателем товаров.
2. В выходные данные добавить "Чек", "Непроданный товар", также можно добавить информационные составляющие "Копия чек в pos-терминале".
-
По собственному опыту могу сказать, что объекты не должны появляться без действий и исчезать бесследно.
В данном случае:
1. Входными данными является также "Корзина". Имеется в виду корзина набранных покупателем товаров.
2. В выходные данные добавить "Чек", "Непроданный товар", также можно добавить информационные составляющие "Копия чек в pos-терминале".
Отлично! Обратите внимание чек в оригинале есть. Задача заведома содержала ошибку, по товарам мы согласовали потоки, а по деньгам? Деньги аккумулируются в блоке? Во что они должны трансформироваться?
Достаточно ли нам данных для формирования чека? Откуда следует брать по-вашему эти данные?
-
Например, такая ситуация:
контекст: абонемент библиотеки
- вход: прочитанная книга
- выход: запись в читательском о том, что книга возвращена
- функ. блок: принять книги
вопрос: правильно ли я понимаю, что книга на входе преобразуется в информацию том, что она сдана?
ответ: вполне, книга же возвращена и осталась в библиотеке
На самом деле книга остается в модели; может, например, перейти в два потока: идентифицированные книги и неидентифицированные.
Читательский билет на входе и читательский билет на выходе. Внутри есть функция по его модификации, но сущность не меняется. Если запись ведется в отдельном журнале или как отдельная сущность вводится в компьютер, то ее можно учитывать в моделировании как порожденную.
Есть более изощренные моменты:
контекст: абонемент библиотеки
- вход: читательский билет
- выход: электронный формуляр читателя
- процесс: идентификация читателя
казалось бы очень логично, читатель подает билет, библиотекарь вводит номер его, система отображает электронный формуляр читателя.
вопрос: читательский билет преобразуется в ходе идентификации в формуляр читателя
ответ: ну в общем, так и есть
Аналогично предыдущему. Важно! Читательский билет возвращается читателю, но по нему определен формуляр. На вход идут: читательский билет, база формуляров. Управляющим: правило определения. Выход: читательский билет - обратно читателю надо направить (по идее его надо провести за рамки системы), формуляр читателя.
внимание далее:
- вход: электронный формуляр читателя
- выход: формуляр читателя с отметкой о сдаче
- процесс: списание книги с формуляра читателя
вопрос: электронный формуляр читателя преобразуется в формуляр читателя с отметкой о сдаче?
ответ: да нет, электронный формуляр читателя остается в системе он же никуда не выходит, он же внутри системы
вопрос: так откуда же возник формуляр читателя с отметкой о сдаче
ответ: ну так на входе же был читательский билет...
Внимание вопрос к аудитории: Скажите, пожалуйста, а как вы объясняете, производите обзор и рецензию в подобных случаях? Какие правила и проверки вы используете? Спасибо
На вход в функцию добавляем книгу принятую, управляющим - правило оформления формуляра. Без не ничего не будет. Поскольку сама сущность формуляра не меняется, то можно специально не отражать ее состояния. В дальнейшем можно работать всегда с формуляром с помощью функций: проверка состояния, ...
-
Отлично! Обратите внимание чек в оригинале есть. Задача заведома содержала ошибку, по товарам мы согласовали потоки, а по деньгам? Деньги аккумулируются в блоке? Во что они должны трансформироваться?
Достаточно ли нам данных для формирования чека? Откуда следует брать по-вашему эти данные?
По чеку: ориентировался на рисунок.
ИМХО, По остальным вопросам: опирать при моделировании необходимо на:
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 процентов). с этим я, конечно, не согласен.
ну это понятно, только вот и надо вытащить модель твоих "видений" на поверхность наблюдаемого опыта:)
я, собственно, это и предлагаю. коллеги выше дали на эту тему пояснения - в системе мы оперируем информацией о книге, а не самой книгой. получается, что книга - это, так, бесплатное приложение к формуляру :о))) ее же необязательно читать, можно просто подложить под ножку стола :о))
если все свести именно к информации, то ясно, что все объекты - информационные, а не реальные. Но если в системе циркулируют и те и другие?
Без проблем:о))
смысл в том, что суть анализа и построенной на его основе модели - определить информационные связи функций, а не их последовательность во временном аспекте
Ты полагаешь, что я это не понимал раньше?
-
дело в том, что это РАЗНЫЕ сущности, а Вы, видимо, подходите к ним как к одной.
поясню. насколько я понял, формуляр книги (эдакий вкладыш) содержит данные о предыдущих выдачах/сдачах книги, т.е. по сути является базой данных о перемещениях книги между читателями и библиотекой. записями (сущностями) этой базы данных являются отдельные операции выдачи/сдачи со своими данными о читателе и дате.
так что ложки нет...
Т.е. на выходе и входе верхнего уровня такой модели необходимо вводить сущность "запись в формуляре". Не получится большое количество таких сущностей на входе-выходе?
-
Т.е. на выходе и входе верхнего уровня такой модели необходимо вводить сущность "запись в формуляре". Не получится большое количество таких сущностей на входе-выходе?
на самом деле не следует из сказанного ранее :о))) это в том числе зависит от степени подробности модели. разве не может существовать функции "зафиксировать факт передачи книги в формуляре"? на входе формуляр (незаполненный), данные о читателе, данные об операции, на выходе - заполненный формуляр. это все как раз и зависит от точки зрения и целей моделирования: того, чего мы хотим достигнуть с помощью модели. вдруг нам надо только отследить количество задержек конкретным студентом или всего лишь факт их наличия? а решение будет что-то типа "отобрать парт читательский билет"
-
Хорошая тема. Но возвращаясь к вопросу о правилах и проверках при рецензировании модели.
Имеем следующее:
Методология IDEF0 незначительно отличается от классической схемы описания бизнес-процессов DFD, которая была рассмотрена ранее. Основным отличием является наличие в языке дополнительной аналитики. Данный стандарт описания бизнес-процессов предлагает показывать не просто входы и выходы, как это делается в DFD – формате, он предлагает ввести три типа входов. Первый тип входов назвали так же входом, а два других входа назвали управлением и механизмами.
В стандарте IDEF0 c помощью входа показывают объекты – информационные и материальные потоки, которые преобразуются в бизнес-процессе. С помощью управления показывают объекты – материальные и информационные потоки, которые не преобразуются в процессе, но нужны для его выполнения. С помощью механизмов стали показывать механизмы, при помощи которых бизнес-процесс реализуется: технические средства, люди, информационные системы и т.д.
Теперь сами правила, точнее больше напоминания:
1. В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы и зафиксирована точка зрения. Точка зрения определяет уровень детализации, направление развития модели и позволяет разгрузить модель. Так при моделировании можно отказаться от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему.
2. Функциональный блок (или Функция) преобразует Входы в Выходы (т.е. входную информацию в выходную), Управление определяет, когда и как это преобразование может или должно произойти Исполнители непосредственно осуществляют это преобразование.
3. Заранее определиться с терминологией.
Что еще?
-
Хорошая тема. Но возвращаясь к вопросу о правилах и проверках при рецензировании модели.
1. В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы и зафиксирована точка зрения. Точка зрения определяет уровень детализации, направление развития модели и позволяет разгрузить модель. Так при моделировании можно отказаться от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему.
Рекомендации и правила выбора точки зрения и цели моделирования? Очевидно, что цель моделирования определяет точку зрения. Цель определяет и список вопросов, на которые следует ответить модели. Тогда точка зрения - та, которая отвечает на большинство поставленных вопросов.
Однако чаще всего цель и точка зрения выбирается очень произвольно (студентами имеется в виду)
2. Функциональный блок (или Функция) преобразует Входы в Выходы (т.е. входную информацию в выходную), Управление определяет, когда и как это преобразование может или должно произойти Исполнители непосредственно осуществляют это преобразование.
А материальные потоки? а кто такие исполнители? Вы имели в виду механизмы? но механизмы - это не всегда исполнители.
Что еще?
1. каковы правила отнесения входа в управление, вход или механизм
2. если вход покрывает несколько типов, как быть?
3. может ли порождаться выход - если нет явных входов (для материальных потоков)
4. может ли быть материалный вход, но отсутствовать материальный выход?
5. каковы правила декомпозиции, как определять что блоки на одном уровне рассмотрения?
6. как правильно именовать блоки, стрелки
7. что отличает хорошую модель, от плохой
-
Цель и точка зрения - это все-таки мне как мне видится должно быть в задании студенту.
Т.е. рассмотрите (нарисуйте) модель с точки зрения того-то.
Получается как бы небольшое описание к модели.
Исполнители - это имелось ввиду механизмы.
В целом по вопросам проверки мне видится что в каждом случае надо разбираться.
Но при этом можно использовать созданные методики. Во вложении (tk_ pb.rar - просто к сведению).
-
По поводу вопросов "каковы правила отнесения входа в управление, вход или механизм" здесь больше вопросов чем ответов. ;)
И здесь (http://www.cfin.ru/forum/messages/2869/16900.shtml?1096369161)
Однозначного понимания того, на вход или на механизм поступают фин.ресурсы после прочтения многочисленной литературы по ИДЕФ-ноль у меня не сформировалось. Увиденые модели БП допускают и тот и другой вариант.
и на нашем форуме (http://www.uml2.ru/forum/index.php?topic=75.0) пока четкого ответа нет.
Есть рекомендации IDEF0 и опыт разработки (http://www.or-rsv.narod.ru/Articles/Article_30r.htm) в которых сказано
Для практического удобства может быть предложена иная (зауженная) интерпретация исходных примитивов стандарта IDEF0 (см. Рис.1 “Общая модель БП (В)”). Основная идея предлагаемой рекомендации по конкретизации языков моделирования БП состоят в следующем:
(1) Все “Работы” принадлежат одному классу, т.е. обладают одинаковым набором свойств и поведением. Этот важный и часто нарушаемый принцип отдельно обсудим ниже.
(2) Все связи между “Работами” относятся к классу “Ресурс”. Например, электронное издание “Налогового кодекса РФ” является общедоступным информационным ресурсом.
(3) Для однозначной “привязки” ресурсов к трем возможным входам БП на множестве “Ресурсов” вводится следующая классификация.
1. Признак изменчивости “Ресурса” при исполнении “Работы”.
1.1. “Ресурсы”, подлежащие трансформации в другие виды “Ресурсов”.
1.2. Нетрансформируемые “Ресурсы”.
1.2.1. Неизнашиваемые “Ресурсы”. Например, большая часть информационных “Ресурсов” в электронной форме являются неизнашиваемыми.
1.2.2. Изнашиваемые (устаревающие) “Ресурсы”. Например, вспомогательные инструменты, персонал.
2. Признак блокировки “Ресурса” “Работой”, исключающий возможность использования “Ресурса” другими “Работами”
2.1. “Ресурсы”, которые не могут блокироваться “Работами” (“Ресурсы” общего пользования)
2.2. Блокируемые “Ресурсы”
Возможно и к данной классификации есть вопросы (точнее они есть в данной статье (http://www.osp.ru/os/2003/03/182731/) ) но все же это может помочь
-
Ищите по ссылкам:
http://mmpk.appach.ru/ и http://www.fondgp.ru/
Материалов там море, и сходу то, что нужно я найти не могу.
Еще поищите книгу Анисимова "Основы методологии"
-
Ищите по ссылкам:
http://mmpk.appach.ru/ и http://www.fondgp.ru/
Материалов там море, и сходу то, что нужно я найти не могу.
Еще поищите книгу Анисимова "Основы методологии"
Спасибо за ссылки, это весьма познавательно, но мое мнение, твои рекомендации слишком абстрактны в свете обсуждаемого вопроса.
По поводу вопросов "каковы правила отнесения входа в управление, вход или механизм" здесь больше вопросов чем ответов. ;)
Да, Вы правы, уважаемый Thyestes. Вы привели интересную подборку публикаций и обсуждений. Увеличение возможностей ведет и не к однозначности использования и восприятия. Главное отличие IDEF0 именно в разделение семантики входов создает и чуть ли не основную трудность в корректном применении. Однако может не стоит искать в этом нечто сакральное?
У проектировщика(аналитика, автора моделей) есть дополнительный инструмент особым образом подчеркнуть смысл входов. Он определяется положением: вверху - управление, внизу - механизм
Однако, делая различие между входными дугами и дугами управления, SADT дает аналитику возможность точно описать ограничения, накладываемые на функции преобразования. Ограничения позволяют получить более верное представление о работе системы, поскольку они описывают факты и правила, которым должны следовать функции преобразований.
[5.4. Различие между входными дугами и дугами управления. Методология структурного анализа и проектирования SADT]
В SADT система описывается в первую очередь с точки зрения ее функций. Но система должна быть в конечном итоге реализована (т.е. быть работоспособной), поэтому дуги механизма SADT имеют большое значение при описании системы. Они дают аналитику возможность точно определить способ выполнения конкретной функции, какие ресурсы требуются для этой функции, кто будет выполнять ее и т.д. С помощью дуг механизма аналитик может добавить к описанию последние детали, не вызывающие сомнений в том, что происходит при выполнении функции.
[5.5. Дуги механизмов определяют способы реализации функций. Методология структурного анализа и проектирования SADT]
Т.е. читатель(рецензент) обращает внимание на акценты автора, и может усомниться в их корректности, либо согласиться с ними?
Хотя напомню, что в начале был такой вопрос, может ли входить материальный поток, а выходить только информационный? И наоборот? На мой взгляд ни чистая аккумуляция, ни чистая генерации "материи" не должна присутствовать.
С другой стороны а следует ли вообще говорить о материальности потоков при описании и моделировании БП? Не следует ли все сразу сводить к информационным моделям и понятиям, и это есть единственно верное решение?