Московский международный институт эконометрики, информатики, финансов и права Уринцов А. И.

Методология построения многоуровневых экономических информационных систем Москва 2003 УДК 004 ББК 32.973.202 У 697 Уринцов А.И. Методология построения многоуровневых экономических информационных систем (учебное пособие). - М.: Московский международный институт эконометрики, информатики, финансов и права, 2003. - 57 с. Рекомендовано Учебно-методическим объединением по образованию в области антикризисного управления в качестве учебного пособия для студентов высших учебных заведений, обучающихся по специальности 351000 Антикризисное управление и другим экономическим специальностям.

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

Уринцов А.И., 2003 г. Московский международный институт эконометрики, информатики, финансов и права, 2003 г.

СОДЕРЖАНИЕ Предисловие.............................................................................................. 4 Глава I. Особенности построения многоуровневых экономических информационных систем на основе структурной и объектно-ориентированной декомпозиции................................................................................. 6 Глава II. Логическая трехуровневая архитектура многоуровневой экономической информационной системы................................................ 18 Глава III. Физическая архитектура многоуровневой экономической информационной системы................................................ 30 Глава IV. Реализация многоуровневой экономической информационной системы с использованием CORBA и Java & Intranet............... 41 Вопросы для самопроверки.................................................................... 55 Список литературы................................................................................. 57 Список Internet - адресов........................................................................ Предисловие Переход России к цивилизованным рыночным отношениям характеризуется переменами, протекающими как на макроэкономическом уровне - в отраслях экономики в целом, так и на микроэкономическом уровне - на предприятиях, организациях и в учреждениях. Результатом вышесказанного является появление принципиально новых экономических объектов и понятий, изменение номенклатуры, предоставляемых хозяйствующими субъектами работ и услуг. В этих условиях радикальные изменения претерпевают и компьютерные информационные системы. Стремительный рост и дифференциация спроса на все виды информации, в том числе научную, техническую и, в большей степени, экономическую, а также повышение требований к её содержанию и формам представления, является главенствующим стимулом развития информационных систем. Благодаря научно-техническому прогрессу, появляются новые технические и программные решения, возникают новые подходы, связанные с проектированием и использованием многоуровневых экономических информационных систем (ЭИС) как средства принятия и исполнения управленческих решений, что является необходимым и достаточным условием выживаемости и рентабельности предприятия в условиях конкурентной борьбы за существование. Процессы формирования многоуровневой ЭИС предполагают создание единого аппаратно-программного комплекса, являющегося неким инструментарием для эффективного управления организационными, финансовыми, кадровыми, производственными и др. ресурсами хозяйствующего субъекта. При этом, многоуровневая ЭИС охватывает совокупность организационно-экономических задач не фрагментарно (дискретно), а комплексно, отражая всю сложность их взаимосвязей. Это не набор разрозненных хорошо автоматизированных решений, а такая их совокупность, которой присущи такие свойства сложной системы как множественность функциональных целей;

сложность иерархической структуры;

эмерджентность;

динамичность в работе при обеспечении управления процессами, носящими стохастический (вероятностный) характер;

многофункциональность. Поэтому создание многоуровневой ЭИС, являясь сложной задачей, требующей адекватных методов и средств решения, предполагает выполнение всестороннего анализа факторов, оказывающих влияние как на её структуру, так и на содержание будущей информационной системы. Данное учебное пособие рассматривает вопросы разработки, теоретического обоснования и практической реализации концепции использования современной многоуровневой экономической информационной системы, в процессе реструктуризации крупных и корпоративных хозяй ствующих субъектов. Работа посвящена методологическим вопросам построения многоуровневых экономических информационных систем. Такая ЭИС будет характеризоваться совокупностью пользовательских мест для автоматизированного ведения всех технологических операций (в том числе и территориально распределенных), на основе синтеза функциональных информационных технологий, объединенных по принципу завершенности и призванных обеспечить ускорение поддержки формирования и принятия решений специалистов всех уровней управления (как руководителей, так и исполнителей) непосредственно на их рабочих местах. Комплексное автоматизированное ведение технологических операций позволит освободить пользователей от рутинной работы и предоставит последним в награду самый важный капитал - время, которое можно с большей пользой употребить для творческой, интеллектуальной работы. Учебное пособие ориентировано на получение студентами знаний по организации многоуровневых иерархических экономических информационных систем на основе применения распределенных структурных (функциональных) и объектно-ориентированных информационных технологий. Курс опирается на научный метод - Усистемный подходФ и рассматривает МРИС, с одной стороны как сложную систему, обеспечивающую решение задач, поставленных перед участниками процесса управления предприятием, а с другой, - МРИС, как совокупность объектных, функциональных и обеспечивающих информационных технологий. В процессе изучения пособия у студентов формируются теоретические знания об организации МРИС на основе трехуровневой логической архитектуры с использованием методологий Уклиент-серверФ, архитектур доступа к удаленным данным, структурных (функциональных) и объектно-ориентированных методологий построения многоуровневых информационных систем;

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

Глава I. Особенности построения многоуровневых экономических информационных систем на основе структурной и объектноориентированной декомпозиции. Информационные системы экономического характера (ЭИС) призванные осуществлять процессы поддержки принятия и исполнения решений на всех уровнях управления хозяйственным субъектом и ориентированные на одновременное использование несколькими пользователями в литературе получили название многоуровневые ЭИС. Данные системы весьма разнообразны по охвату реализуемых функций, особенностям представления исходных и результатных данных, способам построения и привязки к специфике конкретных предприятий, количественному составу предоставляемых услуг, техническому, программному, лингвистическому методическому обеспечению. Построение многоуровневых ЭИС характеризуется наличием двух основных подходов. Первый подход называют функциональномодульным или структурным, второй - объектно-ориентированным (рис. 1). В основу структурного подхода проектирования ЭИС положен принцип функциональной декомпозиции, в соответствии с которым производится разделение функций системы на модули по функциональной принадлежности, где каждый модуль выполняет определенную последовательность действий в общем процессе. Рассматриваемая ЭИС делится на подсистемы, подсистемы на комплексы задач и т.п.

Подходы к проектированию Структурный подход Объектный подход потоки данных Шлеер/Меллора Йодан/ДеМарко Гейн/Сарсона информационное моделирование на моделях Джексона Чена Варнье/Орра OMT (Джим Рамбо) Booch (Гради Буч) Кодд/Йодан OOSE (Айвар Якобсон) UML (Д.Рамбо, Г.Буч, А.Якобсон) IDEF IDEF0 (метод функционального моделирования, основа - SADT, метод Росса) IDEF1 (метод информационного моделирования, основа ER-модели, модели Чена) IDEF1 X (расширение методологии IDEF1 релиционными моделями Кодда) IDEF2 (динамическая модель, основа - сети Петри) Рис. 1. Подходы к проектированию многоуровневых ЭИС Традиционный функционально-модульный подход предусматривает строго последовательный порядок действий и характеризуется лавинообразным нарастанием сложности, что, несомненно, может являться отрицательным фактором при разработке многоуровневой ЭИС, поскольку рассматриваемые и анализируемые информационные потоки имеют тенденцию поступательного движения - УтеченияФ только в одну сторону. Если проблема оказывается "внизу по течению", то часто возникает сильное организационное и методическое противостояние с целью проводить лишь ограниченные исправления и обеспечить решение проблемы без воздействия на предыдущие стадии проекта. Такая обратная связь приводит к подготовке проекта недостаточно высокого качества, а дальнейшее внесение исправлений в проект приводит к существенным отклонениям при реализации. Изменение требований к системе может привести к ее полному перепроектированию, поэтому ошибки, за ложенные на ранних этапах, ощутимо сказываются на времени и конечной цене разработки. При разработке многоуровневых ЭИС большой сложности ориентация на данный подход увеличивает вероятность того, что будет утрачен контроль над решением возникающих проблем, что в конечном итоге как правило приводит к банкротству разрабатываемой ЭИС. Среди методологий, ориентированных на функциональномодульный подход, наиболее распространены следующие: IDEF;

методологии, ориентированные на потоки данных: (Гейн/Сарсон, Йодан);

методологии информационного моделирования, основанные на моделях Джексона, Чена и Варнье/Орра. IDEF (ICAM DEFininition) была разработана в середине 70-х годов в рамках программы ICAM (Integrated Computer Aided Manufacturing) для военно-космических сил США, а затем была принята как стандарт Министерства обороны США. Она представляет собой семейство независимых, но дополняющих друг друга методологий, основанных на графическом представлении информации и включающая механизмы построения логических и семантических моделей данных, состоящих из методологий: IDEF0 - метод функционального моделирования, в основе которого лежит методология структурного анализа и проектирования (SADT) (Structured Analysis and Design Technique) предложенная Дугласом Россом в 1973 году;

IDEF1 - метод информационного моделирования, основанный на ER (Entity-Relationship) - моделях Чена;

IDEF1X - расширение IDEF1 на основе дополнения методологиями Т.Кодда, П.Чена;

IDEF2 - метод создания динамической модели системы, основанный на цветных сетях Петри (CPN - Colored Petri Nets). Модель многоуровневой ЭИС на основе SADT основывается либо на функциях (активностная модель), либо на сущностях предметной области (модель данных). Для полного описания сложной системы необходимо построить множество активностных моделей и моделей данных. Наиболее часто используются активностные модели. Результатом анализа является диаграмма, которая состоит из элементов двух типов: блоки, изображающие активности ЭИС;

дуги, связывающие блоки и обозначающие взаимосвязи между ними. Допускаются обратные входные и управленческие связи;

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

Основным достоинством SADT является простота и удобство в использовании. В основе IDEF0 лежит принцип декомпозиции процессов и данных. Функциональная модель отражает архитектуру многоуровневой ЭИС на основе взаимосвязанных модулей и состоит из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели. Диаграммы состоят из блоков и дуг. Блоки представляют действие, дуги - объекты, обрабатываемые системой. Место соединения дуги с блоком определяет тип интерфейса. Управляющие функцией данные входят в блок сверху, в то время как материалы или информация, которая подвергается операции функции, показаны с левой стороны блока;

результаты выхода - с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию представляется стрелками, входящими в блок снизу. Метод IDEF0 характеризуется постепенным введением всё больших уровней детализации по мере создания диаграмм, отображающих модель. Таким образом обеспечивается представление информации, и пользователь располагает хорошо очерченным предметом изучения с приемлемым объемом новой информации на каждой следующей диаграмме. Модель проектируемой ЭИС начинается с представления всей системы в виде простейшей компоненты - блока и дуг, изображающих интерфейсы с функциями вне системы. Затем данный блок представляющий многоуровневую ЭИС в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют собой основные подфункции (подмодули) единого исходного модуля. Данная декомпозиция выявляет полный набор подмодулей, каждый из которых представлен как блок, границы которого определены интерфейсными дугами. Каждый из этих подмодулей декомпозирован подобным образом для более детального рассмотрения. Таким образом рассматриваются все аспекты функционирования ЭИС. Функциональные блоки должны располагаться на диаграмме в строгой последовательности, что ограничивает разработчика при анализе ЭИС и приводит к загромождению диаграммы (приходится использовать многочисленные и иногда лишние обратные связи). В методе Росса алгоритмическая декомпозиция проявляется при разбиении функций ЭИС (функциональных блоков) на составные части. Следовательно, ему присущи те же недостатки, что и для всех функциональноЦмодульных методов. В частности, для достаточно крупных систем с большим количеством функциональных блоков (которые играют роль либо модулей, либо функций) и обратных связей диаграмма становится чрезвычайно громоздкой и нечитабельной. Незначительные изменения функциональных характеристик многоуровневой ЭИС приведут к модификации диа грамм на верхних уровнях, что лавинообразно повлечет за собой необходимость перестройки всех нижних уровней, то есть, практически, к проведению анализа заново. IDEF1X представляет расширенную версию методологии моделирования IDEF1, включающую IISS-подход, основанный на создании и использовании единого семантического определения данных как ресурса и получившего название УКонцептуальной схемыФ. Целью данного метода является выработка непротиворечивого интегрированного определения семантических характеристик данных. С помощью IDEF1X осуществляется концептуальное проектирование баз данных в форме одной модели или нескольких локальных моделей функционального взгляда, которые относительно легко могут быть отображены в любую систему управления базами данных. IDEF1X использует подход УсущностьсвязьФ (сущностей - отношений) к семантическому моделированию данных и представляет комбинацию реляционной теории Т.Кодда, методологии УEntity-RelationshipФ и диаграммы Усущности-отношенияФ П.Ченна. Для улучшения графического представления данных и процедур моделирования IDEF1X дополнена отношениями категоризации, называемыми также отношениями обобщения. Метод IDEF1X содержит набор правил и процедур для построения информационной модели. Моделирование IDEF1X представляет собой процесс, состоящий из ряда стадий, каждая из которых завершается подающимися оценке результатами, конкретными проектными материалами. Такой порядок моделирования в отличие от других подходов обеспечивает модульность как процесса, так и его результатов, что позволяет избежать некорректности, неполноты, противоречивости и неточности. Информационная модель содержит две основные компоненты: диаграммы, отображающие структурные характеристики модели, обеспечивая выразительное представление информации;

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

