OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 14 Декабрь, 2019 00:58

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.
Автор Сообщение
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 22 Август, 2012 20:52 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Ув. Владислав Жаринов.

Как Вы уже, возможно, успели заметить, мне приходится заниматься программированием этих бизнес-процессов, будь они неладны. Попробую поделиться и своими пятью копейками.
Жизнь заставила описание процессов привести к относительно простой и универсальной модели. Упрощённо ее можно представить в виде нескольких таблиц или списков:

- бизнес-модули
- регистры информации и субрегистры
- балансовые единицы
- бизнес-объекты
- бизнес-участки
- группы пользователей или роли
- список пользователей

Слово-паразит "бизнес-..." лично мне не нравится, но так исторически попсово повлиял "ынтырпрайз". Подробнее:

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

- регистры - в первом приближении, это списки типов или видов документов, которые прикреплены к каждому бизнес-модулю. Т.е. для бизнес-модуля "расчёт бюджета ..." указывается, что в его рамках ведутся документы: "договор, форма такая-то" для отношений с поставщиками, "договор ..." для клиентов, "спецификация проекта, форма..." и т.д. Для "учёта материальных запасов": "акт приёмки ...", "накладная отгрузки" и т.д. Структура документов может быть тоже раскрыта в отдельных описаниях, сейчас этот момент опускаем;
- субрегистры - это некая вариантная часть регистра. К примеру, для "спецификации проекта" можно отдельно выделить "привязанные" бухгалтерские проводки и проч. реквизиты, если это предусмотрено. И, таким образом, как бы, для "обслуживания" документа явно предопределяется два этапа: оформление или создание спецификации и её проведение в бухгалтерии. Можно добавить ещё один "субрегистр" - "одобрямс" от начальника, и тогда бухгалтерия "займётся" документом после "подписи" ответственного начальника. Или, к примеру, для "акта приёмки товаров" можно выделить два субрегистра: первый -цены и суммы, второй - реквизиты поставщика. Тогда, например, складской работник имеет только количественные данные, кто-то другой может и "подбивать суммы", а кто-то имеет полный доступ к документу, включая "коммерческую тайну" - реального поставщика. В общем, о нюансах сущности субрегистров будет ещё сказано.
Кроме того, регистры - это универсальное понятие, это не только реальные первичные (внешние и внутренние) документы, это и справочные массивы данных, и различные режимы работы, действия в рамках программной системы. Формально, каждый "чих" в прогкомплексе оформляется документально, пусть и несколько абстрактно. Если кто-то запустил какой-то расчёт данных (т.е. "выполнил" какой-то "регистр" с учётом варианта-субрегистра), то это всё фиксируется, и можно выписать справку, кто и когда что именно сделал.
Таким образом, через регистры и их опции - субрегистры - раскрывается сущность бизнес-модуля, т.е. указывается, какая осуществляется деятельность;

- балансовые единицы - это список "владельцев" бизнес-модулей, т.е. это "хозяева". В системе их может быть несколько, они повязаны между собой, возможен консолидированный учёт. Скажем, головное предприятие и дочерние, предприятие может через кучу частных предпринимателей осуществлять "поставку продукции", в конце концов, возможна "чёрная бухгалтерия" и т.д.;

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

- бизнес-участки - это аналитические участки бизнес-деятельности предприятия. Например, создаём участок №36 "Обслуживание клиентов ...", где указываем, какая деятельность выполняется - составляем список используемых регистров данных (т.е. документов и действий нужных бизнес-модулей), к примеру, все регистры из "расчёт бюджета..." и часть регистров из "материального учёта", "прикрепляем" к участку группу клиентов в рамках регистров "расчёт бюджета" и несколько складов в рамках "учёта материалов". При этом согласно структуре управления предприятием никакого подразделения №36 "Обслуживание клиентов ..." нет, это некое виртуальное определение в разрезе информационного учёта. А вот в этом участке №36 косвенно задействованы реальные подразделения предприятия: склад №12, склад №16 и к нему (бизнес-участку) будут "привязаны" некоторые работники этих складов, а также представители отдела маркетинга и финотдела. Можем создать ещё один похожий участок №37, где укажем другую группу клиентов, и, возможно другие склады и т.п.
Иными словами, вся деятельность предприятия (а точнее, та, которая "автоматизирована") ведется только через бизнес-участки (в информационном плане). Каждый участок привязан к нужной балансовой единице (участок может "входить" только в одну балансовую единицу), для каждого участка указывается список деятельности - регистры из нужных бизнес-модулей, и к каждому участку привязываются бизнес-объекты в рамках соответствующих регистров. При этом один и тот же бизнес-объект не может быть привязан к одному и тому же регистру дважды. Например, если склад №12 мы привязали к регистрам материального учёта на участке №36, то этот склад больше нигде не может быть прикреплён к материальному учёту, но в рамках расчёта зарплаты он может быть указан на другом участке (или на том же №36);

- роль - группа пользователей, которые выполняют одни и те же действия. Составляется список ролей, каждой роли назначаются права: указывается, к какому бизнес-участку имеется доступ, к каким его регистрам и их субрегистрам, а также с какими бизнес-объектами возможна работа на участке. При этом для регистров задаются права для выполнения операций чтения документа или выполнения (если это действие/режим), редактирования и удаления, а также чтение/выполнение связанных субрегистров. Таким образом, через права пользователей есть возможность задать, кроме списка допустимых действий, косвенно и порядок работ по исполнителям. К примеру, создают какой-то документ те, кто имеет на это право, только после создания документа специалист по экономическим вопросам может проставить в нём цены и суммы, затем начальник поставит свою подпись, и только потом бухгалтерия его может акцептировать.
Роли в программной системе не обязательно те должности, которые указаны в штатном расписании. Скажем, на фирме, где всего-лишь директор и бухгалтер да кладовщик, роль менеджера по подготовке спецификации заказа может исполнять бухгалтер, а его деятельность в рамках бухучёта может быть и не отражена в комплексе;

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

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

Вся модель задаётся в виде таблиц. Что касается граф-схем. Мою историю с рисованием Вы уже знаете. Имхо, в 90 процентах случаев после составления этих табличек в схемах потребности, реальной, нет. Модель, конечно, составляется не сразу, циклически, с разборами полётов, после ряда этапов разработки и т.д. Более того, ситуация такова. От меня и моих коллег, как представителей небольшой компании-разработчика всяких автоматизированных систем, не всегда (а точнее, редко) требуют блок-схемы в рамках документации к комплексу. Как правило, их всё-равно никто не смотрит толком, да и документацию не читают тоже, одни формальности. Теоретически, наоборот, нам должны выдавать схемы в рамках технического задания, и я, откровенно говоря, что-то не помню, чтобы нам какие-то "бизнес-описатели" давали реально полезную схему, одна "бизнес-вода". Схемки приходится иногда составлять для разборов полётов, причём полёт устраиваем мы, поэтому приходится выжимать максимум реально возможного и, прежде всего, полезного из графического представления, и Вы уже смогли заметить, под какую горячую руку попал ДРАКОН. В принципе, если бы была адекватная технология создания схем, при этом схемы интегрированы с остальной документацией, а то и с программным кодом (некий ГРАФИТ-ФЛОКС), то я не исключаю, что в практике схем было бы больше, а то и всё бы документировалось, как и требуется. Вот сейчас оцениваются на эту роль Р-схемы.

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

А схемы деятельности для одного исполнителя по мотивам как выше в постах: в цикле ждать события, а в фоне при отсутствии событий заниматься такими-то обязанностями или курить в сторонке - имхо, слабо полезны. Тем более, в реальной жизни он эту инструкцию "будет нарушать" беспрерывно, в фоновом цикле, так сказать :). Исполнитель разберётся, когда ему покажут его список "регистров".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 23 Август, 2012 06:09 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Также считаю, что рассуждать об организованной деятельности нужно от цели оргсистемы и её реализации. Потому с Вашими выводами в общем согласен. И обратите теперь внимание, где здесь место алгоритмов (и соответственно средств их записи)... :)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 23 Август, 2012 19:23 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Я обратил внимание, что в свете этой темы пытались говорить и о методах верификации систем и о прочем контроле. В реальной жизни, как я замечаю, фактически работает только один способ, с соответствующим уровнем гарантий, что-то вроде "разработки через поведение", примерно так его обзывают (есть вики, небольшая статья). Правда, метод используется не так формально, но "поведенческие тезисы" реально имеются и используются, можно их "подшить" к описательным таблицам процессов.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Пятница, 24 Август, 2012 07:21 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Как можно понять, материалы относятся к тестированию, а не к верификации. Одно, безусловно, не отменяет другое - ибо абсолютные покрытия и тестами и требованиями недостижимы с формальной т. зр. - можно хотя бы посмотреть мнения специалистов по ссылкам в этом посте. Каждый род приёмки делает своё дело...

По представленному подходу. Да, это активно применяется. Есть даже книга "Автоматизация процессов тестирования" - там введение в практику для разных "мейнстрёмных" приложений (не поддерживающих полностью инженерную разработку - о разнице говорил, например, в конце этого поста). Как можно понять, генерация тестов встроена и в ряд сред реально гарантоспособной разработки (некоторые перечислены в этом посте) - во всяком случае, в ГРАФКОНТ и Г-Ф уж точно...

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

И по языкам. Кое-что уже уточнил здесь. Также в связи с Вашим упоминанием Калянова - саму книгу я читал. Его подход - тоже сделать "суперязык описания бизнес-процессов", дать его формальную грамматику и попытаться ввести критерии установления на полученной модели выполнения неких формальных свойств. Язык похож на то, что получилось в итоге этой темы. В свете этого:
Илья Ермаков в http://oberspace.dyndns.org/index.php/t ... ml#msg6521 писал(а):
Во! Поэтому умницы-математики поступают строго наоборот. Они говорят... мы ввели такое-то понятие и разработали для него алгебру, и теперь при рассмотрении любого реального явления, имеющие свойства нашего понятия, можно использовать данный алгебраический аппарат. Простенько и со вкусом! А физикам слабо... Они "сферических коней в вакууме" рассматривают... которые рушатся при соприкосновении с реальным миром... И хорошие программисты тяготеют к математикам, а плохонькие - к физикам... :) (IMHO... само собой)
Почитайте Арнольда или Успенского, например.
Не сработает... Арнольд тем и славен, что оппонирует "бурбаки", а, следовательно, пристрастен... не объективен. И если Вам ближе позиция Арнольда, то это никак не умаляет заслуг "бурбаки",
...
- методически вроде верно - вводим математический язык с учётом применимости. Но, как я понял, корректно ввести не удалось (как водится, конструктивным, "не-бурбакистским", путём - потому, что сам строил модель, охватывающую те же составляющие отчуждённого знания об оргсистемах). Видимо, ещё и потому, что "описание бизнес-процессов по своей сути антисистемно" ((С) Усов)... а как можно системно подойти - как раз обсуждаем, как уже говорил (также и в личку)...
В указанной теме, как можно видеть, обсуждал конкретный аспект у Калянова, который меня заинтересовал. Однако теперь выявляется, что и это системно м.б. определено иначе...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Понедельник, 27 Август, 2012 17:18 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Спасибо за очередную подборку "матчасти". Я, в общем-то, хотел сказать, что в рамках массового "бизнес-програмляния" формальная верификация - большая редкость. Причины сего Вы правильно подметили в этом посте, справедливы и доводы Ильи Ермакова, чей доклад был указан рядом там же. К тому же, специфика этой области такова, что не редко модель системы может быть получена лишь после этапа опытной эксплуатации, только реальная жизнь покажет все требования к проектам, и то, не сразу. В ряде специализированных случаев, скажем, при решении транспортных задач, можно (или даже нужно) воспользоваться проработанными матмоделями. Поэтому "выживает", прежде всего, тестирование, особенно со стороны материально-ответственных лиц на местах, у которых нет никакого доверия к "циферкам" от компьютера, хотя бы на этапе внедрения :) . Плюс, по возможности, стараешься проектировать систему, чтобы допускались "встречные проверки", т.е. принцип баланса - чтобы что-то где-то с чем-то "сходилось" (некая "проверка эквивалентности"). Отсюда и таково наличие соответствующих "ынтырпрайз"-инструментов для верификации и тестирования. Вести разработку на каком-нибудь языке как Promela лишь только для проверки идеи (без гарантий, что эта идея будет правильно отражена и в конечном проекте) допустимо только в специальных случаях, т.е. это не для "потока". В рамках дедуктивной верификации мне вспоминается только одна попытка реализовать механизм для потенциального "мэйнстрима" - механизм "type state" в языке Rust (и то, если считать, что, всё-таки, Rust найдёт своё широкое применение рядом с С++), но, вроде как, разработчики пока поставили временный "крест" на этой затее, ибо слишком много ограничений во время компиляции (сейчас, похоже, что и соответствующий раздел документации удалили, о "состоянии типов" можно в двух словах глянуть здесь). Поэтому все мечты Дейкстры, Хоара и др. реализованы лишь или в рамках учебных псевдо-языков, или "в промышленности" всё сведено к уровню "ассертов", в том или ином виде, т.е. к проверкам во время выполнения кода, а не к формальной верификации на этапе компиляции и проектирования. Крайне не хватает адекватной программной технологии, разработки есть, но, в основном, в разрезе образовательной или исследовательской деятельности (в основном, в контексте "функциональщины"), или в узкоспециализированной сфере, как системное ПО для встройки, прежде всего, в критически ответственных областях (соответствующие ссылки Вы как раз и указывали в рамках известных прогкомплексов). Если говорить о широком применении, то, боюсь, что необходимо решение на уровне проекта CompCert - компилятора с ограниченного языка "С", который выдаёт байт- или бинарный код (или ассемблер) для разных платформ, при этом есть некая гарантия, что конечный код будет семантически эквивалентный указанному универсальному исходнику на С, что "подтверждается" известным доказателем теорем - Coq. Т.е. необходим предметный язык (DSL, включая возможность использования и граф-языков), на основе которого система верифицирует и генерирует результат - на практике, прежде всего, потребуются "надёжные" исходники для целевых платформ - С, С++, Java, HTML, JavaScript, Delphi, SQL и т.д., а где-то и готовый исполняемый код и т.п. При этом, необходимо не забывать о том, что сейчас "мэйнстримовые" платформы растут как грибы после дождя, особенно, в "мобило-планшетной" гламурности, и программные технологии под них не успевают сменять друг друга. А также требуется учитывать потенциал для прикладной специфики, скажем, генерировать целевой код в расчёте "накатывания" изменений на рабочий комплекс, в том числе, когда таких комплексов множество, и каждый со своим составом прикладных модулей и конфигурационных особенностей (реально тяжёлая задача на практике).
Одним словом, вряд ли возможен некий "универсал", при этом, этот универсал будет вечным исследовательским проектом, с кое-какими практичными возможностями. Поэтому пока каждый вынужден ваять себе своё "счастье", в меру способностей, ресурсов и бюджета. Такова "нетеоретическая" реальность.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Понедельник, 27 Август, 2012 18:41 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ну, в общем, практическая реальность - всё-таки, видимо, признать производство программ именно производством... и делать нормальную сырьевую базу материалов/сортаментов, из которой и производить... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 08 Сентябрь, 2012 15:15 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 412
Откуда: Москва
в сообщении viewtopic.php?p=74155#p74155 PSV100 писал(а):
... в рамках массового "бизнес-программирования" формальная верификация - большая редкость.

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

