Введение

Введение

Разработка системного программного обеспечения - это прямая задача системного программиста. Более того разработка не есть конечный пункт его деятельности. Совершенное владение этим инструментом - вот главная задача. Системное программирование является одной и наиболее широкой областью программного обеспечения. Главным преймуществом его является непосредственная гибкость и направленность на достижение определённой задачи. Логика и формальность - ключ к системному программированию.

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

Разработанный язык в данной программе по классификации

Хомского относится к автоматной грамматике, т. к. последнее звено декомпозиции удовлетворят правилу построении такого рода грамматик.

Замечание: пункт 6, 7, 8 не являются правилами вывода, а лишь служат для отражения семантической и синтаксической стороны грамматики.

Для наглядного изображения работы программы представлено

дерево функционального вызова (рис 1). На нём можно проследить

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

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

Рис 1. Функциональное дерево вызова. Элементы И и ИЛИ определяют выборочность при вызове функции. Т. е. в случае элемента И выполнится как первая так и вторая функция. Для элемента ИЛИ вызов функции определяется однозначно.

			TREATMENT
	&	&	&	&	&	&
TYPE	BRACKET	TERM	SIGN	TERM	BRACKET	FUNC	TZ
		1		1		&
	DIGIT	IDENT	DIGIT	IDENT	TERM	BRACKET

Расшифровка:

1. TYPE - функция TYPE(«набор терминальных символов»). В данном случае представляется TYPE(«if»). Сканирует соответствующие терминальные символы и выдаёт сообщение об ошибке в случае несоответствия текущего и входного языков.

2. BRACKET - функция (англ. «скобка»). В данном случае имеет вид:

BRACKET(1) -параметр функции характеризует тип скобки.

1 - открывающаяся 2 -закрывающаяся 3 - и та и другая

3. TERM - функция TERM(). Сканирует на терм-конструкцию.

4. SIGN - функция SIGN() (англ. «знак»). Сканирует знак.

5. DIGIT - функция DIGIT() (англ. «цифра»). Сканирует на целое число.

6. IDENT - функция IDENT() (сокр. «идентификатор»). Сканирует на идентификатор.

7. FUNC - функция FUNC(), сканирует на функциональную конструкцию.

8. TZ - функция TZ() (сокр. «точка с запятой»), сканирует точку с запятой.

TYPE BRACK TERM SIGN

FUNC TZ

рис. 2 Функциональная схема работы программы. Каждому входу элемента соответствует свой выход.

Данная функциональная схема отражает работу программы с точки зрения вызова функции. Начало работы программы идёт с подачи на вход блока TYPE управляющего терминального символа IF. После его обработки идёт запрос следующего функционального блока, отвечающего за обработку терминальных символов «(» и «)». Затем сигнал подается на вход устройства, соответствующего терминальным символам TERM и т. д.

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

Задача: принадлежит ли грамматике языка следующее синтаксическое предложение:

IF ( A < B ) BULL () ;

Для решения задачи обратимся к имеющемуся входному

языку G <Оператор>.

Любой язык, назовём его G <Z> в независимости от его классификации и функционального назначения содержит следующие базисные элементы: G <Z> ={ Vt, Vn, Z, P }, где:

Vt - словарь терминальных символов

Vn - словарь нетерминальных символов

Z - начальный нетерминальный символ

P - множество правил вывода

Для языка G <Оператор> имеем следующие множества:

Vt ={ 0, 1, 2, ... , 9 ; a, b, c, d, ... ,z ; A, B, C, ..., Z; <, >, = };

Vn ={«Оператор», «УслВыр», «Терм», «Операнд», «Функция», «Идентификатор», «Скобки», «Целое» };

Z = { «Оператор» };

P = {

1. < Оператор > à IF ( < УслВыр > ) < Функция >; [ ELSE < Функция >; ]

2. < УслВыр > à T | < УслВыр > < T | < УслВыр > > T | < УслВыр > = Т

3. < Терм > à O | «Целое»{ «Целое» } | «Идентификатор»{ О }

4. < Функция > à O< Скобки > | О{ О }< Скобки >

5. < Операнд > à «Целое» | «Идентификатор»

6. < Целое > = { 0, 1, 2, 3, ... , 9 }

7. < Идентификатор > à { a, b, c, d, ... , z; A, B, C, ... ,Z }

8. < Скобки > à { ( , ) }

}

< Оператор >

< УВ >

< УВ >

T T

 

< Функция >

 

O O O { O }

 

ид ид { ид }

ИД ИД ИД ИД

IF ( A < B ) B U L L () ;

В программе данные функции размещены в соответствии с входным языком G < Оператор>. В случае смены входного языка

требуется всего на всего заменить очередность вызова функций. Например в пределах заданного базиса можно сконструировать грамматику G < Инструкция >.

G < Инструкция > à PRINT ( < УВ > ) ( < УВ > ) < Функция >;

( Дальнейшая конструкция языка идентична языку G < Оператор > ).

Сконструируем дерево вызова следующим образом:

TREATMENT à TYPE(«print») à BRACKET(1) à TERM() à SIGN() à TERM() à BRACKET(2) à BRACKET(1) à TERM() à SIGN() à TERM() à BRACKET(2) à FUNC() à TZ()

Таким образом можно порождать необходимые языковые конструкции. На данном этапе имеются уже два оператора