словари, содержащие смысловое значение каждого элемента модели, выраженное с помощью краткого текста, и обозначения (указателей), которые в совокупности точно определяют информацию, отображенную в модели. Результатом моделирования IDEF1X является структурно проработанная информационная модель. Она характеризуется взаимосвязью сущностей (объектов), отношениями (связями между объектами) и атрибутами (характеристиками объектов). В ней каждая сущность представляет не избыточную совокупность информации и каждая пара сущно стей, связанная отношением, выражает в модели некоторое не избыточное содержание. Каждая сущность в моделях полностью определена;

каждая сущность идентифицирована через её атрибуты, модель характеризуется простыми отношениями и каждая сущность проявляется в модели только один раз. Совокупность моделей функциональной и информационной обеспечения, как правило, обеспечивает реальное отображение процесса функционирования несложной ЭИС. В методологиях, ориентированных на потоки данных, центральное место занимают диаграммы потоков данных - ДПД (Data-Flow Diagrams - DFD). Метод потоков данных получил широкое распространение как в структурных методологиях (методология Гейна/Сарсона, основанная на ДПД и методология Йодана/ДеМарко, где ДПД занимает центральное место), так и в объектно-ориентированных (методология объектноориентированного анализа Шлеер/Меллора, где используется расширенный вариант ДПД, и методология OMT (Object Modeling Technique - метод объектного моделирования). Формально, потоковая диаграмма есть ориентированный граф, нагруженный по дугам и вершинам. ДПД описывает асинхронный процесс преобразования данных от их ввода в систему до выдачи потребителю. Внешние сущности - источники информации - порождают информационные потоки. Информационные потоки переносят данные к процессам. Процессы, в свою очередь, преобразуют данные и порождают новые информационные потоки, которые переносят данные к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Модель потоков данных строится при помощи небольшого набора логических абстракций - внешних сущностей, моделирующих источники и приемники данных;

процессов, преобразующих данные;

накопителей данных, хранящих данные;

информационных потоков, связывающих внешние сущности, процессы и накопители. Отдельно взятый процесс может быть представлен более детализированной диаграммой потоков данных. Подобная декомпозиция продолжается до тех пор, пока не будет достигнут такой уровень, при котором каждый процесс становится элементарным, непригодным для дальнейшей детализации. Следовательно, осуществляется обыкновенная алгоритмическая декомпозиция многоуровневой ЭИС на составные части. Использование модели потоков данных как центральной в анализе ЭИС непригодно для крупных ЭИС, поскольку при изменений требований или ошибках, совершенных при создании диаграмм верхнего уровня, но обнаруженных при рассмотрении нижнеуровневых диаграмм, приходится по инерции переделывать целые поддеревья со всеми их подуровнями в иерархии ДПД. Методологии информационного моделирования предназначены для проектирования схем баз данных и структур данных. Наиболее широкое распространение получил метод ER (Entity Relationship) Ч моделирования П. Чена и методологии, построенные на его основе (методологии, ориентированные на концептуальное моделирование). При проектировании сложных многоуровневых ЭИС целесообразно использовать объектно-ориентированный подход. Особенность данного подхода заключается в описании взаимодействующих объектов многоуровневой ЭИС. При этом, каждый объект ЭИС обладает собственным поведением, моделирующим поведение реального объекта. Многоуровневая ЭИС рассматривается, как совокупность объектов, взаимодействующих друг с другом путем посылки сообщений. Разделение ЭИС на слабосвязанные части позволяет разрабатывать их практически независимо друг от друга. Таким образом, изменение требований к системе затрагивает лишь некоторую её часть и совершенно не влияет на остальные, чего трудно добиться при традиционном функциональном проектировании. Применение объектно-ориентированной методологии создает большие удобства в планировании и управлении разработкой проекта ЭИС. К основным понятиям объектно-ориентированного подхода следует отнести объект, экземпляр объекта, класс. Объект - это такая абстракция множества предметов реального мира, что все предметы этого множества (экземпляры объекта) имеют одинаковые характеристики и правила поведения. Объект представляет собой типичный и неопределенный экземпляр некоторого множества предметов реального мира. Иногда вместо термина Фэкземпляр объектаФ употребляют слово ФобъектФ, и значение этого понятия можно понять из контекста. Класс - это множество объектов, связанных общностью структуры и поведения (например, класс расчетно-денежных документов). Таким образом, объект - это типичный представитель класса, а экземпляр объекта - конкретный элемент класса. С точки зрения анализа информационной модели понятия Уописание классаФ и Уописание объектаФ эквивалентны, так как для описания множества схожих элементов (т.е. класса) достаточно описать его типичный представитель (т.е. объект). Тем не менее в описанных в литературе методологиях понятия УклассФ, УобъектФ, Уэкземпляр объектаФ иногда смешиваются, и смысл того или иного понятия выявляется на основании анализа контекста. Объекту присущи три основные свойства: инкапсуляция;

наследование;

полиморфизм. Инкапсуляция - объединение идей абстрагирования данных и алгоритмов для работы с ними. Объекты наделяются некоторой структурой и обладают определенным набором операций (методов), т.е. поведением. Внутренняя структура объекта скрыта от пользователя;

манипуляция объектом, изменение его состояния возможны лишь посредством его методов. Таким образом, благодаря инкапсуляции объекты можно рассматривать как самостоятельные сущности, отделенные от внешнего мира. Для того чтобы объект произвел некоторое дей ствие, ему необходимо извне послать сообщение, которое инициирует выполнение нужного метода. Наследование - построение новых классов на основе существующих с наследованием данных и методов и с возможностью добавления новых. Полиморфизм - возможность единообразного обращения к объектам при сохранении уникальности поведения каждого из них. Различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, как реализованы у них методы, реагирующие на эти сообщения. Например, объект класса УлинияФ отреагирует на сообщение УнарисоватьФ рисованием линии, тогда как объект класса УокружностьФ - рисованием окружности. Применение объектно-ориентированной методологии охватывает все этапы жизненного цикла многоуровневой ЭИС. В настоящий момент, как правило, используются объектно-ориентированные методологии Шлеер/ Меллора, Рамбо (OMT - Object Modeling Technique), Буча, Кода/Йодана и Якобсона (OOSE). Методология ШлеерЦМеллора представляет собой методологию объектно-ориентрованного анализа предметной области, задачи проектирования в ней вынесены на вторичный план и характеризуются созданием независимой от языка нотации OODLE для дальнейшего объектноориентированного проектирования. Процесс анализа в данной методологии включает три самостоятельных этапа:

- информационное моделирование;

моделирование состояний;

моделирование процессов. Первый этап характеризуется диаграммой информационной структуры1;

описанием объектов и атрибутов;

описанием связей между объектами. В процессе выполнения второго этапа формируются диаграммы перехода состояний;

таблицы переходов в состояния;

список событий. Результирующими данными третьего этапа являются модель доступа к объектам;

диаграммы потоков данных;

таблица процессов состояний;

описание процессов. Методология OMT представляет собой методологию анализа и проектирования. В ней выделяют три основных этапа:

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

моделью поведения, включающей диаграммы перехода состояний (описание жизненных циклов объектов всех классов), диаграммы взаимодействия объектов (диаграмма потоков событий);

функциональной моделью, включающей диаграммы потоков данных2 и ограничения функциональной модели.

1 Здесь речь идет о графическом представлении информационной модели. Основана на нотации де Марко. Системное проектирование характеризуется разбиением системы на подсистемы;

проектированием архитектуры программной системы;

распределением множества подсистем на множество задач операционной системы;

выбором стратегии хранения данных в терминах структур данных, файлов и баз данных (проектирование схемы базы данных);

определением глобальных ресурсов и механизма управления доступом к ним. Объектное проектирование включает детальное описание классов, отношений между классами, событий, состояний, действий, данных, алгоритмов. Это описание используется на этапе кодирования ЭИС. Осуществляется комплектование программных модулей, содержащих реализации классов и отношений между ними. Методологии анализа Шлеер/Меллора и OMT имеют много общего. Авторы OMT отмечают её сходство с методологией Шлеер/Меллора. В обеих методологиях процесс анализа включает три самостоятельных этапа3:- информационное моделирование в методологии Шлеер/Меллора и модель объектов в OMT;

моделирование состояний в методологии Шлеер/Меллора и динамическая модель в OMT;

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

взаимодействие объектов и их параллельное функционирование;

выделение отдельных доменов4;

разбиение доменов на подсистемы5;

преобразование моделей объектно-ориентированного анализа в модели объектно-ориентированного проектирования;

создание независящей от языка нотации объектно-ориентированного проектирования. За последний десяток лет на свет появилось множество методологий проектирования и поддерживающих их программ. Несомненный интерес наблюдается в области развития методологий, обеспечивающих проведение объектно-ориентированного анализа. Наиболее ярким достоинством объектно-ориентированного анализа в процессе проектирования многоуровневой ЭИС является наличие единого подхода, распространяющегося на весь жизненный цикл программного обеспечения. Объектная декомпозиция ЭИС состоит из ряда хорошо продуманных этапов, что повышает уверенность в правильности принимаемых решений и сокращает степень риска. В противовес традиционному структурному подходу (поступательной разработке сверху вниз), для которого, В скобках приведены соответствующие названия для OMT. Домен - представляет собой реальную или абстрактную модель, составленную из множества разнообразных объектов. 5 Подсистема - группа взаимосвязанных объектов, имеющая слабые связи с другими объектами данного домена.

4 как отмечалось выше, характерно лавинообразное возрастание сложности, применение объектно-ориентированного подхода приводит к построению многоуровневой ЭИС на основе стабильных промежуточных форм. Это позволяет легко использовать метод возвратного проектирования и дает возможность постепенного развития ЭИС без полной ее переработки в случае существенных изменений исходных требований и обеспечивает создание более открытых для изменения систем. Объектная декомпозиция упрощает распараллеливание разработки, поскольку позволяет представить всю ЭИС в виде слабо связанных друг с другом объектов, обменивающихся сообщениями. Появление за последнее десятилетие множества программных продуктов, поддерживающих различные методологии проведения объектного анализа характеризовались тем, что используемые в них методологии разрабатывались разрозненно и не обеспечивали целостного описания предметной области как некого результата анализа. Одни из этих методологий акцентировали внимание на потоки данных, другие на структуру объектов или связи между ними. В стане объектно-ориентированных методологий анализа наблюдалась некоторая несогласованность. Обуславливалась она тем, что различные методы анализа акцентировали внимание на различных аспектах построения модели предметной области, в той или иной степени решали определенные вопросы, не давая полной и всесторонней картины анализа. Однако пользователи желали получить такой инструмент объектного моделирования, который бы отвечал их потребностям в той же мере, что и методология SADT в структурном анализе.

Так, середина 90-х ознаменовалась конкретными шагами в этом направлении при участии таких известных специалистов в области объектного анализа, как Гради Буч, Джим Рамбо и Айвар Якобсон. Втроем они возглавили разработку специального языка объектного моделирования UML (Unified Modeling Language) в фирме Rational Software6. Появление в свет первой версии этого языка 13 января 1997 года стало логическим продолжением развития методологий анализа и проектирования. За время своего существования язык UML стал стандартом де-факто. Интересно отметить, что в октябре 1996 года Rational Software и Microsoft подписали стратегическое соглашение, по которому Microsoft лицензировала некоторые технологии визуального моделирования и использовала их в Visual Modeller for Visual Basic. Со своей стороны Rational лицензировала Visual Basic и Microsoft Repository. UML представляет собой набор диаграмм, описывающих предметную область как в статике (объектные диаграммы), так и в динамике (диаграммы жизненных циклов объектов), а также описывает программную среду с помощью диаграмм модулей. С помощью этого языка достаточно просто переложить результаты анализа на конкретную реализа В то время Айвар Якобсон вместе со своей фирмой Objectory присоединился к первым двум. цию с помощью понятия модулей или компонент, которые достаточно часто прямо отражают домены предметной области. Распределенная ЭИС в моделях UML представляется в виде некой совокупности взаимосвязанных диаграмм, описывающих наиболее важные аспекты системы с точки зрения разработчика. Это дает возможность наиболее полно охватить систему, увидеть ее несовершенства, внести необходимые изменения, избежать многих ошибок на ранней стадии создания программного обеспечения. В UML используются все те же диаграммы, что и в других средствах анализа, однако собранные воедино, они дают возможность наиболее полно рассмотреть предметную область и подвергнуть ее более глубокому анализу. Так, из методологии OOSE Айвара Якобсона были взяты диаграммы прецедентов (Use Case Diagram) для анализа предметной области. Для создания иерархической структуры объектов в методе UML применяются диаграмм классов (Class Diagram). Они отображают взаимосвязи между объектами, классами системы, их атрибуты и поведение. По своей значимости диаграммы классов, пожалуй, являются наиболее весомыми в объектном анализе, так как от качества классификации объектов зависит жизнеспособность будущей системы. Диаграмма поведения системы (Interaction Diagram), диаграммы последовательности (Sequence Diagram) и взаимодействия (Collaboration Diagram) вместе дают трехмерную модель взаимодействия объектов системы относительно времени. С помощью диаграмм состояний (State Diagram) описывается структура переходов объектов из одного состояния в другое при возбуждении определенных событий. Также используются диаграммы активности (Activity Diagram), с помощью которых описывают алгоритмы выполнения определенных операций. Для того, чтобы описать и спроектировать архитектуру системы, а также обозначить процессы, которые будут выполняться на определенных узлах распределенной системы используются диаграммы размещения (Deployment Diagram). Для разбиения системы на отдельные компоненты, выявления возможности повторного использования уже существующих компонент используются диаграммы компонент (Component Diagram). Таким образом, объектно-ориентированная декомпозиция на базе UML поддерживает все стадии жизненного цикла проектов - от анализа требований к системе до проекта на конкретном языке программирования. Средства визуального проектирования, поддерживающие язык UML (такие как, например новое CASE средство Rational Rose) обеспечивают генерацию кода и обратное проектирование для множества языков программирования и описания интерфейсов (например PowerBuilder, CORBA IDL и др.), а также имеют поддержку моделей ERwin и языка описания данных DDL для большинства СУБД. Таким образом, достоинствам объектно-ориентированного подхода в построении многоуровневых ЭИС является максимальное задейство вание возможностей объектно-ориентированных языков программирования, что позволяет создавать программные продукты на основе повторного использования программного кода. Такие ЭИС получаются более компактными, по сравнению с традиционными эквивалентными системами, что позволяет говорить не только об уменьшении объемов исходного кода, но и об удешевлении проекта. Сложность применения объектно-ориентированного подхода полностью перекрывается преимуществами объектно-ориентированной методологии по сравнению с функциональным подходом. Объектно-ориентрованная методология представляет собой не революционный подход, а эволюционный, включающий все лучшее из существующих методологий, и создаваемые на основе данного подхода ЭИС будут обладать этими преимуществами. Завершая данный раздел, отметим, что в настоящее время существует большое разнообразие инструментальных средств проектирования ЭИС, реализующих как структурный, так и объектно-ориентированный подходы - так называемых CASE - средств.

Глава II. Логическая трехуровневая архитектура многоуровневой экономической информационной системы. В процессе создания многоуровневой ЭИС выделяют логическое и физическое проектирование. Физическое проектирование рассматривает механизмы построения многоуровневых ЭИС, организацию аппаратного обеспечения и связано с рассмотрением процессов распределенного обмена между узлами сети и внутри узла, в том числе: где хранить информацию (данные), где её обрабатывать, какие данные и куда следует передавать. Решение этих задач включает реализацию методик распределения вычислительных работ по уровням обработки информации и узлам сети;

распределения данных информационных массивов по узлам сети;

определения количества компьютеров в узле. Для решения перечисленных задач могут быть использованы экономико-математические методы и модели, а также специальный инструментарий класса CASE. Логическое проектирование рассматривает структуру многоуровневой ЭИС вне зависимости от типа и месторасположения оборудования, аппаратных и программных платформ, в рамках которых функционирует система. Таким образом осуществляется декомпозиция системы на модули и подсистемы. Логическая архитектура многоуровневой ЭИС характеризуется наличием трех уровней, которые в литературе получили названия УдокументыФ, Убизнес-правилаФ и Ухранилище данныхФ (см. рис. 2.). Трехуровневая (трехзвенная) логическая архитектура проектирования многоуровневой ЭИС позволяет обеспечить правильную организацию разработки системы. Итак, основное назначение логической архитектуры заключается в описании функций каждой конкретной подсистемы многоуровневой ЭИС, способов и механизмов взаимодействия этих подсистем для каждого из трех уровней, без привязки к выбору и размещению физического оборудования (устройств). Физическая архитектура рассматривает вопросы выбора и размещения конкретных аппаратных и программных средств, необходимых для обслуживания пользователей. Следует отметить, что только грамотно выполненное логическое проектирование позволяет правильно реализовать механизмы автоматизированной обработки для создания многоуровневой ЭИС. Без него построение системы практически невозможно, как бы идеально не было бы размещено оборудование и какое бы совершенное программное обеспечение не использовалось. Логическая архитектура многоуровневой ЭИС всегда первична. Отражая декомпозицию задач, решаемых системой, она позволяет продумывать структуру необходимых элементов будущего проекта, при этом предоставляя богатый выбор в вопросах физического построения, т.е. оставляя большинство окончательных решений открытыми. Логический проект указывает на потребность пользователей многоуровневой ЭИС. Физический проект переводит логический проект в его точный план с четко определенными параметрами многоуровневой ЭИС. Логическое проектирование многоуровневой ЭИС является сложной задачей и требует адекватных методов решения. Для того чтобы процессы проектирования системы были управляемы и не вышли из-под контроля используют два механизма управления сложностью многоуровневой ЭИС:

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

Приложения рабочего стола Логический уровень Физический уровень Предворительная обработка, сбор данных.

Описание GUI Уровень ДОКУМЕНТЫ Объекты приложения, независимые от правил.

Правила бизнеса и вычислительные процессы Логический уровень Физический уровень Алгоритмы решения, независимые от данных.

Правила (Бизнес-логика) Уровень БИЗНЕС-ПРАВИЛА Описание Принятие решений, проведение политики, координация ресурсов Управление данными Логический уровень Физический уровень Окончательная обработка, хранение.

Реляционный SQL, СУБД Уровень ХРАНИЛИЩЕ ДАННЫХ Описание Данные, независимые от решений Рис. 2. Уровни абстракции в архитектуре приложений.

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

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

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

присутствием внутри каждого уровня некоторых свойств, отражающих особенности функционирования данного уровня, скрытых, и недоступных для других уровней. То есть трехуровневая архитектура обеспечивает защиту каждого из уровней от конкретных деталей, содержащихся в нижележащем уровне. Например, уровень Убизнес-правилаФ защищен концептуально и механически от уровня Ухранилище данныхФ, где осуществляется управление базой данных. Наиболее детальным является уровень Ухранилище данныхФ, на более высоком уровне абстракции располагается уровень Убизнес правилаФ и, наконец, наивысший уровень абстрагирования представляет собой уровень УдокументыФ, с которым в своей повседневной работе ежедневно соприкасаются пользователи ЭИС, даже не подозревая о наличии нижележащих уровней и сложностях в организации этих уровней. Таким образом, несомненным достоинством абстрагирования является то, что конкретный уровень логической архитектуры ограничен в детализации информации об особенностях функционирования других уровней многоуровневой ЭИС. Проектирование каждого уровня логической архитектуры характеризуется тем, что разработчик может не располагать знаниями о деталях нижележащего уровня. Это существенно упрощает проектирование и разработку модулей. Кроме того, разработчик одного уровня физически не имеет возможности контролировать нижележащий уровень, опираясь на собственные знания об особенностях организации и составе данных многоуровневой ЭИС. Логическую архитектуру многоуровневой ЭИС можно рассматривать с позиций микро- и макромира. Микромир трехуровневой архитектуры отражает конкретную подсистему. Любая подсистема включает три независимых уровня:

- хранилище данных, правила осуществления бизнеса (бизнес-правила), отражающие политику предприятия, проводимую в определенные временные периоды и интерфейс ЭИС с пользователем посредством экранных форм (документов). От того, насколько незави симы друг от друга будут данные уровни, зависит жизненный цикл подсистемы многоуровневой ЭИС, её гибкость, модульность и универсальность. С позиций макромира следует, что информация является основным ключевым ресурсом организации и каждый отдельный уровень трехуровневой архитектуры не зависит от конкретной подсистемы, а данные каждого из уровней сохраняют способность к использованию даже при изменении этой подсистемы. Каждый уровень многоуровневой ЭИС характеризуется множеством используемых несвязанных подсистем, но в целом трехуровневая архитектура четко отделяет Убизнес правилаФ от УдокументовФ и Ухранилище данныхФ. Рассматривая трехуровневую архитектуру целесообразно акцентировать внимание на интеграции логического и физического проектирования (см. рис. 3). Верхний уровень логической архитектуры многоуровневой ЭИС, называемый УдокументыФ7, отражает интерфейс взаимодействия между пользователем и конкретным АРМ, функционирующим в рамках этой ЭИС. Физически, примером организации данного уровня является оконная технология, предложенная фирмой Microsoft в начале 1990-х годов, получившая мировую известность и ставшая чрезвычайно популярной. Интеграция компонентов данного уровня осуществляется на основе использования технологии OLE (Object Linking and Embedding), что переводится как связывание и встраивание объектов.

Логическое проектирование Уровень Документы Экран.форма № Задача учет поставщиков Ввод имени заказчика:

Экран.форма № Заказчик: Петров Петров Показать _ Дата: 01/05/99 Количество: 100 Сумма: 2300.....

Физическое проектирование Документы рабочего стола Приложения рабочего стола Бизнес правила (Менеджер бизнес-процессов) Бизнес-логика Уровень Бизнесправила Опер.1. Бизнес-процесс №2 Опер.1.1:... Опер.1.2:... Бизнес-процесс №3 Опер.1.1:... Опер.1.2:...

Бизнес-процесс №4 Опер.1.1:... Опер.1.2:... Бизнес-процесс №5 Опер.1.1:... Опер.1.2:...

Бизнес-процесс № Опер.1.1: Запрос к БД Опер.1.2: Отправка полученных данных на рабочий стол Уровень Хранилище данных Опер.1. БД База Данных БД Файл Файл Файл Таб Таб Таб Таб Таб Рис. 3. Пример организации трехуровневой (трехзвенной) архитектуры.

В литературе также встречается название данного уровня как Уприложения предметной областиФ. Под термином интеграция компонентов следует понимать такое использование нескольких одновременно выполняющихся в пределах данного уровня независимых компонентов (для данного уровня это программные решения рабочего пространства8), которое создает иллюзию выполнения одного единого крупного компонента в контексте всего уровня. Навигация, контроль, поиск, активизация и завершение компонентов информационной системы на данном уровне происходит с использованием окон. Даже если подсистема не выполняется в момент вызова (обращения), оконная среда, при необходимости, обеспечит ее автоматический запуск. Действующими объектами данного уровня являются документы. Технология OLE является в настоящий момент стандартом архитектурной организации составного документа9. В настоящий момент OLE является наиболее удобным инструментарием разработки и планирования электронных страниц, обеспечивая удобный и простой интерфейс комбинирования динамической и статической информации. Популярность OLE объясняется ее тесной связью непосредственно с Windows, а также с подсистемами функционирующими под управлением Windows. Основным преимуществом технологии OLE является принцип связывания, обеспечивающий установление связи или ссылки на содержимое объекта и позволяющий предоставлять динамично поступающую информацию заинтересованным лицам, вместо того, чтобы копировать полностью выбранный объект в документ, как это делалось ранее при встраивании10 объектов в составной документ. При открытии документа система обработки текстов через OLE автоматически проверяет, изменились ли какие-либо связанные объекты, содержащиеся в документе, предоставляя пользователю возможность активизации измененной версии. Еще одним достоинством OLE является удобство использования мультимедийных подсистем в АРМ, УоживляющихФ экранный интерфейс. Нижним уровнем трехуровневой архитектуры является Ухранилище данныхФ Активными компонентами на физическом уровне являются файлы базы данных (БД)11. Этот уровень обеспечивает доступ к данным в процессе обработки запросов и осуществляет управление изменениями данных (транзакциями12), гарантируя их согласованность.

Здесь подразумевается пространство рабочего стола (DeskTop). Под термином составной документ следует понимать электронный документ, состоящий из нескольких потенциально разных частей, например, диаграмм, фрагментов видеофильма, таблиц со сложными формулами расчетов, фотографиями, рисунками, схемами, цифровой и текстовой информацией, созданных с использованием различных инструментальных средств. 10 Под термином встраивание объектов следует понимать их буквальное включение в документ и сохранение объекта в нем. 11 В литературе данный уровень также носит название системного или системозависимого уровня. 12 Транзакция - выполнение элементарной целостной операции над данными в базе данных, например, удаление или модификация записи.

Согласованность базы данных является самой важной функцией данного уровня. Она обеспечивает исключение дублирования расчетов. Согласованная база данных гарантирует, что все пользователи получат одинаковые результаты, когда будут решать одну и ту же определенную проблему. Как правило, многоуровневые ЭИС организуются на основе распределенной обработки информации, располагаются в различных базах данных, представляющих собой набор взаимодействующих компонентов. Многие из этих компонентов принимают форму ячеек-контейнеров для хранения физических таблиц, состоящих из физических записей и содержащих фактические данные пользователей. Разделение базы данных на компоненты предоставляют пользователям право выбора инструментария для хранения данных. Для обеспечения удобства получения информации по запросам используется другой вид ячейки-контейнера (получивший название логического массива), строящийся с использованием логических записей, т.е. набора, сформированного на основе выборки полей-данных из ячеек-контейнеров, содержащих физические записи. Прототипом массива логических записей является процессор запросов, который обеспечивает контроль за базой данных в целом. Совокупность физических и логических ячеек-контейнеров записей образуют среду базы данных, характеризуемую набором различных БД с файлами данных или таблицами. Процессор запросов является независимым самостоятельным компонентом данного уровня и осуществляет выборку из среды базы данных на основе поиска в ячейках записи, удовлетворяющей запросу, выборке записи и её компоновке с другими записями. Именно процессор запросов на данном уровне выполняет функции навигации, контроля и интеграции, обеспечивая более качественное нахождение данных. Эффективность функционирования процессора запросов на данном уровне рассмотрим на примере использования БД OLE. Интерфейс БД OLE был разработан весной 1995 года фирмой Microsoft, и является удобным инструментарием для создания множества взаимосвязанных компонентов БД. БД OLE представляет собой набор интерфейсов описывающих взаимодействие произвольных компонент, каждая из которых работает с таблицами данных и наборами записей. Любые два взаимодействующих компонента называются поставщиками табличных данных - Tabular Data Providers (TDP). БД OLE может функционировать с сетевыми и иерархическими базами данных, используемыми в крупномасштабных системах, реляционными БД, применяемыми для организации многоуровневых ЭИС, распределенными системами, построенными на основе технологии клиентсервер, в которых на каждом сервере функционирует своя реляционная база данных, а также с относительно новым, не так давно появившимся классом баз данных:

- объектно-ориентированными базами данных OODB (Object Oriented Database), которым эксперты в области систем управления базами данных13 пророчат большое будущее. Компоненты TDP могут быть полной реляционной базой данных, использующей язык структурированных запросов Structured Query Language (SQL) или более простыми, например, электронной таблицей, системой обработки текста или настольной СУБД (как, например, Microsoft Access), в которых TDP манипулируют простыми множествами записей. БД OLE является стандартом, разработанным для того, чтобы располагаться между предварительно определенными внутренними компонентами базы данных, обеспечивая их взаимодействие, на основе использования процессора запросов, который позволяет формировать запросы на SQL для выборки данных из электронной таблицы, при том, что сама электронная таблица не является базой данных и Уне понимаетФ язык SQL. БД OLE позволяет множеству ячеек-контейнеров предоставлять свои записи процессору запросов, чтобы он мог осуществлять поиск нужной записи и работать с ними. Управление процессором запросов осуществляется репозиторием14, который содержит информацию о всех таблицах во всех ячейках-контейнерах многоуровневой ЭИС т.е., описание всех таблиц в базе данных, их индексов и т.д. При этом, каждый сервер обладает, как минимум, одним процессором запросов, который взаимодействует с другими ему подобными, обмениваясь записями. Характерной особенностью данного уровня является функция координации транзакций, которая обеспечивает обновление данных в нескольких базах данных и ячейках-контейнерах записей одновременно. Одной из основных задач данного уровня является поддержка распределенных транзакций, т.е. возможности одновременного изменения локальных и удаленных данных и рассмотрение этих данных как единой части одной и той же транзакции. Для координации распределенной по нескольким базам данных транзакции, которые могут быть расположены на значительном территориальном удалении друг от друга, используют протокол, получивший в литературе название двухфазная фиксация (Two-phase commit), который позволяет любому количеству баз данных скоординироваться так, чтобы транзакция, распределенная по различным местам, могла корректно отработать. Если совместный запрос завершен и обработка прошла успешно, то протокол двухфазной фиксации обеспечивает выполнение дальнейших действий, в противном случае протокол обеспечивает Специалисты по СУБД считают, что объектно-ориентированные базы данных сегодня являются тем, чем реляционные БД были десять лет тому назад, когда они вытеснили сетевые БД. Объектноориентированные базы данных предоставляют возможность создания чрезвычайно сложных наборов связей между большими совокупностями записей, что увеличивает быстродействие и простоту их использования. Производительность таких баз в сравнении с реляционными базами данных значительно выше. 14 В литературе его также называют глобальным каталогом базы данных или глобальным словарем данных. возврат всех баз данных в состояние, в котором они находились на момент запуска этой транзакции. Протокол двухфазной фиксации является протоколом реального времени, обеспечивая координацию частей распределенной транзакции по многим базам данных. Функционирующая в режиме реального времени распределенная многоуровневой ЭИС (МРИС) подразумевает наличие постоянного доступа ко всем её частям, вовлеченным в распределенную транзакцию и поддерживаемых протоколом двухфазной фиксации. Если какая-либо часть вычислительной сети даёт сбой то система останавливается. До недавнего времени, основной проблемой являлось то, что разработчики программного обеспечения для создания МРИС, такие как Oracle, IBM, Tandem, DEC и др., ориентировались на использование и координацию транзакции только для собственных баз данных и не поддерживали программные продукты конкурентов. Для решения данной проблемы в 1990 г., в рамках программы X/Open, был разработан стандарт ХА. В рамках данного стандарта был использован структурный компонент, получивший название менеджер транзакций или координатор транзакций, который позволяет обеспечить управление транзакциями для различных форматов баз данных на основе поддержки использования двухфазной фиксации. Для управления последовательностями транзакций и запросов в распределенной системе используется монитор транзакций15. Индивидуальные запросы обрабатываются средой поддержки компонентов. Индивидуальные транзакции обрабатываются БД. Если транзакции распределяются на несколько серверов или несколько хранилищ, то транзакции управляются координатором транзакций так, чтобы обеспечить одновременное изменение данных во всех информационных хранилищах МРИС, либо ни в одном из них. Аналогичным образом происходит обработка запросов. Когда дело доходит до последовательности транзакций и запросов, активизируется монитор транзакций. При этом запросы нетранзакционных действий обрабатываются средой поддержки компонентов;

транзакционные действия обрабатываются БД. Монитор транзакций позволяет организовать более эффективную обработку распределенных запросов. Все пользовательские запросы соединяются с координатором транзакций, а он являясь своеобразным буфером между сервером базы данных и пользовательскими подсистемами16, обеспечивает управление обращениями к серверу БД, в отличие от ситуации, когда подсистемы МРИС напрямую формируют запрос на обработку к серверу базы данных, и тем самым загружают сервер БД17.

15 В литературе он также называется сервер транзакций. т.к. он единственный обеспечивает коммутацию (connect) с сервером БД 17 т.к. сколько запросов - столько и обращений (connect) к серверу БД Для управления запросами на низком уровне используется удаленный вызов процедуры - Remote Procedure Call (RPC)18, основной задачей которого является перехват запросов и превращение их в сообщения. Удаленный вызов процедуры предоставляет выполняемому компоненту (программе) требуемую информацию, связывая обратившейся к нему компонент с подпрограммой, которая запускается на другом компьютере в другом адресном пространстве. RPC - механизм обеспечивает перехват вызовов от программы и превращение их в сообщения, после чего происходит пересылка сообщения в компьютер, в котором на самом деле находится подпрограмма и производится запуск данной подпрограммы на этом компьютере. Результат выполнения данной подпрограммы затем перехватывается, преобразуется в сообщение и отправляется обратно. Процесс перехвата полностью невидим как для вызывающей, так и для вызванной программы. В результате получается распределенная (distributed) работающая программа, в которой невозможно отделить удаленный вызов процедуры от локального, они как бы являются единым целым. Один и тот же процедурный вызов в зависимости от потребностей в одном случае может быть локальным, а в другом удаленным. Использование стратегии RPC избавляет разработчиков программного обеспечения от программирования на уровне среды поддержки компонентов т.е. использования сетевых программных интерфейсов операционных систем, позволяя осуществлять необходимые действия в слое RPC. Наиболее яркими представителями монитора транзакций, обеспечивающих единообразие множества используемых баз данных в настоящий момент являются такие программные продукты как Tuxedo, Top End, Encina, CICS и др. Данные системы позволяют осуществлять обработку последовательности транзакций и содержат мониторы транзакций. Среди мониторов транзакций лидерство по числу установок и объемам продаж в настоящий момент принадлежит Tuxedo фирмы BEA Systems, который обеспечивает поддержку распределенных транзакций, прозрачное взаимодействие программ в разнородной (гетерогенной) вычислительной сети, обмен сообщениями с гарантированной доставкой, программный интерфейс DCE RPC19, что избавляет разработчика ПО от необходимости обязательного знания и использования многочисленных сетевых и системных программных интерфейсов, например, операционной системы Unix. Главной задачей любой подсистемы МРИС является обеспечение выполнения бизнес правил, т.е., тех тысяч правил и законов, которые определяют нормальную деятельность хозяйственного субъекта. В связи с этим возникает проблема реинжиниринга бизнес-процессов, проте18 Встречается также название RPC механизм Распределенная среда вычислений удаленного вызова процедуры, разновидность RPC. кающих на предприятии и характеризующих экономическую систему хозяйствующего субъекта. Он подразумевает изменение существующей логики связей различных компонент многоуровневой ЭИС и объединение разрозненных бизнес-процессов. В настоящий момент времени значительное количество программных решений характеризуется тем, что их выполняемый модуль включает в себя как коды пользовательского интерфейса и автоматизируемых бизнес-процессов, так и команды доступа к базе данных. Ввод данных, обработка и вывод результатов обработки этих данных производится только на компьютере пользователя. Это так называемая двухуровневая архитектура построения приложений. Какими бы универсальными не были программные продукты, разработанные для двухуровневой архитектуры, они обеспечивают автоматизированные решения только дискретных задач и не позволяют полностью автоматизировать бизнеспроцессы, протекающие в фирме. В таких программных продуктах жестко заложены модели бизнес-процессов, от которых напрямую зависят структуры баз данных. В результате при изменении бизнес-процесса в реальном мире, его модель - программный код, приходится перепрограммировать, а из-за жесткой связи модели с кодом доступа к базе данных изменять и этот код. Наряду с этим также необходимо менять и код пользовательского интерфейса. Выходом из этой ситуации сегодня служит разделение приложения на три слабосвязанных уровня, центральным из которых является уровень Убизнес-правилаФ, реализующий функции данного приложения и отражающий его бизнес-процессы, а другими - уровень УдокументыФ, отражающий средства управления этими процессами и Ухранилище данныхФ показывающий уровень доступа к базе данных. Последний из них подразумевает не только серверы конкретных баз данных, но и прослойку информационной архитектуры, которая служит фундаментом для программной модели бизнес процессов. Все эти уровни в силу своей слабой связи друг с другом можно изменять или настраивать без влияния на остальные, тем самым резко сокращая затраты на поддержку существующей МРИС. В настоящее время популярность трехуровневой архитектуры стремительно возрастает, однако говорить о вымирании двухуровневой архитектуры преждевременно. Еще существует значительное количество приложений, для которых двухуровневая архитектура идеально подходит. При создании небольших проектов, двухуровневая архитектура является более простой и дешевой, по сравнению с трехуровневой. Однако с ростом сложности приложений и увеличением их жизненного цикла, по мнению Gartner Grouр, одного из крупнейших в компьютерной индустрии поставщиков услуг по стратегическому планированию для специалистов в области информационных технологий, использование двухуровневой модели увеличивает сложность разработки приложений и стоимость эксплуатации системы по экспоненте (рис. 4). Все бизнес-процессы, протекающие на предприятии, строятся на основе этих бизнес-правил. Автоматизированная обработка и поддержка управления бизнес-процессами, растянутыми во времени, рассмотрение этих процессов в виде набора бизнес- правил позволяет выделять и обрабатывать наиболее трудоемкие и рутинные из них, высвобождая время пользователей-специалистов и оставляя им наиболее ответственные и творческие моменты в процессе принятия решений. Для манипуляции и управления данными в процессе принятия решений был выделен средний уровень, получивший, как отмечалось выше, название УбизнесправилаФ20. Данный уровень характеризуется программным обеспечением, ориентированным на специалистов предприятия, которые используют его по профилю своей деятельности. Элементами данного уровня являются компоненты, реализующие, как отдельные бизнес-правила, так и их совокупность. В дальнейшем эти компоненты будем называть бизнескомпонентами. Каждый компонент принимает запросы, выполняет работу по запросу и возвращает результат в требуемой форме. Интеграция на данном уровне означает обеспечение такого режима работы, при котором разрозненные бизнес компоненты представляли бы собой единый бизнес процесс. Для достижения этого необходима единая информационная и технологическая среда, которая позволила бы осуществлять координацию деятельности бизнес- компонент. Иными словами, уровень бизнес-правил должен функционировать в рамках единой обеспечивающей технологии.

Стоимость разработки и поддержки 2-х уровневая архитектура 3-х уровневая архитектура Сложность приложений и длина жизненного цикла Рис. 4. Стоимость 2-х и 3-х уровневых приложений В литературе данный уровень имеет также названия УmiddlewareФ или Усредства прикладной средыФ Механизмом, позволяющим любому количеству отдельных компонентов взаимодействовать друг с другом так, как если бы они были одним единым большим компонентом является среда поддержки компонентов. В настоящий момент наибольшей популярностью пользуются такие среды компонентов как SOM фирмы IBM, COM фирмы Microsoft, NextStep фирмы Next, ORBIX и программные продукты IONA Technologies, а также среда NEO и JOE от SUN Microsystems. За навигацию и контроль на данном уровне отвечает менеджер бизнес-транзакций (координатор компонентов). Менеджер бизнестранзакций - это компонент, который осуществляет управление последовательностями задач, образующих некоторый бизнес-процесс. Подобно менеджерам верхнего и среднего звена, осуществляющих управление хозяйственным субъектом на основе координации взаимозаменяемых участников трудового процесса, менеджер бизнес-транзакций, взаимодействуя со средой поддержки компонентов обеспечивает распределенную координацию решаемых задач.

Глава III. Физическая архитектура многоуровневой экономической информационной системы. Организация МРИС, как правило ориентирована на распределенную обработку информации, которая может осуществляться на основе функциональной или объектно-ориентированной информационной технологии между несколькими участниками, и предполагает обработку задания несколькими процессами, выполняющимися в различных узлах сети. Распределенная обработка предполагает коллективный доступ к базе данных, на основе использования различных архитектурных решений, таких как файл/сервер и клиент/сервер. Архитектура файл/сервер (File Server - FS) до недавнего времени являлась базовой для локальных сетей персональных компьютеров. Она была достаточно распространенной среди разработчиков, использующих такие СУБД, как FoxPro, CA-Clipper, Paradox, dBase, Clarion. Суть архитектуры файл/сервер заключается в следующем. Один из компьютеров в сети является файловым сервером и предоставляет услуги по обработке файлов другим компьютерам. Сервер файловой системы, исполняющийся на нем под управлением некоторой сетевой операционной системы (наиболее часто Novell NetWare), играет роль компонента доступа к информационным ресурсам. На других компьютерах в сети функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент. Все данные, необходимые приложению, размещены на одном или нескольких файловых серверах. Архитектура файл/сервер послужила фундаментом для расширения возможностей персональных СУБД в направлении поддержки многопользовательского режима. В МРИС, созданных по такой архитектуре на нескольких персональных компьютерах выполняется как пользовательская программа, так и СУБД (или её часть), а сама база данных хранится в разделяемых файлах, которые находятся на файловых серверах. В процессе работы пользовательская программа обращается к локальной части СУБД, которая в свою очередь исполняет запрос непосредственно на сервере файловой системы, содержащем базу данных. В процессе исполнения запроса файловый сервер представляет доступ по сети к требуемым данным, а СУБД, получив данные, выполняет над ними действия, которые были декларированы в пользовательской программе (рис.5).

Клиент Дей с 1. П твие № 2. З роверк 1. а Взя прос а прав. ть ф к се 3. Р а йл р в е р а у c us 4. С бота tom : с на Ф охране БД cu ers.d stom bf н ие а йл c ово e м с ustom rs.dbf ерв e ере rs.dbf.

Файловый сервер customers.dbf Действие №1. 1. Проверка прав. 2. Запрос к серверу : Взять файл customers.dbf 3. Ожидание, пока Клиент 1 закончти работать с customers.dbf *.dbf *.dbf *.dbf *.dbf *.dbf *.dbf Клиент Клиент Рис.5. Коллективный доступ к базе данных, на основе использования модели файлового сервера. Недостатками модели файлового сервера являются: высокий сетевой трафик (на сетевую станцию передается множество лишних данных, отбрасываемых после проведения поиска в файлах базы данных;

поскольку поиск происходит на компьютере клиента пославшего запрос, то по сети необходимо передавать многочисленные фрагменты индексных файлов);

обработка данных на пользовательских местах;

отсутствие адекватных средств безопасности (защита только на уровне файловой системы). Архитектура файл/сервер может оказаться пригодной для реализации небольших прикладных программ, используемых в рамках рабочей группы или малого предприятия, где требования к безопасности и скорости доступа невелики. Стоимость разработки этих систем чрезвычайно мала, а для их построения нет необходимости в высокой квалификации персонала. На смену архитектуры файл/сервер для обеспечения решения задачи УоблегченияФ клиентских мест была разработана архитектура клиент/сервер. Под УоблегчениемФ следует понимать использование на пользовательских местах менее производительных и, соответственно, более дешевых рабочих станций. Таким образом, используя множество недорогих компьютеров, разработчики систем клиент/сервер могут в полном объеме эмулировать вычислительную мощность Main Frame, Д 1 ей 2. П ств Вз. За ров ие 3 ят пр ер № 1. О ь ос к а 1. cu зак жи фа к с пр st он да йл ер ав om ч н c в. er ти ие, ust еру s. ра п om : d b б ок e f от а r s ат К л. d ь и bf с ен т распределяя вычислительные ресурсы по различным рабочим станциям и серверам. Каждый из них берет на себя свою часть вычислительной нагрузки, используя информацию совместно с другими компьютерами, подключенными к сети, и мощность системы в целом повышается не за счет наращивания производительности отдельного компьютера, а за счет суммирования вычислительных ресурсов. В архитектуре файл/сервер такого распределения вычислительных ресурсов не происходит, поскольку компьютеры подключенные к файловому серверу вынуждены самостоятельно осуществлять выборку необходимых файлов на сервере, перекачивать их в собственную оперативную память и, затем, производить обработку данных;

основное назначение файлового сервера заключается именно в хранении данных. Архитектура клиент/сервер предполагает использование компьютерамиклиентами некоего языка запросов, который обеспечивает эффективную доставку (транспортировку) данных между клиентскими и серверными процессами, тем самым перемещая центр тяжести от клиентов и увеличивая нагрузку на сервера. Архитектура клиент/сервер предполагает распределение вычислительной нагрузки между двумя (или более) отдельными процессами21. Если процессов всего два, то один из них является клиентом, а другой сервером. Сервер - это логический процесс, который обеспечивает обслуживание запрашивающих его процессов и возврат результатов работы. Клиент - это процесс, посылающий серверу запрос на обслуживание. Хотя и клиент, и сервер могут находиться на одном и том же компьютере, большинство систем архитектуры клиент/сервер запускают клиентский процесс на одном компьютере, а процесс-сервер на другом, используя для обмена информацией сетевые связи. При этом один процесс может работать независимо от другого, выполнять определенные задания и разделять вычислительную нагрузку. Процессы взаимодействуют по схеме "запрос-ответ". Клиент выполняет активную функцию, т. е. инициирует запросы, а сервер пассивно на них отвечает. При этом в различный момент времени роли процесса могут меняться, так например некоторый процесс может одновременно выполнять функции сервера по отношению к одному процессу и клиента по отношению к другому. В современной МРИС должны присутствовать функциональные части, обеспечивающие хранение данных в базе данных (уровень хранилище данных), обработки (уровень бизнес-правила) пользовательского интерфейса (уровень документы). Как было отмечено выше, каждая из этих частей может быть реализована независимо от двух других. Например, не изменяя программные модули, обеспечивающие хранение и обработку данных, можно изменить интерфейс с пользователем таким образом, что одни и те же данные будут совершенно по-разному отобра Или разделение прикладной программы по двум (и более) логически различным компонентам (клиент и сервер), каждая из которых выполняет свои отдельные функции. жаться на рабочем столе (экране монитора) в виде текстов, таблиц, диаграмм и т.д.;

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

и наконец, не меняя программные модули представления и обработки данных, можно изменить программное обеспечение для хранения данных, перейдя, например, к другой файловой системе. На практике происходит разделение МРИС на несколько взаимодействующих компонент, которые в свою очередь могут выступать в роли клиента (и/или) сервера. Клиент взаимодействует с сервером по строго определенному алгоритму: установление связи с сервером;

запрос конкретного вида обслуживания;

получение от сервера результатов запроса;

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

глобальная сеть;

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

прикладные функции, характерные для данной предметной области;

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

прикладной компонент, поддерживающий функции второй группы (уровень бизнесправила);

компонент доступа к информационным ресурсам (менеджер ресурсов), поддерживающий функции третьей группы (уровень хранилище данных). Различают двухуровневую и трехуровневую архитектуру клиент/сервер. В двухуровневой архитектуре три логические компоненты распределяют между двумя физическими модулями. Обычно данные располагаются на сервере (например, сервере базы данных), интерфейс с пользователем - на стороне клиента, а бизнес-логику распределяют между клиентской и серверной компонентой. В этом и заключается основной недостаток двухуровневой архитектуры, значительно усложняющий разработку программных решений под клиент/сервер. Чтобы избежать несогласованности различных элементов архитектуры, пытаются выполнять обработку данных на одной из двух физических частей - либо на стороне клиента: - так называемый "толстый" клиент, либо на сервере: - "тонкий" клиент22. Для решения перечисленных проблем используются многоуровневые (три и более уровней) архитектуры клиент/сервер. Такие архитектуры более оптимально распределяют компоненты обработки данных, которые в этом случае выполняются на одном или нескольких отдельных серверах. Данные компоненты выполняют функции сервера для интерфейсов с пользователями и клиента - для серверов баз данных. Кроме того, различные серверы приложений могут взаимодействовать между собой, осуществляя точное разделение системы на функциональные блоки, выполняющие определенные роли. Трехуровневая архитектура клиент/сервер обеспечивает распределение полномочий пользователей, которые получают права доступа не к самой базе данных, а к определенным функциям сервера приложений. Характерной особенностью многоуровневых архитектур является использование менеджеров транзакций, которые позволяют одному серверу приложений одновременно обмениваться данными с несколькими серверами баз данных. Менеджер транзакций используется для управления распределенными разнородными операциями и согласования действий различных компонентов информационной системы. Примером такого согласования может являться ситуация, когда часть информации на сервере баз данных хранится в формате Oracle, часть в формате Informix, а часть в виде текстовых файлов. Рассмотрим более подробно подходы к построению приложений в архитектуре клиент/сервер. Различия в реализациях приложений клиент/сервер определяются в основном тем, как логические компоненты взаимосвязаны друг с другом и каким образом они распределяются между компьютерами в сети. Наиболее известными моделями реализации являются: модель доступа к удаленным данным (Remote Data Access - RDA);

модель сервера базы данных (DataBase Server - DBS);

модель распределенной функциональной логики;

модель распределенных услуг;

распределенная одноранговая модель. Модель доступа к удаленным данным (RDAЦмодель) строится на основе специального языка запросов к серверу базы данных (SQLсерверу). В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте, менеджер ресурсов и данные находятся на сервере. Последний поддерживает Такая архитектура в литературе также получила название 2,5- уровневый клиент/сервер. как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка запросов23 или вызовами функций специальной библиотеки если имеется соответствующий интерфейс прикладного программирования. Клиент направляет запросы к менеджеру информационных ресурсов, находящемуся на удаленном компьютере, например, серверу базы данных). Последний обрабатывает и выполняет запросы, и возвращает клиенту результат, оформленный как блок данных. При этом инициатором манипуляций с данными выступают программы, выполняющиеся на компьютерахЦклиентах, в то время как менеджеру ресурсов отводится пассивная роль - обслуживание запросов клиентов (рис. 6). Говоря об архитектуре клиент/сервер, в большинстве случаев имеют в виду именно эту модель. Главным достоинством данной модели является возможность использования клиентских пользовательских мест и разгрузка сервера. Перенос компонента представления и прикладного компонента на компьютерыЦклиенты обеспечивает разгрузку сервера, который освобождается от несвойственных ему функций;

процессор (процессоры) сервера целиком осуществляет обработку данных, запросов и транзакций. По сравнению с моделью файлового сервера уменьшается загрузка сети, так как по ней передаются только запрашиваемые клиентом данные, а не все файлы, в которых они содержатся. В настоящий момент существует множество инструментальных средств, обеспечивающих быстрое создание настольных приложений, работающих с SQLЦориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя и содержат средства автоматической генерации кода, в которых смешаны прикладные функции и функции представления. Из наиболее популярных инструментальных средств можно назвать Power Builder от фирмы Powersoft, Visual Basic от Microsoft, Delphi от Inprise (Borland).

Например, языка SQL, если речь идет о базах данных. Запрос к SQL Серверу: выбрать пользователя из таблицы заказчики где имяЗаказчика='Иван' И фамилияЗаказчика='Иванов' Запрос к SQL Серверу: выбрать пользователя из таблицы заказчики где имяЗаказчика='Иван' И фамилияЗаказчика='Иванов' Клиент Выполнение запросов Клиента 1 и Клиента SQL Server Клиент table Получение ответа: имя=Иван фамилия=Иванов фирма=И&K заказ= table customers table Получение ответа: имя=Иван фамилия=Иванов фирма=И&K заказ= Рис.6. RDA-модель. Основным недостатком RDAЦмодели является то, что взаимодействие клиента и сервера посредством SQLЦзапросов существенно загружает сеть. Поскольку приложение является нераспределенным и вся его логика реализована на компьютере клиенте, то приложение нуждается в передаче по сети данных большого объема, возможно избыточных. При увеличении числа клиентов сеть становится узким местом, снижая быстродействие МРИС. Основу модели сервера базы DBSЦмодели составляет механизм хранимых процедур - средство программирования ядра СУБД (реализованный, например, в Oracle, Informix, Sybase, Adabas). Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует ядро СУБД. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД. Во многих реализациях процедуры являются интерпретируемыми, что делает их выполнение более медленным, чем выполнение программ, написанных на языках третьего и четвертого поколения. В DBSЦмодели приложение является распределенным. Компонент представления выполняется на компьютереЦклиенте, в то время как собственно прикладные функции реализованы в хранимых процедурах и выполняются на компьютереЦсервере (рис. 7). DBSЦмодель является наиболее близкой к жестко централизованной модели вычислений.

GET_CUSTOMERS('ИВАН','ИВАНОВ') GET_CUSTOMERS('ИВАН','ИВАНОВ') Клиент SQL Server Выполнение запросов Клиента 1 и Клиента Клиент customers Хранимая процедура GET_CUSTOMERS: create procedure dbo.GET_CUSTOMERS @FISTNAME T_NAME, @LASTNAME T_NAME as begin выбрать пользователя из таблицы заказчики где имяЗаказчика=@FISTNAME И фамилияЗаказчика=@LASTNAME end Получение ответа: имя=Иван фамилия=Иванов фирма=И&K заказ= Получение ответа: имя=Иван фамилия=Иванов фирма=И&K заказ= Рис. 7. DBS-модель. Преимущества DBSЦмодели по сравнению с RDAЦмоделью характеризуется: - возможностью централизованного администри-рования информационной системы;

снижением сетевого трафика;

24 сосредоточением всех прикладных функций на сервере, что делает менее болезненным процесс наращивания и сопровождения МРИС. К недостаткам DBSЦмодели следует отнести, то что она не обеспечивает требуемой эффективности использования вычислительных ресурсов. При расширении приложений серверы, на которых сосредоточена вся функциональная логика, не справляются с такой нагрузкой и возникает потребность в их замене или модернизации, в то время, как вычислительная мощность пользовательских настольных компьютеров используется недостаточно. Не случайно DBSЦмодель называется также моделью интеллектуального сервера. Часто вместо RDA - или DBSЦмоделей применяется смешанная модель распределенной функциональной логики. В этом случае поддержка целостности базы данных и некоторые простейшие прикладные функции реализованы как хранимые процедуры (DBSЦмодель), а более сложные функции реализуются в прикладной программе, которая выполняется на компьютере клиенте (RDAЦмодель). Такой подход позволяет обойти ограничения моделей, описанных выше, так как прикладные функции (функциональную логику приложения) можно разумно распределить между компьютеромЦклиентом и сервером, исходя из соображений Т.к. обработка данных выполняется преимущественно на сервере, и клиенту посылаются только необходимые данные. уменьшения сетевого трафика и вычислительной нагрузки компьютеров. Недостатком модели распределенной функциональной логики являются ограниченные возможности управления. В приложениях с распределенными функциями компоненты клиента и сервера настолько тесно связаны, что изменить одну часть приложения, не затрагивая другую, довольно трудно. Модель распределенных услуг25 предусматривает не столь жесткие связи между клиентом и сервером и более гибкие формы распределенной обработки. В этой модели компоненты приложения (представления, прикладной, доступа к информационным ресурсам) являются автономными и взаимодействуют через сеть при помощи стандартных интерфейсов. Компонент представления часто располагается на персональном компьютере, прикладной компонент (называемый также сервером приложения) выполняется сервером среднего уровня под управлением операционной системы UNIX или Windows NT, а компонент доступа к данным и сами данные располагаются либо на мощных UNIXЦсерверах, либо на больших или мини-ЭВМ. Однако на практике все три компонента могут с успехом выполняться и на одном компьютере. Основным элементом трехзвенной схемы является сервер приложения (Application Server - AS). В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как сервис (service) и предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый из них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения (Application Client - AC). Детали реализации прикладных функций в серверах приложений полностью скрыты от клиентов. Таким образом, нет необходимости, встраивать какуюЦлибо функцию в каждое выполняющееся приложение, достаточно установить ее на сервер приложения и обеспечить доступ других приложений к соответствующему сервису. Кроме того, разработчики могут создавать, изменять или переносить любые компоненты приложения, практически не затрагивая других (рис. 8).

Эта модель также называется трехзвенной моделью сервера приложений. Сервер баз данных DataBase Сервер приложений Прикладные программа API API DataBase Сервисы Клиент DataBase Рис. 8. Модель распределенных услуг. Для обеспечения взаимодействия сервера приложения и его клиентов создаётся промежуточный программный уровень (middleware), при помощи которого запросы принимаются от клиентов и направляются соответствующему серверу. На сегодняшний день существует достаточное количество инструментальных средств, позволяющих разработчикам строить распределенные приложения, не вдаваясь в детали реализации взаимодействия клиента и сервера. В распределенной одноранговой модели клиент/сервер приложения трактуется более широко, чем компонент представления. Он может поддерживать интерфейс с конечным пользователем, а может выполнять прикладные функции и являться сервером приложения. Все три компонента приложения (представления, прикладной, доступа к информационным ресурсам) выполняются независимо и взаимодействуют друг с другом для выполнения основной задачи. Модель распределенных услуг и одноранговая распределенная модель имеют более универсальный характер, чем RDA - и DBS - модели. Четкое разграничение логических компонентов и рациональный выбор программных средств для их реализации обеспечивают такой уровень гибкости, открытости и производительности, который невозможен в RDA - и DBSЦмоделях. Несмотря на все преимущества технологии клиент/сервер, реализация МРИС, построенной по этой технологии, требует значительных финансовых вложений и характеризуется высокими начальными затратами на разработку и обучение пользователей;

