1. Браузер (browser) - используется для быстрой навигации по модели;
2. Панели инструментов (toolbars) - обеспечивает быстрый доступ к наиболее распространенным командам;
3. Окно диаграммы (diagram window) - используется для просмотра и редактирования одной или нескольких диаграмм UML;
4. Окно документации (documentation window) - используется для работы с документацией элементов модели;
5. Журнал (log) - применяется для просмотра ошибок и отчетов о результатах выполнения различных команд.

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

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

Браузер поддерживает четыре представления (view): представление Вариантов Использования, Компонентов, Размещения и Логическое представление. Содержимое данных представлений представлено в следующей таблице:

Представление	Содержание
Представление Вариантов Использования	Действующие лица Варианты использования Документация по вариантам использования Диаграммы вариантов использования Диаграммы последовательности Диаграммы кооперации Пакеты
Логическое представление	Классы Диаграммы классов Диаграммы взаимодействия Диаграммы состояний Пакеты
Представление компонентов	Компоненты Диаграммы компонентов Пакеты
Представление размещения	Процессы Процессоры Устройства Диаграммы размещения

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

В начале работы над проектом представление Вариантов Использования необходимо заказчикам, аналитикам и менеджерам проекта. Работая с вариантами использования, их диаграммами и документацией, они смогут прийти к соглашению о том, как должна выглядеть система на высоком уровне. Еще раз подчеркнем, что это представление рассматривает только, что именно будет делать система. Обсуждение деталей ее реализации следует оставить на будущее.
В процессе работы над проектом все члены команды могут ознакомиться с этим представлением, чтобы достичь понимания системы на высоком уровне. Документация варианта использования описывает соответствующий поток событий. С помощью этой информации специалисты по контролю качества смогут приступить к созданию тестовых программ для системы, а технические писатели - документации для пользователей. Аналитики и заказчики будут уверены, что учтены все требования. Разработчики поймут, какие высокоуровневые элементы системы предстоит создать и как будет работать ее логика.
Согласовав варианты использования и действующих лиц, заказчики должны будут принять решение и по поводу области применения (scope) системы. После этого разработчики смогут перейти к ее Логическому представлению, уделяющему больше внимания тому, как система будет реализовывать поведение, определяемое вариантами использования.

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

Часто разработка Логического представления осуществляется в два этапа. Сначала определяются классы анализа (analysis classes). Они не зависят от языка программирования. Создавая их в первую очередь, разработчики могут увидеть структуру системы, не углубляясь в специфические особенности конкретного языка. В языке UML для изображения классов анализа используют следующие пиктограммы:

Классы анализа могут появляться также на диаграммах взаимодействия в представлении Вариантов Использования. После определения всех классов анализа каждый из них может быть преобразован в класс проекта (design class). Класс проекта уже содержит специфические для данного языка детали. Например, можно представить себе класс анализа, отвечающий за обмен информацией с другой системой. Нас пока не интересует, на каком языке он будет написан, мы уделяем внимание только его данным и поведению. Но преобразуя его в класс проекта, нам придется коснуться специфических для языка деталей. Допустим, что это будет класс Java. Тогда для реализации того, что мы заложили в класс анализа, нам могут понадобиться два класса Java. Это значит, что отсутствует строгое соответствие между классами того и другого типа. Классы проекта изображают на диаграммах взаимодействия Логического представления системы.

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

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

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

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