Учебно-методический комплекс ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ   А. М. Гудов, С. Ю. Завозкин, С. Н. Трофимов

[Титульная] [Программа] [Учебное пособие] [Лабораторный практикум] [Дополнительные материалы]

[Глава 1] [Глава 2] [Глава 3] [Глава 4] [Глава 5] [Глава 6] [Глава 7] [Глоссарий] [Метод. рекомендации]

Глава 3.  Реализация ПО

Архитектурное проектирование

Архитектурным проектированием называют первый этап процесса проектирования, на котором определяются подсистемы, а также структура управления и взаимодействия подсистем.

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

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

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

Этапы, общие для всех процессов архитектурного проектирования:

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

2. Моделирование управления. Разрабатывается базовая модель управления взаимоотношениями между частями системы.

3. Модульная декомпозиция. Каждая определенная на первом этапе подсистема разбивается на отдельные модули. Здесь определяются типы модулей и типы их взаимосвязей.

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

Как правило, разрабатывается четыре архитектурные модели:

1. Статическая структурная модель, в которой представлены подсистемы или компоненты, разрабатываемые в дальнейшем независимо.

2. Динамическая модель процессов, в которой представлена организация процессов во время работы системы.

3. Интерфейсная модель,  которая определяет сервисы,  предоставляемые каждой подсистемой через общий интерфейс.

4. Модели отношений, в которых показаны взаимоотношения между частями системы, например поток данных между подсистемами.

Модели архитектуры могут зависеть от нефункциональных системных требований:

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

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

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

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

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

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

Рис. 34 ‑ Блок-схема системы управления автоматической упаковкой

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

1. Все совместно используемые данные хранятся в центральной базе данных, доступной всем подсистемам. Модель системы, основанная на совместном использовании базы данных, часто называют моделью репозитория.

2. Каждая подсистема имеет собственную базу данных. Взаимообмен данными между подсистемами происходит посредством передачи сообщений.

3. Модель репозитория

4. Совместное использование больших объемов данных эффективно, поскольку не требуется передавать данные из одной подсистемы в другие.

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

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

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

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

9. К разным подсистемам предъявляются разные требования, касающиеся безопасности, восстановления и резервирования данных. В модели репозитория ко всем подсистемам применяется одинаковая политика.

10. Модель совместного использования репозитория прозрачна: если новые подсистемы совместимы с согласованной моделью данных, их можно непосредственно интегрировать в систему.

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

Рис. 35 ‑ Архитектура интегрированного набора CASE-средcтв

Модель клиент/сервер

Модель архитектуры клиент/сервер — это модель распределенной системы, в которой показано распределение данных и процессов между несколькими процессорами. Модель включает три основных компонента:

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

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

3. Сеть, посредством которой клиенты получают доступ к сервисам.

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

Рис. 36 ‑ Архитектура библиотечной системы фильмов и фотографий

Модель абстрактной машины

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

Рис. 37 ‑ Модель абстрактной машины для системы администрирования версий

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

Можно выделить два основных типа управления:

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

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

Централизованное управление

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

Модель вызова-возврата. Это известная модель организации вызова программных процедур "сверху вниз", в которой управление начинается на вершине иерархии процедур и через вызовы передается на более нижние уровни иерархии. Данная модель применима только в последовательных системах.

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

Рис. 38 ‑ Модель вызова-возврата

Рис. 39 ‑ Модель диспетчера для системы реального времени

Управление, основанное на событиях

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

Модели передачи сообщений. В этих моделях событие представляет собой передачу сообщения всем подсистемам. Любая подсистема, которая обрабатывает данное событие, отвечает на него.

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

Рис. 40 ‑ Модель управления, основанная на передаче сообщений

Рис. 41 ‑ Модель управления, основанная на прерываниях

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

Распространены две модели, используемые на этапе модульной декомпозиции подсистем:

1. Объектно-ориентированная модель. Система состоит из набора взаимодействующих объектов.

2. Модель потоков данных. Система состоит из функциональных модулей, которые получают на входе данные и преобразуют их некоторым образом в выходные данные. Такой подход часто называется конвейерным.

В объектно-ориентированной модели модули представляют собой объекты с собственными состояниями и определенными операциями над этими состояниями. В модели потоков данных модули выполняют функциональные преобразования.

 Объектные модели

Рис. 42 ‑ Объектная модель системы обработки счетов

 Модели потоков данных

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

Рис. 43 ‑ Модель потоков данных для системы обработки счетов

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

Можно выделить два типа проблемно-зависимых архитектурных моделей:

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

2. Базовые модели. Более абстрактны и предоставляют разработчикам информацию по общей структуре какого-либо типа систем.

 Модели классов систем

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

Рис. 44 – Модель компилятора

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

Рис. 45 – Модель репозитория

Базовые архитектуры

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

Примером базовой архитектуры может служить модель OSI.

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

Вопросы для обсуждения

1. Объясните, почему архитектуру системы необходимо разработать до окончания создания спецификации.

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

3. Объясните, почему модель управления вызова-возврата обычно не подходит для систем реального времени, управляющих определенным процессом.

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

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

Проектирование с повторным использованием компонентов

В большинстве инженерных разработок процесс проектирования основан на повторном использовании уже имеющихся компонентов.

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

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

Метод проектирования ПО, основанный на повторном использовании, предполагает максимальное использование уже имеющихся программных объектов:

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

2. Повторно используемые компоненты.  Можно повторно  использовать компоненты приложений — от подсистем до отдельных объектов.

3. Повторно используемые функции. Можно повторно использовать программные компоненты, которые реализуют отдельные функции.

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

Таблица   3 ‑ Преимущества повторного использования кода

Для успешного проектирования и разработки ПО с повторным использованием компонентов должны выполняться три основных условия:

1. Возможность поиска необходимых системных компонентов.

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

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

Таблица 4 ‑ Проблемы повторного использования

Покомпонентная разработка

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

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

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

1. Интерфейс поставщика сервисов,  который определяет сервисы,  предоставляемые компонентом.

2. Интерфейс запросов, который определяет, какие сервисы доступны компоненту из системы, использующей этот компонент.

Рис. 46 ‑ Компонент службы печати

Компоненты могут существовать на разных уровнях абстракции:

-       Функциональная абстракция. Компонент реализует отдельную функцию. В сущности, интерфейсом поставщика сервисов здесь является сама функция.

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

-       Абстракции данных. Компонент является абстракцией данных или классом, описан­ным на объектно-ориентированном языке. Интерфейс поставщика сервисов состоит из методов (операций), обеспечивающих создание, изменение и получение доступа к абстракции данных.

-       Абстракции кластеров. Здесь компонент — это группа связанных классов, работающих совместно. Такие компоненты иногда называют структурой. Интерфейс поставщика сервисов является композицией всех интерфейсов объектов, составляющих структуру.

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

Рис. 47 ‑ Процесс проектирования с повторным использованием компонентов

Объектные структуры приложений

Существует три основных класса объектных структур:

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

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

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

 Одной из самых известных и распространенных объектных структур для графических интерфейсов пользователя (GUI) является объектная структура «модель-представление-контроллер»:

Рис. 48 – Пример объектной структуры

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

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

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

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

 Разработка повторно используемых компонентов

Разработка идеального компонента для повторного использования должна быть процессом (основанным на опыте и знаниях о проблемах повторного использования) создания обобщенных компонентов, которые можно адаптировать для разных вариантов их использования.

Программный компонент, предназначенный для повторного использования, имеет ряд особенностей:

-       Должен отражать стабильные абстракции предметной области, т.е. фундаментальные понятия области приложения, которые меняются медленно.

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

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

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

Семейства приложений

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

Существуют различные специализации семейств приложений:

1. Платформенная специализация, при которой для разных платформ разрабатываются свои версии приложения.

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

3. Функциональная специализация, при которой создаются разные версии приложения для заказчиков с различными требованиями.

Процесс адаптации семейства приложений для создания нового приложения состоит из нескольких этапов:

Рис. 49 – Процесс адаптации семейства приложений

Проектные паттерны

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

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

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

Основные элементы проектного паттерна:

1. Содержательное имя, которое является ссылкой на паттерн.

2. Описание проблемной области с перечислением всех ситуаций, в которых можно использовать паттерн.

3. Описание решений с отдельным описанием различных частей решения и их взаимоотношений. Это не описание конкретного проекта, а шаблон проектных решений, который можно использовать различными способами.

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

Часто в описание паттерна вводятся также разделы мотивации (обоснование полезности паттерна) и применимости (описание ситуаций, в которых можно использовать паттерн).

В качестве примера рассмотрим паттерн Обозреватель. Данный паттерн используется тогда, когда необходимы разные представления состояния объекта. Он выделяет нужный объект и представляет его в разных формах:

Рис. 50 ‑ Паттерн Обозреватель - используется тогда, когда необходимы разные представления состояния объекта. Он выделяет нужный объект и представляет его в разных формах

Проектирование интерфейса пользователя

Проектирование вычислительных систем охватывает широкий спектр проектных действий — от проектирования аппаратных средств до проектирования интерфейса пользователя.

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

Виды интерфейсов: текстовый и графический.

Графические интерфейсы обладают рядом преимуществ:

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

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

-       Режим полноэкранного отображения окон дает возможность прямого доступа к любому месту экрана.

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

Рис. 51 – Процесс проектирования интерфейса пользователя

Таблица  5 ‑  Принципы проектирования интерфейсов

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

Таблица  6 – Стили взаимодействия с пользователем

Таблица 7 ‑ Преимущества и недостатки стилей взаимодействия

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

Рис. 52 ‑ Модель с разделенными интерфейсом

Рис. 53 – Модель представления информации

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

-       Что нужно пользователю: точные значения данных или соотношения между значениями?

-       Насколько быстро будут происходить изменения значений данных? Нужно ли немедленно показывать пользователю изменение значений?

-       Должен ли пользователь предпринимать какие-либо действия в ответ на изменение данных?

-       Нужно ли пользователю взаимодействовать с отображаемой информацией посредством интерфейса с прямым манипулированием?

-       Информация должна отображаться в текстовом (описательно) или числовом формате? Важны ли относительные значения элементов данных?

Альтернативы

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

Янв Фев Март Апр Май Июль 2842 2851 3164 2789 1273 2835

Использование в интерфейсах цвета:

-       Используйте ограниченное количество цветов

-       Используйте разные цвета для показа изменений в состоянии системы

-       Для помощи пользователю используйте цветовое кодирование

-       Используйте цветовое кодирование продуманно и последовательно

-       Осторожно используйте дополняющие цвета

Рис. 54 ‑ Пример неправильного использования цветов

Средства поддержки пользователя

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

-       сообщения, генерируемые системой в ответ на действия пользователя;

-       диалоговая справочная система;

-       документация, поставляемая с системой.

Таблица 8 ‑ Факторы проектирования текстовых сообщений

Таблица 9 ‑ Факторы проектирования текстовых сообщений

Первое впечатление пользователя о системе основано на сообщениях об ошибках, они должны:

-       Быть последовательными и конструктивными

-       Быть вежливыми, краткими, не содержать оскорблений.

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

    Желательно:

-       Связать сообщение с контекстно-зависимой справкой.

-       Включить в сообщение варианты исправления ошибки.

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

Рис. 55 ‑ Пример справочной системы

Тексты справочной системы должны быть:

-       Написаны совместно с создателями приложения.

-       Продуманы так, чтобы его можно было прочитать в окне малого размера(только необходимая информация).

-       Адаптированы к неопытному пользователю.

Документация пользователя должна содержать 5 документов:

-       Функциональное описание, в котором кратко представлены функциональные возможности системы. Прочитав функциональное описание, пользователь должен определить, та ли это система, которая ему нужна.

-       Документ по инсталляции системы, в котором содержится информация по установке системы.

-       Вводное руководство, представляющее неформальное введение в систему, описывающее ее  "повседневное"  использование.

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

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

Рис. 56 ‑ Документация пользователя

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

Оценивание интерфейса

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

Таблица 10 ‑ Показатели удобства использования.

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

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

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

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

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

 Выводы

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

2. Важным аспектом интерфейса является грамотное взаимодействие с пользователем: ввод данных и их представление.

3. Разработчики ПО должны уделять должное внимание средствам поддержки пользователя.

4. Оценивание интерфейса является частью общего процесса тестирования и аттестации систем ПО.

Вопросы для обсуждения

1. Каково место проектирования и оценивания интерфейса пользователя в жизненном цикле ПО?

2. Почему проектирование интерфейса является важным моментом при создании ПО?

3. Какими принципами должен руководствоваться разработчик ПО при разработке интерфейса пользователя.

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

5. В каких случаях следует представлять «голые» данные для пользователя, а в каких некоторое представление от данных?

6. Какие ошибки допускают разработчики интерфейсов при использовании цветов?

7. Существует мнение, что пользователю необязательно показывать сообщение с ошибкой, а лучше исправить её системными средствами, не напрягая лишний раз пользователя. Верно ли оно? Обосновать.

8. Что входит в документацию пользователя?

9. Обосновано ли привлечение специалистов (каких?) для оценивания интерфейса?

[Глава 1] [Глава 2] [Глава 3] [Глава 4] [Глава 5] [Глава 6] [Глава 7] [Глоссарий] [Метод. рекомендации]

[Титульная] [Программа] [Учебное пособие] [Лабораторный практикум] [Дополнительные материалы]