(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 

Конференция "ERwin"

Обсуждение вопросов, связанных с компанией Computer Associates, ее продуктами ERwin Data Modeler, ERwin Web Portal, ARCserve и др.

 
 
Добавить сообщение »

Тема: бизнес процесс и объекты в BPWin

Автор:  step Дата: 15.07.2003 11:59
Алексей пишет 15.07:
>...Что касается реагирования на запросы клиентов, то оно поверьте есть.

Беру свои слова о Вашем бездействии в развитии продукта обратно.

>The Arrow report lists all sources and destinations of the arrow, but does not list specific pairs of source and destination corresponding to
>individual arrow segments. The order of the source and destination lists is not significant.
>Кстати, как нельзя в тему нашей дискуссии, но как видите разработчики не считают, что здесь присутствует какой-либо баг.

В сообщении признается факт, но не дается оценка и не выражается позиция разработчика - "Да, просто перечень, да, пары безсмыслены, да, порядок в списке не значим". Здесь не звучит "это не баг, это я так задумал". Я бы все-таки сформулировал "это так получилось", так как вижу в этом следствие идеологии продукта - графические объекты диаграмм идентифицируются по репозитарию бизнес объектов, а не по неким техническим ID. Позиция, тем не менее, прозрачная и для пользователя безрадостная.
Ответить на сообщение »
 
Автор:  Алексей Дата: 15.07.2003 10:52
step пишет 15.07:

>лучше бы конструктивней на описание багов реагировали глядишь и продукт развивался бы интенсивней
Дмитрий день добрый.
Поверьте, что я двумя руками за то, чтобы продукт развивался интенсивней. Что касается реагирования на запросы клиентов, то оно поверьте есть. К примеру могу привести выдержку из ответа тех. поддержки по поводу некорректности построения отчета по стрелкам (кстати запрос был сделан именно после нашего с Вами общения - [открыть ссылку]):
The Arrow report lists all sources and destinations of the arrow, but does not list specific pairs of source and destination corresponding to
individual arrow segments. The order of the source and destination lists is not significant.
Кстати, как нельзя в тему нашей дискуссии, но как видите разработчики не считают, что здесь присутствует какой-либо баг.
Ответить на сообщение »
 
Автор:  step Дата: 15.07.2003 06:05
Резюмирую дискуссию по проблеме адекватности отчета:

Алексей пишет 14.07:
"...Да действительно, желаемый отчет Вы не получите при помощи BPwin, однако из этого не следует, что BPwin отчет по стрелкам строится не верно. Он просто не соответствует Вашим представлениям о том, какой он должен быть. Вы можете донести, свою точку зрения на данный отчет разработчикам данного ПО ..."

Иными словами Алексей признал неадекватность отчета по источникам и получателям. Но его позиция об адекватности отчета по вопросу именно ветвления стрелок остается крепкой и мной с самого начала не оспаривалась. Что касаемо моего представления об отчете, то оно соответствует стандарту IDEF и выражается в понятии "интерфейса между процессами". Получить представление об этих самых интерфейсах BPwin не позволяет. И предвзятость к продукту, и тупоумиие тут не причем.

>>В общем и целом, не пудрите мозги.
>Сие высказывание вообще хотелось бы оставить без ответа :)

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

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

Дмитрий.
Ответить на сообщение »
 
Автор:  Алексей Дата: 14.07.2003 15:53
step пишет 14.07:
>Вот блин, а попробовать, что Вам по пальцам рассказали - "не досуг"?
К счастью ли, к сожалению ли, однако будучи в отпуске я предпочитаю отдыхать от работы.
>В модели ArenaOrderEntry41-5 добавил стрелку Market Communication между Assess Market Place и Order Authorization (хоть с помощью тунелирования, хоть в явном виде сквозь все диаграммы - результат один).
>Предлагаемый Вами отчет по данной стрелке (Имя дуги, БП источник, БП получатель) выглядит так:
>Market Communication
>* Assess Market Place * { Tunnel }
>* Provide awareness inf.. * Manage Product Launch
>* Advertise Product * Liaise with Customer
>* Manage Product Launch * Sell additional services
> *Order Authorization
>Внимание вопрос: найдите мне в модели дугу Market Communication, которая соединяет Provide awareness information и Manage Product Launch, и куда это, интересно, подевалась только что построеная дуга Assess Market Place - Order Authorization.
Извините, однако в данном отчете речь идет о стрелке, а не о конкретной ее ветви. Не понимаю, почему Вы думаете, что если Provide awareness information и Manage Product Launch находятся на одном уровне, то это значит, что они связаны. В данном случае просто перечисляются лишь источники и приемники определенной стрелки, а не источники и приемники ее конктретной ветви.
>
>В общем и целом, не пудрите мозги.
Сие высказывание вообще хотелось бы оставить без ответа :)
Ответить на сообщение »
 
