Часть 3

Серьезно принимаемся

за дело

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

В третьей части рассматриваются следующие темы.

Глава 16. Высокоуровневое проектирование (семантика и структура).

Глава 17. Методы спецификации.

Глава 18. Низкоуровневое проектирование.

Глава 19. Конструирование, тестирование и развертывание продукта.

Глава 16

Высокоуровневое проектирование

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

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

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

• Установление контекста в пределах цикла разработки.

• Определения и входная информация проекта.

• Объектно-ориентированные компоненты.

• Поведение рабочего стола.

• Логика вызовов ПИ.

• Основные экраны — функции, содержимое, меню.

• Основные диалоги.

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

• Инсталляция, печать и другие системные функции.

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

В процессе проектирования бригада разработчиков проводит анализ и проверку обоснованности проектных решений, а затем, при необходимости, выполняет оче­редную итерацию. Итерация 1₂ представляет собой основную итерацию, которая мо­жет содержать множество более мелких шагов. Цель заключается в идентифицирова­нии основных повторно используемых компонентов, ранее не идентифицированных.

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

Установление контекста в рамках цикла разработки

До сих пор наша деятельность была сконцентрирована на первой главной проект­ной итерации — концептуальном проектировании. Для небольших и средних по объ­ему программных проектов с коротким циклом разработки закрытие концептуально­го проекта происходит уже через три-четыре недели. Для средних и крупных проек­тов с более продолжительным календарным графиком концептуальное проектирова­ние занимает от четырех до шести недель.

В этот период проектная бригада выполняет следующие виды деятельности.

• Планирование проекта, оценка объема работ, подбор персонала и обучение.

• Формулировка и анализ требований.

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

• Проектирование и разработка прототипов для альтернатив концептуального уровня.

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

• Интеграция проекта ПИ с проектом инфраструктуры.

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

Теперь приступим к изучению следующего основного этапа проекта— высоко­уровневого проектирования.

Определения и входная информация проекта

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

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

Напомним, что проект ПИ продукта материализуется в спецификациях, макетах, раскадровке, моделях, прототипах и, безусловно, в ПО продукта, поставляемом поль­зователям. Проект не обязательно касается способа реализации ПИ.

Мотивация. Разработка ПИ-ориентированного приложения— рискованное предприятие с точки зрения проектирования, реализации и тестирования. Именно здесь начинается трудная работа.

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

Следующий уровень ПО — уровень поддержки ПИ, который обеспечивает струк­туры данных и алгоритмы, необходимые для функциональных возможностей ПИ или прикладной области и не поддерживаемые явно ОС или ее средствами. Примеры поддержки ПИ— непосредственное манипулирование и поисковые действия. Если приложению требуется база данных или другая инфраструктура ПО, выполняется проектирование и реализация добавочного базового ПО для не интерфейсных функ­ций или API (Application Programming Interface — программный интерфейс приложе­ния) таким образом, чтобы дополнять поведение ПИ приложения до необходимого уровня.

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

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

Высокоуровневый проект для ПИ включает следующие основные компоненты (рис. 16.3).

• Подход к использованию платформы ПИ.

• Предполагаемую пользовательскую модель.

• Характеристики объектов, свойств и действий.

• Структуру и логику вызовов окон и экранов.

• Основные окна, экраны, представления и диалоги.

• Стандартные и дополнительные представления.

• Графический, аудио - и визуальный стиль.

• Стиль меню и выбор команд.

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

Внешний вид и поведение экранов

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

Полезное правило. Аналогично другим аспектам проектирования работа со всеми этими возможностями ведется активно и в соответствии с планами.

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

Пример. Для иллюстрации элементов проекта ПИ воспользуемся приложением Address Book (Адресная книга). Address Book— это приложение, разработанное для поль­зователя {Conference Companion), который посещает конференцию или симпозиум. В итоге предполагается интеграция Address Book с Conference Companion, что позволит просматривать перечень посетителей конференции, обеспечить подробную инфор­мацию по каждому посетителю и создавать записи, касающиеся отдельных людей и организаций. В приложение Address Book также могут быть встроены возможности на­подобие электронной почты и пейджинга при условии, что они поддерживаются ап­паратной и программной платформами пользователя.

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

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

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

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

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

Полезное правило. В максимальной степени используйте стандартные эле­менты управления платформы.

Следствие. Избегайте конструирования пользовательских элементов управления.

Объектно-ориентированные компоненты

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

Высокоуровневое определение. Для объектно-ориентированной систе­мы характерны следующие особенности.

• Классы объектов.

• Иерархия классов.

• Наследование через иерархию классов.

Любая система, удовлетворяющая первому из условий, является только объектной. Если система удовлетворяет двум первым условиям, ее называют системой классов.

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

Полезное правило. С точки зрения ПИ, пользователи лучше всего осведомле­ны об объектах и их поведении. Нет необходимости в явном представлении пользо­вателям классов, иерархии классов и наследования, но эти понятия весьма полезны для любого проекта реализации, где цель состоит в повторном использовании.

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

Методология. В основе эффективной разработки объектно-ориентированной системы лежат три ключевые вида деятельности.

• Объектно-ориентированный анализ (ООА) направлен на оценку потребности пользователей и проблем, которые необходимо решить. Результатом ООА является концептуальный проект для статических, динамических и функцио­нальных аспектов пользовательских проблем.

• Объектно-ориентированное проектирование (ООПР) позволяет преобразо­вать результаты ООА в проектные решения для системы и объектов, более тесно привязанные к потребностям реализации.

• Объектно-ориентированное программирование (ООП) дает возможность преобразовать результаты ООА и ООПР в ПО продукта с помощью инст­рументальных средств реализации.

Существует несколько методологий, которые подходят для ООА, ООПР и ООП. Нет необходимости их изучать углубленно, поскольку подробное изложение этих ме­тодологий выходит за рамки книги. Для проектной бригады действительно важно оп­ределить такой объектно-ориентированный процесс разработки, который бы подхо­дил с точки зрения решения пользовательских проблем, а также навыков и средств, которыми располагает бригада.

Полезное правило. Существует много способов решения проблемы в объект­но-ориентированном стиле.

Аспекты, связанные с объектами. Все функции и возможности прило­жения можно выразить в терминах объектов, операций и атрибутов объектов и опе­раций.

Полезное правило. Независимо от способа реализации ПИ или базового ПО, объектно-ориентированная методология чрезвычайно полезна при проектировании.

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

Ниже приведены типичные требования к приложению Address Book.

• Создать систему, которая позволит пользователям отображать и взаимо­действовать со списком имен.

• Дать возможность пользователям создавать свои собственные персональные записи.

• Предусмотреть схемы и указания по доступу к ресурсам, таким как конференц-залы и офисы.

• Обеспечить возможности поиска и печати.

• Доступ к продукту должен осуществляться посредством GUI-, WUI- и HUI-интерфейсов.

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

• Определить природу объекта.

• Описать его использование.

• Определить характеристики, свойства и значения свойств.

• Описать отношения объекта с другими объектами.

• Определить набор операций, применимых к объекту.

Примеры объектов, с которыми имеют дело конечные пользователи и которые получены в результате анализа адресной книги, — это объекты Address Book (Адресная книга), Person (Особа), Group (Группа), Resource (Ресурс), Distribution List (Список [абонентов для] распределения [групповых сообщений]). Примером объек­та с вариациями в свойствах является объект Address Book, для которого адресная книга организации не редактируется пользователем, не имеющим административных прав, а личная адресная книга (Personal Address Book) может редактироваться всеми пользователями. Другой пример подобного объекта — группа или список распределе­ния, включающие информацию об адресатах (То: (Кому:) ее: (Копия:)).

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

• Определить, что такое операция (ее природу).

• Задать способ использования операций отдельно от их природы.

• Определить характеристики, свойства и значения свойств операции.

• Описать отношения операции с другими операциями.

• Определить объекты, к которым применима операция.

Операции могут быть чувствительными к контексту— они демонстрируют разное поведение в зависимости от объекта. Каждая пара объект-операция тщательно иссле­дуется для определения точного результата операции.

Примеры операций для приложения Address Book адресной книги включают та­кие действия, как Find (Найти), Search (Поиск) и Print (Печать). В качестве примера операции с вариациями в свойствах можно назвать операцию Sort (Сортировка), ко­торая выполняется по отношению к объектам Name (Имя) и City Address (Адрес горо­да). Операции, наличие которых является результатом анализа требований, включа­ют операции Drag (Перетащить), Cut (Вырезать) и Properties (Свойства).

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

Примером примитивной операции является операция определения местоположе- \ ния (Locate), которая может быть использована для построения операций Find I (Найти) и Search (Поиск). Пример примитивного объекта— группа, которая исполь­зуется для построения объектов Group (Группа) и Distribution List (Список распреде­ления).

Построение матриц объект – операция – свойство. Чтобы облегчить анализ, проектная бригада конструирует матрицу для объектов и операций, объектов и свойств, а также для операций и свойств. Бригада определяет потенциальную сово­купность правомерных операций для каждого объекта, включая системные функции наподобие операций "перетащить и оставить" и буфера обмена. Аналогично, бригада анализирует, какие свойства связаны с каждым отдельным объектом и операцией.

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

• Многие операции, которые исторически ограничены определенными типами объектов, оказываются правомерными в отношении многих других объектов.

• Многие свойства специализированных объектов также применимы к другим более общим объектам.

• Многие свойства определенных операций применимы также к другим операциям.

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

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

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

Абстракция классов. Неплохо для начала сгруппировать объекты исходя из результатов анализа пар объекты-действия. Некоторые объекты естественным обра­зом попадают в схожие группы, в то время как определенные типы объектов по при­роде различны. Например, объекты Address Book отличаются от принтеров, а объек­ты отображений отличаются от контейнеров. Однако элементы для объекта Person до некоторой степени похожи на элементы для объекта Resource, добавленного в лич­ную адресную книгу (Personal Address Book). Некоторое различие между элементами весьма небольшое и требует дополнительного рассмотрения. Предполагаемая поль­зовательская модель помогает прояснить эти различия.

Типы отношений. В качестве полезного теста на принадлежность объекта к классу используется отношение "является". Например, предложения "каждая лягушка является рептилией" и "каждая мусорная урна является контейнером" четко определя­ют класс, к которому принадлежит объект. Если предложение "каждое событие явля­ется контейнером" — ложно, тогда объект "событие" принадлежит к другому классу.

Полезное правило. Редко можно найти объект, не принадлежащий к какому-либо классу.

Еще один метод, позволяющий выяснить, является ли объект компонентой класса или частью другого объекта, состоит в использовании отношения "является частью". Например, "нога является частью собаки". Аналогично, "страница является частью тет­ради". Однако географическая карта может быть, а может и не быть частью события.

После выделения классов из совокупности объектов необходимо проанализиро­вать множества свойств и операций, чтобы убедиться, что свойства также принадле­жат сущностям экземпляров или подклассов.

Другие аспекты объектно-ориентированного подхода. Для реа­лизации проекта бригада разработчиков строит иерархии классов и наследования. По завершении проекта бригада имеет в своем распоряжении одно или несколько де­ревьев (иерархий классов), отображающих отношения между различными классами приложения. Чтобы определения с точки зрения пользователей были осмысленны­ми, чрезвычайно важно иметь адекватную пользовательскую модель и объектные оп­ределения.

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