Студопедия

Главная страница Случайная лекция


Мы поможем в написании ваших работ!

Порталы:

БиологияВойнаГеографияИнформатикаИскусствоИсторияКультураЛингвистикаМатематикаМедицинаОхрана трудаПолитикаПравоПсихологияРелигияТехникаФизикаФилософияЭкономика



Мы поможем в написании ваших работ!




на входе регистр

Читайте также:
  1. V. Регистрация и лицензирование страховых организаций.
  2. Аналитические регистры НУ
  3. Аппаратура оповещения и регистрации
  4. АЦП с регистром поразрядного уравновешивания
  5. В процессе учетной регистрации на основе бухг. документов, когда устанавливается факт неправильной контировки.
  6. Взаимосвязь ГКН с регистрацией прав на объекты недвижимости.
  7. Вопрос 3. Порядок гос регистрации, реорганизации и ликвидации НКО.
  8. Гидроприводы с последовательным расположением дросселя на входе в гидродвигатель
  9. Государственная регистрация
  10. Государственная регистрация интеллектуальной деятельности и средств индивидуализации.

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

Как реализуется управление устройством в МПС по рис.2.3.2?. Для этого разрабатывается программа, которая после её запуска:

♦ формирует очередную команду в устройство и записывает её в порт вывода;

♦ устройство, получив команду, отрабатывает её и выдаёт состояния КТ (реакция устройства) после отработки выданной команды, которые записываются в порт ввода;

♦ программа анализирует состояния КТ. Анализ идет сравнением считанного и эталонного состояний КТ, который находится в программе в виде константы;

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

Разработанная программа записывается в ЗУ микропроцессора. Далее фон неймановский принцип работы с реализацией указанных функций для каждой команды.

 

2.4 СИСТЕМЫ СВЯЗИ КАК СРВ

ЦЕЛЬ – показать идентичность различных типов связи основным принципам построения СРВ.

Рассмотрим типы связи в понятиях СРВ, данных в главе 1 и разделах 2.1, 2.2, 2.3.

Итак, режим реального времени, это режим работы вычислительной системы, при котором обработка данных о процессах, происходящих во внешней среде, происходит в том же темпе, что и сами процессы. Исходя из данного определения, вычислительная система является инструментом в виде СРВ. Назначение такого инструмента, как указано в определении, обеспечивать обработку данных о процессах, происходящих во внешней среде. Для систем связи внешней средой являются абоненты, которым нужно:

♦ соединиться друг с другом;

♦ с целью передачи различных видов информации (разговор, данные, изображение).

Любой тип связи в понятиях СРВ, рассматривается как система массового обслуживания реального времени.

Так как все виды связи являются частным случаем СРВ, то все рассмотренные в главе 1 свойства СРВ, принадлежат и системам связи. Так, например, принцип управления соединениями абонентов состоит в «проталкивании» процессов соединения от одного действия до следующего действия. Абонент «руководит» действиями, а система связи «реализует» руководство, выдавая соответствующую информацию абоненту и создавая для него разговорный тракт.

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

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

На основе раздела 2.3 можно обобщить программную начинку МПС на уровне портов ввода/вывода в виде следующей структурной схемы (рис.2.4.1).

 

 
 

 

 


Рис.2.4.1 Обобщённая структурная схема программной начинки МПС на уровне портов ввода/вывода

Из схемы на рис.2.4.1 видно, что любая МПС:

■ с портов ввода принимает информацию;

■ комплекс программ, находящийся в ней, перерабатывает её;

■ и выдаёт переработанную информацию в порты вывода.

На вопрос «а что же входит в комплексы программ?» даёт ответ рис.1.5.2. Объединив рис.1.5.2 и 2.4.1 получаем рис.2.4.2. Здесь порты ввода/вывода условно обозначены через П.

 

 
 

 


 

Рис.2.4.2 Типовая структура МПС как детализация структуры СРВ

/Рисунок 2.4.2 даёт наглядное подтверждение того, зачем нужно знать и понимать, что такое СРВ? Зная и понимая типовые структуры СРВ, не так уж трудно разработать конкретную структуру конкретной МПС./

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

 

 

 


