Как составить техническое описание программы

 vlada_maestro / shutterstock

Пишет о программировании, в свободное время создаёт игры. Мечтает открыть свою студию и выпускать ламповые RPG.

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

Содержание

• Два вида документации
• Правила хорошего тона в составлении документации
• Где писать документацию в C#
• Как создать файл документации
• Заключение

Разработчики имеют дело с двумя основными видами документации:

1. Пользовательская документация. Это руководство по эксплуатации программ. Обычно оно нужно для сложных профессиональных инструментов. Если же пользователи не могут сами разобраться в приложении пиццерии, то лучше доработать интерфейс — добровольно никто инструкцию читать не станет.
2. Техническая документация. Это пояснения для программистов, которые будут использовать или дорабатывать существующий код. Они помогут быстро вникнуть в проект и начать работать. Или же продолжить писать программу после долгого перерыва.

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

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

1. Документация нужна не всегда

Если программа одноразовая, не стоит тратить время на написание пояснений. Например, если нужен небольшой скрипт, который будет написан за пять минут и использован 1-2 раза.

2. Документация нужна не везде

Также не нужно писать пояснения ко всему. Если код написан хорошо, то по названиям уже будет понятно, что это такое и зачем оно используется. Например, легко догадаться, что метод int Sum (int a, int b) возвращает результат сложения двух чисел.

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

3. Документация должна быть точной

Очень важно уметь ясно выражать свои мысли. Нужно предельно точно описывать, что делает тот или иной фрагмент кода. Для этого стоит давать как можно более короткие определения. Например:

/// <summary>
/// Сообщение в чате. 
/// </summary>
class Message
{
	…
	/// <summary>
	/// Текст сообщения. 
	/// </summary>
	public string Text
	{
		get { return this.text; }
}
}

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

4. Документация должна быть сухой

Хотя канцеляризмов нужно избегать, писать надо максимально сухо и по делу. Никаких стихов, метафор, аналогий или шуток — всё это может быть забавным, но не добавляет ясности.

5. В документации не должно быть старого кода

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

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

Если есть сомнения пригодится ли еще этот код, его лучше сохранить в системе контроля версий — именно для этого ее и придумали.

Дальше речь пойдет о том, как писать техническую документацию для программ на C#. Вся работа будет вестись в Visual Studio.

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

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

В C# есть два вида комментариев. Однострочные:

int a = 11 + 12; //Это однострочный комментарий

И многострочные:

/* Начало комментария
Это
Многострочный
Комментарий
Конец комментария */

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

Более продвинутый вариант — использовать XML. Чтобы вставить XML-комментарий, нужно перед названием класса, поля, свойства или метода поставить тройной слеш.

После этого автоматически будет создано два элемента:

1. Summary — общий комментарий. В нем пишут, что делает метод или для чего нужен класс.
2. Param — комментарий об аргументе. В нем указывается, какое значение надо передать.

Практически все инструменты, в том числе и Visual Studio, поддерживают вывод подсказок, которые подгружаются из документации. И теперь, если навести на метод Main () или его аргумент, то можно увидеть, что было написано в комментарии.

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

Еще можно использовать такие XML-элементы, как:

• Returns — возвращаемое значение;
• Value — значение свойства;
• Exception — исключение;
• Remarks — ремарка к основному комментарию.

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

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

Для этого сначала нужно зайти в настройки проекта:

А потом перейти во вкладку Build и поставить галочку XML documentation file:

Теперь вместе с компиляцией программы будет создаваться файл с документацией в формате XML. Его можно преобразовать в HTML с помощью специальных утилит. Microsoft для этого рекомендует использовать DocFX или Sandcastle.

Рассмотрим на примере DocFX. Его можно скачать с помощью NuGet Package Manager в Visual Studio. Для этого нажмите на проект правой кнопкой мыши и выберите пункт Manage NuGet Packages:

Затем перейдите во вкладку Browse и введите в поле поиска название docfx.console, а потом нажмите Install:

После нужно подтвердить установку и согласиться с условиями лицензионного соглашения.

Теперь при сборке проекта будет создаваться папка _site, в которой находится сайт с документацией. Однако это касается класса Program, поэтому чтобы проверить работу DocFX, нужно добавить какой-нибудь класс:

