Размещено на http://www.allbest.ru/

Оглавление

1. Обоснование актуальности разработки. Описание УУМ-32

1.1 Обоснование актуальности разработки

1.2 Описание универсальной учебной виртуальной машины УУМ-32

2. Анализ инструментальных средств разработки

2.1 Средства моделирования

2.2 Средства разработки программного обеспечения

3. Техническое задание. Структурная и функциональная схемы ПО

3.1 Техническое задание

3.1.1 Основание для разработки

3.1.2 Назначение разработки

3.1.3 Требования к программным и аппаратным средствам

3.2 Структурная схема ПО

3.3 Функциональная схема ПО

4. Описание приложения «Интегрированная среда разработки для УУМ-32»

4.1.1 Общие сведения

4.1.2 Функциональное назначение приложения

4.1.3 Описание структуры приложения

4.2 Описание приложения «Макроассемблер для УУМ-32»

4.2.1 Функциональное назначение приложения

4.2.2 Описание логической структуры приложения

4.2.3 Используемые технические средства

4.2.4 Вызов и загрузка

5. Тестирование и подготовка руководств пользователя

5.1 Тестирование приложения

5.2 Руководства пользователя

5.2.1 Описание языка Макроассемблера для УУМ-32

Заключение

Список использованных источников информации

Приложения



1. Обоснование актуальности разработки. Описание УУМ-32

1.1 Обоснование актуальности разработки

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

Именно по этой причине архитектура учебной универсальной 32-х разрядной машины (УУМ-32) была упрощена. С помощью УУМ-32 можно освоить основные принципы функционирования вычислительной техники. Это позволит в последствии понять функционирование не только процессоров, применяемых в персональных и промышленных компьютерах, но и современных мэйнфреймов и микропроцессоров. Простота изменения конфигурации виртуального оборудования обеспечит возможность ставить эксперименты практически в любых «аппаратных условиях».

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

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

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

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

1.2 Описание универсальной учебной виртуальной машины УУМ-32

Концепция универсальной учебной машины

Универсальная учебная машина УУМ-32 имеет следующую базовую архитектуру, состоящую из:

· Ядра УУМ-32 (арифметико-логическое устройство АЛУ)

· Оперативная память (до 4х гигабайт на систему)

· Менеджера устройств, позволяющего подключать к УУМ-32 различные устройства и получать к ним доступ в режиме супервизора через прерывания и регистры УУМ-32

На рисунке 1.1 представлена базовая архитектура УУМ-32.

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



Рисунок 1.1 Базовая архитектура УУМ-32

Перспективы развития

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

Зеленым цветом отмечены те компоненты, которые реализованы в данном дипломном проекте. Как видно из рисунка, их три:

· Ассемблер для УУМ-32

· Макроассемблер с поддержкой библиотек макросов

· Интегрированная среда разработки для УУМ-32

Все остальные компоненты (не выделены никаким цветом) на сегодняшний день еще не реализованы, в связи с этим исследования в области УУМ-32 по-прежнему актуальны.

Постоянное развитие архитектуры УУМ-32 позволит ей стать богатой платформой для полноценных исследований в области создания операционных систем и системного программирования.



Рисунок 1.2 Современное состояние архитектуры УУМ-32

Архитектура УУМ-32

Основу архитектуры УУМ-32 составляют следующие компоненты:

· Ядро УУМ-32 - эмулятор процессора УУМ-32. Процессором в настоящее время поддерживается 41 команда. Список команд приведен в Приложении 1.

· Оперативная память. Так как архитектура УУМ-32 является 32-х разрядной, каждому процессу доступно до 232 МБ памяти. Архитектура УУМ-32 такова, что контекст каждого процесса снабжен двумя специальными регистрами LB и HB: нижняя и верхняя границы памяти соответственно. Они позволяют отделить адресное пространство каждого процесса. Так как контроль границ происходит на аппаратном уровне, преодолеть границы адресного пространства процесса невозможно. В будущем, когда на платформе УУМ-32 будет реализована операционная система, контроль границ адресного пространства приведет к невозможности реализации вирусов, изменяющих чужое адресное пространство с целью подмены или хищения данных.

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

Регистры УУМ-32

В УУМ-32 существует 16 программно доступных регистров и 4 программно-недоступных регистра. Их описание приведено в таблице 1.1 (для программно доступных регистров определены порядковые номера).



Таблица 1.1 Регистры УУМ-32