Автор:  step Дата: 14.07.2003 14:27
Алексей пишет 26.06:
>... В общем я пришел к выводу, что в IDEF0 данный отчет работает корректно.

Вот блин, а попробовать, что Вам по пальцам рассказали - "не досуг"?
В модели ArenaOrderEntry41-5 добавил стрелку Market Communication между Assess Market Place и Order Authorization (хоть с помощью тунелирования, хоть в явном виде сквозь все диаграммы - результат один).
Предлагаемый Вами отчет по данной стрелке (Имя дуги, БП источник, БП получатель) выглядит так:
Market Communication
* Assess Market Place * { Tunnel }
* Provide awareness inf.. * Manage Product Launch
* Advertise Product * Liaise with Customer
* Manage Product Launch * Sell additional services
*Order Authorization
Внимание вопрос: найдите мне в модели дугу Market Communication, которая соединяет Provide awareness information и Manage Product Launch, и куда это, интересно, подевалась только что построеная дуга Assess Market Place - Order Authorization.

В общем и целом, не пудрите мозги. Жаль только потраченого времени на общение с Вами в форуме и вне его.
Ответить на сообщение »
 
Автор:  Алексей Дата: 26.06.2003 11:39
step пишет 26.06:
>Алексей пишет 21.06:
>>Что касается правильности построения отчета по стрелкам в IDEF0 и стрелки "Market Communication" в частности, то BPwin строит отчет корректно.
>
>Алексей, честно говоря, с нетерпением жду вашего ответа на мои последние контраргументы. Все таки надеюсь что я не прав.

День добрый.
Несмотря на все мои попытки ввести в заблуждение отчет по стрелкам, я этого сделать не смог :)
Итак, я произвел следующие трансформации:
1) добавил стрелку Market Communication на контекстную диаграмму и провел эту стрелку до диаграммы А42-Qualify Customer Order
2) на диаграмме A42 я произвел следующее:
- еще раз просмотрев все свои изменения я пришел к выводу, что описать их проблематично, точнее понять мое описание, в случае необходимости я могу выслать изменненный файл и полученный отчет.
Хочу лишь добавить, что я разветвлял стрелку (один из потоков был слит с другой стрелкой), создал новую стрелку на основании одной из ветвей стрелки Market Communication, создал межстраничную ссылку, которая с диаграммы A42 была направлена на диаграмму A1, т.е. я пытался смоделировать целый ряд возможных ситуаций, однако как я уже сказал ошибок в отчете я не обнаружил. В общем я пришел к выводу, что в IDEF0 данный отчет работает корректно.
Ответить на сообщение »
 
Автор:  step Дата: 26.06.2003 06:41
Извините за повтор сообщений. Странным образом реагирует сайт - на попытку разместить сообщение выдает страницу ошибки, если пытаешся еще раз, то опять "извините страница не доступна", а потом с удивлением обнаруживаешь 40 своих сообщений (по количеству "неудачных" попыток).
Ответить на сообщение »
 
Автор:  step Дата: 26.06.2003 06:26
Алексей пишет 21.06:
>Что касается правильности построения отчета по стрелкам в IDEF0 и стрелки "Market Communication" в частности, то BPwin строит отчет корректно.

Алексей, честно говоря, с нетерпением жду вашего ответа на мои последние контраргументы. Все таки надеюсь что я не прав.
Ответить на сообщение »
 
Автор:  step Дата: 24.06.2003 11:02
Dmitiry Valov пишет 21.06:
>Когда ставится галочка в одной из колонок CRUD/IRUN, можно поставить галочку, а можно галочку со стрелкой рядом.

Галки радом с названием сущности означают ЖЦ сущности (CRUD). Галки рядом с атрибутами - ЖЦ атрибута (IRUN). Это не одно и то-же, например, сущность может быть создана, но при этом долго существовать без заполненных параметров. Расстановка галок CRUD и IRUN, два самостоятельных процесса и не всегда производится одновременно. Так в один заход можно определить где сущности создаются и редактируются, во-второй, какие конкретно аттрибуты заполняются и используются.

>Что означает стрелка?

Стрелка рядом с названием дуги означает тип входа в блок.
Стрелка рядом с символом CRUD, лично мной интерпретируется как "для сущности данный метод возможно существует, так как атрибуту сущности указан подобный метод". Иными словами если в блоке предусмотрена возможность читать атрибута сущности, то очевидно и для сущности существует возможность ее читать.

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

Галки, к сожалению, не наследуются в дочку и наоборот. Галки привязаны к конкретному коннекту дуги и блока, не взирая на декомпозицию. На мой взгляд, по крайней мере, снизу вверх это можно было бы предусмотреть.
Ответить на сообщение »
 
