OberonCore
https://forum.oberoncore.ru/

Задача на перспективу
https://forum.oberoncore.ru/viewtopic.php?f=86&t=3633		 Страница 1 из 7
Автор:  Владислав Жаринов [ Четверг, 27 Октябрь, 2011 08:02 ]
Заголовок сообщения:  Задача на перспективу
В теме предлагается конкретный пример эскизного описания решения реальной задачи. На котором каждый желающий может продемонстрировать свои законченные подходы к дальнейшей формализации. И/или предложить какие-то частные идеи.
Предполагается, что желающие будут как-то учитывать математику (ну и логику - взаимосвязанную, допустим, так, как это видит О.Е. Акимов) применительно к данному предмету. Оценивая свою математическую культуру как скромную, автор тем не менее понимает роль математики в процессе формализации. :) Поэтому всевозможные заявления типа "опять теоретики и преподаватели посылают читать" здесь в игноре. А вот когнитивный показ логико-математических аспектов своих идей приветствуется. Если конечно, идеи доходят до этой стадии процесса - что необязательно, они м.б. и качественного порядка.

Конечно, если конструктивное обсуждение завяжется - то в его ходе представление о процессе почти наверняка изменится.
Автор:  Владислав Жаринов [ Четверг, 27 Октябрь, 2011 08:13 ]
Заголовок сообщения:  Задача на перспективу: Что дано
Вот изначальная формулировка задачи:
Вложение:
Текст Задача ПрД ПредвБюджПроекта - извл(РеферПроцесса).pdf [249.37 КБ]
Скачиваний: 864
Несколько слов по содержанию:
    * Из спецификации извлечено только относящееся к импер-части представления о решении. Понятно, что у предметов труда (в данном случае - документов) есть формы, которые объявлены в деклар-части. Но для целей данной темы просто "тупо" пользуемся имеющимися в тексте именами реквизитов (величин). Не задумываясь об их "абстрактных типах" и о положении в структуре форм.
    * Суть расчётных операций считается несущественной. Поэтому описание дано укрупнённым.
    * Для эскиза это описание, возможно, покажется слишком проработанным. В самом деле, на практике начальное описание часто бывает более эскизным. ;)
Автор:  Владислав Жаринов [ Четверг, 27 Октябрь, 2011 08:20 ]
Заголовок сообщения:  Задача на перспективу: Что надо (упрощённый вариант)
Предлагается визуализировать процесс как схему с "расщеплением рабочих точек" в предположении, что каждый исполнитель в единственном экземпляре и занят только данной задачей (но учитывая возможность переключения на другую работу в периоды ожидания). Желательно также учесть возможность исключительных ситуаций и описать реакцию на них (не обязательно как "особых случаев" в обычном для "мейнстримного" программирования смысле).
Автор:  Владислав Жаринов [ Четверг, 27 Октябрь, 2011 08:29 ]
Заголовок сообщения:  Задача на перспективу: Что надо (реалистичный вариант)
Предлагается визуализировать процесс как систему взаимодействующих процессов у исполнителей в предположении, что каждый исполнитель существует в ряде экземпляров и м.б. занят не единственным экземпляром проекта. Кроме того, экземпляр исполнителя м.б. занят другими задачами, относительно более и/или менее важными (учитывая возможность переключения на другую работу не только в периоды ожидания, но и экстренно в зависимости от приоритетов работ). Число экземпляров как исполнителей каждого рода, так и проекта м.б. переменным. Моменты ввода экземпляров, а также других задач м.б. произвольными.
Автор:  Владислав Жаринов [ Четверг, 27 Октябрь, 2011 08:45 ]
Заголовок сообщения:  Задача на перспективу: О решении
Очевидно, стоит учесть опыт обсуждения в этой теме. Но дискутировать по обоснованию свойств предлагаемых языков предлагается в этой теме. Как и по представлениям о "деятельности вообще" - которые должны лежать в основе этих языков. Предполагается, что решение в целом представляется семейством языков, но состав и структура этого семейства не регламентируется - каждый выбирает по-своему. Понятно, что описания на разных языках д.б. связными. ;)

По поводу обработки особых ситуаций исполнения, очевидно, есть смысл учесть обсуждения в этой теме... а также в этой.
Тем, кто хочет дойти до "программно-строгого" языка, исповедуя "чисто объектный" взгляд на деятельность - настоятельно рекомендуется поверять свои представления результатами как Мейера, так и Бабичева.
Автор:  Ильченко Эдуард [ Понедельник, 09 Январь, 2012 16:58 ]
Заголовок сообщения:  Re: Задача на перспективу: Что дано
Владислав Жаринов писал(а):
Предлагается визуализировать процесс

Владислав Жаринов писал(а):
Вот изначальная формулировка задачи:
Вложение:
Текст Задача ПрД ПредвБюджПроекта - извл(РеферПроцесса).pdf


Для кого должен быть предназначен визуализированный процесс?
Для руководства (чтобы хотя бы представлять, что происходит на местах : ),
для исполнителя (чтобы просто выполнять свою работу),
для программиста (который будет писать программные модули),
для всех сразу (серебряная пуля : ) ?
Или другие варианты (комбинация вариантов) ...
Автор:  Владислав Жаринов [ Вторник, 10 Январь, 2012 12:23 ]
Заголовок сообщения:  Re: Задача на перспективу: Что дано
Ильченко Эдуард писал(а):
...
для всех сразу (серебряная пуля : ) ?
Или другие варианты (комбинация вариантов) ...
Хорошо... особенно в свете напоминания alexus о точках зрения: viewtopic.php?p=69232#p69232 ... :)
Я имел в виду - либо т. зр. выбирается по своему вкусу (мы же здесь для интереса участвуем :)) - либо решается "задача вызова" - а как будет выглядеть "прообраз", из которого нужную "проекцию" можно получить?..
Автор:  Ильченко Эдуард [ Вторник, 10 Январь, 2012 12:47 ]
Заголовок сообщения:  Re: Задача на перспективу: Что дано
Владислав Жаринов писал(а):
Ильченко Эдуард писал(а):
...либо т. зр. выбирается по своему вкусу ...

ок : )
Автор:  alexus [ Вторник, 10 Январь, 2012 16:29 ]
Заголовок сообщения:  Re: Задача на перспективу: Что дано
Ильченко Эдуард писал(а):
Владислав Жаринов писал(а):
Предлагается визуализировать процесс

Владислав Жаринов писал(а):
Вот изначальная формулировка задачи:
Вложение:
Текст Задача ПрД ПредвБюджПроекта - извл(РеферПроцесса).pdf

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

Хм?.. Не совсем красиво отвечать вопросами на... вопросы, но всё же... для понятности... если позволите... Скажите, а для кого пишется/рисуется/отображается технологический процесс на любом производстве?.. Варианты ответов-вопросов:
    1. Для руководства (чтобы хотя бы представлять, что происходит на местах : )?,
    2. Для исполнителя (чтобы просто выполнять свою работу)?,
    3. Для разработчика?
    4. Для всех сразу (серебряная пуля : ) ?
    5. Или другие варианты (комбинация вариантов)?
Попробую, с Вашего позволения, допустить правильность всех ответов-вопросов. Действительно, если нет описания тех. процесса у руководства, то как им спланировать и проконтролировать выпуск продукции (банально нет понимания того, что за чем делается, сколько времени и ресурсов (каких?) потребует любая операция).
Для исполнителя в тех. процессе указываются необходимые параметры обработки: температура, классы точности, инструменты, скорости (резания) и пр., и пр. То есть, исполнителю тоже нужен тех. процесс.
Разработчик тех. процесса - технолог помимо, собственно, разработки и привязки тех. процесса к реалиям конкретного производства, должен контролировать точность/правильность выполнения тех. регламентов (технологических требований) на местах, то есть, исполнителями. Для этого цеховому технологу тоже необходимо описание тех. процесса.
Другими словами, тех. процесс нужен всем основным работникам, занятым в процессе производства (вспомогательному персоналу: ремонтникам, смазчикам, настройщикам, уборщицам и пр., технология не слишком интересна) .
Ну, и как Вы правильно ставите вопрос, тех. процесс нужен и "другим вариантам"... например, надзорным органам, владельцам патентов на изделие/технологию, поставщикам исходных материалов (комплектующие и сырьё), потребителям, наконец... Возможно, и этот список не полон... (но сейчас речь не о полноте, а о... принципе, как я понимаю).
Пример с технологическим процессом хорош тем, что он основан на едином представлении предметной области (производства) самых разных категорий/групп специалистов, хотя при этом он остаётся только частью многих других описаний/представлений.
Автор:  Владислав Жаринов [ Вторник, 10 Январь, 2012 20:23 ]
Заголовок сообщения:  Re: Задача на перспективу
Ну, в общем, я где-то это и имел в виду... что лучше бы инвариантную семантику прообраза... а её уже рассматривать "с точки зрения"...

Наверное, "правила построения прообраза" всё-таки хорошо уяснять на конкретной задаче... раз эта годится - пусть будет она...
Автор:  alexus [ Среда, 11 Январь, 2012 08:53 ]
Заголовок сообщения:  Re: Задача на перспективу
Владислав Жаринов писал(а):
Ну, в общем, я где-то это и имел в виду... что лучше бы инвариантную семантику прообраза... а её уже рассматривать "с точки зрения"...

Наверное, "правила построения прообраза" всё-таки хорошо уяснять на конкретной задаче... раз эта годится - пусть будет она...

Владислав, тема здесь не вызывает интереса. Если хотите, то можно по ней общаться лично.
Автор:  Valery Solovey [ Среда, 11 Январь, 2012 18:26 ]
Заголовок сообщения:  Re: Задача на перспективу
У меня вызывает интерес, поэтому включите меня в дискуссию, если не сложно.
Автор:  Ильченко Эдуард [ Воскресенье, 12 Август, 2012 13:09 ]
Заголовок сообщения:  Re: Задача на перспективу
Сдерживало отсутствие адекватного инструмента (как я его понимаю). В свете новых приобретённых мною знаний : ) попробую использовать практически стандартный ДРАКОН (там где это возможно).

Цель: получить понятное руководству, исполнителям и программистам описание деятельности (допрограммного уровня), как отдельных исполнителей, так и процессов в целом.

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

Тем не менее следующий шаг делаю...

Для описания деятельности исполнителя попробую применить дракон-схему, имеющую специальную структуру и наполнить её содержанием из
Владислав Жаринов писал(а):
Вот изначальная формулировка задачи:
Вложение:
Вложение Текст Задача ПрД ПредвБюджПроекта — извл(РеферПроцесса).pdf больше недоступно
часть «Описание решения»

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

Вложение:
actor_1.png
actor_1.png [ 61.47 КБ | Просмотров: 17845 ]

Вложение:
actor_2.png
actor_2.png [ 44.09 КБ | Просмотров: 17845 ]


В полученной схеме отражено далеко не всё : ) Это просто иллюстрация. Но пообсуждать кое-что можно ...
Автор:  Владимир Паронджанов [ Воскресенье, 12 Август, 2012 16:48 ]
Заголовок сообщения:  Re: Задача на перспективу
Ильченко Эдуард писал(а):
Сдерживало отсутствие адекватного инструмента (как я его понимаю). В свете новых приобретённых мною знаний : ) попробую использовать практически стандартный ДРАКОН (там где это возможно).


Уважаемый Эдуард!

Черная ветка "События" является незаконным входом.

Ее можно свести к стандартным приемам. Для этого описывайте Ваши события с помощью цикла ЖДАТЬ.

См. рис. 84 в книге "Как улучшить работу ума". В первой ветке есть цикл ЖДАТЬ.

Левый двигатель в норме" — это событие. Дракон-схема ждет, когда наступит это событие.

Замените событие "Левый двигатель в норме" на название Вашего события.

Замените событие "Правый двигатель в норме" на название другого Вашего события.

Событий может быть сколько угодно. Их можно ожидать с помощью одного или нескольких циклов ЖДАТЬ.

И все будет в порядке.

Цикл ЖДАТЬ предназначен для управления событиями, которые могут появляться в неопределенные промежутки времени. Или не появляться вообще.

Цикл ЖДАТЬ в общем виде показан на стр. 168-170.
Автор:  Владислав Жаринов [ Воскресенье, 12 Август, 2012 17:02 ]
Заголовок сообщения:  Re: Задача на перспективу
Ильченко Эдуард писал(а):
...
Сразу скажу, что в очередной раз отсутствие удобства работы с редактором фактически ставит крест на исследовательской работе. Кроме того, для обсуждения хорошо бы чтобы у всех заинтересованных участников были одинаковые версии редакторов для обмена и модификации схем, которые просто хорошо работали бы, а не заставляли думать о смене деятельности. Я таких не знаю : )

Тем не менее следующий шаг делаю...

Для описания деятельности исполнителя попробую применить дракон-схему, имеющую специальную структуру и наполнить её содержанием из
Владислав Жаринов писал(а):
Вот изначальная формулировка задачи:
Вложение:
Текст Задача ПрД ПредвБюджПроекта — извл(РеферПроцесса).pdf
часть «Описание решения»
...
В поисковой работе вряд ли м.б. готовый редактор, хорошо работающий в смысле требуемого по результатам поиска... :)
Поэтому понятно, что желателен редактор максимально свободный - но выполняющий общие логические требования. Можно считать, что они сформулированы Усовым в сообщении "О языках". Вы что-то такое имели в виду?..
Кстати, это получается близко ко всё тому же DesignIDEF - в смысле возможности строить свою графику вершин, сохраняя логику подключения дуг... но там трудно говорить о вполне удобной работе... да и логика связей возможна только IDEF-овская...

По существу ответил пока здесь: viewtopic.php?p=73838#p73838.
Автор:  Ильченко Эдуард [ Понедельник, 13 Август, 2012 00:11 ]
Заголовок сообщения:  Re: Задача на перспективу
Владислав Жаринов писал(а):
В поисковой работе вряд ли м.б. готовый редактор, хорошо работающий в смысле требуемого по результатам поиска... :)
Поэтому понятно, что желателен редактор максимально свободный - но выполняющий общие логические требования. Можно считать, что они сформулированы Усовым в сообщении "О языках". Вы что-то такое имели в виду?..

Всё гораздо проще : )
Например, я нарисовал схему, а Вы захотели в неё что-то добавить. Взяли мою схему, что-то в ней добавили и отправили мне. Таким образом идёт быстрая проработка вопроса : ) Так что речь шла просто о едином инструменте.
Автор:  Ильченко Эдуард [ Понедельник, 13 Август, 2012 01:41 ]
Заголовок сообщения:  Re: Задача на перспективу
Владимир Паронджанов писал(а):
Ильченко Эдуард писал(а):
Сдерживало отсутствие адекватного инструмента (как я его понимаю). В свете новых приобретённых мною знаний : ) попробую использовать практически стандартный ДРАКОН (там где это возможно).


Уважаемый Эдуард!

Черная ветка "События" является незаконным входом.

Ее можно свести к стандартным приемам. Для этого описывайте Ваши события с помощью цикла ЖДАТЬ.

Да, я знаю о цикле ЖДАТЬ. Но он мне кажется менее выразительным. Что делать если ждать не нужно, а реагировать на события нужно?

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

Что такое Деятельность?

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

Активная Деятельность - Деятельность, выполняющаяся в данный момент времени.

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

Чтобы как-то отличать правильные дракон-схемы от схем, которые на них похожи, буду называть такие схемы Похожими на Дракон схемами (или ПД-схемами).

Ниже Ваша дракон-схема «Алгоритм реального времени» и моя ПД-схема модель актора «Бортовой компьютер летающей тарелки» : )
Вложение:
арв1.png
арв1.png [ 35.61 КБ | Просмотров: 17783 ]

Вложение:
actor84.png
actor84.png [ 51.28 КБ | Просмотров: 17783 ]
Автор:  Владимир Паронджанов [ Понедельник, 13 Август, 2012 13:46 ]
Заголовок сообщения:  Re: Задача на перспективу
Ильченко Эдуард писал(а):
Да, я знаю о цикле ЖДАТЬ. Но он мне кажется менее выразительным. Что делать если ждать не нужно, а реагировать на события нужно?


Уважаемый Эдуард Ильченко!

Я чрезвычайно дорожу Вашим мнением. Ваши сообщения превосходны и всегда глубоко продуманы.

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

Я всегда считал, что цикл ЖДАТЬ исчерпывающим образом решает проблему управления событиями.

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

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

В связи с этим (в связи с огромной важностью проблемы управления событиями ... я не знаю как именно полагается называть эту проблему) у меня к Вам две большие просьбы.

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

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

Спасибо
Автор:  Alexey_Donskoy [ Понедельник, 13 Август, 2012 14:11 ]
Заголовок сообщения:  Re: Задача на перспективу
Ильченко Эдуард писал(а):
Деятельность - единица выражающая производимую актором последовательность действий за один рабочий цикл.
Напрашиваются очевидные аналогии:
- обработка прерываний (синхронная реакция на события);
- квантованние процессов в многозадачной среде (а именно, асинхронная обработка событий).

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

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


Владимир Паронджанов писал(а):
желательно подробно перечислить недостатки цикла ЖДАТЬ
Цикл ЖДАТЬ никак не подходит для изображения синхронной обработки событий (например, прерываний процессора).
Только достаточно редкие частные (и специально организованные) случаи можно изобразить с применением цикла ЖДАТЬ.
Автор:  Ильченко Эдуард [ Понедельник, 13 Август, 2012 20:37 ]
Заголовок сообщения:  Re: Задача на перспективу
Alexey_Donskoy писал(а):
Ильченко Эдуард писал(а):
Деятельность - единица выражающая производимую актором последовательность действий за один рабочий цикл.
Напрашиваются очевидные аналогии:
- обработка прерываний (синхронная реакция на события);
- квантованние процессов в многозадачной среде (а именно, асинхронная обработка событий).

В первом случае нахожу совершенно не оправданным нахождение фонового процесса и процессов обработки событий в одном "силуэте".

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

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

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

Например, если менеджер занят проработкой заказа и телефонный звонок оторвал его от этого увлекательного занятия, то телефонный разговор можно считать совершенно отдельным процессом, а можно — другой Деятельностью. Телефонный звонок не делает менеджера совершенно другим актором (иначе он шизофреник : ) Вот подумалось, микропроцессор, у которого постоянно меняется контекст работы — скрытый шизофреник : )
Страница 1 из 7 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/