Регистр	Порядковый номер	Назначение
A (accumulator)	0	Операции ввода вывода
B (base)	1	Базовый регистр для адресации с базированием
X (index)	2	Индексный регистр для адресации с индексированием
SW (status word)	3	Слово состояния процессора
R0 - R11	4 - 15	Регистры общего назначения
PC (program counter)	-	Счетчик команд, указывает на адрес следующей исполняемой команды
LB (low border)	-	Нижняя граница адресного пространства процесса
HB (high border)	-	Верхняя граница адресного пространства процесса
SS (stack summit)	-	Указатель вершины стека

Состав слова состояния процессора:

· CC (condition code) - Код состояния. Отражает результат операций сравнения. Доступен из режима пользователя на чтение и запись.

· IC (interrupt code) - Код последнего возникшего прерывания. Доступен из режима пользователя на чтение и запись.

· UM (user mode) - Уровень привилегий. Для этого поля возможны следующие значения:

§ 0 - уровень супервизора

§ 1 - пользовательский уровень

§ 2 - зарезервировано для будущего использования

· PH (process handler) - Дескриптор процесса. В системе возможно существование 262144 процессов. В режиме пользователя доступен только для чтения.

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

Форматы команд УУМ-32. Способы адресации

В УУМ-32 существует 4 формата команд. Специального названия форматы не имеют, поэтому при обозначении используется порядковый номер формата. Такое многообразие форматов позволяет использовать минимум места при записи команд. Возможно, при современных объемах оперативной памяти, это и не так важно, если речь идет о прикладном программном обеспечении. Однако при написании системного программного обеспечения, а, тем более, операционной системы, это может сыграть ключевую роль. Форматы команд представлены на рисунке 1.4.

Остановимся на каждом формате подробнее.

· Формат 1 используется для команд, не имеющих параметры. Команда, записанная в этом формате, занимает всего 1 байт памяти.

· Формат 2 используется для команд, оперирующих с регистрами. Так как программно доступных регистров всего 16, для кодирования номера регистра используется полубайтовое слово. Таким образом, команда, записанная в формате 2, занимает 2 байта памяти.

· Формат 3 используется для команд, у которых одним операндом является регистр, а другим - содержание участка памяти. Причем участок памяти определяется не абсолютным адресом, а смещением (сдвигом) относительно текущего значения регистра команд PC.

· Формат 4 используется для тех же команд что и формат 3, с той лишь разницей, что под поле смещения отводится 32 разряда.

Описание полей команд:

· op - поле, содержащее код операции.

· eop - поле, содержащие код разрядности извлекаемых из оперативной памяти операндов. Если поле равно 0, то операнд из памяти не извлекается, а в качестве операнда используется значение поля disp. Для команд формата 1 данное поля смысла не имеет и используется только для байтового выравнивания.

· r1, r2 - поля, содержащие номера операндов регистров. Номера регистров приведены в таблице 1.1. Регистры, для которых нет номеров, программно недоступны.

· e - признак использования расширенного формата.

· b - признак базирования по регистру B.

· n - признак косвенной адресации. При косвенной адресации извлекается значение из памяти по адресу disp, которое в свою очередь интерпретируется как значение адреса, из которого извлекается операнд.

· x - признак индексирования по регистру X.

· disp - поле может быть интерпретировано в зависимости от значений eop и n следующим образом:

§ Сдвиг относительно регистра PC до адреса операнда в оперативной памяти

§ Значение операнда

§ Адрес значения операнда

§ Адрес содержащий адрес операнда

В таблице 1.2 приведены все способы адресации УУМ-32.

Таблица 1.2 Способы адресации УУМ-32

Тип адресации	Признаки	Мнемокод Ассемблера	Формула вычисления TA	Операнд
	e i b n x
Простая	0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 1 1 0 1 0 1	op m op m,b +op m +op m,b op m,x op m,x,b +op m,x +op m,x,b	(PC)+disp (PC)+(B)+disp addr (B)+addr (PC)+disp+(X) (PC)+(B)+disp+(X) addr+(X) (B)+addr+(X)	(TA) (TA) (TA) (TA) (TA) (TA) (TA) (TA)
Косвенная	0 0 0 1 0 0 0 1 1 0 1 0 0 1 0 1 0 1 1 0 0 0 1 1 1 0 0 0 1 1 1 0 1 1 1 1 0 0 1 1	op @m op @m,b +op @m +op @m,b op @m,x op @m,x,b +op @m,x +op @m,x,b	(PC)+disp (PC)+(B)+disp addr (B)+addr (PC)+disp+(X) (PC)+(B)+disp+(X) addr+(X) (B)+addr+(X)	((TA)) ((TA)) ((TA)) ((TA)) ((TA)) ((TA)) ((TA)) ((TA))
Непосредственная	0 1 0 0 0 1 1 0 0 0	op #m +op #m	disp addr	TA TA

Способы извлечения значения из памяти в таблице 1.2. обозначены следующим образом:

· TA - непосредственное значение целевого адреса

· (TA) - значение, хранящееся в участке памяти по адресу TA

· ((TA)) - значение, хранящееся в участки памяти, адрес которого определяется значением (TA)

Контекст процесса УУМ-32

Контекст каждого процесса УУМ-32 содержит следующую информацию:

· 16 программно доступных регистров.

· Регистр команд, содержащий адрес следующей исполняемой команды. Программно не доступен.

· Граничные регистры области памяти. В этих регистрах хранятся верхняя и нижняя границы адресного пространства процесса.

· Указатель стека содержит сдвиг первого свободного элемента в стеке от начала стека.

Безопасность исполнения кода и разграничение прав пользователя в среде УУМ-32

В среде УУМ-32 на данный момент существуют два режима исполнения кода: режим супервизора и режим пользователя.

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

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

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

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

Главные функции механизма прерываний -- это:

· распознавание или классификация прерываний.

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

· корректное возвращение к прерванной программе.

Введение полноценного механизма прерываний позволит реализовать на платформе УУМ-32 микроядро операционной системы. Такой подход к разработке в совокупности аппаратным контролем границ адресного пространства процессов позволит разработать непревзойденную в настоящий момент по защищенности исполнения кода операционную систему. Хорошо отлаженное микроядро будет являться «стержнем» операционной системы. Даже при сбое в каком-то из модулей операционной системы, микроядро будет сохранять свою жизнеспособность и своевременно перезагружать «обручившиеся» компоненты. Большинство системных сбоев будет проходить незаметно для пользователя. Это позволит свести к минимуму эмоциональную нагрузку, связанную с недовольством пользователей из-за возникающих ошибок: ошибки будут просто не видны, а пользователи спокойны.



2. Анализ инструментальных средств разработки

2.1 Средства моделирования

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

AllFusion Process Modeler 7 (ранее BPwin) - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusion Process Modeler 7 можно использовать для графического представления бизнес-процессов. Эта система помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты.

AllFusion Process Modeler 7 поддерживает методологии IDEF0 (функциональная модель), IDEF3 (Work-Flow Diagram) и DFD (DataFlow Diagram). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы, и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования.

AllFusion Process Modeler 7 с использованием IDEF0 методологии позволяет наглядно представить выбранную систему как совокупность взаимодействующих функций и задач. Функции и задачи системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов.

К основным преимуществам выбора этого инструмента можно отнести следующее:

· используются очень простые элементы - блоки и стрелки;

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

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

· в программе осуществляется автоматическая нумерация обозначений, диаграмм и элементов, что значительно упрощает навигацию;

· каждая диаграмма модели располагается на отдельном листе и распечатывается в виде многостраничного отчета.

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



2.2 Средства разработки программного обеспечения

В качестве среды разработки программного обеспечения выбрана интегрированная среда разработки Microsoft Visual Studio 12 Professional.

Microsoft Visual Studio -- линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, Xbox, Windows Phone .NET Compact Framework и Microsoft Silverlight.

Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования или инструментов для прочих аспектов процесса разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server).

Visual Studio включает один или несколько компонентов из следующих:

· Visual Basic .NET

· Visual C++

· Visual C#

· Visual F# (включён начиная с Visual Studio 2010)

Приложение, разработанное в рамках данного дипломного проекта, целиком написано на языке Microsoft C# 4.0.

Язык C# является объектно-ориентированным языком программирования. Он был разработан в 1998-2001 компанией Майкрософт. C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов (в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщённые типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.

C# разрабатывался как язык программирования прикладного уровня для CLR (англ. Common Language Runtime -- общеязыковая исполняющая среда -- исполняющая среда, интерпретирующая код на языке CIL в байт-код, в который компилируются программы, написанные, в частности, на .NET-совместимых языках программирования) и, как таковой, зависит, прежде всего, от возможностей самой CLR. Это касается, прежде всего, системы типов C#, которая отражает BCL (Base Class Library -- стандартная библиотека классов платформы «.NET Framework»).

CLR предоставляет C#, как и всем другим .NET-ориентированным языкам, многие возможности, которых лишены «классические» языки программирования. Например, сборка мусора не реализована в самом C#, а производится CLR для программ, написанных на C# точно так же, как это делается для программ на VB.NET, J# и др.

