Cтраница 4
Существуют различные классификации инструментария. В приведенной классификации инструментарии расположены в порядке убывания трудоемкости, требуемой для создания с их помощью прототипа. Действительно, при использовании инструментария первого типа в задачу разработчика входит программирование всех компонент ЭС на языке довольно низкого уровня. Использование инструментария второго типа позволяет значительно повысить уровень языка, что, как правило, влечет за собой снижение эффективности. Инструментальные средства третьего типа позволяют разработчику не программировать некоторые или все компоненты ЭС, а выбирать их из заранее составленного набора. [46]
Дальнейшие исследования в данном направлении ориентированы на автоматизацию программирования, разработку систем представления результатов проектирования в машинно-читаемой форме и разработку систем документации. Хорошая документация на проект должна учитывать все достижения педагогики. Следует развивать автоматизацию синтеза оптимальных модульных структур, структур управления модульными программами, структур данных, а также автоматизированные системы, обеспечивающие учет и контроль взаимосвязей требований ТЗ с проектными решениями ТП, программами в кодах и рабочими инструкциями РП. Увеличение числа мини - и микро - ЭВМ и разработка типовых проектных решений и модулей программного обеспечения еще более усложняют задачи разработчиков. Требуется разработка методики синтеза модульных программ с учетом наличия библиотеки типовых модулей и реализации их на конкретных ЭВМ. [47]
Среди прочих устройств вычислительных систем центральные процессоры выделяются тем, что при их создании использовались самые различные методы, привлекались самые различные конструктивные решения и по сложности они в очень большой степени отличаются друг от друга. В последнее время организация устройств ввода - вывода, устройств передачи информации, устройств управления и запоминающих устройств испытывает тенденцию к упрощению и стандартизации. Разработки этих устройств в значительно большей степени ориентируются на использование стандартных модулей и блоков, чем разработки центральных процессоров. Подобное положение объясняется тем, что номенклатура операций, выполняемых всеми прочими устройствами машины, в настоящее время уже достаточно установилась и задача разработчика состоит в упрощении, уменьшении стоимости, увеличении эффективности и повышении надежности разрабатываемых им устройств. [48]
Предоставляемые логикой преимущества начинают приводить к отказу от подхода к реализации СБД, основанного на реляционных исчислениях, и в настоящее время ведутся многочисленные исследования, посвященные тому, как наилучшим образом заставить логику служить тем требованиям высокого уровня, которые предъявляются методологией СБД. Основное направление этих усилий связано с оптимизацией запросов и их анализом. Общепризнано, что языки запросов в СБД должны быть пригодными для употребления непрофессиональными пользователями, которые не обязаны сами иметь дело с механизмами хранения и поиска данных. С этой точки зрения запрос трактуется как спецификация, лишенная процедурных качеств. Задача разработчика состоит тогда в выборе наилучшего способа наложения запроса на базу данных. Одна из трудностей, возникающих при стандартном прологовском исполнении запросов, представленных целевыми утверждениями, заключается, как указывает Уоррен ( 1981), в том, что Пролог по умолчанию слепо следует текстуальному упорядочению подцелей в целевом утверждении, а это может оказаться чрезвычайно неэффективным способом. [49]
Вывод о том, каков или на сколько выше технический уровень данного оборудования, является понятием достаточно условным и может служить предварительной, ориентировочной оценкой перспективности данного оборудования. Окончательный вывод о качестве оборудования на любой стадии его разработки может быть сделан только на основании оценки уровня качества. Это обусловлено и тем, что качество нельзя рассматривать и оценивать в отрыве от экономических результатов производства и эксплуатации оборудования. Любое оборудование, отличающееся высоким техническим уровнем, но неэкономичное в производстве и эксплуатации, не может быть рекомендовано к внедрению. Поэтому в задачу разработчика и изготовителя входит создание оборудования не только с улучшенными ( по сравнению с существующими аналогами) техническими характеристиками, но также и обеспечивающего экономический эффект. [50]
Голографические и обычные оптические элементы имеют одно общее важное свойство: любой отдельный элемент может быть изготовлен так, что он будет иметь нулевые или малые аберрации для одной пары сопряженных точек. При этом для других сопряженных точек возникают аберрации. Чтобы избежать аберраций в некоторой протяженной области поля зрения или зрачка, в систему вводят дополнительные элементы. Параметры дополнительных элементов позволяют конструктору уменьшить аберрации системы в целом. В этом смысле задача разработчика состоит в том, чтобы определить, какие элементы и в какое место системы их нужно вставить, чтобы они действительно позволили устранить аберрации. [51]
На этом уровне цели тоже выражаются как действия или события, но их неопределенность намеренно сокращается. Когда определены промежуточные цели, проблема распадается па подзадачи. Каждая цель представляет предполагаемый результат, предлагаемый программой при решении частной проблемы. Они должны устанавливаться в начале, гак чтобы проектировщик имел ясное представление о задачах, которые должна решать система, и о подходе к их решению. Система может прийти к разнооЬразным выводам и рекомендовать различные стратегии поведения, и до тех пор, пока разработчик и пользователь не придут к соглашению, какие события должны быть выявлены в результате этих действий, не будет никаких гарантий в том, что получено нужное решение. Так как задача разработчиков состоит в том, чтобы наметить приемлемый путь к достижению этих целей-событий, они должны иметь конкретные представления об ожидаемых, ясно просматриваемых человеко-машинных характеристиках. [52]
Эти команды обеспечивают способность программы принимать решения. Вообще говоря, они проверяют значение или состояние регистра или индикатора и фиксируют результат проверки путем модификации счетчика команд. Следовательно, проверка может изменить нормальную последовательность команд в программе. Ветвление имеет место, когда счетчик команд загружается совершенно новым значением и управление передается новой части программы. Пропуск просто заставляет счетчик команд увеличить содержимое на единицу, так что следующая по порядку команда пропускается. Поскольку проверка различных условий производится в ЭВМ весьма часто, задача разработчиков электронных вычислительных машин состоит в том, чтобы обеспечить быстродействующие и экономичные средства определения состояния специальных индикаторов и соответствующей передачи управления программой. [53]