IF и PRINT. Можно продолжать дальнейшее наращивание входного словаря операторов, таким образом расширяя сам свой собственный язык.

Язык G < Оператор > выполнен со значительными усечениями поэтому не претендует на роль идеального базиса. Например обязателен вызов функции после круглой скобки,

хотя реально это только мизерная часть возможных операций.

Автор данной работы не ставил перед собой задачу сконструировать более менее приемлимый язык. Главная цель -это отразить понимание принципа построения грамматик и выработки языка.

Несколько слов о самой программе. Программа выполнена,

как я уже упомянал, на языке Си, с элементами Си++. После запуска

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

a) Об ошибках - в случае несоответствия входного и текущего языков

b) «Успех!!!» - в противном случае

Имеется возможность использования ключевых слов:

1. «help» -выводит на экран окно помощи

2. «helpme» -выводит на экран авторское окно

3. «exit» - выход из программы

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

Постановка задачи

Пользуясь базовым языком высокого уровня Си ++ разработать и реализовать синтаксический анализатор условного оператора

IF ELSE языка Си.

Порядок выполнения:

1. Построение формального языка L

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

2. Подбор грамматики G[Z] по языку L

Построенный формальный язык L, подвергается декомпозиции, в процессе которой выявляются лексические составляющие - идентификаторы, константы и др. терминальные символы.

3. Классификация G[Z]

Для гарантии однозначности и безвозвратности разработанного языкового процессора выбранный язык отнести согласно класси-

фикации формальных грамматик, предложенных Хомским.

4. Выбор метода анализа

Проанализировать и выбрать наиболее подходящий анализ входного языка.

5. Диагностика и нейтрализация ошибок

Разработать алгоритм диагностики и нейтрализации ошибок.

6. Тестирование на программы на символьных цепочках

Протестировать разработанный языковой процессор на конкретных символьных цепочках.

7. Листинг

В конце отчета поместить распечатку программы с подробными коментариями.

Построение формального языка L

< Оператор > à IF ( < УслВыр > ) < Функция >;

[ ELSE < Функция >; ]

< Оператор > -- начальный нетерминальный символ

IF -- входной терминальный символ

ELSE -- входной терминальный символ (может и отсутствовать)

< УВ > -- условное выражение

< Функция > - отражает функциональную конструкцию языка Си

Пример правильного синтаксиса:

if ( a < b ) CallTheFunction( code1 ); else TheNextFunction( code2 );

a < b - есть условное выражение

«CallTheFunction» и «TheNextFunction» -- функции

code1 & code2 -- параметры функции

Подбор грамматики G[Z] по языку L

Любой язык, назовём его G <Z> в независимости от его классификации и функционального назначения содержит следующие базисные элементы: G <Z> ={ Vt, Vn, Z, P }, где:

Vt - словарь терминальных символов

Vn - словарь нетерминальных символов

Z - начальный нетерминальный символ

P - множество правил вывода

Для языка G <Оператор> имеем следующие множества:

Vt ={ 0, 1, 2, ... , 9 ; a, b, c, d, ... ,z ; A, B, C, ..., Z; <, >, = };

Vn ={«Оператор», «УслВыр», «Терм», «Операнд», «Функция», «Идентификатор», «Скобки», «Целое» };

Z = { «Оператор» };

P = {

1. < Оператор > à IF ( < УслВыр > ) < Функция > [ ELSE < Функция > ]

2. < УслВыр > à T | T < T | T > T | T = T

3. < Операнд > à «Идентификатор» | «ЦБЗ»

4. < Функция > à < Идентификатор > (< Список параметров >);

5. < Список параметров > à < Параметр > | W

6. < Параметр > à «Идентификатор» | «ЦБЗ» | W

7. < Идентификатор > à Б { Б | Ц }

}

Классификация G[Z]

1. < Оператор > à IF ( < УслВыр > ) < Функция > [ ELSE < Функция > ]

2. < УслВыр > à T | T < T | T > T | T = T

3. < Операнд > à «Идентификатор» | «ЦБЗ»

4. < Функция > à < Идентификатор > (< Список параметров >);

5. < Список параметров > à < Параметр > | W

6. < Параметр > à «Идентификатор» | «ЦБЗ» | W

7. < Идентификатор > à Б { Б | ЦБЗ }

Сделаем замену нетерминальных символов:

< Оператор > à Z

< УслВыр > à A

< Терм > à B

< Функция > à C

< Список параметров > à D

< Параметр > à E

< Идентификатор > à F

Сделаем замену терминальных символов:

IF à a

( à b

) à c

; à d

ELSE à e

ЦБЗ à f

Б à g

W à h

1. Z à abAcC [ eC ]

2. A à B | B < B | B > B | B = B

3. B à F | f

4. C à FbDcd

5. D à E | h

6. E à F | f | h

7. F à g { g | f }

Вывод : G[Z] - автоматная грамматика.

Выбор метода анализа

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

Диагностика и нейтрализация ошибок

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

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

Для наглядности изобразим куст синтаксического разбора для входного языка:

Дано:

IF ( A < Bc ) BULL () ;

1. Z à abAcC [ eC ]

2. A à B | B < B | B > B | B = B

3. B à F | f

4. C à FbDcd

5. D à E | h

6. E à F | f | h

7. F à g { g | f }

Z

 

a b A c C

 

B B F b c d

 

F F g { g }

 

g g {g} g g g g

