На правах рекламы:
ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Авторитетность издания

ВАК - К1
RSCI, ядро РИНЦ

Добавить в закладки

Следующий номер на сайте

2
Ожидается:
16 Июня 2024

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

Статья опубликована в выпуске журнала № 1 за 1989 год.
Аннотация:
Abstract:
Автор: Халабузарь Г.И. () -
Ключевое слово:
Ключевое слово:
Количество просмотров: 16465
Версия для печати

Размер шрифта:       Шрифт:

Основнос отличие персональных ЭВМ (ПЭВМ) от ЭВМ общего назначении состоит в их ориентации на широкий спектр категорий пользователей.

Весьма существенным фактором, связанным с появлением персональных ЭВМ, следует считать и резкое возрастание масштабов тиражирования программного обеспечения (ПО). Если для 3tiM общего назначения тираж измерялся от сотен до нескольких тысяч экземпляров, то на ПЭВМ ПО, особенно прикладное, — сотнями тысяч.

8 связи с этим существенны и различия в требованиях к качеству ПО ПЭВМ по отношению к ПО ЭВМ общего назначения (тиражирование ошибок в широком масштабе затрудняет сопровождение).

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

Общая структура ПО

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

Предлагается следующая классификация ПО ПЭВМ и пользователей (рис. 1).

ИНСТРУМЕНТАЛЬНОЕ ПО представляет собой набор инструментальных средств общего назначения (инструментарий 1-го уровни) и обеспечивает возможность эффективного создания и сопровождения проблемно- и профессионально-ориентированного ПО. Порядок и правила использования инструментальных средств регламентируются ОБЕСПЕЧИВАЮЩЕЙ ТЕХНОЛОГИЕЙ (ее название вытекает непосредственно ич назначения — обеспечивать создание ПО и соответствующих технологий для более низких уровней иерархии в предложенной классификации). Разработчиком (равно как и пользователем) инструментального ПО является ПРОГРАММИСТ-ПРОФЕССИОНАЛ. Основным пользователем инструментального ПО и обеспечивающей технологии является ПРОГРАММИСТ-ПРИ КЛАД-НИК (обладает довольно высокой квалификацией как разработчик ПО, а также необходимыми и достаточными познаниями в определенной проблемной области).

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

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

инструментальное ПО (инструментарий 2-го уровня) для создания путем генерации или настройки профессионально-ориентированного ПО

Проблемно-ориентированное ПО разрабатывается программистом-прикладником, который одновременно может являться и пользователем этого класса ПО (когда оно используется как инструментарий 2-го уровня). Средства, входящие в состав проблемно-ориентированного ПО, поддерживают ТЕХНОЛОГИЮ РЕШЕНИЯ ЗАДАЧ (ТРЗ) в конкретной проблемной области; с другой стороны, ТРЗ регламентирует использование инструментальных средств 2-го уровня при создании профессионально-ориентированного ПО и соответствующих технологий решения задач для узкоспециализированные применений в конкретной проблемной области.

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

Традиционные средства программирования

Обобщенная модель традиционного программирования представлена на рис. 2. Программисту предоставляется системное ПО с минимальным набором инструментальных средств (редакторы, компиляторы, отладчики и т. д.), нам которым могут надстраиваться дополнительные инструментальные средства, поддерживающие определенную ПАРАДИГМУ ПРОГРАММИРОВАНИЯ. Под ней понимается некоторый общий план, который должен выполнить программист (с использованием соответствующих инструментальных средств) для достижения поставленной цепи. Используя программное окружение (по рисунку: операционная система, инструментальные средства и парадигма программирования), программист должен достичь основной цели — решения задачи, В описанной модели программист является связующим звеном между дифференцированными компонентами среды, т. е. он постоянно должен не только отслеживать логику решения задачи, но и реалиэовывать последовательность вызовов инструментальных средств в Соответствии с парадигмой программирования. При этом программист должен удерживать в уме большой объем различной информации: парадигму, существенно отличающиеся друг от друга командные ячыки операционной системы и инструментальных средств, информационные связи между отдельными компонентами среды. Вся эта информация и соответствующая ей деятельность являются рутинными на фоне «полезных», т. е. непосредственно связанных с решением задачи, хотя и занимают немалую долю общих усилий программиста.

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

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

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

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

сравнительно низкий уровень автоматизации труда;

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

недостаточная поддержка инструментарием проектирования систем (поддерживаются в основном процессы, связанные с кодированием программ).

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

