Классификация преобразователей технологических операций

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

· поиск и выборка информации;

· создание инструментальных универсумов;

· управление метаданными;

· выбор общесистемных проектных решений;

· параметризация компонентов ИС;

· преобразование алгоритмов;

· преобразование программ;

· проведение контроля;

· формализация расчета показателей.

Рассмотрим характеристику каждого класса преобразователей.

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

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

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

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

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

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

Создание инструментальных универсумов. Множество универсумов можно разбить на два класса:

· проектные, содержат множество ранее разработанных проектных решений, которые могут быть использованы для реализации процессов обработки в создаваемой ИС без изменения или с частичной модификацией. К ним относятся «типовые проектные решения», классификаторы, унифицированные системы документации, алгоритмы решения задач и т.д. Эти универсумы используются для снижения трудоёмкости проектирования за счёт включения типовых проектных решений в ИС;

· инструментальные, используемые при проектировании для автоматизации выполнения проектных операций, например, множество ППП (Aris, BPwin, Erwin, Rational Rose) позволяют автоматизировать проектные операции по созданию проектных решений. Рассмотрим особенности создания инструментальных универсумов. С их помощью можно отслеживать теоретические концепции и практический опыт создания ИС и формирование на этой основе инструментальных универсумов. Примерами универсумов этого класса могут служить универсумы по методам проектирования, пакетам прикладных программ, системам классификации и кодирования, системам управления базами данных, формам документов для различных классов объектов, системам ввода-вывода. Для каждого инструментального универсума определяются: имя-идентификатор, структура элемента, множество значений.

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

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

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

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

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

Связи, описанные в СД, отображают:

· структурную входимость реквизита в показатель, СЕИ или БД;

· входимость показателя в СЕИ, БД, входные и выходные документы;

· вывод форм выходных документов на соответствующих устройствах вывода;

· прочие.

Примечание: возможны и обратные связи, например, показатель включает данный реквизит, и т. д.

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

Следовательно, СД адекватно отображает состояние создаваемой системы обработки данных на всем временном интервале ее существования.

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

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

Как показывает опыт разработки информационных систем, проект ИС включает в среднем [20]:

· 2000 реквизитов;

· не менее 4000 показателей (со всем их структурным разнообразием);

· одну базу данных;

· 200 форм входных документов;

· 400 форм выходных документов;

· 400 файлов;

· 1000 программ;

· 6 пакетов прикладных программ;

· 20 устройств ввода-вывода;

· 60 документов проекта.

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

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

· внесение новых компонентов со связями;

· корректировка компонентов и связей;

· поиск информации, причем вход может быть с любой составляющей, определенной выше;

· вывод на печать или на экран дисплея информации о компонентах и их связях;

· контроль данных, например, выполнения наложенных запретов.

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

· комплекса технических средств;

· системы ввода-вывода;

· версии операционной системы;

· системы программирования;

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

· решений по телеобработке;

· системы управления базами данных;

· пакетов прикладных программ;

· инструментальных средств проектирования;

· средств автоматизированного проектирования.

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

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

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

Приведем пример использования параметров при выборе системы управления базами данных. При проектировании любой ИС встает вопрос, нужна ли СУБД, а если нужна, то какая конкретно. При этом надо учитывать, что системы обработки данных проектируются для работы на достаточно большом интервале времени, поэтому они должны обладать определенными свойствами, прежде всего адаптивными. В типовом варианте используется ряд СУБД: ACCESS,ORACLE, FOXPRO, SQL_SERVER, PARADOX, INTERBASE и др. [1]. Каждая из них имеет несколько версий. Для оценки соответствующего компонента ИС (в данном случае СУБД) и его выбора необходимы некоторые интегральные характеристики этих средств, т.е. некоторое параметрическое описание соответствующих компонентов. В зависимости от рассматриваемых средств различаются определяемые для них параметры. Список параметров для описания соответствующих компонентов должен быть полным. Приведем основные параметры, характеризующие системы управления базами данных:

· структура данных, на которую ориентирована данная СУБД (иерархическая, реляционная или сетевая);

· ресурсы вычислительной системы, на которые ориентирована соответствующая СУБД (объем оперативной памяти, памяти на дисках, быстродействие процессора). Величина ресурсов должна характеризоваться по крайней мере двумя значениями: минимальными, при которых СУБД может работать, и оптимальными, при которых СУБД будет работать с наибольшей отдачей, т.е. обеспечивать минимальное интегральное время получения информации или минимальную стоимость обработанной единицы данных;

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

· параметры проектируемой информационной системы, т. е. их перечень и границы изменения значений. В первую очередь это характеристики документооборота, общий объем информации Q за время t, причем Q =f(t), пиковые нагрузки, время реакции системы на получение необходимой информации и т. д.

Анализ значений данных параметров позволит проектировщику выбрать СУБД, которая в наибольшей степени соответствует проектируемой ИС.

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

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

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

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

· смысловой (семантический), оценивающий правильность выполнения технологической операции (операций) исходя из конечных целей проектирования ИС;

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

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

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

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

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

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