Автор:  step Дата: 24.06.2003 10:28
Алексей пишет 21.06:
>Что касается правильности построения отчета по стрелкам в IDEF0 и стрелки "Market Communication" в частности, то BPwin строит отчет корректно.

Нет, Алексей. В стандартной модели отчет лишь "выглядит" правильно. Попробуйте тот способ о котором я говорил - добавьте стрелку Market Communication от источника в самом верху браузера модели к приемнику в самом низу. И тогда увидите дефект. Кстати, стрелка Market Communication единственная в модели на которой можно отследить дефект. Откройте какую-нибудь не стандартную модель в которой существуют дуги, для которых имеется несколько источников и несколько приемников, если блоки будут достаточно отдалены (в смысле браузера модели) то вам удастся воткнуться в ошибку алгоритма.

>Что касается DFD, то данный отчет не применим в теории, так как сама методология предполагает в том числе существование двунаправленных стрелок, что считать источником, а что приемником в данном случае?

Действительно. Ну, тогда мне просто интересно знать коммутирующие блоки ;-).
Ответить на сообщение »
 
Автор:  Dmitiry Valov Дата: 21.06.2003 14:04
step пишет 20.06:
>Dmitiry Valov пишет 19.06:
>
>>Это все хоршо, но прорблема в том, как получить адекватные отчеты.
>>Например список документов. Как отделить стрелки с документами от дургих (формально)
>>Как увидестьт иерархическую структуру документов, подчиненность.
>>Средствами bpwin этого не сделать?
>
>Попробуйте использовать такую методику. Интерпретируйте стрелки как бизнес-роли документов, а сами документы моделируйте посредством Entity. Например в торговле, печатный документ "Заявка" с одной стороны может играть роль "распоряжения на резерв товара", с другой стороны "приказ на отгрузку", и с третьей "Отчет об отгрузке со склада".
>
>Моделируем ситуацию так. Создаем сущность "Заявка" и стрелки с упомянутыми названиями ролей. К этим стрелкам цепляем "Заявку". В модели создаем работу "принять заказ" и выходом указываем "распоряжение...", которое подаем на контроль работы "управлять зарезервированый товаром", одним из результатов этой работы ("управлть...") будет "приказ на отгрузку", который подается на контроль следующей работы - "загружать в транспорт", ну а в последней результатом будет "Отчет об отгрузке со склада".
>И вот теперь ключевой момент, для каждой созданной работы указываем правила работы с сущностью "Заявка" (в диаграмме вызываем мышкой контекстное меню для активити и выполняем команду Data Usage). В паре "принять заказ"-"распоряжение.." устанавливаем метод "С"("Created"), в паре "управлять"-"распоряжение" устанавливаем "R", в паре "загружать"-"Отчет" устанавливаем "U".
>Теперь воспользовавшись стандартным отчетом Data Usage Репорт вы сможете получить табличку, в которой во-первых будут упомянуты только те стрелки, в которых есть сущности (т.е. решили задачу фильтрации стрелок не имеющих отношения к потокам документов(сущностей)), во-вторых, имеем по каждому печатному документу его жизненный цикл - в какой работе создан, в какой использовался, где редактировался, какие роли играет в деятельности.
>
>Ну а задачу источника/получателя мы не так и не ришили, и похоже вряд ли удастся.
>
>В вашем сообщении мне вот что не понятно - что вы имеете в виду под "подчиненностью" документов? "Один отменяет другой"? "Один создается на основе другого"? или иное?

Вопрос технического плана.
Когда ставится галочка в одной из колонок CRUD/IRUN, можно поставить галочку, а можно галочку со стрелкой рядом.
Что означает стрелка? И потом, если я задаю принципы использования сущности для дочернего процесса, что будет с ролительским его атрибуты не поменяются? т.е. целосьтностьь в этотм смысле не поддерживается?

Дмитрий
Ответить на сообщение »
 
Автор:  Алексей Дата: 21.06.2003 12:33
step пишет 21.06:
>Для IDEF3, теоритически, можно выделить цепочки работ (глазками на диаграмме), практически - трудно подобрать формальный признак принадлежности к одной цепочке. Так что и здесь без специальных средств не обойтись.

День добрый, опять же для определения признака принадлежности к одной цепочке можно выбрать механизм UDP предложенный в BPwin, однако, что касается сортировки в отчете, к сожалению без Excel на данном этапе не обойтись.
Ответить на сообщение »
 
Автор:  Алексей Дата: 21.06.2003 12:18
step пишет 20.06:
>>Что касается DFD, то этот момент будет учтен в моих предстоящих тестах, дабы расставить точки над "и". Наше с вами общение я хорошо помню :)
>>
>
>Вот взял стандартную модель ArenaOrderEntry41-5, убил все диаграммы DFD IDEF3. Особенно обратите внимание на поток "Market Communication" он, во-первых, имеет и слияние и ветвление, во-вторых, подается на вход и одновременно выходит из активити "Manage Product Launch", в третьих имеет два источника и четыре приемника - в общем, идеальный пример для теста.
>
День добрый.
Что касается правильности построения отчета по стрелкам в IDEF0 и стрелки "Market Communication" в частности, то BPwin строит отчет корректно. В итоге мы имеем: БП источник (Provide awareness information, Advertise Product, Manage Product Launch), БП получатель ({ Tunnel }, Manage Product Launch, Liaise with Customer, Sell additional services). Слияний и ветвлений у данной стрелки нет и это действительно так, так как в данном случае предполагается слияние с другими стрелками, а не с экземплярами стрелки и соответственно, ветвление - это разбиение на ряд других стрелок, а не распараллеривование стрелки на ряд экземпляров.
Что касается DFD, то данный отчет не применим в теории, так как сама методология предполагает в том числе существование двунаправленных стрелок, что считать источником, а что приемником в данном случае?
Ответить на сообщение »
 
Автор:  step Дата: 21.06.2003 07:41
Dmitiry Valov пишет 20.06:

>Я попробовал, но возникла сделующая проблема.
>При использовании Data Usage Report прорцессы нельзя отсортироватьт в порядке их прохождения.
>Таким образом получается набор из прорцессов в которых участвует изучаемая сущность, но как такового жизненного цикла не видно, т.е. нельзя проследить как она живет от рождения до уничтоожения
>

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

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

ЖЦ документов можно указать только в таком формате: (группа работ в котором документ может быть создан) - (группа работ в котором документ может быть редактирован) - (группа работ в котором документ может быть использован). Расширить количество этапов ЖЦ можно лишь использовав в каждом документе специальные атрибуты ("Создан", "Обработан", "Подписан", "Внесен в дело", ""Заархивирован" и пр.) и далее по этим атрибутам указывать в активити методы IRUN.

Сортировать придется в Excel.
Ответить на сообщение »
 
Автор:  Dmitiry Valov Дата: 20.06.2003 16:12
step пишет 20.06:
>Dmitiry Valov пишет 20.06:
>
>>К стати гипотеза, что в рамках IDEF0 все хорошо подтвердилась?
>
>Нет. Я смог показать сценарий в котором формируется неправильный отче и не смог найти для этого сценария какой-нибудь подходящий отчет. Но может быть -это мои проблемы? ;-)

Может ...
:)
Возвращаясь к предложенному метотду (когда к стрелкам привязываются данные, а у процессов указывается, как используются данные)
Я попробовал, но возникла сделующая проблема.
При использовании Data Usage Report прорцессы нельзя отсортироватьт в порядке их прохождения.
Таким образом получается набор из прорцессов в которых участвует изучаемая сущность, но как такового жизненного цикла не видно, т.е. нельзя проследить как она живет от рождения до уничтоожения
Ответить на сообщение »
 
Автор:  step Дата: 20.06.2003 15:04
Dmitiry Valov пишет 20.06:

>К стати гипотеза, что в рамках IDEF0 все хорошо подтвердилась?

Нет. Я смог показать сценарий в котором формируется неправильный отче и не смог найти для этого сценария какой-нибудь подходящий отчет. Но может быть -это мои проблемы? ;-)
Ответить на сообщение »
 
Автор:  step Дата: 20.06.2003 13:33
Как ни смотрел, а все одно - по каждой стрелке всегда правильно указаны все источники, всегда правильно указаны все приемники, при этом источники и приемники в отчете сортируются в иерархическом порядке отдельно друг от друга, а не по принципу связности через поток. Тройки "Источник"-"стрелка"-"приемник" совпадаеют только при удачном стечении обстоятельств. Пример дефекта - если источник стрелки находится в самом верху браузера модели, а приемник в самом низу, то для этой тройки вы не получите строку отчета. Попробуйте в модели ArenaOrderEntry41-5 (она в папке примеров к продукту) соединить стрелкой Market Communication работы Order Authorization и Provide awareness information (хоть ответвление, хоть еще один поток, все едино) и убедитесь что отчет парит. Проверил - нотация ни при чем, для всех диаграм один алгоритм. Для того чтобы народ не смущать надо было в АрроуРепорте вместо галок переключатель поставить - либо отчет по приемникам, либо отчет по получателям.
Ответить на сообщение »
 
