OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 13 Декабрь, 2019 02:53

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




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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Ильченко Эдуард писал(а):
Одновременное нахождение, указанных Вами процессов в одном силуэте, обусловлено их принадлежностью к одной системе (актору).
В общем случае это неверно. И методически неверно. Да и алгоритмически неверно.
Рассмотрите, к примеру, какую-нибудь МНОГОПОТОЧНУЮ систему. С одной стороны, задача вроде бы одна, с другой - акторов несколько (если считать актором процесс в понимании ОС).
С третьей стороны, система может и нового актора создать для обработки события.
Так что имеем разнообразие технических деталей реализации.

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

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


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

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

Но Ваш вариант мне пока не понятен. Точнее, понятен, но как-то неубедителен для меня.

Мне мой вариант понятен, но тоже до конца не убедителен : ) Требуется обкатка на реальных задачах.

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

1. Цикл Ждать визуально не очень хорошо различим на схеме, а ведь он отдаёт управление внешнему диспетчеру и принимает обратно. Это важное обстоятельство, но догадаться о нём не просто даже изучив специальное пояснение. В схеме имеется дыра, а мы её даже не видим.

v.d.parondzhanov-kak_uluchshit_rabotu_uma.doc писал(а):
Цикл Ждать
Предположим, требуется в течение трех минут ждать появления хотя бы одного из двух признаков ЛЕВЫЙ ДВИГАТЕЛЬ В НОРМЕ и ПРАВЫЙ ДВИГАТЕЛЬ В НОРМЕ. При наступлении этого события (появлении признака) необходимо включить плазменный реактор. Если же названные признаки отсутствуют, по истечении трех минут следует включить фотонный двигатель.
Для решения задачи на рис. 84 используются два оператора: пуск таймера Т, отсчитывающего три минуты, и цикл ЖДАТЬ. В состав последнего входит икона “период” и три иконы “вопрос”, в которых размещены надписи ЛЕВЫЙ ДВИГАТЕЛЬ В НОРМЕ?, ПРАВЫЙ ДВИГАТЕЛЬ В НОРМЕ? и Т > 3мин (последний оператор проверяет: значение таймера Т больше трех минут?). Если оба признака отсутствуют, а значение таймера не превышает трех минут, опрос условий периодически повторяется, причем период опроса указывается в иконе “период”. В данном примере он равен 4 секундам.

2. Цикл Ждать привязан к временным промежуткам, что потенциально опасно. Что делать если события будут появляться и пропадать между опросами? Нужно встраивать какой-то дополнительный механизм фиксации событий.

3. Ну и петля цикла загромождает схему : ) Дополнительная вертикальная линия, пространство слева справа. А места и так мало.

Владимир Паронджанов писал(а):
Просьба вторая. Откройте новую тему по данному вопросу (название темы по Вашему усмотрению) поближе к ДРАКОНу, например, здесь
viewforum.php?f=62


Поскольку о цикле Ждать мало что смог сказать, пока отвечаю здесь. По крайней мере хоть какой-то контекст присутствует.


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

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

Совершенно верно. ПД-схема одна, а техническая реализация разная.

Главная цель создания схемы актор - понимание.
Человек, не знакомый с программированием, но знакомый с предметной областью, понимает как работает актор, а человек, не знакомый с предметной областью, но знакомый с программированием, понимает как работает актор : )

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

Конечно, кроме Деятельностей, актору присущи и другие свойства, описание которых впереди ...
И ждут своего исследования конгломераты акторов : )


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

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

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

ПРЕРЫВАНИЕ

Сохранить контекст менеджера.
Щелкнуть его по лбу.
Восстановить контекст менеджера.

СУПЕРВИЗОР

Проанализировать мысли менеджера, наблюдающего синяк на лбу.

: )


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Ильченко Эдуард писал(а):
Главная цель создания схемы актор - понимание.
Позвольте возразить именно в отношении понимания.
Актор - это не главное в данном случае.
Главное - это РОЛЬ.
А роль - это функциональность, которая может быть исполнена разными акторами (в т.ч. с одинаковым успехом).
Если речь идёт о менеджере, то его функции может выполнить (равноправный) коллега.
Если речь идёт о процессах в ОС, то текущий процесс может быть выполнен на любом ядре (по усмотрению супервизора).

