АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
1.3. Понятие архитектуры ИС Современные ИТ и ИС достигли такого уровня развития, когда на первый план выходит бизнес-оценка проектов, а не личные пристрастия разработчиков или заказчиков. В связи с этим большое внимание в настоящее время уделяется архитектуре ИС. Термин "архитектура" в применении к ИС уже давно стал привычным, так как грамотное построение ИС, эффективно и надежно функционирующей, является не менее сложной задачей, чем проектирование и возведение современного многофункционального здания. Архитекту́ра (лат. architectura ) - искусство проектировать и строить здания и другие сооружения (также их комплексы), создающие материально организованную среду, необходимую людям для их жизни и деятельности, в соответствии с современными техническими возможностями и эстетическими воззрениями общества. Постепенно классическое определение архитектуры трансформировалось в применении к техническим системам, как принципиальное устройство чего-либо сложного, общий вид, без указания конкретных инженерных расчетов. Когда речь заходит об архитектуре ИС, то, прежде всего, следует задаться вопросом, зачем нужно само понятии архитектура и какую пользу можно извлечь из его существования. Ответ на этот вопрос применительно к программным системам можно найти, в частности, в [10], где ответ формулируется следующим образом. Программная архитектура – это абстракция или модель, а точнее одна из ряда моделей, описывающих ИС, которая обычно создаются на этапе архитектурного проектирования, при этом ИС ставится в соответствие архитектурное описание, которое может быть полезным для решения, по крайней мере, 3 важных задач проектирования ИС. 1. Архитектурное описание, выполненное в соответствии с определенными правилами, может использоваться как язык общения между заинтересованными сторонами (архитектор, аналитик, программист, покупатель, пользователь) в процессе, как проектирования, так и эксплуатации. 2. Архитектурное описание, наряду с другими, более детализированными описаниями, может использоваться для генерации кода приложения. Такой подход называют проектированием с помощью моделей. Этот подход более подробно будет рассмотрен ниже. 3. Архитектурное описание может быть полезно при проектировании линеек или семейств продуктов, которые могут строиться на базе одной и той же архитектуры, что позволяет уменьшить стоимость разработки и уменьшает риски. Следует заметить, никогда не возникало недостатка в определениях понятия архитектура. На сайте SEI (Software Engineering Institute) имелся даже специальный раздел, посвященный определениям архитектуры, где их собрано более ста [11]. Рассмотрим несколько вариантов определения понятия "Архитектура ИС" [10]: Архитектура – это организационная структура системы. Архитектура ИС – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы. Архитектура – это набор значимых решений по поводу организации системы программного обеспечения, набор структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе с их поведением, определяемым во взаимодействии между этими элементами, компоновка элементов в постепенно укрупняющиеся подсистемы, а также стиль архитектуры, который направляет эту организацию – элементы и их интерфейсы, взаимодействия и компоновку. Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними. Архитектура – это структура организации и связанное с ней поведение системы. Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы. Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания. Для того чтобы разобраться в этом многообразии определений, выделим наиболее существенные стороны архитектуры ИС. Основным критерием выбора архитектуры и инфраструктуры ИС в условиях рыночной экономики является минимизация совокупной стоимости владения системой. Из этого следует два основных тезиса. В проектах построения ИС, для которых важен экономический эффект, должна выбираться архитектура системы с минимальной совокупной стоимостью владения. Совокупная стоимость владения информационной системой состоит из плановых затрат и стоимости рисков. Стоимость рисков определяется стоимостью бизнес-рисков, вероятностями технических рисков и матрицей соответствия между ними. Матрица соответствия определяется архитектурой информационной системы. Термин «Архитектура ИС» обычно довольно согласованно понимаются специалистами на уровне подсознания, и столь же несогласованно определяются. Два основных класса определений архитектур — определения «конструктивные» и «идеологические». Основные идеологические определения архитектуры ИС таковы: «Архитектура ИС — это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой». «Архитектура ИС — это набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения». Оба эти определения согласованы в том смысле, что если ключевое решение приходится изменять при изменении бизнес-технологии в рамках бизнес-видения, то резко возрастает стоимость владения системой. Следствием этих определений является понимание важности принятия архитектуры системы как стандарта предприятия, ввиду значимости архитектурных решений и их устойчивости по отношению к изменениям бизнес-технологии. Еще одно важное следствие первого определения — архитектура системы на самом деле должна строиться еще на стадии технико-экономического обоснования системы. Выделим несколько наиболее значимых и принципиально различных типов рисков: проектные риски при создании системы; технические риски, состоящие в простоях, отказах, потере или искажении данных и т. п.; риски бизнес-потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из-за технических рисков). Такие риски бизнес-потерь назовем бизнес-рисками. Каждый бизнес-риск принадлежит, по крайней мере, одному из вариантов бизнес-использования (business use case) системы. Например, для интернет-магазина бизнес-риски «Покупатель не может сделать заказ и уходит» и «Покупатель делает заказ, но уходит рассерженный функционированием системы» принадлежат вариантам бизнес-использования «Сделать заказ». риски бизнес-потерь, связанные с вариативностью бизнес-процессов. При этом потери происходят оттого, что: а) бизнес-процессы надо изменять, а информационная система не готова к этому, и потери связаны с неоптимальным функционированием бизнеса; б) приходится платить за модификацию системы. Такие риски бизнес-потерь назовем неопределенностями (RUP упоминает аналогичные по смыслу «варианты изменения», change cases). Затраты на создание и эксплуатацию системы с некоторой точностью оцениваются достаточно стандартно. Динамические же бизнес-риски количественно учесть невозможно, и их следует оценивать исключительно качественно (на уровне понимания, насколько бизнес-процессы в организации являются определенными/застывшими/неустоявшимися). Наиболее интересная часть совокупной стоимости владения системой — статические бизнес-риски и риски разработки. Каждый вариант бизнес-использования реализуется с помощью набора операций соответствующих бизнес-процессов, а бизнес-риск возникает по причине неисполнения одной или нескольких операций. Такие риски мы называем операционными. Таким образом, операционные риски являются источниками бизнес-рисков. Например, источниками риска «Покупатель не может сделать заказ и уходит» могут быть операционный риск «Информация о заказе не может быть передана для обработки в систему». В свою очередь операционные риски для автоматизированных операций могут возникать по причине технических рисков. Например, операционный риск «Информация о заказе не может быть передана для обработки в систему» может возникнуть по причине реализации технического риска «Обрыв канала связи». С другой стороны, бизнес-риск может быть парирован соответствующей организацией процесса и/или архитектурным решением. Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы: что делает система; на какие части она разделяется; как эти части взаимодействуют; где эти части размещены. Таким образом архитектура ИС является логическим построением, или моделью, и влияет на совокупную стоимость владения через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т. п. — то есть через то, что мы называем инфраструктурой ИС. Еще раз подчеркнем, что инфраструктура включает решения не только по программному обеспечению, но и по аппаратному комплексу и организационному обеспечению. Это вполне соответствует пониманию системы в наиболее современных стандартах типа ISO/IEC 15288 [12]. В результате длительных обсуждений, которые происходили в течение 90-х годов прошлого века были выпущены 2 стандарта [5] и [6]. Первый стандарт назывался «Рекомендации по архитектурному описанию программных систем (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems) появился в 2000 году, а второй появился в 2011 году и называется «Системная и программная инженерия – архитектурное описание». Второй стандарт является новой редакцией первого. В нем архитектура системная и программные архитектуры определяются следующим образом. Стандарт [6] определяет архитектуру как принципы организации системы, в терминах основных компонентов, их взаимосвязей, окружения и принципов проектирования и эволюции, а архитектурное описание как набор артифактов, составляющих описание архитектуры. Появление стандартов фактически положило конец дискуссиям о том, что такое системная и программная архитектура. Однако использовать данное определение применительно к корпоративным ИС затруднительно, поскольку корпоративные системы – это, прежде всего, многоуровневые системы. Кроме того, они имеют очень длительный жизненный цикл, длительность которого может измеряться десятилетиями. На протяжении всего жизненного цикли они постоянно развиваются. Остановимся более подробно на КИС. С КИС обычно связывают такие понятия как корпоративная архитектура, корпоративная информационная система. Корпоративная архитектура (Enterprise architecture (EA)) – эта методология для формирования проактивной холлистической реакции организации на внешние деструктивные воздействия посредством идентификации, анализа и формирования реакции с целью получения желаемого состояния бизнеса и результатов его функционирования. ЕА должна представлять руководству и, в частности, ИТ менеджерам, готовую информацию для принятия решений, выработку политик и формирование политик, направленных достижение максимальной эффективности функционирования организации [13]. Корпоративная информационная система (Enterprise Information System (EIS)) (КИС) – любая ИС, предназначенная для совершенствования реализуемых в организации бизнес-процессов посредствам их интеграции. КИС может работать на любых уровнях. Термин «корпоративная» (enterprise) в данном случае используется в самом широком смысле. Это может быть либо транснациональная корпорация, небольшая коммерческая фирма, образовательное учреждение, больница, некоммерческая организация и т.д. Особо следует отметить, что речь идет не только об организации в классическом понимании, но это может быть и виртуальная организация. Корпоративная информационная архитектура (Enterprise information architecture (EIA)) (КИА) – это часть корпоративного архитектурного процесса. КИА предназначена для описания текущего состояния и прогнозировать изменение состояния с целью повышения качества функционирования системы. КИА оперирует такими понятиями требования, принципы, модели [14]. Из приведенных определений видно, что термин «корпоративная архитектура» определяется как система поддержки принятия решений, КИС – это, прежде всего, интеграционная система, а КИА – это элемент архитектурного процесса. Приведенные определения фактически отражают только требования, но не дают никакой информации о принципах организации и функционирования КИС. Эта информация содержится в документе, который называется Корпоративный архитектурный фреймворк (Enterprise Architecture framework) [14]. В данном случае под термином фреймворк понимается эталонная реализация. Эта модель восходит к предложенной еще в 1988 году модели NIST Enterprise Architecture Model (Национальный институт стандартов и технологий - одного из агентств Министерства торговли США), в соответствии с которой модель описывается как 5 уровневая модель, в которой определяются следующие уровни (рис. 1.1). бизнес архитектура (Business architecture); ИТ архитектура (Information Technology Architecture) или информационная архитектура (Information Architecture), архитектура данных (Data Architecture), архитектура приложения (Application Architecture) или программная архитектура (Software Architecture), техническая архитектура (Hardware Architecture). Совокупность данных архитектур и является архитектурой ИС Бизнес архитектура или архитектура уровня бизнес процессов определяет бизнес стратегии, управление, организацию, ключевые бизнес процессы в масштабе предприятия, причем не все бизнес процессы реализуются средствами ИТ технологий. Бизнес архитектура отображается на ИТ архитектуру.  Рис. 1.1. Архитектурные уровни ИТ архитектура рассматривается в трех аспектах: обеспечивает достижение бизнес целей посредством использования программной инфраструктуры, ориентированной на реализацию наиболее важных бизнес приложений; среда, обеспечивающая реализацию бизнес приложений; совокупность программных и аппаратных средств, составляющая информационную систему организации и включающая, в частности, базы данных и промежуточное программное обеспечение. Архитектура данных организации включает логические и физические хранилища данных и средства управления данными. Архитектура данных должна быть поддержана ИТ архитектурой. В современных ИТ системах, ориентированных на работу со знаниями, иногда выделяют отдельный тип архитектуры – архитектуру знаний (Knowledge Architecture). Программная архитектура отображает совокупность программных приложений. Программное приложение – это компьютерная программа, ориентированная на решение задач конечного пользователя. Архитектура приложений – это описание отдельного приложения, работающего в составе ИТ системы, включая его программные интерфейсы. Архитектура приложения базируется на ИТ архитектуре и использует сервисы, предоставляемые ИТ архитектурой. Техническая архитектура характеризует аппаратные средства, системное ПО и включает такие элементы, ОС, процессор, память, жесткие диски, периферийные устройства, элементы, используемые для их соединения, а также сетевые средства. Часто нельзя провести четкой границы между ИТ архитектурой и архитектурой отдельного приложения. В частности, в случае, когда некоторую функцию требуется реализовать в нескольких приложений, то она может быть перенесена на уровень ИТ архитектуры. Обычно приложения интегрируются средствами ИТ архитектуры. 1.4. Классификация ИС В виду многообразия ИС остановимся на их классификации. В последние годы все более широкое распространение получил доменный подход к описанию ИТ архитектур. Под доменной архитектурой понимают эталонную модель, описывающая множество систем, реализующих похожую структуру, функциональность и поведение. Доменную архитектуру можно рассматривать как метамодель, описывающая множество решений. Схемы классификации архитектур ИС, основанная на доменном подходе, показаны на рис. 1.2 и 1.3. На верхнем уровне выделяются 2 типа доменов: домены задач (Problem domains) (рис. 1.2) и домены решений (Solution Domains) (рис. 1.3).  Рис. 1.2. Классификация архитектур ИС, основанная на домене задач Можно выделить следующие основные характеристики домена задач: характер решаемых задач тип домена предметная область степень автоматизации масштаб системы. По характеру обработки данных ИС делятся на: системы, ориентированные на решение крупномасштабных задач преимущественно вычислительного характера, информационно-справочные и информационно-поисковые ИС, в которых нет сложных алгоритмов обработки данных, а целью системы является поиск и выдача информации в удобном виде; автоматизированные системы управления и системы поддержки принятия решений; коммуникационные системы; ИС, ориентированные на предоставление услуг (сервисов), таких как доступ в Интернет, сервисы хранения данных, доступа к вычислительным ресурсам, доступа к данным и т.п.  Рис. 1.3. Классификация архитектур ИС, основанная на домене решений По принадлежности к базовому домену. Можно выделить следующие базовые домены задач [15]: информационно-управляющие системы (ИУС) – Management Information Systems, управляющие системы (УС) – Process Control Systems, системы мониторинга и управления ресурсами (СМУР) – Resource Allocation and Tracking Systems, системы управления производством (СУП) – Manufacturing Systems, системы управления доступом (СУД) – Access Control Systems. По принадлежности к предметной области. Обычно ИС ориентированы на использование и удовлетворение информационных потребностей в рамках конкретной предметной области. В настоящее время ИС используются практически повсеместно, то перечислить все области, в которых используются ИС просто невозможно. В качестве примера можно указать следующие области, в которых ИС активно используются: системы управления организацией — ИС, предназначенная для выполнения функций управления на организацией (предприятием); телекоммуникационные системы – ИС, предназначенные для реализации функций, связанных передачей данных; геоинформационные системы — ИС, обеспечивающие сбор, хранение, обработку, доступ, отображение и распространение пространственно-координированных данных (пространственных данных); торговые ИС; встроенные системы управления сложными объектами, такими как самолеты и корабли; медицинская информационная система — ИС, предназначенные для использования в больницах, поликлиниках и др. лечебных учреждениях. Автоматизированные ИС предполагают участие человека в ее функционировании. Автоматические ИС функционируют без участия оператора. По масштабности применения ИС делятся на: персональные ИС, предназначеные для использованием одним человеком; ИС, предназначенные для совместного использования группой людей, например, сотрудниками одного подразделения. корпоративные ИС, охватывающие информационные процессы отдельной организации; глобальные ИС, охватывающие информационные процессы многих организаций, или находятся в свободном доступе. По степени автоматизации ИС делятся на автоматические и автоматизированные. Основными характеристиками домена решений являются программная и техническая архитектуры. Применительно к уровню программной архитектуры выделим следующие характеристики: используемый архитектурный стиль; способ реализации. Существует пять групп архитектурных стилей: потоки данных; вызов с возвратом; независимые компоненты; централизованные данные; виртуальные машины. Более подробно архитектурные стили будут рассмотрены ниже. Реализация программной архитектуры может быть осуществлена двумя альтернативными подходами: монолитное приложение; многомодульное приложение. Основными характеристиками многомодульных приложений являются: подход к реализации моделей; способа интеграции компонентов в систему. Основные подходы к реализации модулей: представление модуля как объекта; представление модуля как компонента; реализация модуля в виде веб-службы; реализация модуля в виде грид-службы; реализация модуля в виде облачного сервиса; реализация модуля в виде агента. Основные подходы к интеграции модулей: вызов удаленных процедур (методов); очереди сообщений; бизнес-процессы; межагентные коммуникации; разделяемые базы данных; разделяемые файлы. Применительно к уровню технической архитектуры ИС можно разделить на следующие группы: системы, реализованные на локальном хосте; системы реализованные на нескольких хостах; системы, реализованные в виде виртуального сетевого ресурса. |