Области знаний программной инженерии и стандарты ЖЦ программного обеспечения

1.1.2. Проектирование ПО (Software design)

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

• базовые концепции проектирования ПО (Software Design Basic Concepts),
• ключевые вопросы проектирования ПО (Key Issue in Software Design),
• структура и архитектура ПО (Software Structure and Architecture),
• анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation),
• нотации проектирования ПО (Software Design Notations),
• стратегия и методы проектирования ПО (Software Design Strategies and Methods).

Базовая концепция проектирования ПО - это методология проектирования архитектуры с помощью разных методов (объектного, компонентного и др.), процессы ЖЦ (стандарт ISO/IEC 12207) и техники - декомпозиция, абстракция, инкапсуляция и др. На начальных стадиях проектирования предметная область декомпозируется на отдельные объекты (при объектно-ориентированном проектировании) или на компоненты (при компонентном проектировании). Для представления архитектуры программного обеспечения выбираются соответствующие артефакты (нотации, диаграммы, блок-схемы и методы).

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

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

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

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

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

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

Структурные нотации - это структурное, блок-схемное или текстовое представление аспектов проектирования структуры ПО из объектов, компонентов, их интерфейсов и взаимосвязей. К нотациям относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity-Relation Diagrams), IDL (Interface Description Language), Use Case Driven и др. Нотации включают языки описания

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

Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. Таким нотациям соответствуют диаграммы потоков данных (Data Flow), таблиц принятия решений (Decision Tables), деятельности (Activity), кооперации (Collaboration), последовательности (Sequence), пред- и постусловия (Pre-Post Conditions), формальные языки спецификации (Z, VDM, RAISE), языки проектирования PDL и др.

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

В объектно-ориентированном проектировании ключевую роль играет наследование, полиморфизм и инкапсуляция, а также абстрактные структуры данных и отображение объектов. Подходы, ориентированные на структуры данных, базируются на методе Джексона [1.8] и используются для задания входных и выходных данных структурными диаграммами. Метод UML предназначен для сценарного моделирования проекта [1.19] в наглядном диаграммном виде. Компонентное проектирование ориентировано на использование готовых компонентов (reusing), их интерфейсов и интеграцию для формирования конфигурации, служащей основой развертывания компонентного ПО и взаимодействия компонентов в операционной среде.

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

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

1.1.3. Конструирование ПО (Software Construction)

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

Область знаний "Конструирование ПО (Software Construction)" включает следующие разделы:

• снижение сложности (Reduction in Complexity),
• предупреждение отклонений от стиля (Anticipation of Diversity),
• структуризация проверок (Structuring for Validation),
• использование внешних стандартов (Use of External Standards)

Снижения сложности - это минимизация, уменьшение и локализация сложности конструирования.

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

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

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

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

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

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

Визуальный стиль является наиболее универсальным стилем конструирования ПО, он позволяет разработчикам проекта представлять конструируемый элемент в наглядном виде. Визуальный язык проектирования UML представляет разработчику набор удобных диаграмм для задания статической и динамической структуры ПО [1.17]. При применении визуального стиля конструирования создается текстовое и диаграммное описание конструктивных элементов ПО, которое выводится на экран дисплея не только для их наглядного представления, но и корректировки.

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

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

Иными словами, внешние и внутренние стандарты должны определить общие правила работы членов проектной команды с учетом процессов ЖЦ. Такими стандартами являются: языки программирования (например, Java Language Specification, С++), интерфейсы ЯП и прикладные интерфейсы платформ Windows и др. При конструировании используются стандарты: ЯП (Ада 95, С++ и др.), языков описания данных (XML, SQL и др.), средств коммуникации (COM, CORBA и др.), интерфейсных языков (POSIX, IDL, APL) [1.18], сценарии UML [1.17] и др.

Данная область пополнилась новым разделом (SWEBOK, 2004 г.), описываемым ниже.

Управление конструированием - это управление процессом конструирования ПО, которое базируется на моделях конструирования, планировании и внесении изменений.

Модели конструирования включают набор операций, последовательность действий и результатов. Виды моделей определяются стандартом ЖЦ, методологиями и практиками. Некоторые стандарты ЖЦ по своей природе ориентированы на конструирование, например, экстремальное программирование (XP - eXtreme Programming). Конструирование с помощью моделирования осуществляется в рациональном унифицированном процессе - RUP (Rational Unified Process) [1.19].

Планирование состоит в определении порядка операций и уровня выполнения заданных условий в процессе конструкторской деятельности. Определяется модель ЖЦ, включающая задачи и действия по созданию компонентов, а также по их проверке, включая достижение показателей качества на этапах ЖЦ. Исполнители распределяются по процессам ЖЦ и выполняют соответствующие задачи по реализации промежуточного продукта. Затем проводится измерение разных аспектов конструирования, например, количественная оценка объема кода, оценка степени использования reuse, вычисление вероятности появления дефектов и оценка количественных показателей качества ПО.

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

1.1.4. Тестирование ПО (Software Testing)

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

Существует две формы проверки кода - модульное и интеграционное. При этом используются стандарты (IEEE 829-1996 и IEEE 1008-1987) проверки и тестирования модулей ПО. Затем проводится интеграционное тестирование модулей системы и их интерфейсов в динамике выполнения. В процессе разных видов проверок собираются данные об ошибках, дефектах, отказах и т.п. и оформляется соответствующая документация (таблицы типов ошибок, частота и время появления отказов и др.). Данные, собранные при отладке, просмотрах, инспекции и тестировании, используются для оценки характеристик качества готового ПО, например, атрибутов показателя надежности - интенсивность отказов, количество ошибок и др.

Область знаний "Тестирование ПО (Software Testing)" включает следующие разделы:

• основные концепции и определение тестирования (Testing Basic Concepts and definitions),
• уровни тестирования (Test Levels),
• техники тестирования (Test Techniques),
• метрики тестирования (Test Related Measures),
• управление процессом тестирования (Managing the Test Process).

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

Основная концепция тестирования описывает базовые термины, ключевые проблемы и их связь с другими областями знаний. Тестирование - это процесс проверки правильности программы в динамике ее выполнения на тестовых данных. При тестировании выявляются недостатки: отказы (faults) и дефекты (defects) как причины нарушения работы программы, сбои (failures) как нежелательные ситуации, ошибки (errors), как последствия сбоев и др. Базовым понятием тестирования является тест, который выполняется в заданных условиях и на заданных наборах данных. Тестирование считается успешным, если найден дефект или ошибка, и они сразу устраняются. Степень тестируемости определяется критерием покрытия системы тестами, проверки всех возможных путей выполнения алгоритмов программ и вероятности статического предположения того, что при тестировании может появиться сбой или ошибочная ситуация в системе.

Уровни тестирования:

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