2 Выбор метода решения задачи icon

2 Выбор метода решения задачи




Скачати 53.98 Kb.
Назва2 Выбор метода решения задачи
Дата19.08.2012
Розмір53.98 Kb.
ТипДокументи

2 Выбор метода решения задачи


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

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

Обычно выделяют следующие уровни (рис 2.1):

  • презентационная логика (Presentation Layer - PL), включающая уровень представления;

  • бизнес-логика (Business Layer - BL), включающая уровень прикладной и принятия решения;

  • логика доступа к ресурсам (Access Layer - AL).




Рисунок 2.1 — Уровни приложений


Уровень представления отвечает за обеспечение интерфейса системы.

^ Уровень прикладной и принятия решения реализуют правила и процедуры в форме решений в трех обширных категориях:

  • формальные решения подразумевают точные запросы на проверку полномочий. Лежит ли эта транзакция в пределах кредита, отведенного клиенту? Может ли заказ быть отправлен в четверг? В этих случаях процесс на уровне бизнес – логики принимает определенное решение или отвечает на поставленный вопрос;

  • решения по проведению политики подразумеваются и являются безоговорочными. Например:

  • информацию о клиентах, которые имеют неоплаченные счета, нельзя удалять из БД;

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

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

  • принимать заказы только при наличии необходимой продукции на складе;

  • прекращать регистрацию на семинар, когда не осталось свободных мест;

  • управлять расписанием поставок в целях оптимизации времени доставки.

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

Таким образом, можно прийти к нескольким моделям клиент-серверного взаимодействия:

  1. "Толстый" клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении PL и BL уровней. Серверная часть, при описанном подходе, представляет собой сервер баз данных, реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access.

В этой системе клиент-сервер для запуска приложений необходимо, чтобы клиентское ПО было заранее установлено.

  1. "Тонкий" клиент. Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.

В архитектуре с “тонким” клиентом специализированное программное обеспечение не обязательно устанавливать на клиенте, поскольку исполняемые компоненты могут загружаться с Web-сайта для последующего взаимодействия с клиентом. Таким образом, “тонкий” клиент получает два ключевых преимущества при работе в сети: универсальный доступ и уменьшение затрат на инсталляцию и управление. Однако, из-за наличия браузеров и HTML, тонким клиентам для динамического управления бизнес-приложениями необходимо использование дополнительных средств, таких как Java-апплеты и элементы управления ActiveX.

  1. ^ Сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL.

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

С точки зрения применения описанных моделей, при проектировании прикладных систем разработчик часто сталкивается с правилом 20/80 [21]. Суть этого правила заключается в том, что 80% пользователей обращаются к 20% функциональности, заложенной в систему. Оставшиеся 20% задействуют основную бизнес-логику — 80%. В первую группу пользователей попадают операторы информационных систем (ввод и редактирование информации), а также рядовые сотрудники и менеджеры, обращающиеся к поисковым и справочным механизмам (поиск и чтение данных). Во вторую группу пользователей попадают эксперты, аналитики и менеджеры управляющего звена, которым требуются как специфические возможности отбора информации, так и развитые средства ее анализа и представления.

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

Любая прикладная система, вне зависимости от выбранной модели взаимодействия, требует такой инструментарий, который бы смог существенно ускорить сам процесс создания системы и, одновременно с этим, обеспечить прозрачность и наращиваемость кода. На фоне разработки и внедрения систем корпоративного масштаба явно присутствует тенденция использования объектно-ориентированных компонентных средств разработки [16]. Соответственно, полноценное применение объектов в распределенной клиент-серверной среде требует и распределенного объектно-ориентированного взаимодействия, то есть возможности обращения к удаленным объектам.

При построении реальных систем корпоративного масштаба уже мало обходиться их разделением на три базовых фрагмента PL, BL и AL. Так как бизнес-логика является блоком, наиболее емким и специфичным для каждого проекта, именно ее приходится разделять на более мелкие составляющие. Такими составляющими могут быть, например, функциональные компоненты обработки транзакций (Transaction Process Monitoring), обеспечения безопасности (Security), отбора и анализа данных в процессе принятия решений (Decision Support), асинхронного уведомления о событиях (Event Alerts), тиражирования данных (Replication), почтового обмена (Mailing) и др. Вследствие наличия такого огромного количества функций, закладываемых в блоки поддержки бизнес-логики, появляется понятие сервера приложений (Application Server - AS). Причем сервер приложений не просто является неким единым универсальным средним BL-звеном между клиентской и серверной частью системы, но существует во множественном варианте, как частично изолированные приложения, выполняющие специальные функции, обладающие открытыми интерфейсами управления и поддерживающие стандарты объектного взаимодействия. Проникновение информационных технологий в сферу бизнеса в качестве неотъемлемого условия успешного управления приводит к тому, что системы корпоративных масштабов требуют сочетания различных клиент-серверных моделей в зависимости от задач, решаемых на различных направлениях деятельности предприятия. Вспомнив о правиле 20/80, можно придти к выводу, что наиболее оптимальным выбором, с точки зрения управляемости и надежности системы, является сочетание различных моделей взаимодействия клиентской и серверной части. По сути, мы приходим даже не к трехуровневой, а многоуровневой (N-tier) модели, объединяющей различных по "толщине" клиентов, серверы баз данных и множество специализированных серверов приложений, взаимодействующих на базе открытых объектных стандартов. Существенным облегчением в реализации многоуровневых гетерогенных систем является активная работа ряда производителей программного обеспечения, направленная на создание переходного ПО. В отличие от продуктов middleware, обеспечивающих верхний транспортный уровень (универсальные интерфейсы доступа к данным ODBC, JDBC, BDE; Message Oriented Middleware — MOM; Оbject Request Broker — ORB), переходное ПО отвечает за трансляцию вызовов в рамках одного стандарта обмена в вызовы другого —- мосты ODBC/JDBC и BDE/ODBC, COM/CORBA, Java/ActiveX и т. п.

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

Схожі:

2 Выбор метода решения задачи iconА. А. Литвиненко, доц
Предлагается алгоритм численного метода решения систем обыкновенных дифференциальных уравнений (задачи Коши), представляющий собой...
2 Выбор метода решения задачи icon1. Работа посвящена проблеме создания системы управления технологическим процессом производства сложных минеральных удобрений
Информационный обзор существующих технологий решения этой задачи показывает, что нейросетевая технология является одним из наиболее...
2 Выбор метода решения задачи iconОсобенности решения обратной задачи в спектроэллипсометрических исследованиях в. Д. Карпуша, канд физ мат наук, доц.; У. С. Швец, асп
Целью настоящей работы является изучение особенностей применения метода спектральной эллипсометрии в исследовании оптических свойств...
2 Выбор метода решения задачи icon6 задачи и решения
Исходя из условия задачи, можем в качестве (x0,y0,z0) использовать (6; 9; – 2). Далее заметим, что у двух параллельных плоскостей...
2 Выбор метода решения задачи iconАлгоритм муравья для решения задачи коммивояжера
Для кооперации агенты используют «фермент», оставляемый на гранях транспортной сети, в процессе поиска оптимального решения. Алгоритм...
2 Выбор метода решения задачи iconРешение прямой задачи представлено следующими симплекс-таблицами: бп
Получение оптимального решения двойственной задачи с помощью симплекс-таблиц прямой задачи
2 Выбор метода решения задачи iconРешение прямой задачи представлено следующими симплекс-таблицами: бп
Получение оптимального решения двойственной задачи с помощью симплекс-таблиц прямой задачи
2 Выбор метода решения задачи iconМетодические указания для студентов V и VI курса медицинских вузов Запорожье 2000
Научиться на основании данных анамнеза, основных методов обследования (эндоскопии, рентгенологического метода, изучение желудочной...
2 Выбор метода решения задачи iconТактический алгоритм: «Выбор метода лечения кариеса временных и постоянных зубов (вз и пз) у детей»

2 Выбор метода решения задачи iconРешение по методу Денавита Хартенберга было очень громоздким и потому решили его упростить. Как известно, решение прямой задачи намного проще решения обратной, потому очертим метод решения только обратной задачи
Украине внедряются разные типы роботов и станков. Это позволяет предприятиям уменьшить процентное соотношение брака продукции и увеличить...
Додайте кнопку на своєму сайті:
Документи


База даних захищена авторським правом ©zavantag.com 2000-2013
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи