Параллельное программирование

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

Декомпозиция работ, как  уже было отмечено выше, определяет, что должны делать разные части ПО. Когда множество компонентов ПО работают в рамках одной задачи, их функционирование необходимо координировать. Определенный компонент должен «уметь» определить, когда достигается решение всей задачи. Необходимо также скоординировать порядок выполнения компонентов. При этом возникает множество вопросов. Все ли части ПО должны одновременно приступать к работе или только некоторые, а остальные могут находиться пока в состоянии ожидания? Каким двум (или больше) компонентам необходим доступ к одному и тому же ресурсу? Кто имеет право получить его первым? Если некоторые части ПО завершат свою работу гораздо раньше других, то нужно ли им «поручать» новую работу? Кто должен давать новую работу в таких случаях? ДСС (декомпозиция, связь и синхронизация) — это тот минимум вопросов, которые необходимо решить, приступая к параллельному или распределенному программированию. Помимо сути проблем, составляющих ДСС, важно также рассмотреть их привязку. Существует несколько уровней параллелизма в разработке приложений, и в каждом из них ДСС-составляющие применяются по-разному.

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

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

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

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

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

 

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

Инкапсуляция

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

•языковой механизм ограничения доступа к определённым компонентам объекта;

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

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

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

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

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

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

Изменим пример с принтером. Предположим, во время профилактики вычислительной системы у принтера было отключено электропитание. Естественно, в этом случае наши попытки что-то напечатать ни к чему не приведут. Учтем  это в нашей модели принтера. Добавим  свойство is_on, отражающее подключение к принтеру электрического питания (0 – включено, 1 – выключено). Тогда состояние принтера определяется комбинацией значений двух свойств – is_on и status.

Допустимые состояния  принтера

is_on	status	Сообщение на экране
0	0	Принтер включен
1	0	Принтер включен Состояние: готов к работе
	1	Принтер включен Состояние: печатает

 

При этом класс представляется в виде:

class Printer

{

char model[15];

int year;

int status;

int is_on; //Принтер включен (0 – нет,1 – да)

public:

Printer(char* _model, int _year);

void on_off(); //Включение/выключение питания

void set_print();

void stop_print();

void show();

};

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

Printer :: Printer(char* _model, int _year)

{

strcpy(model, _model);

year=_year;

status=0;

is_on=0; //Принтер отключен по умолчанию

}

void Printer :: on_off()

{

//Метод моделирует нажатие  кнопки включения 

//питания:если оно выключено, то произойдет

//включение, и наоборот;

//одновременно при любых  переключениях питания //принтер  оказывается в состоянии готовности 

//и печать не ведет

is_on=!is_on;

status=0;

}

void Printer :: set_print()

{

If (is_on) status=1; //Принтер будет печатать,

//если он включен

}

void Printer :: stop_print()

{

If (status) status=0; //Принтер остановится,

//если он до того  печатал

}

void Printer :: show()

{

cout << "Модель: " << model << "Год выпуска: " << year << endl;

if (is_on)

{

cout << "Принтер включен";

if (status) cout << "Состояние: печатает";

else cout << "Состояние: готов к работе";

}

else cout << "Принтер выключен";

cout << endl;

}

Класс запрещает прямой доступ к своим переменным состояния, поэтому  не удастся реализовать недопустимое состояние is_on=0, status=1. Методы set_print(), stop_print(), on_off(), предоставляющие доступ к свойствам объекта, реализованы так, что также исключают это состояние объекта. В этом и заключается смысл понятия инкапсуляции.

 

 

 

 

 

 

 

 

 

 

Заключение 

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

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

 

Список использованной литературы

1. Водяхо А.И., Горнец Н.Н., Пузанков Д.В. Высокопроизводительные системы обработки данных./А.И. Водяхо, Н.Н. Горонец, Д.В. Пузанков. – М.: Высшая школа, 1997.
2. Хьюз К., Хьюз Т. Паралелльное и распределенное программирование на С++. / К. Хьюз, Т. Хьюз. – М.:
3. http://f1-delphi.ru/books/parallelnoe_i_raspredelennoe_p/