Пример. Описание предметной области.

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

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

Пользователь может приостановить процесс приготовления пищи открыванием дверцы. В этом случае время сбрасывается.

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

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

1. Промежутки времени между двумя последовательными воздействиями пользователя на печь распределены нормально с математическим ожиданием 60 секунд и дисперсией 30 секунд.

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

3. Необходимо провести моделирование работы системы в течение 10 минут и собрать следующую статистику:

‒ общее время работы силового элемента печи;

‒ количество приготовленных блюд;

‒ количество прерываний приготовления блюд.

4. На каждом шаге моделирования необходимо выводить состояние системы и происходящие события. Собранную статистику необходимо вывести на экран и в файл.

5.1 Объектно-ориентированный анализ

Объектно-ориентированный анализ системы можно провести двумя традиционными методами: методом Аббота и CRC-карточек, а также методом построения диаграмм вариантов использования.

Use-Case Diagrams. Диаграммы вариантов использования являются действенным методом анализа, относящимся к методологии UML. Варианты использования – это описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия [3].

Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы. Актер обозначается значком человечка, а Use Case – овалом. Дополнительно в диаграммы могут быть добавлены комментарии.

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

1. Простая ассоциация – отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования.

2. Направленная ассоциация – то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.

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

4. Расширение (extend) – показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений "включение" расширенная последовательность может осуществляться в зависимости от определенных условий.

5. Включение – показывает, что вариант использования включается в базовую последовательность и выполняется всегда.

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

На рис. 5.1 показана диаграмма вариантов использования для вышеописанной ПрО. Системой на данной диаграмме изображена микроволновая печь, а актером – человек, ее пользователь. Пользователь использует четыре варианта использования (направленная ассоциация): «Включить печь», «Выключить печь», «Приготовление пищи», «Вымыть печь». Варианты «Открыть дверь» и «Закрыть дверь» включаются в варианты «Вымыть печь» и «Приготовление пищи», кроме того в последний включаются также «Поставить блюдо», «Нажать кнопку» и «Забрать блюдо». Варианты использования, инициированные самой печью, расширяют варианты использования доступные актеру.

Рисунок 5.1 – Диаграмма вариантов использования для предметной области «Моделирование работы микроволновой печи»

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

Метод Аббота.Метод Аббота заключается в словесном анализе предметной области и получении ее словаря и объектно-ориентированного словаря. Согласно этому методу надо описать задачу на обычном языке, а потом подчеркнуть существительные и глаголы [1]. Существительные – кандидаты на роль классов, а глаголы могут стать именами методов.

Подход Аббота полезен, так как он прост и заставляет разработчика заниматься словарем предметной области. Однако он весьма приблизителен и непригоден для сколько-нибудь сложных проблем. Человеческий язык - ужасно неточное средство выражения, потому список объектов и операций зависит от умения разработчика записывать свои мысли.

Пример. ОО анализ предметной области методом Аббота.

Таблица 5.0.1 – Словарь предметной области

При переходе от словаря ПрО (табл. 5.1) к ОО словарю (табл. 5.2) некоторые классы, свойства и методы можно ввести в независимости от наличия соответствующих существительных и глаголов. Так в нижеприведенной таблице выделен базовый класс электроприбора ElectricalAppliance, бытового прибора HouseholdAppliance и класс генератора случайных чисел Random.

Таблица 5.0.2 – ОО словарь предметной области

Продолжение таблицы 5.0.3

Обратите внимание на приведенное в скобках англоязычное название классов, свойств и методов. Так как данное пособие предусматривает программирование на языке C++, который не допускает применение других национальных алфавитов, то рекомендуется уже на этапе анализа переходить к англоязычной терминологии. Следует отметить и применяемую нотацию именования. Имена классов состоят из английских терминов, начинающихся с прописной буквы и написанных слитно без пробелов, например, PowerElement, а не Power_Element и не Power_element, и не powerElement. Имена методов формируются аналогично. Имена свойств начинаются не с прописной, а с обычной буквы, так как свойства – это переменные некоего типа, например, timeToAction, а не TimeToAction. Более подробно о правилах и нотациях именования можно прочесть в соответствующей литературе [12].

