Три описанных показателя оценивают только отдельные аспекты качества пользовательского интерфейса — главным образом те, которые связаны с эффективностью применения. Для проведения более глубокой оценки эти показатели необходимо объединить с другими параметрами и образовать большой метрический комплект. Хотя измерения не являются ответом на все вопросы разработки, «численная» разработка пользовательского интерфейса, основанная на хорошо продуманных измерениях параметров, позволяет на порядки поднять уровень юзабилити объектно-ори-ентированного программного обеспечения.
По материалам журнала Object Magazine, сентябрь 1997 г.
48
Связанные объекты
Что делает тот или иной предмет легким для понимания? Что делает тот или иной предмет простым в использовании? Что превращает совокупность объектов — не отдельных, а представленных в определенном контексте — в набор рабочих инструментов? Возьмем объекты, взаимосвязанные внутри программного обеспечения, или визуальные объекты, отображаемые в графическом пользовательском интерфейсе. Что делает их понятными? Что делает их удобными?
Эти главные вопросы знакомы всякому, кто когда-нибудь пробовал готовить на чужой кухне. Чтобы разобраться, где что находится, нужно несколько минут, и все равно придется спрашивать, где находится нож для чистки овощей или дуршлаг. Тем не менее постепенно, по мере того как вы обнаруживаете разные наборы предметов, вы начинаете замечать определенную логику в их размещении, и вскоре все становится на свои места.
Если только хозяин кухни не является человеком неорганизованным или если вы сами не привели эту кухню в полный беспорядок, можно предположить, что в одном из ящиков найдутся ножи. В банке, стоящей в буфете, может храниться набор деревянных ложек. Вероятно, кастрюли и сковородки составлены в шкафу, а их крышки находятся на специальной подставке. Или же кастрюли вместе с крышками стоят в кладовке.
Для приготовления пищи важно наличие посуды и нужных приспособлений, однако размещение кухонной утвари не менее важно для ощущений при готовке — будет ли это радость или полное разочарование.
Представьте, что все предметы на кухне переставлены так, что мерные емкости оказываются вместе с блюдцами, ножи для чистки овощей — со спичками, а крышки от кастрюль лежат на тарелках. Ставим микровол-новку в кладовку, а холодильник — в комнату. В раковину составляем консервы. Тарелки убираем в холодильник, а все ножи, ложки и вилки раскладываем на шкафах. И тут вы понимаете, что в этой, некогда хорошо обставленной кухне, теперь почти невозможно готовить.
Некоторые из современных пользовательских интерфейсов имеют приблизительно такую же степень хаоса. Форматирование абзаца и строки располагается в меню Формат, форматирование колонтитулов — в меню Вид, а форматирование страницы — в меню Файл. Человеческий мозг обладает такой способностью к приспособлению, что со временем может изучить почти любую схему расположения, какой бы хаотичной она ни была. Однако разумные схемы делают процесс изучения быстрее, а приготовление пищи — и работу с текстом — намного проще.
Конечно, кухни, как и пользовательские интерфейсы программного обеспечения, можно организовать несколькими способами и при этом сохранить в них разумный порядок. Большинство схем размещения утвари в кухне совмещают в себе больше одного вида логики. Некоторые предметы распределяются по категориям, другие — по способу применения, а третьи — по иным соображениям и ограничениям, таким как наличие ребенка. Тем не менее, хотя личные предпочтения могут отличаться большим разнообразием, одни способы разделения по категориям могут быть более разумны, чем другие. Некоторые формы организации могут быть концептуально красивы, но совершенно не подходить для практического применения. Для большинства людей было бы трудно готовить на кухне, организованной только по принципу формы — квадратные предметы в выдвижных ящиках, плоские и круглые в нижних шкафах, круглые и глубокие в верхних шкафах и т. д., - несмотря на простоту и очевидность такого порядка.
С другой стороны, некоторые виды категоризации (например, по материалам, из которых изготовлены предметы) являются более разумными и практичными, чем может показаться на первый взгляд. Собирать предметы из стекла, или серебра, или фарфора в одном месте разумно и удобно — отчасти потому, что такие наборы зачастую объединяют предметы не только по схожести материала, но и по схожести функционального назначения. Другой эффективный способ группирования — собирать предметы, которые обычно применяются вместе. Например, в одном шкафу можно хранить инструменты для выпечки: миксерные чашки, миксеры, изме-рительные стаканы и т. п. Т amp;кжб могут быть и промежуточные варианты: вилки обычно хранятся рядом с другими приборами, но каждый столовый набор, состоящий из ножа, вилки и ложки, обычно не хранится в виде отдельных комплектов, разве что в кухнях на самолетах.
Таким образом, качество организации кухни или компоновки пользовательского интерфейса зависит от того, как объекты связаны друг с другом и с выполняемой задачей. Целостность задач (см. главу 47) является мерой качества интерфейсов. Она оценивает степень, с какой данный дизайн интерфейса объединяет в одном пространстве элементы, которые применяются вместе в обычной задаче — в одной пользовательской ситуации. В этой главе речь пойдет о визуальном сцеплении. Это мера, с помощью которой можно оценить качество организации интерфейса в показателях объединения связанных между собой объектов и разделения несвязанных.
В объектно-ориентированной технологии давно признается важность хорошей организации программного обеспечения. Нас учат, что классы следует хорошо подбирать и определять. Они должны взаимодействовать между собой оптимальными и рациональными способами. Крепкая объектная архитектура сможет сохранить свою устойчивость под неизбежным и безжалостным натиском изменяющихся условий, добавлений и многократных исправлений. Она принесет пользу не только самим разработчикам, но и множеству других профессионалов, которые будут заниматься расшифровкой и пересмотром этой архитектуры.
Повседневный язык, который мы применяем для обсуждения этой темы — будь то кухни или программное обеспечение, — обнаруживает в своих этимологических корнях основы хорошей организации. Например, о хорошем дизайне, или об убедительном доказательстве, или об удобном интерфейсе мы говорим как о вещах связных и ясных. Связанные группы включают в себя предметы, скрепленные вместе. Если они крепятся друг к другу, то их легче понять, «схватить» — либо умом, либо руками.
Разумная объектно-ориентированная архитектура начинается с разумных объектных классов, построенных на устойчивой концептуальной основе, — с таких классов, которые объединяют в себе те методы и атрибуты, которые составляют связанное целое. Этот принцип связанности воплощается в одном из основных критериев качества программного обеспечения — сцеплении. Показатель сцепления известен давно. Впервые он был представлен как одно из ключевых понятий в структурном проектировании (Yourdon и Constantine, 1979 [70]), а затем стал одним из основных элементов современного проектирования программного обеспечения. Этот критерий применялся в различных видах, в том числе и в хорошо известном и широко обсуждаемом методе LCOM (Lack of Cohesion of Methods, метрика отсутствия сцепления в методах) (Chidamber и Kemerer, 1994 [7]; Henderson-Sellers, Constantine и Graham, 1996 [39]). Позднее критерий сцепления был доработан и расширен для того, чтобы лучше оценивать качество объектно-ориентированных проектов.
Что же означает сцепление и почему оно так важно для ОО-проектирова-ния? Сцепление — это мера смысловой и понятийной взаимосвязанности между частями какого-либо программного целого. Она основана на том принципе, что для более легкого понимания общей картины взаимосвязанные предметы необходимо размещать в одном месте, а менее зависимые предметы — отделять друг от друга. Таким образом, части соединяются в блоки, которые легче воспринять и понять в виде гештальтов — целых и интегрированных единиц. Столовые приборы находятся в одном шкафу, тарелки — в другом, и все это не смешивается с чайными чашками. Сцепленные объектные классы и системы, построенные на их основе, более просты для понимания как при создании программного обеспечения, так и в процессе применения, повторного использования или модификации.