Всё это говорит о том, что роль (она же функциональность) почти всегда первична.
Исключения достаточно редки (скажем, страницы мемуаров "один день менеджера Иванова").

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


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

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Alexey_Donskoy писал(а):
Ильченко Эдуард писал(а):
Главная цель создания схемы актор - понимание.
Позвольте возразить именно в отношении понимания.
Актор - это не главное в данном случае.
Главное - это РОЛЬ.
А роль - это функциональность, которая может быть исполнена разными акторами (в т.ч. с одинаковым успехом).
Если речь идёт о менеджере, то его функции может выполнить (равноправный) коллега.
Если речь идёт о процессах в ОС, то текущий процесс может быть выполнен на любом ядре (по усмотрению супервизора).

Я уже говорил, что понимаю под «актором»: «Это общий шаблон описания деятельности актора. Шаблон наполняется под конкретного исполнителя. Актором может быть человек, должность, группа людей, предприятие, механизм, процессор компьютера, исполняемая программа и т. п.»

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

Каким-то образом нужно совместить описание всего этого безобразия, чтобы и люди были сыты и программа работала. Нужен План. Я предложил только начало такого плана. Возможно он плох. Сейчас есть текстовое описание деятельности должности «менеджер» и ПД-схема «Менеджер проекта» (надеюсь я её доделаю : ) Уже можно что-то сравнивать. Хорошо бы увидеть третий вариант. Возможно есть способ представить всё проще и быстрее.

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

Alexey_Donskoy писал(а):
А это значит, что вынесение внутренностей какого-либо из процессов (как веточный цикл в Вашем примере) на общий силуэт недопустимо.

Оно допустимо уже в силу того, что я это допустил как автор структуры «шаблон актора». При этом я могу ошибаться. Но не в том, что это недопустимо, а в том что делает ли это понятнее деятельность акторов или нет. Можно обсуждать для чего это сделано и на сколько удалось. Сделано это для акцентирования внимания на событиях, которые меняют маршруты деятельностей. На сколько удалось … Для этого нужно сравнить с другими вариантами. На текущий момент есть текст и цикл Ждать. Можете ли Вы что нибудь предложить? Просто переключатель в рабочем цикле не выразителен и теряется на фоне других маршрутов.


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

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


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

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

Ильченко Эдуард писал(а):
...
Имхо, людям, не обременённым специфическими знаниями, понятнее «Схема деятельности менеджера», чем «Процессы исполняемые ролью» (или как это сказать-то нужно?),...
Так можно и сказать - "Схема деятельности для роли менеджера" (длиннее и точнее - "... исполнителя в роли такой-то").

Ильченко Эдуард писал(а):
...
Но не в том, что это недопустимо, а в том что делает ли это понятнее деятельность акторов или нет. Можно обсуждать для чего это сделано и на сколько удалось. Сделано это для акцентирования внимания на событиях, которые меняют маршруты деятельностей. На сколько удалось … Для этого нужно сравнить с другими вариантами. На текущий момент есть текст и цикл Ждать. Можете ли Вы что нибудь предложить? Просто переключатель в рабочем цикле не выразителен и теряется на фоне других маршрутов.
Ну, о допустимости следует говорить в отношении - представляется ли тем или иным синтаксисом (напр., графическим) реальная математическая модель предметки? Не знаю, что имел в виду Алексей...
Если начинать до математики - то я честно пытался понять, "как это должно работать" по Вашей схеме. И как-то не связывалось... Похоже, он объяснил, почему... :) Это отчасти связано и с этим:
Ильченко Эдуард в viewtopic.php?p=73852#p73852 писал(а):
...
Владислав Жаринов писал(а):
1. Предполагается, что в Вашем синтаксисе модели можно отделить вещи, связанные с множественностью "рабочих точек" (сеть работ) от вещей, требующих их единственности (алгоритмы работ)? В таком кратком эскизе это не ясно...