В ходе непрерывного процесса уточнения, адаптации и нововведений C# продемонстрировал способность быстро реагировать на потребности программистов в переменах. Об этом свидетельствуют многие новые возможности, введенные в язык с момента выхода исходной версии 1.0 в 2000 году. Благодаря такой способности быстро приспосабливаться к постоянно меняющимся потребностям в области программирования C# постоянно остается живым и новаторским языком. А, следовательно, он представляет собой один из самых эффективных и богатых своими возможностями языков в современном программировании. Именно поэтому ему было отдано предпочтение при разработке данного дипломного проекта.



3. Техническое задание. Структурная и функциональная схемы ПО

3.1 Техническое задание

3.1.1 Основание для разработки

Основанием для разработки Интегрированной среды разработки для УУМ-32 (далее просто Среды или Приложения) является необходимость создания программной системы, обеспечивающей возможность быстрой и удобной разработки программного обеспечения для УУМ-32.

3.1.2 Назначение разработки

Назначение Приложения состоит в обеспечении возможности быстрой и удобной разработки и оптимизации программного обеспечения для УУМ-32.

3.1.3 Требования к программным и аппаратным средствам

Минимальные требования к составу технических (аппаратных) средств:

· ПЭВМ с микропроцессором типа Pentium или аналогичным от компаний Intel или AMD с частотой не менее 1 ГГц

· ОЗУ не менее 512 МБайт

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

· Операционная система Microsoft Windows XP, Windows Vista, Windows 7, Windows 8 или более новая (32 или 64-разрядная)

· Программная платформа Microsoft .NET Framework версии 4.0 или выше

· Распространяемый пакет Microsoft Visual C++ 2010

Входные и выходные данные

1) Входные данные

Входными данными для Приложения является исходный код программы на языке Макроассемблера для УУМ-32 либо сохраненный ранее файл с исходным кодом.

2) Выходные данные

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

Выходные данные компилятора:

· Файл, содержащий преобразованный в чисто ассемблерный код исходный код программы;

· Файл, содержащий объектный код программы. Является входным для компоновщика;

· Файл листинга;

· Список ошибок, обнаруженных во время компиляции;

Выходные данные компоновщика:

· Исполнимый файл программы (двоичный образ). Является входным для эмулятора;

· Файл определений внешних имен ESTAB;

· Файл таблицы использования внешних имен CRTAB;

· Список ошибок, обнаруженных в процессе связывания;

Выходные данные эмулятора:

· Данные, полученные во время выполнения исполнимого файла программы;

Требования к основным режимам работы

1) Основные функции Приложения

Разрабатываемая среда должна поддерживать выполнение следующих основных функций:

· Обеспечение возможности создания, редактирования и сохранения файлов, содержащих исходные коды программы, коды макроопределений и других текстовых файлов стандартными для операционных систем семейства Microsoft Windows способами в мультидокументном режиме (одновременное редактирование нескольких файлов)

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

· Обеспечение возможности поиска и исправления ошибок, допущенных во время разработки программ

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

2) Интерфейс пользователя Приложения

Основным элементом интерфейса пользователя Приложения является Главное окно. Оно представляет собой контейнер для размещения на нем всех остальных элементов пользовательского интерфейса. Главное окно содержит:

· Заголовок. В заголовке окна отображается название приложения

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

§ меню Файл. Содержит команды создания, сохранения и закрытия файлов, а также завершения работы среды

§ меню Правка. Содержит команды текстового редактора.

§ меню Вид. Содержит команды включения/отключения отображения ряда элементов Главного окна

§ меню Запуск. Содержит команды компиляции и запуска разработанных программ

§ меню Настройка. Содержит команды открытия окон настройки параметров среды

§ меню Окно. Содержит команды организации окон открытых документов

§ меню Справка. Содержит команду вызова информационного окна

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

· Строка состояния. Содержит информацию о текущем состоянии среды.

· Окно вывода. Служит для отображения данных, выдаваемых внешними приложениями.

· Окно списка ошибок. Служит для отображения обнаруженных в процессе компиляции ошибок.

· Окно обозревателя ключевых слов. Содержит исчерпывающую справочную информацию по всем элементам языка Макроассемблера для УУМ-32.

· Окно редактирования исходного кода программы. Предназначено для обеспечения удобного ввода и редактирования исходного кода программы.

3) Установка Приложения

