О X1 Y1 Р

Т Е

О З

К X2 Y2 П У

И О Л

Т Ь

Д О Т

А К А

Н Xn Yn И Т

Н О

Ы В

Х

Команда

 

рис.2.6.2 Принцип объединения процессоров машин класса ОКМД

 

На рис.2.6.2 дан принцип объединения процессоров машин класса ОКМД. Система из N взаимосвязанных процессоров (Пр1, Пр2, …, ПрN) обрабатывает на одной команде n потоков данных (X1, X2, …, Xn), преобразуя их в n потоков результатов (Y1, Y2, …, Yn).

Особенностью класса ОКМД является то, что за одну операцию в N процессорах выполняются:

♦ одинаковые команды;

♦ данные для таких команд в каждом из N процессоров различны.

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

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

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

Круг решаемых задач компьютерами данного типа, задачи со слабо связанными частями, т.к. в них требуется небольшой объем информации между процессорами. Это ограничение резко сужает сферу применения ОКМД.

 

► МКОД. (рис. 2.6.3).

 

 

 

Рис. 2.6.3 Принцип объединения процессоров машин класса МКОД

На рис.2.6.3 дан принцип объединения процессоров машин класса МКОД. На вход X подается поток данных и каждый процессор (Пр1, Пр2, …, ПрN) работает по своему потоку команд, передавая результаты работы на вход следующего процессора, последний из которых и выдает результат Y.

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

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

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

При всей привлекательности данного типа обработки информации он имеет существенное ограничение: все операции на всех процессорах должны быть равны по времени срабатывания. Это требование является системным для любого конвейера. Если операции на нем не синхронны по времени, то конвейер не может работать. Например, если i–й рабочий занимает на свою операцию время m, а (i + 1)–й рабочий – время k и m больше k на d (т.е. m = k + d), то (i + 1)-й рабочий, после окончания своей работы через время k, будет простаивать время d.

 

► МКМД. (рис.2.6.4)

 

 

 

 

 

Рис.2.6.4 Принцип объединения процессоров машин класса МКМД

На рис.2.6.4 дан принцип объединения процессоров машин класса МКМД. Класс является гибридом векторной и конвейерной схем и представляет собой матричную схему обработки. Такой мультипроцессор называется матричным, так как структурная схема представлена в виде матрицы и принцип работы также основан на обработке матриц. Каждый процессор за одну операцию обрабатывает один элемент матрицы, таким образом, за одну операцию параллельно обрабатываются все элементы матрицы. Чтобы получить такой же результат при использовании обычного процессора, надо обработать каждый элемент матрицы последовательно, поэтому и время вычисления значительно больше. Матричные процессоры – мощное устройство решения задач, характеризующихся высокой степенью параллелизма.

 

Машины потока данных (рис.2.6.5).Такие машины являются частным случаем классов Флинна и решают задачи, когда данные не известны, а генерируются в самой машине как промежуточные результаты. Это позволяет использовать описанные выше принципы параллельной обработки для решения громоздких вычислительных задач при отсутствии потока данных извне.

 

 

 

Рис. 2.6.5 Принцип построения машины потока данных

Мультипроцессор реализован по матричной схеме. Здесь потоки промежуточных результатов (данных) X1, …., Xn, получаемые в процессе решения задачи, являются исходными данными для последующих вычислений. Потоки команд K1, …, Km обеспечивают обработку поступающих на мультипроцессор потоков данных, а потоки результатов Y1, …, Yn поступают в ЗУ, чтобы стать потом потоками данных. Здесь процесс вычислений управляется не программой, а потоком данных, получаемых в процессе вычислений. Для этого выделяется свободный Пр той части программы, для которой имеются данные. Такое последовательное применение этого подхода приводит к тому, что заранее уже нельзя сказать, какой обработкой будет занят тот или иной процессор – все решится после его освобождения от предыдущей работы. И ему в соответствии с принципом управления данных поступает задача, для которой к этому моменту будут готовы данные. Так данные (точнее, моменты их появления в вычислительной системе) управляют вычислительным процессом. Чем больше процессоров, тем более эффективно применение этого подхода, т.к. меньше вероятность, что Пр будут простаивать в ожидании данных и данные в ожидании своего процессора.

 

 

2.7 СТРАТЕГИЯ РАЗРАБОТКИ МПС

ЦЕЛЬ – дать и обосновать стратегическое направление разработок МПС.

Как указывалось ранее, любой тип связи является частным случаем СРВ, которые имеют объект управления (ОУ) и устройство управления (УУ).

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

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

Анализ взаимосвязи компонент СРВ. Так как в СРВ имеются две взаимосвязанных компоненты (УУ и ОУ), то, естественно, возникает вопрос: откуда вести разработку?:

► от УУ к ОУ;

► или от ОУ к УУ.

► Разработка от УУ к ОУ. Обоснованием для такой стратегии разработки служит следующая «железная логика»: ФПО находится в компьютере, значит, нужен специалист, знающий компьютер. Но согласно такой «логике» и любой настройщик фортепьяно должен профессионально сыграть фортепьянный концерт потому, что фортепьянные концерты исполняются на фортепьяно, а он его великолепно знает. К сожалению, именно такой тип рассуждений, естественно, считающихся «логичными», распространён при разработках СРВ, в которых УУ является компьютером. Данное образное сравнение показывает нелепость принципа разработки «от УУ к ОУ». Значит, остаётся принцип «от ОУ к УУ», но не ясно, «почему так нужно, почему именно с ОУ?».

► Разработка от ОУ к УУ. Для логического обоснования такого направления разработки рассмотрим следующее образное сравнение. Нужно перевести какой – то груз. С чего начать решение данной задачи: с варианта «на чём перевести?» или с варианта «что перевести?». Элементарная логика подсказывает вариант: «что перевести?». Почему? Да всё зависит от груза. Если этот груз по габаритам и весу мал, то его может перевести (перенести) человек в сумке, если более крупный, то на машине, причем в зависимости от веса это может быть машина разной грузоподъёмности. Таким образом, только после того как определились с грузом, можно приступить к решению варианта «на чём перевести?».

В исходных алгоритмах ФПО реализуются специфические для данного ОУ процессы. Безграничное терминологическое разнообразие ОУ в различных СРВ не даёт возможности создать единые алгоритмы в конкретных терминах для всех типов ОУ (как например, в операционных системах УУ). Для специалиста, работающего с данным типом ОУ, вытащить логику работы (а именно она является базой алгоритмов ФПО) из физики конкретных процессов - трудная проблема, требующая времени и знания физики процессов ОУ («что перевести?»), а не УУ («на чём перевести?»). Но только после того, как будет качественно (начиная с системного уровня) алгоритмизирована логика процессов, к ней нужно подключать специалиста по УУ (компьютерщика)

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

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

Почему в Интернете и сетях нужен только компьютерщик? Интенсивно развивающиеся в последнее время различные типы сетей и Интернеттакже являются СРВ. Таким образом, и там есть ОУ и УУ, но именно при их разработке знание компьютера и необходимо и достаточно, т.е. разработчику сетей и Интернета нужно знать только компьютер. Почему так происходит? Дело всё в том, что ОУ в них является другой компьютер, и специалисту по компьютерам известно, не только сигналы из другого компьютера, но и как их обрабатывать, а также отдельные специфические нюанса такого ОУ. К сожалению, именно массовость развития этих направлений и выработала устойчивый стереотип мышления в виде необходимости вести разработки СРВ, в которых ОУ не является другим компьютером, от компьютера, т.е. для разработки программного ОУ привлекать специалистов по компьютерам как основных разработчиков.

Методологический принцип разработки ФПО. В условиях рыночной экономики разработку необходимо вести так, как это выразил основатель конвейерной системы в производстве Фредерик Тейлор (США): «Поймите точно, что Вы хотите сделать, и затем следите, чтобы это делалось наилучшим и самым дешёвым способом».

Методология разработки должна основываться на «бритве Оккама» – методологическом принципе, сформулированном английским философом Уильямом Оккамом в 14 веке в виде: «То, что можно объяснить посредством меньшего, не следует выражать посредством большего» (принцип бережливости или экономии гипотез). Этот принцип требует, чтобы любая научная гипотеза, объясняющая ряд фактов, основывалось на наименьшем числе предположений, т.е. наиболее правдоподобной является та гипотеза, которая основывается на меньшем количестве допущений. Как этот принцип применим к разработкам технических систем?

На начальных стадиях разработок прорабатываются несколько вариантов реализации системы. После этого возникает вопрос выбора варианта реализации. Но как выбрать, когда система ещё не готова? В этом случае необходимо использовать «бритву Оккама» в виде следующей модификации: «Из нескольких технических решений, обеспечивающих данные требования, наиболее простое в реализации является наиболее правильным». Синонимы «бритвы Оккама» в западных разработках известны как «принцип простоты». «элегантное решение», «максимум при минимуме». «Упрощайте сложное и вы получите самый существенный результат». / Английский историк и социолог Генри Бокль 19 век/.

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

Типология построения МПС. Типовая структура и типовая, структурная схема ПО базируется на положениях для СРВ, данных в разделе 1.5. Выбор варианта снятия информации от датчиков /например, телефонных аппаратов или мобильников/ (прерывание или сканирование) основывается на положениях, данных в разделе 2.4. Вообще, в сложных системах всё должно быть предсказуемо, а прерывания непредсказуемы. Сложные системы не должны «гоняться» за каждым прерыванием от датчиков СРВ, обрабатывая их.

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

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

 

К ним относятся:

♦ сопряжения основных устройств системы.

♦ представление передачи информации при взаимодействии пользователя с системой;

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

В МПС термин архитектура используется для описания принципа действия, конфигурации и взаимного соединения их основных логических узлов. Если рассматривать архитектуру определенного класса таких систем, то реализация конкретной системы из данного класса, может отличаться как на уровне физических компонентов аппаратных средств, так и на уровне способов реализации подсистем. Те или иные реализации также отличаются по производительности и стоимости. Детали реализации «невидимые» для пользователя не оказывают влияния на архитектуру. Общность архитектуры класса обеспечивает их совместимость с точки зрения пользователя.

Принципы разбивки ПО СРВ. Как с точки зрения функциональной реализации разбивается программное обеспечение (ПО) СРВ? Почему это важно? Анализ этого вопроса сразу же даёт стратегическое направление разработки, а правильно выбранное стратегическое направление резко снижает время и затраты на разработку. Образное сравнение: можно из СПб в Москву поехать как обычно, а можно и через Париж. Ясно, что если выбрано стратегическое направление через Париж, то не укладываются и в сроки и в деньги. При этом некого винить, что они бездельничают, (ведь человек то не сачкует, а едет).

Традиционной «разбивкой» ПО СРВ является деление его на:

♦ функциональное ПО (ФПО);

♦ операционную систему (ОС).

ФПО реализует функциональные процессы (т.е. процессы ОУ).

ОС реализует управление функциональных процессов в реальном времени.

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

Более правильной является следующее разделение.

ПО СРВ имеет следующие базовые компоненты (своего рода фундамент):

► функциональные процессы в ОУ, которые подлежат управлению в реальном времени;

► функциональные процессы в реальном времени (управление процессами ОУ в реальном времени);

► база данных (БД) функциональных процессов в реальном времени.

На основе такого «фундамента» строится всё программное обеспечение СРВ.

► Функциональные процессы в ОУ. Например, это установление различного рода соединений в различных АТС. Причём, это сами процессы без «привязки» их к УУ. Описание алгоритмов здесь идёт, естественно, в терминах функциональных процессов.

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

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

► База данных (БД) функциональных процессов в реальном времени. Здесь реализуются БД процессов в ОУ.

 

Что даёт такое деление? Оно чётко разграничивает работу:

♦ по направлению;

♦ и по специализации.

Что это такое?

Функциональные процессы в ОУ должен делать специалист в данном ОУ. Он и только он, а не компьютерщик. Для связи это специалист, знающий данный тип связи!

Функциональными процессами в реальном времени должен заниматься компьютерщик, ибо он хорошо знает инструменты УУ (т.е. компьютер) и может грамотно «уложить» функциональные процессы в реальном времени с точки зрения имеющихся инструментов в компьютере. Но задавать ему сам процесс, который нужно «уложить» в реальное время, должен специалист по функциональным процессам. Именно он должен ему объяснять логику и специфику этих процессов, а не он сам догадываться. Что задаст специалист по функциональным процессам в ОУ, то на компьютере и реализует компьютерщик. Таким образом, стратегией разработки на данном этапе «владеет» компьютерщик, но смыслом функциональных процессов – специалист по ОУ.

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

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

 

2.8 НЕКОТОРЫЕ ТИПОВЫЕ КОМПОНЕНТЫ ПРОГРАММНОЙ РАЗРАБОТКИ МПС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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