Назовите, пожалуйста, конкретные вещи в первом и втором случае и я попробую ответить на Ваш вопрос. Боюсь, что не совсем понимаю что названо «рабочей точкой».
Это по-простому "фокус внимания" экземпляра исполнителя на модели деятельности (для человека можно просто считать, что он читает описание техпроцесса с документа или мысленного образа). В алгопроцессе допустима единственная РТ - развёртывающая конкретный вариант использования на маршрутной схеме.

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

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

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

Пока так...


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Эдуард, я буду комментировать тут, поскольку Владислав сформулировал точнее :)

Владислав Жаринов писал(а):
В принципе должность - это роль, да. Правда, ДИ регламентирует не только импер-часть (суть деятельности), но и всё остальное (предметы/результаты, средства деятельности, взаимоотношения и связи).
Именно всё как в жизни. Есть роль (куча метаинформации от формы одежды до выражения лица), и есть её алгоритмическая часть, в народе называемая сценарием :)

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

Что мы видим на маршрутной схеме?
Мы видим там сценарий (алгоритмические составляющие ролей).
Всё остальное - зависит от задачи, которую мы хотим решить при помощи данного представления. И, соответственно, от рассматриваемой нами системы.

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

Кстати, по определению такая общая схема допускает много экземпляров исполнителей (акторов, рабочих точек) и их маршрутов.

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

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

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

Владислав Жаринов писал(а):
Ну, о допустимости следует говорить в отношении - представляется ли тем или иным синтаксисом (напр., графическим) реальная математическая модель предметки? Не знаю, что имел в виду Алексей...
Ну вот и объяснил вроде подробно, хотя и совсе не формально.
Как видите, синтаксис допускает много чего, и во всех случаях он практически одинаковый.
А вот смысл представленного - зависит от задачи.
В соответствии с задачей формализуем отношения субъектов - получаем модель системы с разных точек зрения.

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

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


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

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

И тут важна также та самая принятая математика схем со множественностью РТ... А уж дальше вопрос - как её "расшифрровывать" алгоритмически строго - через циклы ЖДАТЬ?.. обмен сообщениями (рандеву - опять же асинхронное или синхронное)?.. ещё как-то?..


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
А что является главным? На мой взгляд - суть тех самых функций кординации...
Главным, имхо, является выбор адекватной точки зрения на систему. Метры с килограммами на одной диаграмме показать можно (например, как оси системы координат :wink: ), но только когда это оправданно и важно для задачи.

Владислав Жаринов писал(а):
А уж дальше вопрос - как её "расшифрровывать" алгоритмически строго - через циклы ЖДАТЬ?.. обмен сообщениями (рандеву - опять же асинхронное или синхронное)?.. ещё как-то?..
Да, обработка событий может быть синхронной (например, прерывание) и асинхронной (например, очередь сообщений). Цикл ЖДАТЬ не годится для синхронной. Только для асинхронной.
В большинстве программных систем, как и в жизни, реакция на событие регулируется системой приоритетов. В том числе и для синхронной обработки. Вышеупомянутого менеджера можно прервать телефонным звонком, и способ обработки звонка (синхронный или асинхронный) будет зависеть от приоритета звонящего :) Алгоритмически всё это показать вообще, имхо, нереально. Ибо эта метаинформация о программной системе не является алгоритмической.

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


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Да, и на других форумах видят эту проблему: viewtopic.php?p=73812#p73812.


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

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Alexey_Donskoy писал(а):
Ильченко Эдуард писал(а):
Главная цель создания схемы актор - понимание.
Позвольте возразить именно в отношении понимания.
Актор - это не главное в данном случае.
Главное - это РОЛЬ.
А роль - это функциональность, которая может быть исполнена разными акторами (в т.ч. с одинаковым успехом).

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

Я с вами соглашусь. К тому же понятие РОЛЬ уже устоялось. В определённых кругах : )

Но.
Есть роль «Менеджер».
Есть менеджер Иван Иваныч.

«Обратитесь к менеджеру Иван Иванычу». Но не «Обратитесь к Иван Иванычу в роли менеджера». Не по-человечески как-то.

Владислав Жаринов писал(а):
(всё д.б. как в жизни :wink:).

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

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


Итак, имеем шаблон схемы деятельности некоторого исполнителя в некоторой РОЛИ. (Или схема деятельности РОЛИ? Или просто схема РОЛИ? Или схема деятельности актора (как абстрактной единицы)?).

(Кстати, если описывать с помощью этого шаблона программу сбора данных, мы же не будем говорить «Схема деятельности микропроцессора в роли программы сбора данных»)

Шаблон отображён в виде похожей на дракон схемы (ПД-схемы).
Вложение:
shablon_1.png
shablon_1.png [ 20.35 КБ | Просмотров: 6419 ]

Правильная дракон-схема этого же шаблона выглядит примерно так:
Вложение:
shablon_2.png
shablon_2.png [ 14.38 КБ | Просмотров: 6419 ]

или так
Вложение:
shablon_3.png
shablon_3.png [ 19.79 КБ | Просмотров: 6419 ]

Свёртываем в одну икону Выбор иконы Вставка и Выбор.
Указываем на неявный выход из иконы Выбор «Выбор деятельности» на петлю силуэта и вход с петли силуэта обратно в ту же икону.
Вложение:
shablon_4.png
shablon_4.png [ 37.46 КБ | Просмотров: 6419 ]

Таким образом, имеем сокращённую запись правильной дракон-схемы.

Получаем меньшее количество икон и веток и более эргономичное (имхо) расположение схемы на пространстве листа. А также чётко выделенные места для деятельности и событий.


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ильченко Эдуард писал(а):
...
«Обратитесь к менеджеру Иван Иванычу». Но не «Обратитесь к Иван Иванычу в роли менеджера». Не по-человечески как-то.
Потому, что естественный язык предполагает возможность упрощённых формулировок - когда стороны опираются на здравый смысл...
Для данной ситуации в контексте нашего обсуждения это легко выявить, рассмотрев возможное продолжение диалога. Подразумеваемый адресат может, в частности, ответить: "- Пожалуй, я лучше обращусь к Петру Петровичу"... если понимает, что Иван Иваныч сработает недостаточно хорошо... хотя оба назначены (как предполагается) на одинаковые работы.. Вот так и выявляется, что за Вашей первой формулировкой на самом деле стоит вторая... :) Это и к сказанному о сущности корректного назначения на работы здесь: viewtopic.php?p=73877#p73877. Что связано и с этим:
Ильченко Эдуард писал(а):
...
Владислав Жаринов писал(а):
(всё д.б. как в жизни :wink:).

Никто не подумает, что «схема деятельности менеджера» описывает конкретного Иван Иваныча, а не должность, которую он занимает. Ну, разве что в определённых кругах : )
А Алексей как раз хотел сказать другое здесь:
Alexey_Donskoy в viewtopic.php?p=73875#p73875 писал(а):
...
Можно спросить, как всё сказанное соотносится с тем, что пишет Усов о предприятии как системе.
На это можно ответить, что по содержанию система остаётся описанной в едином формализме, как и предлагает Усов. Все возможные проблемы кроются в степени детализации.
Так, даже подробные управленческие модели обычно останавливаются на уровне должности. При этом система (модель то есть) получается красивой, идеально соответствующей замыслу архитектора - но, увы, бюрократической и плохо работающей. Оказывается, что должность должностью, но хороший хозяин будет смотреть глубже - на уровень не абстрактной должности, а конкретного "экземпляра исполнителя" дяди Васи.
Но все рассмотренные формализмы (ресурсы, возможности, потребности и т.п.) будут теми же и на этом уровне.
Алгоритмическая часть ролей (сценарии), как это ни странно, будут иметь далеко не главную роль, чтобы так сильно ими заморачиваться... Имхо, конечно :)
Именно - что в модели "по жизни" учитываются характеристики замещающего должность.
В отношении роли алгочасти в целостном описании - по теории систем процессов это легко объясняется:
Жаринов В.Н. в http://drakon.su/vershiny_i_linii_sxem_ ... ego_azbuka писал(а):
В условном времени мы можем построить модель исполнения алгоритма — т.н. циклограмму. На ней все действия упорядочены по оси времени. Из циклограммы ясно, когда чем исполнитель загружен по данному алгопроцессу. А в окружении все действия исполнителя считаются вызывающими тоже известные по содержанию и времени процессы.

