Некоммерческое акционерное общество

              АЛМАТИНСКИЙ  УНИВЕРСИТЕТ  ЭНЕРГЕТИКИ  И  СВЯЗИ

Кафедра инженерной кибернетики

 

 

ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ

Методические указания к выполнению расчетно-графических работ

для студентов всех форм обучения

специальности 5В070200 – Автоматизация и управление

 

 

 

 

Алматы 2010 

СОСТАВИТЕЛИ: Н.В. Сябина. Технологии программирования. Методические указания к выполнению расчетно-графических работ для студентов всех форм обучения специальности 5В070200 – Автоматизация и управление. - Алматы: АУЭС, 2010. -  48 с.

     

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

1)    Использование структурного подхода при проектировании программного продукта.

2)    Проектирование и реализация пользовательского интерфейса в выбранной среде программирования.

3)    Тестирование и отладка программного продукта. Составление программной документации.

В приложениях содержится весь необходимый справочный материал.

    Методические указания предназначены для студентов всех форм обучения специальности 5В070200 – Автоматизация и управление.

 

1 Расчетно-графическая работа. Использование структурного подхода при проектировании программного продукта

 

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

 

1.1 Задания к расчетно-графической работе

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

б)    разработать техническое задание, которое должно включать титульный лист, введение, пункты по стандарту,

в)    с помощью пакета MS Project организовать управление проектом, а именно: разработать график распределения работ и организовать контроль хода его выполнения;

г)     разработать алгоритм решения задачи, выполнить его графическое описание одним из способов: для нечетных вариантов с помощью Flow-формы, для четных – с помощью диаграммы Насси-Шнайдермана;

д)    выполнить уточнение спецификаций, составить словарь терминов.

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

 

1.2 Общие рекомендации к выполнению работы

1.2.1 Постановка задачи и разработка технического задания

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

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

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

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

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

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

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

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

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

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

На техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». В соответствии с этим стандартом техническое задание должно содержать следующие раз­делы:

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

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

в)    Назначение разработки - содержит описание функцио­нального и эксплуатационного назначения программного продукта с указа­нием категорий пользователей;

г)     Требования к программе или программному изделию включает:

1)  подраздел Требования к функциональным характеристикам, в котором перечислены выполняемые функции, описаны состав, характеристики и фор­мы представления исходных данных и результатов; при не­обходимости указывают критерии эффективности (максимально допустимое время ответа системы, максимальный объем используемой оперативной и/или внешней памяти и др.);

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

3)  подраздел Условия эксплуатации, в котором указывают особые требования к условиям эксплуатации в нестандартных ус­ловиях (температура окружающей среды, относительная влажность воздуха и т. п.) или при использовании специальных внешних устройств (вид обслуживания, необходимое ко­личество и квалификация персонала);

4)  подраздел Требования к составу и параметрам технических средств, в котором указывают необходимый состав технических средств с указанием основ­ных технических характеристик (тип микропроцессора, объем памяти, нали­чие внешних устройств и т. п.) и варианта конфигурации (минимальная и рекомендуемая);

5)  подраздел Требования к информационной и программной совместимости, в котором задают методы решения, определяют язык или среду программирования для разработки, степень защиты информации, используемую опера­ционную систему и другие системные и пользовательские программные средства, взаимодействующие с разрабатываемым программ­ным обеспечением;

6)  подраздел Требования к маркировке и упаковке;

7)  подраздел Требования к транспортированию и хранению;

8)  подраздел Специальные требования;

д)    Требования к программной документации – содержит перечень  необходимой сопроводительной документации (руководство программиста, руководство пользователя, ру­ководство системного программиста, пояснительная записка и т. п.);

е)     Технико-экономические показатели – содержит сведения об ориентировочной экономической эффективности, предполагаемой годовой потребности и экономических преимуществах по сравнению с существующими аналогами;

ж)  Стадии и этапы разработки – содержит перечень стадий разработки и этапов, а также содержание работ с указанием сроков разработки и исполнителей;

з)     Порядок контроля и приемки -  содержит перечень видов испытаний и общие требования к приемке работы.

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

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

 

1.2.2 Использование офисного пакета Microsoft Project для управления проектами

При создании сложного программного обеспечения возникает необходимость в организации контроля процесса разработки и управления проектом. Поскольку к процессу разработки привлекается довольно много специалистов разного профиля, то координация их действий является важной задачей, которая весьма успешно решается с использованием современных CASE-средств. Наиболее простым и доступным программным продуктом, который позволяет планировать и отслеживать ход разработки, является офисный пакет Microsoft Project.

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

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

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

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

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

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

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

План работ лучше всего составлять в представлении Gantt Chart (Диаграмма Ганта).

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

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

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

MS Project содержит ряд автоматизированных средств для оперативного перепланирования, позволяющих быстро перенести невыполненную работу на время после заданной даты (текущей даты или даты отчета). Они запускаются автоматически в момент ввода данных по задачам (при установленных флажках в настройках расчетов, которые переносят невыполненные работы к дате отчета) или вручную в любой момент (с помощью панели инструментов и диалоговых окон обновления задач и проекта). Перепланирование можно также проводить вручную с помощью диаграмм с повременными данными, например Task Usage (Использование задач).

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

Отчет - это формат представления проектных данных, предназначенный для распечатки. В MS Project входит набор предопределенных отчетов, которые можно использовать в готовом виде или настроить. Самый простой статистический отчет, Project Statistics (Статистика проекта), вызывается с помощью кнопки Statistics (Статистика) из диалогового окна сведений о проекте.

 

1.2.3 Анализ требований и определение спецификаций

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

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

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

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

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

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

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

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

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

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

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

«термин – категория– краткое описание».

Пример выполнения словаря терминов приведен в таблице В.1.

 

1.2.4 Средства описания структурных алгоритмов

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

а)   линейный (для получения результата необходимо выполнить операции в определен­ной последовательности);

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

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

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

Для реализации трех основных управляющих конструкций в языках программирования высокого уровня имеются управляющие операторы. К базовым относят:

а)     следование - обозначает последовательное выполнение действий;

б)    ветвление -  выбор одного из двух вариантов действий;

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

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

а)     выбор - выбор одного варианта из нескольких в зависимости от значения некоторой величины;

б)    цикл-до - повторение действий до выполнения заданного условия, проверка которого осуществляется после выполнения действий в цикле;

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

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

Пример 1.1 – Использование блок-схемы для описания алгоритма поиска в массиве А(n) элемента, равного заданному (см. рисунок 1.1).

Рисунок 1.1 – Фрагмент блок-схемы алгоритма поиска

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

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

1) предполагает слишком низкий уровень детализации, что часто скрыва­ет суть сложных алгоритмов;

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

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

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

Пример 1.2 – Использование псевдокода для описания алгоритма поиска в массиве А(n) элемента, равного заданному (фрагмент).

i :=1

Цикл-пока  i £ n и A(i) ¹ Y

i := i + 1

Все-цикл

Если i £ n

          то Вывести «Элемент найден»

      иначе Вывести «Элемент не найден»

Все-если

 

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

Пример 1.3 – Использование Flow-форм для описания алгоритма поиска в массиве А(n) элемента, равного заданному (см. рисунок 1.2).

Рисунок 1.2 –  Flow-форма алгоритма поиска (фрагмент)

Диаграммы Насси-Шнейдермана являются развитием Flow-форм. Основное их отличие от Flow-форм заклю­чается в том, что область обозначения условий и вариантов ветвления изоб­ражают в виде треугольников. Такое обозначение обеспечивает большую наглядность представления алгоритма.

Пример 1.4 – Использование диаграмм Насси-Шнейдермана для описания алгоритма поиска в массиве А(n) элемента, равного заданному (см. рисунок 1.3).

Рисунок 1.3 –  Фрагмент диаграммы Насси-Шнейдермана

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

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

 

1.3 Контрольные вопросы

1.3.1    Назовите основные этапы разработки программного обеспечения.

1.3.2 Какие задачи решаются на основных этапах разработки?

1.3.3 Какова цель и результаты предпроектных исследований?

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

1.3.5  Перечислите основные эксплуатационные требования к программным продук­там.

1.3.6 Что понимается под термином «проект»? В чем заключается управление проектом?

1.3.7  Что такое задача? Какими свойствами она обладает?

1.3.8    Какие ресурсы предусмотрены для использования в проектах?

1.3.9    Как организуется связь между задачами и ресурсами?

1.3.10 Что понимается под термином «представление»?

1.3.11 Как осуществляется отслеживание проекта? Каких принципов следует придерживаться при этом?

1.3.12  Что такое базовый план и чем он отличается от текущего?

1.3.13  Какие отчеты входят в состав MS Project и какую информацию с их помощью можно получить?

1.3.14 Какие стандартные отчеты предусмотрены в MS Project?

1.3.15  Что представляют собой спецификации программного обеспечения?

1.3.16   Какие методы существуют для уточнения спецификаций?

1.3.17   Какие средства используются для описания алгоритмов?

1.3.18   Какие способы описания алгоритмов подходят для разработки структурных программ?

1.3.19   Какие структуры относятся к базовым и какие к дополнительным?

1.3.20   В чем заключается недостаток описания алгоритмов с помощью Flow-форм и диаграмм Насси-Шнейдермана?

 

 

2 Расчетно-графическая работа. Проектирование и реализация пользовательского интерфейса в выбранной среде программирования

 

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

 

2.1 Задания к расчетно-графической работе

Для спроектированного в предыдущей расчетно-графического работе программного продукта:

а) разработать структурную схему;

б) разработать функциональную схему;

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

г) спроектировать пользовательский интерфейс;

д) выполнить программную реализацию (создать исполняемый файл с расширением *.ехе).

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

 

2.2 Общие рекомендации к выполнению расчетно-графической работы

2.2.1 Разработка структурной и функциональной схем

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

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

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

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

Рисунок 2.1 - Пример структурной схемы программного комплекса

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

Рисунок 2.2 - Пример структурной схемы программной системы

Пример структурной схемы разработки алгоритма программы построения графиков функций одной переменной на заданном интервале изменения аргумента [х1, х2] при условии непрерывности функции на всем интервале определения приведен на рисунке 2.3.

Рисунок 2.3 - Структурная схема программы построения графиков/таблиц функций

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

Рисунок 2.4 - Полная многоуровневая структурная схема программы построения графиков/таблиц

Более полное представление о проектируемом программном продукте с точки зрения взаимодействия его компонентов между собой и с внеш­ней средой дает функциональная схема (схема данных, ГОСТ 19.701-90) - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функцио­нальных схем используют специальные обозначения, установленные стан­дартом. Основные обозначения схем данных приведены в таблице В.3. Функциональные схемы более информативны, чем структурные. На рисунке 2.5 приведены структурная и функциональная схемы программной системы.

    

Рисунок 2.5 – Структурная и функциональная схемы системы учета успеваемости студентов

 

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

 

2.2.2 Принципиальные решения начальных этапов проектирования

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

а)   архитектуры программного обеспечения - совокупность базовых прин­ципов его построения;

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

в)   технологии работы с до­кументами (однодокументная, многодокументная);

г)   подхода к разработке (структурный, объектный);

д)   языка и среды программирования.

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