Автор:  Dmitiry Valov Дата: 20.06.2003 13:33
Алексей пишет 19.06:
>Dmitiry Valov пишет 19.06:
>>>День добрый, Дмитрий.
>>>На верхнем уровне у Вас должна быть стрелка, к примеру, Документация, а на нижележащем уровне Вы можете разветвить данную стрелку в соответствии с тем какая часть Документации используется для той или иной составляющей процесса. Конечно, в моем примере используется методология IDEF0.
>>
>>Это все хоршо, но прорблема в том, как получить адекватные отчеты.
>>Например список документов. Как отделить стрелки с документами от дургих (формально)
>>Как увидестьт иерархическую структуру документов, подчиненность.
>>Средствами bpwin этого не сделать?
>>
>День добрый, Дмитрий. Средствами одного BPwin получить такой отчет не получится. Однако возможно создать подобный отчет используя связку BPwin+Excel, причем Excel в основном будем использовать для придания отчету "приятного" вида и сортировки данных (к сожалению в данный момент построители отчетов в BPwin не позволяют применить фильтр на один из столбцов участвующих при построении отчета и произвести сортировку по столбцу). Итак в итоге получим следующий отчет, далее следует шапка отчета (названия столбцов подкорректированны в Excel).
>_____________________________
>Название стрелки БП источник БП получатель Родитель для стрелок Потомок стрелки Включает в себя Является частью тип стрелки
>_____________________________
>Данный отчет построен при помощи стандартного отчета по стрелкам (Tools-Reports-Arrow Report), не буду в данный момент перечислять все столбцы которые выбраны для его построения, хочу лишь заметить что при помощи данного отчета можно достаточно наглядно просмотреть иерархию стрелок и их подчиненность. И еще один немаловажный момент, как формально отделить стрелки документов от других типов стрелок. В BPwin встроены свойства определяемые пользователем (UDP) итак добавляем один UDP (меню Model-UDP Definition Editor) под названием тип стрелки (последний столбец в нашем отчете), тип UDP выбирается равным text list (single selection). Далее всем стрелкам относящимся к документам присваивается данный тип UDP. В итоге мы при формировании отчета ясно видим, что относится к документам и этот UDP позволяет впоследствии отсортировать данные в Excel.
>Н-да, объяснение получилось довольно пространным, если интересно могу прислать модель на основании которой строился отчет и собственно сам отчет отредактированный в Excel.
>
>С уважением,
>Алексей.
>

Спасибо, смысл примерно понятен.
Было бы интересно посмотреть на отчет про который вы говорили.
Если не трудно вышлите пожалуйста на dvalov@one.lv

Дмитрий
Ответить на сообщение »
 
Автор:  Dmitiry Valov Дата: 20.06.2003 13:29
step пишет 20.06:
>Dmitiry Valov пишет 19.06:

>Попробуйте использовать такую методику. Интерпретируйте стрелки как бизнес-роли документов, а сами документы моделируйте посредством Entity. Например в торговле, печатный документ "Заявка" с одной стороны может играть роль "распоряжения на резерв товара", с другой стороны "приказ на отгрузку", и с третьей "Отчет об отгрузке со склада".
>
>Моделируем ситуацию так. Создаем сущность "Заявка" и стрелки с упомянутыми названиями ролей. К этим стрелкам цепляем "Заявку". В модели создаем работу "принять заказ" и выходом указываем "распоряжение...", которое подаем на контроль работы "управлять зарезервированый товаром", одним из результатов этой работы ("управлть...") будет "приказ на отгрузку", который подается на контроль следующей работы - "загружать в транспорт", ну а в последней результатом будет "Отчет об отгрузке со склада".
>И вот теперь ключевой момент, для каждой созданной работы указываем правила работы с сущностью "Заявка" (в диаграмме вызываем мышкой контекстное меню для активити и выполняем команду Data Usage). В паре "принять заказ"-"распоряжение.." устанавливаем метод "С"("Created"), в паре "управлять"-"распоряжение" устанавливаем "R", в паре "загружать"-"Отчет" устанавливаем "U".
>Теперь воспользовавшись стандартным отчетом Data Usage Репорт вы сможете получить табличку, в которой во-первых будут упомянуты только те стрелки, в которых есть сущности (т.е. решили задачу фильтрации стрелок не имеющих отношения к потокам документов(сущностей)), во-вторых, имеем по каждому печатному документу его жизненный цикл - в какой работе создан, в какой использовался, где редактировался, какие роли играет в деятельности.
>
>Ну а задачу источника/получателя мы не так и не ришили, и похоже вряд ли удастся.
>
>В вашем сообщении мне вот что не понятно - что вы имеете в виду под "подчиненностью" документов? "Один отменяет другой"? "Один создается на основе другого"? или иное?

