Реферат: Вопрос №3 Принципы проектирования информационного обеспечения программного комплекса

Содержание

Вопрос №1. Системный подход к проектированию программного обеспечения 2

Вопрос №2 Методы проектирования программного обеспечения (программных продуктов) 4

Вопрос №3 Принципы проектирования информационного обеспечения программного комплекса. 6

Вопрос №4 Показатели качества программного обеспечения 8

Вопрос №5. Методы создания надежного программного обеспечения 10

Вопрос №6 Ассемблеры. Определение. Области применения. 13

Вопрос №7 Управление ресурсами вычислительных систем 15

Вопрос №8 Классификация и организация прерываний в ОС 17

Вопрос №9 Общая характеристика (типы) операционных систем 20

Вопрос №15 Модели баз данных 25

Вопрос №16. Уровни отображения данных в СУБД 31

Вопрос № 17 Языки общения с СУБД (SQL, QBE) 32

Вопрос №18. Отличие баз данных от файловых систем 34

Вопрос №19 Методика проектирования имитационных моделей 37

Вопрос №21. Обработка списковых структур на языке Турбо Пролог. 39

Вопрос №22. Организация рекурсивных структур на Прологе. 46

Вопрос №23. Системы ИИ. Фреймы, семантические сети и процедуры. 51

Вопрос №24. Экспертные системы. Цель, состав и принципы функционирования. 57

Вопрос №25. Техническое и программное обеспечение глобальных компьютерных сетей (INTERNET). 62

Вопрос №26. Типы, стандарты протоколов компьютерной сети. 67

Вопрос №27. Топология компьютерных сетей. 71

Вопрос №28. Технические средства передачи информации. 73

Вопрос № 29 Многоуровневая модель взаимодействия компьютерных сетей 77

Вопрос № 31 Оценка производительности ЭВМ 79

Вопрос №33 Привилегии в ПЭВМ. Слово состояния программы. 83

Вопрос №34 Управление выполнением последовательности команд. 84

Вопрос №36 Приоритетное обслуживание прерываний 87

Вопрос № 37 Страничная адресация памяти 90

Вопрос № 38. Способы адресации в ПЭВМ с 32-х разрядной архитектурой 93

Вопрос №35 Передача данных с прямым доступом к памяти 98

Вопрос №35 Формирование адресов микрокоманд. 100

Вопрос №46 Функциональные узлы комбинационного и последовательного типа. 104

Вопрос №47 Понятие функционирования сети Петри. 108

Вопрос №48. Задание автоматов с помощью таблиц переходов и выходов. 110

Вопрос №49. Построение закона функционирования управляющего автомата Мили по граф-схеме алгоритма. 111



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

^ 1. Определение и содержание проектирования

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

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

С системотехнической точки зрения в практику будущей работы) проектирование в общем случае включает следующие фазы: замысла, исследования возможностей, - фазы системного проектирования (СП); разработки и конструирования, включая и такую же схему испытаний объекта проектирования – фазы основного проектирования (ОП).

^ 2. Системное проектирование

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

а) определение назначения СТК;

б) формирование требований в разрезе установленного назначения;

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

г) выбор принципиальных положений по созданию, использованию и ликвидации системы;

д) предварительная оценка потребных ресурсов;

е) предварительная оценка экономической эффективности и допустимости в экологическом отношении.

Истоками замысла являются потребности социальной среды. Социальные условия определяют состав задания на проектирование системы, которое формирует заказчик. С организационной точки зрения, основное в фазе «замысла» - это взаимодействие разработчика с заказчиком по вопросам отработки задания на разрабатываемую систему. Сформированное и согласованное задание – первый важнейший документ на создаваемую систему.

Задание на систему обычно имеет следующие особенности:

а) заказчик ориентирует требование к системе на её назначение и, как правило, уделяет мало внимания вопросам реализуемости системы;

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

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

Следующая фаза – исследование возможностей начинается ещё до окончания предыдущей, так как уже в фазе замысла осуществляется определённая оценка и изучение возможностей.

В достаточно сложных случаях эта фаза связана с развёртыванием НИР и ОКР. В менее сложных случаях обходятся оценочными расчётами и общим логическим анализом на базе существующего опыта и творческих возможностей.

Основные ограничения, которые всегда должны учитываться, включают:

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

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

в) особенности графика проектных работ – требование плотного графика может привести к согласованию заниженных технических и экономических показателей системы;

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

При проведении указанных работ решаются следующие задачи:

а) изыскание новых принципов построения системы, отвечающей заданным требованиям;

б) разработка на базе известных принципов инженерных методов проектирования;

в) определение методов оптимизации характеристик системы.

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

