Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. Основы индустрии программных продуктов

Подождите немного. Документ загружается.

системы – это две взаимно дополняющие друг друга модели связи системы со

средой.

Модель окружения системы – это статическая модель, которая описывает

другие системы из пространства разрабатываемого ПО, а модель использования

системы – это динамическая модель, которая определяет взаимодействие системы

со своей средой.

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

объектов и реакцией системы после выполнения запроса. Когда взаимодействие

между объектами проектируемой системы и ее окружением определены, эти

данные используются для разработки архитектуры системы, которая может

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

Основные модели системной архитектуры такие:

– статическая модель описывает статическую структуру системы в терминах

классов объектов и взаимоотношений между ними (обобщения, расширения,

использования и др.);

– динамическая модель представляет динамическую структуру системы и

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

Результат проектирования – это ПС, в которой все необходимые объекты

определены статически или динамически с помощью классов и соответствующих

методов их реализации. Полученная объектно-ориентированная система

проверяется на показатели качества на основе результатов тестирования и сбора

данных об ошибках. Такую систему можно рассматривать как совокупность

автономных и независимых объектов. Изменение метода реализации объекта или

добавление новых функций не влияет на другие объекты системы. Объекты могут

быть повторно используемыми.

Компонентно-ориентированная разработка (Component-Based Development –

CBD). Это самостоятельная методология, появление которой наряду с модульной

технологией связано с такими тенденциями в программировании [132, 133]:

– переход к распределенным вычислениям и обработке информации, при

которых различные вычислительные процессы выполняются на разных

компьютерах и средах, для их разработки применяются разные ЯП и механизмы

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

– широкое распространение готовых компонентов разного назначения и их

применение в процессе разработки новых ПС при условии соответствия

определенным требованиям к структуре, интерфейсам и правилам интеграции;

– визуализация типовой структуры объектов и их интерфейсов, проверка

возможности их применения в целях генерации и связывания в единое целое.

Данные тенденции основываются на унификации и стандартизации

программных компонентов, их выбора и построения из них сложных программных

продуктов.

Особенность компонентной разработки – применение компонентов на всех

процессах ЖЦ. Иными словами, все элементы и объекты компонентной разработки

– это модули, компоненты, программы, данные и т.п., представляемые

программными компонентами.

Использование компонентов в программировании имеет ряд преимуществ:

– снижение затрат на разработку ПС;

– сокращение времени разработки отдельных компонентов;

– улучшение показателей качества и надежности программ из компонентов;

– упрощение процедур и снижение затрат на поддержку и сопровождение

программных продуктов;

– создание определенной инфраструктуры в разработке ПС, основанной на

унификации и стандартизации компонентов в целях практического применения;

– создание рыночных компонентов за счет их стандартизации и ориентации

на повторное использование.

С формальной точки зрения программный компонент (component) – это

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

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

порядок обращения к его операциям.

В компонентной CBD разработке обеспечен механизм взаимодействия

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

другими компонентами, входящими в контейнер или каркас.

Интеграция (сборка) компонентов и их развертывание с среде не зависят от ЖЦ

разработки компонентов. Замена любого компонента новым компонентом не

должна приводить к перекомпиляции или перенастройке связей в ПС.

Интерфейс компонента может быть определен в виде спецификации точек

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

серверной среде. Так как интерфейс не предоставляет реализацию операций, то

можно изменять реализацию без изменения интерфейса и таким образом улучшать

исполнительные или функциональные свойства компонента без перестройки ПС в

целом, а также прибавлять новые интерфейсы (и реализацию) без изменения

существующей реализации ПС.

Семантика интерфейса может быть представлена с помощью контрактов,

которые определяют внешние ограничения и поддерживают компонент-инвариант.

Кроме того, для каждой операции компонента контракт может определять

ограничения, которые должны быть выполнены клиентом перед вызовом

операции (предусловие), и условия, которое компонент выполнит после

завершения операции (постусловие). Предусловие и постусловие определяют

спецификацию поведения компонента и зависят от состояния, которое

поддерживает компонент, а также интерфейсов, связанных с набором инвариантов.

Контракты и интерфейс связаны между собою, но содержат разные сущности.

Интерфейс представляет собою коллекцию операций или функциональных свойств

спецификации сервисов, которые поддерживает компонент. Контракт задает

описание поведения компонента, нацеленное на взаимодействие с другими

компонентами, и отражает семантику функциональных свойств компонента.

Таким образом, спецификация семантики компонента определяет его интерфейс

и ограничения. Каждый интерфейс состоит из набора операций (сервисов, которые

он предлагает или требует). Поведение компонента определяют также и

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