сложностью и высокой стоимостью поддержки и администрирования системы. Решение об использовании технологии клиент/сервер составляет очень важную часть информационной стратегии предприятия. При ее правильном применении можно получить МРИС с более оптимальным соотношением цена/производительность, которая допускает легкое наращивание, модификацию и адаптацию к изменившимся требованиям. Неоспоримым преимуществом использования архитектуры клиент/сервер является следующее: - с точки зрения пользователя прикладные программы выполняются быстрее, так как основная обработка информации происходит параллельно на одном или нескольких серверах;

более эффективное использование ресурсов клиента и сервера при разумном распределении компонент приложения между клиентом и сервером;

сокращение сетевого трафика, так как по сети передаются только запросы от клиента к серверу и результаты от сервера к клиенту;

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

Глава IV. Реализация многоуровневой экономической информационной системы с использованием CORBA и Java & Intranet. Многоуровенвая ЭИС подразумевает организацию такого доступа, чтобы пользователю было безразлично, где именно находится нужная ему информация. Пользователь должен лишь иметь право доступа к требуемой информации. При этом система, обеспечивающая организацию удаленного доступа к сетевым ресурсам, может и не обладать необходимыми пользователю возможностями. Данными возможностями должна обладать другая подобная система, с которой осуществляется взаимодействие между подсистемами, находящимися в разных системах. Иными словами данные, расположенные в системе становятся прозрачными для пользователя независимо от месторасположения их в самой системе. Данное свойство принято называть прозрачностью МРИС. Несколько лет назад появилась технология, которую стали использовать ведущие компании для построения информационной структуры организации по образу Internet, с Web-сервисом в качестве концептуальной основы. Возможность хранения данных различных типов в сочетании с механизмами связывания информации, расположенной в территориально разнесенных узлах компьютерной сети, позволяют рассредоточивать информацию в соответствии с естественным порядком ее создания и потребления, осуществлять единообразный доступ. В трехуровневой архитектуре "тонкий" клиент не перегружен функциями обработки данных, а выполняет свою основную роль системы представления информации, поступающей с сервера приложений. Такой интерфейс можно реализовать с помощью стандартных средств Web-технологии26, что уменьшает объем данных, передаваемых между клиентом и сервером приложений. Следует отметить, что значительно проще разработать html-формы для доступа пользователей к определенным функциям базы данных, чем ко всем данным. Средства Web, помимо связывания распределенных данных, позволяют рассматривать информацию с нужной степенью детализации, что существенно упрощает анализ больших объемов данных. Многоуровневые клиент/серверные ЭИС достаточно легко можно перевести на Web-технологию. Для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web-сервером и небольшими программами вызова процедур сервера. При этом, клиентская часть будет характеризоваться следующим. Прикладная программа доступна с любого компьютера, на котором инсталлирован браузер. Пользователю нет необходимости изучать инфтерфейс прикладной программы, потому что он всегда преобразуется к стандарту HTML-страниц. Это помогает снизить затраты на обучение.

Описание Web-технологии будет приведено ниже. Кроме того, пользователя совершенно не волнуют особенности аппаратной платформы и операционной системы, поскольку он имеет дело только с браузером. В свою очередь серверная часть будет характеризоваться следующей картиной. Приложения доступны любому пользователю, имеющему право обращаться к ним. Поскольку все операции по сопровождению и усовершенствованию системы производятся на сервере, то отпадает необходимость сопровождать и модернизировать части приложений, находящихся на машинах - клиентах. Рассмотрим основные моменты построения МРИС, в идеологии Web с использованим новых информационных технологий CORBA (Common Object Request Broker Architecture), Java и Intranet. Спецификации CORBA были разработаны и выпущены крупнейшим в мире консорциумом по разработке стандартов построения информационных систем Object Management Group (OMG), который в настоящее время включает около 600 крупнейших фирм в области информатизации. Основной задачей консорциума является разработка технологии, обеспечивающей повторное использование программных и информационных компонентов в распределенных неоднородных средах.CORBA27 - промышленный стандарт, отвечающий определению открытой системы28 и позволяющий разработчикам избежать неточностей и ошибок при создании МРИС. Следование стандартам CORBA обеспечивает использование единого языка обмена информацией между различными МРИС. Компоненты могут быть написаны на различных языках программирования, с использованием различных технологий и быть ориентированы на различные аппаратные платформы, но только отвечая единому стандарту взаимодействия друг с другом, одна подсистема может передать информацию в другую, что особенно важно при организации крупных МРИС, где проблема взаимодействия множества программных компонент и платформ, стоит особенно остро. И именно спецификация CORBA является наиболее эффективным инструментарием и наиболее полно обеспечивает разрешение данной проблемы. МРИС по спецификации CORBA состоит из серверов, управляющих объектами, и клиентов, запрашивающих эти объекты. Серверы предоставляют клиентам и другим серверам доступ к объектам. Сервер, при посылке запроса на другой сервер, сам становится клиентом. Операция вызова CORBA объекта связана с Object Request Broquer (ORB) - объектным брокером вызовов, который выполняет роль посредника между Здесь и далее речь идет об архитектуре CORBA версии 2.0. Открытая система - Усистема, реализующая открытые спецификации на интерфейсы, сервисы и поддерживаемые форматы данных, достаточные для того, чтобы обеспечить должным образом разработанным приложениям возможность переноса с минимальными изменениями на широкий диапазон систем, совместной работы с другими приложениями на локальной и удаленных системах и взаимодействия с пользователями в стиле, облегчающем тем переход от системы к системеФ.

28 клиентом и сервером и скрывает механизмы передачи информации по спецификации CORBA (рис.9).