IF ( A < Bc ) BULL ( ) ;

Тестирование на цепочках

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

IF ( A < B ) BULL ( );

< Оператор >

 

a b < УслВыражение > c < Функция >

 

< Терм > < Терм > < Идент > b c d

 

< Идент > < Идент > g { g }

 

g g {g} g g g g

IF ( A < B ) BULL ( ) ;

1. Проверка на нетерминальный символ IF

2. Проверка на терминальный символ « ( »

3. Проверка на условное выражение

3.1 Проверка на терм

3.2 Проверка на знак

3.3 Проверка на терм

4. Проверка на терминальный символ « ) »

5. Проверка на функцию

5.1 Проверка на имя функции

5.2 Проверка на наличие терминального символа « ( »

5.3 Проверка на параметр функции (может и отсутствовать)

5.4 Проверка на наличие терминального символа « ) »

6. Проверка на терминальный символ « ; »

Вывод: ошибок не обнаружено

JTAG и Граничное Сканирование

1.  Что такое JTAG 2.  Порт тестового доступа: TAP (Test Access Port) 3.  Автомат управления TAP (TAP-controller) 4.  JTAG цепочка 5.  Что такое Граничное Сканирование (Boundary Scan Testing 6.  Архитектура поддержки Граничного Сканирования 7.  Возможности Граничного Сканирования 1. Что такое JTAG Когда речь идет о JTAG, прежде всего, подразумевается стандарт: IEEE 1149.1-2001 Test Access Port and Boundary-Scan Architecture (Стандарт IEEE 1149.1-2001 Порт тестового доступа и Архитектура Граничного сканирования ). С ростом степени интеграции БИС, плотности монтажа и появлением многослойных печатных плат, методы диагностики, основанные на подключении к контрольным точкам платы и выводам микросхем, становятся все более сложными в использовании и неэффективными. Основные недостатки альтернативных способов диагностики были связаны, прежде всего, с отсутствием соответствующих общепринятых стандартов—и, как следствие, широкой поддержки проектировщиков и производителей. В начале 1985 года объединенными усилиями нескольких европейских компаний была создана группа для разработки решения проблем тестирования интегральных схем,  цифровых устройств и систем. Эта группа получила имя: Joint European Test Action Group (JETAG). Позднее, в 1988 году к ней присоединились представители североамериканских компаний, и название было изменено на Joint Test Action Group (JTAG). Результатом работы этой группы явился принятый в 1990 году стандарт IEEE Std.1149.1 и его усовершенствованная версия: стандарт IEEE Std.1149.1a (1993 год). В основу стандарта положена идея внедрение в компоненты цифрового устройства средств, обеспечивающих унифицированный подход к решению следующих задач: ·  Тестирование связей между интегральными схемами, после того, как они были смонтированы на печатной плате или другой основе; ·  Наблюдение за работой компонент без вмешательства в их нормальную работу, или непосредственное управление одним или более компонентом; ·  Обеспечение стандартизованного доступа к произвольным средствам самотестирования, встраиваемым в БИС; При этом в общем виде сам процесс тестирования выглядит следующим образом: Тестируемая плата с расположенными на ней БИС подключается, через последовательный канал передачи данных (JTAG интерфейс), к некоторому ведущему устройству. Ведущее устройство, используя возможности предоставляемые JTAG, решает задачи связанные с диагностикой тестируемого устройства, локализации неисправностей, загрузкой конфигураций PLD и т. п. Как правило, ведущим устройством является персональный компьютер, оснащенный соответствующим программным обеспечением. Подключение к ведомому устройству осуществляется через параллельный или последовательный порт, или через плату расширения. Впрочем, если задачи решаемые через JTAG достаточно просты, как загрузка начальной конфигурации в PLD, или тестирование общей работоспособности устройства после включения питания, то роль ведущего устройства может играть простейший микропрограммный автомат постоенный на базе ПЗУ и счетчика. Рис 1. Тестирование устройства по JTAG. Таким образом, стандарт JTAG определяет: ·  Интерфейс, через который осуществляется обмен тестовыми инструкциями и данными между ведущим устройством и встроенными средствами тестирования (TAP — Test Access Port) ; ·  Минимальный набор средств тестирования, встраиваемых в БИС (средства поддержки метода Граничного Сканирования); 2. Порт тестового доступа: TAP (Test Access Port). Когда мы говорим о передаче информации через JTAG, то мы подразумеваем обмен между ведущим устройством и встроенными в БИС средствами тестирования. Для этой цели был разработан TAP (Test Access Port)—Порт Тестового Доступа. Аппаратная поддержка поддержки JTAG реализуется достаточно простыми схемами. TAP требует 4-х внешних контактов: ·  TDI (Test Data Input)—контакт для получения последовательных данных. На этот контакт последовательно, бит-за-битом податься данные, которые затем интерпретируются схемой управления; ·  TDO (Test Data Output)—контакт вывода последовательных данных. С этого контакта ведущее устройство последовательно считывает данные из БИС (например результат тестовых операций); ·  TCK (Test Clock Input)—контакт сигнала синхронизации обмена; ·  TMS (Test Mode Select)—этот контакт управляет состоянием внутреннего автомата TAP. В частности с помощью этого контакта определяется что грузиться: команда или данные, а также определяться начало и конец загрузки; Следующий контакт не является обязательным для реализации: ·  TRST (Test ReSeT)—сброс в начальное состояние контроллера внутреннего автомата TAP  Ниже схематически показана ИС со встроенной схемой поддержки JTAG. Рис. 2. ИС со встроенной схемой поддержки JTAG В процессе обмена информацией через TAP, ведущее устройство воспринимает такую БИС как сдвиговый регистр. При этом ·  TDI—вход сдвигового регистра; ·  TDO—выход сдвигового регистра; ·  TCK—сигнал сдвига; В зависимости от состояния автомата TAP в канал может быть включен либо регистр данных либо регистр команды. Регистр команды в JTAG контроллере всегда один. Регистров данных в JTAG контроллере может быть сколько угодно. Какой именно регистр данных будет выбран для подключения, как правило, определяется загруженной командой. Стандарт JTAG требует наличия в контроллере одноразрядного регистра данных, называемого BYPASS. Его назначение будет пояснено ниже. Рассмотрим более подробно схему управления JTAG интерфейсом, встраиваемую в БИС: Рис. 3. Сехема управления JTAG иннтерфейсом В состав схемы входят: ·  Три сдвиговых регистра (регистр команд (IR), регистр пропуска (Bypass) и регистр данных (DR); ·  Выходной мультиплексор (MUX); ·  Контроллер управления (TAP Controller). Основным регистром является регистр данных, он служит источником и приемником данных при выполнении в JTAG цепочках любых команд. С точки зрения устройства управления, регистр данных является одним из трех сдвигающих регистров, включаемых между контактом для подачи входной информации (контакт TDI) и контактом для получения выходной информации (контакт TDO). 3. Автомат управления TAP (TAP-controller) Можно выделить два важных режима или состояния TAP: ·  Состояние загрузки команд; ·  Состояние загрузки данных; Режим работы определяется текущим состоянием встроенного в TAP конечного автомата. Его граф приведен ниже: Рис. 5. Граф состояний управляющего автомата TAP. Граф включает в себя 16 состояний. Переход от состояния к состоянию осуществляется по каждому переднему фронту TCK. Ветвь перехода зависит от текущего состояния сигнала TMS. Начальным состоянием автомата является Test Logic Reset. После включения питания, ведущее устройство "не знает", в каком состоянии окажется автомат TAP тестируемого устройства. Необходим способ гарантированного перевода TAP в начальное состояние. Таких способов два: ·  Установить на TMS высокий уровень и подать 5 или более импульсов TCK. В этом услучае автомат окажеться в состоянии Test Logic Reset; ·  Если реализован контакт TRST то автомат можно сбросить импульсом на этом выводе; Загрузки команды в регистра команды происходит в состоянии Shift-IR. Загрузка данных происходит в заданный регистр данных происходит в состоянии Shift-DR. Какой именно регистр данных будет выбран для обмена, определяется текущим содержимым регистра команды. Ниже приведен более подробное описание каждого состояния: ·  Test-Logic-Reset—сброс логики тестирования. В этом состоянии тестирующая логика отключается, регистр команды инициализируеться кодом команды BYPASS или кодом команды вывода идентификационного кода интегральной схемы (IDCODE); ·  Run Test\Idle—состояние ожидания или выполнения внутренних тестов. Это состояние используеться как промежуточное между операциями. Например, если загрузкой некоторой команды и данных, была инициализирована продолжительная тестовая процедура, то на время ее выполнения TAP следует перевести в это состояние; ·   Select-DR-Scan—промежуточное состояние автомата, позволяет попасть в ветвь автомата, связанную с загрузкой данных; ·   Select-IR-Scan—промежуточное состояние автомата, позволяет попасть в ветвь автомата, связанную с загрузкой команды; ·  Capture-DR—это состояние подготовки данных к обмену. Данные, которые должны быть переданы ведущему устройству, загружаются в соответствующий регистр данных контроллера JTAG; ·  Shift-DR—в этом состоянии регистр данных включаеться между выводами TDI и TDO. Данные, подготовленные для ведущего утройства (результат текущей команды загрущенной в командный регистр) последовательно выдвигаються наружу, замещаясь данными, которые передаються ведущим устройством; ·  Exit1-DR, Exit2-DR, Exit1-IR, Exit2-IR—промежуточные состояния, не оказывают никакого влияния на состояние тестовой логики, предназначены для быстрого перехода в начальное состояние; ·  Pause-DR, Pause-IR —эти состояния,  позволяют приостанавливать продвижение информации на произвольное количество тактов синхронизации (например, для выполнения каких либо действий в БИС с внешним тактированием); ·  Update-DR—это состояние, в котором вдвинутые данные "защелкиваються", в момент выхода из этого состояния тестовая логика приступает к соотвествующей операции с использованием загруженных данных; ·  Capture-IR—фактически промежуточное состояние, не оказывает никакого влияния на состояние тестовой логики; ·  Shift-IR—в этом состоянии регистр команды включаеться между выводами TDI и TDO. Текущее содержмое регистра последовательно выдвигаеться наружу, замещаясь командой, которые передаваемой ведущим устройством; ·  Update-IR—cостояние фиксации и активизации вдвинутой команды; 4. JTAG-цепочка. Если на плате смонтировано несколько ИС, поддерживающих JTAG, то они объединяються в так называемую JTAG цепочку: Рис 4. Схема JTAG-цепочки. Стандарт не вводит никаких ограничений на количество устройств в цепочке. В процессе обмена вся цепочка представляет собой один сдвиговый регистр, каждой ИС будет соответствовать определенное количество разрядов в этом регистре. Ведущее устройство должно "знать" количество разрядов для каждой БИС. 5. Что такое Граничное Сканирование (Boundary Scan Testing) Стандарт JTAG определяет минимально-необходимый набор средств, который должен быть включен в состав БИС для того чтобы ее можно было вовлечь в процесс тестирования методом Граничного Сканирования. Главная идея метода—получение ведущим устройством доступа к внешним выводам БИС через JTAG, включая: ·  Возможность наблюдения за выводами, без вмешательства в нормальную работу тестируемого устройства, ·  Прямое управление выводами БИС. 6. Архитектура поддержки Граничного Сканирования Рассмотрим подробнее структуру БИС, построенными в соответствии с требованиями JTAG. Рис. 5. Архитектура БИС поддерживающая метод граничного сканирования. Основу архитектурной поддержки метода состоявляют ячейки граничного сканирования (BSC—Boundary Scan Cell). Последовательность из этих ячеек разделяет внутреннюю логику БИС и ее внешние выводы. С точки зрения обмена эта последоваетельность представляет собой один регистр данных, который включаться в канал JTAG. Такой регистр называеться Регистром Граничного Сканирования (Boundary Scan Register).  Ниже приведен наиболее простой вариант схемы отдельной ячейки: Рис. 6. Схема сканирующей ячейки Можно выделить несколько режимов в работе ячейкиЖ ·  Режим сдвига, когда в триггера Т1 по сигналу "захват" сохраняеться состояние аналогичного триггера предыдущей ячейки. В этом режиме ведущее устройство последовательно выдвигает текущее состояние ячеек и вдвигает новое; ·  Режим наблюдения ("Sample") В этом режиме по импульсу текущее состояние вывода фиксируется в триггере, и может быть потом считано ведущим устройством. При этом, в процессе обмена данные получаемая от ведущего устройства фиксируются в триггере. При необходимости, в режиме тестирования (EXTEST) эти данные могут быть выведены на внешний вывод; ·  Режим тестирования ( EXTEST—Executing Test ). В этом режиме на выход подается логическое значение, которое находиться в триггере Т2; В приведенной схеме на каждый вывод БИС приходиться один бит регистра граничного сканирования (его роль играет триггер Т1). Однако очень часто встречаються схемы, в которых на каждый вывод приходиться 3 бита: бит для вывода значения в тестовом режиме, бит, сохраняющий фактический логический уровень, находящийся на выводе, и бит управляющий переводом вывода в высоко-импедансное состояние. 7. Возможности Граничного Сканирования Таким образом ведущее устройство может получить доступ к любому выводу любой БИС, включенной в JTAG-цепочку. Рис. 7. Плата с поддержкой JTAG. ·  Выставляя на одних выводах логические уровни и проверяя состояния других ведущее устройство может делать заключение о наличии или отсутствии связей между выводами различных БИС; ·  Перехватывая управление выводами можно формировать на выводах областей не охвеченных цепочкой тестовые комбинации и проверять корректность реакций. Например, управляя выводами центрального процессора произвести тестирование работоспособности ОЗУ; ·  Делать "снимки" состояний контактов интегральных схем цифрового устройства, и на основе их анализа делать заключение о правильности его работы;

Часть I: Технический обзор Платформы Eclipse

If you build it, they will come. ---W. P. Kinsella, Field of Dreams (1989)

Платформа Eclipse (или просто "Платформа", когда нет риска неоднозначности) разработана и построена для выполнения следующих требований:

Поддержка конструирования разнообразных инструментов для разработки приложений. Поддержка неограниченного ряда поставщиков инструментария, включая независимых поставщиков программного обеспечения (ISV). Поддержка инструментов в манипулировании произвольным типом содержимого (т. е., HTML, Java, C, JSP, EJB, XML и GIF). Обеспечение "бесшовной" интеграции инструментов c различными типами содержимого и разными поставщиками инструментария. Поддержка сред разработки приложений как с графическим интерфейсом пользователя (GUI), так и без GUI. Выполнение на широком спектре операционных систем, включая Windows и Linux. Использование популярности языка программирования Java для написания инструментария.

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

Рисунок 2 показывает главные компоненты и API Платформы Eclipse.

Рисунок 2. Архитектура Платформы Eclipse.

Архитектура Среды Выполнения Платформы и подключений

Подключение (plug-in) - наименьшая единица функциональности Платформы Eclipse, которая может быть разработана и поставлена отдельно. Обычно небольшой инструмент пишется как одно подключение, тогда как функциональность сложного инструмента разносится по нескольким подключениям. За исключением небольшого ядра, называемого Средой Выполнения Платформы (Platform Runtime Environment), вся функциональность Платформы Eclipse находится в подключениях.

Подключения кодируются на языке Java. Типовое подключение состоит из кода Java в библиотеке JAR, нескольких доступных только для чтения файлов и других ресурсов, таких, как изображения, web-шаблоны, каталоги сообщений, библиотеки в кодах аппаратной платформы и т. д.. Некоторые подключения вообще не содержат кода. Одним из примеров такого подключения является подключение, которое предоставляет онлайновую помощь в форме страниц HTML. Библиотеки кодов одного подключения и информация, доступная только для чтения, располагаются вместе в каталоге файловой системы или по базовому URL на сервере. Этот механизм также предохраняет подключение от составления его из нескольких разных фрагментов, каждый из которых находится в собственном каталоге или по собственному URL. Это также и механизм для поставки раздельных языковых пакетов для интернационализированных подключений.

Каждое подключение имеет файл манифеста (manifest), объявляющий его соединение с другими подключениями. Модель соединения простая: подключение объявляет любое количество именованных точек расширения (extension point), и любое количество расширений (extension) к одной или более точкам других подключений.

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

Точка расширения может иметь связанный с ней интерфейс API. Другие подключения вносят реализации этого интерфейса через расширения для этой точки расширения. Любое подключение свободно может определить новую точку расширения и обеспечить новые API для использования другими подключениями.

При запуске Среда Выполнения Платформы определяет набор доступных подключений, читает их файлы манифеста и строит в памяти реестр подключений. Платформа проверяет соответствия по именам объявлений расширений соответствующим им объявлениям точек расширения. Любые проблемы, такие, как расширение несуществующей точки расширения, обнаруживаются и протоколируются. Результирующий реестр подключений доступен через API Платформы. После запуска подключения добавляться уже не могут.

Файлы манифеста подключений сдержат XML. Точка подключения может объявлять дополнительные специфические типы элементов XML для использования в подключениях. Это позволяет подключению дать возможность расширению обмениваться произвольной информацией с подключением, объявляющим соответствующую точку расширения. Более того, информация манифеста доступна из реестра без активизации внесшего его подключения или загрузки какого-либо его кода. Это свойство является ключевым для поддержки большой базы инсталлированных подключений, из которых только несколько необходимы в каждом данном сеансе пользователя. Пока код подключения не загружен, оно занимает незначительную память и не влияет на время запуска. Использование манифеста подключений на основе XML также облегчает написание инструментов, которые поддерживают создание подключений. Среда Разработки Подключений (Plug-in Development Environment - PDE), которая включена в Eclipse SDK, является таким инструментом.

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

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

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

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

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

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

Среда Выполнения Платформы Eclipse также обеспечивает механизм для динамического расширения объектов. Класс, который использует "адаптируемый" интерфейс, объявляет свои экземпляры открытыми для изменения поведения от третьих лиц. Адаптируемый экземпляр может быть запрошен у объекта адаптера, который реализует интерфейс или класс. Например, ресурсы рабочего пространства являются адаптируемыми объектами, рабочее место добавляет адаптеры, которые обеспечивают подходящие иконки и текстовые метки для ресурса. Любая часть может добавить поведение к существующему типу (как к классу, так и к интерфейсу) адаптируемого объекта путем регистрации в Платформе подходящей фабрики адаптеров. Многие части могут независимо друг от друга расширять один и тот же адаптируемый объект, каждая для своей цели. Когда адаптер для данного интерфейса зарегистрирован, Платформа определяет и вызывает фабрику адаптеров, чтобы создать его. Механизм используется только для Java-типа адаптируемого объекта (он не увеличивает память адаптируемого объекта). Любое подключение может использовать этот механизм для добавления поведения к существующим адаптируемым объектам и для определения новых типов адаптируемых объектов, используемых и, возможно, расширяемых другими подключениями.

Рабочие пространства

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

Механизм типа проекта (project nature) позволяет инструменту помечать проект, чтобы придать ему определенную персонификацию или тип. Например, типом web-сайта помечается проект, который содержит статическое содержимое для web-сайта, а типом Java помечается проект, который содержит исходный код для Java-программы. Механизм типа проекта является открытым. Подключения могут объявлять новые типы проектов и обеспечивать коды для конфигурирования проектов этого типа. Один проект может иметь столько типов, сколько требуется. Это предоставляет для инструментов способ совместно использовать проекты, ничего не зная друг о друге.

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

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

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

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

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

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

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

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

Рабочее место и инструментальные средства пользовательского интерфейса

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

SWT - набор элементов и графическая библиотека, интегрированные с оконной системой базовой платформы, но независимые от API ОС. JFace - инструментальное средство UI, реализованное при помощи SWT, которое упрощает общие задачи программирования UI.

SWT

Standard Widget Toolkit (SWT) обеспечивает общий, независимый от ОС API для элементов и графики, реализованный таким образом, что он допускает тесную интеграцию с оконной системой базовой платформы. Весь UI Платформы Eclipse и инструменты, которые подключены к нему, используют SWT для представления информации пользователю.

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

SWT решает эту проблему определением API, доступного для большого числа поддерживаемых оконных систем. Для каждой платформенной оконной системы реализация SWT использует платформенные элементы, где это возможно; там же, где нет пригодных платформенных элементов, реализация SWT обеспечивает подходящую эмуляцию. Общие низкоуровневые элементы, такие как списки, текстовые поля и кнопки, везде реализуются на базе платформы. Но некоторые обычно используемые высокоуровневые элементы могут потребовать эмуляции в некоторых оконных системах. Например, элемент линейки инструментов SWT реализован как платформенная линейка инструментов в Windows и как эмулируемый элемент в Motif. Эта стратегия позволяет SWT поддерживать целостную программную модель во всех средах, позволяя при этом виду и впечатлению базовой платформенной оконной системе проявляться через все возможные расширения.

SWT также представляет специфичный для платформенной оконной системы API в случаях, когда данная платформенная оконная система предоставляет уникальные и значимые возможности, недоступные в других оконных системах. Хорошим примером этого является Windows ActiveX. Специфичный для Window API выделен в надлежащим образом именованные пакеты, чтобы обозначить тот факт, что они являются в действительности непереносимыми.

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

Внутри реализация SWT обеспечивает раздельные и различные реализации на Java для каждой платформенной оконной системы. Платформенные библиотеки Java полностью различны, и каждая сделана с API, специфичным для базовой оконной системы. (В отличие от Java AWT, в которой платформенно-зависимые различия находятся в реализации в кодах C общего набора методов Java.) Поскольку в кодах платформы не скрыто никакой специальной логики, реализация SWT выражается полностью в Java-коде. Тем не менее, код Java выглядит знакомым для разработчика на платформе базовой ОС. Любой Windows-программист найдет Java-реализацию SWT для Windows безусловно знакомой, поскольку она состоит из вызовов Windows API, которые уже знакомы C-программисту. Так же и для Motif-программиста выглядит реализация SWT для Motif. Эта стратегия значительно упрощает воплощение, отладку и сопровождение SWT, поскольку она позволяет выполнить всю интересующую разработку на Java. Конечно, это не имеет прямого отношения к обычным клиентам SWT, поскольку платформенно-зависимые коды полностью скрыты под системно-независимым SWT API.

JFace

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

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

Механизм действий (action) позволяет командам пользователя быть определенными независимо от их точного местонахождения в UI. Действие представляет команду, которая может быть запущена пользователем через кнопку, пункт меню, или пункт линейки инструментов. Каждое действие знает свои собственные ключевые свойства UI (метка, иконка, всплывающая подсказка, etc.), которые используются для конструирования соответствующих элементов, представляющих действие. Это разделение позволяет одному и тому же действию быть использованным в нескольких местах в UI и означает, что место, где действие представляется в UI, можно легко изменить без необходимости изменения кода самого действия.

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

Рабочее место

В отличие от SWT и JFace, которые оба являются инструментальными средствами UI общего назначения, рабочее место (workbench) обеспечивает UI именно для Платформы Eclipse и поставляет структуры, в которых инструменты взаимодействуют с пользователем. Благодаря этой центральной и определяющей роли, рабочее место является синонимом UI Платформы Eclipse в целом и главного окна, которое пользователь видит при запуске Платформы (см. Рисунок 1). API рабочего места зависит от SWT API и, в меньшей степени, расширяет JFace API. Реализация рабочего места построена с использованием и SWT, и JFace; Java AWT и Swing не использованы.

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

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

Представления (view) обеспечивают информацию о некотором объекте, с которым пользователь работает в рабочем месте. Представление может помогать редактору в обеспечении информации о редактируемом документе. Например, стандартное представление схемы содержимого показывает структурированную схему содержимого активного редактора, если оно доступно. Представление может дополнять другие представления путем обеспечения информации о выбранном в данный момент объекте. Например, стандартное представление свойств представляет свойства объекта, выбранного в другом представлении. Платформа имеют более простой жизненный цикл, чем редакторы: модификации, сделанные в представлении, обычно сохраняются немедленно, и изменения немедленно отражаются в других связанных частях UI. Платформа обеспечивает несколько стандартных представлений (см. Рисунок 1); дополнительные представления поставляются в других подключениях.

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

Инструменты интегрируются в эту парадигму UI редакторы-представления-перспективы четко определенными способами. Главная точка расширения позволяет инструментам наращивать рабочее место:

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

Все стандартные редакторы и представления внесены с использованием этих механизмов.

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

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

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

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

Интеграция UI

Инструменты, написанные на Java с использованием API Платформы, достигают наивысшего уровня интеграции с Платформой. В другом крайнем случае внешние инструменты, запускаемые в Платформе, должны открывать собственные отдельные окна, чтобы взаимодействовать с пользователем, и должны обращаться к данным пользователя через файловую систему. Их интеграция, следовательно, очень слабая, в особенности на уровне UI. В некоторых средах Платформа Eclipse поддерживает также промежуточные уровни интеграции между этими крайними случаями:

Рабочее место имеет встроенную поддержку для встраивания любого документа OLE как редактора (только Windows). Эта опция обеспечивает тесную интеграцию UI. Подключаемый инструмент может реализовать контейнер, который является мостом между API Платформы Eclipse и управляющим элементом ActiveX, так что он может быть использован в редакторе, представлении, диалоге или мастере (только Windows). SWT обеспечивает необходимую низкоуровневую поддержку. Эта опция обеспечивает тесную интеграцию UI. Подключаемый инструмент может использовать AWT или Swing для открытия отдельных окон. (В Eclipse SDK 2.1 (март 2003) это работало для Windows, но не для Linux.) Эта опция обеспечивает слабую интеграцию UI, но допускает тесную интеграцию ниже уровня UI. (Конечно, AWT и Swing должны быть представлены в конфигурации базовой среды выполнения Java, в которой выполняется Платформа Eclipse.)

Поддержка командной разработки

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

Функция, обеспечиваемая конкретным командным репозиторием, однозначно влияет на рабочий поток (workflow) пользователя, например, добавлением шагов для выборки файлов из репозитория и для сравнения разных версий файла. Точный эффект на рабочем потоке пользователя кое в чем варьируется для разных типов репозиториев. Соответственно, Платформа Eclipse позволяет каждому поставщику репозитория определять собственный рабочий поток, так что пользователь, уже знакомый с продуктом командного репозитория, может быстро изучить использование его из Eclipse. Платформа поставляет базовые зацепки, позволяющие поставщику командного репозитория вмешаться в определенные операции, которые манипулируют ресурсами в проекте. Эти зацепки обеспечивают хорошую поддержку и для оптимистической, и для пессимистической модели. На уровне UI Платформа поставляет шаблоны-заполнители для определенных действий, настроек и свойств, но предоставляет каждому поставщику репозитория определять эти элементы UI. Есть также простой мастер, с расширяемой конфигурацией, который позволяет пользователю связывать проекты с репозиториями, и который каждый поставщик репозитория может расширить элементами UI для собирания информации, специфичной для данного вида репозитория.

Множество поставщиков командных репозиториев могут мирно сосуществовать в Платформе. Платформа Eclipse включает поддержку для репозиториев CVS, доступных через протоколы pserver или ssh.

Помощь

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

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

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

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

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

Эпилог

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

Этот краткий обзор не коснулся многих других интересных аспектов Платформы Eclipse, таких как поддержка отладчиков и интеграция с инструментом построения ANT. Дополнительные подробности об API Платформы Eclipse, точках расширения и стандартных компонентах вы можете найти в Platform Plug-in Developer Guide, которое доступно как онлайновая помощь для Eclipse SDK.

РАЗДЕЛ I - Изучение Soft-ICE

ГЛАВА 1

1.1 Описание Продукта

Soft-ICE - инструмент отладки программного обеспечения, который обеспечивает возможности отладки на аппаратном уровне для отладчиков PC DOS и MS DOS.

Soft-ICE использует защищенный режим 80386, чтобы запускать DOS в виртуальной машине. Это дает Soft-ICE полный контроль над окружением DOS. Soft-ICE использует особенности защищенного режима 80386, типа страничной организации памяти, уровня привилегий ввода/вывода и регистров отладки, для установки аппаратных точек останова из вашего существующего отладчика DOS.

Soft-ICE был разработан для достижения трех целей:

Использовать возможности виртуальной машины 80386 для тех способов отладки, которые являются невозможными или недопустимо медленными для отладчиков, использующих только программные средства (например, аппаратные точки останова в режиме реального времени, защита памяти, борьба с программами, вызывающими зависание системы и т. д.). Работать с существующими отладчиками. Мы хотели предоставить инстру - мент, который работал бы с существующими инструментами. Мы разработали Soft-ICE таким образом, чтобы вам не нужно было изучать новый отладчик для получения мощных возможностей для отладки программ на аппаратном уровне. Быть программой, дружественной к пользователю, с окном, которое всплывает немедленно и не мешает работать. Все команды Soft-ICE были разработаны, чтобы помещаться в небольшом окне так, чтобы была видна информация за экраном Soft-ICE. Динамическая система интерактивной помощи помогает пользователям, редко использующим Soft-ICE.

Предоставляемые возможности программы Soft-ICE:

Точки останова на чтение/запись в ОЗУ в режиме реального времени, на чтение/запись в порты и области памяти и на прерывания История выполнения команд для обратной трассировки Символьная отладка и отладка на уровне исходных текстов Окружение, работающее с существующими отладчиками Полная поддержка EMM 4.0 Возможность наращивания основной памяти свыше 640КБ для систем с монохромными адаптерами Окно, всплывающее в любое время Способность всплытия по нажатию клавиши даже при отключенных прерываниях Код отладчика, изолированный при помощи защищенного режима 80386. Это предотвращает изменение или разрушение Soft-ICE выполняющейся программой; даже если DOS будет разрушена, Soft-ICE все еще будет работать Способность настроить Soft-ICE не использовать память ниже границы 640КБ, если в системе есть больше чем 640КБ Дружественная динамическая помощь Возможность использования в качестве автономного отладчика. Эта возможность полезна при отладке загружаемых драйверов устройств, обработчиков прерываний, последовательностей команд, которые традиционные отладчики не могут пройти; если ваш отладчик испытывает трудности при повторных вхождениях в код (re-entrancy) * Способность мягкой перезагрузки, позволяющая отлаживать другие операционные системы или самозагружающиеся программы Простая установка без необходимости настройки DIP-переключателей для предотвращения захвата портов и никаких конфликтов с адресным пространством ОЗУ

Внимание:

Soft-ICE будет работать только с программами реального режима адресации. Он не будет работать с программами, которые используют инструкции защищенного режима 80286 или 80386.

Системные требования

Soft-ICE работает с IBM Серии II модели 70 и 80, Compaq 80386 и компьютерами 80386SX, с совместимыми с AT и 80386 картами сопроцессора. Soft-ICE будет работать с сопроцессорами 80386 XT только, если они совместимы с AT.

Soft-ICE лучше всего работает при наличии расширенной памяти, но так же прекрасно работает на системах только с основной памятью.

Soft-ICE не использует DOS или ROM BIOS для видео вывода и клавиатурного ввода. Поэтому видеоадаптер должен быть совместим с одним из следующих: MDA, Hercules, CGA, EGA или VGA. Soft-ICE также поддерживает двухмониторную конфигурацию, которая очень полезна при отладке программ, интенсивно работа - ющих с видеоадаптером.

Список литературы:

www. khpi-iip. mipk. kharkiv. edu

www. *****/