Открытость системы принципов

3. Принципы открытых систем

Открытость системы принципов
sh: 1: id_: not found

Открытые Системы  

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

3.1. Эталонная модель среды открытых систем

Для структурирования среды открытых систем используется эталонная модель (Open System Environment Reference Model — OSE/RM), принятая в основополагающем документе ISO/IEC 14252 (Рисунок 3).

Она может модернизироваться в зависимости от класса системы.

Например, для телекоммуникационных систем хорошо известна 7-уровневая модель взаимосвязи открытых систем ISO/IEC 7498, которую можно представить как расширение модели OSE/RM с детализацией верхнего прикладного уровня.

Рисунок 3–Эталонная модель среды открытых систем

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

  • приложение;
  • платформу;
  • внешнюю среду;
  • интерфейс приложения с платформой;
  • интерфейс платформы с внешней средой.

По горизонтали имеются следующие компоненты (функциональные области):

  • службы операционной системы;
  • службы интерфейса «человек-машина»;
  • служба управления данными;
  • служба обмена данными;
  • служба машинной графики;
  • служба сетевого обеспечения.

К третьему измерению относятся:

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

На базе эталонной модели строятся ее модификации в зависимости от архитектуры конкретной системы.

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

3.2. Классификация профилей

Существует несколько видов классификации профилей. В общем случае профили можно разделить на :

  • профили общего назначения;
  • профили конкретного применения.

К профилям общего назначения относятся:

  • международные стандартизованные профили (International Standardized Profiles — IPS), признанные комитетом ISO/IEC. ISP имеют в международном сообществе такой же статус, что и международные базовые стандарты и направлены на широкую область применения;
  • национальные профили, в соответствии с которыми должна строиться национальная Информационная Инфраструктура;
  • корпоративные профили;
  • технические профили, описывающие среду, такие как профили платформ, профили суперкомпьютерной среды, профили реального времени и др.

К профилям конкретного применения относятся :

  • отраслевые или ведомственные профили;
  • профили предприятий, организаций, департаментов и подразделений.

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

  • в разработке профилей общего назначения участвует как можно большее число специалистов;
  • в разработке профилей конкретного применения участвуют около 10 специалистов, половину из которых составляют пользователи, а половину — специалисты в области информационных технологий. Очень важно, чтобы эта группа возглавлялась одним из первых лиц (отрасли, организации), хорошо представляющим цели основной деятельности (отрасли, организации и т.д.).

3.3. Масштаб проблемы

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

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

  • системы реального времени;
  • микропроцессорные встроенные системы;
  • среду высокопроизводительных вычислений (Grid-структуру).

В реализации принципов открытых систем заинтересованы все участники процесса информатизации:

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

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

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

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

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

2005-06-22 14:21:31 :: 1

а не плохо написано! 

ДОБАВИТЬ КОММЕНТАРИЙ

Источник: http://www.opensys.info/article/index.php?id_article=8&id_parent=0&id_

Принцип открытости-закрытости

Открытость системы принципов

Привет, Хабр! Перед вами перевод статьи Роберта Мартина Open-Closed Principle, которую он опубликовал в январе 1996 года. Статья, мягко говоря, не самая свежая. Но в рунете статьи дяди Боба про SOLID пересказывают только в урезанном виде, поэтому я подумал, что полный перевод лишним не будет.

Я решил начать с буквы O, так как принцип открытости-закрытости, по сути, является центральным. Среди прочего тут есть много важных тонкостей, на которые стоит обратить внимание:

  • Ни одну программу нельзя «закрыть» на 100%.
  • Объектно-ориентированное программирование (ООП) оперирует не физическими объектами реального мира, а понятиями — например, понятием «упорядочивание».

Это первая статья в моей колонке Заметки Инженера для The C++ Report. Статьи, публикуемые в этой колонке, будут фокусироваться на использовании C++ и ООП и затрагивать сложности в разработке ПО. Я постараюсь сделать так, чтобы материалы были прагматичны и полезны для практикующих инженеров. Для документации объектно-ориентированного дизайна в этих статьях я буду использовать нотацию Буча.

С объектно-ориентированным программированием связано много эвристик. Например, «все переменные-члены (member variables) должны быть закрытыми (private)», или «следует избегать глобальных переменных», или «определение типов во время исполнения опасно».

В чем причина таких эвристик? Почему они правдивы? Всегда ли они правдивы? В этой колонке исследуется принцип проектирования, лежащий в основе этих эвристик, — принцип открытости-закрытости.
Ивар Якобсон сказал: «Все системы изменяются в процессе жизненного цикла.

Это нужно иметь в виду при проектировании системы, у которой ожидается больше одной версии».

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

Програмные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения и закрыты для изменений.

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

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

Описание

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

  1. Открыты для расширения. Это означает, что поведение модуля может быть расширено. То есть мы можем добавить модулю новое поведение в соответствии с изменившимися требованиями к приложению или для удовлетворения нужд новых приложений.
  2. Закрыты для изменений. Исходный код такого модуля неприкасаем. Никто не вправе вносить в него изменения.

Кажется, что два этих признака друг с другом не вяжутся. Стандартный способ расширить поведение модуля — внести в него изменения. Модуль, который не может быть изменен, обычно мыслится как модуль с фиксированным поведением. Как же могут быть выполнены эти два противоположных условия?

Ключ к решению — абстракция

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

Абстракции — это абстрактные базовые классы, а неограниченный набор возможных поведений представлен всеми возможными классами-наследниками. Модуль может манипулировать абстракцией. Такой модуль закрыт для изменений, так как он зависит от фиксированной абстракции. Также поведение модуля может быть расширено созданием новых наследников абстракции.

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

Нет гарантий, что функции — члены класса Server виртуальны. Класс Client использует класс Server.

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

Закрытый клиент

А на следующей схеме представлен соответствующий вариант проектирования, который отвечает принципу открытости-закрытости. В этом случае класс AbstractServer — это абстрактный класс, все функции-члены которого виртуальные. Класс Client использует абстракцию.

Однако объекты класса Client будут использовать объекты класса-наследника Server. Если мы захотим, чтобы объекты класса Client использовали другой класс сервера, то мы введем нового наследника класса AbstractServer. Класс Client при этом останется без изменений.

Открытый клиент

Абстракция Shape

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

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

Этот элемент — код типа, который идентифицирует структуру данных как круг или квадрат.

Функция DrawAllShapes проходит по массиву указателей на эти структуры данных, узнавая код типа и затем вызывая соответствующую функцию (DrawCircleили DrawSquare).

//Листинг 1//Решение проблемы Квадрат/Круг в процедурном стиле enum ShapeType {circle, square} struct Shape{ ShapeType itsType;};struct Circle{ ShapeType itsType; double itsRadius; Point itsCenter;}; struct Square{ ShapeType itsType; double itsSide; Point itsTopLeft;};//// реализованы в другом месте//void DrawSquare(struct Square*)void DrawCircle(struct Circle*);typedef struct Shape *ShapePointer;void DrawAllShapes(ShapePointer list[], int n){ int i; for (i=0; iitsType) { case square: DrawSquare((struct Square*)s); break; case circle: DrawCircle((struct Circle*)s); break; } }}

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

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

Добавить новые фигуры в такое приложение — значит найти все места, где используются такие switch-операторы (или цепочки if/else), и добавить новую фигуру в каждое из них.

Более того, очень маловероятно, что все switch-операторы и цепочки if/else будут так же хорошо структурированы, как в DrawAllShapes.

Куда более вероятно, что предикаты в операторах if будут скомбинированы с логическими операторами или case-блоки switch-операторов будут скомбинированы так, чтобы «упростить» конкретное место в коде. Поэтому проблема нахождения и понимания всех мест, где нужно добавить новую фигуру, может быть нетривиальна.

В листинге 2 я покажу код, который демонстрирует решение задачи квадрат/круг, отвечающее принципу открытости-закрытости. Вводится абстрактный класс Shape. Этот абстрактный класс содержит одну чистую виртуальную функцию Draw. Классы Circle и Square являются наследниками класса Shape.

