OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 25 Август, 2019 17:19

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




Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 11 Июнь, 2010 20:07 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
Хорошо описана проблема и задачи, требующие решения.

Карл Левитин "Прощание с Алголом". - М.: Знание. - 1989.

с. 43
Цитата:
У нас в стране около 200 тыс. человек заняты только тем, что составляют программы для ЭВМ. (При этом ещё в полтора раза больше людей, которые программируют почти постоянно, решая свои задачи на машинах, но профессиональными программистами не являются, и потому мы их учитывать не будем). Каждый из них пишет в год в среднем 5000 команд. Если даже девять десятых из этого миллиарда - разовые программы или же такие, что не выходят за пределы того коллектива, где возникла задача для программиста, то и тогда 100 миллионов команд ежегодно отчуждаются от тех, кто их написал и уходят "в большую жизнь".

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Июнь, 2010 20:55 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
с. 58

Цитата:
Ершов:
Дело в том, что программы должны теперь обладать необычайной надёжностью и защищённостью - куда большей, чем, скажем, те же самые мосты или станки.
...
Сейчас это моя самая большая забота. Что-то надо делать, создавать какую-то вынуждающую обстановку, которая не позволила бы программисту работать по-старому, то есть, заканчивая свою работу и отдавая её людям, не быть уверенным в её стопроцентной точности. Существующая практика программирования совершенно неадекватна тем задачам, которые стоят перед эти новым видом человеческой деятельности. Свидетельства правильности программ носят эмпирический и заведомо приближённые характер и основаны на демонстрации поведения машины, управляемой данной программой, в весьма ограниченном числе ситуаций. .. Сегодня оценка степени достоверности программы - личное дело каждого программиста. А нынешние правила приёмки результатов их труда, при всей кажущейся строгости, носят поверхностный характер, не затрагивающий существа самого программного продукта ...
Теперь два слова о причинах, породивших нынешнее положение. Добрых две трети из двухсот тысяч профессиональных программистов, которые сегодня трудятся в стране, были выпущены вузами и университетами в десятилетие между 1968 и 1977 годами по специальности "Прикладная математика" или родственным ей. ... Не подвергая сомнению ни добросовестность их [учебных программ и учебников] авторов, ни необходимость обучения тем начальным сведениям по программированию, которые содержатся в этих книгах, надо всё-таки признать, что с позиций современной науки всё, чему сейчас учат будущих программистов, не выходит за пределы элементарной "компьютерной грамотности".
Программированию как научно обоснованному методу составления программ для ЭВМ не учат и сейчас. ... Действительно, есть проекты, в которых достигается высокая надёжность программ, но делается это средствами, недоступными массовому разработчику, чересчур дорогой ценой. Есть поток научной, главным образом переводной литературы, который должен был, казалось, играть формирующую роль в подходе программистов к своей работе. Но тираж и расходимость этих книг показывают, что они становятся достоянием лишь незначительной части профессиональных программистов, а кроме того, знание, заключённое в этих книгах, за редчайшим исключением не может быть использовано в непосредственной практике и потому оказывает лишь угнетающее воздействие - вызывает раздвоение между "большой наукой" и неприглядной действительностью.
С горечью приходится констатировать, что личный опыт программиста лишь усиливает эмпирическое начало в его труде. В последние годы, правда, в программировании стали созревать очень глубокие аналогии, раскрывающие математический характер создаваемого нами доказательного программирования и его связь с другими разделами математики. Составление программы можно представить в виде символического решения некоторого уравнения - поставленной перед программистом задачи. Сама программа получается как побочный результат строгих рассуждений о возможности её создания. Таким образом, её правильность гарантируется всем математическим аппаратом, использованным при её получении. Конечно, чудес на свете не бывает - плата за доказательность программирования состоит в том, что приходится манипулировать текстами, превышающими в десять раз по объёму собственно программу.
- Какой же выход предлагаете вы, Андрей Петрович? Вашу концепцию лексикона программирования, о которой вы говорили вчера в своём докладе?
- Да, её самую. Вся концепция лексикона направлена на то, чтобы выработать стабильную, убедительную и всеохватывающую математическую форму записи программы, сформулировать - опять-таки математически базу знания, найти те закономерности, которым удовлетворяет процесс программирования. Это можно назвать математическим анализом программ - как раньше был математический анализ величин и функций. Концепция эта сейчас настолько "носится в воздухе", что я не могу по чести сказать, что являюсь её единоличным автором. Просто мне удалось сформулировать некоторые положения.
[Слово "лексикон"] родилось как стремление противопоставить нечто многочисленным языкам программирования. Программирование родилось под знаком мечты об едином языке, но сразу же породило великое множество их. Проблема тут в диалектическом противоречии. У всякого языка программирования две ипостаси. Одна - быть средой, в которой возникает программа. Тут перед нами встаёт образ языка-оболочки, обладающего расчленённой семантикой и разнообразными изобразительными средствами. Другая же его испостась - быть системой, лежащей в основе передачи программы машине. Здесь возникает образ языка-ядра, крайне экономичного во всех своих конструкциях, имеющего ограниченную и замкнутую, то есть защищённую от нашего произвола, семантику.
...
Отсюда следует важный тезис: поскольку мы не можем повлиять на языковое разнообразия или хотя бы расчитывать на его заметное сокращение, идеология программирования не может ориентироваться ни на какой конкретный язык. Такая, скажем, книга, как "Структурное программирование на КОБОЛе", - это всего лишь костыли, гуманно предлагаемые людям, покалеченным смолоду.
Вот качестве альтернативы единому языку программирования и надвигается представление о языковой среде, которую хочется назвать лексиконом программирования в том смысле, в котором говорят "и он перешёл на свой лексикон профессионального бухгалтера".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Июнь, 2010 21:01 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
Можно говорить о том, что Оберон является ядром такого лексикона программирования. Как мы всегда говорили - экстрактом самых существенных понятий. Однако выраженных в форме языка программирования, на котором можно непосредственно писать эффективно выполняемые программы.

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

