Билет 1. Время жизни объектов. Связь с типами памяти и областями видимости

Стр 1 из 5Следующая ⇒

Билет 1. Время жизни объектов. Связь с типами памяти и областями видимости

Время жизни объектов

Время жизни объекта — интервал времени выполнения программы, в течение которого объект существует в памяти

Время жизни объекта:

- Глобальное - время работы программы (при этом не обязательно всегда видима)

- Локальное - время выполнения блока (при новом входе в блок обновляется)

Время жизни функций – глобальное

Область видимости

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

Области видимости переменной:

- Локальная — в блоке (и вложенных блоках)

- Файловая — в файле с места объявления

- Глобальная — межфайловая при объявлениях extern

Видимость функций:

- Файловая, с момента описания или объявления прототипа

- Функция может быть описана в другом файле ( должна быть объявлена как extern)

Типы памяти

Статическая память

- Для переменных, объявленных вне функций или с модификатором static

- Время жизни == время выполнения программы

Автоматическая память (стэк)

- Для переменных внутри функций и блоков (без static)

- Время жизни - блок

Динамическая память (куча)

- Выделяется по запросу

- Время жизни – от момента выделения с помощью new до момента освобождения с помощью delete

Билет 2. Области видимости. Связь с временем жизни и типами памяти.

Область видимости

Области видимости переменной:

- Локальная — в блоке (и вложенных блоках)

- Файловая — в файле с места объявления

- Глобальная — межфайловая при объявлениях extern

Видимость функций:

- Файловая, с момента описания или объявления прототипа

- Функция может быть описана в другом файле ( должна быть объявлена как extern)

Время жизни объектов

Время жизни объекта — интервал времени выполнения программы, в течение которого объект существует в памяти

Время жизни объекта:

- Глобальное - время работы программы (при этом не обязательно всегда видима)

- Локальное - время выполнения блока (при новом входе в блок обновляется)

Время жизни функций – глобальное

Типы памяти

Статическая память

- Для переменных, объявленных вне функций или с модификатором static

- Время жизни == время выполнения программы

Автоматическая память (стэк)

- Для переменных внутри функций и блоков (без static)

- Время жизни - блок

Динамическая память (куча)

- Выделяется по запросу

- Время жизни – от момента выделения с помощью new до момента освобождения с помощью delete

Билет №3. Принципы ООП: абстрагирование, инкапсуляция, иерархичность, модульность

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

Абстра́ кция в объектно-ориентированном программировании — это существенные характеристики объекта, которые отличают его от всех других объектов, четко определяя его концептуальные границы. Основная идея состоит в том, чтобы отделить способ использования составных объектов данных от деталей их реализации в виде более простых объектов, подобно тому, как функциональная абстракция разделяет способ использования функции и деталей её реализации в терминах более примитивных функций (Данные обрабатываются функцией высокого уровня с помощью вызова функций низкого уровня).

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

Инкапсуляция – объединение данных (атрибутов) и поведения (операций) в рамках класса

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

Инкапсуляция — один из четырёх важнейших механизмов объектно-ориентированного программирования (наряду с абстракцией, полиморфизмом и наследованием).

Предостережение: Одна из наиболее распространенных ошибок — делать сокрытие реализации только ради сокрытия. Целями, достойными усилий, являются: предельная локализация изменений при необходимости таких изменений, прогнозируемость изменений (какие изменения в коде надо сделать для заданного изменения функциональности) и прогнозируемость последствий изменений.

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

Часто инкапсуляция может быть достигнута простейшими организационными мерами: знание того, что «вот так-то делать нельзя» иногда является самым эффективным средством инкапсуляции!

class A

{

private:

int a, b; //скрытые свойства

void DoSomething(); //скрытый метод.

public:

int ReturnSomething(); //открытый интерфейс

};

Класс А инкапсулирует свойства a, b и метод DoSomething, представляя внешний интерфейс ReturnSomething.

Модульность – свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей

Модульность — в языках программирования — принцип, согласно которому программное средство (ПС, программа, библиотека, web-приложение и др.) разделяется на отдельные именованные сущности, называемые модулями. Модульность часто является средством упрощения задачи проектирования ПС и распределения процесса разработки ПС между группами разработчиков. При разбиении ПС на модули для каждого модуля указывается реализуемая им функциональность, а также связи с другими модулями.

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

Чисто абстрактные классы

• Классы, которые содержат n абстрактные методы называются абстрактными

• Классы, которые содержат только абстрактные методы называются чисто абстрактными

• Нельзя создать экземпляр абстрактного класса

• А указатель на абстрактный класс – можно!

• Указывает на экземпляр одного из производных классов

• Абстрактные методы должны быть переопределены в производных классах

Имеют собственное название – интерфейс

Билет №7. Полиморфизм

Полиморфизм - это свойство, которое позволяет одно и то же имя использовать для решения двух или более схожих, но технически разных задач. Целью полиморфизма, применительно к объектно-ориентированному программированию, является использование одного имени для задания общих для класса действий. Выполнение каждого конкретного действия будет определяться типом данных. Например для языка Си, в котором полиморфизм поддерживается недостаточно, нахождение абсолютной величины числа требует трёх различных функций: abs(), labs() и fabs(). Эти функции подсчитывают и возвращают абсолютную величину целых, длинных целых и чисел с плавающей точкой соответственно. В С++ каждая из этих функций может быть названа abs(). Тип данных, который используется при вызове функции, определяет, какая конкретная версия функции действительно выполняется. В С++ можно использовать одно имя функции для множества различных действий. Это называется перегрузкой функций.

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

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

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

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

Деструкторы и полиморфизм

// Деструктор – виртуальный поэтому вызывается через

// таблицу виртуальных функций и вызывает деструкторы

// базовых классов

При возможности полиморфного использования (то есть практически во всех нетривиальных случаях) деструктор класса необходимо объявлять виртуальным

Билет №8.Типы методов

Типы методов (Операций):

• Селектор (инспектор)
- Метод, считывающий состояние объекта, но не меняющий его

• Модификатор (мутатор)

• Метод, меняющий состояние объекта

• Конструктор

• Операция создания объекта и/или его инициализации

• Деструктор

• Операция, освобождающая состояние объекта и/или разрушающая сам объект

Конструкторы

(Конструктор по умолчанию, Конструктор копирования, Конструктор - инициализатор, Конструктор преобразования типа, Обязательные конструкторы)

• Конструктор – метод создания и/или инициализации объекта

• Конструктор – специальный метод, который

– имеет то же имя, что и класс

– не возвращает значений

– вызывается непосредственно после выделения памяти

– не может быть вызван явно

Когда вызывается конструктор:

• При объявлении объекта:

Rational r;

Если объект глобальный, конструктор вызывается до функции main!

• При динамическом создании объекта:

Rational* r = new Rational();

• При присваивании значения не вызывается:

Rational r1, r2;

r1 = r2;

• При передаче параметров между функцией и вызывающей ее программой если параметр передается по значению:

Rational DoSomething(Rational A);

Когда и какие конструкторы нужны:

• Может ли быть класс без конструкторов?

– Нет! Конструктор по умолчанию и конструктор копирования создаются автоматически

• Автоматически созданный конструктор копирования копирует значения полей

• Явные конструкторы копирования абсолютно необходимы, если класс имеет динамические поля

• Все остальные конструкторы определяются исходя из соображений удобства использования

Конструкторы и наследование:

• Конструктор класса-потомка должен вызывать конструктор прямого предка. При этом:

– при отсутствии явного вызова конструктора предка неявно (автоматически) вызывается конструктор предка по умолчанию

– при необходимости конструктор потомка может явно вызвать конструктор предка любого типа (но только один! )

– конструктор предка должен быть указан в списке инициализации потомка

• «Многоуровневый объект» конструируется «сверху-вниз» от предков к потомкам – сначала инициализация предков, затем потомков

Деструкторы

• Деструктор — специальный метод, который вызывается перед освобождением памяти занимаемой объектом

• Деструктор вызывается:

– только неявно (автоматически) – при удалении объекта из стэка

– при удалении динамического объекта:

Rational * c1 = new Rational();

delete c1;

• Функции деструктора:

– освобождение памяти, занимаемой динамическими полями объекта

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

• Компилятор всегда автоматически создает «пустой» деструктор

• В случае, если класс содержит поля-указатели, явное написание деструкторов является абсолютно необходимым