Разработка непосредственно поль­зовательского интерфейса включает те же основные этапы, что и разработка программного обеспечения:

1)   постановка задачи - определение типа интерфейса и общих требований к нему;

2)   анализ требований и определение спецификаций - определение сценариев использования и пользовательской модели интерфейса;

3)   проектирование - проектирование диалогов и их реализация в виде процессов ввода-вывода;

реализация - программирование и тестирование интерфейсных процессов.

 

2.2.3 Выбор типа пользовательского интерфейса

Различают четыре типа пользовательских интерфейсов:

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

 

Рисунок 2.6 - Типичная структура алгоритма программ с примитивным интерфейсом: а) последовательный; б) с возможностью повторения

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

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

Рисунок 2.7 - Структура алгоритма программы с одноуровневым меню

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

в) со свободной навигацией - интерфейсы, реализующие множество сценариев, операции которых не привязаны к уровням иерархии, и предполагающие определение множества возможных операций на конкретном шаге работы. Их также называют графическими пользовательскими интерфейсами (GUI - Graphic User Interface) или интер­фейсами WYSIWYG (What You See Is What You Get - что видишь, то и полу­чишь, т. е., что пользователь видит на экране, то он и получит при печати). Интерфейсы данного типа ориентированы на использование экрана в графическом режиме с высокой разрешающей способностью. Графические интерфейсы поддерживают концепцию интерактивного взаимодействия с программным обеспечением, осуществляя визуальную обратную связь с пользователем и возможность прямого манипулирования объ­ектами и информацией на экране. Кроме того, интерфейсы данного типа под­держивают концепцию совместимости программ, позволяя перемещать меж­ду ними информацию.

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

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

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

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

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

-  однодокументная, которая предполагает однодокументный интерфейс (SDI - Single Document Interface);

-  многодокументная, которая предполагает многодокументный интерфейс (MDI - Multiple Document Interface).

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

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

 

2.2.4 Выбор подхода к разработке

Если выбран интерфейс со свободной на­вигацией или прямого манипулирования, то, как указывалось выше, это практически однозначно предполагает использование событийного програм­мирования и объектного подхода, так как современные среды визуального программирования, такие как Visual C++, Delphi, Builder C++ и им подобные, предоставляют интерфейсные компоненты именно в виде объектов библио­течных классов. При этом в зависимости от сложности предметной области программное обеспечение может реализовываться как с использованием объектов и, соответственно, классов, так и чисто процедурно. Исключение составляют случаи использования специализированных языков разработки Интернет-приложений, таких как Perl, построенных по совершенно другому принципу.

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

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

Например, при проектировании системы учета успеваемости имеет смысл выбрать объектный подход к разработке, соответствующий выбору типа интерфейса.

 

2.2.5 Выбор среды программирования

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

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

Наиболее часто используемыми являются визуальные среды Delphi, C++ Builder фирмы Borland (Inprise Corporation), Visual C++, Visual Basic фирмы Microsoft, Visual Ada фирмы IBM и др.

Между основными визуальными средами этих фирм Delphi, C++ Builder и Visual C++ имеется существенное различие: визуальные среды фирмы Microsoft обеспечивают более низкий уровень программирования «под Windows». Это является их достоинством и недостатком. Достоинством - так как уменьшается вероятность возникновения «нестандартной» ситуации, т. е. ситуации, не предусмотренной разработчиками библиотеки компо­нентов, а недостатком - так как это существенно загружает программиста «рутинной» работой, от которой избавлен программист, работающий с Delphi или C++ Builder. Много нареканий вызывает также интерфейс Visual C++, также ориентированный на «низкоуровневое» программирование.

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

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

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

 

2.2.6 Учет психофизических особенностей человека при проектировании интерфейсов

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

Например, следует иметь в виду, что подавляющему большинству людей сложно, например, запомнить и ввести на другом экране число, содержащее более 5 цифр (7 - 2), или некоторое сочетание букв.

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

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

Кроме всего прочего, человеку свойственно субъектив­ное восприятие времени. Считают, что внутреннее время связано со скоро­стью и количеством воспринимаемой и обрабатываемой информации. Заня­тый человек обычно времени не замечает. Зато в состоянии ожидания время тянется бесконечно, что связано с тем, что в это время мозг оказывается в со­стоянии информационного вакуума. К аналогичному состоянию приводит и усталость: информация поступает, но больше обрабатывается, а потому и ход времени замедляется. Доказано, что при ожидании более 1-2 секунд пользователь может отвлечься, «потерять мысль», что неблагоприятно сказывается на результатах работы и увеличивает усталость, так как каждый раз после ожидания много сил тра­тится на включение в работу. Сократить время ожидания можно, заняв пользователя, но, не отвлекая его от работы. Например, можно предоставить ему какую-либо информацию для обдумывания. По возможности целесообразно выводить пользователю промежуточные результаты: во-первых, он будет занят их обдумыванием, во-вторых, по ним он сможет оценить будущие результаты и отменит операцию, если они его не удовлетворяют.

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

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

 

2.2.7 Стили оформления программы

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

Стиль оформления программы включает:

а) правила именования объектов (переменных, функций, типов и т. п.);

б) правила оформления модулей;

в) стиль оформления текстов модулей.

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

а) имя объекта должно соответствовать его содержанию, например:

Maxltem - максимальный элемент; Nextltem - следующий элемент;

б) если позволяет язык программирования, можно использовать символ «_» для визуального разделения имен, состоящих из нескольких слов, напри­мер: Max_Item, Next_Item;

в) необходимо избегать близких по написанию имен, например:

Index и InDec.

2.2.7.2 Правила оформления модулей

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

а)   название модуля;

б)   краткое описание его назначения;

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

