2313

Windows, с которыми вы уже знакомы. Однако для того, чтобы изменить гарнитуру, стиль или размер шрифта, необходимо вывести для соответствующего элемента управления Properties Window (окно свойств) и изменить свойство Font.

Чтобы отредактировать текст заголовка формы, отредактируйте свойство формы Caption в Properties Window. А для форматирования текста заголовка формы воспользуйтесь свойством формы Font.

Некоторые элементы управления, такие как поля (TextBox), списки (ListBox) и поля со списком (СоmbоВох) не имеют встроенной надписи (или заголовка). Чтобы пометить такие элементы на форме, используйте элемент Label.

8.6.4. Управление последовательностью перехода

В активном состоянии ваша форма будет вести себя подобно другим диалоговым окнам Windows. Пользователь вашего диалогового окна может переходить от одного элемента управления к другому вперед и назад, используя соответственно клавиши Tab или Shift+Tab. Порядок, в котором будут активизироваться элементы управления в ответ на нажатие пользователем клавиш Tab или Shif+Tab, называется последовательностью перехода (tab order) элементов управления. Обычно последовательность перехода для элементов управления выбирают так, чтобы она соответствовала (приблизительно) перемещению слева направо и сверху вниз. Вообще говоря, вы должны постараться так расположить элементы управления, чтобы последовательность перехода обеспечивала логическое перемещение от одного элемента управления диалогового окна к другому.

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

143

ческой последовательности перемещения по элементам управления диалогового окна.

Для изменения последовательности перехода, выполните следующие действия:

1.Выберите команду View | Tab Order (Вид | Последовательность перехода);редактор VB отображает диалоговое окно Tab Order (Последовательность перехода). Список Tab Order выводит все элементы управления формы в существующей на данный момент последовательности.

2.В списке Tab Order выберите элементы, положение которых хотите изменить.

3.Используя кнопки Move Up (вверх) и Move Down (вниз), измените положение выбранного элемента управления

впоследовательности перехода. Щелчок по кнопке Move Up переместит элемент управления вверх по списку (то есть он будет активизироваться раньше), а щелчок по кнопке Move Down переместит этот элемент вниз по списку (то есть он будет активизироваться позже).

4.Повторите пункты 2 и 3 для каждого элемента управления, пока не получите удовлетворяющую вас последовательность перехода для элементов управления формы.

5.Выберите в диалоговом окне Tab Order кнопку OK, чтобы подтвердить сделанные вами изменения, после чего закройте окно.

Хотя элементы Label тоже появляются в диалоговом окне Tab Order и вы можете поменять их положение в списке, в VBA нельзя выбрать элемент управления Label. Этот элемент предназначен исключительно для вывода текста.

8.6.5. Задание свойств формы и элементов управления в режиме разработки

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

144

формы или элемента управления становятся для них новыми свойствами по умолчанию.

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

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

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

В режиме разработки свойства формы или элемента управления устанавливаются в Properties Window, где перечислены все свойства объекта, которые вы можете установить в этом режиме. Конкретные свойства, появляющиеся в этом окне, зависят от выбранного вами элемента управления.

Properties Window имеет две страницы (вкладки). Первая содержит список свойств объекта в алфавитном порядке. Вторая страница содержит список свойств, разделенных на категории. Заметьте, что различные категории выделены в Properties Window жирным шрифтом: Appearance (Вид), Behavior

(Поведение), Font (Шрифт) и так далее. Вы можете свернуть

145

или развернуть список свойств конкретной категории, щелкнув по квадратику слева от заголовка каждой из категорий.

Чтобы задать свойство формы или элемента управления, щелкните в поле, соответствующем свойству, которое хотите изменить. Для большинства свойств появится раскрывающийся список. Щелкните по кнопке списка и выберите из списка нужное значение свойства. Другие свойства (такие как Name и Caption) дают возможность ввести любой необходимый текст. Некоторые свойства при их выборе выводят кнопку с многоточием (...). Щелчок по такой кнопке открывает дополнительные диалоговые окна, помогающие задать это свойство.

Чтобы изменить свойства формы или элемента управления, выполните следующие действия:

1. Выберите элемент управления, свойства которого хотите изменить. Чтобы выделить форму, щелкните где-нибудь на поверхности формы, не занятой элементами управления.

2. Выберите команду View | Properties Window (Вид Ок-

но свойств) для отображения Properties Window. (Вы можете сделать это и щелчком на кнопке Properties Window на панели инструментов редактора VB или, нажав F4.)

3.Установите необходимое свойство для выбранного элемента управления.

4.Щелкните по кнопке Close (закрыть) в верхнем левом углу окна Properties Window, чтобы его закрыть.

Итак, вы познакомились с основными положениями создания и управления диалоговыми окнами и их элементами.

9.ОСОБЕННОСТИ РАЗРАБОТКИ ОФИСНЫХ

ПРИЛОЖЕНИЙ

9.1. Изменение требований

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

146

манда проекта или целая организация). Из-за того, что субъектов два, очень многое зависит от степени их взаимопонимания.

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

Разработчик обязан принимать во внимание три толкования ТЗ:

1.То, которое предполагает разработчик.

2.То, которое имеет в виду заказчик.

3.То, которое отражает объективную потребность заказ-

чика.

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

Из сказанного следует, что ТЗ на разработку офисного приложения будет изменяться. Эти изменения могут быть многократными или происходить всего несколько раз, они могут быть радикальными или только "косметическими", но изменения будут иметь место.

Разработчик должен быть готов к изменениям ТЗ. Линия поведения, при которой разработчик категорически отказывается даже от рассмотрения изменений ТЗ, абсолютно беспер-

147

спективна и, как правило, она является признаком некомпетентности разработчика.

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

9.2. Прототип приложения

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

С другой стороны, если предъявить заказчику некоторое приложение, то он без колебаний может ответить на вопрос: "это то, что нужно, или нет?". Более того, как правило, работая

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

Учитывая эту ситуацию, при разработке офисных приложений используется следующий прием. Получив ТЗ, разработчик как можно быстрее создает некоторую версию приложения, называемую прототипом. Прототип должен быть похож на разрабатываемое приложение, но не обязан им являться. Например, это может быть только интерфейс будущего приложения или интерфейс и несколько ключевых функций. Заказчик знакомится с прототипом и говорит: "Да, это то, что нужно, можно отливать в металле" или "Нет, это не то, здесь, здесь и здесь нужно изменить". После этого, с учетом замечаний заказчика, корректируется ТЗ и начинается работа над основным вариантом приложения. Очень важно, что при работе

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

148

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

Офисные средства разработки хороши тем, что позволяют очень быстро построить прототип.

9.3. Интерфейс пользователя

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

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

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

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

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

149

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

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

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

фактами.

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

9.4. Артефакты офисных приложений

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

150

бочно полагают, что всегда верно и обратное, то есть что если есть код программы (есть формы, есть процедуры, все это запускается и как-то работает), то офисное приложение готово. Иногда это утверждение бывает верным: например, если студенческое упражнение по программированию запускается и выдает более или менее правдоподобные результаты, то преподаватель может поставить удовлетворительную оценку. Но для реального офисного приложения ни в коем случае нельзя считать, что как-то работающего кода достаточно и дело сделано.

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

Техническое задание (ТЗ) — это описание того, что должна делать система для пользователя. Данный артефакт называют по-разному: спецификации, требования (от английского названия данного понятия — requirements). Суть этого артефакта:

ТЗ является техническим (не финансовым и не организационным) документом, описывающим решаемую задачу;

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

ТЗ может принимать разные формы:

обычный текст на естественном языке;

диаграммы использования;

ссылка на уже работающее унаследованное приложение, которое нужно изменить и (или) расширить.

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

151

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

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

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

Прототип — это модель графического интерфейса пользователя. Для современных офисных приложений графический интерфейс является неотъемлемой частью.

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

Word.

Программная документация. Документация к про-

граммам необходима. Недокументированные программы долго не живут — кадровые изменения в организации-разработчике

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

Понятие программной документации достаточно широ-

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

иповедение программ, — все это примеры программной документации.

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

152