СОВМЕСТИМОСТЬ — отдельные инструментальные компоненты трудно объединять как на интерфейсном уровне, так и на уровне и* применения;

ОДНОРОДНОСТЬ —наборы инструментальных средств отличаются друг от друга в зависимости от используемых ЭВМ, операционных систем, языков программирования, что значительно затрудняет работу программистов,

ГИБКОСТЬ — большая часть инструментальных средств ориентирована на строго определенную парадигму программирования и затрудняет переход к другой модели их использовании

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

Интегрированная среда программирования

Интеграция отдельных инструментальных компонентов в единую систему с развитым интерфейсом — реальный путь преодоления рассмотренных проблем. В качестве такой системы выбрана ИНТЕГРИРОВАННАЯ СРЕДА ПРОГРАММИРОВАНИЯ (ИСП), которая в зависимости от целей применения может нести различную функциональную нагрузку.

В отличие от традиционных средств программирования ИСП обеспечивает:

более жесткую регламентацию создания ПО,

более высокий уровень автоматизации;

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

развитый интерфейс, основанный на перспективных подходах взаимодействия пользователя с ЭВМ;

увеличение суммарной эффективности компонентов среды;

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

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

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

Уровни интеграции инструментальных средств

Предлагается два вида интеграции инструментальных средств на уровне:

технологических модулей (интеграция 1-го уровня);

интегрированных сред (интеграция 2-го уровня).

Под ТЕХНОЛОГИЧЕСКИМ МОДУЛЕМ (ТМ) понимается ограниченный набор элементарных инструментальных средств, которые выполняют конечное множество операций определенного класса.

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

интерфейсные;

инструментальные;

информационные;

операционные;

обучающие и др.

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

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

На 1-м уровне интеграции (ИНТЕГРАЦИЯ ПО ГЛУБИНЕ) технологические модули объединяются в ИСП. Качественный состав ТМ определяется функциональной направленностью целевой ИСП. В основе этой интеграции лежит интерфейсный технологический модуль, который представляет собой реализацию некоторого унифицированного интерфейса для конечного множества ИСП. Необходимое условие интеграции 1-го уровня — автономность технологических модулей.

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

ИСП, =1УИП, ИТМ, ТМ}, где ИСП^ — ИСП, выполняющая i-ю функцию;

УИП— унифицированный интерфейс с пользователем (интерфейсный ТМ); ИТМ = £ КГМ,— набор из К инструментальных ТМ, выполняющих

к К (обязательных] операций для i-й функции; ТМ = t1 TMt — набор необязательных технологических модулей.

На 2-м уровне интеграции (ИНТЕГРАЦИЯ ПО ШИРИНЕ) отдельные ИСП объединяются в ИНСТРУМЕНТАЛЬНО-ТЕХНОЛОГИЧЕСКИЕ КОМПЛЕКСЫ (ИТК), использующие индустриальные подходы к созданию и сопровождению программного обеспечения; при этом качественный и количественный состав ИСП определяется исходя из конкретных условий применения ИТК и решаемого круга задач.

В основе интеграции этого уровня лежат локальные сети ЭВМ, которые позволяют:

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

рсализовывать принципы интеграции и разделения (специализации) труда в условиях коллективов программистов:

распределить «производственные мощности» ИТК (инструментальное программное и аппаратное обеспечение) по принципу «все для одного или один для всех»;

снизить стоимость разработок в условиях ИТК.

Необходимое условие интеграции 2-го уровня — автономность ИСП.

Предложенные методы положены в основу компоновки отдельных компонентов экспериментальной системы автоматизации проектирования, изготовления и сопровождения ПО ЭКСПРОМТ, а также инструментальных комплексов, создаваемых на их основе.

Компоненты ЭКСПРОМТ по функциональному назначению относятся к инструментальному ПО и поддерживают обеспечивающую технологию, т. е. являются инструментарием 1-го уровня.

Структурно ЭКСПРОМТ состоит из базового набора автономных интегрированных сред программирования с различной функциональной ориентацией.

Вазовый состав ЭКСПРОМТ определяют следующие ИСП:

экспериментальная среда изготовления ПО (ЭЛИС/И);

экспериментальная q^ejia проектирования ПО (ЭЛИС7П);

экспериментальная среда документирования ПО (ЭЛИС/Д);

экспериментальная среда управления и планирования разработки (ЭЛИС/УП).

Экспериментальный образец системы ЭКСПРОМТ разрабатывается в ИПИ АН СССР.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=1347&lang=&lang=&like=1
Версия для печати
Статья опубликована в выпуске журнала № 1 за 1989 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: