Глава 17

Методы спецификации

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

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

В этой главе рассматриваются следующие вопросы.

• Потребности и трудности.

• Подходы к спецификации.

• Спецификации в стиле минимализма.

• Виды спецификации— концептуальная, высокоуровневая, детализированная; реализация.

• Схема спецификации.

• Подход к спецификации для программных проектов.

• Продолжение обсуждения проекта: спецификация.

Разработка спецификаций для ПИ-ориентированных приложений (рис. 17.1) — трудное дело, в особенности для проектов с коротким жизненным циклом.

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

Потребности и трудности

Разработка GUI-ориентированного приложения — непростое дело с точки зрения проектирования, реализации и тестирования. Web- и PDA-ориентированные прило­жения менее трудны, в особенности если речь идет о выполнении сложных произ­водственных задач. Традиционные подходы к спецификации ПИ-ориентированных приложений не облегчают задачу, особенно когда цикл разработки непродолжите­лен, а в число пользователей спецификации входит персонал, который сравнительно поздно был вовлечен в цикл разработки продукта (например, традиционный подход по использованию независимой бригады тестировщиков).

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

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

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

• Определение поля.

• Метка для поля в обычном или книжном стиле.

• Пунктуация для метки (подчеркивание, выделение и т.д.).

• Внутреннее имя элемента управления для метки.

• Внутреннее имя элемента управления для поля.

• Ускоряющая клавиша для поля.

• Расположение метки и поля на экране.

• Интервал между меткой и полем.

• Интервал между меткой, полем и другими элементами управления на экране.

• Выравнивание базовой линии текста метки и поля.

• Необходимый индикатор поля, если таковой уместен.

• Тип, формат, диапазон данных и значение данных, используемое по умол­чанию.

• Ширина поля.

• Маски ввода, если таковые имеются.

• Выравнивание данных внутри поля.

• Порядок работы клавиши табуляции.

• Специфическое поведение устройства ввода в отношении поля (например, клавиатура или мышь).

• Внешний вид (шрифт, стиль, размер, цвет, эффекты, графика).

Поведение (разблокирование и блокирование, только просмотр или редакти­рование, использование звука и т.п.).

• Правила верификации для самого поля и для поля во взаимодействии с другими данными, представленными на экране (множество функций, обеспечивающих проверку данных (dialog data verification), получаемых от диалоговых эле­ментов управления. — Прим. ред.)

• Бизнес-правила, управляющие обработкой данных.

• Условия выполнения верификации.

• Информация по сообщениям, полю, поддержке эффективности, справочная и обучающая информация для поля.

Web- и PDA-ориентированный интерфейс касается большей части перечисленных выше аспектов; даже для простого элемента управления количество деталей довольно велико. Для более сложных элементов управления объем деталей возрастает, и пере­чень становится более длинным и неполным. Если же рассматривать интеграцию элемента управления с другими элементами управления, присутствующими на экране, перечень деталей становится еще длиннее.

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

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

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