Проектирование на нескольких языках

Программные микропроцессорные ядра 81 Профаммные СИС 89 Проектирование блочное 215 Проектирование на нескольких языках 148 Проектирование на языке С/С++ 164 Произведение 41 [c.404]

Модульный принцип построения ППП (модульное программирование) имеет ряд преимуществ параллельная работа нескольких программистов над большой программой упрощение сегментации, проектирования, изменения и тестирования больших программ создание и широкое использование библиотек наиболее употребительных модулей. Основная трудность реализации модульного программирования связана с отсутствием четких правил вычленения модулей и их сопряжения. Эта задача обычно решается на основе инженерного анализа ПП. Другая трудность — объединение модулей, написанных на разных языках. В этом случае необходимо создавать дополнительные связывающие (интерфейсные) модули, написанные на АССЕМБЛЕРе. [c.151]

Поэтому Eie случайно, что последние годы к проблеме надежности приковано внимание больших коллективов ученых и инженеров. В ряде промышленно-развитых стран в государственных масштабах созданы специальные службы надежности. Опубликовано огромное количество работ, посвященных вопросам надежности. Вместе с развитием теории и накоплением практического опыта в области надежности, ростом количества публикаций и специалистов, заинтересованных в непосредственном использовании достижений в указанной области, постоянно возникает необходимость в монографиях, обобщающих и систематизирующих результаты (в достаточно компактном виде). Если несколько лет назад существовал пробел в монографической литературе по надежности, то в настоящее время положение существенно изменилось. На русском языке нет теперь острого недостатка в подобных монографиях, способных удовлетворить интересы специалистов различных профилей и уровней. Издательство Советское радио начиная с 1966 г. выпускает специальную библиотеку инженера по надежности. Оц-нако все еще мало работ, посвященных практическим методам обеспечения надежности при проектировании, производстве ц эксплуатации, методам испытаний и отработки с.хем и конструкций. Важнейшей задачей является также издание учебных пособий, поскольку самостоятельные курсы надежности постепенно прочно внедряются в программы высшей школы и факультетов усовершенствования, и справочников, необходимых широкому кругу специалистов в их повседневной практической работе. [c.6]

Цель первого издания книги — убедить инженеров в необходимости при проектировании учитывать человеческие факторы, а не принимать их во внимание лишь в конце работы. Чтобы конструкция была удобной, она должна создаваться с учетом физических и психофизиологических возможностей человека. Необходимая информация представлена в простой и наглядной форме. Издание оказалось удачным, оно выдержало несколько тиражей, было переведено на многие языки стран Европы и Азии. [c.256]

При проектировании интерпретатора входного языка требуется решение нескольких вопросов. Они могут быть разбиты на 3 группы проектирование диспетчера, составление правил компиляции таблиц, ввод данных в программу. [c.354]

Различают несколько типов ППП в зависимости от состава пакета. Пакеты прикладных программ простой структуры характеризуются наличием только обрабатывающей части — набора функциональных программ, каждая из которых предназначена для выполнения некоторой проектной операции или процедуры. Объединение нужных программ для реализации маршрутов проектирования происходит средствами операционной системы ЭВМ или мониторной системы САПР на основе соответствующего языка управления заданиями. Совместное исполнение этих программ определяется возможностями организации их информационного интерфейса. В ППП простой структуры организация информационного интерфейса в значительной мере возлагается на пользователя. Такие пакеты просты в разработке, но неразвитость средств управления, информационного интерфейса и отсутствие удобного лингвистического обеспечения ограничивают их возможности. Они применяются лишь на маршрутах проектирования, на которых последовательно выполняемые операции достаточно автономны, информационные связи программ между собой и с пользователем достаточно слабые. [c.283]

Первая группа объединяет элементы, конфигурация и возможная ориентация которых в процессе проектирования такова, что графика проекций данных элементов на сборочном чертеже очевидна на стадии разработки программ типовых изображений. В связи с этим графическая интерпретация элементов производится с помощью типовых изображений, графика которых постоянна или может принимать несколько разновидностей. Эти типовые изображения называют изображениями с детерминированной графикой. Описание данных типовых изображений производится на формализованном языке математического обеспечения чертежно-графического автомата. [c.328]

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

Запись математических моделей на языке ЭВМ выполняется в несколько этапов. Сначала модель-описание представляется в форме алгоритма, т. е. упорядоченной последовательности действий, приводящих к требуемому результату в рамках заданных ограничений на систему входных данных. Наиболее удобной формой представления алгоритмов для инженерных задач принято считать блок-схему. На основании блок-схемы и тестовых задач составляется и отлаживается машинная программа. Готовая программа включается в состав библиотеки ЭВМ и системы автоматизированного проектирования. [c.68]

Весь последующий процесс проектирования внутри системы выполняется только на внутреннем ее языке и формально представляет процесс анализа и преобразования только цифровой информации, что вызывает специфические трудности при алгоритмическом описании различных процессов проектирования, особенно связанных с решением многочисленных геометрических задач. В особо трудных случаях целесообразно и экономически выгоднее поручить решение таких задач человеку (эстетическая оценка конструкций, принятие принципиальных решений на основе сравнения нескольких вариантов конструкций, процессы обобщения полученных результатов и т. п.). При этом человек становится одним из необходимых элементов автоматизированной системы, а информация, необходимая ему для визуальной оценки, преобразуется с внутреннего языка [c.18]

В самом начале проектирования входного языка следует определить количество различных включенных устройств ввода. Для некоторых языков предполагается подключение нескольких устройств ввода. Например, для определения графических данных применяется кодирующий планшет, для часто используемых слов — функциональные ключи, а для остальных слов строки текста набираются на клавиатуре вводного устройства и т. д. В других языках ис- [c.341]

Автоматическое проектирование означает тесное взаимодействие человека с ЭВМ на основе использования дисплеев, телетайпных пультов, специальных языков программирования и других средств диалога человека с машиной. Человек получает возможность беседовать с ЭВМ. Такой двусторонний разговор может происходить при наличии чертежа или схемы, как показано на рис. 1. Например, проектировщик может с помощью светового пера сформировать изображение на экране дисплея. Можно составить такие программы, чтобы ЭВМ в течение нескольких секунд поняла изображение, выполнила некоторые связанные с ним вычисления и представила человеку либо результаты, либо уже скорректированное изображение. После этого проектировщик может по желанию или удовлетвориться полученными данными, или продолжить процесс внесения изменений. [c.7]

Целью разработок было создание методов моделирования, анализа и проектирования систем управления с использованием интерактивных средств современных ЭВМ для широкого круга пользователей инженеров, научных работников, студентов [12]. В 1970 г., когда начинались эти работы, у нас был накоплен опыт в аналоговом моделировании, опыт в программировании, отладке и использовании программ в интерактивном режиме на языках ФОРТРАН, БЕЙСИК и АПЛ. Мы понимали преимущество человеко-машинного взаимодействия при аналоговом моделировании и возможности цифровых вычислений на мощных ЭВМ. Программное обеспечение (ПО) было разработано при тесном сотрудничестве с пользователями была разработана структура ПО, основные идеи которой были обсуждены на семинарах. Несколько пользователей проверили разработанное ПО средних размеров, после чего оно было модифицировано и доработано, хотя на начальной стадии разработки у нас неоднократно возникало желание начать все с начала. По мере развития работы мы начали лучше понимать, что и как должно быть сделано, что необходимо развивать универсальные программы. Такие пакеты были разработаны, они претерпели много изменений и к 1979 г. достигли законченного состояния, характеризующегося переносимостью, модульностью и эффективностью. С тех пор в пакеты вносились только незначительные изменения, а число пользователей этих пакетов быстро увеличивалось. [c.12]

Многие современные интерактивные пакеты являются командно-управляемыми в том смысле, что пользователь задает порядок действий с помощью часто довольно сложного командного языка. По сравнению с другими способами, например управлением с помощью диалога вопрос/ответ или с помощью меню, командный интерфейс является более быстрым, обеспечивает пользователю большую гибкость и лучше подходит для решения задач алгоритмического типа, встречающихся в теории управления. Однако любой разработчик такого командного языка должен идти на определенный компромисс если язык достаточно развит, сложность системы затрудняет его использование. С другой стороны, если в него включены всего несколько языковых элементов, система будет не в состоянии обеспечить пользователю возможность решения любых задач. В этом разделе речь пойдет о необходимости использования для автоматизированного проектирования систем управления сильно структурированного командного языка, конструкции которого в то же время были бы понятны неопытным пользователям. [c.143]

Упрощение и ускорение программирования с позиций КП, составляющего исходное описание задачи на языке проектирования, достигается повышением уровня этого языка. На рис. 11.4 представлено несколько уровней информационного интерфейса пользователя с вычислительной системой. На нижнем уровне в распоряжение пользователя предоставляется только аппаратная часть ВС и интерфейс должен осуществляться на машинном языке. Аппаратная часть, дополненная ассемблером, представляется пользователю как виртуальная ЭВМ уровня А, с которой можно обмениваться информацией на языке ассемблера. Включение в ВС трансляторов с языков типа ФОРТРАН, ПЛ/1, ПАСКАЛЬ и т. п. образует для пользователя виртуальную ЭВМ уровня В. Но для КП в САПР описание задач проектирования на этих языках приводит к чрезмерным затратам времени и в большинстве случаев недопустимо, Поэтому в существующих САПР реализуются ПМК с проблемно-ориентированными языками. Это могут быть процедурные языки, такие, как язык имитационного моделирования GPSS [c.307]

Рассмотренные выше передовые методы разработки ПО (Н1Р0 — технология, нисходящее проектирование, структурное ирограммирование, нисходящее тестирование, бригада главного црограммиста) были исиользованы фирмой ШМ для создания программной системы объемом свыше 80 тыс. операторов языка программирования, при этом была достигнута производительность труда G5 операторов/деиь па каждого программиста и 35 операторов/день на каждого члена бригады. Если учесть, что бригада возглавлялась программистом чрезвычайно высокой квалификации, а проект поддерживался фирмой с колоссальными возможностями, то можно предположить, что эти показатели близки к предельным. Однако темпы выпуска ЭВМ во всем мире продолжают расти (так, в США в настоящее время количество ежегодно выпускаемых ЭВМ превышает количество студентов, оканчивающих вузы), усиливаются потребности общества в системах ПО. Многие специалисты по электронной обработке данных связывают возможность разрешения этого противоречия с созданием и широким использованием генераторов прикладных программ. Например, такие интерактивные генераторы, как ADF и DMS, позволяют на несколько порядков повысить производительность труда программистов при разработке диалоговых прикладных программ для решения экономических задач. Практически для создания прикладного пакета требуется всего лишь несколько сеансов совместной работы системного аналитика и будущего пользователя за экраном дисплея, во время которых главным об- [c.49]

Рассмотрим условия, при которых проектировщики широко используют машину для математического эксперимента на примере проектирования радиотехнических устройств. Небольшой группой математиков, инженеров-математиков и программистов разработан метод анализа радиотехнических цепей, простой входной язык для описания этих цепей и комплекс программ, реализующий предложенный метод и обеспечивающий транляцию с входного языка. Время для описания различных схем на входном языке колеблется от нескольких часов до нескольких дней в зависимости от сложности схемы. Так, например, описание приемного устройства занимает 2—4 дня. В зависимости от исследуемого вопроса информация обрабатывается определенной. последовательностью программ. Изменяя параметры схемы или применяя другую схему, проектировщик добивается желательных результатов и лищь после этого приступает к макетированию. Проведенные эксперименты на ЦВМ Урал-2 дали вполне удовлетворительные результаты. Однако, несоверщенство современных цифровых вычислительных машин (ограничения по скорости и оперативной памяти) не позволяет дать в распоряжение проектировщика производительный и удобный инструмент для постановки математического эксперимента (полный статистический анализ схемы ШАРУ занимает на Урал-2 250—300 часов машинного времени). [c.165]

Наиболее сложной является предварительная разработка алгоритма технологического проектирования и составление программы. работы машины. Алгоритм —это система операций, выполняемых в определенном порядке для решения поставленной задачи. Алгоритмы подразделяют на математические и эвристические. Первые обоснованы на достаточно точных законах, вторые на наблюдениях, опытах, статистических данных. Программа — это описание алгоритма на определенном языке (содержательном, математических выражений, фюрмальном, машинном). По программе в ЭВМ реализуется принятый алгоритм путем выполнения в определенной последовательности арифметических и логических операций, задаваемых набором команд. Программы перед вводом в ЭВМ кодируются на языке машины и записываются на перфоленте. Используются языки Ассемблер , Алгамс , Кабол Алгол-60 , Фортран п др. После кодирования программа представляет собой совокупность команд, преобразуемых в ЭВМ в управляющие сигналы. Перед началом работы программа отлаживается и контролируется. Ошибки в программе не допускаются. Алгоритм и программа могут разрабатываться для специального и типового случаев проектирования. В последнем случае по единой программе решаются задачи, сходные по структуре и последовательности выполнения этапов (проектирование технологии изготовления типовых деталей разных размеров). При решении задач такого типа в ЭВМ каждый раз вводятся исходные данные и ограничивающие условия. Весь комплекс работ по составлению программы отнимает много времени (в сложных случаях до двух недель). Поэтому широко применяется автоматическое программирование, представляющее собой перевод программы в содержательных обозначениях в машинные коды. Автоматическое программирование сокращает время до нескольких десятков минут. Основные этапы автоматизированного проектирования технологии на ЭВМ приведены на рис. 173, а (штриховой линией показаны этапы, выполняемые технологом). [c.385]