Установка Приложения на компьютер пользователя должна осуществляться путем распаковки архива, содержащего пакет Приложения, в выбранную пользователем папку. Предварительно может потребоваться установка некоторых необходимых пакетов (см. пункт 4.3.2 - Минимальные требования к составу программных средств)

4) Запуск и завершение работы Приложения

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

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

5) Обработка Приложением ошибок пользователя

Ошибки пользователя можно разделить на две категории:

· Ошибки, допускаемые пользователем при работе со средой

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

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

· Ошибки в исходном коде программы.

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

Требования к программной документации

Описание Приложения должно быть представлено в следующих документах:

· Техническое задание на разработку

· Руководство оператора

Стадии и этапы разработки

Этапы и стадии разработки приведены в таблице 3.1.

Таблица 3.1. Стадии и этапы разработки

№ этапа	Название этапа	Сроки
1	Разработка Технического задания	31.03.2014 - 03.04.2014
2	Разработка альфа-версии Приложения	04.04.2014 - 08.04.2014
3	Разработка бета-версии Приложения	09.04.2014 - 15.04.2014
4	Разработка документации	16.04.2014 - 20.04.2014
5	Тестирование и исправление ошибок	21.04.2014 - 03.05.2014
6	Подготовка и проведение приемо-сдаточных испытаний	04.05.2014 - 05.05.2014

Порядок контроля и приемки

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

· Технического задания на разработку Приложения

· Руководства оператора

· Исполнимого пакета Приложения

· Результатов тестирования

· Контрольного (приемо-сдаточного) примера.

3.2 Структурная схема ПО

Структурная схема разработанного программного обеспечения приведена на рисунке 3.1.

Рисунок 3.1. Структурная схема ПО



3.3 Функциональная схема ПО

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

Рисунок 3.2 Контекстная диаграмма

Далее функция решения задачи на УУМ-32 декомпозируется на вложенные функции, которые выполняются последовательно:

1) Подготовка исходного кода программы

2) Компиляция исходного кода программы. Построение объектного кода. Выдача листинга.

3) Компоновка объектного кода программы. Выдача исполнимого кода.

4) Запуск исполнимого кода на эмуляторе УУМ-32.

Этот уровень декомпозиции приведен на рисунке 3.3.



Рисунок 3.3 Диаграмма декомпозиции процесса решения задачи

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

Процесс компиляции можно разделить на два этапа:

1) Этап обработки макроинструкций

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

2) Компиляция ассемблерного кода

На этом этапе выполняется компиляция ассемблерного кода, построенного на предыдущем шаге.

Диаграмма декомпозиции процесса компиляции приведена на рис. 3.4



Рисунок 3.4 Диаграмма декомпозиции процесса компиляции исходного кода программы

Дальнейшая декомпозиция будет выполняться для обоих этапов:

1) Декомпозиция процесса обработки макроинструкций

Диаграмма декомпозиции этого шага представлена на рисунке 3.5.

Рисунок 3.5 Диаграмма декомпозиции процесса обработки макроинструкций

Как видно из рисунка 3.5, обработка макроинструкций выполняется в два этапа. Диаграммы декомпозиции этих этапов приведены на рисунке 3.6 и 3.7 соответственно.



Рисунок 3.6 Диаграмма декомпозиции процесса построения списка макросов

Рисунок 3.7 Диаграмма декомпозиции процесса построения ассемблерного кода

2) Декомпозиция процесса компиляции ассемблерного кода

Диаграмма декомпозиции процесса компиляции ассемблерного кода приведена на рисунке 3.8.

Рисунок 3.8 Диаграмма декомпозиции процесса компиляции ассемблерного кода

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

Как видно из этого рисунка, процесс выполняется в три прохода:

· Первый проход

На этом этапе выполняется подготовка таблицы символических имен и списка инструкций для трансляции.

· Промежуточный проход

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

· Второй проход

На этапе второго прохода выполняется построение объектного кода программы и листинга. Диаграмма декомпозиции этого этапа приведена на рисунке 3.12.

Рисунок 3.9 Диаграмма декомпозиции процесса построения объектного кода секций и выдачи листинга



Рисунок 3.10 Диаграмма декомпозиции первого прохода компилятора

Рисунок 3.11 Диаграмма декомпозиции промежуточного прохода компилятора

Рисунок 3.12 Диаграмма декомпозиции второго прохода компилятора

1 Реализация программного обеспечения

В процессе реализации программного обеспечения было разработано два автономных приложения: Интегрированная среда разработки для УУМ-32 и Макроассемблер для УУМ-32, представляющее собой компилятор и подключаемое к среде как внешнее приложение.

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



4. Описание приложения «Интегрированная среда разработки для УУМ-32»

4.1.1 Общие сведения

Приложение «Интегрированная среда разработки для УУМ-32» UUM32IDE (в дальнейшем просто Приложение, или Среда) предназначено для обеспечении возможности быстрой и удобной разработки и оптимизации программного обеспечения для УУМ-32.

Приложение написано на языке Microsoft C# версии 4.0. Разработка приложения выполнялась в интегрированной среде разработки Microsoft Visual Studio Professional 2012. Для работы Приложения на компьютере пользователя должна быть установлена операционная система Microsoft Windows XP, Windows Vista, Windows 7 или Windows 8 или более новая с пакетом Microsoft .NET Framework версии 4.0 или выше. Также требуется наличие установленного распространяемого пакета Microsoft Visual C++ 2010.

Для работы с Приложением конечный пользователь (оператор) должен обладать практическими навыками работы с графическим интерфейсом операционной системы семейства Microsoft Windows, а также обладать умением написания программ на языке Макроассемблера для УУМ-32.

4.1.2 Функциональное назначение приложения

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

4.1.3 Описание структуры приложения

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

· Оболочки, служащей контейнером для всех остальных компонентов и предоставляющей инструменты управления ими

· Мультидокументного текстового редактора с подсветкой синтаксиса и встроенной системой подсказок

· Внешних автономных приложений:

§ Компилятор (Макроассемблер УУМ-32)

§ Компоновщик

§ Эмулятор УУМ-32

· Компонента управления работой внешних приложений

· Вспомогательных компонентов:

§ Обозреватель ключевых слов Макроассемблера УУМ-32

§ Компонент перехвата и отображения потока вывода внешних приложений

§ Компонент для представления списка ошибок компиляции

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

· Подготовка исходного кода программы

· Компиляция исходного кода программы. Построение объектного кода программы.

· Компоновка объектного кода программы. Построение исполнимого кода программы.

· Запуск исполнимого кода программы на эмуляторе.

Используемые технические средства

Минимальные требования к составу используемых технических (аппаратных) средств:

· ПЭВМ с микропроцессором типа Pentium или аналогичным от компаний Intel или AMD с частотой не менее 1 ГГц

· ОЗУ не менее 512 МБайт

Вызов и загрузка

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

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

Входные данные

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

Рабочие данные - это данные, для работы с которыми непосредственно и предназначено приложение. К рабочим данным относится исходный код программного модуля или код макробиблиотеки. Эти данные могут как вводиться вручную, так и быть загружены из файла, сохраненного на носителе. Подробная их характеристика приводится в разделе 4.2 «Описание приложения «Макроассемблер для УУМ-32»».

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

1) Конфигурационный файл приложения. Конфигурационный файл приложения представляет собой XML-файл, хранящий настройки всех параметров приложения. Корневым узлом этого файла является узел с именем “UUM32IDESettings”. Настройки, хранящиеся в файле, можно разделить на две группы: настройки внешний приложений и настройки текстового редактора.

Раздел настроек внешних приложений в файле представлен узлом с именем “ExternalApplicationPaths”, который имеет один аргумент “relative”. Этот аргумент определяет, являются ли заданные пути к внешним приложениям абсолютными или относительными (т.е. пути будут рассчитываться относительно исполнимого файла среды). Аргумент может принимать значения “True” и “False”. Узел “ExternalApplicationPaths” имеет три дочерних узла с именем “App”, каждый из которых представляет одно из внешних приложений (компилятор, компоновщик, эмулятор). Узел “App” не имеет дочерних узлов, все параметры внешнего приложения задаются с помощью следующих атрибутов:

· id. Этот атрибут определяет, какое из внешних приложений описывает узел. Может принимать значения “Compiler”, “Linker” или “UUM32”.

· exe. Этот атрибут содержит абсолютный или относительный путь к исполнимому файлу внешнего приложения, которое он представляет.

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

§ %FILENAMEMASK% - необходима для подстановки вместо нее имени файла без расширения

§ %FILENAMEEXTMASK% - необходима для подстановки вместо нее имени файла с расширением

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

Настройки текстового редактора разбиты на несколько подразделов:

· Настройки нумерации строк. В файле этот раздел представлен единичным узлом с именем “LinesNumeration”, который не содержит дочерних узлов и имеет следующие аргументы:

§ enabled - определяет, включена ли нумерация строк. Может принимать значения “True” и “False”.

§ color - задает цвет цифр нумерации в виде 32-битного числа, записанного в шестнадцатеричном виде.

