
- •Билет №1
- •1.Составные части и свойства распределенной системы
- •2. Удаленный сервер
- •Билет №2
- •1. Параллелизм в распределенной системе
- •2. Реализация локального сервера
- •Билет №3
- •1. Закон Амдала
- •2. Заместитель/заглушка. Компилятор midl
- •Билет №4
- •1. Ускорение решения задачи в распределенной параллельной системе
- •2. Язык idl
- •Билет №5
- •1. Последовательные операции. Параллельные операции. Число процессоров.
- •2. Назначение данных на узлы распределенной системы. Модель назначения объектов на узлы. Сокращение трафика в каналах передачи данных.
- •Билет №6
- •1. Планирование параллельной распределенной обработки данных.
- •2. Модель назначения объектов на узлы. Частоты запросов к объектам. Длины объектов. Производительность узлов. Производительность каналов передачи данных.
- •Билет №7
- •1. Параллелизм в пространстве и во времени (конвейерный параллелизм)
- •2. Среднее время обработки одного запроса. Минимизация времени
- •Многошаговое планирование на базе asap
- •Билет №8
- •1. Синхронное и асинхронное планирование.
- •2. Время обработки всех запросов к объектам. Загрузка узлов. Загрузка каналов передачи данных.
- •Билет №9
- •1. Планирование при ограничениях на ресурсы, время, достижимость
- •2. Локальный вызов процедуры. Маршалинг Локальный вызов процедуры
- •Маршалинг
- •Б илет №10
- •Стратегия планирования asap Алгоритм планирования asap (как можно раньше)
- •2. Серверы в exe.
- •Билет №11
- •1. Стратегия планирования alap
- •2. Включение и агрегирование компонентов
- •Стратегия планирования «Группировка доминирующей последовательности» (Dominant Sequence Clustering - dsc)
- •Билет №12
- •1. Стратегия спискового планирования
- •Регистрация компонента в реестре
- •Билет №13
- •1. Многошаговое планирование
- •2. Функции CoGetClassObject и DllGetClassObject и их использование
- •Билет №14
- •1. Цепочечное планирование
- •2. Интерфейс iClassFactory
- •Билет №15
- •1. Граф предшествования и граф распараллеленности операций
- •2. Фабрика класса
- •Билет №16
- •1. Свертывание графа распараллеленности операций
- •2. Использование динамической библиотеки. Экспорт функций из библиотеки. Загрузка и выгрузка dll
- •Билет №17
- •1. Синтез последовательно параллельного плана
- •2. Динамическая компоновка. Библиотеки dll. Создание динамической библиотеки
- •Билет №18
- •1. Модель разнородной распределенной системы
- •2. Управление временем жизни компонента. Подсчет ссылок
- •Билет №19
- •1. Сведение планирования к задаче целочисленного линейного программирования
- •2. Запрос интерфейса. Интерфейс iUnknown. Реализация интерфейса
- •Билет №20
- •1. Задача минимизации ресурсов при заданном времени реализации плана
- •2. Таблица виртуальных функций
- •Билет №21
- •1. Целочисленное линейное программирование. Пример. Целевая функция. Система ограничений
- •Многошаговое планирование на базе asap
- •Билет №22
- •1. Планирование выполнения графа задач на узлах распределенной системы с учетом обмена данными
- •2. Теория интерфейсов
- •Неизменность интерфейсов
- •Билет №23
- •1. Граф задач. Назначение задач на процессоры. Обмен данными. План решения задач на каждом процессоре. Планирование выполнения графа задач на узлах распределенной системы с учетом обмена данными
- •Планирование графа задач
- •2. Языки и инструменты программирования распределенной обработки данных.
- •Билет №24
- •1. Стратегии планирования на графе задач. Планирование графа задач
- •2. Процессы и потоки. Многопоточные приложения. Модель многопоточных приложений
- •Билет №25
- •1. Стратегия планирования «Наиболее ранняя задача первая» (Earliest Task First - etf). Стратегия планирования «Наиболее ранняя задача первая» (Earliest Task First - etf)
- •2. Инкапсуляция. Полиморфизм. Виртуальные функции. Чисто абстрактные базовые классы. Множественное наследование. Инкапсуляция.
- •Полиморфизм и виртуальные функции
- •Чисто абстрактные базовые классы
- •Множественное наследование классов. Компоненты
- •Типы операций:
- •Билет №26
- •1. Стратегия планирования «Зануление дуг» (Edge Zeroing - ez). Стратегия планирования «Зануление дуг» (Edge Zeroing - ez)
- •2. Преимущество использования компонентов. Требования к компонентам. Преимущества использования компонентов
- •Требования к компонентам
- •Билет №27
- •2. Модель компонентных объектов com.
- •Билет №28
- •1. Стратегия планирования «Управление мобильностью» (Mobility Directed - md). Стратегия планирования «Управление мобильностью» (Mobility Directed - md)
- •2. Интерфейс передачи сообщений (Message Passing Interface - mpi). Интерфейс передачи сообщений mpi
- •Билет №29
- •1. Граф взаимодействия задач. Граф разнородной сети. Планирование решения задач в разнородной распределенной системе
- •Постановка проблемы
- •2 . Интерфейс OpenMp. Интерфейс OpenMp
- •Билет №30
- •Постановка проблемы
- •Алгоритм а* оптимального назначения задач на процессоры
- •2. Технологический стандарт написания распределённых приложений corba. Технологический стандарт corba
2. Инкапсуляция. Полиморфизм. Виртуальные функции. Чисто абстрактные базовые классы. Множественное наследование. Инкапсуляция.
Компоненты должны скрывать (или инкапсулировать) детали своей реализации. Для того, чтобы воспользоваться преимуществами динамической компоновки, компоненты и клиенты должны не изменять свои интерфейсы. Они должны быть инкапсулирующими. Детали реализации клиента и компонента не должны отражаться в интерфейсе. Чем надежнее интерфейс изолирован от реализации, тем менее вероятно, что он изменится при модификации клиента и компонента. Если интерфейс не изменяется, то изменение компонента оказывает лишь незначительное влияние на приложение в целом. Необходимость изоляции клиента от деталей реализации накладывает на компоненты важные ограничения:
Компонент должен скрывать используемый язык программирования.
Компоненты должны распространяться в двоичной форме.
Должна быть возможность модернизировать компоненты, не затрагивая уже существующих пользователей.
Должна быть возможность перемещать компоненты в сети, внутри одного процесса, в разных процессах на разных машинах.
Полиморфизм и виртуальные функции
Классы объектов в С++. Они инкапсулируют данные и функции, описывающие объект класса и записываются в виде
class X {
private:
<внутренняя реализация>
public:
<интерфейс с внешним миром>
};
Иерархия классов. Для построения иерархии классов используются два принципа: наследования (inheritance) и композиции. Композиция определяется через объявление объекта существующего класса в виде элемента данных нового класса. Наследование определяется как создание нового класса как типа существующего класса путем наращивания нового кода без изменения кода существующего класса. Пример композиции и наследования:
class Point { … };
class Task { … };
class Node : public Point { … Task t; …};
Полиморфизм. В языке С++ полиморфизм трактуется как объявление функции в базовом классе и ее специфическое определение в каждом классе иерархии, наследующей базовый класс. На базе полиморфизма строится еще одна плоскость, отделяющая интерфейс объекта от его реализации. Он поддерживает создание программ, расширяемых не только в период их создания, но также в период использования. Полиморфный тип, определяемый через иерархию классов объектов, – это тип, описываемый посредством виртуальных функций.
Виртуальные функции. Виртуальные функции отделяют интерфейс от реализации в зависимости от типов. Виртуальные функции предоставляют возможность объявлять в базовом классе методы, которые можно определять по-своему в каждом производном классе. Объявление виртуальной функции работает в качестве интерфейса к функциям, определенным в производных классах.
Типы аргументов функции в производном классе не должны отличаться от типов аргументов, объявленных в базовом классе. Небольшие изменения допускаются для типа возвращаемого значения
Спецификация функции в базовом классе как virtual вызываем позднее связывание (так называемое связывание во время выполнения). Если функция виртуальная в базовом классе, она виртуальная также во всех производных классах. Позднее связывание имеет место только при использовании адреса объекта базового класса, в котором функция объявляется.
Пример полиморфизма в С++. Он строится на иерархии классов духовых инструментов:
// Инструмент
class Instrument { public: virtual void play () { cout << “Instrument :: play” << endl; }};
// Духовые
class Wind : public Instrument { public: void play () { cout << “Wind :: play” << endl; }};
// Мелодия
void tune ( Instrument& i ) { i.play (); }
// Исполнение
void main () {
Wind flute; // Флейта
tune (flute); // Upcasting
}
В функции tune содержится вызов виртуальной функции play, который связывается с той реализацией, которая соответствует реальному типу объекта, используемому в качестве аргумента функции.