г)   список используемых (вызываемых) модулей;

д)   краткое описание алгоритма (метода) и/или ограничений;

е)   ФИО автора программы;

ж)  идентифицирующую информацию (номер версии и/или дату последней корректировки).

Пример 2.1 – Оформление модуля программы (см. рисунок 2.8)

Рисунок 2.8 – Оформление модуля программы

 

2.2.7.3 Стиль оформления текстов модулей

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

Пример 2.2 – Использование комментариев в С++

void main ()

{

// инициализация переменных

// вычисление выражения

cout<<”Result=”<<y;

// операция над результирующей переменной

cout<<”Result operation”<<y;

}

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

Пример 2.3 – Использование дополнительных отступов в С++

void main ()

{                              // начало функции

   int k, y;

      for (k=1;k<=10;k++)

          {                         // начало тела цикла  

if (y*y-5>60)   break;       

    cout<<y*y-5<<endl;              

     }                           // конец тела цикла

}                              // конец функции

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

Пример 2.4 – Использование комментариев с неочевидной информацией

// проверка условия и выход, если условие не выполняется

if (y*y-5>60)  

    {

cout<<”Значение не попадает в указанный диапазон”<<endl;

break;

                              }    

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

 

2.3 Контрольные вопросы

2.3.1 Что представляет собой структурная схема ПО?

2.3.2 В чем особенность функциональной схемы?

2.3.3. Как подбирается тип интерфейса пользователя?

2.3.4 Какие особенности человека следует учитывать при разработке пользовательских интерфейсов?

2.3.5 Какие особенности у интерфейса прямого манипулирования?

2.3.6 Каковы особенности интерфейса со свободной навигацией?

2.3.7 Как правильно подобрать среду программирования?

2.3.8  С какими сложностями сталкиваются при выбора подхода к разработке? 

2.3.9 В каких случаях используют примитивные интерфейсы?

2.3.10 Как строятся функциональные схемы?

2.3.11  Какие решения ранних этапов проектирования считают основными и поче­му?

2.3.12   Чем руководствуются при выборе языка программирования?

2.3.13   Что называют «хорошим стилем» оформления программ?

2.3.14   Каковы правила именования объектов программы?

2.3.15   Каковы особенности оформления текстов модулей?

2.3.16   Какую роль играют психофизические особенности человека при разработке интерфейсов пользователя?

2.3.17   Как влияют цвет и звук на пользователя?

2.3.18   Каких рекомендаций следует придерживаться при решении проблемы времени ожидания при разработке интерфейсов? 

2.3.19   Какие существуют технологии работы с документами?

2.3.20   Каковы особенности интерфейса-меню?

3 Расчетно-графическая работа. Тестирование и отладка программного продукта. Составление программной документации

 

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

 

3.1 Задания к расчетно-графической работе

Для программного продукта, разработанного в расчетно-графических работах 1 и 2:

а) выполнить отладку программы;

б) выполнить тестирование программы с заполнением соответствующей таблицы (см. таблицу В.4);

в) исправить выявленные ошибки и недочеты;

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

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

 

3.2 Общие рекомендации к выполнению расчетно-графической работы

3.2.1 Отладка

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

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

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

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

Что делать, если программа напечатала какой-то «мусор» или, кажется, "зависла"? Начинающие обычно винят в происшедшем компилятор, библиотеку или еще что-нибудь, но только не свой код. Опытные программисты были бы счастливы сделать то же самое, но они-то знают, что проблема, скорее всего, заключается в их собственной ошибке.

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

Процесс отладки включает в себя обратную трассировку (backward reasoning) — прослеживание событий в обратном порядке. Для того чтобы раскрыть причины, нужно мысленно проходить обратный путь от результата к возможной причине. Когда имеется полное объяснение, и известно, что именно нужно исправлять, по ходу дела, скорее всего, обнаружится несколько других неожиданных ошибок. При этом следует придерживаться некоторых правил, рекомендуемых профессионалами:

1)       Ищите знакомые ситуации. Спросите себя, известна ли уже вам эта ситуация. "Я уже видел это" — с этой фразы часто начинается понимание, а иногда даже и возникает ответ. Обычные ошибки имеют четко различимые признаки. Например, неинициализированные локальные переменные - один из источников четко отличимых ошибок. Результатом часто являются слишком большие значения, возникшие из-за «мусора», оставшегося в этом месте памяти от другой переменной. Некоторые компиляторы предупредят вас, если вы включите это предупреждение, но часть случаев они отследить все же не могут;

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

3)       Не повторяйте дважды ту же самую ошибку. После того как вы исправите ошибку, спросите себя, не совершали ли вы подобной ошибки когда-то раньше. В простом коде могут быть ошибки, если привычность этого кода такова, что заставляет нас ослабить внимание;

4)       Не откладывайте отладку на потом. Чрезмерная торопливость может повредить и в других ситуациях. Не игнорируйте проявившуюся ошибку: отследите ее прямо сейчас, потому что потом она может и не возникнуть. Пример - знаменитая история, случившаяся при запуске космической станции "Mars Pathfinder". После безупречного "приземления" в июле 1997 года компьютеры станции имели обыкновение перезагружаться в среднем один раз в день, и это поставило инженеров в тупик. Когда они отследили ошибку, то поняли, что уже встречались с ней. Во время предпусковых проверок такие перезагрузки случались, но были проигнорированы, потому что инженеры работали над другими вопросами. Теперь они оказались вынуждены решать проблему, когда машина находится на расстоянии десятков миллионов километров, и исправить ошибку стало значительно труднее;

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

6)       Читайте код перед тем, как исправлять. Один из эффективных, но недооцененных приемов отладки — тщательное чтение и обдумывание кода перед внесением в него исправлений. Порою хочется добраться до клавиатуры и начать редактировать программу, чтобы посмотреть, не исчезнет ли ошибка сама собой. Но все же, скорее всего, вы не знаете, что именно сломано, и измените что-нибудь не то, может быть, сломав при этом что-нибудь еще. Распечатанный на бумаге критический участок кода выглядит совсем не так, как на экране, и поощряет потратить больше времени на обдумывание. Однако не печатайте листинги постоянно. На распечатку целой программы вы изведете уйму бумаги, а структуру программы, разбросанной по множеству страниц, гораздо сложнее увидеть. Кроме того, распечатка устареет в тот момент, когда вы начнете вносить изменения. Сделайте перерыв. Иногда вы видите в исходном тексте то, что вы имели в виду, а не то, что вы на самом деле написали. Небольшое отвлечение от текста смягчит ваше недопонимание и поможет коду сказать самому за себя, когда вы к нему вернетесь. Боритесь с желанием начать исправлять немедленно: подумать - хорошая альтернатива;

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

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

3.2.2 Тестирование

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

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

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

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

Также как и для процесса отладки существуют сформулированные специалистами правила:

1)  Тестируйте при написании кода. Чем раньше обнаружена проблема, тем лучше. Если вы будете постоянно задумываться о том, что вы пишете, то сможете проконтролировать простейшие свойства программы прямо на этапе ее создания. В результате ваш код как бы пройдет один круг тестирования еще до того, как будет скомпилирован. Ошибки определенных видов даже никогда не появятся;

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

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

4)  Используйте утверждения. В С и C++ существует возможность использования специального механизма утверждений (assertions) (подключается с помощью заголовочного файла <assert.h>), который позволяет включать в программу проверку пред- и постусловий. Поскольку невыполненное утверждение прерывает работу программы, используют их, как правило, в ситуациях, когда сбой на самом деле не ожидается, а при его возникновении нет возможности продолжить работу нормально. Например, если программу дополнить утверждением, вставленным перед началом цикла:

аssert (n > 0);

Если утверждение не выполнено, программа прерывается и это сопровождается выдачей стандартного сообщения:

Аassertion failed: n > 0,  file avgtest.с, line 7

Abort(crash)

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

5)  Используйте подход защитного программирования. Полезно вставлять некоторый код для обработки (или просто предупреждения пользователю) случаев, которых "не может быть никогда", то есть ситуаций, которые теоретически не должны случиться, но все же имеют место (например, из-за сбоя где-то в другом участке программы). Это пример защитного программирования (defensive programming), при котором можно убедиться в том, что программа защищена от неправильного использования или некорректных данных. Пустые указатели, индексы вне диапазона, деление на ноль и другие ошибки можно обнаружить на ранних стадиях жизни программы или нейтрализовать;

6)  Проверяйте коды возврата функций. Одним из приемов защиты, которым программисты почему-то незаслуженно пренебрегают, является проверка возвращаемого значения библиотечных функций и системных вызовов. Например, значения, возвращаемые функциями, обслуживающими ввод, такими как fread, надо всегда проверять. Также обязательно надо проверять и возвращаемые значения вызовов открытий файлов типа fopen. Если чтение или открытие файла по каким-то причинам не выполняется, не может быть и речи о нормальном продолжении работы программы. Проверка возвращаемого значения функций вывода типа fprintf или fwrite поможет поймать ошибки, происходящие при попытке записи в файл, когда свободного места на диске не осталось. Также полезно на всякий случай проверить значение, возвращаемое fclose, - если при выполнении произошла какая-нибудь ошибка, эта функция возвратит EOF, в противном случае возвращается ноль.

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

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

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

1)  Тестируйте по возрастающей. Тестирование должно идти рука об руку с созданием кода. Тестирование методом "большого скачка", когда сначала пишется вся программа, а потом тестируется целиком, гораздо сложнее и отнимает гораздо больше времени, чем постепенное. Напишите часть программы, оттестируйте ее, напишите очередной кусок кода, оттестируйте его и т. д. Если у вас есть два блока, которые писались и тестировались раздельно, оттестируйте их взаимодействие;

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

3)  Четко определите, чего вы ожидаете на выходе теста. При проведении всех тестов вы должны четко знать правильный результат; если вы его не знаете, то напрасно теряете время. На первый взгляд мысль кажется самоочевидной, поскольку для многих программ очень просто определить, работают они или нет. Например, создается ли копия файла или нет, отсортированы ли данные на выходе или нет, и т. п.

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

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

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

5)       Сравните независимые реализации. Независимые реализации библиотек или программ должны выдавать одни и те же результаты. Например, два компилятора должны из одного и того же текста создавать программы, которые на одной и той же машине будут вести себя одинаково. Иногда искомый ответ можно получить двумя различными способами, а иногда - написать тривиальную версию программы, не заботясь о быстродействии и используемых ресурсах, для сравнения результатов. Если две программы независимо друг от друга выдают одни и те же ответы, с большой долей уверенности можно считать, что обе они работают корректно; если же ответы их разнятся, значит, по крайней мере, в одной из них есть ошибки;

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

Тестирование, проводимое создателем кода или другим тестером, имеющим тем не менее доступ к исходному коду, называется тестированием белого (прозрачного) ящика. Свой код тестировать, конечно, необходимо. Однако зачастую люди склонны обманывать сами себя и верить в лучшее, поэтому при тестировании надо отрешиться от кода и стараться придумать как можно более каверзные ходы. Цель тестирования — найти ошибки, а не объявить, что программа работает. Стало быть, тесты должны быть жесткими, и если с их помощью обнаруживаются проблемы, то это является доказательством действенности используемых методов, а не сигналом тревоги.

Тестирование черного ящика означает, что тестер не имеет никакого представления ни о доступе к коду, ни о его внутреннем устройстве. При таком тестировании выявляются несколько иные сшибки, поскольку тестер имеет иные отправные точки для поиска. Хорошо начинать с проверки граничных условий; после этого стоит перейти к большим объемам и некорректному вводу. Естественно, не надо забывать и о "золотой середине": проверке работы программы в нормальных условиях.

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

3.2.3 Составление программной документации

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

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

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

Содержание пояснительной записки по стандарту (ГОСТ 19.404-79) должно выглядеть следующим образом:

1)       введение;

2)       назначение и область применения;

3)       технические характеристики;

4)       ожидаемые технико-экономические показатели;

5)       источники, используемые при разработке.

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

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

Раздел Технические характеристики должен содержать следующие подразделы:

-  постановка задачи, описание применяемых математических методов и допущений и ограничений, связанных с выбранным математическим аппаратом;

-  описание алгоритмов и функционирования программы с обосновани­ем принятых решений;

-  описание и обоснование выбора способа организации входных и выходных данных;

-  описание и обоснование выбора состава технических и программных средств на основании проведенных расчетов или анализов.

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

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

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

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

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

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

- излагайте ясно, используйте короткие предложения;

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

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

Руководство пользователя, как правило, содержит следующие разделы:

1)  общие сведения о программном продукте;

2)  описание установки;

3)  описание запуска;

4)  инструкции по работе (или описание пользовательского интерфейса);

5)  сообщения пользователю.

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

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

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

Раздел Инструкции по работе обычно содержит описание режимов работы, форматов ввода-вывода информации и возможных настроек.

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

3.2.3.3 Руководство системного программиста. По ГОСТ 19.503-79 руководство системного программиста должно содержать всю информацию, необходимую для установки программного обеспечения, его настройки и проверки работоспособности. Кроме того, как ука­зывалось выше, в него часто включают и описание необходимого обслуживания, которое раньше приводилось в руководстве оператора (ГОСТ 19.505-79) и/или руководстве по техническому обслуживанию (ГОСТ 19.508-79). В настоящее время данную схему используют для составления руководства системному администратору.

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

1)  общие сведения о программном продукте;

2)  структура;

3)  настройка;

4)  проверка;

5)  дополнительные возможности;

6)  сообщения системному программисту.

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

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

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

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

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

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

 

3.3 Контрольные вопросы

3.3.1    Что представляет собой процесс отладки?

3.3.2    Какие виды ошибок наиболее распространены?

3.3.3    Что представляет собой процесс тестирования?

3.3.4    Какие способы используются при тестировании?

3.3.5    Какая документация заполняется в процессе тестирования?

3.3.6    Как нумеруются версии программного продукта?

3.3.7    Что понимают под тестированием «черного ящика»?

3.3.8    Что понимают под тестированием «белого ящика»?

3.3.9    Каких рекомендаций следует придерживаться при систематическом тестировании?

3.3.10   Что понимается под «обратной трассировкой»?

3.3.11   Какая документация должна быть подготовлена?

3.3.12   Каковы особенности руководства пользователя?

3.3.13   Что содержит руководство системного программиста?

3.3.14   Какие методы используются при отладке программных продуктов?

3.3.15  Что представляют собой отладчики?

 

Приложение А

Варианты заданий к расчетно-графическим работам

 

Таблица А.1 – Варианты заданий

№ вар.	Тема	Поля структуры
1	Выставка собак	Порода; Пол; Кличка; Возраст; Владелец
2	Продажа программных продуктов	Наименование; Разработчик; Стоимость; Объем, Мбайт; Кол-во на складе
3	Абонентская плата за телефон	ФИО абонента; Телефон; Год установки; Статус абонента; Плата за телефон
4	Телевизоры на складе	Наименование; Изготовитель; Стоимость; Размер экрана; Кол-во на складе
5	Города	Наименование; Кол-во жителей; Год основания; Площадь кв.км.; Количество школ
6	Мосты	Наименование; Высота; Ширина; Количество опор; Протяженность
7	Радиодетали на складе	Наименование; Материал; Назначение; Стоимость; Количество
8	Компьютеры	Модель; Производитель; Комплектация; Стоимость; Количество
9	Кредиты	Наименование; Банк; Процентная ставка; Срок кредита; Сумма кредита
10	Аренда автомобилей	Марка; Год выпуска; Пробег; Стоимость; Срок аренды
11	Библиотека	Автор книги; Название; Издательство; Год выпуска; Количество
12	Переводы	Язык перевода; Стоимость за стр; Объем заказа; Срок выполнения; Исполнитель
13	Коллекция пластинок	Название альбома; Исполнитель; Год выпуска; Кол-во записей; Стоимость
14	Картинная галерея	Название картины; Страна; Художник; Год написания; Стоимость
15	Деканат	ФИО студ; Курс; Группа; Год рождения; Адрес
16	Соревнования	Страна; Год; Вид соревнований; Команда; Место
17	Каталог сотовых телефонов	Наименование; Модель; Производитель; Стоимость; Особенности
18	Недвижимость	Наименование; Площадь; Этажность; Количество комнат; Стоимость
19	Самолеты	Наименование; ФИО конструктора; Год выпуска; Количество; Грузоподъемность
20	Компьютерные игры	Название; Разработчик; Версия; Жанр; Стоимость
21	Стипендия	ФИО студента; Курс; Средний балл; Размер стипендии; Надбавки
22	Расписание автобусов	Номер маршрута; Пункт отправления; Время отправления; Пункт назначения; Время прибытия
23	Зарплата сотрудников фирмы	ФИО; Должность; Оклад; Стаж; Надбавки к окладу
24	Прайс-лист	Вид услуги; Объем работ; Стоимость; Срок исполнения; Скидки

Продолжение таблицы А.1

25	Репертуар кинотеатров	Кинотеатр; Фильм; Жанр; Период показа; Время
26	Магазин игрушек	Наименование; Материал; Цвет; Артикул; Количество; Возраст ребенка; Стоимость
27	Сбербанк	Номер счета; ФИО вкладчика; Наименование депозита; Сумма вклада; Процентная ставка; Срок
28	Справочник астронома	Название созвездия; Звездная величина; Расстояние от Земли; Координаты на небосклоне: прямое восхождение и склонение; Яркость
29	Реки мира	Название реки; Протяженность; Куда впадает; Годовой сток (км3); Площадь бассейна
30	Телепрограмма	Телекомпания; Название передачи; Жанр; День недели; Время;
31	Музеи	Наименование коллекции; Описание; Оригинал или копия; Владелец; Дата приобретения
32	Аукцион	Дата проведения; Наименование лота; Первоначальная стоимость; ФИО покупателя; Сумма приобретения
33	Картинная галерея	Название полотна; Художник; Дата создания; Жанр; Примерная стоимость
34	Справочник нумизмата	Страна; Номинал монеты; Год выпуска; Количество выпущенных монет; Особенности
35	Справочник филателиста	Страна; Нарицательная стоимость марки; Год выпуска; Тираж; Особенности
36	Коллекционеры	Страна; Имя; Контактные координаты; Направление; Наличие редких экземпляров в коллекции
37	Туристическое агентство	Страна; Предлагаемые маршруты; Условия проживания и поезда; Экскурсионное обслуживание; Стоимость путевки
38	Автосалон	Марка; Год выпуска; Технические характеристики; Особенности; Техническое состояние; Цена
39	Риэлтерская контора	Район; Адрес; Характеристика жилья; Цена; Контактный телефон заявителя
40	Спортсмены	ФИО; Гражданство; Происхождение; Вид спорт; Клуб (команда); Личные достижения
41	Рецепты блюд	Название блюда; Количество порций; Вес порции; Расход продуктов; Рецепт приготовления
42	Банкет	Наименование блюда; Количество порций; Вес порции; Цена порции; Сумма
43	Высшие учебные заведения	Наименование; Адрес; Перечень специальностей; Проходной балл; Язык обучения; Стоимость обучения
44	Зачисление абитуриентов	ФИО; Год рождения; Год окончания школы; Специальность; Общий балл; Форма обучения;
45	Ломбард	Дата сдачи; ФИО клиента; Паспортные данные; Наименование товара; Оценочная стоимость; Сумма, выданная под залог; Срок хранения
46	Терминология	Раздел науки; Вводимый термин; Толкование; Ссылки на используемые термины

 

Окончание таблицы А.1

47	Справочник селекционера	Наименование сорта; Урожайность; Характеристики плодов; Устойчивость к вредителям; Морозоустойчивость
48	Гостиница	Номер; Класс; Число мест; Стоимость в сутки; Сервис
49	Заселение в гостиницу	ФИО; Паспортные данные; Дата приезда; Номер; Дата выезда; Стоимость проживания; Стоимость дополнительных услуг
50	Картотека Интерпола	ФИО преступника; Кличка; Рост; Цвет волос и глаз; Особые приметы; Место и дата рождения; Гражданство; Знание языков; Профессия; Дополнительная информация
51	Биржа  труда	ФИО безработного; Профессия; Образование; Место и должность последней работы; Причина увольнения; Контактный телефон
52	Вакансии	Фирма; Должность; Условия труда; Оплата; Требования к кандидату; Контактный телефон
53	Типография	Дата заказа; Наименование заказа; Объем; Цена за единицу; Срок исполнения; Сумма
54	Отдел кадров	ФИО сотрудника; Паспортные данные; Образование; Специальность; Подразделение; Должность; Оклад; Дата поступления в фирму
55	Курорты	Страна; Город; Наименование отеля; Класс; Услуги; Стоимость путевки
56	Ремонт	Наименование работ; Используемый материал; Объем работ; Цена за м2; Сумма
57	Кулинария	Наименование продукции; Дата изготовления; Срок хранения; Вес; Цена; Бригада
58	База автомобилистов	ФИО; Адрес; Марка автомобиля; Цвет; Номерной знак; Дата получения водительских прав
59	Экзаменационная ведомость	Дата экзамена; Дисциплина; ФИО преподавателя; ФИО студента; Группа; Рейтинг допуска; Экзаменационная оценка; Итоговая оценка
60	Производственный план	Наименование сырья; Требуемый объем сырья; Цена за единицу; Трудозатраты; Энергозатраты; Цена изделия; Объем заказа; Прибыль

 

Приложение Б

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

 

 

Рисунок Б.1 – Титульный лист технического задания
1 Введение

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

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

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

Система разрабатывается на основании приказа декана теплоэнергетического факультета № 15 от 24 сентября 2010 г. и в соответствии с планом мероприятий по совершенствованию учебного процесса на 2010-2011 учебный год.

3 Назначение

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

4 Требования к программе или программному изделию

4.1 Требования к функциональным характеристикам

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

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

- ввод и коррекцию текущей информации о ходе сдачи сессии конкретными студентами;

- хранение информации об успеваемости в течение времени обучения студента;

- получение сведений о текущем состоянии сдачи сессии студентами.

4.1.2 Исходные данные:

- списки студентов учебных групп;

- учебные планы кафедр - перечень предметов и контрольных мероприятий по каждому предмету;

- расписания сессий;

- текущие сведения о сдаче сессии каждым студентом.

4.1.3 Результаты:

- итоги сдачи сессии конкретным студентом;

- итоги сдачи сессии студентами конкретной группы;

- процент успеваемости по всем студентам группы при сдаче конкретного пред­мета в целом на текущий момент;

- проценты успеваемости по всем группам специальности на текущий момент;

- проценты успеваемости по всем группам курса на текущий момент;

- проценты успеваемости по всем курсам и в целом по факультету на текущий момент;

- список задолжников группы на текущий момент;

- список задолжников курса на текущий момент.

4.2  Требования к надежности

4.2.1. Предусмотреть контроль вводимой информации.

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

4.2.3.  Обеспечить целостность хранимой информации.

4.3 Требования к составу и параметрам технических средств

4.3.1.  Система должна работать на IBM совместимых персональных компьюте­рах.

4.3.2. Минимальная конфигурация: тип процессора - Pentium и выше; объем оперативного запоминающего устройства - 32 Мб и более.

4.4 Требования к информационной и программной совместимости

Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows 2000, Windows NT и т. п.).

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

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

5.2 Программная система должна включать справочную информацию о работе и подсказки пользователю.

5.3 В состав сопровождающей документации должны входить:

5.3.1 Пояснительная записка, содержащая описание разработки.

5.3.2    Руководство системного программиста.

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

5.3.4    Графическая часть на трех листах формата А3 (блок-схемы алгоритмов): схема структурная программной системы; диаграмма компонентов данных; формы интерфейса пользователя.

6 ЭТАПЫ РАЗРАБОТКИ

№	Название этапа	Срок	Отчетность
1	Проектирование программного продукта	01.10.2007-31.11.2007	Разработка технического задания и уточнение спецификаций. Принятие принципиальных решений. Алгоритмов решения задачи. Проектирование структурной и функциональной схем системы учета успеваемости.
2	Реализация	01.12.2007-29.02.2008	Описание внутренних форматов, интерфейса и форматов данных базы. Реализация систе­мы на уровне интерфейса. Реализация программных модулей задачи.
3	Тестирование  и составление программной документации	01.03.2008-30.04.2008	Тесты. Документация. Программный продукт

Приложение В

Определение спецификаций и описание структурных алгоритмов

 

Таблица В.1 – Словарь  терминов

Термин	Категория	Краткое описание
а	Входные данные	Верхний предел интегрирования
b	Входные данные	Нижний предел интегрирования
y	Результат	Значение интеграла
…	…	…

 

 

Таблица  В.2 – Соответствие различных способов описания алгоритмов

Структура	Псевдокоды	Flow-формы	Диаграммы Насси-Шнейдермана
Следование	<действие 1> <действие 2>
Ветвление	Если <условие>       то <действие 1>       иначе <действие 2>    Все-если
Цикл-пока	Цикл-пока <условие> <действие>    Все-цикл
Выбор	Выбор <код>    <код 1>: <действие 1>    <код 2>: <действие 2>     иначе <действие 3>    Все-выбор
Цикл с парамет-ром	Для <индекс> =          <n>,<m>,<h>         <действие >    Все-цикл
Цикл-до	Выполнять <действие>    До <условие>

 

 

 

 

Таблица В.3 – Основные обозначения схем данных по ГОСТ 19.701-90

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

 

Таблица В.4 – Пример заполнения таблицы тестирования

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

 

1.       ГОСТ 19.701-90. ЕСПД. Схемы алгоритмов и программ. Обозначения условные, графические. – М.: Издательство стандартов,1990.

2.       Либерти Дж. Освой самостоятельно С++ за 21 день. – М.: Издательский дом «Вильямс», 2001.

3.       Ашарина И.В. Основы программирования на языках С и С++. – М.: Горячая линия-Телеком, 2002.

4.       Крупник А.Б. Самоучитель С++. – СПб.: Питер, 2005.

5.       Бентли Дж. Жемчужины программирования. - СПб.: Питер, 2003.

6.       Марченко А.Л. С++. Бархатный путь. - М.: Горячая линия-Телеком, 2002.

7.       Иванова Г.С. Технология программирования. - М.: Изд-во МГТУ им. Н.Э.Баумана, 2002.

8.       Вирт Н. Алгоритмы и структуры данных. – М.: Мир, 1989.

9.       Тассел Д. Ван. Стиль, разработка, эффективность, отладка и испытание программ. – М.: Мир, 1985.

10.   Соммервиль И. Инженерия программного обеспечения. - М.: Изд-во Вильямс, 2002.

11.   Мандел Т. Разработка пользовательского интерфейса. – М.: ДМК Пресс, 2001.

12.   Канер С., Фолк Д., Нгуен Е.К. Тестирование программного обеспечения. - Киев: «ДиаСофт», 2000

13.   Гримм С.Дж. Как писать руководства для пользователей. – М.: Радио и связь, 1985.

14.   Липпман С., Лажойе Ж. Весь С++ от азов до совершенства. – СПб.: Невский диалект. - М.: ДМК Пресс, 2007.

15.   Сябина Н.В. Технологии программирования. Конспект лекций (для студентов всех форм обучения спец. 050702, 050703). - Алматы: АИЭС, 2008.

 

Содержание 

1 Расчетно-графическая работа. Использование структурного

подхода при проектировании программного продукта.                                3

2 Расчетно-графическая работа. Проектирование и реализация пользовательского интерфейса в выбранной среде программирования                                      14

3  Расчетно-графическая работа. Тестирование и отладка программного продукта. Составление программной документации                                                      27

Приложение А                                                                                                 39

Приложение Б                                                                                                  42

Приложение В                                                                                                 45

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