§ bgColor - задает цвет фона поля нумерации в виде
32-битного числа, записанного в шестнадцатеричном виде.

Рассматриваемые далее узлы определяют стиль текста и являются дочерними узлами одного общего узла с именем “Styles”:

· Настройки шрифта. Настройки основного шрифта поля ввода текстового редактора задаются в узле “Font” со следующими атрибутами:

§ name - задает имя шрифта

§ size - задает размер шрифта

§ charset - задает набор символов для шрифта

§ bgColor - задает цвет фона

Узел “Font” не имеет дочерних узлов.

· Настройки подсветки синтаксиса. Для этих настроек в файле предусмотрен узел “TextElementStyles” с одним атрибутом “enabled”, определяющим, включена ли подсветка синтаксиса (может принимать значения “True” и “False”). Этот узел содержит три дочерних узла:

§ Узел “StandartElementsStyles”. Данный узел содержит несколько дочерних узлов “StandartStyle”, каждый из которых представляет один из видов стандартных элементов исходного текста программы (просто текст, комментарий, строковой литерал и т.п.) и имеет следующие атрибуты:

- id - задает идентификатор вида стандартного элемента (“Default”, “ Comment” или “ String”)

- name - задает описание вида стандартного элемента

- color - задает цвет, которым следует выделять все стандартные элементы данного вида в редакторе исходного кода

- style - определяет стиль шрифта (обычный, наклонный, полужирный) для всех стандартных элементов данного вида

§ Узел “Keywords”. Этот узел определяет путь к xml-файлу, содержащему информацию об элементах языка Макроассемблера для УУМ-32. Он имеет атрибут “fileName”, в котором задается абсолютный или относительный путь к этому файлу.

§ Узел “KeywordsStyles”. В этом узле определены настройки стилей, применяемых к различным элементам языка Макроассемблера для УУМ-32, которые определены в файле, заданном в узле Keywords. Узел KeywordsStyles содержит несколько дочерних узлов с именем “KeywordStyle”, каждый из которых представляет одну из групп ключевых слов. Эти узлы имеют следующие атрибуты:

- name - задает имя (тип) группы ключевых слов (например, “Директивы ассемблера”)

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

- style - определяет стиль шрифта (обычный, наклонный, полужирный) для всех ключевых слов данной группы

· Настройки ширины колонок. Этот раздел в файле представлен узлом “Indents”, который содержит одну строку, состоящую из нескольких чисел, разделенных пробелом. Каждое число определяет ширину (в символах) очередной по счету колонки.

Пример конфигурационного файла приведен в Приложении 2.

2) Файл, содержащий информацию об элементах языка Макроассемблера для УУМ-32. Этот файл также является XML-файлом. Корневой узел имеет имя “UUM32AssemblerKeywords”. Внутри него определяется несколько дочерних узлов “Keywords”, каждый из которых представляет одну группу ключевых слов Макроассемблера для УУМ-32. Узел “Keywords” имеет один атрибут “type”, который определяет имя (тип) группы ключевых слов (например, “Директивы ассемблера”). Каждый из узлов “Keywords” содержит один или несколько узлов с именем “Keyword”. Узел “Keyword” представляет одно ключевое слово и имеет следующие атрибуты:

· name - определяет само ключевое слово

· hint - задает подсказку для данного ключевого слова

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

Выходные данные

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

Выходные данные компилятора:

· Файл, содержащий преобразованный в чисто ассемблерный код исходный код программы;

· Файл, содержащий объектный код программы. Является входным для компоновщика;

· Файл листинга;

· Список ошибок, обнаруженных во время компиляции;

Выходные данные компоновщика:

· Исполнимый файл программы (двоичный образ). Является входным для эмулятора;

· Файл определений внешних имен ESTAB;

· Файл таблицы использования внешних имен CRTAB;

· Список ошибок, обнаруженных в процессе связывания;

Выходные данные эмулятора:

· Данные, полученные во время выполнения исполнимого файла программы.

4.2 Описание приложения «Макроассемблер для УУМ-32»

Общие сведения

Приложение «Макроассемблер для УУМ-32» (в дальнейшем просто Приложение, Компилятор или Макроассемблер) предназначено для компиляции исходного кода программ, написанных на языке Макроассемблера для УУМ-32.

Приложение написано на языке Microsoft C# версии 4.0. Разработка приложения выполнялась в интегрированной среде разработки Microsoft Visual Studio Professional 2012. Для работы Приложения на компьютере пользователя должна быть установлена операционная система Microsoft Windows XP, Windows Vista, Windows 7 или Windows 8 или более новая с пакетом Microsoft .NET Framework версии 4.0 или выше.

