Cтраница 2
Вторым компонентом, который необходим для разработки приложения, является программный код, описывающий реакцию имеющихся на экране объектов и элементов управления на различные события, которые могут происходить в ходе выполнения программы. Реакция на событие описывается в виде соответствующей подпрограммы, входящей в основной программный модуль. Подобно заготовкам для экранных объектов, текстовое окно, содержащее исходный код программы, также имеет заготовки для подпрограмм. В частности, по правилам языка Object Pascal каждая подпрограмма должна иметь заголовок, начинающийся со служебного слова procedure, в начале основной части подпрограммы должно содержаться служебное слово begin, a завершаться она должна служебным словом end, после которого ставится точка с запятой. [16]
Следующей вспомогательной функцией является согласование параметров перечней исходных данных и параметров перечней результатов вычислений модулей программной модели по форме представления и единицам измерения с их общесистемным представлением. Формы представления и единицы измерения, используемые в системе в целом, могут отличаться от потребностей отдельных программных модулей. Поэтому перед началом выполнения функций основных программных модулей необходимо осуществить соответствующее согласование. [17]
Рассмотрим основные элементы, из которых формируется программная модель. Их состав определяется целью построения программной модели. Основными элементами программной модели являются следующие: основные программные модули, вспомогательные программные модули, основные информационные модули и вспомогательные информационные модули. Общим для всех этих элементов является принадлежность к одной и той же категории - категории модулей. Это означает, что при хранении модуля в различных видах памяти технических средств автоматизации он размещается там как поименованное множество, для обращения к которому достаточно указания его имени. Основные достоинства модульного представления были указаны в гл. Эти достоинства в полной мере сохраняются и для программной модели. [18]
На современном этапе развития радиотехники чрезвычайно возросла роль ЭВМ, эффективно выполняющих сложные и трудоемкие вычислительные операции. Здесь в качестве примеров приводятся две реальные подпрограммы на алгоритмическом языке ФОРТРАН, иллюстрирующие применение ЭВМ для расчета характеристик радиотехнических цепей с распределенными параметрами. Все приводимые подпрограммы оформлены как программные единицы типа SUBROUTINE; связь между ними и основным программным модулем осуществляется посредством формальных параметров, что обеспечивает максимальную универсальность использования. [19]
В 1976 - 1977 гг. в Институте проблем механики АН СССР был реализован вариант такого комплекса программ на языке Алгол применительно к ЭВМ БЭСМ-4М. Ниже описан последующий вариант комплекса программ на языке Фортран применительно к ЭВМ серии ЕС. К настоящему времени этот вариант КПП в целом и его отдельные части прошли отладку и систематически используются для конкретных расчетов. Данная статья содержит краткое описание функционального наполнения этого комплекса программ: исходную математическую модель, методику численного решения и обработки результатов и сводные характеристики основных программных модулей, составляющих комплекс, а также сложившийся опыт использования комплекса и некоторые конкретные примеры. [20]
Типовые модули могут разрабатываться как стандартные. Одновременно улучшаются условия для повышения надежности ( правильности) программной модели. Проверка качества ( работоспособности) каждого модуля может осуществляться автономно, независимо от других модулей. Включение ранее разработанных стандартных модулей, прошедших длительную проверку в других программных моделях, не только повышает надежность, но и сокращает сроки создания программной модели. Основные программные модули реализуют функции, определенные информационной и математической моделями. Между модулями математической модели и основными программными модулями может не быть взаимно-однозначного соответствия. Один модуль математической модели может отображаться несколькими основными программными модулями, и наоборот, один основной программный модуль может поглотить несколько модулей математической модели. Это объясняется тем, что математическая модель, учитывающая возможности технических средств автоматизации управления, тем не менее в значительной степени является машинонезависимым объектом. Она вместе с информационной моделью может отображаться на различные технические средства автоматизации управления. [21]
Видимы ли переменные, модуля В основному программному модулю. Напомним, что ничто из модуля невидимо за пределами модуля, если только оно не экспортируется, а переменные В не экспортировались модулем А. Именно поэтому мы говорили об игнорировании модуля В в списке экспорта модуля А. Обратите внимание, что переменные В экспортируются из А путем экспортирования имени модуля В. Это единственный имеющийся метод сделать переменные В доступными для основного программного модуля. Этот последний пример показывает, что, прежде чем объект из модуля нижнего уровня из группы вложенных модулей может стать видимым за пределами этой группы, его необходимо экспортировать через все уровни вложенных модулей. [22]
Ни один из модулей этого примера не может видеть никаких переменных, за исключением своих собственных, поскольку не применялись никакие импорты. Исключение составляет модуль А. Модуль А может видеть экспортированные объекты модуля В, поскольку А составляет окружение В. По этой же причине основной программный модуль может видеть все, что экспортируется из модулей А и С. [23]
Типовые модули могут разрабатываться как стандартные. Одновременно улучшаются условия для повышения надежности ( правильности) программной модели. Проверка качества ( работоспособности) каждого модуля может осуществляться автономно, независимо от других модулей. Включение ранее разработанных стандартных модулей, прошедших длительную проверку в других программных моделях, не только повышает надежность, но и сокращает сроки создания программной модели. Основные программные модули реализуют функции, определенные информационной и математической моделями. Между модулями математической модели и основными программными модулями может не быть взаимно-однозначного соответствия. Один модуль математической модели может отображаться несколькими основными программными модулями, и наоборот, один основной программный модуль может поглотить несколько модулей математической модели. Это объясняется тем, что математическая модель, учитывающая возможности технических средств автоматизации управления, тем не менее в значительной степени является машинонезависимым объектом. Она вместе с информационной моделью может отображаться на различные технические средства автоматизации управления. [24]
Аварийные ситуации могут приводить к длительному выходу из строя всех или только части технических средств автоматизации. Выработку реакции на подобные ситуации ( для устранения их последствий) осуществляют технические средства автоматизации и общесистемное математическое обеспечение. Эти меры носят универсальный характер и распространяются на все программные модели, обслуживаемые этими средствами. Однако не всегда с помощью таких универсальных мер удается полностью устранить последствия аварийных ситуаций. В этих случаях целесообразно привлечь и использовать особенности конкретных программных моделей для выработки реакции на подобные ситуации и устранения их последствий. Эти функции могут исполняться автономными вспомогательными программными модулями. Частично они могут быть реализованы внутри основных программных модулей. Включение таких функций в основные программные модули должно осуществляться системой, которая обеспечивает автоматическое формирование программного модуля. [25]
Типовые модули могут разрабатываться как стандартные. Одновременно улучшаются условия для повышения надежности ( правильности) программной модели. Проверка качества ( работоспособности) каждого модуля может осуществляться автономно, независимо от других модулей. Включение ранее разработанных стандартных модулей, прошедших длительную проверку в других программных моделях, не только повышает надежность, но и сокращает сроки создания программной модели. Основные программные модули реализуют функции, определенные информационной и математической моделями. Между модулями математической модели и основными программными модулями может не быть взаимно-однозначного соответствия. Один модуль математической модели может отображаться несколькими основными программными модулями, и наоборот, один основной программный модуль может поглотить несколько модулей математической модели. Это объясняется тем, что математическая модель, учитывающая возможности технических средств автоматизации управления, тем не менее в значительной степени является машинонезависимым объектом. Она вместе с информационной моделью может отображаться на различные технические средства автоматизации управления. [26]
Типовые модули могут разрабатываться как стандартные. Одновременно улучшаются условия для повышения надежности ( правильности) программной модели. Проверка качества ( работоспособности) каждого модуля может осуществляться автономно, независимо от других модулей. Включение ранее разработанных стандартных модулей, прошедших длительную проверку в других программных моделях, не только повышает надежность, но и сокращает сроки создания программной модели. Основные программные модули реализуют функции, определенные информационной и математической моделями. Между модулями математической модели и основными программными модулями может не быть взаимно-однозначного соответствия. Один модуль математической модели может отображаться несколькими основными программными модулями, и наоборот, один основной программный модуль может поглотить несколько модулей математической модели. Это объясняется тем, что математическая модель, учитывающая возможности технических средств автоматизации управления, тем не менее в значительной степени является машинонезависимым объектом. Она вместе с информационной моделью может отображаться на различные технические средства автоматизации управления. [27]
Аварийные ситуации могут приводить к длительному выходу из строя всех или только части технических средств автоматизации. Выработку реакции на подобные ситуации ( для устранения их последствий) осуществляют технические средства автоматизации и общесистемное математическое обеспечение. Эти меры носят универсальный характер и распространяются на все программные модели, обслуживаемые этими средствами. Однако не всегда с помощью таких универсальных мер удается полностью устранить последствия аварийных ситуаций. В этих случаях целесообразно привлечь и использовать особенности конкретных программных моделей для выработки реакции на подобные ситуации и устранения их последствий. Эти функции могут исполняться автономными вспомогательными программными модулями. Частично они могут быть реализованы внутри основных программных модулей. Включение таких функций в основные программные модули должно осуществляться системой, которая обеспечивает автоматическое формирование программного модуля. [28]
Это относится в первую очередь к определению объема и состава каждого программного модуля. Математическая модель оставляет определенную свободу при размещении ее функций в основных программных модулях. Объем и состав вспомогательных программных модулей полностью определяется на этапе построения программной модели. Эта свобода должна использоваться для минимизации затрат времени на вспомогательные работы. Например, если модули программной модели хранятся во внешней памяти и для исполнения вызываются в оперативную, то затраты времени на обмен между внешней памятью и оперативной относятся к непроизводительным. Для их сокращения необходимо минимизировать число обращений за пределы каждого программного модуля. Это достигается как соответствующим размещением выполняемых функций по модулям, так и увеличением объема каждого модуля до максимально допустимых размеров. Аналогично необходимо размещать параметры в информационных модулях, стремясь к минимизации числа вызовов этих модулей из внешней памяти в оперативную. Математическая модель разрабатывается с применением алгоритмических языков. Таким образом, при разработке программной модели используются модули математической модели, описанные на алгоритмических языках. Если между модулями математической модели и основными программными модулями удается установить взаимно-однозначное соответствие, то программы этих модулей получаются автоматически путем трансляции, осуществляемой вычислительными машинами. Если такого соответствия нет, то построение программ также может быть автоматизировано с помощью специальных систем комплексирования. В этом случае неавтоматизированным остается процесс составления параметрического описания задания на комплексиро-вание. [29]
Гораздо больших усилий требует разработка правил оформления и связи модулей, типовых управляющих конструкций. Разнообразие вариантов здесь достаточно велико, а эффективность применения каждого из них меняется в зависимости от конкретной ситуации. Целевая установка на поиск оптимального варианта программы не позволяет ограничивать средства языка, рекомендованные к применению. Но и в этом случае может быть найдено компромиссное решение, облегчающее разработку. Основано оно на том, что различные части программы оказывают существенно разное влияние на время ее работы. Если программа хорошо структурирована, то такая работа не вызовет трудностей. При таком подходе на первом этапе разработки могут быть применены макрокоманды, реализующие оформление модулей, типовые управляющие конструкции, описание данных. По своим функциям, а часто и форме, такие макрокоманды напоминают соответствующие конструкции языков высокого уровня. Ассемблер, дополненный набором упомянутых макрокоманд, обычно называют структурным. При переработке программного текста макрокоманды могут быть заменены более эффективными для конкретной ситуации последовательностями команд. При разработке или выборе набора макрокоманд важно только помнить, что цель состоит в упрощении процесса разработки и поэтому разнообразие макрокоманд должно быть невелико. Кроме написания текста основной программы, для ее реализации на ЭВМ необходимо написать текст управляющего задания. Задания необходимо подготавливать и для выполнения вспомогательных программ, обеспечивающих процесс разработки. С точки зрения технологии программирования управляющее задание представляет собой модуль самого верхнего уровня, выполняющий специфический набор функций. Как и все остальные модули, он должен быть тщательно спроектирован. Проект его может быть выполнен на языке текстового описания. Но если при проектировании основных программных модулей мы могли отвлечься от особенностей средств их будущей реализации, то в данном случае проект должен быть ориентирован на возможности и особенности языка управления заданиями. [30]