Содержание к диссертации
Введение
Глава I. Системный инженерно-ориентированный язык САПР и архитектура компилятора 18
1.1. Особенности инженерно-ориентированного языка взаимодействия проектировщика и системы 18
1.2. Архитектура самонастраивающегося компилятора языка для мини-ЭВМ с нормированной и ненормированной длиной команды 38
Глава II. Автоматизация штабирования и построения блок-схем алгоритмов программ 49
2.1. Алгоритмы оптимального масштабирования вычислительных и тригонометрических операций. Автоматизированная система масштабирования 49
2.2. Автоматизированное построение блок-схем алгоритмов программ 60
Глава III. Автоматизированная система получения документации и программоносителей. оценка качества программного продукта 72
3.1. Автоматизированная система получения документации и программоносителей 72
3.2. Программирование "из середины" и оценка качества программ 83
3.3. Специализированная иерархическая база данных 101
Заключение 117
Литература
- Архитектура самонастраивающегося компилятора языка для мини-ЭВМ с нормированной и ненормированной длиной команды
- Алгоритмы оптимального масштабирования вычислительных и тригонометрических операций. Автоматизированная система масштабирования
- Автоматизированное построение блок-схем алгоритмов программ
- Программирование "из середины" и оценка качества программ
Введение к работе
В докладе на ХХУІ съезде партии (І) особо отмечалось дальнейшее "совершенствование вычислительной техники, ее элементной базы и математического обеспечения, средств и систем сбора, передачи и обработки информации".
Важное значение, как было подчеркнуто на съезде, имеет также разработка и ускоренное внедрение различных форм и методов автоматизации для облегчения ручного и умственного труда во всех сферах производства и народного хозяйства. Эта задача, особенно на сегодняшний момент, имеет первостепенное значение в связи с тем, что доля математического обеспечения в общем объеме стоимости средств вычислительной техники продолжает непрерывно возрастать. Так по данным американской фирмы (2,3), в 1955 году доля математического обеспечения (МО) в стоимости вычислительных систем составляла 15$, в 1975 году - 75$, а по прогнозам на 1985 год она должна превысить 90$.
В последние годы получило значительное развитие направление применения вычислительной техники в автоматизированных системах проектирования программ. Наиболее остро этот вопрос возникает при создании относительно недорогого МО для специализированных цифровых вычислительных машин (ЦВМ), входящих в состав авиационных комплексов.
Увеличение скорости, дальности, высоты полета, необходимость учета многочисленных внешних факторов, возросшие требования к точности решения радиолокационных и специальных задач требуют осуществления широкой автоматизации процессов обработки информации, управления и контроля, достигаемых средствами бортовой радиоэлектронной аппаратуры. Решению задачи расширения функциональных возможностей бортовой радиоэлектронной аппаратуры при одновременном уменьшении веса и габаритов входящих в ее состав устройств, способствовало широкое использование на борту самолета не одной ЦВМ, а расширенной сети бортовых вычислительных средств сбора и обработки информации»
Эти вычислительные комплексы, создаваемые на основе специализированных мини-ЭВМ, выполняют роль универсальных преобразователей вводимой информации и являются основным связующим звеном
- с системами, обеспечивающими обнаружение и опознавание различных объектов;
- с системой управления самолетом;
- с системами навигации;
- с системами индикации и пультами управления.
В настоящее время развитие авиационных систем в части вычислительных средств идет по следующим направлениям:
- расширение круга задач, решаемых вычислительной системой, включая задачи оптимизации различных парамотров;
- решение задач, связанных с максимальной автоматизацией управления летательным аппаратом,
В связи с разгрузкой летчика резко возрастает при различных ситуациях функциональная загруженность управляющей мини-ЭВМ, что влечет за собой появление большого количества алгоритмов, а следовательно, значительного увеличения объема математического обеспечения бортовых вычислительных систем.
Из приведенного круга задач следует, что цифровые вычислительные системы (ЦВС) представляют сейчас одно из наиболее мощных и экономичных средств решения задач управления летательным аппаратом и обработки данных в реальном масштабе времени. Однако, методы использования этих средств и, особенно, методы разработки МО в настоящее время требуют значительного усовершенствования, так как большинство систем математического обеспечения состоит, в основном, из взаимонезаменяемых компонентов, разрабатываемых ценой больших затрат, причем эти системы часто оказываются ненадежными, неудобными в эксплуатации и сложными в освоении.
Одним из наиболее эффективных средств преодоления этого кризиса в области разработки программного обеспечения бортовых специализированных мини-ЭВМ является создание.комплексной системы автоматизации проектирования (САПР) МО (5),(2).
Исходя из вышесказанного, можно сделать вывод, что автоматизация проектирования, выступая как мощное средство повышения эффективности т.е. повышение качества, сокращение сроков и стоимости разработки программных средств имеет большую актуальность.
Прежде чем приступить к рассмотрению этого вопроса необходимо вкратце остановиться на ряде уже разработанных систем автоматизации процесса программирования. Хотя эти системы не приспособлены для работы с данным классом машин, общие принципы, которые легли в основу их построения, имеют много общих сторон с САПР МО бортовых специализированных машин.
Поскольку в создании комплекса программ для самолетных систем, как показала практика, участвует от 80 до 100 человек и полный объем математического обеспечения исчисляется десятками тысяч команд, его можно отнести к большим проектам (104),(16).
При разработке таких систем основным критерием является обеспечение заданных показателей надежности, стоимости, а также удовлетворение соответствующих тактико-технических требований.
К основным особенностям больших проектов разработки программных средств можно отнести следующие: - большой коллектив программистов для реализации МО, что усложняет процесс управления разработкой всего программного комплекса;
- разработка, как правило, реализуется не гладко и имеет довольно много неожиданностей, обусловленных нечеткими исходными требованиями и заданиями, а также дефектами самого процесса разработки программ;
- документация не всегда удовлетворяет требованиям эксплуатации и контроля, что обычно связано с постепенным введением многочисленных поправок и "заплат" в программы, которые не всегда находят отражение в документации;
- разработчики выполняют большой объем работы вручную, подготавливая контрольные тесты, сравнивая текущие и выходные результаты с эталонами и т.д.
Все вышеперечисленные особенности в конечном итоге приводят к существенному возрастанию стоимости и времени разработки больших программных проектов.
Следовательно, основная проблема автоматизации разработки состоит в создании методов и технических средств для облегчения работы программистов на всех этапах отладки, сопровождения и дальнейшей эксплуатации системы. Это может быть достигнуто только путем создания комплексной САПР МО.
В ранее разработанных системах предусмотрены изолированные между собой средства внесения изменений в программы, программы-редакторы и интерпритаторы. В более совершенных системах автоматизации разработки программ включаются средства корректировки описания системы на языках близких к языкам высокого уровня, руководств по использованию системы и ее частей, средств проверки совместимости между модулями и другие вспомогательные программы, обеспечивающие разработку, редактирование, отладку и проверку системы и ее составных частей.
В настоящее время создано достаточно большое количество различного рода автоматизированных систем для более эффективной разработки программоного обеспечения. Так, в частности, разработана простая система ARCHIVES(5), которая позволяет оперировать с множеством программных модулей и их модификацией на основе иерархической системы обозначений. Структура системы автоматизации разработки программ включает: базу данных, средства разработки программ, средства описания и средства реализации. Описанная структура системы автоматизации является довольно общей и представляет широкие возможности включения в нее различных средств разработки. Однако сама по себе система ARCHIVES является достаточно частной и предназначена только для внутреннего пользования на фирме. Одним из существенных недостатков этой системы является наличие "привязанного" компилятора только к конкретной микро-ЭВМ.
На сегодняшний момент эти проблемы решаются более радикальными средствами. Так, например, в Европе для современных микропроцессоров разработан общий язык ассемблерного типа (6),(7), который содержит широкий спектр команд типичных современных микропроцессоров. Обычно указанный язык используется как общая мнемоника и всякий раз требуется с помощью таблиц преобразований осуществлять переход к конкретному микропроцессору и его системе команд, однако в большинстве случаев это является неудобным для пользователей.
К середине 60-х годов большинство квалифицированных специалистов по программированию занималось поисками единого языка, который решал бы все проблемы. Однако, вскоре стало совершенно очевидным бесплодность таких попыток. В настоящее время сложилось мнение, что необходимы как универсальные, так и разнообразные специальные языки программирования. Для такого изменения точки зрения существуют объективные причины: сфера применения ЭВМ существенно расширилась; структура ЭВМ не только изменилась, но и развилась в различных направлениях. Семидесятые годы показали, что один язык и один компилятор не могут ликвидировать проблему программного обеспечения. Разработка как прикладного, так и системного программного обеспечения для различных машин в рамках одного проекта особенно необходима в области систем реального времени и вычислительных сетях МИНИ-ЭВМ.
В 1975 году фирмой 5CS для ЭВМ IBM/370 был разработан язык программирования в реальном масштабе времени P0LVP (8). По своей структуре язык POLYP сходен с языком алгол-60. Правда, его семантика в некоторых случаях достаточно сильно отличается от семантики этого языка. Существенным преимуществом системы POLYP является то, что в ней воедино связаны следующие компоненты: инструментальный язык, макроязык, кросс компилятор, средства отладки на уровне переходного языка и система отладки. Разработанный комплекс программ является удобным для использования его в качестве базиса для построения специальных языков, однако данная система жестко привязана к ІВВД/370, что делает ее немобильной.
Цифровые вычислительные машины, предназначенные для управления динамическими объектами УЦВМ, как правило, не имеют ресурсов по памяти и по производительности, необходимых для размещения и функционирования системы автоматизации программирования и отладки (САЛО). Поэтому средства САЛО размещаются на достаточно мощных технологических ЭВМ, пригодных для автоматизации всего технологического цикла разработки управляющих программ. Основные тре 9 бования к созданию подобных систем были частично реализованы на системах ЯУЗА-І и ЯУЗА-2 (9,10) и в более полной мере нашли свое отражение в системе ЯУЗА-6 (II), построенной на технологической ЭВМ БЭСМ-6.
Система автоматизации программного обеспечения САЛО ЯУЗА-6 делится на три части: организующую систему, систему автоматизации программирования и систему автоматизации отладки. Эти три подсистемы используют развитую информационную систему архивов и библиотек, которая включает архив символьной информации исходных текстов программ, библиотеку паспортов подпрограмм и адресную библиотеку оттранслированных программ в машинных кодах.
Основным недостатком систем семейства ЯУЗА является нерешенность в достаточной мере вопросов масштабирования, автоматического построения блок-схем алгоритмов программ, отсутствие языка нанипулящи данными для работы с библиотеками, отриентации самой системы автоматизации только на ЭВМ-220 и БЭСМ-6, наличие пакетного режима работы пользователей.
В последнее время делаются попытки создания САПР МО для специализированных мини-ЭВМ на базе языка программирования АДА. Однако, количество публикаций по этому вопросу недостаточно, чтобы судить об эффективности разрабатываемой системы.
Следующей системой, которая была создана для автоматизации программирования управляющих специализированных ЦВМ, является система САПАР (12). Она была реализована на технологической ЭВМ БЭСМ-6. Для автоматизации процесса написания программ в системе был разработан специальный язык, который занимает промежуточную ступень между автокодом и языком высокого уровня. Общие положения, которые легли в основу построения САПАР схожи с положениями, заложенными при реализации ЯУЗА-6. Однако система в целом получилась недостаточно эффективной в практическом внедрении в силу ее жесткой привязки только к одной специализированной машине, полного отсутствия какой-либо базы данных для хранения всего комплекса МО, а также длительного и трудоемкого процесса ее адаптации на другие типы технологических ЭВМ.
Прежде чем перейти к рассмотрению комплексной САПР МО для специализированных ЦВМ (36), которая и является предметом разработки, необходимо кратко остановиться на их особенностях.
Все современные управляющие специализированные ЦВМ - вычислительные машины параллельного действия, использующие представление чисел с фиксированной запятой. Машины данного класса работают как с одноадресными и двухадресными командами, так и с командами переменной адресности (22). В качестве элементной базы применяются элементы 2-ой и 3-ей степени интеграции. В структурном отношении эти машины используют различные принципы вычислительного процесса: наряду с однопроцессорными ЦВС имеют место многопроцессорные, которые работают в мультипрограммном режиме и в режиме реального масштаба времени. Надежность работы обеспечивается высокой надежностью элементной базы, функциональным резервированием, применением аппаратных и программных средств контроля. Емкость памяти большинства современных управляющих ЦВМ составляет 32К с возможностью наращивания до 64К. В качестве ЗУ используются магнитные сердечники и ППЗУ. Число команд в этих ЭВМ составляет 40+150; быстродействие - 50+800 тыс. коротких операций в секунду, разрядность чисел и команд - 16+32 бит.
Таким образом, современные управляющие ЦВМ предназначены для решения достаточно узкого класса задач, оснащены небольшим числом аппаратных средств, способны выполнить лишь ограниченное число операций и автоматизация выступает как одно из наиболее эффективных средств снижения стоимости, уменьшения времени и повышения эффективности разработки их программного обеспечения (14),(15), (16). В настоящее время на борту самолета используются специализированные ЦВМ, близкие по своим характеристикам с мини-ЭВМ, однако уже наметилась тенденция к переходу на 8-16-ти разрядные микропроце ссоры.
Общую схему разработки САПР (34), начиная от постановки задачи и кончая готовым продуктом в виде программоносителей и документации, можно представить в виде, изображенном на рис.1. Из данного представления видно, что весь процесс проектирования такой системы разбивается на два этапа:
- этап разработки автоматизированной системы анализа и выбора средств реализации (АСАР);
- этап создания автоматизированной системы проектирования программ для выбранной архитектуры ЦВС.
Система АСАР наряду с разработкой математического аппарата и логикой функционирования поставленной задачи, включает оценку вычислительной мощности всего комплекса и выбор на основе этого архитектуры управляющей ЦВС. Совершенно очевидно, что ряд этапов, описанных в данной схеме, не поддается полной автоматизации. К ним можно отнести постановку задачи, разработку математического аппарата и логику функционирования. Однако анализ и выбор средств реализации, этапы моделирования, рекомендации по выбору, вычислительной мощности, целесообразно осуществлять на технологической ЭВМ, что наряду с сокращением времени разработки позволит в значительной мере избежать различных толкований технических требований к комплексу, которые, как правило, возникают при создании сложных программных систем. .
Под анализом и выбором средств реализации понимается всес 12 торонний разбор поставленной задачи и оценка возможности реализации отдельных частей системы с помощью программных или аппаратных средств. Важность этого момента продиктована практикой создания комплексных систем управления, работающих в реальном масштабе времени и от качества его решения во многом зависят сроки разработки, эффективность работы системы и выполнение тактико-технических требований.
На втором этапе при создании автоматизированной системы разработки программного обеспечения необходимо остановиться на трех наиболее важных моментах:
- разработка языка взаимодействия проектировщика МО и системы;
- создание системы отладки;
- быстрое и эффективное получение документации и программоносителей.
Каждый из этих трех этапов имеет определенные особенности, связанные не только с конкретными управляющими мини-ЭВМ, но и с методами и способами отладки, эксплуатации и модернизации всего программного обеспечения. Работа с САПР МО является более эффективной в том случае, когда для пользователя-проектировщика МО в системе существует диалоговый режим, позволяющий не только быстро обучить программиста работе с определенными частями системы, но и сократить время на организацию всего рабочего процесса.
Для современного этапа развития средств вычислительной техники характерно наличие широкого класса терминальных систем, как универсальных, так и специализированных (19+21). Развитие терминалов, аппаратного и математического обеспечения ЭВМ позволило размещать терминалы пользователя на большом расстоянии от ЭВМ и стимулировало интерес к системам с разделением времени (4). В
ІЗ таких системах возможности сравнительно большой вычислительной машины распределяются между отдельными пользователями, каждый из которых взаимодействует с ЭВМ посредством своего собственного терминала. Возможность хранения больших банков данных, обеспечение доступа нескольких пользователей делает терминальные комплексы наиболее перспективными при использовании в автоматизированных системах проектирования программного обеспечения, создаваемых для специализированных управляющих мини-ЭВМ.
Целесообразно в качестве технологических ЭВМ на настоящий момент для целей создания САПР МО использовать типовые вычислительные комплексы ряда CM-ЭВМ. Особенностями этого класса машин являются: магистральная структура интефейса с аппаратной реализацией большинства системных функций ввода-вывода, простая реализация многопроцессорных и многомашинных систем, высокая скорость обработки прерываний, возможность работы с форматами различной длины, подключение до 16 терминалов в ОС РВ, возможность совместной работы УВК СМ-3, СМ-4 с ЭВМ единой серии. Эти особенности дают определение преимущества для создания систем автоматизации обработки информации в различных сферах применений (17,18).
Как уже было отмечено выше, управляющие специализированные ЦВМ, используемые в контуре управления авиационных систем, способны выполнять лишь ограниченное число операций или допускают использование одного языка программирования, находящегося на уровне не выше автокода. Решение любой практической задачи на таких машинах можно разбить на пять составных частей:
- разработка и построение блок-схемы алгоритма;
- масштабирование вычислительных операций;
- разработка и расчет контрольных вариантов для всесторонней проверки логики работы алгоритма; - распределение памяти ОЗУ и ДЗУ;
- получение программоносителей и документации.
Каждый из этих пяти этапов наряду со специфическими особенностями имеет трудоемкие участки, как правило, состоящие из типовых операций, не требующие творческого подхода при каждой реализации. Кроме того, программирование для таких ЦВМ на автокоде, а тем более на языке машинных команд требует весьма значительных затрат и времени разработки.
Для того, чтобы автоматизировать эти процессы, необходимо, как было сказано выше, создать САПР МО. Для достижения этой цели потребовалось:
- создание инженерно-ориентированного системного языка (ИОСЯ)взаимодействия проектировщика МО и системы;
- реализация компилятора с ИОСЯ на язык специализированных ЦВМ с нормированной и ненормированной длиной команды;
- разработка автоматизированных подсистем построения блок-схем алгоритмов программ и масштабирование вычислительных операций;
- автоматическая стыковка программ по глобальным переменным;
- распределение памяти ОЗУ и ДЗУ;
- создание базы данных для хранения МО и языка манипулирования базой;
- автоматизация процесса получения документации и программоносителей;
- разработка комплекса программ для обучения пользователей работе с системой на основе интерактивного режима работы.
В основу работы был положен системный подход к проблеме создания САПР МО для описанного класса машин, который включает: анализ и сопоставление языковых средств автоматизированных систем, технологий разработки и схем отладки программ реального времени, направленных на повышение надежности программного продукта, анализ методов повышения качества программ, имеющих целью сокращение стоимости и поднятие эффективности как на этапе отладки, так и на этапе дальнейшей эксплуатации. В работе использовался аппарат теории графов, теории формальных грамматик, методы математического моделирования, методы построения систем реального времени, технология программирования "из середины", впервые разработанная автором, а также основные принципы создания и организации баз данных в вычислительных системах.
В первой главе диссертации описана версия языка взаимодействия программиста-разработчика и системы, по характеру близкого к языку высокого уровня. По своей структуре он является языком инженерно-ориентированного типа и представляет собой-исходный инструмент автоматизированной системы проектирования МО для управляющих специализированных мини-ЭВМ и позволяет осуществлять автоматизацию всех процессов решения задач бортовых машин. Принцип построения семантики и синтаксиса ИОСЯ был основан на представлении всех операторов с использованием подпрограмм-функций, что не имеет аналогов в известных разработках для систем данного класса. Бесприоритетная форма записи выражений, а также логика построения условных операторов и операторов цикла обеспечивает независимую структуризацию программ. В этой же главе обосновывается выбор структуры и построения компилятора с ИОСЯ на машкод специализированных мини-ЭВМ с нормированной и ненормированной длиной команды. В определенной мере созданный компилятор можно отнести к классу "самоподстраивающихся", что в практической реализации является новым. Во второй главе описаны результаты исследований и разработки трансляторов масштабирования и построения блок-схем алгоритмов программ как на уровне инженерно-ориентированного языка, так и с локализацией до одной машинной команды.
Алгоритмы масштабирования полностью отвязаны от разрядности и системы счисления данной ЦВМ, что позволяет их использовать практически для любых вычислительных машин с дробной арифметикой. Автоматизированное построение функциональных схем программ основано на представлении исходного текста в виде схем Ляпунова-Янова с введением групповых символьных ключей, что в части реализации осуществлено впервые. Здесь же описана методика, которая позволяет проектировщикам МО эффективно работать с режимами масштабирование и формирование блок-схем и обсуждаются пути развития этих процедур.
В третьей главе диссертации описана автоматизированная система получения документации и программоносителей, сервисные режимы, позволяющие значительно упростить процесс отладки и верификации программ пользователей. Здесь же приводится структура специализированной базы данных, созданной для хранения различных версий МО, анализируется язык управления базой с иллюстрацией различных режимов работы. В этой же главе рассматриваются вопросы качества программного обеспечения, технология программирования "из середины", впервые сформулированная и обоснованная автором.
Созданная система автоматизации МО реализована на БЭСМ-6 и СМ-4. Реализация на этих машинах обусловлена тем, что основное ядро системных программ написано на мобильном фортране, что позволяет легко адаптировать САПР МО на любые типы ЭВМ, имеющие транслятор с одного из диалектов этого языка программирования. Хочется также отметить, что состав и возможности САПР МО постоянно распшряются. Ведутся работы, связанные с вопросами самодокументирования для облегчения динамической отладки программ с реальной аппаратурой. Происходит адаптация автоматизированной системы в операционные среды ДОС/ЕС и ОС/ЕС.
Архитектура самонастраивающегося компилятора языка для мини-ЭВМ с нормированной и ненормированной длиной команды
Использование языков подобных языку P0TALZ значительно сокращает время и стоимость программирования, уменьшает возможность появления ошибок и, следовательно, повышает надежность Мо, обеспечивая ясность и удобочитаемость программ. Однако написание оптимальной по всем параметрам программы на системном языке еще не означает, что эта программа будет оптимальной для управляющей мини-ЭВМ. Это связано с тем, что программирование на специализированных машинах данного класса осуществляется, как правило, либо в определенной системе команд, либо на автокоде низшего уровня, и вопрос создания качественной компиляции с инженерно-ориентированного системного языка на язык бортовых мини-ЭВМ является достаточно сложной задачей (41), (42). Сложность создания компиляторов подобного рода автоматизированных систем разработки МО определяется также тем, что время морального старения управляющих специализированных мини-ЭВМ из-за бурного развития элементной базы исчисляется двумя-тремя годами. Поэтому в настоящее время очень остро возникает проблема создания "самонастраивающего" компилятора, который бы требовал минимального времени на введение доработок при переходе с одной мини-ЭВМ на другую. Этот вопрос в последнее время достаточ 39 но широко обсуждается как в нашей стране (9,39) так и за рубежом (37), (38). Однако, в основном, все разработки касаются только компиляторов, приспособленных для конкретных ЭВМ общего назначения и не включают класс специализированных, управляющих мини-ЭВМ.
В данной части главы рассматривается общая структура "самонастраивающегося" компилятора, основные принципы синтаксической и логической подстройки, а также определяется место и связи компилятора с автоматизированной системой разработки МО. Прежде чем перейти к рассмотрению данного вопроса формализуем постановку задачи и введем ряд функциональных понятий и определений. Условимся, что построение ИОСЯ базируется на языке высокого уровня с развитой структурой конструкции подпрограмм-функций (например ФОРТРАН или АЛГОЛ-ГДР). Транслятор с этого языка включает программные уровни, написанные на всем диапазоне языков базовой ЭВМ, а сам компилятор создается на основе этих языков.
Введем ряд определений, которые упростят разбор и формализацию поставленной задачи: - кодовый элемент (КЭ) - код-любой операции системы команд или автокода управляющей мини-ЭВМ; - синтаксическая конструкция (СК) - конструкция имени кодового элемента; - законченная логическая группа (ЗЛГ) - набор кодовых элементов для реализации макродирективы на входном языке (ВЯ); - увеченная логическая группа (УЛГ) - набор кодовых элементов для реализации макродирективы программы на ВЯ с учетом влияния вышестоящей и нижестоящей логических групп; - логическая замкнутая группа (ЛЗГ) - набор законченных логических групп, выполняющих локальную логическую задачу; - общий базовый элемент (ОБЭ) - некоторое устройство мини-ЭВМ, которое участвует в большинстве операций (например, сумматор или регистры общего назначения); - частный базовый элемент (ЧБЭ) - некоторое устройство мини-ЭВМ, которое участвует в ограниченном наборе операций (например, регистры, не доступные программисту). Структурную схему самонастраивающегося компилятора можно разбить на три уровня: 1) уровень априорной информации и каталогизация основных элементов; 2) уровень обработки макродиректив программы на входном языке и формальная запись модуля, написанного на ИОСЯ, в кодах данной ЭВМ; 3) уровень оптимизации и вывода объектной программы в виде требуемых программоносителей. Важным вопросом, определяющим успех решения задачи, является правильный выбор исходной априорной информации. В данном случае задача усложняется тем, что априорная информация должна не только адекватно отображать специфику какой-то определенной управляющей мини-ЭВМ, но и включать основные общие особенности, присущие этому классу машин. В качестве такой информации можно выбрать следующие характеристики: - целые числа, характеризующие объем памяти управляющей мини-ЭВМ, а также соотношение между областями ДЗУ и ОЗУ; - количество регистров как доступных, так и не доступных программисту, их разрядность, разрядность слова и т.д.; - двоичные константы-маски, определяющие различные поля команд и формы представления чисел; - коды операций и виды адресации для данной системы команд управляющей мини-ЭВМ; - логика работы стандартных и нестандартных операций; - описание работы алгоритмов стандартных подпрограмм.
Алгоритмы оптимального масштабирования вычислительных и тригонометрических операций. Автоматизированная система масштабирования
Специализированные ЦВМ, реализующие алгоритмы управления, оперируют с машинными переменными, которые соответствуют физическим параметрам решаемых задач. Приведение всех физических величин к диапазону изменения и размерностям машинных переменных, с учетом точности решения задачи, производится с помощью масштабирования. Наиболее сложным при этом является случай использования в цифровой вычислительной системе специализированной мини-ЭВМ с фиксированной запятой, когда применение аппарата плавающей запятой невозможно ввиду целого ряда конструкторских ограничений. В данном случае необходимость масштабирования определяется тем, что физическая величина всегда имеет определенную размерность и диапазон изменения, в то время как машинная переменная является безразмерной; кроме того, для обеспечения точности вычислений бывает необходимо задавать переменные в максимально возможном масштабе. Часто на практике встречаются случаи, когда физическая переменная поступает в ЦВМ в различном диапазоне, что требует применения переменного масштабирования при реализации алгоритмов управления.
Для более наглядного представления сущности поставленной задачи рассмотрим конкретный пример линейной экстраполяции параметра некоторого объекта на небольших интервалах времени с последующей высветкой его на индикационном дисплее, имеющем размер экрана 200x200 мм в центральной системе координат.
Здесь сразу возникает принципиальный вопрос: какова потеря точности параметра Z(t) при его вычислении, поэтому необходимо произвести еще один этап проверки для Zui - & При делении на Т мы имеем явную потерю точности, что можно скомпенсировать только сдвигом: i(t)=[(iLH-ZL)ATja4 Правда, и в этом случае необходима проверка на переполнение сумматора. На данном примере видно, что реализация даже простейшего алгоритма требует громозкого анализа, а для практического случая достаточно большого количества преобразований параметра, вообще трудно оценить окончательную точность представления без введения какой-то ни было автоматизации. Рассмотрим дальнейшее изложение этого примера для того, чтобы показать случай применения нестандартного масштаба и введение специальных коэффициентов масштабирования, а также попытаемся упростить метод масштабирования до получения формальной методики, описывающей процесс нахождения масштабных коэффициентов. Анализ второго выражения производится аналогично анализу первой формульной зависимости и его машинная реализация будет иметь вид: «Й/Л vArff J - i clto- ьА /і JO В данном выражении, как уже говорилось выше, рассмотрен случай применения стандартного масштабирования, т.е. приведе п ние переменной к математическому диапазону, кратному 2 , через масштабные коэффициенты Л0 = Рассмотрим теперь алгоритм сопряжения с дисплеем, на котором мы должны высветить параметр У (t ) в виде точки, причем конструктивная особенность дисплея такова, что информация на него должна поступать в виде слова, содержащего безразмерные дискреты, количество которых определяется некоторым масштабным коэффициентом. Таким образом, параметр У ( ), перед высветкой на экране, должен пройти целый ряд масштабных преобразований. Для представления этой величины в диапазоне экрана дисплея, который имеет размер в центральной системе координат - 100 мм, необходимо ввести первый масштабный коэффициент: ГП, = І00««/250м Второе масштабное преобразование для привязки безразмерных дискретов, задает их количество с помощью коэффициента ГИк г 1/1. 5" Ъ/мм
Рассмотрим процесс масштабирования операции алгебраического сложения и вычитания двух переменных, который можно изобразить в виде алгоритма, показанного на рис.14. В предложенном алгоритме заложена логика выравнивания масштабов и приоритетность левого сдвига, который, по крайней мере, не дает потери в точности. Логика операции сложения выполнена для общего случая и охватывает любые ЭВМ с фиксированной запятой и разрядной сеткой. В алгоритм также включены все известные ситуации, возникающие в процессе масштабирования этой операции, что делает его универсальным. В структурной схеме предусмотрен анализ нестандартных масштабов и приведение их при необходимости к стандартным; в конце алгоритма введен блок корректировок масштабов в соответствии с заданной точностью результата операции, которая опеределена требованиями на систему и, кроме того, предус 56 мотрена возможность выдачи диагностики об ошибках при работе пользователей с некорректными масштабами.
Автоматизированное построение блок-схем алгоритмов программ
Реализация практически любой физической задачи на ЭВМ начинается с разработки и построения алгоритма ее решения. В проблемном программировании этот этап следует сразу после математической формулировки и выбора методики решения поставленной задачи. Строгое определение понятия алгоритма, к сожалению, дать не удается (55), поэтому ограничиваясь интуитивным описанием, алгоритм, для некоторого класса задач, можно представить как общее правило, определяющее процесс преобразования исходных данных в искомый результат (24) и обладающее свойствами определенности, результативности, массовости и осуществимости. Это общее правило или как его еще принято называть предписание, не поддается в математике четкой и ясной формулировке. Однако, с полной определенностью можно сказать, что алгоритм описывает поэтапную логику решения конкретной математической задачи.
Как известно, для решения одной и той же задачи можно составить несколько различных алгоритмов, причем этот процесс является достаточно трудоемким. Такая неоднозначность в трактовке решения задачи объясняется рядом причин, которые связаны прежде всего с индивидуальными особенностями программиста, выбором ЭВМ и алгоритмическим языком, на котором будет осуществляться программирование.
Практика показывает, что чем выше находится алгоритмический язык в иерархии языков программирования, тем меньше неоднозначность при реализации логики решения конкретной задачи.
Это объясняется тем, что на машкоде, вследствие большого количества различных команд, пользователь в силу своей квалификации и привязанности к какой-то определенной группе, стремится составить алгоритм с ориентацией на ту часть команд, которую он уже успел опробывать на практике и в которой уверен.
При решении задачи с использованием языков высокого уровня и тем более с использованием проблемно-ориентированных языков, которые специально разрабатываются для автоматизации процесса программирования, за счет большей инфорнативной емкости каждого оператора языка уменьшается разброс в применении операндов пользователями, что приводит к уменьшению расхождения при составлении исходного алгоритма.
В последнее время все чаще можно услышать от квалифицированных программистов (особенно, работающих на языках ФОРТРАН, АЛГОЛ или ПЛ), что при реализации поставленной перед ними задачи, они обходятся без составления подробной структурной схемы алгоритма. Это объясняется прежде всего простотой этих языков, их наибольшей приближенностью к обычному языку математических зависимостей, а также высокой степенью профессионализма.
Аналогичная картина наблюдается, правда в значительно меньших масштабах, у программистов, пишущих на машкоде. Однако, подобный профессионализм присущ только единицам, а подавляющее большинство программистов без блок-схем алгоритмов обойтись не могут.
Сам по себе язык блок-схем, созданный для описания дискретных процессов различной природы, является наиболее наглядным и приемлемым при общении не только между разработчиками программ, но и между программистами и заказчиками, которые порой имеют смутное представление об алгоритмических языках.
Как уже говорилось выше, процесс отладки программного обеспечения управляющих мини-ЭВМ разбивается на ряд последовательных этапов. На каждом из них происходит корректировка логики отдельных частей системы, что необходимо отслеживать в блок-схемах алгоритмов. Если этот процесс является не достаточно оперативным, то уже на стадии статической отладки, происходит большая путаница с документацией, что в конечном итоге сказывается как на процессе дальнейшей полудинамической отладки, так и на общем времени разработки математического обеспечения.
Таким образом, совершенно очевидно, что при автоматизации проектирования МО важное место занимает процесс автоматизированного построения алгоритмов программ.
Реализация практически любой задачи на ЭВМ включает, наряду с разработкой и построением алгоритма, этап поиска и исправления ошибок, являющихся либо результатом неправильной записи алгоритма, либо следствием недостаточно ясного представления о логике решения физической задачи.
Как правило, выявление логических ошибок возможно только при проверке работы алгоритма по контрольным вариантам или тестам, разработка которых является достаточно сложной и трудоемкой задачей и не может быть качественно решенной без соответст 63 вущей блок-схемы проектировщика МО.
Проблема автоматизации алгоритмирования не является новой и достаточно широко обсуждается (64), (65). Основным в этих работах является возможность упрощения анализа программ за счет более наглядного представления ее структуры, чем это дает простая печать. Данные системы предназначены, в основном, для работы с языками высокого уровня. Автоматизированная система анализа и построения блок-схем символьных программ, описанная в (64), упрощает анализ логики подпрограмм, написанных на языке АЛТОЛ-60, а система (65) предназначена для построения алгоритмов с входного языка КОБОЛ. Основным недостатком этих систем является малая степень детализации, что является существенным ограничением в использовании их при алгоритмизации задач МО для управляющих мини-ЭВМ.
Автором создан транслятор с языка P0WLZ Для автоматического построения блок-схем алгоритмов программ и расчета контрольных вариантов (44). С его помощью удается строить блок-схемы программ как на физическом уровне (укрупненная формализованная структура), так и с локализацией до одной машинной команды, добиваясь тем самым наивысшей степени детализации.
Программирование "из середины" и оценка качества программ
Анализ математического обеспечения неразрывно связан с определением качественной оценки разрабатываемых программ. На се 84 годняшний день, к сожалению, отсутствуют четкие критерии оценки количества и качества программного продукта (50 -г- 54) и здесь хотелось бы более подробно остановиться на данном вопросе. Этой проблеме в настоящее время уделяется пристальное внимание однако, большинство статей носит, как правило, чисто теоретический характер, изобилуя сложными математическими выкладками, которые затруднительно использовать на практике. Во многих работах качество программы трактуется недостаточно корректно и порою сводится лишь к минимизации памяти и времени счета. Рассматривая качество программы как понятие более широкое (75 76), можно представить F кач (функцию качества), зависящей от следующих аргументов: - модифицируемости программы (JM - СТОИМОСТИ (jc - удобочитаемости j4. - степени адаптации или мобильности о . - времени счета (jt - объема памяти, занимаемого программой jjn
Таким образом, F гф( (J-M, , fe-ч, kstafr") Здесь надо сразу оговориться, что постановка вопроса о хорошей или плохой программе безотносительно к конкретной области применения является ошибочным. При решении любой задачи необходимо четко представлять к какому она относится классу и в каких условиях будет эксплуатироваться. Если, например, решается задача чисто научного характера, то программиста порой не интересует сколько памяти она занимает (если, конечно, не занята вся область памяти ЭВМ) и каково время счета по центральному процессору (если, правда, оно не исчисляется сутками). Его больше интересуют вопросы модифицируемости, мобильности и стоимости программного продукта. С другой стороны, если программисты разрабатывают программой обеспечение УЦВМ, то наиболее остро возникают вопросы экономии памяти, удобочитаемости составленной программы, уменьшение времени счета задачи и ее модифицируемость.
Однако, коль речь зашла о качестве программного продукта, необходимо учитывать следующие обстоятельства. При рассмотрении комплекса программ, качество программной системы зависит не только от качества каждой отдельной подпрограммы. Часто бывает, что программный продукт, составленный из подпрограмм, не обладающих совершенством, в совокупности работает с очень высоким качеством и наоборот. Поэтому здесь необходимо оптимизировать внешние программные связи и от качества этой оптимизации во многом будет за-висить качество программного комплекса. Аналогичные проблемы возникают и при осуществлении стыковки программных модулей, написанных на разных языках программирования.
Рассмотрим теперь отдельные аргументы F кач. В последние годы большое число программистов стало заниматься созданием всевозможного рода автоматизированных систем. Увеличение работ в области программного обеспечения привело к необходимости координации программ, написанных разными людьми (зачастую даже разной квалификации) не только на заключительных стадиях разработки системы, но и на ее первоначальных этапах. При создании программной единицы стало важно не только составить ее правильно в соответствии с алгоритмом решаемой задачи, но и написать программу, по возможности, простой и более понятной. Порою программисты совершенно не задумываются над этим важным вопросом и пишут программы, понятные только самим разработчикам. Такой подход приводит к тому, что в конечном итоге пользователи таких программ затрачивают значительные усилия на их даже небольшие изменения, что влияет на стоимость программного продукта в целом.
Сейчас все чаще возникает проблема заимствования программ с целью сокращения времени разработчика сложных программных систем и, в связи с этим, на первый план выдвигается вопрос улучшения читабельности программного продукта.
Прежде всего, удобочитаемость программы зависит от выбора языка программирования (56, 2). Известно, что чем выше язык программирования находится на иерархическом уровне, тем он ближе к обычному языку математических зависимостей. Программы, написанные на языках высокого уровня, более наглядны, удобны для отладки и дальнейшей эксплуатации, нежели программы, созданные на языке машины, другим важным моментом при рассмотрении этого вопроса является структуризация программ. Общепризнано (2,57,50), что использование в программах операторов GO ТО ухудшает их понимание и запутывает логику решения задачи, тем самым ухудшая удобочитаемость. Степень структуризации может быть определена как отношение числа операторов GO ТО к общему количеству операторов в программе. Уменьшение этой величины приводит к улучшению читабельности программной единицы. Однако, слепое увлечение структурным программированием может привести и к обратным последствиям. Поэтому существенным является вопрос какие и до какой степени программы могут подвергаться процессу структурирования.
Немаловажно также, при исследовании функции удобочитаемости, учитывать такую важную характеристику, как сложность программной единицы. Если перед программистом стоит реальная физическая задача, то упрощение ее при написании программы по отношению к первоначальной постановке (имеется в виду математической) практически не происходит. Более того, задача может только усложняться за счет использования различных методов вычислений. Слож 87 ность программы, определяемая числом логических операторов и операторов безусловного перехода, находится в обратной пропорциональной зависимости с функцией удобочитаемости.
Помимо вышеперечисленных характеристик, при оценке функции удобочитаемости, необходимо учитывать длину написанной программы. Данной влияния интуитивно установить достаточно просто. Чем больше операторов в программе, тем сложнее понять, а следовательно, и прочитать ее.