Так же, как синтез "и псевдокод, и язык программирования".

И синтез учебного и промышленного языка: если начинаем рассуждать о потребностях образования, то сразу же говорим, что распространённость и промышленная применимость не имеет значения. Находим Оберон как оптимум. Затем оказывается, что в форме КП/ББ это ещё и промышленная среда. Произошло снятие противоречий и синтез ранее несовместимого.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Июнь, 2010 06:37 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3061
Откуда: Астрахань
Я тут намедни писал статью о предметной области в обучающей системе по программированию. О возможном вычислении сложности предлагаемого материала.
И тоже написал, что при обучении программированию концепты не являются понятиями только языка программирования. Цикл - он в любом языке цикл, и подпрограмма - тоже. Форма представления меняется от языка к языку (не не сильно), а вот семантика-то остается одна и та же. При автоматизации обучения программированию как раз одна из задач - выделить такие концепты и их связи-отношения. Чтобы можно было построить семантическую сеть. И вычислять неким образом сложность подаваемого системой материала (для адаптивного управления).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О лексиконе инженерии знаний
СообщениеДобавлено: Суббота, 12 Июнь, 2010 22:15 

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

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

Так же, как синтез "и псевдокод, и язык программирования".


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

Прежде всего - у нас получится метаязык РДП-документа, несводимый только к ДРАКОНу как по алфавиту, так и по типологии схем.
Далее - нужно исходить из принципа единого источника данных модели. Это предложил и Дмитрий_ВБ как ТФАП (свою т. зр. изложил во вложении в это сообщение), это же определено в 9-м техтребовании от меня. А по сути, в основе этого требования и лежит моя идея реализации единого источника, только не сформулированная явно - Оберон (в перспективе - Активный) и должен быть языком ТФАП (лежащим в основе метаязыка РДП-документа)! Для этого и нужно соответствие исхчертежи-исхтекст - тогда Оберон-текст (с уточнениями, о которых ниже - т.к. не всё сводится к алгоритмам и программам) и является содержанием РДП-документа, а в РДП-редакторе просто визуализируется как граф-схемы.
На мой взгляд, для отражения семантики Оберона эти схемы образуют такую иерархию (снизу вверх):
    * дракон-схемы отдельных алгоритмов, отражающие структуру маршрутов для одной рабочей точки (потока исполнения) и деклар-схемы типов величин;
    * схема модулярной структуры программы - отражает её реализацию как изделия (я так понимаю, то что в UML представлено диаграммами реализации);
    * межпрограммная конструктивная схема, которую можно трактовать как метамодулярную, описывающую взаимодействие ряда потоков в общей задаче.
На первом уровне снова приходим к необходимости визуального (графового) деклар-языка. Для него и иконы нужно определять, и схемы.
С визуализацией модулярности вопрос вижу такой - определять ли её через вставки (полагая, что оператор MODULE - это такой особый случай/расширение PROCEDURE, естественно визуализируемого иконой Вставка) или ввести отдельную икону Модуль? Склоняюсь ко второму - всё-таки реализация нагружает деталями, нехарактерными для процедур. И схема модулей - это уже не обязательно дракон-схема.
Язык межпрограммных схем - это по сути то, что обсуждалось в этой теме - для визуализации независимых процессов. С чем-то в Обероне надо отождествить и икону Параллельный процесс.
Нужно квалифицированное рассмотрение - возможно, в чём-то эти рассуждения следует уточнить.

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

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

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

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

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

Вот такие соображения пока. Прошу критиковать.


Последний раз редактировалось Владислав Жаринов Пятница, 23 Июль, 2010 10:06, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 13 Июнь, 2010 00:44 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
Алгоритмы - это только небольшая составляющая структуры программной системы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Июнь, 2010 04:26 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков писал(а):
Алгоритмы - это только небольшая составляющая структуры программной системы.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Июнь, 2010 06:54 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1381
Общее замечание на тему гостов.
На госты (особенно в области построения ПО) надо ОЧЕНЬ аккуратно и с оглядкой смотреть, ссылаться и опираться.

Почему?

Описываю ситуацию. Ранее документация ПО проходила на манер ЕСКД. И общий ход работ старались вжать в тиски общих инженерных подходов. Ближайшей областью посчитали электронщиков. Вот оттуда и копировали "по аналогии".

Но - область ИТ кардинально отличается по организации работ и подходам.

Кроме того, анализируя ситуацию многих коллективов и фирм, в продукции которых стал "возникать" программный "момент", можно выделить определённую закономерность/эффект (если раньше никто в открытую это не описывал, я скромно назову его "эффектом Лося" :) ).

Что это такое?

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

Тоже самое и - с программированием. Как только в "изделиях" появляются составляющие, в которых работают программные компоненты - всё, производство ОБЯЗАНО перестроится под отдел проектирования ПО!
До эпохи применения ПО такими ведущими технологиями владела электроника. Но теперь и электронщики переходят в роль "обслуживающего" персонала.

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

то же самое отражают и госты (в большинстве своём).
Большинство гостов (особенно "закрытых") писались в те годы, когда опыта разработки НЕ БЫЛО. Как выходили из положения? а - очень просто! брали за основу интересующие моменты из "успешно внедрённых" проектов, просто поручая исполнителям этих проектов описать свои продукты с той или иной точки зрения.
Поэтому в этих гостах отражены не общие и базовые принципы для ВСЕГО ПО и процесса его производства, а - результаты работы отдельного коллектива (откуда ж им было брать обобщения и генеральные принципы вырабатывать? ;) )

В результате большинство "закрытых и ответственных тематик" выполняется, как кому "удобно" или "понятно", а в отчётах и документации упоминают о "соответствии ГОСТу ХХХХХ-ХХ"... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Июнь, 2010 07:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
Угу, именно так.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Июнь, 2010 07:55 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
Wlad2 писал(а):
Тоже самое и - с программированием. Как только в "изделиях" появляются составляющие, в которых работают программные компоненты - всё, производство ОБЯЗАНО перестроится под отдел проектирования ПО!
До эпохи применения ПО такими ведущими технологиями владела электроника. Но теперь и электронщики переходят в роль "обслуживающего" персонала.


Интересно отмечено.
Этого и надо ожидать, так как вся интеграционная роль, обеспечение системных связей и "системного эффекта" технического комплекса ложится на ПО.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Июнь, 2010 08:40 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3061
Откуда: Астрахань
У нас по крайней мере в 80-х было не так. Помнится писали ось под бортовую эвм. Наглядную разницу в отношении было видно по деньгам. С нами договор был тысяч на 800, а машина стоила 7 лимонов. Мы тогда написали на нее первый драйвер для дисплея и обработку прерывания от таймера и смеялись: будильник за 7 лимонов! Таймер на экране время показывал... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Июнь, 2010 16:48 

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

Почему?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Июнь, 2010 18:54 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1381
Илья Ермаков писал(а):
Wlad2 писал(а):
Тоже самое и - с программированием. Как только в "изделиях" появляются составляющие, в которых работают программные компоненты - всё, производство ОБЯЗАНО перестроится под отдел проектирования ПО!
До эпохи применения ПО такими ведущими технологиями владела электроника. Но теперь и электронщики переходят в роль "обслуживающего" персонала.

Интересно отмечено.
Этого и надо ожидать, так как вся интеграционная роль, обеспечение системных связей и "системного эффекта" технического комплекса ложится на ПО.

Конечно - интересно. Например ещё интересней, как стал разниться подход американский и наш к проектированию самолётов после появления Ф-22...
Американцы отвели "пятому поколению" ту же роль, что и пресловутой СОИ перед растаскиванием Союза. Пятого поколения НЕ будет.
Не понятно?
Повторяю. У американцев ПЯТОГО поколения, УПРАВЛЯЕМЫХ ЧЕЛОВЕКОМ БОЕВЫХ САМОЛЁТОВ, не будет.
Если Ф-22 начинал проектироваться классически - с планера и двигателя, то знаете, что было первым документом для Ф-35? Не поверите: Руководство по стилю кодирования на Си++ для коллективов разработчиков.
Первые блоки кода и архитектура программных систем для Ф-35 стали появляться и отлаживаться до картинки с эскизом и общей компоновки планера.
Ф-22 и Ф-35 - последние представители самолётов с человеком на борту.
Совокупность факторов показывает, что американцы к 2020 году выйдут на качественно новый уровень управления автономными группировками своих ВС, сама структура которых будет кардинально перестроена.
Сам факт удаления человека непосредственно с боевой платформы, с одновременным возрастанием её "вовлечённости" в каналы информационного обмена, кардинально изменяет даже принципы ценообразования и себестоимости вооружений и оценки факторов их боеэффективности.

Просто из-за того, что воплощать идеи в программных компонентах стали раньше, чем в чём-то материальном...

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

Характерный пример из моей практики:
поехали в Белорусь дисплеи покупать. В тамошнем КБ наше "старшее поколение" сразу кинулось к железкам - смотреть и щупать..., а ведь надо было смотреть на пацанов, которые за кадовскими пакетами сидели и на лету перепроектировали железки, обсчитывая тепловые потоки внутри изделия и распределение эм полей... И - ЗА ПЯТЬ МИНУТ - по сети, перестраивая программы всего парка станков с ЧПУ тремя этажами ниже. Одновременно были сгенерированы-запротоколированы исправленные версии конструкторской документации и оповещены программисты, с сообщением о возможной необходимости коррекции некоторых констант в их программах...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Август, 2010 16:41 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Wlad2 в viewtopic.php?p=48554#p48554 писал(а):
можно выделить определённую закономерность/эффект (если раньше никто в открытую это не описывал, я скромно назову его "эффектом Лося" ).

Что это такое?

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

Ну, это, пожалуй, проявление известного положения о перманентном приведении производственных отношений в соответствие с развитием производительных сил как факторе исторического процесса... видимо последнее на сегодня публичное напоминание о том, что справедливость этого фактора никак не связана с существованием советского строя :D, содержится в ACADEMIA-видеолекции С.П. Капицы по теории демографии...
Недавно попалась книжка, где этот вопрос ещё подробно рассматривался: Переслегин С.Б. Самоучитель по игре на мировой шахматной доске. - издана вроде в АСТ, 2007 год (тот самый Переслегин - комментатор творчества братьев Стругацких). Он берёт, в частности, пример из английской истории, когда "овцы поедали людей" (становление капитализма, район XV века), но не только - и напоминает, что эта "организация на поддержку передового" сопровождалась сильным негативом в развитии общества (вспомним, что как раз при переходе к капитализму в Англии были фактически отработаны основные элементы фашизма гитлеровского типа) - но не вдаётся в суть особо, делая вывод типа "это проявилась такая-то закономерность модели прогресса, и как-то иначе достичь результата вряд ли было возможно". Если поискать эту суть - похоже, что это связано с позитивистским подходом "модель работает - значит, она верна", о чём говорил Акимов в лекциях по конструктивизму в науке (см. [url=http://forum.oberoncore.ru/viewtopic.php?p=42569#p42569]вложение в это сообщение[/url). Кстати, и в связи с искусственным интеллектом сейчас делаются прогнозы неблагоприятные - пришлось читать в одной книжке российских авторов - там делается упор на сингулярность, но тот же Акимов в другой работе (Акимов О.Е. Естествознание: Курс лекций. - М.:ЮНИТИ-ДАНА, 2001) указывает, что с сингулярностью нужно обращаться аккуратно :) как и с диалектикой (не потому ли Председатель Мао решил её модифицировать в духе "единое неизменно раздваивается, но перемены следуют через сочетание не двух, а трёх сил"?)...
Между прочим, в работе Переслегина прослеживается закономерность, подмеченная в /Девятов, Мартиросьян, с. 386-388/ - игровая модель исторического процесса не м.б. сведена к шахматному "единству и борьбе противоположностей" - для читателя он даёт раскладку на "двоих дерущихся", но полностью к этому его рассуждения не сводятся, где-то можно подразумевать "третьего радующегося" :wink: . Похоже, он в целом позитивист-формалист - в то же время, скажем выдвигает принцип физического моделирования любых процессов (на примере сталинских "шарашек", ЖЦ которых он представляет моделью термодинамического цикла турбодетандера) - что перекликается с предложением Акимова (вроде как конструктивиста) о сведении представления процессов более высоких уровней движения материи через физические.


Wlad2 в viewtopic.php?p=48572#p48572 писал(а):
Сам факт удаления человека непосредственно с боевой платформы, с одновременным возрастанием её "вовлечённости" в каналы информационного обмена, кардинально изменяет даже принципы ценообразования и себестоимости вооружений и оценки факторов их боеэффективности.

Как раз об этих принципах читал в /Девятов, Мартиросьян, с. 200-203/ :) подоплёка именно экономическая - выправить перекосы развития, "поиграв мускулами" с высокими затратами. Сохранит ли боевая платформа вовлечённость в каналы удалённого управления в реальности же - зависит и от силы и эффективности противодействия противника... Это как раз к уточнению содержания "эффекта Лося" (или Переслегина? :wink:) с учётом экономического базиса.

Wlad2 в viewtopic.php?p=48572#p48572 писал(а):
поехали в Белорусь дисплеи покупать. В тамошнем КБ наше "старшее поколение" сразу кинулось к железкам - смотреть и щупать..., а ведь надо было смотреть на пацанов, которые за кадовскими пакетами сидели и на лету перепроектировали железки,...

Да, на пацанов стоит смотреть :lol: ... и именно на условия, в которых они создают что-то для тебя - как производственные, так и жизненные. Олег Табаков хорошо сказал в своё время (принимая МХТ имени Чехова известно в каком состоянии после "академизма" и последующего "реформаторства") примерно так: "В театре всё должно быть в порядке, начиная с того, что запах в туалете должен быть человеческим" :)
А вот пример с Саяно-Шушенской ГЭС - чтобы ликвидировать последствия того, что вода из водоводов пойдёт "не туда", были запроектированы затворы, но не внизу (в машзале) а наверху (в местах выхода водоводов из плотины), что физически верно - это место, где потенциальная энергия только начинает переходить в кинетическую :) Однако удаление от машзала составляет 245 метров в высоту, а дистанционного управления по проекту не было - кто-то из машзала д.б. подниматься к затворам (!). Естественно, при переходе к "приберально-лихватизационной" экономике никто это управление не реализовал - ведь надо быть "конкурентоспособным", т.е. сиюминутно-локально-эффективным. По проекту на подъём отводилось более 2 часов - и только потому, что кто-то сумел вырваться из затопляемого помещения и подняться за 1ч 40мин, удалось избежать затопления нижележащих поселений... но не спасти работников и станцию. Сейчас при восстановлении станции делают это управление - и только в связи с этим глухо упомянули, что раньше его не было...
Было в дореволюционной истории такое событие - "Ленский расстрел" 1912 года. Там тоже "эффективный собственник" "Лензолтоварищество" экономил на условиях труда и быта (ну и старался любым путём извлечь больше денег из кармана рабочих - активное штрафование, "карманные" магазины и пр.). Что из этого вышло - можно почитать в учебниках истории, я отмечу лишь итог - оно послужило толчком к усилению рабочего движения, а поскольку другие "эффективные собственники" в массе своей нужных выводов не сделали - то и к экстремизации его (и причины, и ход следствия, и последующее поведение хозяев - всё служило к облегчению убеждения работников, что им и правда "нечего терять, кроме своих цепей").

Почему я это вспомнил? Это примеры того, как действия собственника средств производства в своих частных интересах привели в т.ч. к понижению "гарантоспособности совокупного работника", как это называется в /Паронджанов, 2001, Гл.18/. Надо полагать, "в тамошнем КБ" (как и "тремя этажами ниже") всё приемлемо не только в плане производственного оснащения и освоения передовой технологии... иначе о стабильно высоком качестве продукции и сервиса на сколько-нибудь значительном промежутке времени можно и не думать... в общем, оценивая организационную культуру, начинаем с посещения туалета (естественно, не "для руководства")... :wink:
Возможен (и практически часто возникает) и другой сценарий развития событий - гарантоспособность при недостаточно приемлемых условиях работы поддерживается за счёт замены людей на свежих... но тем самым организация становится в терминах современного бизнеса "генератором центров затрат" для общества, которое либо платит по этим счетам из ОФП (что худо-бедно происходит в "цивилизованных" обществах), либо не платит и сталкивается с тем, что они всё равно "предъявляются к оплате" самым разным образом.


Wlad2 в viewtopic.php?p=48554#p48554 писал(а):
Большинство гостов (особенно "закрытых") писались в те годы, когда опыта разработки НЕ БЫЛО. Как выходили из положения? а - очень просто! брали за основу интересующие моменты из "успешно внедрённых" проектов, просто поручая исполнителям этих проектов описать свои продукты с той или иной точки зрения.
Поэтому в этих гостах отражены не общие и базовые принципы для ВСЕГО ПО и процесса его производства, а - результаты работы отдельного коллектива (откуда ж им было брать обобщения и генеральные принципы вырабатывать?

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


Последний раз редактировалось Владислав Жаринов Понедельник, 30 Август, 2010 05:04, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Август, 2010 16:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
Драконограф писал(а):
Между прочим, в работе Переслегина прослеживается закономерность, подмеченная в /Девятов, Мартиросьян, с. 386-388/ - игровая модель исторического процесса не м.б. сведена к шахматному "единству и борьбе противоположностей" - для читателя он даёт раскладку на "двоих дерущихся", но полностью к этому его рассуждения не сводятся, где-то можно подразумевать "третьего радующегося" :wink: . Похоже, он в целом позитивист-формалист - в то же время, скажем выдвигает принцип физического моделирования любых процессов (на примере сталинских "шарашек", ЖЦ которых он представляет моделью термодинамического цикла турбодетандера) - что перекликается с предложением Акимова (вроде как конструктивиста) о сведении представления процессов более высоких уровней движения материи через физические.


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


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8170
Откуда: Троицк, Москва
Соглашусь насчёт сортиров.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Август, 2010 03:49 

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Август, 2010 09:10 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9134
Откуда: Россия, Орёл
Драконограф писал(а):
Авторы имели в виду, я так понимаю, что когда рассматриваем систему, включающую людей - люди и являются носителями противоположностей (в ситуации "поляризации" идеалов и интересов).


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 30 Август, 2010 04:42 

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


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


В принципе да наверное - люди становятся на стороны объективно определившиеся - недаром китайцы создали Канон перемен и ввели "циклы развития", устанавливающие общую динамику возможностей, как они их представляют...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 30 Август, 2010 05:00 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Info21 писал(а):
Соглашусь насчёт сортиров.

Ага :D разумеется, с этого только начинается... тут попалась под руку статья о том, какова м.б. оргкультура... хотел сказать "в идеале", но речь-то идёт о реальном предприятии...
Вложение:
Комментарий к файлу: Обзор и анализ оргкультуры компании SAS и её развития в условиях кризиса
Голубицкий-ВПолеВоинОдин-ст(БЖ4_10).djvu [320.57 КБ]
Скачиваний: 257

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


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

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


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

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


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

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