OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 21 Ноябрь, 2019 19:42

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




Начать новую тему Ответить на тему  [ Сообщений: 38 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 15 Октябрь, 2011 10:39 

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

(модератор) выделено по предложению Владислава Жаринова (viewtopic.php?p=70836#p70836)


Последний раз редактировалось Евгений Темиргалеев Четверг, 03 Январь, 2013 12:15, всего редактировалось 2 раз(а).
инф. о переносе


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О целостном представлении систем
СообщениеДобавлено: Суббота, 15 Октябрь, 2011 10:50 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Драконограф писал(а):
alexus писал(а):
При этом рефакторинг, как явление, необходимо предать массовому осуждению... жестче, чем пресловутый GoTo.
Почему бы и нет?.. А если изменения понимаются как варианты - то вместо этого что-то подобное механизму областей предполагается?
Предполагается несколько иное... Я уже говорил о схемах. Схема - это распределение внешнего/внутреннего воздействия/возмущения/сообщения/запроса/задания по элементам системы. На одно и то же воздействие может быть несколько разных схем, выбор нужной схемы определяется состоянием системы. (Состояние не всегда является статическим, оно может быть и динамическим/переходным... но это очень трудная задача, как правило). Схема - это ничто иное, как алгоритм работы системы... с одной стороны. С другой стороны, это основа для расписания работы элементов (для большого класса систем - это очень важный момент).
...
Ага. Если я правильно понял - схема есть порядок прохождения деклар-сущностей (вещества/энергии/данных как предметов труда) по связям. Т.е. (в привычной мне графит-терминологии) распределение имён деклар-сущностей по меткам дуг актив-схемы (а метки эти как раз определяют наполнение связей). Ессно, по ходу передела имена могут меняться; также (напр., через РБНФ, расширенный операциями "алгебры материального") задаётся превращение актив-сущностей при переделе (когда "два ручья плюс два ручья есть одна река" - м.б. ещё помните из "Города роботов" И. Росохватского?.. ;)).
На каждое имя определён алгопроцесс обработки (импер-сущность), исполняемый в актив-сущности, для которой это имя является входным. Ессно, процесс м.б. комбинаторным (т.е. работать с набором сущностей, в т.ч. поступающих неодновременно); для этого д.б. задана время-зависимая логика реакций на комбинации объектов. М.б. запущены экземпляры процессов в одной актив-сущности для переработки независимо обрабатываемых сущностей (комбинаций).

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

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

Каково Ваше мнение по этим вопросам?

P.S. Отсюда у меня и РДП превратилось в разработку и документирование процессов. И представление из заключения к документу, вложенному в этот пост, о среде исполнения РДП-моделей как приложении диспетчирования...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О ролевой структуре деятельности
СообщениеДобавлено: Суббота, 15 Октябрь, 2011 11:11 

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

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

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

    * конструктор — замышляет орудия как изделия сообразно назначению (воспринимаемому от эксплуатанта и/или мыслимому самостоятельно) и определяет их облик (устройство и принцип действия) и способ применения (включая обслуживание), оптимальный (в идеале — наилучший) для удовлетворения требуемых целей в заданных условиях, учитывая условия производства и программу выпуска (включая возможность использовать наличные/доступные для заказа на стороне комплектующие изделия); для коллективного создания изделий также отражает облик в конструкторской документации, а способ применения — в эксплуатационной на установленных языках; взаимодействует с эксплуатантом (заказчиком) по оптимизации требований (в идеале — совершенствованию с учётом перспективы применения); при коллективном конструировании могут выделяться представители заказчика, специализирующиеся на формировании требований к изделиям, а также испытатели, предварительно эксплуатирующие образцы изделия для уточнения облика и/или требований;

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

    * инструментальщик — сообразно облику изделия и содержанию техпроцесса определяет необходимость в орудиях производства (инструменты, приспособления, машины) — как существующих (программу выпуска/заказа для восполнения расхода по данному изделию) так и новых (замысел), формирует облик новых орудий и определяет техпроцесс их производства (обычно только для собственного, но м.б. также и для стороннего); для коллективного создания изделий также отражает содержание техпроцесса в технологической документации, а потребность — в документации заказа на установленных языках; взаимодействует с технологом по оптимизации техпроцесса и с конструктором — облика изделия в смысле сокращения потребности; при коллективном орудийном обеспечении могут выделяться роли конструктора и технолога по средствам производства;

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

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

    * снабженец — обеспечивает деятельность необходимыми ресурсами; независимо от экономической системы (формации) базовым ресурсом являются кадры — люди, готовые/способные к той или иной деятельности (после замещения должностей становящиеся сотрудниками), а также условия существования людей в связи с деятельностью (как частный случай — сотрудников в конкретном трудовом процессе); в товарно-денежной экономике основной вид прочих ресурсов составляют деньги и т.н. финансовые инструменты, также возможно обеспечение через прямой товарообмен (бартер); при коллективном обеспечении выделяются специализации: кадров (подбора и расстановки, найма и увольнения, [пере]подготовки), жизнеобеспечения (производства условий пребывания людей по местам деятельности и окружающей среды), материально-технического снабжения, сбыта, логистическая (транспорта и хранения), при деятельности нефинансового профиля м.б. также специализация ценностного снабжения (деньгами и фининструментами помимо результатов сбыта);
      Жизнеобеспечение включает самые разные виды работ, как- то: питания, энергоснабжения, вентиляции, освещения, сантехники, подвода/отведения специальных рабочих сред — смазывающих, охлаждающих, изолирующих, ингибирующих и пр., очистки/подготовки воздуха, воды и спецсред; те или иные работы м.б. переданы сторонним исполнителям.
      Видно, что мы трактуем термин «снабженец» в широком смысле; впрочем, это касается не только данной роли. :)

    * организатор — принимает решения о развёртывании/свёртывании того или иного вида деятельности, текущем управлении им во взаимодействии с надсистемой деятельности, об обеспечении различных видов; при коллективной организации выделяются первые лица (высшие руководители), а остальные организаторы (частного управления) могут образовывать иерархию последующих уровней, одноранговую или смешанную структуру управления; сферы частного управления м.б. выделены в пространстве, во времени (обычно относительно трудового процесса, т.е. по порядку работ от предметов к результатам труда) и/или функционально (по видам деятельности);

    * администратор — определяет порядок и/или результат использования ресурсов; при коллективном администрировании выделяются специализации: распорядительная (диспетчеризации работ), учётная (продукции, труда и заработка, финансов и иных ценностей), безопасности (контроля условий труда и факторов влияния на систему деятельности);

    * эксперт (контролёр, приёмщик) — определяет соответствие изделия (сырья, полуфабриката) требованиям и причины несоответствия; обычно выделяются внутренний (контроль качества) и внешний (экспертиза); к тому и другому часто привлекаются испытатели, в т.ч. сторонние (независимые от производителя).

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

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

В то же время любое строгое деление несколько условно; это мы видим и здесь, когда по поводу требований (а часто и сервиса) взаимодействуют эксплуатант и производитель, а по поводу качества (изделия и/или обслуживания) — они же и эксперт (независимый). Также и в категорию снабжения мы включили жизнеобеспечение, которое, как видим, с тем же успехом можно отнести и к производству (вспомогательному).

Здесь мы не выстроили никакой иерархии ролей. Большинство таких иерархий так или иначе возникает в практике коллективного труда; но следует помнить, что следование какой-то одной из них обычно приводит к стагнации и краху системы. Ранги ролей во времени д.б. динамичны и меняться естественно; в каком-то смысле роль хорошего организатора и состоит в поддержании этой динамики; этому учит в основном опыт деятельности в различных ролях.
    По-видимому, некоторые виды иерархии ролей вообще не м.б. употребительны сколь-нибудь долго, ибо порождают факторы, дестабилизирующие систему.

Общий принцип управления в коллективе — трудовая деятельность любого специалиста управляема организатором и администратором.
    Деятельность по созданию орудий труда/ улучшению условий существования сама также должна рассматриваться как предмет труда по её созданию/улучшению. Это задача в первую очередь организатора; в современных условиях также признано необходимым учатие в преобразовании коллективной деятельности всех сотрудников.

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

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

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

    * «абстрактный» инициатор (инвестор) — вносит ценностный вклад в деятельность без права инициирующих решений, имея в обмен гарантированное участие в результатах; в современных условиях обычно также возможно ограниченное право (с негарантированным участием); в паразитической экономике эта роль гипертрофирована, в аморальном/криминализованном обществе - «абстрагирована» от последствий деятельности (допуская обход граничений и/или запретов); возможны коллективные инвестиции; при специализации возможна передача вклада профессионально инвестирующей организации;

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

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

Нужно выделить также типы организации производства по личностным отношениям:

    * «я для себя» - утилитарное, когда эксплуатант единолично и применяет/обслуживает, и производит орудия труда;

    * «кто-то для меня» - заказное, когда производитель удовлетворяет требования конкретного эксплуатанта; возможно, что ряд независимых производителей поставляют/обслуживают несамостоятельные части, образующие орудие труда лишь в совокупности; тогда среди производителей м.б. выделен т.н. системный интегратор частей в орудие;

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

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

Существуют также виды производства по объёму выпуска — единичное, серийное, массовое. Они хорошо известны и часто смешиваются с типами организации.

Также предметом м.б. не только изделие, но и услуга — создание неких необходимых/желательных условий существования, состояния самого потребителя и/или его окружения. Основное отличие — в том, что она «производится на месте», у потребителя. Услуга может заключаться и в создании требуемых условий деятельности (жизнедеятельности).

Заметим, что трудовые процессы по назначению не сводятся только к практическому — производству продуктов/услуг. Мы вслед за А.Я. Фридландом выделяем также учебное и научное назначения.

Наконец, в роли изделия может выступать набор (массив) данных; также возможны услуги, связанные с уже имеющимися у потребителя данными. Тогда можно говорить о датаматическом производстве/обслуживании (часто говорят «информационное», но в принятом нами толковании информации по Фридланду это не совсем корректно). Продуцируемые данные м.б. предназначены для управления орудиями труда. В этом случае имеем автоматизированное производство (сервис).
    Заметим, что работа, связанная с информацией, может включать передачу знаний; но это всегда делается в том же процессе формализации, т.е. через передачу данных, включаемых в ментальный опыт реципиента (насколько — зависит от его образованности и умственных способностей). Также неверно относить передачу знаний к услугам — это коллективный труд реципиента (обучаемого) вместе с донором (учителем).

О специфике труда, связанного с данными, поговорим отдельно. Именно таков и труд по формализации знаний, включая создание, применение, утилизацию инфопрограммных изделий.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Октябрь, 2011 11:17 

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

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

    В принципе возможно, что информатизация проводится для более эффективной организации труда людей без дополнительной автоматизации. Тогда создаётся только новая модель процессов труда; она м.б. основана на новом (более прогрессивном) представлении (типизации/атрибуции) объектов (предметов и средств) труда. Здесь результатом будут "педантические" (алгоритмически строгие) описания манипуляций с ручным инструментом и/или машинами (станками, приспособлениями) над "педантически" (датаматически строго) описанными объектами (вещами, данными).
      Пример - описание технологии по стандартам ЕСТД (ГОСТ 3.*) над материальными изделиями, описанными по стандартам ЕСКД (ГОСТ 2.*).

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

Всё это напоминания тривиальные; важно лишь, что это действующие лица фазы применения полного ЖЦ, а нас интересует и фаза создания.

    Кто тогда технолог? Системный аналитик — специалист по процессам разработки на имеющихся платформах.

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

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

    При автоформализации знаний или формализации с вовлечением конечных пользователей (на чём основан менеджмент качества) этот эксперт есть сам заказчик системы автоматизации.