Класс генератора случайных чисел Random был введен из-за желания выделить код (ответственность) из класса Man для получения времени до следующего действия timeToAction в методе Imitate. Хотя из описания ПрО и следует, что генерация случайных чисел требуется только в одном участке программы, но разработчик всегда должен думать о ее дальнейшем развитии. Так если бы потребовалось ввести класс блюд и для некоторых из них требовалось неопределенное время приготовления, то код генерации случайных чисел дублировался бы в программе, что значительно усложнило бы ее отладку, развитие и поддержку.

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

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

CRC-карточки. CRC обозначает Class-Responsibilities-Collaborators (Класс/Ответственности/Участники). Это эффективный способ анализа сценариев. Карты CRC впервые предложили Бек и Каннингхэм для обучения объектно-ориентированному программированию [2].

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

Т.е. это вполне нормальная ситуация, когда разработчику необходимо переделывать ОО словарь и CRC-карты несколько раз, что говорит о важности этапа анализа.

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

В таблицах 5.3-5.13 приведены примеры окончательных CRC-карт, полученных после нескольких проходов по сценарию работы ПрО.

Пример. ОО анализ предметной области методом CRC-карточек.

Таблица 5.0.4 – CRC-карточка класса Man

Таблица 5.0.5 – CRC-карточка класса Random

Таблица 5.0.6 – CRC-карточка класса ElectricalAppliance

 Таблица 5.0.7 – CRC-карточка класса Button

Таблица 5.0.8 – CRC-карточка класса Speaker

Таблица 5.0.9 – CRC-карточка класса PowerElement

Таблица 5.0.10 – CRC-карточка класса Lamp

Таблица 5.0.11 – CRC-карточка класса Timer

Таблица 5.0.12 – CRC-карточка класса HouseholdAppliance

Таблица 5.0.13 – CRC-карточка класса Door

Таблица 5.0.14 – CRC-карточка класса MicrowaveOven

Если бы мы только начинали проектирование, то в ОО словаре, вероятно, не было бы класса электроприбора ElectricalAppliance, но классы Button, Speaker, PowerElement, Lamp имели бы общие свойства и методы. А при проходе по сценарию из описания ПрО, мы бы выделили часть ответственности в этот базовый класс.

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

1. Какие классы и объекты предлагается ввести, чему они соответствуют в моделируемой предметной области?

2. Что является "состоянием" для объектов этих классов, набором каких параметров оно задается?

3. Какие сообщения должны принимать и обрабатывать объекты?

4. Какие информационные зависимости существуют между классами, какими общими функциями они пользуются?

5.2 Объектно-ориентированное проектирование

Результатами объектно-ориентированного проектирования являются диаграммы, выполненные в нотациях Booch или UML. В нотации Booch к фазе проектирования относятся – диаграммы классов, объектов, состояний и переходов, взаимодействия [2]; а в нотации UML – диаграммы классов, объектов, последовательностей, кооперации, состояний, деятельности [3].

5.2.1 Диаграммы классов

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

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

Рисунок 5.2 – Значок класса

На обозначениях классов полезно перечислять несколько свойств (атрибутов/полей) и методов (операций/функций-членов) класса. Атрибут обозначает часть составного объекта, или агрегата. Атрибуты используются для выражения отдельных свойств класса. В нотации Booch используется синтаксис, в котором свойство может обозначаться именем или типом данных, или и тем и другим, и, возможно, иметь значение по умолчанию:

‒ A - только имя;

‒ :C - только тип данных (класс);

‒ A:C - имя и  тип данных (класс);

‒ A:C=E - имя,  тип данных (класс) и значение по умолчанию.

Имя свойства должно быть недвусмысленно в контексте класса. Метод – это услуга, предоставляемая классом. Методы обычно изображаются внутри значка класса только своим именем. Чтобы отличать их от свойств, к их именам добавляются скобки. Иногда полезно указать полную сигнатуру метода:

‒ N() - только имя метода;

‒ RN(Аргументы) – тип возвращаемого значения (R), имя и формальные параметры (если есть).

Имена методов должны пониматься в контексте класса однозначно в соответствии с правилами перегрузки методов.

Пример. Обозначение класса на диаграмме классов.

