Типовые архитектурные решения для корпоративных информационных систем на платформе Microsoft. Net Текст научной статьи по специальности «Компьютерные и информационные науки»

КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ

УДК 004.4

ТИПОВЫЕ АРХИТЕКТУРНЫЕ РЕШЕНИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ПЛАТФОРМЕ MICROSOFT.NET

© 2006 г. А.И. Долженко

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

Понятие архитектуры является достаточно ёмким и может быть конкретизировано в зависимости от точки зрения, целей и задач создания информационной системы. В общем случае архитектуру информационной системы можно представить как концепцию, определяющую модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. В работе [1] отмечается, что архитектура нужна, чтобы у разработчиков складывалась единая концепция большой и сложной программной системы. Кроме того, архитектура программной системы должна включать в себя данные: об организации программной системы; о структурных элементах, входящих в систему, и их интерфейсах, а также поведение, определяемое кооперациями, в которых участвуют элементы; о составе структурных элементов и элементов поведения наиболее крупных подсистем; о стиле архитектуры, принятом в организации, элементах и их интерфейсах, их кооперации и композиции.

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

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

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

Для распределенных корпоративных информационных систем типичным архитектурным решением служит трехуровневая структура: уровень представления, уровень бизнес-логики, уровень данных.

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

Уровень представления КИС предназначен для отображения данных на компьютере конечного пользователя и его интерактивного взаимодействия с системой. Основой построения уровня представления является контейнерный класс, включающий разнообразные, взаимодействующие с ним классы графических элементов управления (кнопки, текстовые поля, списки, таблицы, календари и др.). Платформа Microsoft.NET [3] для этой цели предоставляет класс System. Windows.Forms.Form или System.Web.UI.Page.WebForm и большое разнообразие классов элементов управления, дочерних от класса Control. Функциональность уровня представления во многом определяется составом элементов управления, входящих в коллекцию Controls для конкретной формы.

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

Уровень бизнес-логики получает на вход информацию от уровня представления, проводит необходимые проверки и вычисления, сохраняет информацию в базе данных, активизирует операции других систем и возвращает уровню представления определенные данные. Для организации уровня бизнес-логики в [2] предлагается три типовых решения: сценарий транзакций; модель предметной области; модуль таблиц.

Сценарий транзакций представляет собой процедурную модель, предназначенную для работы с простыми схемами организации источника данных и относительно несложной бизнес-логикой. Сценарий транзакций реализуется методами, которые получают входную информацию от слоя представления, обрабатывают её, проводят необходимые проверки и вычисления, сохраняют информацию в базе данных. Методы могут возвращать слою представления данные из базы. Бизнес-логика описывается набором методов, реализующих бизнес-транзакцию. Для платформы Microsoft.NET это типовое решение использует прямой доступ к базе данных и базируется на использовании объектов классов DataCommand и DataReader

Операционист: Person

Представление

ChildForm

Display( )

тг

Сценарий транзакции DataReader

тг

База данных

-3>rt

0

Найти

тг

Выполнить бизнес-логику

Выполнена транзакция ^ "Найти"

Set( )

Сохранить изменения ->

О

Выполнить бизнес-правила ' -1

Выполнена транзакция ^ "Обновить"

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

технологии ADO.NET [4]. Класс, реализующий сценарий транзакций, обеспечивает прямой доступ к источнику данных и необходимую функциональность бизнес-логики. Для данного типового решения все обязанности по реализации бизнес-логики возлагаются на методы сценария транзакций. Взаимодействия архитектурных уровней информационной системы при использовании типового решения сценарий транзакций показано на рис. 1.

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

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

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

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

Извлечь

И

Обновить

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

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

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

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

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

Модель предметной области позволяет достаточно эффективно описывать сложные бизнес-процессы. Основной недостаток этой модели - сложность создания интерфейса модели предметной области к реляционной базе данных.

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

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

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

Тем не менее при использовании платформы Microsoft.NET наиболее рационально применять типовое решение Модуль таблицы, которое достаточно эффективно реализуется компонентами технологии ADO.NET и поддерживается разносторонним набором инструментальных средств. Типовое решение основывается на классе DataSet, который может включать данные об одной или более таблиц. Конкретный Модуль таблицы должен включать набор методов для реализации бизнес-логики предметной области. Для манипуляции записями таблиц используются методы класса DataSet. В состав методов класса должны входить как методы создания, изменения и удаления записей конкретной таблицы, так и методы, реализующие бизнес-логику (вычисление значений по заданным алгоритмам, проверки ограничений целостности данных), что является расширением типичной функциональности класса DataSet. Следует отметить, что библиотека Framework.NET предоставляет пользователям класс BindingManagerBase, который синхронизирует все элементы управления уровня представления и данные экземпляра класса бизнес-логики.

Уровень данных корпоративной информационной системы предназначен для реализации функций, обеспечивающих взаимодействие приложения с источником данных, как правило, системой управления базами данных. Этот уровень несет ответственность за мониторинг транзакций, обмен сообщениями. Типовые решения этого уровня должны обеспечить способы взаимодействия бизнес-логики с базой данных. Взаимодействие с реляционной базой данных осуществляется с помощью языка SQL. Данный уровень позволяет обособить код SQL от бизнес-логики, разместив его в специальных классах. Для информационных систем, разрабатываемых на платформе Microsoft.NET, можно использовать идею типового решения Шлюз таблицы данных, базируя его на классах Connection и DataAdapter технологии ADO.NET. В приложениях DataAdapter обеспечивает считывание информации из базы данных и пересылку её в DataSet, возврат изменений в исходную базу данных. Шлюз таблицы данных достаточно хорошо отображает таблицы базы данных на объекты и выполняет важную функцию: инкапсулирует точную логику доступа к источнику данных.

Типовое решение Шлюз таблицы данных содержит команды SQL, которые реализуют функции чтения, обновления, вставки и удаления данных из таблиц базы данных. Методы шлюза таблицы данных, реализованные на базе классов DataAdapter технологии ADO.NET, обрабатывают структуры данных в виде множества записей, с которыми затем работает модуль таблицы.

На рис. 2 приведена диаграмма классов, моделирующая место заключения сделок с ценными бумагами (торговую площадку) и расчет торговой комиссии.

Класс FormDirectory моделирует функциональность уровня представления. Класс tmDealPlace представляет собой типовое решение Модуль таблицы и обеспечивает выполнение бизнес-логики системы, осуществляя как актуализацию информации по торговым площадкам, так и расчет торговой комиссии в соответствии с условиями договоров брокерского обслуживания. Класс tmDealPlace инкапсулирует сложную бизнес-логику расчета торговой комиссии. Класс DealPlaceGateway соответствует типовому решению Шлюз таблицы данных, который организует и контролирует взаимодействие приложения с системой управления базой данных. На рис. 3 представлена диаграмма взаимодействия классов.

В соответствии с рис. 3 операционист формирует сообщение на выполнение редактирования данных, что реализуется методом Display() класса Представление. Класс Представление передает сообщение Найти шлюзу таблицы данных, который формирует требуемый SQL-запрос (сообщение Извлечь) к базе данных. Результатом SQL-запроса является возврат множества записей, которые запоминаются в модуле таблицы и отображаются на уровне представления. Операционист инициирует редактирование записи (метод Edit). После окончания редактирования данных класс Представление передает сообщение Модулю таблицы на проверку данных (Проверить правильность). По окончании проверки операционист инициирует сохранение изменений в базе данных (метод Save).

FormDirectory'

Display0 ReadOnly0 Set0 Get0

tmDealPlace

Fill0 Find0 New0 Edit0 Save0 Delete0

DealPlaceGeteway

sqlSelect0

sqlInstrt0

sqlDelete0

sqlUpdate0

Connection0

База данных

Рис. 2. Диаграмма классов информационной системы

Edit( )

Проверить на правильность

1)

Save( )

т

Сохранить

изменения ->1

Обновить

- I

Рис. 3. Схема взаимодействия архитектурных уровней информационной системы

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

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

Рассмотренный вариант архитектуры корпоративной информационной системы является модификацией типовых проектных решений, предложенных в [2], применительно к программной платформе Microsoft.NET. Эффективность предложенного подхода апробировалась при разработке информационной

При использовании любой технологии связи и информатики очень важно знать, какой спектр оборудования можно использовать. Программное и аппаратное обеспечение ISDN для ПК удивительно разнообразно и сильно отличается по своим характеристикам [1, 2]. В целом аппаратные средства ISDN для ПК можно разделить на три основные группы: платы адаптеров, мосты/маршрутизаторы, ISDN модемы. Они имеют следующие достоинства и недостатки.

Адаптеры: имеют более высокую пропускную способность, чем у ISDN-модемов. Могут содержать разъемы POTS и встроенные устройства NT1 и обходятся дешевле модемов, мостов или маршрутизаторов. Для увеличения пропускной способности до 128 кбит/с можно использовать средства BOND («полоса пропускания по требованию»). Однако при этом имеют место некоторые трудности в настройке и конфигурировании, особенно когда в компьютере уже установлены другие сетевые платы. В качестве недостатков следует отметить, что адаптеры не поддерживают прямого взаимодействия с аналоговыми устройствами и требуют одного устройства ТА на каждого пользователя.

Мосты/маршрутизаторы: имеют более высокую пропускную способность, чем у ISDN-модемов. Часто имеются разъемы POTS и встроенные устройства NT1. Для увеличения пропускной способности до

системы внутреннего учета инвестиционных компаний - профессиональных участников рынка ценных бумаг.

Литература

1. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. СПб., 2002.

2. Фаулер М. Архитектура корпоративных программных приложений.: Пер. с англ. М., 2004.

3. Чакраборти А., Кранти Ю., Сандху Р. Дж. Microsoft®.NET Framework: разработка профессиональных проектов: Пер. с англ. СПб., 2003.

4. Постолит А.В. Visual Studio.NET: разработка приложений баз данных. СПб., 2003.

2006 г.

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

ISDN модемы: обеспечивают простое подключение к внешнему или встроенному последовательному порту. Сконструированы как стандартные модемы, использующие обычные СОМ-порты и существующее программное обеспечение. Поддерживают взаимодействие как с аналоговыми устройствами, так и с ISDN-устройствами. К недостаткам относят: невысокую производительность, при использовании низкоскоростного UART доступен только один 5-канал (64 кбит/с или меньше). Может потребоваться применение F.120 для взаимодействия с другими устройствами ISDN.

Платы адаптеров ISDN по существу представляют собой сетевые платы. В настоящее время широко доступны платы ISA, совместимые с Windows. К недостаткам плат адаптеров ISDN можно отнести то, что

Ростовский государственный экономический университет (РИНХ) 21 марта

УДК 681.3

АППАРАТНОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ISDN НА СОВРЕМЕННОМ ЭТАПЕ РАЗВИТИЯ ЭЛЕКТРОСВЯЗИ

© 2006 г. Б.П. Борисов, Р.И. Гуренко