другими компонентами или средой, а также механизмы защиты и безопасности

выполнения.

Компонент может использоваться многократно, как КПИ, к которым относятся

формализованные артефакты деятельности разработчиков ПС при реализации

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

Артефактом может быть реальная порция информации, создаваемая при

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

назначения, в частности промежуточные продукты процесса разработки ПС:

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

системы и т.п. Ими также могут быть: спецификации, модели, архитектура, каркас

(framework) и т.п., а также готовые ПС.

Для объединения разных видов компонентов применяются шаблоны

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

спецификации компонента могут прибавляться новые шаблоны интеграции или

изменяться старые. В некоторых классах КПИ параметры интеграции в новую

среду включаются в интерфейс компонента, что сужает круг задач компонента для

его повторного использования. Интеграция компонентов в архитектуру целевой ПС

в CBSE состоит из нескольких типичных методов объединения, среди которых

наибольшее распространение получили паттерны, каркасы и контейнеры [8, 26].

Паттерн – абстракция, которая содержит описание взаимодействий

совокупности объектов, ролей участников и их ответственности. Он практически

определяет повторяемое решение в проблеме объединения КПИ в программную

структуру. Для каждого объединения определяется взаимодействие объектов при

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

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

по трем уровням абстракции:

– высокий уровень связан с глобальными свойствами и архитектурой системы,

скомпонованной из компонентов в виде архитектурного паттерна, который

охватывает общую структуру и организацию ПС в виде набора подсистем с

определением их ролей и отношений между ними;

– средний уровень абстракции уточняет структуру, поведение отдельных

подсистем и компонентов ПС, а также взаимодействие между ними;

– нижний уровень представляет собой абстракцию определенного вида

(например, объединение компонентов по аналогии), которая зависит от выбранной

парадигмы и ЯП.

Кроме паттернов, в сборочной стратегии широко используется каркас –

типовая повторно возникающая ситуация на уровне модели ПС, которая

определяет структуру проекта и имеет недоопределенные элементы, обозначенные

пустыми слотами для расположения в них новых определенных компонентов. В

этом смысле каркас становится КПИ со свойством экземпляризации и

представленный высокоуровневой абстракциею проекта ПС, в которой отделены

функции компонентов от задач управления ими. В бизнес-функциях каркас задает

надежное управление ими. Каркас объединяет множество взаимодействующих

между собою объектов в некоторую интегрированную среду, предназначенную для

решения заданной конечной цели типа “белый” или “черный ящик”.

Каркас типа “белый ящик” включает в себя абстрактные классы для

представления цели объекта и его интерфейсов. При реализации эти классы

наследуются в конкретные классы с указанием соответствующих методов

реализации, как это принято в OOП. Каркас типа «черный ящик» характеризуется

тем, что в видимой, информационной, части имеется описание точек входа и

выхода. Через эти точки можно входить и выходить из компонента не обязательно

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

отдельно построенных программных частей. Физически он реализуется с помощью

одного или больше паттернов, которые в свою очередь выступают в роли

инструкций по реализации проектных решений.

Заполненный компонентами каркас становится контейнером и сам может быть

компонентом ПС, обеспечивает инкапсуляцию компонентов и доступ к

компонентам через каркас, который определяет возможные варианты наполнения

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

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

контракты выражают общие принципы и определяют спецификацию отношений

между конкретными компонентами, которые могут отличаться от спецификации

компонентов как частей композиции.

Создание компонентной системы начинается с построения компонентной

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

компонентов, разные типы паттернов, связи между ними, способы взаимодействия

(интерфейсы) и операции развертки ПС в среде функционирования.

Схема модели компонентной системы представлена на рис. 1.3 [6].

Data

Компонентный каркас

Компонентная

модель

Интерфейс,

специфичный

для компонентного

типа

Реализация интерфейса и

спецификация контракта

Независимое

развертывание

Реализация

компонента

Компонентные

типы и контракты

Координационные

сервисы (транзакции,

....)

Рис. 1.3. Модель компонентной системы

Здесь: 1 – компонент, имеющий функциональность; 2 – один или более

интерфейсов, описанных внутри контракта; 3 – контрактное взаимодействие

компонентов друг с другом; 4 – развертывание компонентов во время выполнения

в заданной среде; 5 – разные типы компонентов системы; 6 – компонентная

модель из множества типов компонентов, их интерфейсов; 7 – спецификаций

шаблонов взаимодействия этих компонентов; 8 – компонентный каркас

обеспечивает выполнение компонентной модели, множество сервисов.

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

помощью любой методологии разработки ПС с учетом требований и условий их

