Рисунков 5 в тексте

Системный и программный инжиниринг – гармония найдена!

Сергей Зыль

Исторически сложилось, что системные архитекторы, разработчики программного обеспечения и тестировщики используют разные инструментальные средства. В результате одна только процедура передачи, например, подпроекта от системных инженеров разработчикам (особенно если речь идет о субподрядчиках) связана с немалыми трудностями и рисками. Элегантным решением такого рода задач является Harmony – платформо-независимый процесс модельно-управляемой разработки (Model-Driven Development -- MDD) компьютерных систем реального времени и встроенных систем.

Harmony-SE vs. Harmony-SWE

Для того чтобы понять суть процесса Harmony, необходимо вспомнить классический V-цикл разработки критического программного обеспечения. Под критическим (safety-critical) программным обеспечением понимается такое программное обеспечение, сбой которого может привести к человеческим жертвам или крупному материальному ущербу.

Рис. 1. Макроцикл Harmony - классический V-цикл создания критических систем.

Как видно из рис. 1 порядок проектирования и разработки критического программного обеспечения таков:

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

НЕ нашли? Не то? Что вы ищете?

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

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

Тесты должны проектироваться сразу после разработки соответствующей спецификации, т. е. до разработки программного обеспечения. В противном случае, вместо валидации («Правильная ли работа выполняется?») и верификации («Правильно ли выполняется работа?») артефактов проекта на соответствие спецификациям, существует почти непреодолимый соблазн заниматься выяснением того, как же работает то “нечто”, что придумали программисты.

Здесь уместно вспомнить классическую диаграмму дефектов программного обеспечения, известную как закон Рамамурти (Ramamoorthy), представленный на рис. 2.

Рис. 2. Закон Рамамурти

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

Основной причиной «живучести» закона Рамамурти является, по мнению экспертов, недооценка как заказчиками, так и исполнителями сложности современного программного обеспечения. Положение вещей на рынке встраиваемого программного обеспечения наглядно иллюстрируется таблицей 1.

Таблица 1. Объемы исходных кодом встраиваемых приложений

Когда

Разрядность

микропроцессоров

Среднее количество строк

исходного кода в приложении

Начало 90-х

8

8 000

Конец 90-х

16

80 000

2005 год

32

~1 

Из таблицы 1 видно, что в начале девяностых годов прошлого века встраиваемые системы использовали 8-разрядные процессоры и средний объем типового прикладного приложении я составлял 8 тысяч строк исходного текста. Встроенные системы работали автономно и были относительно простыми, поэтому многие распространенные в то время встраиваемые операционные системы (pSOS, SuperTask, VxWorks) не умели, например, обеспечивать изоляцию процессов в оперативной памяти. В конце 90-х годов рынок встраиваемых систем практически полностью перешел на 16-разрядные процессоры, а средний объем исходных кодов типового прикладного приложения составил уже 80 тысяч строк. И наконец, в начале этого века типовой процессор встраиваемой системы имеет 32 разряда, а объем размеры приложений достигли одного миллиона строк исходного текста. Современные встроенные системы подключены к вычислительным сетям, поддерживают разнообразные протоколы обмена и, разумеется, должны обеспечивать защиту информации от несанкционировнного доступа.

Чтобы удовлетворять новым требованиям разработчики встроенных систем стали широко применять современные операционные системы, имеющие развитые функциональные возможности (Windows CE, INTEGRITY, Neutrino, Linux), становится нормой использование полномасштабных инфраструктурных решений (CORBA, .NET), уже никого не удивляет словосочетание “Realtime Java”... Но сложность задач и требования заказчиков растут, сроки на выполнения работ сокращаются, а выделяемые на выполнение проектов ресурсы – в первую очередь человеческие – остаются прежними. Поэтому закон Рамамурти по-прежнему жив.

Есть ли выход? Есть. Он был предложен консорциумом Object Management Group (OMG) и получил название Model Driven Development (MDD) – “разработка на основе моделирования”. Идея MDD сама по себе не нова, но ее широкое использование стало возможным лишь с появлением современных технологий на базе унифицированного языка моделирования UML. Задача MDD – поменять на диаграмме Рамамурти графики внесения дефектов местами. Т. е. дефекты должны выявляться на этапе спецификации требований к проектируемой системе. Кроме того, MDD решает известную проблему обеспечения соответствия между моделью, построенной системными архитекторами, и программным обеспечением, написанным программистами.

Основной методологией MDD-разработки критических систем реального времени (критической называют такую систему, сбой которой может привести к человеческим жертвам или крупному материальному ущербу) является Harmony – результат развития и совершенствования методологии ROPES (Rapid Object-oriented Process for Embedded Systems). К его основным особенностям относятся:

- независимость от применяемых UML-инструментов;

- единый подход и к системному, и к программному инжинирингу;

- включает сбор требований к разрабатываемой системе и ех спецификацию;

- полная интеграция с любыми промышленными стандартами проектирования, разработки, тестирования и документирования, включая DoDAF (“Department of Defense Application Framework”), DO-178B, CMMI;

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

Harmony рассматривает проектирование и разработку как макроцикл, включающий три части (см. рис. 1): системный инжиниринг (Harmony-SE), программный инжиниринг (Harmony-SWE или микроцикл Harmony) и приемочное тестирование.

HARMONY-SE

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

- Идентификация и фиксирование функциональных требований к разрабатываемой системе;

- Идентификация возможных состояний и режимов работы разрабатываемой системы;

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

Основой для Harmony-SE служат операционные контракты. Операционный контракт – это спецификация поведения системы, которая получается путем добавления пред - и пост-условий к описанию соответствующей операции. Схема Harmony-SE представлена на рис. 3.

Рис. 3. Системный инжиниринг на основе моделирования

Основными задачами фазы анализа требований является фиксация и систематизация требований к проектируемой системе и группировка требований в варианты использования (Use Cases – UC) или прецеденты системы. Каждый вариант использования показывает один из аспектов функционирования системы, рассматриваемой как «черный ящик». Т. е. варианты использования никаким образом не подразумевают внутреннюю структуру системы или способ реализации той или иной функциональности. Следует заметить, что в ходе анализа требований не рассматривают варианты использования, связанные с обработкой исключительных ситуаций – это выполняется на стадии функционального анализа.

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

- Структура системы описывается с помощью блоков, представляющих на соответствующих UML-диаграммах базовые структурные элементы;

Интерфейсы между блоками (используемые или предоставляемые) описываются в виде портов;

- Взаимодействие между блоками описывается с помощью сообщений – запросов сервиса;

- Функции системы описываются операционными контрактами;

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

Каждый вариант использования рассматривается с двух точек зрения: анализ «Черного ящика» и анализ «Белого ящика». Анализ «Черного ящика» сфокусирован на взаимодействии системы с внешними объектами (например, с пользователями, базами данных или с другими системами) и позволяет определить поведение системного уровня. При анализе «Белого ящика» это поведение описывается как взаимодействие логических или функциональных подсистем разрабатываемой системы.

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

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

После верификации и валидации модели, полученной в результате функционального анализа системы, выполняется анализ вариантов использования «Белого ящика». В результате формируется модель, описывающая логическую структуру системы, и сценарии взаимодействия между логическими подсистемами. Верификация и валидация модели «Белого ящика» осуществляется с помощью уже имеющихся сценариев вариантов использования «Черного ящика».

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

HARMONY-SWE

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

Рис. 4. Организация модели (представление в браузере среды MDD-разработки Rhapsody)

Модель, построенная в ходе системного инжиниринга, включает три основных раздела: требования, архитектура и подсистемы. Для удобства эти разделы помещают в соответствующие пакеты (рис. 4). Например, пакет “SystemRequirements” (“Требования к системе”) содержит операционные и функциональные требования, представленные в виде вариантов использования и структурированные с помощью вложенных пакетов (“UseCase1”, “UseCase2”, “UseCase3”). Каждый вариант использования может иметь свои структурные диаграммы «Черного ящика» и «Белого ящика». Отдельный пакет “Requirements” содержит требования параметрического характера. Пакет “SystemArchitecture” содержит диаграммы, определяющие логическую структуру системы и интерфейсы между логическими подсистемами. И наконец, в отдельный пакет (в нашем примере “SubsystemSpecifications” помещают все артефакты, связанные с конкретными подсистемами – каждая физическая подсистема, разумеется, описывается отдельным пакетом.

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

- требования к подсистеме;

- интерфейсы подсистемы;

- архитектура, в которую подсистема должна “вписываться”.

Далее разработчики программного обеспечения действуют в соответствии с Harmony-SWE – процессом циклической инкрементной разработки (или “микроцикл Harmony”).

Рис. 5. Место микроцикла Harmony в V-цикле создания критичных систем.

Как видно из рис. 5 V-цикл включает несколько фаз разработки. Harmony-SWE предлагает выполнять эти фазы циклически, на каждой итерации создавая более детализированный прототип проектируемой системы. Удобнее и эффективнее с точки зрения управления проектом фазы разработки, выполняемые на каждой итерации, интерпретировать следующим образом:

1)  Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям;

2)  Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями;

3)  Реализация -- создание корректно работающего компонента или подсистемы;

4)  Тестирование -- получение верифицированной версии системы с хорошо известными возможностями;

5)  Ревизия -- идентификация и корректировка задач, связанных с выполнением всего проекта.

Анализ

На фазе анализа выполняется поиск ответа на вопрос «что?», но не на вопрос «как?». Эта фаза включает две процедуры: определение прототипа и объектный анализ.

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

- Идентификация существительных -- осуществляется путем поиска имен существительных и подлежащих в спецификации требований;

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

- Транзакции -- в качестве объектов транзакции могут рассматриваться тогда, когда нужно сохранять “следы” взаимодействия между объектами. Примерами транзакционных объектов могут служить сообщения или команды;

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

- Ключевые концепции -- в качестве объектов рассматриваются ключевые понятия предметной области. Например, в навигации таким понятием является местонахождения, а в банковском деле – расчетный счет;

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

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

вся работа сосредотачивается вокруг

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

Дизайн

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

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

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

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

Реализация

Фаза реализации включает трансляцию модели в исполняемые коды, тестирование программных модулей и ревизию их соответствия модели. Наиболее популярные UML-инструменты моделирования обеспечивают следующие возможности: IBM Rational Rose – генерацию скелетного исходного кода приложений, Telelgic Rhapsody – генерация полностью законченного исходного кода приложений (с точки зрения Rhapsody исходный код является одним из представлений модели наравне с UML-диаграммами). Высокая формализация UML-моделей позволяет генерировать исполняемый код непосредственно из модели, однако такой подход в настоящее время не пользуется доверием – разработчики изучают исходные коды, сгенерированные на заданном языке программирования (чаще всего – на С++ или Java), при необходимости изменяют параметры кодогенерации для тех или иных компонентов и, возможно, вносят необходимые изменения вручную (следует заметить, что современные инструменты MDD-разработки поддерживают обратное отображение написанного вручную кода в UML-модель). В зависимости от назначения создаваемой системы и требований к ее верификации могут осуществляться различные типы тестирования: функциональное, качества сервиса, покрытия кода, стресс-тестирование, нагрузочное. Протестированную модель целесообразно подвергнуть ревизии на предмет соответствия высокоуровневой модели. Результатом фазы реализации являются высококачественные компоненты и подсистемы создаваемой системы.

Тестирование

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

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

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

Ревизия

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

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

- Ревизия архитектуры. Архитектура оценивается на различных фазах проекта, тем не менее ревизия необходима – просчеты в архитектуре системы дорого стоят.

- Ревизия процесса. Проводится оценка самого процесса разработки и его рабочих процедур – при необходимости процесс корректируется.

- Ревизия рисков. Большинство проектов терпят неудачу из-за игнорирования рисков. В Harmony план управления рисками является одним из важных артефактов. На данном шаге необходимо проверить, как контролируются предусмотренные в плане риски, а так же какие новые риски появились.

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

***

Процесс Harmony нашел широкое применение преимущественно в аерокосмической и оборонной отраслях промышленности США и стран Евросоюза – использование инструментальных средств, поддерживающих этот процесс является обязательным при участии в проектах Airbus, Boeing, Lockheed Martin и других известных корпораций. После краткого обзора этой стройной и эффективной методологии разработки критически важных программно-аппаратных систем жесткого реального времени читатель сможет оценить определение, которое Harmony дает процессу: «Процесс – это спецификация серии последовательных деятельностей, выполняемых группой взаимодействующих специалистов, в результате которой создается когерентное множество артефактов, одним из которых является требуемая система».

[об авторе] Сергей Зыль (s. *****@***ru), преподаватель учебного центра компании SWD Software (г. Санкт-Петербург).