На рис. 5.3 показан пример обозначения класса электроприбора ElectricalAppliance. Имена его свойств и методов взяты из ОО словаря ПрО (табл. 5.2). Свойство state имеет логический тип данных bool (включен прибор или нет) и по умолчанию установлено в значение false (выключен). Вертикальная черта слева от свойства означает, что оно имеет модификатор доступа protected, т.е. свойство защищено от доступа извне. Для доступа к свойству принято применять пару методов: для чтения – геттер GetState() и для записи – сеттер SetState().

Рисунок 5.3 – Пример обозначения класса

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

В случае класса ElectricalApplianceсеттер отсутствует, что говорит о том, что внешние сущности могут лишь наблюдать за состоянием электроприбора, но никак не могут изменить его состояние по своей воле. Вместо этого класс предоставляет свой интерфейс в виде двух методов: включение On()и выключение Off(), т.о. любая внешняя сущность может управлять состоянием электроприбора путем его включения и выключения. Причем, перед тем, как произвести воздействие на электроприбор, можно оценить его текущее состояние, иначе было бы нелогично пытаться включить уже включенный прибор или выключить выключенный.

Метод Imitate() предназначен для имитирования поведения любого класса объектов в данный момент времени. Его наличие обусловлено в большей степени использованием проектируемых классов в имитационном моделировании динамических систем и процессов. Если бы у нас во всей глобальной иерархии наследования был один суперкласс, например Object, то с очень большой вероятностью у него был бы виртуальный метод Imitate().

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

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

Пример. Составление чернового протокола класса.

Используя ОО словарь ПрО (табл. 5.2), CRC-карточку класса (табл. 5.10) и графическое обозначение класса (рис. 5.3) на диаграмме классов составим приблизительный протокол класса электроприбора ElectricalAppliance.

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

Полученный протокол класса представлен ниже.

class ElectricalAppliance   // класс электроприбор

{

protected:             // защищенные члены класса

  bool state;           // состояние

public:                      // открытые члены класса

  ElectricalAppliance(); // конструктор по умолчанию

  ~ElectricalAppliance(); // деструктор

  bool GetState();      // геттер для состояния

  void On();            // включить

  void Off();           // выключить

  void Imitate();       // имитировать работу в течении еденицы времени

};

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

Как было отмечено выше, классы состоят в отношениях между собой. Виды отношений между классами показаны на рис. 5.4: ассоциация, наследование, агрегация (has) и использование [2]. При изображении конкретной связи ей можно сопоставить текстовую метку, документирующую имя этой связи или подсказывающую ее роль. Имя связи не обязано быть глобальным, но должно быть уникально в своем контексте.

Значок ассоциации соединяет два класса и означает наличие семантической связи между ними. Ассоциации часто отмечаются существительными, например Employment (место работы), описывающими природу связи. Класс может иметь ассоциацию с самим собой (так называемая рефлексивная ассоциация). Одна пара классов может иметь более одной ассоциативной связи. Возле значка ассоциации можно указать ее мощность, используя синтаксис следующих примеров:

‒ 1 - в точности одна связь;

‒ N - неограниченное число (0 или больше);

‒ 0..N - ноль или больше;

‒ 1..N - одна или больше;

‒ 0..1 - ноль или одна;

‒ 3..7 - указанный интервал;

‒ 1..3, 7 - указанный интервал или точное число.

Рисунок 5.4 – Значки отношений между классами

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

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

Значок наследования, представляющего отношение "общее/частное", выглядит как значок ассоциации со стрелкой, которая указывает от подкласса к суперклассу. Подкласс наследует структуру и поведение своего суперкласса. Класс может иметь один (одиночное наследование), или несколько (множественное наследование) суперклассов. Как правило, циклы в наследовании запрещаются. К наследованию значок мощности не приписывается.

Пример. Обозначение на диаграмме и реализация на языке C++ отношения наследования.

На рис. 5.5 показан фрагмент иерархии наследования в ПрО «Микроволновая печь». Обратите внимание на изменившееся обозначения класса ElectricalAppliance. Треугольник с буквой «А» обозначает, что класс является абстрактным, т.е. невозможно создание его экземпляров. Кроме того метод Imitate() объявлен как virtual Imitate() = 0, т.е. является чисто виртуальной функцией, а значит, все дочерние классы от ElectricalAppliance обязаны реализовывать (перегружать) данный метод. Эта возможность обеспечивается принципом полиморфизма.

