2.8 Некоторые типовые компоненты программной

РАЗРАБОТКИ МПС

ЦЕЛЬ - анализ некоторых типовых программных компонент МПС, используемых в разработках Функционального Программного Обеспечения (ФПО), т.е. ПО, разрабатываемого для управления ОУ.

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

Алгоритм - заранее заданная последовательность четко определенных правил или команд для получения решения задачи за конечное число шагов. Большой класс алгоритмов построен на программно - логических функциях. К ним относятся функции, принимающие значения 1 или 0 (бинарная логика). Например, в телефонных процессах логические значения 1 или 0 могут интерпретироваться как: микротелефонная трубка снята? (да(1)/нет(0)), есть сигнал / нет сигнала; для сотового телефона нажал / не нажал; выбрал из меню функцию да/нет и т.д. Если из таких компонент реализуется алгоритм функции, по которому затем разрабатывается программа, то такие функции называются программно – логическими.

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

Первый (идеальный вариант) – разработка данной функции в предположении её реализации при наличии всех нужных ресурсов, например, данных, с которыми работает программа; отсутствие ошибок в устройствах, если программа работает с ними (устройство всегда отрабатывает нормально) и т.д.

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

♦ повышает компетенцию алгоритмиста в реализации алгоритма (только идеальный вариант в алгоритмах это, как правило, в лучшем случае - половина разработки);

♦ существенно сокращает общее время отладки всего ПО, т.к. программы, построенные на соответствующих методах разработки (см. далее), сами сообщают о неисправностях и методах их устранений.

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

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

Класс программно – логических функций необходимо аксиоматизировать Аксиоматика избавляет от «проклятия смысла», ибо с её помощью функции реализуются в виде «кубиков». Это позволяет чётко разделить «логику» и «физику» функций. Если не аксиоматизировать функции, то каждый их реализатор будет сам придумывать свой способ реализации, т.е будет столько способов реализации сколько будет реализаторов функций, при этом обычно смешивают «физику» с «логикой», размазывая её по функциям.

Программное обеспечение (ПО). В данном подразделе под ПО подразумеваются и алгоритмы и программы по ним.. В условиях рыночных механизмов отношение к разработке ПО как к “искусству” (индивидуальное программирование) увеличивает время разработок и резко снижает коррекционную стойкость ПО. При коррекциях, которые, например, будут нужны заказчику через год, даже разработчик данного фрагмента ПО, созданного по принципу “искусства”, не может сделать их быстро и качественно. К сожалению, промышленного программирования в массовом масштабе до сих пор нет.

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

система (ФПО) -> подсистема -> комплекс -> программа (подпрограмма) -> модуль -> блок -> фрагмент -> команда.

Разбиение программ на модули. Как следует из данной выше логической структуры, программы должны быть разбиты на модули (программные части). К сожалению, разработка программ в несколько сотен и даже тысяч команд в виде монолитных мастодонтов вещь не такая уж редкая даже в 21-ом веке. Модули должны содержать несколько десятков строк (команд) и в идеале иметь один вход и один выход. Однако на практике для ФПО «один вход – один выход» не всегда удаётся создать. Например, если в алгоритме имеется переключатель и каждая «ветка» в нём реализуется несколькими десятками команд, рациональнее сделать модуль с переключателем, у которого будет столько выходов, сколько есть у переключателя, чем делать один громоздкий модуль, реализующий все ветки переключателя. Как показывает практика, общая методология процесса разбиения программ ФПО на модули должна строиться на том, чтобы при разбиении следовать «физике» процесса, даже если это приводит к увеличению числа входов и выходов в модули. Программа с таким разбиением более понятна (по названиям функций модуля), а уже после понимания принципа её работы легче будет разбираться с её входами и выходами. Если же разбить её на модули по принципу «один вход – один выход» логическое взаимодействие модулей будет простым и наглядным, но «физика реализации» будет скрыта за такой логикой взаимодействия модулей, т.к. приходится в этом случае, как правило, искусственно создавать «один вход – один выход», затемняя физику процесса. /В качестве примера, разработчик данного лекционного материала, в своё время, более месяца «разрезал» функциональный алгоритм, разработанный аппаратурщиком по заданной ему табличной форме, который при программной реализации потянул почти на 2 тысячи команд ассемблера. Некоторые модули в ней имели до пяти выходов. При комплексной отладке и опытной эксплуатации аппаратурщиками (разработчиками алгоритмов) было внесено несколько коррекций, которые, однако, не затронули связи между модулями/.

Листинг программного модуля должен быть самодостаточным (принцип самодокументируемости программ), т.е. в нем должна быть информация, позволяющая понять принцип программной реализации алгоритма. К такой информации можно отнести: название модуля, перечень реализуемых им функций, описание общего принципа реализации. Для блоков, реализующих часть функции, и фрагментов внутри блоков необходимо давать их развернутое название и принцип реализации. Комментарий для команд должен быть смысловым для реализуемой функции, а не повторением описания языковой команды. Принцип, выдвинутый ещё на заре программирования, вначале комментарий, а потом команда, никто не отменял (правда, даже тогда большинство программистов его «в упор» не замечали). Хороший комментарий при коррекциях, связанных, например, с расширением или изменением функций, особенно после длительной эксплуатации программы, экономит массу времени. Как указано выше, программа – продукт, отчуждаемый от разработчика, как и любая электронная схема. Также как в начерченной электронной схеме должны быть указаны номиналы всех её компонент, так и листинг программы должен объяснять не только в программной, но и в словесной форме как реализованы все компоненты программы.

Отладку, как программ, так и всего ПО необходимо проводить в два этапа:

● этап 1 - на программных имитаторах оборудования, ресурсов;

● этап 2 – на реальных компонентах (оборудование, ресурсы).

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

Некоторые компоненты программ. Программирование как процесс аналогичен работе мозга. Мозг воспринимает слова, которыми в нашем мире человек “кодирует” конкретные предметы и явления. Например, у нас нет в голове реального стула, книги и т.д., но по условному обозначению в русском языке “стол”, “книга” и т.д. мы понимаем, о каких предметах реального мира идет речь. При этом исходными компонентами для кодировки предметов реального мира для человека, говорящего, например, на русском языке, являются буквы и правила русского языка. Такой процесс кодировки называется абстрактным представлением конкретных объектов и явлений реального мира.

Для программиста исходными компонентами, которые он использует при работе, являются: память (ЗУ), рабочие регистры (РР) и порты ввода / вывода. Типы данных в этих компонентах представляют собой информационные объекты, с которыми работает машинная команда: бит, полубайт (4 бита), байт (8 бит), слово (16 бит), двойное слово (32 бита). Так как процесс работы с двоичными объектами для человека неудобен, были разработаны языки высокого уровня, приближенные к естественному (английскому) языку. Программист разрабатывает по алгоритму программу на таком языке и затем специальная программа преобразовывает (транслирует) предложения (команды) таких языков в машинный (двоичный) код, «понятный» ЦПр. В языках программирования компоненты обозначаются именами (так же как, например, в мозгу человека реальное дерево обозначается на русском языке словом дерево), с помощью которых, программист на выбранном языке программирования кодирует элементы реального процесса, заданные в алгоритме.

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

БУФЕР – специально отведенный участок памяти для промежуточного хранения данных. Принцип работы буфера аналогичен работе почтовых ящиков, в которые в произвольные моменты времени письма опускаются, а их выборка идет через определенные интервалы времени. В буфере реализуется следующий временной принцип: загрузка информации в буфер идет в произвольные моменты времени (т.е. в темпе реального времени), а разгрузка – через определенные моменты времени. Такой принцип работы позволяет, например, эффективно использовать буфер для работы с процессами, имеющими разные скорости.

Так как буфер физически - «кусок» памяти, то в нем различают два конца (образно «верх», «низ»). В буфере используются следующие принципы записи / чтения (вставки / удаления):

♦ запись / чтение проводится с разных концов;

♦ запись / чтение проводится с одного конца (стек).

СТЕК – программно – аппаратное средство, представляющее собой совокупность ячеек памяти (список), записи в котором вставляются и убираются с одного конца, называемого вершиной стека (списка). Такой тип доступа к записям реализует принцип: «последним вошел, первым вышел», т.е. последний вставленный в список элемент, удаляется первым из списка. В бытовой ситуации стековый принцип реализуется, например, при заполнении сумки продуктами. Вы постепенно заполняете сумку, при этом продукт, купленный первым, находится в самом низу, а самый последний – наверху. При разгрузке сумки первым достается продукт, положенный туда последним (он на самом верху). У этого принципа есть и другое название – магазинный, ибо он используется в оружии типа автомата, пистолета. В них имеется магазин, своего рода плоская коробка, в которой находятся патроны. При зарядке магазина патронами первый заряжаемый патрон оказывается внизу, а последний – наверху. При стрельбе первым выбирается патрон, заряженный последним.

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

ПРЕРЫВАНИЕ – сигнал, по которому процессор «узнает» о совершении асинхронного, относительно циклов его работы, события, которое ему нужно срочно реализовать (обработать). В разделе 1.3 рассмотрен принцип прерывания. Реализация его в ЦПр определяется следующей последовательностью действий.

■ При поступлении прерывания ЦПр заканчивает выполнение текущей команды в программе, которая им обрабатывается.

■ ЦПр запоминает состояние СчК и РР прерванной программы, записывая их в стек. Совокупность запомненных состояний программы называется ССП (слово состояния программы).

■ ЦПр начинает выполнять программу обработки данного прерывания.

■ После выполнения программы обработки данного прерывания ЦПр восстанавливает запомненное состояние прерванной программы и продолжает выполнять её так, как будто никакого прерывания и не было.

Наиболее типовыми событиями, вызывающими прерывание могут быть следующие:

● внешнее прерывание от датчиков;

● прерывание по таймеру, По окончании времени отработки, выставленном на таймере, происходит прерывание, по которому процессор «узнает», что время в таймере окончено;

● предопределённые события. Например, прерывания, специально «вставленные» в программу программистом;

● не предопределённые события, Например, при попытке программы осуществить неизвестное или запрещенное действие, приходит прерывание на которое реагирует операционная система;

● действия оператора.

В МПС имеется возможность маскировать (не замечать) некоторые прерывания. С этой точки зрения прерывания могут быть:

♦ не маскируемые, Они реализованы аппаратно и не управляются программистом. Это, как правило, прерывания «жизненно необходимые» для МПС, например, сообщение о неисправности какой либо программно - аппаратной компоненты;

♦ маскируемые. Могут управляться программистом. Они управляются специальными командами и имеют цель дать программисту возможность гибкого управления вычислительным процессом.