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

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


Сообщения - Влад Жаринов

Страницы: 1 ... 10 11 [12] 13
166
Общий раздел / Re: Системы: средства и цели
« : Август 11, 2012, 01:32:31 pm »
...
3) В смысле сказанного здесь: http://forum.oberoncore.ru/viewtopic.php?p=52789#p52789 - можно считать, что [мета]язык "внешней схемы" - система предметных [подъ]языков? Которым и д.б. изоморфны языки того же класса "нейтральные"?
Не понял...
В смысле - что ЯВУ просто передают то же содержание, что и предметные языки (DSL) того же уровня - только не "разговорно", а для алгоритмически строгого исполнителя?.. Т.е. надо иметь две системы (иерархии) языков моделирования?..

167
Общий раздел / Re: Системы: средства и цели
« : Август 11, 2012, 01:28:29 pm »
...
Я не увидел в работе Кубанычбека описания/определения какой-то общей ситуации. ... Принципиальное различие "тогда" и "сейчас" состоит в том, что "тогда" было глубокое понимание (или стремление к пониманию) сути, а "сейчас" - желание быстро получить результат (неважно как). При чтении "Вступления" к книге Кубанычбека мне видится "сейчас", а хотелось бы "тогда".
...
Да, у меня тоже возникли сомнения... которые Вы и сформулировали... :) Возможно, сказанное здесь:
Цитата: Валерий Аджиев в http://www.osp.ru/os/1998/06/179592/
..., когда критерии качества не имеют столь высокого приоритета, как удобство пользования, простота освоения и дешевизна - и все это в сочетании с избыточной функциональностью, пожирающей компьютерные ресурсы, и отсутствием у производителя стимула выбрасывать на рынок действительно отлаженный продукт. Весьма взрывчатая смесь. В обозримом будущем мы можем оказаться свидетелями катастрофических ситуаций, в которые попадут пользователи массовых продуктов, и, похоже, что только это способно сдвинуть ситуацию с ее нынешнего печального положения.
- приближается и из-за т.о. направленных усилий?..
Кстати, что Вы думаете о его оценках разницы программно-управляемых реализаций и аппаратных:
Цитировать
Можно выделить и такой фактор, как переоценка уровня безопасности, в принципе гарантируемого программным обеспечением. Это послужило стимулом заменить используемые в предыдущих версиях системы защитные механизмы, которые контролировали радиационные потоки и блокировали их в случае выхода из нормального режима, с "аппаратных" блокираторов (на базе электронно-механических устройств) на чисто программные. ...

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

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

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

168
Общий раздел / Re: Системы: средства и цели
« : Август 11, 2012, 01:10:37 pm »
...
2) Вообще та или иная концепция товарно-денежных отношений, по-Вашему, влияет на семантическую модель предприятия?
О какой "концепции товарно-денежных отношений" Вы говорите? Всё, что я говорю: "предприятие является агентом товарно-денежных отношений", то есть, оно включено в товарно-денежный обмен наряду с другими предприятиями, частными потребителями, гос. органами и пр. Концепции товарно-денежных отношений не озвучивались, в частности потому, что мы не разбирали ещё, что такое "товар", и что такое "деньги" (на уровне смыслов этих понятий).
...
Как примеры концептуальных положений - считаем мы деньги эквивалентом труда или чем-то иным?.. допускаем кредит только под простой процент или и под сложный?.. ещё что-нибудь?.. может ли влиять на модель семантики или она всегда одинакова?

169
Общий раздел / Re: Системы: средства и цели
« : Август 11, 2012, 01:07:11 pm »
Я бы даже уточнил первый вопрос - я вот так понимаю Александра Сергеевича, что проектируем предприятие (орг[тех]систему), а программная система - результат "технологической реализации" выбранных частей (функций?) как киберсистемы, где между человеком и предметами/средствами/продуктами труда ставится (частично/иногда) "языковая машина", прогсистемой "настроенная на" определение/произведения языка предметной области?.. верно?..
Понятно, что обычное определение формального языка как "множества возможных цепочек символов в заданном алфавите" покрывает аспекты и определения языка, и свода произведений на нём... это я для уточнения своей мысли так подразделил...
После уточнения... я совсем перестал понимать вопрос... :) Можно, как-нибудь попроще изложить вопрос?
...
Т.е. программа - результат просто разделения функций между машиной (для которой реализуется язык представления делегированной ей части функций "для объекта" и "для человека") и человеком (для которого вместо прежнего языка реализуется новый - для оставшихся функций и для управления машиной)?..