Для работы с Приложением конечный пользователь (оператор) должен обладать практическими навыками работы с командной строкой операционной системы семейства Microsoft Windows, а также обладать умением написания программ на языке Макроассемблера для УУМ-32.

4.2.1 Функциональное назначение приложения

Функциональное назначение приложения состоит в следующем:

· Обработка макроинструкций, заданных как непосредственно в коде, так и в подключаемых макробиблиотеках

· Трансляция мнемонических кодов операций в их эквиваленты на машинном языке

· Преобразование символических операндов в эквивалентные им машинные адреса

· Построение машинных команд в соответствующем формате

· Преобразование констант, заданных в исходной программе, во внутреннее машинное представление

· Запись объектной программы

· Выдача листинга

4.2.2 Описание логической структуры приложения

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

· Макропроцессора, предназначенного для обработки макроинструкций

· Ассемблера, предназначенного для компиляции исходного кода программы, написанной на языке Ассемблера для УУМ-32 (язык Ассемблера отличается от языка Макроассемблера отсутствием возможности работы с макросами)

4.2.3 Используемые технические средства

Минимальные требования к составу используемых технических (аппаратных) средств:

· ПЭВМ с микропроцессором типа Pentium или аналогичным от компаний Intel или AMD с частотой не менее 1 ГГц

· ОЗУ не менее 512 МБайт

4.2.4 Вызов и загрузка

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

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

Входные данные

Входными данными для приложения являются файлы, содержащие исходный код программы. Приложение поддерживает несколько типов файлов:

· Файлы, содержащие исходный код программы на языке Ассемблера для УУМ-32. Обязательно должны иметь расширение “.uum32asm”

· Файлы, содержащие исходный код программы на языке Макроассемблера для УУМ-32 (Ассемблер + макроинструкции). Файлы этого типа имеют расширение “.uum32masm”.

· Файлы, представляющие библиотеки макросов. В этих файлах хранятся только макроопределения. Они не могут быть непосредственно переданы Макроассемблеру на обработку и используются только как подключаемые (в макродирективе INCLUDE). Файлы макробиблиотек имеют расширение “.uum32mlb”.

Информация о языке Макроассемблера для УУМ-32 приведена в разделе в документе «Описание языка Макроассемблера для УУМ-32».

Выходные данные

Выходными данными Приложения являются:

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

· Файл, содержащий объектный код программы. Объектный файл содержит машинное представление символических команд и данных, а также записи, необходимые для работы компоновщика. Ниже приведено краткое описание формата объектных файлов УУМ32:

§ Формат объектных файлов - текстовый, записи представляют собой строки, разделённые символами перевода строки.

§ Пустые и некорректные строки игнорируются (это сделано, чтобы можно было вставлять комментарии в учебных целях).

§ Строки состоят из полей, разделяемых символом "|" (ASCII 7C).

§ Некоторые поля (имена секций) имеют переменную (произвольную) длину.

§ Несимвольные поля (адреса, объектный код) записываются в шестнадцатеричном виде.

Виды записей объектного файла:

1) Заголовок секции

Формат: H|ИМЯ|ДЛИНА

В одном объектном файле может быть несколько секций.

2) Объектный код

Формат: T|АДРЕС_БЛОКА|ДЛИНА_БЛОКА|ОБЪ_КОД_БЛОКА

- АДРЕС_БЛОКА - 4 байта

- ДЛИНА_БЛОКА - 1 байт

- ОБЪ_КОД_БЛОКА - шестнадцатеричные коды команд и данных, разделённые символом '|'

3) Модификатор

Формат: M|АДРЕС_ПОЛЯ|ДЛИНА_ПОЛЯ|ИМЯ<+/->

- "+" - значение имени прибавляется

- "-" - значение имени вычитается

адрес - 4 байта, длина - 1 байт.

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

4) Определение внешних имён (экспорт из секции)

Формат: D|ИМЯ1|АДРЕС1|ИМЯ2|АДРЕС2...

5) Список внешних ссылок (импорт в секцию)

Формат: R|ИМЯ1|ИМЯ2|...

6) Конец секции

Формат: E

Пример объектного файла см. в Приложении 5.

· Файл листинга. Листинг представляет собой текстовый файл, который содержит:

§ Текст исходной программы с удаленными комментариями и удобочитаемой структурой

§ Адреса каждой команды и записи данных