- •Конспект лекций модуля № 1 "Введение" дисциплины "Распределенные программные системы и технологии" Тема 1. Определение и характеристики распределенных программных систем
- •1.1. Определение и задачи распределенных систем
- •1.2. Прозрачность
- •1.3. Открытость
- •1.4. Масштабируемость
- •1.5. Дополнительные свойства распределенных систем
- •1.5.1. Отказоустойчивость.
- •1.5.2. Безопаснтность.
- •1.6. Проблемы создания распределенных систем
- •Тема 2. Организация распределенных систем
- •2.1. Уровни распределенных программных систем
- •2.2. Аппаратный уровень
- •2.2.1. Классификация Флина
- •Simd(векторные компьютеры)
- •Misd(систалический массив)
- •Mimd(локальные, глобальные сети)
- •2.2.2. Классификация, основанная на процессорах и памяти (разделённой памяти)
- •2.2.3. Мультипроцессоры и мультикомпьютеры Базовые архитектуры
- •Мультипроцессоры
- •Гомогенные мультикомпьютерные системы
- •Гетерогенные мультикомпьютерные системы
- •2.3. Уровень операционных систем
- •2.3.1. Виды операционных систем
- •2.3.2 Распределенные операционные системы
- •Операционные системы для однопроцессорных компьютеров
- •Мультипроцессорные операционные системы
- •Мультикомпьютерные операционные системы
- •Системы с распределенной разделяемой памятью
- •2.3.3. Сетевые операционные системы
- •2.4. Программное обеспечение промежуточного уровня
- •2.4.1. Позиционирование программного обеспечения промежуточного уровня
- •2.4.2. Модели промежуточного уровня
- •2.4.3. Службы промежуточного уровня
- •2.4.4. Промежуточный уровень и открытость
- •Тема 3. Архитектуры распределенных программных систем
- •3.1. Протокол запрос-ответ
- •3.2. Выбор архитектуры
- •3.2.1.Виды архитектур
- •3.2.2. Архитектура клиент/сервер
- •3.2.3. Трехзвенная архитектура
- •3.2.4. Архитектура распределенных объектов.
- •Тема 4. Декомпозиция программных систем
- •4.1. Проектирование модульных систем
- •4.1.1. Основные понятия
- •4.3.2. Проектирование на основе структур данных (Data-Structure-Centered Design)
- •4.3.3. Компонентное проектирование (Component-Based Design)
- •4.1. Декомпозиция программных систем
- •4.1.1. Объектно-ориентированная декомпозиция
- •4.1.2. Статически-ориентированная декомпозиция
- •4.2. Метрики связанности модулей
- •4.2.1. Основные метрики
- •4.2.2. Главная последовательность
- •4.2.3. Расстояние от главной последовательности
- •4.3. Параллелизм программных систем
- •4.3.1 Признаки параллельных программ
- •4.3.2. Параллелизм данных (Data Parallel)
- •4.3.3. Параллелизм задач
- •4.3.3.1. Общая идея
- •4.3.3.2. Модель процесс/канал
- •4.3.3.3. Модель обмен сообщениями
- •4.3.3.3. Модель общая память
- •4.3.4. Оценки эффективности параллелизма.
4.2. Метрики связанности модулей
4.2.1. Основные метрики
Ответственность, независимость и стабильность модуля могут быть измерены путем подсчета зависимостей, которые взаимодействуют с этим модулем. Могут быть определены три метрики :
Ca :Центростремительное сцепление (Afferent Couplings). Количество классов вне этого модуля, которые зависят от классов внутри этого категории.
Ce: Центробежное сцепление (Efferent Couplings). Количество классов внутри этого модуля, которые зависят от классов вне этого модуля.
I: Нестабильность (Instability ): I = Ce / (Ca+Ce). Эта метрика имеет диапазон значений [0,1]. I = 0 указывает максимально стабильный модуль. I = 1 указывает максимально не стабильный модуль.
Если бы все модули в системе были максимально устойчивы, система была бы неизменна. На самом деле, необходимо, чтобы часть проекта была достаточно гибкой, а оставшаяся часть оставалась неизменной. Как может модуль с максимальной устойчивостью (I=0) быть достаточно гибким, чтобы противостоять изменениям? Ответ должен быть найден в использовании принципа "открыт/закрыт". Руководствуясь этим принципом, можно и желательно создать классы, которые являются достаточно гибкими, чтобы быть расширенными, и не требовать при этом модификации. Какие классы соответствуют этому принципу? Абстрактные классы.
Таким образом, если модуль должен быть устойчивым, он должен состоять из абстрактных классов, чтобы его можно было затем расширить. Устойчивые модули те, которые являются расширяемыми, гибкими и не ограничивают проект.
Если устойчивые модули должны быть очень абстрактными, то можно сделать вывод, что нестабильные модули должны быть очень конкретны. На самом деле это стоит обсудить подробнее.
Абстрактный модуль должен иметь зависимые от него модули, поскольку должны существовать классы вне этого абстрактного модуля. Эти классы есть наследники классов из этого модуля, либо они реализуют отсутствующие у них чистые интерфейсы из абстрактного модуля. Нестабильные модули должны быть поэтому не абстрактными, а конкретными.
Мы можем определять метрику, которая измеряет "абстрактность" модулей следующим образом:
A: Абстрактность (Abstractness): A = nA / nAll. nA - количество_абстрактных_классов_в_модуле. nAll - oбщее_количество_классов_в_модуле. Значения этой метрики меняются в диапазоне [0,1]. 0 – модуль полностью конкретен, 1 - модуль полностью абстрактен.
4.2.2. Главная последовательность
Теперь мы в состоянии определить отношение между стабильностью (I) и абстрактностью (A). Мы можем создавать граф с (A) на вертикальной оси и (I) на горизонтальной оси. Если мы начертим на этом графике два вида "хороших" модулей, то модули, которые являются максимально устойчивыми и абстрактными, окажутся в верхнем левом углу в (0,1). Модули, которые являются максимально нестабильными и конкретными - в нижнем правом углу (1,0).
Но не все модули окажутся в одной из этих двух позиций. Модули имеют степени абстракции и стабильности. Например, очень часто один абстрактный класс порожден от другого абстрактного класса. Порожденный класс - абстракция, которая имеет зависимость из-за его порождения. Поэтому, хотя он имеет максимальную абстракцию, он не будет максимально стабилен. Эта его зависимость уменьшит его стабильность.
Рассмотрим модуль с A=0 и I=0. Это - очень стабильный и конкретный модуль. Такой модуль не желателен из-за своей "твердости". Он не может быть расширен, потому что не абстрактен. И очень трудно изменяем из-за своей стабильности.
Рассмотрим модуль с A=1 и I=1. Этот модуль также нежелателен (и даже невозможен), потому что он - максимально абстрактен, и, тем не менее, его никто не использует. Он также тверд, потому что такие абстракции невозможно расширить.
Что можно сказать относительно модуля A =.5 и I =.5? Он частично расширяем, потому что он частично абстрактен. Кроме того, он частично стабилен, поскольку расширения не являются максимально неустойчивыми. Такая модуль выглядит "сбалансированным". Его стабильность находится в балансе с его абстрактностью.
Рассмотрим снова граф (A-I), показанный ниже на рисунке. Мы можем нарисовать линию из (0,1) в (1,0). Эта линия (A + I = 1) представляет модуль, чья абстрактность сбалансирована с их стабильностью. Из-за сходства с графом, используемым в астрономии, эту линию можно назвать Главная последовательность.
Модуль, который расположен на главной последовательности, не "слишком абстрактен" для его стабильности, ни - "слишком нестабилен" для его абстрактности.
Он имеет "правильное" количество конкретных и абстрактных классов пропорционально его центробежным и центростремительным зависимостям. Ясно, наиболее желательные положения для модуля на одном из концов главной последовательности. Однако, судя по опыту, только приблизительно половина модулей проекта может иметь такие идеальные характеристики. Оставшиеся модули имеют лучшие характеристики, если они или расположены близко к главной последовательности, или расположены прямо на ней.
