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

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

Объектом называется понятие, абстракция или любая другая вещь с четко очерченными границами, имеющая смысл в кон­тексте рассматриваемой прикладной проблемы. Примеры объек­тов: форточка, центральный банк, школа № 42, Петр Сидоров, дело № 7461, сберкнижка и т.д.

Введение объектов преследует две цели:

Понимание прикладной задачи (проблемы);

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

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

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

Все объекты одного и того же класса характеризуются одина­ковыми наборами свойств (атрибутов). Однако объединение объектов в классы определяется не наборами свойств, а семан­тикой. Так, например, объекты «Конюшня» и «Лошадь» могут иметь одинаковые атрибуты: «Цена» и «Возраст». При этом они могут относиться к одному классу, если рассматриваются в задаче просто как товар, либо к разным классам, что более естественно.

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

Пример класса СЧЕТ

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

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

Над объектом можно выполнить некоторые операции. Напри­мер, «Проверить», «Снять», «Поместить» для объектов класса «Счет» или «Открыть», «Читать», «Закрыть» для объектов класса «Файл» и т. п.

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

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

Каждой операции соответствует метод - реализация этой операции для объектов данного класса. Таким образом, операция - это спецификация метода, метод - реализация операции. Например, в классе файл может быть определена операция «Печать» (print ). Эта операция может быть реализована разными методами: (а) «Печать двоичного файла», (б) «Печать текстового файла» и др. Логически эти методы выполняют одну и ту же операцию, хотя реализуются они разными фрагментами кода.

Каждая операция всегда имеет один неявный аргумент - объект, к которому она применяется. Кроме того, операция может иметь и другие аргументы - свойства (параметры). Эти допол­нительные аргументы характеризуют операцию, и никак не связаны с выбором метода.

Метод связан только с классом и объектом. (Некоторые объектно-ориентированные языки, например C++, допускают одну и ту же операцию с разным числом аргументов, причем, используя то или иное число аргументов, мы практически выбираем один из методов, связанных с такой операцией. На этапе предварительного проектирования системы удобнее считать эти операции различными, давая им разные имена, чтобы не услож­нять проектирование).

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

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

Между объектами можно устанавливать зависимости по дан­ным. Эти зависимости выражают связи или отношения между классами указанных объектов.

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

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

Зависимости, как и классы, могут иметь свои свойства. Например, при организации доступа пользователя к файлу «Разрешение на доступ» является свойством зависимости «Дос­тупен». Отметим, что разрешение на доступ связано как с пользо­вателем, так и с файлом, и не может быть атрибутом ни поль­зователя, ни файла в отдельности.

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

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

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

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

Целесообразно придерживаться следующих правил наследова­ния:

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

Все операции, изменяющие значения свойств, должны наследоваться во всех их расширениях;

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

Унаследованные операции можно уточнять, добавляя дополнительные действия.

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

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

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

» я рассказал о том, что делю дизайн-документ на Объектную Модель и Функциональную Спецификацию . Я получил довольно много вопросов, в том числе и вопрос о том, зачем я делаю такое деление, а также в чем разница между ОМ и Функциональной Спецификацией , почему не совместить эти две части? Я начал было отвечать, но в процессе понял, что, по сути, я начал писать отдельную статью. А раз так, то лучше я напишу ее здесь.

Зачем нужна Объектная Модель (ОМ)

Кратко — чтобы в проекте не было вот этого:

Не поймите превратно. Я люблю пасту, но только в качестве еды.

Обычно про пасту любят писать и говорить программисты. Но и в дизайне тоже она может быть, и еще как. С пастообразным дизайн-документом работать крайне трудно и даже поиск по ключевым словам не всегда спасает. И даже перекрестные ссылки (в тех редких случаях, когда они расставлены) не всегда помогают, а иногда и запутывают.

Поэтому, Объектная Модель выполняет две важные функции :

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

Теперь подробнее о каждом из этих пунктов.

Справочник

Справочник позволяет отделить сущность и ее параметры от ее функционала. Это дает возможность быстро, одним взглядом понять как и из чего она состоит, как хранится в базе, как работает в логике игры и так далее. Такое простое восприятие сущностей позволяет программистам легко понять будущую архитектуру проекта и спроектировать то, как он будет создаваться еще до того, как они начнут воплощать его в коде. Такое четкое понимание может спасти от переработок в будущем, когда спустя год-полтора вдруг оказывается, что все работает не так, не хватает гибкости, это не предусмотрено а то вообще потребует полного рефакторинга 75% кода. Конечно, справочник ОМ — это не волшебная пилюля, но как минимизация таких рисков работает отлично при условии, что она грамотно составлена).

Кроме того, справочник позволяет сортировать игровые сущности по их типам, в то время как в Функциональной Спецификации они сортируются или описываются по функциональности. Например, у нас есть такая иерархия в ОМ:

• Игорвая сущность
  • Предмет
    • Оружие
      • Меч
    • Расходники
      • Бутылка

Но при описании геймплея у нас может быть совсем иная структура. Например:

• Боевая система
  • Начисление урона
  • Работа брони
  • Бутылки во время боя
  • Стрелковое оружие
  • Холодное оружие
• Крафт
  • Крафт бутылки
  • Крафт оружия
    • Стрелкового
    • Холодного

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

И обратный пример, если у нас весь диздок отсортирован в по иерархической системе сущностей: при описании боевой системы, она будет размазана по всему диздоку.

Наследование (pro feature)

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

• Игровая сущность (GameEntity)
  • Предмет (InventoryItem)
    • Одежда (Equipment)
      • Армор (Armor)

Ниже — как они выглядят в документации (естественно, в сокращенном виде, по 3-4 строки из ОМ):

Члены типа GameEntity (это верхняя, самая главная сущность в архитектуре проекта и то, как она хранится в БД)

Члены типа InventoryItem

Члены типа Equipment

Члены типа Armor

Как видно, Armor — это последняя сущность в приведенном примере, и имеет всего три параметра: ArmorType, DamageReduxF, DamageReduxP . Однако он наследует из предыдущей сущности: DurabilityMax, DurabilityCurrent, Tiemype . В свою очередь, та сущность наследует: Volume, PlayMoneyPrice, realMoneyPrice, и так далее до самого верха.

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

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

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

Объектная модель (Главное меню → Отчёты → Объектная модель ) служит для просмотра описания справочников. Для каждого справочника отображается информация о его назначении, составе его параметров и их назначении. Объектная модель необходима при работе с отчетами, так как из нее может быть получена информация, необходимая для формирования привязок к данным.

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

В Объектной модели представлены три раздела: классы, перечисления и элементы списков.

Классы

Классы - раздел, в котором представлены описания справочников, хранимых в базе данных.

Объект справочника может являться значением объектного параметра другого объекта. Например, параметр "Тип документа" в справочнике "Бумажные документы" является объектным параметром, значением которого является один из объектов справочника "Типы документа".

Перечисления

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

Элементы списков

Элементы списков - это справочники для хранения экземпляров (строк) параметров типа "Список". Список используется для реализации отношения "один-ко-многим". Список представляет собой набор объектов одного и того же класса (класса элементов списка). Например, в классе "Процессы" используется параметр-список "Нормативно-справочные документы". Строки этого списка хранятся в классе элементов списков "БизнесМодель.СписокНСДПроцессов", каждая строка связана с конкретным процессом отношением "один-ко-многим".

Также элементы списков используются для хранения параметров типа "Структура". В этом случае реализуется отношение "один-к-одному". Элемент структуры содержит свой набор параметров. Например, все "Объекты деятельности" имеют параметр-структуру "Параметры ФСА". Элементы структуры хранятся в виде строк класса элементов списков "БизнесМодель.СтоимостьОбъектовДеятельности", каждая строка связана с конкретным объектом деятельности отношением "один-к-одному".

Схема того, как в интерфейсе Business Studio представлены справочники, их параметры и объекты справочников, приведена на Рисунке 1.

Рисунок 1. Справочники, их параметры и объекты справочников в интерфейсе Business Studio

Работа с объектной моделью. Окно объектной модели

В окне справочника слева показывается дерево системных классов, справа - описание параметров класса.

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

На панели инструментов Объектной модели также присутствуют навигационные кнопки:

На Рис. 2 показана Объектная модель , в которой открыто описание справочника "Процессы".

Рисунок 2. Описание справочника "Процессы" в Объектной модели

Для узлов в дереве также действует своё контекстное меню:

Рядом с названием класса в дереве показана иконка:

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

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

Свойство	Назначение
№	Номер параметра.
Название	Пользовательское название параметра. Отображается в Окнах свойств и заголовках списков.
Системное название	Системное название параметра.
Тип	Тип параметра: - простой параметр - "Строка", "Логический", "Целый", "Вещественный", "ДатаВремя", "Текст"; - "Объект"; - "Список"; - "Структура"; - "Перечисление".
Хранимый	Логика, показывающая, хранится параметр физически в базе данных или рассчитывается на основе имеющейся информации. Например, в справочнике "Физические лица" параметры "Фамилия", "Имя", "Отчество" являются хранимыми, они задаются пользователем, а параметр "ФИО" является нехранимым, рассчитываемым на основе этих параметров. Хранимые параметры рассчитываются в момент обращения к ним, например, при отображении в Окнах свойств и Окнах списков , при выполнении отчетов.

Таблица 1. Свойства параметров

Для списка параметров класса действует контекстное меню.

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

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

В объектно-реляционных СУБД за основу берётся реляционная модель, которую расширяют системой объектных типов данных, конструируемых пользователем. Язык запросов представляет собой расширение SQL.

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

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

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

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

Рассмотрим язык UML (Unified Modeling Language) обладающий более широкими возможностями. Отметим, что термин "унифицированный" не означает претензий на универсальность. Просто UML был создан путем объединения как минимум трех языков концептуального моделирования.

Для построения реляционных, объектных и объектно-реляционных баз данных из определённых в UML-2 тринадцати видов диаграмм нам достаточно диаграмм классов. Это структурные диаграммы, определяющие наборы классов, их атрибуты, операторы и связи между ними.

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

Возможно четыре варианта обозначения класса, приведенные на рисунке 10.1.

Рис. 10.1.

Рис. 10.2.

Определение . Связи-ассоциации классифицируются по числу соединяемых классов. Обозначаются они сплошными линиями. Выделяют бинарные связи (соединяют два класса), тернарные (три класса) и N-арные. Для бинарных связей может быть указан порядок соединяемых классов. Так, в примере на рисунке 10.3 связь читается так: "Мама моет раму".

Рис. 10.3.

Концы связи-ассоциации можно помечать именами ролей, для которых могут быть указаны кратности связи. Назначения ролей такие же, как в ER-диаграммах (см. раздел 2.2.6). Кратности роли указывают, сколько объектов с этой ролью могут участвовать в ассоциации. Так, кратность 1 указывает на обязательность связи, кратность 0..1 означает её необязательность. Задание диапазона 1..* говорит о том, что все объекты должны участвовать в каком-нибудь экземпляре ассоциации и что число объектов, участвующих в одном экземпляре ассоциации не ограничено.

В примере на рисунке 10.4 в показано, что работник обязательно работает равно в одном отделе, а отдел может существовать вообще без работников, но может иметь до 15 человек.

Рис. 10.4.

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

Определение . Связью-обобщением называется связь между более общим классом, называемым родителем или предком, и более специализированным классом, называемым потомком или подклассом.

Резюме

Недостатки модели TCP/IP

Несмотря на огромную популярность, у модели TCP/IP и ее протоколов имеется ряд недостатков:

· отсутствие разграничений концептуальных понятий интерфейса, протокола и уровневого сервиса, что достаточно четко сделано в модели ISO/OSI. Вследствие этого модель TCP/IP не может применяться при разработке новых сетей;

· с помощью модели TCP/IP нельзя описать никакой другой стек протоколов, кроме TCP/IP;

· в модели не различаются физический и канальный уровни, в то время как они абсолютно разные и в корректной модели это должно учитываться;

· наиболее тщательно продуманы и проработаны протоколы IP и TCP. Многие из других протоколов стека разрабатывались студентами (студентам к размышлению!) и свободно распространялись, вследствие чего широко укоренились в практике и теперь их трудно заменить на что-либо новое, предлагаемое по коммерческой схеме.

В качестве резюме отметим, что модель ISO/OSI является полезной для теоретических исследований и разработок новых сетей, хотя протоколы OSI не получили широкого распространения. Для TCP/IP можно сделать обратное утверждение: стек не может рассматриваться в качестве полноценной модели, тогда как сами протоколы хорошо апробированы и чрезвычайно популярны.

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

Во-первых, на транспортном и канальном уровнях реализуются два независимых механизма переноса. Такое разбиение задачи транспортировки информации было в свое время продиктовано необходимостью объединения множества сетей, использующих разные технологии доступа к каналу связи. Однако, наличие двух несогласованных механизмов передачи создает проблему обеспечения качества обслуживания при переносе информации. Добиться согласованного поведения транспортного и канального уровней (через сетевой уровень) невозможно, исходя их принципа автономности уровней в модели ISO/OSI. Однако современные концепции развития сетей на мультисервисной основе (в частности концепция NGN) предусматривают стратегии согласованного поведения транспортного и канального уровней в обход сетевого уровня, что формально нарушает принцип автономности и выходит за рамки эталонной модели.

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

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

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

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

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

Иерархия программного обеспечения (ПО) может быть представлена в следующем виде:

· прикладное ПО;

· промежуточное ПО;

· базовое ПО.

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

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

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

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

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

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

К базовому ПО относятся и объекты обработки и хранения данных, реализуемые в таких программных комплексах, как СУБД (системы управления базами данных), базовое ПО сервера обработки транзакций и др.

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

Различают следующие типы объектных интерфейсов (программных интерфейсов):

· прикладной протокол (Application Protocol, АР) – логический интерфейс между прикладными объектами;

· интерфейс прикладных программ (Application Program Interface, API) – логический интерфейс между прикладными объектами и объектами промежуточного ПО, которые поддерживают прикладные объекты;

· протокол промежуточного ПО (Managing Protocol, МР) – логический интерфейс между объектами промежуточного ПО;

· интерфейс базовых программ (Base Program Interface, ВРІ) – логический интерфейс между объектами промежуточного и базового ПО, которые поддерживают объекты промежуточного ПО;

· интерфейс человек-компьютер (User-Computer Interface, UCI) – логический интерфейс между пользователем и, главным образом, объектами базового ПО, однако он может включать в себя также логический интерфейс с объектами промежуточного ПО и даже объектами приложений.

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