//Листинг 2//Решение проблемы Квадрат/Круг в ООП-стиле class Shape{public: virtual void Draw() const = 0;};class Square : public Shape{public: virtual void Draw() const;};class Circle : public Shape{public: virtual void Draw() const;};void DrawAllShapes(Set& list){ for (Iteratori(list); i; i++) (*i)->Draw();}

Заметьте: если мы захотим расширить поведение функции DrawAllShapes в листинге 2, чтобы рисовать новый вид фигур, то все, что нам нужно сделать, это добавить нового наследника класса Shape. Не нужно изменять функцию DrawAllShapes. Поэтому DrawAllShapes отвечает принципу открытости-закрытости. Ее поведение может быть расширено без изменений самой функции.

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

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

Стратегия ввода закрытости

Очевидно, что ни одна программа не может быть на 100% закрыта. Например, что произойдет с функцией DrawAllShapes из листинга 2, если мы решим, что сначала должны быть нарисованы круги, а затем квадраты? Функция DrawAllShapes не закрыта от такого рода изменений. В целом не важно, насколько «закрыт» модуль, всегда есть какой-то тип изменений, от которого он не закрыт.

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

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

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

Использование абстракции для доcтижения дополнительной закрытости

Как мы можем закрыть функцию DrawAllShapes от изменений в порядке рисования? Помним, что закрытие базируется на абстракции. Поэтому, чтобы закрыть DrawAllShapes от упорядочивания, нам нужна некая «абстракция упорядочивания». Частный случай упорядочивания, представленный выше, — это рисование фигур одного типа перед фигурами другого типа.

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

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

В C++ эта функция может быть представлена как перегрузка оператора « 0)) done = true; } else // table entry == 0 done = true; } return thisOrd < argOrd;}

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

Дальнейшее закрытие

Это не конец истории. Мы закрыли иерархию класса Shape и функцию DrawAllShapes от изменения политики упорядочивания, базирующейся на типе фигур. Однако наследники класса Shape не закрыты от политик упорядочивания, которые не связаны с типами фигур.

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

Полное исследование подобных проблем выходит за рамки данной статьи; однако интересующийся читатель может подумать, как решить эту проблему, используя абстрактный класс OrderedObject, содержащийся в классе OrderedShape, который наследуется от классов Shape и OrderedObject.

Эвристики и конвенции

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

Делайте все переменные-члены приватными

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

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

То есть функция не закрыта от изменений этих переменных.

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

Но что если у вас есть переменная, насчет которой вы уверены, что она никогда не изменится? Имеет ли смысл делать ее private? Например, в листинге 7 приводится класс Device, содержащий переменную — член bool status. В ней хранится статус последней операции. Если операция была успешна, то значение переменной status будет true, в противном случае — false.

//Листинг 7//неконстантная публичная переменная class Device{public: bool status;};

Мы знаем, что тип или смысл этой переменной никогда не изменится.

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

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

С другой стороны, предположим, что у нас есть класс Time, приведенный в листинге 8. В чем опасность публичности переменных — членов этого класса? Очень маловероятно, что они изменятся.

Более того, не важно, изменяют клиентские модули значения этих переменных или нет, так как изменение этих переменных предполагается.

Также очень маловероятно, что наследуемые классы могут зависеть от значения конкретной переменной-члена. Так есть ли проблема?

//Листинг 8 class Time{public: int hours, minutes, seconds; Time& operator-=(int seconds); Time& operator+=(int seconds); bool operator< (const Time&); bool operator> (const Time&); bool operator==(const Time&); bool operator!=(const Time&);};

Единственная претензия, которую я мог бы предъявить коду из листинга 8, — это то, что изменение времени не атомарно. То есть клиент может изменить значение переменной minutes без изменения значения переменной hours.

Это может привести к тому, что объект класса Time может содержать несогласованные данные. Я бы предпочел ввести единственную функцию для установки времени, которая принимала бы три аргумента, что делало бы установку времени атомарной операцией.

Но это слабый аргумент.

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

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

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

Поэтому в таких редких случаях, когда принцип открытости-закрытости не нарушается, запрет public — и protected-переменных зависит больше от стиля, а не от содержания.

Никаких глобальных переменных… вообще!

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

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

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

Тут опять же вступают в игру проблемы стиля. Альтернативы использованию глобальных переменных обычно недороги.

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

Типичный пример — глобальные переменные cout и cin. В таких случаях, если принцип открытости-закрытости не нарушается, можно пожертвовать стилем ради удобства.

RTTI — это опасно

Еще один распространенный запрет — использование dynamic_cast. Очень часто dynamic_cast или другою форму определения типа во время выполнения (RTTI) обвиняют в том, что это крайне опасная техника, а потому ее следует избегать.

При этом часто приводят пример из листинга 9, который очевидно нарушает принцип открытости-закрытости.

Однако в листинге 10 приведен пример аналогичной программы, которая использует dynamic_cast, не нарушая при этом принцип открытости-закрытости.

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

Однако в листинге 10 в этом случае никаких изменений не требуется. Поэтому код из листинга 10 не нарушает принцип открытости-закрытости.

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

//Листинг 9//RTTI, нарушающее принцип открытости-закрытости. class Shape {};class Square : public Shape{private: Point itsTopLeft; double itsSide; friend DrawSquare(Square*);};class Circle : public Shape{private: Point itsCenter; double itsRadius; friend DrawCircle(Circle*);};void DrawAllShapes(Set& ss){ for (Iteratori(ss); i; i++) { Circle* c = dynamic_cast(*i); Square* s = dynamic_cast(*i); if (c) DrawCircle(c); else if (s) DrawSquare(s); }}
//Листинг 10//RTTI, не нарушающее принцип открытости-закрытости. class Shape{public: virtual void Draw() cont = 0;};class Square : public Shape{// реализация.};void DrawSquaresOnly(Set& ss){ for (Iteratori(ss); i; i++) { Square* s = dynamic_cast(*i); if (s) s->Draw(); }}

Заключение

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

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

Источник: https://habr.com/post/472186/

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

Открытость системы принципов

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

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

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

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

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

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

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

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

В первом учебнике С. Л. Рубинштейна это прозвучало так: «Психологическое познание — это опосредованное познание психического через раскрытие его существенных, объективных связей и опосредований», — и далее: «правильность определения психологического факта в процессе осознания, всегда основывающегося на раскрытии его отношений к объективной деятельности, может быть объективно установлена в деятельности» [Рубинштейн, 1935, с. 45-46]. Здесь еще категории опосредствования и деятельности слиты в едином понимании активного бытия человека в мире и обоснования возможности объективного познания психического. Но позже категория опосредствования была так детально разработана в культурно-исторической концепции (опосредствование психологическими орудиями, знаками), что ее частнонаучное звучание — в конкретной теории — в определенной степени перевесило изначально более широкий методологический посыл, стоявший за этим словом как категорией. Как будет показано в следующей главе, в конце 90-х гг. XX в. вновь встала проблема соотнесения категорий деятельности и опосредствования. Понимание опосредствования как широко понятой медиации [Зинченко, 2003] возвращает этому понятию статус категории, но в уже ином содержательном наполнении, чем применительно только к концепции деятельностного опосредствования. Деятельность в обоих подходах, поставивших во главу угла эту категорию (подходы Рубинштейна и Леонтьева), рассматривалась как активное отношение человека к действительности, как молярная единица этой активности. Поэтому другой переформулировкой могло бы быть утверждение деятельностного понимания психики как принципа активности в психологии. Разработка категории активности в философии и психологии исторически была связана с другими направлениями, апеллировавшими к имманентной активности сознания. И потребовались специальные усилия отечественных психологов (сюда необходимо отнести концепцию Н. Бернштейна наряду с культурно-деятельностным подходом) по утверждению материалистического понимания принципа активности. Относительно других принципов, например системности, будет сказано в основном в общенаучном плане, поскольку многообразие использования понятия «система» в психологии таково, что в частнонаучном значении всегда необходимо упоминать конкретные психологические школы, совершенно по-разному представляющие реализацию этого принципа в научном исследовании. В книге «Методологические и теоретические проблемы психологии» Б. Ф. Ломов рассмотрел некоторые принципы системного подхода в психологии [Ломов, 1984]. О. К. Тихомиров показал, что не следует противопоставлять принципы деятельностного и системного подходов [Тихомиров, 1983]. Апелляция к этому принципу в частных теориях рассматривается также в других частях учебного пособия. Отметим также, что ряд категорий выступали на разных этапах отечественной психологии как принципообразующие. В первую очередь это категория личности. Так, разными авторами формулировался «личностный подход как принцип психологии». В настоящее время принцип личностного опосредствования неразрывно связан как с деятельностным подходом, что закреплено в названии книги А. Н. Леонтьева «Деятельность. Сознание. Личность», так и с принципом активности, развиваемым в психологии познания и психологии личности с разных теоретических позиций (А. Г. Ас.молов, Б. С. Братусь, Д. А. Леонтьев, В. А. Петровский, С. Д. Смирнов и др.).

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

Источник: https://bookucheba.com/obschaya-psihologiya-knigi/otkryitost-sistemyi-printsipov-33193.html

Открытые системы. Концепции

Открытость системы принципов

3 Принципы открытых систем

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

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

3.1 Эталонная модель среды открытых систем

Для структурирования среды открытых систем используется эталонная модель (Open System Environment Reference Model — OSE/RM), принятая в основополагающем документе ISO/IEC 14252 (Рисунок 3).

Она может модернизироваться в зависимости от класса системы.

Например, для телекоммуникационных систем хорошо известна 7-уровневая модель взаимосвязи открытых систем ISO/IEC 7498, которую можно представить как расширение модели OSE/RM с детализацией верхнего прикладного уровня.

Рисунок 3–Эталонная модель среды открытых систем

Как видно из рисунка 3., эталонная модель является трехмерной. По вертикали в ней можно выделить следующие компоненты: — приложение; — платформу; — внешнюю среду; — интерфейс приложения с платформой; — интерфейс платформы с внешней средой.

По горизонтали имеются следующие компоненты (функциональные области): — службы операционной системы; — службы интерфейса «человек-машина»; — служба управления данными; — служба обмена данными; — служба машинной графики; — служба сетевого обеспечения.

К третьему измерению относятся: — службы поддержки разработки программного обеспечения; — службы защиты информации; — интернационализация; — служба поддержки распределенной системы;

На базе эталонной модели строятся ее модификации в зависимости от архитектуры конкретной системы.

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

3.2 Классификация профилей

Существует несколько видов классификации профилей. В общем случае профили можно разделить на : — профили общего назначения;

— профили конкретного применения.

К профилям общего назначения относятся: — международные стандартизованные профили (International Standardized Profiles — IPS), признанные комитетом ISO/IEC.

ISP имеют в международном сообществе такой же статус, что и международные базовые стандарты и направлены на широкую область применения; — национальные профили, в соответствии с которыми должна строиться национальная Информационная Инфраструктура;

— корпоративные профили;

— технические профили, описывающие среду, такие как профили платформ, профили суперкомпьютерной среды, профили реального времени и др.

К профилям конкретного применения относятся : — отраслевые или ведомственные профили;

— профили предприятий, организаций, департаментов и подразделений.

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

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

3.3 Масштаб проблемы

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

Кроме того, принципы открытых систем распространяются на системы всех классов и назначений, в том числе на: — системы реального времени; — микропроцессорные встроенные системы;

— среду высокопроизводительных вычислений (Grid-структуру).

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

— разработчики стандартов.

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

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

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

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

Источник: http://www.cplire.ru/rus/casr/os/3_1/2003-1/p3.htm

Book for ucheba
Добавить комментарий