или "в промышленности" всё сведено к уровню "ассертов", в том или ином виде, т.е. к проверкам во время выполнения кода, а не к формальной верификации на этапе компиляции и проектирования.

... Поэтому пока каждый вынужден ваять себе своё "счастье", в меру способностей, ресурсов и бюджета. Такова "нетеоретическая" реальность.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 08 Сентябрь, 2012 16:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Да... и особенно хорошо это видно в теории потоков работ (основной при "описании бизнес-процессов")... где хорошо доказываются свойства моделей как графов... но хуже при введении разметки...

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

Ну и как можем видеть здесь: https://www.box.com/s/84130eef00353ba8bd9d или здесь: http://www.sphere-u.ru/about.html - в целом реализованы.


Последний раз редактировалось Владислав Жаринов Воскресенье, 09 Сентябрь, 2012 19:19, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 08 Сентябрь, 2012 20:41 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Ильченко Эдуард писал(а):
Цель: получить понятное руководству, исполнителям и программистам описание деятельности (допрограммного уровня), как отдельных исполнителей, так и процессов в целом.
...
Для описания деятельности исполнителя попробую применить дракон-схему, имеющую специальную структуру и наполнить её содержанием из
Владислав Жаринов писал(а):
Вот изначальная формулировка задачи:
Вложение:
Вложение Текст Задача ПрД ПредвБюджПроекта — извл(РеферПроцесса).pdf больше недоступно
часть «Описание решения»

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

