Управление требованиями клиент-серверного программного обеспечения

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

     Важным фактором является метод взаимодействия пользователя с системой, то есть большое значение имеет пользовательский интерфейс клиентской машины. В большинстве систем клиент-сервер графическому интерфейсу пользователя (Graphical User Interface, GUI) уделяется очень серьезное внимание — он должен быть простым и удобным, но одновременно мощным и гибким. Таким образом, модуль услуг представления на рабочей станции можно считать ответственным за дружественный интерфейс с распределенными приложениями. Договорённость об особенностях интерфейса – также очень важный момент, который стоит учитывать на этапе согласования требований.

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

Функциональные  требования к клиент-сервер ПО.

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

     -Цель продукта

     -Классы  пользователей

     -Описание  функций

     -Внешний  интерфейс 

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

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

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

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

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

Системные и архитектурные требования к клиент-сервер ПО.

 

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

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

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

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

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

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

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

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

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

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

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

     

     Рис.2. Общая архитектура клиент-сервер. 

     Базы  данных.

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

     Популярным  примером такой логики является язык структурированных запросов (Structured Query Language, SQL).

     

     Рис.3. Архитектура клиент-сервер для баз данных. 

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

     Клиент-серверная  система управления базой данных может опираться на несколько  типов распределения обязанностей между клиентом и сервером:

     -«интеллектуальные» клиенты;

     -«интеллектуальный» сервер;

     -смешанные системы;

     -многоуровневые системы.  

     Схему реализации выбирают на основе анализа  требований к:

     -сетевому графику;

     -ресурсам клиента и сервера;

     -производительности базы данных. 

     «Интеллектуальные»  клиенты 

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

       
 

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

     Достоинства «интеллектуальных» клиентов

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

       Наличие хорошо известных и  достаточно мощных средств разработки (например, Visual Basic 5.0).

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