В реальном времени действует совершенно иной принцип — сочинитель не должен определять порядок действий во времени. Течение процесса определяется только отслеживаемыми исполнителем данными — т.е. величинами данного процесса и, возможно, какими-то дополнительными данными состояния исполнителя и его окружения. Что происходит в окружении (и в самом исполнителе кроме работы с величинами данного алгоритма) — определяется только по значениям величин состояния. Главный теоретический принцип здесь — шаги сочиняемого алгопроцесса и любых других могут перемежаться в любом порядке. И если мы уж хотим анализировать исполнение в реальном времени — то надо все эти порядки и рассматривать. И определять, какие из них ведут к нужным результатам, а какие нет. А дальше думать, можно ли исключить каждый такой порядок и как? И если нельзя, то как его обнаружить при исполнении и какие реакции заложить, чтобы результаты были всё-таки наиболее благоприятными (или хотя бы наименее неблагоприятными)?..

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

Ильченко Эдуард писал(а):
...
Итак, имеем шаблон схемы деятельности некоторого исполнителя в некоторой РОЛИ. (Или схема деятельности РОЛИ? Или просто схема РОЛИ? Или схема деятельности актора (как абстрактной единицы)?).

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

Ильченко Эдуард писал(а):
...
Указываем на неявный выход из иконы Выбор «Выбор деятельности» на петлю силуэта и вход с петли силуэта обратно в ту же икону.
Вложение:
shablon_4.png

Таким образом, имеем сокращённую запись правильной дракон-схемы.

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

Вот и подумайте - как описать, чтобы облегчить размышление над этими задачами и их частичную формализацию?..


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Ильченко Эдуард писал(а):
имеем шаблон схемы деятельности некоторого исполнителя в некоторой РОЛИ
Извините, Эдуард, но Вашу схему я понять не могу. Она взята с потолка, высосана из пальца и не имеет ничего общего с реальной жизнью.

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

1. Жёсткий реалтайм. Так обычно строятся промышленные контроллеры. Есть один фоновый процесс, который занимается обслуживанием, самодиагностикой, обработкой некритичных событий (запросов). И есть один или несколько оперативных процессов, которые должны быть выполнены с высоким приоритетом и запускаются по прерыванию от таймеров или внешних событий (мелочь вроде обработки прерываний от периферии оставим на уровне драйверов и рассматривать на общей схеме не будем). Схема, правда, получилась конкретная и подробная, но тем даже лучше :)
Вложение:
Промышленный контроллер.png
Промышленный контроллер.png [ 18.95 КБ | Просмотров: 6382 ]

Вложение:
Промышленный контроллер.drt [2.43 КБ]
Скачиваний: 369


2. Кооперативная многозадачность (чем обычно заняты всякие менеджеры :) ). В принципе без особых комментариев.
Вложение:
Кооперативная многозадачность_1.png
Кооперативная многозадачность_1.png [ 10.95 КБ | Просмотров: 6382 ]

Вложение:


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


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

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

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


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
Вопрос по 1: пуск таймера есть, а где синхронизация по таймеру?
Таймер периодически генерирует прерывание, обработчиком прерывания является "Рабочий цикл". Как это изобразить в Драконе, не знаю, просто "икон" недостаточно.

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

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


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

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


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
Ну да... представляемых разными структурами доалгоритмических схем?..
Что есть "доалгоритмическая схема" и для чего она нужна?

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


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

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


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

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


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

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


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

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