Что такое распределенная архитектура сети. Архитектура распределенной системы управления на основе реконфигурируемой многоконвейерной вычислительной среды L-Net

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

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

Все современные программные системы можно разделить на три больших класса.

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

2. Встроенные системы, предназначенные для работы на одном процессоре либо на интегрированной группе процессоров. К ним относятся системы управления бытовыми устройствами, различными приборами и др.

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

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

Выделено шесть основных характеристик распределенных систем.

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

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

3. Параллельность. В распределенных системах несколько процессов могут одновременно выполняться на разных компьютерах в сети. Эти процессы могут (но не обязательно) взаимодействовать друг с другом во время их выполнения.

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

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

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

Разумеется, распределенным системам присущ ряд недостатков.

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

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

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

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

При обсуждении преимуществ и недостатков распределенных систем определяется ряд критических проблем проектирования таких систем (табл. 9.1).

Таблица 9.1. Проблемы проектирования распределенных систем

Проблема проектирования	Описание
Идентификация ресурсов	Ресурсы в распределенной системе располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимые им ресурсы и ссылаться на них. Примером может служить система унифицированного указателя ресурсов URL, которая определяет адреса Web-страниц. Без легковоспринимаемой и универсальной системы идентификации большая часть ресурсов окажется недоступной пользователям системы
Коммуникации	Универсальная работоспособность Internet и эффективная реализация протоколов TCP/IP в Internet для большинства распределенных систем служат примером наиболее эффективного способа организации взаимодействия между компьютерами. Однако там, где на производительность, надежность и прочее накладываются специальные требования, можно воспользоваться альтернативными способами системных коммуникаций
Качество системного сервиса	Качество сервиса, предлагаемое системой, отражает ее производительность, работоспособность и надежность. На качество сервиса влияет целый ряд факторов: распределение системных процессов, распределение ресурсов, системные и сетевые аппаратные средства и возможности адаптации системы
Архитектура программного обеспечения	Архитектура программного обеспечения описывает распределение системных функций по компонентам системы, а также распределение этих компонентов по процессорам. Если необходимо поддерживать высокое качество системного сервиса, выбор правильной архитектуры оказывается решающим фактором

Задача разработчиков распределенных систем – спроектировать программное или аппаратное обеспечение так, чтобы предоставить все необходимые характеристики распределенной системы. А для этого требуется знать преимущества и недостатки различных архитектур распределенных систем. Здесь выделяется два родственных типа архитектур распределенных систем.

1. Архитектура клиент/сервер. В этой модели систему можно представить как набор сервисов, предоставляемых серверами клиентам. В таких системах серверы и клиенты значительно отличаются друг от друга.

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

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

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

По утверждению известного специалиста в области информатики Э. Таненбаума, не существует общепринятого и в то же время строгого определения распределенной системы. Некоторые остряки утверждают, что распределенной является такая вычислительная система , в которой неисправность компьютера, о существовании которого пользователи ранее даже не подозревали, приводит к остановке всей их работы. Значительная часть распределенных вычислительных систем, к сожалению, удовлетворяют такому определению, однако формально оно относится только к системам с уникальной точкой уязвимости (single point of failure ).

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

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

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

Рис. 1.1.

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

Рис. 1.2.

Рассмотрим некое типичное приложение , которое в соответствии с современными представлениями может быть разделено на следующие логические уровни (рис. 1.2): пользовательский интерфейс (ИП), логика приложения (ЛП) и доступ к данным (ДД), работающий с базой данных ( БД ). Пользователь системы взаимодействует с ней через интерфейс пользователя, база данных хранит данные, описывающие предметную область приложения, а уровень логики приложения реализует все алгоритмы, относящиеся к предметной области .

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

Рис. 1.3.

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

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

Рис. 1.4.

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

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

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

Возрождается подход к построению распределенных систем, основанный на одноранговой архитектуре (Peer-to-Peer), при котором, в отличие от доминирующей сегодня в распределенных системах архитектуры «клиент-сервер», роли взаимодействующих сторон в сети не фиксируются. Они назначаются в зависимости от ситуации в сети, от загруженности ее узлов.

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

Создан стандарт протокола беспроводного доступа приложений в Web (Wireless Application Protocol - WAP), который уже поддерживается некоторыми моделями сотовых телефонов. На основе WAP и языка XML консорциум W3C разработал язык разметки для беспроводных коммуникаций WML (Wireless Markup Language).

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

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

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

Вероятно, первым стандартом де-факто этой категории был язык описания данных CODASYL для баз данных сетевой структуры. Из более поздних стандартов следует назвать: стандарт языка запросов SQL для реляционных баз данных, содержащий определение так называемой информационной схемы - совокупности представлений схем реляционных баз данных; компонент стандарта объектных баз данных ODMG, описывающий интерфейсы репозитория объектных схем; международный стандарт IRDS (Information Resource Dictionary Systems), описывающий системы для создания и поддержки справочников информационных ресурсов организации.

Далее следует упомянуть разработанный консорциумом OMG стандарт CWM (Common Warehouse Metamodel) представления метаданных хранилищ данных, основанный на ранее созданном для более широких целей стандарте OIM (Open Information Model) консорциума MDC (Meta Data Coalition).

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

К числу стандартов метаданных Web относится подмножество языка XML, используемое для описания логической структуры XML-документов некоторого типа. Это описание называется DTD (Document Type Definition). Кроме того, платформа XML включает стандарт XML Schema, предлагающий более развитые возможности для описания XML-документов. Стандарт RDF (Resource Definition Framework) определяет простой язык представления знаний для описания содержимого XML-документов. Наконец, разрабатываемый стандарт OWL (Ontology Web Language) определяет формальный язык описания онтологии, предназначенный для семантического Web.

Стандарт языка UML (Unified Modeling Language), обеспечивающий представление метаданных инструментов CASE для визуального объектного анализа и проектирования, разработан консорциумом OMG. Этот язык поддерживается во многих программных продуктах CASE. Консорциум OMG создал также стандарт XMI (XML Metadata Interchange) для обмена метаданными между инструментами CASE, использующими язык UML.

Следует упомянуть здесь также стандарт Дублинского ядра (Dublin Core - DC) - набора элементов метаданных для описания содержания документов различной природы. Этот стандарт быстро приобрел популярность и нашел, в частности, широкое применение в среде Web (см. разд. 3.3).

Работы по развитию существующих и созданию новых стандартов представления метаданных для АИС продолжаются. Более подробные сведения о рассматриваемых стандартах можно найти в энциклопедии.

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

Кроме того, в пределах одной компании используется множество систем для решения разных задач: ERP-система для учетных операций, отдельные инсталляции ЕСМ-систем для организационно-распорядительной документации, для проектно-сметной документации и т.д.

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

DIRECTUM предоставляет удобные инструменты для построения управляемой распределенной архитектуры организации и решения следующих задач:

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

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

Механизмы межсистемного взаимодействия (DCI)

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

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

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

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

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

Федеративный поиск

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

Федеративный поиск позволяет:

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

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

Центр администрирования служб DIRECTUM

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

Центр администрирования служб DIRECTUM — это единая точка входа администратора для конфигурирования, мониторинга и управления службами и системами DIRECTUM. Центр представляет собой сайт с инструментами управления сервером сеансов, службой Workflow, службой обработки событий, службой файловых хранилищ , службами ввода и преобразования , федеративным поиском и веб-справкой.

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

Службы останавливаются и включаются в один клик. Состояние служб моментально отображается на экране.

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

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

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

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

Исторически первыми получила широкое распространение файл-серверная архитектура, поскольку ее логика проста и перевести на такую архитектуру уже находящиеся в эксплуатации ИС –проще всего. Затем она была трансформирована в архитектуру сервер-клиент, которую можно трактовать как ее логическое продолжение. Современные системы, используемые в глобальной сети INTERNET в основном относятся к архитектуре распределенных объектов (см. Рис. III ‑15 )

ИС можно представить состоящую из следующих составных частей (Рис. III‑16)

III.03.2. a Файл-серверные приложения.

Это исторически первая распределенная архитектура (Рис. III‑17). Организуется она предельно просто: на сервере находятся только данные, а все остальное относится к клиентской машине. Поскольку локальные сети достаточно дешевы, и в силу того, что при такой архитектуре прикладное ПО автономно, такая архитектура достаточно часто используется и сейчас. Можно сказать, что это вариант клиент-серверной архитектуры, при которой на сервере находятся только файлы данных. Разные персональные компьютеры взаимодействуют только по средствам общего хранилища данных, поэтому программы, написанные в расчете на один компьютер проще всего адаптировать под такую архитектуру.

Плюсы:

Плюсы файл-серверной архитектуры:

Простота организации;

Не противоречит необходимым требованиям к БД к поддержанию целостности и надежности.

Перегрузка сети;

Непредсказуемость реакции на запрос.

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

III.03.2. b Клиент-серверные приложения.

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

В модели «тонкий клиент” вся работа приложения и управление данными выполняются на сервере. Пользовательский интерфейс в этих системах "переселяется" на персональный компьютер, а само программное приложение выполняет функции сервера, т.е. выполняет все процессы приложения и управляет данными. Модель тонкого клиента можно также реализовать там, где клиенты компьютеры или рабочие станции. Сетевые устройства запускают Internet-броузер и пользовательский интерфейс, реализованный внутри системы.

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

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

III.03.2. c Двух- и трехуровневые архитектура клиент-сервер.

Все рассмотренные выше архитектуры являются двухуровневыми. В них различается уровень клиента и уровень сервера. Строго говоря, ИС состоит из трех логических уровней:

· Уровень пользователя;

· Уровень приложения:

· Уровень данных.

Поэтому в двухуровневой модели, где задействованы только два уровня, возникает проблема с масштабируемостью и производительностью, если выбрана модель тонкий клиент, либо проблемы связанные с управлением системы, если взята модель толстый клиент. Избежать этих проблем можно, если применять модель, состоящую из трех уровней, где два из них сервера(Рис. III‑21).

Сервер данных

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

Таблица III‑5 Применение разных типов архитектур

Архитектура	Приложение
Двухуровневая тонкий клиент	1 Наследуемые системы, в которых не целесообразно разделять выполнение приложения и управление данными. 2 Приложения с интенсивными вычислениями, но малыми объемами управления данными. 3 Приложения с большими объемами данных, но малым количеством вычислений.
Двухуровневый толстый клиент	1 Приложения, где пользователю требуется интенсивная обработка данных, то есть визуализация данных. 2 Приложения с относительно постоянным набором функций пользователя, применяемых к среде с хорошо отлаженным системным управлением.
Трехуровневый сервер-клиент	1 Большие приложения с сотами и тысячами клиентов 2 Приложения, в которых часто меняются и данные и методы их обработки. 3 Приложения, в которых выполняются интеграции данных из многих источников.

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

III.03.2. d Архитектура распределенных объектов.

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

…

Диспетчер драйвер ODBC

Драйвер 1

Драйвер К

БД 1

БД К

Работа с SQL

…

Архитектура ODBC включает компоненты:

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

2. Диспетчер устройств. Он загружает драйвера по требованию приложений, предлагает единый интерфейс всем приложениям, причем интерфейс администратора ODBC одинаков и независим то того, с какой СУБД приложение будет взаимодействовать. Диспетчер драйверов, поставляемый Microsoft, является динамически загружаемой библиотекой DLL.

3. Драйвер зависит от СУБД. Драйвер ODBC – это динамическая библиотека DLL, которая реализует функции ODBC и взаимодействует с источником данных. Драйвер – это программа, которая обрабатывает запрос какой-то функции специфично для СУБД (может модифицировать запросы в соответствии с СУБД) и возвращает результат приложению. Каждая СУБД, поддерживающая технологию ODBC, должна предоставить разработчикам приложений драйвер для этой СУБД.

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

Динамическая модель

Эта модель предполагает много аспектов, для представления которых на языке UML используется как минимум 5 диаграмм см. пп. 2.04.2- 2.04.5.

Рассмотрим аспект управления. Модель управления дополняет структурные модели.

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

Можно выделить два основных типа управления в программных системах.

1. Централизованное управление.

2. Управление, основанное на событиях.

Централизованное управление может быть:

· Иерархическим - по принципу «вызов-возврат» (именно так чаще всего работает учебные программы)

· Модель диспетчера , которая применяется для параллельных систем.

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

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

Примером такого управления является организация приложений в ОС Windows.

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

Пользовательский интерфейс

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

III.03.4. a Психофизические особенности человека, связанные с восприятием и обработкой информации.

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

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

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

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

Краткосрочная память - самое узкое место в системе обработки информации человека. Ее емкость равна 7±2 несвязанных объекта. Невостребованная информация хранится в ней не более 30 секунд. Чтобы не забыть какую-нибудь важную для нас информацию, мы обычно повторяем ее про себя, обновляя информацию в краткосрочной памяти. Таким образом, при проектировании интерфейсов следует иметь в виду, что подавляющему большинству сложно, например, запомнить и ввести на другом экране числа, содержащие более пяти цифр.

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

III.03.4. b Основные критерии оценки интерфейсов

Многочисленные опросы и обследования, проводимые ведущими фирмами по разработке программного обеспечения, показали, что пользователи ценят в интерфейсе:

1)простоту освоения и запоминания - конкретно оценивают время освоения и продолжительность сохранения информации и памяти;

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

3)субъективную удовлетворенность при эксплуатации системы (удобство работы, утомляемость и т. д.).

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

С этой точки зрения на сегодняшний день наилучшими характеристиками для пользователей-профессионалов обладают интерфейсы со свободной навигацией, а для пользователей-непрофессионалов - интерфейсы прямого манипулирования. Давно замечено, что при выполнении операции копирования файлов при прочих равных условиях большинство профессионалов используют оболочки типа Far, а непрофессионалы - «перетаскивание объектов» Windows.

III.03.4. c Типы интерфейсов пользователя

Различают следующие типы пользовательских интерфейсов:

Примитивные

Со свободной навигацией

Прямого манипулирования.

Интерфейс примитивный

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

Интерфейс Меню.

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