Вроде бы вещи тривиальные, и каждый скажет "так это давно так и есть". А так ли? Посмотрим, каково положение дел в реальности...

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

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

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

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

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

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

    Это не зависит от предмета труда — но попробуйте найти в документации на орудие материального производства ограничение ответственности типа: «мы не отвечаем за какие бы то ни было последствия применения нашего орудия по назначению». А в ИТ подобное сплошь и рядом...

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

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

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

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

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

    Так что реализуя графит-языки, стоит подумать, как построить дело — если не сразу, то по мере работы.

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

В каждой предметной области существует свой профессиональный язык. И помимо базиса графит-языков, рассматриваемого нами, среда поддержки формализации должна позволять «говорение» на этом — предметном — языке (зарубежные ИТ-специалисты обычно называют их domain-specified languages, DSLs). Хотя бы на уровне «букв», из которых пользователь среды будет складывать «слова». В графике «буквы» - это базовые примитивы (автофигуры).

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: И что из этого?
СообщениеДобавлено: Суббота, 15 Октябрь, 2011 11:27 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И что из этого?
СообщениеДобавлено: Понедельник, 17 Октябрь, 2011 12:53 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9160
Откуда: Россия, Орёл
Драконограф писал(а):
Илья Ермаков предлагал вариант спецификации системы (также оргтехнической, как моожно понять) на Обероне. Будут ли другие предложения?


Не предлагал... Или предлагал, но не это... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Октябрь, 2011 05:33 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Октябрь, 2011 06:51 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Октябрь, 2011 08:02 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Интересно, что скажут другие, кто в теме... alexus, допустим...
Вроде бы эти вопросы мы уже обсуждали... и неоднократно. Ничего нового я не скажу. Вы правы, можно исходить из базовой модели жизненного цикла изделия/продукции: моделирование - проектирование/конструирование - планирование - разработка/создание - эксплуатация. Каждая стадия представима своим технологическим процессом. То есть, существует процесс моделирования, существует процесс проектирования и т.д. Любой процесс состоит из отдельных операций (в предельном случае может состоять из одной операции). Собственно, принципиальной разницы между процессом и операцией нет, любой процесс можно считать макрооперацией, а любую операцию можно рассматривать, как микропроцесс. На производстве этим часто пользуются, называя микропроцесс - типовым технологическим процессом, например. Подобная масштабируемость очень удобна, поскольку позволяет использовать одни и те же модели на микро- и макро-уровнях.
Любой технологический процесс представляет собой орграф (направленный граф), где вершины соответствуют технологическим операциям, а рёбра - передачам полуфабрикатов. На микроуровне (уровень предприятия) операции выполняются производственными мощностями данного предприятия, на макроуровне, операции выполняются на отдельных предприятиях (например, операция по выпуску тракторов выполняется тракторостроительным заводом [ЧТЗ, к примеру]). Аналогии по описанию микро- и макро-уровней можно приводить долго... но я их опущу, чтобы не уходить от темы.
Технологическая операция объединяет в себе три элемента (порождается ими): средства труда, предмет труда и, собственно, живой труд. Каждый элемент операции нормируется: нормы износа основных средств, нормы выработки/потребления, и нормы времени работы персонала. Помимо этого, есть нормативы и требования к самой тех. операции, которые не сводятся к её элементам (или сведение не является тривиальным). Нормироваться, например, может время выполнения тех. операции, которое, в общем случае, не равно времени работы оборудования и/или персонала. Требования к операции оформляются технологическим регламентом, где прописывается порядок выполнения операции и контроль выполнения и результатов.
Что мы сейчас имеем...
1. Стадии жизненного цикла, где каждая стадия - процесс, и связи между стадиями;
2. Структуру любого процесса;
3. Элементы, из которых состоит процесс, включая нормативы и требования к ним.
Как видите, всё достаточно строго/формально, единообразно и полиморфично... Всё сказанное можно довольно просто превратить в систему, которая позволяет контролировать жизненный цикл, планировать развитие изделия (вносить изменения, выпускать новые ревизии/версии, переходить к новым изделиям). В общем, даже структура БД для этой системы довольно проста.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Октябрь, 2011 17:47 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Октябрь, 2011 18:40 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Да, это в таком ключе действительно обсуждалось в содержательных темах. Эту я вижу скорее как "формальную". Потому как раз интересно - каким языком кто считает возможным выразить сие?
Русский, английский, испанский, французский, немецкий, итальянский?.. Не подойдут?.. Проекция на конкретную предметную область [автоматически] породит сленг. Если обычных языков мало, тогда добавьте графику... графическое изображение графов (простите за тавтологию) в виде схем, диаграмм... помогает их восприятию.
По своему опыту... граф описанный в терминах конкретного предприятия позволяет руководству данного предприятия легко понять и функциональную структуру всего предприятия и... существо деятельности любого подразделения/подсистемы. Был довольно интересный/забавный случай, когда мы встречались с руководством Уралмаша (~2006-2007 г.г.).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Октябрь, 2011 19:01 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Любопытно... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Октябрь, 2011 05:46 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Любопытно... :)
История длинная, пересказывать её, наверное, нет смысла, оставлю только существенное. ... мы последовательно обходили руководителей/директоров предприятия объясняя/обосновывая им устройство системы/предприятия. Если руководитель понимал и мог представить, как это использовать в текущей деятельности, то "выкатывал белый шар", в противном случае... "шар был чёрный"... он же последний. Мы вполне успешно поговорили с производственниками, снабжением (он нам потом прислал своего сына... устраиваться на работу)... дошла очередь до планирования... Планирование на таком крупном предприятии, как Уралмаш (в хорошие годы там работало 55 000 чел.), занятие... занятное... :)
Мы пришли в плановый отдел чуть раньше времени, нас отвели в комнату, в центре которой стоял большой стол, и рабочие столы по периметру комнаты... штук 10-12... Всё это пространство было завалено листами бумаги... с диаграммами... описаний "бизнес-процессов". Такое обилие макулатуры навевало грустные размышления. Я неосторожно пошутил по поводу "бизнес-процессов", меня привычно не поняли... но когда пришёл руководитель, ему передали "остроту", сопроводив её своими комментариями. Тот покраснел (от крайнего неудовольствия) и сразу перешёл на повышенный тон. Минут тридцать он объяснял, что никто не представляет себе планирования на таком крупном предприятии. Номенклатура собственных деталей - несколько десятков тысяч, покупных - на порядок больше... Если на каком-то этапе на одном из участков не окажется [паршивых] болтов, то процесс встанет... прощай выручка, прибыль, премии и даже зарплаты... Никто [толком] не знает, что в данный момент находится на участках, на сколько хватит складских запасов по той или иной номенклатуре... Вёрстка общего производственного плана [с учётом бесконечных согласований] на следующий месяц может занимать более месяца, а в результате горят сроки исполнения заказов [заказчику нужно быстрее/ещё вчера, а производство очень неповоротливо]... И т.д. и т.п. Если кто-то работал на крупных [машиностроительных] предприятиях, тот, наверное, знает "стандартный" набор проблем, с которыми приходится сталкиваться руководителям. Трудности Уралмаша обусловлены ещё тем, что это мелкосерийное и порой позаказное производство, что выливается в малые размеры производственных партий и, соответственно, их большое количество, что, разумеется, не облегчает жизнь плановикам, производственникам, снабженцам... И без детального описания "бизнес-процессов" [как это сделано во всём цивилизованном мире] планировать не удастся, поэтому... шутки здесь неуместны. Он шумно выдохнул... было видно, что он устал и ему совсем не хочется тратить время на очередную PR-акцию... каких-то очередных автоматизаторов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Октябрь, 2011 07:53 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Рассказывать о системе, о моделях не имело смысла, поскольку это просто не стали бы слушать (или сделали бы вид, что прослушали). Поэтому я просто продолжил перечислять проблемы планирования, которые ещё не были озвучены, попутно связывая их в цепочку, расставляя их приоритеты и показывая внутренние зависимости/обусловленности и, наконец, возможные причины возникновения. Это подействовало... минут десять я говорил спокойно (стараясь попасть в интонации руководителя), потом стали перебивать вопросами. В какой-то момент говорить стало невозможно и вернулись к началу. Я им нарисовал схему многопередельного/многоцехового производства (всё тот же орграф, где вершинами являются макрооперации выполняемые цехом: литейный цех, кузнечный, штамповочный, мех. обработки и т.д., а ребрами являются межцеховые связи - передачи полуфабрикатов). Естественно, что связи являются слабыми и гибкими, то есть, их можно перестраивать при планировании производства конкретной продукции (например, для какой-то продукции не нужны кузнечные операции или, наоборот... нужны). Когда связи установлены, можно переходить к планированию, то есть, перемещению по связям полуфабрикатов. Если известен норматив времени выполнения какой-то операции, то зная объём партии, можно сказать сколько времени займёт выполнение этой операции над данной партией продукции. При этом планировать можно от конца к началу (от плановой даты выпуска продукции до даты запуска в производство - "тянущая" методика планирования) или от начала к концу (от даты запуска к дате выпуска - "толкающая" методика планирования). Таким образом, добавляем к плану выпуска/запуска всё новые партии продукции, в соответствии с приоритетами (срочные заказы, отстающие, обычные, "фоновые") до тех пор пока на одном из участков/цехов не произойдёт перегрузка. Перегрузка означает, что на участке/в цехе не хватает производственных мощностей для выпуска нужного объёма продукции (с учётом коэффициента загрузки, который в мелкосерийном машиностроении составляет 0,6 - 0,85 [чем выше, тем эффективнее используются производственные мощности], в Японии этот коэффициент держат на уровне 0,45 - 0,6 (двойной запас производственной мощности), в противном случае их пресловутый Канбан не работает, а стоит запас мощностей... дорого... половина оборудования простаивает без дела). Если план работы подходит к пределу (0,85), а сроки выпуска "горят", тогда следует подумать о повышении сменности (ввести дополнительные рабочие смены) и/или организацию и оплату сверхурочных работ. Выполнив планирование на уровне производства в целом, можно перейти к цеховому планированию. Нам уже известны объёмы работ, которые должен выполнить цех в плановом периоде, зная технологию производства в данном цехе, количество и размещение производственных мощностей, можно по той же схеме (теми же алгоритмами) выполнить внутрицеховое планирование.
Отдельно стоит вопрос о горизонте планирования, поскольку от момента запуска в производство до выпуска готовой продукции проходит порой не один месяц, и даже не один год... То есть, планирование работы начальных цехов по выпуску данной продукции происходит задолго до планирования работы сборочных/разборочных (конечных) цехов, в противном случае, сборщики просто останутся без работы. Также необходимо учитывать, что даже при мелкосерийном производстве, часть производственных подразделений могут работать в режиме средней и даже крупной серии (на одной буровой установке может быть несколько тысяч болтов - выпуск болтов - средняя серия, а сами буровые выпускаются мелкой серией).
Потом обсуждались вопросы нормирования, включая нормативы складских запасов, учёта остатков на рабочих местах/участках и пр. пр. ...
Через неделю мне позвонил мой знакомый и сказал, что на совете директоров Уралмаша докладывал руководитель отдела планирования по нашим моделям. Однако не прошло и трёх месяцев, и "москвичи" в очередной раз сменили руководство предприятием... Разруха, увы, продолжается... Но сам факт того, что работу любого предприятия можно выстроить сообразуясь с элементарной логикой, без каких-то анкет, рисования "бизнес-процессов" и прочих глупостей (а-ля ISO 9000:2000 и подобных)... вселяет надежду, что может быть одумаются... ещё...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2011 11:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков в viewtopic.php?f=62&t=3630&start=40#p66891 писал(а):
Подумалось...

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

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

