Логическое представление

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

Логическое представление содержит:

	Классы, являющиеся строительными блоками системы. Класс состоит из небольшого количества данных (атрибутов) и некоторого поведения (операций), сгруппированных вместе. Например, класс Employee (работник) может в качестве данных содержать имя работника, его адрес и номер социальной страховки, а в качестве поведения — прием на работу и увольнение.
	Диаграммы Классов, используемые для представления классов системы, их атрибутов, операций и связей друг с другом. Как правило, для описания системы применяется несколько диаграмм Классов, каждая из которых отображает некоторое подмножество всех классов системы.
	Диаграммы Взаимодействия, применяемые для отображения классов, участвующих в одном потоке событий варианта использования. Как упоминалось ранее, диаграммы Взаимодействия создаются в представлении Вариантов Использования или в Логическом представлении. При этом, как правило, в первом случае на диаграммах изображают объекты, а во втором — классы системы.
	Диаграммы 'Состояний, описывающие динамику поведения объекта. Они включают в себя все состояния, в которых данный объект может существовать. Они также показывают, как объект переходит из одного состояния в другое, в каком состоянии он находится сразу после создания и в каком — непосредственно перед уничтожением.
	Пакеты, являющиеся группами взаимосвязанных классов. Объединять классы в пакеты не обязательно, но настоятельно рекомендуется. Типичная система может содержать сотню или более классов, и объединение их в пакеты помогает уменьшить сложность модели. Для понимания общей картины системы достаточно взглянуть на ее пакеты. Чтобы изучить систему на более детальном уровне, приходится углубляться в пакеты и исследовать классы, находящиеся внутри.

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

Граничный класс (boundary)

Управляющий класс (control)

Сущность (entity)

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

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

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

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

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

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