В настоящее время существует ряд разнообразных методов поиска дублирующегося исходного кода в программных продуктах. Эти методы используют различные техники для выявления клонов (softwareclones), имеют как преимущества, так и недостатки. Однако, как показано в [1], практически во всех случаях можно выделить ряд общих этапов в процессе обработки кода (рис. 1).
В связи с этим возникает идея построения новой программной системы, которая бы могла достаточно эффективно использовать различные алгоритмы дедупликации кода, и при этом не требовала бы существенных доработок при переходе от одного алгоритма к другому. В данной статье будут рассмотрены некоторые особенности создания архитектуры подобной системы.
Архитектура [2] — это фундаментальная организация системы, реализованная в ее компонентах, связях этих компонентов друг с другом и внешней средой и принципах, определяющих структуру и развитие системы.
Основным назначением архитектуры является описание использования или взаимодействия базовых элементов и компонентов приложения. Выбор структур данных и алгоритмов их обработки или деталей реализации отдельных компонентов являются вопросами проектирования. Часто вопросы архитектуры и проектирования пересекаются. Вместо того чтобы вводить жесткие правила, разграничивающие архитектуру и проектирование, имеет смысл комбинировать эти две области. В некоторых случаях, принимаемые решения, очевидно, являются архитектурными по своей природе, в других — больше касаются проектирования и реализации архитектуры.
В контексте архитектуры и дизайна вариант использования (use case) — это описание ряда взаимодействий между системой и одним или более действующими лицами (либо пользователем, либо другой системой).
Возвращаясь к системе поиска клонов, можно выделить следующие варианты использования (рис.2).
Предполагается, что поиск клонов будет осуществляться с учётом одного выбранного языка программирования. Можно указать отдельный файл, группу файлов или каталог для последующего анализа. Отбор нужных файлов целесообразно производить по расширению. Поскольку процедура поиска клонов может быть достаточно длительной, должна быть возможность её прерывания.
Ключевым фактором при выборе технологий для приложения является тип разрабатываемого приложения, а также предпочтительные варианты топологии его развертывания и архитектурные стили.
Выбор соответствующего типа приложения, как правило, определяется конкретными требованиями и ограничениями среды. В нашем случае, основываясь на основных выполняемых операциях и позиционируя создаваемое приложение, как вспомогательный элемент процесса разработки ПО, наиболее подходящим типом будет «насыщенное клиентское приложение для выполнения преимущественно на клиентских ПК».
Насыщенные клиентские приложения обычно разрабатываются как самодостаточные приложения с графическим пользовательским интерфейсом, который обеспечивает отображение данных с помощью набора элементов управления.
Развертывание — это процесс распространения готового приложения или компонента для установки на другие компьютеры. Приложения развертываются в физической среде, ограничения которой могут вносить коррективы в некоторые архитектурные решения. Следовательно, предполагаемый сценарий развертывания и инфраструктура должны рассматриваться как часть процесса проектирования приложения.
Поскольку разрабатываемое приложение будет работать преимущественно на клиентских ПК, то целесообразно использовать нераспределённую модель развертывания. При нераспределенном развертывании вся функциональность и слои приложения (кроме, как правило, функциональности хранения данных) располагаются на одном сервере (клиентской машине) (рис. 3).
Преимуществом данного подхода является простота и минимальные требования по количеству необходимых физических серверов. Также обеспечивается наилучшая производительность, поскольку взаимодействие между слоями осуществляется без пересечения физических границ между серверами или кластерами серверов.
Архитектурный стиль, иногда называемый архитектурным шаблоном — это набор принципов, высокоуровневая схема, обеспечивающая абстрактную инфраструктуру для семейства систем. Архитектурный стиль улучшает секционирование и способствует повторному использованию дизайна благодаря обеспечению решений часто встречающихся проблем. Архитектурные стили и шаблоны можно рассматривать как набор принципов, формирующих приложение.
Архитектура программной системы практически никогда не ограничена лишь одним архитектурным стилем, зачастую она является сочетанием архитектурных стилей, образующих полную систему.
Для построения системы поиска клонов будем использовать комбинацию компонентного, объектно-ориентированного и многослойного стилей.
Объектно-ориентированная архитектура — это парадигма проектирования, основанная на разделении ответственностей приложения или системы на самостоятельные пригодные для повторного использования объекты, каждый из которых содержит данные и поведение, относящиеся к этому объекту. При объектно-ориентированном проектировании система рассматривается как наборы взаимодействующих объектов. Объекты обособлены, независимы и слабо связаны; обмен данными между ними происходит через интерфейсы путем вызова методов и свойств других объектов и отправки/приема сообщений.
Компонентная архитектура описывает подход к проектированию и разработке систем с использованием методов проектирования программного обеспечения. Основное внимание в этом случае уделяется разложению дизайна на отдельные функциональные или логические компоненты, предоставляющие четко определенные интерфейсы, содержащие методы, события и свойства. В данном случае обеспечивается более высокий уровень абстракции, чем при объектно-ориентированной разработке, и не происходит концентрации внимания на таких вопросах, как протоколы связи или общее состояние.
Многослойная архитектура (рис. 4) обеспечивает группировку связанной функциональности приложения в разных слоях, выстраиваемых вертикально, поверх друг друга. Функциональность каждого слоя объединена общей ролью или ответственностью. Слои слабо связаны, и между ними осуществляется явный обмен данными. Правильное разделение приложения на слои помогает поддерживать строгое разделение функциональности, что в свою очередь, обеспечивает гибкость, а также удобство и простоту обслуживания.
Дальнейшее развитие архитектуры системы состоит в детальном проектировании каждого слоя, реализации всех ключевых вариантов использования и сценариев. Также необходимо учитывать, что в ходе этой работы дизайн системы будет изменяться, эволюционировать.