namespace ConsoleApp1
{
	/// <summary>
	/// Класс, который представляет пользователя.
	/// </summary>
	public class User
	{
		private string name;

		/// <summary>
		/// Конструктор класса.
		/// </summary>
		/// <param name="name">Имя пользователя.</param>
		public User(string name)
		{
			this.name = name;
		}

		/// <summary>
		/// Меняет имя пользователя.
		/// </summary>
		/// <param name="name">Имя пользователя.</param>
		public void ChangeName(string name)
		{
			this.name = name;
		}

		/// <summary>
		/// Метод для вывода имени пользователя.
		/// </summary>
		/// <returns>Возвращает имя пользователя.</returns>
		public string GetName()
		{
			return this.name;
		}

	}
}

После компиляции проекта с таким классом можно проверить сайт. Его главная страница будет пуста — она нужна для того, чтобы вкратце описать свою программу. Сама же документация находится по адресу api/index.html.

Вот как она выглядит:

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

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

ТЗ на разработку программного обеспечения

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

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

Что такое ТЗ на разработку ПО?

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

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

Правильно составленное техническое задание дает четкую связку заказчик-исполнитель,
что позволяет обеим сторонам понимать друг друга. Грамотное ТЗ устанавливает следующее:

• Главное назначение разрабатываемого ПО.

• Характеристики и функциональность.

• Технико-экономические обоснования разработки.

• Предписание по выполнению стадий, этапов работы.

Чем детальнее составлено техническое задание, тем лучше. Благодаря этому заказчик понимает,
что именно ему нужно, может контролировать исполнителя на предмет соответствия продукта ТЗ.
Исполнитель в свою очередь получает точные сведения относительно задачи, может спланировать
проект, а также персональный план по ее воплощению.

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

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

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

• 1.

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

• 2.

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

• 3.

  Инструментальное ПО. Средства, создаваемые для отладки, редактирования софта.

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

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

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

2. Технический проект. Документ, в котором подробно прописывается последовательность действий для софта.

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

Информационный комплекс и структура технического задания

Как отмечалось выше, техническое задание должно быть четким и понятным обеим сторонам. На первом этапе должны быть
сформулированы правила к разрабатываемой информационной системе. Все непонятные вопросы проясняются, что позволяет
избежать недопонимания. Практика подтверждает, что на разработку ТЗ уходит до 25-30% от всех затрат. Это связано
с потребностью в техническом проектировании, глубокой аналитической и технической работе.

Многое в ТЗ зависит от языка программирования, на котором будет создана программа. К примеру, если софт
разрабатывается на языке С++, то требуется детальное техническое проектирование. Что касается софта, создаваемого
на платформе 1С, ее проектируют по классической схеме. Все правила прописываются в отдельном разделе. К каждому из
них прикладывается план, предусматривающий выполнение с поэтапной структурой. Таким образом, создание
ТЗ – сложная работа, требующая затрат сил, времени.

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

• 1.

  Общая информация.

• 2.

  Цели разработки (развития), назначение.

• 3.

  Характеристика объектов автоматизации.

• 4.

  Главные нормы будущего софта.

• 5.

  Состав, содержание работ по созданию системы.

• 6.

  Порядок контроля, приемки готового ПО.

• 7.

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

• 8.

  Нормы к документированию процесса.

• 9.

  Источники для выполнения поставленной цели.

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

ГОСТы к техническому заданию на разработку программного обеспечения

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

Для лучшего понимания отличий методологии при составлении ТЗ, стоит подробнее рассмотреть эти ISO и нормы, которые
используются для выполнения поставленной задачи. Это позволит лучше понять отличия и пользоваться тем ГОСТом,
который подходит наилучшим образом.

ГОСТ 34

Используется для разработки систем, предусматривающих не только разработку ПО, но также подбор нужного аппаратного
обеспечения. Это позволяет также выгодно автоматизировать информационные процессы на предприятии. По данному ГОСТу
при разработке ТЗ предусматриваются такие разделы:

• 1.

  Сведения общего характера.

• 2.

  Цели и задачи создания системы (софта).

• 3.

  Характеристика главных объектов автоматизации.

• 4.

  Нормы к разрабатываемой системе.

• 5.

  Состав с содержанием работ по созданию программы.

• 6.

  Порядок приемки системы с контролем со стороны заказчика.

• 7.

  Требования к содержанию работ по подготовке к вводу системы в действие.

• 8.

  Нормы к документированию.

• 9.

  Источники для создания софта.

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

ГОСТ 19

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

• 1.

  Введение.

• 2.

  Основания.

• 3.

  Назначение.

• 4.

  Требования к софту (программному изделию).

• 5.

  Особенности программной документации.

• 6.

  Технико-экономические показатели.

• 7.

  Стадии, этапы создания ПО.

• 8.

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

• 9.

  Приложения.

Данные ГОСТы используются далеко не всеми программистами. Ведь они были разработаны свыше 30 лет назад.
Для этого будет полезным рассмотреть более актуальные, новые стандарты,
применяемые для создания современного софта.

IEEE STD 830-1998

Данным документом определяются качественные характеристики, содержание, спецификация, нормы, которые
предъявляются к программному обеспечению. В документе даны конкретные определения основных понятий и терминов.
Чаще всего документ применяется при разработке задания для современного софта. Согласно стандарту,
ТЗ по IEEE STD 830-1998 включает в себя такие разделы:

1. Введение

• Назначение

• Область действия

• Определения, акронимы, сокращения

• Ссылки

• Краткий обзор

2. Общее описание

• Взаимодействие продукта (с другими продуктами и компонентами).

• Функции продукта (краткое описание).

• Характеристики пользователя.

• Ограничения.

• Допущения и зависимости.

3. Детальные требования

• Требования к внешним интерфейсам.

• Интерфейсы пользователя.

• Интерфейсы аппаратного обеспечения.

• Интерфейсы программного обеспечения.

• Интерфейсы взаимодействия.

• Функциональные требования.

• Требования к производительности.

• Проектные ограничения (и ссылки на стандарты).

• Нефункциональные требования (надежность, доступность, безопасность и пр.).

• Другие требования.

4. Приложение

5. Алфавитный указатель

Данный стандарт разработан американским Комитетом по стандартам программного обеспечения и системной инженерии C / S2ESC.

ISO/IEC/ IEEE 29148-2011

Наиболее современный стандарт, который обеспечивает единый способ трактовки в процессах при разработке ТЗ для ПО.
Оригинал IEEE доступен на английском языке. В состав входит 2 шаблона, каждый из которых рассмотрим подробней:

System requirements specification (SyRS)

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

1. Введение

• Назначение системы.

• Содержание системы (границы системы).

• Обзор системы.

• Содержание системы.

• Функции системы.

• Характеристики пользователей.

• Термины и определения.

2. Ссылки

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

• Функциональные требования.

• Требования к юзабилити.

• Требования к производительности.

• Интерфейс (взаимодействие) системы.

• Операции системы.

• Состояния системы.

• Физические характеристики.

• Условия окружения.

• Требования к безопасности.

• Управление информацией.

• Политики, правила.

• Требования к обслуживанию системы на протяжении ее жизненного цикла.

• Требования к упаковке, погрузке-разгрузке, доставке и транспортировке.

4. Тестирование и проверка (список нужных приемочных тестов, которые отражают зеркально раздел 3)

5. Приложение

• Предположения, зависимости.

• Аббревиатуры и сокращений.

Software requirements specification (SRS)

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

1. Введение

• Назначение.

• Содержание (границы).

• Обзор продукта.

• Взаимодействие продукта (с другими продуктами, компонентами).

• Функции продукта (краткое описание).

• Характеристики пользователей.

• Ограничения.

• Терминология, определение со значениями.

2. Ссылки

3. Детальные нормы

• Требования к внешним интерфейсам.

• Функции продукта.

• Параметры юзабилити.

• Нормы производительности.

• Требования к логической структуре БД.

• Ограничения проектирования.

• Системные свойства ПО.

• Дополнительные требования.

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложение

• Предположения, зависимости.

• Аббревиатуры и сокращений.

Такой стандарт пришел на смену IEEE STD 830-1998. Он также был разработан в США и сегодня
используется разными специалистами разных стран мира.

Заключение

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

< Вернуться к списку публикаций

Облако тегов

Техническое описание работы программы

В приложении
используются семь внешних процедур.
т.е. 7 файлов типа .PRGиз них один процедурный. Краткая
характеристик каждого из них:

• MENU.PRG-главный
  программный файл(приложение 1.1)

• FUNC.PRG-процедурный
  файл(приложение 1.2)

• OPEN.PRG-файл
  открытия БД(приложение 1.3)

• BAZES.PRG-файлBROWSE-окон(приложение
  1.4)

• ADD_DEL.PRG-файл
  дополнение и изменения данных(приложение
  1.5)

• RAS.PRG-файл
  расчетов квартплаты, льгот и их слияния(приложение 1.6)

• OTCHET.PRG-файл
  формирование отчетов(приложение
  1.7)

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

• Блок
  установочных команд SETопределяющих параметры конфигурации
  рабочей среды;

• Открытие
  баз данных и необходимых индексных
  файлов;

• Определение
  глобальных переменных, массивов и их
  инициализация;

• Определение
  и описание окон;

• Описание
  и активизация работы главного меню для
  выбора основных вариантов работы
  системы и передача управления
  соответствующим программным файлам
  или подпрограммам;

• Закрытие
  баз данных и выход из СУБД.

Сейчас
рассмотрим работу приложения в той
последовательности, как она выполняется
по шаговом выполнении каждого кода в
окне трассировки. Для чего, при чтении
данной главы целеобразно запустить
среду FoxPro,открыть в окне
трассировки файлMENU.PRG в
режиме пошагового выполнения, либо
обращаться к приложению 1, где прилагаются
распечатки файлов программ

В первых
строках файла MENU.PRG с
помощью командSET устанавливается
операционная среда:

• Отключение
  макросов

• Установление
  даты

• Запрет
  отображения на экране записей помеченных
  на удаление

• Отключение
  статус-строки и т.д.

Далее
определяются и загружаются в память
цветовые схемы, которые используются
для раскраски окон и некоторых областей
внутри них.(SET COLOR OF SCHEME).
Подключается процедурный файл (FUNC.PRG),командойON ERROR и
функциейERROR()определяется анализ возможных ошибок
в программе.

Далее вызывается
процедура находящаяся в файле OPEN.PRG
(см. прилож. 1.3 стр. 1)
для открытия БД. Здесь проверяется
наличие баз на диске и если их нет, то
они создаются с помощью языкаSQL,
при этом в БДHELP, которая
состоит из одногоMEMO-поля,
копируются текстовые файлы помощи. Если
базы уже созданы ранее, то они открываются
в заданных областях вместе со структурными
индексами, которые содержатTAG’и
для связи БД и систематизированного
предъявления данных:

БД <RABOT.DBF>
(База жильцов)

• TAG-tab
  – индексирование по полю табельного
  номера, для связи с БД ставок (TABLE_R.DBF).

• TAG-fam
  – индексирование по полю фамилии,
  для поиска командойSEEK.

• TAG-n_lg
  – индексирование по полю номера
  льготы (код), для связи с БД льгот
  (LGOT.DBF).

• TAG-date
  – индексирование по полям периода
  действия льготы (dat_c,dat_po),
  для расчета сумм по льготникам,
  рассчитываются только те льготники, у
  кого период входит в текущую дату и кто
  не имеет периода действия льготы.

• TAG-lgt
  – индексирование по полям адреса,
  с условием, что предъявляться будут
  только жильцы, имеющие льготу.

• TAG-ord
  – индексирование по полям адреса,
  с условием, что предъявляться будут
  только те жильцы, кто платит за квартиру.

• TAG-adrr
  – индексирование по полям адреса
  и табельного номера, для связи с БД
  начислений (OPLATA.DBF), а
  также это главныйTAGпри
  просмотре данных.

БД <OPLATA.DBF
(База начислений)

• TAG-tab
  –индексирование по полю табельного
  номера.

• TAG-adr
  – индексирование по адресу, для
  связи с БД жильцов (RABOT.DBF)

БД <LGOT>
(БД льгот)

• TAG-n_lg
  – индексирование по полю номера
  льготы (код), для связи с БД жильцов
  (RABOT.DBF).

БД <TABLE_R
(БД ставок)

• TAG-tab
  – индексирование по полю табельного
  номера, для связи с БД жильцов (RABOT.DBF).

В том случае,
если индексных файлов не обнаружено,
то они создаются. Здесь также устанавливается
связь между базами по ключевым полям.
Связь между базами имеет структуру ОДИН
КО МНОГИМ, то есть БД жильцов является
родительской по отношению к другим.

Далее
объявляются глобальные перемены (PUBLIC)

_PAD_OTCH
– которое служит для анализа
формирования отчета если ее значение
.T.то отчет формируется,
если ее значение .F., которая
присваивается в процедуре дополнения,
то при выборе формирования отчета
программа просит провести слияние
квартплаты со льготами, где данной
переменной присваивается значение .Т.

_REC-
запоминает номер текущей записи в
БД

_FILTR-
имеет числовое значение и в зависимости
от значения устанавливает фильтр
предъявления данных в окне «Работа с
картотекой».

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

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

Команды DEFINE
MENU, DEFINE POPUP иDEFINE BAR
определяют и описывают расположение
на экране и работу основного меню.
КомандойON SELECTION PAD (BAR)
определяется реакция пунктов
меню при их выборе. Здесь нужно сказать,
что командаON SELECTION PAD может
использоваться в видеON
PAD в этом случае, при попадании
курсора на такойPAD-пункт
сразу вызовет действия определенные
при описании этих пунктов, а с добавлением
словаSELECTION, чтобы
выполнилось действие нужно непосредственно
его выбрать, то есть на
соответствующем пункте нажать клавишу
ввода (Enter).

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

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

Здесь функцией
RECCOUNT() проверяется
наличие записей в БД и если значение
равно нулю, то активируется окноVIB
в котором при помощи команд
ввода-вывода@…SAY…GET выводится
поясняющий текст(SAY)
и кнопки для выбора дальнейших действий(GET), которые активируются
командойREAD с опциейCYCLE, которая запрещает
выход из окна по достижении курсора
последнегоGET-объекта .GET–объекты часто
используется в программе, поэтому сейчас
разберем их подробнее.

В данном
случае используются кнопки меню, которые
определяются в команде FUNCTION
и обработка выбранной кнопки с
помощью командыVALID.
В процедуреINS2(),
которая описана в приложении 1.2 стр. Эти
объекты еще называют как средства
управления в стилеWINDOWS все
переменные, определенные командойGET
имеют или числовые значения, тогда
переменной присваивается номер объекта
в порядке его расположения в команде,
или символьные, тогда переменной
присваивается символьное описание
кнопки, а также для кнопок-переключателей
и радио-кнопок возможно логическое
значение переменной.

Затем в
процедуре с именем определенной командой
VALIDилиWHEN
осуществляется в структуреDO
CASE выбор дальнейших
действий в зависимости от значения
переменной. Например, в данном случае
в окне определены две кнопкиДополнить
и Отмена (FUNCTION
‘ * …’), которые
при их выборе присваивают числовое
значение переменнойins1 и
которая при выборе кнопки анализируется
в структуреDO CASE
в процедуреINS2. Eсли
выбрана кнопкаДополнить,то
переменнаяins1 принимает
значение 1(потому что эта
кнопка описана первой в командеFUNCTION
‘* …’), выполняется
условиеCASE
ins1=1 и следовательно выполняются
команды которые следуют после этого
условия (DO INS WITH 1).
Если выбор не происходит вообще, то
и процедура игнорируется.

Теперь еще раз пройдемся по
пунктам меню, и разберем его работу
с точки зрения языка программирования.
Начнем с пункта «СЕРВИС»

Соседние файлы в папке АРМ бухгалтера расчетчика квартплаты

• #

  27.06.201433.28 Кб311.DOC

• #

  27.06.201442.5 Кб292.DOC

• #
• #
• #

  27.06.20142.2 Кб28READ.TXT