Рисунок 5.5 – Обозначение отношения наследования

На рисунке классы Button и MicrowaveOven наследуют класс ElectricalAppliance, что в принципе логично – и кнопка и микроволновая печь являются электроприборами. Значит, они наследуют состояние и поведение своего базового класса, т.е. их тоже можно включать, выключать, проверять их состояние. В этом и состоит принцип наследования.

Так как обозначение класса ElectricalAppliance на рис. 5.5 модифицировано по сравнению с рис. 5.3, то и протокол класса будет изменен.

class ElectricalAppliance abstract // класс электроприбор - абстрактный класс

{

protected:                         // защищенные члены класса

  bool state;                  // состояние

public:                            // открытые члены класса

  ElectricalAppliance();       // конструктор по умолчанию

  ~ElectricalAppliance();      // деструктор

  bool GetState();             // геттер для состояния

  void On();                   // включить

  void Off();                  // выключить

  virtual void Imitate() = 0;  // имитировать работу в течении еденицы времени

                                   // чисто виртуальная функция

};

Протокол класса Button будет выглядеть следующим образом. Через двоеточие после имени класса указывается суперкласс с модификатором наследования, который определяет область видимости членов суперкласса из дочернего класса и через объект дочернего класса. Также в обязательном порядке переопределен метод Imitate().

class Button :                     // класс кнопка

  public ElectricalAppliance // наследует электроприбор

{

public:

  Button();

  ~Button();

  void Push();                 // нажать

  void Imitate();              // перегруженный метод имитации работы

};

Значок агрегации обозначает отношение "целое/часть" (связь "has") и получается из значка ассоциации добавлением закрашенного кружка на конце, обозначающем агрегат. Экземпляры класса на другом конце стрелки будут в каком-то смысле частями экземпляров класса-агрегата. Разрешается рефлексивная и циклическая агрегация. Агрегация не требует обязательного физического включения части в целое.

Пример. Обозначение на диаграмме и реализация на языке C++ отношения агрегации.

На рис. 5.6 показан пример обозначения отношения агрегации между двумя классами MicrowaveOven и Button. При этом MicrowaveOven является агрегатом по отношению к Button, и у MicrowaveOven может быть единственный экземпляр Button, а отдельный Button может принадлежать единственному MicrowaveOven.

Рисунок 5.6 – Обозначение отношения агрегации

Протокол класса MicrowaveOven будет выглядеть следующим образом. В качестве одного из открытых свойств объявлен экземпляр типа Button.

class MicrowaveOven :              // класс микроволновая печь

  public ElectricalAppliance // наследует электроприбор

{

public:                            // открытые члены класса

  Button button;               // кнопка

  MicrowaveOven();

  ~MicrowaveOven();

  void Imitate();              // имитировать работу в течении еденицы времени

};

На рис. 5.6 на конце агрегации, обозначающем часть агрегата, добавлен квадрат. Квадрат отвечает за физическое включение частей в агрегат: закрашенный – агрегация по значению, незакрашенный – агрегация по ссылке. В примере используется агрегация по значению, и поэтому в протоколе класса MicrowaveOven жестко определен объект Button. Если бы использовалась агрегация по ссылке, то был бы определен указатель на Button. Применение агрегации по значению целесообразно, когда часть постоянно принадлежит агрегату, а по ссылке – когда в процессе выполнения программы необходимо осуществлять замену частей агрегата.

class MicrowaveOven :              // класс микроволновая печь

  public ElectricalAppliance // наследует электроприбор

{

public:                            // открытые члены класса

  Button* button;              // указатель на кнопку

  MicrowaveOven();

  ~MicrowaveOven();

  void Imitate();              // имитировать работу в течении еденицы времени

};

Знак использования обозначает отношение "клиент/сервер" и изображается как ассоциация с пустым кружком на конце, соответствующем клиенту. Эта связь означает, что клиент нуждается в услугах сервера, то есть методы класса-клиента вызывают методы класса-сервера или имеют сигнатуру, в которой возвращаемое значение или аргументы принадлежат классу сервера.

Пример. Обозначение на диаграмме и реализация на языке C++ отношения использования.

На рис. 5.7 показан пример обозначения отношения использования между классами Man и MicrowaveOven, Button. Класс человека Man использует класс печи MicrowaveOven для приготовления блюд, что отражено в сигнатуре метода Imitate(MicrovavrOven&). А где-то в реализации этого метода человек взаимодействует с открытым свойством печи – кнопкой Button, вызывая у нее метод нажать Push().

Рисунок 5.7 – Обозначение отношения использования

Протокол класса будет выглядеть следующим образом.

class Man                    // класс человек

{

protected:                   // защищенные члены класса

  int timeToAction;     // время до взаимодействия с печью

public:                      // открытые члены класса

  Man();                // конструктор

  ~Man();               // детсруктор

  void Imitate(  // имитировать деятельность в течении еденицы времени

        MicrowaveOven&); // используется печь

};

Пример. Диаграмма классов.

На рис. 5.8 приведена диаграмма классов.

На диаграмме показаны все классы, полученные на этапе ОО анализа и представленные в ОО словаре ПрО. Человек Man взаимодействует с печью MicrowaveOven через ее открытые свойства – дверь door(может открывать open()и закрывать close()) и кнопку button(может нажимать push()). Для генерации случайных чисел человек Man использует статический класс Random, обозначенный облаком с тенью. Random предоставляет интерфейс для генерации случайных чисел распределенных по равномерному закону Uniform() с указанием левой min и правой max границы отрезка и нормальному закону Normal() с указанием математического ожидания M и дисперсии D.

Рисунок 5.8 – Диаграмма классов

ПечьMicrowaveOven наследует два базовых абстрактных класса: электроприбор ElectricalAppliance и бытовой прибор HouseholdAppliance. Печь состоит из двери door, кнопки button, спикера speaker, силового элемента powerElement, лампы lamp и таймера timer. На обозначении отношений агрегации защищенных частей печи MicrowaveOven дополнительно нанесена черта, обозначающая защищенность данной части агрегата.

5.2.2 Диаграммы объектов

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

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

Рисунок 5.9 – Значок объекта

Имя объекта следует синтаксису для атрибутов, и может быть записано в одной из трех следующих форм:

‒ A - только имя объекта;

‒ :C - только класс объектов;

‒ A:C - имя объекта и класса.

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

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

Рисунок 5.10 – Значок связи между объектами

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

Пусть имеются объекты A и B и связь L между ними. Тогда A может вызвать любую операцию, имеющуюся в классе B и доступную A. То же верно для операций над A, вызываемых B. Объект, вызывающий операцию, называется объект-клиент, а объект, который предоставляет операцию, - объект-сервер. Обычно отправитель сообщения знает получателя, но обратное необязательно.

В установившемся состоянии структуры классов и объектов системы должны быть согласованы. Если мы показываем на диаграмме операцию M на классе B, вызванную по связи L, то М должна быть объявлена в спецификации B, или в спецификациях его суперклассов.

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

‒ символ синхронизации, обозначающий направление вызова;

‒ вызов операции или извещение о событии;

‒ необязательный порядковый номер.

Направление сообщения обозначается стрелкой, указывающей на объект-сервер. Этот символ означает простейшую форму передачи сообщений, семантика которой гарантирована только в присутствии единственного потока контроля.

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

‒ N() - только имя операции;

‒ RN(arguments) - возвращаемое значение, имя и фактические параметры операции.

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

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

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

Пример. Диаграмма объектов.

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

1. Человек использует метод Random::Normal для генерации продолжительности времени до следующего воздействия на печь.

2. Человек использует метод Random::Uniform для определения того, на что он будет воздействовать: на кнопку или дверь.

3. Человек проверяет состояние двери.

4. В зависимости от состояния открывает ее.

5. Либо закрывает.

6. Нажимает кнопку.

7. Печь проверяет состояние двери.

8. И состояние кнопки.

9. Устанавливает время работы таймера.

10. И включает его.

11. Соответственно включает силовой элемент.

12. И лампу.

13. Если время, которое отсчитывает таймер, истекло.

14. Выключается силовой элемент.

15. И лампа.

16. Печь при помощи спикера издает звуковой сигнал.

17. Который слышит человек.

На диаграмме используются дополнительные обозначения. На шаге 13 при проверке печью, истекло ли время таймера, возвращается его текущее значение timer.time. На некоторых объектах указана их область видимости. Для указания видимости могут быть использованы следующие обозначения:

‒ G - сервер глобален для клиента;

‒ P - сервер является параметром некоторой операции клиента;

‒ F - сервер является частью клиента;

‒ L - сервер локально определен в области видимости клиента.

Рисунок 5.11 – Диаграмма объектов

5.2.3 Диаграммы состояний и переходов

Диаграмма состояний и переходов показывает: пространство состояний данного класса; события, которые влекут переход из одного состояния в другое; действия, которые происходят при изменении состояния [2]. Отдельная диаграмма состояний и переходов представляет определенный ракурс динамической модели отдельного класса или целой системы. Диаграммы состояний и переходов строятся только для классов, поведение которых (управляемое событиями) существенно. Можно также представить диаграмму состояний и переходов для управляемого событиями поведения системы в целом. Эти диаграммы используются в ходе анализа, чтобы показать динамику поведения системы, а в ходе проектирования - для выражения поведения отдельных классов или их взаимодействия.

Два основных элемента диаграммы состояний и переходов - это, естественно, состояния и переходы между ними.

Состояние представляет собой итоговый результат поведения системы. В любой момент времени состояние объекта определяет набор свойств (обычно статический) объекта и текущие (обычно динамические) значения этих свойств. На рис. 5.12 показано обозначение для отдельного состояния.

Рисунок 5.12 – Значок состояния

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

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

Событием называется любое происшествие, которое может быть причиной изменения состояния системы. Изменение состояний называется переходом. На диаграмме переходов и состояний он изображается значком, показанным на рис. 5.13. Каждый переход соединяет два состояния. Состояние может иметь переход само в себя; обычно есть несколько различных переходов в одно и то же состояние, но все переходы должны быть уникальны в том смысле, что ни при каких обстоятельствах не может произойти одновременно два перехода из одного состояния.

Рисунок 5.13 – Значок перехода из состояния в состояние

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

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

Существует несколько стратегий реализации управления событиями.

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

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

3. Можно определить событие просто как операцию, такую как MicrowaveOven::Imitate(). Это похоже на подход, который трактует события как имена, но в отличие от него здесь не требуется явного диспетчера событий.

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

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

‒ door.Open() – действие;

‒ Сброс времени - произошло событие;

‒ start ОтсчетВремени - начать некоторую деятельность;

‒ stop ОтсчетВремени - прекратить деятельность.

Имена операций или событий должны быть уникальны в области видимости диаграммы; там, где необходимо, они могут быть квалифицированы соответствующими именами классов или объектов.

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

Пример. Диаграммы состояний и переходов.

На рисунках 5.14-5.20 показаны диаграммы состояний и переходов для классов ПрО «Микроволновая печь» Man, Door, ElectricalAppliance, Button, Speaker, Timer, MicrowaveOven. Для класса Random диаграмма не приводится, так как класс статический.

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

Рисунок 5.14 – Диаграмма состояний и переходов для класса Man

Дверь – простейший класс, имеющий состояния: открыта и закрыта; и переходящий из одного в другое при вызове соответствующих методов.

Рисунок 5.15 – Диаграмма состояний и переходов для класса Door

Аналогично ведет себя и класс электроприбора.

Рисунок 5.16 – Диаграммы состояний и переходов для класса ElectricalAppliance

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

Рисунок 5.17 – Диаграмма состояний и переходов для класса Button

Класс Speaker также наследует ElectricalAppliance. Ведет себя аналогично Button, но время нахождения в состоянии включен иное.

Рисунок 5.18 – Диаграмма состояний и переходов для класса Speaker

Класс Timer очень похож на Button и Speaker, но позволяет извне установить и изменить время работы. На рисунке показаны два вложенных состояния: ожидание и отсчет времени завершен. Также в состоянии включен осуществляется деятельность, которая ведет отсчет времени.

Рисунок 5.19 – Диаграмма состояний и переходов для класса Timer

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

Рисунок 5.20 – Диаграмма состояний и переходов для класса MicrowaveOven

5.2.4 Диаграммы взаимодействия

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

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

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

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

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

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

На рисунке 5.21 приведен пример диаграммы взаимодействия. Объекты рекомендуется располагать таким образом, чтобы горизонтальные стрелки сообщений не пересекали полосы периодов управления.

Рисунок 5.21 – Диаграмма взаимодействия

5.3 Объектно-ориентированное программирование

Результатами объектно-ориентированного программирования являются диаграммы модулей и процессов в нотации Booch [2] и диаграммы пакетов, компонентов и развертывания в нотации UML [3], а также протоколы классов.

5.3.1 Диаграммы модулей

Диаграмма модулей показывает распределение классов и объектов по модулям в физическом проектировании системы. Каждая отдельная диаграмма модулей представляет некоторый ракурс структуры модулей системы. При разработке диаграмма модулей используется, чтобы показать физическое деление архитектуры по слоям и разделам [2].

Основными элементами диаграммы модулей являются модули и их зависимости. На рис. 5.22 приведены обозначения различных типов модулей. Первые три значка – это файлы, различающиеся своими функциями. Значок главной программы обозначает файл, содержащий корневую программу. В C++ это соответствовало бы некоторому файлу с расширением .cpp содержащему привилегированную функцию-неэлемент, называемую main. Обычно существует ровно один такой модуль на программу. Значок описания и значок тела обозначают файлы, которые содержат, соответственно, описания и реализации. В C++, например, модуль описаний соответствует заголовочному файлу с расширением .h, а модуль тела – файлу с текстом программы с расширением .cpp.

Рисунок 5.22 – Значки модулей и подсистем

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

Единственная связь, которая может существовать между двумя модулями, – компиляционная зависимость – представляется стрелкой, выходящей из зависимого модуля. В C++ такая зависимость указывается директивой #include. В множестве компиляционных зависимостей не могут встречаться циклы. Для того чтобы избежать цикличности при компиляции взаимозависящих модулей, используется директива #pragma once, либо конструкция:

#ifndef <Literal>

#define <Literal>

#include <ModuleName>

<ModuleFirstString>

…

<ModuleLastString>

#endif

Чтобы определить частичную упорядоченность компиляций, достаточно выполнить частичное упорядочение структуры модулей системы.

Большие системы могут быть разложены на несколько сотен, если не тысяч, модулей. Пытаться разобраться в физической архитектуре такой системы без ее дополнительного структурирования почти безнадежно. На практике разработчики стремятся следовать неформальному соглашению собирать связанные между собой модули в структуры типа каталогов. По этим соображениям вводится понятие подсистемы на диаграмме модулей. Подсистемы представляют собой совокупности логически связанных модулей. В языке C++ объединение нескольких модулей в подсистему осуществляется их логическим заключением в единое пространство имен (namespace).

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

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

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

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

Пример. Диаграмма модулей.

На рисунке 5.23 приведен пример построения диаграммы модулей ПрО «Микроволновая печь». Имеется главный модуль Imitation.cpp, содержащий функцию main. На каждый класс ПрО заведено по два модуля: один (*.h) для протокола класса, второй (*.cpp) для его реализации.

Рисунок 5.23 – Диаграмма модулей

5.3.2 Диаграммы процессов

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

Основные элементы диаграммы процессов – процессоры, устройства и их соединения.

На рис. 5.24 показано обозначение процессора. Процессор – часть аппаратуры, способная выполнять программы. Каждый процессор должен иметь имя; никаких особых ограничений на имена процессоров нет, так как они обозначают "железо", а не программы.

Значок процессора можно дополнить списком процессов. Каждый процесс в таком списке обозначает или главную программу (функцию main из диаграммы модулей) или имя активного объекта (из диаграммы объектов).

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

Рисунок 5.24 – Значки процессора и устройства

Процессоры и устройства должны сообщаться друг с другом. На диаграмме процессов соединения изображаются ненаправленными линиями. Соединение обычно представляет непосредственную связь между аппаратурой, например, RS232, Ethernet, или даже доступ к разделяемой памяти, но эта связь может быть и не прямой, например, "Земля-спутник". Соединения обычно считаются двунаправленными, но при необходимости к их обозначению можно добавить стрелку, чтобы указать направление. Любое соединение может иметь необязательную именующую его метку.

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

Таблица 5.14 – Типы и описания реализации многозадачности

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

Пример. Диаграммы процессов.

На рисунках 5.25 и 5.26 приведены диаграммы процессов для ПрО «Микроволновая печь».

Рисунок 5.25 – Диаграмма модулей для однопроцессорной архитектуры