Файл: Общетеоретический сектор.pdf

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

2.4. Архитектурная система «клиент-сервер» использующая к БД

2.4.1. Существенные методы структурного способа

В основу функционально-модульного способа положен метод алгоритмической декомпозиции, в соответствии с которым производится секторение функций ИС на модули по функциональной принадлежности, когда каждый модуль программные детали реализует один из этапов общего процесса. Традиционный функционально-модульный способ к воспроизведению ИС предусматривает строго последовательный порядок действий (так называемая "вид водопада"). По мнению Страуструпа, [10], главный недостаток виды "водопада" заключается в склонности данных течь только в одну сторону. Если препятствие оказывается "внизу по течению", то часто возникает сильный организационный и методический нажим с целью проводить лишь ограниченные исправления и разрешить проблему без воздействия на предыдущие стадии проекта. Такая недостаточная обратная связь подводит к проектированию, ущербному во многих отношениях, а ограниченные исправления ведут к деформированным реализациям. Изменение требований к системному средству может привести к ее полному перепроектированию, поэтому препятствия, заложенные на ранних этапах, сильно сказываются на времени и конечной цене создание. Ориентация на такую последовательную вид увеличивает вероятность того, что будет утрачен контроль над решением возникающих проблем.

2.4.2. Разнородность средствов в назначенных системах

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

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

2.4.3. Положении и методы предметного способа (Классы и предметы)

Существенные понятия предметно-ориентированного способа - предмет, класс и экземпляр.

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

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

Таким образом, предмет - это типичный представитель класса, а термины "экземпляр предмета" и "элемент класса" равнозначны.

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

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

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

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

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

2.4.1. Особенности применения предметного способа

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

Класс предметов, кроме структур данных, определяет функции (методы), применимые к этим структурам.

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

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

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

сервер клиент данных предметный

2.5. Двойная уровневая архитектурная система «клиент-сервер».

Эта архитектурная система получила распространение с начала 1990-хгодов на фоне роста рынка персональных ПК и снижения спроса на мэйнфреймы. Первоначально вышеописанные программные детали базировались на классической двухуровневой клиент-серверной архитектурной системному средству (Two-tierarchitecture). Под клиент-серверными программами в этом случае понимается информационная система, основанная на использовании серверов баз данных.

Схематически такую архитектурную системную часть можно представить, как показано на рис

Классическое представление архитектуры "клиент-сервер"

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

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

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

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

Позже была разработана Положение активного ПК сервера, который использовал механизм хранимых процедур. Это позволило сектор прикладного компонента перенести на сервер (вид распределенного приложения). Процедуры хранятся в словаре БД, секторяются между несколькими владельцами и выполняются на том же ПК, что и SQL-сервер.

Преимущества такого способа:

-возможно централизованное администрирование прикладных функций,

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

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

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

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

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

Это подводит к идее поддержки локального кэша общей БД на стороне каждого владельца. Фактически, Положение локального кэширования БД является частным случаем Положении реплицированных баз данных. Как и в общем случае, для поддержки локального кэша БД ПО рабочим станциям должно содержать компонент управления базами данных – упрощенный вариант ПК сервера баз данных, который, например, может не обеспечивать многопользовательский режим способа.

Отдельной проблемой является обеспечение согласованности (когерентности) кэшей и общей БД. Здесь возможны различные решения – от автоматической поддержки согласованности за счет средств базового программного обеспечения управления базами данных до полного перекладывания этой задачи на прикладной степень.

Преимуществами данной архитектуры являются: