Software & Systems

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

ИНТЕРФЕЙС СЭВ — это система соглашений для обеспечения единообразной формы обмена информацией, передаваемой между человеком (Ч), программой (П) и машиной (М).

При этом система «человек-программа-машина», дополненная методологическим, организационным и информационным обеспечением, рассматривается как инструментально-технологическая среда функционирования ИНТЕРФЕЙСа, позволяющая с учетом Международной унификации работ в области программирования эффективно выполнить пять основных требований Международного конкурса и Исходной концепции проведения работ по проблеме «Развитие технологии разработки и промышленного производства программных средств вычислительной техники» Комплексной программы научно-технического прогресса стран — членов СЭВ (КП НТП СЭВ):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—  достижение эффективности обмена по данным и управлению между программами;

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

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

В качестве рекомендации предлагается использовать унифицированный способ взаимодействия программ, основанный на понятии виртуальных устройств. Данный подход хорошо согласуется с уже из-вестньЕми и эффективными принципами организации информационных обменов, принятыми в ОС ЮНИКС, и в то же время может рассматриваться как существенное развитие этих принципов в направлении универсализации. Виртуальные устройства могут обеспечивать:

—  автоматическую синхронизацию процессов на основе принципа рандеву;

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

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

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

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

К этому типу интерфейса предъявляются следующие основные требования:

—  доступность и простота освоении;

—  адекватность программной модели решении задачи модели пользователя;

—  надежность, защищенность от ошибок пользователя:

—  ведущая роль пользователя в диалоге;

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

—  получение справочной и обучающей информации.

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

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

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

В качестве основы для унификации можно рекомендовать опубликованные предложения Международной рабочей группы X/OPEN по созданию стандартизированной версии мобильной ОС ЮНИКС. Внедрение ее на всех основных типах ЭВМ, имеющихся в странах — членах СЭВ, может существенно облегчить решение проблемы интерфейса во всех аспектах.

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

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

Описание алгоритма и других понятий (данных и базиса) в контуре осуществляется в форме чертежа, состоящего из трех последовательно располагаемы* полей: спецификации, рабочего и абстракций. Структура алгоритма представляется в виде иерархической совокупности формализованных описаний (в том числе графических структур, располагаемых а рабочем поле) и определяет процесс декомпозиции обозначений к элементам базиса данного контура. Внешний вид используемых графических структур должен соответствовать ГОСТ 19.005-85 (для Р-схем) или ISO D1S 5807.2, ГОСТ 19.003. 19.004 (для блок-схем).

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

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

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

Первый контур проекта моделирует решаемую программным изделием задачу непосредственно в той предметной области, где это изделие должно функционировать. Самый последний контур характеризуется тем, что данные и базис представляются целиком в терминах выбранного для реализации языка программирования и конкретной инструментально-технической среды. С учетом предложений, содержащихся в представленных иа конкурс проектах, а также рекомендаций Международной конкурсной комиссии целесообразно в качестве одного из основных аспектов унификации ИНТЕРФЕЙСа рассматривать разработку и использование единой инструментально-технической среды, построенной на базе мобильной операционной системы, примером которой в настоящее время является система типа ЮНИКС.

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

Количество промежуточных контуров не регламентируется и выбирается в зависимости от специфики решаемых задач.

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

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

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

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

Для повышения мобильности и переносимости программных проектов рекомендуется выбирать контуры проектирования так, чтобы как можно меньшее число из них зависело от специфики конкретной ЭВМ или ОС,

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

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

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

Первым и основополагающим документом, инициирующим разработку, является ТЗ, оформляемое по существующим в настоящее время правилам в соответствии с ГОСТ 19.201-78 (СТ СЭВ 1627-79). Процедура согласования ТЗ в обязательном порядке должна включать в себя согласование чертежа верхнего контура, который по существу представляет собой точное и формализованное описание постановки задачи, решаемой программным изделием, а также отражать ее содержательной смысл. Чертежи остальньи контуров являются детальным описанием способа реализации задачи и отражают способ перехода от постановки ее в пользовательских терминах к представлению в виде текстов программ.

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

Для обеспечения соглашений, составляющих основу ИНТЕРФЕЙСа СЭВ, необходимо:

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

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

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

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

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

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

На 6-м Совещании главных конструкторов по проблеме КП НТО СЭВ (.Развитие технологии разработки и промышленного производства программных средств вычислительной техники» была согласована предложенная ВКС ИНТЕРФЕЙС Программа реализации ИНТЕРФЕЙС» СЭВ, которая положена в основу рабочего плана Договора о многостороннем научно-техническом сотрудничестве, подписанного 31 марта 1988 года в г. Киеве (СССР) и направленного на практическое развертывание работ по реализации ИНТЕРФЕЙСа СЭВ.