Клиент Сервер Целевой объект CORBA Клиент CORBA Сервер Stub Stub Stub Stub ORB IDL Interface Промежуточный код взаимодействия клиентской части с ORB IDL Interface Промежуточный код взаимодействия серверной части с ORB Рис. 9. Взаимодействие клиента с сервером посредством ORB Клиент и сервер могут не знать находятся ли они в одном адресном пространстве, в одном узле вычислительной сети или в разных частях света. Сервер может запускаться автоматически при обращении клиента к его объекту и функционирует до тех пор пока хотя бы один объект используется клиентами. В свою очередь клиент может содержать объекты, к которым может поступать запрос от других клиентов или серверов. Это становится возможным, если клиент передаст ссылку серверу на один из своих объектов. Отличие клиента от сервера заключается в том, что клиент не может быть автоматически запущен и его роль заключается в основном в получении от сервера обработанной информации в качестве ответа на запрос и предоставлении ее пользователю. В подсистемах МРИС реализация различных объектов может быть выполнена с помощью различных языков программирования. При этом возникает проблема стыковки и взаимодействия этих реализаций. Решением проблемы служит абстрагирование от языка реализации с помощью описания интерфейса между этими реализациями. Консорциумом OMG был разработан специальный язык описания интерфейсов Interface Definition Language (IDL), который на сегодняшний день является стандартом в области построения МРИС и обеспечивает разделение процессов проектирования и программирования.

CORBA предоставляет инфраструктуру для создания легко изменяющейся, настраиваемой и расширяемой информационной архитектуры. Инструментами для этого служат OMG IDL и ORB. OMG IDL описывает лишь интерфейсы взаимодействия различных компонент, не описывая реализацию. Благодаря этому при построении информационной архитектуры можно абстрагироваться от применения той или иной платформы и собственно реализации. Этим достигается разделением процессов проектирования и разработки программного кода. Использование IDL позволяет создавать промежуточные коды взаимодействия клиентской и серверных частей МРИС с ORB. Имея описание интерфейса, разработчик программного кода может реализовывать объект, так как он видит эту реализацию, но доступ к ней с помощью различных языков программирования будет прозрачным. Компоненты МРИС, организованные на основе стандарта CORBA представляют собой объекты, для которых описаны интерфейсы на языке IDL и которые могут быть доступны из любого узла сети. Каждый объект принадлежит какому-либо серверу, который управляет набором объектов с одним и тем же или различными интерфейсами. Каждый объект имеет свой уникальный в рамках МРИС идентификатор, по которому он может быть найден. CORBA с помощью IDL скрывает от проектировщиков механизмы взаимодействия компонент. При использовании прямой интеграции, т.е. когда встраиваемая компонента использует API (Aplication program interface) уже функционирующего приложения, проектировщики ставят проект под угрозу быстрого устаревания. Чтобы эффективно использовать API, необходимы квалифицированные специалисты по разработке ПО, которые бы знали все тонкости данного API и способы встраивания его в открытую систему. Программисты могут потратить несколько лет, чтобы получить требуемые знания. Затраты на поддержку этих знаний на необходимом уровне будут непосредственно влиять на конечную стоимость программного продукта. Технология CORBA позволяет клиенту не заботиться об адресе объекта, к которому он собирается послать запрос, о механизмах передачи этого запроса и получения ответа. Запрос от клиента может быть построен как статически, если интерфейс известен на стороне клиента, так и динамически. В первом случае клиент просто посылает запрос с помощью этого интерфейса, который был определен на стадии компиляции, а во втором случае сначала получает информацию о том, как использовать интерфейс с объектом, который он хочет использовать, а затем формирует запрос. Таким образом, можно использовать либо строгую проверку типов при раннем связывании или преимущества гибкости системы, связанные с поздним связыванием, т.е. во время исполнения.

ORB позволяет объектам находить другие объекты и сервисы благодаря наличию репозитория интерфейсов, который содержит информацию о параметрах методов и самих методах сервиса. Эти метаданные используются клиентом для получения информации о том, как вызвать тот или иной метод на стороне сервера. Таким образом, ORB - самоописываемая система, позволяющая совместить компоненты, написанные на разных языках программирования. Все что нужно разработчику программного обеспечения для написания компоненты - это откомпилировать интерфейс, описанный на языке IDL, в заголовки кода и специальный код для доступа к ORB из необходимого языка программирования, называемый stub-кодом. По мере разрастания и увеличения объемов информации, изменения бизнес процессов и пользовательских интерфейсов особенно важной стала возможность совместного использования различных компонентов, будь то компоненты функциональной логики, информационной архитектуры, представления, или базы данных. Совместное использование предполагает прозрачный доступ к ним с различных компьютеров, объединенных в сеть. При этом работу компонентов, связанных с непосредственной обработкой информации, целесообразно организовывать на более мощных компьютерах, способных к большим вычислительным нагрузкам. Компоненты же, не требующие от компьютера таких нагрузок, например, компоненты представления, можно предоставить менее мощным машинам или терминалам. МРИС в сегодняшнем понимании есть набор программных компонентов, функционирующих на нескольких компьютерах и взаимодействующих между собой. В соответствии с методологией сбора, обработки и передачи данных выделяют VI уровней сложности предприятий, использующих разнообразные технологии для достижения взаимодействия разрозненных по сети компонент. К первому уровню относятся предприятия, использующие уже написанные частные, плохо настраиваемые приложения. При этом такие приложения просто обречены на быстрое устаревание. Ко второму относятся организации, которые сами создают программные решения под свои собственные нужды без использования технологий интеграции. Эти программы создаются на основе так называемых Уad hocФ архитектур, которые не представляют из себя целостных архитектурных абстракций. На этом уровне используются такие средства взаимодействия приложений в сети, как TCP/IP (Transmission Control Protocol) и ONC RPC (Object Network Computing Remote Procedure Call), которые обычно встроены в операционные системы или поставляются дополнительно. На следующем уровне организации нуждаются в использовании единого подхода в интеграции и технологий ONC, RPC более высокого уровня, в котором уже заложены базовые сервисы безопасности, именования объектов и др. Эти организации не используют преимущества но вейших технологий и тратят большие средства на разработку и поддержку МРИС, основанных на низкоуровневых технологиях взаимодействия. Организации четвертого уровня используют технологию CORBA для обеспечения возможности распределенных вычислений. В случае, когда эти возможности не нужны, архитектурные интерфейсы используют старые унаследованные механизмы. Таким образом, большинство таких организаций не используют основные преимущества CORBA и их МРИС не отвечают этой спецификации. В результате эти системы рискуют быстро устареть, так как используют технологии, зависящие от поставщика. Организации на пятом уровне разрабатывают каркас МРИС, воплощающий продуманные принципы построения программной архитектуры, и используемый в рамках одного или нескольких проектов. Они реализуют собственные механизмы на основе технологии CORBA, как унифицированное средство организации взаимодействия компонент в рамках рассматриваемых предметных областей, не только для обеспечения межплатформенного взаимодействия. Однако организации этого уровня по-прежнему сталкиваются с проблемами взаимодействия между программными продуктами разных производителей. Организации шестого уровня создают программные архитектуры и сервисы для использования во многих проектах. Они полностью ориентированы на стандарт CORBA, что позволяет организациям поддерживать множество аппаратных и программных платформ и избежать риска устаревания МРИС. Они оказывают влияние на развитие систем в своей отрасли, являются создателями стандартов взаимодействия систем для отрасли, а некоторые из них разрабатывают технологию мирового класса. Организации, относящиеся к этому уровню - всемирно известные фирмы. Важное свойство стандарта CORBA заключается в объектной ориентированности. Инкапсуляция позволяет обращаться к объектам, не зная, как и с помощью каких языков программирования они реализованы. Наследование позволяет многократно использовать ранее написанный код и легко его расширять. Механизмы передачи запросов позволяют пользователю не знать, где объекты физически находятся в сети. С помощью этой технологии можно собрать разрозненные по сети компоненты и разные информационные системы в единое целое. Основные преимущества, получаемые при переходе на технологию CORBA - это реинжиниринг информационной системы предприятия. Задача проектировщика, использующего технологию CORBA для построения МРИС - создать информационную архитектуру отдельно от анализа предметной области, предварительно уяснив какие компоненты архитектуры будут нужны МРИС, а затем перенести на нее результаты анализа. Средства, определения и сервисы, описанные в спецификации CORBA позволяют абстрагироваться от реализации, сосредоточить усилия разработчика на анализе предметной области, а также интегрировать вместе старые используемые приложения и новые, написанные с учетом данных спецификаций. CORBA является средством создания правильной информационной архитектуры, так как скрывает от проектировщика ее реализацию. Ему не нужно думать с помощью каких средств компоненты МРИС будут обмениваться информацией, находить друг друга, запускать и т.п. Таким образом, проектировщик может лучше сосредоточиться на построении информационной архитектуры. Кроме того, CORBA предоставляет сервисы, которые могут быть необходимы в дальнейшем множеству объектов МРИС. Еще одной важной составляющей организации МРИС является технология, основанная на синтезе языка Java и Intranet. Intranet - это корпоративная сеть, построенная по технологии Internet. Организация распространения и обработки электронных документов происходит с помощью Web-технологии. Ключевые компоненты этой технологии: Webсервер и Web-броузер. Броузер для пользователя - это инструмент, с помощью которого он может читать и изменять документы. На Webсервере хранятся документы или ссылки на эти документы. Броузер и сервер общаются между собой с помощью протокола HTTP (HyperText Transfer Protocol) и передают ссылки на документы с помощью URL (Unified Resource Locator). Основные достоинства Intranet в том, что пользователь может не знать, что такое УфайФ, УдиректорияФ, УсерверФ. Он работает только с документами и ссылками на другие документы, по которым может получить новый гипертекстовый документ. Чтобы новый документ могли прочитать все заинтересованные пользователи, достаточно поместить его на Web-сервер и внести его краткое содержание и ссылку на него в соответствующие каталоги. Webтехнология, созданная для глобальной сети Internet, обеспечивает простой механизм структурирования огромных объемов информации и доступа к ним. Web-технология позволяет создать такую информационную систему, в которой любой документ можно будет найти довольно быстро. Intranet позволяет избежать лишних операций копирования, так как используется одна копия на Web-сервере, хранящаяся в стандартном формате. Технология Intranet позволяет использовать сетевые компьютеры JavaStation, которые представляют из себя бездисковые рабочие станции. Бездисковая рабочая станция подразумевает отсутствие винчестера и дисководов. Преимущества ее очевидны, кроме снижения стоимости самой станции, исключается опасность заражения вирусами, и обеспечивается УаппаратнаяФ защита информации, исключающая возможность несанкционированного копирования. Такие компьютеры можно использовать в качестве терминалов, например, в операционном зале для пер сонального доступа клиента банка к собственным счетам. При этом клиенту не нужно обращаться к операционисту за информацией о своем счете и, кроме того, он может получить ее не только в виде текущего остатка, но и в виде графиков за необходимый период, а также другую интересующую информацию, например, курсы валют. Кроме того, ему предоставляется возможность использования электронных таблиц, калькулятора, текстового редактора и т.п. Intranet позволяет объединять системы в единое информационное пространство и обеспечивает взаимодействие между ними. Эта технология не только включает в себя все достоинства корпоративной "паутины", но и расширяет их. Так, например, пользователь одной системы может работать с данными из другой. Основным недостатком Web-технологии является поддержка работы только со статической информацией. Для того, чтобы изменить какую-либо часть HTML-страницы, необходимо полностью ее перезагрузить. При частых изменениях работа с такой страницей становится невозможной. Ещё одним недостатком Intranet является сложный доступ к базам данных. Броузер не может сам обращаться к серверу базы данных и принимать от него ответы, он работает только с Web-сервером. На сегодняшний день наиболее распространенным решением этой задачи является использование так называемой технологии броузер/сервер. При этом на стороне сервера функционируют приложения, написанные по спецификации CGI (Common Gateway Interface). По этой спецификации в HTML-странице содержится форма, в которую пользователь вводит необходимую информацию, а затем броузер передает ее на Web-сервер, который запускает приложение CGI. Далее это приложение формирует запрос на языке запросов SQL к базе данных, получает ответ и конвертирует его в HTML-страницу и через Web-сервер передает ее броузеру (рис. 10.). Однако приложение CGI можно применять и не только для доступа к базам данных - оно может быть и частью функциональной логики. Приложение CGI может быть реализовано как отдельный выполнимый модуль или как динамически подгружаемая библиотека. Этот модуль или библиотека вызывается каждый раз Web-сервером, устанавливает связь с сервером базы данных, обрабатывает ответ, прекращает работу и освобождает ресурсы. Такая схема требует довольно много ресурсов на серверной стороне. Таким образом Web-сервер при большом количестве клиентов становится узким местом МРИС.

CGI приложение HTTP или URL Переменные окружения или API HTML страница WWW сервер SQL сервер БД Рис. 10. Доступ к базе данных через CGI На сегодняшний момент развитие интрасетей привело к тому, что недостаточно получить просто статичную информацию с HTMLстраницы. Пользователям необходимо интерактивное взаимодействие с информацией, хранящейся внутри Intranet. Появились технологии, позволяющие посылать запросы к базе данных и участвовать в изменении внутренней информации интрасети. Одной из наиболее перспективных и заслуживающих внимание является технология Java. Главное достоинство состоит в легкости ее использования при написании компонент, функционирующих в сети. Программа на Java может быстро передаваться по сети за счет своей компактности. Кроме того, пользователю Web-броузера не нужно хранить у себя код пользовательского интерфейса. Этот код он может получить вместе с HTML-страницей в виде аплета (APPLET), который представляет собой байт-код Java и ключевое слово языка HTML в этой странице. Когда броузер получает такую страницу, он автоматически загружает исполняемый код, на который указывает это ключевое слово и передает его на выполнение интерпретатору. Данная технология позволяет встраивать в электронные документы активные элементы, например, объект УзаявкаФ при открытии лицевого счета клиенту может быть непосредственно загружен на его компьютер с сервера банковской интрасети и после заполнения необходимых полей передан другому ответственному лицу или помещен в базу данных. Java аплет может напрямую взаимодействовать с базами данных посредством Java DataBase Connectivity (JDBC). Благодаря этому высвобождается часть ресурсов, связанных с функционированием связки серверCGI (рис. 11).

Распределять объекты по сети и организовывать их взаимодействие можно с помощью применения API интерфейсов JavaBeans. JavaBeans представляют собой программные компоненты, которые можно многократно использовать в своих программных продуктах, легко встраивать компоненты от третьих поставщиков в свои приложения или документы, а также поставлять их другим разработчикам. Основная цель архитектуры JavaBeans заключается в обеспечении платформно-независимой архитектуры. Любая компонента JavaBeans может быть встроена в другую, а УкорневаяФ компонента - в платформно-зависимый контейнер, например, такой как Internet Explorer, Microsoft Word, Netscape Navigator и т.п. Это означает, что любая компонента или целое приложение JavaBeans может быть интегрированы в локальное для данной платформы приложение. Таким образом, одно и то же приложение JavaBeans может выполняться на разнообразных платформах.

CGI приложение HTTP или URL Переменные окружения или API HTML страница Java аплет J D B C WWW сервер Database protocol SQL сервер БД Рис. 11. Доступ к базе данных через JDBC Использование компонент JavaBeans может быть разным. Некоторые из них могут быть УстроительнымиФ блоками в создаваемом приложении. С помощью визуальных средств создания программ эти блоки собираются вместе и настраиваются под конкретные нужды. Однако приложение JavaBeans может быть больше чем просто приложение, так как его может содержать другая компонента. Например, в Web-страницу легко встроить электронную таблицу JavaBeans. Таким образом, стираются грани между терминами Усоставной документФ и Усоставное приложениеФ, так как электронную таблицу (или любую другую компоненту) с Web-страницы можно легко перенести в создаваемое приложение, а окно текстового редактора - в Усоставной документФ. Компоненты JavaBeans могут взаимодействовать с разными объектами в системе, такими как базы данных, объекты CORBA и Java и т.п. Взаимодействие осуществляется с помощью различных протоколов передачи данных, основными из которых являются JDBC, RMI (Remote Method Invocation) и IIOP (Internet InterORB Protocol) (рис. 12).

Java Bean J D B C Database protocol RMI сервер БД SQL Java сервер IIOP CORBA объект ORB Рис. 12. Использование JavaBeans Язык Java является языком, предназначенным для сетевых вычислений, его важнейшее свойство заключается в независимости от архитектуры компьютера. То есть модули приложения имеют архитектурнонезависимый формат, представляющие собой байт-коды, которые могут быть проинтерпретированы на множестве разнообразных платформ, где используется виртуальная Java машина (Virtual Java machine - VJM). Java создавался как средство для написания интерактивных сетевых компонент. В нём реализовано несколько решений, позволяющих создавать код, который выполняет одновременно большое количество различных функций, осуществляет контроль над взаимодействием подзадач и обеспечивает их полную синхронизацию. Программные решения, выполненные с помощью языка Java, хорошо функционируют даже на компьютерах с маломощным процессором. В языке Java для обеспечения синхронизации процессов используется инструментарий, позволяющий конструировать интерактивные системы. Java является объектно-ориентированным языком. Объектная модель в Java проста и легко расширяется. В большинстве других объектно-ориентированных систем либо используются негибкие и трудные в управлении иерархии объектов, либо за счет огромных потерь в производительности и универсаль ности применяются полностью динамические объектные модели. Java обеспечивает разумный компромисс, предоставляя простой механизм классов, и лишь в тех случаях, когда это действительно необходимо, предлагает динамическую модель. В нем упрощен механизм управления памятью, благодаря чему с разработчика программного кода снимается ответственность за управление памятью и резко снижается количество ошибок. Компоненты, написанные на языке Java, должны взаимодействовать как друг с другом, так и с остальными компонентами. МРИС требуется доступ не только к базам данных, но и к функциональной логике. Этот доступ целесообразно реализовать на основе спецификаций CORBA, которые обеспечивают стандартную среду взаимодействия программных компонент. Таким образом Java- компонент, созданный с использованием технологии CORBA, может не только обеспечивать WIMР-интерфейс с пользователем, но и взаимодействовать с любыми другими компонентами, поддерживающими стандарт CORBA. Компонент, реализованный на языке Java может функционировать на любой программной и аппаратной платформе, где существует VJM. Современные информационные технологии позволяют встраивать VJM в броузеры Internet, что в свою очередь предоставляет возможность загружать Java- компоненты по сети с удаленного сервера. Например, клиент банка хочет открыть новый счет, не выходя из своего офиса. Для открытия счета он просто связывается с Webсервером этого банка с помощью броузера. После идентификации клиент инициирует процесс открытия нового счета и ему передается объект заявки, которая представляет собой аплет. Этот объект после заполнения заявки передается по сети на машину ответственного лица, после чего сохраняется в базе данных. После успешного завершения необходимых бизнес процессов клиенту открывается счет. При этом все процессы, происходящие в сети скрыты от клиента. Он лишь привел процесс в действие, все остальное сделала за него связка сервисов и объектов функциональной логики, где Java является средством быстрой передачи объектов по сети. При этом клиент даже не задумывался о сложности процессов протекающих в процессе передачи информации. Ранее, для того чтобы осуществить подобную процедуру пользователь должен был обладать знаниями о структуре баз данных банка, протоколах передачи данных, использующихся в интрасети банка, знать языки программирования, на которых были реализованы компоненты функциональной логики МРИС. На рис. 13 показано взаимодействие объектов Java и CORBA и протоколов, посредством которых взаимодействуют эти объекты. Они могут представлять из себя сервисы и объекты функциональной логики, которые позволяют не только обращаться к базе данных, когда часто это невозможно сделать напрямую, но и использовать информацию, находя щуюся в других объектах и их функции. Этим обеспечивается связывание различных локальных сетей Intranet в единое целое, где доступ к возможностям одной сети будет прозрачным для другой. Таким образом, наиболее перспективным инструментарием для организации МРИС является синтез технологий CORBA, Java & Intranet, которые позволяют говорить об устойчивости структуры системы в течение её жизненного цикла. Большие МРИС характеризуются постоянными процессами устаревания, и в связи с этим необходимостью замены их структурных компонент, но программная архитектура ЭИС, реализованная с использованием CORBA, Java & Intranet останется неизменной, что обеспечит значительную экономию финансовых, трудовых и временных ресурсов в процессе дальнейшего совершенствования системы.

HTTP или URL HTML страница Java Applet WWW сервер SQL CORBA объект IIOP IIOP сервер БД ORB CORBA объект Рис. 13. Взаимодействие Java и CORBA Совместное использования технологий CORBA, Java и Intranet позволят повысить качество обработки информации, минимизировать использование бумажных носителей, увеличить оперативность формирования аналитической информации для руководства, повысить достоверность результатных данных, снизить затраты на подготовку, ввод, передачу, хранение, получение и анализ информации, что обеспечит повышение качества принятия решения на всех уровнях управления и безусловно является немаловажным аспектом повседневной деятельности фирмы в условиях рыночной экономики.

Экономическая система России является весьма динамичной, постоянно развивается и модифицируется особенно в части финансовых, бухгалтерских и налоговых механизмов. Страна постепенно движется к цивилизованным рыночным отношениям, и все меньше места в ней остается сомнительным спекулятивным операциям. Одним из актуальных товаров современного рынка становятся время и информация. Использование многоуровневых ЭИС, построенных на основе технологий CORBA, Java и Intranet позволяет оперативно получить ответ на интересующий вопрос. Для оценки какого-либо проекта или, например, портфеля ценных бумаг потребуются считанные минуты, в то время как используя традиционных технологии можно потратить несколько часов или даже суток. А для Уолл-стрит или, например, для Центрального Банка РФ, разница между минутами и часами может быть эквивалентна стоимости затрат на создание МРИС на базе рассмотренных выше технологий.

Вопросы для самопроверки 1. Какие существуют проблемы при создании территориальнораспределенных ФИТ? 2. Приведите пример формирования многопользовательской функциональной информационной технологии. 3. Назовите классификационные признаки современных многопользовательских информационных технологий. 4. Назовите основные тенденции изменений на рынке индустрии программных продуктов. 5. Охарактеризуйте процессы интеграции современных многопользовательских информационных технологий. 6. Как многоуровневая функциональная информационная технология может быть распределена между несколькими участниками бизнеспроцесса. 7. Охарактеризуйте реинжиниринг бизнес-процессов как следствие влияния МФИТ на бизнес-процессы предприятия и на перераспределение ответственности и полномочий. 8. Назовите компоненты МРИС, влияющие на ее стоимость. Какова их доля в формировании общей цены? 9. Как окупаются затраты на приобретение и разработку МРИС? 10. Назовите виды положительные стороны (выйгрыш), получаемый предприятием, от использования МРИС. 11. Каковы перспективы использования трехзвенной логической архитектуры;

12. Как распределить данные и расчеты между участниками процесса управления;

13. Каким образом и зачем МФИТ превращаются в АРМ;

14. Какое место АРМ занимает в МРИС. 15. Как связана МРИС с информационными технологиями. 16. Назовите методы распределения данных в рамках МРИС. 17. Какие возможности предоставляют сетевые технологии для развития МРИС. 18. В чем заключается распределенная обработка данных в рамках МРИС. 19. В чем сущность распределенной базы данных. 20. Какие возможности предоставляет распределенная обработка данных в рамках МРИС. 21. В какой операционной системе (среде) возможна реализация архитектуры клиент сервер Dos, Windows 98/2000, Windows NT, Unix, Apple ЦMac. 22. Способы обмена информацией между подсистемами в рамках МРИС. 23. Два подхода при проектировании МРИС.

24. Архитектурные решения на базе платформы файл сервера в рамках МРИС. 25. Распределенная обработка информации в рамках МРИС на примере архитектуры клиент-сервер 26. Способы обмена данными в МРИС 27. Принципы организации построения МРИС 28. Объектно-ориентированное проектирование МРИС 29. Способы распределения данных в рамках МРИС 30. Особенности создания МРИС на основе объединения технологий CORBA Java & Intranet 31. Стандарты построения открытых систем, на примере C O R B A. 32. Механизмы управления сложностью в процессе логического проектировании МРИС 33. Какой вариант классификации МРИС Вы запомнили. 34. Какова структура МРИС и её состав. 35. Трехуровневая логическая архитектура проектирования МРИС. Выделение уровней УдокументыФ, Убизнес- правилаФ и база данных. 36. Архитектурные решения на базе платформы клиент-сервер. 37. Укажите особенности функционального и объектноориентированного подхода создания МРИС. 38. Какая классификация МРИС вам известна 39. В чем нюансы объектно-ориентированного проектирования МРИС 40. Вопросы организации удаленного доступа к информационным ресурсам МРИС. 41. Свойство прозрачности МРИС. 42. Назовите принципы объектно-ориентированной декомпозиции МРИС. 43. Назовите принципы структурной декомпозиции МРИС. 44. Охарактеризуйте наиболее известные методологии проектирования МРИС, поддерживающие структурный подход. 45. Охарактеризуйте наиболее известные методологии проектирования МРИС, поддерживающие объектно-ориентированной подход. 46. Приведите пример распределения АРМ по уровням обработки информации в рамках МРИС для крупного предприятия. 47. Укажите условия, тенденции и перспективы развития МРИС в экономике и управлении. 48. Охарактеризуйте МРИС как систему управления полномочиями. 49. Опишите Офис будущего на основе МРИС. 50. Как разработчики и поставщики участвуют в продвижении МРИС на рынке?

Книги, научные публикации

Blog

Московский международный институт эконометрики, информатики, финансов и права Уринцов А. И.