Вышинский Л.Л., Гринев И.Л., Флеров Ю.А., Широков А.Н., Широков Н.И. Генератор проектов инструментальный комплекс для разработки "клиент-серверных" систем

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

Автор: Вышинский Л.Л., Гринев И.Л., Флеров Ю.А., Широков А.Н., Широков Н.И.

Источник: http://ict.informika.ru/ft/002154/journ1-2_page6_25.pdf

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

Введение

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

1. Проектный подход к разработке информационных систем

Вообще говоря, всегда между постановкой задачи и ее реализацией существует разрыв. Но в большинстве сфер производственной деятельности его научились преодолевать за счет квази-реализации, то есть за счет создания проектов. Это непреложная истина: для того, чтобы избежать поспешных решений и неудачных реализаций, для того, чтобы получить продуманную, добротную и красивую вещь (здание, конструкцию, машину, программную систему), необходимо сначала разработать ее проект, со всех сторон проанализировать его, обсудить со специалистами, может быть, построить макет и лишь после этого приступать к реализации, неукоснительно следуя проекту. Во многих традиционных сферах этап проектирования узаконен и существуют определенные правила и стандарты создания проектов. Но этого мало, между проектом и конечным объектом, как правило, стоит технология, которая определяет необходимое оборудование, инструменты, оснастку и другие средства конкретной реализации проекта. В области прикладного программирования ситуация несколько иная. Конечно, любой программной разработке обязательно предшествует некий план, или техническое задание, или даже проект, например, в виде набора квадратиков и стрелочек между ними. Существуют даже определенные подходы к построению таких проектов. Одним из наиболее развитых методов проектирования информационных систем является структурный анализ и функциональное моделирование, которые были положены в основу концепции SADT - Structured Analysis and Design Technique [1,2]. На основе SADT в ряде отраслей были даже разработаны стандарты проектирования больших информационных систем [3]. Как показал опыт, использование таких подходов весьма полезно для этапа исследования предметной области, построения структурной модели системы автоматизации этой области, обеспечивающей ее функциональную полноту и непротиворечивость. Однако построение структурной модели не исчерпывает все содержательные проблемы, которые хотелось бы решить на этапе проектирования. Проект системы с точки зрения программистов, которые его реализуют, должен содержать полную информацию о том, с какими содержательными понятиями и объектами, с какими математическими моделями в данной системе будут иметь дело пользователи, как эти объекты связаны между собой, каковы свойства этих объектов, что с этими объектами можно будет делать, какие функции и процедуры должны быть реализованы в системе, в каком виде должны быть представлены результаты и так далее и тому подобное. Только такое максимально детализированное описание задачи может в полной степени соответствовать понятию проекта и служить отправной точкой для программирования. Можно задать вопрос, а чем, собственно, полный текст программы на каком-нибудь алгоритмическом языке программирования плох в качестве проекта. Ведь в этом тексте однозначно определены все содержательные понятия и модели? Это действительно так, но в тексте программного кода очень трудно, а практически - невозможно отделить содержательные вопросы от чисто программистских аспектов, связанных с реализацией проекта в конкретной вычислительной среде. А такое разделение, на наш взгляд, крайне полезно как с точки зрения специализации разработчиков, так и для более четкого выделения и понимания всех возникающих проблем, и содержательных, и программистских.

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

Надо сказать, что наши взгляды на создание программных проектов формировались постепенно, в процессе более чем двадцатилетней практики разработки прикладных информационных систем. На этом пути нами была создана серия различных технологических инструментальных средств [4,5,6,7], которые в течение долгого времени позволяли относительно небольшому коллективу разрабатывать, внедрять и сопровождать различные прикладные информационные системы в самых разных предметных областях.

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

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

2. Архитектура "клиент - сервер"

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

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

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

- клиентские модули;
- прикладной программный сервер системы;
- система управления базой данных.

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

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

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

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

3. Структурная модель проектируемых систем

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

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

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

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

<КМ> <входные данные> <ПС>-> <результат> <КМ>

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

<входные данные> <ПС>-^ <результат >

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

Многие современные системы коллективного пользования предоставляют возможность работать большим группам своих клиентов через ИНТЕРНЕТ. В рамках представленной структурной модели для этой цели служат специализированные SQL-серверы. Используя только стандартный ИНТЕРНЕТ-браузер, пользователи в рамках выделенных им полномочий могут выполнять определенные запросы к прикладным серверам. SQL-серверы по сути являются специальными клиентскими модулями коллективного пользования.

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

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

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

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

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

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

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

Утилиты по работе с базами данных. Важным аспектом разработки прикладных систем является разработка специальных средств для инсталляции и сопровождения системы. Для поддержания этих функций в нашей структурной модели предусматривается специальная утилита - конфигуратор баз данных. Конфигуратор баз данных используется для построения командных файлов, создания пустой базы данных, создания основных объектов базы данных (таблиц, индексов), удаления их из базы данных, а также обновления баз данных при модификации системы.

В конфигураторе базы данных предусмотрена также функция генерации командных файлов загрузки и выгрузки информации в текстовые файлы. Такая загрузка и выгрузка может использоваться как для резервного копирования наряду со штатными средствами системы управления базой данных, так и для переноса информации в базу данных под управлением другой СУБД. Например, можно выгрузить информацию из базы данных MS SQL Server и загрузить в базу данных Oracle, используя промежуточное представление в виде текста.

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

Заключение

Эффективность всякой автоматизации, как правило, измеряется коэффициентом повышения производительности труда. Разумеется, и при применении ГЕНЕРАТОРА ПРОЕКТОВ к разработке прикладных информационных систем хотелось бы иметь такие оценки. Объем автоматически сгенерированного программного кода (сумма объемов только *.с, *.Ь файлов ~0.7 Мгб) более чем в сто раз превышает суммарный объем исходных файлов проекта (~5 Кбт). Для крупных проектов это соотношение будет меньше, но все равно оно составляет, как минимум, порядка десяти. Это, конечно, обеспечивает очень высокую производительность труда разработчиков прикладных систем. Однако не в этих цифрах заключается основной эффект от примения ГЕНЕРАТОРА ПРОЕКТА. Главное преимущество проектного подхода состоит в том, что он разделяет две области деятельности -содержательное моделирование прикладных задач и технологические проблемы программирования. Благодаря этому появляется возможность достаточно глубокой формализации на этапе постановки задачи, т.е. в процессе проектирования системы. С другой стороны, средства проектирования, то есть правила описания системы, их форма и содержание, однозначно соответствуют доступной в данный момент технологии создания программ, которая заложена в ГЕНЕРАТОРЕ ПРОЕКТА и в той структурной модели, на которую он опирается. Развитие структурной модели, расширение возможностей автоматической генерации программ будут совершенствовать и средства проектирования. В связи с этим нам представляется, что дальнейшее углубление проектного подхода, разработка более мощных языковых средств описания содержательных объектов, моделей и процедур, может быть, даже их специализация и ориентация на конкретные предметные области, являются весьма актуальной задачей для разработчиков прикладных информационных систем.

Литература

1. David A. Marca, Clement L. McGowan. SADT: Structured Analysis and Design Technique. McGrow-Hill Book Company, New York, 1988.
2. Brackett, J., and C. McGowan: "Applying SADT to Large System Problems", SofTech Technical Paper TP059, January 1977.
3. SofTech, Inc. "Introduction to IDEF0", SofTech Deliverable no. 7500-14, September 1979.
4. Вьшшнский Л.Л., Прибытков Ю.Д., Шиленко В.И., Широков Н.И. Инструментальная система ФАКИР.// Известия АН СССР, Техническая кибернетика, Москва, 1986 г., № 3.
5. Вышинский Л.Л., Гринев И.Л., Шиленко В.И., Широков Н.И. Инструментальные средства САПР. В сб. Задачи и методы: автоматизированного проектирования в авиастроении. ВЦ АН СССР, Москва, 1991 г.
6. Гринев И.Л., Широков Н.И. Средства управления данными в САПР. В сб. Задачи и методы автоматизированного проектирования в авиастроении// ВЦАН СССР, Москва, 1991 г.
7. Вышинский Л.Л., Гринев И.Л., Демидов А.Ю., Широков Н.И. Технологии разработки и сопровождения АБС// "Банковские технологии", Москва, 1997 июль-август.