Рис.2.4.3 Передача информации в различных типах связи

 

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

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

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

►база данных процессов в реальном времени.

На основе такого «фундамента» строятся остальные программные компоненты СРВ.

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

Примеры связи как СРВ. Рассмотрим АТС, сотовую связь, IP-телефонию и сети передачи данных в понятиях СРВ.

АТС. Датчиками и потребителями в АТС являются стационарные телефоны, в сотовой связи – сотовые телефоны, в IP-телефонии – компьютеры, в сетях передачи данных - терминалы. Средой являются абоненты, которые работают со своими аппаратами, выдавая из них сигналы Xi и получая сигналы Yj.

Например, сигналами Xi для АТС могут быть поднятие и опускание трубки, набор номера; для сотовой связи - различные манипуляции с клавишами сотового телефона; для IP-телефонии - различные манипуляции с клавишами компьютера.

Сигналами Yj для АТС являются различные сигналы из АТС (например, сигнал «занято»); для сотовой связи – подаваемые на сотовый телефон голосовые, звуковые сигналы или информация на дисплее; для IP-телефонии – те же типы сигналов и информации, что и на сотовый телефон, но подаваемые на компьютер.

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

Типовая, структурная схема АТС в понятиях СРВ дана на рис.2.4.4.

 

 
 

 


Рис.2.4.4 АТС как система реального времени

Условные обозначения на рис.2.4.4:

ТА – телефонные аппараты;

Xi - сигналы и информация от абонентов в АТС;

Yj - сигналы и информация от АТС к абоненту;

Xk – сигналы и информация от других АТС;

Ym – сигналы и информация к другим АТС.

 

Всё изложенное выше действительно для сотовой связи и IP-телефонии.

Сотовая связь. На рис.2.4.5 дана типовая структурная схема сотовой связи.

 
 


Рис.2.4.5 Типовая структурная схема сотовой связи как СРВ

Условные обозначения на рис.2.4.5:

МТ – мобильные телефоны пользователей;

Сота – условное обозначение компоненты (ячейки), каждая из которых обслуживается отдельной базовой радиостанцией небольшой мощности, находящейся в центре ячейки;

Xi - сигналы и информация от мобильного телефона;

Yj - сигналы и информация от соты к мобильному телефону;

ЦК – центр коммутации (на рисунке показано два центра коммутации)

ТфОП – телефонная сеть общего пользования

 

 

IP-телефония. На рис.2.4.6 дан один из вариантов IP-телефонии.

 

 

 
 

 


Рис.2.4.6 Один из вариантов IP-телефонии

 

IP-телефония это технология, позволяющая использовать Интернет для ведения телефонных разговоров в режиме реального времени. /Аббревиатура IP расшифровывается как Internet Protocol – межсетевой протокол/. Использование Интернет позволяет резко удешевить телефонные разговоры, особенно междугородные и международные. Для организации связи используется специальное устройство – шлюз (gateway).

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

♦ с одной стороны шлюз подключается к телефонным линиям;

♦ с другой стороны шлюз подключается к компьютеру, который подключён к IP сети и может связаться с любым компьютером в мире.

Таким образом, абонент может связаться с любым телефоном в мире, также подключённым через шлюз в сети.

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

От шлюза к абоненту. Для пакетов, приходящих из IP сети в шлюз и направляемых в телефонную линию, операция происходит в обратном порядке.

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

 

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

Выход из такой ситуации был найден в периодическом снятии информации с датчиков, а не в прерывании от каждого из них. Наиболее наглядно этот принцип можно показать на коммутационном оборудовании программных АТС, в которых он определяется как сканирование устройств (периодический просмотр состояний устройств). Всё оборудование объекта управления снабжено датчиками состояния (в программных АТС они называются “контрольные точки” (КТ)). Все КТ программно - доступны, т.е. их состояния можно считывать из памяти (ЗУ). Специальные программы (программы сканирования) периодически (по таймеру) проводят опрос состояния КТ (так называемые “циклы сканирования”) для каждого типа оборудования. Снятые в цикле сканирования текущие состояния КТ сравниваются с состояниями в предыдущем цикле. При сравнении выделяются те КТ, которые изменили свое состояние по сравнению с предыдущим циклом. Таким образом, за один цикл (опрос состояний) выявляется всё то оборудование, которое изменило свое состояние. Затем вся группа изменений задаётся как входная информация в соответствующие программы. Таким образом, исключается очередь к программам. Например, на таком принципе построено определение состояний «абонент поднял/опустил МТТ».

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

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

 

 

2.5 МУЛЬТИПРОГРАММНЫЕ, МУЛЬТИПРОЦЕССОРНЫЕ И КЛАСТЕРНЫЕ СИСТЕМЫ

ЦЕЛЬ– дать базовые принципы компьютерных систем, работающих с несколькими независимыми программами, которые реализуются на одном или нескольких процессорах.

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

Итак, исходными понятиями являются:

независимые программы, каждая из которых реализует какой – то процесс,

процессоры (один или несколько), на которых реализуются эти программы.

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

В качестве аналога, поясняющего принцип работы нескольких независимых программ (процессов) на одном Пр, рассмотрим работу с очередью к одному кассиру в универсаме. В этой аналогии кассир интерпретируется как один Пр, а покупатели в очереди – как независимые программы (процессы). Если считать, например, что за 5 мин. кассир обслуживает 3 человека, то можно сказать, что на уровне кванта времени 5 мин., он обслуживает их одновременно (т.е. каждые 5 мин. – 3 чел.). В определении этот факт обозначается как «задействованы несколько», однако в каждый момент внутри этих 5-ти мин. (например, через 1 сек), он обслуживает только одного покупателя из этих 3-х.. Аналогично работает и один Пр с несколькими независимыми программами. Если рассматривать работу такого Пр на уровне кванта времени, бо’льшего чем время выполнения одной команды, то за счет своей большой скорости он успевает обслужить все процессы одновременно. Однако, на уровне выполнения любой команды в Пр, он работает только с одной программой (процессом).

 

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

Такая система всегда мультипрограммна. Такой режим обработки не нужно путать с мультипрограммной обработкой на одном Пр, т.к. в этом варианте любая команда в Пр реализуется только на одном Пр, а здесь команды одновременно на всех Пр. На рис. 2.5.1 в виде схемы показана взаимосвязь между количеством Пр и типом системы.

 

СИСТЕМА Мультипрограммная Мультипроцессорная реализация реализация на одном или нескольких всегда на нескольких Пр Пр всегда мультипрограммна    

 

 


Рис. 2.5.1 Взаимосвязь между количеством Пр и типом системы

 

Управление в таких системах может быть:

♦ общим;

♦ распределенным.

 

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

 

♦ Распределённое (децентрализованное) управление является базовым при создании распределённых вычислительных систем, характеризующихся наличием отсутствием единого центра управления и наличием нескольких центров обработки данных. К таким системам относятся компьютерные сети, в которых нет единого центра управления. Конструктивно такие системы могут быть:

мультипроцессорные;

кластерные.

 

Мультипроцессорные. В них для всех процессоров общими являются:

● операционная система, которая кроме типовых функций управления (распределения времени и памяти) занимается управлением вычислительной нагрузки между процессорами;

● память, включая оперативную (ОЗУ) и дисковую (диски);

● периферийные устройства.

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

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

Преимущества таких систем:

♦ Высокая производительность. Она достигается за счёт параллельной работы всех компьютеров в системе.

♦ Отказоустойчивость. Система способна продолжать работу при отказах отдельных элементов (например, процессоров, блоков памяти), хотя при этом её производительность и снижается, но не до нуля.

 

Кластерные (многомашинные) (анг. cluster – блок, группа)) - система, состоящая:

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

● и имеющая программно – аппаратные средства связи компьютеров в систему.

Избыточность в них организована на уровне компьютеров.

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

/В чём отличие мультипроцессорных и кластерных систем?/

Исторически многомашинные (кластерные) системы появились после создания сравнительно дешевых компьютеров на базе микропроцессоров. На определённом этапе развития появилась потребность в объединении нескольких компьютеров в единую систему (сети передачи данных).

 

 

 

2.6 СУПЕРКОМПЬЮТЕРЫ

ЦЕЛЬ – анализ методов повышения производительности МПС, определение суперкомпьютера и их классификация.

Принципы повышения производительности МПС. Необходимость повышения скорости работы МПС связана с появлением всё более сложных задач для удовлетворения потребностей человека. В СРВ такая необходимость порождается потребностью обработки мощных потоков информации от датчиков.

Проблема повышения скорости работы МПС привела к разработке суперкомпьютеров, т.е. компьютеров, имеющих производительность более 100 млн. оп./ сек.

Наиболее очевидным принципом повышения производительности компьютера является увеличение скорости работы его ЦПр. Пока это наиболее массовое направление разработок в создании коммерческих процессоров. Однако скорость работы базируется на физике процессов, проходящих в микросхемах. Наиболее значимыми из них являются:

♦ конечная скорость распространения электрических сигналов (не больше скорости света (300 тыс. км./ сек.));

♦ увеличение тепловых шумов при уменьшении размеров микросхем.

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

Другим направлением повышения производительности МПС является объединение типовых (сравнительно «медленных») микропроцессоров в единое целое – суперкомпьютеры, достигающие сверхвысокой производительности. Направлением решения такой задачи является распараллеливание (параллельная обработка), принцип которой заключается в одновременном решении разных частей одной задачи на разных процессорах, объединенных в единое целое (Потренируйтесь в выделении ключевых слов, в данном описании принципа).

Пример. Пусть нужно решить за T = 100 с. задачу, требующую N = 10.000.000.000 машинных операций. Для этого нужно взять компьютер со скоростью N/T = 10.000.000.000 : 100 = 100.000.000 оп./ сек. Предположим, что таких процессоров нет, но есть процессоры производительностью V = 1.000.000 оп./сек. Тогда если задача допускает распараллеливание, нужно взять 100 таких процессоров, разбить задачу на 100 частей, и они одновременно, проработав каждый над своей частью 100 сек., выполнят всю задачу.

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

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

 

Виды распараллеливания по классификации Флинна. Виды параллелизма основываются на классификации Флинна, которая ведется по двум типам потоков информации в вычислительных системах (рис.2.6.1):

♦ параллелизма потока команд;

♦ параллелизма потока данных.

 

 
 

 


Рис. 2.6.1 Классификация параллелизма по Флинну

 

В таблице на рис.2.5.1 на пересечении строк и столбцов указаны абревиатуры классов параллелизма:

ОКОД (одиночный поток команд – одиночный поток данных);

ОКМД (одиночный поток команд – множественный поток данных);

МКМД (множественный поток команд – одиночный поток данных);

МКМД (множественный поток команд – множественный поток данных).

 

► ОКОД представляет собой обычный МП последовательной обработки, который в каждый момент времени, обрабатывает один набор данных с помощью одной команды. МП именно этого класса являются «базовыми кирпичиками» для построения остальных классов МПС.

 

СУПЕРКОМПЬЮТЕРЫ.

►ОКМД (рис.2.6.2) /Для простоты на рис. 2.6.2 – 2.5.5 показаны принципы построения на уровне объединяемых процессоров без остальных компонент мультипроцессорной системы/.

 

 

П

О 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 бита). Так как процесс работы с двоичными объектами для человека неудобен, были разработаны языки высокого уровня, приближенные к естественному (английскому) языку. Программист разрабатывает по алгоритму программу на таком языке и затем специальная программа преобразовывает (транслирует) предложения (команды) таких языков в машинный (двоичный) код, «понятный» ЦПр. В языках программирования компоненты обозначаются именами (так же как, например, в мозгу человека реальное дерево обозначается на русском языке словом дерево), с помощью которых, программист на выбранном языке программирования кодирует элементы реального процесса, заданные в алгоритме.

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

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

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

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

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

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

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


<== предыдущая страница | следующая страница ==>
ВВОД / ВЫВОД | Многоэлектронные атомы

Дата добавления: 2014-08-09; просмотров: 487; Нарушение авторских прав




Мы поможем в написании ваших работ!
lektsiopedia.org - Лекциопедия - 2013 год. | Страница сгенерирована за: 0.027 сек.