Моделирование интерфейса с пользователем (GUI) в Rational Rose с использованием Rational Unified Process (RUP)

Введение

Вопросам моделирования GUI обычно уделяют мало внимания. Многие специалисты считают, что проблема GUI достаточно легко решается применением современных средств быстрого построения интерфейса, например, таких как Delphi или VisualAge.

В подтверждение этого автор может сослаться на форум по UML, который компания Rational организовала на своем сайте. Однажды там был задан вопрос, какие существуют средства для моделирования GUI. Человек, задавший вопрос, обращал внимание на то, что интерфейс в его системе - очень сложная и большая часть проекта и ему хотелось бы иметь возможность посмотреть ее на моделях. Единственый ответ-рекомендация предлагал воспользоватья средствами быстрого построения интерфейса, и лучше всего Borland Delphi / C++ Builder. В этом ответе несомненно есть доля истины, и автор сам так многократно поступал. Тем не менее, RUP содержит достаточно подробные рекомендации касательно того, как строить GUI, предварительно его моделируя. И, что на мой взгляд гораздо более важно, эти рекомендации хорошо вписаны в общую Rational-методологию разработки сложных систем.

Рассмотрению некоторых сторон этих рекомендаций RUP я и хочу посвятить настоящую статью.

В ответ на ворпрос “Как моделировать GUI?” автор хотел бы поделиться собственным опытом применения этой технологии при работе над конкретным проектом. Основная часть статьи посвящена смылсу и содержанию понятию “Use-сase Storyboard”, используемому для построения модели GUI в RUP. А для иллюстрации будут приведены два примера, реализованные в Rational Rose.

Для того, чтобы перейти к описанию методологии проктирования GUI., основанной на Use-case Storyboard, мне необходимо уточнить два вспомогательных вопроса:

• многооконный интерфейс, его организация с точки зрения RUP, и
• essential (существенный) Use-case.

Хотелось бы отметить те аспекты многооконного интерфейса, которые RUP считает фундаментальными. Это возможность свободно перемещать окна по экрану, накладывать их друг на друга и превращать в иконки и т.д. Я не буду их все перечислять – они достаточно хорошо известны. Остановлюсь лишь на тех, которые менее очевидны.

RUP настоятельно рекомендует, чтобы проектируемая система в качестве интерфейса с пользователем имела одно primary-(первичное) окно и некоторое количество secondary-(вторичных) окон.

Primary-окно обрабатывает главные взаимодействия с пользователем и обычно содержит произвольное число объектов. Secondary-окна используются как вспомогательные для того, чтобы обеспечить возможность работать с деталями объектов primary-окна, например такими, как свойства объектов.

В большинстве случаев можно провести четкое разграничение между primary и secondary окнами. Primary являются более важными и большая часть проектной работы ведется с ними. Secondary-окна всегда доступны через primary-окно, но не наоборот. Отметим, что к числу secondary-окон относятся также диалоговые окна, окна сообщений, выбора цветов, файлов и др.

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

Основной вывод, который делает RUP, касающийся многооконного интерфейса, состоит в следующем.

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

Термин Essential Use case активно используется в концепции User Centered Design (Проектирование, ориентированное на пользователя), которая лишь частично заимствуется RUP.

Это понятие является качественным, и потому не существует его строгого определения. Для того, чтобы понять различие между Essential Use case и обычным Use-case, обратимся к примеру, приведенному в RUP, который, в свою очередь заимствован из книги Constantine&Lockwood Software for Use.

Таблица 1: Use-case для описания получения наличных денег с помощью ATM-машины (банкомата).

Таблица 2: Essential Use-case для описания получения наличных денег с помощью ATM-машины (банкомата)

Различие между двумя описаниями: первый Use-case не является Essential Use-case, поскольку в нем присутствуют синтаксические детали взаимодействия, которые описывают КАК происходит это взаимодействие. Второе описание является Essential Use-Case, поскольку оно акцентирует внимание на том, НА ЧТО нацелено взаимодействие, т.е. определяет его семантику.

Моделирование GUI с помощью Use-case Storyboard

По определению, данному в RUP, Use-case Storyboard - это логическое и концептуальное описание того, как Use-case обеспечивается интерфейсом с пользователем, включая требуемое взаимодействие между Экторами и Системой.

Рассматриваемый термин состоит из двух частей: Use-case и Storyboard. Термин Use-case в настоящее время получил достаточное широкое распространение, и потому не требует пояснения. Термин Storyboard заимствован из киноиндустрии и означает следующее: последовательность простых картинок, которые изображают важные изменения в сценах и действиях в планируемом фильме или видео-продукции.

Термин Storyboard также используется в RUP вне рассматриваемого контекста моделирования интерфейса и означает применение некоторых простых (или не очень простых) инструментов для иллюстрации того, как система вписывается в работу организации или как работает сама система. К простым инструментам относятся бумага, карандаш, GUI-buider. Примером более сложных являются PowerPoint, Macromedia Director и некоторые другие.

Как единый термин Use-сase Storyboard используется для понимания требований к интерфейсу с пользователем, включая нефункциональные требования, такие как требование используемости (usability) etc. Например, максимальное время выполнения некоторого сценария.

Use-сase Storyboard представляет высокоуровневое понимание интерфейса с пользователем, который можно разработать быстрее, чем реальный интерфейс с пользователем. Он может быть использован для создания нескольких модельных версий интерфейса прежде, чем реальный интерфейс будет прототипирован, спроектирован и реализован.

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

Рассмотрим последовательность построения Use-сase Storyboard в контексте Rational Rose ( далее эта последовательность будет проиллюстрирована на конкретных примерах ):

1. В Logical View построить соответствующий модельный элемент. Если данная версия не включает такой элемент, можно использовать Use-сase-элемент со стереотипом use-case storyboard.
2. Связать этот элемент с тем Use-сase, для которого был построен данный модельный элемент. Это можно сделать с помощью диаграммы классов, поместив на нее оба элемента и установив между ними отношение типа Dependency (Use-сase Storyboard зависит от Use-сase) со стереотипом trace.
3. Для Use-сase построить его essential (существенный) Use-сase, определяющий семантику потока событий. В RUP он получил название storyboard и помещается в документальную часть элемента Use-сase Storyboard.
4. Storyboard (точнее говоря каждый его элемент из потока событий) может быть дополнен некоторой информацией, которая не будет использоваться при моделировании, но которая может оказаться полезной на более поздних этапах, например при построении прототипа интерфейса. Эта информация не является функциональными требованиями и может быть представлена в следующем виде:

   Желательные рекомендации (desired guidance) – определяют, что делать для того, чтобы пользователь не потонул в огромном потоке второстепеной информации.

   Средние значения атрибутов и размеры объектов (average attribute values and object volumes) – позволяют выбрать оптимальные размеры визуальных компонентов.

   Средняя частота использования (average action usage) – позволяет часто используемые операции представлять в виде отдельных иконок.

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

   Один граничный класс должен быть определен для primary-окна;

   Один граничный класс должен быть определен для каждого объекта, который будет использован эктором. Для каждого такого объекта часто используется secondary-окно, например в качестве окна-свойства;

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

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

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

Пример 1

Рассмотрим простой пример из RUP, иллюстрирующий некоторые аспекты построения Use-Case Storyboard.

Этот пример представляет упрощенный вариант программы почтового (e-mail) обслуживания пользователя. Предполагается, что эта программа описывается единственным use-case, текст которого опущен.

Ниже приведен storyboard для этого use-case.

a) Use-case начинает свою работу, когда пользовательвходящей почты запрашивает текущую почту,и система отображает список сообщений.
[Пользователь должен иметь возможность различать новые, ранее прочитанные и непрочитанные сообщения. ]
{В среднем около 100 сообщений показываются одновременно и в 90% случаев subject -заголовок сообщения содержит менее 40 букв.}
"Mail Box"

b) Пользователь входящей почты может выполнить одно из следующих действий:

g) Use-case завершается когда пользователь входящей почты выдает запрос на завершение работы.

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

В качестве граничных классов используются:

MailBox – определяет основное окно,

MailMessage – определяет e-mail соообщение,

Attachment – определяет attachment-файл.

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

Ниже, для рассматриваемого примера, приведены диаграмма классов и collaboration-диаграмма для достаточно простого сценария, который включает:

Тривиальность данного примера не требует дополнительного коментария.

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

Будем понимать, в простейшем случае, линейный классификатор (ЛК) - как совокупность элементов. Например, перечень единиц измерения (метры, килограммы, штуки и т.д.).

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

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

Ниже приведена небольшая часть storyboard, которая используется в данном примере. Так же, как в первом примере, текст исходного use-case опущен.

1. Эктор, Лицо ответственное за ведение классификаторов, запускает подсистему ЛК.
2. Эктор может выполнить одно из следующих действий:
   1. Добавить новый ЛК.
   2. Добавить новый атрибут в общий список атрибутов для всех ЛК.
   3. Добавить атрибут из общего списка атрибутов в выбранный ЛК.
   4. Добавить новую связь для выбранного ЛК.
   5. Добавить новый элемент для выбранного ЛК, включая имя элемента, значение его атрибутов, связи с элементами других ЛК.
3. Эктор завершает работу подсистемы ЛК.

После построения storyboard RUP рекомендует установить отношение зависимости со стереотипом trace между нашим use-case storyboard и исходным use-case. Ниже приведена соответствующая диаграмма.

Далее необходимо определить граничные (boundary) классы. Граничные классы, используемые в нашем примере, выявляются из анализа storyboard. Ниже приведена диаграмма классов, которая использует эти граничные классы. Для обеспечения большей наглядности исходая диаграмма классов разбита на три диаграммы:

1. общая часть;
2. линейный классификатор с атрибутами;
3. линейный классификатор со связями.

Кроме того, при построении рассматриваемой диаграммы применен один из рекомендуемых RUP принципов построения GUI - разделение интерфейса с пользователем на primary- и secondary-окна.

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

Для диаграммы классов 3, линейный классификатор со связями, входящие в нее граничные классы, приведены вместе с их ответственностями (responsibilities).

Для различных сценариев использования GUI можно построить диаграммы взаимодействия в терминах граничных объектов. Как правило, для use-case storyboard используются collaboration-диаграммы.

Use-case storyboard используется главным образом на начальных этапах проекта, перед тем, как возможно будет построен прототип интерфейса с пользователем.

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

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

Отметим также, что граничные классы, которые выявляются на этапе построения use-case storyboard являются очень удобными артефактами для последующего этапа, связанного с Анализом проекта.

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

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Rational Software
Отправить ссылку на страницу по e-mail