Использование подхода на основе приведенных выше правил по-
зволяет повторно применять правила в других проектах, внося в них
необходимые изменения.
Обсуждение полученных результатов.
Сравним предложенный
подход с ОО- и СОА-подходами на основе требований I–IV.
Известно, что важную проблему представляет не проектирование,
а перепроектирование системы. При использовании ОО-подхода эта
проблема очень серьезна, так как подход на основе шаблонов проек-
тирования является “хрупким”, перепроектирование часто приводит
к полной переработке шаблонов системы. Эту проблему, в частно-
сти, пытаются решать с помощью элементарных шаблонов проекти-
рования [10]. В случае СОА-подхода система при перепроектировании
является менее “хрупкой”, поскольку она создана на основе неболь-
ших сервисов, элементы workflow поддаются изменениям достаточ-
но хорошо. Однако workflow охватывает не все элементы системы,
пользовательский интерфейс приходится перепроектировать традици-
онными методами. Предлагаемый подход обеспечивает максимальную
гибкость при перепроектировании, изменение требований приводит к
изменению правил, программный код генерируется автоматически.
ОО- и СОА-подходы не обеспечивают гибкой замены использу-
емых технологий и языков программирования. За счет использова-
ния workflow, СОА-подход обладает несколько большей гибкостью по
сравнению с ОО-подходом, однако вызовы библиотек, как правило,
происходят на уровне сервисов в тексте программы. Предлагаемый
подход обеспечивает гибкость, так как технологии и языки програм-
мирования задаются на уровне правил.
В ОО- и СОА-подходах объяснение текста программы выполня-
ется с использованием комментариев, которые могут отсутствовать. В
предлагаемом подходе с помощью трека можно проследить путь от це-
лей проектирования до сгенерированного кода. Результаты сравнения
приведены в таблице.
Результаты сравнения ОО-подхода, СОА-подхода и предлагаемого подхода
Требование
ОО-подход СОА-подход Предлагаемый
подход
I. Гибкость модификации кода
системы в зависимости от из-
меняющихся требований
Не обеспечивает Частично
обеспечивает
Обеспечивает
II. Гибкая замена элементов ис-
пользуемых технологий
Не обеспечивает Частично
обеспечивает
Обеспечивает
III. Независимость от целевого
языка программирования
Не обеспечивает Не обеспечи-
вает
Обеспечивает
IV. Возможность объяснения
сгенерированного кода
Не обеспечивает Не обеспечи-
вает
Обеспечивает
ISSN 0236-3933. Вестник МГТУ им. Н.Э. Баумана. Сер. “Приборостроение”. 2014. № 5 85