Именно. Об этом и говорилось в заключении спецификации Ты-среды). :) На этом основана и идеология СУПР. Вот только с представлением о деятельности в целом надо бы определиться, чтобы реализовать. У Вас, возможно, есть предложения?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Октябрь, 2011 11:09 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Для предметки "защиты информации", конечно, уже давно создавались различные модели деятельности. В специфических целях, разумеется - поэтому иной раз можно понимать как "представление о части слона". :) Вот одно такое представление:
Вложение:
Комментарий к файлу: Предложения предприятия "Информзащита" по определению ролей в АИС.
НИП ИЗ-ИБАС-подб(Концепция)сер.tif
НИП ИЗ-ИБАС-подб(Концепция)сер.tif [ 841.61 КБ | Просмотров: 9556 ]
Оно было реализовано в изделиях предприятия. Любопытно, насколько м.б. использовано для формирования целостного представления о системе деятельности.


Вложения:
НИП ИЗ-ИБАС-подб(Концепция)сер3.png
НИП ИЗ-ИБАС-подб(Концепция)сер3.png [ 258.84 КБ | Просмотров: 9556 ]
НИП ИЗ-ИБАС-подб(Концепция)сер2.png
НИП ИЗ-ИБАС-подб(Концепция)сер2.png [ 20.41 КБ | Просмотров: 9556 ]
НИП ИЗ-ИБАС-подб(Концепция)сер1.png
НИП ИЗ-ИБАС-подб(Концепция)сер1.png [ 204.15 КБ | Просмотров: 9556 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Реализация СУПР
СообщениеДобавлено: Воскресенье, 30 Октябрь, 2011 11:45 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков писал(а):
Подумалось...
Если посмотреть на все эти "рабочие инструкции", "описания процессов", то можно увидеть, что там большая часть может быть автоматизирована.
...
Хм?... Прямо таки реклама... :) Посмотрите здесь... Это делал один наш сотрудник в порядке личной инициативы, установлена в ~15 разных организациях (редакция журнала "Медицина и здоровье", юридические фирмы, рекламные компании и т.п.). Всё, что Вы написали там есть и много чего ещё. Делалось одним человеком в течение ~0,5 года. В качестве СУБД используется Firebird 1.x (более поздние версии использовать нельзя по причине некорректной работы с системными таблицами). Отзывы о системе только самые положительные. Я не рекламирую этот продукт, мы его не внедряем, но если интересно, то посмотрите.
Ну что ж, молодцы... уже давно реализовали моё техзадание... :)
Если серьёзно - то конечно, потребность давно назревшая. Посему неудивительно, что уже есть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 31 Октябрь, 2011 10:25 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alignat в viewtopic.php?f=62&p=67067#p67067 писал(а):
...
1. Исполнителя лучше рисовать отдельной иконой сбоку.
Можно и так... в интересах эргономики мы всё равно можем (и это ещё один принцип УПР-языка в моём понимании) абстрагировать такую схему по разным критериям. В частности, оставив только исполнителей - и тем самым получив граф их связей по ходу исполнения схемы.
alignat писал(а):
...
3. Если необходимо указать документы - руководства к действию, то их пишем в комментарии.
Или можно в текст действия - в формулировке "Сделать <то-то> с <тем-то> как указано <там-то>".

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

alignat писал(а):
...
Остается открытым вопрос что делать с массой вариантов параллельных действий.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 31 Октябрь, 2011 19:38 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Ноябрь, 2011 12:14 

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

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

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


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

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


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

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


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

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