• Явная реализация конструкторов и деструкторов является «хорошим тоном»

• (Деструктор – виртуальный поэтому вызывается через

Базовых классов )

Полиморфизм и деструктор

• При возможности полиморфного использования (то есть практически во всех нетривиальных случаях) деструктор класса необходимо объявлять виртуальным

Модификаторы(мутаторы, mutator)

• Модификатор – метод, меняющий состояние объекта.

• Модификатор в C++ – это просто… метод

class Polygon{

Point* vertices;

public:

//...

void set_vertex(int index, const Point & val);

//...
};

Селекторы(Инспекторы, константные методы)

• Селекторы – методы, не меняющие состояние объекта

• В C++ есть специальный синтаксис для селекторов снабжаются спецификатором const, который входит в сигнатуру метода

• Компилятор в состоянии отследить, что метод-селектор не меняет поля объекта

• Селекторы могут вызывать только селекторы (свои и включенных объектов)

•

Итоги

• Перегрузка оператора может помочь писать интуитивно понятный и «красивый» код.

• При перегрузке операторов нужно «играть по правилам». Некоторые из них проверит компилятор, за некоторыми нужно следить самостоятельно

• Не злоупотребляйте переопределением операторов, смысл операторов должен быть понятен другим программистам

Правила

• Операцию можно определить только в соответствии с синтаксисом С++, например: не может быть унарной операции «/» или постфиксной операции «! »

• Приоритеты, порядок и количество операндов переопределить нельзя 3 + A*b; // operator+(3, operator*(A, b))

• Операторы не имеют аргументов по умолчанию

• Операторы – функции должны содержать хотя бы один пользовательский тип в качестве параметра (кроме операций new и delete)

• Если определены две формы оператора – в виде функции и в виде метода, используется вторая.

Билет №17. Шаблоны

На сцену выходит механизм шаблонов — усовершенствованный макропроцессор для директив

#define. Шаблоны представляют собой ничто иное, как макросы без всех перечисленных

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

функций. Большинство отладчиков C++ при возникновении ошибки правильно указывает строку

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

прекрасную программу закорючками вроде \ и ##.

Если вы собираетесь использовать шаблоны, привыкайте к тому, что в вашей речи будет часто звучать

термин параметризованный (parameterized). Шаблоны используются для создания параметризованных

типов (обычно классов) и параметризованных функций.

Параметризованные типы

Параметризованный тип внешне представляет собой обычное объявление класса, которому

предшествует магическое заклинание template < c1ass Type>, где Type — выбранное вами

символическое имя (остальные элементы задаются жестко). Всюду, где символическое имя Type (или

другое имя) встречается в объявлении класса оно интерпретируется как макрос, вместо которого при

использовании класса подставляется конкретный тип.

Параметризованные функции

Параметризованные функции объявляются точно так же — перед их объявлениями указывается

формула template.... Синтаксис шаблона должен повторяться как при объявлении, так и при

определении функции. Помните, шаблоны на самом деле являются макросами, поэтому они должны

находиться в файлах.h. Если определение будет находиться в файле.срр, программа работать не будет

(если только это не единственный файл.срр, в котором вызывается данная функция).

Передача параметра

Многочисленные символы < и > вызывают изрядную путаницу, поскольку C++ не всегда

последователен. Вообще говоря, < Туре> следует указывать везде, кроме трех мест в объявлениях

классов или определениях их функций:

1. За ключевым словом class в самом начале.

2. При указании имени конструктора.

3. При указании имени деструктора.

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

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

требовал присутствия параметра во всех случаях, но это же C++... Вдобавок можно сэкономить

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

сделать разумные предположения по поводу отсутствующих символов.

Шаблоны с несколькими параметрами

Тип может иметь более одного параметра, хотя такие ситуации встречаются довольно редко. Увидев

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

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

аналогично, разве что вместо < c1ass Type> используется список типа < c1ass Type1, class

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

хотя именно классы прочно удерживают ведущие позиции на рынке параметров.

Долой вложенные параметризованные типы!

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

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

расширении. Помните, что при использовании шаблона самого верхнего уровня будут расширены все

шаблоны.

Последний пункт очень важен. Речь идет о неявных требованиях к типу – параметру шаблона

Эти требования выясняются только при конкретизации класса.

