Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
376
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?
Если трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей, то для ответа на вопрос, нужно переписать диаграмму без спец. обозначения. Получаем:
<>--[a=1 and a=1]-->State2
и
<>--[a=1 and a!=1]-->State3
Ответ: State2.

377
В книге Рамбо и Блаха в 4.10. прямо сказано: "Производными могут быть классы, ассоциации и атрибуты" и пример есть (правда не очень хороший)
Спасибо за ссылку на пример.

378
Если мы сделаем в третьем процессе цикл goto с join аналогичный первому, будет ли это означать, что индивидуальные токены заявок восстановлен из общей кучи, куда их сунули при перемещении?
Это возможно, но при этом на поток данных из второго datastore надо вешать select, определяющий в каком порядке выбираются заявки из общей кучи. Вместо цикла можно было бы задействовать <<iterative>> expansion region, если бы я знал как набор токенов-заявок превратить в один токен-коллекцию-заявок.

379
Клевая ссылка, спасибо.
В стандартной метамодели UML нет места, чтобы запомнить isDerived у класса. Можно без экзотики написать инвариант, запрещающий плохие комбинации наследования.

380
Интересно. Не припомню примеров derived классов.

381
Как реализуется цикличность обработки каждой заявки?
Сначала скажу, что моя версия диаграммы лишь демонстрировала, как я представляю себе цикличность "процесса клиента". Она полна недостатков. Например, можно составить вариант с одним, а не двумя datastore. Есть и другие пробелы.
Теперь по Вашему вопросу:
Никак. Перемещение заявок съедает все предлагаемые ему объектные токены и токен управления и разом их переваривает, выдавая на выход кучу токенов перемещённых заявок. Если важно/нужно, чтобы заявки перемещались по одной, то нужен явный цикл (похожий на клиентский). То же самое справедливо для "обработать заявки".

382
Замечание о необязательности initial node оказалось невполне уместно. ;D Без него не получится сделать цикл. Примерный вид диаграммы во вложении.
Loop на диаграммах деятельности, как мне кажется, нужен лишь в тех случаях, когда планируется генерировать структурированный код по диаграмме. Сделать кодогенератор, который породит код "без goto" по диаграмме из вложения не так просто, как генератор по loop. BPMN не знаю, поэтому не комментирую.

383
Эх. Если нужен цикл, значит нужно придумывать, когда его начинать, а когда заканчивать.
"Accept-флажок" внутри деятельности может не иметь входящих потоков. Т. е. initial node для "процесса клиента" заводить не обязательно. Если нужно учитывать время приёма заявки, можно завести [decision node и] сторожевое условие.

384

... непонятно  насколько корректна такая ДА
С точки зрения стандарта UML 2.5, если каждый из 3 процессов стартует из своего начального узла (initial node), то в рамках моделируемой деятельности "процесс клиента", "процесс перемещения" и "процесс обработки" отработает по одному разу. Т. е., скорее всего, в "процессе клиента" должен быть цикл, иначе в течение выполнения всей большой деятельности клиент будет лишь один (не более одного) и datastore не понадобится для его единственной заявки. 

385
А правильные то примеры с двумя асинхронными процессами встречаются? С удовольствием бы глянул. А то я похоже выразительные возможности диаграммы активности недооценивал
Конечно, проще искать ошибки, чем предложить что-то конструктивное. Если уточните, что нужно, попробую представить. В каком-то смысле, для асинхронных процессов достаточно диаграммы с форком.

386
Порекомендуйте пожалуйста, как можно улучшить понятность описания алгоритма?
Вы описываете алгоритм так, как-будто он -- сценарий. А он не сценарий. Используйте язык с полноценными "если-то-иначе" и понятность повысится.

387
Рисунок 19.9 из книжки про старый UML и на нём недостаёт одной стрелки, а другая нарисована сплошной вместо пунктирной.
Примеры по второй ссылке также не удачны (ЦБ с одним входным потоком и одним выходным; отсутствие select-а на потоке, идущем из datastore в "Обработать заказ").

388
Недочёт диаграммы видится в том, что сохранение "происходит" в двух узлах. Т. е. Вы завели узел действия "Сохранение с присвоением" и объектный узел datastore, семантика которого состоит в том, чтобы сохранять. Налицо дублирование. Про то, где пролегает граница между добавлением и сохранением судить не берусь, отмечу лишь, что и тут видится неоднозначность, т. к. в каком-то смысле каждый входящий  в datastore объектный токен "добавляется" к его содержимому.
Второе замечание относится к тому, что на исходящие из datastore потоки нужно явно повесить select-ы, чтобы было видно, что из всех предлагаемых datastore токенов выбирается тот, id которого совпадает с только что добавленным. Без select-ов диаграмму можно трактовать так, что после каждого добавления на "дальнейшие действия" направляется всё, что накопилось в datastore.
Итого: добавление datastore на диаграмму лишь затруднило её прочтение [с оглядкой на стандарт].

389
Ни ухом ни рылом в EA. Обычный приём для отображения на диаграмме -- заведение примечания.

390
Интересная ссылка, благодарю. Вот бы кто-нибудь не пошёл вслед за стандартом, и вместо добавления псевдосостояний двинутся в сторону "композитных" переходов. Сравнили бы результаты.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »