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

АКАДЕМИЯ НАУК СССР Ордена Ленина Сибирское Отделение Институт систем инфориат ики

На правах рукописи

Сорокин Вячеслав Викторович

УДК 6«!.3

МОЛЕЛЬ АРХИТЕКТУРЫ ТЕХНОЛОГИЧЕСКИХ ПРОГРАММНЫХ ОКРУЖЕНИЯ ДЛЯ БОЛЬШИХ СИСТЕМ

( 0 5.13.11 - патепати ческое и програн иное обеспечение вычислительных папин , комплексов, систем и сетей )

Автореферат диссертации на соискание ученой степени кандидата фи э ико-натенати ческ их наук

Новосибирск - 1991

Работа выполнена 8 Новосибирскон филиале Института точной механики и вычислительно* техники ия . С.А.Лебедева АН СССР

Научны* руководитель - локтор фиэико-катеяатических наук .В.П.Ильин

Официальнме оппоненты - доктор фиэико-натенатических наук

И.В.Поттосин

кандидат физико-математических наук

В.А.Марков Ведущая организация - НИВЦ МГУ

Защита состоится

гола в

часов на

систем информатики СО АН СССР по апресу:

630090, Новосибирск-90, пр. акад . Лаврентьева, 6.

С диссертациэи можно ознакомиться в читальном зале ВЦ СО АН СССР (Новосибирск-90, пр. акад. Лаврентьева, 6).

Ученый секретарь специалиэированмого совета кандидат физ.-пат. наук

В.К.Сабельфельд

- 3 -

1. ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

- модель 'как выход этапа системного анализа" - рассматривается результаты выполнения прелпрогракнистекого этапа системного анализа , особенно важного для Больших систем ;

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

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

- окружении 'для больших систем" - характеризующихся обь-емон разрабатываемого ПО в сотни тысяч строк, продолкитель-ностью разработки 5-10 лет, привлечением коллективов разработчиков в несколько десятков человек , сроком службы более 10 лет с регулярными модернизациями через 2-4 гола; причем ТПО само относится к большим системам .

Актуальность теми. Среди важнеивих проблей , включенных в комплексную программу научно-технического прогресса до 2000 года ("Правда" от 19.12.85), определена проблема 1.1.6: "Развитие технологи и разработки и промышленного произ водетва программных средств вычислительной техники", одна из первоочередных задач которои была сформулирована как 'определение концепции и принципов построения базового интерфейса и мобильном технологической среды, обеспечивающих коллективную разработку качественных программных средств, новых принципов фондирования и стыковки друг с другом при независимой разработке, а также их многократную применимость взамен дублирующих разработок." Актуальность данном работа определяется ее сходством с этой задачей.

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

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

Данная работа проводилась в плановой порядке в ранках тематических работ по НИР 'Исследование и разработка интегрированной мобильной среды поддержки ХЦПО встроенных систем реального времени*, по ОКР 'Технологическое программное окружение на базе языка Фортран* и "Базовый комплекс инструментальных средств программного окружения для языка Фортран*.

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

В соответствии с цепью основными задачами является:

1 , Исследование* концепции и принципов построения существуют« х развитых технологических окружении поддержки ХЦПО, с проведением комплексного обследования области больних встроенных систем реального времени.

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

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

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

Нотодика исследования характеризуется комплексным подхо—

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

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

Достоверносгь результатов определяется:

- во-первых, самим способом построения подели, в основе которого лежит обобщение опита отечественных я зарубежных разработок;

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

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

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

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

2. Разделением ропи и песта в архмт ектуре ТПО нзспец нали -эированнои СУБД с развитыми эволюционными возможностями и специализированных ТБД в технологиях конкретных проектов.

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

4. Непосредственным отражением в принципиальном подели архитектуры ТПО механиэиов фондирования и переиспользоаания программных компонентов посредством организации уровня пере-мспольэуекых форм.

Теоретическая и практическая ценность работы определяется использованием основных ее положении и результатов при создании и оценки леяств/ювего макета интегрированной новияьнок среды поддержки ЖЦПО Больших встроенных СРВ, при подготовке предложения по архитектуре технологического программного окружения на базе языкажФортран, обосновании архитектурных решения по базовому комплексу инструментальных средств программного окружения.

Апробация работы. Материалы представленной работы докладывались и обсуждались на Всесоюзной конференции по трансляции и к о не г руиров ани ю программ {Исвосиби рек t )98&), на семинаре "Системное программирование* (ИСИ СО АН СССР, Новосибирск) . Отдельные положения сообщались на научно-тех-яическоя конференции "Архитектура и программные средства вы-соколрокзводительных вычислительных систем* (Новосибирск, 1985) и семинарах НФ ИТМ и ВТ.

Пубяикации . По теме диссертации иместся 9 печатных и 1] рукописных работ .

Сг руктура и обьен работа. Работа состоит из введения, 5 г лав, заключения и списка литературы. Основноя текст изложен на 149 страницах , включая 12 рисунков и S таблиц. Список основной использованнои литературы вклъчает 77 наииеновании.

2. СОДЕРЖАНИЕ РАБОТЫ

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

Глава 1 начинается с обзора методов и процедур традиционного понятия системного анализа больших систем. Согласно определение в СЭС, "системным анализ - совокупность методологических средств, используемых для подготовки и обоснования решении по сложным проблемам .., научного и технического характера. Опирается на системны« подход, а также на ряд математических дисциплин и современных методов управления. Основная процедура - построение обобщенной_модели >

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

"Затем рассматривается системный анализ применительно .к программным проектам . С учетом рассмотренного опыта в эаклю —

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

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

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

изучения особен ^ кик систем. Обращение к больиин

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

Краткие характеристики результатов проведенного обследования, отражающие специфические особенности, требования и тенденции по каждому из компонентов больших встроенных систен выполнены на основании соответствующих отчетов по НИР 13 -7]. В целях наглядности эти результаты сведены в общую таблицу, которая объединяет определяющие факторы, наблюдаемые тенденции и основные выводи цо каждому из компонентов: 5ЦВН, их приложениям, целевому ПСГ, языкам программирования, инструментарию -и общея архитектуре.

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

1) необходимость Бояыаих капитальных затрат на разработку инструментов, часто сравнимых с затратами на целевое "ПО, значитея ьно сдерживает к к разработку в ранкак прик ладного проекта; руководители проектов более склонны поэтояу использовать ручные методы как более дешевые и гибкие, чем специально разрабатывать свои инструмент;

2 > дифференциация инструментов, вызванная развитием функ-ция традиционных систем программирования, наблюдается одновременно с тенденцией к их интеграции в технологические окружения ;

3) все более строго и последовательно разделяются функции "инструмент ал ьнои ** и "целевой " мавины . Развитие кросс -технологии особенно актуально для вот роеиных систем из-за необходим ости "выжимать" предельные характеристики по производитель ноет н и условиям зкеплуагации бортовых ЭВМ j

4) для &о.лыаих систем характерно на практике распространение инструментальной поддержки на весь жмэненныя цикл ПО , захватывая э тапы определения требовании м спецификации , с одной стороны, и эксплуатации и сопровождения, - с другой, и вызывая рост нногоообразия моделей ХЦПО ;

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

6) особое вникание разработчиков больянх систем уделяется средствам версионного программирования и конфигурационного управления на основе технологических баз данных 1ТБД).

В главе 3 рассматривается другая более практическая составляющая опыта, к от ория получен на примере создания реально действующего макета интегрированной мобильно» среды поддержки жизненного цикла программного обеспеченна встроенных систем реального времени на БЭСМ-6 IS).

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

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

На проектирование пакета больоое влияние оказал популярный в это время подход APSE. В соответствии с нин в пакете можно выделить следующие три урооня:

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

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

- нихнии уровень 'ататнык* средств.

В peaли эацим накета качестве ни »него уровня использованы итатные системы Транс-ЯРМО и комплекс Интеграл, которые могут работать в райках ОС ФЕЛИКС и ОС ДИСПАК на ЗВП БЭСМ-6 и Элъврус-1К2. Реализация базового уровня среда поддержки выполнена по методу бы строг о лрототипироеания на основе заимствования программных модулей инструментария из базового системного програм иного обеспечен* я для ЭВМ семейства БЭСМ. А верхнии уровень представляет языки описания архитектуры проекта ЯОА и спецификации модулей ЯС/ЯРКО-3 для программированы я -в-большо* , языки ЯРМО-3 и ЯРМО-2 пня програниированме-в-малом, относи тельно сапостояте льни и язык управления реализацией ЯУР м средства СКУ для переопределение физической организации молулеи f 9).

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

t). В силу больших объемов работ и проблем , стоящих перед разработчиками, реализации технологических окружении на основе оригинального языка (как ЯРМО-З в навел случае! объективно не могут рассчитывать на успех в условиях слабого распространения языка. Разработку 7П0 следует рассяатриват ь прежде всего как задачу интеграции существуючих инструментов, а не создания все новых и новых. Это требует совершенна иных подходов и ином идеологии разработки.

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

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

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

3). Реализация возго*ностаи, зависящих от условия проекта, оказалась чрезвычайно трудоемкой задачей в райках "специализированного' подхода к созданию ТБП, принятого в пакете. В макете приелось ограничиться реализацией линь технических функция СКУ — поддержкой нногоаерсионности, множественности представления (текстов, кодов, внутренних таблиц к т.п.), в то время как административные функции, существенно зависящие от особенностей конкретного проекта, предъявили слмщком жесткие требования к адаптационным возможностям ТБД. Отсюда вывод, что в архитектуре ТПО следует иметь не просто "специализированное хранилище всей информации по проекту*, а СУБД, как инструмент для создания, ведения и, что очень важно , развития Баз данных в конкретных проектах.

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

Лоэтону материалы комплексного, но ограниченного конкретной областью, обследования Были дополнены рядом частных, но охватывающих Более яирокии круг приложении* аналитических обзоров по наиболее существенный вопросам технологий программирования :

- модели жизненного цикла больиих систем 1101;

- языки программирования бояьыих встроенных систем (.11];

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

Для целей системного анализа важно, что эти, охватывающие

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

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

В практике программирования используются сотни поделен ХЦПО. Чтобы разобраться в них, нужны соответствующие схемы классификации. Автором предложена классификация моделей ХЦПО , основанная на логике естественного развития концепция жизненного цикла (10 J.

Из анализа, используемых в разработке больших систем моделей ХЦПО и тенденции их развития вытекает следующие выводы:

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

2. Развитие моделей ХЦПО больших систем в последние годы явно смещается в сторону более ориентированного на прикладного программиста эволюционных подходов , как более соответствующих природе и уровню сложности больших программных систем. Альтернативные модели ХЦТЮ , включая автопати эированные модели, модели с переиспользованием и быстрым прототипкрова-нием, занимают в этой классификации промежуточное положение между моделями, соответствующими чисто трансформационном и чисто эволюционной парадигмам. Однако из этого не следует неустойчивость их положения. Напротив, объединяя достоинства обоих подходов, альтернативные модели реально являются наиболее перспективныни на блихапоее Будущее .

3. Нет и не может быть универсально« модели ХЦПО. Поэтому инструменты , сходящие в состав ТПО, не должны навязывать конкретную модель ХЦПО; напротив , архитектура ТПО должна обеспечивать адаптацию инструментов к жизненному циклу, определяемому условиями конкретного проекта.

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

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

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

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

2* С другой сторон», на практике обнаружилась тенденция к усиленно дифференциации языковых средств по фазам ЖЦПО. Эта* тенденция отчетливо проявилась при рассмотрении языков программирования больших встроенных СРВ, однако имеет Более общий характер и касается вообще языков для больших систем.

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

Однако на практике использование технологии баз данных заметно сдерживается. Чтобы понять причины этого, автор провел анализ средств ТБД в ТПО м тенденции их.развития 112), на основе которого и с учетом работ (13,14] били сделаны следующие выводы:

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

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

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

- \г -

Глава 4 посвящена совсгвенмо 'построению обобщенной модели* архитектуры ТПО на основе результатов системного анализа узких мест, заявленных в ходе проведенного обследования. Хотя выполнение на предыдущем зтапе аналитические обзоры по таким вопросам как модели ДЦГГО , языки программирования , ТБД, могут, видимо, представлять самостоятельный интерес, в контексте данном главы они рассматриваются в качестве базы системного анализа.

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

Как выяснилось из анализа к ним относятся три группы противоречия t которые оказывают влияние на всю архитектуру ТПО:

1) противоречия процесса автоматизации ЯЦПО;

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

3) противоречия в организации средств ТЕЛ.

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

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

Вторая группа противоречия особенно наглядно проявляется

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

Вновь решение подсказывается практиков, а именно, тенденцией к дифференциации языковых средств по фазан ХЦПО, наблюдаемой как :

- выделение PDL-подмножеств для описания структуры проекта при проектировании архитектуры системы;

— разделение средств програмиирования~в-6ольяон и -в-малом;

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

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

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

Источником третьей группы противоречия является принципиальное различие функция ТБЛ:

1) как модели проекта, призванно* отражать индивидуальную структуру конкретного проекта;

2) как ядра ТПО, которое должно служить о качестве универсальной развязки для инструментов, входящих в окружение.

Поэтому перед разработчиками возникает дилемма, не всегда разрешаемая на практике, — либо ориентироваться на универсальную, оттого и неэффективную ТБД, но дающую возможность заранее реализовать мощные инструменты, образующие ТПО; либо

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

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

Однако остается противоречие, состоящее в необходимости создавать инструменты окружения,, работающие с ТБД, прежде чем сама ТБД будет сгенерирована. К счастью, традиционная технология баз данных предлагает, и в этом ее прянояпяальное отличие от использования фаяяовык систем, средство, способное снять это противоречие. Речь идет о механизме подсхем, которым допускает возможность дхя одном сжеми БД иметь разные пользовательские <в навей случае, инструнемтоориентиро-ванные) представления данных. Специфицируя предполагаемые подсхемы ТБД дня инструментов, можно разделить во времени моменты создания ТБД и инструментов, т.е. начать реаиьно разрабатывать инструменты'вще до фактического создания ТБД конкретного проекта. В »том случае создание экземпляров ТБД на стадии технологической подготовки каждого проекта связано с привязкам существующих инструментов с помощь» соответствующих подсхем к конкретной схеме ТБД.

С учетом результатов проделанного анаяяза Были предложены пути преодоления ограничении существующих ТПО 1151 к сформулированы требования к организации инструментальных систем (16*17], которые легли в основу предлагаемом модели архитектуры ТПО (181.

Последняя предусматривает четыре уровня организации технологической поддержки (см. рис}!

Уровень специализированных технологии (СТПО)

\ проектирование-а \ -в-больвом

программкрование--в-калом

интеграция и отладка

л т и р

э е б

л

е п н р

и о е е

Уровень общего ТПО (ОТПО > = инструмент инструментов + переиспользуемые форм»;

Базовых уровень (БТПО)

.язык реализации

.транслятор

.СУБД

.СПТ

.СКУ

Каик ноэ» к рани -1 рук>ция уровень IЭТПО)

ЭВМ

.ВТМ .ВЦП

.коиплвк-сатор

.отладчик

.загрузчик

.интерпретатор языка

управления задани ями

язык управления заданиями 1ЯУЗ>

.библиотеки переиспользуем ых модулей

.полсхемы ТБЛ

.конфигуратор«

.передние МНЗ-части трансляторов

.заготовки

кодогенераторов

.имитаторы внеянеп среды

.отладочные стенды и т.д. и т.п.

ТБД проектов

/

/с

Рис. Многоуровневая архитектура ТПО

- 17 -

1) маяино-экранирующми уровень ЗТГ10 , обеспечивающий виртуальные интерфейсы для инетрументал ьноя и целевой навин;

2) вазовый уровень БТПО, содержащий минимальное функционал ьно полное подиножество инструм ентов яля обеспечения переносимости ;

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

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

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

Во—первых , и нтегрирующим эвеном каждой частной технологии проекта служит своя ТБД, основным требованием которой (в соответствии с ее назначение?» — отражать текущее состояние проекта) является требование адапт ируемости и развиваемости; поэтому в составе окружения предусмотрена мощная неспециали -зировалная СУБД с развитымм возможностями реструктуризации и реорганизации БД.

Во-вторых, архитектурно предусмотрен уровень так называемых "переиспользуемых форм* ~ программных полуфабрикатов, подсхеи , заготовок для сборки и настрокки конкретных технологии ;

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

В-четвертых 4 предлагаемая модель отражает не только нно-гояэыковость а смысле традиционном взаимозаменяемости входных языков на этапе программирования, но и дифференциацию языковых средств по фазам 2ЦП0 .

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

- к -

кого проектирован*» двух архитектур: технологического прог-раямного окружения на Базе аэика Фортран ала вичкслительного коцплекса Зяьбрус—3.1 119] и Базового комплекса инструиен-тальних средств ирограяиного окружения (БКИСП01 дня разработки я сопровождения на ПЭВМ (Ш РС прикладных програикных комплексов на Фортране та Больилх ЭВП (201.

Конкретизация архитектура ТПО является в известная спиеле пряно противоположно* операцией по сравнена» с предадуиияи деиствияяя по оБоБценяв суиествуоиеи практики при построения принципиальной иоаеяи. Однако я в этой случае от системного аналитика тра&уегся ткательння учет специфики и анализ тенденции развития технологии программирования в соответствуо-яеи оБяасти прияожв кия. Если в первой случае это нужно вило для того, чтоБи исключить вяяяняе специфики встроенных приложении при обоБиении результатов анализа, то в последнем случае, напротив«- итоБи учесть суаественние особенности применения Фортрана в Бояьиих приложениях при конкретяэацяи принципиальной архитектура ТПО.

С этой цепьо Бил сделан обзор и анализ специфики суяест-вуаих окружения- для яэика Фортран в 120], чтобы определить особенности и направления развития и принять реяения по конкретизация. принципиальной модели с учетом реальная условии конкретно« разработка.

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

1. Выработана яетрдика в проведен сястеинкк анализ узких мест архитектур» ТПО как Больной инструментально* система, результата«* которого является:

а) классификация яодеявя ХЦПО Больших систем;

6 1 определение закономерностей дифференциации «эикових средств по функциям я фаза* Х1Ш0 Бояьиих састеи;

а) обоснование принципиальном роли несяецяалазированнои СУБД .с развитии* •вонпииаииыи* аозяаккостяяи для ведения спе-jiaanaэированних ТБЯ в ралк&х технология конкретных проектов.

2. На-основе пакетирования архитектуры я анализа опита реализации действующего макета интегрированноа аобияьноя среды поддержки жизненного ЦИКя» програяиного обеспечения встроенных систа« рввяьного врелени еистенатизирована, определен» я уточнен* требования к уровнал архитектуры, составу инструментов и к отпвльнил кояпоивнтая ТПО.

- 19 -

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

а) выделение?* в качестве самостоятельного уровня индивид-дуальных технологии над уровней общей поддержки ГПО с целью согласовать преимущества индувидуальноя технологической подготовки проектов с промыяленнын производством вазовых инструментов ТПО;

б) разделением в архитектуре ТПО места и роли неспециали-зированнои СУБД с разви тыми эволюционными возпожностями и специализированных ТБЛ для конкретных технологии;

в ) обобщением принципа многоя зиковости , г ради ционно сводимого к взаимозаменяемости языков реализации на этапе программирования, до дифференциированного ло функциям и фазам ЗЦПО мультиязыкового интерфейса;

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

Спи сок выполненных работ по теме

1, Определение требования и принципов разработки технологических окружения встроенных СРВ на вазе языка реализации высокого уровня: отчет о НИР/АН СССР. Ин-т точной механики и вычислительной техники, Новосиб.Фил.; рук. Р.Д.Чииин -АТИ-НД 395/01-5. - Новосибирск, I9S6, - 214 С. - Авт.: В.В.Сорокин.

2. Архитектура бопьвих встроенных СРВ: Отчет о НИР/АН СССР, Ин—т точное механики и вычисд .техники . Новосиб,фил.; рук. Г.Д.Чмнин. - АТИ-НД 416/03-5. - Новосибирск, 1937. - 43 с. - Авт.: В.В.Сорокин,

. 3. Тенденции развития БЦВМ: Отчет о МИР/АН СССР.Ин-т точной механики и вичисл. техники. Новосиб . филиал.; рук. Г. Д.Чннин. - АТИ-НД -920/07 -5. - Новосибирск, I9S7.- 66с.- Авт.: В .Б .Сорокин,

4, Особенности приложения БЦВМ: отчет о НИР/АН СССР. Инт точной механики и вичисп, техники, Новосиб.фил.; рук. Г. Д.Чинмн. - АТИ НД 418/05-5. - Новосибирск,1987.- 70 с.-Авт.: В.В .Сорокин.

5. Особенности программного обеспечения больших встроен-

них систем: Отчет о НИР/АН СССР. Ин-т точной механики и вит числ . техники . Новосиб.фил.; руководитель Г.Д.Минин. - АТИ-НД 423-10/$.- Новосибирск, 1987. - 42 с. - Авт.: В.Б.Сорокин.

6 . Особенности языков программирования больших встроенных СРВ: Отчет о НИР/АН СССР. Ин-т точной механики и вычисл. техники. • Новосиб.фил. ; руководитель Г.Я.Чинин . -АТИ-НД 417/ 04-5. - Новосибирск, 1987 . - 70с. — Авт.: В.В.Сорокин.

7. Тенденции развития технологии программного обеспечения : Отчет о НИР/АН СССР. Ин-т точном механики и вычисл. техники. Новосиб .фил . ; руководитель Г.Д.Чинин. - АТИ-НД 419/ 06-03. - Новосибирск, 1947. ~ 172с. - Авт.: В.В.Сорокин.

£. Исследование и разработка интегрированном мобильном среды поддержки жизненного цикла программного обеспечения встроенных систем реального времени на базе языка реализации высокого уровня: Отчет о НИР/АН СССР. Ин-т точной механики и вычислительной техники. Новосиб. фил.; руководитель Г.Д.Чинин - АТИ-НД 422/ 09- - Новосибирск, 1987. - 132с. - Отв. В.В.Сорокин,

9. Л.М.Арбузов, В,И .Гололобов, В.В .Сорокин , С.Ф.Чухонцев . Опыт макетирования технологическом среды поддержки на основе базового системного программного обеспечения. - Новосибирск , 1991. - 22 с. — <Лрепринт/Ин-т точном пеханики и вычислительной техники АН СССР, Новосибирским филиал; 2).

10. Сорокин В.В. Модели жизненного цикла программного обеспечения. - Новосибирск, 1949 . - 39с. — (Препринт/Ин-т точной механики и вычислительной техники АН СССР, Новосибирским филиал;12).

11. Сорокин В.В, Тенденции развития языков программирования больших встроенных систем реального времени. - Новосибирск, 1990. - 50с. - (Препринт/Ин-т точном механики и вычислительном техники АН СССР, Новосибирским филиал; 5).

12. Сорокин В.В. Средства баз данных в разработке программ. - Новосибирск, 1991. - 50 с. - (Препринт/Ин-т точной механики и вычислительной техники АН СССР, Новосибирским филиал ; I ) .

1$. Методологические трудности в проблематике баз данных : Отчет/АН СССР.Ин-т точной механики и вычислительном техники, Новосибирски» филиал; руководитель В .И.Гололобов -АТИ-ПА 354-04. - Новосибирск, 1985. - 85 с. - Отв. исполнитель Б.В. Сорокин.

14. Сорокин В.В. Черти баз знания в базах данных. - Но-

восибирск, 19(3. — 18с. - |Препрмнт/Ин-т точной механики и вычислительном техники АН СССР, Новосибирским филиал; 13).

15. Сорокин В.В. Принципиальная модель архитектуры интегрированиях технологических окружении//-Метояы трансляции и конструирования программ/ Тезисы докладов всесоюзном конференции 23-25 ноября 1999, ВЦ СО АН СССР, Новосибирск, часть 2. - Новосибирск, 1988. - с.101103.

16. Сорокин В.В. 0 соотношении требования нногоязыковос-ти и переносимости tf Программное обеспечение вычислительных комплексов новой архитектуры. - Новосибирск,1986. - С.118-128.

17. Сорокин В.В. Требования к интегрированному технологическому программному окружение. - Новосибирск, 1989 - 20с.

- (Препринт/Ин-т точной механики и вычислительной техники АН СССР, Новосибирским филиал; II).

18. Сорокин В.В. Многоуровневая архитектура технологического програкмного окружения . - Новосибирск, 1988 - 30с . -(Препринт / Ии-т точной механики и вычислительном техники АН СССР. Новосибирский филиал; 10).

19. Технологическое программное окружение на базе языка Фортран: Требования к интегрированным технологическим пол-держиваоцим окружениям разработки больяих программ (аванпро-ект): Отчет f АН СССР. Ин-т точной механики и вычисл. техники. Новосиб.фил. ; Руководитель И.С. Голосов,- АТИ—КВ 431/025. - Новосибирск, 1988. - 90с. - Отв. йен. В.В.Сорокин.

20. Базовым комплекс инструментальных средств программного окружения для языка Фортран (эскизно-техническия проект): Отчет по ОКР / АН СССР. Ин-т точной механики и вычисл. техники . Новосиб. фил . ; рук . В.И.Гололобов . - АТИ-СК 516/01.

- Новосибирск , I 990.. — 401с. - От в . исполнитель : В .В .Сорокин .