Контекст и основные элементы архитектуры приложений

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

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

Характерным примером может являться наблюдающаяся тенденция выделения типовой функциональности, такой как управление пользователями на уровне общесистемных сервисов. Если раньше разработчики приложений обязательно включали поддержку таких функций как регистрация пользователей, присваивание им отдельных прав доступа, задание паролей в свои приложения, или предлагали использовать стандартные средства используемой СУБД, то теперь практически все приложения позволяют использовать стандартные возможности, предоставляемые LDAP-серверами. Другими примерами такого рода являются поддержка электронной почты или документооборота (workflow) между пользователями в рамках одного приложения.

 

2. Влияние архитектуры приложений на инфраструктуру

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

Например, компания Delta Air Lines построила свою «Нервную Систему», которая использует при работе с данными принцип публикации и подписки для управления операциями и работы с клиентами. Эта инфраструктура работает так, что каждый, кому это необходимо, будет получать точную информацию о статусе полета, экипажах и пассажирах.

Однако архитектура  этой инфраструктуры не обеспечивает адекватные возможности по созданию прикладных систем для таких задач, как планирование прибыли, что является критически важной проблемой для обеспечения прибыльности операций и распределения ресурсов, или развертывания ERP-системы для управления административными процессами. Таким образом, различные бизнес-процессы требуют разную по характеру среду информационных технологий, отличающуюся производительностью, надежностью. Для решения этой проблемы в компании Delta Air Lines была сформулирована концепция «архитектурного стиля», которая определяет архитектурный стиль как некоторую совокупность корпоративных технологий и операционных сред, ориентированных на обслуживание определенного класса бизнес-процессов.

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

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

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

Операции в реальном времени (Real-Time Operations). Примеры: транспортные операции в аэропорту, мониторинг пациентов  в клинике.

Аналитические приложения, бизнес-аналитика, поддержка принятия решений (Analytical and Business Intelligence). Примеры: интенсивный анализ больших массивов данных в поисках закономерностей, прогнозирование, принятие решений о выдаче кредита.

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

Корпоративные и обслуживающие (Utility) приложения. Этот стиль характерен для многих стандартных систем, таких  как ERP, CRM, системы управления персоналом, системы расчета заработной платы. Такая категоризация, возможно, не является бесспорной, но она дает некоторую основу для обсуждения набора тех прикладных систем, которые требуются организации, а также тех базовых, инфраструктурных технологий, которые должны поддерживать эти приложения.

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

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

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

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

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

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

	Процессы  с большим количеством транзакций	Операции  в реальном времени	Аналитические процессы и бизнес- аналитика	Совместная  работа	Корпоративные (обслуживание)
Стратегические  потребности	Предоставление услуг	Время реакции системы	Способность дать объяснение и поддержка принятия решения	Распространение знаний и скорость, инновации	Надежность, низкая стоимость  с точки зрения ИТ
Бизнес  – требования	Обслуживание клиентов, уменьшение затрат, работа 24*7 и целостность  данных	Экономичность и безопасность, работа 24*7*365	Повышение эффективности  и производительности, наглядность представления информации	Скорость выпуска услуг  и повторное использование знаний	Экономичность и улучшение  в процессах
Отличительные характеристики	Низкая стоимость (на одну транзакцию), надежность, масштабируемость, производительность, резервирование	Сканирование и фильтрация потока данных, приоритезация запросов, надежность, публикация и подписка на данные	Механизм аналитики, мощность обработки, объединение данных	Простота использования, надежность, высокая пропускная способность, обмен данными «по горизонтали»	Стандартные процессы, кандидаты  на аутсорсинг
Интегрирующие технологии	Системы интеграции корпоративных  приложений	Специально разработанный  програмный код	Хранилища данных	Совместно используемые данные и обмен данными	Стандартные интерфейсы (АPI)/ XML

 

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

 

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

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

Компенсацией и потенциальным  преимуществом будет идентификация  общих по характеру бизнес-процессов в различных подразделениях например, таких как аналитические задачи и применение наилучших технологий для таких общих потребностей. Основные рекомендации состоят в том, что неразумно использовать один «архитектурный стиль» набор технологий и решений для всех типов процессов и приложений. Более правильно идентифицировать несколько общих инфраструктурных технологий для различных категорий бизнес-процессов и прикладных систем, например, аналитика и применить к ним наиболее адекватный инструментарий для данного класса.

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

 

 

 

3. ТРЕБОВАНИЯ К ОБОБЩЕННОЙ АРХИТЕКТУРЕ ПРИЛОЖЕНИЙ ДЛЯ ПОИСКА КОДА

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

Рис. 2 – Обобщенная схема  поиска дублирующихся фрагментов кода

 

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

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

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

В контексте архитектуры  и дизайна вариант использования (use case) – это описание ряда взаимодействий между системой и одним или более действующими лицами (либо пользователем, либо другой системой).

Возвращаясь к системе  поиска клонов, можно выделить следующие  варианты использования.

Рис. 3 – Диаграмма вариантов использования

 

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

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

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

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

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

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