На чем пишется софт для КА?

[TAU]

С Яковом Абрамовичем?

Яковом Анатольевичем, вообще-то. И Анатолием Владимировичем.

[TAU]

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

Заранее Спасибо!

Вам уже ответили ;-)

Если БВС используется для решения задач управления БА, и почти не используется для вычислений - то вполне хватает скромных показателей.

Если требуется, скажем, обрабатывать на борту предварительно изображения - то, как Вы понимаете, ресурсы нужны совсем другие.
Впрочем, это может быть и отдельная ЭВМ.

[TAU]

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

например?

Графическое программирование в системе ГРАФИТ-ФЛОКС

А, вы про это

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

Очень спорное утверждение, что это современное средство разработки. Лично я бы никогда не стал на ней работать - элементарно неудобно

Мне кажется, это просто Ваше субъективное мнение. Именно что удобно. Смотря для чего, конечно. Для понимания логической структуры алгоритма - очень даже то. А это и нужно при создании управляющих алгоритмов реального времени для КА.

Судите сами http://store.oberoncore.ru/lib/image/drakon/list1.png

Вы полагаете, я этого не видел?

эта программа сделанная в "современном средстве разработки" (которая заняла бы несколько десятков строк на обычном ЯП), нарисована на формате A1, и в углу основная надпись по ГОСТу

Что Вас "умиляет"? Надпись по ГОСТу? Смешно? Знаете поговорку "смех без причины"? Вы представляете хоть немного, каков уровень требований к документации на КА, сколько там формальностей, подписей и согласований? И если, не дай Бог, что-то там не так, за этот документо кто-то несет личную ответственность - и, соответственно, "подписывается кровью", в том числе - в той самой надписи по ГОСТу.

Да, наверное можно обучится за несколько дней "кодить" на Драконе, но очень сомневаюсь, что кто-то возьмется на ней делать что-то реально сложное и большое

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

кроме разве что автора и нескольких закоренелых энтузиастов

Уже нашлось достаточно значимое количество таких "энтузиастов", не знаю, можно ли корректно называть его "несколькими".

не применяется в "коммерческом мэйнстриме" всего лишь показывает, что реально это никому не нужно

Данное утверждение не соответствует действительности - ГРАФИТ-ФЛОКС успешно применяется, и достаточно давно. Кстати, существует и используется еще целый набор графических языков стандарта МЭК по программированию промышленных контроллеров, и поддерживающих их средств, например, ISA GRAF.
Так что - нужно.
Кстати, мера успеха в "коммерческом мэйнстриме" - некорректная мера для сравнения качества/эффективности технологии или продукта.

[jettero]

эта программа сделанная в "современном средстве разработки" (которая заняла бы несколько десятков строк на обычном ЯП), нарисована на формате A1, и в углу основная надпись по ГОСТу

Что Вас "умиляет"? Надпись по ГОСТу? Смешно? Знаете поговорку "смех без причины"? Вы представляете хоть немного, каков уровень требований к документации на КА, сколько там формальностей, подписей и согласований? И если, не дай Бог, что-то там не так, за этот документо кто-то несет личную ответственность - и, соответственно, "подписывается кровью", в том числе - в той самой надписи по ГОСТу.

То есть вы хотите сказать, что программу надо печатать на листах А1 и потом эти десятки тысяч листов (а скорее сотни тысяч, так как на А1 там мало что помещается, всего-то 20-30 строк на обычном ЯП) визировать подписью и хранить в архиве? И вы всерьез это называете "современным средством разработки"? Ну ваше право конечно...
А почему тогда не на перфокартах? ))))

Только я разделяю мнение тех кто удалил из википедии Дракон за незначимостью - я не вижу ничего отличного в нем от обычных блоксхем, а это "технология" 70-80 годов.
А то, что это где-то применяется совсем не показатель - у нас и гравицапы летают в космос и что?

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

[Not]

То есть вы хотите сказать, что программу надо печатать на листах А1 и потом эти тысячи листов визировать подписью и хранить в архиве? И вы всерьез это называете "современным средством разработки"? Ну ваше право конечно...
А почему тогда не на перфокартах? ))))

Вы бы, батенька, прежде чем за животик хвататься, задумались - а зачем это все нужно?

Вам такая процедура, как просмотр и визирование кода знакома?

[jettero]

То есть вы хотите сказать, что программу надо печатать на листах А1 и потом эти тысячи листов визировать подписью и хранить в архиве? И вы всерьез это называете "современным средством разработки"? Ну ваше право конечно...
А почему тогда не на перфокартах? ))))

Вы бы, батенька, прежде чем за животик хвататься, задумались - а зачем это все нужно?

Вам такая процедура, как просмотр и визирование кода знакома?

Вы путаете теплое с мягким, причем тут бумажный vs. электронный документооборот и визирование кода?
Подумайте сами, просмотреть код с 1000 строками на экране это обычное дело – требуется полчаса - час.
Просмотреть 50 чертежей А1 – сплю и вижу, нафиг-нафиг

[TAU]

То есть вы хотите сказать, что программу надо печатать на листах А1 и потом эти тысячи листов визировать подписью и хранить в архиве? И вы всерьез это называете "современным средством разработки"? Ну ваше право конечно...
А почему тогда не на перфокартах? ))))

Вы бы, батенька, прежде чем за животик хвататься, задумались - а зачем это все нужно?

Вам такая процедура, как просмотр и визирование кода знакома?

Вы путаете теплое с мягким, причем тут бумажный / электронный документооборот и визирование кода?

Не переживайте, есть там и электронный документооборот.

Я не недооцениваю значение коммерческого мэйнстрима. Но и не переоцениваю. Смотрю трезво   И кстати.

