Тема 3. Практические соображения

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

3.1 Проектирование в конструировании

Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования; другие проекты явно выделяют проектную деятельность в форме фазы дизайна.

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

Детали деятельности по проектированию на стадии конструирования в основном те же самые, что и описанные в области знаний “Проектирование программного обеспечения” (Software Design). Отличие заключается в большем внимании деталям.

3.2 Языки конструирования

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

Простейший тип языков конструирования – конфигурационный язык (configuration language), позволяющий задавать параметры выполнения программной системы.

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

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

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

• лингвистическая
• формальная
• визуальная

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

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

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

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

Сегодняшние работы (и их состояние) в области архитектур и приложений, управляемых моделями, в первую очередь - OMG MDA (Model-Driven Architecture www.omg.org/mda), UML (Unified Modeling Language www.omg.org/uml), Microsoft DSL (Domain-Specific Language), направлены на то, чтобы использовать ту или иную визуальную нотацию, базирующуюся на мета-моделях, в качестве инструмента, применяемого и для определения функциональной логики системы. Можно ли в чистом виде считать эти нотации именно визуальными - вопрос спорный. Они относятся именно к визуальным нотациям, так как предполагают однозначную интерпретацию визуального представления в виде текста и наоборот. Кроме того, исторически эти нотации определялись изначально как нотации визуального представления функциональности и уже в дальнейшем эти визуальные представления были отражены на уровне соответствующих мета-моделей (хотя это в большей степени верно для UML, чем DSL, но DSL можно рассматривать и как аналог UML, предполагающий большую свободу применений и интегрированность с конкретной платформой - Microsoft). Другая область стандартов, направленных на применение визуальных нотаций для описания функциональности – Business Process Management Notation (BPMN - www.omg.org/bpmn) и связанный с ней язык Business Process Execution Language, построенный на базе XML. Таким образом, область обоснованного применения визуальных нотаций для конструирования программных систем качественно расшириться и, не исключено, мы станем свидетелями de-facto формирования новой категории нотаций, соглашений и смешанных типов языковых средств, предназначенных для конструирования программного обеспечения как естественного продолжения проектирования.

3.3 Кодирование

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

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

3.4 Тестирование в конструировании

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

• модульное тестирование
• интеграционное тестирование

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

Тестирование в конструировании обычно включает подмножество тестовых методик, описанных в области знаний “Тестирование программного обеспечения” (Software Testing). Например, тестирование в конструировании обычно не включает системного тестирования, нагрузочного тестирования, usability-тестирования (оценки прозрачности использования) и других видов тестовой деятельности.

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

• IEEE Std 829-1998: “IEEE Standard for Software Test Documentation”;
• IEEE Std 1008-1987: “IEEE Standard for Software Unit Testing”.

3.5 Повторное использование

Во введении в стандарт IEEE Std. 1517-99 “IEEE Standard for Information Technology – Software Lifecycle Process – Reuse Processes” даётся следующее понимание повторному использованию в программном обеспечении: “Реализация повторного использования программного обеспечения подразумевает и влечёт за собой нечто большее, чем просто создание и использование библиотек активов. Оно требует формализации практики повторного использования на основе интеграции процессов и деятельности по повторному использованию в сам жизненный цикл программного обеспечения.” В то же время, повторное использование достаточно важно и непосредственно при конструировании программных систем, что подчеркивается включением этой темы в обсуждаемую область знаний конструирования ПО.

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

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

3.6 Качество конструирования

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

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

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

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

3.7 Интеграция

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

Кроме упомянутых аспектов интеграции, к обсуждаемым интеграционным вопросам конструирования относятся:

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