    ГЛАВА 7

    Проектирование приложения архитектуры клиент/сервер 

    Пакет Silverrun, использованный при изложении материала глав 6, 7 и 8, — 
один из многих систем такого рода, предназначенных для поддержки разработки 
программ в Delphi. Выбор этого пакета в качестве примера является личным 
решением автора и не означает какого-либо одобрения со стороны компании Borland. 
    В главе 6, "Проектирование базы данных архитектуры клиент/сервер", были 
перечислены пять этапов процесса создания приложения базы данных. Перечислим 
их снова, чтобы освежить в памяти. 
    Q Определение назначения и функций приложения. 
    Q Проектирование функциональности приложения и процессов, необходимых для 
реализации этой функциональности. 
    Q Воплощение проекта в реальное приложение путем создания необходимых 
программных объектов и объектов базы данных. 
    Q Тестирование приложения на предмет его соответствия назначению и 
правильность функционирования. 
    Q Настройка и установка приложения для его использования. 
    В главе 6 эти этапы были показаны с точки зрения проектирования базы 
данных. Эта глава посвящена описанию их связи с проектированием приложения. 
Так как оба процесса (проектирование приложения и проектирование базы данных) 
тесно взаимосвязаны, точно определить, где заканчивается один процесс и 
начинается другой, невозможно. Разработку приложения базы данных можно 
сравнить с таблицей, состоящей из двух столбцов, первый из которых — процесс 
проектирование базы данных, а второй — процесс проектирования приложения. 
Строками такой таблицы являются пять вышеназванных этапов. Аналогии могут быть 
различными, главное — понимание тесной взаимосвязи процессов проектирования 
базы данных и приложения. 
    Давайте продолжим работу с той точки, где мы остановились в главе 6, и 
рассмотрим, как пять основных этапов разработки применяются в проектировании 
приложения базы данных. 

    На заметку 
    Для создания приложений архитектуры клиент/сервер существует немало широко 
известных методик. Эти методики идут дальше моделирования базы данных и 
приложения и рассматривают весь процесс создания надежных систем клиент/сервер 
в целом. В качестве примера можно привести методику Rational-Booch, методику 
SAFE, разработанную компанией Sybase, и др. Хотя задача их описания выходит за 
рамки данной книги, все же они заслуживают того, чтобы обратить на них самое 
пристальное внимание. Проектирование приложений архитектуры клиент/сервер — 
это не просто разработка пользовательского интерфейса. Это процесс намного 
более сложный, чем создание базы данных или связывание объектов друг с другом 
в единую систему. Лучшие разработчики систем клиент/сервер придерживаются 
методик, согласно которым разработка, тестирование и совершенствование 
приложения рассматриваются как единое целое. 

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

    Глава 7. Проектирование приложения архитектуры клиент/сервер 141 


    Проектирование базы данных и процессов предметной области 

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

    Некоторые соображения о разработке программного обеспечения 

    Прежде чем мы приступим к собственно проектированию приложения, я бы хотел 
поделиться своими мыслями по поводу разработки программного обеспечения. Из-за 
этого мы немного уклонимся от основной темы данной книги, но я думаю, что 
предмет достаточно важен, так как позволяет взглянуть на излагаемый материал с 
высоты "птичьего полета". 
    На мой взгляд, в разработке приложений нет "правильных" и "неправильных" 
подходов. Не существует единой системы, согласно которой можно было бы создать 
любое приложение любого класса. Подобно шеф-повару, который работает не только 
на основании рецептов из поваренной книги, но и на основе своего опыта, 
фантазии и интуиции, так и программист постоянно принимает решения — что он 
будет делать "по книге", а что "по-своему". Целью является поиск подхода, 
лучшего для вас и доказавшего свою работоспособность на практике. 
    Большинство людей считает разработку программного обеспечения наукой. 
Некоторые считают эту область человеческой деятельности не лишенной элемента 
творчества, но, тем не менее, все же являющейся наукой. В конце концов, 
выпускникам колледжей США присваивают звания бакалавров наук (B.S., Bachelor 
of Sciences), а не бакалавров искусств (В.А., Bachelor of Arts). Да и сама 
дисциплина в университетах США называется "Компьютерная наука" (Computer 
Science), а не "Компьютерное искусство" (Computer Art). Однако я всегда 
придерживался той точки зрения, что разработка программ — это в большей 
степени искусство или, если хотите, ремесло, чем наука. Различие между 
искусством и ремеслом заключается в утилитарности последнего — продукты труда 
ремесленника предназначены для практического использования, а произведения 
художника — для эстетического удовольствия. 
    Подобно столярам, гончарам и другим ремесленникам, разработчики 
программного обеспечения для того, чтобы получить нужные результаты, должны 
выполнять определенные физические законы. Гончар, например, должен знать 
физические свойства глины, иначе его изделия будут бракованными. Столяр, не 
знающий, как использовать уровень, не сможет точно выдержать размеры и углы 
создаваемой им мебели. Однако на этом влияние науки на их работу практически 
заканчивается. Гончар может сотворить из глины все, что он пожелает, и при 
этом мы будем называть его произведение "гончарным изделием". Столяр также 
может проявить фантазию, но, тем не менее, что бы он ни создал, мы назовем это 
"мебелью". Как работает ремесленник — голыми руками, молотком и пилой или с 
помощью инструментов, которые он сам придумал, — для нас не имеет никакого 
значения. Главное — это творение мастера, а не подход, которым он пользовался. 
Нет "правильного" подхода к созданию кувшинов и мисок. Нет единственного и 
неукоснительно соблюдаемого подхода к созданию столов и стульев. Качество 
получаемых изделий зависит не от подхода, а от мудрости, опыта и интуиции 
ремесленника. Все это распространяется и на разработку программ. 
    Сегодняшнее состояние дел в области разработки программного обеспечения 
напоминает мебельную промышленность середины 19-го века. С незапамятных времен 
мебель создавалась столярами от начала до конца по отдельным деталям. В 
небольших цехах работало несколько высококвалифицированных мастеров, каждый из 
которых изготавливал свои изделия самостоятельно, вплоть до самых мелких 
деталей. Так как каждая такая деталь создавалась и подгонялась вручную, 
точность была великолепной. Поэтому мастера подписывали все, что они делали, в 
знак гордости за свою работу, давая тем самым гарантию ее качества. 
    Грянула промышленная революция, и на смену мастерству пришли клей и скобы, 
а качество было вытеснено низкой ценой. Для того чтобы ускорить производство 
мебели, были разработаны упрошенные ме-

    142 Часть I. Основы 

ханизированные процессы. Ремесло превратилось в промышленное производство, 
и на смену старым мастерам пришли рабочие конвейера. 
    Такое мышление сборочно-конвейерного типа сегодня превалирует в 
большинстве отраслей человеческой деятельности. В этом есть неоспоримые 
достоинства, но есть и явные недостатки. Достоинством является то, что большая 
часть товаров сегодня дешевле, чем когда бы то ни было. Однако, какой ценой? 
Что нам было нужно — качественные товары по умеренной цене или не очень 
качественные дешевые товары? И не привело ли вырождение ремесла к тому, что 
по-настоящему хорошие изделия стали не дешевле, а еще дороже? 
    Какое отношение все вышесказанное имеет к разработке систем клиент/сервер? 
Самое прямое. Помните, все началось с того, что из ремесла удалили все 
операции, требующие мастерства, и упростили его до набора примитивных 
механических действий, которыми мог овладеть любой человек. Большую часть 
работы стали выполнять машины. Следствием этого стали неизбежное снижение 
качества товаров и всякое подавление нововведений. Разработку программного 
обеспечения, по-видимому, ожидает та же судьба. Течения, утверждающие, что 
есть "правильные" и "неправильные" подходы к разработке приложений, подавляют 
в ремесленниках от программирования свободу мышления, что неизбежно отражается 
на их созданиях. Это ограничивает творчество и практически не оставляет места 
для нововведений. Разработка программ не может не носить творческого 
характера. В труде программиста всегда должно быть место изобретательности. 
Именно поэтому я утверждаю, что нет "правильных" подходов в труде 
программиста, как их нет в труде гончара или столяра. Не существует набора 
правил, согласно которым в любой ситуации можно было бы создать качественное 
приложение любой сложности. Секрет ремесла программиста не в том, чтобы делать 
вещи "хорошим" способом, а в том, чтобы делать хорошие вещи. 
    Итак, приступая к описанию создания приложения архитектуры клиент/сервер, 
я призываю вас не рассматривать эту и предыдущую главы как догматы, 
предписывающие выполнять разработку этих приложений таким и только таким 
способом. Все, что вы почерпнете из данной книги, — только один из возможных 
подходов к решению задач такого рода, не больше и не меньше. Если он вас 
устраивает — используйте его, если нет — выработайте собственный. 

    Выбор типа приложения 

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

    Схема производственных процессов приложения 

    Для того чтобы создать модель, спроектированную на этапе разработки базы 
данных, нужно изобразить все процессы приложения в виде схемы. Для 
моделирования процессов приложения существует несколько CASE-средств. 
Некоторые из них позволяют создавать такую модель на базе модели сущностей и 
связей и реляционной модели, разработанных во время проектирования объектов 
баз данных. Другие — содержат прямую поддержку Delphi. К последним относятся, 
например, система Silverrun-RDM и PowerDesigner (в предыдущей версии — 
S-Designor) AppModeler for Delphi. He забывайте, что моделировать элементы 
приложения можно и не прибегая к помощи каких-либо CASE-средств. Независимо от 
выбранного подхода, во время моделирования нужно решить следующие задачи. 
    Q Составить перечень всех форм проектируемого приложения. 
    Q Составить перечень всех отчетов и других видов выходной информации приложения. 
    Q Связать эти элементы с элементами данных ранее разработанных моделей. 
    О Составить перечень потоков данных, пересылаемых между формами и 
отчетами, а также между процессами. 
    Q Определить независимые вспомогательные подпрограммы (т.е. не связанные с 
какими-либо формами или отчетами), необходимые для обслуживания приложения. 
    На рис. 7.1 и 7.2 представлены две модели процессов различных приложений. 

    Глава 7. Проектирование приложения архитектуры клиент/сервер 143 


    Рис. 7.1. Простая предварительная модель приложения RENTMAN 

    Рис. 7.2. Пример модели приложения 

    Часть I. Основы 144 


    Генерация приложения 

    Если вы используете CASE-средство, в котором предусмотрена генерация 
исходного текста программ по разработанной модели, то нет никаких причин 
отказываться от такой генерации, по крайней мере, для части приложения. Время, 
которое вы сэкономите при этом, зависит от используемого CASE-средства. 
Например, система Silverrun-RDM генерирует наборы атрибутов, которые затем 
можно использовать в системе Delphi при разработке приложения. В системе 
PowerDesigner AppModeler for Delphi применен другой подход — она генерирует 
все приложение, включая исходный текст форм, отчетов и вспомогательных подпрограмм. 

    Проектирование иерархии форм и отчетов 

    После определения форм и отчетов будущего приложения нужно разработать 
иерархию этих форм и отчетов. Наличие такой иерархии позволит вам впоследствии 
воспользоваться наследованием объектов форм, поддерживаемых языком Object 
Pascal и средствами Delphi. Другими словами, нужно разбить формы и отчеты на 
классы, основывающиеся друг на друге. Например, можно определить форму 
приложения, на основе которой будут построены все остальные формы. Если вам 
впоследствии понадобиться изменить атрибуты всех форм, для этого достаточно 
будет модифицировать только форму верхнего уровня. То же самое касается и 
иерархии отчетов. Так как, по-видимому, большую часть отчетов вы будете 
создавать на основе компонентов семейства QuickReport Delphi, имеет смысл 
построить иерархию отчетов именно на его основе. 

    Определение вспомогательных подпрограмм 

    Завершив создание иерархии форм и отчетов, постарайтесь заранее 
определить, понадобятся ли вам какие-либо библиотеки. В случае положительного 
решения нужно выбрать конкретную библиотеку, подходящую для использования в 
вашем приложении. В качестве примеров таких библиотек могу назвать Orpheus 
Visual Component Library и Asynch Professional, разработанные компанией 
TurboPower Software. Если вы являетесь участником крупного проекта, выясните 
у руководителя проекта или менеджера по обеспечению ресурсами, какие 
библиотеки утилит уже разработаны и эксплуатируются в организации. Когда вы 
решите, какие процессы будут использовать формы, а какие — процедуры, не 
имеющие визуального представления, сразу же обязательно нужно решить вопрос об 
использовании вспомогательных библиотек. Если отложить его до тех пор, пока 
эти библиотеки вам понадобятся для тестирования приложения, то может 
выясниться, что из-за непредусмотренной несовместимости вам придется 
переделывать все приложение. 

    Технологический план 

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

    Производственный план 

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

    Глава 7. Проектирование приложения архитектуры клиент/сервер 145 

    Создание приложения 

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

    Проектирование форм 

    Подход, применяемый к проектированию форм в основном зависит от типа 
разрабатываемого приложения и типа самих форм. В приложениях баз данных 
архитектуры клиент/сервер как правило используются три типа форм —поддержки 
решения, обработки транзакций и ввода данных. Каждый из этих типов сильно 
отличается от остальных. Именно из-за этого различия еще на этапе 
проектирования приложения нужно четко представлять, какие формы будут 
использоваться в приложении для тех или иных целей. Как говорится: "Если план 
не удался — неудача запланирована". 
    Ниже приведены некоторые рекомендации общего характера о проектировании 
форм. Как и все остальные рекомендации в этой книге, они носят субъективный 
характер — вы вольны использовать или не использовать их в своей работе. 
Рекомендации разбиты на четыре группы: общие рекомендации для всех форм, 
рекомендации для форм принятия решения, рекомендации для форм обработки 
транзакций и рекомендации для форм ввода данных. 
    Q Выберите стиль. Одним из важных решений, которые надо принять как можно 
раньше, является стиль оформления визуального представления будущего 
приложения. Выбранный стиль влияет на вид всех форм, образующих интерфейс 
приложения. В мире приложений для Windows широкое распространение получили три 
основных стиля. Это стили пакетов CorelDRAW, Lotus SmartSuit и Microsoft 
Office. Если вы выберите стиль Corel (рис. 7.3), интерфейс вашего приложения 
будет напоминать интерфейс CorelDraw 7 и WordPerfect. В случае выбора стиля 
Lotus (рис. 7.4), вид приложения будет подобен интерфейсу Lotus 1-2-3 и 
WordPro. Если же вам больше по душе оформление Microsoft (рис. 7.5), то 
интерфейс ваших программ будет похож на интерфейс Word и Excel. 
    
    Рис. 7.3. Интерфейс CorelDraw 7 
    146 Часть I. Основы 


    Рис. 7.4. Интерфейс Lotus SmartSuite 

    Рис. 7.5. Интерфейс Microsoft Office 


    Глава 7. Проектирование приложения архитектуры клиент/сервер Стр 276 Разд 1 

    Одна из основных причин выбора одного из популярных стилей заключается в 
том, что пользователям нравится преемственность интерфейсов приложений, 
облегчающая освоение новых приложений. Кроме того, подражание пользовательским 
интерфейсам, разработанным лидирующими компаниями, придает вашим приложениям 
более профессиональный вид. 
    Q Не перенасыщайте формы ненужной информацией. Отображение слишком 
большого количества данных на форме приводит только к потерям времени как 
пользователя, так и разработчика. Поставьте себя на место пользователя и 
постарайтесь определить, что вам как пользователю по-настоящему нужно от 
приложения, а что является избыточным. Часто бывает, что те или иные элементы 
интерфейса указывают только на то, с помощью какой функции они были созданы. 
Пользователю же нужно не восторгаться ежеминутно обширным познаниям 
программиста, а выполнять свою работу, поэтому они хотят видеть такие формы, 
назначение каждого элемента которых было бы интуитивно понятным. 
    Q Создайте иерархии форм и отчетов, чтобы в полной мере использовать 
преимущества наследования визуальных форм Delphi. Создайте базовую форму 
приложения, от которой будут наследоваться все остальные формы. Если 
впоследствии вам понадобится внести однотипные исправления во все формы 
приложения, для этого достаточно будет подправить только базовую форму 
иерархии. Это касается и отчетов — так как, скорее всего, все они будут 
базироваться на компонентах семейства QuickReport Delphi, для них также можно 
создать свою иерархию. 
    Q Проявляйте последовательность как во внутреннем устройстве приложения, 
так и в его визуальном представлении. Последовательность во внутреннем 
устройстве означает сохранение единого стиля программирования всех форм. В 
этом вам поможет применение иерархии форм. Последовательность в визуальном 
представлении — сохранение единого стиля приложения в целом. Именно по этой 
причине я рекомендую вам выбрать стиль как можно раньше. Шрифты, цвет фона, 
размер визуальных элементов, размещение панелей инструментов и т.п. — все это 
должно соответствовать тем или иным правилам оформления приложений для Windows. 
    О Создавайте формы в стиле SDI, а не MDI. Были времена, когда формы MDI 
(Multiple-Document Interface — многодокументный интерфейс) превалировали над 
формами SDI (Single-Document Interface — однодокументный интерфейс). К 
счастью, маятник качнулся в противоположном направлении, и сегодня компания 
Microsoft рекомендует разработчикам придерживаться соглашений SDI. Это только 
общее направление и приложениям MDI, безусловно, также найдется место. Однако 
сегодня интерфейс SDI приобретает все большую популярность. 
    Q Старайтесь разрабатывать формы так, чтобы на них была представлена 
однотипная информация. Например, не следует на одной форме показывать данные 
счетов-фактур и квитанций об оплате. Форма должна быть настолько простой, 
насколько это возможно. В большинстве случаев каждая форма должна отображать 
документ только одного типа. 
    Q В тех случаях, когда это возможно, используйте диалоговые окна Windows 
общего назначения. Неразумно возиться с собственными диалоговыми окнами 
открытия и сохранения файлов, если они уже есть в Windows. Все диалоговые окна 
общего назначения представлены в Delphi в виде простых и удобных в 
использовании компонентов. Везде, где это возможно, используйте такие 
компоненты для экономии своего времени и сохранения ресурсов системы. 
Компоненты Delphi, представляющие диалоговые окна общего назначения, находятся 
на вкладке Dialogs палитры компонентов. 
    Q Используйте для фона форм нейтральные цвета (например, clBtnFace, 
который по умолчанию соответствует серому цвету). Это придаст вашему 
приложению более профессиональный вид, не будет вызывать у пользователей 
раздражения и обеспечит правильное отображение, независимо от типа 
видеоадаптера и монитора. 
    Q Для визуализации режима, в котором работает многорежимное приложение, 
пользуйтесь компонентами Toolbar и SpeedButton. Группу компонентов SpeedButton 
можно с помощью свойства Grouplndex настроить таким образом, чтобы 
представляемые ими кнопки панели инструментов вели себя подобно 
кнопкам-переключателям бытового магнитофона: как только нажимается одна 
кнопка, вторая тут же отключается. Для этого нужно присвоить свойствам 
Grouplndex данных компонентов ненулевые значения, а свойству AllowAlIUp — 
значение False. Если многорежимное приложение в каждый момент времени может 
работать только в одном режиме, переключаясь из одного режима в другой, то 
данные компоненты являются очень удобным средством как для обеспечения 
переключения между режимами, так и для отображения текущего режима. Обратите 
также внимание на свойство Down компонента SpeedButton, с помощью которого 
кнопка может появляться сразу в нажатом состоянии. 

    148 Часть I. Основы 

    Q Облегчите жизнь пользователям — сделайте кнопки достаточно большими, 
чтобы им было удобно работать с мышью. 
    Q Для каждой кнопки формы создайте отдельные команды подменю в главном 
меню приложения, а для каждой команды, которой нет на форме — вложенные меню. 
Пользователи, предпочитающие работать с клавиатурой, а не с мышью, скажут вам 
за это большое спасибо. Кроме того, назначьте основным командам меню 
приложения клавиатурные эквиваленты — это также существенно поможет 
пользователям в работе с приложением. 
    Q Используйте комбинации клавиш для ускорения доступа к основным командам 
меню. Если вы хотите добавить такую комбинацию клавиш, не связывая ее с той 
или иной командой, сначала создайте фиктивный пункт меню и назначьте ему 
нужную комбинацию клавиш с соответствующим программным кодом в обработчике 
события OnClick. Затем сделайте элемент меню невидимым во время выполнения, 
установив с помощью окна Object Inspector его свойство visible равным значению 
False. Когда приложение запустится, комбинация клавиш будет срабатывать, хотя 
соответствующего пункта в меню не будет. 
    Q Для основных полей формы назначьте клавиши мнемонического доступа. Для 
этого сначала определите такие клавиши с помощью свойства Caption компонента 
Label (соответствующая буква в тексте заголовка выделяется путем применения 
перед ней символа &). Затем установите "свойство FocusControl компонента Label 
равным имени компонента, который должен получать фокус ввода при нажатии 
пользователем соответствующей клавиши мнемонического доступа. 
    О Размещение и функции объектов-навигаторов должны быть неизменными во 
всех формах и приложениях. Если на одной форме вы разместите компонент 
DBNavigator в верхней ее части, а на другой — в нижней, то это нарушит 
единообразие приложения и может запутать пользователей. Лучше всего размещать 
компоненты, выполняющие в разных формах одни и те же функции, в одном месте. 
    Q Используйте на всех кнопках один и тот же шрифт. Это позволит придать 
всем вспомогательным элементам пользовательского интерфейса вид, не 
раздражающий пользователей своей пестротой. Если пользователям приходится 
останавливаться, чтобы, прищурившись, разбирать надписи на кнопках, — значит, 
вы с этой задачей не справились. Лучше сделать кнопки крупнее, чем экономить 
каждый миллиметр пространства формы. 
    Q На мой взгляд рубленые шрифты (например, Arial) воспринимаются лучше, 
чем шрифты с засечками (типа Times New Roman), поэтому старайтесь не применять 
последних в своих формах. 
    Q Используйте всплывающие подсказки — небольшие надписи, поясняющие 
назначение соответствующего элемента, которые появляются, если указатель мыши 
задерживается на этом элементе на пару секунд. Особенно полезны такие 
подсказки для кнопок панелей инструментов. 
    Q Включите в комплект поставки приложения интерактивную справочную 
информацию. Профессиональные приложения для Windows всегда снабжены 
полнофункциональными справочными базами данных, которые позволяют 
просматривать нужную информацию с помощью перекресных ссылок. Кроме того, 
нужно настроить формы таким образом, чтобы пользователь мог обратится к 
контекстнозависимой справке. Это достигается с помощью свойства HelpContext 
формы и ее элементов управления. При обращении к справочной системе Windows 
она автоматически переходит к той теме справки, которая определена с помощью 
свойства HelpContext элемента управления, обладающего в этот момент фокусом 
ввода. Более подробно о разработке справочных файлов для Windows говорится в 
главе 13, "Последние штрихи". 
    О Создайте форму About, в которую поместите информацию о названии 
приложения, номере его версии, а также названии вашей компании и (или) имя 
автора приложения. Кроме того, с помощью этой формы можно отображать сведения 
о номере телефона технической поддержки и принадлежности авторских прав, а 
также информацию об используемых ресурсах Windows. Название продукта, номер 
версии и извещение об авторских правах нужно связать с приложением с помощью 
ресурса Windows VERSIONINFO. Более подробная информация по этому вопросу 
приводится в главе 13. 
    Q Используйте в приложениях панели инструментов. Такие панели являются 
неотъемлемой частью трех вышеназванных стилей оформления приложений. Более 
того, наличие панелей инструментов — это стандарт де-факто в современных 
приложениях для Windows. В Delphi для этих целей существуют два компонента — 
TToolbar и TCoolbar. Кроме того, такие панели можно создать самому, размещая 
компоненты TSpeedButton на компонентах TPanel. 

    Глава 7. Проектирование приложения архитектуры клиент/сервер 149 

    Q Создайте в приложении строку состояния. Для этого можно воспользоваться 
компонентом StatusBar, расположенным на вкладке Win95 палитры компонентов. 
    Q На формах, предназначенных для ввода данных, устанавливайте поля ввода, 
выбранные по умолчанию. Это достигается путем присвоения свойству TabOrder 
нужного компонента поля значения 0. 
    Q Для размещения большого количества элементов управления на ограниченном 
пространстве формы, используйте многостраничные диалоговые окна и вкладки. 
Такие окна являются стандартными в Windows 95, хотя в продуктах Borland они 
появились еще раньше. 
    Q Назначьте приложению легкоузнаваемую уникальную пиктограмму. Хотя это и 
не имеет отношения к формам, но, тем не менее, имеет отношение к 
пользовательскому интерфейсу. Пиктограмма приложения появляется в окне 
Explorer (Проводник) Windows, а также в окне быстрого переключения при нажатии 
<Alt+Tab>, поэтому пользователи по виду этой пиктограммы должны легко 
идентифицировать приложение. В Delphi назначение пиктограммы выполняется с 
помощью команды Project=>Options=>Application. 
    Q Разрабатывайте формы, установив самое низкое разрешение экрана из тех, с 
которым работают пользователи вашего приложения. Скорее всего это дисплей VGA, 
поэтому без опасения можно использовать разрешение 640х480. Если не учитывать 
этого, то может случиться так, что формы, выглядевшие нормально на экране 
вашего дисплея, будут уходить за пределы экрана на дисплее, работающего с 
более низкой разрешающей способностью. 
    Q Применяйте во всех формах единообразные шрифты. Используйте мелкие 
системные шрифты 96 dpi или крупные системные шрифты 120 dpi, но не смешивайте 
их в одном приложении. Кроме того, формы лучше масштабируются в сторону 
увеличения, чем в сторону уменьшения, поэтому разработка форм с форм-фактором 
96 dpi будет давать более приемлемые результаты на компьютерах, в которых 
используется режим крупных шрифтов, чем в случае отображения форм с крупными 
шрифтами на компьютерах, в которых используется режим мелких шрифтов. Если вы 
не хотите, чтобы формы масштабировались, установите значение свойства Scaled 
форм равным False (по умолчанию установлено значение True). Если же вы решили 
включить режим масштабирования (что лучше), присвойте свойству AutoScroll 
значение False. 
    Q Не объясняйте в интерактивной справке элементарных вещей. В большинстве 
случаев приложения должны быть понятны и без чтения руководств и обращения к 
справочной системе. 
    Q Как можно быстрее создайте прототипы форм и представьте их заказчику, 
чтобы он мог высказать свои соображения по поводу пользовательского 
интерфейса. Я считаю что в этом смысле Delphi — идеальная система. Часто я 
разрабатываю прототипы форм прямо на глазах у заказчика. 

    Формы поддержки решений 

    Формы, используемые в приложениях поддержки принятия решений, обычно 
предназначены для тех пользователей, которые, не всегда являясь образцами 
компьютерной грамотности, тем не менее, имеют гораздо больший вес в 
организации, чем все остальные пользователи. Приложения поддержки принятия 
решений им нужны не для развлечения, а потому, что в круг обязанностей этих 
людей входит именно принятие решений. Согласно книге Скотта Адамса (Scott 
Adams), The Dilbert Principle, уровень компьютерной грамотности руководителей 
обратно пропорционален уровню занимаемой ими должности. Таким образом, 
разрабатывая формы принятия решений, нужно постараться сделать их как можно 
информативнее и проще. 
    Q Формы должны занимать как можно большую часть экрана. Обычно 
руководители хотят, чтобы приложение было как можно проще, а его "картинка" — 
как можно больше. Кроме того, весьма вероятно, что руководители вашей 
организации не работают одновременно с несколькими приложениями Windows, 
поэтому увеличение размера форм приложения никак не помешает им в работе. 
    Q Еще раз подчеркиваю: простота, простота и еще раз простота. Не 
заполняйте формы излишними деталями или таблицами. Обычно руководителям нужны 
факты, причем как можно более общего характера. Не отображайте на форме 
больших массивов информации по тем или иным операциям, — скорее всего, 
руководитель на нее даже не взглянет. 
    Q Везде, где только можно, используйте графическое представление данных. В 
зависимости от уровня руководителя, диаграммы могут послужить мощным 
инструментом демонстрации итоговых данных. Если руководитель теряется в цифрах 
и предпочитает диаграммы, то их использование придаст вашему при-

    150 Часть I. Основы 

ложению лоск и профессиональный вид, что не потребует от вас больших 
усилий. Однако нужно предусмотреть и средство, с помощью которого 
руководитель, при желании, мог бы погрузиться в исходные данные, положенные в 
основу диаграммы. Очень хорошим примером такого средства является компонент 
Delphi TDecisionCube. 
    Q Удалите все компоненты, обеспечивающие ввод данных и работу с ними 
(TDBEdit, TDBListBox, TDBLookupComboBox и т.п.), если приложение предназначено 
только для отображения информации, а не для ее записи. Помимо всего прочего, 
это позволит сэкономить системные ресурсы. Вместо таких компонентов примените 
компоненты TDBText или даже TLabel, которые будут просто отображать нужную 
информацию без ее сортировки. 
    Q Контролируйте доступ к данным с помощью сервера базы данных или сетевого 
сервера — не применяйте средства защиты на уровне приложения. Пользователи, 
особенно руководители, не любят получать сообщения о том, что у них нет прав 
на выполнение тех или иных функций. 
    Q Не оставляйте в приложении функций, к которым руководящий состав не 
может получить доступа. Не используйте недоступных пунктов меню или кнопок, 
так как они могут сбить с толку пользователей. Если по каким-то причинам тот 
или иной элемент должен быть недоступным для пользователя приложения поддержки 
решения, установите свойство Visible такого элемента равным False, а не просто 
делайте его недоступным. 

    Интерактивные формы 

    Интерактивные формы — это формы, которые чаще всего используются во всех 
приложениях. Посредством этих форм вводятся, редактируются и удаляются данные 
общего назначения. Типичными пользователями таких форм, как правило являются 
лица, имеющие несколько большие знания о компьютерах, чем руководители. Это, 
как правило, секретари, операторы и т.п. Однако при этом нужно не забывать, 
что интерактивные формы также должны быть как можно проще. 
    Q Постарайтесь заменить кнопки компонента Delphi DBNavigator стандартными 
кнопками. Навигатор базы данных, хотя и является мощным и удобным средством, 
однако не имеет некоторых функций, например, поиска. Кроме того, для его 
кнопок нельзя назначить комбинаций клавиш ускоренного доступа. В главе 27, 
"Разработка компонентов баз данных", показано, как создать шаблон компонента, 
являющегося функциональным аналогом компонента DBNavigator. 
    Q Сгруппируйте компоненты так, чтобы ими было удобно пользоваться. 
Сделайте их расположение логичным и интуитивно понятным. Поместите связанные 
друг с другом компоненты рядом. Это поможет пользователям быстрее освоиться с 
формами и избежать типичных ошибок. 
    Q Создайте комбинации клавиш для мнемонического доступа к кнопкам и полям 
ввода. Такие комбинации должны являться обязательным элементом приложения, 
поскольку некоторые пользователи предпочитают работать с клавиатурой. При 
назначении таких клавиш, руководствуйтесь не расположением элементов на форме, 
а логикой работы программы, причем при назначении комбинаций клавиш кнопки 
должны иметь преимущество перед метками. Например, если в верхней части формы 
имеется поле ввода, метка которого начинается с буквы А, а в нижней части 
расположена кнопка Add, то нужно создать комбинацию клавиш <Alt+A> для 
мнемонического доступа к кнопке, а не к метке. Маловероятно, чтобы 
пользователь предпочел быстро переходить в поле, которое и так расположено в 
верхней части формы, а не использовать комбинацию клавиш для выполнения 
команды, представленной кнопкой. 
    Q Установите логически продуманный порядок обхода элементов формы. В 
большинстве случаев порядок переход с поля на поле и с кнопки на кнопку должен 
выполнятся слева направо, сверху вниз. 
    О Везде, где это возможно, пользуйтесь свойством Kind компонента TBitBtn 
для создания стандартных кнопок ОК и Cancel (Отмена). Назначение кнопки в 
качестве кнопки ОК автоматически устанавливает значение ее свойства Default 
равным True, что делает ее используемой по умолчанию. Это позволит 
пользователю с помощью нажатия <Enter> закончить сеанс работы с окном, а с 
помощью нажатия <Esc> — прервать его. 
    Q Применяйте, где это возможно, контекстные меню, всплывающие при щелчке 
правой кнопкой мыши. Некоторые пользователи предпочитают работать с такими 
меню, впервые введенными компанией Borland. Если пользователи вашего 
приложения относятся к такой категории пользователей, то создать такие меню в 
Delphi — пара пустяков. 

    Глава 7. Проектирование приложения архитектуры клиент/сервер 151 


    Формы ввода данных 

    Формы ввода данных обычно используют для занесения информации в базы 
данных. Особенностью таких форм являются более высокие требования к скорости 
работы, чем к оформлению и применению различного рода "украшений", наподобие 
всплывающих подсказок и раскрывающихся списков. Формы ввода данных, как 
правило, имеют очень аскетичное оформление и содержат только самые необходимые 
элементы. Типичными пользователями таких форм являются операторы, которые 
больше смотрят в исходные документы, чем на экран. Особое внимание в формах 
данных уделяется работе с клавиатурой, так как использование мыши требует 
визуальной интерактивности. 
    Q Назначьте элементам формы, отображающим текст, полужирный моноширинный 
шрифт. Использование пропорциональных шрифтов облегчает чтение текстов 
большого объема, однако они занимают больше экранного пространства. Когда 
главное — скорость, то применяйте моноширинные шрифты. Применение полужирного 
шрифта также облегчает чтение. 
    Q Удалите ненужные кнопки и поля. Удалите те элементы, которые не нужны 
для быстрого ввода данных. Например, если вы знаете, что пользователи не 
применяют выборку номера счета из полученного из базы данных списка, а вводят 
его вручную, уберите кнопку выборки номера счета — она только занимает место 
на экране. Хотя это средство полезно в обычных формах, когда речь идет о 
скорости, такие элементы только мешают. 
    Q Связывайте компоненты семейства DataSet с подчиненными компонентами 
формы для работы с данными с помощью связи вида "главный-подчиненный". Не 
заставляйте пользователя щелкать мышью или выполнять другие действия, чтобы 
увидеть подробную информацию, соответствующую отображаемым основным данным. 
Связывайте таблицы с помощью соответствующих свойств, чтобы они автоматически 
синхронизировались. 
    Q Назначайте комбинации клавиш, которыми легко пользоваться. Не 
заставляйте пользователей тянуться пальцами через всю клавиатуру. При 
назначении таких комбинаций руководствуйтесь логикой работы с формой, а не 
расположением элементов на экране. Если двум компонентам нужно назначить одну 
и ту же комбинацию, присвойте ее тому, который чаще используется, а не тому, 
который размещен выше или левее на экране. Компоненту, который используется 
реже, назначьте другую комбинацию с какой-нибудь другой мнемоникой. Для 
команд, выполняемых чаще других, назначайте более удобные комбинации клавиш. 
    Q Там, где это необходимо, назначайте кнопкой, используемой по умолчанию, 
кнопку Add (Добавить), а не кнопку ОК. В отличие от обычных форм, в формах 
ввода данных чаще используется кнопка добавления записи в базу данных, а не 
закрытия окна. Это позволит ускорить работу пользователя при добавлении 
нескольких записей в течение одного сеанса работы с окном. 
    Q Формы должны иметь как можно меньший размер. В отличие от форм других 
типов, такие формы должны позволять перемещение их в то положение, которое 
удобно пользователю. Пользователи форм такого типа, как правило, больше 
смотрят в документы, а не на экран, поэтому применяйте для них окна 
нормального, а не максимального размера. 

    Проектирование отчетов 

    Разработка отчетов подробно рассмотрена в главе 19, "Отчеты". Здесь я 
приведу лишь самые общие рекомендации по проектированию отчетов. 
    Q Если это возможно, используйте для создания отчетов компоненты семейства 
QuickReport Delphi. Они более просты в настройке и применении, чем отчеты, 
создаваемые с помощью внешних систем разработки отчетов, так как, в отличие от 
последних, встроены в приложение. При запуске отчета, созданного на базе 
компонентов QuickReport, вам не понадобиться запускать никакие утилиты. 
    Q Для сложных отчетов, которые трудно создать с помощью QuickReport, 
применяйте, по возможности, системы графической разработки отчетов, например, 
ReportSmith, R&R SQL Report Writer for Windows, Crystal Reports и т.д. 
Использование таких систем позволит пользователям вашего приложения создавать 
новые отчеты на базе имеющихся без необходимости модификации исходного текста 
приложения. 
    Q Если СУБД вашего приложения поддерживает хранимые процедуры, 
задействуйте их при создании отчетов как можно интенсивнее. Это приведет к 
тому, что большая часть работы будет перенесена на сервер базы данных, т.е. 
туда, где она и должна выполнятся в хороших системах клиент/сервер. Кроме 

    152 Часть I. Основы 

того, это также облегчит тестирование той части отчета, которая занимается 
выборкой данных, так как в данном случае не понадобится запуск системы 
разработки отчетов. Более того, с помощью хранимых процедур можно отделить 
функции получения данных от функций их представления, что облегчит переход к 
другой системе подготовки отчетов или получения данных отчета прямо в приложении. 
    Q При использовании хранимых процедур регистрируйте их вызовы в системном 
журнале сервера. Это можно сделать посредством служб контроля сервера (если 
они имеются) или с помощью такой настройки хранимых процедур, При которой они 
вызывали бы процедуры регистрации. В этом случае процедура будет автоматически 
обновлять таблицу системного журнала сервера при ее вызове. Регистрация 
вызовов процедуры даст вам информацию об общей производительности отчетов, а 
также позволит узнать, какие отчеты пользователи создают чаще всего и в какое 
время. Ниже приведен пример создания такой процедуры в Transact-SQL (диалект 
Sybase и Microsoft SQL Server). 

    CREATE PROCEDURE reportlog @StartEnd char(6), @ReportName char(30) as 
    insert into REPORTLOG 
    select @StartEnd, getdate(), suser name(), @ReportName 

    Создав такую процедуру, можете использовать следующие операторы SQL для ее вызова. 

    /* 
    Регистрация запуска процедуры создания отчета. 
    exec reportlog 'STARTED','MAINTENANCE REPORT BY WORK TYPE' 
    /* 
    Работа процедуры создания отчета. 
    */ 
      ..........
    /* 
    Регистрация завершения работы процедуры создания отчета. 
    */
    exec reportlog 'ENDED','MAINTENANCE REPORT BY WORK TYPE' 


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

    Q На титульной странице отчета поместите внутреннее имя отчета, текущие 
время и дату, а также имя пользователя, создавшего отчет. Указание времени и 
даты позволит различить разные версии одного отчета, а также судить о том, 
насколько его данные пригодны к использованию по прошествии нескольких дней. 
Внутреннее имя отчета позволит вам прояснить "источник" происхождения отчета, 
если в будущем потребуется доработать соответствующее приложение. Имя 
пользователя может пригодиться для определения того, с кем нужно обсуждать 
возможные проблемы. На рис. 7.6. приведен вид страницы правильно оформленного отчета. 
    Q Поместите в колонтитуле отчета какую-либо информацию, позволяющую 
однозначно квалифицировать его данные. Если пользователь при генерации отчета 
вводит дату или какие-нибудь другие подобные критерии, используйте их в 
колонтитуле отчета. Это требование продиктовано тем, что в соответствии с 
какими-то критериями в итоговый отчет могут не включаться те или иные данные, 
что может, в свою очередь, вызвать недоумение со стороны пользователей. 
Особенно высока вероятность таких ситуаций, когда между генерацией отчета и 
его просмотром проходит длительное время. 
    Q В колонтитулах используйте пропорциональные шрифты, а в отчетах — 
моноширинные. Пропорциональные шрифты придают тексту более завершенный вид, а 
также дают возможность использовать все преимущества современных принтеров. 
Однако они обладают одним недостатком — при их применении к выводу табличных 
данных могут возникать проблемы с выравниванием выводимой информации по 
столбцам. Например: поскольку цифра 1 при печати уже, чем цифра 5, 
использование пропорциональных шрифтов приведет к тому, что числа в столбцах 
будут "плясать". Лично я использую пропорциональные шрифты типа Arial или 
Times New Roman для колонтитулов, а моноширинные типа Courier New — для 
собственно отчета. 

    Глава 7. Проектирование приложения архитектуры клиент/сервер 153 


    Рис. 7.6. Правильно оформленный отчет 

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

    154      Часть I. Основы 


    Тестирование приложения на предмет соответствия его назначению и функциям 

    Предмет тестирования и оценки качества приложения сам по себе заслуживает 
отдельной книги. Хотя рассмотрение данного вопроса во всех тонкостях выходит 
за рамки этой книги, я хочу поделиться с вами некоторыми соображениями на этот счет. 
    Q Разработайте стандартную процедуру описания выявленных отклонений в 
работе вашего приложения и извещения о них. Общепринятой является практика, 
когда для этого создается отдельная форма или, что еще лучше, специальное 
небольшое приложение. В генерируемый отчет поместите такую необходимую 
информацию, как его номер, описание действий, приведших к возникновению 
аномалии, тип отчета (ошибка, предложение, запрос информации), а также меры, 
принятые разработчиком по сути отчета. 
    Q Обеспечьте механизм простого распространения доработанных и обновленных 
версий среди своих заказчиков. Когда-то я для этих целей создал небольшое 
приложение, которое запускается из папки Startup Windows и проверяет даты 
выполняемого файла на локальных жестких дисках и на сетевом сервере. Если 
локальная копия файла является устаревшей, то приложение заменяется его новой версией. 
    Q Во всех приложениях отображайте номер версии. Когда вы рассылаете 
обновленный вариант приложения, даже если изменения были незначительными, 
обязательно увеличивайте номер подверсии. Как я уже упоминал, для этих целей 
нужно пользоваться ресурсом Windows VERSIONINFO (см. главу 13). 
    Q Задайте себе вопрос, соответствует ли приложение своему назначению. 
Например, можете ответить на такой вопрос: "Эффективно ли приложение 
обслуживает управление арендой недвижимости?" 
    Q Проверьте, как выполняются производственные, функциональные и 
технические требования, выдвигавшиеся к приложению. Убедитесь, что все 
средства приложения соответствуют тем функциям, для выполнения которых они 
предназначены. 
    Q Если это возможно, установите приложение на компьютере такой же 
конфигурации, как и у компьютеров вашего заказчика, и протестируйте на нем 
работу приложения. Особенно внимательным нужно быть в отношении типа 
процессора, объема памяти и дискового пространства, а также типа 
видеоадаптера. Постарайтесь также установить такую же локальную и сетевую 
операционные системы. Если пользователи приложения будут работать в Windows 
NT, протестируйте приложение в Windows NT, a если в Windows 95 — сделайте это 
в Windows 95. Хорошо также проверить совместную работу вашего приложения с 
другими приложениями, которые использует ваш заказчик, с тем, чтобы убедиться 
в их совместимости. 
    Q Проверьте ограничения базы данных, чтобы убедиться в том, что они 
выполняют возложенные на них задачи. Попробуйте вводить неправильные данные, 
чтобы удостовериться в том, что они не будут пропущены приложением. Проверьте 
работу ограничений как при выходе данных за нижнюю границу допустимого 
диапазона значений, так и при выходе за верхнюю границу. Попытайтесь удалить 
строки с зависящими ключами. Посмотрите, позволяет ли база данных дублировать 
значения в столбцах, которые не должны этого допускать. Проверьте, что 
происходит, когда не заполняются поля, являющиеся обязательными. 
    Q Выполните тестирование одновременной работы нескольких копий приложения. 
Если приложение предназначено для одновременной работы 20 пользователей, 
протестируйте, что происходит при работе 30 или 40 пользователей. Попросите 
тестирующих, чтобы они одновременно обновили одну и ту же строку или чтобы 
один пользователь удалил строку, которую в это время редактирует другой 
пользователь. Проверьте как работают средства блокировки базы данных, чтобы 
убедиться в том, что при одновременной работе нескольких пользователей не 
происходит потери информации, а обновление выполняется с приемлемой скоростью. 
    Q Если приложение должно располагаться на сервере, убедитесь, что 
определенные вами права доступа действительно управляют доступом в той 
степени, в которой предполагалось. Убедитесь в правильности работы паролей. 
Проверьте, чтобы все пользователи имели необходимые им права, для работы с 
приложением. Попробуйте имитировать нарушение прав доступа на каждом уровне. 
Выясните, удается ли удалять или обновлять строки, если у пользователя 
отсутствуют соответствующие права. Все это позволит удостовериться в 
правильности работы средств ограничения доступа приложения. 

    Глава 7. Проектирование приложения архитектуры клиент/сервер 155 

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

    Установка приложения 

    Полностью вопрос совершенствования и окончательного оформления приложения 
освещен в главе 29, "Совершенствование приложения", поэтому здесь я приведу 
лишь несколько рекомендаций общего характера. 
    Q Как я уже упоминал, перед установкой приложения нужно протестировать 
его работу на типичном компьютере с типичным программным обеспечением будущих 
пользователей вашего приложения. 
    Q Старайтесь как можно меньше привязывать приложение к конфигурации 
компьютера пользователя. Не модифицируйте конфигурационные параметры 
приложения, если в этом нет острой необходимости. 
    Q Посетите компанию заказчика и выясните, нужно ли устанавливать какие-то 
дополнительные аппаратные средства или программы для обеспечения работы 
приложения. Если приложение работает, например, с СУБД клиент/сервер по 
протоколу TCP/IP, то на рабочих станциях нужно установить поддержку этого 
протокола. Для этого вам может понадобиться помощь администратора сети заказчика. 
    Q С помощью средства InstallShield, входящего в комплект поставки Delphi, 
создайте программу установки вашего приложения и всех нужных для его работы 
файлов на компьютеры заказчика. Подробнее этот вопрос освещен в главе 29. 

    Резюме 

    Надеюсь, вы почерпнули из глав 6 и 7 достаточно много и можете приступать 
к разработке реальных приложений баз данных. Возможно, вы поняли, что 
разработка приложений архитектуры клиент/сервер является сложной задачей, 
однако не стоит падать духом. Такая работа может потребовать больше сил и 
времени, но это, тем не менее, все та же разработка программного обеспечения. 
    Когда вы приступите к созданию приложений клиент/сервер, помните, что 
основное внимание должно уделяться не соответствию теории построения этих 
приложений, а выполнению практических задач. Иногда для достижения тех или 
иных целей приходится жертвовать стройностью структуры в угоду 
производительности. И главное, никогда не забывайте, что в разработке 
приложений нет "правильных" и "неправильных" путей, т.е. нет проторенных 
дорог, которые всегда приводят к получению хороших приложений. Разработка 
программного обеспечения — это, скорее, не наука, а ремесло. 

    Что дальше... 

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

    156 Часть I. Основы 