Если спутник успешно продается - за немаленькие суммы - значит, он коммерчески успешен. Со всеми своими "потрохами". В том числе - со своим БПО. Таким образом, уместно говорить про "коммерческую успешность" технологии его создания. Если спутники эти делаются серийно - то, не исключено, что и о своего рода "мэйнстриме". Так сказать, "широкой известности в узких кругах".

[Not]

То есть вы хотите сказать, что программу надо печатать на листах А1 и потом эти тысячи листов визировать подписью и хранить в архиве? И вы всерьез это называете "современным средством разработки"? Ну ваше право конечно...
А почему тогда не на перфокартах? ))))

Вы бы, батенька, прежде чем за животик хвататься, задумались - а зачем это все нужно?

Вам такая процедура, как просмотр и визирование кода знакома?

Вы путаете теплое с мягким, причем тут бумажный / электронный документооборот и визирование кода?

То есть хранение тех же самых диаграмм в электронном виде сделает вас счастливее?   Подсказываю еще раз - задумайтесь, зачем нужны диаграммы и будет вам просветление  

[jettero]

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

Я же сказал свое мнение – это не нужно, мне не надо заменять 20 строк кода чертежами на А1.
Вы кстати слышали про системы типа Javadoc, Doxygen итп? Где в том числе автоматически генерируются диаграммы наследования / зависимостей итд? Таких диаграмм вполне достаточно, а все что ниже по уровню – избыточно. Лучше текстового кода пока-что ничего не придумали.

[Not]

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

Я же сказал свое мнение - это не нужно, мне не надо заменять 20 строк кода чертежами на А1.
Вы кстати слышали про системы типа Javadoc например?  Таких диаграмм вполне достаточно, а все что ниже по уровню – избыточно. Лучше текстового кода пока-что ничего не придумали.

Слышал, слышал   И про javadoc и про doxygen. И более того, успешно применяю.

Где в том числе автоматически генерируются диаграммы наследования / зависимостей итп?

А вот про итп - поподробнее   Что кроме диаграмм наследования и зависимостей вам может сгенерировать javadoc и как это коррелирует с той диаграммой, которую вы упомянули ранее?

[jettero]

Слышал, слышал   И про javadoc и про doxygen. И более того, успешно применяю.

про doxygen только-что дописал выше )

Где в том числе автоматически генерируются диаграммы наследования / зависимостей итп?

А вот про итп - поподробнее   Что кроме диаграмм наследования и зависимостей вам может сгенерировать javadoc и как это коррелирует с той диаграммой, которую вы упомянули ранее?

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

[TAU]

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

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

Кстати, и программисты некоторые вполне даже выступают за графическую нотацию, не говорите за всех

[Not]

Слышал, слышал   И про javadoc и про doxygen. И более того, успешно применяю.

про doxygen только-что дописал выше )

Где в том числе автоматически генерируются диаграммы наследования / зависимостей итп?

А вот про итп - поподробнее   Что кроме диаграмм наследования и зависимостей вам может сгенерировать javadoc и как это коррелирует с той диаграммой, которую вы упомянули ранее?

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

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

[jettero]

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

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

Кстати, и программисты некоторые вполне даже выступают за графическую нотацию, не говорите за всех

Как я уже писал может непрограммист и обучится быстрее как записывать элементарные операции, но сложность написания больших системы не в том, что сложно писать элементарные операции.

[jettero]

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

А при чем тут диаграммы состояний?
Началось с обсуждения диаграмм языка Дракон, где графически записывается поток команд, а не состояния. Мой тезис, что это не нужно и код для потока команд подходит лучше.
Другие диаграммы, могут быть полезны, как например я писал про диаграммы наследований в doxygen.
Состояния это другая тема, их кстати тоже можно вполне наглядно записывать булевой алгеброй, а не диаграммами, как делается в конечных автоматах например.

[TAU]

Как я уже писал может непрограммист и обучится быстрее как записывать элементарные операции, но сложность написания больших системы не в том, что сложно писать элементарные операции

Яснее пишите.

[TAU]

А при чем тут диаграммы состояний?
Началось с обсуждения диаграмм языка Дракон, где графически записывается поток команд, а не состояния

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

Мой тезис, что это не нужно и код для потока команд подходит лучше

Тезис неверен. Т.е. некорректен для общего случая.

Состояния это другая тема, их кстати тоже можно вполне наглядно записывать булевой алгеброй, а не диаграммами, как делается в конечных автоматах например

Неверно снова. Диаграммы - наглядны, формулы наоборот.

[Сергиенко Роман]

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

[jettero]

Да, как я писал, блоксхемы бывают полезны, в том числе при обучении. На блоксхемах бывает удобно показать взаимосвзяь больших участков кода. Но когда ими пытаются программировать – то есть записывать каждую элементарную операцию, то при реализации сложных алгоритмов получают клубок линий и нулевую читаемость – гораздо проще прочесть название вызываемой процедуры или метода чем следить по линиям что куда идет, когда таких линий 5 штук - все ок, а когда их сотни это дурдом.
Факт в том, что 99% программистов программируют кодом, а не рисуют и для этого есть причины. И причина вовсе не в том, что производители КА прогрессивнее, чем коммерческий мейнстрим

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

Кстати самый известный алгоритмист – Дональд Кнут писал алгоритмы на MIX/МMIX ассемблере – язык, который он создал специально для обучения алгоритмам в своей серии книг Искусство программирования и он в предисловии писал почему он решил так, а не использовал языки выокого уровня или блоксхемы.

[Сергиенко Роман]

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

P.S. Современные графические нотации типа UML - это не просто блок-схемы. Их функционал гораздо шире.