разобраться, например, с POSIX (Portable Operating System Interface, интерфейс переносимых операционных систем), OSI (Open Systems Interconnection, связь открытых систем), CORBA (Common Object Request Broker, единый брокер объектных запросов), объектно-ориентированным расширением языка SQL (SQL3), и рядом специальных решений фирм-поставщиков типа OLE (Object Linking and Embedding, связывание и внедрение объектов) фирмы Microsoft [Именно по этой причине хорошие архитекторы информационных систем получают либо громадные деньги за свое мастерство, либо - массу удовольствия от самого процесса сборки многих разрозненных технологий в одно согласованное целое].
Но на архитектурные решения оказывает влияние не только обилие стандартов. Имеют значение и такие вопросы, как защита данных, производительность системы и ее объем. Берсон предлагает архитектору несколько основных правил проектирования приложении клиент-сервер:
• Компонент логики представления обычно устанавливается там же, где и терминал ввода-вывода, то есть на компьютере конечного пользователя.
• Учитывая возросшую мощность рабочих станций, а также тот факт, что логика представления установлена на машине клиента, имеет смысл там же разместить и некоторую часть бизнес-логики.
• Если механизмы обращения к базе данных связаны с бизнес-логикой, и если клиенты поддерживают некоторое взаимодействие низкого уровня и квазистатические данные, то механизмы обращения к базе данных можно также разместить на стороне клиента.
• Принимая во внимание тот факт, что сетевые пользователи обычно организованы в рабочие группы, и что рабочая группа совместно использует базу данных, фрагменты бизнес-логики и механизмов обращения к базе данных, которые являются общими, и сама СУБД должны находиться на сервере [4].
Если нам удастся выбрать верные архитектурные решения и успешно реализовать их тактические детали, модель клиент-сервер даст системе целый ряд преимуществ. Берсон особо выделяет, что архитектура клиент-сервер:
• Позволяет более эффективно использовать новые компьютерные технологии автоматизации.
• Позволяет перенести обработку данных ближе к клиенту, что снижает загрузку сети и уменьшает продолжительность транзакций.
• Облегчает использование графических интерфейсов пользователя, которые стали доступны на мощных современных рабочих станциях.
• Облегчает переход к открытым системам [5]. Надо выделить, однако, следующие моменты риска:
• Если значительная часть логики приложения окажется вынесенной на сервер, то последний может стать узким местом системы, замедляющим работу пользователей (как это часто бывало при использовании мэйнфреймов в архитектуре хозяин-раб).
• Распределенные приложения... сложнее нераспределенных [6].
Мы уменьшим этот риск, используя объектно-ориентированный подход к разработке.
Сценарии работы
Сейчас, когда мы представили себе систему в целом, продолжим наш анализ и изучим несколько сценариев ее работы. Сначала перечислим ряд основных режимов использования:
• Клиент звонит по телефону в удаленную телемаркетинговую организацию, чтобы сделать заказ.
• Клиент посылает заказ по почте.
• Клиент звонит, чтобы узнать состояние дел по его заказу.
• Клиент звонит, чтобы добавить или убрать некоторые позиции из заказа.
• Кладовщик получает указание отгрузить клиенту необходимое количество товара.
• Служба доставки получает со склада заказанные клиентом товары и готовит их к отправке.
• Бухгалтерия готовит счет для клиента.
• Отдел закупок готовит заказ на новый товар.
• Отдел закупок добавляет или удаляет имя поставщика из списка.
• Отдел закупок запрашивает поставщика о состоянии заказа.
• Отдел приема товара принимает груз от поставщика и проверяет его соответствие заказу.
• Кладовщик заносит новый товар в список.
• Бухгалтерия отмечает прибытие нового товара.
• Плановый отдел генерирует отчет о показателях продаж по различным типам продуктов.
• Плановый отдел генерирует отчет для налоговых органов с указанием количества товаров на складах.
Каждый из основных сценариев может включать в себя ряд вторичных:
• Заказанного клиентом товара нет на складе.
• Заказ клиента неверно оформлен, или в нем присутствуют несуществующие или устаревшие идентификаторы товаров.
• Клиент звонит, чтобы проверить состояние заказа, но не помнит точно что, кем и когда было заказано.
• Кладовщик получил расходную накладную, но некоторые перечисленные в ней товары не нашлись.
• Служба доставки получает заказанные клиентом товары, но они не соответствуют заказу.
• Клиент не заплатил по счету.
• Отдел закупок делает новый заказ, но поставщик либо ушел из бизнеса, либо больше не поставляет заказанный тип товара.
• Отдел приема товара принимает груз, не полностью соответствующий заказу.
• Кладовщик хочет разместить на складе новый товар, но обнаруживается, что для него нет места.
• Изменяются налоговые коды, что вынуждает плановый отдел составить новый инвентаризационный список находящихся на складе товаров.
Для системы такой сложности, наверно, будут выявлены десятки основных сценариев и еще большее количество вторичных. Этот этап анализа может занять несколько недель, пока не удастся добиться более или менее подробного уровня детализации [Но помните о параличе анализа: если фаза анализа не укладывается в сроки, диктуемые бизнесом, то 'оставь надежду всяк сюда входящий', - этот бизнес не для вас]. Поэтому мы настоятельно советуем применять правило восьмидесяти процентов: не ждите, пока сформируется полный список всех сценариев (никакого времени на это не хватит), изучите около 80% наиболее интересных из них и, если возможно, попытайтесь хотя бы оценочно проверить правильность общей концепции. В этой главе мы подробно остановимся на двух основных сценариях.
На рис. 10-2 представлен сценарий, в котором покупатель размещает свой заказ в телемаркетинговой фирме. В выполнении этой системной функции задействовано несколько различных объектов. И хотя управление осуществляется взаимодействием клиента (aCustomer) с агентом (anAgent), есть и другие ключевые объекты, а именно: сведения о клиенте (aCustomerRecord), база данных о товарах (inventoryDatabase) и заявка на комплектование (aPackingOrder), являющиеся абстракциями системы складского учета. Этот список абстракций формируется как раз на этапе рассмотрения сценариев работы.
Рис. 10-3 отражает продолжение данного сценария. На нем представлена схема взаимодействия кладовщика и расходной накладной. Мы видим, что здесь кладовщик является главной фигурой. Он взаимодействует с другими объектами, например с отгрузкой (shipping), которой не было в предыдущем сценарии. Однако большинство объектов, фигурирующих на рис. 10-3, присутствуют также и на рис. 10-2, хотя они играют в этих сценариях различные роли. Например, в сценарии взаимодействия с клиентом мы создаем заказ (anOrder) как документ, в котором отражены требования клиента. В складском сценарии тот же самый заказ исполняется.
При составлении каждого из таких сценариев мы должны постоянно задавать себе ряд вопросов. Какой
