Виды диаграмм UML

Диаграммы UML, как и было сказано выше, являются основным способом представления моделей. Последовательность рассмотрения диаграмм в данном подразделе обусловлена рекомендациями Rational Unified Process и наглядно показывает последовательность моделирования системы.

Диаграмма прецедентов (use case diagram)

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

Каждый прецедент характеризует некую предполагаемую последовательность действий. Актер представляет некую внешнюю по отношению к модели сущность. Существует несколько стандартных видов отношений между актерами и прецедентами:

• 1) ассоциация — указание на семантическую связь актера и прецедента (например, актер инициирует прецедент);
• 2) включение — указание на то, что заданное поведение одного прецедента включается как составная часть в поведение другого;
• 3) расширение — указание на то, что заданное поведение прецедента может использоваться другим в случае выполнения неких условий;
• 4) обобщение — указание на то, что прецедент или актер является специальным случаем другого прецедента или актера соответственно.

Рис. 2.1. Диаграмма прецедентов

Диаграмма классов (class diagram)

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

Класс в UML является абстрактным описанием свойств множества объектов, обладающих одинаковой структурой, поведением и отношениями с объектами других классов. Класс обладает набором атрибутов или свойств, а также набором операций или методов. Выделяется понятие шаблонного класса, аналогичное одноименному из языка С++.

Между классами могут быть следующие отношения:

• 1) ассоциация — произвольная семантическая связь классов, может иметь кратность (аналогично ER-диаграммам);
• 2) обобщение — отношение между предком и потомком, интерпретация наследования;
• 3) агрегация — включение одной сущностью других как составных частей, взаимосвязь между частью и целым;
• 4) композиция — более сильный вариант агрегации, при котором часть не может существовать отдельно от целого;
• 5) зависимость — семантическая связь, не являющаяся какой-либо из вышеперечисленных.

Интерфейс в UML — это специальный случай класса, когда специфицируется только его поведение.

Рис. 2.2. Диаграмма классов

Диаграмма кооперации (collaboration diagram)

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

Кооперация — множество взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Различают два уровня представления кооперации: на уровне спецификации (показывает роли спецификаторов и роли ассоциаций во взаимодействии) и на уровне экземпляров (объекты и связи, образующие отдельные роли).

Рис. 2.3. Диаграмма коопераций уровня спецификации

Рис. 2.4. Диаграмма коопераций уровня экземпляров

Диаграмма последовательности (sequence diagram)

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

Рис. 2.5. Диаграмма последовательности

Диаграмма состояний (statechart diagram)

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

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

Рис. 2.6. Диаграмма состояний

Диаграмма деятельности (activity diagram)

Диаграмма деятельности является самым низкоуровневым видом диаграмм UML. Её семантика сродни многократно стандартизованным правилам записи блок-схем алгоритмов.

Рис. 2.7. Диаграмма активностей

Диаграмма компонентов (component diagram)

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

Диаграмма развертывания (deployment diagram)

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

2.1.3 Связь с объектно-ориентированными языками

Некоторые виды диаграмм UML, например диаграммы классов, очень хорошо поддаются обработке генераторами кода. Соответствующие инструментальные средства встроены в большинство мощных CASE-средств, таких как, например, Rational Rose. По данным диаграммы классов такое инструментальное средство способно создать набор файлов со сгенерированными определениями классов, включая их свойства и методы согласно спецификациям диаграммы.

2.4 Идеология STL в применении к архитектуре модуля

Как и многие другие объектно-ориентированные языки, С++ предоставляет широкие возможности по созданию новых типов данных. Библиотека STL призвана предоставить возможность свободно оперировать этими типами.

Библиотека STL (Standard Template Library — стандартная библиотека шаблонов) вводит широкий набор контейнеров для хранения объектов и большое число алгоритмов для манипулирования ими. Благодаря использованию шаблонов, библиотека STL является строго типизированной, что позволяет ей быть крайне гибкой и дает возможность обнаруживать многие ошибки ещё на этапе компиляции.

Библиотека STL является частью стандартной библиотеки языка С++, как это определено в стандарте ISO / IEC 14 882 от 1998 года.

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

Шаблоны в C++

Шаблон (template) — параметризированная часть C+±кода. Шаблонными параметрами, как правило, являются имена типов (малоиспользуемый вариант — константы). Единожды описанный в программе шаблон можно инстанцировать (создавать на его основе новые классы или функции) неограниченное число раз. Фактически, шаблон является способом метапрограммирования — для каждого объявления параметризованного класса или функции с известным набором аргументов шаблона компилятором генерируется новый класс или функция обычного вида. Можно сказать, что такое метапрограммирование является вариантом умных макроподстановок. С одной стороны, это увеличивает объем компилируемого кода (часто в разы), но с другой, дает очень большую гибкость в использовании.

Перед макросами с параметрами препроцессора языка C (которые сохраняют в полном объёме свой функционал и в C++) шаблоны имеют следующие преимущества:

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

В качестве иллюстрации, рассмотрим довольно распространенным пример использования макроса и шаблона для определения возведения в квадрат (листинг 2.1). Легко видеть, что оба подхода позволяют определить функцию возведения в квадрат, однако использование шаблона позволяет избежать нежелательного многократного выполнения операций с побочным эффектом (в примере — двукратного выполнения операции инкремента). Замечу, что для шаблонных функций аргумент шаблона может быть вычислен из типа переданного аргумента, что во многих случаях позволяет избежать явного указания аргументов шаблона.

#define SQR (x) ((x) * (x)).

template T sqr (const T& x) { return (x * x); }.

void test ().

{.

int x = 2;

int y = 2;

x = sqr (y);

y = SQR (x);

x = sqr (++y);

y = SQR (++x);// ошибка! Инкремент x произойдет дважды.

}.

Листинг 2.1. Макрос и шаблон На текущий момент можно с уверенностью сказать, что век макроподстановок заканчивается. Они используются только там, где необходимо обеспечивать межплатформенную совместимость на уровне исходного кода (пример — заголовочные файлы STLport).

Контейнеры STL

Контейнеры STL — это шаблонные классы, которые предназначены для хранения ряда однотипных объектов. К объектам, хранимым в контейнере, предъявляются следующие требования:

• 1) доступный конструктор копирования;
• 2) доступный оператор присваивания;
• 3) доступный деструктор.

Все контейнеры поддерживают базовый функционал:

• 1) набор конструкторов; среди них: конструктор по умолчанию, конструктор копирования, конструктор, заполняющий контейнер элементами из последовательности и ряд других;
• 2) деструктор; при уничтожении контейнера вызываются деструкторы всех содержащихся в нём объектов, а всё память освобождается;
• 3) функции begin (), end (), rbegin (), rend () — возвращают итераторы на начало и конец последовательности объектов, содержащихся в контейнере, в прямом и, соответственно, обратном порядке; как и всюду в STL, итератор на начало указывает на первый элемент последовательности, а итератор на конец — на место в памяти за последним;
• 4) функция size (), возвращающая количество элементов в контейнере.

В разработке VFS контейнеры применялись как основной способ хранения данных. Все предоставляемые интерфейсом модуля последовательности объектов являются контейнерами STL. Ниже перечислены основные использовавшиеся контейнеры.

vector — контейнер, являющийся динамическим массивом. Используется для организации редко редактируемых списков. Контейнер vector эффективно реализует следующие операции:

• 1) добавление и удаление элементов в конце массива;
• 2) доступ к элементу с произвольным номером;
• 3) возможность интерпретировать список элементов как традиционный массив C.

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

Доступ к элементам контейнера реализуется с помощью random-access итераторов и оператора [] (аналогично массивам С).

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

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

set, multiset, map, multimap — ассоциативные контейнеры, предназначенные для хранения упорядоченных последовательностей элементов с возможностью быстрой вставки и удаления.

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

Контейнеры с приставкой multiдопускают повторяющиеся элеметы, без приставки — нет. При этом set требует, чтобы были упорядочены сами хранимые элементы, а map хранит пары ключ-значение (map использует простой вспомогательный шаблон pair для хранения этих пар). Следует учесть, что ассоциативные контейнеры не допускают изменение ключей после добавления элементов. Это правило можно обойти, но это может привести к непредсказуемым последствиям.

string — формально можно рассматривать как частный случай контейнера vector, содержащего символы. Использовать string гораздо удобней, чем пользоваться строками в стиле C. Для string определены такие операции, как конкатенация (сцепление), преобразование к традиционной C-строке, присваивание, сравнение и ряд других.

Кроме того, string является контейнером, а значит к нему применим весь набор стандартных алгоритмов STL.

Итераторы

Итератор (iterator) — специализированный объект, предназначенный для доступа к элементам последовательностей, в частности к элементам контейнеров. По своему поведению итератор напоминает указатель на элемент данных: к нему можно применить оператор разыменования «*» или оператор выбора члена класса через указатель «->».

Рис. 2.8. Иерархия итераторов в STL

Иерархия итераторов STL представлена на рис. 2.8. Это не диаграмма наследования классов. Категория итераторов — это характеристика типа, основанная на том, какие операции он обеспечивает. Существует известная идиома на этот счет: «всё, что ведет себя как итератор, является итератором».

Итератор ввода позволяет только считывать значения и поддерживает операцию инкрементации «++». Итератор вывода позволяет только записывать значения и поддерживает операцию инкрементации «++». Однонаправленный итератор является итератором ввода и вывода одновременно. Итераторы этих трёх типов в основном применяются потоками ввода вывода и стандартными шаблонными алгоритмами. Двунаправленный итератор подобен однонаправленному, но кроме операции инкрементации поддерживает ещё и операцию декремента «—». Все контейнеры поддерживают двунаправленные итераторы. Итератор со случайным доступом поддерживает операции сдвига на целое число элементов и, подобно обычному указателю C++, разыменование с помощью оператора индексации. Кроме того, можно вычесть один итератор с произвольным доступом из другого и узнать, сколько элементов их разделяет.

Среди контейнеров, vector и string поддерживают итераторы со случайным доступом. Обычный указатель C++ в большинстве случаев может играть роль итератора со случайным доступом, но пользоваться этим категорически не рекомендуется.

Алгоритмы STL

Библиотека STL содержит развитые средства по управлению контейнерами. Благодаря использованию идеологии итераторов, эти средства не зависят от типа используемого контейнера. Они используют только тип итератора и основываются на операциях, которые он предоставляет.

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

Ниже приведены некоторые особенно популярные алгоритмы STL, которые я использовал при разработке VFS.

copy — осуществляет копирование из последовательности, заданной итераторами [First; Last) (используются стандартное математические обозначение полуоткрытого интервала), в последовательность, начинающуюся итератором Dest. Возвращает итератор на элемент, следующий за последним скопированным элементом.

fill — заполняет диапазон [First; Last) значением Val. Все контейнеры имеют специальный конструктор с аналогичным функционалом.

find — ищет в диапазоне [First; Last) значение Val. Возвращает итератор на первое встретившееся значение. Если значение не найдено, возвращает итератор Last. У этого алгоритма есть мощные расширения, использующие поиск в подпоследовательностях.

for_each — для каждого элемента из диапазона [First; Last), вызывает функтор, передавая ему в качестве параметра текущий элемент (полученным разыменовыванием итератора).

replace — заменяет в диапазоне [First; Last) все элементы, для которых унарный предикат истинен, значением Val.

sort — осуществляет сортировку элементов в диапазоне [First; Last). Передаваемый бинарный предикат имеет смысл оператора сравнения «<�». В случае, если сортируемые объекты поддерживают сравнение с использованием оператора «<�», можно воспользоваться упрощённой формой.

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

Функтор (functor, также называются объектами-функциями) — объект любого класса, для которого определён оператор вызова функции «()». Следуя определению, любая функция является функтором.

Перегрузка оператора «()» в классе позволяет одновременно решить две задачи:

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

Предикат (predicate) — это функтор, возвращающий логическое (bool) значение. Различают унарные (принимающие один параметр) и бинарные (принимающие два однотипных параметра) предикаты.

Предикаты активно используются в STL. Практически все стандартные алгоритмы и контейнеры, сравнивающие элементы, позволяют задать произвольный предикат в качестве оператора сравнения (по умолчанию для элементов используются операторы «==» и «<�», в зависимости от алгоритма).

Потоки

В языке C++ отсутствуют встроенные средства ввода/вывода. Они предоставляются программисту различными библиотеками, в том числе STL. В STL реализован гибкий объектно-ориентированный подход, названный «потоки» (streams).

Центральным понятием библиотеки iostream является поток (stream). Поток можно представить себе как источник и/или приёмник последовательности байт. Переопределяя операции записи и чтения потока («сдвиг»), можно заставить поток быть источником и/или приёмником объектов некого класса.

Примечательно, что несмотря на большую гибкость, базовый интерфейс всех потоков предельно прост: он включает в себя возможность последовательно читать байты данных (для потоков ввода istream) и последовательно записывать их (для потоков вывода ostream). При этом для потоков допускается буферизованный вывод (т.е. ситуация, когда оправленные на вывод данные временно хранятся в некотором буфере). Для незамедлительной отправки данных все потоки вывода поддерживают метод flush. Подобная универсальность выгодно отличает библиотеку iostream от альтернативных решений.

Использование потоков ввода/вывода распадается на две стадии: формирование и закрытие потока и собственно ввод/вывод.

Ввод/вывод в потоки осуществляется с помощью перегруженных операторов сдвига «<>» (ввод). Как указывалось выше, программист имеет возможность перегрузить эти операторы для своих классов обеспечив простой и удобный способ взаимодействия их с внешним миром. При этом необходимо иметь о потоке самые общие сведения:

• 1) тип потока (ввода, вывода, ввода/вывода);
• 2) тип символов потока;
• 3) наличие или отсутствие буферизации;

Замечу, что упомянутые операторы осуществляют форматированный ввод/вывод. Используя такие низкоуровневые средства, как методы put, write, get, read и им подобные, можно посимвольно манипулировать потоками, но эти возможности, как правило, используются при написании высокоптимизированного кода.

В модуле VFS потоки были использованы как одна из основных составных частей: согласно ТЗ, модуль обязан предоставлять данные любого файла как поток. Используя стандартные интерфейсы потоков STL и их буферов, были реализованы потоки, осуществляющие архивирование/распаковку и шифрацию/дешифрацию «на лету».

Умные указатели

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

Библиотека STL, предоставляя мощные средства управления памятью, тем не менее не избавляет программиста от возможных ошибок. Частая ошибка — возврат адреса локальной переменной — контролируется только компилятором. Широкое использование механизма исключений и вообще, любой развитый механизм обработки ошибок, требует, чтобы все динамические объекты удалялись вовремя.

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

Рассмотрим использованные при разработке проекта умные указатели. Это шаблон auto_prt из стандартной библиотеки языка C++ и шаблоны weak_prt и shared_prt из библиотеки boost.

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

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

Шаблоны weak_ptr и shared_ptr библиотеки boost являются довольно мощными реализациями указателей с подсчетом ссылок. Поскольку их применение в VFS было эпизодическим, а в конечной версии исключено за ненадобностью, подробно рассматриваться здесь они не будут.

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

• 1)множественные ссылки (один умный указатель уже удалил объект, а какой-то другой указатель продолжает ссылаться на него); чаще всего проблема возникает при одновременном использовании простых и умных указателей;
• 2)циклические связи; возникают только при использовании умных указателей с счётчиками ссылок; приводят к невозможности корректного уничтожения контролируемых объектов и, как следствие, к утечкам памяти.