Большое спасибо за информацию. Сегодня попытаюсь попробовать данную методику ....
По поводу "подчиненности", немного неправильно выразился. Скорее имелась ввиду классификация документов. Скажем все документы распадаются на документы товародвижения и административные, товародвижения к примеру на отгрузки и прихода или еще как-то. Смысл в том, что иногда хочется оперировать группой документов, а иногда спускаться до конкретных документов. Но, как я понимаю этот может быть решено с помощью того- же Excel'я
К стати гипотеза, что в рамках IDEF0 все хорошо подтвердилась?
Ответить на сообщение »
 
Автор:  step Дата: 20.06.2003 12:28
>Что касается DFD, то этот момент будет учтен в моих предстоящих тестах, дабы расставить точки над "и". Наше с вами общение я хорошо помню :)
>

Вот взял стандартную модель ArenaOrderEntry41-5, убил все диаграммы DFD IDEF3. Особенно обратите внимание на поток "Market Communication" он, во-первых, имеет и слияние и ветвление, во-вторых, подается на вход и одновременно выходит из активити "Manage Product Launch", в третьих имеет два источника и четыре приемника - в общем, идеальный пример для теста.
Ответить на сообщение »
 
Автор:  Алексей Дата: 20.06.2003 11:55
step пишет 20.06:
>Алексей пишет 20.06:
>>... Я проведу еще ряд тестов, однако я был бы Вам очень признателен если бы Вы выслали либо модель, либо
>>сценарий на который я мог бы ориентироваться для воспроизведения ошибки.
>>С уважением, Алексей.
>
>Алексей, мы с вами общались именно на эту тему не более 3 месяцев назад вот здесь [открыть ссылку] там и сценарий есть.
>
>Но сегодня вы выдвинули очень интересную гипотезу - что данная проблема касается только нотации IDEF3 (кстати, а в DFD как?). Хочу это проверить, так как сулит хорошую возможность улучшить отчетность. Если это будет так, то будет Вам превеликая благодарность...;-)
>

Что касается DFD, то этот момент будет учтен в моих предстоящих тестах, дабы расставить точки над "и". Наше с вами общение я хорошо помню :)
Ответить на сообщение »
 
Автор:  step Дата: 20.06.2003 11:43
Алексей пишет 20.06:
>... Я проведу еще ряд тестов, однако я был бы Вам очень признателен если бы Вы выслали либо модель, либо
>сценарий на который я мог бы ориентироваться для воспроизведения ошибки.
>С уважением, Алексей.

Алексей, мы с вами общались именно на эту тему не более 3 месяцев назад вот здесь [открыть ссылку] там и сценарий есть.

Но сегодня вы выдвинули очень интересную гипотезу - что данная проблема касается только нотации IDEF3 (кстати, а в DFD как?). Хочу это проверить, так как сулит хорошую возможность улучшить отчетность. Если это будет так, то будет Вам превеликая благодарность...;-)
Ответить на сообщение »
 
Автор:  Алексей Дата: 20.06.2003 09:43
step пишет 20.06:
>
>>_____________________________
>>Название стрелки БП источник БП получатель Родитель для стрелок Потомок стрелки Включает в себя Является частью тип стрелки
>>_____________________________
>
>Добрый день.
>Алексей, боюсь Вы предлагаете не оттестированный Вами способ. Дело в том, что не смотря на то, что формально BPWin может сформировать указанный отчет на практике Вам придется проверять каждую строку и ПРАВИТЬ многие строки. Так как информация о ветвлении стрелок, их источниках и приемниках BPWin собирается неверно. Однажды попавшись на эту удочку, я до сих пор зол на BPWin за подобные шутки.

День добрый.
Нет почему же, этот метод я конечно же тестировал. Возможно это была не слишком сложная модель (2 уровня декомпозиции). Что касается моего примера, то в нем я не обнаружил каких либо несоответствий. Работаю я с версией продукта 4.1sp2b. Возможно ли получить часть Вашей модели, для того чтобы выявить ошибку? Либо не могли бы Вы описать сценарий воспроизведения описанной Вами ошибки? Я предполагаю, что этот отчет не совсем корректно будет работать в методологии IDEF3 в виду того, что в данной методологии возможно создать ряд стрелок с одинаковыми названиями, а уникальных идентификаторов ветвей этих стрелок в BPwin не присутствует. Однако в отчете по стрелкам IDEF0 я не вижу на чем BPwin может спотыкнуться. Я проведу еще ряд тестов, однако я был бы Вам очень признателен если бы Вы выслали либо модель, либо сценарий на который я мог бы ориентироваться для воспроизведения ошибки.
С уважением, Алексей.
Ответить на сообщение »
 
Автор:  step Дата: 20.06.2003 07:54
Dmitiry Valov пишет 19.06:

>Это все хоршо, но прорблема в том, как получить адекватные отчеты.
>Например список документов. Как отделить стрелки с документами от дургих (формально)
>Как увидестьт иерархическую структуру документов, подчиненность.
>Средствами bpwin этого не сделать?

Попробуйте использовать такую методику. Интерпретируйте стрелки как бизнес-роли документов, а сами документы моделируйте посредством Entity. Например в торговле, печатный документ "Заявка" с одной стороны может играть роль "распоряжения на резерв товара", с другой стороны "приказ на отгрузку", и с третьей "Отчет об отгрузке со склада".

Моделируем ситуацию так. Создаем сущность "Заявка" и стрелки с упомянутыми названиями ролей. К этим стрелкам цепляем "Заявку". В модели создаем работу "принять заказ" и выходом указываем "распоряжение...", которое подаем на контроль работы "управлять зарезервированый товаром", одним из результатов этой работы ("управлть...") будет "приказ на отгрузку", который подается на контроль следующей работы - "загружать в транспорт", ну а в последней результатом будет "Отчет об отгрузке со склада".
И вот теперь ключевой момент, для каждой созданной работы указываем правила работы с сущностью "Заявка" (в диаграмме вызываем мышкой контекстное меню для активити и выполняем команду Data Usage). В паре "принять заказ"-"распоряжение.." устанавливаем метод "С"("Created"), в паре "управлять"-"распоряжение" устанавливаем "R", в паре "загружать"-"Отчет" устанавливаем "U".
Теперь воспользовавшись стандартным отчетом Data Usage Репорт вы сможете получить табличку, в которой во-первых будут упомянуты только те стрелки, в которых есть сущности (т.е. решили задачу фильтрации стрелок не имеющих отношения к потокам документов(сущностей)), во-вторых, имеем по каждому печатному документу его жизненный цикл - в какой работе создан, в какой использовался, где редактировался, какие роли играет в деятельности.

Ну а задачу источника/получателя мы не так и не ришили, и похоже вряд ли удастся.

В вашем сообщении мне вот что не понятно - что вы имеете в виду под "подчиненностью" документов? "Один отменяет другой"? "Один создается на основе другого"? или иное?
Ответить на сообщение »
 
Автор:  step Дата: 20.06.2003 06:57

>_____________________________
>Название стрелки БП источник БП получатель Родитель для стрелок Потомок стрелки Включает в себя Является частью тип стрелки
>_____________________________

Добрый день.
Алексей, боюсь Вы предлагаете не оттестированный Вами способ. Дело в том, что не смотря на то, что формально BPWin может сформировать указанный отчет на практике Вам придется проверять каждую строку и ПРАВИТЬ многие строки. Так как информация о ветвлении стрелок, их источниках и приемниках BPWin собирается неверно. Однажды попавшись на эту удочку, я до сих пор зол на BPWin за подобные шутки.
Ответить на сообщение »
 
Автор:  Алексей Дата: 19.06.2003 13:58
Dmitiry Valov пишет 19.06:
>>День добрый, Дмитрий.
>>На верхнем уровне у Вас должна быть стрелка, к примеру, Документация, а на нижележащем уровне Вы можете разветвить данную стрелку в соответствии с тем какая часть Документации используется для той или иной составляющей процесса. Конечно, в моем примере используется методология IDEF0.
>
>Это все хоршо, но прорблема в том, как получить адекватные отчеты.
>Например список документов. Как отделить стрелки с документами от дургих (формально)
>Как увидестьт иерархическую структуру документов, подчиненность.
>Средствами bpwin этого не сделать?
>
День добрый, Дмитрий. Средствами одного BPwin получить такой отчет не получится. Однако возможно создать подобный отчет используя связку BPwin+Excel, причем Excel в основном будем использовать для придания отчету "приятного" вида и сортировки данных (к сожалению в данный момент построители отчетов в BPwin не позволяют применить фильтр на один из столбцов участвующих при построении отчета и произвести сортировку по столбцу). Итак в итоге получим следующий отчет, далее следует шапка отчета (названия столбцов подкорректированны в Excel).
_____________________________
Название стрелки БП источник БП получатель Родитель для стрелок Потомок стрелки Включает в себя Является частью тип стрелки
_____________________________
Данный отчет построен при помощи стандартного отчета по стрелкам (Tools-Reports-Arrow Report), не буду в данный момент перечислять все столбцы которые выбраны для его построения, хочу лишь заметить что при помощи данного отчета можно достаточно наглядно просмотреть иерархию стрелок и их подчиненность. И еще один немаловажный момент, как формально отделить стрелки документов от других типов стрелок. В BPwin встроены свойства определяемые пользователем (UDP) итак добавляем один UDP (меню Model-UDP Definition Editor) под названием тип стрелки (последний столбец в нашем отчете), тип UDP выбирается равным text list (single selection). Далее всем стрелкам относящимся к документам присваивается данный тип UDP. В итоге мы при формировании отчета ясно видим, что относится к документам и этот UDP позволяет впоследствии отсортировать данные в Excel.
Н-да, объяснение получилось довольно пространным, если интересно могу прислать модель на основании которой строился отчет и собственно сам отчет отредактированный в Excel.

С уважением,
Алексей.
Ответить на сообщение »
 
Автор:  Dmitiry Valov Дата: 19.06.2003 09:51
>День добрый, Дмитрий.
>На верхнем уровне у Вас должна быть стрелка, к примеру, Документация, а на нижележащем уровне Вы можете разветвить данную стрелку в соответствии с тем какая часть Документации используется для той или иной составляющей процесса. Конечно, в моем примере используется методология IDEF0.

Это все хоршо, но прорблема в том, как получить адекватные отчеты.
Например список документов. Как отделить стрелки с документами от дургих (формально)
Как увидестьт иерархическую структуру документов, подчиненность.
Средствами bpwin этого не сделать?
Ответить на сообщение »
 
Автор:  Алексей Дата: 16.06.2003 18:47
Dmitiry Valov пишет 16.06:
>Добрый день
>Подскажите, как правильно использовать BPWin для описания следующей ситуации.
>Есть диаграмм представляющая декомпозицию некоторого бизнес-процесса.
>Допустим, бизнес процесс распадается на четыре составляющие.
>Например, бизнес процесс: «Создать что-либо» распадается на четыре блока
>- Анализировать
>- Проектировать
>- Реализовать
>- Внедрить
>При этом есть информационный поток (например документация), который проходит через все составляющие бизнес процесса.
>Совершенно понятно, что между различными составляющими бизнес процесса в состав потока входят различные документы (требования, ТЗ, отчеты о реализации и т.д.).
>Как используя BPWin указать состав потока? Надо сделать это так, чтобы можно было получить отчет типа: «Документы, используемые в глобальном бизнес процессе».
>
День добрый, Дмитрий.
На верхнем уровне у Вас должна быть стрелка, к примеру, Документация, а на нижележащем уровне Вы можете разветвить данную стрелку в соответствии с тем какая часть Документации используется для той или иной составляющей процесса. Конечно, в моем примере используется методология IDEF0.
Ответить на сообщение »
 
Автор:  Dmitiry Valov Дата: 16.06.2003 15:02
Добрый день
Подскажите, как правильно использовать BPWin для описания следующей ситуации.
Есть диаграмм представляющая декомпозицию некоторого бизнес-процесса.
Допустим, бизнес процесс распадается на четыре составляющие.
Например, бизнес процесс: «Создать что-либо» распадается на четыре блока
- Анализировать
- Проектировать
- Реализовать
- Внедрить
При этом есть информационный поток (например документация), который проходит через все составляющие бизнес процесса.
Совершенно понятно, что между различными составляющими бизнес процесса в состав потока входят различные документы (требования, ТЗ, отчеты о реализации и т.д.).
Как используя BPWin указать состав потока? Надо сделать это так, чтобы можно было получить отчет типа: «Документы, используемые в глобальном бизнес процессе».
Ответить на сообщение »
 

Добавить сообщение »

 Распечатать »
 Правила публикации »
   
 Рекомендовать »  
 

Магазин программного обеспечения   WWW.ITSHOP.RU
erwin Data Modeler Standard Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
erwin Data Modeler Workgroup Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
erwin Data Modeler Navigator Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
IBM Domino Utility Server Processor Value Unit (PVU) License + SW Subscription & Support 12 Months
VideoStudio X9 Pro. Электронный ключ.
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Компьютерный дизайн - Все графические редакторы
Компьютерные книги. Рецензии и отзывы
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Русификация рамки IDEF0 BPWin4 (41)
Возможно ли русифицировать рамку диаграмм в BPWin4?
 
Проектирование курсовой работы в BPWin (32)
Здравствуйте.Подскажите пожалуйста где можно найти примерное проектирование курсовой работы...
 
Русификация ERWin (29)
Здравствуйте! Используем версию ERwin 4.1 в сети,но при создании логической модели вместо...
 
применение CA Process Modeller (BPWin) и связь моделей BPWin и ErWin (1)
Не очень понятна связь прогр продуктов CA Process Modeller (BPWin) и CA Data Modeller...
 
Erwin 3.5.2 (6)
Где скачать или кто может поделиться прогой Erwin 3.5.2? И как открыть файл из 3.5.2 в Erwin...
 
 
 



    
rambler's top100 Rambler's Top100