Разработка программного
обеспечения на основе
визуального моделирования
В.В. Макаров,
ст.н.с., доц.,
к.т.н., с.н.с.,
ИПУ
РАН, makarov@ipu.ru,
г.Москва
1. Традиционный подход к проектированию ПО
Традиционные
подходы к разработке на основе документации предполагают, что требования к
системе неформально сформулированные в документе полностью определяют систему.
Этот документ передаётся на следующий этап системного анализа и проектирования.
На
этом этапе определяется высокоуровневая архитектура системы, разбивая её на
аппаратные, программные, механические и другие взаимодействующие части. Опять
же всё это определяется неформально с использованием текстовых спецификаций.
Проектировщики
ПО получают спецификации на ПО и начинают определять архитектуру ПО входящего в
систему. Обычно архитектуру определяется в виде спецификаций как ПО должно быть
реализовано.
В
этой точке проект должен быть полностью определён, так чтобы он мог быть
реализован и протестирован на разных уровнях: от элементарного, интеграционного
и приёмочного тестирования
2. Современный подход к проектированию ПО
Процесс
разработки на основе проектной документации не способен более обеспечить
предсказуемое создание ПО для встраиваемых устройств и своевременный вывод на
рынок новых продуктов. По оценкам зарубежных специалистов с конца 90-х годов
число строк кода для встраиваемых систем, которое пишется программистами, растет
по экспоненциальному закону и достигает в настоящее время более миллиона строк
в год. К 2010 году ожидается увеличение на 35% объема внутренней электроники и
ПО. 90% процентов инноваций связаны с встраиваемыми системами с электроникой.
80% этих инноваций связаны с ПО.
При этом сложилось ряд мифов о создании ПО, что
например, программное обеспечение легко модифицировать, что разработчики,
сидящие в одной комнате, тесно взаимодействуют и т.п. Рассматривая V-цикл
проектирования и разработки ПО (Рис.1), количество выявленных дефектов при
традиционном проектировании растет экспоненциально по этапам проектирования.
Для внедренных проектов количество выявленных дефектов имеет вид обратной экспоненты,
т.е. этап спецификации требований имеет наибольшее количество дефектов.
При
выявлении серьезных дефектов ПО предприятия-разработчики снижают функциональность
разрабатываемого продукта, переписывают некорректные модули или даже отменяют
проект, превышают сроки сдачи проекта или выделенный бюджет. Решение проблемы –
разработка ПО на основе моделей, описанных на языке UML. Изменение технологии
проектирования изменяет знак экспоненты количества дефектов по стадиям проектирования.
рис.1 V-цикл проектирования и разработки ПО
Основные
достоинства применения UML в структурированном
представлении требований, в необходимости обдумывать модель, а не код, в достижении
четкой и целостной структуры ПО, в возможности использовать анимацию и
симуляцию, применение UML на всех фазах разработки
(включая анализ) обеспечивает ее структурированность, автоматическая генерация
кода повышает производительность труда и снижает количество ошибок, в корреляции
между моделью, кодом и документацией, графическое представление проекта в UML
облегчает взаимодействие между разработчиками и пользователями, повышается
уровень абстракции, вследствие чего облегчается надзор, визуализируется структура
и взаимосвязи, что позволяет повысить качество кода.
UML
- язык для спецификации, визуализации, проектирования и документирования ПО,
бизнес-процессов и других систем. Назначение UML – обеспечить спецификацию
моделей. Историю появления и развития UML представлена на рис.2.
Рис.2 Появление и развитие UML. OOSE - Object
Oriented Software Engineering Method, OMT – Object Modelling Technique, UML - Unified Modeling Language,
SysML – System Modeling Language, RFP – Request for Proposal
Модель
описывается интегрированным когерентным набором UML-диаграмм (рис.3). Исходный
текст приложения – это одно из представлений модели, описанной на UML [2].
Use Case Diagram -
диаграмма вариантов использования показывает, что система делает и кто ее
использует. Sequence Diagram - диаграммы
последовательностей показывают как объекты взаимодействуют во времени. Class Diagram - диаграмма классов показывает классы и связи между
ними. State Machine Diagram -
конечные автоматы используются, когда перед переходом в другое состояние надо
ждать пока что-то произойдет. Activity Diagram -
диаграммы деятельности используют для описания поведения операций, классов и
вариантов использования. Как только одна деятельность заканчивается, начинается
следующая. Package Diagram - пакет похож на папку и
используется для организации элементов UML-модели. В CASE системах
разработки этим диаграммам соответствуют модули конфигурационного управления.
Использование средств моделирования, основанных на UML, является,
по крайней мере на словах, общепризнанной практикой при разработке крупных
бизнес-приложений, предназначенных для эксплуатации на настольных системах или майнфреймах.
рис.3 Диаграммы UML 2.0
Однако при создании ПО для встраиваемых систем моделирование
применяется значительно реже. Этому имеется ряд объективных причин: маломощность
аппаратной базы встраиваемых систем по сравнению с ПК; жесткие ограничения по
времени реакции на возникающие события и не менее жесткие требования к надежности
ПО; существование широкого спектра процессорных архитектур, ни одна из которых
не занимает доминирующего положения; связанное с этим разнообразие ОС и средств
разработки и одновременно невозможность применения инструментария, предназначенного
для создания решений для настольных систем.
Возникает
вопрос, применим ли UML для Real-Time System. На
этот вопрос Grady Boch уже в 1997 году дал положительный
ответ: Real-Time UML – это стандартный UML, UML – адекватен
для систем реального времени. Несмотря на некоторые запросы о расширении UML для
сферы реального времени опыт показывает, что в этом нет необходимости.
Приложения
реального времени и встраиваемые приложения имеют некоторые особые требования [1]:
·
к QoS (объем памяти, время загрузки, WCET и т.п.);
·
к низкоуровневому программированию;
·
к функциональной безопасности (safety) и надёжности (reliability).
Под
термином «Real-Time UML» понимают применение UML для
выполнения этих особых требований.
По
сути модель на языке UML и код на языке программирования в современной системе
разработки являются лишь двумя различными представлениями одного и того же
проекта. Благодаря этому свойству ликвидируется одна из наиболее неприятных и
опасных особенностей разработки ПО с использованием UML - утрата соответствия
между моделями, созданными на этапе анализа и проектирования, и реальным кодом,
полученным в процессе разработки и отладки приложения.
3. Тестирование
Не один soft по оценкам зарубежных
специалистов не тестируется более чем на 60%. Несмотря на долгое использование PLM имеется
множество примеров ошибок в проектах. 60-70% IT проектов заканчивается
неудачно из-за неудачных требований. В среднем IT проекты на 220% продолжаются
дольше, т.е. проект длится в 2-3 раза дольше.
Процесс верификации является процессом
определения того, что программные продукты функционируют в полном соответствии
с требованиями или условиями, реализованными в предшествующих работах. Для
оценки эффективности затрат и выполняемых работ верификация должна как можно
раньше реализовываться в соответствующих процессах (таких как поставка, разработка,
эксплуатация или сопровождение). Данный процесс может включать анализ, проверку
и испытание (тестирование) - ГОСТ Р ИСО/МЭК 12207-99 «Информационная
технология. Процессы жизненного цикла программных средств».
Автоматизация тестирования в современных CASE системах
может выглядеть следующим образом [3-5] - Рис.4.
Таблица 1
Требования к покрытию критичных приложений
тестами (DO-178B)
|
Уровень |
Влияние на безопасность |
Покрытие |
Требование к покрытию |
|
A |
Программное обеспечение, сбой
которого может привести к возникновению или способствовать возникновению
катастрофического сбоя самолета. |
MC/DC |
Уровень B + 100% MC/DC |
|
B |
Программное обеспечение,
сбой которого может создать условия или способствовать созданию условий для
опасного сбоя |
DC |
Уровень C + 100% DC |
|
C |
Программное обеспечение,
сбой которого может создать условия или способствовать созданию условий для
крупного сбоя |
SC |
Уровень D + 100% SC |
|
D |
Программное обеспечение,
сбой которого может создать условия или способствовать созданию условий для
малозначительного сбоя |
|
100%
покрытие требований |
|
E |
Программное обеспечение,
сбой которого не может влиять на самолет или на нагрузку пилота |
|
Нет требований |
рис.4 Концепция автоматизации тестирования
Покрытие операторов (Statement Coverage
– SC) означает, что в ходе тестирования каждый оператор программы был
вызван или использован не менее одного раза. Когда говорят о покрытии кода – «Code coverage» – обычно имеют ввиду именно SC.
Покрытие ветвей (Decision Coverage – DC)
означает, что в ходе тестирования каждая точка входа в программу и выхода из
нее была использована не менее одного раза так, что каждое возможное значение логических
условий принималось не менее одного раза. По сути дела, это означает, что в
ходе тестирования каждое логическое условие имело и значение «истина», и значение
«ложь».
Покрытие условий и ветвей (Modified Condition/Decision Coverage
– MC/DC) означает, что в ходе тестирования каждая точка
входа в программу и выхода из нее была использована не менее одного раза так,
что каждое решение в программе принимало все возможные значения. При этом было
показано, какое влияние оказывает на решение каждое условие независимо от остальных
условий. Для сложных логических операций необходимо разрабатывать таблицы
истинности, что бы определить все возможные комбинации значений «истина» и
«ложь».
Современные CASE средства должны иметь в своем
составе подсистему автоматической генерации тестов. Эта подсистема автоматически генерирует тест-кейсы
с высоким покрытием проекта:
§ покрытие модели: состояний,
переходов, операций, генерации событий;
§ покрытие кода: генерация всех
возможных комбинаций входных данных для MC/DC.
Подсистема автоматической генерации тестов анализирует
исходные тексты для генерации векторов. Информация UML-модели направляет генерацию
тестов к заданной цели. Автоматическая генерация тест-кейса для анализа
покрытия может включать в себя задачи:
§
активизации состояния конечного автомата;
§
выполнения перехода;
§
генерации/принятия события;
§
вызова/возврата из операций;
§
создания/уничтожения объектов.
Кроме автоматической генерации тест-кейса, в
системе обязательно должна быть предусмотрена возможность генерации заданного
пользователем тест-кейса, т.е. особые тестовые сценарии приходится разрабатывать
вручную.
При этом подсистема автоматической генерации
тестов должна обеспечивать среду процесса:
- для
интерактивного процесса играть роль пользователя;
- управлять действиями среды:
•
порождение событий;
•
вызов операций;
•
задание значений параметров;
•
изменение активных потоков;
•
задание команд Go (Go Event, Go Idle и т.д.);
•
управление течением времени.
В итоге подсистема тестирования должна производить анализ результатов.
Чтобы при
создании ПО значительно повысить продуктивность и снизить риски, необходимо
обеспечить выявление и устранение ошибок на ранних стадиях процесса разработки.
Для отладки приложения в подсистеме тестирования используются те же графические
представления, что и для построения моделей: с этой целью подсистема превращает
модели UML в проверяемые исполняемые модели. В результате во время тестового
прогона можно видеть текущее состояние выделенных диаграмм, передаваемые
сообщения в диаграммах последовательности, динамически создаваемые и
уничтожаемые экземпляры классов, а также изменяющиеся значения атрибутов. Это
позволяет создавать и проверять графические исполняемые спецификации до начала
высокоуровневого проектирования. Более того, программисты могут исполнять и
проверять структуру, интерфейсы и поведение компонентов раньше, чем система
будет передана на приемочные испытания. Группа тестирования может графически
проверить систему, выполняя сценарии на уровне "черного ящика".
4. Заключение
На
что, исходя из опыта, должен обратить особое внимание руководитель проекта,
приступая к применению систем разработки на базе UML [4, 6].
Для начала выбрать маленький проект или хорошо определенный подпроект.
Изучить сгенерированный код – это поможет понять UML.
Обязательно провести обучение для разработчиков по использованию
инструмента.
Начать с того, что UML будут использовать только
несколько разработчиков. Затем постепенно увеличивать их число.
Требуется обучение ООП, UML и системы разработки.
Использовать индивидуальное «натаскивание» (coaching) в пилотном проекте
Используйте UML и генерацию кода только если целевая платформа
имеет достаточную производительность.
Использовать хорошо определенный процесс разработки.
Литература
1. Douglass, Bruce
Powel. Real-Time Design Patterns: robust scalable architecture for Real-time
systems. – Addison-Wesley, 2003.
2.
Леоненков, А.В. –
Лекции по курсу «Нотация и семантика языка UML». http://www.intuit.ru
3.
Интернет-сайт http://www.ilogix.com.
4.
Интернет-сайт http://www.ibm.com.
5.
Интернет-сайт http://www.real-time.org.
6.