
- •Раздел 1. Специальный раздел
- •1.1. Исследовательская часть
- •1.1.1. Постановка задачи
- •1.1.2. Предварительные нир
- •1.3. Информационные потребности пользователя
- •1.1.4. Требования, предъявляемые системе
- •1.2. Конструкторская часть
- •1.2.1. Структура входных и выходных данных
- •1.2.2. Общая схема работы модуля
- •1.2.3. Выбор платформы проектирования и его обоснование
- •1.2.4. Проектирование архитектуры модуля
- •1.2.5. Конфигурация технических средств
- •1.2.6. Алгоритмы работы модуля
- •1.2.7. Методика тестирования
- •1.2.8. Результаты экспериментальной проверки
- •2.1. Проектирование на языке uml
- •2.1.1. Концепция Unified Modeling Language
- •2.1.2. Виды диаграмм uml
- •2.1.3. Связь с объектно-ориентированными языками
- •2.2. Идеология stl в применении к архитектуре модуля
- •2.2.2. Контейнеры stl
- •2.2.3. Алгоритмы stl
- •2.2.4. Потоки
- •2.4.1. Умные указатели
- •2.3. Специализированный инструментарий
- •2.4.2. Типы тестов
- •2.4.3. Планирование модульных тестов
- •2.4.4. Примеры тестирования
- •2.4.5. Методы “грубой силы” и их применение при отладке программы
- •3.1. Цели определения себестоимости и цены модуля
- •3.2. Методы определения себестоимости
- •3.3. Расчет себестоимости vfs
- •3.4. Методы расчета цены
- •3.4.1. Расчет цены по стоимости изготовления
- •3.4.2. Расчет цены на основе роялти
- •3.4.3. Расчет цены на тиражируемый продукт
- •3.5. Расчет цены vfs
- •3.6. Выводы
- •4.2.1. Психофизиологические факторы
- •4.2.2. Электромагнитные излучения
- •4.2.3. Освещение рабочего места
- •4.2.4 Электробезопасность
- •4.2.5 Микроклимат
- •4.2.6. Зашумленность
- •4.3. Инженерный расчет освещенности машинного зала
- •4.4. Экологическая безопасность
- •4.5. Пожарная безопасность
- •4.6. Выводы
- •Список литературы
2.1.3. Связь с объектно-ориентированными языками
Некоторые виды диаграмм UML, например диаграммы классов, очень хорошо поддаются обработке генераторами кода. Соответствующие инструментальные средства встроены в большинство мощных CASE-средств, таких как, например, Rational Rose. По данным диаграммы классов такое инструментальное средство способно создать набор файлов со сгенерированными определениями классов, включая их свойства и методы согласно спецификациям диаграммы.
2.2. Идеология stl в применении к архитектуре модуля
Как и многие другие объектно-ориентированные языки, С++ предоставляет широкие возможности по созданию новых типов данных. Библиотека STLпризвана предоставить возможность свободно оперировать этими типами.
Библиотека STL(Standard Template Library – стандартная библиотека шаблонов) вводит широкий набор контейнеров для хранения объектов и большое число алгоритмов для манипулирования ими. Благодаря использованию шаблонов, библиотекаSTLявляется строго типизированной, что позволяет ей быть крайне гибкой и дает возможность обнаруживать многие ошибки ещё на этапе компиляции.
Библиотека STLявляется частью стандартной библиотеки языка С++, как это определено в стандартеISO/IEC14882 от 1998 года.
Под идеологией STLв архитектуре программного модуля понимают использование структур данных, алгоритмов и типовSTLне только в реализации, но и в программном интерфейсе. Это упрощает задачу программистам, использующим модуль, поскольку позволяет оперировать с модулем в рамках привычных и удобных средствSTL.
2.2.1. Шаблоны в C++
Шаблон (template) – параметризированная частьC++-кода. Шаблонными параметрами, как правило, являются имена типов (малоиспользуемый вариант - константы). Единожды описанный в программе шаблон можно инстанцировать (создавать на его основе новые классы или функции) неограниченное число раз. Фактически, шаблон является способом метапрограммирования – для каждого объявления параметризованного класса или функции с известным набором аргументов шаблона компилятором генерируется новый класс или функция обычного вида. Можно сказать, что такое метапрограммирование является вариантом умных макроподстановок. С одной стороны, это увеличивает объем компилируемого кода (часто в разы), но с другой, дает очень большую гибкость в использовании.
Перед макросами с параметрами препроцессора языка C(которые сохраняют в полном объёме свой функционал и вC++) шаблоны имеют следующие преимущества:
1) область видимости шаблонов подчиняется стандартным правилам языка C++, в то время как макрос всегда является объектом с глобальной видимостью;
2) компилятор осуществляет синтаксическую проверку шаблона до его первого использования, макрос никогда не проверяется, что делает даже простейшие ошибки (например, пропущенную точку с запятой в конце оператора) трудно обнаруживаемыми;
3) препроцессор рассматривает параметры макроса как текстовые строки без дополнительных проверок; это может привести к замаскированным ошибкам; параметры шаблона по использованию во многом аналогичны параметрам функции.
В качестве иллюстрации, рассмотрим довольно распространенным пример использования макроса и шаблона для определения возведения в квадрат (листинг 2.1). Легко видеть, что оба подхода позволяют определить функцию возведения в квадрат, однако использование шаблона позволяет избежать нежелательного многократного выполнения операций с побочным эффектом (в примере – двукратного выполнения операции инкремента). Замечу, что для шаблонных функций аргумент шаблона может быть вычислен из типа переданного аргумента, что во многих случаях позволяет избежать явного указания аргументов шаблона.
Листинг 2.1. Макрос и шаблон
#define SQR(x) ((x) * (x))
template<typename T> T sqr(const T& x) { return (x * x); }
void test()
{
int x = 2;
int y = 2;
x = sqr(y);
y = SQR(x);
x = sqr(++y);
y = SQR(++x); // ошибка! Инкремент x произойдет дважды.
}
На текущий момент можно с уверенностью сказать, что век макроподстановок заканчивается. Они используются только там, где необходимо обеспечивать межплатформенную совместимость на уровне исходного кода (пример – заголовочные файлы STLport).