Файл: Инфрам.pdf

237 круга конечных пользователей, не имеющих знаний в программирова- нии и в области вычислительной техники.
Программисты и специалисты по теории программирования обычно не имеют подготовки и опыта в проектировании такого рода. Они могут быть специалистами по языкам программирования, алгоритмам, мето- дам программирования, теории компиляторов, тестированию и отладке, но у них мало или вовсе нет опыта в использовании компьютера, разра- ботке психологических факторов, психологии взаимоотношений чело- века и машины. Было бы разумно использовать программистов для внешнего проектирования продукта, предназначенного для программи- стов, например, языков программирования или инструментов отладки, но неразумно ожидать, чтобы программисты выполняли внешнее про- ектирование операционной системы или системы диспетчеризации гру- зовиков.
Из-за сложности внешнего проектирования и его возрастающей важности для разработки ПС оно требует специалистов особого рода.
Такой специалист должен разбираться в соответствующей предметной области пользователя, быть знакомым со всеми этапами проектирова- ния и тестирования системы, чтобы понимать влияние на них внешнего проектирования. В качестве возможных кандидатов можно назвать сис- темных аналитиков, психологов, занимающихся вопросами поведения, специалистов по исследованию операций, а возможно, и опытных спе- циалистов по теории программирования (если их подготовка включает упомянутые области). Часто бывает полезно привлечь к этой работе технического писателя, так как его ориентированность на пользователя оказывается очень полезной.
5.4.2. Проектирование взаимодействия с пользователем
При проектировании внешних сопряжений системы разработчик ин- тересуется тремя областями, имеющими отношение к надежности про- граммной системы: минимизация ошибок пользователя, обнаружением ошибок пользователя, когда они все же возникают, и минимизацией сложности.
Между ошибками пользователя и ошибками в ПС имеет место опре- деленная связь. Ошибки пользователя увеличивают вероятность пере- хода системы в непредвиденное состояние. Минимизация ошибок поль- зователя не уменьшает числа ошибок в программной системе, но увели- чивает ее надежность за счет снижения вероятности столкновения с ос- тавшимися ошибками. Основные правила минимизации ошибок пользо- вателя в диалоговых (интерактивных) системах приводятся ниже.
Большинство из них имеет аналогию и для случая пакетной обработки.
Майерс Г. предлагает:
1. Согласовывать способ взаимодействия с подготовкой и уровнем пользователя, а также с ограничениями, в условиях которых пользова- тель работает. Интерфейс должен быть различен в зависимости от того, кто им пользуется. Например, можно ожидать, что взаимодействие с

238 пользователем банковской системы должно существенно различаться в зависимости от того, является ли пользователь клиентом банка или опытным кассиром.
2. Проектировать таким образом, чтобы сообщения, вводимые поль- зователем, были как можно короче, но не настолько, чтобы исчезла их осмысленность. При этом следует учитывать частоту работы с системой для среднего пользователя, а также возможность стрессовой ситуации для пользователя в момент его работы с системой.
3. Обеспечивать концептуальную целостность для разных типов вводимых и выводимых сообщений. Например, все сообщения, выда- ваемые на экран дисплея, отчеты, графические документы и т. п. долж- ны иметь одинаковые (по возможности) форматы, стиль, сокращения.
4. Обеспечивать пользователю средства “помощи" с достаточно ши- роким набором функций. При разработке листингов помощи важно планировать короткие ответы на запросы пользователя.
5. Проектировать сообщения пользователю в короткой форме и при- ближайте язык сообщений к языку пользователя.
6. Проектировать подтверждение ввода данных с тем, чтобы поль- зователь или оператор знал о завершении процесса. Без этого пользова- тель может засомневаться, правильно ли введено сообщение, и попыта- ется повторить ввод, вследствие чего может возникнуть ошибочная си- туация.
Кроме доведения до минимума ошибок пользователя (за счет пра- вильно спроектированного интерфейса) система должна правильно об- рабатывать ошибки пользователя, а они будут независимо от того, на- сколько хорошо спроектированы правила взаимодействия. Основные правила обнаружения ошибок пользователя перечислены ниже [18].
1. Проектируйте систему так, чтобы она принимала любые данные.
Если введенная информация не является тем, что система считает до- пустимым, она должна информировать пользователя об этом.
2. Если пользователь вводит сложное сообщение, особенно если для этого нужно несколько обращений к системе, позвольте ему проверить части сообщения, прежде чем оно будет обрабатываться.
3. Проектируйте систему так, чтобы ошибки пользователя обрабаты- вались немедленно.
4. Там, где особенно важна точность, проектируйте избыточность входных данных. Например, в банковской системе можно потребовать, чтобы фамилия клиента вводилась вместе с номером счета, так чтобы можно было обнаружить ошибки при вводе номеров счетов.
Другой возможностью повышения надежности системы является до- ведение до минимума сложности внешнего проекта, с целью уменьше- ния сложности будущей системы и минимизации ошибок пользовате- лей. Распространено мнение, что интеллектуальный (“очеловеченный”) внешний проект будет сложным, что он предполагает фантастические по сложности методы, много дополнительных возможностей, автомати- ческое исправление ошибок (например, орфографических). По мнению
Г. Майерса [18], это представление ошибочно. Например, современные

239
ПС, такие как поисковые и справочные системы (возьмите тот же Ян- декс), достаточно интеллектуальны.
Вторая проблема, связанная со сложностью, – предоставление поль- зователю слишком большого числа возможностей и вариантов. В опе- рационной системе OS/360 (как и в советской ОС ЕС ЭВМ) имеется процесс настройки, называемый генерацией системы, который позволя- ет “перекраивать” систему при ее установке. Это привело к тому, что почти каждая установка OS/360 имеет уникальную версию, что услож- нило работу компании IBM по сопровождению системы.
Всякий раз, когда есть сомнения, давать пользователю некоторую возможность или нет, слишком часто принимается решение “давать”. В целом же большой набор режимов (вариантов) не нужен пользователю, поскольку часто их обилие неблагоприятно сказывается на работе поль- зователя. К этому надо добавить, что всякая дополнительная возмож- ность или режим работы системы усложняет ее, что приводит к допол- нительным ошибкам.
Проектировщик должен рассматривать каждый режим или функцио- нальность системы с учетом его полезности в противовес внесению до- полнительной сложности из-за достижения удобств пользователю. Ко- гда возникают сомнения, безопаснее отказаться от рассматриваемого варианта. Множество доступных мелких возможностей не повысят кон- курентоспособности продукта. Кроме того, эти возможности могут не- гативно повлиять на потенциального покупателя, показывая, что разра- ботчик не имеет ясного представления о том, как именно система будет использоваться.
Последний вопрос, связанный с надежностью, – на каких предполо- жениях основывается система, воспринимающая входные данные. На- пример, из каких соображений она пытается исправлять ошибки поль- зователя. Методы такого рода настолько сложны, что часто становятся опасными (см. пример на стр. 68 в [18]). Решением при проектировании интерфейса пользователя для надежной программной системы является обеспечение однородного и простого интерфейса, ожидающего некото- рый набор входных данных и немедленно обнаруживающего как можно больше ошибок.
5.4.3. Подготовка внешних спецификаций
Правильно составленные внешние спецификации – объемистый до- кумент. Эффективным методом создания такого большого документа является применение к нему иерархической организации. В п. 4.1 внеш- нее проектирование представлялось в виде двух процессов: первона- чального (предварительного) и подробного внешнего проектирования.
Допуская, что спецификации являются иерархически организованными, эти два процесса просто представляют контрольные точки в проектиро- вании системы согласно принятой иерархии. Сначала описываются ос- новные компоненты (то, что находится на первом уровне), затем просто компоненты, затем внешние функции (функции пользователя) и в конце

240 концов – детали всех функций пользователя. Предварительное внешнее проектирование включает три первых шага.
Система проектируется до уровня, когда уже выделены все функции пользователя, но точный их синтаксис, семантика и выходные результа- ты остаются еще не определенными. При этом преследуются две цели: во-первых, внутри продолжительного процесса внешнего проектирова- ния устанавливается контрольная точка для руководства проекта и, во- вторых, становится возможной проверка правильности промежуточного уровня проекта и сопоставление его с поставленными целями. В качест- ве примера на рис. 5.35 показан основной компонент управляющий, в рамках этого основного компонента примером компонента может быть администратор секретности. А в рамках этого компонента примером функции может быть приказ Сообщить о нарушениях секретности
(пример взят из [18]).
Рис. 5.35. Иерархическая организация спецификаций
Публикация [18] относится к тому времени, когда CASE-средства, поддерживающие процессы проектирования программных систем, только начали развиваться. В настоящее время для целей моделирова- ния процессов проектирования ПС на рынке программных продуктов представлен широкий спектр CASE-средств. В нашей стране в начале
2000-х годов наиболее популярными CASE-средствами являлись
Rational Rose, BPwin, Silverrun, Process Analyst [13]. Моделирование жизненного цикла программных систем в этих средствах имеет много общего, хотя есть и различия. Немаловажным является комплексность подхода и использование единой унифицированной нотации, не только на этапе моделирования предметной области, но и на последующих эта- пах разработки программной системы, как это имеет место в CASE
Rational Rose.

241
Развитием Rational Rose явилось новое CASE-средство – IBM
Rational Software Architect (RSA), являющееся частью IBM Software
Development Platform – набора инструментов, поддерживающих жиз- ненный цикл разработки программных систем [14, 16, 26]. IBM Rational
Software Architect предназначен для построения моделей разрабатывае- мых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разраба- тываемого приложения. Кроме того, Rational Software Architect поддер- живает технологию разработки, управляемой моделями (model-driven development, MDD), позволяющую моделировать программное обеспе- чение на различных уровнях абстракции с возможностью трассируемо- сти [21].
Следуя принципам RUP, Rational Software Architect позволяет созда- вать необходимые модели в рамках рабочих процессов таких дисцип- лин, как [23]: управление требованиями (Requirements); анализ и проектирование (Analysis and Design); реализация (Implementation).
Для решения задач подготовки внешних спецификаций RSA предос- тавляет разработчику средства построения диаграмм вариантов исполь-
зования, диаграмм деятельности и диаграммы состояний. Варианты использования специфицируют внешнее поведение, ничего не говоря о том, как его достичь. Это важно, потому что позволяет эксперту или конечному пользователю общаться с разработчиками, конструирующи- ми систему в соответствии с требованиями пользователя (заказчика), не углубляясь в детали реализации. Диаграммы деятельности показывают структуру процесса как пошаговый поток управления и данных. Они описывают динамическое представление системы и важны при модели- ровании функций системы. Диаграммы состояний также описывают динамическое представление объекта. Они важны для моделирования поведения интерфейсов, классов или коопераций (вместе функциони- рующих объектов, обеспечивая совместное поведение).
Детальный внешний проект каждой функции пользователя должен освещать следующие вопросы.
1. Описание входных данных. Точное описание синтаксиса (напри- мер. формат, допустимые значения, области изменения) и семантики всех данных, вводимых пользователем. Этими данными могут быть приказ, входной документ (форма), ответ на подсказку или аналоговый
(цифровой) сигнал от внешних устройств.
2. Описание выходных данных. Точное описание всех результатов
(выводов) функции, например, реакции терминала, сообщения об ошиб- ках, отчеты, аналоговые (цифровые) управляющие сигналы для внеш- них устройств и т. п. должна быть описана функциональная связь вход- ных сигналов с выходными. Это значит, что читатель спецификаций должен быть в состоянии представить себе выходные данные, порож- денные каждым конкретным вариантом входных данных.

242 3. Преобразования системы. Многие внешние функции не только порождают выходные данные, но и изменяют состояние системы. В этом случае должны быть описаны все такие преобразования системы с точки зрения пользователя, так как спецификация является внешней.
Например, складская система могла бы иметь команду “заказ”, которая используется продавцом, чтобы начать выполнение заказа. Эта функция имеет два выходных результата: накладная, которая пересылается в от- дел доставки, и подтверждение, выдаваемое на терминал продавца. Она вызывает также два преобразования системы: обновляется инвентарный файл и заказ регистрируется в файле контроля.
4. Характеристики надежности. Это описание воздействия всех воз- можных отказов функций на саму систему, файлы (базы данных) и пользователя. Установлено, что включение этого раздела в проект внешних спецификаций оказывает небольшое, но положительное влия- ние на надежность [18]. В проекте разработки интерактивной системы необходимо, чтобы предложение “любая ошибка в этой команде не должна вызывать сбоя системы” имело место в этом разделе для каждой команды. Хотя разработчики, проектирующие внутреннюю структуру системы, никогда сознательно не допустили бы, чтобы ошибка в коман- де пользователя вызывала общесистемный сбой, это предложение слу- жит постоянным напоминанием данного факта.
5. Эффективность. Это описание всех требований, которые предъяв- ляются к эффективности функции, таких как затрачиваемое время, и используемая память. эффективность можно редко специфицировать как абсолют, так как она зависит от конфигураций аппаратуры (компь- ютера), скорости передачи данных по линиям связи, эффективности всех других параллельно выполняющихся программ , числа активных пользовательских терминалов и др. Чтобы справиться с этой проблемой, в спецификациях можно описать несколько стандартных конфигураций и уровней нагрузки, а затем можно указать эффективность отдельных функций по отношению к ним.
6. Замечания по программированию. Внешние спецификации долж- ны описывать продукты с точки зрения пользователя и избегать ограни- чений на внутренне устройство системы. Однако иногда бывает необхо- димо подсказать или сообщить какие-то идеи относительно внутреннего проектирования функции. Практиковать это следует как можно реже, но если это необходимо, соответствующую информацию нужно сообщать в этом разделе.
Для всякой достаточно сложной функции задача описания функцио- нальных связей результатов и преобразований с входными данными нетривиальна. Отличный способ справиться с этой проблемой – таблица решений [18]. На рис. 5.36 показана таблица решений для команды L
(ОТГРУЗИТЬ_ДЕТАЛИ) из спецификации для складской системы. Ко- манда L имеет три операнда: N
п