1441

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 26 Декабря 2011, 17:37:23 »

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

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

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

1442

UML SysML и пр. / Re: Как средствами UML описать протокол общение между сервером и клиентом

« : 26 Декабря 2011, 16:49:37 »

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

На общем уровне это могут быть просто Клиент и Сервер. Можно детализировать при желании стурктуру клиента и сервера

1443

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 26 Декабря 2011, 16:45:05 »

По собственному опыту могу сказать, что объекты не должны появляться без действий и исчезать бесследно.
В данном случае:
1. Входными данными является также "Корзина". Имеется в виду корзина набранных покупателем товаров.
2. В выходные данные добавить "Чек", "Непроданный товар", также можно добавить информационные составляющие "Копия чек в pos-терминале".

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

1444

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 26 Декабря 2011, 12:47:34 »

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

Друзья, спасибо за интерес к теме. Толкьо дискуссия пошли не в том русле.

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

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

Вот типичный сценарий, наблюдаемый мною в нашей библиотеке. Он естественно может идти с множеством вариаций

1445

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 26 Декабря 2011, 08:09:59 »

другие не занимаются такой ерундой - они моделируют сразу на UML

А ты резок, как я посмотрю. Назови мне в UML альтернативу IDEF0, т.е. что обладает относительной простотой изображения и возможность легко и просто использовать функциональную декомпозицию. Что дает возможность оторваться от структурных моментов и сосредоточиться на назначении? К тому же в ГОСе это прописано, мы вынуждены знакомить с этим студентов.

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

мы это делаем, тем же примерно способом.

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

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

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

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

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

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

тут будут уместны твои вопросыпопробую ответить:
1. А что с книгой-то происходит? С самой книгой ничего, она физически перемещается из рук читателя, через несколько других рук, на свое место на полочке, которое указывает библиотечный каталог. В принципе при некоторых ракурсах рассмотрения можно отражать во входах/выходах разные состояния книги: книга, полученная от читателя, книга на столе регистратора, книга на полке.
С формуляром IMHO проще - это вторая цепочка (потому что формуляр это информационная карточка книги (в определенном смысле). Когда книга на руках, он где лежит? Когда книгу сдают, что с формуляром происходит? Когда книгу на полку кладут, куда формуляр девается? и т.п.

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

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

именно ее и рассматриваем. абонемент библиотеке - место где читатели берут и сдают книги.

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

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

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

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

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

понятно, что пример вырван из контекста. точка зрения библиотекаря абонемента. границы системы  - именно абонемент библиотеки

1446

Задачи студентов / Re: Диаграмма ВИ ИС безопасности

« : 26 Декабря 2011, 07:50:03 »

(делал в первый раз, сильно не пинать=) )

И что? Изучаем примеры на форуме и их обсуждения. Большинство начинается примерно с этой же фразы.
ВСЕ НЕПРАВИЛЬНО. Читаем:
1. что такое ВИ
2. чем ВИ отличается от функции системы
3. ВИ как способ описания требований
4. назначение диаграммы использования
5. что такое действующее лицо
6. чем отличается взаимодействие от использования
7. что такое декомпозиция
8. что такое функциональная декомпозиция

1447

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 25 Декабря 2011, 21:26:11 »

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

Согласен - это одно из самых сложных моментов, но и это момент логических построений...
А какие у тебя подходы? Как ты это делаешь? Обращаюсь к тебе (других видимо нет

1448

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 25 Декабря 2011, 21:23:41 »

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

Что значит не надо перескакивать.
Кто-то - автор - моделирует систему. Он отображает материальный поток и информационный поток. Естественно одно другое не заменяет. Ясно, что информационный поток сопровождает материальный. Ясно, что если мы говорим о требованиях к информационной системе, мы рассуждаем о информационных потоках.

Однако вопрос был: как вы объясняете (своим студентам, своим сотрудникам, своим оппонентам). Каковы правила?

Ты вот высказал: не прописано как выбирать выход, вход, управление.

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

В принципе "дезинтеграция" материальных объектов нормальна, в сетях Петри, вернее их расширении Е-сети, существует типичная конструкция - Аккумулятор, роль которого гасить выходящие из системы заявки-метки, если ты понимаешь о чем я толкую. Но будет ли это частью работы абонемента? Т.е. на входе книга - на выходе только информация (при сдаче) и на входе информация - на выходе книга (при выдаче). Правда я бы вообще не разделял эти две операции. Я бы назвал их Прием/выдача книг. И у меня было управление (а может механизм) Фонд библиотеки...

1449

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 25 Декабря 2011, 19:26:33 »

За что я тебя люблю, Водолеюшка, так это за твои ясные обтекаемые ответы

1. Буду продолжать придерживаться своего мнения - это не алгоритм, в нем, например, не говорится что может быть выходом, а что не может. А термин "стараясь понять" откровенно порадовал. Чтобы "понять" смысл предложения, нужно не только буквы знать, и в слова их уметь складывать, но и что-то еще - правда? Вот этого-то и нет у студентов.

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

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

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

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

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

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

Если я не прав, то как правильно?

1450

Реализация / Re: Прошу посоветуйте программу для проектирования

« : 25 Декабря 2011, 00:30:35 »

visual paradigm - может, если использовать соответствующий SDE (http://www.visual-paradigm.com/product/sde/)

генерирование кода на основе модели - это сюда (http://www.new.capableobjects.com/)

1451

ПО Аналитика / Re: “visual paradigm” vs “PowerDesigner”

« : 25 Декабря 2011, 00:22:43 »

PowerDesigner - безусловно давний и зрелый игрок. Тем не менее существует масса альтернативных и пожалуй лучших решений. Другой вопрос как много они стоят. Это и MagicDraw, IBM Rational, IBM Telelogic и другие

Visual Paradigm - более новый игрок, но очень активный.

Однако хотелось бы понять для чего вам нужен моделирующий инструмент. Для разработки ПО все равно будете использовать с#, следовательно целесообразнее использовать VS. А VS имеет вполне адекватные инструменты UML-моделирования с поддержкой round-trip разработки.

Каков ваш опыт, знания UML, каков бюджет, почему вы думаете, что все перечисленные продукты нужны вам?

1452

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 25 Декабря 2011, 00:11:03 »

Спасибо, Водолей.

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

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

Вот скажи, плиз, моделируем магазин.
Функция: Продать товар
Выход: проданный товар, чек
Вход: деньги
Управление: цена, политика скидок, правила продажи
Механизм: Кассир, Покупатель, POS-система

Что тут правильно или не правильно?

1453

Обучение / Re: Сайты и электронная литература по OCL

« : 24 Декабря 2011, 00:01:28 »

1. только недавно была тема: Тьюториары по MDA
2. поищите в интернете, на западных сайтах тема довольно широко представлена. у нас крайне незначительно.

1454

IDEF ARIS BPMN и пр. / IDEF0: Парадоксы "материального" баланса

« : 23 Декабря 2011, 23:56:47 »

Уважаемые коллеги, друзья.

Многие из вас знают, что я преподаю в университете. В том числе и структурные методы анализа и проектирования. Среди них встречается (пока) и IDEF0. IDEF0 достаточно прост. Есть неплохая книга деМарко. И все равно возникают разные проблемы с выбором и интерпретации модели. Особенно в дискуссиях со студентами, которые настолько горячие порой бывают, что они пишут некоторую неправду, например в prepodam.net

Казалось чего проще:
прямоугольник - функциональный блок, символизирующий деятельность, процесс, операцию или действие;
3 вида входа - 1 просто вход (то, что является материалом изменения в блоке), управление (то, что регламентирует работу по изменению входа), механизм (то, с помощью чего производится изменение входа)
выход - результат преобразования.
Входами чаще всего являются материальные и информационные объекты.

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

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

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

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

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

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

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

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

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

1455

Примеры / Re: Вопросы о диаграмме деятельностей

« : 22 Декабря 2011, 13:23:47 »

Вообще, поисковые машины работаю релевантно

http://www.omg.org/spec/UML/