170
Общий раздел / Re: Системы: средства и цели
« : Август 11, 2012, 01:02:19 pm »
...
Здесь приводилось описание "6 кружков" - это и есть язык. Смотрите. Система имеет элементы и связи (в модели: "подсистемы" и "ресурсы"). Отметьте, что элементы и связи есть в любой системе, то есть это структура системы. Эта структура должна быть выражена в языке (понятия (декларации) элементов и связей должны быть частью языка). Далее, добавление, удаление элементов - операторы языка моделирования системы; установление связи, переключение связи, удаление связи - это тоже операторы языка. И т.д. Можно взять для примера языки описания БД (близкие понятия - сущность (entity) и связь (relationship)).
Но мне бы в очередной раз хотелось вернуться к мысли, которую я уже неоднократно Вам высказывал: для описания систем вполне пригоден обычный разговорный язык, поскольку, если система построена на адекватной модели, то она всегда проста.
А, то, что мы с Вами обсуждали в личке по исчислению схем... и где-то близко к этому Кауфман, когда рассматривает задачу построения сетей - скажем, здесь на Обероне и ТП5.5: http://forum.oberoncore.ru/viewtopic.php?p=72006#p72006 ?..

171
Общий раздел / Re: Oberon & GCless modules
« : Август 10, 2012, 03:38:26 pm »
Кстати, в спецификации О-2 от Вирта явно определена нужность сбора мусора и основы его реализации (пп. D3,5).
Oberon-2 не совсем от Вирта все же. И да, про этом в этом топике уже упоминалось:
...
Да, точно... :) Сборку мусора для Оберона он описывает в "Проекте Оберон", и это ессно не описание языка... :)

172
Общий раздел / Re: ещё про цикл дейкстры
« : Август 10, 2012, 03:27:46 pm »
Имел в виду, что для рекурсивных алгоритмов указывается возможность откладывания операторов, если определённым образом расположить их в структуре маршрутов. Видел такое в этой книге (Гл. 18 выдержки). Вот и интересно - это можно считать отложенными вычислениями, как Вы их используете здесь (или аналогом)?..

173
Общий раздел / Re: Oberon & GCless modules
« : Август 10, 2012, 03:21:20 pm »
Кстати, в спецификации О-2 от Вирта явно определена нужность сбора мусора и основы его реализации (пп. D3,5).

174
Общий раздел / Re: ещё про цикл дейкстры
« : Август 10, 2012, 11:32:42 am »
...
Отложенные вычисления не являются мусором -- ведь на них есть живые ссылки, в отличие от мусора.
Отложенные вычисления могут быть в любой момент востребованы во время вывода результатов на печать/файл/сеть и тд. -- вот тогда они и вычисляются, а пока они не оказались востребованы, они находятся в памяти в виде формулы вычисления значения.
Проблема лишь в том, что эта формула занимает много места, иногда на много порядков больше, чем результирующее значение...
Это то же самое, что в императивном представлении можно сделать в рекурсии?..

175
Общий раздел / Re: Системы: средства и цели
« : Август 10, 2012, 11:30:03 am »
Я бы даже уточнил первый вопрос - я вот так понимаю Александра Сергеевича, что проектируем предприятие (орг[тех]систему), а программная система - результат "технологической реализации" выбранных частей (функций?) как киберсистемы, где между человеком и предметами/средствами/продуктами труда ставится (частично/иногда) "языковая машина", прогсистемой "настроенная на" определение/произведения языка предметной области?.. верно?..
Понятно, что обычное определение формального языка как "множества возможных цепочек символов в заданном алфавите" покрывает аспекты и определения языка, и свода произведений на нём... это я для уточнения своей мысли так подразделил...

Также уточню по пунктам отсюда кое-что:

2) Вообще та или иная концепция товарно-денежных отношений, по-Вашему, влияет на семантическую модель предприятия? например, м.б. она в одних случаях иерархическая, как Вы формулировали, в других - структурно иной? или иерархия иначе выстраиваться?.. И на аспект, описанный здесь: http://oberspace.dyndns.org/index.php/topic,288.msg7386.html#msg7386 (и прямо совпадающий с предметом обоснований у Кубанычбека)?
А в экономике предприятие - это подсистема? или нечто одноранговое... так сказать, "целое в миниатюре"?..

3) В смысле сказанного здесь: http://forum.oberoncore.ru/viewtopic.php?p=52789#p52789 - можно считать, что [мета]язык "внешней схемы" - система предметных [подъ]языков? Которым и д.б. изоморфны языки того же класса "нейтральные"?

176
Общий раздел / Системы: средства и цели
« : Август 10, 2012, 09:06:59 am »
Вот ещё три рода вопросов возникают по мотивам как этого обсуждения, так и других источников.

1. О средствах описания. В обсуждениях об информатически (программно) строгом описании систем, а также о применимости Оберона для этого можно было видеть разные позиции участников - какова модель системы и как её представить. С учётом мнения, что можно добавить в Оберон и что нужно от инфор-языка (Я[П]ВУ для меня, как понятно - частный случай в расчёте на "языковую машину" как читателя/исполнителя), вот что интересно.
Можно считать, что оправданно доработать какой-то ЯВУ для реализации поставленного Вами назначения в качестве средства описания систем? Оберон поддаётся такой доработке? Или определять язык с самого начала? Что за средства (их виды) он должен содержать, как Вы думаете? Можно ли сказать, что он д.б. "мультипарадигменным"? Или вообще правильно определить ряд языков? Как тогда распределить виды средств между ними? По критерию однопарадигменности? или вообще не этим руководствоваться? или да - но определять полный базис парадигм иначе, чем обычно у программистов принято?..

2. В рукописи Кубанычбека: http://progbookn1.narod.ru/ программирование как вид деятельности также вписывается в некую более общую ситуацию (во Введении прежде всего). Как Вы могли бы оценить данный подход? В частности, с учётом указанного в этом посте?..

3. Как сопрягаются программное и иные описания? Верно ли, что язык высокоуровневого описания программ как систем представляет то же самое, что и менее формальные языки - архитектуру системы (по выделенным Вами уровням). Т.е. каждый уровень имеет описание "для исполнителя программ" и "для более творческого исполнителя"? Можно ли говорить, что ЯВУ задаёт "нейтральную схему" предмета описания в том смысле, как это понимается в разработке БД?

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


...
Что делать - известно, контролировать полученную продукцию на соответствие требованиям стандарта на продукцию (ГОСТ, ОСТ, ТУ). О любом отклонении по любому параметру производитель должен ставить в известность потребителя.
Это тоже важная сторона дела. А делать-то что... если отклонение парируемое в реальности с сохранением качества, но превышающее нормативное?.. только извещать или всё-таки выпускать продукцию?..

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


...
Нет, объединять их не надо, это совсем разные взгляды, но сопрягать нужно обязательно, с помощью ПО, в частности. В машиностроении большая проблема из-за того, что изменения сделанные конструкторами с большими запозданиями отражаются в тех. процессе.
Вот именно, что Грабиным так и было сделано: http://forum.oberoncore.ru/viewtopic.php?p=44068#p44068 - технолог включён в конструирование и побуждает конструктора повысить технологичность.
А про современность - думаю, потому-то в "цеховые" решения наряду с САПР-К стали включать САПР-Т (часто интегрируя через приложения управления инженерными данными - как тот же АСКОН, упомянутый здесь)... Вероятно, Вы видите решение несколько иначе (кстати, заметим, что они ввели элементы WF-моделирования на Паскале... интересно, как при этом описываются совместно протекающие процессы ;) )?..

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

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

179
Общий раздел / Re: Язык для прикладных задач
« : Август 10, 2012, 06:41:51 am »
Вот я где-то о том же... предметный язык должен предоставлять средства выражения реальных моделей предметки... :) Кстати, калькуляция в моём представлении - это рецептура+удельные стоимости ингредиентов/компонентов... ну и расчёт нормативной цены порции/единицы продукта...

Припёк - да, хороший пример... как "из четырёх ручёв получается одна река" ((С) И. Росохватский)... с эффектами слияния... ;)

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

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

Страницы: 1 ... 10 11 [12] 13