^ Задача разработки способов оптимизации преследует цели: минимизация стоимости, объёма, веса, обеспечения максимума надёжности, ремонтопригодности и т.д. и должна решаться в процессе создания методов проектирования.

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

^ Значимость решений на стадии системного проектирования наиболее высока, поскольку принятые здесь решения не только во многом предопределяют эффективность будущей системы, но и обеспечивают рациональное использование ресурсов, которыми располагают и заказчик и разработчики. В свою очередь оптимальность решений существенно зависит от правильного выбора показателя и критериев эффективности.

Итогом системного проектирования служит документ, который должен содержать:

обоснование предлагаемых решений;

достаточно подробное описание работы всей системы в целом;

чёткое описание подсистем;

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

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

^ Эффективность системного проектирования определяется полнотой и обоснованностью формулируемых заданий и требований и совершенством принятых методов оценки эффективности.
^ Вопрос №2 Методы проектирования программного обеспечения (программных продуктов)
Процессы проектирования всей системы и отдельных программ во многом подобны друг другу. Но в отличие от системы каждая программа имеет единственное функциональное назначение и не может быть разбита на части, используемые в различные моменты времени. Сходство программы с системой заключается в наличии внешних и внутренних потоков данных, областей хранения данных, а, также в возможности разделения ее на независимые модули, которые можно разрабатывать и настраивать отдельно.

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

Методы проектирования программ, основанные на модульном принципе, делятся на три группы:

методы нисходящего проектирования,

методы расширения ядра

методы восходящего проектирования.

На практике обычно применяются различные сочетания этих методов.

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

^ 1. Метод нисходящего проектирования

Метод нисходящего проектирования подобен методу получения детального изображения из более общего вида с помощью телескопического увеличения. На начальном шаге формируется предложение, описывающее функцию всей программы. Затем определяются ее подфункции. Эта процедура является рекурсивной, т. е., следуя ей, каждая из подфункций может расчленяться до тех пор, пока ее составные части не будут окончательно уточнены. Метод нисходящего проектирования, иногда называемый функциональной декомпозицией, основан на двух стратегиях: пошаговом уточнении и анализе сообщений. Эти стратегии отличаются способами определения начальных спецификаций, методами, используемыми при разбиении задачи на части, и правилами записи.
^ Пошаговое уточнение
При пошаговом уточнении на каждом следующем этапе декомпозиции определяются программы очередного, более низкого уровня. Для этого используются процедурные языки программирования.

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

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

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

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

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

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

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

^ 2. Метод расширения ядра

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

^ Спецификация модуля

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

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

После того как выбраны алгоритмы, структуры данных и методы доступа, связи между модулями перестраиваются.

^ Метод иерархического проектирования модулей

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

^ 3. Метод восходящего проектирования

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

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

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

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

^ 1. Строгость и формальность

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

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

^ 2. Разделение задач

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

3. Модульность

Сложная система может быть разделена на простые части - модули тем, состоящая из модулей, называется модульной. Главное преимущество Модульности заключается в том, что она позволяет применить принцип разделения задач на двух этапах: при работе с элементами каждого модуля. Сдельно (игнорируя элементы других модулей) и при работе с общими Характеристиками всех модулей и отношениями между ними с целью объединить их в когерентную систему. Если данные этапы выполняются в последовательности, предусматривающей сначала концентрацию на модулях, а затем - их объединение, то говорят, что система проектируется снизу вверх; если, наоборот, сначала систему разбивают на модули, а потом работают над их индивидуальным проектированием, то это - проектирование сверху вниз.

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

4. Абстракция

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

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

^ 5. Предусмотрение изменений

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

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

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

Факторы, влияющие на качество программного обеспечения, классифицируются по трем аспектам программного продукта:

рабочие характеристики;

приспособленность к внесению изменений;

приспособленность к изменению окружающей обстановки.

К первой группе можно отнести следующие характеристики:

правильность (корректность), характеризующая степень функционального
соответствия программного обеспечения требованиям пользователя;

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

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

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

• целостность определяет степень, с которой может быть проконтролирован несанкционированный доступ к данным и программам.

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

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

•^ Удобство и простота тестировани^ Вопрос №6 Ассемблеры. Определение. Области применения.
Языки программирования для микро-ЭВМ можно разде­лить на три основных уровня: машинные, алгоритмические высокого уровня и ассемблера.

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

^ Языки ассемблера, занимая промежуточное положение между машинными языками и языками высокого уровня (будучи при этом гораздо ближе к машинным языкам), объединяют в себе некоторые достоинства самого нижнего и самого верхнего уровней языков программирования.

Свое название языки ассемблера получили от имени про­граммы, преобразующей программу, написанную на таком языке, в машинные коды.