Прагматика оператора ЕХЕС для ОС ЕС определяется только как средство запуска пакета (безразлично какого). В комплексной САПР прагматика средств запуска иная. Смысл текста оператора ЕХЕС заключается в том, чтобы определить, какой именно пакет долл ен быть запущен для решения определенной задачи. Существует отображение множества проектных задач во множество прикладных пакетов, а для множества прикладных пакетов — во множество средств их запуска (различных предложений с оператором ЕХЕС и именем каталогизированной процедуры запуска). Аналогичное происходит и с семантикой входной информации для пакета в комплексной САПР из общего текста задания на проектирование выбирается только тот текст, который предназначен для данного пакета (ил г производится его перекодирование в текст на входном языке данного пакета). При сквозном проектировании с участием нескольких пакетов из данных, полученных на предыдущих шагах, нужно выбрать данные, которые необходимы для очередного шага, и сформулировать задание для него в терминах входного языка применяемого (выбранного) пакета. [c.54]

А. Юдицкого , А. Д. Чудакова и др. [60], в которых даны рекомендации по проектированию пневматических систем управления и записи условий их работы на различных формальных языках. Структурному синтезу машины с несколькими приводами посвящена работа В. П. Зенченко, которая может быть использована для любых дискретных систем. Наиболее полно представлены на IV и V Совещаниях работы по проблемам динамики. М. А. Мамонтов [46] исследовал возможность применения при анализе и синтезе пневматических систем разработанной им теории аналогичностей. Основы методов анализа и синтеза, созданные различными исследователями, изложены в работе [18]. [c.171]

В процессе постепенного развития методов машинной графики у разработчиков графических систем несколько раз менялась направленность их работы. Вначале разработчики добивались в основном характеристик, при которых система могла бы выполнять полезную работу. Такое положение было достигнуто в середине 60-х годов, когда в автомобильной и авиационной отраслях промышленности началось использование нескольких больших и дорогостоящих графических систем для проектирования с применением ЭВМ [41, 127]. Когда на этих системах была показана целесообразность использования машинной графики, появилось стремление к снижению стоимости графических систем. Значительные силы были вложены в разработку операционных систем, чтобы обеспечить возможность использования дисплеев в качестве терминалов в системах с разделением времени это привело к разработке некоторых достаточно интересных сат.гллитных графических систем [44, 58]. Однако до этого времени графические системы оставались довольно сложными, поэтому для составления прикладных программ требовались квалифицированные программисты. Очевидные недостатки такой ситуации привели к появлению более простых и менее дорогих дисплейных терминалов, а также, что очень важно, более удобных языков для программирования графики. [c.21]

Две последние статьи описывают экспериментальные программы. Одна из них—расчет профиля крыла—представляет собой попытку решения небольшой задачи, затраты на которую можно оценить одним человеко-годом. Эта программа интересна в двух отношениях. Во-первых, она служит прекрасной иллюстрацией эффективного сотрудничества человека с машиной в. процессе поиска оптимального проекта методом проб и ошибок. В этом отношении описанная работа является классической. Во-вторых, она объединяет отдельные программы проектирования, которые были запрограммированы и отлажены отдельно, а затем собраны в общую систему. Система работала на языке ФОРТРАН в режиме разделения времени с дистанционных телетайпных пультов на ЭВМ IBM-360/50. Вывод изображения на терминалах осуществлялся в автономном режиме с помощью графических программ фирмы al omp. После того как отладка и проверка системы полностью закончились, в течение нескольких недель эту программу удалось запустить в графической системе D -3300 в режиме взаимодействия человек — машина. Только из-за того, что при околозвуковых скоростях полета прямая форма крыла не подходила, эта программа не получила промышленного применения. Она явилась, однако, осно- [c.176]

Энциклопедия по машиностроению XXL

Оборудование, материаловедение, механика и ...