применения при построении из них новых систем.

Порождающее программирование. Данное программирование ориентиро-

вано на создание семейств программных систем путем трансформации описания

членов семейства спецификациями высокого уровня типа языка DSL (Domain

Specific Language) с отображением специфики предметной области в терминах

соответствующей базовой терминологии. Результат последовательной

трансформации генерируется и собирается в выходной код [142, 204].

Его основа – общая порождающая доменная модель GDM (Generative Domain

Model) семейства систем. В ней содержатся:

– описание членов семейства в языках (DSL, RSL, CSP, Clear и др.);

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

– знания о конфигурации (Configuration knowledge) в виде правил

конструирования, вариантов оптимизации, сочетания и зависимости между

членами семейства и др.;

– модель общих, изменяемых характеристик членов семейства и их

взаимодействия;

– механизмы обеспечения изменчивости, синхронизации и безопасности как

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

Знания о конфигурации упакованы в виде абстракций общего и специального

назначения и хранятся в активной библиотеке многократного использования. Там

же хранятся и производственные знания о средствах тестирования, измерения,

планирования и оценки отдельных компонентов и членов семейства. В наборе

этих знаний определяются задачи ПрО и подходы к ее описанию и реализации.

Каждая модель члена семейства представляется в некотором конкретном

синтаксисе, например DSL, XML, UML и др., которая трансформируется к

выходному целевому представлению по следующей схеме (рис.1.4) [185]:

– преобразование исходной модели к промежуточному (объектному) виду;

– преобразование исходной модели в выходную (целевую);

– преобразование целевой модели в конкретный код.

Исходная модель

(Конкретный синтаксис)

Парсер конкретного синтаксиса

Дерево абстрактного синтаксиса

исходной модели

Пребразователь

Целевая модель

(Конкретный синтаксис)

Преобразователь в конкретный

синтаксис

Дерево абстрактного синтаксиса

целевой модели

Рис. 1.4. Схема преобразования модели системы

Генерация выходного кода осуществляется такими способами:

– итеративным, при котором перечисляются все узлы исходной модели и они

преобразуются в соответствующее представление целевой модели;

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

часть заданного шаблона;

– поисковым, состоящим в нахождении места в исходной модели и ее

преобразования.

Шаблон – это некоторое регулярное выражение концептуальной модели

системы. Для его описания создается специальный язык шаблона, основанный на

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

сложных совпадений в исходной модели.

Цель генерации кода – обеспечение возможности его настройки на целевую

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

этап – обеспечивает чтение конфигурации, по которой создается соответствующий

генератор текущего преобразования, второй – использует созданный генератор для

выполнения необходимых преобразований модели.

Генерация исполняемого кода осуществляется посредством:

– использования шаблонов проектирования;

– сохранения сгенерированного и исправленного вручную (рукописного кода) в

отдельных файлах;

– дизайна архитектуры системы, в которой определены сгенерированные ар-

тефакты;

– использования гибких методик склеивания сгенерированных и рукописных

частей кода.

Интеграция (сборка) сгенерированного кода и рукописного состоит в

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

вставки.

Моделирование в UML. Основу составляет стандартный язык UML lkz

моделирования программ. Язык предназначен для визуализации, спецификации,

конструирования и документирования артефактов ПС. Описание программ в этом

языке осушествляется с помощью стандартных диаграмм, словаря и механизмов

расширения.

Словарь UML содержит три категории элементов: предметы (things), связи

(relationships) и диаграммы (diagrams). Предметы имеют такие разновидности:

структурные ( use case, class, active class, interface, component, collobaration, node);

поведенческие ( interaction, state machine); групповые (package, model, subsystem,

framework); аннотационные (note). Связи различаются как зависимые

(dependency), ассоциативные (association) и те, которые обеспечивают обобщение

(generalization).

В состав диаграмм входят: class, use case, object, sequence, component,

colloboration, statechart, activity, deployment. Они используются для графического

изображения соответствующих элементов ПС. Графические нотации – это

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

механизмов расширения языка UML. Механизмы расширения предназначены для

уточнения синтаксиса и семантики языка и включаютв себя: стереотипы и

констрейны. Метод UML включает в себя:

– формальную метамодель для описания синтаксиса и семантики, а также для

унификации разных аспектов проектирования объектных приложений;

– совокупный набор нотаций графического представления объектов

проектирования;

– множество разнообразных идиом для отображения конкретной модели ПС.

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

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

выполнении таких действий:

– создание среды разработки ПС в UML с помощью сценариев и шаблонов

проектирования;

– проектирование модели интеграции ПС и системы образцов средствами

UML;

– выбор метрик и методов оценивания показателей качества объектов в

проектируемой системе;

– модификация моделей с учетом функциональных и нефункциональных

требований к системе;

– изменение системы путем повторного использования КПИ и методик

преобразования передаваемых данных;

– проверка поведения системы осуществляется после выполнения разного рода

преобразований;

– обеспечение целостности модели путем внесения изменений в модель.

Иными словами, модели в UML, а также модели, спроектированные на языке

SDL, трансформируются специальными утилитами для исполняемого кода.

Инсерционное программирование. Термин «инсерционное» происходит от

английского insert – вставить, поместить, погрузить. Имеется в виду вставка в

программу или среду объекта, называемого агентом. Агент обладает поведением и

погружается в информационную среду, которая меняет ее поведение относительно

других агентов этой среды [147, 148]. Описание инсерционной программы состоит

в определении функции погружения, начального состояния среды и агента,

погруженного в эту среду. Поведение среды меняется в результате воздействия на

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

Основа инсерционного программирования – модель поведения агентов в

средах, базирующихся на понятиях транзиционной системы, теории

взаимодействующих процессов и отношений бисимуляционной эквивалентности

агентов относительно среды. В отличие от агентного программирования,

инсерционное программирование ориентируется исключительно на поведение

агентов.

Представление состояний агентов и сред как структур данных, а также

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

программирования АPS [147]. Инсерционная программа описывается на языке AL

и имеет три уровня:

– описание поведения инициализированной многоуровневой среды с

расположенными в ней агентами;

– задание функции, определяющей отношения переходов агентов;

– описание ядра функции погружения или развертывания агентной программы.

Инсерционными программами моделируются реальные системы с

недетерминированным поведением агентов и сред. Реализация систем

инсерционного программирования требует применения программ-симуляторов, а не

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

Таким образом, в современных средах программирования решается задача

взаимодействия объектов через контракты в компонентном программировании,

через шаблоны проектирования в порождающем программировании или через

механизмы погружения в инсерционном программировании. Эта особенность

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

1.2. ОСНОВНЫЕ ЭЛЕМЕНТЫ И ЗАДАЧИ СБОРОЧНОГО

ПРОГРАММИРОВАНИЯ

Процесс сборки любых изделий характеризуется: комплектующими деталями и

узлами, схемой сборки (взаимосвязями отдельных компонентов и правилами

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

понятия с точки зрения метода сборочного программирования. При этом будем

предполагать, что используются только готовые программные продукты [125, 133,

140].

Комплектующие элементы. Комплектующими в методе сборочного програм-

мирования являются простые программные элементы (модули, объекты,

компоненты, сервисы и др. (табл.1.3).

Т а б л и ц а 1.3

Элемент

сборки

Описание

элемента

Схема

взаимодействия

Представление,

хранение

Результат

композиции

Процедура,

подпрограмма,

функция

Идентификатор Непосредственное

обращение,

оператор вызова

Библиотеки

подпрограмм

и функций

Программа

Модуль Паспорт модуля

связи

Вызов модулей,

интеграция

модулей

Банк,

библиотеки

модулей

Программа

с модульной

структурой

Объект Описание

класса

Создание

экземпляров

классов,

вызов методов

Библиотеки классов Объектно-

ориентирован-

ная

программа

Компонент Описание

логики (бизнес),

интерфейсов

(APL, IDL),

схемы

развертки

Удаленный вызов в

компонентных

моделях (COM,

CORBA, OSF, …)

Репозитарий

компонентов,

серверы и

контейнеры

компонентов

Распределен-

ное

компонентно-

ориентирован-

ное

приложение

Сервис Описание

бизнес-логики

и интерфейсов

сервиса (XML,

WSDL, …)

Удаленный вызов

(RPS, HTTP,

SOAR, …)

Индексация и

каталогизация

сервисов

(XML, UDDI, …)

Распределен-

ное сервисно-

ориентирован-

ное

приложение

Из них собираются программные объекты различной сложности и степени

готовности: программы, комплексы, пакеты прикладных программ, программные

системы и т.д.

Модуль – независимая функциональная часть программы, к которой можно

обращаться как к самостоятельной единице через внешний интерфейс.

Объект – базовое понятие в объектно-ориентированном программировании,

которое обладает свойствами наследования, инкапсуляции и полиморфизма.

Объединяет данные и операции (методы). Объекты взаимодействуют между собой

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

являясь в нем экземплярами класса. В языке С++ имеется несколько библиотек

классов общего применения.

Компонент – программный объект, который реализует некоторую

функциональность и является базовым понятием компонентного программирования

и компонентно-ориентированной разработки (component-based development – CBD).

Основная форма представления компонента – каркас и контейнер. Каркас –

высокоуровневая абстракция, в которой функции отделены от задач управления.

Контейнер – оболочка, внутри которой реализованы функции в виде

экземпляров компонентов, обеспечивает взаимодействие с сервером через

стандартные интерфейсы (function, home interface). Экземпляры обращаются друг к

другу через системные сервисы данного контейнера или другого.

Сервис – это программный ресурс, который реализует некоторую функцию, в

том числе и бизнес функцию. Содержит независимый интерфейс с другими

сервисами и ресурсами. Веб-сервис обеспечивает реализацию задач интеграции

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

взаимодействующих сервисов, веб-сервиса и их интерфейсов образует сервисно-

ориентированную архитектуру (service oriented architecture), доступ к которым

происходит через веб-языки и протоколы.

Результатом сборки может быть любой программный объект, за исключением

элементарного элемента – модуля, компонента, сервиса и др. Однако для

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

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

метода сборочного программирования.

Для технологичности сборки все объекты должны иметь паспорта, содержащие

данные, необходимые для информационного сопряжения и организации совместного

функционирования в рамках программного объекта более сложной структуры.

Важное условие сборки состоит в наличии большого числа разнообразных

комплектующих, т.е. ПС, обеспечивающих решение широкого спектра задач из

различных предметных областей.

Схема сборки. Под схемой сборки программных объектов понимается схема их

взаимодействия, определяющаяся непосредственными обращениями к компонентам

(типа оператора CALL) или последовательностью их выполнения. При этом

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

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

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

обмен информацией, условия совместного функционирования и т. д.

Операции сборки выполняются согласно паспортам объектов и правилам

сопряжения. Информация в паспортах должна быть систематизирована и выделена в

такие отдельные группы: передаваемые данные и их типы, вызываемые объекты,

совместно используемые файлы и т.д. Правила сопряжения определяют

совместимость объединяемых объектов и содержат описание функций, необходимых

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

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

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

практически неосуществим, что связано с недостаточно формальным определением

программных объектов и их интерфейсов. Ручной способ нецелесообразен, так как

сборка готовых компонентов представляет собой большой объем действий, носящих

скорее рутинный, чем творческий характер. Наиболее приемлемый –

автоматизированный способ сборки в среде системы, которая по заданным спе-

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

правил сопряжения под управлением человека. Средства, поддерживающие данный

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

программирования. К ним относятся средства комплексирования (объединения

компонентов в более сложный объект); средства интерфейсов (реализация

сопряжения объектов согласно их паспортам и стандартным правилам связи);

средства описания и использования моделей сборочного программирования

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

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

и условия его применения:

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

процесса решения класса задач из определенной предметной области;

– проектирование структуры (моделей) создаваемого объекта, элементами

которого являются готовые программные элементы, определенные на множестве

данных выбранной предметной области;

– сборка согласно моделям программного продукта, реализующего функции,

соответствующие целям и задачам автоматизируемой предметной области.

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

в себя:

– наличие большого числа разнообразных программных продуктов, как объектов

сборки;

– паспортизация программных объектов сборки;

– наличие достаточно полного набора стандартных правил сопряжения и

алгоритмов их реализации и средств автоматизации процесса сборки;

– создание технологий применения разработанных объектов для использования в

более сложных программных продуктах.

Последнее условие означает, что должны существовать определенные формы

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

проектирования и разработки программных систем.

Основной вопрос сборки – это реализация интерфейсов между отдельными

модулями и/или компонентами, обеспечивающими их «стыковку» или связь.

1.3. ОПРЕДЕЛЕНИЕ ИНТЕРФЕЙСА ПРОГРАММНЫХ ОБЪЕКТОВ

Общее определение. Интерфейс – это связь двух отдельных сущностей. Виды

интерфейсов: программные, аппаратные, языковые, пользовательские, цифровые и

т.п. Программный (API) и/или аппаратный интерфейс (port) – это способы

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

периферийным оборудованием. Языковый интерфейс определяет константы,

переменные, параметры и структуры данных программы в некотором ЯП, которые

передаются другим программам или модулям [116, 127, 132].

Иными словами, термин интерфейс в программировании олицетворяет собой

набор операций с параметрами, обеспечивающими определение видов услуг и

способов их передачи от одного программного объекта другому. На начальном

процессе программирования в роли интерфейса выступали операторы обращения к

процедурам и функциям программы с соответствующими формальными

параметрами. Программы, процедуры и функции записывались в ЯП, а операторы

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