В полученной схеме отражено далеко не всё : ) Это просто иллюстрация. Но пообсуждать кое-что можно ...

Расщепить рабочую точку стандартным ДРАКОНом красиво не получилось...

Попробую зайти с другой стороны : )
Для этого потребовалось ввести некоторые дополнения и замещения в стандартный ДРАКОН. В качестве эксперимента.

Вводится икона «Расщепление» (три варианта).
Вводится икона «Слияние» (три варианта).
Отменяется использование структуры «Переключатель».
Вводится икона «Начало процесса», визуально выполненная как икона «Вариант».
Вводится икона «Параметр пуска», визуально выполненная как икона «Параллельный процесс».
Петля силуэта понимается как шина маршрутов (может одновременно содержать множество маршрутов).
Ветка не несёт нагрузки в виде выделения некоторой структуры, соответственно, иконы «Адрес» и «Имя ветки» - просто показывают переходы.
Одновременно могут выполняться процессы, расположенные в разных ветках.
Ветка может не иметь выхода через икону «Адрес» и тогда она может сливаться с маршрутами из другой ветки через икону «Слияние».

Конечно, в схеме отражено не всё, что требуется в задаче, но для иллюстрации, думаю, сойдёт.

В примитиве:
Вложение:
1p.png
1p.png [ 49.41 КБ | Просмотров: 5642 ]

Та же схема с некоторыми пояснениями.
Вложение:
1pp.png
1pp.png [ 100.47 КБ | Просмотров: 5642 ]

В силуэте:
Вложение:
1s.png
1s.png [ 45.04 КБ | Просмотров: 5642 ]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Воскресенье, 09 Сентябрь, 2012 09:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Отлично! Схема GAN-типа у Вас уже получилась (имея в виду, что в сетевых графиках циклы запрещены - для устранения их надо топосортировать).

Теперь, если есть желание, попробуйте сделать так. Составьте актив-схему ("диаграмму кооперации") рабочих мест, фигурирующих в задаче. И распишите техпроцесс как совокупность алгоритмов, исполняемых на каждом РМ. Имея в виду, что каждый сотрудник - полноправный владелец своих процессов. А с остальными связан только по передачам чего-либо - целевого (принимает предмет труда, отдаёт результат) и управленческого (принимает данные управления, отдаёт данные состояния). И сетевой график ТП решения задачи тут будет существенен (как доалгоритмическая схема) - только нужно учесть естественный для системирования порядок нагрузки (вершины - техоперации на РМ, дуги - передачи с возможным хранением). Возможно, что Вам будет удобнее разбить решение на ряд ТП - стыкуемых через концы на соседних по актив-схеме рабочих местах (передачами между техоперациями, назначенными соседним РМ).

Связи РМ при решении этой задачи полагаем жёсткими. Но, если есть желание, можно отразить, откуда они берутся. Например, вводим в актив-схему работника, ответственного за доведение любых описаний ТП до участников решения задачи - и связываем его с ними в контур управления по передаче тех самых описаний, которые Вы и составляете. :)
    Понятно, что в социотехнической системе мы выделяем РМ минимально для каждого сотрудника; возможно, минимум будет для бригады (расчёта) - т.е. группы сотрудников, совместно использующих совокупность орудий труда. Их деятельность (и области её приложения) мы либо не хотим, либо не можем выделить - потому и рассматриваем коллективное РМ.
    Такие элементарные РМ мы можем укрупнять при менее детальном рассмотрении ПМ, при этом логика подхода сохраняется.