Например, на слайде 31 я забыл убрать параметр по умолчанию 0 для параметра конструктора класса Link

Это накладывает ограничение на тип, который можно использовать в качестве контейнера:

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

Если такое приведение невозможно, конкретный класс не будет скомпилирован.

Фабрика-шаблон

Фабрика-шаблон (С++)

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

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

Побочные эффекты
(требует дальнейшей доработки)

· Application теперь отвечает и за создание объектов, кроме своих прямых обязанностей – взаимодействия с пользователем, чем нарушает принцип???

· Интерфейс «создатель» может создавать только овощи, и ничего больше, чем нарушает принцип!!!

(Если захочется создавать фрукты, потребуется другая иерархия классов-создателей)

??? - единственности ответственности

!!! - инвертирования зависимостей

Последовательные контейнеры

– Сохраняют порядок, в котором элементы были добавлены в контейнер:

– list – поддерживает эффективное удаление и добавление элемента в любой точке массива

(двусвязный список)

– vector – поддерживает эффективный случайный доступ к элементам, добавление и удаление из хвоста последовательности

– deque – поддерживает эффективный случайный доступ к элементам, добавление и удаление из начала и хвоста последовательности

Ассоциативные контейнеры

• Словари – хранят множество пар (Key, Value))

– map, multimap хранят отсортированные по ключу множества

– hash_map, hash_multimap хранят неотсортированные множества, добавление, поиск по ключу элемента в этих структурах очень эффективен

• Множества – хранят множкства элементов (Key)

– set, multiset хранят отсортированные множества

– hash_ set, hash_multiset хранят неотсортированные множества, добавление, поиск по ключу и удаление элемента в этих структурах очень эффективен

• Multi в имени класса обозначает, что контейнер может хранить более одного объекта с идентичным ключом

Итераторы

• Итераторы – объекты, которые предоставляют доступ к объектам, хранящимся в контейнере, без предоставления прямого доступа к деталям реализации контейнера

• Предоставляют универсальный доступ к контейнерам

Итераторы STL

• Обобщение указателей, ключевая концепция в STL

• Перегружают операции арифметики указателей, сравнения, разыменования (operator *) и косвенного обращения (operator-> )

• Являются «посредниками» между алгоритмами и контейнерами

– В STL реализованы алгоритмы сортировки, поиска, манипуляции последовательностями

– Алгоритмы используют итераторы, а не контейнеры

Важно, что итераторы – самостоятельныеобъекты, которые хранят внутри себя состояние итерации.

Это позволяет запускать несколько итераций по одному контейнеру одновременно

Итераторы в STL бывают

• Итераторы записи (OutputIterator). Гарантирует запись в контейнер, но не обязательно чтение, и сдвиг в одном направлении.

• Итераторы чтения (InputIterator). Гарантирует чтение значения(через операцию разыменования) и сдвиг в одном направлении (операция инкремента).

• Однонаправленные (Forward). Однонаправленные итераторы работают на чтение и на запись и гарантируют возможность дважды использовать один и тот же итератор

• Двунаправленные (Bidirectional). Как однонаправленный, но сдвигать можно в двух направлениях

• Случайного доступа. Доступна также целочисленная арифметика указателей и операция взятия индекса

•

Объекты

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

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

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

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

Линия жизни объекта

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

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

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

Фокус управления

В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия, или состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а его нижняя сторона - окончание фокуса управления (окончание активности). Прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни, если на всем ее протяжении он является активным.

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

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

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

Сообщения

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

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

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

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

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

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

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

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

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

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

Билет 1. Время жизни объектов. Связь с типами памяти и областями видимости

Время жизни объектов

Время жизни объекта — интервал времени выполнения программы, в течение которого объект существует в памяти

Время жизни объекта:

- Глобальное - время работы программы (при этом не обязательно всегда видима)

- Локальное - время выполнения блока (при новом входе в блок обновляется)

Время жизни функций – глобальное

Область видимости

Области видимости переменной:

- Локальная — в блоке (и вложенных блоках)

- Файловая — в файле с места объявления

- Глобальная — межфайловая при объявлениях extern

Видимость функций:

- Файловая, с момента описания или объявления прототипа

12 3 4 5 Следующая ⇒