Лекции: Инженерия и инструментарий ПО

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

Ряд направлений инженерии ПО представляет интерес с методологической и технологической точек зрения.

Стиль программирования — набор приёмов, методик и практик кодирования, которые используются, чтобы получить правильные, эффективные, простые для понимания и удобные для применения программы.

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

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

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

Защитное программирование — подход к программированию, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом. Существуют три основных принципа защитного программирования:

• 1. Общее недоверие: Для каждого модуля входные данные должны тщательно анализироваться в предположении, что они могут быть ошибочными.
• 2. Немедленное обнаружение: Каждая ошибка должна быть выявлена как можно раньше, это упрощает установление её причины.
• 3. Изолирование ошибки: Ошибки в одном модуле должны быть изолированы так, чтобы не допустить их влияние на другие модули.

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

• — Проверка области значений переменных.
• — Контроль правдоподобности значений переменных.
• — Проверка результатов вычислений.
• — Автоматические проверки (например, контроль переполнения).
• — Проверка длины элементов информации.
• — Проверка кодов возврата функций.

К механизмам защитного программирования относят:

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

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

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

Проектирование по контракту — подход к проектированию и программированию, основанный на документировании прав и обязанностей подпрограмм и модулей для корректности программы. Предложен Б. Мейером и изложен им в 1997 г. в книге «Конструирование объектно-ориентированного ПО».

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

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

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

Ряд направлений инструментария ПО позволяет оценить инженерно-практическую сторону методологии и технологии разработки ПО. Методологические и технологические подходы разработки становятся эффективными и экономически выгодными при их автоматизации. Системы автоматизации программной / системной разработки получили название «CASE-средства».

CASE-средство (CASE — букв. компьютерная автоматизированная программная / системная инженерия) — система автоматизированной разработки ПО / систем с помощью компьютеров.

Обычно CASE-средством считается программное средство, автоматизирующее некоторую совокупность ЖЦ и обладающее следующими особенностями:

• 1. Визуальные возможности для описания и документирования систем — обеспечивает удобный интерфейс с разработчиком и реализацию его творческих возможностей, избавляя от рутинной деятельности.
• 2. Интеграция компонент этого средства — позволяет управлять процессом разработки с помощью элементарной передачи данных между компонентами.
• 3. Использование репозитория — единого хранилища информации о проекте.

Интегрированное CASE-средство включает в себя следующие компоненты:

• 1. Репозиторий — основа CASE-средства: база данных со специальными возможностями по хранению и управлению информацией о проекте.
• 2. Компоненты разработки: бизнес-моделирование с использованием различных методологий и технологий, анализ и проектирование.
• 3. Компоненты программирования: кодирование и тестирование / инспектирование, а также интеграция и сопровождение.
• 4. Компоненты поддержки: документирование и управление конфигурацией, верификация и аттестация, обзор и аудит.
• 5. Компоненты организации: управление проектом, инфраструктура.

CASE-средства обычно классифицируются по типам и категориям.

Тип CASE-средства отражает его функциональное назначение:

• 1. Анализ и проектирование: анализ требований и проектирование, в том числе определение требований, специфицирование и построение архитектуры системы различного уровня детализации.
• 2. Проектирование баз данных: моделирование данных, преобразования моделей данных, генерация схем баз данных и описаний форматов файлов.
• 3. Программирование (разработка приложений): автоматизированное кодирование, тестирование и/или инспектирование, интеграция.
• 4. Сопровождение и поддержка: сопровождение всех категорий, документирование и другие связанные действия.
• 5. Управление проектом: руководство, планирование, контроль.
• 6. Инфраструктура: создание и управление инфраструктурой.

Таким образом, классификация по типам определяется компонентным составом CASE-средств.

Категория CASE-средства связана со степенью взаимодействия его компонентов в рамках охватываемых им стадий ЖЦ:

• 1. Инструментальное средство (букв. инструмент) — вспомогательное средство для решения относительно самостоятельных задач.
• 2. Инструментальный пакет (букв. набор инструментов) — связанная совокупность инструментальных средств для решения класса задач обычно в рамках одной стадии ЖЦ.
• 3. Инструментарий (букв. верстак) — организованная совокупность инструментальных средств для решения класса задач в рамках всего ЖЦ.

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

Дополнительная классификация связана с выделением уровней.

Уровень CASE-средства выражает область его действия в рамках ЖЦ:

• 1. Верхний уровень: организация, управление.
• 2. Средний уровень: моделирование, анализ и проектирование.
• 3. Нижний уровень: программирование и поддержка.

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

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

Большинство технологий разработки и соответствующих им CASE-средств ориентировано на одну из двух наиболее популярных методологий — структурную или объектно-ориентированную. Для бизнес-моделирования, анализа и проектирования CASE-средства на основе структурной методологии используют подходы на основе DFD, ERD, STD и IDEF0 (SADT) с применением при необходимости других моделей и методов, а CASE-средства на основе объектно-ориентированной методологии применяют подход на основе UML.

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

• 1. Дайте определение понятию «стиль программирования».
• 2. Как формируется стиль программирования?
• 3. Дайте определение понятию «защитное программирование». Перечислите основные принципы защитного программирования.
• 4. Перечислите общие рекомендации по защитному программированию. Перечислите и поясните механизмы защитного программирования.
• 5. Что представляет собой подход Проектирование по контракту? Поясните механизм, используемый Проектированием по контракту?
• 6. Что такое CASE-средство? Перечислите их особенности и компоненты.
• 7. Перечислите основные признаки классификации CASE-средств.
• 8. Приведите классификации CASE-средств по типам, категориям и уровням.
• 9. Кратко охарактеризуйте системы автоматизации.