1.2. Суть проекта
В данной курсовой работе студентам предлагается реализовать проект по созданию ПО модели автоматизированной системы управления температурой медной пластинки. Это означает, что студенты должны отдельно реализовать в программном коде, как объект управления (ОУ), так и автоматизированную систему управления (АСУ).
Объектом управления является медная пластинка, нагреваемая с одной стороны напряжением либо током и охлаждаемая с другой стороны потоком воздуха (рис. 1). Аналогичный процесс рассматривался в курсе лабораторных работ по дисциплине «Теплотехника и термодинамика».
Рис. 1. Объект управления.
Величины тока I(τ)и напряженияU(τ)определяют количество подводимой к пластинке энергии. Скорость потока воздухаυ(τ)и температура окружающей средыTосопределяют величину потерь.
Задача управления заключается в поддержании заданной температуры пластинки T(τ) = Tзад(τ)путем изменения либо напряжения, либо тока, либо скорости потока воздуха.
Структурная схема системы управления представлена на рис. 2.
Рис. 2. Структурная схема системы управления.
В ходе выполнения курсовой работы каждый студент должен в индивидуальном порядке реализовать ПО моделирующее в реальном режиме времени поведение объекта управления и ПО моделирующее поведение АСУ т.е. регулятора. ПО должно быть реализовано в виде отдельных программных модулей, запускаемых на разных машинах, с использованием сетевых технологий.
На выполнение курсовой работы студентам отводится 12 недель. Защита будет происходить на 13 неделе.
1.3. Документация
Разработка ПО живет документацией. Документация может быть отделена от программного кода, а может быть тесно с ним связана. Для того чтобы понять важность исчерпывающей документации, представьте, что вам предложили участие в уже полным ходом идущем программном проекте. По уровню сложности это примерно соответствовало бы тому, как если бы вас заставили изучить, например, некоторые аспекты патологии крови. Чтобы сделать это, вам, скорее всего, захотелось бы получить общее представление о предмете, узнать причины необходимости его изучения, затем от обзора постепенно перейти к изучению деталей, диаграмм, демонстрирующих внутренние связи, описаниям частных случаев и т.д. Упрощения и противоречия могут привести к частичному, а возможно, и полному непониманию изучаемого материала.
Чтобы проиллюстрировать важность документирования программного обеспечения на различных уровнях, обратимся к фрагменту программного кода (листинг 1). Без полной документации этот код невозможно интерпретировать, поэтому его ценность невелика, если он вообще хоть чего-то стоит. Если мы добавим комментарии и сделаем имена функции более информативными (листинг 2), то получим несколько лучший результат. Этот результат даже может ввести нас в заблуждение, заставив поверить, что мы знаем значение и контекст кода; при этом последствия могут оказаться более катастрофичными, чем в том случае, если бы мы признали непонимание значения текста программы.
Листинг 1.Недокументированный код
int a(int i, char с)
{
if(c == "m")
if(i < 1000)
return 0;
else
if(i < 10000)
return 500;
else
return 1200;
else
return 1300;
}
Листинг 2.Частично документированный код
int tax(int anEarning, char aStatus)
{
if(aStatus == "m")
if(anEarmng < 1000)
return 0; // Женатые не облагаются налогом. <$1000 else
if(anEarning < 10000)
return 500; // Женат. $1000-110000
else
return 1200; // Женат. >=$10000
// Если не женат, то использовать ставку налога в размере $1300 else
return 1300;
}
Когда мы смотрим на тщательно документированный программный код (листинг 3), его значение становится намного понятнее. Благодаря документированию мы узнаем очень важный новый факт, заключающийся в том, что приведенные ставки заработной платы действительны только для ограниченного отрезка времени. Ссылка на одно из требований в спецификации требований является еще одной важной частью документации.
Листинг 3. Документированный код
/**
* Этот метод реализует требование 4.3:
* "Установить действие налога с 01.09.98 по 31.12.99".
* author Э. Брауде
* version 2.3.4 (08.06.98)
* param anEarning: зарплата
* param aStatus: 'm' означает "женат", иное означает "не женат"
*/
int tax(int anEarning, char aStatus)
{ …
Однако история этой части программного кода еще не окончена. Так как, при тщательном документировании должен вестись учет всех версий ПО, то может получиться так, что фрагмент кода, рассмотренный нами, во многом уже не относится к делу, так как текущая версия функции tax(), например 2.7.6,может выглядеть совсем по-другому.
До сих пор у нас еще не сложилось представление об общем положении вещей. Например, мы не знаем, работает ли версия 2.3.4 функции tax() как требуется? Какому классу принадлежит эта функция? Какому пакету? Даже если мы знаем имя пакета, то каково его предназначение? Как он соотносится с другими пакетами? То есть, документация обретает смысл не только из текста своего содержания, но еще и из контекста. «Лакмусовой бумажкой» для определения хорошего ведения документации является готовность нового инженера включиться в проект за разумное время.
На сегодняшний день в Украине единым стандартом, содержащим требования к составу и содержанию программной документации, является комплекс ГОСТов ЕСПД — Единой Системы Программной Документации. Также в последнее время разработчики ПО осознают, что для создания качественного ПО необходимо проведение верификации программного кода на всех стадиях его разработки. К сожалению единого ГОСТа или ДСТУ определяющего состав и содержание документов по верификации на сегодня не существует. Поэтому каждый разработчик ведет свой вариант документации по верификации. Также в Украине отсутствуют единые требования к оформлению программного кода, поэтому при разработке программного кода следует придерживаться нижеследующих правил.
1. Имена переменных должны иметь смысловое значение, должны начинаться с обозначения типа и каждое слово с большой буквы.
2. Допускается именование переменных типа «Temp», «Buffer», «String», «Len» и т.п., если их видимость не более 10 строк
3. Допускается длина имени переменной не более 30 символов.
4. Необходима проверка инициализации переменных при объявлении.
5. Необходимо наличие проверки результата при выделении памяти.
6. Имена функций должны иметь смысловое значение, должны начинаться с большой буквы для каждого слова.
7. Длина имени функции не более 64 символов.
8. При наличии в параметрах функции указателя необходима его проверка.
9. Необходимо указывать возвращаемые значения: «int» или объявленный тип в рамках проекта («enum») (0 - нормальное завершение, иначе - код ошибки), «bool» («true» - нормальное завершение, «false» - ошибка).
10. Объем тела функции не более 100 строк.
11. При экспортировании функции, ее параметры - указатели, а не ссылки.
12. Все экспортируемые из компонента ПО функции должны быть описаны в одном файле, в котором ничего кроме описания экспортируемых функций быть не должно.
13. Глобальные переменные должны начинаться с «g_» .
14. Название класса должно иметь смысловое значение и начинаться с «C».
15. Переменные, члены класса должны начинаться с «m_» .
16. Название файла должно иметь смысловое значение.
17. Файлы описания («h»-файлы) и реализации («cpp»-файлы) одного класса должны иметь одинаковые названия и отличаться расширением.
18. Файлы одного компонента ПО должны размещаться в одном каталоге.
19. Файлы, являющиеся общими для нескольких ПО компонентов, должны размещаться в общем каталоге проекта.
20. Имена файлов в глобальном проекте должны быть уникальны и иметь смысловое значение, следует избегать имен: «main.cpp», «global.cpp» и т.п.
21. В файлах описания использовать «шапку»:
«#ifndef __[FileName]_H
#define __[FileName]_H
тело файла
#endif»
22. Длина файлов реализации — не более 1500 строк.
23. Если реализация класса занимает много места, допускается разбиение файла с сохранением имени и добавлением номера, например «MyClass01.cpp», «MyClass02.cpp» и т.д.
24. Фигурные скобки блоков необходимо располагать на одной линии по вертикали от начала оператора, если блок содержит 1 строку, применение фигурных скобок не обязательно.
25. При расчетах следует использовать константы и объявления (например, «#define MAX_PATH 255»).
26. Не использовать оператор «GOTO» для 32-х разрядных приложений, а использовать структурную обработку исключений.
27. Для 16-ти разрядных приложений не использовать более одного оператора «GOTO» в функции.
28. Следует использовать стандартные библиотеки.
29. Следует использовать шаблоны.
30. Следует использовать интерфейсные классы.
31. Каждый файл должен начинаться комментарием с именем файла и информацией о содержимом файла.
32. Файл описания должен содержать описание применения класса, а затем объявление класса.
33. Описание переменных — в той же строке, где и переменная.
34. Описание функций – над объявлением или реализацией, должно содержать описание использования функции, описание входных параметров и результата.
35. Необходимо писать комментарий при вызове других функций.
36. Необходимо писать комментарии циклов и операторов сравнения.
37. В случае сложного алгоритма, обязательно его описание либо в текущем файле (файл реализации), либо в файле описания, либо в другом документе (с указанием ссылки на него в «h»-файле или «cpp»-файле).