Глава 11

Концептуальное проектирование

и архитектура

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

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

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

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

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

• Формирование ведения.

• Распределение компонент работы.

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

• Архитектура ПИ — самый высокоуровневый проект.

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

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

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

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

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

Концептуальный проект включает следующие компоненты.

• Общий стиль ПИ.

• Прикладной стиль ПИ.

• Сущности и артефакты конечных пользователей.

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

• Организация, структура, потоки и отношения между сущностями коне пользователей.

• Ключевые принципы функционирования.

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

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

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

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

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

Рис.11.1 Концептуальное проектирование

Формирование видения

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

• Альтернативы, заложенные в концептуальный проект, получают наглядность в спецификации и прототипе.

• Для получения исходной информации от пользователей применяются методы привлечения пользователей к участию в проекте.

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

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

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

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

Полезное правило. Начинайте формулировать концептуальный проект как можно быстрее (после того как в вашем распоряжении окажется критическая мас­са информации).

Проектная итерация 1 (I₁). Концептуальное проектирование представляем собой первую из множества проектных итераций. Хотя он обозначается как I₁, проектная бригада на данном этапе проектирования быстро выполняет многочисленные итерации. Итерации в рамках концептуального проектирования обозначаются I₁₁, I₁₂, и т.д.

Есть много способов "ободрать липку", точно так же существуют и многочисленные способы "ободрать" ПИ. Однако наступает момент, когда бригада разработчиков продукта принимает решение, по какому пути развития проекта следовать, опираясь на пользователей. I₁ — это интервал времени, выделенный для принятия решения.

Начальная итерация выражается в следующих действиях.

• Формулировка множества проектных альтернатив.

• Описание каждой проектной альтернативы.

• Оценка каждой альтернативы по отношению к требованиям, средам и поль­зователям.

• Выбор наиболее многообещающих альтернатив и отбрасывание тех, которые расцениваются как нежелательные.

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

Главная цель первой итерации заключается в отборе наиболее подходящих прочных альтернатив для дальнейшего рассмотрения и уточнения (рис. 11.2). Лучшая ситуация для итерации I, — выявление единственной проектной альтернативы для продвижения и более детального изучения. Как правило, в течение последующих фаз анализа обычно не хватает времени и ресурсов для изучения множества проектных альтернатив, которые требуют более скрупулезной

работы по проектированию, созданию прототипов, оценке и выполнению итераций.

Неприемлемые решения Ход проекта

Рис. 11.2. Сужение круга допустимых альтернатив в процессе проектирования

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

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

Альтернативы использования базовых свойств ПИ

Проектная бригада также анализирует альтернативное использование основных стилей ПИ, которые должны применяться и представлять внешний вид ПИ и поведенческие модели пользовательского взаимодействия с системой. Примеры альтернативных форм использования базовых свойств GUI-интерфейса включают выбор предоставляемых в распоряжение пользователей возможностей, а также возможно­стей, доступных по умолчанию (например, строка меню (состояние "включено"), па­нель инструментов (состояние "включено и отображается под строкой меню") и пик­тограммы панели инструментов (состояние "крупные (Large) с текстом")). GUI -, WUI- и HUI – интерфейсы предоставляют бесчисленные возможности и альтернативы.

Альтернативы использования прикладных стилей ПИ

Бригада разработчиков формирует и придает наглядный вид проектной модели пользовательского интерфейса прикладного ПО, которое поддерживает от пяти до семи задач, оказывающих наибольшее влияние на работу системы. Эти задачи могут представлять до 20% объема проекта, на которые приходится до 80% объема использования, влияния и значимости продукта. Примеры альтернативных прикладных стилей ПИ включают представление программных артефактов пользователей по меньшей мере в трех формах.

• Электронной.

• Физической.

• Визуальной (наглядной).

Электронный СТИЛЬ. Электронный стиль концептуально подобен электронной таблице или документу. Этот тип приложения показывает пользователю компьютерные сущности или элементы предметной области без физических границ. Примером может служить компьютеризованный перечень файлов каталога без страниц (в противоположность адресной книге).

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

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

Другие СТИЛИ. К другим стилям ПИ можно отнести игровой подход, который по существу, переворачивает проблему с ног на голову и занимается поиском путей превращения компьютерных артефактов в игру. Например, игра Find Francine может служить игровой моделью для адресной книги.

Архитектурный стиль для организации функций и информации применительно к ПИ представляет собой объектный (или объектно-ориентированный) стиль. Возможности [ продукта представляются как объекты, классы объектов, иерархии классов, действия и соответствующие свойства. Этот стиль не слишком отличается от физического стиля за исключением того, что в нем может участвовать базовый объектно – ориентированный язык программирования. Примеры объектов включают адресную книгу и каталог, а примерами действий являются операции Add (Добавить) и Person (Субъект).

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

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

Объединение перестановок и сочетаний стилевых вариаций.

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

Полезное правило. Следует выработать, как минимум, три проектных альтернативы, используя варианты стиля ПИ и прикладного стиля ПИ: традиционное проектирование; нетрадиционное проектирование, которое раздвигает границы возможного; и в некотором роде промежуточный вариант проектирования (рис. 11.3).

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

Нетрадиционное проектирование характеризуется возможностями, которые ино­гда кажутся нереальными, революционными или просто благими пожеланиями.

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

Рис.11.3. Измерение концептуального проекта

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

Распределение компонент работы

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

• Задачи, подлежащие выполнению.

• Пользователи, выполняющие задачи.

• Сильные стороны и ограничения возможностей пользователей.

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

• Перспективные характеристики ПО, которые улучшают, наращивают или

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

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

• Перспективы выполнения требований в отношении ПИ и практичности.

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

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

Предполагаемая пользовательская модель

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

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

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

• Понятия. Общее представление или идея, конструкции или вопросы, отображающие проектные решения.

• Возможности. Возможности, обеспечиваемые набором функций и ПИ продук­та. Примеры функциональных возможностей— команды Add (Добавить) Person (Особа) адресной книги. Примером возможностей ПИ, интегрированных с функциональными возможностями, является операция перетаскивания (Drag) объекта Person из адресной книги в календарь событий (точнее, из окна приложе­ния "Адресная книга" в окно приложения "Календарь мероприятий". — Прим. ред.).

• Аналогии и метафоры. Подобие между сходными возможностями или понятиями, не связанными буквально.

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

• Внешний вид. Визуальное или графическое представление объекта или действ вия на экране дисплея привносит концептуальную информацию о природе сущности.

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

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

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

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

• Естественность. Предполагаемая пользовательская модель представляет собой абстракцию и отражение пользовательской среды. Объекты, действия и стили взаимодействия знакомы и удобны конечному пользователю.

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

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

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

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

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

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

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

Принципы проектирования для предполагаемой пользова­тельской модели. Формирование предполагаемой пользовательской модели подчиняется нескольким принципам и правилам.

• Следует предусматривать единую модель системного уровня. Одна базисная

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

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

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

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

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

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

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

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

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

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