Понятно, что здесь все РМ индивидуальные.

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

Важно, что все ТО - и целевые, и координационные - представляются как алгопроцессы. Но не без механизмов взаимодействия. Причём активация процессов не м.б. "разношёрстной" - как это бывает у "описателей". В данном случае мы рассматриваем систему-решатель задачи с позиций, при которых взаимодействие представлено передачами сущностей. Поэтому, спускаясь на уровень алгоритмически строгого представления, мы должны использовать передачу/приём сообщений (рандеву с каналами между РМ - эти каналы и моделируют передачи). Не забывая о парности рандеву-операторов (послать кому-то мало - надо, чтобы он принял)... :wink: И активация алгопроцессов для целевых ТО идёт, допустим, как сообщение "Пуск" от процесса-координатора, обнаружившего приход по установленному рандеву-каналу уместного объекта. И аналогично - делаем чего-то (обычно по логике ОС - снимаем или откладываем) с процессом, который не дошёл до конца, тоже сообщениями (как оно там программируется для машины или реализуется человеком - нас не интересует - это более низкий уровень). Подумайте, где будет уместно зацикливание алгопроцесса... Также нужно учесть, что рандеву-канал бывает с памятью - посмотрите, может ли это пригодиться...
    В общем случае мы описываем протокол работы связи - с хранением или без. Это и будет представлением взаимодействия РМ как единиц производственных мощностей, выделенных на данном уровне рассмотрения. При этом привлекаем уместные формализмы взаимодействия из рассматриваемых в теории систем процессов - рандеву, семафоры и пр.
В этом случае канал представляет частную связь единиц ПМ в терминах рандеву. Реально связь может слагаться из ряда каналов между одними и теми же ПМ.

И по форме записи. Полагаю, что мы здесь друг друга не ограничиваем, раз уж занимаемся для интереса... :) Так что не обязательно представлять алгопроцессы в графит-нотации (как у меня в этой и других задачах), а актив-схемы рисовать именно как графит-сети. Можно, скажем, записывать алгопроцессы текстом на Promela - тем более, что там есть операторы управления процессами (и некоторым из них ещё надо найти графит-форму). Да и русским псевдокодом (но несущим аналогичный смысл) можно для начала... если это удобнее для мышления...
Как мы видим, декларативная составляющая здесь мала. Нужно только иногда указывать как объекты действий/условий, кроме документов целиком, также их части. Для чего, думаю, достаточно "квалифицированной идентификации" их (типа, как полей записи) через точку после имени документа. Разную там модуляризацию/классообразование не представляем вообще - ещё вопрос, как парадигмы информатизации включать в системное представление. Примерно так...


Последний раз редактировалось Владислав Жаринов Понедельник, 10 Сентябрь, 2012 18:24, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Воскресенье, 09 Сентябрь, 2012 11:09 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Владислав Жаринов писал(а):
Теперь, если есть желание, попробуйте сделать так.

Желание есть, да со временем швах : )
Спасибо Вам за задачу!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Воскресенье, 09 Сентябрь, 2012 11:55 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Пожалуйста... ну и со временем тоже друг друга не ограничиваем... :) тем более, я высказываюсь из своего текущего понимания... которое, возможно, требует уточнения...

P.S. По предварительным данным эт ориго, понимание в основе правильное... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 00:32 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Ильченко Эдуард писал(а):
Отменяется использование структуры «Переключатель».
Дайте мне волю, я весь закон драконий к переключателям сведу! :)

Только теперь это будут не совсем переключатели, а блоки, выполняющие сопоставление маршрута с состоянием(параллелограм) и событием(трапеция). И теперь их можно "переворачивать", т.е. сопоставлять не только выходы(1:N), но и входы(N:1)! Конструкция, сопоставляющая одной иконкой (N:N) является запрещённой. "Лампасы" на иконках - для обозначения набора "всё,несколько,один". Элемент с "лампасами" выполняет сопоставление, элемент без лампасов - действие(установку состояния - параллелограм, инициализацию события - трапеция..). Как ни странно, это справедливо и для классической пары "Действие"-"Вставка". Ну и, разумеется, в алфавите присутствуют только шампур-иконы. Последнее - моя давняя математическая слабость :wink:

"Полка" получила сестру - "параллельную полку", выражающую подготовку чего-либо для другого контекста, например "документа". Просто "Полка" - это подготовка чего-либо для собственного контекста. "Параллельная полка" может по-умолчанию выставлять одноимённое событие. Это будет трапеция без "лампасов". Рисовать её явно сразу под "параллельной полкой" не нужно. "Ввод-вывод" не изменяется.

Итак, попробуем поиграться триплетом "контекст, состояние, событие":
Вложение:
boom.png
boom.png [ 157.46 КБ | Просмотров: 5473 ]
Примечание: схема рисовалась с опорой на 1p.png от Эдуарда Ильченко, без анализа исходной постановки задачи. Естественно, вылезли кое-какие хомуты. Надеюсь, несильно пригрузил :)


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

Нравится:
    выделились некоторые паттерны.
Не нравится:
    конец процесса визуально теряется(нет эпилога)
    нужен запрет образования (N:N) из (N:1)+(N:1)

Замеченные недостатки устраняются введением в алфавит соединителя.

Лицензия: как всегда - свободная: http://creativecommons.org/licenses/by-nc-sa/3.0/


p.s.: добавлено на картинку - синхронизация по "И" немного проще..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 22:29 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Вот здесь я тоже попробовал применить Переключатель для описания процессов (конечно, с более простым подходом). Но потом отказался от продолжения поисков в этом направлении. Основным соображением было то, что, имхо, нужно как можно дальше развести визуальный синтаксис процессов и алгоритмов (в традиционном для ДРАКОНа смысле) друг от друга, сохраняя в тоже время драконистость обоих синтаксисов. Собственно, иконы Расщепление и Слияние и есть модернизированный Выбор.

По-хорошему, икону Начало процесса тоже нужно визуально отделить от иконы Вариант.
Например, как-то так:
Вложение:
np.png
np.png [ 1.75 КБ | Просмотров: 5456 ]

По поводу множественности выходов из одного процесса.
Для пояснения своего взгляда привлеку нотацию eEPC.
Вложение:
pm.png
pm.png [ 177.11 КБ | Просмотров: 5456 ]

Рэйлвэй Каген писал(а):
Важно: видимо, процесс должен иметь один выход(цель).

Приведите, пожалуйста, вариант с одним выходом для процесса с РУКОВОДСТВОМ.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 04:41 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Рэйлвэй Каген писал(а):
Ильченко Эдуард писал(а):
Отменяется использование структуры «Переключатель».
Дайте мне волю, я весь закон драконий к переключателям сведу! :)
...
Ну конечно... Ваша мысль и здесь отражена... :)

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

Как я сейчас понимаю, автор цитаты в основе говорит дело, но отчасти оправдывает свою фамилию :) тем, что у него везде "бизнес-процессы" вместо "техпроцессы".
Разница - в том, что под первым обычно (в рамках БПР) понимают продукт опроса исполнителей, как они работают... :wink: Представляющий набор неких вариантов использования себя и других (причём возможны - и считаются уместными - некие т. зр. на одно и то же). Т.е. результат имитомоделирования (часто умозрительного) реальной работы оргструктуры, как она описана здесь: viewtopic.php?p=74506#p74506.
Техпроцесс же - это продукт проектирования деятельности для того самого "достижения конкретной цели" - требуемого (государством, рынком, собственниками) продукта. В расчёте на условного "эффективного исполнителя" - ПМ как заданную совокупность связанных РМ расчётной квалификации/оснащения - проектируемого совместно. По правде же учитывается разброс возможностей ПМ - потому ТП проектируется вариантным/привязываемым. И никаких интервью на местах... :wink: только возможность рационализации ТП и/или ПМ - как возврата к фазе проектирования...

Какие проблемы у "БП-описания"? Т.к. это некий симулят - то приходится "загонять" туда функции координации разных работ, назначенных на одно РМ (от экземпляров одного или разных типов ТП). Вот и "вылезают хомуты"... и будут вылезать. Возможность представить координацию (перефразируя Ермакова - "когда каждый мяч идёт правильным путём между своими Хоттабычами" :)) здесь тоже принципиально ограничена - только как артефакты реальных процессов координации. Так что если оформить это как нормы организации - придётся либо дать полный перебор для всех мыслимых значений/диапазонов факторов, влияющих на достижение цели... либо так и оставить определение неполным.
Тогда как потребный по данным условиям ход работ естественно образуется в функционировании связанных РМ по координируемым активным экземплярам ТП... И м.б. воспроизведён любым, кто представляет себе это функционирование (в частности, самым обычным диспетчером :))...

Прошу критиковать... конструктивно...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 21:31 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Рэйлвэй Каген писал(а):
Конструкция, сопоставляющая одной иконкой (N:N) является запрещённой.
Вложение:
s.png
s.png [ 50.04 КБ | Просмотров: 5409 ]

Соединитель представляется каким-то лишним. Какая разница между (N:1 + 1:N) и (N:1 + 1:1 + 1:N) ?
Структуры и так отделены разными иконами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 21:57 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Ильченко Эдуард писал(а):
Собственно, иконы Расщепление и Слияние и есть модернизированный Выбор.
Ну да, только я только малость абсолютизировал такую точку зрения, потому выбрал "косые бока".
Ильченко Эдуард писал(а):
По-хорошему, икону Начало процесса тоже нужно визуально отделить от иконы Вариант.
Начало процесса следует за реальными узлами сети - трапециями и параллелограммами. Попав в узел, нужно
Ильченко Эдуард писал(а):
Приведите, пожалуйста, вариант с одним выходом для процесса с РУКОВОДСТВОМ.
Эдуард, Вы же знаете рецепт :wink: "Именно РУКОВОДСТВО генерирует дальнейшие события своими решениями". Поэтому поступим также, как и с ФИНОТДЕЛом:
Вложение:
руководство.png
руководство.png [ 12.77 КБ | Просмотров: 5406 ]


Последний раз редактировалось Рэйлвэй Каген Среда, 12 Сентябрь, 2012 22:18, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 22:18 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Ильченко Эдуард писал(а):
Какая разница между (N:1 + 1:N) и (N:1 + 1:1 + 1:N) ?
на приведённой Вами вырезке (N:1)+(N:1). Без соединителя в синем кружке может показаться, что там (N:N)+(1:1), а это туфта. Мы-то знаем, что (N:N)-низзя, но глаз так и норовить что-нибудь запретное узрить :) Визуально, конечно, не лучшее решение в этом месте.
Разницу между (N:1 + 1:N) и (N:1 + 1:1 + 1:N)? На (1:1) можно нагрузить лампасы "в шашечку", тогда разница и появится. Внутри такой (1:1) можно расписать, например, анализ проходящего процесса, его подмену другим и т.д..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 23:12 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Рэйлвэй Каген писал(а):
Не нравится:
    конец процесса визуально теряется(нет эпилога)

Ваши соединители хорошо показывают выходы из процесса.
Особенно, если их пронумеровать.
Вложение:
s2.png
s2.png [ 109.29 КБ | Просмотров: 5396 ]

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 23:18 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Рэйлвэй Каген писал(а):
Эдуард, Вы же знаете рецепт :wink: "Именно РУКОВОДСТВО генерирует дальнейшие события своими решениями". Поэтому поступим также, как и с [url=http://forum.oberoncore.ru/download/file.php?id=3452&mode=view]ФИНОТДЕЛом
Всё бы хорошо, но в случае отказа должна быть повторная обработка заявки с нуля, согласно ТЗ (наверно, будут уговаривать клиента другими способами : ). И выйти из этого цикла можно только утвердив заказ : )

В показанном Вами случае придётся слитые воедино решения РУКОВОДСТВА : ) отказать и утвердить опять расщеплять и одно отправлять на Конец, а другое менеджеру.

А вот ниже другой случай. Как здесь показать один выход?
Вложение:
s3.png
s3.png [ 27.87 КБ | Просмотров: 5396 ]


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB