Информация об области видимости

Для каждого члена класса необходимо указать область его видимости. Существует три вида областей видимости:

– public (+) – член класса виден за его пределами;

– protected (#) – член класса виден только самому классу и его потомкам;

– private (–) – член класса виден только самому классу.

 

 

Рис. 86. Диаграмма классов для системы розничной торговли

 

На рис. 86 все члены классов имеют видимость public, т.к. на данной диаграмме изображена модель спецификации. В данном случае атрибут Платеж.Сумма следует воспринимать как свойство класса. На модели реализации данное свойство может быть реализовано как скрытое поле и пара методов доступа (рис. 87).

Вычислимые атрибуты

Вычислимые атрибуты – это такие атрибуты, чье значение класс не хранит, а вычисляет при каждом обращении. Примерами вычислимых атрибутов на рис. 86 являются Продажа.Сумма и ТоварнаяПозиция.Сумма. Перед име­нем вычислимого атрибута ставится слэш.

Рис. 87. Реализация свойства при помощи скрытого поля
и двух методов доступа

Направление навигации

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

Зависимости

Зависимости используются для отражения способов видимости, отличных от видимости посредством ассоциаций. Например, товарная позиция вызывает методы каталога товара (зависимость «call»), доступ к которому она получает через продажу и систему розничной торговли.

Вопросы для самоконтроля

1. Какие видимости членов класса бывают? В чем разница при использовании разных видов видимости?

2. Что такое параметризованный класс?

3. Как определить состав операций класса?

Задания для самостоятельной работы

1. Постройте концептуальную модель диаграммы классов.

2. Постройте диаграммы классов для учебного задания.

Рекомендации по построению
диаграмм классов

При построении диаграмм классов придерживайтесь тех же правил, что и при построении диаграмм понятий. Дополнительно можно посоветовать воспользоваться CRC-карточками (Class Responsibility Card – карточка ответственности класса).

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

Если Вы затрудняетесь сформулировать обязанности некоторого класса, то стоит задуматься о его необходимости.

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

Тема 6.8. Модель реализации и диаграмма компонентов

Тематический контекст

Краткое содержание

1. Модель реализации.

2. Диаграмма компонентов. Основные элементы диаграммы компонентов: компоненты, интерфейсы, зависимости.

3. Использование стереотипов.

Модель реализации

В предыдущих разделах были рассмотрены модели анализа и проектирования, которые призваны ответить на вопросы «Что делать?» и «Как делать?» соответственно. Модель реализации завершает описание системы и акцентирует внимание на ее физической структуре. Под физической структурой в данном случае понимается как набор программных компонентов, так и аппаратные средства, на которых они размещаются и исполняются.

Для построения моделей реализации в UML используется два типа диаграмм – диаграммы компонентов и диаграммы развертывания. Рассмотрим диаграмму компонентов.

Диаграмма компонентов

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

Рис. 88. Пример диаграммы компонентов

Компоненты

Основным элементом диаграммы компонентов является компонент, для изображения которого используется прямоугольник с двумя небольшими накладками с левой стороны (рис. 89).

Рис. 89. Пример компонента

Стереотипы

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

Рис. 90. Пример использования стереотипа

Пиктограммы

Для повышения наглядности диаграммы в стандарте UML предусмотрена возможность связать с каждым стереотипом некоторую пиктограмму, которая более точно, по сравнения со стандартной нотацией, отражает его суть (рис. 91). Однако не стоит забывать о том, что основное достоинство UML – это его стандартная нотация, понятная большинству разработчиков и аналитиков. Поэтому если принимается решение о введении нестандартного обозначения для некоторого стереотипа, то необходимо позаботиться о том, чтобы оно было максимально простым и понятным, находилось в рамках принятых в UML соглашений и не выбивалось и общего визуального ряда.

Рис. 91. Пример нестандартной нотации для компонента
со стереотипом «database»

Интерфейсы

Если компонент представляет собой некоторый программный модуль, то в большинстве случаев он будет реализовывать один или несколько интерфейсов. Наличие этих интерфейсов является необходимым условием того, чтобы компонент можно было использовать в другом контексте или, при необходимости, заменить другим. Интерфейс на диаграмме компонентов обозначается так же, как это принято в COM-технологии – при помощи отрезка с окружностью на конце (рис. 92).

Рис. 92. Пример компонента, который реализует интерфейс

Зависимости

Одной из важнейших целей построения диаграмм компонентов является выделение и визуализация зависимостей между частями системы. Если один компонент потребляет услуги (например, библиотека классов) или ресурсы (например, изображение) другого компонента, то он зависит от него. Зависимость между компонентами изображается при помощи пунктирной стрелки, направленной от зависимого компонента к независимому (рис. 93).

Рис. 93. Пример зависимости между компонентами

Компоненты, связанные отношением зависимости, должны находиться «близко» друг к другу. Степень «близости» (одна папка, один компьютер, локальная сеть) определяется требованиями конкретной ситуации. Если не отслеживать зависимости между компонентами, то высока вероятность того, что в процессе разработки система превратится в груду файлов, про многие из которых сложно будет сказать, нужны они или нет. Это усложняет разработку и приводит к засорению компьютеров конечных пользователей.

Вопросы для самоконтроля

1. Что такое компонент?

2. Как компонент связан с классами и интерфейсами?

3. Какие преимущества дает использование стереотипов на диаграмме компонентов?

Задания для самостоятельной работы

1. Постройте концептуальную модель диаграммы компонентов.

2. Постройте диаграмму компонентов для учебного задания.

Рекомендации по построению диаграммы
компонентов

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

Тема 6.9. Модель и диаграмма развертывания

Тематический конспект

Краткое содержание

1. Модель развертывания.

2. Диаграмма развертывания.

3. Узлы. Разделение узлов на процессоры и устройства.

4. Использование стереотипов.

Модель развертывания

Для функционирования любой программной системы требуется аппаратное обеспечение. В случае информационных систем оно редко ограничивается одним компьютером и обычно представляет собой сложную систему аппаратных средств. Такая система может включать в себя клиентские компьютеры, компьютерные терминалы, серверы различного назначения, средства коммуникации, системы хранения данных, специализированные устройства (например, сканер штрих-кодов или датчик подачи топлива), сетевые принтеры и т.д. Каждое из этих устройств обладает рядом характеристик (таких как тактовая частота, объем памяти, пропускная способность и т.д.), на значения которых разрабатываемая информационная система накладывает определенные ограничения. Все эти аспекты, безусловно, нуждаются в описании и являются составляющими модели развертывания системы.

Определение. Модель развертывания – это описание состава, характеристик и топологии аппаратных средств, а также распределения компонентов системы между ними.

Диаграмма развертывания

Для визуализации модели развертывания в UML используется диаграмма развертывания. Пример диаграммы развертывания приведен на рис. 94.

Рис. 94. Пример диаграммы развертывания

Узлы

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

Определение. Узел – это элемент аппаратного комплекса, который представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти. Совокупность компонентов может размещаться на узле, а также мигрировать с одного узла на другой.

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

Стереотипы

Так же как и на диаграмме компонентов, на диаграмме развертывания часто используются стереотипы, для некоторых из которых вводится нестандартная нотация. При расширении диаграмм развертывания следует придерживаться тех же рекомендаций, что и для диаграмм компонентов. На рис. 95 приведен пример использования стереотипов, в котором для узлов «Internet» и «Модемный пул» были использованы нестандартные обозначения.

Рис. 95. Пример использования стереотипов на диаграмме развертывания

Вопросы для самоконтроля

1. Что такое узел?

2. В чем разница и какая связь между узлами и компонентами?

3. Чем отличается процессор от устройства? Приведите примеры процессоров и устройств.

Задания для самостоятельной работы

1. Постройте концептуальную модель диаграммы развертывания.

2. Постройте диаграмму развертывания для учебного задания (задание приведено в конце пособия).

Раздел 7. Шаблоны проектирования

Тема 7.1. Введение в шаблоны проектирования

Тематический контекст

Краткое содержание

1. Обязанности, классификация обязанностей.

2. Понятие и назначение шаблонов проектирования.

3. Стандартный вид описания шаблона проектирования.

Обязанности

Занимаясь объектно-ориентированным проектированием, и в частности построением диаграмм взаимодействия, разработчик на самом деле занимаемся распределением обязанностей между объектами системы. Все обязанности можно разделить на действия и знания. К первой группе обязанностей относятся операции, за выполнение которых отвечает объект. Например, объектам класса «Продажа» может быть вменено в обязанность создавать товарные позиции. К обязанностям из группы действий относятся следующие виды обязанностей:

– выполнение некоторых действий самим объектом;

– инициация действий других объектов;

– управление и координирование действий других объектов.

Ко второй группе обязанностей относятся обязанности, связанные с наличием некоторого рода информации. Например, объектам класса «Продажа» может быть вменено в обязанность знание даты продажи. К обязанностям из группы знаний относятся следующие виды обязанностей:

– наличие информации о закрытых инкапсулированных данных;

– наличие информации о связанных объектах;

– наличие информации о вычислимых величинах.

Заметим, что один объект может выполнять несколько обязанностей. И наоборот, одну обязанность могу реализовывать несколько объектов. Например, за реализацию возможности отправки электронной почты, скорее всего, будет отвечать целая группа объектов.

Диаграммы взаимодействий отражают распределение обязанностей между объектами. Если на диаграмме объект (или класс) получает сообщение, то ему вменяется в обязанность его обработать. Кроме того, отправителю сообщения вменяется в обязанность видеть получателя, т.е. распределение обязанностей определяется взаимодействием (поток сообщений) и сотруд­ни­чест­вом (связи между объектами).

Человеческий опыт распределения обязанностей сконцентрирован в шаблонах проектирования (Design Patterns). Шаблоны не содержат новых идей, они систематизируют и формализуют существующие знания, принципы и удачные решения в области проектирования. Практически все шаблоны преследуют цель повышения гибкости, расширяемости системы.

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

Шаблоны оформляются в виде структурированного описания, которое обычно включает следующие разделы:

– название шаблона;

– описание проблемы или задачи;

– описание решения;

– пример использования;

– рекомендации по использованию;

– описание достоинств и недостатков.

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

Вопросы для самоконтроля

1. Что такое шаблон проектирования и зачем он нужен?

2. Какие виды обязанностей Вы знаете?

3. Как выглядит описание шаблона проектирования?

Дополнительная информация

В следующей теме рассматриваются общие шаблоны распределения обязанностей (GRASP). Для дальнейшего изучения шаблонов проектирования можно порекомендовать обратиться к книге Эриха Гаммы и др. «Примеры объектно-ориентированного проектирования. Паттерны проектирования».

Тема 7.2. Шаблоны проектирования GRASP

Тематический контекст

Краткое содержание

1. Обзор общих шаблонов распределения обязанностей (GRASP).

2. Шаблоны: «Эксперт», «Создатель», «Низкое связывание», «Высокое зацепление» и «Контроллер».

Шаблоны GRAPS

В данном разделе рассматриваются шаблоны GRASP (General Responsibility Assignment Patterns – Общие шаблоны распределения обязанностей). Это наиболее общие и часто (порой, неосознанно) используемые шаблоны проектирования. Некоторые из них напрямую следуют из принципов объектно-ориентированного подхода и могут показаться очень простыми и интуитивно понятными. Однако не стоит их недооценивать. Осознанное применение этих шаблонов поможет избежать многих проблем.

Шаблон Expert (Эксперт)

Проблема. Каков наиболее общий принцип распределения обязанностей между объектами при объектно-ориентированном проектировании?

Рис. 96. Концептуальная модель продажи

Решение. Назначить обязанность информационному эксперту – объекту, который имеет информацию, необходимую для выполнения обязанности.

Например, в системе розничной торговли некоторому объекту необходимо знать общую сумму продажи. На рис. 96 представлена часть соответствующей концептуальной модели.

Рис. 97. Распределение обязанностей в соответствии
с шаблоном Expert

Распределение обязанностей в соответствии с шаблонном Expert показано на рис. 97. Для выполнения обязанности «знать и предоставлять общую сумму продажи» объектам системы были назначены следующие обязанности: объектам класса «Продажа» было вменено в обязанность вычисление общей суммы продажи и владение коллекцией товарных позиций; объек­там класса «ТоварнаяПозиция» было вменено в обязан­ность вычисление суммы товарной позиции, знание количества продаваемого товара и его описания; объектам класса «ОписаниеТовара» было вменено в обязанность знание цены товара.

Заметим, что на рис. 97 классы «Продажа», «ТоварнаяПозиция» и «ОписаниеТовара» появились не столь­ко потому, что соответствующие понятия есть на концеп­ту­альной модели, сколько потому, что эти классы понадобились для реализации обязанности. Модель спецификации и тем бо­лее модель реализации могут существенно отличаться от кон­цептуальной модели.

Шаблон Expert является наиболее часто используемым шаблоном. Этот шаблон поддерживает инкапсуляцию, т.к. используются собственные данные. Кроме того, его применение приводит к определению классов, которые гораздо легче понимать и поддерживать.

Шаблон Creator (Создатель)

Проблема. Кто должен отвечать за создание нового экземпляра некоторого класса?

Решение. Назначить классу А обязанность создавать экземпляры класса Б, если:

– А агрегирует объекты Б;

– А содержит объекты Б;

– А записывает объекты Б;

– А активно использует объекты Б;

– А обладает данными инициализации, которые передаются объектам Б при создании (т.е. А является экспертом).

Если выполняется несколько условий (т.е. есть несколько кандидатов на роль создателя), то предпочтение следует отдать первым двум, т.е. агрегирует и содержит.

Например, кто в системе розничной торговли должен отвечать за создание товарных позиций? Продажа агрегирует товарные позиции и, следовательно, является кандидатом на создателя (рис. 98).

Рис. 98. Создание товарных позиций

При использовании шаблона Creator степень связности не повышается (см. шаблон Low Coupling), т.к. создаваемый объект, как правило, оказывается видимым для создателя посредством уже имеющихся ассоциаций.