Язык ассемблера, обеспечивая возможность символи­ческих имен в программе и избавляя программиста от уто­мительной работы по распределению памяти ЭВМ для переменных и констант, существенно облегчает труд про­граммиста и повышает его производительность по сравне­нию с программированием на машинном языке. Язык ас­семблера позволяет также гибко и полно реализовать тех­нические возможности ЭВМ, как и машинный язык. Транс­лятор программ с этого языка, т. е. ассемблер, гораздо проще и компактней транслятора программ, требующегося для алгоритмического языка высокого уровня, а результи­рующая машинная программа на выходе ассемблера мо­жет быть столь же эффективной, как и программа, которую сразу написали на машинном языке. Поэтому неудиви­тельно, что первым транслятором, который создается для новой ЭВМ, является обычно ассемблер. Это особенно справедливо для микро-ЭВМ, в которых ограниченный объем основной памяти может значительно усложнить за­дачу создания транслятора с языка высокого уровня и заставить разработчиков программного обеспечения в течение долгого времени довольствоваться языком ассемблера.

На языке ассемблера, как правило, программируется операционная система микро-ЭВМ или по крайней мере наиболее ответственные и «узкие» места в такой системе, а также в ряде других сложных систем обработки данных.

Таким образом, язык ассемблера и сам ассемблер обычно составляют основу для создания программного обеспечения микро-ЭВМ и, в частности, операционных систем и систем реального времени, к которым предъявля­ются высокие требования с точек зрения объема занимае­мой машинной памяти и скорости выполнения программ.

Каждый язык ассемблера является машинно-зависи­мым языком и отражает аппаратурные особенности (в ча­стности, состав программно-доступных регистров) той микро-ЭВМ, для которой он создан. Их команды прямо и однозначно соответствуют командам программы на машинном языке. Чтобы ускорить процесс коди­рования программы на языке ассемблера, были разработаны и включены в ассемблеры так называемые макропроцессоры. Програм­мист пишет макрокоманду как указание необходимости выполнить действие, описываемое несколькими командами на языке ассемб­лера. Когда макропроцессор во время трансляции программы чи­тает макрокоманду, он производит макрорасширение — т. е. гене­рирует ряд команд языка ассемблера, соответствующих данной макрокоманде. Таким образом, процесс программирования значи­тельно ускоряется, поскольку программисту приходится писать меньшее число команд для определения того же самого алгоритма.

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

Обратимся к толковому словарю

^ А. 143 assembler

ассемблер

1. Программа, используемая для пре­образования исходной программы на языке ассемблера в машинный код или перемещаемую программу.

assembly language

язык ассемблера

Система обозначений, используемая для представления в удобочитаемой форме программ, записанных в машинном коде. Язык ассемблера позволяет про­граммисту пользоваться алфавитными мнемоническими кодами операций, по своему усмотрению присваивать сим­волические имена регистрам ЭВМ и памяти, а также задавать удобные для себя схемы адресации (А.055 addres­sing schemes) (например, индексную или косвенную адресацию). Кроме того, он позволяет использовать раз­личные системы счисления (например, десятичную или шестнадцатеричную) для представления числовых кон­стант и дает возможность пользова­телю помечать специальными метками (L.001 label) строки программы с тем, чтобы к ним могли обращаться (по символическим именам) другие части программы, например в случае пере­дачи управления или при переходах.

^ Вопрос №7 Управление ресурсами вычислительных систем
При рассмотрении операционной системы, как совокупности программ, управляющих ресурсами, то каждый компонент управления конкретным устройством должен выполнять следующие функции:

Отслеживать состояние ресурса

Определять, кто получает, что и в каком количестве.

Выделять ресурс.

Освобождать ресурс.

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

Мониторы реализуются в форме некоторого объединения проце­дур доступа к ресурсам, которые он распределяет процессам-по­требителям по формализованным запросам. В составе монитора находится локализованная в них управляющая информация, необ­ходимая для организации такого доступа. Помимо этого монитор содержит механизмы и средства, которые используются при распределении ресурсов с учетом их характерных свойств. Такие ме­ханизмы строятся на основе классификационной схемы ресурсов. В состав системы распределения ресурсов входят следующие механизмы распределителя активных ресурсов; распределения пассив­ных ресурсов; виртуализации ресурсов создания и уничтожения ресурсов; ранжирования ресурсов, управления тупиковыми ситуациями; функциональной избыточности; учета ресурсов; контроля работоспособности твердых ресурсов, а также средства реконфигурации системы ресурсов; человеко-машинные средства общения.

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

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

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

выбрать приемлемое правило удовлетворения запросов на каж­дый из р